2024-07-29-draft-consitution-converted.html

<p><code>Draft 2024-07-29</code></p>
<h1>CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION</h1>
<h2>PREAMBLE</h2>
<p>In the beginning of the Cardano Blockchain ecosystem, three pioneering entities, IOHK,<br />
Emurgo, and the Cardano Foundation, came together to foster the emergence of a new<br />
blockchain, the Cardano Blockchain, laying the foundation for a decentralized network that<br />
would empower individuals, and promote collaboration and innovation. Their pioneering efforts<br />
have shaped the path for a blockchain designed to ensure a fair and transparent environment<br />
where all participants can contribute to the Cardano Blockchain ecosystem's growth and success.</p>
<p>Over time, the Cardano Blockchain ecosystem has expanded significantly, and now, the Cardano<br />
Blockchain ecosystem, comprising of thousands of ada holders, individuals, builders, developers,<br />
enterprises, stake pools, users of the Cardano Blockchain and others, operates in a truly<br />
decentralized manner, further strengthening the resilience and autonomy of the Cardano<br />
Blockchain ecosystem.</p>
<p>As the Cardano Blockchain ecosystem continues to grow, it has become imperative to similarly<br />
adapt and evolve its governance model, reflecting the principles of decentralization, community<br />
involvement, inclusivity and collaboration that have been the cornerstone of the Cardano<br />
Blockchain ecosystem since its start.</p>
<p>Recognizing the need for a more robust and dynamic governance framework, and one that<br />
utilizes wherever possible and beneficial blockchain technology in the governance process, the<br />
Cardano community, as the members of this decentralized Cardano Blockchain ecosystem,<br />
hereby establishes this Cardano Constitution. It shall serve as a guiding set of principles for the<br />
operation and governance of our collective efforts, fostering an environment where all<br />
participants can contribute to the betterment of the Cardano Blockchain ecosystem as a whole.</p>
<p>Through adopting this Constitution, the Cardano Blockchain ecosystem shall establish a robust<br />
governance framework, ensuring that decisions are made in the best interest of the Cardano<br />
community. The Cardano community shall uphold principles of transparency, openness, and<br />
responsible governance, promoting a culture of trust and collaboration. Together, the Cardano<br />
community commits to uphold these principles and to work together towards the continuous<br />
improvement, growth, and success of our decentralized blockchain ecosystem known as the<br />
Cardano Blockchain.</p>
<p>This Constitution shall serve as the embodiment of these guiding principles for the operation and<br />
governance of the decentralized Cardano Blockchain ecosystem, providing a foundation that will<br />
adapt and evolve over time to meet the continuing needs of the Cardano community.</p>
<p>All members of the Cardano community are expected to abide by this Constitution, and are<br />
entitled to participate in its governance processes, and are encouraged to work collaboratively<br />
towards the betterment of the Cardano Blockchain ecosystem as a whole, contributing to its<br />
growth, sustainability, and success. The Cardano Blockchain shall be governed on a vote-based<br />
decision-making model, fostering inclusivity, a diversity of views, innovation and adaptability.</p>
<p>All owners of ada shall have the opportunity to contribute to the governance and direction of the<br />
decentralized Cardano Blockchain ecosystem.</p>
<p>In approaching this Constitution, it must be remembered that this is not a constitution for only a<br />
blockchain but rather, it is a constitution for a blockchain ecosystem – a much more ambitious<br />
endeavor. Accordingly, how governance actions are approved, while extremely important, is not<br />
the sole focus of this Constitution. Rather, this Constitution provides the basis and fundamental<br />
framework through which all actors in the Cardano Blockchain ecosystem can come together to<br />
govern themselves and form radically new approaches to human interaction and collaboration.</p>
<p>By necessity, this Constitution recognizes the role of and empowers the Constitutional<br />
Committee, confirms the right of the Cardano community to participate in collective bodies for<br />
collaboration, gives effect to on-chain governance, and empowers DReps to act as the voice of<br />
ada owners for on-chain voting.</p>
<p>The Constitution also recognizes the necessity of safeguarding access to and the use of funds of<br />
the Cardano treasury through the inclusion of the Cardano Guardrails in this Constitution.</p>
<h2>ARTICLE I. CARDANO BLOCKCHAIN TENETS AND GUARDRAILS</h2>
<h3>Section 1</h3>
<p>These below Tenets shall guide all actors in the Cardano Blockchain ecosystem including the<br />
Constitutional Committee and proposed governance actions shall be evaluated in accordance<br />
with these Tenets.</p>
<p>Transactions on the Cardano Blockchain should not be slowed down or censored and should be<br />
expediently served for their intended purpose. The Cardano Blockchain should scale taking into<br />
consideration throughput, sharding, settlement and dynamic pricing.</p>
<p>The cost of transactions on the Cardano Blockchain should be predictable and not unreasonable.<br />
The Cardano Blockchain should facilitate an accessible, predictable pricing model.</p>
<p>Anyone desiring to develop and deploy applications on the Cardano Blockchain should not<br />
unreasonably be prevented from developing and deploying such applications as intended. The<br />
Cardano community should promote features to assist in developing and deploying applications<br />
such as digital subscriber lines, formal verification support, asynchronous and scalable location<br />
services, oracles and access to partnerchains.</p>
<p>Contributions by Cardano community on the Cardano Blockchain should be recognized,<br />
recorded and assessed fairly by the Cardano community through reward sharing with SPOs and<br />
DReps, appropriate tokenomics and multi-resource consensus approaches.</p>
<p>The Cardano Blockchain shall not lock in an ada owner’s value without an owner’s consent. The<br />
Cardano Blockchain should promote interoperability and access to partnerchains.</p>
<p>The Cardano Blockchain shall preserve in a safe manner any value and information an owner of<br />
ada seeks to store on the Cardano Blockchain. To assure safe protection of value and<br />
information, the Cardano Blockchain should focus on integrity, post-quantum security,<br />
decentralization and decentralized storage, access to stablecoins and robust key management<br />
approaches.</p>
<p>The Cardano Blockchain shall not unnecessarily spend resources. The Cardano Blockchain shall<br />
promote efficient design, memory and storage.</p>
<p>All users of the Cardano Blockchain shall be treated equally taking into account the collective<br />
desires of the Cardano Blockchain community consistent with the long-term sustainability and<br />
viability of the Cardano Blockchain. Long-term sustainability and viability shall be evaluated by<br />
a number of considerations including fairness, neutrality, sustainability, robust governance,<br />
promotion of decentralized identity, use of multi-resource consensus and democratic<br />
participation by all members of the Cardano community.</p>
<h4>Workshop Questions</h4>
<ul>
<li>Do you believe these tenets appropriately reflect the ethos of the Cardano Blockchain?</li>
<li>Should there be an additional tenet addressing financial sustainability? If yes, what<br />
should it contain? Should it include an absolute cap on the circulating supply of ada?</li>
</ul>
<h3>Section 2</h3>
<p>The Cardano Blockchain shall operate in accordance with the Cardano Blockchain Guardrails as<br />
set forth in the Guardrails Appendix to this Constitution. The Cardano community may from<br />
time to time digitally codify certain Cardano Blockchain Guardrails such that such Cardano<br />
Blockchain Guardrails are directly programmed and implemented on the Cardano Blockchain<br />
using on-chain scripts or built-in ledger rules.</p>
<p>In the event there are inconsistencies between a Cardano Blockchain Guardrail as set forth in the<br />
Guardrails Appendix and any such Cardano Blockchain Guardrail that has been programmed and<br />
implemented on the Cardano Blockchain, the version of such Cardano Blockchain Guardrail that<br />
has been deployed directly on the Cardano Blockchain shall prevail and the Constitutional<br />
Committee shall seek to reconcile such inconsistencies through the encouragement of an<br />
appropriate on-chain governance action.</p>
<h2>ARTICLE II. THE CARDANO BLOCKCHAIN COMMUNITY</h2>
<h3>Section 1</h3>
<p>No formal membership shall be required to use, participate in and benefit from the Cardano<br />
Blockchain. Instead, all owners of ada, all developers of, all those building on, and all those<br />
otherwise supporting, maintaining or using the Cardano Blockchain are beneficiaries of the<br />
Cardano Blockchain ecosystem and, as such, are collectively members of the Cardano</p>
<p>community. All Cardano community members are accordingly beneficiaries of this Constitution,<br />
entitled to its rights, privileges and protections and, as such, are expected to support and uphold<br />
this Constitution.</p>
<h3>Section 2</h3>
<p>Members of the Cardano community who own ada <em>[, as well as their appointed designees,]</em> are<br />
entitled to access and participate in the on-chain decision-making processes of the Cardano<br />
Blockchain ecosystem, including voting and taking part in on-chain governance regarding the<br />
Cardano Blockchain.</p>
<h4>Workshop Questions</h4>
<ul>
<li>Should on-chain governance participation be limited to only owners of ada or should<br />
ada owners be allowed to appoint designees who are then entitled to participate in on-<br />
chain governance? [Note that this is not a reference to delegation to DReps.</li>
</ul>
<h3>Section 3</h3>
<p>Members of the Cardano community have a responsibility to maintain the integrity of the<br />
Cardano Blockchain ecosystem by following this Constitution, operating the Cardano<br />
Blockchain network, participating in Cardano Blockchain governance activities, and resolving<br />
disputes in a fair and transparent manner.</p>
<h3>Section 4</h3>
<p>The Cardano community is entitled and encouraged through the provisions of this Constitution to<br />
collaborate in developing, maintaining and building applications for the Cardano community,<br />
and to form temporary and permanent organizations and entities as the Cardano community<br />
deems desirable or appropriate in support of the Cardano Blockchain ecosystem.</p>
<h2>ARTICLE III. PARTICIPATORY GOVERNANCE</h2>
<h3>Section 1</h3>
<p>The Cardano Blockchain ecosystem shall be governed by a decentralized, on-chain governance<br />
model, utilizing, to the extent possible and beneficial, smart contracts and other blockchain-<br />
based tools to facilitate decision-making and ensure transparency. On-chain voting for<br />
governance actions shall follow the process outlined in the Cardano Blockchain Guardrails.</p>
<h3>Section 2</h3>
<p>Three independent governance bodies shall participate in voting for on-chain governance actions<br />
to provide checks and balances for the Cardano Blockchain consisting of Delegated<br />
Representatives (DRep), Stake Pool Operators (SPO) and the Constitutional Committee (CC).</p>
<h3>Section 3</h3>
<p>On-chain governance decisions shall be made through a collective decision-making process, with<br />
specific consensus threshold requirements as required by the Cardano Blockchain Guardrails.<br />
All on-chain governance actions shall be voted upon in accordance with the Cardano Blockchain<br />
Guardrails.</p>
<h3>Section 4</h3>
<p>All owners of ada <em>[, as well as their appointed designees,]</em> shall have the right to vote in on-chain<br />
governance action decision-making processes, subject to any restrictions or requirements<br />
provided for in this Constitution and the Cardano Blockchain Guardrails.</p>
<h4>Workshop Questions</h4>
<ul>
<li>Voting rights are in proportion to the ada owned. However, should the Constitution<br />
specify a specific voting model?</li>
<li>Should the Constitution enshrine one ada one vote?</li>
<li>How do we address participation by institutions? Should holders of ada who are not<br />
owners, such as exchanges, be allowed to vote?</li>
</ul>
<p>All owners of ada <em>[, as well as their appointed designees,]</em> shall have the right to propose changes<br />
to the governance structure of the Cardano Blockchain ecosystem in accordance with the<br />
Cardano Blockchain Guardrails.</p>
<h3>Section 5</h3>
<p>A special form of governance action exists to allow community sentiment to be gauged without<br />
committing to any on-chain change of the Cardano Blockchain. "Info" actions have no on-chain<br />
effect other than to record the outcome of such a vote on the Cardano Blockchain.</p>
<h3>Section 6</h3>
<p>Any proposed on-chain governance action shall require a standardized and legible format<br />
including a URL and hash linked to documented off-chain content. Sufficient rationale shall be<br />
provided to justify the requested change to the Cardano Blockchain. The rationale shall include,<br />
at a minimum, a title, abstract, reason for the proposal, and relevant supporting materials.</p>
<p>Any governance action proposal reaching the on-chain governance stage shall be identical in<br />
content as to the final off-chain version of such governance action proposal.</p>
<p>“Hard Fork Initiation” and “Protocol Parameter Change” governance actions should undergo<br />
sufficient technical review and scrutiny as mandated by the Cardano Blockchain Guardrails to<br />
ensure that the governance action does not endanger the security, functionality or performance of<br />
the Cardano Blockchain. On-chain governance actions should address their expected impact on<br />
the Cardano Blockchain ecosystem.</p>
<p>All owners of ada shall have the right to ensure that the process for participating in, submitting<br />
and voting on on-chain governance actions is open and transparent and is protected from undue<br />
influence and manipulation.</p>
<h3>Section 7</h3>
<p>The Cardano community is expected to support the creation, maintenance and ongoing<br />
administration of off-chain governance processes as may be necessary to give effect to this<br />
Constitution and to ensure that there is awareness of and an opportunity to debate and shape all<br />
future governance actions for the Cardano Blockchain.</p>
<h3>Section 8</h3>
<p>The Cardano community is expected to propose, not less than on an annual basis, a budget for<br />
the ongoing maintenance and future development of the Cardano Blockchain. All owners of<br />
ada <em>[, as well as their appointed designees,]</em> are expected to periodically approve the Cardano<br />
Blockchain budget through an on-chain governance action. No withdrawals from the Cardano<br />
treasury shall be permitted unless a budget for the Cardano Blockchain is then in effect as<br />
required by the Cardano Blockchain Guardrails.</p>
<p><em>[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.]</em></p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution require that governance actions above a specified amount<br />
include allocations of ada to cover periodic audits and implementation of oversight<br />
metrics? If yes, how should they be enforced?</li>
<li>Should the Constitution require that contractual provisions governing the use of ada<br />
received from the treasury above a specified amount include dispute resolution<br />
provisions? If yes, how should they be enforced?</li>
<li>Should the Constitution require that the budget include a contingency fund? If so, how<br />
would it work? What could it be used for? Who would administer it?</li>
<li>Should the Constitution require that the budget include an indemnity fund to cover<br />
potential claims against governance participants such as DReps and Constitutional<br />
Committee members? If so, how would it work? What could it be used for? Who would<br />
administer it?</li>
<li>Should the budgetary process be spelled out in greater detail in the Constitution? Should<br />
the Constitution identify how the budget will be administered? Should it identify who<br />
will administer the budget?</li>
<li>Should the Constitution specify a cap on the annual budget?</li>
</ul>
<h2>ARTICLE IV. DELEGATED REPRESENTATIVES</h2>
<h3>Section 1</h3>
<p>In order to participate in governance actions, owners of ada may register as DReps and directly<br />
vote on such governance actions or may delegate their voting rights to other registered DReps<br />
who shall vote on their behalf.</p>
<h3>Section 2</h3>
<p>Any owner of ada shall have the option to register as a DRep. Any owner of ada <em>[, as well as
their appointed designees,]</em> shall be allowed to delegate their voting stake to one or more<br />
registered DReps, including themselves. DReps may be individuals or coordinated groups.<br />
DReps are entitled to cast votes directly for on-chain governance actions and represent those ada<br />
holders delegating their voting rights to them.</p>
<p>This voting system shall enshrine a liquid democracy model where owners of ada can seamlessly<br />
select among DReps, register as a DRep, and change their delegation at any time.</p>
<h3>Section 3</h3>
<p><em>[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.]</em></p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution include any guidelines as to the requirements that must be<br />
included by DReps in their respective codes of conduct?</li>
<li>Should there be one code of conduct for all DReps or should each DRep be allowed to<br />
adopt its own code of conduct? Should DRep codes of conduct be on-chain?</li>
<li>Should the Constitutional Committee determine whether such codes of conduct are<br />
consistent with the Constitution?</li>
<li>Should the Constitution include term limits for DReps?</li>
</ul>
<h3>Section 4</h3>
<p>The Cardano community is expected to support the creation, maintenance and ongoing<br />
administration of tools to enable owners of ada to explore and evaluate DRep candidates and<br />
select DReps on such criteria as they deem relevant.</p>
<h3>Section 5</h3>
<p><em>[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.]</em></p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution mandate compensation for DReps? If so, should the Constitution<br />
specify how compensation is determined or include a cap on compensation?</li>
<li>Should the Constitution require that budgets approved for the Cardano Blockchain<br />
include an allocation from the Cardano Blockchain treasury sufficient to compensate<br />
DReps in such amounts as may be approved from time to time by ada owners.</li>
</ul>
<h2>ARTICLE V. STAKE POOL OPERATORS</h2>
<h3>Section 1</h3>
<p>SPOs shall have a specific role in approving critical on-chain governance actions which require<br />
additional oversight and independence, voting separately and independently from DReps as set<br />
forth in the Cardano Blockchain Guardrails. SPOs shall participate in hard fork initiation<br />
processes as the operators of the nodes that participate in Cardano Blockchain’s consensus<br />
mechanism.</p>
<h3>Section 2</h3>
<p>SPOs may act as a check on the power of the Constitutional Committee under exceptional<br />
circumstances by separately voting on "Motion of no-confidence" and "Update<br />
committee/threshold" governance actions.</p>
<h3>Section 3</h3>
<p><em>[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.]</em></p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution include a requirement that ada owners who are both DReps and<br />
SPOs either refrain from voting in both capacities or disclose such dual roles?</li>
<li>Should the Constitution include other conflicts of interest provisions included?</li>
<li>Should the Constitution require that SPOs be expected to implement codes of conduct? If<br />
yes, should they be on-chain? Should the Constitutional Committee determine whether<br />
such codes of conduct are consistent with the Constitution?]</li>
</ul>
<h2>ARTICLE VI. CONSTITUTIONAL COMMITTEE</h2>
<h3>Section 1</h3>
<p>A Constitutional Committee shall be established as the branch of Cardano's on-chain governance<br />
process that ensures governance actions are consistent with this Constitution. The Constitutional<br />
Committee shall comprise a set of owners of ada <em>[, including their appointed designees,]</em> that is<br />
collectively responsible for ensuring that on-chain governance actions prior to enactment on-<br />
chain, are constitutional. The Constitutional Committee shall be limited to voting on the<br />
constitutionality of governance actions. Constitutional Committee members are expected to have<br />
appropriate expertise to carry out their required responsibilities, considering their past<br />
contributions and involvement in the Cardano Blockchain ecosystem.</p>
<h3>Section 2</h3>
<p>The Constitutional Committee shall be composed of <em>[such number of members as shall be
determined from time to time by owners of ada]</em> , as consistent with the Cardano Blockchain<br />
Guardrails, and as shall be sufficient to assure the ongoing integrity of the Cardano Blockchain.</p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution specify</li>
</ul>
<h3>Section 2</h3>
<p>The Constitutional Committee shall be composed of <em>[such number of members as shall be
determined from time to time by owners of ada]</em> , as consistent with the Cardano Blockchain<br />
Guardrails, and as shall be sufficient to assure the ongoing integrity of the Cardano Blockchain.</p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution specify how the number of members of the CC are determined?<br />
[Note that the Guardrails specify both a minimum and maximum number of members.]</li>
</ul>
<p>Members of the Constitutional Committee shall serve such terms <em>[as shall be determined from
time to time by owners of ada]</em> as consistent with the Cardano Blockchain Guardrails, provided<br />
that terms shall not be less than one year. To assure continuity in the operation of Constitutional<br />
Committee, the terms for Constitutional Committee members shall be staggered.</p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution specify how term limits for CC members are determined? [Note<br />
that the Guardrails specify both a minimum and maximum term limit.]</li>
</ul>
<h3>Section 3</h3>
<p>The Cardano community shall establish a process from time to time for election of members of<br />
the Constitutional Committee consistent with the requirements of the Cardano Blockchain<br />
Guardrails.</p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution include an explicit process for the election of members of the<br />
CC?</li>
</ul>
<h3>Section 4</h3>
<p>No governance action, other than a "Motion of no-confidence" or "Update constitutional<br />
committee/threshold" may be implemented on-chain unless the Constitutional Committee shall<br />
have first determined and affirmed through an on-chain action that such proposal does not violate<br />
this Constitution.</p>
<p>The Constitutional Committee shall be considered to be in one of the following two states at all<br />
times: a state of confidence or a state of no-confidence. In a state of no-confidence, members of<br />
the then standing Constitutional Committee must be reinstated or replaced using the "Update<br />
committee/threshold" governance action before any other on-chain governance action may go<br />
forward.</p>
<h3>Section 5</h3>
<p>Constitutional Committee processes shall be transparent. The Constitutional Committee shall<br />
publish each decision. When voting <em>[no]</em> on a proposal, <em>[the Constitutional Committee] [each
member of the Constitutional committee casting a no vote]</em> shall set forth the basis for its<br />
decision with reference to specific Articles of this Constitution that are in conflict with a given<br />
proposal.</p>
<p>The Constitutional Committee shall operate pursuant to a code of conduct published by the<br />
Constitutional Committee from time to time and shall adopt such policies and procedures as the<br />
Constitutional Committee shall deem necessary in carrying out its duties.</p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution require that the Constitutional Committee code of conduct be on-<br />
chain?</li>
<li>Should the community have any role in approving the Constitutional Committee code of<br />
conduct? If so, how would this work?</li>
</ul>
<h3>Section 6</h3>
<p>The Cardano community is expected to support the creation, maintenance and ongoing<br />
administration of tools as may be necessary and appropriate for the Constitutional Committee to<br />
perform its required functions.</p>
<h3>Section 7</h3>
<p><em>[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.]</em></p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution mandate compensation for CC members? If so, should the<br />
Constitution specify how compensation is determined or include a cap on compensation?</li>
<li>Should the Constitution require that budgets approved for the Cardano Blockchain<br />
include an allocation from the Cardano Blockchain treasury sufficient to compensate CC<br />
members in such amounts as may be approved from time to time by ada owners.</li>
<li>Should the Constitution require that the budget include an allocation for the<br />
administrative costs of the CC? If so, how should the amount be determined? If so,<br />
should the Constitution specify who would administer such a budget and whether<br />
expenditures by the CC should be public or subject to audit oversight?</li>
</ul>
<h2>ARTICLE VII. AMENDMENTS</h2>
<h3>Section 1</h3>
<p>Except as otherwise so provided in the Cardano Blockchain Guardrails Appendix, amendments<br />
to this Constitution, including to the Cardano Blockchain Guardrails Appendix, shall be<br />
approved by a collective decision-making process, requiring an on-chain governance action by<br />
owners of ada <em>[, including their appointed designees,]</em> satisfying a threshold of not less than 67%<br />
of the then active voting stake.</p>
<h3>Section 2</h3>
<p>If the Cardano Blockchain Guardrails Appendix sets forth an amendment threshold for a<br />
Cardano Blockchain Guardrail that is different than the amendment threshold contained in<br />
Section 1 of this Article VII, then the threshold set forth in the Cardano Blockchain Guardrails<br />
Appendix for such Cardano Blockchain Guardrail shall apply.</p>
<h4>Workshop Questions</h4>
<ul>
<li>Should the Constitution include a provision preventing Article VII itself from being<br />
amended or allowing any governance action that would have the effect of changing these<br />
amendment requirements?</li>
<li>Should the Constitution include a category of technical guardrail modifications that<br />
could be overseen and approved by the Constitutional Committee? Is this even possible?<br />
If yes, should such a category be narrowly defined to only address high security risks or<br />
emergency issues?</li>
</ul>
<h2>APPENDIX I: CARDANO BLOCKCHAIN GUARDRAILS</h2>
<h3>1. INTRODUCTION</h3>
<p>To implement Cardano Blockchain on-chain governance pursuant to CIP-1694, it is necessary to<br />
establish sensible guardrails that will enable the Cardano Blockchain to continue to operate in a<br />
secure and sustainable way.</p>
<p>This Appendix sets forth guardrails that must be applied to Cardano Blockchain on-chain<br />
governance actions, including changes to the protocol parameters and limits on treasury<br />
withdrawals. These guardrails cover both essential, intrinsic limits on settings, and<br />
recommendations that are based on experience, measurement and governance objectives.</p>
<p>These guardrails are designed to avoid unexpected problems with the operation of the Cardano<br />
Blockchain. They are intended to guide the choice of sensible parameter settings and avoid<br />
potential problems with security, performance or functionality. As described below, some of<br />
these guardrails are automatable and will be enforced via an on-chain script or built-in ledger<br />
rules.</p>
<p>These guardrails apply to the Cardano Blockchain Layer 1 mainnet environment. They are not<br />
intended to apply to test environments or to other blockchains that use the Cardano Blockchain<br />
software.</p>
<p>Not all parameters for the Cardano Blockchain can be considered independently. Some<br />
parameters interact with other settings in an intrinsic way. Where known, these interactions are<br />
addressed in this Appendix.</p>
<p>While the guardrails in this Appendix presently reflect the current state of technical insight, this<br />
Appendix should be treated as a living document. Implementation improvements, new<br />
simulations or performance evaluation results for the Cardano Blockchain may allow some of the<br />
restrictions contained in these guardrails to be relaxed (or, in some circumstances, require them<br />
to be tightened) in due course.</p>
<p>Additional guardrails may also be needed where, for example, new protocol parameters are<br />
introduced.</p>
<p>The guardrails set forth in this Appendix may be amended from time to time pursuant to an on-<br />
chain governance action that satisfies the applicable voting threshold as set forth in this<br />
Appendix. Any such amendment to any guardrails shall require and be deemed to be an<br />
amendment to the Constitution itself.</p>
<h4>Workshop Questions</h4>
<ul>
<li>Should any of the below Guardrails include an amendment threshold different from the<br />
threshold included in Article VII?</li>
</ul>
<h3>Terminology and Guidance</h3>
<p><strong>Should/Should not.</strong> Where this Appendix says that a value "should not" be set below or<br />
above some value, this means that the guardrail is a recommendation or guideline, and the<br />
specific value could be open to discussion or alteration by a suitably expert group recognized by<br />
the Cardano community in light of experience with the Cardano Blockchain governance system<br />
or the operation of the Cardano Blockchain.</p>
<p><strong>Must/Must not.</strong> Where this Appendix says that a value "must not" be set below or above<br />
some value, this means that the guardrail is a requirement that will be enforced by Cardano<br />
Blockchain ledger rules, types or other built-in mechanisms where possible, and that if not<br />
followed could cause a protocol failure, security breach or other undesirable outcome.</p>
<p><strong>Benchmarking.</strong> Benchmarking refers to careful system level performance evaluation that is<br />
designed to show a-priori that, for example, 95% of blocks will be diffused across a global<br />
network of Cardano Blockchain nodes within the required 5s time interval in all cases. This may<br />
require construction of specific test workflows and execution on a large test network of Cardano<br />
nodes, simulating a global Cardano Blockchain network.</p>
<p><strong>Performance analysis.</strong> Performance analysis refers to projecting theoretical performance,<br />
empirical benchmarking or simulation results to predict actual system behavior. For example,<br />
performance results obtained from tests in a controlled test environment (such as a collection of<br />
data centers with known networking properties) may be extrapolated to inform likely<br />
performance behavior in a real Cardano Blockchain network environment.</p>
<p><strong>Simulation.</strong> Simulation refers to synthetic execution that is designed to inform<br />
performance/functionality decisions in a repeatable way. For example, the IOSim Cardano<br />
Blockchain module allows the operation of the networking stack to be simulated in a controlled<br />
and repeatable way, allowing issues to be detected before code deployment.</p>
<p><strong>Performance Monitoring.</strong> Performance monitoring involves measuring the actual behavior<br />
of the Cardano Blockchain network, for example, by using timing probes to evaluate round-trip<br />
times, or test blocks to assess overall network health. It complements benchmarking and<br />
performance analysis by providing information about actual system behavior that cannot be<br />
obtained using simulated workloads or theoretical analysis.</p>
<p><strong>Reverting Changes.</strong> Where performance monitoring shows that actual network behavior<br />
following a change is inconsistent with the performance requirements for the Cardano<br />
Blockchain, then the change must be reverted to its previous state if that is possible. For<br />
example, if the block size is increased from 100KB to 120KB and 95% of blocks are no longer<br />
diffused within 5s, then a change must be made to revert the block size to 100KB. If this is not<br />
possible, then one or more alternative changes must be made that will ensure that the<br />
performance requirements are met.</p>
<p><strong>Severity Levels.</strong> Issues that affect the Cardano Blockchain network are classified by<br />
severity level, where:</p>
<ul>
<li>Severity 1 is a critical incident or issue with very high impact to the security,<br />
performance, or functionality of the Cardano Blockchain network.</li>
<li>Severity 2 is a major incident or issue with significant impact to the security,<br />
performance, or functionality of the Cardano Blockchain network.</li>
<li>Severity 3 is a minor incident or issue with low impact to the security, performance, or<br />
functionality of the Cardano Blockchain network.</li>
</ul>
<p><strong>Future Performance Requirements.</strong> Planned development such as new mechanisms for out-<br />
of-memory storage may impact block diffusion or other times. When changing parameters, it is<br />
necessary to consider these future performance requirements as well as the current operation of<br />
the Cardano Blockchain. Until development is complete, the requirements will be conservative;<br />
they may then be relaxed to account for actual timing behavior.</p>
<h3>Automated Checking ("Guardrails Script")</h3>
<p>A script hash is associated with the constitution hash when a <strong>New Constitution or Guardrails
Script</strong> governance action is enacted. It acts as an additional safeguard to the ledger rules and<br />
types, filtering non-compliant governance actions.</p>
<p>The guardrails script only affects two types of governance actions:</p>
<ul>
<li><strong>Parameter Update</strong> actions, and</li>
<li><strong>Treasury Withdrawal</strong> actions.</li>
</ul>
<p>The script is executed when either of these types of governance action is submitted on-chain.<br />
This avoids scenarios where, for example, an erroneous script could prevent the chain from ever<br />
enacting a Hard Fork action, resulting in deadlock. There are three different situations that apply<br />
to script usage.</p>
<p><strong>Symbol and Explanation</strong></p>
<ul>
<li>(y) The script can be used to enforce the guardrail.</li>
<li>(x) The script cannot be used to enforce the guardrail.</li>
<li>(~ - reason) The script cannot be used to enforce the guardrail for the reason given, but<br />
future ledger changes could enable this.</li>
</ul>
<p>Guardrails may overlap: in this case, the most restrictive set of guardrails will apply.</p>
<p>Where a parameter is not explicitly listed in this document, then the script <strong>must not</strong> permit<br />
any changes to the parameter.</p>
<p>Conversely, where a parameter is explicitly listed in this document but no checkable guardrails<br />
are specified, the script <strong>must not</strong> impose any constraints on changes to the parameter.</p>
<h3>2. GUARDRAILS AND GUIDELINES ON PROTOCOL PARAMETER UPDATE ACTIONS</h3>
<p>Below are guardrails and guidelines for changing updatable protocol parameter settings via the<br />
protocol parameter update governance action such that the Cardano Blockchain is never in an<br />
unrecoverable state as a result of such changes.</p>
<p>Note that there are at least five different sources of parameter names, and these are not always<br />
consistent:</p>
<ol>
<li>The name used in the Genesis file</li>
<li>The name used in protocol parameter update governance actions</li>
<li>The name used internally in ledger rules</li>
<li>The name used in the formal ledger specification</li>
<li>The name used in research papers</li>
</ol>
<p>Where these parameter names differ, this Appendix uses the second convention.</p>
<h4>Guardrails</h4>
<p><strong>PARAM-01</strong> (y) Any protocol parameter that is not explicitly named in this document <strong>must
not</strong> be changed by a Parameter update governance action.</p>
<p><strong>PARAM-02</strong> (y) Where a protocol parameter is explicitly listed in this document but no<br />
checkable guardrails are specified, the guardrails script <strong>must not</strong> impose any constraints on<br />
changes to the parameter. Checkable guardrails are shown by a (y).</p>
<h3>2.1. Critical Protocol Parameters</h3>
<p>The below protocol parameters are critical from a security point of view.</p>
<p><em>Parameters that are Critical to the Operation of the Blockchain</em></p>
<ul>
<li><em>maximum block body size</em> (<em>maxBlockBodySize</em>)</li>
<li><em>maximum transaction size</em> (<em>maxTxSize</em>)</li>
<li><em>maximum block header size</em> (<em>maxBlockHeaderSize</em>)</li>
<li><em>maximum size of a serialized asset value</em> (<em>maxValueSize</em>)</li>
<li><em>maximum script execution/memory units in a single block</em> (<em>maxBlockExecutionUnits[steps/memory]</em>)</li>
<li><em>minimum fee coefficient</em> (<em>txFeePerByte</em>)</li>
<li><em>minimum fee constant</em> (<em>txFeeFixed</em>)</li>
<li><em>minimum fee per byte for reference scripts</em> (<em>minFeeRefScriptCoinsPerByte</em>)</li>
<li><em>minimum Lovelace deposit per byte of serialized UTxO</em> (<em>utxoCostPerByte</em>)</li>
<li><em>governance action deposit</em> (<em>govDeposit</em>)</li>
</ul>
<h4>Guardrails</h4>
<p><strong>PARAM-03</strong> (y) Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs <strong>must</strong> 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.</p>
<p><strong>PARAM-04</strong> (x) At least 3 months <strong>should</strong> 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.</p>
<p><em>Parameters that are Critical to the Governance System</em></p>
<ul>
<li><em>delegation key Lovelace deposit</em> (<em>stakeAddressDeposit</em>)</li>
<li><em>pool registration Lovelace deposit</em> (<em>stakePoolDeposit</em>)</li>
<li><em>minimum fixed rewards cut for pools</em> (<em>minPoolCost</em>)</li>
<li><em>DRep deposit amount</em> (<em>dRepDeposit</em>)</li>
<li><em>minimal Constitutional Committee size</em> (<em>committeeMinSize</em>)</li>
<li><em>maximum term length (in epochs) for the Constitutional Committee members</em> (<em>committeeMaxTermLimit</em>)</li>
</ul>
<h4>Guardrails</h4>
<p><strong>PARAM-05</strong> (y) DReps <strong>must</strong> 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.</p>
<p><strong>PARAM-06</strong> (x) At least 3 months <strong>should</strong> 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.</p>
<h3>2.2. Economic Parameters</h3>
<p>The overall goals when managing economic parameters are to:</p>
<ol>
<li>Enable long-term economic sustainability for the Cardano Blockchain ecosystem;</li>
<li>Ensure that stake pools are adequately rewarded for maintaining the Cardano Blockchain;</li>
<li>Ensure that ada holders are adequately rewarded for using stake in constructive ways, including when delegating ada for block production; and</li>
<li>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).</li>
</ol>
<p><em>Triggers for Change</em></p>
<ol>
<li>Significant changes in the fiat value of ada resulting in potential problems with security, performance, or functionality.</li>
<li>Changes in transaction volumes or types.</li>
<li>Community requests or suggestions.</li>
<li>Emergency situations that require changes to economic parameters.</li>
</ol>
<p><em>Counter-indicators</em></p>
<p>Changes to the economic parameters should not be made in isolation. They need to account for:</p>
<ul>
<li>External economic factors.</li>
<li>Network security concerns.</li>
</ul>
<p><em>Core Metrics</em></p>
<ul>
<li>Fiat value of ada resulting in potential problems with security, performance, or functionality.</li>
<li>Transaction volumes and types.</li>
<li>Number and health of stake pools.</li>
<li>External economic factors.</li>
</ul>
<p><em>Changes to Specific Economic Parameters</em></p>
<p><strong>Transaction fee per byte (txFeePerByte) and fixed transaction fee (txFeeFixed)</strong></p>
<p>Defines the cost for basic transactions in Lovelace:</p>
<p>fee(tx) = txFeeFixed + txFeePerByte x nBytes(tx)</p>
<h4>Guardrails</h4>
<p><strong>TFPB-01</strong> (y) <em>txFeePerByte</em> <strong>must not</strong> be lower than 30 (0.000030 ada). This protects against low-cost denial of service attacks.</p>
<p><strong>TFPB-02</strong> (y) <em>txFeePerByte</em> <strong>must not</strong> exceed 1,000 (0.001 ada). This ensures that transactions can be paid for.</p>
<p><strong>TFPB-03</strong> (y) <em>txFeePerByte</em> <strong>must not</strong> be negative.</p>
<p><strong>TFF-01</strong> (y) <em>txFeeFixed</em> <strong>must not</strong> be lower than 100,000 (0.1 ada). This protects against low-cost denial of service attacks.</p>
<p><strong>TFF-02</strong> (y) <em>txFeeFixed</em> <strong>must not</strong> exceed 10,000,000 (10 ada). This ensures that transactions can be paid for.</p>
<p><strong>TFF-03</strong> (y) <em>txFeeFixed</em> <strong>must not</strong> be negative.</p>
<p><strong>TFGEN-01</strong> (x - "should") To maintain a consistent level of protection against denial-of-service attacks, <em>txFeeFixed</em> and <em>txFeePerByte</em> <strong>should</strong> be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory]).</p>
<p><strong>TFGEN-02</strong> (x - unquantifiable) Any changes to <em>txFeeFixed</em> or <em>txFeePerByte</em> <strong>must</strong> 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.</p>
<p><em>UTxO cost per byte (utxoCostPerByte)</em></p>
<p>Defines the cost for storage in UTxOs:</p>
<ul>
<li>Sets a minimum threshold on ada that is held within a single UTxO (~1 ada minimum, could be >= 50 ada in the worst case).</li>
<li>Provides protection against low-cost denial of service attack on UTxO storage. This attack has been executed on other chains; it is not theoretical.</li>
<li>DoS protection decreases in line with the free node memory (proportional to UTxO growth).</li>
<li>Helps reduce long-term storage costs.</li>
<li>Provides an incentive to return UTxOs when no longer needed.</li>
<li>Should significantly exceed minimum tx cost (~0.15 ada).</li>
</ul>
<h4>Guardrails</h4>
<p><strong>UCPB-01</strong> (y) <em>utxoCostPerByte</em> <strong>must not</strong> be lower than 3,000 (0.003 ada).</p>
<p><strong>UCPB-02</strong> (y) <em>utxoCostPerByte</em> <strong>must not</strong> exceed 6,500 (0.0065 ada).</p>
<p><strong>UCPB-03</strong> (y) <em>utxoCostPerByte</em> <strong>must not</strong> be zero.</p>
<p><strong>UCPB-04</strong> (y) <em>utxoCostPerByte</em> <strong>must not</strong> be negative.</p>
<p><strong>UCPB-05</strong> (x - "should") Changes <strong>should</strong> account for:</p>
<p>i) The acceptable cost of attack.<br />
ii) The acceptable time for an attack (at least one epoch is assumed).<br />
iii) The acceptable memory configuration for full node users (assumed to be 16GB for wallets or 24GB for stake pools).<br />
iv) The sizes of UTxOs (~200B per UTxO minimum, up to about 10KB).<br />
v) The current total node memory usage.</p>
<p><em>Stake address deposit (stakeAddressDeposit)</em></p>
<p>Ensures that stake addresses are retired when no longer needed:</p>
<ul>
<li>Helps reduce long-term storage costs.</li>
<li>Helps limit CPU and memory costs in the ledger.</li>
</ul>
<p>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.</p>
<h4>Guardrails</h4>
<p><strong>SAD-01</strong> (y) <em>stakeAddressDeposit</em> <strong>must not</strong> be lower than 1,000,000 (1 ada).</p>
<p><strong>SAD-02</strong> (y) <em>stakeAddressDeposit</em> <strong>must not</strong> exceed 5,000,000 (5 ada).</p>
<p><strong>SAD-03</strong> (y) <em>stakeAddressDeposit</em> <strong>must not</strong> be negative.</p>
<p><em>Stake pool deposit (stakePoolDeposit)</em></p>
<p>Ensures that stake pools are retired by the stake pool operator when no longer needed by them:</p>
<ul>
<li>Helps reduce long-term storage costs.</li>
</ul>
<p>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.</p>
<h4>Guardrails</h4>
<p><strong>SPD-01</strong> (y) <em>stakePoolDeposit</em> <strong>must not</strong> be lower than 250,000,000 (250 ada).</p>
<p><strong>SPD-02</strong> (y) <em>stakePoolDeposit</em> <strong>must not</strong> exceed 500,000,000 (500 ada).</p>
<p><strong>SPD-03</strong> (y) <em>stakePoolDeposit</em> <strong>must not</strong> be negative.</p>
<p><em>Minimum Pool Cost (minPoolCost)</em></p>
<p>Part of the rewards mechanism:</p>
<ul>
<li>The minimum pool cost is transferred to the pool rewards address before any delegator rewards are paid.</li>
</ul>
<h4>Guardrails</h4>
<p><strong>MPC-01</strong> (y) <em>minPoolCost</em> <strong>must not</strong> be negative.</p>
<p><strong>MPC-02</strong> (y) <em>minPoolCost</em> <strong>must not</strong> exceed 500,000,000 (500 ada).</p>
<p><strong>MPC-03</strong> (x - "should") <em>minPoolCost</em> <strong>should</strong> be set in line with the economic cost for operating a pool.</p>
<p>_<em>Treasury Cut (treasuryCut)</em></p>
<p>Part of the rewards mechanism:</p>
<ul>
<li>The treasury cut portion of the monetary expansion is transferred to the treasury before any pool rewards are paid.</li>
<li>Can be set in the range 0.0-1.0 (0%-100%).</li>
</ul>
<h4>Guardrails</h4>
<p><strong>TC-01</strong> (y) <em>treasuryCut</em> <strong>must not</strong> be lower than 0.1 (10%).</p>
<p><strong>TC-02</strong> (y) <em>treasuryCut</em> <strong>must not</strong> exceed 0.3 (30%).</p>
<p><strong>TC-03</strong> (y) <em>treasuryCut</em> <strong>must not</strong> be negative.</p>
<p><strong>TC-04</strong> (y) <em>treasuryCut</em> <strong>must not</strong> exceed 1.0 (100%).</p>
<p><strong>TC-05</strong> (~ - no access to change history) <em>treasuryCut</em> <strong>must not</strong> be changed more than once in any 36-epoch period (approximately 6 months).</p>
<p><em>Monetary Expansion Rate (monetaryExpansion)</em></p>
<p>Part of the rewards mechanism:</p>
<ul>
<li>The monetary expansion controls the amount of reserves that is used for rewards each epoch.</li>
<li>Governs the long-term sustainability of Cardano.</li>
<li>The reserves are gradually depleted until no rewards are supplied.</li>
</ul>
<h4>Guardrails</h4>
<p><strong>ME-01</strong> (y) <em>monetaryExpansion</em> <strong>must not</strong> exceed 0.</p>
<p><strong>ME-02</strong> (y) <em>monetaryExpansion</em> <strong>must not</strong> be lower than 0.</p>
<p><strong>ME-03</strong> (y) <em>monetaryExpansion</em> <strong>must not</strong> be negative.</p>
<p><strong>ME-04</strong> (x - "should") <em>monetaryExpansion</em> <strong>should not</strong> be varied by more than +/- 10% in any 73-epoch period (approximately 12 months).</p>
<p><strong>ME-05</strong> (x - "should") <em>monetaryExpansion</em> <strong>should not</strong> be changed more than once in any 36-epoch period (approximately 6 months).</p>
<p><em>Plutus Script Execution Prices (executionUnitPrices[priceSteps/priceMemory])</em></p>
<p>Defines the fees for executing Plutus scripts:</p>
<ul>
<li>Gives an economic return for Plutus script execution.</li>
<li>Provides security against low-cost DoS attacks.</li>
</ul>
<h4>Guardrails</h4>
<p><strong>EIUP-PS-01</strong> (y) <em>executionUnitPrices[priceSteps]</em> <strong>must not</strong> exceed 2,000 / 10,000,000.</p>
<p><strong>EIUP-PS-02</strong> (y) <em>executionUnitPrices[priceSteps]</em> <strong>must not</strong> be lower than 500 / 10,000,000.</p>
<p><strong>EIUP-PM-01</strong> (y) <em>executionUnitPrices[priceMemory]</em> <strong>must not</strong> exceed 2,000 / 10,000.</p>
<p><strong>EIUP-PM-02</strong> (y) <em>executionUnitPrices[priceMemory]</em> <strong>must not</strong> be lower than 400 / 10,000.</p>
<p><strong>EIUP-GEN-01</strong> (x - "similar to") The execution prices <strong>must</strong> be set so that:</p>
<ul>
<li>i) the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum-sized non-script transaction and</li>
<li>ii) the cost of executing a transaction with maximum memory units is similar to the cost of a maximum-sized non-script transaction.</li>
</ul>
<p><strong>EIUP-GEN-02</strong> (x - "should") The execution prices <strong>should</strong> be adjusted whenever transaction fees are adjusted (<em>txFeeFixed/txFeePerByte</em>). The goal is to ensure that the processing delay is similar for "full" transactions, regardless of their type.</p>
<ul>
<li>This helps ensure that the requirements on block diffusion/propagation times are met.</li>
</ul>
<p><em>Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte)</em></p>
<p>Defines the cost for using Plutus reference scripts in Lovelace.</p>
<h4>Guardrails</h4>
<p><strong>MFRS-01</strong> (y) <em>minFeeRefScriptCoinsPerByte</em> <strong>must not</strong> exceed 1,000 (0.001 ada).</p>
<ul>
<li>This ensures that transactions can be paid for.</li>
</ul>
<p><strong>MFRS-02</strong> (y) <em>minFeeRefScriptCoinsPerByte</em> <strong>must not</strong> be negative.</p>
<p><strong>MFRS-03</strong> (x - "should") To maintain a consistent level of protection against denial-of-service attacks, <em>minFeeRefScriptCoinsPerByte</em> <strong>should</strong> be adjusted whenever Plutus Execution prices are adjusted (<em>executionUnitPrices[steps/memory]</em>) and whenever <em>txFeeFixed</em> is adjusted.</p>
<p><strong>MFRS-04</strong> (x - unquantifiable) Any changes to <em>minFeeRefScriptCoinsPerByte</em> <strong>must</strong> consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee.</p>
<h3>2.3. Network Parameters</h3>
<p>The overall goals when managing the Cardano Blockchain network parameters are to:</p>
<ol>
<li>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.</li>
<li>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.</li>
</ol>
<p><em>Triggers for Change</em></p>
<p>Changes to network parameters may be triggered by:</p>
<ol>
<li>Measured changes in traffic demands over a 2-epoch period (10 days).</li>
<li>Anticipated changes in traffic demands.</li>
<li>Community requests.</li>
</ol>
<p><em>Counter-indicators</em></p>
<p>Changes may need to be reversed and/or should not be enacted in the event of:</p>
<ul>
<li>Excessive block propagation delays.</li>
<li>Stake pools being unable to handle traffic volume.</li>
<li>Scripts being unable to complete execution.</li>
</ul>
<p><em>Core Metrics</em></p>
<p>All decisions on parameter changes should be informed by:</p>
<ul>
<li>Block propagation delay profile.</li>
<li>Traffic volume (block size over time).</li>
<li>Script volume (size of scripts and execution units).</li>
<li>Script execution cost benchmarks.</li>
<li>Block propagation delay/diffusion benchmarks.</li>
</ul>
<p>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.</p>
<h4>Guardrails</h4>
<p><strong>NETWORK-01</strong> (x - "should") No individual network parameter <strong>should</strong> change more than once per two epochs.</p>
<p><strong>NETWORK-02</strong> (x - "should") Only one network parameter <strong>should</strong> be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits.</p>
<p><em>Changes to Specific Network Parameters</em></p>
<p><em>Block Size (maxBlockBodySize)</em></p>
<p>The maximum size of a block, in Bytes.</p>
<h4>Guardrails</h4>
<p><strong>MBBS-01</strong> (y) <em>maxBlockBodySize</em> <strong>must not</strong> exceed 122,880 Bytes (120KB).</p>
<p><strong>MBBS-02</strong> (y) <em>maxBlockBodySize</em> <strong>must not</strong> be lower than 24,576 Bytes (24KB).</p>
<p><strong>MBBS-03</strong> (x - "exceptional circumstances") <em>maxBlockBodySize</em> <strong>must not</strong> be decreased, other than in exceptional circumstances where there are potential problems with security, performance, or functionality.</p>
<p><strong>MBBS-04</strong> (~ - no access to existing parameter values) <em>maxBlockBodySize</em> <strong>must</strong> be large enough to include at least one transaction (that is, <em>maxBlockBodySize</em> <strong>must</strong> be at least <em>maxTxSize</em>).</p>
<p><strong>MBBS-05</strong> (x - "should") <em>maxBlockBodySize</em> <strong>should</strong> be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch.</p>
<p><strong>MBBS-06</strong> (x - "should") The block size <strong>should not</strong> induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation, and benchmarking.</p>
<p><strong>MBBS-07</strong> (x - "unquantifiable") The impact of any change to <em>maxBlockBodySize</em> <strong>must</strong> be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to <em>maxBlockBodySize</em> must also consider future requirements for Plutus script execution (<em>maxBlockExecutionUnits[steps]</em>) 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.</p>
<p><em>Transaction Size (maxTxSize)</em></p>
<p>The maximum size of a transaction, in Bytes.</p>
<h4>Guardrails</h4>
<p><strong>MTS-01</strong> (y) <em>maxTxSize</em> <strong>must not</strong> exceed 32,768 Bytes (32KB).</p>
<p><strong>MTS-02</strong> (y) <em>maxTxSize</em> <strong>must not</strong> be negative.</p>
<p><strong>MTS-03</strong> (~ - no access to existing parameter values) <em>maxTxSize</em> <strong>must not</strong> be decreased.</p>
<p><strong>MTS-04</strong> (~ - no access to existing parameter values) <em>maxTxSize</em> <strong>must not</strong> exceed <em>maxBlockBodySize</em>.</p>
<p><strong>MTS-05</strong> (x - "should") <em>maxTxSize</em> <strong>should not</strong> be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably <strong>should</strong> be increased by 2,048 Bytes (2KB) or less per epoch.</p>
<p><strong>MTS-06</strong> (x - "should") <em>maxTxSize</em> <strong>should not</strong> exceed 1/4 of the block size.</p>
<p><em>Memory Unit Limits (maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory])</em></p>
<p>The limit on the maximum number of memory units that can be used by Plutus scripts, either per-transaction or per-block.</p>
<h4>Guardrails</h4>
<p><strong>MTEU-M-01</strong> (y) <em>maxTxExecutionUnits[memory]</em> <strong>must not</strong> exceed 40,000,000 units.</p>
<p><strong>MTEU-M-02</strong> (y) <em>maxTxExecutionUnits[memory]</em> <strong>must not</strong> be negative.</p>
<p><strong>MTEU-M-03</strong> (~ - no access to existing parameter values) <em>maxTxExecutionUnits[memory]</em> <strong>must not</strong> be decreased.</p>
<p><strong>MTEU-M-04</strong> (x - "should") <em>maxTxExecutionUnits[memory]</em> <strong>should not</strong> be increased by more than 2,500,000 units in any epoch.</p>
<p><strong>MBEU-M-01</strong> (y) <em>maxBlockExecutionUnits[memory]</em> <strong>must not</strong> exceed 120,000,000 units.</p>
<p><strong>MBEU-M-02</strong> (y) <em>maxBlockExecutionUnits[memory]</em> <strong>must not</strong> be negative.</p>
<p><strong>MBEU-M-03</strong> (x - "should") <em>maxBlockExecutionUnits[memory]</em> <strong>should not</strong> be changed (increased or decreased) by more than 10,000,000 units in any epoch.</p>
<p><strong>MBEU-M-04</strong> (x - unquantifiable) The impact of any change to <em>maxBlockExecutionUnits[memory]</em> <strong>must</strong> be confirmed by detailed benchmarking/simulation and not exceed the requirements of the diffusion/propagation time budgets, as also impacted by <em>maxBlockExecutionUnits[steps]</em>. Any increase <strong>must</strong> also consider previously agreed future requirements for the total block size (<em>maxBlockBodySize</em>) 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.</p>
<p><strong>MEU-M-01</strong> (~ - no access to existing parameter values) <em>maxBlockExecutionUnits[memory]</em> <strong>must not</strong> be less than <em>maxTxExecutionUnits[memory]</em>.</p>
<p><em>CPU Unit Limits (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps])</em></p>
<p>The limit on the maximum number of CPU steps that can be used by Plutus scripts, either per-transaction or per-block.</p>
<h4>Guardrails</h4>
<p><strong>MTEU-S-01</strong> (y) <em>maxTxExecutionUnits[steps]</em> <strong>must not</strong> exceed 15,000,000,000 (15Bn) units.</p>
<p><strong>MTEU-S-02</strong> (y) <em>maxTxExecutionUnits[steps]</em> <strong>must not</strong> be negative.</p>
<p><strong>MTEU-S-03</strong> (~ - no access to existing parameter values) <em>maxTxExecutionUnits[steps]</em> <strong>must not</strong> be decreased.</p>
<p><strong>MTEU-S-04</strong> (x - "should") <em>maxTxExecutionUnits[steps]</em> <strong>should not</strong> be increased by more than 500,000,000 (500M) units in any epoch (5 days).</p>
<p><strong>MBEU-S-01</strong> (y) <em>maxBlockExecutionUnits[steps]</em> <strong>must not</strong> exceed 40,000,000,000 (40Bn) units.</p>
<p><strong>MBEU-S-02</strong> (y) <em>maxBlockExecutionUnits[steps]</em> <strong>must not</strong> be negative.</p>
<p><strong>MBEU-S-03</strong> (x - "should") <em>maxBlockExecutionUnits[steps]</em> <strong>should not</strong> be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days).</p>
<p><strong>MBEU-S-04</strong> (x - unquantifiable) The impact of the change to <em>maxBlockExecutionUnits[steps]</em> <strong>must</strong> be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by <em>maxBlockExecutionUnits[memory]</em>. Any increase <strong>must</strong> also consider previously identified future requirements for the total block size (<em>maxBlockBodySize</em>) 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 <strong>must</strong> be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements.</p>
<p><strong>MEU-S-01</strong> (~ - no access to existing parameter values) <em>maxBlockExecutionUnits[steps]</em> <strong>must not</strong> be less than <em>maxTxExecutionUnits[steps]</em>.</p>
<p><em>Block Header Size (maxBlockHeaderSize)</em></p>
<p>The size of the block header.</p>
<p><strong>Note:</strong> Increasing the block header size may affect the overall block size (<em>maxBlockBodySize</em>).</p>
<h4>Guardrails</h4>
<p><strong>MBHS-01</strong> (y) <em>maxBlockHeaderSize</em> <strong>must not</strong> exceed 5,000 Bytes.</p>
<p><strong>MBHS-02</strong> (y) <em>maxBlockHeaderSize</em> <strong>must not</strong> be negative.</p>
<p><strong>MBHS-03</strong> (x - "largest valid header" is subject to change) <em>maxBlockHeaderSize</em> <strong>must</strong> be large enough for the largest valid header.</p>
<p><strong>MBHS-04</strong> (x - "should") <em>maxBlockHeaderSize</em> <strong>should</strong> only normally be increased if the protocol changes.</p>
<p><strong>MBHS-05</strong> (x - "should") <em>maxBlockHeaderSize</em> <strong>should</strong> be within TCP's initial congestion window (3 or 10 MTUs).</p>
<h3>2.4. Technical/Security Parameters</h3>
<p>The overall goals when managing the technical/security parameters are:</p>
<ol>
<li>Ensure the security of the Cardano network in terms of decentralization, protection against Sybil and 51% attacks, and protection against denial of service attacks.</li>
<li>Enable changes to the Plutus language.</li>
</ol>
<p><em>Triggers for Change</em></p>
<ol>
<li>Changes in the number of active SPOs.</li>
<li>Changes to the Plutus language.</li>
<li>Security threats.</li>
<li>Community requests.</li>
</ol>
<p><em>Counter-indicators</em></p>
<ul>
<li>Economic concerns, e.g., when changing the number of stake pools.</li>
</ul>
<p><em>Core Metrics</em></p>
<ul>
<li>Number of stake pools.</li>
<li>Level of decentralization.</li>
</ul>
<p><em>Changes to Specific Technical/Security Parameters</em></p>
<p><em>Target Number of Stake Pools (stakePoolTargetNum)</em></p>
<p>Sets the target number of stake pools:</p>
<ul>
<li>The expected number of pools when the network is in the equilibrium state.</li>
<li>Primarily a security parameter, ensuring decentralization by pool division/replication.</li>
<li>Has an economic effect as well as a security effect; economic advice is also required when changing this parameter.</li>
<li>Large changes in this parameter will trigger mass redelegation events.</li>
</ul>
<h4>Guardrails</h4>
<p><strong>SPTN-01</strong> (y) <em>stakePoolTargetNum</em> <strong>must not</strong> be lower than 250.</p>
<p><strong>SPTN-02</strong> (y) <em>stakePoolTargetNum</em> <strong>must not</strong> exceed 2,000.</p>
<p><strong>SPTN-03</strong> (y) <em>stakePoolTargetNum</em> <strong>must not</strong> be negative.</p>
<p><strong>SPTN-04</strong> (y) <em>stakePoolTargetNum</em> <strong>must not</strong> be zero.</p>
<p><em>Pledge Influence Factor (poolPledgeInfluence)</em></p>
<p>Enables the pledge protection mechanism:</p>
<ul>
<li>Provides protection against Sybil attack.</li>
<li>Higher values reward pools that have more pledge and penalize pools that have less pledge.</li>
<li>Has an economic effect as well as technical effect; economic advice is also required.</li>
<li>Can be set in the range 0.0-infinity.</li>
</ul>
<h4>Guardrails</h4>
<p><strong>PPI-01</strong> (y) <em>poolPledgeInfluence</em> <strong>must not</strong> be lower than 0.1.</p>
<p><strong>PPI-02</strong> (y) <em>poolPledgeInfluence</em> <strong>must not</strong> exceed 1.0.</p>
<p><strong>PPI-03</strong> (y) <em>poolPledgeInfluence</em> <strong>must not</strong> be negative.</p>
<p><strong>PPI-04</strong> (x - "should") <em>poolPledgeInfluence</em> <strong>should not</strong> vary by more than +/- 10% in any 18-epoch period (approximately 3 months).</p>
<p><em>Pool Retirement Window (poolRetireMaxEpoch)</em></p>
<p>Defines the maximum number of epochs notice that a pool can give when planning to retire.</p>
<h4>Guardrails</h4>
<p><strong>PRME-01</strong> (y) <em>poolRetireMaxEpoch</em> <strong>must not</strong> be negative.</p>
<p><strong>PRME-02</strong> (x - "should") <em>poolRetireMaxEpoch</em> <strong>should not</strong> be lower than 1.</p>
<p><em>Collateral Percentage (collateralPercentage)</em></p>
<p>Defines how much collateral must be provided when executing a Plutus script as a percentage of the normal execution cost:</p>
<ul>
<li>Collateral is additional to fee payments.</li>
<li>If a script fails to execute, then the collateral is lost.</li>
<li>The collateral is never lost if a script executes successfully.</li>
<li>Provides security against low-cost attacks by making it more expensive rather than less expensive to execute failed scripts.</li>
</ul>
<h4>Guardrails</h4>
<p><strong>CP-01</strong> (y) <em>collateralPercentage</em> <strong>must not</strong> be lower than 100.</p>
<p><strong>CP-02</strong> (y) <em>collateralPercentage</em> <strong>must not</strong> exceed 200.</p>
<p><strong>CP-03</strong> (y) <em>collateralPercentage</em> <strong>must not</strong> be negative.</p>
<p><strong>CP-04</strong> (y) <em>collateralPercentage</em> <strong>must not</strong> be zero.</p>
<p><em>Maximum number of collateral inputs (maxCollateralInputs)</em></p>
<p>Defines the maximum number of inputs that can be used for collateral when executing a Plutus script.</p>
<h4>Guardrails</h4>
<p><strong>MCI-01</strong> (y) <em>maxCollateralInputs</em> <strong>must not</strong> be lower than 1.</p>
<p>The limit on the serialized size of the Value in each output.</p>
<h4>Guardrails</h4>
<p><strong>MVS-01</strong> (y) <em>maxValueSize</em> <strong>must not</strong> exceed 12,288 Bytes (12KB).</p>
<p><strong>MVS-02</strong> (y) <em>maxValueSize</em> <strong>must not</strong> be negative.</p>
<p><strong>MVS-03</strong> (~ - no access to existing parameter values) <em>maxValueSize</em> <strong>must</strong> be less than <em>maxTxSize</em>.</p>
<p><strong>MVS-04</strong> (~ - no access to existing parameter values) <em>maxValueSize</em> <strong>must not</strong> be reduced.</p>
<p><strong>MVS-05</strong> (x - "sensible output" is subject to interpretation) <em>maxValueSize</em> <strong>must</strong> 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).</p>
<p><em>Plutus Cost Models (costModels)</em></p>
<p>Defines the base costs for each Plutus primitive in terms of CPU and memory units:</p>
<ul>
<li>There are about 150 distinct micro-parameters in total.</li>
<li>Cost models are defined for each Plutus language version. A new language version may introduce additional micro-parameters or remove existing micro-parameters.</li>
</ul>
<h4>Guardrails</h4>
<p><strong>PCM-01</strong> (x - unquantifiable) <em>Cost model</em> values <strong>must</strong> be set by benchmarking on a reference architecture.</p>
<p><strong>PCM-02</strong> (x - primitives and language versions aren't introduced in transactions) The <em>cost model</em> <strong>must</strong> be updated if new primitives are introduced or a new Plutus language version is added.</p>
<p><strong>PCM-03</strong> (~ - no access to <em>Plutus cost model</em> parameters) <em>Cost model</em> values <strong>should not</strong> be negative.</p>
<p><strong>PCM-04</strong> (~ - no access to <em>Plutus cost model</em> parameters) A <em>cost model</em> <strong>must</strong> be supplied for each Plutus language version that the protocol supports.</p>
<h3>2.5. Governance Parameters</h3>
<p>The overall goals when managing the governance parameters are to:</p>
<ol>
<li>Ensure governance stability.</li>
<li>Maintain a representative form of governance as outlined in CIP-1694.</li>
</ol>
<p><em>Triggers for Change</em></p>
<p>Changes to governance parameters may be triggered by:</p>
<ol>
<li>Community requests.</li>
<li>Regulatory requirements.</li>
<li>Unexpected or unwanted governance outcomes.</li>
<li>Entering a state of no confidence.</li>
</ol>
<p><em>Counter-indicators</em></p>
<p>Changes may need to be reversed and/or should not be enacted in the event of:</p>
<ul>
<li>Unexpected effects on governance.</li>
<li>Excessive Layer 1 load due to on-chain voting or excessive numbers of governance actions.</li>
</ul>
<p><em>Core Metrics</em></p>
<p>All decisions on parameter changes should be informed by:</p>
<ul>
<li>Governance participation levels.</li>
<li>Governance behaviors and patterns.</li>
<li>Regulatory considerations.</li>
<li>Confidence in the governance system.</li>
<li>The effectiveness of the governance system in managing necessary change.</li>
</ul>
<p><em>Changes to Specific Governance Parameters</em></p>
<p><em>Deposit for Governance Actions (govDeposit)</em></p>
<p>The deposit that is charged when submitting a governance action:</p>
<ul>
<li>Helps to limit the number of actions that are submitted.</li>
</ul>
<h4>Guardrails</h4>
<p><strong>GD-01</strong> (y) <em>govDeposit</em> <strong>must not</strong> be negative.</p>
<p><strong>GD-02</strong> (y) <em>govDeposit</em> <strong>must not</strong> be lower than 1,000,000 (1 ada).</p>
<p><strong>GD-03</strong> (y) <em>govDeposit</em> <strong>must not</strong> exceed 10,000,000,000,000 (10 million ada).</p>
<p><strong>GD-04</strong> (x - "should") <em>govDeposit</em> <strong>should</strong> be adjusted in line with fiat changes.</p>
<p><em>Deposit for DReps (dRepDeposit)</em></p>
<p>The deposit that is charged when registering a DRep:</p>
<ul>
<li>Helps to limit the number of active DReps.</li>
</ul>
<h4>Guardrails</h4>
<p><strong>DRD-01</strong> (y) <em>dRepDeposit</em> <strong>must not</strong> be negative.</p>
<p><strong>DRD-02</strong> (y) <em>dRepDeposit</em> <strong>must not</strong> be lower than 1,000,000 (1 ada).</p>
<p><strong>DRD-03</strong> (y) <em>dRepDeposit</em> <strong>must not</strong> exceed 100,000,000,000 (100,000 ada).</p>
<p><strong>DRD-04</strong> (x - "should") <em>dRepDeposit</em> <strong>should</strong> be adjusted in line with fiat changes.</p>
<p><em>DRep Activity Period (dRepActivity)</em></p>
<p>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.</p>
<h4>Guardrails</h4>
<p><strong>DRA-01</strong> (y) <em>dRepActivity</em> <strong>must not</strong> be lower than 13 epochs (2 months).</p>
<p><strong>DRA-02</strong> (y) <em>dRepActivity</em> <strong>must not</strong> exceed 37 epochs (6 months).</p>
<p><strong>DRA-03</strong> (y) <em>dRepActivity</em> <strong>must not</strong> be negative.</p>
<p><strong>DRA-04</strong> (~ - no access to existing parameter values) <em>dRepActivity</em> <strong>must</strong> be greater than <em>govActionLifetime</em>.</p>
<p><strong>DRA-05</strong> (x - "should") <em>dRepActivity</em> <strong>should</strong> be calculated in human terms (2 months, etc.).</p>
<p><em>DRep and SPO Governance Action Thresholds (dRepVotingThresholds[…], poolVotingThresholds[…])</em></p>
<p>Thresholds on the active voting stake that is required to ratify a specific type of governance action by either DReps or SPOs:</p>
<ul>
<li>Ensures legitimacy of the action.</li>
</ul>
<p>The threshold parameters are listed below:</p>
<p><strong>dRepVotingThresholds</strong>:</p>
<ul>
<li><em>dvtCommitteeNoConfidence</em></li>
<li><em>dvtCommitteeNormal</em></li>
<li><em>dvtHardForkInitiation</em></li>
<li><em>dvtMotionNoConfidence</em></li>
<li><em>dvtPPEconomicGroup</em></li>
<li><em>dvtPPGovGroup</em></li>
<li><em>dvtPPNetworkGroup</em></li>
<li><em>dvtPPTechnicalGroup</em></li>
<li><em>dvtTreasuryWithdrawal</em></li>
<li><em>dvtUpdateToConstitution</em></li>
</ul>
<p><strong>poolVotingThresholds</strong>:</p>
<ul>
<li><em>pvtCommitteeNoConfidence</em></li>
<li><em>pvtCommitteeNormal</em></li>
<li><em>pvtHardForkInitiation</em></li>
<li><em>pvtMotionNoConfidence</em></li>
<li><em>pvtPPSecurityGroup</em></li>
</ul>
<h4>Guardrails</h4>
<p><strong>VT-GEN-01</strong> (y) All thresholds <strong>must</strong> be greater than 50% and less than or equal to 100%.</p>
<p><strong>VT-GEN-02</strong> (y) Economic, network, and technical parameter thresholds <strong>must</strong> be in the range 51%-75%.</p>
<p><strong>VT-GEN-03</strong> (y) Governance parameter thresholds <strong>must</strong> be in the range 75%-90%.</p>
<p><strong>VT-HF-01</strong> (y) <strong>Hard fork</strong> action thresholds <strong>must</strong> be in the range 51%-80%.</p>
<p><strong>VT-CON-01</strong> (y) <strong>New Constitution or guardrails script action</strong> thresholds <strong>must</strong> be in the range 65%-90%.</p>
<p><strong>VT-CC-01</strong> (y) <strong>Update Constitutional Committee action</strong> thresholds <strong>must</strong> be in the range 51%-90%.</p>
<p><strong>VT-NC-01</strong> (y) <strong>No confidence</strong> action thresholds <strong>must</strong> be in the range 51%-75%.</p>
<p><em>Governance Action Lifetime (govActionLifetime)</em></p>
<p>The period after which a governance action will expire if it is not enacted:</p>
<ul>
<li>As a whole number of epochs.</li>
</ul>
<h4>Guardrails</h4>
<p><strong>GAL-01</strong> (y) <em>govActionLifetime</em> <strong>must not</strong> be lower than 1 epoch (5 days).</p>
<p><strong>GAL-03</strong> (x - "should") <em>govActionLifetime</em> <strong>should not</strong> be lower than 2 epochs (10 days).</p>
<p><strong>GAL-02</strong> (y) <em>govActionLifetime</em> <strong>must not</strong> exceed 15 epochs (75 days).</p>
<p><strong>GAL-04</strong> (x - "should") <em>govActionLifetime</em> <strong>should</strong> be calibrated in human terms (e.g., 30 days, two weeks) to allow sufficient time for voting, etc., to take place.</p>
<p><strong>GAL-05</strong> (~ - no access to existing parameter values) <em>govActionLifetime</em> <strong>must</strong> be less than <em>dRepActivity</em>.</p>
<p><em>Maximum Constitutional Committee Term (committeeMaxTermLimit)</em></p>
<p>The limit on the maximum term that a committee member may serve.</p>
<h4>Guardrails</h4>
<p><strong>CMTL-01</strong> (y) <em>committeeMaxTermLimit</em> <strong>must not</strong> be zero.</p>
<p><strong>CMTL-02</strong> (y) <em>committeeMaxTermLimit</em> <strong>must not</strong> be negative.</p>
<p><strong>CMTL-03</strong> (y) <em>committeeMaxTermLimit</em> <strong>must not</strong> be lower than 18 epochs (90 days, or approximately 3 months).</p>
<p><strong>CMTL-04</strong> (y) <em>committeeMaxTermLimit</em> <strong>must not</strong> exceed 293 epochs (approximately 4 years).</p>
<p><strong>CMTL-05</strong> (x - "should") <em>committeeMaxTermLimit</em> <strong>should not</strong> exceed 220 epochs (approximately 3 years).</p>
<p><em>The minimum size of the Constitutional Committee (committeeMinSize)</em></p>
<p>The least number of members that can be included in a Constitutional Committee following a governance action to change the Constitutional Committee.</p>
<h4>Guardrails</h4>
<p><strong>CMS-01</strong> (y) <em>committeeMinSize</em> <strong>must not</strong> be negative.</p>
<p><strong>CMS-02</strong> (y) <em>committeeMinSize</em> <strong>must not</strong> be lower than 3.</p>
<p><strong>CMS-03</strong> (y) <em>committeeMinSize</em> <strong>must not</strong> exceed 10.</p>
<h3>2.6. Monitoring and Reversion of Parameter Changes</h3>
<p>All network parameter changes <strong>must</strong> be monitored carefully for no less than 2 epochs (10 days):</p>
<ul>
<li>Changes <strong>must</strong> 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.</li>
</ul>
<p>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.</p>
<p>A specific reversion/recovery plan <strong>must be</strong> produced for each parameter change. This plan must include:</p>
<ul>
<li>Which parameters need to change and in which ways in order to return to the previous state (or a similar state).</li>
<li>How to recover the network in the event of a disastrous failure.</li>
</ul>
<p>This plan <strong>should</strong> 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.</p>
<h3>2.7. Non-Updatable Protocol Parameters</h3>
<p>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.</p>
<h3>3. GUARDRAILS AND GUIDELINES ON TREASURY WITHDRAWAL ACTIONS</h3>
<p><strong>Treasury withdrawal</strong> actions specify the destination and amount of a number of withdrawals from the Cardano treasury.</p>
<h4>Guardrails</h4>
<p><strong>TREASURY-01</strong> (x) DReps <strong>must</strong> define a net change limit for the Cardano Treasury's balance per period of time.</p>
<p><strong>TREASURY-02</strong> (x) The budget for the Cardano Treasury <strong>must not</strong> exceed the net change limit for the Cardano Treasury's balance per period of time.</p>
<p><strong>TREASURY-03</strong> (x) The budget for the Cardano Treasury <strong>must</strong> be denominated in ada.</p>
<p><strong>TREASURY-04</strong> (x) Treasury withdrawals <strong>must not</strong> 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.</p>
<h3>4. GUARDRAILS AND GUIDELINES ON HARD FORK INITIATION ACTIONS</h3>
<p>The <strong>hard fork initiation</strong> action requires both a new major and a new minor protocol version to be specified:</p>
<ul>
<li>As positive integers.</li>
</ul>
<p>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.</p>
<h4>Guardrails</h4>
<p><strong>HARDFORK-01</strong> (~ - no access to existing parameter values) The major protocol version <strong>must</strong> 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 <strong>must</strong> be zero.</p>
<p><strong>HARDFORK-02</strong> (~ - no access to existing parameter values) The minor protocol version <strong>must</strong> be no less than the minor version that will be enacted immediately prior to this change.</p>
<p><strong>HARDFORK-03</strong> (~ - no access to existing parameter values) At least one of the protocol versions (major or minor or both) <strong>must</strong> change.</p>
<p><strong>HARDFORK-04</strong> (x) At least 85% of stake pools by active stake <strong>should</strong> have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version.</p>
<p><strong>HARDFORK-05</strong> (x) Any new updatable protocol parameters that are introduced with a hard fork <strong>must</strong> be included in this Appendix and suitable guardrails defined for those parameters.</p>
<p><strong>HARDFORK-06</strong> (x) Settings for any new protocol parameters that are introduced with a hard fork <strong>must</strong> be included in the appropriate Genesis file.</p>
<p><strong>HARDFORK-07</strong> (x) Any deprecated protocol parameters <strong>must</strong> be indicated in this Appendix.</p>
<p><strong>HARDFORK-08</strong> (~ - no access to <em>Plutus cost model</em> parameters) New Plutus versions <strong>must</strong> be supported by a version-specific <em>Plutus cost model</em> that covers each primitive that is available in the new Plutus version.</p>
<h3>5. GUARDRAILS AND GUIDELINES ON UPDATE CONSTITUTIONAL COMMITTEE OR THRESHOLD ACTIONS</h3>
<p><strong>Update Constitutional Committee or Threshold</strong> governance actions may change the size, composition, or required voting thresholds for the Constitutional Committee.</p>
<h4>Guardrails</h4>
<p><strong>UPDATE-CC-01</strong> (x) <strong>Update Constitutional Committee and/or threshold</strong> <strong>and/or term</strong> governance actions <strong>must not</strong> be ratified until ada holders have ratified through an on-chain governance action the Final Constitution.</p>
<h3>6. GUARDRAILS AND GUIDELINES ON NEW CONSTITUTION OR GUARDRAILS SCRIPT ACTIONS</h3>
<p>New constitution or guardrails script actions change the hash of the on-chain constitution and the associated guardrails script.</p>
<h4>Guardrails</h4>
<p><strong>NEW-CONSTITUTION-01</strong> (x) A <strong>New Constitution</strong> <strong>or Guardrails Script</strong> governance action <strong>must</strong> be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action.</p>
<h3>7. GUARDRAILS AND GUIDELINES ON NO CONFIDENCE ACTIONS</h3>
<p><strong>No confidence</strong> actions signal a state of no confidence in the governance system. No guardrails are imposed on <strong>No Confidence</strong> actions.</p>
<h4>Guardrails</h4>
<ul>
<li>None</li>
</ul>
<h3>8. GUARDRAILS AND GUIDELINES ON INFO ACTIONS</h3>
<p><strong>Info</strong> actions are not enacted on-chain. No guardrails are imposed on <strong>Info</strong> actions.</p>
<h4>Guardrails</h4>
<ul>
<li>None</li>
</ul>
<h3>9. GUARDRAILS DURING THE INTERIM PERIOD</h3>
<p><em>Interim Period</em></p>
<p>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.</p>
<p><em>Interim Period Technical Rollout:</em></p>
<ul>
<li>The Chang Hard Fork will enable three initial CIP-1694 governance actions and enable the representative framework to be established.</li>
</ul>
<p>These actions are the <strong>"Info"</strong>, <strong>"Hard-fork initiation"</strong>, and <strong>"Protocol parameter changes"</strong> actions.</p>
<p>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 <strong>"Info"</strong> actions. This ensures that ada holders have sufficient time to choose their voting delegations.</p>
<p>SPOs will be able to vote as described in CIP-1694.</p>
<p><strong>"Hard-fork initiation"</strong> and <strong>"Protocol parameter changes"</strong> actions will also be ratified by the Constitutional Committee.</p>
<p>ada holders will be able to withdraw their staking rewards as usual.</p>
<ul>
<li><p>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:</p></li>
<li><p><strong>"Treasury withdrawals"</strong>,</p></li>
<li><p><strong>"Motion of no-confidence"</strong>,</p></li>
<li><p><strong>"Update constitutional committee and/or threshold and/or terms"</strong>, and</p></li>
<li><p><strong>"New constitution or guardrails script"</strong>.</p></li>
</ul>
<p>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).</p>
<h4>Guardrails</h4>
<p><strong>INTERIM-01</strong> (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) <strong>must</strong> 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.</p>
<p><strong>INTERIM-02</strong> (x) Treasury withdrawals <strong>must not</strong> be ratified until there is a community-approved Cardano Blockchain Ecosystem budget then in effect pursuant to a previous on-chain governance action.</p>
<p><strong>INTERIM-03</strong> (x) Treasury withdrawals <strong>must</strong> be consistent with the community-approved Cardano Blockchain ecosystem budget(s).</p>
<p><strong>INTERIM-04</strong> (x) ada holders <strong>must</strong> have ratified the Final Constitution as specified in Appendix II before ratifying any other proposed <strong>"new constitution"</strong>, <strong>"update constitutional committee and/or threshold and/or terms"</strong>, and <strong>"motion of no-confidence"</strong> governance actions.</p>
<p><strong>INTERIM-05</strong> (x) <strong>"New guardrails script"</strong> actions that are consistent with the Interim Constitution may be ratified during the interim period, provided the Interim Constitution itself is not changed.</p>
<h3>10. LIST OF PROTOCOL PARAMETER GROUPS</h3>
<p>The protocol parameters are grouped by type, allowing different thresholds to be set for each group.</p>
<p><em>The network group consists of:</em></p>
<ul>
<li><em>maximum block body size</em> (<em>maxBlockBodySize</em>)</li>
<li><em>maximum transaction size</em> (<em>maxTxSize</em>)</li>
<li><em>maximum block header size</em> (<em>maxBlockHeaderSize</em>)</li>
<li><em>maximum size of a serialized asset value</em> (<em>maxValueSize</em>)</li>
<li><em>maximum script execution units in a single transaction</em> (<em>maxTxExecutionUnits[steps]</em>)</li>
<li><em>maximum script execution units in a single block</em> (<em>maxBlockExecutionUnits[steps]</em>)</li>
<li><em>maximum number of collateral inputs</em> (<em>maxCollateralInputs</em>)</li>
</ul>
<p><em>The economic group consists of:</em></p>
<ul>
<li><em>minimum fee coefficient</em> (<em>txFeePerByte</em>)</li>
<li><em>minimum fee constant</em> (<em>txFeeFixed</em>)</li>
<li><em>minimum fee per byte for reference scripts</em> (<em>minFeeRefScriptCoinsPerByte</em>)</li>
<li><em>delegation key Lovelace deposit</em> (<em>stakeAddressDeposit</em>)</li>
<li><em>pool registration Lovelace deposit</em> (<em>stakePoolDeposit</em>)</li>
<li><em>monetary expansion</em> (<em>monetaryExpansion</em>)</li>
<li><em>treasury expansion</em> (<em>treasuryCut</em>)</li>
<li><em>minimum fixed rewards cut for pools</em> (<em>minPoolCost</em>)</li>
<li><em>minimum Lovelace deposit per byte of serialized UTxO</em> (<em>utxoCostPerByte</em>)</li>
<li><em>prices of Plutus execution units</em> (<em>executionUnitPrices[priceSteps/priceMemory]</em>)</li>
</ul>
<p><em>The technical group consists of:</em></p>
<ul>
<li><em>pool pledge influence</em> (<em>poolPledgeInfluence</em>)</li>
<li><em>pool retirement maximum epoch</em> (<em>poolRetireMaxEpoch</em>)</li>
<li><em>desired number of pools</em> (<em>stakePoolTargetNum</em>)</li>
<li><em>Plutus execution cost models</em> (<em>costModels</em>)</li>
<li><em>proportion of collateral needed for scripts</em> (<em>collateralPercentage</em>)</li>
</ul>
<p><em>The governance group consists of all the new protocol parameters that are introduced in CIP-1694:</em></p>
<ul>
<li><em>governance voting thresholds</em> (<em>dRepVotingThresholds[…], poolVotingThresholds[…]</em>)</li>
<li><em>governance action maximum lifetime in epochs</em> (<em>govActionLifetime</em>)</li>
<li><em>governance action deposit</em> (<em>govActionDeposit</em>)</li>
<li><em>DRep deposit amount</em> (<em>dRepDeposit</em>)</li>
<li><em>DRep activity period in epochs</em> (<em>dRepActivity</em>)</li>
<li><em>minimal constitutional committee size</em> (<em>committeeMinSize</em>)</li>
<li><em>maximum term length (in epochs) for the constitutional committee members</em> (<em>committeeMaxTermLimit</em>)</li>
</ul>
<h2>APPENDIX II: INTERIM CONSTITUTION</h2>
<h3>1. PREAMBLE</h3>
<p>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.</p>
<h3>2. INTERIM GOVERNANCE STRUCTURE</h3>
<h4>Section 1: Interim Constitutional Committee</h4>
<p>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.</p>
<p><strong>Composition:</strong></p>
<ul>
<li>The ICC shall consist of a minimum of 3 and a maximum of 10 members.</li>
<li>Members shall be selected based on their expertise, contributions to the Cardano ecosystem, and commitment to decentralized governance.</li>
</ul>
<p><strong>Term:</strong></p>
<ul>
<li>The term of the ICC members shall not exceed 18 epochs (90 days) unless extended by a community vote.</li>
</ul>
<p><strong>Powers:</strong></p>
<ul>
<li>The ICC shall have the power to veto governance actions that are deemed unconstitutional or detrimental to the Cardano ecosystem.</li>
<li>The ICC shall ensure that all governance actions comply with the guardrails established in this Interim Constitution.</li>
</ul>
<p><strong>Dissolution:</strong></p>
<ul>
<li>The ICC shall be dissolved upon the ratification of the Final Constitution, at which point a new Constitutional Committee shall be established.</li>
</ul>
<h4>Section 2: Interim Voting Mechanisms</h4>
<p>During the Interim Period, governance actions shall be subject to the following voting mechanisms:</p>
<p><strong>DReps Voting:</strong></p>
<ul>
<li>Delegated Representatives (DReps) shall vote on governance actions on behalf of ADA holders.</li>
<li>DRep votes shall be weighted according to the amount of ADA delegated to them.</li>
<li>A simple majority of the active voting stake is required to approve a governance action.</li>
</ul>
<p><strong>SPOs Voting:</strong></p>
<ul>
<li>Stake Pool Operators (SPOs) shall vote on specific governance actions, particularly those related to protocol parameters and technical changes.</li>
<li>SPO votes shall be weighted according to the amount of ADA staked in their pools.</li>
<li>A simple majority of the active stake pool stake is required to approve a governance action.</li>
</ul>
<p><strong>Community Sentiment Votes:</strong></p>
<ul>
<li>Community sentiment votes (Info actions) shall be conducted to gauge the community's opinion on non-binding governance actions.</li>
<li>Info actions shall not have any on-chain effects other than recording the outcome of the vote.</li>
</ul>
<h3>3. TRANSITION TO FINAL CONSTITUTION</h3>
<h4>Section 1: Development and Ratification</h4>
<p>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:</p>
<ol>
<li><strong>Community Consultation:</strong></li>
</ol>
<ul>
<li>The Cardano community shall be actively involved in the consultation process, providing input and feedback on the draft Final Constitution.</li>
</ul>
<ol>
<li><strong>Drafting Committee:</strong></li>
</ol>
<ul>
<li>A Drafting Committee shall be established to compile and refine the input from the community into a cohesive Final Constitution.</li>
<li>The Drafting Committee shall consist of representatives from various stakeholder groups, including ADA holders, DReps, SPOs, and developers.</li>
</ul>
<ol>
<li><strong>Public Review:</strong></li>
</ol>
<ul>
<li>The draft Final Constitution shall be made available for public review and comment for a minimum of 6 epochs (30 days).</li>
</ul>
<ol>
<li><strong>Ratification Vote:</strong></li>
</ol>
<ul>
<li>A ratification vote shall be conducted to approve the Final Constitution.</li>
<li>A minimum of 67% of the active voting stake must support the Final Constitution for it to be ratified.</li>
</ul>
<h4>Section 2: Implementation</h4>
<p>Upon ratification of the Final Constitution:</p>
<ol>
<li><strong>Establishment of the Constitutional Committee:</strong></li>
</ol>
<ul>
<li>A new Constitutional Committee shall be established in accordance with the Final Constitution.</li>
<li>The Interim Constitutional Committee shall be dissolved.</li>
</ul>
<ol>
<li><strong>Transition of Governance Powers:</strong></li>
</ol>
<ul>
<li>All governance powers and responsibilities shall transition from the Interim Constitutional Committee to the new Constitutional Committee.</li>
<li>Any pending governance actions under the Interim Constitution shall be carried over and processed under the Final Constitution.</li>
</ul>
<ol>
<li><strong>Guardrails and Protocol Parameters:</strong></li>
</ol>
<ul>
<li>The guardrails and protocol parameters established under the Interim Constitution shall remain in effect until they are reviewed and potentially amended by the new Constitutional Committee under the Final Constitution.</li>
</ul>
<h3>4. AMENDMENTS TO THE INTERIM CONSTITUTION</h3>
<p>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:</p>
<ol>
<li><strong>Proposal Submission:</strong></li>
</ol>
<ul>
<li>The proposed amendment shall be submitted as a governance action, accompanied by a rationale and supporting documentation.</li>
</ul>
<ol>
<li><strong>Review by the ICC:</strong></li>
</ol>
<ul>
<li>The Interim Constitutional Committee shall review the proposed amendment for compliance with the guardrails and overall impact on the Cardano ecosystem.</li>
</ul>
<ol>
<li><strong>Community Vote:</strong></li>
</ol>
<ul>
<li>The proposed amendment shall be put to a community vote, requiring a minimum of 67% of the active voting stake to approve the amendment.</li>
</ul>
<ol>
<li><strong>Implementation:</strong></li>
</ol>
<ul>
<li>If approved, the amendment shall be implemented and the Interim Constitution shall be updated accordingly.</li>
</ul>
<h3>5. FINAL PROVISIONS</h3>
<h4>Section 1: Supremacy Clause</h4>
<p>In the event of a conflict between this Interim Constitution and any governance action or protocol parameter, this Interim Constitution shall prevail.</p>
<h4>Section 2: Continuity Clause</h4>
<p>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.</p>
<h4>Section 3: Interpretation</h4>
<p>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.</p>
<h4>Section 4: Dissolution of Interim Governance Structures</h4>
<p>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.</p>
<h2>APPENDIX III: GLOSSARY OF TERMS</h2>
<p><strong>ADA:</strong> The native cryptocurrency of the Cardano Blockchain.</p>
<p><strong>Cardano Blockchain:</strong> A decentralized blockchain platform that enables the development of smart contracts, decentralized applications (DApps), and digital assets.</p>
<p><strong>CIP-1694:</strong> A Cardano Improvement Proposal that outlines the governance framework for the Cardano Blockchain.</p>
<p><strong>Constitutional Committee:</strong> The governance body responsible for ensuring that governance actions are consistent with the Cardano Constitution.</p>
<p><strong>DRep (Delegated Representative):</strong> An individual or entity that represents ADA holders in the on-chain governance process by voting on governance actions on their behalf.</p>
<p><strong>Epoch:</strong> A time period used in the Cardano Blockchain, typically lasting 5 days.</p>
<p><strong>Final Constitution:</strong> The permanent governance framework for the Cardano Blockchain, to be ratified by the community and replace the Interim Constitution.</p>
<p><strong>Guardrails:</strong> Specific guidelines and constraints that govern the parameters and actions within the Cardano Blockchain ecosystem.</p>
<p><strong>Hard Fork:</strong> A protocol upgrade that changes the blockchain's rules and requires all nodes to upgrade to the new version.</p>
<p><strong>Interim Constitution:</strong> The temporary governance framework for the Cardano Blockchain during the transition to the Final Constitution.</p>
<p><strong>SPO (Stake Pool Operator):</strong> An individual or entity responsible for operating a stake pool, which participates in the consensus mechanism of the Cardano Blockchain.</p>
<p><strong>Treasury:</strong> A pool of ADA used to fund development and other initiatives within the Cardano ecosystem.</p>
<h2>APPENDIX IV: INTERIM PERIOD ACTIONS AND TIMELINE</h2>
<h3>1. INITIAL GOVERNANCE ACTIONS</h3>
<p>During the Interim Period, the following initial governance actions shall be prioritized:</p>
<ol>
<li><strong>Establishment of the Interim Constitutional Committee (ICC):</strong></li>
</ol>
<ul>
<li>The ICC shall be established within 2 epochs following the Chang Hard Fork.</li>
</ul>
<ol>
<li><strong>Delegated Representative (DRep) Registration:</strong></li>
</ol>
<ul>
<li>DReps shall be allowed to register immediately following the Chang Hard Fork.</li>
<li>ADA holders shall have the option to delegate their voting rights to registered DReps.</li>
</ul>
<ol>
<li><strong>Community Sentiment (Info) Actions:</strong></li>
</ol>
<ul>
<li>Info actions shall be used to gauge community sentiment on key governance topics.</li>
<li>These actions shall not have on-chain effects but shall inform future governance decisions.</li>
</ul>
<ol>
<li><strong>Initial Hard Fork Initiation:</strong></li>
</ol>
<ul>
<li>The first hard fork initiation action shall be proposed to enable additional governance actions, such as Treasury withdrawals.</li>
</ul>
<h3>2. TIMELINE FOR FINAL CONSTITUTION DEVELOPMENT</h3>
<p>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.</p>
<ol>
<li><strong>Community Consultation Phase:</strong></li>
</ol>
<ul>
<li>Duration: 6 epochs (30 days).</li>
<li>Purpose: Engage the Cardano community in discussions and solicit feedback on the principles, structure, and content of the Final Constitution.</li>
<li>Actions: Conduct workshops, surveys, and community forums to gather input.</li>
</ul>
<ol>
<li><strong>Drafting Phase:</strong></li>
</ol>
<ul>
<li>Duration: 6 epochs (30 days).</li>
<li>Purpose: The Drafting Committee compiles and integrates community feedback into a cohesive draft of the Final Constitution.</li>
<li>Actions: The Drafting Committee meets regularly to refine the draft, considering all input from the community consultation phase.</li>
</ul>
<ol>
<li><strong>Public Review Phase:</strong></li>
</ol>
<ul>
<li>Duration: 6 epochs (30 days).</li>
<li>Purpose: Present the draft Final Constitution to the Cardano community for public review and comment.</li>
<li>Actions: The draft is published online, and a dedicated platform is made available for comments, suggestions, and discussion.</li>
</ul>
<ol>
<li><strong>Revision Phase:</strong></li>
</ol>
<ul>
<li>Duration: 4 epochs (20 days).</li>
<li>Purpose: The Drafting Committee revises the draft based on community feedback from the public review phase.</li>
<li>Actions: Final adjustments are made, and the draft is prepared for the ratification vote.</li>
</ul>
<ol>
<li><strong>Ratification Vote:</strong></li>
</ol>
<ul>
<li>Duration: 2 epochs (10 days).</li>
<li>Purpose: Conduct a vote among ADA holders to ratify the Final Constitution.</li>
<li>Threshold: A minimum of 67% of the active voting stake must support the Final Constitution for it to be ratified.</li>
<li>Actions: Voting takes place on-chain, with results published immediately after the vote concludes.</li>
</ul>
<ol>
<li><strong>Transition Phase:</strong></li>
</ol>
<ul>
<li>Duration: 2 epochs (10 days).</li>
<li>Purpose: Implement the Final Constitution and transition governance powers to the new governance structures.</li>
<li>Actions: Dissolution of the Interim Constitutional Committee, establishment of the Constitutional Committee, and activation of the governance framework as outlined in the Final Constitution.</li>
</ul>
<h3>3. INTERIM PERIOD GOVERNANCE ACTIONS</h3>
<p>During the Interim Period, specific governance actions shall be prioritized to ensure the smooth transition to the Final Constitution. These actions include:</p>
<ol>
<li><strong>Guardrails Implementation:</strong></li>
</ol>
<ul>
<li>Purpose: Ensure all critical guardrails are in place to protect the integrity and stability of the Cardano Blockchain during the Interim Period.</li>
<li>Actions: Establish, review, and amend guardrails as necessary.</li>
</ul>
<ol>
<li><strong>Budget Proposal and Approval:</strong></li>
</ol>
<ul>
<li>Purpose: Develop and approve a budget for the ongoing maintenance and development of the Cardano Blockchain during the Interim Period.</li>
<li>Actions: The Interim Constitutional Committee, in collaboration with the community, shall propose a budget that must be approved through an on-chain governance vote.</li>
</ul>
<ol>
<li><strong>Hard Fork Preparation:</strong></li>
</ol>
<ul>
<li>Purpose: Prepare for necessary hard forks that may be required to implement changes during the Interim Period.</li>
<li>Actions: Engage with developers, SPOs, and the community to ensure a smooth transition during hard fork events.</li>
</ul>
<ol>
<li><strong>Treasury Management:</strong></li>
</ol>
<ul>
<li>Purpose: Oversee the management and distribution of funds from the Cardano Treasury.</li>
<li>Actions: Review treasury withdrawal proposals, ensuring alignment with community goals and budgetary constraints.</li>
</ul>
<ol>
<li><strong>Community Engagement and Education:</strong></li>
</ol>
<ul>
<li>Purpose: Ensure that the Cardano community remains informed and engaged throughout the Interim Period.</li>
<li>Actions: Conduct regular updates, educational sessions, and community events to explain governance processes and encourage participation.</li>
</ul>
<h2>APPENDIX V: IMPLEMENTATION GUIDELINES FOR CIP-1694</h2>
<h3>1. INTRODUCTION TO CIP-1694 IMPLEMENTATION</h3>
<p>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.</p>
<h3>2. ESTABLISHMENT OF GOVERNANCE BODIES</h3>
<h4>Section 1: Delegated Representatives (DReps)</h4>
<p>DReps play a crucial role in representing ADA holders in the governance process. The following steps outline the process for establishing DReps:</p>
<ol>
<li><strong>Registration:</strong></li>
</ol>
<ul>
<li>DReps must register on-chain, providing information about their qualifications, experience, and governance philosophy.</li>
<li>Registration fees may apply, as specified in the governance parameters.</li>
</ul>
<ol>
<li><strong>Delegation:</strong></li>
</ol>
<ul>
<li>ADA holders can delegate their voting power to registered DReps.</li>
<li>Delegation is flexible, allowing ADA holders to change their DRep at any time.</li>
</ul>
<ol>
<li><strong>Responsibilities:</strong></li>
</ol>
<ul>
<li>DReps are expected to vote on governance actions, represent the interests of their delegators, and adhere to the code of conduct.</li>
</ul>
<ol>
<li><strong>Accountability:</strong></li>
</ol>
<ul>
<li>DReps must disclose any conflicts of interest and provide regular updates to their delegators.</li>
<li>Failure to act in the best interests of delegators may result in loss of delegation or other penalties.</li>
</ul>
<h4>Section 2: Stake Pool Operators (SPOs)</h4>
<p>SPOs contribute to the security and decentralization of the Cardano Blockchain and participate in governance actions. The following guidelines apply to SPOs:</p>
<ol>
<li><strong>Participation:</strong></li>
</ol>
<ul>
<li>SPOs are automatically eligible to vote on certain governance actions, particularly those related to protocol parameters and technical changes.</li>
</ul>
<ol>
<li><strong>Voting Power:</strong></li>
</ol>
<ul>
<li>SPO voting power is weighted according to the amount of ADA staked in their pools.</li>
<li>SPOs must act transparently and in the best interests of the Cardano community.</li>
</ul>
<ol>
<li><strong>Conflicts of Interest:</strong></li>
</ol>
<ul>
<li>SPOs must disclose any potential conflicts of interest and refrain from voting on actions where such conflicts may arise.</li>
</ul>
<ol>
<li><strong>Compliance:</strong></li>
</ol>
<ul>
<li>SPOs must comply with all governance guidelines and adhere to the code of conduct.</li>
</ul>
<h4>Section 3: Constitutional Committee</h4>
<p>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:</p>
<ol>
<li><strong>Selection:</strong></li>
</ol>
<ul>
<li>Members of the Constitutional Committee shall be selected based on their expertise, contributions to the Cardano ecosystem, and commitment to decentralized governance.</li>
<li>The number of members and term limits are specified in the governance parameters.</li>
</ul>
<ol>
<li><strong>Responsibilities:</strong></li>
</ol>
<ul>
<li>The Constitutional Committee reviews all governance actions to ensure they comply with the Cardano Constitution.</li>
<li>The Committee may veto any governance action that violates the Constitution.</li>
</ul>
<ol>
<li><strong>Transparency:</strong></li>
</ol>
<ul>
<li>The Constitutional Committee must operate transparently, publishing its decisions and the rationale behind them.</li>
<li>All meetings and votes of the Committee should be documented and made available to the public.</li>
</ul>
<ol>
<li><strong>Accountability:</strong></li>
</ol>
<ul>
<li>Members of the Constitutional Committee are accountable to the Cardano community and must act in the best interests of the ecosystem.</li>
<li>The community may propose changes to the Committee's composition or powers through governance actions.</li>
</ul>
<h3>3. VOTING PROCEDURES</h3>
<p>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:</p>
<h4>Section 1: Proposal Submission</h4>
<ol>
<li><strong>Eligibility:</strong></li>
</ol>
<ul>
<li>Any ADA holder, DRep, or SPO may submit a governance proposal.</li>
<li>Proposals must be submitted in a standardized format, including a clear rationale, potential impact, and supporting documentation.</li>
</ul>
<ol>
<li><strong>Submission Process:</strong></li>
</ol>
<ul>
<li>Proposals are submitted on-chain and are subject to a deposit fee, as specified in the governance parameters.</li>
<li>The proposal is then reviewed by the relevant governance bodies (e.g., DReps, SPOs, Constitutional Committee).</li>
</ul>
<ol>
<li><strong>Review and Approval:</strong></li>
</ol>
<ul>
<li>Proposals are reviewed for completeness, compliance with guardrails, and potential impact on the Cardano ecosystem.</li>
<li>Once approved, proposals are scheduled for a vote.</li>
</ul>
<h4>Section 2: Voting Process</h4>
<ol>
<li><strong>Voting Period:</strong></li>
</ol>
<ul>
<li>The voting period for each proposal is defined in the governance parameters and typically lasts between 5 to 15 epochs.</li>
<li>During this period, ADA holders, DReps, and SPOs can cast their votes.</li>
</ul>
<ol>
<li><strong>Voting Mechanisms:</strong></li>
</ol>
<ul>
<li>Votes are cast on-chain, and each vote is weighted according to the voter's stake (for ADA holders) or delegation (for DReps).</li>
<li>The results of the vote are automatically recorded on the blockchain.</li>
</ul>
<ol>
<li><strong>Thresholds:</strong></li>
</ol>
<ul>
<li>Different types of proposals may require different thresholds for approval (e.g., simple majority, supermajority).</li>
<li>Thresholds are defined in the governance parameters and vary based on the type and significance of the proposal.</li>
</ul>
<ol>
<li><strong>Result Publication:</strong></li>
</ol>
<ul>
<li>The results of the vote are published immediately after the voting period ends.</li>
<li>All votes and outcomes are recorded on-chain, ensuring transparency and immutability.</li>
</ul>
<h4>Section 3: Implementation of Approved Proposals</h4>
<ol>
<li><strong>Execution:</strong></li>
</ol>
<ul>
<li>Approved proposals are automatically executed by smart contracts, where applicable.</li>
<li>For proposals requiring manual implementation (e.g., changes to off-chain processes), the responsible parties are notified, and a timeline for implementation is established.</li>
</ul>
<ol>
<li><strong>Monitoring:</strong></li>
</ol>
<ul>
<li>The implementation of approved proposals is monitored by the relevant governance bodies to ensure compliance and effectiveness.</li>
<li>Any issues or deviations from the approved proposal must be reported and addressed promptly.</li>
</ul>
<ol>
<li><strong>Feedback Loop:</strong></li>
</ol>
<ul>
<li>The Cardano community is encouraged to provide feedback on the implementation and outcomes of approved proposals.</li>
<li>This feedback may be used to refine future proposals or governance processes.</li>
</ul>
<h3>4. ONGOING GOVERNANCE MAINTENANCE</h3>
<p>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:</p>
<h4>Section 1: Regular Reviews</h4>
<ol>
<li><strong>Periodic Audits:</strong></li>
</ol>
<ul>
<li>Governance processes, including voting procedures, the role of DReps, SPOs, and the Constitutional Committee, shall undergo periodic audits.</li>
<li>Audits will assess compliance with the Constitution, effectiveness, and areas for improvement.</li>
<li>The results of these audits will be made public and may inform future governance proposals.</li>
</ul>
<ol>
<li><strong>Annual Governance Review:</strong></li>
</ol>
<ul>
<li>An annual review of the governance framework shall be conducted by the Constitutional Committee in collaboration with the Cardano community.</li>
<li>This review will consider the performance of the governance structures, the effectiveness of the guardrails, and any evolving needs of the Cardano ecosystem.</li>
<li>Recommendations from the review may lead to proposed amendments or updates to the Constitution or governance parameters.</li>
</ul>
<ol>
<li><strong>Community Feedback:</strong></li>
</ol>
<ul>
<li>Continuous feedback from the Cardano community will be solicited to ensure the governance framework remains responsive to community needs.</li>
<li>Mechanisms for gathering feedback include surveys, forums, and public consultations.</li>
</ul>
<ol>
<li><strong>Review of Guardrails:</strong></li>
</ol>
<ul>
<li>Guardrails that govern protocol parameters and governance actions should be reviewed regularly to ensure they remain relevant and effective.</li>
<li>Changes to guardrails may be proposed as governance actions and must go through the standard voting process.</li>
</ul>
<h4>Section 2: Governance Updates and Amendments</h4>
<ol>
<li><strong>Amendment Proposals:</strong></li>
</ol>
<ul>
<li>Any member of the Cardano community may propose amendments to the Constitution, guardrails, or other governance parameters.</li>
<li>Proposals must include a clear rationale, potential impacts, and a detailed plan for implementation.</li>
</ul>
<ol>
<li><strong>Review Process:</strong></li>
</ol>
<ul>
<li>Amendment proposals will be reviewed by the Constitutional Committee for compliance with the existing governance framework.</li>
<li>The Committee may provide recommendations or request revisions before the proposal is put to a vote.</li>
</ul>
<ol>
<li><strong>Voting on Amendments:</strong></li>
</ol>
<ul>
<li>Amendments to the Constitution or guardrails require a supermajority (e.g., 67% of the active voting stake) to be approved.</li>
<li>The results of the vote will be binding, and approved amendments will be implemented as specified.</li>
</ul>
<ol>
<li><strong>Implementation of Amendments:</strong></li>
</ol>
<ul>
<li>Once an amendment is approved, it will be incorporated into the governance framework.</li>
<li>Any necessary updates to documentation, processes, or smart contracts will be executed to reflect the amendment.</li>
</ul>
<ol>
<li><strong>Communication of Changes:</strong></li>
</ol>
<ul>
<li>All amendments and updates to the governance framework will be communicated to the Cardano community through official channels.</li>
<li>Educational resources may be provided to help the community understand the implications of the changes.</li>
</ul>
<h4>Section 3: Emergency Governance Actions</h4>
<ol>
<li><strong>Definition of Emergencies:</strong></li>
</ol>
<ul>
<li>An emergency is defined as any situation that poses an immediate threat to the security, stability, or functionality of the Cardano Blockchain.</li>
<li>Examples include severe security vulnerabilities, catastrophic failures, or unforeseen critical issues.</li>
</ul>
<ol>
<li><strong>Emergency Action Procedures:</strong></li>
</ol>
<ul>
<li>In the event of an emergency, the Constitutional Committee may expedite the governance process to address the issue.</li>
<li>Emergency actions may include temporary changes to protocol parameters, suspension of certain governance processes, or other measures necessary to mitigate the threat.</li>
</ul>
<ol>
<li><strong>Community Notification:</strong></li>
</ol>
<ul>
<li>The Cardano community must be notified immediately of any emergency governance actions, including the rationale, expected impact, and duration.</li>
<li>A full report on the emergency and the actions taken must be provided once the situation is resolved.</li>
</ul>
<ol>
<li><strong>Review and Ratification:</strong></li>
</ol>
<ul>
<li>Any emergency actions taken must be reviewed and ratified by the community through a governance vote as soon as possible.</li>
<li>If the community does not ratify the emergency actions, they must be rolled back, and alternative solutions must be proposed.</li>
</ul>
<ol>
<li><strong>Post-Emergency Evaluation:</strong></li>
</ol>
<ul>
<li>After the resolution of an emergency, a thorough evaluation will be conducted to assess the effectiveness of the response and identify any areas for improvement.</li>
<li>The findings of this evaluation may inform updates to the emergency governance procedures.</li>
</ul>
<h3>5. COMMUNITY ENGAGEMENT AND EDUCATION</h3>
<p>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:</p>
<h4>Section 1: Governance Education Programs</h4>
<ol>
<li><strong>Workshops and Webinars:</strong></li>
</ol>
<ul>
<li>Regular workshops and webinars will be conducted to educate the community on the governance framework, voting procedures, and the roles of DReps, SPOs, and the Constitutional Committee.</li>
<li>These sessions will be open to all community members and will be recorded and made available online.</li>
</ul>
<ol>
<li><strong>Educational Resources:</strong></li>
</ol>
<ul>
<li>Comprehensive educational materials, including guides, FAQs, and video tutorials, will be developed to explain the governance processes in detail.</li>
<li>These resources will be accessible through the official Cardano website and other community platforms.</li>
</ul>
<ol>
<li><strong>Onboarding for New Participants:</strong></li>
</ol>
<ul>
<li>A dedicated onboarding program will be established for new ADA holders, DReps, and SPOs to help them understand their roles and responsibilities within the governance framework.</li>
<li>This program will include step-by-step instructions on how to participate in governance actions, delegate voting power, and submit proposals.</li>
</ul>
<h4>Section 2: Community Outreach</h4>
<ol>
<li><strong>Regular Updates:</strong></li>
</ol>
<ul>
<li>The Cardano governance bodies will provide regular updates to the community on ongoing governance actions, upcoming votes, and other relevant developments.</li>
<li>Updates will be shared through multiple channels, including the official Cardano blog, social media, and community forums.</li>
</ul>
<ol>
<li><strong>Open Forums:</strong></li>
</ol>
<ul>
<li>Open forums and discussion groups will be established to facilitate dialogue between community members and governance bodies.</li>
<li>These forums will provide a platform for community members to ask questions, share ideas, and provide feedback on governance matters.</li>
</ul>
<ol>
<li><strong>Community Ambassadors:</strong></li>
</ol>
<ul>
<li>A network of community ambassadors will be established to represent different regions and demographic groups within the Cardano ecosystem.</li>
<li>Ambassadors will play a key role in disseminating information, gathering feedback, and ensuring that diverse perspectives are considered in governance decisions.</li>
</ul>
<ol>
<li><strong>Surveys and Polls:</strong></li>
</ol>
<ul>
<li>Regular surveys and polls will be conducted to gauge community sentiment on various governance issues and proposals.</li>
<li>The results of these surveys will be used to inform decision-making and prioritize governance actions.</li>
</ul>
<h4>Section 3: Transparency and Accountability</h4>
<ol>
<li><strong>Public Reporting:</strong></li>
</ol>
<ul>
<li>All governance bodies, including the Constitutional Committee, DReps, and SPOs, will publish regular reports on their activities, decisions, and the outcomes of governance actions.</li>
<li>These reports will be made available to the entire Cardano community to ensure transparency and accountability.</li>
</ul>
<ol>
<li><strong>Audit and Oversight:</strong></li>
</ol>
<ul>
<li>Independent audits of the governance processes and financial management (e.g., Treasury withdrawals) will be conducted periodically.</li>
<li>The results of these audits will be published and any recommendations for improvement will be considered and implemented as appropriate.</li>
</ul>
<ol>
<li><strong>Feedback Mechanisms:</strong></li>
</ol>
<ul>
<li>Formal mechanisms will be established to allow community members to provide feedback on the performance and conduct of governance bodies.</li>
<li>This feedback will be reviewed regularly, and governance bodies will be expected to address any issues or concerns raised by the community.</li>
</ul>
<h3>6. CONCLUSION</h3>
<p>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.</p>
<p>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.</p>
<p>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.</p>