Draft 2024-07-29
In the beginning of the Cardano Blockchain ecosystem, three pioneering entities, IOHK,
Emurgo, and the Cardano Foundation, came together to foster the emergence of a new
blockchain, the Cardano Blockchain, laying the foundation for a decentralized network that
would empower individuals, and promote collaboration and innovation. Their pioneering efforts
have shaped the path for a blockchain designed to ensure a fair and transparent environment
where all participants can contribute to the Cardano Blockchain ecosystem's growth and success.
Over time, the Cardano Blockchain ecosystem has expanded significantly, and now, the Cardano
Blockchain ecosystem, comprising of thousands of ada holders, individuals, builders, developers,
enterprises, stake pools, users of the Cardano Blockchain and others, operates in a truly
decentralized manner, further strengthening the resilience and autonomy of the Cardano
Blockchain ecosystem.
As the Cardano Blockchain ecosystem continues to grow, it has become imperative to similarly
adapt and evolve its governance model, reflecting the principles of decentralization, community
involvement, inclusivity and collaboration that have been the cornerstone of the Cardano
Blockchain ecosystem since its start.
Recognizing the need for a more robust and dynamic governance framework, and one that
utilizes wherever possible and beneficial blockchain technology in the governance process, the
Cardano community, as the members of this decentralized Cardano Blockchain ecosystem,
hereby establishes this Cardano Constitution. It shall serve as a guiding set of principles for the
operation and governance of our collective efforts, fostering an environment where all
participants can contribute to the betterment of the Cardano Blockchain ecosystem as a whole.
Through adopting this Constitution, the Cardano Blockchain ecosystem shall establish a robust
governance framework, ensuring that decisions are made in the best interest of the Cardano
community. The Cardano community shall uphold principles of transparency, openness, and
responsible governance, promoting a culture of trust and collaboration. Together, the Cardano
community commits to uphold these principles and to work together towards the continuous
improvement, growth, and success of our decentralized blockchain ecosystem known as the
Cardano Blockchain.
This Constitution shall serve as the embodiment of these guiding principles for the operation and
governance of the decentralized Cardano Blockchain ecosystem, providing a foundation that will
adapt and evolve over time to meet the continuing needs of the Cardano community.
All members of the Cardano community are expected to abide by this Constitution, and are
entitled to participate in its governance processes, and are encouraged to work collaboratively
towards the betterment of the Cardano Blockchain ecosystem as a whole, contributing to its
growth, sustainability, and success. The Cardano Blockchain shall be governed on a vote-based
decision-making model, fostering inclusivity, a diversity of views, innovation and adaptability.
All owners of ada shall have the opportunity to contribute to the governance and direction of the
decentralized Cardano Blockchain ecosystem.
In approaching this Constitution, it must be remembered that this is not a constitution for only a
blockchain but rather, it is a constitution for a blockchain ecosystem – a much more ambitious
endeavor. Accordingly, how governance actions are approved, while extremely important, is not
the sole focus of this Constitution. Rather, this Constitution provides the basis and fundamental
framework through which all actors in the Cardano Blockchain ecosystem can come together to
govern themselves and form radically new approaches to human interaction and collaboration.
By necessity, this Constitution recognizes the role of and empowers the Constitutional
Committee, confirms the right of the Cardano community to participate in collective bodies for
collaboration, gives effect to on-chain governance, and empowers DReps to act as the voice of
ada owners for on-chain voting.
The Constitution also recognizes the necessity of safeguarding access to and the use of funds of
the Cardano treasury through the inclusion of the Cardano Guardrails in this Constitution.
These below Tenets shall guide all actors in the Cardano Blockchain ecosystem including the
Constitutional Committee and proposed governance actions shall be evaluated in accordance
with these Tenets.
Transactions on the Cardano Blockchain should not be slowed down or censored and should be
expediently served for their intended purpose. The Cardano Blockchain should scale taking into
consideration throughput, sharding, settlement and dynamic pricing.
The cost of transactions on the Cardano Blockchain should be predictable and not unreasonable.
The Cardano Blockchain should facilitate an accessible, predictable pricing model.
Anyone desiring to develop and deploy applications on the Cardano Blockchain should not
unreasonably be prevented from developing and deploying such applications as intended. The
Cardano community should promote features to assist in developing and deploying applications
such as digital subscriber lines, formal verification support, asynchronous and scalable location
services, oracles and access to partnerchains.
Contributions by Cardano community on the Cardano Blockchain should be recognized,
recorded and assessed fairly by the Cardano community through reward sharing with SPOs and
DReps, appropriate tokenomics and multi-resource consensus approaches.
The Cardano Blockchain shall not lock in an ada owner’s value without an owner’s consent. The
Cardano Blockchain should promote interoperability and access to partnerchains.
The Cardano Blockchain shall preserve in a safe manner any value and information an owner of
ada seeks to store on the Cardano Blockchain. To assure safe protection of value and
information, the Cardano Blockchain should focus on integrity, post-quantum security,
decentralization and decentralized storage, access to stablecoins and robust key management
approaches.
The Cardano Blockchain shall not unnecessarily spend resources. The Cardano Blockchain shall
promote efficient design, memory and storage.
All users of the Cardano Blockchain shall be treated equally taking into account the collective
desires of the Cardano Blockchain community consistent with the long-term sustainability and
viability of the Cardano Blockchain. Long-term sustainability and viability shall be evaluated by
a number of considerations including fairness, neutrality, sustainability, robust governance,
promotion of decentralized identity, use of multi-resource consensus and democratic
participation by all members of the Cardano community.
The Cardano Blockchain shall operate in accordance with the Cardano Blockchain Guardrails as
set forth in the Guardrails Appendix to this Constitution. The Cardano community may from
time to time digitally codify certain Cardano Blockchain Guardrails such that such Cardano
Blockchain Guardrails are directly programmed and implemented on the Cardano Blockchain
using on-chain scripts or built-in ledger rules.
In the event there are inconsistencies between a Cardano Blockchain Guardrail as set forth in the
Guardrails Appendix and any such Cardano Blockchain Guardrail that has been programmed and
implemented on the Cardano Blockchain, the version of such Cardano Blockchain Guardrail that
has been deployed directly on the Cardano Blockchain shall prevail and the Constitutional
Committee shall seek to reconcile such inconsistencies through the encouragement of an
appropriate on-chain governance action.
No formal membership shall be required to use, participate in and benefit from the Cardano
Blockchain. Instead, all owners of ada, all developers of, all those building on, and all those
otherwise supporting, maintaining or using the Cardano Blockchain are beneficiaries of the
Cardano Blockchain ecosystem and, as such, are collectively members of the Cardano
community. All Cardano community members are accordingly beneficiaries of this Constitution,
entitled to its rights, privileges and protections and, as such, are expected to support and uphold
this Constitution.
Members of the Cardano community who own ada [, as well as their appointed designees,] are
entitled to access and participate in the on-chain decision-making processes of the Cardano
Blockchain ecosystem, including voting and taking part in on-chain governance regarding the
Cardano Blockchain.
Members of the Cardano community have a responsibility to maintain the integrity of the
Cardano Blockchain ecosystem by following this Constitution, operating the Cardano
Blockchain network, participating in Cardano Blockchain governance activities, and resolving
disputes in a fair and transparent manner.
The Cardano community is entitled and encouraged through the provisions of this Constitution to
collaborate in developing, maintaining and building applications for the Cardano community,
and to form temporary and permanent organizations and entities as the Cardano community
deems desirable or appropriate in support of the Cardano Blockchain ecosystem.
The Cardano Blockchain ecosystem shall be governed by a decentralized, on-chain governance
model, utilizing, to the extent possible and beneficial, smart contracts and other blockchain-
based tools to facilitate decision-making and ensure transparency. On-chain voting for
governance actions shall follow the process outlined in the Cardano Blockchain Guardrails.
Three independent governance bodies shall participate in voting for on-chain governance actions
to provide checks and balances for the Cardano Blockchain consisting of Delegated
Representatives (DRep), Stake Pool Operators (SPO) and the Constitutional Committee (CC).
On-chain governance decisions shall be made through a collective decision-making process, with
specific consensus threshold requirements as required by the Cardano Blockchain Guardrails.
All on-chain governance actions shall be voted upon in accordance with the Cardano Blockchain
Guardrails.
All owners of ada [, as well as their appointed designees,] shall have the right to vote in on-chain
governance action decision-making processes, subject to any restrictions or requirements
provided for in this Constitution and the Cardano Blockchain Guardrails.
All owners of ada [, as well as their appointed designees,] shall have the right to propose changes
to the governance structure of the Cardano Blockchain ecosystem in accordance with the
Cardano Blockchain Guardrails.
A special form of governance action exists to allow community sentiment to be gauged without
committing to any on-chain change of the Cardano Blockchain. "Info" actions have no on-chain
effect other than to record the outcome of such a vote on the Cardano Blockchain.
Any proposed on-chain governance action shall require a standardized and legible format
including a URL and hash linked to documented off-chain content. Sufficient rationale shall be
provided to justify the requested change to the Cardano 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 should undergo
sufficient technical review and scrutiny as mandated by the Cardano Blockchain 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 Cardano Blockchain ecosystem.
All owners of ada shall have the right to ensure that the process for participating in, submitting
and voting on on-chain governance actions is open and transparent and is protected from undue
influence and manipulation.
The Cardano community is expected to support the creation, maintenance and ongoing
administration of off-chain governance processes as may be necessary to give effect to this
Constitution and to ensure that there is awareness of and an opportunity to debate and shape all
future governance actions for the Cardano Blockchain.
The Cardano community is expected to propose, not less than on an annual basis, a budget for
the ongoing maintenance and future development of the Cardano Blockchain. All owners of
ada [, as well as their appointed designees,] are expected to periodically approve the Cardano
Blockchain budget through an on-chain governance action. No withdrawals from the Cardano
treasury shall be permitted unless a budget for the Cardano Blockchain is then in effect as
required by the Cardano Blockchain Guardrails.
[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.]
In order to participate in governance actions, owners of ada may register as DReps and directly
vote on such governance actions or may delegate their voting rights to other registered DReps
who shall vote on their behalf.
Any owner of ada shall have the option to register as a DRep. Any owner of ada [, as well as
their appointed designees,] 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.
[DReps are expected to adopt codes of conduct from time to time governing their activities as DReps and make such codes of conduct publicly available.]
The Cardano community is expected to support the creation, maintenance and ongoing
administration of tools to enable owners of ada to explore and evaluate DRep candidates and
select DReps on such criteria as they deem relevant.
[DReps may be compensated for their efforts to foster the creation of a professional governance cohort for the Cardano Blockchain ecosystem. DReps shall ensure that any compensation received in connection with their activities as a DRep is disclosed. DReps may not otherwise purchase voting rights.]
SPOs shall have a specific role in approving critical on-chain governance actions which require
additional oversight and independence, voting separately and independently from DReps as set
forth in the Cardano Blockchain Guardrails. SPOs shall participate in hard fork initiation
processes as the operators of the nodes that participate in Cardano Blockchain’s consensus
mechanism.
SPOs may act as a check on the power of the Constitutional Committee under exceptional
circumstances by separately voting on "Motion of no-confidence" and "Update
committee/threshold" governance actions.
[Owners of ada who are both DReps and SPOs shall either refrain from voting in on-chain governance actions in both capacities or shall publicly disclose that they are participating in on- chain governance actions in both such capacities prior to exercising any on-chain governance rights.]
A Constitutional Committee shall be established as the branch of Cardano's on-chain governance
process that ensures governance actions are consistent with this Constitution. The Constitutional
Committee shall comprise a set of owners of ada [, including their appointed designees,] that is
collectively 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. Constitutional Committee members are expected to have
appropriate expertise to carry out their required responsibilities, considering their past
contributions and involvement in the Cardano Blockchain ecosystem.
The Constitutional Committee shall be composed of [such number of members as shall be
determined from time to time by owners of ada] , as consistent with the Cardano Blockchain
Guardrails, and as shall be sufficient to assure the ongoing integrity of the Cardano Blockchain.
The Constitutional Committee shall be composed of [such number of members as shall be
determined from time to time by owners of ada] , as consistent with the Cardano Blockchain
Guardrails, and as shall be sufficient to assure the ongoing integrity of the Cardano Blockchain.
Members of the Constitutional Committee shall serve such terms [as shall be determined from
time to time by owners of ada] as consistent with the Cardano Blockchain Guardrails, provided
that terms shall not be less than one year. To assure continuity in the operation of Constitutional
Committee, the terms for Constitutional Committee members shall be staggered.
The Cardano community shall establish a process from time to time for election of members of
the Constitutional Committee consistent with the requirements of the Cardano Blockchain
Guardrails.
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.
Constitutional Committee processes shall be transparent. The Constitutional Committee shall
publish each decision. When voting [no] on a proposal, [the Constitutional Committee] [each
member of the Constitutional committee casting a no vote] shall set forth the basis for its
decision with reference to specific Articles of this Constitution that are in conflict with a given
proposal.
The Constitutional Committee shall operate pursuant to a code of conduct published by the
Constitutional Committee from time to time and shall adopt such policies and procedures as the
Constitutional Committee shall deem necessary in carrying out its duties.
The Cardano community is expected to support the creation, maintenance and ongoing
administration of tools as may be necessary and appropriate for the Constitutional Committee to
perform its required functions.
[Constitutional Committee members may be compensated for their efforts as members of the Constitutional Committee. Constitutional Committee members shall ensure that any compensation received in connection with their activities as a member is disclosed.] [Budgets approved for the Cardano Blockchain shall include allocations from the Cardano Blockchain treasury sufficient to [compensate Constitutional Committee members in such amounts as may be approved from time to time by ada owners] and to provide for periodic administrative costs of the Constitutional Committee in such amounts as requested from time to time by the Constitutional Committee.]
Except as otherwise so provided in the Cardano Blockchain Guardrails Appendix, amendments
to this Constitution, including to the Cardano Blockchain Guardrails Appendix, shall be
approved by a collective decision-making process, requiring an on-chain governance action by
owners of ada [, including their appointed designees,] satisfying a threshold of not less than 67%
of the then active voting stake.
If the Cardano Blockchain Guardrails Appendix sets forth an amendment threshold for a
Cardano Blockchain Guardrail that is different than the amendment threshold contained in
Section 1 of this Article VII, then the threshold set forth in the Cardano Blockchain Guardrails
Appendix for such Cardano Blockchain Guardrail shall apply.
To implement Cardano Blockchain on-chain governance pursuant to CIP-1694, it is necessary to
establish sensible guardrails that will enable the Cardano Blockchain to continue to operate in a
secure and sustainable way.
This Appendix sets forth guardrails that must be applied to Cardano Blockchain on-chain
governance actions, including changes to the protocol parameters and limits on treasury
withdrawals. These guardrails cover both essential, intrinsic limits on settings, and
recommendations that are based on experience, measurement and governance objectives.
These guardrails are designed to avoid unexpected problems with the operation of the Cardano
Blockchain. They are intended to guide the choice of sensible parameter settings and avoid
potential problems with security, performance or functionality. As described below, some of
these guardrails are automatable and will be enforced via an on-chain script or built-in ledger
rules.
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 in this Appendix.
While the guardrails in this Appendix presently reflect the current state of technical insight, this
Appendix 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 Appendix may be amended from time to time pursuant to an on-
chain governance action that satisfies the applicable voting threshold as set forth in this
Appendix. Any such amendment to any guardrails shall require and be deemed to be an
amendment to the Constitution itself.
Should/Should not. Where this Appendix 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 Appendix 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:
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.
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:
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
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.
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:
Where these parameter names differ, this Appendix uses the second convention.
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).
The below protocol parameters are critical from a security point of view.
Parameters that are Critical to the Operation of the Blockchain
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
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.
The overall goals when managing economic parameters are to:
Triggers for Change
Counter-indicators
Changes to the economic parameters should not be made in isolation. They need to account for:
Core Metrics
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 x nBytes(tx)
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:
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:
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.
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:
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.
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:
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:
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:
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:
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:
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.
Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte)
Defines the cost for using Plutus reference scripts in Lovelace.
MFRS-01 (y) minFeeRefScriptCoinsPerByte must not exceed 1,000 (0.001 ada).
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.
The overall goals when managing the Cardano Blockchain network parameters are to:
Triggers for Change
Changes to network parameters may be triggered by:
Counter-indicators
Changes may need to be reversed and/or should not be enacted in the event of:
Core Metrics
All decisions on parameter changes should be informed by:
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.
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.
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.
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.
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.
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).
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).
The overall goals when managing the technical/security parameters are:
Triggers for Change
Counter-indicators
Core Metrics
Changes to Specific Technical/Security Parameters
Target Number of Stake Pools (stakePoolTargetNum)
Sets the target number of stake pools:
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:
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.
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:
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.
MCI-01 (y) maxCollateralInputs must not be lower than 1.
The limit on the serialized size of the Value in each output.
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:
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.
The overall goals when managing the governance parameters are to:
Triggers for Change
Changes to governance parameters may be triggered by:
Counter-indicators
Changes may need to be reversed and/or should not be enacted in the event of:
Core Metrics
All decisions on parameter changes should be informed by:
Changes to Specific Governance Parameters
Deposit for Governance Actions (govDeposit)
The deposit that is charged when submitting a governance action:
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:
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.
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:
The threshold parameters are listed below:
dRepVotingThresholds:
poolVotingThresholds:
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:
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.
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.
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.
All network parameter changes must be monitored carefully for no less than 2 epochs (10 days):
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:
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.
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.
Treasury withdrawal actions specify the destination and amount of a number of withdrawals from the Cardano treasury.
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.
The hard fork initiation action requires both a new major and a new minor protocol version to be specified:
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.
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 Appendix 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 Appendix.
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.
Update Constitutional Committee or Threshold governance actions may change the size, composition, or required voting thresholds for the Constitutional Committee.
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.
New constitution or guardrails script actions change the hash of the on-chain constitution and the associated guardrails script.
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.
No confidence actions signal a state of no confidence in the governance system. No guardrails are imposed on No Confidence actions.
Info actions are not enacted on-chain. No guardrails are imposed on Info actions.
Interim Period
The Interim Period begins with the Chang Hard-Fork 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 the features of CIP-1694.
Interim Period Technical Rollout:
These actions are the "Info", "Hard-fork initiation", and "Protocol parameter changes" actions.
ada holders will be able to register as and delegate to DReps immediately after the hard fork but, as described in CIP-1694, DRep voting will not be available, except on "Info" actions. This ensures that ada holders have sufficient time to choose their voting delegations.
SPOs will be 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 the pre-defined Abstain/No Confidence voting options).
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 Appendix 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.
The protocol parameters are grouped by type, allowing different thresholds to be set for each group.
The network group consists of:
The economic group consists of:
The technical group consists of:
The governance group consists of all the new protocol parameters that are introduced in CIP-1694:
This Interim Constitution serves as the foundational governance framework for the Cardano Blockchain ecosystem during the transitional period leading up to the ratification of the Final Constitution. The Interim Constitution aims to ensure continuity, stability, and decentralization of governance, facilitating the transition to a fully decentralized and community-driven governance model.
The Interim Constitutional Committee (ICC) shall be established to oversee the governance of the Cardano Blockchain during the Interim Period. The ICC shall have the authority to approve or reject governance actions, ensure compliance with the Interim Constitution, and oversee the transition to the Final Constitution.
Composition:
Term:
Powers:
Dissolution:
During the Interim Period, governance actions shall be subject to the following voting mechanisms:
DReps Voting:
SPOs Voting:
Community Sentiment Votes:
The Cardano community shall be responsible for developing and ratifying the Final Constitution, which will replace this Interim Constitution. The process for developing the Final Constitution shall include:
Upon ratification of the Final Constitution:
Amendments to this Interim Constitution may be proposed by any ADA holder, DRep, or SPO. The process for amending the Interim Constitution is as follows:
In the event of a conflict between this Interim Constitution and any governance action or protocol parameter, this Interim Constitution shall prevail.
All governance actions, guardrails, and protocol parameters enacted under the Interim Constitution shall remain in effect until they are explicitly amended or repealed by the Final Constitution.
The Interim Constitutional Committee shall have the final authority to interpret the provisions of this Interim Constitution. All interpretations shall be made in a manner consistent with the principles of decentralization, community participation, and the long-term sustainability of the Cardano ecosystem.
Upon the ratification of the Final Constitution, all governance structures and committees established under this Interim Constitution shall be dissolved, and their powers shall be transferred to the governance structures established by the Final Constitution.
ADA: The native cryptocurrency of the Cardano Blockchain.
Cardano Blockchain: A decentralized blockchain platform that enables the development of smart contracts, decentralized applications (DApps), and digital assets.
CIP-1694: A Cardano Improvement Proposal that outlines the governance framework for the Cardano Blockchain.
Constitutional Committee: The governance body responsible for ensuring that governance actions are consistent with the Cardano Constitution.
DRep (Delegated Representative): An individual or entity that represents ADA holders in the on-chain governance process by voting on governance actions on their behalf.
Epoch: A time period used in the Cardano Blockchain, typically lasting 5 days.
Final Constitution: The permanent governance framework for the Cardano Blockchain, to be ratified by the community and replace the Interim Constitution.
Guardrails: Specific guidelines and constraints that govern the parameters and actions within the Cardano Blockchain ecosystem.
Hard Fork: A protocol upgrade that changes the blockchain's rules and requires all nodes to upgrade to the new version.
Interim Constitution: The temporary governance framework for the Cardano Blockchain during the transition to the Final Constitution.
SPO (Stake Pool Operator): An individual or entity responsible for operating a stake pool, which participates in the consensus mechanism of the Cardano Blockchain.
Treasury: A pool of ADA used to fund development and other initiatives within the Cardano ecosystem.
During the Interim Period, the following initial governance actions shall be prioritized:
The development and ratification of the Final Constitution shall follow a structured timeline to ensure broad community participation and careful consideration of all relevant factors.
During the Interim Period, specific governance actions shall be prioritized to ensure the smooth transition to the Final Constitution. These actions include:
CIP-1694 introduces a new governance framework for the Cardano Blockchain, emphasizing decentralization, community participation, and robust governance structures. This appendix provides guidelines for implementing CIP-1694, ensuring that all aspects of the governance framework are effectively realized.
DReps play a crucial role in representing ADA holders in the governance process. The following steps outline the process for establishing DReps:
SPOs contribute to the security and decentralization of the Cardano Blockchain and participate in governance actions. The following guidelines apply to SPOs:
The Constitutional Committee is the final authority on the constitutionality of governance actions. The following steps outline the establishment and operation of the Constitutional Committee:
The voting procedures for governance actions are designed to be transparent, inclusive, and efficient. The following guidelines outline the key aspects of the voting process:
The governance framework established by CIP-1694 requires ongoing maintenance to ensure its effectiveness and adaptability. The following guidelines outline key aspects of governance maintenance:
Engaging and educating the Cardano community is critical to the success of the governance framework. The following guidelines outline key initiatives for community engagement and education:
The implementation of CIP-1694 and the ongoing development of the Cardano governance framework represent a significant step toward a truly decentralized, community-driven ecosystem. By adhering to the principles of transparency, inclusivity, and accountability, the Cardano community can ensure the long-term success and sustainability of the blockchain.
As the governance framework continues to evolve, the active participation and engagement of all stakeholders will be crucial. Through collaboration, education, and a shared commitment to the principles outlined in the Cardano Constitution, the community can achieve its vision of a decentralized, fair, and resilient blockchain ecosystem.
This document, along with the Cardano Constitution, shall serve as a living framework, continuously adapted and improved in response to the needs and aspirations of the Cardano community.