Jane

The Cardano Constitution

PREAMBLE

The Cardano blockchain is a software protocol enabling development of contracts, applications, and digital assets in a permissionless, decentralized manner. Cardano, named for 16th century mathematician Girolamo Cardano, was launched in Japan in 2017. Its three pioneering founders, Input Output Hong Kong, Emurgo, and Cardano Foundation, chose peer review as a method to develop an open-source blockchain that is secure, scalable, and decentralized.

Early on-chain governance utilized on-chain parameters as well as off-chain decisions made by majority vote of the founders, who held seven genesis keys allowing them to make agreed changes to the protocol. The founders took input on Cardano’s development from scientists, academic experts, developers, and many others, including holders of ADA, the native currency of the blockchain. From creation of Cardano’s whitepaper, the aim was to fully decentralize governance.

On September __, 2024, an important milestone was realized when the genesis keys were turned over to community members all over the world, elected to its first Constitutional Committee. The goal of this Constitution is to set forth a governance framework which will keep the Cardano blockchain ecosystem alive, and thriving, for generations to come.

Article 1 - PRINCIPLES

Section 1

These principles are important to the community for the maintenance and growth of the Cardano blockchain, and proposed governance actions shall be evaluated in accordance with them.

• The Cardano blockchain ecosystem has the right to exist. In order for it to thrive, governance actions should strive to improve the scale, efficiency, and speed of transactions, without unduly compromising security and decentralization.
• The cost of transactions on the Cardano Blockchain should be based upon an accessible, and predictable pricing model.
• The Cardano Blockchain should promote interoperability with other blockchain protocols including sidechains and partnerchains.
• The Cardano Blockchain shall strive always to preserve all transactions on the blockchain and their accompanying on-chain information.
• The Cardano Blockchain shall maintain a Treasury of ADA governed in accordance with this document.
• The Cardano Blockchain should promote efficient design, memory, and storage.
• The Cardano blockchain shall continue to utilize ADA as its base currency.
• The Cardano blockchain shall take no action to abridge the current supply of ADA of 45 billion tokens.
• The Cardano blockchain shall take no action to remove the right of ADA holders to hold ADA in their own wallets in an unlocked manner, without the consent of such ADA holders.
• Unless otherwise agreed in an amendment to this Constitution, the Cardano blockchain shall continue to operate via proof-of-stake consensus mechanism, but may partner with chains operating with proof-of-work or other consensus mechanisms.

Section 2

The Cardano Blockchain shall operate in accordance with the Cardano Blockchain Guardrails as set forth in Article VII. The Cardano community may digitally codify Cardano Blockchain Guardrails to allow their implementation on the blockchain using on-chain scripts or built-in ledger rules. Where possible, on-chain implementation is desired and encouraged.

In the event of inconsistency between a Guardrail in this Constitution and a Guardrail programmed and implemented on the blockchain, the version deployed on the blockchain shall prevail and the Constitutional Committee shall seek to reconcile such inconsistency through on-chain governance action.

Article II - THE CARDANO BLOCKCHAIN COMMUNITY

Section 1

No formal membership shall be required to hold ADA or participate in the Cardano Blockchain ecosystem. All owners of ADA are beneficiaries of the Cardano Blockchain ecosystem.

Section 2

Members of the Cardano community who own ADA are entitled to access and participate in the on-chain decision-making processes of the blockchain ecosystem, either directly or through the appointment of delegates in accordance with this Constitution, including voting in accordance with this Constitution.

Article III - GOVERNANCE FRAMEWORK

Section 1

The Cardano Blockchain ecosystem shall utilize a decentralized, on-chain governance model for decision on changes to the blockchain or its governance, using, to the extent possible and beneficial, programmable “smart” contracts and other blockchain-based tools to facilitate decision-making and ensure transparency. On-chain voting for governance actions shall follow the processes outlined in this Constitution.

Section 2

Three governance bodies have been created to participate in voting on the Cardano Blockchain. These consist of Delegated Representatives (DReps), Stake Pool Operators (SPOs), and the Constitutional Committee (CC). Acting as a member of more than one of these groups fosters centralization, and could result in conflicts of interest to the detriment of the blockchain. Therefore, governance actions are favored which discourage the same parties from holding more than one position in governance, or which allow parties to disclose potential conflicts, and abstain from potentially conflicting votes.

DReps, SPOs, and Constitutional Committee members may be individual ADA holders or ADA holders who have organized as a group.

DReps, SPOs, and Constitutional Committee members will necessarily be required to incur transaction fees for voting. It shall not be unconstitutional for the community to vote for reimbursement for such fees or to compensate for the time expended to act as a DRep so long as allocation for such is made within an approved budget.

Section 3

On-chain governance decisions shall be made through a collective decision-making process, with specific consensus threshold requirements as required by Article VII of this Constitution, the Cardano Blockchain Guardrails. All on-chain governance actions shall be voted upon in accordance with such Guardrails.

Except as set forth in the Interim Period Guardrails of Article VII, every governance vote must be ratified by two of the three governance bodies, by the percentages specified in this Constitution.

Section 4

A special form of governance action exists to gauge community sentiment without committing to on-chain change of the Cardano Blockchain. These “info” actions have no on-chain effect other than to record the outcome of a vote on the blockchain.

Section 5

Any proposed on-chain governance action shall require a standardized and legible format including a URL and hash linked to documented off-chain content. Rationale shall be provided to justify the requested change to the blockchain. The rationale shall include, at a minimum, a title, abstract, reason for the proposal, and relevant supporting materials.

Any governance action proposal reaching the on-chain governance stage shall be identical in content as to the final off-chain version of such governance action proposal.

“Hard Fork Initiation” and “Protocol Parameter Change” governance actions shall undergo technical review and scrutiny as mandated by the Guardrails to ensure that the governance action does not endanger the security, functionality, or performance of the Cardano Blockchain. On-chain governance actions should address their expected impact on the blockchain ecosystem.

Section 6

The Cardano community is expected to propose, not less than on an annual basis, (nor more than on a ___ basis?) a budget for the ongoing maintenance and future development of the Cardano Blockchain. The budget shall be voted on through on-chain voting. No withdrawals from the Cardano treasury shall be permitted unless a budget for the Cardano Blockchain is then in effect.

[Any governance action requesting ADA from the Cardano Blockchain treasury in excess of [1,000,000] ADA shall require an allocation of ADA as a part of such funding request to cover the cost of periodic independent audits and the implementation of oversight metrics as to the use of such ADA.] [Contractual obligations governing the use of ADA received from the Cardano Blockchain treasury pursuant to a Cardano budget in excess of [1,000,000] shall include dispute resolution provisions.]?

Article IV - DELEGATED REPRESENTATIVES

Section 1

In order to participate in on-chain voting, owners of ADA must either register as DReps to directly vote on governance actions, or delegate their voting rights to other registered DReps who shall vote on their behalf.

Section 2

Any owner of ADA shall have the option to register as a DRep. Any owner of ADA shall be allowed to delegate their voting stake to one or more registered DReps, including themselves. DReps may be individuals or coordinated groups. DReps are entitled to cast votes directly for on-chain governance actions and represent those ADA holders delegating their voting rights to them. This voting system shall enshrine a liquid democracy model where owners of ADA can seamlessly select among DReps, register as a DRep, and change their delegation at any time.

Section 3

DReps may choose to adopt codes of conduct governing their activities as DReps and make such codes of conduct publicly available. However, codes of conduct are not expressly required, and it is hoped that any code of conduct which may be adopted will consider the enforceability of it in global jurisdictions, as well as the goals set forth in this document.

Section 4

DReps shall have the power to act as a check on the power of the Constitutional Committee under exceptional circumstances by voting on “Motion of no-confidence” and “Update committee/threshold” governance actions, as described in this document.

Article V - STAKE POOL OPERATORS

Section 1

A Stake Pool Operator (SPO) is an individual or entity responsible for operating a stake pool, which participates in the consensus mechanism of the Cardano Blockchain. SPOs shall have a specific role in approving critical on-chain governance actions which require additional oversight and independence, voting as set forth in this Constitution. SPOs shall participate in hard fork initiation processes as the operators of the nodes that participate in Cardano Blockchain’s consensus mechanism.

Section 2

SPOs shall have the power to act as a check on the power of the Constitutional Committee under exceptional circumstances by voting on “Motion of no-confidence” and “Update committee/threshold” governance actions, as described in this document.

Article VI - CONSTITUTIONAL COMMITTEE

Section 1

A Constitutional Committee shall be established to ensure that governance actions are consistent with this Constitution. The Constitutional Committee shall comprise owners of ADA responsible for ensuring that on-chain governance actions prior to enactment on-chain, are constitutional. The Constitutional Committee shall be limited to voting on the constitutionality of governance actions.

Section 2

The Constitutional Committee shall be formed in accordance with this Constitution, and members shall serve terms such terms in accordance with this Constitution, provided that terms shall not be less than one year unless otherwise approved by voting on chain. To assure continuity in the operation of the Constitutional Committee, the terms for Constitutional Committee members shall be staggered. Where a motion of no confidence requires immediate replacement of Constitutional Committee members, the end dates of each term shall be maintained for the incoming members, unless otherwise agreed.

Section 3

Election of members to the Constitutional Committee shall take place in accordance with the requirements of this Constitution.

Section 4

No governance action, other than a “Motion of no-confidence” or “Update constitutional committee/threshold” may be implemented on-chain unless the Constitutional Committee shall have first determined and affirmed through an on-chain action that such proposal does not violate this Constitution.

The Constitutional Committee shall be considered to be in one of the following two states at all times: a state of confidence or a state of no-confidence. In a state of no-confidence, members of the then standing Constitutional Committee must be reinstated or replaced using the “Update committee/threshold” governance action before any other on-chain governance action may go forward.

Section 5

The Constitutional Committee shall publish each decision. When voting against a proposal, a member shall set forth the basis for its decision with reference to specific Articles of this Constitution that are in conflict with a given proposal.

Article VII - BLOCKCHAIN GUARDRAILS

Section 1

To implement Cardano Blockchain on-chain governance it is necessary to establish guardrails that will enable the Cardano Blockchain to continue to operate in a secure and sustainable way.

These guardrails apply to the Cardano Blockchain Layer 1 mainnet environment. They are not intended to apply to test environments or to other blockchains that use the Cardano Blockchain software.

Not all parameters for the Cardano Blockchain can be considered independently. Some parameters interact with other settings in an intrinsic way. Where known, these interactions are addressed herein. While the guardrails presently reflect the current state of technical insight, this Article should be treated as a living document. Implementation improvements, new simulations or performance evaluation results for the Cardano Blockchain may allow some of the restrictions contained in these guardrails to be relaxed (or, in some circumstances, require them to be tightened) in due course.

Additional guardrails may also be needed where, for example, new protocol parameters are introduced.

The guardrails set forth in this Article may be amended pursuant to an on-chain governance action that satisfies the applicable voting threshold as set forth in this Constitution. Any such amendment to any guardrails shall require and be deemed to be an amendment to the Constitution itself.

Terminology and Guidance

• Should/Should not: Where this Article says that a value “should not” be set below or above some value, this means that the guardrail is a recommendation or guideline, and the specific value could be open to discussion or alteration by a suitably expert group recognized by the Cardano community in light of experience with the Cardano Blockchain governance system or the operation of the Cardano Blockchain.

• Must/Must not: Where this Article says that a value “must not” be set below or above some value, this means that the guardrail is a requirement that will be enforced by Cardano Blockchain ledger rules, types, or other built-in mechanisms where possible, and that if not followed could cause a protocol failure, security breach, or other undesirable outcome.

• Benchmarking: Benchmarking refers to careful system-level performance evaluation that is designed to show a-priori that, for example, 95% of blocks will be diffused across a global network of Cardano Blockchain nodes within the required 5s time interval in all cases. This may require construction of specific test workflows and execution on a large test network of Cardano nodes, simulating a global Cardano Blockchain network.

• Performance analysis: Performance analysis refers to projecting theoretical performance, empirical benchmarking, or simulation results to predict actual system behavior. For example, performance results obtained from tests in a controlled test environment (such as a collection of data centers with known networking properties) may be extrapolated to inform likely performance behavior in a real Cardano Blockchain network environment.

• Simulation: Simulation refers to synthetic execution that is designed to inform performance/functionality decisions in a repeatable way. For example, the IOSim Cardano Blockchain module allows the operation of the networking stack to be simulated in a controlled and repeatable way, allowing issues to be detected before code deployment.

• Performance Monitoring: Performance monitoring involves measuring the actual behavior of the Cardano Blockchain network, for example, by using timing probes to evaluate round-trip times, or test blocks to assess overall network health. It complements benchmarking and performance analysis by providing information about actual system behavior that cannot be obtained using simulated workloads or theoretical analysis.

• Reverting Changes: Where performance monitoring shows that actual network behavior following a change is inconsistent with the performance requirements for the Cardano Blockchain, then the change must be reverted to its previous state if that is possible. For example, if the block size is increased from 100KB to 120KB and 95% of blocks are no longer diffused within 5s, then a change must be made to revert the block size to 100KB. If this is not possible, then one or more alternative changes must be made that will ensure that the performance requirements are met.

• Severity Levels: Issues that affect the Cardano Blockchain network are classified by severity level, where:

  • Severity 1 is a critical incident or issue with very high impact to the security, performance, or functionality of the Cardano Blockchain network.
  • Severity 2 is a major incident or issue with significant impact to the security, performance, or functionality of the Cardano Blockchain network.
  • Severity 3 is a minor incident or issue with low impact to the security, performance, or functionality of the Cardano Blockchain network.

• Future Performance Requirements: Planned development such as new mechanisms for out-of-memory storage may impact block diffusion or other times. When changing parameters, it is necessary to consider these future performance requirements as well as the current operation of the Cardano Blockchain. Until development is complete, the requirements will be conservative; they may then be relaxed to account for actual timing behavior.

Automated Checking (“Guardrails Script”)

A script hash is associated with the constitution hash when a New Constitution or Guardrails Script governance action is enacted. It acts as an additional safeguard to the ledger rules and types, filtering non-compliant governance actions.

The guardrails script only affects two types of governance actions:

• Parameter Update actions, and
• Treasury Withdrawal actions.

The script is executed when either of these types of governance action is submitted on-chain. This avoids scenarios where, for example, an erroneous script could prevent the chain from ever enacting a Hard Fork action, resulting in deadlock. There are three different situations that apply to script usage.

Symbol and Explanation

• (y) The script can be used to enforce the guardrail.
• (x) The script cannot be used to enforce the guardrail.
• (~ - reason) The script cannot be used to enforce the guardrail for the reason given, but future ledger changes could enable this.

Guardrails may overlap: in this case, the most restrictive set of guardrails will apply.

Where a parameter is not explicitly listed in this document, then the script must not permit any changes to the parameter.

Conversely, where a parameter is explicitly listed in this document but no checkable guardrails are specified, the script must not impose any constraints on changes to the parameter.

2. Guardrails and Guidelines on Protocol Parameter Update Actions

Below are guardrails and guidelines for changing updatable protocol parameter settings via the protocol parameter update governance action such that the Cardano Blockchain is never in an unrecoverable state as a result of such changes.

Note that there are at least five different sources of parameter names, and these are not always consistent:

• The name used in the Genesis file
• The name used in protocol parameter update governance actions
• The name used internally in ledger rules
• The name used in the formal ledger specification
• The name used in research papers

Where these parameter names differ, this Article uses the second convention.

Guardrails

• PARAM-01 (y): Any protocol parameter that is not explicitly named in this document must not be changed by a Parameter update governance action.
• PARAM-02 (y): Where a protocol parameter is explicitly listed in this document but no checkable guardrails are specified, the guardrails script must not impose any constraints on changes to the parameter. Checkable guardrails are shown by a (y).

2.1. Critical Protocol Parameters

The below protocol parameters are critical from a security point of view.

Parameters that are Critical to the Operation of the Blockchain

• Maximum block body size (maxBlockBodySize)
• Maximum transaction size (maxTxSize)
• Maximum block header size (maxBlockHeaderSize)
• Maximum size of a serialized asset value (maxValueSize)
• Maximum script execution/memory units in a single block (maxBlockExecutionUnits[steps/memory])
• Minimum fee coefficient (txFeePerByte)
• Minimum fee constant (txFeeFixed)
• Minimum fee per byte for reference scripts (minFeeRefScriptCoinsPerByte)
• Minimum Lovelace deposit per byte of serialized UTxO (utxoCostPerByte)
• Governance action deposit (govDeposit)

Guardrails

• PARAM-03 (y): Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs must say “yes” with a collective support of more than 50% of all active block production stake. This is enforced by the guardrails on the stake pool voting threshold.
• PARAM-04 (x): At least 3 months should normally pass between the publication of an off-chain proposal to change a critical protocol parameter and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation.

Parameters that are Critical to the Governance System

• Delegation key Lovelace deposit (stakeAddressDeposit)
• Pool registration Lovelace deposit (stakePoolDeposit)
• Minimum fixed rewards cut for pools (minPoolCost)
• DRep deposit amount (dRepDeposit)
• Minimal Constitutional Committee size (committeeMinSize)
• Maximum term length (in epochs) for the Constitutional Committee members (committeeMaxTermLimit)

Guardrails

• PARAM-05 (y): DReps must vote “yes” with a collective support of more than 50% of all active voting stake. This is enforced by the guardrails on the DRep voting thresholds.
• PARAM-06 (x): At least 3 months should normally pass between the publication of an off-chain proposal to change a parameter that is critical to the governance system and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation.

2.2. Economic Parameters

The overall goals when managing economic parameters are to:

• Enable long-term economic sustainability for the Cardano Blockchain ecosystem;
• Ensure that stake pools are adequately rewarded for maintaining the Cardano Blockchain;
• Ensure that ADA holders are adequately rewarded for using stake in constructive ways, including when delegating ADA for block production; and
• Balance economic incentives for different Cardano Blockchain ecosystem stakeholders, including but not limited to Stake Pool Operators, ADA holders, DeFi users, infrastructure users, developers (e.g., DApps), and financial intermediaries (e.g., exchanges).

Triggers for Change

• Significant changes in the fiat value of ADA resulting in potential problems with security, performance, or functionality.
• Changes in transaction volumes or types.
• Community requests or suggestions.
• Emergency situations that require changes to economic parameters.

Counter-indicators

Changes to the economic parameters should not be made in isolation. They need to account for:

• External economic factors.
• Network security concerns.

Core Metrics

• Fiat value of ADA resulting in potential problems with security, performance, or functionality.
• Transaction volumes and types.
• Number and health of stake pools.
• External economic factors.

Changes to Specific Economic Parameters

Transaction fee per byte (txFeePerByte) and fixed transaction fee (txFeeFixed)

Defines the cost for basic transactions in Lovelace:
fee(tx) = txFeeFixed + txFeePerByte * nBytes(tx)

Guardrails

• TFPB-01 (y): txFeePerByte must not be lower than 30 (0.000030 ADA). This protects against low-cost denial of service attacks.
• TFPB-02 (y): txFeePerByte must not exceed 1,000 (0.001 ADA). This ensures that transactions can be paid for.
• TFPB-03 (y): txFeePerByte must not be negative.
• TFF-01 (y): txFeeFixed must not be lower than 100,000 (0.1 ADA). This protects against low-cost denial of service attacks.
• TFF-02 (y): txFeeFixed must not exceed 10,000,000 (10 ADA). This ensures that transactions can be paid for.
• TFF-03 (y): txFeeFixed must not be negative.
• TFGEN-01 (x - “should”): To maintain a consistent level of protection against denial-of-service attacks, txFeeFixed and txFeePerByte should be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory]).
• TFGEN-02 (x - unquantifiable): Any changes to txFeeFixed or txFeePerByte must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee so that it becomes impossible to construct a transaction.

UTxO cost per byte (utxoCostPerByte)

Defines the cost for storage in UTxOs:

• Sets a minimum threshold on ADA that is held within a single UTxO (~1 ADA minimum, could be >= 50 ADA in the worst case).
• Provides protection against low-cost denial of service attack on UTxO storage. This attack has been executed on other chains; it is not theoretical.
• DoS protection decreases in line with the free node memory (proportional to UTxO growth).
• Helps reduce long-term storage costs.
• Provides an incentive to return UTxOs when no longer needed.
• Should significantly exceed minimum tx cost (~0.15 ADA).

Guardrails

• UCPB-01 (y): utxoCostPerByte must not be lower than 3,000 (0.003 ADA).
• UCPB-02 (y): utxoCostPerByte must not exceed 6,500 (0.0065 ADA).
• UCPB-03 (y): utxoCostPerByte must not be zero.
• UCPB-04 (y): utxoCostPerByte must not be negative.
• UCPB-05 (x - “should”): Changes should account for:
  • i) The acceptable cost of attack.
  • ii) The acceptable time for an attack (at least one epoch is assumed).
  • iii) The acceptable memory configuration for full node users (assumed to be 16GB for wallets or 24GB for stake pools).
  • iv) The sizes of UTxOs (~200B per UTxO minimum, up to about 10KB).
  • v) The current total node memory usage.

Stake address deposit (stakeAddressDeposit)

Ensures that stake addresses are retired when no longer needed:

• Helps reduce long-term storage costs.
• Helps limit CPU and memory costs in the ledger.
• The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Reducing the number of active stake addresses also reduces processing and memory costs at the epoch boundary when calculating stake snapshots.

Guardrails

• SAD-01 (y): stakeAddressDeposit must not be lower than 1,000,000 (1 ADA).
• SAD-02 (y): stakeAddressDeposit must not exceed 5,000,000 (5 ADA).
• SAD-03 (y): stakeAddressDeposit must not be negative.

Stake pool deposit (stakePoolDeposit)

Ensures that stake pools are retired by the stake pool operator when no longer needed by them:

• Helps reduce long-term storage costs.
• The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Rewards and stake snapshot calculations are also impacted by the number of active stake pools.

Guardrails

• SPD-01 (y): stakePoolDeposit must not be lower than 250,000,000 (250 ADA).
• SPD-02 (y): stakePoolDeposit must not exceed 500,000,000 (500 ADA).
• SPD-03 (y): stakePoolDeposit must not be negative.

Minimum Pool Cost (minPoolCost)

Part of the rewards mechanism:

• The minimum pool cost is transferred to the pool rewards address before any delegator rewards are paid.

Guardrails

• MPC-01 (y): minPoolCost must not be negative.
• MPC-02 (y): minPoolCost must not exceed 500,000,000 (500 ADA).
• MPC-03 (x - “should”): minPoolCost should be set in line with the economic cost for operating a pool.

Treasury Cut (treasuryCut)

Part of the rewards mechanism:

• The treasury cut portion of the monetary expansion is transferred to the treasury before any pool rewards are paid.
• Can be set in the range 0.0-1.0 (0%-100%).

Guardrails

• TC-01 (y): treasuryCut must not be lower than 0.1 (10%).
• TC-02 (y): treasuryCut must not exceed 0.3 (30%).
• TC-03 (y): treasuryCut must not be negative.
• TC-04 (y): treasuryCut must not exceed 1.0 (100%).
• TC-05 (~ - no access to change history): treasuryCut must not be changed more than once in any 36-epoch period (approximately 6 months).

Monetary Expansion Rate (monetaryExpansion)

Part of the rewards mechanism:

• The monetary expansion controls the amount of reserves that is used for rewards each epoch.
• Governs the long-term sustainability of Cardano.
• The reserves are gradually depleted until no rewards are supplied.

Guardrails

• ME-01 (y): monetaryExpansion must not exceed 0.
• ME-02 (y): monetaryExpansion must not be lower than 0.
• ME-03 (y): monetaryExpansion must not be negative.
• ME-04 (x - “should”): monetaryExpansion should not be varied by more than +/- 10% in any 73-epoch period (approximately 12 months).
• ME-05 (x - “should”): monetaryExpansion should not be changed more than once in any 36-epoch period (approximately 6 months).

Plutus Script Execution Prices (executionUnitPrices[priceSteps/priceMemory])

Defines the fees for executing Plutus scripts:

• Gives an economic return for Plutus script execution.
• Provides security against low-cost DoS attacks.

Guardrails

• EIUP-PS-01 (y): executionUnitPrices[priceSteps] must not exceed 2,000 / 10,000,000.
• EIUP-PS-02 (y): executionUnitPrices[priceSteps] must not be lower than 500 / 10,000,000.
• EIUP-PM-01 (y): executionUnitPrices[priceMemory] must not exceed 2,000 / 10,000.
• EIUP-PM-02 (y): executionUnitPrices[priceMemory] must not be lower than 400 / 10,000.
• EIUP-GEN-01 (x - “similar to”): The execution prices must be set so that:
  • i) the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum-sized non-script transaction and
  • ii) the cost of executing a transaction with maximum memory units is similar to the cost of a maximum-sized non-script transaction.
• EIUP-GEN-02 (x - “should”): The execution prices should be adjusted whenever transaction fees are adjusted (txFeeFixed/txFeePerByte). The goal is to ensure that the processing delay is similar for “full” transactions, regardless of their type.

This helps ensure that the requirements on block diffusion/propagation times are met.

Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte)

Defines the cost for using Plutus reference scripts in Lovelace.

Guardrails

• MFRS-01 (y): minFeeRefScriptCoinsPerByte must not exceed 1,000 (0.001 ADA). This ensures that transactions can be paid for.
• MFRS-02 (y): minFeeRefScriptCoinsPerByte must not be negative.
• MFRS-03 (x - “should”): To maintain a consistent level of protection against denial-of-service attacks, minFeeRefScriptCoinsPerByte should be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory]) and whenever txFeeFixed is adjusted.
• MFRS-04 (x - unquantifiable): Any changes to minFeeRefScriptCoinsPerByte must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee.

2.3. Network Parameters

The overall goals when managing the Cardano Blockchain network parameters are to:

• Match the available Cardano Blockchain Layer 1 network capacity to current or future traffic demands, including payment transactions, layer 1 DApps, sidechain management, and governance needs.
• Balance traffic demands for different user groups, including payment transactions, minters of Fungible/Non-Fungible Tokens, Plutus scripts, DeFi developers, Stake Pool Operators, and voting transactions.

Triggers for Change

Changes to network parameters may be triggered by:

• Measured changes in traffic demands over a 2-epoch period (10 days).
• Anticipated changes in traffic demands.
• Community requests.

Counter-indicators

Changes may need to be reversed and/or should not be enacted in the event of:

• Excessive block propagation delays.
• Stake pools being unable to handle traffic volume.
• Scripts being unable to complete execution.

Core Metrics

All decisions on parameter changes should be informed by:

• Block propagation delay profile.
• Traffic volume (block size over time).
• Script volume (size of scripts and execution units).
• Script execution cost benchmarks.
• Block propagation delay/diffusion benchmarks.

Detailed benchmarking results are required to confirm the effect of any changes on mainnet performance or behavior prior to enactment. The effects of different transaction mixes must be analyzed, including normal transactions, Plutus scripts, and governance actions.

Guardrails

• NETWORK-01 (x - “should”): No individual network parameter should change more than once per two epochs.
• NETWORK-02 (x - “should”): Only one network parameter should be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits.

Changes to Specific Network Parameters

Block Size (maxBlockBodySize)

The maximum size of a block, in Bytes.

Guardrails

• MBBS-01 (y): maxBlockBodySize must not exceed 122,880 Bytes (120KB).
• MBBS-02 (y): maxBlockBodySize must not be lower than 24,576 Bytes (24KB).
• MBBS-03 (x - “exceptional circumstances”): maxBlockBodySize must not be decreased, other than in exceptional circumstances where there are potential problems with security, performance, or functionality.
• MBBS-04 (~ - no access to existing parameter values): maxBlockBodySize must be large enough to include at least one transaction (that is, maxBlockBodySize must be at least maxTxSize).
• MBBS-05 (x - “should”): maxBlockBodySize should be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch.
• MBBS-06 (x - “should”): The block size should not induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation, and benchmarking.
• MBBS-07 (x - “unquantifiable”): The impact of any change to maxBlockBodySize must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to maxBlockBodySize must also consider future requirements for Plutus script execution (maxBlockExecutionUnits[steps]) against the total block diffusion target of 3s with 95% block propagation within 5s. The limit on maximum block size may be increased in the future if this is supported by benchmarking and monitoring results.

Transaction Size (maxTxSize)

The maximum size of a transaction, in Bytes.

Guardrails

• MTS-01 (y): maxTxSize must not exceed 32,768 Bytes (32KB).
• MTS-02 (y): maxTxSize must not be negative.
• MTS-03 (~ - no access to existing parameter values): maxTxSize must not be decreased.
• MTS-04 (~ - no access to existing parameter values): maxTxSize must not exceed maxBlockBodySize.
• MTS-05 (x - “should”): maxTxSize should not be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably should be increased by 2,048 Bytes (2KB) or less per epoch.
• MTS-06 (x - “should”): maxTxSize should not exceed 1/4 of the block size.

Memory Unit Limits (maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory])

The limit on the maximum number of memory units that can be used by Plutus scripts, either per-transaction or per-block.

Guardrails

• MTEU-M-01 (y): maxTxExecutionUnits[memory] must not exceed 40,000,000 units.

• MTEU-M-02 (y): maxTxExecutionUnits[memory] must not be negative.

• MTEU-M-03 (~ - no access to existing parameter values): maxTxExecutionUnits[memory] must not be decreased.

• MTEU-M-04 (x - “should”): maxTxExecutionUnits[memory] should not be increased by more than 2,500,000 units in any epoch.

• MBEU-M-01 (y): maxBlockExecutionUnits[memory] must not exceed 120,000,000 units.

• MBEU-M-02 (y): maxBlockExecutionUnits[memory] must not be negative.

• MBEU-M-03 (x - “should”): maxBlockExecutionUnits[memory] should not be changed (increased or decreased) by more than 10,000,000 units in any epoch.

• MBEU-M-04 (x - unquantifiable): The impact of any change to maxBlockExecutionUnits[memory] must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the diffusion/propagation time budgets, as also impacted by maxBlockExecutionUnits[steps]. Any increase must also consider previously agreed future requirements for the total block size (maxBlockBodySize) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements.

• MEU-M-01 (~ - no access to existing parameter values): maxBlockExecutionUnits[memory] must not be less than maxTxExecutionUnits[memory].

CPU Unit Limits (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps])

The limit on the maximum number of CPU steps that can be used by Plutus scripts, either per-transaction or per-block.

Guardrails

• MTEU-S-01 (y): maxTxExecutionUnits[steps] must not exceed 15,000,000,000 (15Bn) units.

• MTEU-S-02 (y): maxTxExecutionUnits[steps] must not be negative.

• MTEU-S-03 (~ - no access to existing parameter values): maxTxExecutionUnits[steps] must not be decreased.

• MTEU-S-04 (x - “should”): maxTxExecutionUnits[steps] should not be increased by more than 500,000,000 (500M) units in any epoch (5 days).

• MBEU-S-01 (y): maxBlockExecutionUnits[steps] must not exceed 40,000,000,000 (40Bn) units.

• MBEU-S-02 (y): maxBlockExecutionUnits[steps] must not be negative.

• MBEU-S-03 (x - “should”): maxBlockExecutionUnits[steps] should not be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days).

• MBEU-S-04 (x - unquantifiable): The impact of the change to maxBlockExecutionUnits[steps] must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by maxBlockExecutionUnits[memory]. Any increase must also consider previously identified future requirements for the total block size (maxBlockBodySize) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements.

• MEU-S-01 (~ - no access to existing parameter values): maxBlockExecutionUnits[steps] must not be less than maxTxExecutionUnits[steps].

Block Header Size (maxBlockHeaderSize)

The size of the block header.

Note: Increasing the block header size may affect the overall block size (maxBlockBodySize).

Guardrails

• MBHS-01 (y): maxBlockHeaderSize must not exceed 5,000 Bytes.
• MBHS-02 (y): maxBlockHeaderSize must not be negative.
• MBHS-03 (x - “largest valid header” is subject to change): maxBlockHeaderSize must be large enough for the largest valid header.
• MBHS-04 (x - “should”): maxBlockHeaderSize should only normally be increased if the protocol changes.
• MBHS-05 (x - “should”): maxBlockHeaderSize should be within TCP’s initial congestion window (3 or 10 MTUs).

2.4. Technical/Security Parameters

The overall goals when managing the technical/security parameters are:

• Ensure the security of the Cardano network in terms of decentralization, protection against Sybil and 51% attacks, and protection against denial of service attacks.
• Enable changes to the Plutus language.

Triggers for Change

• Changes in the number of active SPOs.
• Changes to the Plutus language.
• Security threats.
• Community requests.

Counter-indicators

• Economic concerns, e.g., when changing the number of stake pools.

Core Metrics

• Number of stake pools.
• Level of decentralization.

Changes to Specific Technical/Security Parameters

Target Number of Stake Pools (stakePoolTargetNum)

Sets the target number of stake pools:

• The expected number of pools when the network is in the equilibrium state.
• Primarily a security parameter, ensuring decentralization by pool division/replication.
• Has an economic effect as well as a security effect; economic advice is also required when changing this parameter.
• Large changes in this parameter will trigger mass redelegation events.

Guardrails

• SPTN-01 (y): stakePoolTargetNum must not be lower than 250.
• SPTN-02 (y): stakePoolTargetNum must not exceed 2,000.
• SPTN-03 (y): stakePoolTargetNum must not be negative.
• SPTN-04 (y): stakePoolTargetNum must not be zero.

Pledge Influence Factor (poolPledgeInfluence)

Enables the pledge protection mechanism:

• Provides protection against Sybil attack.
• Higher values reward pools that have more pledge and penalize pools that have less pledge.
• Has an economic effect as well as technical effect; economic advice is also required.
• Can be set in the range 0.0-infinity.

Guardrails

• PPI-01 (y): poolPledgeInfluence must not be lower than 0.1.
• PPI-02 (y): poolPledgeInfluence must not exceed 1.0.
• PPI-03 (y): poolPledgeInfluence must not be negative.
• PPI-04 (x - “should”): poolPledgeInfluence should not vary by more than +/- 10% in any 18-epoch period (approximately 3 months).

Pool Retirement Window (poolRetireMaxEpoch)

Defines the maximum number of epochs notice that a pool can give when planning to retire.

Guardrails

• PRME-01 (y): poolRetireMaxEpoch must not be negative.
• PRME-02 (x - “should”): poolRetireMaxEpoch should not be lower than 1.

Collateral Percentage (collateralPercentage)

Defines how much collateral must be provided when executing a Plutus script as a percentage of the normal execution cost:

• Collateral is additional to fee payments.
• If a script fails to execute, then the collateral is lost.
• The collateral is never lost if a script executes successfully.
• Provides security against low-cost attacks by making it more expensive rather than less expensive to execute failed scripts.

Guardrails

• CP-01 (y): collateralPercentage must not be lower than 100.
• CP-02 (y): collateralPercentage must not exceed 200.
• CP-03 (y): collateralPercentage must not be negative.
• CP-04 (y): collateralPercentage must not be zero.

Maximum number of collateral inputs (maxCollateralInputs)

Defines the maximum number of inputs that can be used for collateral when executing a Plutus script.

Guardrails

• MCI-01 (y): maxCollateralInputs must not be lower than 1.

The limit on the serialized size of the Value in each output.

Guardrails

• MVS-01 (y): maxValueSize must not exceed 12,288 Bytes (12KB).
• MVS-02 (y): maxValueSize must not be negative.
• MVS-03 (~ - no access to existing parameter values): maxValueSize must be less than maxTxSize.
• MVS-04 (~ - no access to existing parameter values): maxValueSize must not be reduced.
• MVS-05 (x - “sensible output” is subject to interpretation): maxValueSize must be large enough to allow sensible outputs (e.g., any existing on-chain output or anticipated outputs that could be produced by new ledger rules).

Plutus Cost Models (costModels)

Defines the base costs for each Plutus primitive in terms of CPU and memory units:

• There are about 150 distinct micro-parameters in total.
• Cost models are defined for each Plutus language version. A new language version may introduce additional micro-parameters or remove existing micro-parameters.

Guardrails

• PCM-01 (x - unquantifiable): Cost model values must be set by benchmarking on a reference architecture.
• PCM-02 (x - primitives and language versions aren’t introduced in transactions): The cost model must be updated if new primitives are introduced or a new Plutus language version is added.
• PCM-03 (~ - no access to Plutus cost model parameters): Cost model values should not be negative.
• PCM-04 (~ - no access to Plutus cost model parameters): A cost model must be supplied for each Plutus language version that the protocol supports.

2.5. Governance Parameters

The overall goals when managing the governance parameters are to:

• Ensure governance stability.
• Maintain a representative form of governance as outlined herein.

Triggers for Change

Changes to governance parameters may be triggered by:

• Community requests.
• Regulatory requirements.
• Unexpected or unwanted governance outcomes.
• Entering a state of no confidence.

Counter-indicators

Changes may need to be reversed and/or should not be enacted in the event of:

• Unexpected effects on governance.
• Excessive Layer 1 load due to on-chain voting or excessive numbers of governance actions.

Core Metrics

All decisions on parameter changes should be informed by:

• Governance participation levels.
• Governance behaviors and patterns.
• Regulatory considerations.
• Confidence in the governance system.
• The effectiveness of the governance system in managing necessary change.

Changes to Specific Governance Parameters

Deposit for Governance Actions (govDeposit)

The deposit that is charged when submitting a governance action:

• Helps to limit the number of actions that are submitted.

Guardrails

• GD-01 (y): govDeposit must not be negative.
• GD-02 (y): govDeposit must not be lower than 1,000,000 (1 ADA).
• GD-03 (y): govDeposit must not exceed 10,000,000,000,000 (10 million ADA).
• GD-04 (x - “should”): govDeposit should be adjusted in line with fiat changes.

Deposit for DReps (dRepDeposit)

The deposit that is charged when registering a DRep:

• Helps to limit the number of active DReps.

Guardrails

• DRD-01 (y): dRepDeposit must not be negative.
• DRD-02 (y): dRepDeposit must not be lower than 1,000,000 (1 ADA).
• DRD-03 (y): dRepDeposit must not exceed 100,000,000,000 (100,000 ADA).
• DRD-04 (x - “should”): dRepDeposit should be adjusted in line with fiat changes.

DRep Activity Period (dRepActivity)

The period (as a whole number of epochs) after which a DRep is considered to be inactive for vote calculation purposes, if they do not vote on any proposal.

Guardrails

• DRA-01 (y): dRepActivity must not be lower than 13 epochs (2 months).
• DRA-02 (y): dRepActivity must not exceed 37 epochs (6 months).
• DRA-03 (y): dRepActivity must not be negative.
• DRA-04 (~ - no access to existing parameter values): dRepActivity must be greater than govActionLifetime.
• DRA-05 (x - “should”): dRepActivity should be calculated in human terms (2 months, etc.).

DRep and SPO Governance Action Thresholds (dRepVotingThresholds[...], poolVotingThresholds[...])

Thresholds on the active voting stake that is required to ratify a specific type of governance action by either DReps or SPOs:

• Ensures legitimacy of the action.

The threshold parameters are listed below:

• dRepVotingThresholds:

  • dvtCommitteeNoConfidence
  • dvtCommitteeNormal
  • dvtHardForkInitiation
  • dvtMotionNoConfidence
  • dvtPPEconomicGroup
  • dvtPPGovGroup
  • dvtPPNetworkGroup
  • dvtPPTechnicalGroup
  • dvtTreasuryWithdrawal
  • dvtUpdateToConstitution

• poolVotingThresholds:

  • pvtCommitteeNoConfidence
  • pvtCommitteeNormal
  • pvtHardForkInitiation
  • pvtMotionNoConfidence
  • pvtPPSecurityGroup

Guardrails

• VT-GEN-01 (y): All thresholds must be greater than 50% and less than or equal to 100%.
• VT-GEN-02 (y): Economic, network, and technical parameter thresholds must be in the range 51%-75%.
• VT-GEN-03 (y): Governance parameter thresholds must be in the range 75%-90%.
• VT-HF-01 (y): Hard fork action thresholds must be in the range 51%-80%.
• VT-CON-01 (y): New Constitution or guardrails script action thresholds must be in the range 65%-90%.
• VT-CC-01 (y): Update Constitutional Committee action thresholds must be in the range 51%-90%.
• VT-NC-01 (y): No confidence action thresholds must be in the range 51%-75%.

Governance Action Lifetime (govActionLifetime)

The period after which a governance action will expire if it is not enacted:

• As a whole number of epochs.

Guardrails

• GAL-01 (y): govActionLifetime must not be lower than 1 epoch (5 days).
• GAL-03 (x - “should”): govActionLifetime should not be lower than 2 epochs (10 days).
• GAL-02 (y): govActionLifetime must not exceed 15 epochs (75 days).
• GAL-04 (x - “should”): govActionLifetime should be calibrated in human terms (e.g., 30 days, two weeks) to allow sufficient time for voting, etc., to take place.
• GAL-05 (~ - no access to existing parameter values): govActionLifetime must be less than dRepActivity.

Maximum Constitutional Committee Term (committeeMaxTermLimit)

The limit on the maximum term that a committee member may serve.

Guardrails

• CMTL-01 (y): committeeMaxTermLimit must not be zero.
• CMTL-02 (y): committeeMaxTermLimit must not be negative.
• CMTL-03 (y): committeeMaxTermLimit must not be lower than 18 epochs (90 days, or approximately 3 months).
• CMTL-04 (y): committeeMaxTermLimit must not exceed 293 epochs (approximately 4 years).
• CMTL-05 (x - “should”): committeeMaxTermLimit should not exceed 220 epochs (approximately 3 years).

The minimum size of the Constitutional Committee (committeeMinSize)

The least number of members that can be included in a Constitutional Committee following a governance action to change the Constitutional Committee.

Guardrails

• CMS-01 (y): committeeMinSize must not be negative.
• CMS-02 (y): committeeMinSize must not be lower than 3.
• CMS-03 (y): committeeMinSize must not exceed 10.

2.6. Monitoring and Reversion of Parameter Changes

An epoch consists of 5 calendar days. All network parameter changes must be monitored carefully for no less than 2 epochs (10 days):

• Changes must be reverted as soon as possible if block propagation delays exceed 4.5s for more than 5% of blocks over any 6-hour rolling window.
• All other parameter changes should be monitored carefully for any adverse effects on performance, security, or functionality. If such effects are observed, appropriate actions, including reversion to previous parameters, should be taken.

A specific reversion/recovery plan must be produced for each parameter change. This plan must include:

• Which parameters need to change and in which ways in order to return to the previous state (or a similar state).
• How to recover the network in the event of a disastrous failure.

This plan should be followed if problems are observed following the parameter change. Note that not all changes can be reverted. Additional care must be taken when making changes to these parameters.

2.7. Non-Updatable Protocol Parameters

Some fundamental protocol parameters cannot be changed by the Protocol Parameter Update governance action. These parameters can only be changed in a new Genesis file as part of a hard fork. It is not necessary to provide specific guardrails on updating these parameters.

3. Guardrails and Guidelines on Treasury Withdrawal Actions

Treasury withdrawal actions specify the destination and amount of a number of withdrawals from the Cardano treasury.

Guardrails

• TREASURY-01 (x): DReps must define a net change limit for the Cardano Treasury’s balance per period of time.
• TREASURY-02 (x): The budget for the Cardano Treasury must not exceed the net change limit for the Cardano Treasury’s balance per period of time.
• TREASURY-03 (x): The budget for the Cardano Treasury must be denominated in ADA.
• TREASURY-04 (x): Treasury withdrawals must not be ratified until there is a community-approved Cardano budget then in effect pursuant to a previous on-chain governance action agreed by the DReps with a threshold of greater than 50% of the active voting stake.

4. Guardrails and Guidelines on Hard Fork Initiation Actions

The hard fork initiation action requires both a new major and a new minor protocol version to be specified:

• As positive integers.
• As the result of a hard fork, new updatable protocol parameters may be introduced. Guardrails may be defined for these parameters, which will take effect following the hard fork. Existing updatable protocol parameters may also be deprecated by the hard fork, in which case the guardrails become obsolete for all future changes.

Guardrails

• HARDFORK-01 (~ - no access to existing parameter values): The major protocol version must be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version must be zero.
• HARDFORK-02 (~ - no access to existing parameter values): The minor protocol version must be no less than the minor version that will be enacted immediately prior to this change.
• HARDFORK-03 (~ - no access to existing parameter values): At least one of the protocol versions (major or minor or both) must change.
• HARDFORK-04 (x): At least 85% of stake pools by active stake should have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version.
• HARDFORK-05 (x): Any new updatable protocol parameters that are introduced with a hard fork must be included in this Article and suitable guardrails defined for those parameters.
• HARDFORK-06 (x): Settings for any new protocol parameters that are introduced with a hard fork must be included in the appropriate Genesis file.
• HARDFORK-07 (x): Any deprecated protocol parameters must be indicated in this Article.
• HARDFORK-08 (~ - no access to Plutus cost model parameters): New Plutus versions must be supported by a version-specific Plutus cost model that covers each primitive that is available in the new Plutus version.

5. Guardrails and Guidelines on Update Constitutional Committee or Threshold Actions

Update Constitutional Committee or Threshold governance actions may change the size, composition, or required voting thresholds for the Constitutional Committee.

Guardrails

• UPDATE-CC-01 (x): Update Constitutional Committee and/or threshold and/or term governance actions must not be ratified until ADA holders have ratified through an on-chain governance action the Final Constitution.

6. Guardrails and Guidelines on New Constitution or Guardrails Script Actions

New constitution or guardrails script actions change the hash of the on-chain constitution and the associated guardrails script.

Guardrails

• NEW-CONSTITUTION-01 (x): A New Constitution or Guardrails Script governance action must be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action.

7. Guardrails and Guidelines on No Confidence Actions

No confidence actions signal a state of no confidence in the governance system. No guardrails are imposed on No Confidence actions.

Guardrails

• None

8. Guardrails and Guidelines on Info Actions

Info actions are not enacted on-chain. No guardrails are imposed on Info actions.

Guardrails

• None

9. Guardrails During the Interim Period

Interim Period

The Interim Period began with the Chang Hard-Fork on September __ 2024, and ends after a community-ratified Final Constitution is enacted on-chain. Throughout the Interim Period, technical and constitution-enforced triggers will progressively turn on governance features.

Interim Period Technical Rollout:

The Chang Hard Fork enabled three initial governance actions proposed by Cardano Improvement Proposal (CIP) 1694, and enabled the representative governance framework to be established. These actions are the “Info”, “Hard-fork initiation”, and “Protocol parameter changes” actions.

ADA holders were able to register as and delegate to DReps immediately after the Chang hard fork but DRep voting will not be available, except on “Info” actions. This ensures that ADA holders have sufficient time to choose their voting delegations. SPOs are able to vote as described in CIP-1694.

“Hard-fork initiation” and “Protocol parameter changes” actions will also be ratified by the Constitutional Committee.

ADA holders will be able to withdraw their staking rewards as usual.

A subsequent hard fork, ratified by the Constitutional Committee and SPOs, shortly after the Chang Hard Fork, will enable the four remaining CIP-1694 governance actions:

• “Treasury withdrawals”,
• “Motion of no-confidence”,
• “Update constitutional committee and/or threshold and/or terms”, and
• “New constitution or guardrails script”.

At this point, DRep voting will be enabled and staking rewards can only be withdrawn if the ADA holder has delegated their vote (including to themselves and to the pre-defined Abstain/No Confidence voting options).

Guardrails

• INTERIM-01 (x): To provide sufficient time for DReps to register and campaign and for ADA holders to choose their initial voting delegations, at least 18 epochs (90 days, or approximately 3 months) must elapse after the Chang hard fork before the subsequent hard fork can be ratified. Once the subsequent hard fork is enacted, DRep voting can occur as described in CIP-1694.
• INTERIM-02 (x): Treasury withdrawals must not be ratified until there is a community-approved Cardano Blockchain Ecosystem budget then in effect pursuant to a previous on-chain governance action.
• INTERIM-03 (x): Treasury withdrawals must be consistent with the community-approved Cardano Blockchain ecosystem budget(s).
• INTERIM-04 (x): ADA holders must have ratified the Final Constitution as specified in this Article II before ratifying any other proposed “new constitution”, “update constitutional committee and/or threshold and/or terms”, and “motion of no-confidence” governance actions.
• INTERIM-05 (x): “New guardrails script” actions that are consistent with the Interim Constitution may be ratified during the interim period, provided the Interim Constitution itself is not changed.

10. List of Protocol Parameter Groups

The protocol parameters are grouped by type, allowing different thresholds to be set for each group.

The network group consists of:

• maximum block body size (maxBlockBodySize)
• maximum transaction size (maxTxSize)
• maximum block header size (maxBlockHeaderSize)
• maximum size of a serialized asset value (maxValueSize)
• maximum script execution units in a single transaction (maxTxExecutionUnits[steps])
• maximum script execution units in a single block (maxBlockExecutionUnits[steps])
• maximum number of collateral inputs (maxCollateralInputs)

The economic group consists of:

• minimum fee coefficient (txFeePerByte)
• minimum fee constant (txFeeFixed)
• minimum fee per byte for reference scripts (minFeeRefScriptCoinsPerByte)
• delegation key Lovelace deposit (stakeAddressDeposit)
• pool registration Lovelace deposit (stakePoolDeposit)
• monetary expansion (monetaryExpansion)
• treasury expansion (treasuryCut)
• minimum fixed rewards cut for pools (minPoolCost)
• minimum Lovelace deposit per byte of serialized UTxO (utxoCostPerByte)
• prices of Plutus execution units (executionUnitPrices[priceSteps/priceMemory])

The technical group consists of:

• pool pledge influence (poolPledgeInfluence)
• pool retirement maximum epoch (poolRetireMaxEpoch)
• desired number of pools (stakePoolTargetNum)
• Plutus execution cost models (costModels)
• proportion of collateral needed for scripts (collateralPercentage)

The governance group consists of all the new protocol parameters that are introduced in CIP-1694:

• governance voting thresholds (dRepVotingThresholds[...], poolVotingThresholds[...])
• governance action maximum lifetime in epochs (govActionLifetime)
• governance action deposit (govActionDeposit)
• DRep deposit amount (dRepDeposit)
• DRep activity period in epochs (dRepActivity)
• minimal constitutional committee size (committeeMinSize)
• maximum term length (in epochs) for the constitutional committee members (committeeMaxTermLimit)

Appendix II

Article VIII - Amendments

Except as otherwise provided herein, amendments to this Constitution shall be approved by on-chain governance action by the authorized governance bodies by a threshold of not less than 67% of the then active voting stake.

Changes to the Guardrails may be made by on-chain governance action satisfying a threshold of a majority of then-active stake of voting SPOs.

Article IX - Dispute Resolution

Resolving disputes in a cost-effective manner is critical to the Cardano Blockchain ecosystem. A Dispute Resolution Committee shall be established (within ninety (90) days?) after ratification of the Constitution, comprised of DReps, SPOs and members of the Constitutional Committee, with the goal of researching on-chain and off-chain dispute resolution methods suitable for blockchain, and coming up with a framework for dispute resolution for those disputes which are suitable to be resolved on-chain or with agreed off-chain procedures. Within one (1) year (?) after ratification of this Constitution on-chain, an amendment to the Constitution shall be proposed to govern dispute resolution. If no such framework is ratified, treasury withdrawals to Catalyst or to individuals or companies seeking funds to develop on the blockchain must provide details of agreed dispute resolution mechanisms as part of their proposals. The adequacy of same shall be evaluated by those voting on such proposals, and shall be a key factor in determining whether funding is provided.

This Constitution seeks to encourage members of the Cardano blockchain community to become involved in governance. To facilitate this, it is agreed that SPOs, DReps, Constitutional Committee members and Dispute Resolution Committee members, as well as others participating in governance, shall be immune from liability and suit for actions taken in the ordinary course of their duties. This immunity shall not apply if the actions of such members are determined to fall outside the ordinary course and scope of their duties or are determined to violate criminal law in an applicable jurisdiction. Mere disagreement with the votes of such individuals is not sufficient basis for suit.