From e99730fa2ef9af93582197a188440b55d2b74642 Mon Sep 17 00:00:00 2001 From: Cerkoryn <30681834+Cerkoryn@users.noreply.github.com> Date: Wed, 25 Sep 2024 21:07:13 -0500 Subject: [PATCH 01/17] Deletes only. No other edits made. --- CONSTITUTION.md | 1854 +---------------------------------------------- 1 file changed, 14 insertions(+), 1840 deletions(-) diff --git a/CONSTITUTION.md b/CONSTITUTION.md index 87d809e..e539a3f 100644 --- a/CONSTITUTION.md +++ b/CONSTITUTION.md @@ -1,62 +1,17 @@ -`Draft 2024-07-29` +`Draft 2024-09-20` # CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION ## PREAMBLE -In the beginning of the Cardano Blockchain ecosystem, three pioneering entities, IOHK, -Emurgo, and the Cardano Foundation, came together to foster the emergence of a new -blockchain, the Cardano Blockchain, laying the foundation for a decentralized network that -would empower individuals, and promote collaboration and innovation. Their pioneering efforts -have shaped the path for a blockchain designed to ensure a fair and transparent environment -where all participants can contribute to the Cardano Blockchain ecosystem's growth and success. - -Over time, the Cardano Blockchain ecosystem has expanded significantly, and now, the Cardano -Blockchain ecosystem, comprising of thousands of ada holders, individuals, builders, developers, -enterprises, stake pools, users of the Cardano Blockchain and others, operates in a truly -decentralized manner, further strengthening the resilience and autonomy of the Cardano -Blockchain ecosystem. - -As the Cardano Blockchain ecosystem continues to grow, it has become imperative to similarly -adapt and evolve its governance model, reflecting the principles of decentralization, community -involvement, inclusivity and collaboration that have been the cornerstone of the Cardano -Blockchain ecosystem since its start. - -Recognizing the need for a more robust and dynamic governance framework, and one that -utilizes wherever possible and beneficial blockchain technology in the governance process, the -Cardano community, as the members of this decentralized Cardano Blockchain ecosystem, -hereby establishes this Cardano Constitution. It shall serve as a guiding set of principles for the -operation and governance of our collective efforts, fostering an environment where all -participants can contribute to the betterment of the Cardano Blockchain ecosystem as a whole. - Through adopting this Constitution, the Cardano Blockchain ecosystem shall establish a robust governance framework, ensuring that decisions are made in the best interest of the Cardano community. The Cardano community shall uphold principles of transparency, openness, and -responsible governance, promoting a culture of trust and collaboration. Together, the Cardano -community commits to uphold these principles and to work together towards the continuous -improvement, growth, and success of our decentralized blockchain ecosystem known as the -Cardano Blockchain. - -This Constitution shall serve as the embodiment of these guiding principles for the operation and -governance of the decentralized Cardano Blockchain ecosystem, providing a foundation that will -adapt and evolve over time to meet the continuing needs of the Cardano community. - -All members of the Cardano community are expected to abide by this Constitution, and are -entitled to participate in its governance processes, and are encouraged to work collaboratively -towards the betterment of the Cardano Blockchain ecosystem as a whole, contributing to its -growth, sustainability, and success. The Cardano Blockchain shall be governed on a vote-based -decision-making model, fostering inclusivity, a diversity of views, innovation and adaptability. +responsible governance, promoting a culture of trust and collaboration. All owners of ada shall have the opportunity to contribute to the governance and direction of the decentralized Cardano Blockchain ecosystem. -In approaching this Constitution, it must be remembered that this is not a constitution for only a -blockchain but rather, it is a constitution for a blockchain ecosystem – a much more ambitious -endeavor. Accordingly, how governance actions are approved, while extremely important, is not -the sole focus of this Constitution. Rather, this Constitution provides the basis and fundamental -framework through which all actors in the Cardano Blockchain ecosystem can come together to -govern themselves and form radically new approaches to human interaction and collaboration. - By necessity, this Constitution recognizes the role of and empowers the Constitutional Committee, confirms the right of the Cardano community to participate in collective bodies for collaboration, gives effect to on-chain governance, and empowers DReps to act as the voice of @@ -69,52 +24,25 @@ the Cardano treasury through the inclusion of the Cardano Guardrails in this Con ### Section 1 -These below Tenets shall guide all actors in the Cardano Blockchain ecosystem including the -Constitutional Committee and proposed governance actions shall be evaluated in accordance +These below Tenets shall guide the Constitutional Committee and proposed governance actions shall be evaluated in accordance with these Tenets. Transactions on the Cardano Blockchain should not be slowed down or censored and should be -expediently served for their intended purpose. The Cardano Blockchain should scale taking into -consideration throughput, sharding, settlement and dynamic pricing. +expediently served for their intended purpose. The cost of transactions on the Cardano Blockchain should be predictable and not unreasonable. -The Cardano Blockchain should facilitate an accessible, predictable pricing model. Anyone desiring to develop and deploy applications on the Cardano Blockchain should not -unreasonably be prevented from developing and deploying such applications as intended. The -Cardano community should promote features to assist in developing and deploying applications -such as digital subscriber lines, formal verification support, asynchronous and scalable location -services, oracles and access to partnerchains. +unreasonably be prevented from developing and deploying such applications as intended. -Contributions by Cardano community on the Cardano Blockchain should be recognized, -recorded and assessed fairly by the Cardano community through reward sharing with SPOs and -DReps, appropriate tokenomics and multi-resource consensus approaches. - -The Cardano Blockchain shall not lock in an ada owner’s value without an owner’s consent. The -Cardano Blockchain should promote interoperability and access to partnerchains. +The Cardano Blockchain shall not lock in an ada owner’s value without an owner’s consent. The Cardano Blockchain shall preserve in a safe manner any value and information an owner of -ada seeks to store on the Cardano Blockchain. To assure safe protection of value and -information, the Cardano Blockchain should focus on integrity, post-quantum security, -decentralization and decentralized storage, access to stablecoins and robust key management -approaches. +ada seeks to store on the Cardano Blockchain. The Cardano Blockchain shall not unnecessarily spend resources. The Cardano Blockchain shall promote efficient design, memory and storage. -All users of the Cardano Blockchain shall be treated equally taking into account the collective -desires of the Cardano Blockchain community consistent with the long-term sustainability and -viability of the Cardano Blockchain. Long-term sustainability and viability shall be evaluated by -a number of considerations including fairness, neutrality, sustainability, robust governance, -promotion of decentralized identity, use of multi-resource consensus and democratic -participation by all members of the Cardano community. - -#### Workshop Questions - -- Do you believe these tenets appropriately reflect the ethos of the Cardano Blockchain? -- Should there be an additional tenet addressing financial sustainability? If yes, what - should it contain? Should it include an absolute cap on the circulating supply of ada? - ### Section 2 The Cardano Blockchain shall operate in accordance with the Cardano Blockchain Guardrails as @@ -135,13 +63,7 @@ appropriate on-chain governance action. ### Section 1 No formal membership shall be required to use, participate in and benefit from the Cardano -Blockchain. Instead, all owners of ada, all developers of, all those building on, and all those -otherwise supporting, maintaining or using the Cardano Blockchain are beneficiaries of the -Cardano Blockchain ecosystem and, as such, are collectively members of the Cardano - -community. All Cardano community members are accordingly beneficiaries of this Constitution, -entitled to its rights, privileges and protections and, as such, are expected to support and uphold -this Constitution. +Blockchain. ### Section 2 @@ -150,40 +72,12 @@ entitled to access and participate in the on-chain decision-making processes of Blockchain ecosystem, including voting and taking part in on-chain governance regarding the Cardano Blockchain. -#### Workshop Questions - -- Should on-chain governance participation be limited to only owners of ada or should - ada owners be allowed to appoint designees who are then entitled to participate in on- - chain governance? [Note that this is not a reference to delegation to DReps. - -### Section 3 - -Members of the Cardano community have a responsibility to maintain the integrity of the -Cardano Blockchain ecosystem by following this Constitution, operating the Cardano -Blockchain network, participating in Cardano Blockchain governance activities, and resolving -disputes in a fair and transparent manner. - -### Section 4 - -The Cardano community is entitled and encouraged through the provisions of this Constitution to -collaborate in developing, maintaining and building applications for the Cardano community, -and to form temporary and permanent organizations and entities as the Cardano community -deems desirable or appropriate in support of the Cardano Blockchain ecosystem. - ## ARTICLE III. PARTICIPATORY GOVERNANCE ### Section 1 The Cardano Blockchain ecosystem shall be governed by a decentralized, on-chain governance -model, utilizing, to the extent possible and beneficial, smart contracts and other blockchain- -based tools to facilitate decision-making and ensure transparency. On-chain voting for -governance actions shall follow the process outlined in the Cardano Blockchain Guardrails. - -### Section 2 - -Three independent governance bodies shall participate in voting for on-chain governance actions -to provide checks and balances for the Cardano Blockchain consisting of Delegated -Representatives (DRep), Stake Pool Operators (SPO) and the Constitutional Committee (CC). +model. ### Section 3 @@ -192,57 +86,16 @@ specific consensus threshold requirements as required by the Cardano Blockchain All on-chain governance actions shall be voted upon in accordance with the Cardano Blockchain Guardrails. -### Section 4 - -All owners of ada _[, as well as their appointed designees,]_ shall have the right to vote in on-chain -governance action decision-making processes, subject to any restrictions or requirements -provided for in this Constitution and the Cardano Blockchain Guardrails. - -#### Workshop Questions - -- Voting rights are in proportion to the ada owned. However, should the Constitution - specify a specific voting model? -- Should the Constitution enshrine one ada one vote? -- How do we address participation by institutions? Should holders of ada who are not - owners, such as exchanges, be allowed to vote? - All owners of ada _[, as well as their appointed designees,]_ shall have the right to propose changes to the governance structure of the Cardano Blockchain ecosystem in accordance with the Cardano Blockchain Guardrails. -### Section 5 - -A special form of governance action exists to allow community sentiment to be gauged without -committing to any on-chain change of the Cardano Blockchain. "Info" actions have no on-chain -effect other than to record the outcome of such a vote on the Cardano Blockchain. - ### Section 6 -Any proposed on-chain governance action shall require a standardized and legible format -including a URL and hash linked to documented off-chain content. Sufficient rationale shall be -provided to justify the requested change to the Cardano Blockchain. The rationale shall include, -at a minimum, a title, abstract, reason for the proposal, and relevant supporting materials. - -Any governance action proposal reaching the on-chain governance stage shall be identical in -content as to the final off-chain version of such governance action proposal. - -“Hard Fork Initiation” and “Protocol Parameter Change” governance actions should undergo -sufficient technical review and scrutiny as mandated by the Cardano Blockchain Guardrails to -ensure that the governance action does not endanger the security, functionality or performance of -the Cardano Blockchain. On-chain governance actions should address their expected impact on -the Cardano Blockchain ecosystem. - All owners of ada shall have the right to ensure that the process for participating in, submitting and voting on on-chain governance actions is open and transparent and is protected from undue influence and manipulation. -### Section 7 - -The Cardano community is expected to support the creation, maintenance and ongoing -administration of off-chain governance processes as may be necessary to give effect to this -Constitution and to ensure that there is awareness of and an opportunity to debate and shape all -future governance actions for the Cardano Blockchain. - ### Section 8 The Cardano community is expected to propose, not less than on an annual basis, a budget for @@ -259,79 +112,13 @@ such ada.] [Contractual obligations governing the use of ada received from the C Blockchain treasury pursuant to a Cardano budget in excess of [1,000,000] shall include dispute resolution provisions.]_ -#### Workshop Questions - -- Should the Constitution require that governance actions above a specified amount - include allocations of ada to cover periodic audits and implementation of oversight - metrics? If yes, how should they be enforced? -- Should the Constitution require that contractual provisions governing the use of ada - received from the treasury above a specified amount include dispute resolution - provisions? If yes, how should they be enforced? -- Should the Constitution require that the budget include a contingency fund? If so, how - would it work? What could it be used for? Who would administer it? -- Should the Constitution require that the budget include an indemnity fund to cover - potential claims against governance participants such as DReps and Constitutional - Committee members? If so, how would it work? What could it be used for? Who would - administer it? -- Should the budgetary process be spelled out in greater detail in the Constitution? Should - the Constitution identify how the budget will be administered? Should it identify who - will administer the budget? -- Should the Constitution specify a cap on the annual budget? - ## ARTICLE IV. DELEGATED REPRESENTATIVES -### Section 1 - -In order to participate in governance actions, owners of ada may register as DReps and directly -vote on such governance actions or may delegate their voting rights to other registered DReps -who shall vote on their behalf. - ### Section 2 Any owner of ada shall have the option to register as a DRep. Any owner of ada _[, as well as their appointed designees,]_ shall be allowed to delegate their voting stake to one or more -registered DReps, including themselves. DReps may be individuals or coordinated groups. -DReps are entitled to cast votes directly for on-chain governance actions and represent those ada -holders delegating their voting rights to them. - -This voting system shall enshrine a liquid democracy model where owners of ada can seamlessly -select among DReps, register as a DRep, and change their delegation at any time. - -### Section 3 - -_[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.]_ - -#### Workshop Questions - -- Should the Constitution include any guidelines as to the requirements that must be - included by DReps in their respective codes of conduct? -- Should there be one code of conduct for all DReps or should each DRep be allowed to - adopt its own code of conduct? Should DRep codes of conduct be on-chain? -- Should the Constitutional Committee determine whether such codes of conduct are - consistent with the Constitution? -- Should the Constitution include term limits for DReps? - -### Section 4 - -The Cardano community is expected to support the creation, maintenance and ongoing -administration of tools to enable owners of ada to explore and evaluate DRep candidates and -select DReps on such criteria as they deem relevant. - -### Section 5 - -_[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.]_ - -#### Workshop Questions - -- Should the Constitution mandate compensation for DReps? If so, should the Constitution - specify how compensation is determined or include a cap on compensation? -- Should the Constitution require that budgets approved for the Cardano Blockchain - include an allocation from the Cardano Blockchain treasury sufficient to compensate - DReps in such amounts as may be approved from time to time by ada owners. +registered DReps, including themselves. ## ARTICLE V. STAKE POOL OPERATORS @@ -339,31 +126,7 @@ purchase voting rights.]_ SPOs shall have a specific role in approving critical on-chain governance actions which require additional oversight and independence, voting separately and independently from DReps as set -forth in the Cardano Blockchain Guardrails. SPOs shall participate in hard fork initiation -processes as the operators of the nodes that participate in Cardano Blockchain’s consensus -mechanism. - -### Section 2 - -SPOs may act as a check on the power of the Constitutional Committee under exceptional -circumstances by separately voting on "Motion of no-confidence" and "Update -committee/threshold" governance actions. - -### Section 3 - -_[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.]_ - -#### Workshop Questions - -- Should the Constitution include a requirement that ada owners who are both DReps and - SPOs either refrain from voting in both capacities or disclose such dual roles? -- Should the Constitution include other conflicts of interest provisions included? -- Should the Constitution require that SPOs be expected to implement codes of conduct? If - yes, should they be on-chain? Should the Constitutional Committee determine whether - such codes of conduct are consistent with the Constitution?] +forth in the Cardano Blockchain Guardrails. ## ARTICLE VI. CONSTITUTIONAL COMMITTEE @@ -374,51 +137,19 @@ process that ensures governance actions are consistent with this Constitution. T Committee shall comprise a set of owners of ada _[, including their appointed designees,]_ that is collectively responsible for ensuring that on-chain governance actions prior to enactment on- chain, are constitutional. The Constitutional Committee shall be limited to voting on the -constitutionality of governance actions. Constitutional Committee members are expected to have -appropriate expertise to carry out their required responsibilities, considering their past -contributions and involvement in the Cardano Blockchain ecosystem. +constitutionality of governance actions. ### Section 2 The Constitutional Committee shall be composed of _[such number of members as shall be determined from time to time by owners of ada]_ , as consistent with the Cardano Blockchain -Guardrails, and as shall be sufficient to assure the ongoing integrity of the Cardano Blockchain. - -#### Workshop Questions - -- Should the Constitution specify +Guardrails. ### Section 2 -The Constitutional Committee shall be composed of _[such number of members as shall be -determined from time to time by owners of ada]_ , as consistent with the Cardano Blockchain -Guardrails, and as shall be sufficient to assure the ongoing integrity of the Cardano Blockchain. - -#### Workshop Questions - -- Should the Constitution specify how the number of members of the CC are determined? - [Note that the Guardrails specify both a minimum and maximum number of members.] - Members of the Constitutional Committee shall serve such terms _[as shall be determined from -time to time by owners of ada]_ as consistent with the Cardano Blockchain Guardrails, provided -that terms shall not be less than one year. To assure continuity in the operation of Constitutional -Committee, the terms for Constitutional Committee members shall be staggered. - -#### Workshop Questions - -- Should the Constitution specify how term limits for CC members are determined? [Note - that the Guardrails specify both a minimum and maximum term limit.] - -### Section 3 - -The Cardano community shall establish a process from time to time for election of members of -the Constitutional Committee consistent with the requirements of the Cardano Blockchain -Guardrails. - -#### Workshop Questions +time to time by owners of ada]_ as consistent with the Cardano Blockchain Guardrails. -- Should the Constitution include an explicit process for the election of members of the - CC? ### Section 4 @@ -427,12 +158,6 @@ committee/threshold" may be implemented on-chain unless the Constitutional Commi have first determined and affirmed through an on-chain action that such proposal does not violate this Constitution. -The Constitutional Committee shall be considered to be in one of the following two states at all -times: a state of confidence or a state of no-confidence. In a state of no-confidence, members of -the then standing Constitutional Committee must be reinstated or replaced using the "Update -committee/threshold" governance action before any other on-chain governance action may go -forward. - ### Section 5 Constitutional Committee processes shall be transparent. The Constitutional Committee shall @@ -441,46 +166,6 @@ member of the Constitutional committee casting a no vote]_ shall set forth the b decision with reference to specific Articles of this Constitution that are in conflict with a given proposal. -The Constitutional Committee shall operate pursuant to a code of conduct published by the -Constitutional Committee from time to time and shall adopt such policies and procedures as the -Constitutional Committee shall deem necessary in carrying out its duties. - -#### Workshop Questions - -- Should the Constitution require that the Constitutional Committee code of conduct be on- - chain? -- Should the community have any role in approving the Constitutional Committee code of - conduct? If so, how would this work? - -### Section 6 - -The Cardano community is expected to support the creation, maintenance and ongoing -administration of tools as may be necessary and appropriate for the Constitutional Committee to -perform its required functions. - -### Section 7 - -_[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.]_ - -#### Workshop Questions - -- Should the Constitution mandate compensation for CC members? If so, should the - Constitution specify how compensation is determined or include a cap on compensation? -- Should the Constitution require that budgets approved for the Cardano Blockchain - include an allocation from the Cardano Blockchain treasury sufficient to compensate CC - members in such amounts as may be approved from time to time by ada owners. -- Should the Constitution require that the budget include an allocation for the - administrative costs of the CC? If so, how should the amount be determined? If so, - should the Constitution specify who would administer such a budget and whether - expenditures by the CC should be public or subject to audit oversight? - ## ARTICLE VII. AMENDMENTS ### Section 1 @@ -497,1514 +182,3 @@ If the Cardano Blockchain Guardrails Appendix sets forth an amendment threshold Cardano Blockchain Guardrail that is different than the amendment threshold contained in Section 1 of this Article VII, then the threshold set forth in the Cardano Blockchain Guardrails Appendix for such Cardano Blockchain Guardrail shall apply. - -#### Workshop Questions - -- Should the Constitution include a provision preventing Article VII itself from being - amended or allowing any governance action that would have the effect of changing these - amendment requirements? -- Should the Constitution include a category of technical guardrail modifications that - could be overseen and approved by the Constitutional Committee? Is this even possible? - If yes, should such a category be narrowly defined to only address high security risks or - emergency issues? - -## APPENDIX I: CARDANO BLOCKCHAIN GUARDRAILS - -### 1. INTRODUCTION - -To implement Cardano Blockchain on-chain governance pursuant to CIP-1694, it is necessary to -establish sensible guardrails that will enable the Cardano Blockchain to continue to operate in a -secure and sustainable way. - -This Appendix sets forth guardrails that must be applied to Cardano Blockchain on-chain -governance actions, including changes to the protocol parameters and limits on treasury -withdrawals. These guardrails cover both essential, intrinsic limits on settings, and -recommendations that are based on experience, measurement and governance objectives. - -These guardrails are designed to avoid unexpected problems with the operation of the Cardano -Blockchain. They are intended to guide the choice of sensible parameter settings and avoid -potential problems with security, performance or functionality. As described below, some of -these guardrails are automatable and will be enforced via an on-chain script or built-in ledger -rules. - -These guardrails apply to the Cardano Blockchain Layer 1 mainnet environment. They are not -intended to apply to test environments or to other blockchains that use the Cardano Blockchain -software. - -Not all parameters for the Cardano Blockchain can be considered independently. Some -parameters interact with other settings in an intrinsic way. Where known, these interactions are -addressed in this Appendix. - -While the guardrails in this Appendix presently reflect the current state of technical insight, this -Appendix should be treated as a living document. Implementation improvements, new -simulations or performance evaluation results for the Cardano Blockchain may allow some of the -restrictions contained in these guardrails to be relaxed (or, in some circumstances, require them -to be tightened) in due course. - -Additional guardrails may also be needed where, for example, new protocol parameters are -introduced. - -The guardrails set forth in this Appendix may be amended from time to time pursuant to an on- -chain governance action that satisfies the applicable voting threshold as set forth in this -Appendix. Any such amendment to any guardrails shall require and be deemed to be an -amendment to the Constitution itself. - -#### Workshop Questions - -- Should any of the below Guardrails include an amendment threshold different from the - threshold included in Article VII? - -### Terminology and Guidance - -**Should/Should not.** Where this Appendix says that a value "should not" be set below or -above some value, this means that the guardrail is a recommendation or guideline, and the -specific value could be open to discussion or alteration by a suitably expert group recognized by -the Cardano community in light of experience with the Cardano Blockchain governance system -or the operation of the Cardano Blockchain. - -**Must/Must not.** Where this Appendix says that a value "must not" be set below or above -some value, this means that the guardrail is a requirement that will be enforced by Cardano -Blockchain ledger rules, types or other built-in mechanisms where possible, and that if not -followed could cause a protocol failure, security breach or other undesirable outcome. - -**Benchmarking.** Benchmarking refers to careful system level performance evaluation that is -designed to show a-priori that, for example, 95% of blocks will be diffused across a global -network of Cardano Blockchain nodes within the required 5s time interval in all cases. This may -require construction of specific test workflows and execution on a large test network of Cardano -nodes, simulating a global Cardano Blockchain network. - -**Performance analysis.** Performance analysis refers to projecting theoretical performance, -empirical benchmarking or simulation results to predict actual system behavior. For example, -performance results obtained from tests in a controlled test environment (such as a collection of -data centers with known networking properties) may be extrapolated to inform likely -performance behavior in a real Cardano Blockchain network environment. - -**Simulation.** Simulation refers to synthetic execution that is designed to inform -performance/functionality decisions in a repeatable way. For example, the IOSim Cardano -Blockchain module allows the operation of the networking stack to be simulated in a controlled -and repeatable way, allowing issues to be detected before code deployment. - -**Performance Monitoring.** Performance monitoring involves measuring the actual behavior -of the Cardano Blockchain network, for example, by using timing probes to evaluate round-trip -times, or test blocks to assess overall network health. It complements benchmarking and -performance analysis by providing information about actual system behavior that cannot be -obtained using simulated workloads or theoretical analysis. - -**Reverting Changes.** Where performance monitoring shows that actual network behavior -following a change is inconsistent with the performance requirements for the Cardano -Blockchain, then the change must be reverted to its previous state if that is possible. For -example, if the block size is increased from 100KB to 120KB and 95% of blocks are no longer -diffused within 5s, then a change must be made to revert the block size to 100KB. If this is not -possible, then one or more alternative changes must be made that will ensure that the -performance requirements are met. - -**Severity Levels.** Issues that affect the Cardano Blockchain network are classified by -severity level, where: - -- Severity 1 is a critical incident or issue with very high impact to the security, - performance, or functionality of the Cardano Blockchain network. -- Severity 2 is a major incident or issue with significant impact to the security, - performance, or functionality of the Cardano Blockchain network. -- Severity 3 is a minor incident or issue with low impact to the security, performance, or - functionality of the Cardano Blockchain network. - -**Future Performance Requirements.** Planned development such as new mechanisms for out- -of-memory storage may impact block diffusion or other times. When changing parameters, it is -necessary to consider these future performance requirements as well as the current operation of -the Cardano Blockchain. Until development is complete, the requirements will be conservative; -they may then be relaxed to account for actual timing behavior. - -### Automated Checking ("Guardrails Script") - -A script hash is associated with the constitution hash when a **New Constitution or Guardrails -Script** governance action is enacted. It acts as an additional safeguard to the ledger rules and -types, filtering non-compliant governance actions. - -The guardrails script only affects two types of governance actions: - -- **Parameter Update** actions, and -- **Treasury Withdrawal** actions. - -The script is executed when either of these types of governance action is submitted on-chain. -This avoids scenarios where, for example, an erroneous script could prevent the chain from ever -enacting a Hard Fork action, resulting in deadlock. There are three different situations that apply -to script usage. - -**Symbol and Explanation** - -- (y) The script can be used to enforce the guardrail. -- (x) The script cannot be used to enforce the guardrail. -- (~ - reason) The script cannot be used to enforce the guardrail for the reason given, but - future ledger changes could enable this. - -Guardrails may overlap: in this case, the most restrictive set of guardrails will apply. - -Where a parameter is not explicitly listed in this document, then the script **must not** permit -any changes to the parameter. - -Conversely, where a parameter is explicitly listed in this document but no checkable guardrails -are specified, the script **must not** impose any constraints on changes to the parameter. - -### 2. GUARDRAILS AND GUIDELINES ON PROTOCOL PARAMETER UPDATE ACTIONS - -Below are guardrails and guidelines for changing updatable protocol parameter settings via the -protocol parameter update governance action such that the Cardano Blockchain is never in an -unrecoverable state as a result of such changes. - -Note that there are at least five different sources of parameter names, and these are not always -consistent: - -1. The name used in the Genesis file -2. The name used in protocol parameter update governance actions -3. The name used internally in ledger rules -4. The name used in the formal ledger specification -5. The name used in research papers - -Where these parameter names differ, this Appendix uses the second convention. - -#### Guardrails - -**PARAM-01** (y) Any protocol parameter that is not explicitly named in this document **must -not** be changed by a Parameter update governance action. - -**PARAM-02** (y) Where a protocol parameter is explicitly listed in this document but no -checkable guardrails are specified, the guardrails script **must not** impose any constraints on -changes to the parameter. Checkable guardrails are shown by a (y). - -### 2.1. Critical Protocol Parameters - -The below protocol parameters are critical from a security point of view. - -_Parameters that are Critical to the Operation of the Blockchain_ - -- *maximum block body size* (*maxBlockBodySize*) -- *maximum transaction size* (*maxTxSize*) -- *maximum block header size* (*maxBlockHeaderSize*) -- *maximum size of a serialized asset value* (*maxValueSize*) -- *maximum script execution/memory units in a single block* (*maxBlockExecutionUnits[steps/memory]*) -- *minimum fee coefficient* (*txFeePerByte*) -- *minimum fee constant* (*txFeeFixed*) -- *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*) -- *minimum Lovelace deposit per byte of serialized UTxO* (*utxoCostPerByte*) -- *governance action deposit* (*govDeposit*) - -#### Guardrails - -**PARAM-03** (y) Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs **must** say "yes" with a collective support of more than 50% of all active block production stake. This is enforced by the guardrails on the stake pool voting threshold. - -**PARAM-04** (x) At least 3 months **should** normally pass between the publication of an off-chain proposal to change a critical protocol parameter and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation. - -_Parameters that are Critical to the Governance System_ - -- *delegation key Lovelace deposit* (*stakeAddressDeposit*) -- *pool registration Lovelace deposit* (*stakePoolDeposit*) -- *minimum fixed rewards cut for pools* (*minPoolCost*) -- *DRep deposit amount* (*dRepDeposit*) -- *minimal Constitutional Committee size* (*committeeMinSize*) -- *maximum term length (in epochs) for the Constitutional Committee members* (*committeeMaxTermLimit*) - -#### Guardrails - -**PARAM-05** (y) DReps **must** vote "yes" with a collective support of more than 50% of all active voting stake. This is enforced by the guardrails on the DRep voting thresholds. - -**PARAM-06** (x) At least 3 months **should** normally pass between the publication of an off-chain proposal to change a parameter that is critical to the governance system and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation. - -### 2.2. Economic Parameters - -The overall goals when managing economic parameters are to: - -1. Enable long-term economic sustainability for the Cardano Blockchain ecosystem; -2. Ensure that stake pools are adequately rewarded for maintaining the Cardano Blockchain; -3. Ensure that ada holders are adequately rewarded for using stake in constructive ways, including when delegating ada for block production; and -4. Balance economic incentives for different Cardano Blockchain ecosystem stakeholders, including but not limited to Stake Pool Operators, ada holders, DeFi users, infrastructure users, developers (e.g., DApps), and financial intermediaries (e.g., exchanges). - -_Triggers for Change_ - -1. Significant changes in the fiat value of ada resulting in potential problems with security, performance, or functionality. -2. Changes in transaction volumes or types. -3. Community requests or suggestions. -4. Emergency situations that require changes to economic parameters. - -_Counter-indicators_ - -Changes to the economic parameters should not be made in isolation. They need to account for: - -- External economic factors. -- Network security concerns. - -_Core Metrics_ - -- Fiat value of ada resulting in potential problems with security, performance, or functionality. -- Transaction volumes and types. -- Number and health of stake pools. -- External economic factors. - -_Changes to Specific Economic Parameters_ - -**Transaction fee per byte (txFeePerByte) and fixed transaction fee (txFeeFixed)** - -Defines the cost for basic transactions in Lovelace: - -fee(tx) = txFeeFixed + txFeePerByte x nBytes(tx) - -#### Guardrails - -**TFPB-01** (y) *txFeePerByte* **must not** be lower than 30 (0.000030 ada). This protects against low-cost denial of service attacks. - -**TFPB-02** (y) *txFeePerByte* **must not** exceed 1,000 (0.001 ada). This ensures that transactions can be paid for. - -**TFPB-03** (y) *txFeePerByte* **must not** be negative. - -**TFF-01** (y) *txFeeFixed* **must not** be lower than 100,000 (0.1 ada). This protects against low-cost denial of service attacks. - -**TFF-02** (y) *txFeeFixed* **must not** exceed 10,000,000 (10 ada). This ensures that transactions can be paid for. - -**TFF-03** (y) *txFeeFixed* **must not** be negative. - -**TFGEN-01** (x - "should") To maintain a consistent level of protection against denial-of-service attacks, *txFeeFixed* and *txFeePerByte* **should** be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory]). - -**TFGEN-02** (x - unquantifiable) Any changes to *txFeeFixed* or *txFeePerByte* **must** consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee so that it becomes impossible to construct a transaction. - -_UTxO cost per byte (utxoCostPerByte)_ - -Defines the cost for storage in UTxOs: - -- Sets a minimum threshold on ada that is held within a single UTxO (~1 ada minimum, could be >= 50 ada in the worst case). -- Provides protection against low-cost denial of service attack on UTxO storage. This attack has been executed on other chains; it is not theoretical. -- DoS protection decreases in line with the free node memory (proportional to UTxO growth). -- Helps reduce long-term storage costs. -- Provides an incentive to return UTxOs when no longer needed. -- Should significantly exceed minimum tx cost (~0.15 ada). - -#### Guardrails - -**UCPB-01** (y) *utxoCostPerByte* **must not** be lower than 3,000 (0.003 ada). - -**UCPB-02** (y) *utxoCostPerByte* **must not** exceed 6,500 (0.0065 ada). - -**UCPB-03** (y) *utxoCostPerByte* **must not** be zero. - -**UCPB-04** (y) *utxoCostPerByte* **must not** be negative. - -**UCPB-05** (x - "should") Changes **should** account for: - -i) The acceptable cost of attack. -ii) The acceptable time for an attack (at least one epoch is assumed). -iii) The acceptable memory configuration for full node users (assumed to be 16GB for wallets or 24GB for stake pools). -iv) The sizes of UTxOs (~200B per UTxO minimum, up to about 10KB). -v) The current total node memory usage. - -_Stake address deposit (stakeAddressDeposit)_ - -Ensures that stake addresses are retired when no longer needed: - -- Helps reduce long-term storage costs. -- Helps limit CPU and memory costs in the ledger. - -The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Reducing the number of active stake addresses also reduces processing and memory costs at the epoch boundary when calculating stake snapshots. - -#### Guardrails - -**SAD-01** (y) *stakeAddressDeposit* **must not** be lower than 1,000,000 (1 ada). - -**SAD-02** (y) *stakeAddressDeposit* **must not** exceed 5,000,000 (5 ada). - -**SAD-03** (y) *stakeAddressDeposit* **must not** be negative. - -_Stake pool deposit (stakePoolDeposit)_ - -Ensures that stake pools are retired by the stake pool operator when no longer needed by them: - -- Helps reduce long-term storage costs. - -The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Rewards and stake snapshot calculations are also impacted by the number of active stake pools. - -#### Guardrails - -**SPD-01** (y) *stakePoolDeposit* **must not** be lower than 250,000,000 (250 ada). - -**SPD-02** (y) *stakePoolDeposit* **must not** exceed 500,000,000 (500 ada). - -**SPD-03** (y) *stakePoolDeposit* **must not** be negative. - -_Minimum Pool Cost (minPoolCost)_ - -Part of the rewards mechanism: - -- The minimum pool cost is transferred to the pool rewards address before any delegator rewards are paid. - -#### Guardrails - -**MPC-01** (y) *minPoolCost* **must not** be negative. - -**MPC-02** (y) *minPoolCost* **must not** exceed 500,000,000 (500 ada). - -**MPC-03** (x - "should") *minPoolCost* **should** be set in line with the economic cost for operating a pool. - -__Treasury Cut (treasuryCut)_ - -Part of the rewards mechanism: - -- The treasury cut portion of the monetary expansion is transferred to the treasury before any pool rewards are paid. -- Can be set in the range 0.0-1.0 (0%-100%). - -#### Guardrails - -**TC-01** (y) *treasuryCut* **must not** be lower than 0.1 (10%). - -**TC-02** (y) *treasuryCut* **must not** exceed 0.3 (30%). - -**TC-03** (y) *treasuryCut* **must not** be negative. - -**TC-04** (y) *treasuryCut* **must not** exceed 1.0 (100%). - -**TC-05** (~ - no access to change history) *treasuryCut* **must not** be changed more than once in any 36-epoch period (approximately 6 months). - -_Monetary Expansion Rate (monetaryExpansion)_ - -Part of the rewards mechanism: - -- The monetary expansion controls the amount of reserves that is used for rewards each epoch. -- Governs the long-term sustainability of Cardano. -- The reserves are gradually depleted until no rewards are supplied. - -#### Guardrails - -**ME-01** (y) *monetaryExpansion* **must not** exceed 0. - -**ME-02** (y) *monetaryExpansion* **must not** be lower than 0. - -**ME-03** (y) *monetaryExpansion* **must not** be negative. - -**ME-04** (x - "should") *monetaryExpansion* **should not** be varied by more than +/- 10% in any 73-epoch period (approximately 12 months). - -**ME-05** (x - "should") *monetaryExpansion* **should not** be changed more than once in any 36-epoch period (approximately 6 months). - -_Plutus Script Execution Prices (executionUnitPrices[priceSteps/priceMemory])_ - -Defines the fees for executing Plutus scripts: - -- Gives an economic return for Plutus script execution. -- Provides security against low-cost DoS attacks. - -#### Guardrails - -**EIUP-PS-01** (y) *executionUnitPrices[priceSteps]* **must not** exceed 2,000 / 10,000,000. - -**EIUP-PS-02** (y) *executionUnitPrices[priceSteps]* **must not** be lower than 500 / 10,000,000. - -**EIUP-PM-01** (y) *executionUnitPrices[priceMemory]* **must not** exceed 2,000 / 10,000. - -**EIUP-PM-02** (y) *executionUnitPrices[priceMemory]* **must not** be lower than 400 / 10,000. - -**EIUP-GEN-01** (x - "similar to") The execution prices **must** be set so that: - -- i) the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum-sized non-script transaction and -- ii) the cost of executing a transaction with maximum memory units is similar to the cost of a maximum-sized non-script transaction. - -**EIUP-GEN-02** (x - "should") The execution prices **should** be adjusted whenever transaction fees are adjusted (*txFeeFixed/txFeePerByte*). The goal is to ensure that the processing delay is similar for "full" transactions, regardless of their type. - -- This helps ensure that the requirements on block diffusion/propagation times are met. - -_Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte)_ - -Defines the cost for using Plutus reference scripts in Lovelace. - -#### Guardrails - -**MFRS-01** (y) *minFeeRefScriptCoinsPerByte* **must not** exceed 1,000 (0.001 ada). - -- This ensures that transactions can be paid for. - -**MFRS-02** (y) *minFeeRefScriptCoinsPerByte* **must not** be negative. - -**MFRS-03** (x - "should") To maintain a consistent level of protection against denial-of-service attacks, *minFeeRefScriptCoinsPerByte* **should** be adjusted whenever Plutus Execution prices are adjusted (*executionUnitPrices[steps/memory]*) and whenever *txFeeFixed* is adjusted. - -**MFRS-04** (x - unquantifiable) Any changes to *minFeeRefScriptCoinsPerByte* **must** consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee. - -### 2.3. Network Parameters - -The overall goals when managing the Cardano Blockchain network parameters are to: - -1. 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. -2. Balance traffic demands for different user groups, including payment transactions, minters of Fungible/Non-Fungible Tokens, Plutus scripts, DeFi developers, Stake Pool Operators, and voting transactions. - -_Triggers for Change_ - -Changes to network parameters may be triggered by: - -1. Measured changes in traffic demands over a 2-epoch period (10 days). -2. Anticipated changes in traffic demands. -3. Community requests. - -_Counter-indicators_ - -Changes may need to be reversed and/or should not be enacted in the event of: - -- Excessive block propagation delays. -- Stake pools being unable to handle traffic volume. -- Scripts being unable to complete execution. - -_Core Metrics_ - -All decisions on parameter changes should be informed by: - -- Block propagation delay profile. -- Traffic volume (block size over time). -- Script volume (size of scripts and execution units). -- Script execution cost benchmarks. -- Block propagation delay/diffusion benchmarks. - -Detailed benchmarking results are required to confirm the effect of any changes on mainnet performance or behavior prior to enactment. The effects of different transaction mixes must be analyzed, including normal transactions, Plutus scripts, and governance actions. - -#### Guardrails - -**NETWORK-01** (x - "should") No individual network parameter **should** change more than once per two epochs. - -**NETWORK-02** (x - "should") Only one network parameter **should** be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits. - -_Changes to Specific Network Parameters_ - -_Block Size (maxBlockBodySize)_ - -The maximum size of a block, in Bytes. - -#### Guardrails - -**MBBS-01** (y) *maxBlockBodySize* **must not** exceed 122,880 Bytes (120KB). - -**MBBS-02** (y) *maxBlockBodySize* **must not** be lower than 24,576 Bytes (24KB). - -**MBBS-03** (x - "exceptional circumstances") *maxBlockBodySize* **must not** be decreased, other than in exceptional circumstances where there are potential problems with security, performance, or functionality. - -**MBBS-04** (~ - no access to existing parameter values) *maxBlockBodySize* **must** be large enough to include at least one transaction (that is, *maxBlockBodySize* **must** be at least *maxTxSize*). - -**MBBS-05** (x - "should") *maxBlockBodySize* **should** be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch. - -**MBBS-06** (x - "should") The block size **should not** induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation, and benchmarking. - -**MBBS-07** (x - "unquantifiable") The impact of any change to *maxBlockBodySize* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to *maxBlockBodySize* must also consider future requirements for Plutus script execution (*maxBlockExecutionUnits[steps]*) against the total block diffusion target of 3s with 95% block propagation within 5s. The limit on maximum block size may be increased in the future if this is supported by benchmarking and monitoring results. - -_Transaction Size (maxTxSize)_ - -The maximum size of a transaction, in Bytes. - -#### Guardrails - -**MTS-01** (y) *maxTxSize* **must not** exceed 32,768 Bytes (32KB). - -**MTS-02** (y) *maxTxSize* **must not** be negative. - -**MTS-03** (~ - no access to existing parameter values) *maxTxSize* **must not** be decreased. - -**MTS-04** (~ - no access to existing parameter values) *maxTxSize* **must not** exceed *maxBlockBodySize*. - -**MTS-05** (x - "should") *maxTxSize* **should not** be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably **should** be increased by 2,048 Bytes (2KB) or less per epoch. - -**MTS-06** (x - "should") *maxTxSize* **should not** exceed 1/4 of the block size. - -_Memory Unit Limits (maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory])_ - -The limit on the maximum number of memory units that can be used by Plutus scripts, either per-transaction or per-block. - -#### Guardrails - -**MTEU-M-01** (y) *maxTxExecutionUnits[memory]* **must not** exceed 40,000,000 units. - -**MTEU-M-02** (y) *maxTxExecutionUnits[memory]* **must not** be negative. - -**MTEU-M-03** (~ - no access to existing parameter values) *maxTxExecutionUnits[memory]* **must not** be decreased. - -**MTEU-M-04** (x - "should") *maxTxExecutionUnits[memory]* **should not** be increased by more than 2,500,000 units in any epoch. - -**MBEU-M-01** (y) *maxBlockExecutionUnits[memory]* **must not** exceed 120,000,000 units. - -**MBEU-M-02** (y) *maxBlockExecutionUnits[memory]* **must not** be negative. - -**MBEU-M-03** (x - "should") *maxBlockExecutionUnits[memory]* **should not** be changed (increased or decreased) by more than 10,000,000 units in any epoch. - -**MBEU-M-04** (x - unquantifiable) The impact of any change to *maxBlockExecutionUnits[memory]* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the diffusion/propagation time budgets, as also impacted by *maxBlockExecutionUnits[steps]*. Any increase **must** also consider previously agreed future requirements for the total block size (*maxBlockBodySize*) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. - -**MEU-M-01** (~ - no access to existing parameter values) *maxBlockExecutionUnits[memory]* **must not** be less than *maxTxExecutionUnits[memory]*. - -_CPU Unit Limits (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps])_ - -The limit on the maximum number of CPU steps that can be used by Plutus scripts, either per-transaction or per-block. - -#### Guardrails - -**MTEU-S-01** (y) *maxTxExecutionUnits[steps]* **must not** exceed 15,000,000,000 (15Bn) units. - -**MTEU-S-02** (y) *maxTxExecutionUnits[steps]* **must not** be negative. - -**MTEU-S-03** (~ - no access to existing parameter values) *maxTxExecutionUnits[steps]* **must not** be decreased. - -**MTEU-S-04** (x - "should") *maxTxExecutionUnits[steps]* **should not** be increased by more than 500,000,000 (500M) units in any epoch (5 days). - -**MBEU-S-01** (y) *maxBlockExecutionUnits[steps]* **must not** exceed 40,000,000,000 (40Bn) units. - -**MBEU-S-02** (y) *maxBlockExecutionUnits[steps]* **must not** be negative. - -**MBEU-S-03** (x - "should") *maxBlockExecutionUnits[steps]* **should not** be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days). - -**MBEU-S-04** (x - unquantifiable) The impact of the change to *maxBlockExecutionUnits[steps]* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by *maxBlockExecutionUnits[memory]*. Any increase **must** also consider previously identified future requirements for the total block size (*maxBlockBodySize*) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but **must** be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. - -**MEU-S-01** (~ - no access to existing parameter values) *maxBlockExecutionUnits[steps]* **must not** be less than *maxTxExecutionUnits[steps]*. - -_Block Header Size (maxBlockHeaderSize)_ - -The size of the block header. - -**Note:** Increasing the block header size may affect the overall block size (*maxBlockBodySize*). - -#### Guardrails - -**MBHS-01** (y) *maxBlockHeaderSize* **must not** exceed 5,000 Bytes. - -**MBHS-02** (y) *maxBlockHeaderSize* **must not** be negative. - -**MBHS-03** (x - "largest valid header" is subject to change) *maxBlockHeaderSize* **must** be large enough for the largest valid header. - -**MBHS-04** (x - "should") *maxBlockHeaderSize* **should** only normally be increased if the protocol changes. - -**MBHS-05** (x - "should") *maxBlockHeaderSize* **should** be within TCP's initial congestion window (3 or 10 MTUs). - -### 2.4. Technical/Security Parameters - -The overall goals when managing the technical/security parameters are: - -1. Ensure the security of the Cardano network in terms of decentralization, protection against Sybil and 51% attacks, and protection against denial of service attacks. -2. Enable changes to the Plutus language. - -_Triggers for Change_ - -1. Changes in the number of active SPOs. -2. Changes to the Plutus language. -3. Security threats. -4. Community requests. - -_Counter-indicators_ - -- Economic concerns, e.g., when changing the number of stake pools. - -_Core Metrics_ - -- Number of stake pools. -- Level of decentralization. - -_Changes to Specific Technical/Security Parameters_ - -_Target Number of Stake Pools (stakePoolTargetNum)_ - -Sets the target number of stake pools: - -- The expected number of pools when the network is in the equilibrium state. -- Primarily a security parameter, ensuring decentralization by pool division/replication. -- Has an economic effect as well as a security effect; economic advice is also required when changing this parameter. -- Large changes in this parameter will trigger mass redelegation events. - -#### Guardrails - -**SPTN-01** (y) *stakePoolTargetNum* **must not** be lower than 250. - -**SPTN-02** (y) *stakePoolTargetNum* **must not** exceed 2,000. - -**SPTN-03** (y) *stakePoolTargetNum* **must not** be negative. - -**SPTN-04** (y) *stakePoolTargetNum* **must not** be zero. - -_Pledge Influence Factor (poolPledgeInfluence)_ - -Enables the pledge protection mechanism: - -- Provides protection against Sybil attack. -- Higher values reward pools that have more pledge and penalize pools that have less pledge. -- Has an economic effect as well as technical effect; economic advice is also required. -- Can be set in the range 0.0-infinity. - -#### Guardrails - -**PPI-01** (y) *poolPledgeInfluence* **must not** be lower than 0.1. - -**PPI-02** (y) *poolPledgeInfluence* **must not** exceed 1.0. - -**PPI-03** (y) *poolPledgeInfluence* **must not** be negative. - -**PPI-04** (x - "should") *poolPledgeInfluence* **should not** vary by more than +/- 10% in any 18-epoch period (approximately 3 months). - -_Pool Retirement Window (poolRetireMaxEpoch)_ - -Defines the maximum number of epochs notice that a pool can give when planning to retire. - -#### Guardrails - -**PRME-01** (y) *poolRetireMaxEpoch* **must not** be negative. - -**PRME-02** (x - "should") *poolRetireMaxEpoch* **should not** be lower than 1. - -_Collateral Percentage (collateralPercentage)_ - -Defines how much collateral must be provided when executing a Plutus script as a percentage of the normal execution cost: - -- Collateral is additional to fee payments. -- If a script fails to execute, then the collateral is lost. -- The collateral is never lost if a script executes successfully. -- Provides security against low-cost attacks by making it more expensive rather than less expensive to execute failed scripts. - -#### Guardrails - -**CP-01** (y) *collateralPercentage* **must not** be lower than 100. - -**CP-02** (y) *collateralPercentage* **must not** exceed 200. - -**CP-03** (y) *collateralPercentage* **must not** be negative. - -**CP-04** (y) *collateralPercentage* **must not** be zero. - -_Maximum number of collateral inputs (maxCollateralInputs)_ - -Defines the maximum number of inputs that can be used for collateral when executing a Plutus script. - -#### Guardrails - -**MCI-01** (y) *maxCollateralInputs* **must not** be lower than 1. - - - -The limit on the serialized size of the Value in each output. - -#### Guardrails - -**MVS-01** (y) *maxValueSize* **must not** exceed 12,288 Bytes (12KB). - -**MVS-02** (y) *maxValueSize* **must not** be negative. - -**MVS-03** (~ - no access to existing parameter values) *maxValueSize* **must** be less than *maxTxSize*. - -**MVS-04** (~ - no access to existing parameter values) *maxValueSize* **must not** be reduced. - -**MVS-05** (x - "sensible output" is subject to interpretation) *maxValueSize* **must** be large enough to allow sensible outputs (e.g., any existing on-chain output or anticipated outputs that could be produced by new ledger rules). - -_Plutus Cost Models (costModels)_ - -Defines the base costs for each Plutus primitive in terms of CPU and memory units: - -- There are about 150 distinct micro-parameters in total. -- Cost models are defined for each Plutus language version. A new language version may introduce additional micro-parameters or remove existing micro-parameters. - -#### Guardrails - -**PCM-01** (x - unquantifiable) *Cost model* values **must** be set by benchmarking on a reference architecture. - -**PCM-02** (x - primitives and language versions aren't introduced in transactions) The *cost model* **must** be updated if new primitives are introduced or a new Plutus language version is added. - -**PCM-03** (~ - no access to *Plutus cost model* parameters) *Cost model* values **should not** be negative. - -**PCM-04** (~ - no access to *Plutus cost model* parameters) A *cost model* **must** be supplied for each Plutus language version that the protocol supports. - -### 2.5. Governance Parameters - -The overall goals when managing the governance parameters are to: - -1. Ensure governance stability. -2. Maintain a representative form of governance as outlined in CIP-1694. - -_Triggers for Change_ - -Changes to governance parameters may be triggered by: - -1. Community requests. -2. Regulatory requirements. -3. Unexpected or unwanted governance outcomes. -4. Entering a state of no confidence. - -_Counter-indicators_ - -Changes may need to be reversed and/or should not be enacted in the event of: - -- Unexpected effects on governance. -- Excessive Layer 1 load due to on-chain voting or excessive numbers of governance actions. - -_Core Metrics_ - -All decisions on parameter changes should be informed by: - -- Governance participation levels. -- Governance behaviors and patterns. -- Regulatory considerations. -- Confidence in the governance system. -- The effectiveness of the governance system in managing necessary change. - -_Changes to Specific Governance Parameters_ - -_Deposit for Governance Actions (govDeposit)_ - -The deposit that is charged when submitting a governance action: - -- Helps to limit the number of actions that are submitted. - -#### Guardrails - -**GD-01** (y) *govDeposit* **must not** be negative. - -**GD-02** (y) *govDeposit* **must not** be lower than 1,000,000 (1 ada). - -**GD-03** (y) *govDeposit* **must not** exceed 10,000,000,000,000 (10 million ada). - -**GD-04** (x - "should") *govDeposit* **should** be adjusted in line with fiat changes. - -_Deposit for DReps (dRepDeposit)_ - -The deposit that is charged when registering a DRep: - -- Helps to limit the number of active DReps. - -#### Guardrails - -**DRD-01** (y) *dRepDeposit* **must not** be negative. - -**DRD-02** (y) *dRepDeposit* **must not** be lower than 1,000,000 (1 ada). - -**DRD-03** (y) *dRepDeposit* **must not** exceed 100,000,000,000 (100,000 ada). - -**DRD-04** (x - "should") *dRepDeposit* **should** be adjusted in line with fiat changes. - -_DRep Activity Period (dRepActivity)_ - -The period (as a whole number of epochs) after which a DRep is considered to be inactive for vote calculation purposes, if they do not vote on any proposal. - -#### Guardrails - -**DRA-01** (y) *dRepActivity* **must not** be lower than 13 epochs (2 months). - -**DRA-02** (y) *dRepActivity* **must not** exceed 37 epochs (6 months). - -**DRA-03** (y) *dRepActivity* **must not** be negative. - -**DRA-04** (~ - no access to existing parameter values) *dRepActivity* **must** be greater than *govActionLifetime*. - -**DRA-05** (x - "should") *dRepActivity* **should** be calculated in human terms (2 months, etc.). - -_DRep and SPO Governance Action Thresholds (dRepVotingThresholds[...], poolVotingThresholds[...])_ - -Thresholds on the active voting stake that is required to ratify a specific type of governance action by either DReps or SPOs: - -- Ensures legitimacy of the action. - -The threshold parameters are listed below: - -**dRepVotingThresholds**: -- *dvtCommitteeNoConfidence* -- *dvtCommitteeNormal* -- *dvtHardForkInitiation* -- *dvtMotionNoConfidence* -- *dvtPPEconomicGroup* -- *dvtPPGovGroup* -- *dvtPPNetworkGroup* -- *dvtPPTechnicalGroup* -- *dvtTreasuryWithdrawal* -- *dvtUpdateToConstitution* - -**poolVotingThresholds**: -- *pvtCommitteeNoConfidence* -- *pvtCommitteeNormal* -- *pvtHardForkInitiation* -- *pvtMotionNoConfidence* -- *pvtPPSecurityGroup* - -#### Guardrails - -**VT-GEN-01** (y) All thresholds **must** be greater than 50% and less than or equal to 100%. - -**VT-GEN-02** (y) Economic, network, and technical parameter thresholds **must** be in the range 51%-75%. - -**VT-GEN-03** (y) Governance parameter thresholds **must** be in the range 75%-90%. - -**VT-HF-01** (y) **Hard fork** action thresholds **must** be in the range 51%-80%. - -**VT-CON-01** (y) **New Constitution or guardrails script action** thresholds **must** be in the range 65%-90%. - -**VT-CC-01** (y) **Update Constitutional Committee action** thresholds **must** be in the range 51%-90%. - -**VT-NC-01** (y) **No confidence** action thresholds **must** be in the range 51%-75%. - -_Governance Action Lifetime (govActionLifetime)_ - -The period after which a governance action will expire if it is not enacted: - -- As a whole number of epochs. - -#### Guardrails - -**GAL-01** (y) *govActionLifetime* **must not** be lower than 1 epoch (5 days). - -**GAL-03** (x - "should") *govActionLifetime* **should not** be lower than 2 epochs (10 days). - -**GAL-02** (y) *govActionLifetime* **must not** exceed 15 epochs (75 days). - -**GAL-04** (x - "should") *govActionLifetime* **should** be calibrated in human terms (e.g., 30 days, two weeks) to allow sufficient time for voting, etc., to take place. - -**GAL-05** (~ - no access to existing parameter values) *govActionLifetime* **must** be less than *dRepActivity*. - -_Maximum Constitutional Committee Term (committeeMaxTermLimit)_ - -The limit on the maximum term that a committee member may serve. - -#### Guardrails - -**CMTL-01** (y) *committeeMaxTermLimit* **must not** be zero. - -**CMTL-02** (y) *committeeMaxTermLimit* **must not** be negative. - -**CMTL-03** (y) *committeeMaxTermLimit* **must not** be lower than 18 epochs (90 days, or approximately 3 months). - -**CMTL-04** (y) *committeeMaxTermLimit* **must not** exceed 293 epochs (approximately 4 years). - -**CMTL-05** (x - "should") *committeeMaxTermLimit* **should not** exceed 220 epochs (approximately 3 years). - -_The minimum size of the Constitutional Committee (committeeMinSize)_ - -The least number of members that can be included in a Constitutional Committee following a governance action to change the Constitutional Committee. - -#### Guardrails - -**CMS-01** (y) *committeeMinSize* **must not** be negative. - -**CMS-02** (y) *committeeMinSize* **must not** be lower than 3. - -**CMS-03** (y) *committeeMinSize* **must not** exceed 10. - -### 2.6. Monitoring and Reversion of Parameter Changes - -All network parameter changes **must** be monitored carefully for no less than 2 epochs (10 days): - -- Changes **must** be reverted as soon as possible if block propagation delays exceed 4.5s for more than 5% of blocks over any 6-hour rolling window. - -All other parameter changes should be monitored carefully for any adverse effects on performance, security, or functionality. If such effects are observed, appropriate actions, including reversion to previous parameters, should be taken. - -A specific reversion/recovery plan **must be** produced for each parameter change. This plan must include: - -- Which parameters need to change and in which ways in order to return to the previous state (or a similar state). -- How to recover the network in the event of a disastrous failure. - -This plan **should** be followed if problems are observed following the parameter change. Note that not all changes can be reverted. Additional care must be taken when making changes to these parameters. - -### 2.7. Non-Updatable Protocol Parameters - -Some fundamental protocol parameters cannot be changed by the Protocol Parameter Update governance action. These parameters can only be changed in a new Genesis file as part of a hard fork. It is not necessary to provide specific guardrails on updating these parameters. - -### 3. GUARDRAILS AND GUIDELINES ON TREASURY WITHDRAWAL ACTIONS - -**Treasury withdrawal** actions specify the destination and amount of a number of withdrawals from the Cardano treasury. - -#### Guardrails - -**TREASURY-01** (x) DReps **must** define a net change limit for the Cardano Treasury's balance per period of time. - -**TREASURY-02** (x) The budget for the Cardano Treasury **must not** exceed the net change limit for the Cardano Treasury's balance per period of time. - -**TREASURY-03** (x) The budget for the Cardano Treasury **must** be denominated in ada. - -**TREASURY-04** (x) Treasury withdrawals **must not** be ratified until there is a community-approved Cardano budget then in effect pursuant to a previous on-chain governance action agreed by the DReps with a threshold of greater than 50% of the active voting stake. - -### 4. GUARDRAILS AND GUIDELINES ON HARD FORK INITIATION ACTIONS - -The **hard fork initiation** action requires both a new major and a new minor protocol version to be specified: - -- As positive integers. - -As the result of a hard fork, new updatable protocol parameters may be introduced. Guardrails may be defined for these parameters, which will take effect following the hard fork. Existing updatable protocol parameters may also be deprecated by the hard fork, in which case the guardrails become obsolete for all future changes. - -#### Guardrails - -**HARDFORK-01** (~ - no access to existing parameter values) The major protocol version **must** be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version **must** be zero. - -**HARDFORK-02** (~ - no access to existing parameter values) The minor protocol version **must** be no less than the minor version that will be enacted immediately prior to this change. - -**HARDFORK-03** (~ - no access to existing parameter values) At least one of the protocol versions (major or minor or both) **must** change. - -**HARDFORK-04** (x) At least 85% of stake pools by active stake **should** have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version. - -**HARDFORK-05** (x) Any new updatable protocol parameters that are introduced with a hard fork **must** be included in this Appendix and suitable guardrails defined for those parameters. - -**HARDFORK-06** (x) Settings for any new protocol parameters that are introduced with a hard fork **must** be included in the appropriate Genesis file. - -**HARDFORK-07** (x) Any deprecated protocol parameters **must** be indicated in this Appendix. - -**HARDFORK-08** (~ - no access to *Plutus cost model* parameters) New Plutus versions **must** be supported by a version-specific *Plutus cost model* that covers each primitive that is available in the new Plutus version. - -### 5. GUARDRAILS AND GUIDELINES ON UPDATE CONSTITUTIONAL COMMITTEE OR THRESHOLD ACTIONS - -**Update Constitutional Committee or Threshold** governance actions may change the size, composition, or required voting thresholds for the Constitutional Committee. - -#### Guardrails - -**UPDATE-CC-01** (x) **Update Constitutional Committee and/or threshold** **and/or term** governance actions **must not** be ratified until ada holders have ratified through an on-chain governance action the Final Constitution. - -### 6. GUARDRAILS AND GUIDELINES ON NEW CONSTITUTION OR GUARDRAILS SCRIPT ACTIONS - -New constitution or guardrails script actions change the hash of the on-chain constitution and the associated guardrails script. - -#### Guardrails - -**NEW-CONSTITUTION-01** (x) A **New Constitution** **or Guardrails Script** governance action **must** be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action. - -### 7. GUARDRAILS AND GUIDELINES ON NO CONFIDENCE ACTIONS - -**No confidence** actions signal a state of no confidence in the governance system. No guardrails are imposed on **No Confidence** actions. - -#### Guardrails - -- None - -### 8. GUARDRAILS AND GUIDELINES ON INFO ACTIONS - -**Info** actions are not enacted on-chain. No guardrails are imposed on **Info** actions. - -#### Guardrails - -- None - -### 9. GUARDRAILS DURING THE INTERIM PERIOD - -_Interim Period_ - -The Interim Period begins with the Chang Hard-Fork and ends after a community-ratified Final Constitution is enacted on-chain. Throughout the Interim Period, technical and constitution-enforced triggers will progressively turn on the features of CIP-1694. - -_Interim Period Technical Rollout:_ - -- The Chang Hard Fork will enable three initial CIP-1694 governance actions and enable the representative framework to be established. - -These actions are the **"Info"**, **"Hard-fork initiation"**, and **"Protocol parameter changes"** actions. - -ada holders will be able to register as and delegate to DReps immediately after the hard fork but, as described in CIP-1694, DRep voting will not be available, except on **"Info"** actions. This ensures that ada holders have sufficient time to choose their voting delegations. - -SPOs will be able to vote as described in CIP-1694. - -**"Hard-fork initiation"** and **"Protocol parameter changes"** actions will also be ratified by the Constitutional Committee. - -ada holders will be able to withdraw their staking rewards as usual. - -- A subsequent hard fork, ratified by the Constitutional Committee and SPOs, shortly after the Chang Hard Fork, will enable the four remaining CIP-1694 governance actions: - - - **"Treasury withdrawals"**, - - **"Motion of no-confidence"**, - - **"Update constitutional committee and/or threshold and/or terms"**, and - - **"New constitution or guardrails script"**. - -At this point, DRep voting will be enabled and staking rewards can only be withdrawn if the ada holder has delegated their vote (including to the pre-defined Abstain/No Confidence voting options). - -#### Guardrails - -**INTERIM-01** (x) To provide sufficient time for DReps to register and campaign and for ada holders to choose their initial voting delegations, at least 18 epochs (90 days, or approximately 3 months) **must** elapse after the Chang hard fork before the subsequent hard fork can be ratified. Once the subsequent hard fork is enacted, DRep voting can occur as described in CIP-1694. - -**INTERIM-02** (x) Treasury withdrawals **must not** be ratified until there is a community-approved Cardano Blockchain Ecosystem budget then in effect pursuant to a previous on-chain governance action. - -**INTERIM-03** (x) Treasury withdrawals **must** be consistent with the community-approved Cardano Blockchain ecosystem budget(s). - -**INTERIM-04** (x) ada holders **must** have ratified the Final Constitution as specified in Appendix II before ratifying any other proposed **"new constitution"**, **"update constitutional committee and/or threshold and/or terms"**, and **"motion of no-confidence"** governance actions. - -**INTERIM-05** (x) **"New guardrails script"** actions that are consistent with the Interim Constitution may be ratified during the interim period, provided the Interim Constitution itself is not changed. - -### 10. LIST OF PROTOCOL PARAMETER GROUPS - -The protocol parameters are grouped by type, allowing different thresholds to be set for each group. - -_The network group consists of:_ - -- *maximum block body size* (*maxBlockBodySize*) -- *maximum transaction size* (*maxTxSize*) -- *maximum block header size* (*maxBlockHeaderSize*) -- *maximum size of a serialized asset value* (*maxValueSize*) -- *maximum script execution units in a single transaction* (*maxTxExecutionUnits[steps]*) -- *maximum script execution units in a single block* (*maxBlockExecutionUnits[steps]*) -- *maximum number of collateral inputs* (*maxCollateralInputs*) - -_The economic group consists of:_ - -- *minimum fee coefficient* (*txFeePerByte*) -- *minimum fee constant* (*txFeeFixed*) -- *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*) -- *delegation key Lovelace deposit* (*stakeAddressDeposit*) -- *pool registration Lovelace deposit* (*stakePoolDeposit*) -- *monetary expansion* (*monetaryExpansion*) -- *treasury expansion* (*treasuryCut*) -- *minimum fixed rewards cut for pools* (*minPoolCost*) -- *minimum Lovelace deposit per byte of serialized UTxO* (*utxoCostPerByte*) -- *prices of Plutus execution units* (*executionUnitPrices[priceSteps/priceMemory]*) - -_The technical group consists of:_ - -- *pool pledge influence* (*poolPledgeInfluence*) -- *pool retirement maximum epoch* (*poolRetireMaxEpoch*) -- *desired number of pools* (*stakePoolTargetNum*) -- *Plutus execution cost models* (*costModels*) -- *proportion of collateral needed for scripts* (*collateralPercentage*) - -_The governance group consists of all the new protocol parameters that are introduced in CIP-1694:_ - -- *governance voting thresholds* (*dRepVotingThresholds[...], poolVotingThresholds[...]*) -- *governance action maximum lifetime in epochs* (*govActionLifetime*) -- *governance action deposit* (*govActionDeposit*) -- *DRep deposit amount* (*dRepDeposit*) -- *DRep activity period in epochs* (*dRepActivity*) -- *minimal constitutional committee size* (*committeeMinSize*) -- *maximum term length (in epochs) for the constitutional committee members* (*committeeMaxTermLimit*) - -## APPENDIX II: INTERIM CONSTITUTION - -### 1. PREAMBLE - -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. - -### 2. INTERIM GOVERNANCE STRUCTURE - -#### Section 1: Interim Constitutional Committee - -The Interim Constitutional Committee (ICC) shall be established to oversee the governance of the Cardano Blockchain during the Interim Period. The ICC shall have the authority to approve or reject governance actions, ensure compliance with the Interim Constitution, and oversee the transition to the Final Constitution. - -**Composition:** -- The ICC shall consist of a minimum of 3 and a maximum of 10 members. -- Members shall be selected based on their expertise, contributions to the Cardano ecosystem, and commitment to decentralized governance. - -**Term:** -- The term of the ICC members shall not exceed 18 epochs (90 days) unless extended by a community vote. - -**Powers:** -- The ICC shall have the power to veto governance actions that are deemed unconstitutional or detrimental to the Cardano ecosystem. -- The ICC shall ensure that all governance actions comply with the guardrails established in this Interim Constitution. - -**Dissolution:** -- The ICC shall be dissolved upon the ratification of the Final Constitution, at which point a new Constitutional Committee shall be established. - -#### Section 2: Interim Voting Mechanisms - -During the Interim Period, governance actions shall be subject to the following voting mechanisms: - -**DReps Voting:** -- Delegated Representatives (DReps) shall vote on governance actions on behalf of ADA holders. -- DRep votes shall be weighted according to the amount of ADA delegated to them. -- A simple majority of the active voting stake is required to approve a governance action. - -**SPOs Voting:** -- Stake Pool Operators (SPOs) shall vote on specific governance actions, particularly those related to protocol parameters and technical changes. -- SPO votes shall be weighted according to the amount of ADA staked in their pools. -- A simple majority of the active stake pool stake is required to approve a governance action. - -**Community Sentiment Votes:** -- Community sentiment votes (Info actions) shall be conducted to gauge the community's opinion on non-binding governance actions. -- Info actions shall not have any on-chain effects other than recording the outcome of the vote. - -### 3. TRANSITION TO FINAL CONSTITUTION - -#### Section 1: Development and Ratification - -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: - -1. **Community Consultation:** - - The Cardano community shall be actively involved in the consultation process, providing input and feedback on the draft Final Constitution. - -2. **Drafting Committee:** - - A Drafting Committee shall be established to compile and refine the input from the community into a cohesive Final Constitution. - - The Drafting Committee shall consist of representatives from various stakeholder groups, including ADA holders, DReps, SPOs, and developers. - -3. **Public Review:** - - The draft Final Constitution shall be made available for public review and comment for a minimum of 6 epochs (30 days). - -4. **Ratification Vote:** - - A ratification vote shall be conducted to approve the Final Constitution. - - A minimum of 67% of the active voting stake must support the Final Constitution for it to be ratified. - -#### Section 2: Implementation - -Upon ratification of the Final Constitution: - -1. **Establishment of the Constitutional Committee:** - - A new Constitutional Committee shall be established in accordance with the Final Constitution. - - The Interim Constitutional Committee shall be dissolved. - -2. **Transition of Governance Powers:** - - All governance powers and responsibilities shall transition from the Interim Constitutional Committee to the new Constitutional Committee. - - Any pending governance actions under the Interim Constitution shall be carried over and processed under the Final Constitution. - -3. **Guardrails and Protocol Parameters:** - - 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. - -### 4. AMENDMENTS TO THE INTERIM CONSTITUTION - -Amendments to this Interim Constitution may be proposed by any ADA holder, DRep, or SPO. The process for amending the Interim Constitution is as follows: - -1. **Proposal Submission:** - - The proposed amendment shall be submitted as a governance action, accompanied by a rationale and supporting documentation. - -2. **Review by the ICC:** - - The Interim Constitutional Committee shall review the proposed amendment for compliance with the guardrails and overall impact on the Cardano ecosystem. - -3. **Community Vote:** - - The proposed amendment shall be put to a community vote, requiring a minimum of 67% of the active voting stake to approve the amendment. - -4. **Implementation:** - - If approved, the amendment shall be implemented and the Interim Constitution shall be updated accordingly. - -### 5. FINAL PROVISIONS - -#### Section 1: Supremacy Clause - -In the event of a conflict between this Interim Constitution and any governance action or protocol parameter, this Interim Constitution shall prevail. - -#### Section 2: Continuity Clause - -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. - -#### Section 3: Interpretation - -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. - -#### Section 4: Dissolution of Interim Governance Structures - -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. - -## APPENDIX III: GLOSSARY OF TERMS - -**ADA:** The native cryptocurrency of the Cardano Blockchain. - -**Cardano Blockchain:** A decentralized blockchain platform that enables the development of smart contracts, decentralized applications (DApps), and digital assets. - -**CIP-1694:** A Cardano Improvement Proposal that outlines the governance framework for the Cardano Blockchain. - -**Constitutional Committee:** The governance body responsible for ensuring that governance actions are consistent with the Cardano Constitution. - -**DRep (Delegated Representative):** An individual or entity that represents ADA holders in the on-chain governance process by voting on governance actions on their behalf. - -**Epoch:** A time period used in the Cardano Blockchain, typically lasting 5 days. - -**Final Constitution:** The permanent governance framework for the Cardano Blockchain, to be ratified by the community and replace the Interim Constitution. - -**Guardrails:** Specific guidelines and constraints that govern the parameters and actions within the Cardano Blockchain ecosystem. - -**Hard Fork:** A protocol upgrade that changes the blockchain's rules and requires all nodes to upgrade to the new version. - -**Interim Constitution:** The temporary governance framework for the Cardano Blockchain during the transition to the Final Constitution. - -**SPO (Stake Pool Operator):** An individual or entity responsible for operating a stake pool, which participates in the consensus mechanism of the Cardano Blockchain. - -**Treasury:** A pool of ADA used to fund development and other initiatives within the Cardano ecosystem. - -## APPENDIX IV: INTERIM PERIOD ACTIONS AND TIMELINE - -### 1. INITIAL GOVERNANCE ACTIONS - -During the Interim Period, the following initial governance actions shall be prioritized: - -1. **Establishment of the Interim Constitutional Committee (ICC):** - - The ICC shall be established within 2 epochs following the Chang Hard Fork. - -2. **Delegated Representative (DRep) Registration:** - - DReps shall be allowed to register immediately following the Chang Hard Fork. - - ADA holders shall have the option to delegate their voting rights to registered DReps. - -3. **Community Sentiment (Info) Actions:** - - Info actions shall be used to gauge community sentiment on key governance topics. - - These actions shall not have on-chain effects but shall inform future governance decisions. - -4. **Initial Hard Fork Initiation:** - - The first hard fork initiation action shall be proposed to enable additional governance actions, such as Treasury withdrawals. - -### 2. TIMELINE FOR FINAL CONSTITUTION DEVELOPMENT - -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. - -1. **Community Consultation Phase:** - - Duration: 6 epochs (30 days). - - Purpose: Engage the Cardano community in discussions and solicit feedback on the principles, structure, and content of the Final Constitution. - - Actions: Conduct workshops, surveys, and community forums to gather input. - -2. **Drafting Phase:** - - Duration: 6 epochs (30 days). - - Purpose: The Drafting Committee compiles and integrates community feedback into a cohesive draft of the Final Constitution. - - Actions: The Drafting Committee meets regularly to refine the draft, considering all input from the community consultation phase. - -3. **Public Review Phase:** - - Duration: 6 epochs (30 days). - - Purpose: Present the draft Final Constitution to the Cardano community for public review and comment. - - Actions: The draft is published online, and a dedicated platform is made available for comments, suggestions, and discussion. - -4. **Revision Phase:** - - Duration: 4 epochs (20 days). - - Purpose: The Drafting Committee revises the draft based on community feedback from the public review phase. - - Actions: Final adjustments are made, and the draft is prepared for the ratification vote. - -5. **Ratification Vote:** - - Duration: 2 epochs (10 days). - - Purpose: Conduct a vote among ADA holders to ratify the Final Constitution. - - Threshold: A minimum of 67% of the active voting stake must support the Final Constitution for it to be ratified. - - Actions: Voting takes place on-chain, with results published immediately after the vote concludes. - -6. **Transition Phase:** - - Duration: 2 epochs (10 days). - - Purpose: Implement the Final Constitution and transition governance powers to the new governance structures. - - Actions: Dissolution of the Interim Constitutional Committee, establishment of the Constitutional Committee, and activation of the governance framework as outlined in the Final Constitution. - -### 3. INTERIM PERIOD GOVERNANCE ACTIONS - -During the Interim Period, specific governance actions shall be prioritized to ensure the smooth transition to the Final Constitution. These actions include: - -1. **Guardrails Implementation:** - - Purpose: Ensure all critical guardrails are in place to protect the integrity and stability of the Cardano Blockchain during the Interim Period. - - Actions: Establish, review, and amend guardrails as necessary. - -2. **Budget Proposal and Approval:** - - Purpose: Develop and approve a budget for the ongoing maintenance and development of the Cardano Blockchain during the Interim Period. - - Actions: The Interim Constitutional Committee, in collaboration with the community, shall propose a budget that must be approved through an on-chain governance vote. - -3. **Hard Fork Preparation:** - - Purpose: Prepare for necessary hard forks that may be required to implement changes during the Interim Period. - - Actions: Engage with developers, SPOs, and the community to ensure a smooth transition during hard fork events. - -4. **Treasury Management:** - - Purpose: Oversee the management and distribution of funds from the Cardano Treasury. - - Actions: Review treasury withdrawal proposals, ensuring alignment with community goals and budgetary constraints. - -5. **Community Engagement and Education:** - - Purpose: Ensure that the Cardano community remains informed and engaged throughout the Interim Period. - - Actions: Conduct regular updates, educational sessions, and community events to explain governance processes and encourage participation. - -## APPENDIX V: IMPLEMENTATION GUIDELINES FOR CIP-1694 - -### 1. INTRODUCTION TO CIP-1694 IMPLEMENTATION - -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. - -### 2. ESTABLISHMENT OF GOVERNANCE BODIES - -#### Section 1: Delegated Representatives (DReps) - -DReps play a crucial role in representing ADA holders in the governance process. The following steps outline the process for establishing DReps: - -1. **Registration:** - - DReps must register on-chain, providing information about their qualifications, experience, and governance philosophy. - - Registration fees may apply, as specified in the governance parameters. - -2. **Delegation:** - - ADA holders can delegate their voting power to registered DReps. - - Delegation is flexible, allowing ADA holders to change their DRep at any time. - -3. **Responsibilities:** - - DReps are expected to vote on governance actions, represent the interests of their delegators, and adhere to the code of conduct. - -4. **Accountability:** - - DReps must disclose any conflicts of interest and provide regular updates to their delegators. - - Failure to act in the best interests of delegators may result in loss of delegation or other penalties. - -#### Section 2: Stake Pool Operators (SPOs) - -SPOs contribute to the security and decentralization of the Cardano Blockchain and participate in governance actions. The following guidelines apply to SPOs: - -1. **Participation:** - - SPOs are automatically eligible to vote on certain governance actions, particularly those related to protocol parameters and technical changes. - -2. **Voting Power:** - - SPO voting power is weighted according to the amount of ADA staked in their pools. - - SPOs must act transparently and in the best interests of the Cardano community. - -3. **Conflicts of Interest:** - - SPOs must disclose any potential conflicts of interest and refrain from voting on actions where such conflicts may arise. - -4. **Compliance:** - - SPOs must comply with all governance guidelines and adhere to the code of conduct. - -#### Section 3: Constitutional Committee - -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: - -1. **Selection:** - - Members of the Constitutional Committee shall be selected based on their expertise, contributions to the Cardano ecosystem, and commitment to decentralized governance. - - The number of members and term limits are specified in the governance parameters. - -2. **Responsibilities:** - - The Constitutional Committee reviews all governance actions to ensure they comply with the Cardano Constitution. - - The Committee may veto any governance action that violates the Constitution. - -3. **Transparency:** - - The Constitutional Committee must operate transparently, publishing its decisions and the rationale behind them. - - All meetings and votes of the Committee should be documented and made available to the public. - -4. **Accountability:** - - Members of the Constitutional Committee are accountable to the Cardano community and must act in the best interests of the ecosystem. - - The community may propose changes to the Committee's composition or powers through governance actions. - -### 3. VOTING PROCEDURES - -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: - -#### Section 1: Proposal Submission - -1. **Eligibility:** - - Any ADA holder, DRep, or SPO may submit a governance proposal. - - Proposals must be submitted in a standardized format, including a clear rationale, potential impact, and supporting documentation. - -2. **Submission Process:** - - Proposals are submitted on-chain and are subject to a deposit fee, as specified in the governance parameters. - - The proposal is then reviewed by the relevant governance bodies (e.g., DReps, SPOs, Constitutional Committee). - -3. **Review and Approval:** - - Proposals are reviewed for completeness, compliance with guardrails, and potential impact on the Cardano ecosystem. - - Once approved, proposals are scheduled for a vote. - -#### Section 2: Voting Process - -1. **Voting Period:** - - The voting period for each proposal is defined in the governance parameters and typically lasts between 5 to 15 epochs. - - During this period, ADA holders, DReps, and SPOs can cast their votes. - -2. **Voting Mechanisms:** - - Votes are cast on-chain, and each vote is weighted according to the voter's stake (for ADA holders) or delegation (for DReps). - - The results of the vote are automatically recorded on the blockchain. - -3. **Thresholds:** - - Different types of proposals may require different thresholds for approval (e.g., simple majority, supermajority). - - Thresholds are defined in the governance parameters and vary based on the type and significance of the proposal. - -4. **Result Publication:** - - The results of the vote are published immediately after the voting period ends. - - All votes and outcomes are recorded on-chain, ensuring transparency and immutability. - -#### Section 3: Implementation of Approved Proposals - -1. **Execution:** - - Approved proposals are automatically executed by smart contracts, where applicable. - - For proposals requiring manual implementation (e.g., changes to off-chain processes), the responsible parties are notified, and a timeline for implementation is established. - -2. **Monitoring:** - - The implementation of approved proposals is monitored by the relevant governance bodies to ensure compliance and effectiveness. - - Any issues or deviations from the approved proposal must be reported and addressed promptly. - -3. **Feedback Loop:** - - The Cardano community is encouraged to provide feedback on the implementation and outcomes of approved proposals. - - This feedback may be used to refine future proposals or governance processes. - -### 4. ONGOING GOVERNANCE MAINTENANCE - -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: - -#### Section 1: Regular Reviews - -1. **Periodic Audits:** - - Governance processes, including voting procedures, the role of DReps, SPOs, and the Constitutional Committee, shall undergo periodic audits. - - Audits will assess compliance with the Constitution, effectiveness, and areas for improvement. - - The results of these audits will be made public and may inform future governance proposals. - -2. **Annual Governance Review:** - - An annual review of the governance framework shall be conducted by the Constitutional Committee in collaboration with the Cardano community. - - This review will consider the performance of the governance structures, the effectiveness of the guardrails, and any evolving needs of the Cardano ecosystem. - - Recommendations from the review may lead to proposed amendments or updates to the Constitution or governance parameters. - -3. **Community Feedback:** - - Continuous feedback from the Cardano community will be solicited to ensure the governance framework remains responsive to community needs. - - Mechanisms for gathering feedback include surveys, forums, and public consultations. - -4. **Review of Guardrails:** - - Guardrails that govern protocol parameters and governance actions should be reviewed regularly to ensure they remain relevant and effective. - - Changes to guardrails may be proposed as governance actions and must go through the standard voting process. - -#### Section 2: Governance Updates and Amendments - -1. **Amendment Proposals:** - - Any member of the Cardano community may propose amendments to the Constitution, guardrails, or other governance parameters. - - Proposals must include a clear rationale, potential impacts, and a detailed plan for implementation. - -2. **Review Process:** - - Amendment proposals will be reviewed by the Constitutional Committee for compliance with the existing governance framework. - - The Committee may provide recommendations or request revisions before the proposal is put to a vote. - -3. **Voting on Amendments:** - - Amendments to the Constitution or guardrails require a supermajority (e.g., 67% of the active voting stake) to be approved. - - The results of the vote will be binding, and approved amendments will be implemented as specified. - -4. **Implementation of Amendments:** - - Once an amendment is approved, it will be incorporated into the governance framework. - - Any necessary updates to documentation, processes, or smart contracts will be executed to reflect the amendment. - -5. **Communication of Changes:** - - All amendments and updates to the governance framework will be communicated to the Cardano community through official channels. - - Educational resources may be provided to help the community understand the implications of the changes. - -#### Section 3: Emergency Governance Actions - -1. **Definition of Emergencies:** - - An emergency is defined as any situation that poses an immediate threat to the security, stability, or functionality of the Cardano Blockchain. - - Examples include severe security vulnerabilities, catastrophic failures, or unforeseen critical issues. - -2. **Emergency Action Procedures:** - - In the event of an emergency, the Constitutional Committee may expedite the governance process to address the issue. - - Emergency actions may include temporary changes to protocol parameters, suspension of certain governance processes, or other measures necessary to mitigate the threat. - -3. **Community Notification:** - - The Cardano community must be notified immediately of any emergency governance actions, including the rationale, expected impact, and duration. - - A full report on the emergency and the actions taken must be provided once the situation is resolved. - -4. **Review and Ratification:** - - Any emergency actions taken must be reviewed and ratified by the community through a governance vote as soon as possible. - - If the community does not ratify the emergency actions, they must be rolled back, and alternative solutions must be proposed. - -5. **Post-Emergency Evaluation:** - - 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. - - The findings of this evaluation may inform updates to the emergency governance procedures. - -### 5. COMMUNITY ENGAGEMENT AND EDUCATION - -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: - -#### Section 1: Governance Education Programs - -1. **Workshops and Webinars:** - - 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. - - These sessions will be open to all community members and will be recorded and made available online. - -2. **Educational Resources:** - - Comprehensive educational materials, including guides, FAQs, and video tutorials, will be developed to explain the governance processes in detail. - - These resources will be accessible through the official Cardano website and other community platforms. - -3. **Onboarding for New Participants:** - - 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. - - This program will include step-by-step instructions on how to participate in governance actions, delegate voting power, and submit proposals. - -#### Section 2: Community Outreach - -1. **Regular Updates:** - - The Cardano governance bodies will provide regular updates to the community on ongoing governance actions, upcoming votes, and other relevant developments. - - Updates will be shared through multiple channels, including the official Cardano blog, social media, and community forums. - -2. **Open Forums:** - - Open forums and discussion groups will be established to facilitate dialogue between community members and governance bodies. - - These forums will provide a platform for community members to ask questions, share ideas, and provide feedback on governance matters. - -3. **Community Ambassadors:** - - A network of community ambassadors will be established to represent different regions and demographic groups within the Cardano ecosystem. - - Ambassadors will play a key role in disseminating information, gathering feedback, and ensuring that diverse perspectives are considered in governance decisions. - -4. **Surveys and Polls:** - - Regular surveys and polls will be conducted to gauge community sentiment on various governance issues and proposals. - - The results of these surveys will be used to inform decision-making and prioritize governance actions. - -#### Section 3: Transparency and Accountability - -1. **Public Reporting:** - - All governance bodies, including the Constitutional Committee, DReps, and SPOs, will publish regular reports on their activities, decisions, and the outcomes of governance actions. - - These reports will be made available to the entire Cardano community to ensure transparency and accountability. - -2. **Audit and Oversight:** - - Independent audits of the governance processes and financial management (e.g., Treasury withdrawals) will be conducted periodically. - - The results of these audits will be published and any recommendations for improvement will be considered and implemented as appropriate. - -3. **Feedback Mechanisms:** - - Formal mechanisms will be established to allow community members to provide feedback on the performance and conduct of governance bodies. - - This feedback will be reviewed regularly, and governance bodies will be expected to address any issues or concerns raised by the community. - -### 6. CONCLUSION - -The implementation of CIP-1694 and the ongoing development of the Cardano governance framework represent a significant step toward a truly decentralized, community-driven ecosystem. By adhering to the principles of transparency, inclusivity, and accountability, the Cardano community can ensure the long-term success and sustainability of the blockchain. - -As the governance framework continues to evolve, the active participation and engagement of all stakeholders will be crucial. Through collaboration, education, and a shared commitment to the principles outlined in the Cardano Constitution, the community can achieve its vision of a decentralized, fair, and resilient blockchain ecosystem. - -This document, along with the Cardano Constitution, shall serve as a living framework, continuously adapted and improved in response to the needs and aspirations of the Cardano community. From 3f1e861913b144b58245127a77b3a225f527dd8e Mon Sep 17 00:00:00 2001 From: Cerkoryn <30681834+Cerkoryn@users.noreply.github.com> Date: Wed, 25 Sep 2024 21:35:00 -0500 Subject: [PATCH 02/17] Edits and re-writes, still WIP --- CONSTITUTION.md | 146 ++++++++++-------------------------------------- 1 file changed, 31 insertions(+), 115 deletions(-) diff --git a/CONSTITUTION.md b/CONSTITUTION.md index e539a3f..b7e57ff 100644 --- a/CONSTITUTION.md +++ b/CONSTITUTION.md @@ -4,73 +4,41 @@ ## PREAMBLE -Through adopting this Constitution, the Cardano Blockchain ecosystem shall establish a robust -governance framework, ensuring that decisions are made in the best interest of the Cardano -community. The Cardano community shall uphold principles of transparency, openness, and -responsible governance, promoting a culture of trust and collaboration. - -All owners of ada shall have the opportunity to contribute to the governance and direction of the -decentralized Cardano Blockchain ecosystem. - -By necessity, this Constitution recognizes the role of and empowers the Constitutional -Committee, confirms the right of the Cardano community to participate in collective bodies for -collaboration, gives effect to on-chain governance, and empowers DReps to act as the voice of -ada owners for on-chain voting. - -The Constitution also recognizes the necessity of safeguarding access to and the use of funds of -the Cardano treasury through the inclusion of the Cardano Guardrails in this Constitution. +Through the adoption of this Constitution, the Cardano Blockchain ecosystem establishes a transparent and accountable governance framework to ensure that decisions are made in the best interest of the Cardano community. The Constitution acknowledges the role and empowers the Constitutional Committee to enforce its articles and make decisions when "code as law" is insufficient, necessitating the presence of a governance structure with people in the loop. This Constitution serves as a guiding document to promote the long-term sustainability and success of the Cardano Blockchain ecosystem. ## ARTICLE I. CARDANO BLOCKCHAIN TENETS AND GUARDRAILS ### Section 1 -These below Tenets shall guide the Constitutional Committee and proposed governance actions shall be evaluated in accordance -with these Tenets. - -Transactions on the Cardano Blockchain should not be slowed down or censored and should be -expediently served for their intended purpose. +Transactions on the Cardano Blockchain should not be intentionally degraded or censored. The cost of transactions on the Cardano Blockchain should be predictable and not unreasonable. -Anyone desiring to develop and deploy applications on the Cardano Blockchain should not -unreasonably be prevented from developing and deploying such applications as intended. +Any individual or entity desiring to develop and deploy non-malicious applications on the Cardano Blockchain should not unreasonably be prevented from deploying such applications as-intended. -The Cardano Blockchain shall not lock in an ada owner’s value without an owner’s consent. +The Cardano Blockchain shall not lock in an ADA owner’s value without an owner’s consent. -The Cardano Blockchain shall preserve in a safe manner any value and information an owner of -ada seeks to store on the Cardano Blockchain. +The Cardano Blockchain shall preserve in a safe manner any value and information an owner of ADA seeks to store on the Cardano Blockchain. -The Cardano Blockchain shall not unnecessarily spend resources. The Cardano Blockchain shall -promote efficient design, memory and storage. +The Cardano Blockchain shall not unnecessarily waste system, network, or economic resources. ### Section 2 -The Cardano Blockchain shall operate in accordance with the Cardano Blockchain Guardrails as -set forth in the Guardrails Appendix to this Constitution. The Cardano community may from -time to time digitally codify certain Cardano Blockchain Guardrails such that such Cardano -Blockchain Guardrails are directly programmed and implemented on the Cardano Blockchain -using on-chain scripts or built-in ledger rules. +The Cardano Blockchain shall operate in accordance with the Cardano Blockchain Guardrails as set forth in the Guardrails on-chain scripts or built-in ledger rules. -In the event there are inconsistencies between a Cardano Blockchain Guardrail as set forth in the -Guardrails Appendix and any such Cardano Blockchain Guardrail that has been programmed and -implemented on the Cardano Blockchain, the version of such Cardano Blockchain Guardrail that -has been deployed directly on the Cardano Blockchain shall prevail and the Constitutional -Committee shall seek to reconcile such inconsistencies through the encouragement of an -appropriate on-chain governance action. +The Cardano community may modify the Cardano Blockchain Guardrails after a proposal to change them is voted on and ratified. ## ARTICLE II. THE CARDANO BLOCKCHAIN COMMUNITY ### Section 1 -No formal membership shall be required to use, participate in and benefit from the Cardano -Blockchain. +No formal membership shall be required to use, participate in, or benefit from the Cardano Blockchain. ### Section 2 -Members of the Cardano community who own ada _[, as well as their appointed designees,]_ are -entitled to access and participate in the on-chain decision-making processes of the Cardano -Blockchain ecosystem, including voting and taking part in on-chain governance regarding the -Cardano Blockchain. +Members of the Cardano community who own ADA are entitled to access and participate in the on-chain decision-making processes of the Cardano Blockchain ecosystem, including voting and taking part in on-chain governance. + +Reasonable fees and/or deposits may be set via parameters to prevent spam and abuse of the governance process. ## ARTICLE III. PARTICIPATORY GOVERNANCE @@ -79,106 +47,54 @@ Cardano Blockchain. The Cardano Blockchain ecosystem shall be governed by a decentralized, on-chain governance model. -### Section 3 - -On-chain governance decisions shall be made through a collective decision-making process, with -specific consensus threshold requirements as required by the Cardano Blockchain Guardrails. -All on-chain governance actions shall be voted upon in accordance with the Cardano Blockchain -Guardrails. +### Section 2 -All owners of ada _[, as well as their appointed designees,]_ shall have the right to propose changes -to the governance structure of the Cardano Blockchain ecosystem in accordance with the -Cardano Blockchain Guardrails. +All owners of ADA shall have the right to propose changes to the governance structure of the Cardano Blockchain ecosystem. -### Section 6 +### Section 3 -All owners of ada shall have the right to ensure that the process for participating in, submitting -and voting on on-chain governance actions is open and transparent and is protected from undue -influence and manipulation. +The process for participating in, submitting and voting on on-chain governance actions shall be open, transparent, and protected from undue influence and manipulation. -### Section 8 +### Section 4 -The Cardano community is expected to propose, not less than on an annual basis, a budget for -the ongoing maintenance and future development of the Cardano Blockchain. All owners of -ada _[, as well as their appointed designees,]_ are expected to periodically approve the Cardano -Blockchain budget through an on-chain governance action. No withdrawals from the Cardano -treasury shall be permitted unless a budget for the Cardano Blockchain is then in effect as -required by the Cardano Blockchain Guardrails. +No withdrawals from the Cardano treasury shall be permitted except as part of a periodic budget as-required by the Cardano Blockchain Guardrails. -_[Any governance action requesting ada from the Cardano Blockchain treasury in excess of -[1,000,000] ada shall require an allocation of ada as a part of such funding request to cover the -cost of periodic independent audits and the implementation of oversight metrics as to the use of -such ada.] [Contractual obligations governing the use of ada received from the Cardano -Blockchain treasury pursuant to a Cardano budget in excess of [1,000,000] shall include dispute -resolution provisions.]_ +No withdrawals from the Cardano treasury in excess of 1,000,000 ADA shall be permitted without sufficient independent audits, oversight metrics, and a reasonable amount of ADA to cover the cost of such audits. ## ARTICLE IV. DELEGATED REPRESENTATIVES -### Section 2 +### Section 1 + +Any owner of ADA shall have the option to register as a dRep. -Any owner of ada shall have the option to register as a DRep. Any owner of ada _[, as well as -their appointed designees,]_ shall be allowed to delegate their voting stake to one or more -registered DReps, including themselves. +Any owner of ADA shall be allowed to delegate their voting stake to one or more registered dReps, including themselves. -## ARTICLE V. STAKE POOL OPERATORS +## ARTICLE V. STAKE POOLS ### Section 1 -SPOs shall have a specific role in approving critical on-chain governance actions which require -additional oversight and independence, voting separately and independently from DReps as set -forth in the Cardano Blockchain Guardrails. +Any owner of ADA shall be allowed to delegate their voting stake to one or more registered stake pools, including their own. ## ARTICLE VI. CONSTITUTIONAL COMMITTEE ### Section 1 -A Constitutional Committee shall be established as the branch of Cardano's on-chain governance -process that ensures governance actions are consistent with this Constitution. The Constitutional -Committee shall comprise a set of owners of ada _[, including their appointed designees,]_ that is -collectively responsible for ensuring that on-chain governance actions prior to enactment on- -chain, are constitutional. The Constitutional Committee shall be limited to voting on the -constitutionality of governance actions. +The Constitutional Committee shall be limited to voting on the constitutionality of governance actions. ### Section 2 -The Constitutional Committee shall be composed of _[such number of members as shall be -determined from time to time by owners of ada]_ , as consistent with the Cardano Blockchain -Guardrails. +The Constitutional Committee shall be composed of a set number of members and must pass any proposals via a voting threshold defined by the Cardano Blockchain Guardrails and on-chain ledger rules. -### Section 2 - -Members of the Constitutional Committee shall serve such terms _[as shall be determined from -time to time by owners of ada]_ as consistent with the Cardano Blockchain Guardrails. +### Section 3 +Members of the Constitutional Committee shall serve terms for a specific period of time as-defined by the Cardano Blockchain Guardrails and on-chain ledger rules. ### Section 4 -No governance action, other than a "Motion of no-confidence" or "Update constitutional -committee/threshold" may be implemented on-chain unless the Constitutional Committee shall -have first determined and affirmed through an on-chain action that such proposal does not violate -this Constitution. - -### Section 5 - -Constitutional Committee processes shall be transparent. The Constitutional Committee shall -publish each decision. When voting _[no]_ on a proposal, _[the Constitutional Committee] [each -member of the Constitutional committee casting a no vote]_ shall set forth the basis for its -decision with reference to specific Articles of this Constitution that are in conflict with a given -proposal. +The Constitutional Committee shall transparently publish each decision and provide the basis for any "no" votes with reference to specific Articles of this Constitution. ## ARTICLE VII. AMENDMENTS ### Section 1 -Except as otherwise so provided in the Cardano Blockchain Guardrails Appendix, amendments -to this Constitution, including to the Cardano Blockchain Guardrails Appendix, shall be -approved by a collective decision-making process, requiring an on-chain governance action by -owners of ada _[, including their appointed designees,]_ satisfying a threshold of not less than 67% -of the then active voting stake. - -### Section 2 - -If the Cardano Blockchain Guardrails Appendix sets forth an amendment threshold for a -Cardano Blockchain Guardrail that is different than the amendment threshold contained in -Section 1 of this Article VII, then the threshold set forth in the Cardano Blockchain Guardrails -Appendix for such Cardano Blockchain Guardrail shall apply. +Amendments to this Constitution require approval through an on-chain governance action by ADA owners, meeting a threshold set by an on-chain parameter for constitutional amendments. \ No newline at end of file From 1c8c4460d0ddab1547ca8e7f55adbbe80d1f1164 Mon Sep 17 00:00:00 2001 From: rwiley <30681834+Cerkoryn@users.noreply.github.com> Date: Mon, 11 Nov 2024 16:03:58 -0500 Subject: [PATCH 03/17] Cerkoryn Draft Release --- CONSTITUTION.md | 2182 +++++++++-------------------------------------- 1 file changed, 403 insertions(+), 1779 deletions(-) diff --git a/CONSTITUTION.md b/CONSTITUTION.md index 87d809e..902f631 100644 --- a/CONSTITUTION.md +++ b/CONSTITUTION.md @@ -1,2010 +1,634 @@ -`Draft 2024-07-29` +`Draft 2024-09-20` # CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION ## PREAMBLE -In the beginning of the Cardano Blockchain ecosystem, three pioneering entities, IOHK, -Emurgo, and the Cardano Foundation, came together to foster the emergence of a new -blockchain, the Cardano Blockchain, laying the foundation for a decentralized network that -would empower individuals, and promote collaboration and innovation. Their pioneering efforts -have shaped the path for a blockchain designed to ensure a fair and transparent environment -where all participants can contribute to the Cardano Blockchain ecosystem's growth and success. - -Over time, the Cardano Blockchain ecosystem has expanded significantly, and now, the Cardano -Blockchain ecosystem, comprising of thousands of ada holders, individuals, builders, developers, -enterprises, stake pools, users of the Cardano Blockchain and others, operates in a truly -decentralized manner, further strengthening the resilience and autonomy of the Cardano -Blockchain ecosystem. - -As the Cardano Blockchain ecosystem continues to grow, it has become imperative to similarly -adapt and evolve its governance model, reflecting the principles of decentralization, community -involvement, inclusivity and collaboration that have been the cornerstone of the Cardano -Blockchain ecosystem since its start. - -Recognizing the need for a more robust and dynamic governance framework, and one that -utilizes wherever possible and beneficial blockchain technology in the governance process, the -Cardano community, as the members of this decentralized Cardano Blockchain ecosystem, -hereby establishes this Cardano Constitution. It shall serve as a guiding set of principles for the -operation and governance of our collective efforts, fostering an environment where all -participants can contribute to the betterment of the Cardano Blockchain ecosystem as a whole. - -Through adopting this Constitution, the Cardano Blockchain ecosystem shall establish a robust -governance framework, ensuring that decisions are made in the best interest of the Cardano -community. The Cardano community shall uphold principles of transparency, openness, and -responsible governance, promoting a culture of trust and collaboration. Together, the Cardano -community commits to uphold these principles and to work together towards the continuous -improvement, growth, and success of our decentralized blockchain ecosystem known as the -Cardano Blockchain. - -This Constitution shall serve as the embodiment of these guiding principles for the operation and -governance of the decentralized Cardano Blockchain ecosystem, providing a foundation that will -adapt and evolve over time to meet the continuing needs of the Cardano community. - -All members of the Cardano community are expected to abide by this Constitution, and are -entitled to participate in its governance processes, and are encouraged to work collaboratively -towards the betterment of the Cardano Blockchain ecosystem as a whole, contributing to its -growth, sustainability, and success. The Cardano Blockchain shall be governed on a vote-based -decision-making model, fostering inclusivity, a diversity of views, innovation and adaptability. - -All owners of ada shall have the opportunity to contribute to the governance and direction of the -decentralized Cardano Blockchain ecosystem. - -In approaching this Constitution, it must be remembered that this is not a constitution for only a -blockchain but rather, it is a constitution for a blockchain ecosystem – a much more ambitious -endeavor. Accordingly, how governance actions are approved, while extremely important, is not -the sole focus of this Constitution. Rather, this Constitution provides the basis and fundamental -framework through which all actors in the Cardano Blockchain ecosystem can come together to -govern themselves and form radically new approaches to human interaction and collaboration. - -By necessity, this Constitution recognizes the role of and empowers the Constitutional -Committee, confirms the right of the Cardano community to participate in collective bodies for -collaboration, gives effect to on-chain governance, and empowers DReps to act as the voice of -ada owners for on-chain voting. - -The Constitution also recognizes the necessity of safeguarding access to and the use of funds of -the Cardano treasury through the inclusion of the Cardano Guardrails in this Constitution. +Through the adoption of this Constitution, the Cardano Blockchain ecosystem establishes a transparent and accountable governance framework to ensure that decisions are made in the best interest of the Cardano community. The Constitution acknowledges the role and empowers the Constitutional Committee to enforce its articles and make decisions when "code as law" is insufficient, necessitating the presence of a governance structure with people in the loop. This Constitution serves as a guiding document to promote the long-term sustainability and success of the Cardano Blockchain ecosystem. ## ARTICLE I. CARDANO BLOCKCHAIN TENETS AND GUARDRAILS ### Section 1 -These below Tenets shall guide all actors in the Cardano Blockchain ecosystem including the -Constitutional Committee and proposed governance actions shall be evaluated in accordance -with these Tenets. +Transactions on the Cardano Blockchain shall not be intentionally degraded or censored. -Transactions on the Cardano Blockchain should not be slowed down or censored and should be -expediently served for their intended purpose. The Cardano Blockchain should scale taking into -consideration throughput, sharding, settlement and dynamic pricing. +The cost of transactions on the Cardano Blockchain should be predictable and reasonable. -The cost of transactions on the Cardano Blockchain should be predictable and not unreasonable. -The Cardano Blockchain should facilitate an accessible, predictable pricing model. +Any individual or entity desiring to develop and deploy non-malicious applications on the Cardano Blockchain shall not be prevented from deploying such applications as-intended. -Anyone desiring to develop and deploy applications on the Cardano Blockchain should not -unreasonably be prevented from developing and deploying such applications as intended. The -Cardano community should promote features to assist in developing and deploying applications -such as digital subscriber lines, formal verification support, asynchronous and scalable location -services, oracles and access to partnerchains. +When contributions to the system are recognized, recorded, or processed, they should be done so fairly. -Contributions by Cardano community on the Cardano Blockchain should be recognized, -recorded and assessed fairly by the Cardano community through reward sharing with SPOs and -DReps, appropriate tokenomics and multi-resource consensus approaches. +The system shall not spend, delegate, or stake any ADA owner’s assets without the owner’s consent. -The Cardano Blockchain shall not lock in an ada owner’s value without an owner’s consent. The -Cardano Blockchain should promote interoperability and access to partnerchains. +The Cardano Blockchain shall reasonably preserve any value and information an owner of ADA seeks to store, while accommodating evolving innovations that ensure sustainable resource management. -The Cardano Blockchain shall preserve in a safe manner any value and information an owner of -ada seeks to store on the Cardano Blockchain. To assure safe protection of value and -information, the Cardano Blockchain should focus on integrity, post-quantum security, -decentralization and decentralized storage, access to stablecoins and robust key management -approaches. +Resources, whether system, network, or economic, shall not be unnecessarily wasted. -The Cardano Blockchain shall not unnecessarily spend resources. The Cardano Blockchain shall -promote efficient design, memory and storage. +Users shall be treated fairly, and the system shall adapt in alignment with their collective will, ensuring long-term sustainability and viability. -All users of the Cardano Blockchain shall be treated equally taking into account the collective -desires of the Cardano Blockchain community consistent with the long-term sustainability and -viability of the Cardano Blockchain. Long-term sustainability and viability shall be evaluated by -a number of considerations including fairness, neutrality, sustainability, robust governance, -promotion of decentralized identity, use of multi-resource consensus and democratic -participation by all members of the Cardano community. +The system shall not require users to violate local laws and regulations, and should provide alternatives whenever feasible. -#### Workshop Questions - -- Do you believe these tenets appropriately reflect the ethos of the Cardano Blockchain? -- Should there be an additional tenet addressing financial sustainability? If yes, what - should it contain? Should it include an absolute cap on the circulating supply of ada? +Operations should be transparent, predictable, verifiable, and interpretable, ensuring fairness and balance, while also supporting privacy-focused use cases where appropriate. ### Section 2 -The Cardano Blockchain shall operate in accordance with the Cardano Blockchain Guardrails as -set forth in the Guardrails Appendix to this Constitution. The Cardano community may from -time to time digitally codify certain Cardano Blockchain Guardrails such that such Cardano -Blockchain Guardrails are directly programmed and implemented on the Cardano Blockchain -using on-chain scripts or built-in ledger rules. +Operations shall be in accordance with the Guardrails as set forth in the Guardrails appendix and on-chain scripts. -In the event there are inconsistencies between a Cardano Blockchain Guardrail as set forth in the -Guardrails Appendix and any such Cardano Blockchain Guardrail that has been programmed and -implemented on the Cardano Blockchain, the version of such Cardano Blockchain Guardrail that -has been deployed directly on the Cardano Blockchain shall prevail and the Constitutional -Committee shall seek to reconcile such inconsistencies through the encouragement of an -appropriate on-chain governance action. +The Cardano community may modify the Guardrails after a proposal to change them is voted on and ratified. ## ARTICLE II. THE CARDANO BLOCKCHAIN COMMUNITY ### Section 1 -No formal membership shall be required to use, participate in and benefit from the Cardano -Blockchain. Instead, all owners of ada, all developers of, all those building on, and all those -otherwise supporting, maintaining or using the Cardano Blockchain are beneficiaries of the -Cardano Blockchain ecosystem and, as such, are collectively members of the Cardano - -community. All Cardano community members are accordingly beneficiaries of this Constitution, -entitled to its rights, privileges and protections and, as such, are expected to support and uphold -this Constitution. +No formal membership shall be required to use, participate in, or benefit from the Cardano Blockchain. ### Section 2 -Members of the Cardano community who own ada _[, as well as their appointed designees,]_ are -entitled to access and participate in the on-chain decision-making processes of the Cardano -Blockchain ecosystem, including voting and taking part in on-chain governance regarding the -Cardano Blockchain. - -#### Workshop Questions - -- Should on-chain governance participation be limited to only owners of ada or should - ada owners be allowed to appoint designees who are then entitled to participate in on- - chain governance? [Note that this is not a reference to delegation to DReps. +Members of the Cardano community who own ADA are entitled to access and participate in the on-chain decision-making processes of the Cardano Blockchain ecosystem, including voting and taking part in on-chain governance. -### Section 3 - -Members of the Cardano community have a responsibility to maintain the integrity of the -Cardano Blockchain ecosystem by following this Constitution, operating the Cardano -Blockchain network, participating in Cardano Blockchain governance activities, and resolving -disputes in a fair and transparent manner. - -### Section 4 - -The Cardano community is entitled and encouraged through the provisions of this Constitution to -collaborate in developing, maintaining and building applications for the Cardano community, -and to form temporary and permanent organizations and entities as the Cardano community -deems desirable or appropriate in support of the Cardano Blockchain ecosystem. +Reasonable fees and/or deposits may be set via parameters to prevent spam and abuse of the governance process. ## ARTICLE III. PARTICIPATORY GOVERNANCE ### Section 1 -The Cardano Blockchain ecosystem shall be governed by a decentralized, on-chain governance -model, utilizing, to the extent possible and beneficial, smart contracts and other blockchain- -based tools to facilitate decision-making and ensure transparency. On-chain voting for -governance actions shall follow the process outlined in the Cardano Blockchain Guardrails. +The Cardano Blockchain ecosystem shall be governed by a decentralized, on-chain governance model. ### Section 2 -Three independent governance bodies shall participate in voting for on-chain governance actions -to provide checks and balances for the Cardano Blockchain consisting of Delegated -Representatives (DRep), Stake Pool Operators (SPO) and the Constitutional Committee (CC). +All owners of ADA shall have the right to propose changes to the governance structure of the Cardano Blockchain ecosystem. ### Section 3 -On-chain governance decisions shall be made through a collective decision-making process, with -specific consensus threshold requirements as required by the Cardano Blockchain Guardrails. -All on-chain governance actions shall be voted upon in accordance with the Cardano Blockchain -Guardrails. +The process for participating in, submitting and voting on on-chain governance actions shall be open, transparent, and protected from undue influence and manipulation. ### Section 4 -All owners of ada _[, as well as their appointed designees,]_ shall have the right to vote in on-chain -governance action decision-making processes, subject to any restrictions or requirements -provided for in this Constitution and the Cardano Blockchain Guardrails. - -#### Workshop Questions - -- Voting rights are in proportion to the ada owned. However, should the Constitution - specify a specific voting model? -- Should the Constitution enshrine one ada one vote? -- How do we address participation by institutions? Should holders of ada who are not - owners, such as exchanges, be allowed to vote? - -All owners of ada _[, as well as their appointed designees,]_ shall have the right to propose changes -to the governance structure of the Cardano Blockchain ecosystem in accordance with the -Cardano Blockchain Guardrails. - -### Section 5 - -A special form of governance action exists to allow community sentiment to be gauged without -committing to any on-chain change of the Cardano Blockchain. "Info" actions have no on-chain -effect other than to record the outcome of such a vote on the Cardano Blockchain. - -### Section 6 - -Any proposed on-chain governance action shall require a standardized and legible format -including a URL and hash linked to documented off-chain content. Sufficient rationale shall be -provided to justify the requested change to the Cardano Blockchain. The rationale shall include, -at a minimum, a title, abstract, reason for the proposal, and relevant supporting materials. - -Any governance action proposal reaching the on-chain governance stage shall be identical in -content as to the final off-chain version of such governance action proposal. - -“Hard Fork Initiation” and “Protocol Parameter Change” governance actions should undergo -sufficient technical review and scrutiny as mandated by the Cardano Blockchain Guardrails to -ensure that the governance action does not endanger the security, functionality or performance of -the Cardano Blockchain. On-chain governance actions should address their expected impact on -the Cardano Blockchain ecosystem. - -All owners of ada shall have the right to ensure that the process for participating in, submitting -and voting on on-chain governance actions is open and transparent and is protected from undue -influence and manipulation. - -### Section 7 - -The Cardano community is expected to support the creation, maintenance and ongoing -administration of off-chain governance processes as may be necessary to give effect to this -Constitution and to ensure that there is awareness of and an opportunity to debate and shape all -future governance actions for the Cardano Blockchain. - -### Section 8 - -The Cardano community is expected to propose, not less than on an annual basis, a budget for -the ongoing maintenance and future development of the Cardano Blockchain. All owners of -ada _[, as well as their appointed designees,]_ are expected to periodically approve the Cardano -Blockchain budget through an on-chain governance action. No withdrawals from the Cardano -treasury shall be permitted unless a budget for the Cardano Blockchain is then in effect as -required by the Cardano Blockchain Guardrails. - -_[Any governance action requesting ada from the Cardano Blockchain treasury in excess of -[1,000,000] ada shall require an allocation of ada as a part of such funding request to cover the -cost of periodic independent audits and the implementation of oversight metrics as to the use of -such ada.] [Contractual obligations governing the use of ada received from the Cardano -Blockchain treasury pursuant to a Cardano budget in excess of [1,000,000] shall include dispute -resolution provisions.]_ - -#### Workshop Questions - -- Should the Constitution require that governance actions above a specified amount - include allocations of ada to cover periodic audits and implementation of oversight - metrics? If yes, how should they be enforced? -- Should the Constitution require that contractual provisions governing the use of ada - received from the treasury above a specified amount include dispute resolution - provisions? If yes, how should they be enforced? -- Should the Constitution require that the budget include a contingency fund? If so, how - would it work? What could it be used for? Who would administer it? -- Should the Constitution require that the budget include an indemnity fund to cover - potential claims against governance participants such as DReps and Constitutional - Committee members? If so, how would it work? What could it be used for? Who would - administer it? -- Should the budgetary process be spelled out in greater detail in the Constitution? Should - the Constitution identify how the budget will be administered? Should it identify who - will administer the budget? -- Should the Constitution specify a cap on the annual budget? - -## ARTICLE IV. DELEGATED REPRESENTATIVES +No withdrawals from the Cardano treasury shall be permitted except as part of a periodic budget as-required by the Cardano Blockchain Guardrails. -### Section 1 - -In order to participate in governance actions, owners of ada may register as DReps and directly -vote on such governance actions or may delegate their voting rights to other registered DReps -who shall vote on their behalf. - -### Section 2 +No withdrawals from the Cardano treasury in excess of 1,000,000 ADA shall be permitted without sufficient independent audits, oversight metrics, and a reasonable amount of ADA to cover the cost of such audits. -Any owner of ada shall have the option to register as a DRep. Any owner of ada _[, as well as -their appointed designees,]_ shall be allowed to delegate their voting stake to one or more -registered DReps, including themselves. DReps may be individuals or coordinated groups. -DReps are entitled to cast votes directly for on-chain governance actions and represent those ada -holders delegating their voting rights to them. +The total supply of ADA shall not be modified to be less or more than 45,000,000,000. -This voting system shall enshrine a liquid democracy model where owners of ada can seamlessly -select among DReps, register as a DRep, and change their delegation at any time. - -### Section 3 - -_[DReps are expected to adopt codes of conduct from time to time governing their activities as -DReps and make such codes of conduct publicly available.]_ - -#### Workshop Questions - -- Should the Constitution include any guidelines as to the requirements that must be - included by DReps in their respective codes of conduct? -- Should there be one code of conduct for all DReps or should each DRep be allowed to - adopt its own code of conduct? Should DRep codes of conduct be on-chain? -- Should the Constitutional Committee determine whether such codes of conduct are - consistent with the Constitution? -- Should the Constitution include term limits for DReps? - -### Section 4 - -The Cardano community is expected to support the creation, maintenance and ongoing -administration of tools to enable owners of ada to explore and evaluate DRep candidates and -select DReps on such criteria as they deem relevant. - -### Section 5 - -_[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.]_ - -#### Workshop Questions - -- Should the Constitution mandate compensation for DReps? If so, should the Constitution - specify how compensation is determined or include a cap on compensation? -- Should the Constitution require that budgets approved for the Cardano Blockchain - include an allocation from the Cardano Blockchain treasury sufficient to compensate - DReps in such amounts as may be approved from time to time by ada owners. - -## ARTICLE V. STAKE POOL OPERATORS +## ARTICLE IV. DELEGATED REPRESENTATIVES ### Section 1 -SPOs shall have a specific role in approving critical on-chain governance actions which require -additional oversight and independence, voting separately and independently from DReps as set -forth in the Cardano Blockchain Guardrails. SPOs shall participate in hard fork initiation -processes as the operators of the nodes that participate in Cardano Blockchain’s consensus -mechanism. +Any owner of ADA shall have the permissionless option to register as a dRep. -### Section 2 - -SPOs may act as a check on the power of the Constitutional Committee under exceptional -circumstances by separately voting on "Motion of no-confidence" and "Update -committee/threshold" governance actions. +Any owner of ADA shall be allowed to delegate their voting stake to one or more registered dReps, including themselves. -### Section 3 +## ARTICLE V. STAKE POOLS -_[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.]_ +### Section 1 -#### Workshop Questions +Any owner of ADA shall have the permissionless option to register a stake pool. -- Should the Constitution include a requirement that ada owners who are both DReps and - SPOs either refrain from voting in both capacities or disclose such dual roles? -- Should the Constitution include other conflicts of interest provisions included? -- Should the Constitution require that SPOs be expected to implement codes of conduct? If - yes, should they be on-chain? Should the Constitutional Committee determine whether - such codes of conduct are consistent with the Constitution?] +Any owner of ADA shall be allowed to delegate their voting stake to one or more registered stake pools, including their own. ## ARTICLE VI. CONSTITUTIONAL COMMITTEE ### Section 1 -A Constitutional Committee shall be established as the branch of Cardano's on-chain governance -process that ensures governance actions are consistent with this Constitution. The Constitutional -Committee shall comprise a set of owners of ada _[, including their appointed designees,]_ that is -collectively responsible for ensuring that on-chain governance actions prior to enactment on- -chain, are constitutional. The Constitutional Committee shall be limited to voting on the -constitutionality of governance actions. Constitutional Committee members are expected to have -appropriate expertise to carry out their required responsibilities, considering their past -contributions and involvement in the Cardano Blockchain ecosystem. +The Constitutional Committee shall be limited to voting on the constitutionality of governance actions. ### Section 2 -The Constitutional Committee shall be composed of _[such number of members as shall be -determined from time to time by owners of ada]_ , as consistent with the Cardano Blockchain -Guardrails, and as shall be sufficient to assure the ongoing integrity of the Cardano Blockchain. - -#### Workshop Questions - -- Should the Constitution specify - -### Section 2 - -The Constitutional Committee shall be composed of _[such number of members as shall be -determined from time to time by owners of ada]_ , as consistent with the Cardano Blockchain -Guardrails, and as shall be sufficient to assure the ongoing integrity of the Cardano Blockchain. - -#### Workshop Questions - -- Should the Constitution specify how the number of members of the CC are determined? - [Note that the Guardrails specify both a minimum and maximum number of members.] - -Members of the Constitutional Committee shall serve such terms _[as shall be determined from -time to time by owners of ada]_ as consistent with the Cardano Blockchain Guardrails, provided -that terms shall not be less than one year. To assure continuity in the operation of Constitutional -Committee, the terms for Constitutional Committee members shall be staggered. - -#### Workshop Questions - -- Should the Constitution specify how term limits for CC members are determined? [Note - that the Guardrails specify both a minimum and maximum term limit.] +The Constitutional Committee shall be composed of a set number of members and must pass any proposals via a voting threshold defined by the Cardano Blockchain Guardrails. ### Section 3 -The Cardano community shall establish a process from time to time for election of members of -the Constitutional Committee consistent with the requirements of the Cardano Blockchain -Guardrails. - -#### Workshop Questions - -- Should the Constitution include an explicit process for the election of members of the - CC? +Members of the Constitutional Committee shall serve terms for a specific period of time as-defined by the Cardano Blockchain Guardrails. ### Section 4 -No governance action, other than a "Motion of no-confidence" or "Update constitutional -committee/threshold" may be implemented on-chain unless the Constitutional Committee shall -have first determined and affirmed through an on-chain action that such proposal does not violate -this Constitution. - -The Constitutional Committee shall be considered to be in one of the following two states at all -times: a state of confidence or a state of no-confidence. In a state of no-confidence, members of -the then standing Constitutional Committee must be reinstated or replaced using the "Update -committee/threshold" governance action before any other on-chain governance action may go -forward. - -### Section 5 - -Constitutional Committee processes shall be transparent. The Constitutional Committee shall -publish each decision. When voting _[no]_ on a proposal, _[the Constitutional Committee] [each -member of the Constitutional committee casting a no vote]_ shall set forth the basis for its -decision with reference to specific Articles of this Constitution that are in conflict with a given -proposal. - -The Constitutional Committee shall operate pursuant to a code of conduct published by the -Constitutional Committee from time to time and shall adopt such policies and procedures as the -Constitutional Committee shall deem necessary in carrying out its duties. - -#### Workshop Questions - -- Should the Constitution require that the Constitutional Committee code of conduct be on- - chain? -- Should the community have any role in approving the Constitutional Committee code of - conduct? If so, how would this work? - -### Section 6 - -The Cardano community is expected to support the creation, maintenance and ongoing -administration of tools as may be necessary and appropriate for the Constitutional Committee to -perform its required functions. - -### Section 7 - -_[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.]_ - -#### Workshop Questions - -- Should the Constitution mandate compensation for CC members? If so, should the - Constitution specify how compensation is determined or include a cap on compensation? -- Should the Constitution require that budgets approved for the Cardano Blockchain - include an allocation from the Cardano Blockchain treasury sufficient to compensate CC - members in such amounts as may be approved from time to time by ada owners. -- Should the Constitution require that the budget include an allocation for the - administrative costs of the CC? If so, how should the amount be determined? If so, - should the Constitution specify who would administer such a budget and whether - expenditures by the CC should be public or subject to audit oversight? +The Constitutional Committee shall transparently publish each decision and provide the basis for any "no" votes with reference to specific Articles of this Constitution. ## ARTICLE VII. AMENDMENTS ### Section 1 -Except as otherwise so provided in the Cardano Blockchain Guardrails Appendix, amendments -to this Constitution, including to the Cardano Blockchain Guardrails Appendix, shall be -approved by a collective decision-making process, requiring an on-chain governance action by -owners of ada _[, including their appointed designees,]_ satisfying a threshold of not less than 67% -of the then active voting stake. +Amendments to this Constitution require approval through an on-chain governance action by ADA owners, meeting a threshold set by the Cardano Blockchain Guardrails and corresponding parameters for constitutional amendments. ### Section 2 -If the Cardano Blockchain Guardrails Appendix sets forth an amendment threshold for a -Cardano Blockchain Guardrail that is different than the amendment threshold contained in -Section 1 of this Article VII, then the threshold set forth in the Cardano Blockchain Guardrails -Appendix for such Cardano Blockchain Guardrail shall apply. +In case of inconsistencies between the Guardrails documented in the Appendix and the Guardrails implemented on-chain, the on-chain version shall prevail, and the Constitutional Committee shall work to reconcile such inconsistencies through appropriate governance actions. + +## APPENDIX I: CARDANO BLOCKCHAIN GUARDRAILS -#### Workshop Questions +### 1. Introduction -- Should the Constitution include a provision preventing Article VII itself from being - amended or allowing any governance action that would have the effect of changing these - amendment requirements? -- Should the Constitution include a category of technical guardrail modifications that - could be overseen and approved by the Constitutional Committee? Is this even possible? - If yes, should such a category be narrowly defined to only address high security risks or - emergency issues? +This Appendix sets forth guardrails that must be applied to Cardano on-chain governance actions. These guardrails cover both essential, intrinsic limits on settings, and recommendations that are based on experience, measurement and governance objectives. -## APPENDIX I: CARDANO BLOCKCHAIN GUARDRAILS +These guardrails are designed to avoid unexpected problems with the operation of the Cardano Blockchain. They are intended to guide the choice of sensible parameter settings and avoid potential problems with security, performance or functionality. As described below, some of these guardrails are automatable and will be enforced via an on-chain script or built-in ledger rules.  However, many of them require the input of human experts which will be enforced by the Constitutional Committee through referencing this document. -### 1. INTRODUCTION - -To implement Cardano Blockchain on-chain governance pursuant to CIP-1694, it is necessary to -establish sensible guardrails that will enable the Cardano Blockchain to continue to operate in a -secure and sustainable way. - -This Appendix sets forth guardrails that must be applied to Cardano Blockchain on-chain -governance actions, including changes to the protocol parameters and limits on treasury -withdrawals. These guardrails cover both essential, intrinsic limits on settings, and -recommendations that are based on experience, measurement and governance objectives. - -These guardrails are designed to avoid unexpected problems with the operation of the Cardano -Blockchain. They are intended to guide the choice of sensible parameter settings and avoid -potential problems with security, performance or functionality. As described below, some of -these guardrails are automatable and will be enforced via an on-chain script or built-in ledger -rules. - -These guardrails apply to the Cardano Blockchain Layer 1 mainnet environment. They are not -intended to apply to test environments or to other blockchains that use the Cardano Blockchain -software. - -Not all parameters for the Cardano Blockchain can be considered independently. Some -parameters interact with other settings in an intrinsic way. Where known, these interactions are -addressed in this Appendix. - -While the guardrails in this Appendix presently reflect the current state of technical insight, this -Appendix should be treated as a living document. Implementation improvements, new -simulations or performance evaluation results for the Cardano Blockchain may allow some of the -restrictions contained in these guardrails to be relaxed (or, in some circumstances, require them -to be tightened) in due course. - -Additional guardrails may also be needed where, for example, new protocol parameters are -introduced. - -The guardrails set forth in this Appendix may be amended from time to time pursuant to an on- -chain governance action that satisfies the applicable voting threshold as set forth in this -Appendix. Any such amendment to any guardrails shall require and be deemed to be an -amendment to the Constitution itself. - -#### Workshop Questions - -- Should any of the below Guardrails include an amendment threshold different from the - threshold included in Article VII? - -### Terminology and Guidance - -**Should/Should not.** Where this Appendix says that a value "should not" be set below or -above some value, this means that the guardrail is a recommendation or guideline, and the -specific value could be open to discussion or alteration by a suitably expert group recognized by -the Cardano community in light of experience with the Cardano Blockchain governance system -or the operation of the Cardano Blockchain. - -**Must/Must not.** Where this Appendix says that a value "must not" be set below or above -some value, this means that the guardrail is a requirement that will be enforced by Cardano -Blockchain ledger rules, types or other built-in mechanisms where possible, and that if not -followed could cause a protocol failure, security breach or other undesirable outcome. - -**Benchmarking.** Benchmarking refers to careful system level performance evaluation that is -designed to show a-priori that, for example, 95% of blocks will be diffused across a global -network of Cardano Blockchain nodes within the required 5s time interval in all cases. This may -require construction of specific test workflows and execution on a large test network of Cardano -nodes, simulating a global Cardano Blockchain network. - -**Performance analysis.** Performance analysis refers to projecting theoretical performance, -empirical benchmarking or simulation results to predict actual system behavior. For example, -performance results obtained from tests in a controlled test environment (such as a collection of -data centers with known networking properties) may be extrapolated to inform likely -performance behavior in a real Cardano Blockchain network environment. - -**Simulation.** Simulation refers to synthetic execution that is designed to inform -performance/functionality decisions in a repeatable way. For example, the IOSim Cardano -Blockchain module allows the operation of the networking stack to be simulated in a controlled -and repeatable way, allowing issues to be detected before code deployment. - -**Performance Monitoring.** Performance monitoring involves measuring the actual behavior -of the Cardano Blockchain network, for example, by using timing probes to evaluate round-trip -times, or test blocks to assess overall network health. It complements benchmarking and -performance analysis by providing information about actual system behavior that cannot be -obtained using simulated workloads or theoretical analysis. - -**Reverting Changes.** Where performance monitoring shows that actual network behavior -following a change is inconsistent with the performance requirements for the Cardano -Blockchain, then the change must be reverted to its previous state if that is possible. For -example, if the block size is increased from 100KB to 120KB and 95% of blocks are no longer -diffused within 5s, then a change must be made to revert the block size to 100KB. If this is not -possible, then one or more alternative changes must be made that will ensure that the -performance requirements are met. - -**Severity Levels.** Issues that affect the Cardano Blockchain network are classified by -severity level, where: - -- Severity 1 is a critical incident or issue with very high impact to the security, - performance, or functionality of the Cardano Blockchain network. -- Severity 2 is a major incident or issue with significant impact to the security, - performance, or functionality of the Cardano Blockchain network. -- Severity 3 is a minor incident or issue with low impact to the security, performance, or - functionality of the Cardano Blockchain network. - -**Future Performance Requirements.** Planned development such as new mechanisms for out- -of-memory storage may impact block diffusion or other times. When changing parameters, it is -necessary to consider these future performance requirements as well as the current operation of -the Cardano Blockchain. Until development is complete, the requirements will be conservative; -they may then be relaxed to account for actual timing behavior. - -### Automated Checking ("Guardrails Script") - -A script hash is associated with the constitution hash when a **New Constitution or Guardrails -Script** governance action is enacted. It acts as an additional safeguard to the ledger rules and -types, filtering non-compliant governance actions. +#### Automated Checking ("Guardrails Script") + +A script hash is associated with the constitution hash when a New Constitution or Guardrails Script governance action is enacted. It acts as an additional safeguard to the ledger rules and types, filtering non-compliant governance actions. The guardrails script only affects two types of governance actions: -- **Parameter Update** actions, and -- **Treasury Withdrawal** actions. +- Parameter Update actions. +- Treasury Withdrawal actions. -The script is executed when either of these types of governance action is submitted on-chain. -This avoids scenarios where, for example, an erroneous script could prevent the chain from ever -enacting a Hard Fork action, resulting in deadlock. There are three different situations that apply -to script usage. +The script is executed when either of these types of governance action is submitted on-chain. The purpose of this script is to avoid scenarios where an erroneous script could prevent the chain from ever enacting a Hard Fork action, resulting in deadlock. -**Symbol and Explanation** +##### Symbol and Explanation - (y) The script can be used to enforce the guardrail. - (x) The script cannot be used to enforce the guardrail. -- (~ - reason) The script cannot be used to enforce the guardrail for the reason given, but - future ledger changes could enable this. +- (~ - reason) The script cannot be used to enforce the guardrail for the reason given, but future ledger changes could enable this. Guardrails may overlap: in this case, the most restrictive set of guardrails will apply. -Where a parameter is not explicitly listed in this document, then the script **must not** permit -any changes to the parameter. - -Conversely, where a parameter is explicitly listed in this document but no checkable guardrails -are specified, the script **must not** impose any constraints on changes to the parameter. - ### 2. GUARDRAILS AND GUIDELINES ON PROTOCOL PARAMETER UPDATE ACTIONS -Below are guardrails and guidelines for changing updatable protocol parameter settings via the -protocol parameter update governance action such that the Cardano Blockchain is never in an -unrecoverable state as a result of such changes. - -Note that there are at least five different sources of parameter names, and these are not always -consistent: - -1. The name used in the Genesis file -2. The name used in protocol parameter update governance actions -3. The name used internally in ledger rules -4. The name used in the formal ledger specification -5. The name used in research papers - -Where these parameter names differ, this Appendix uses the second convention. - -#### Guardrails - -**PARAM-01** (y) Any protocol parameter that is not explicitly named in this document **must -not** be changed by a Parameter update governance action. - -**PARAM-02** (y) Where a protocol parameter is explicitly listed in this document but no -checkable guardrails are specified, the guardrails script **must not** impose any constraints on -changes to the parameter. Checkable guardrails are shown by a (y). - -### 2.1. Critical Protocol Parameters - -The below protocol parameters are critical from a security point of view. - -_Parameters that are Critical to the Operation of the Blockchain_ - -- *maximum block body size* (*maxBlockBodySize*) -- *maximum transaction size* (*maxTxSize*) -- *maximum block header size* (*maxBlockHeaderSize*) -- *maximum size of a serialized asset value* (*maxValueSize*) -- *maximum script execution/memory units in a single block* (*maxBlockExecutionUnits[steps/memory]*) -- *minimum fee coefficient* (*txFeePerByte*) -- *minimum fee constant* (*txFeeFixed*) -- *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*) -- *minimum Lovelace deposit per byte of serialized UTxO* (*utxoCostPerByte*) -- *governance action deposit* (*govDeposit*) - -#### Guardrails - -**PARAM-03** (y) Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs **must** say "yes" with a collective support of more than 50% of all active block production stake. This is enforced by the guardrails on the stake pool voting threshold. - -**PARAM-04** (x) At least 3 months **should** normally pass between the publication of an off-chain proposal to change a critical protocol parameter and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation. - -_Parameters that are Critical to the Governance System_ - -- *delegation key Lovelace deposit* (*stakeAddressDeposit*) -- *pool registration Lovelace deposit* (*stakePoolDeposit*) -- *minimum fixed rewards cut for pools* (*minPoolCost*) -- *DRep deposit amount* (*dRepDeposit*) -- *minimal Constitutional Committee size* (*committeeMinSize*) -- *maximum term length (in epochs) for the Constitutional Committee members* (*committeeMaxTermLimit*) - -#### Guardrails - -**PARAM-05** (y) DReps **must** vote "yes" with a collective support of more than 50% of all active voting stake. This is enforced by the guardrails on the DRep voting thresholds. - -**PARAM-06** (x) At least 3 months **should** normally pass between the publication of an off-chain proposal to change a parameter that is critical to the governance system and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation. - -### 2.2. Economic Parameters - -The overall goals when managing economic parameters are to: - -1. Enable long-term economic sustainability for the Cardano Blockchain ecosystem; -2. Ensure that stake pools are adequately rewarded for maintaining the Cardano Blockchain; -3. Ensure that ada holders are adequately rewarded for using stake in constructive ways, including when delegating ada for block production; and -4. Balance economic incentives for different Cardano Blockchain ecosystem stakeholders, including but not limited to Stake Pool Operators, ada holders, DeFi users, infrastructure users, developers (e.g., DApps), and financial intermediaries (e.g., exchanges). - -_Triggers for Change_ - -1. Significant changes in the fiat value of ada resulting in potential problems with security, performance, or functionality. -2. Changes in transaction volumes or types. -3. Community requests or suggestions. -4. Emergency situations that require changes to economic parameters. - -_Counter-indicators_ - -Changes to the economic parameters should not be made in isolation. They need to account for: - -- External economic factors. -- Network security concerns. - -_Core Metrics_ - -- Fiat value of ada resulting in potential problems with security, performance, or functionality. -- Transaction volumes and types. -- Number and health of stake pools. -- External economic factors. - -_Changes to Specific Economic Parameters_ - -**Transaction fee per byte (txFeePerByte) and fixed transaction fee (txFeeFixed)** - -Defines the cost for basic transactions in Lovelace: - -fee(tx) = txFeeFixed + txFeePerByte x nBytes(tx) - -#### Guardrails - -**TFPB-01** (y) *txFeePerByte* **must not** be lower than 30 (0.000030 ada). This protects against low-cost denial of service attacks. - -**TFPB-02** (y) *txFeePerByte* **must not** exceed 1,000 (0.001 ada). This ensures that transactions can be paid for. - -**TFPB-03** (y) *txFeePerByte* **must not** be negative. - -**TFF-01** (y) *txFeeFixed* **must not** be lower than 100,000 (0.1 ada). This protects against low-cost denial of service attacks. - -**TFF-02** (y) *txFeeFixed* **must not** exceed 10,000,000 (10 ada). This ensures that transactions can be paid for. - -**TFF-03** (y) *txFeeFixed* **must not** be negative. - -**TFGEN-01** (x - "should") To maintain a consistent level of protection against denial-of-service attacks, *txFeeFixed* and *txFeePerByte* **should** be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory]). - -**TFGEN-02** (x - unquantifiable) Any changes to *txFeeFixed* or *txFeePerByte* **must** consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee so that it becomes impossible to construct a transaction. - -_UTxO cost per byte (utxoCostPerByte)_ - -Defines the cost for storage in UTxOs: - -- Sets a minimum threshold on ada that is held within a single UTxO (~1 ada minimum, could be >= 50 ada in the worst case). -- Provides protection against low-cost denial of service attack on UTxO storage. This attack has been executed on other chains; it is not theoretical. -- DoS protection decreases in line with the free node memory (proportional to UTxO growth). -- Helps reduce long-term storage costs. -- Provides an incentive to return UTxOs when no longer needed. -- Should significantly exceed minimum tx cost (~0.15 ada). - -#### Guardrails - -**UCPB-01** (y) *utxoCostPerByte* **must not** be lower than 3,000 (0.003 ada). - -**UCPB-02** (y) *utxoCostPerByte* **must not** exceed 6,500 (0.0065 ada). - -**UCPB-03** (y) *utxoCostPerByte* **must not** be zero. - -**UCPB-04** (y) *utxoCostPerByte* **must not** be negative. - -**UCPB-05** (x - "should") Changes **should** account for: - -i) The acceptable cost of attack. -ii) The acceptable time for an attack (at least one epoch is assumed). -iii) The acceptable memory configuration for full node users (assumed to be 16GB for wallets or 24GB for stake pools). -iv) The sizes of UTxOs (~200B per UTxO minimum, up to about 10KB). -v) The current total node memory usage. - -_Stake address deposit (stakeAddressDeposit)_ - -Ensures that stake addresses are retired when no longer needed: - -- Helps reduce long-term storage costs. -- Helps limit CPU and memory costs in the ledger. - -The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Reducing the number of active stake addresses also reduces processing and memory costs at the epoch boundary when calculating stake snapshots. - -#### Guardrails - -**SAD-01** (y) *stakeAddressDeposit* **must not** be lower than 1,000,000 (1 ada). - -**SAD-02** (y) *stakeAddressDeposit* **must not** exceed 5,000,000 (5 ada). - -**SAD-03** (y) *stakeAddressDeposit* **must not** be negative. - -_Stake pool deposit (stakePoolDeposit)_ - -Ensures that stake pools are retired by the stake pool operator when no longer needed by them: - -- Helps reduce long-term storage costs. - -The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Rewards and stake snapshot calculations are also impacted by the number of active stake pools. - -#### Guardrails - -**SPD-01** (y) *stakePoolDeposit* **must not** be lower than 250,000,000 (250 ada). - -**SPD-02** (y) *stakePoolDeposit* **must not** exceed 500,000,000 (500 ada). - -**SPD-03** (y) *stakePoolDeposit* **must not** be negative. - -_Minimum Pool Cost (minPoolCost)_ - -Part of the rewards mechanism: - -- The minimum pool cost is transferred to the pool rewards address before any delegator rewards are paid. - -#### Guardrails - -**MPC-01** (y) *minPoolCost* **must not** be negative. - -**MPC-02** (y) *minPoolCost* **must not** exceed 500,000,000 (500 ada). - -**MPC-03** (x - "should") *minPoolCost* **should** be set in line with the economic cost for operating a pool. - -__Treasury Cut (treasuryCut)_ - -Part of the rewards mechanism: - -- The treasury cut portion of the monetary expansion is transferred to the treasury before any pool rewards are paid. -- Can be set in the range 0.0-1.0 (0%-100%). - -#### Guardrails - -**TC-01** (y) *treasuryCut* **must not** be lower than 0.1 (10%). - -**TC-02** (y) *treasuryCut* **must not** exceed 0.3 (30%). - -**TC-03** (y) *treasuryCut* **must not** be negative. - -**TC-04** (y) *treasuryCut* **must not** exceed 1.0 (100%). - -**TC-05** (~ - no access to change history) *treasuryCut* **must not** be changed more than once in any 36-epoch period (approximately 6 months). - -_Monetary Expansion Rate (monetaryExpansion)_ - -Part of the rewards mechanism: - -- The monetary expansion controls the amount of reserves that is used for rewards each epoch. -- Governs the long-term sustainability of Cardano. -- The reserves are gradually depleted until no rewards are supplied. - -#### Guardrails - -**ME-01** (y) *monetaryExpansion* **must not** exceed 0. - -**ME-02** (y) *monetaryExpansion* **must not** be lower than 0. - -**ME-03** (y) *monetaryExpansion* **must not** be negative. - -**ME-04** (x - "should") *monetaryExpansion* **should not** be varied by more than +/- 10% in any 73-epoch period (approximately 12 months). - -**ME-05** (x - "should") *monetaryExpansion* **should not** be changed more than once in any 36-epoch period (approximately 6 months). - -_Plutus Script Execution Prices (executionUnitPrices[priceSteps/priceMemory])_ - -Defines the fees for executing Plutus scripts: - -- Gives an economic return for Plutus script execution. -- Provides security against low-cost DoS attacks. - -#### Guardrails - -**EIUP-PS-01** (y) *executionUnitPrices[priceSteps]* **must not** exceed 2,000 / 10,000,000. - -**EIUP-PS-02** (y) *executionUnitPrices[priceSteps]* **must not** be lower than 500 / 10,000,000. - -**EIUP-PM-01** (y) *executionUnitPrices[priceMemory]* **must not** exceed 2,000 / 10,000. - -**EIUP-PM-02** (y) *executionUnitPrices[priceMemory]* **must not** be lower than 400 / 10,000. - -**EIUP-GEN-01** (x - "similar to") The execution prices **must** be set so that: - -- i) the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum-sized non-script transaction and -- ii) the cost of executing a transaction with maximum memory units is similar to the cost of a maximum-sized non-script transaction. - -**EIUP-GEN-02** (x - "should") The execution prices **should** be adjusted whenever transaction fees are adjusted (*txFeeFixed/txFeePerByte*). The goal is to ensure that the processing delay is similar for "full" transactions, regardless of their type. - -- This helps ensure that the requirements on block diffusion/propagation times are met. - -_Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte)_ - -Defines the cost for using Plutus reference scripts in Lovelace. - -#### Guardrails - -**MFRS-01** (y) *minFeeRefScriptCoinsPerByte* **must not** exceed 1,000 (0.001 ada). - -- This ensures that transactions can be paid for. - -**MFRS-02** (y) *minFeeRefScriptCoinsPerByte* **must not** be negative. - -**MFRS-03** (x - "should") To maintain a consistent level of protection against denial-of-service attacks, *minFeeRefScriptCoinsPerByte* **should** be adjusted whenever Plutus Execution prices are adjusted (*executionUnitPrices[steps/memory]*) and whenever *txFeeFixed* is adjusted. - -**MFRS-04** (x - unquantifiable) Any changes to *minFeeRefScriptCoinsPerByte* **must** consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee. - -### 2.3. Network Parameters - -The overall goals when managing the Cardano Blockchain network parameters are to: - -1. 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. -2. Balance traffic demands for different user groups, including payment transactions, minters of Fungible/Non-Fungible Tokens, Plutus scripts, DeFi developers, Stake Pool Operators, and voting transactions. - -_Triggers for Change_ - -Changes to network parameters may be triggered by: - -1. Measured changes in traffic demands over a 2-epoch period (10 days). -2. Anticipated changes in traffic demands. -3. Community requests. - -_Counter-indicators_ - -Changes may need to be reversed and/or should not be enacted in the event of: - -- Excessive block propagation delays. -- Stake pools being unable to handle traffic volume. -- Scripts being unable to complete execution. - -_Core Metrics_ - -All decisions on parameter changes should be informed by: - -- Block propagation delay profile. -- Traffic volume (block size over time). -- Script volume (size of scripts and execution units). -- Script execution cost benchmarks. -- Block propagation delay/diffusion benchmarks. - -Detailed benchmarking results are required to confirm the effect of any changes on mainnet performance or behavior prior to enactment. The effects of different transaction mixes must be analyzed, including normal transactions, Plutus scripts, and governance actions. - -#### Guardrails - -**NETWORK-01** (x - "should") No individual network parameter **should** change more than once per two epochs. - -**NETWORK-02** (x - "should") Only one network parameter **should** be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits. - -_Changes to Specific Network Parameters_ - -_Block Size (maxBlockBodySize)_ - -The maximum size of a block, in Bytes. - -#### Guardrails - -**MBBS-01** (y) *maxBlockBodySize* **must not** exceed 122,880 Bytes (120KB). - -**MBBS-02** (y) *maxBlockBodySize* **must not** be lower than 24,576 Bytes (24KB). - -**MBBS-03** (x - "exceptional circumstances") *maxBlockBodySize* **must not** be decreased, other than in exceptional circumstances where there are potential problems with security, performance, or functionality. - -**MBBS-04** (~ - no access to existing parameter values) *maxBlockBodySize* **must** be large enough to include at least one transaction (that is, *maxBlockBodySize* **must** be at least *maxTxSize*). - -**MBBS-05** (x - "should") *maxBlockBodySize* **should** be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch. - -**MBBS-06** (x - "should") The block size **should not** induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation, and benchmarking. - -**MBBS-07** (x - "unquantifiable") The impact of any change to *maxBlockBodySize* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to *maxBlockBodySize* must also consider future requirements for Plutus script execution (*maxBlockExecutionUnits[steps]*) against the total block diffusion target of 3s with 95% block propagation within 5s. The limit on maximum block size may be increased in the future if this is supported by benchmarking and monitoring results. - -_Transaction Size (maxTxSize)_ - -The maximum size of a transaction, in Bytes. - -#### Guardrails - -**MTS-01** (y) *maxTxSize* **must not** exceed 32,768 Bytes (32KB). - -**MTS-02** (y) *maxTxSize* **must not** be negative. - -**MTS-03** (~ - no access to existing parameter values) *maxTxSize* **must not** be decreased. - -**MTS-04** (~ - no access to existing parameter values) *maxTxSize* **must not** exceed *maxBlockBodySize*. - -**MTS-05** (x - "should") *maxTxSize* **should not** be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably **should** be increased by 2,048 Bytes (2KB) or less per epoch. - -**MTS-06** (x - "should") *maxTxSize* **should not** exceed 1/4 of the block size. - -_Memory Unit Limits (maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory])_ - -The limit on the maximum number of memory units that can be used by Plutus scripts, either per-transaction or per-block. - -#### Guardrails - -**MTEU-M-01** (y) *maxTxExecutionUnits[memory]* **must not** exceed 40,000,000 units. - -**MTEU-M-02** (y) *maxTxExecutionUnits[memory]* **must not** be negative. - -**MTEU-M-03** (~ - no access to existing parameter values) *maxTxExecutionUnits[memory]* **must not** be decreased. - -**MTEU-M-04** (x - "should") *maxTxExecutionUnits[memory]* **should not** be increased by more than 2,500,000 units in any epoch. - -**MBEU-M-01** (y) *maxBlockExecutionUnits[memory]* **must not** exceed 120,000,000 units. - -**MBEU-M-02** (y) *maxBlockExecutionUnits[memory]* **must not** be negative. - -**MBEU-M-03** (x - "should") *maxBlockExecutionUnits[memory]* **should not** be changed (increased or decreased) by more than 10,000,000 units in any epoch. - -**MBEU-M-04** (x - unquantifiable) The impact of any change to *maxBlockExecutionUnits[memory]* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the diffusion/propagation time budgets, as also impacted by *maxBlockExecutionUnits[steps]*. Any increase **must** also consider previously agreed future requirements for the total block size (*maxBlockBodySize*) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. - -**MEU-M-01** (~ - no access to existing parameter values) *maxBlockExecutionUnits[memory]* **must not** be less than *maxTxExecutionUnits[memory]*. - -_CPU Unit Limits (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps])_ - -The limit on the maximum number of CPU steps that can be used by Plutus scripts, either per-transaction or per-block. - -#### Guardrails - -**MTEU-S-01** (y) *maxTxExecutionUnits[steps]* **must not** exceed 15,000,000,000 (15Bn) units. - -**MTEU-S-02** (y) *maxTxExecutionUnits[steps]* **must not** be negative. - -**MTEU-S-03** (~ - no access to existing parameter values) *maxTxExecutionUnits[steps]* **must not** be decreased. - -**MTEU-S-04** (x - "should") *maxTxExecutionUnits[steps]* **should not** be increased by more than 500,000,000 (500M) units in any epoch (5 days). - -**MBEU-S-01** (y) *maxBlockExecutionUnits[steps]* **must not** exceed 40,000,000,000 (40Bn) units. - -**MBEU-S-02** (y) *maxBlockExecutionUnits[steps]* **must not** be negative. - -**MBEU-S-03** (x - "should") *maxBlockExecutionUnits[steps]* **should not** be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days). - -**MBEU-S-04** (x - unquantifiable) The impact of the change to *maxBlockExecutionUnits[steps]* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by *maxBlockExecutionUnits[memory]*. Any increase **must** also consider previously identified future requirements for the total block size (*maxBlockBodySize*) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but **must** be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. - -**MEU-S-01** (~ - no access to existing parameter values) *maxBlockExecutionUnits[steps]* **must not** be less than *maxTxExecutionUnits[steps]*. - -_Block Header Size (maxBlockHeaderSize)_ - -The size of the block header. - -**Note:** Increasing the block header size may affect the overall block size (*maxBlockBodySize*). - -#### Guardrails - -**MBHS-01** (y) *maxBlockHeaderSize* **must not** exceed 5,000 Bytes. - -**MBHS-02** (y) *maxBlockHeaderSize* **must not** be negative. - -**MBHS-03** (x - "largest valid header" is subject to change) *maxBlockHeaderSize* **must** be large enough for the largest valid header. - -**MBHS-04** (x - "should") *maxBlockHeaderSize* **should** only normally be increased if the protocol changes. +- PARAM-01 (y) Any protocol parameter that is not explicitly named in this document must not be changed by a Parameter update governance action. +- PARAM-02 (y) Where a protocol parameter is explicitly listed in this document but no checkable guardrails are specified, the guardrails script must not impose any constraints on changes to the parameter. Checkable guardrails are shown by a (y). -**MBHS-05** (x - "should") *maxBlockHeaderSize* **should** be within TCP's initial congestion window (3 or 10 MTUs). +#### 2.1 Critical Protocol Parameters -### 2.4. Technical/Security Parameters +##### Parameters that are Critical to the Operation of the Blockchain -The overall goals when managing the technical/security parameters are: +- `maxBlockBodySize` (maximum block body size) +- `maxTxSize` (maximum transaction size) +- `maxBlockHeaderSize` (maximum block header size) +- `maxValueSize` (maximum size of a serialized asset value) +- `maxBlockExecutionUnits` (maximum script execution/memory units in a single block) +- `txFeePerByte` (minimum fee coefficient) +- `txFeeFixed` (minimum fee constant) +- `minFeeRefScriptCoinsPerByte` (minimum fee per byte for reference scripts) +- `utxoCostPerByte` (minimum Lovelace deposit per byte of serialized UTxO) +- `govDeposit` (governance action deposit) -1. Ensure the security of the Cardano network in terms of decentralization, protection against Sybil and 51% attacks, and protection against denial of service attacks. -2. Enable changes to the Plutus language. +Guardrails: +- PARAM-03 (y) Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs must say "yes" with a collective support of more than 50% of all active block production stake. This is enforced by the guardrails on the stake pool voting threshold. +- PARAM-04 (x) At least 3 months should 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 an emergency network issue following careful technical discussion and evaluation. -_Triggers for Change_ +--- -1. Changes in the number of active SPOs. -2. Changes to the Plutus language. -3. Security threats. -4. Community requests. +##### Parameters that are Critical to the Governance System -_Counter-indicators_ +- `stakeAddressDeposit` (delegation key Lovelace deposit) +- `stakePoolDeposit` (pool registration Lovelace deposit) +- `minPoolCost` (minimum fixed rewards cut for pools) +- `dRepDeposit` (DRep deposit amount) +- `committeeMinSize` (minimal Constitutional Committee size) +- `committeeMaxTermLimit` (maximum term length in epochs for the Constitutional Committee members) -- Economic concerns, e.g., when changing the number of stake pools. +Guardrails: +- PARAM-05 (y) DReps must vote "yes" with a collective support of more than 50% of all active voting stake. This is enforced by the guardrails on the DRep voting thresholds. +- PARAM-06 (x) At least 3 months should 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 an emergency network issue following careful technical discussion and evaluation. -_Core Metrics_ +--- -- Number of stake pools. -- Level of decentralization. +#### 2.2. Economic Parameters -_Changes to Specific Technical/Security Parameters_ +##### `txFeePerByte` (transaction fee per byte) -_Target Number of Stake Pools (stakePoolTargetNum)_ +Guardrails: +- TFPB-01 (y) `txFeePerByte` must not be lower than 30 (0.000030 ada). This protects against low-cost denial of service attacks. +- TFPB-02 (y) `txFeePerByte` must not exceed 1,000 (0.001 ada). This ensures that transactions can be paid for. +- TFPB-03 (y) `txFeePerByte` must not be negative. -Sets the target number of stake pools: +--- -- The expected number of pools when the network is in the equilibrium state. -- Primarily a security parameter, ensuring decentralization by pool division/replication. -- Has an economic effect as well as a security effect; economic advice is also required when changing this parameter. -- Large changes in this parameter will trigger mass redelegation events. +##### `txFeeFixed` (fixed transaction fee) -#### Guardrails +Guardrails: +- TFF-01 (y) `txFeeFixed` must not be lower than 100,000 (0.1 ada). This protects against low-cost denial of service attacks. +- TFF-02 (y) `txFeeFixed` must not exceed 10,000,000 (10 ada). This ensures that transactions can be paid for. +- TFF-03 (y) `txFeeFixed` must not be negative. +- TFGEN-01 (x - "should") To maintain a consistent level of protection against denial-of-service attacks, `txFeeFixed` and `txFeePerByte` should be adjusted whenever Plutus Execution prices are adjusted (`executionUnitPrices[steps/memory]`). +- TFGEN-02 (x - unquantifiable) Any changes to `txFeeFixed` or `txFeePerByte` must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee so that it becomes impossible to construct a transaction. -**SPTN-01** (y) *stakePoolTargetNum* **must not** be lower than 250. +--- -**SPTN-02** (y) *stakePoolTargetNum* **must not** exceed 2,000. +##### `utxoCostPerByte` (UTxO cost per byte) -**SPTN-03** (y) *stakePoolTargetNum* **must not** be negative. +Guardrails: +- UCPB-01 (y) `utxoCostPerByte` must not be lower than 3,000 (0.003 ada). +- UCPB-02 (y) `utxoCostPerByte` must not exceed 6,500 (0.0065 ada). +- UCPB-03 (y) `utxoCostPerByte` must not be zero. +- UCPB-04 (y) `utxoCostPerByte` must not be negative. +- UCPB-05 (x - "should") Changes should account for: + - The acceptable cost of attack. + - The acceptable time for an attack (at least one epoch is assumed). + - The acceptable memory configuration for full node users (assumed to be 16GB for wallets or 24GB for stake pools). + - The sizes of UTxOs (~200B per UTxO minimum, up to about 10KB). + - The current total node memory usage. -**SPTN-04** (y) *stakePoolTargetNum* **must not** be zero. + --- -_Pledge Influence Factor (poolPledgeInfluence)_ +##### `stakeAddressDeposit` (Stake address deposit) -Enables the pledge protection mechanism: +Guardrails: +- SAD-01 (y) `stakeAddressDeposit` must not be lower than 1,000,000 (1 ada). +- SAD-02 (y) `stakeAddressDeposit` must not exceed 5,000,000 (5 ada). +- SAD-03 (y) `stakeAddressDeposit` must not be negative. -- Provides protection against Sybil attack. -- Higher values reward pools that have more pledge and penalize pools that have less pledge. -- Has an economic effect as well as technical effect; economic advice is also required. -- Can be set in the range 0.0-infinity. +--- -#### Guardrails +##### `stakePoolDeposit` (Stake pool deposit) -**PPI-01** (y) *poolPledgeInfluence* **must not** be lower than 0.1. +Guardrails: +- SPD-01 (y) `stakePoolDeposit` must not be lower than 250,000,000 (250 ada). +- SPD-02 (y) `stakePoolDeposit` must not exceed 500,000,000 (500 ada). +- SPD-03 (y) `stakePoolDeposit` must not be negative. -**PPI-02** (y) *poolPledgeInfluence* **must not** exceed 1.0. +--- -**PPI-03** (y) *poolPledgeInfluence* **must not** be negative. +##### `minPoolCost` (Minimum Pool Cost) -**PPI-04** (x - "should") *poolPledgeInfluence* **should not** vary by more than +/- 10% in any 18-epoch period (approximately 3 months). +Guardrails: +- MPC-01 (y) `minPoolCost` must not be negative. +- MPC-02 (y) `minPoolCost` must not exceed 500,000,000 (500 ada). +- MPC-03 (x - "should") `minPoolCost` should be set in line with the economic cost for operating a pool. -_Pool Retirement Window (poolRetireMaxEpoch)_ +--- -Defines the maximum number of epochs notice that a pool can give when planning to retire. +##### `treasuryCut` (Treasury Cut) -#### Guardrails +Guardrails: +- TC-01 (y) `treasuryCut` must not be lower than 0.1 (10%). +- TC-02 (y) `treasuryCut` must not exceed 0.3 (30%). +- TC-03 (y) `treasuryCut` must not be negative. +- TC-04 (y) `treasuryCut` must not exceed 1.0 (100%). +- TC-05 (~ - no access to change history) `treasuryCut` must not be changed more than once in any 36-epoch period (approximately 6 months). -**PRME-01** (y) *poolRetireMaxEpoch* **must not** be negative. +--- -**PRME-02** (x - "should") *poolRetireMaxEpoch* **should not** be lower than 1. +##### `monetaryExpansion` (Monetary Expansion Rate) -_Collateral Percentage (collateralPercentage)_ +Guardrails: +- ME-01 (y) `monetaryExpansion` must not exceed 0. +- ME-02 (y) `monetaryExpansion` must not be lower than 0. +- ME-03 (y) `monetaryExpansion` must not be negative. +- ME-04 (x - "should") `monetaryExpansion` should not be varied by more than +/- 10% in any 73-epoch period (approximately 12 months). +- ME-05 (x - "should") `monetaryExpansion` should not be changed more than once in any 36-epoch period (approximately 6 months). -Defines how much collateral must be provided when executing a Plutus script as a percentage of the normal execution cost: +--- -- Collateral is additional to fee payments. -- If a script fails to execute, then the collateral is lost. -- The collateral is never lost if a script executes successfully. -- Provides security against low-cost attacks by making it more expensive rather than less expensive to execute failed scripts. +##### `executionUnitPrices` (Plutus Script Execution Prices [priceSteps/priceMemory]) -#### Guardrails +Guardrails: +- EIUP-PS-01 (y) `executionUnitPrices[priceSteps]` must not exceed 2,000 / 10,000,000. +- EIUP-PS-02 (y) `executionUnitPrices[priceSteps]` must not be lower than 500 / 10,000,000. +- EIUP-PM-01 (y) `executionUnitPrices[priceMemory]` must not exceed 2,000 / 10,000. +- EIUP-PM-02 (y) `executionUnitPrices[priceMemory]` must not be lower than 400 / 10,000. +- EIUP-GEN-01 (x - "similar to") The execution prices must be set so that: + - i) the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum-sized non-script transaction and + - ii) the cost of executing a transaction with maximum memory units is similar to the cost of a maximum-sized non-script transaction. +- EIUP-GEN-02 (x - "should") The execution prices should be adjusted whenever transaction fees are adjusted (`txFeeFixed`/`txFeePerByte`). The goal is to ensure that the processing delay is similar for "full" transactions, regardless of their type, and to ensure that the requirements on block diffusion/propagation times are met. -**CP-01** (y) *collateralPercentage* **must not** be lower than 100. +--- -**CP-02** (y) *collateralPercentage* **must not** exceed 200. +##### `minFeeRefScriptCoinsPerByte` (Transaction fee per byte for a reference script) -**CP-03** (y) *collateralPercentage* **must not** be negative. +Guardrails: +- MFRS-01 (y) `minFeeRefScriptCoinsPerByte` must not exceed 1,000 (0.001 ada). +- MFRS-02 (y) `minFeeRefScriptCoinsPerByte` must not be negative. +- MFRS-03 (x - "should") To maintain a consistent level of protection against denial-of-service attacks, `minFeeRefScriptCoinsPerByte` should be adjusted whenever Plutus Execution prices are adjusted (`executionUnitPrices[steps/memory]`) and whenever `txFeeFixed` is adjusted. +- MFRS-04 (x - unquantifiable) Any changes to `minFeeRefScriptCoinsPerByte` must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee. -**CP-04** (y) *collateralPercentage* **must not** be zero. +--- -_Maximum number of collateral inputs (maxCollateralInputs)_ +#### 2.3. Network Parameters -Defines the maximum number of inputs that can be used for collateral when executing a Plutus script. +Guardrails: +- NETWORK-01 (x - "should") No individual network parameter should change more than once per two epochs. +- NETWORK-02 (x - "should") Only one network parameter should be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits. -#### Guardrails +--- -**MCI-01** (y) *maxCollateralInputs* **must not** be lower than 1. +##### `maxBlockBodySize` (Block Size) +Guardrails: +- MBBS-01 (y) `maxBlockBodySize` must not exceed 122,880 Bytes (120KB). +- MBBS-02 (y) `maxBlockBodySize` must not be lower than 24,576 Bytes (24KB). +- MBBS-03 (x - "exceptional circumstances") `maxBlockBodySize` must not be decreased, other than in exceptional circumstances where there are potential problems with security, performance, or functionality. +- MBBS-04 (~ - no access to existing parameter values) `maxBlockBodySize` must be large enough to include at least one transaction (that is, `maxBlockBodySize` must be at least `maxTxSize`). +- MBBS-05 (x - "should") `maxBlockBodySize` should be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch. +- MBBS-06 (x - "should") The block size should not induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation, and benchmarking. +- MBBS-07 (x - "unquantifiable") The impact of any change to `maxBlockBodySize` must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to `maxBlockBodySize` must also consider future requirements for Plutus script execution (`maxBlockExecutionUnits[steps]`) against the total block diffusion target of 3s with 95% block propagation within 5s. The limit on maximum block size may be increased in the future if this is supported by benchmarking and monitoring results. +--- -The limit on the serialized size of the Value in each output. +##### `maxTxSize` (Transaction Size) -#### Guardrails +Guardrails: +- MTS-01 (y) `maxTxSize` must not exceed 32,768 Bytes (32KB). +- MTS-02 (y) `maxTxSize` must not be negative. +- MTS-03 (~ - no access to existing parameter values) `maxTxSize` must not be decreased. +- MTS-04 (~ - no access to existing parameter values) `maxTxSize` must not exceed `maxBlockBodySize`. +- MTS-05 (x - "should") `maxTxSize` should not be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably should be increased by 2,048 Bytes (2KB) or less per epoch. +- MTS-06 (x - "should") `maxTxSize` should not exceed 1/4 of the block size. -**MVS-01** (y) *maxValueSize* **must not** exceed 12,288 Bytes (12KB). +--- -**MVS-02** (y) *maxValueSize* **must not** be negative. +##### `maxBlockExecutionUnits` (Block memory execution unit limits) -**MVS-03** (~ - no access to existing parameter values) *maxValueSize* **must** be less than *maxTxSize*. +Guardrails: +- MBEU-M-01 (y) `maxBlockExecutionUnits[memory]` must not exceed 120,000,000 units. +- MBEU-M-02 (y) `maxBlockExecutionUnits[memory]` must not be negative. +- MBEU-M-03 (x - "should") `maxBlockExecutionUnits[memory]` should not be changed (increased or decreased) by more than 10,000,000 units in any epoch. +- MBEU-M-04 (x - unquantifiable) The impact of any change to `maxBlockExecutionUnits[memory]` must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the diffusion/propagation time budgets, as also impacted by `maxBlockExecutionUnits[steps]`. Any increase must also consider previously agreed future requirements for the total block size (`maxBlockBodySize`) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. -**MVS-04** (~ - no access to existing parameter values) *maxValueSize* **must not** be reduced. +--- -**MVS-05** (x - "sensible output" is subject to interpretation) *maxValueSize* **must** be large enough to allow sensible outputs (e.g., any existing on-chain output or anticipated outputs that could be produced by new ledger rules). +##### `maxTxExecutionUnits` (Transaction memory execution unit limits) -_Plutus Cost Models (costModels)_ +Guardrails: +- MTEU-M-01 (y) `maxTxExecutionUnits[memory]` must not exceed 40,000,000 units. +- MTEU-M-02 (y) `maxTxExecutionUnits[memory]` must not be negative. +- MTEU-M-03 (~ - no access to existing parameter values) `maxTxExecutionUnits[memory]` must not be decreased. +- MTEU-M-04 (x - "should") `maxTxExecutionUnits[memory]` should not be increased by more than 2,500,000 units in any epoch. -Defines the base costs for each Plutus primitive in terms of CPU and memory units: +--- -- There are about 150 distinct micro-parameters in total. -- Cost models are defined for each Plutus language version. A new language version may introduce additional micro-parameters or remove existing micro-parameters. +##### `maxBlockExecutionUnits` (CPU block limits in steps) -#### Guardrails +Guardrails: +- MBEU-S-01 (y) `maxBlockExecutionUnits[steps]` must not exceed 40,000,000,000 (40Bn) units. +- MBEU-S-02 (y) `maxBlockExecutionUnits[steps]` must not be negative. +- MBEU-S-03 (x - "should") `maxBlockExecutionUnits[steps]` should not be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days). +- MBEU-S-04 (x - unquantifiable) The impact of the change to `maxBlockExecutionUnits[steps]` must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by `maxBlockExecutionUnits[memory]`. Any increase must also consider previously identified future requirements for the total block size (`maxBlockBodySize`) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. -**PCM-01** (x - unquantifiable) *Cost model* values **must** be set by benchmarking on a reference architecture. +--- -**PCM-02** (x - primitives and language versions aren't introduced in transactions) The *cost model* **must** be updated if new primitives are introduced or a new Plutus language version is added. +##### `maxTxExecutionUnits` (CPU transaction limits in steps) -**PCM-03** (~ - no access to *Plutus cost model* parameters) *Cost model* values **should not** be negative. +Guardrails: +- MTEU-S-01 (y) `maxTxExecutionUnits[steps]` must not exceed 15,000,000,000 (15Bn) units. +- MTEU-S-02 (y) `maxTxExecutionUnits[steps]` must not be negative. +- MTEU-S-03 (~ - no access to existing parameter values) `maxTxExecutionUnits[steps]` must not be decreased. +- MTEU-S-04 (x - "should") `maxTxExecutionUnits[steps]` should not be increased by more than 500,000,000 (500M) units in any epoch (5 days). -**PCM-04** (~ - no access to *Plutus cost model* parameters) A *cost model* **must** be supplied for each Plutus language version that the protocol supports. +--- -### 2.5. Governance Parameters +##### `maxBlockHeaderSize` (Block Header Size) -The overall goals when managing the governance parameters are to: +Guardrails: +- MBHS-01 (y) `maxBlockHeaderSize` must not exceed 5,000 Bytes. +- MBHS-02 (y) `maxBlockHeaderSize` must not be negative. +- MBHS-03 (x - "largest valid header" is subject to change) `maxBlockHeaderSize` must be large enough for the largest valid header. +- MBHS-04 (x - "should") `maxBlockHeaderSize` should only normally be increased if the protocol changes. +- MBHS-05 (x - "should") `maxBlockHeaderSize` should be within TCP's initial congestion window (3 or 10 MTUs). -1. Ensure governance stability. -2. Maintain a representative form of governance as outlined in CIP-1694. +--- -_Triggers for Change_ +#### 2.4. Technical/Security Parameters -Changes to governance parameters may be triggered by: +##### `stakePoolTargetNum` (Target Number of Stake Pools) -1. Community requests. -2. Regulatory requirements. -3. Unexpected or unwanted governance outcomes. -4. Entering a state of no confidence. +Guardrails: +- SPTN-01 (y) `stakePoolTargetNum` must not be lower than 250. +- SPTN-02 (y) `stakePoolTargetNum` must not exceed 2,000. +- SPTN-03 (y) `stakePoolTargetNum` must not be negative. +- SPTN-04 (y) `stakePoolTargetNum` must not be zero. -_Counter-indicators_ +--- -Changes may need to be reversed and/or should not be enacted in the event of: +##### `poolPledgeInfluence` (Pledge Influence Factor) -- Unexpected effects on governance. -- Excessive Layer 1 load due to on-chain voting or excessive numbers of governance actions. +Guardrails: +- PPI-01 (y) `poolPledgeInfluence` must not be lower than 0.1. +- PPI-02 (y) `poolPledgeInfluence` must not exceed 1.0. +- PPI-03 (y) `poolPledgeInfluence` must not be negative. +- PPI-04 (x - "should") `poolPledgeInfluence` should not vary by more than +/- 10% in any 18-epoch period (approximately 3 months). -_Core Metrics_ +--- -All decisions on parameter changes should be informed by: +##### `poolRetireMaxEpoch` (Pool Retirement Window) -- Governance participation levels. -- Governance behaviors and patterns. -- Regulatory considerations. -- Confidence in the governance system. -- The effectiveness of the governance system in managing necessary change. +Guardrails: +- PRME-01 (y) `poolRetireMaxEpoch` must not be negative. +- PRME-02 (x - "should") `poolRetireMaxEpoch` should not be lower than 1. -_Changes to Specific Governance Parameters_ +--- -_Deposit for Governance Actions (govDeposit)_ +##### `collateralPercentage` (Collateral Percentage) -The deposit that is charged when submitting a governance action: +Guardrails: +- CP-01 (y) `collateralPercentage` must not be lower than 100. +- CP-02 (y) `collateralPercentage` must not exceed 200. +- CP-03 (y) `collateralPercentage` must not be negative. +- CP-04 (y) `collateralPercentage` must not be zero. -- Helps to limit the number of actions that are submitted. +--- -#### Guardrails +##### `maxCollateralInputs` (Maximum number of collateral inputs) -**GD-01** (y) *govDeposit* **must not** be negative. +Guardrails: +- MCI-01 (y) `maxCollateralInputs` must not be lower than 1. -**GD-02** (y) *govDeposit* **must not** be lower than 1,000,000 (1 ada). +--- -**GD-03** (y) *govDeposit* **must not** exceed 10,000,000,000,000 (10 million ada). +##### `maxValueSize` -**GD-04** (x - "should") *govDeposit* **should** be adjusted in line with fiat changes. +Guardrails: +- MVS-01 (y) `maxValueSize` must not exceed 12,288 Bytes (12KB). +- MVS-02 (y) `maxValueSize` must not be negative. +- MVS-03 (~ - no access to existing parameter values) `maxValueSize` must be less than `maxTxSize`. +- MVS-04 (~ - no access to existing parameter values) `maxValueSize` must not be reduced. +- MVS-05 (x - "sensible output" is subject to interpretation) `maxValueSize` must be large enough to allow sensible outputs (e.g., any existing on-chain output or anticipated outputs that could be produced by new ledger rules). -_Deposit for DReps (dRepDeposit)_ +--- -The deposit that is charged when registering a DRep: +##### `costModels` (Plutus Cost Models) -- Helps to limit the number of active DReps. +Guardrails: +- PCM-01 (x - unquantifiable) Cost model values must be set by benchmarking on a reference architecture. +- PCM-02 (x - primitives and language versions aren't introduced in transactions) The cost model must be updated if new primitives are introduced or a new Plutus language version is added. +- PCM-03 (~ - no access to Plutus cost model parameters) Cost model values should not be negative. +- PCM-04 (~ - no access to Plutus cost model parameters) A cost model must be supplied for each Plutus language version that the protocol supports. -#### Guardrails +--- -**DRD-01** (y) *dRepDeposit* **must not** be negative. +#### 2.5. Governance Parameters -**DRD-02** (y) *dRepDeposit* **must not** be lower than 1,000,000 (1 ada). +##### `govDeposit` (Deposit for Governance Actions) -**DRD-03** (y) *dRepDeposit* **must not** exceed 100,000,000,000 (100,000 ada). +Guardrails: +- GD-01 (y) `govDeposit` must not be negative. +- GD-02 (y) `govDeposit` must not be lower than 1,000,000 (1 ada). +- GD-03 (y) `govDeposit` must not exceed 10,000,000,000,000 (10 million ada). +- GD-04 (x - "should") `govDeposit` should be adjusted in line with fiat changes. -**DRD-04** (x - "should") *dRepDeposit* **should** be adjusted in line with fiat changes. +--- -_DRep Activity Period (dRepActivity)_ +##### `dRepDeposit` (Deposit for DReps) -The period (as a whole number of epochs) after which a DRep is considered to be inactive for vote calculation purposes, if they do not vote on any proposal. +Guardrails: +- DRD-01 (y) `dRepDeposit` must not be negative. +- DRD-02 (y) `dRepDeposit` must not be lower than 1,000,000 (1 ada). +- DRD-03 (y) `dRepDeposit` must not exceed 100,000,000,000 (100,000 ada). +- DRD-04 (x - "should") `dRepDeposit` should be adjusted in line with fiat changes. -#### Guardrails +--- -**DRA-01** (y) *dRepActivity* **must not** be lower than 13 epochs (2 months). +##### `dRepActivity` (DRep Activity Period) -**DRA-02** (y) *dRepActivity* **must not** exceed 37 epochs (6 months). +Guardrails: +- DRA-01 (y) `dRepActivity` must not be lower than 13 epochs (2 months). +- DRA-02 (y) `dRepActivity` must not exceed 37 epochs (6 months). +- DRA-03 (y) `dRepActivity` must not be negative. +- DRA-04 (~ - no access to existing parameter values) `dRepActivity` must be greater than `govActionLifetime`. +- DRA-05 (x - "should") `dRepActivity` should be calculated in human terms (2 months, etc.). -**DRA-03** (y) *dRepActivity* **must not** be negative. +--- -**DRA-04** (~ - no access to existing parameter values) *dRepActivity* **must** be greater than *govActionLifetime*. +##### dRepVotingThresholds -**DRA-05** (x - "should") *dRepActivity* **should** be calculated in human terms (2 months, etc.). +- `dvtCommitteeNoConfidence` +- `dvtCommitteeNormal` +- `dvtHardForkInitiation` +- `dvtMotionNoConfidence` +- `dvtPPEconomicGroup` +- `dvtPPGovGroup` +- `dvtPPNetworkGroup` +- `dvtPPTechnicalGroup` +- `dvtTreasuryWithdrawal` +- `dvtUpdateToConstitution` -_DRep and SPO Governance Action Thresholds (dRepVotingThresholds[...], poolVotingThresholds[...])_ +##### poolVotingThresholds -Thresholds on the active voting stake that is required to ratify a specific type of governance action by either DReps or SPOs: +- `pvtCommitteeNoConfidence` +- `pvtCommitteeNormal` +- `pvtHardForkInitiation` +- `pvtMotionNoConfidence` +- `pvtPPSecurityGroup` -- Ensures legitimacy of the action. +Guardrails: +- VT-GEN-01 (y) All thresholds must be greater than 50% and less than or equal to 100%. +- VT-GEN-02 (y) Economic, network, and technical parameter thresholds must be in the range 51%-75%. +- VT-GEN-03 (y) Governance parameter thresholds must be in the range 75%-90%. +- VT-HF-01 (y) Hard fork action thresholds must be in the range 51%-80%. +- VT-CON-01 (y) New Constitution or guardrails script action thresholds must be in the range 65%-90%. +- VT-CC-01 (y) Update Constitutional Committee action thresholds must be in the range 51%-90%. +- VT-NC-01 (y) No confidence action thresholds must be in the range 51%-75%. -The threshold parameters are listed below: +--- -**dRepVotingThresholds**: -- *dvtCommitteeNoConfidence* -- *dvtCommitteeNormal* -- *dvtHardForkInitiation* -- *dvtMotionNoConfidence* -- *dvtPPEconomicGroup* -- *dvtPPGovGroup* -- *dvtPPNetworkGroup* -- *dvtPPTechnicalGroup* -- *dvtTreasuryWithdrawal* -- *dvtUpdateToConstitution* +##### `govActionLifetime` (Governance Action Lifetime) -**poolVotingThresholds**: -- *pvtCommitteeNoConfidence* -- *pvtCommitteeNormal* -- *pvtHardForkInitiation* -- *pvtMotionNoConfidence* -- *pvtPPSecurityGroup* +Guardrails: +- GAL-01 (y) `govActionLifetime` must not be lower than 1 epoch (5 days). +- GAL-03 (x - "should") `govActionLifetime` should not be lower than 2 epochs (10 days). +- GAL-02 (y) `govActionLifetime` must not exceed 15 epochs (75 days). +- GAL-04 (x - "should") `govActionLifetime` should be calibrated in human terms (e.g., 30 days, two weeks) to allow sufficient time for voting, etc., to take place. +- GAL-05 (~ - no access to existing parameter values) `govActionLifetime` must be less than `dRepActivity`. -#### Guardrails +--- -**VT-GEN-01** (y) All thresholds **must** be greater than 50% and less than or equal to 100%. +##### `committeeMaxTermLimit` (Maximum Constitutional Committee Term) -**VT-GEN-02** (y) Economic, network, and technical parameter thresholds **must** be in the range 51%-75%. +Guardrails: +- CMTL-01 (y) `committeeMaxTermLimit` must not be zero. +- CMTL-02 (y) `committeeMaxTermLimit` must not be negative. +- CMTL-03 (y) `committeeMaxTermLimit` must not be lower than 18 epochs (90 days, or approximately 3 months). +- CMTL-04 (y) `committeeMaxTermLimit` must not exceed 293 epochs (approximately 4 years). +- CMTL-05 (x - "should") `committeeMaxTermLimit` should not exceed 220 epochs (approximately 3 years). -**VT-GEN-03** (y) Governance parameter thresholds **must** be in the range 75%-90%. +--- -**VT-HF-01** (y) **Hard fork** action thresholds **must** be in the range 51%-80%. +##### `committeeMinSize` (Minimum Size of the Constitutional Committee) -**VT-CON-01** (y) **New Constitution or guardrails script action** thresholds **must** be in the range 65%-90%. +Guardrails: +- CMS-01 (y) `committeeMinSize` must not be negative. +- CMS-02 (y) `committeeMinSize` must not be lower than 3. +- CMS-03 (y) `committeeMinSize` must not exceed 10. -**VT-CC-01** (y) **Update Constitutional Committee action** thresholds **must** be in the range 51%-90%. +#### 2.6. Guardrails and Guidelines on Treasury Withdrawal Actions -**VT-NC-01** (y) **No confidence** action thresholds **must** be in the range 51%-75%. +Guardrails: +- TREASURY-01 (x) DReps must define a net change limit for the Cardano Treasury's balance per period of time. +- TREASURY-02 (x) The budget for the Cardano Treasury must not exceed the net change limit for the Cardano Treasury's balance per period of time. +- TREASURY-03 (x) The budget for the Cardano Treasury must be denominated in ADA. +- TREASURY-04 (x) Treasury withdrawals must not be ratified until there is a community-approved Cardano budget then in effect pursuant to a previous on-chain governance action agreed by the DReps with a threshold of greater than 50% of the active voting stake. -_Governance Action Lifetime (govActionLifetime)_ +--- -The period after which a governance action will expire if it is not enacted: +#### 2.7 Guardrails and Guidelines on Hard Fork Initiation Actions -- As a whole number of epochs. +Guardrails: +- HARDFORK-01 (~ - no access to existing parameter values) The major protocol version must be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version must be zero. +- HARDFORK-02 (~ - no access to existing parameter values) The minor protocol version must be no less than the minor version that will be enacted immediately prior to this change. +- HARDFORK-03 (~ - no access to existing parameter values) At least one of the protocol versions (major or minor or both) must change. +- HARDFORK-04 (x) At least 85% of stake pools by active stake should have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version. +- HARDFORK-05 (x) Any new updatable protocol parameters that are introduced with a hard fork must be included in this Appendix and suitable guardrails defined for those parameters. +- HARDFORK-06 (x) Settings for any new protocol parameters that are introduced with a hard fork must be included in the appropriate Genesis file. +- HARDFORK-07 (x) Any deprecated protocol parameters must be indicated in this Appendix. +- HARDFORK-08 (~ - no access to Plutus cost model parameters) New Plutus versions must be supported by a version-specific Plutus cost model that covers each primitive that is available in the new Plutus version. -#### Guardrails +--- -**GAL-01** (y) *govActionLifetime* **must not** be lower than 1 epoch (5 days). +#### 2.8 Guardrails and Guidelines on Update Constitutional Committee or Threshold Actions -**GAL-03** (x - "should") *govActionLifetime* **should not** be lower than 2 epochs (10 days). +Guardrails: +- UPDATE-CC-01 (x) Update Constitutional Committee and/or threshold and/or term governance actions must not be ratified until ADA holders have ratified through an on-chain governance action the Final Constitution. -**GAL-02** (y) *govActionLifetime* **must not** exceed 15 epochs (75 days). +--- -**GAL-04** (x - "should") *govActionLifetime* **should** be calibrated in human terms (e.g., 30 days, two weeks) to allow sufficient time for voting, etc., to take place. +#### 2.9 Guardrails and Guidelines on New Constitution or Guardrails Script Actions -**GAL-05** (~ - no access to existing parameter values) *govActionLifetime* **must** be less than *dRepActivity*. +Guardrails: +- NEW-CONSTITUTION-01 (x) A New Constitution or Guardrails Script governance action must be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action. -_Maximum Constitutional Committee Term (committeeMaxTermLimit)_ +--- -The limit on the maximum term that a committee member may serve. +#### 2.10. Monitoring and Reversion of Parameter Changes -#### Guardrails - -**CMTL-01** (y) *committeeMaxTermLimit* **must not** be zero. - -**CMTL-02** (y) *committeeMaxTermLimit* **must not** be negative. - -**CMTL-03** (y) *committeeMaxTermLimit* **must not** be lower than 18 epochs (90 days, or approximately 3 months). - -**CMTL-04** (y) *committeeMaxTermLimit* **must not** exceed 293 epochs (approximately 4 years). - -**CMTL-05** (x - "should") *committeeMaxTermLimit* **should not** exceed 220 epochs (approximately 3 years). - -_The minimum size of the Constitutional Committee (committeeMinSize)_ - -The least number of members that can be included in a Constitutional Committee following a governance action to change the Constitutional Committee. - -#### Guardrails - -**CMS-01** (y) *committeeMinSize* **must not** be negative. - -**CMS-02** (y) *committeeMinSize* **must not** be lower than 3. - -**CMS-03** (y) *committeeMinSize* **must not** exceed 10. - -### 2.6. Monitoring and Reversion of Parameter Changes - -All network parameter changes **must** be monitored carefully for no less than 2 epochs (10 days): - -- Changes **must** be reverted as soon as possible if block propagation delays exceed 4.5s for more than 5% of blocks over any 6-hour rolling window. - -All other parameter changes should be monitored carefully for any adverse effects on performance, security, or functionality. If such effects are observed, appropriate actions, including reversion to previous parameters, should be taken. - -A specific reversion/recovery plan **must be** produced for each parameter change. This plan must include: +A specific reversion/recovery plan must be produced for each parameter change. This plan must include: - Which parameters need to change and in which ways in order to return to the previous state (or a similar state). - How to recover the network in the event of a disastrous failure. -This plan **should** be followed if problems are observed following the parameter change. Note that not all changes can be reverted. Additional care must be taken when making changes to these parameters. - -### 2.7. Non-Updatable Protocol Parameters - -Some fundamental protocol parameters cannot be changed by the Protocol Parameter Update governance action. These parameters can only be changed in a new Genesis file as part of a hard fork. It is not necessary to provide specific guardrails on updating these parameters. - -### 3. GUARDRAILS AND GUIDELINES ON TREASURY WITHDRAWAL ACTIONS - -**Treasury withdrawal** actions specify the destination and amount of a number of withdrawals from the Cardano treasury. - -#### Guardrails - -**TREASURY-01** (x) DReps **must** define a net change limit for the Cardano Treasury's balance per period of time. - -**TREASURY-02** (x) The budget for the Cardano Treasury **must not** exceed the net change limit for the Cardano Treasury's balance per period of time. - -**TREASURY-03** (x) The budget for the Cardano Treasury **must** be denominated in ada. - -**TREASURY-04** (x) Treasury withdrawals **must not** be ratified until there is a community-approved Cardano budget then in effect pursuant to a previous on-chain governance action agreed by the DReps with a threshold of greater than 50% of the active voting stake. - -### 4. GUARDRAILS AND GUIDELINES ON HARD FORK INITIATION ACTIONS - -The **hard fork initiation** action requires both a new major and a new minor protocol version to be specified: - -- As positive integers. - -As the result of a hard fork, new updatable protocol parameters may be introduced. Guardrails may be defined for these parameters, which will take effect following the hard fork. Existing updatable protocol parameters may also be deprecated by the hard fork, in which case the guardrails become obsolete for all future changes. - -#### Guardrails - -**HARDFORK-01** (~ - no access to existing parameter values) The major protocol version **must** be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version **must** be zero. - -**HARDFORK-02** (~ - no access to existing parameter values) The minor protocol version **must** be no less than the minor version that will be enacted immediately prior to this change. - -**HARDFORK-03** (~ - no access to existing parameter values) At least one of the protocol versions (major or minor or both) **must** change. - -**HARDFORK-04** (x) At least 85% of stake pools by active stake **should** have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version. - -**HARDFORK-05** (x) Any new updatable protocol parameters that are introduced with a hard fork **must** be included in this Appendix and suitable guardrails defined for those parameters. - -**HARDFORK-06** (x) Settings for any new protocol parameters that are introduced with a hard fork **must** be included in the appropriate Genesis file. - -**HARDFORK-07** (x) Any deprecated protocol parameters **must** be indicated in this Appendix. - -**HARDFORK-08** (~ - no access to *Plutus cost model* parameters) New Plutus versions **must** be supported by a version-specific *Plutus cost model* that covers each primitive that is available in the new Plutus version. - -### 5. GUARDRAILS AND GUIDELINES ON UPDATE CONSTITUTIONAL COMMITTEE OR THRESHOLD ACTIONS - -**Update Constitutional Committee or Threshold** governance actions may change the size, composition, or required voting thresholds for the Constitutional Committee. - -#### Guardrails - -**UPDATE-CC-01** (x) **Update Constitutional Committee and/or threshold** **and/or term** governance actions **must not** be ratified until ada holders have ratified through an on-chain governance action the Final Constitution. - -### 6. GUARDRAILS AND GUIDELINES ON NEW CONSTITUTION OR GUARDRAILS SCRIPT ACTIONS - -New constitution or guardrails script actions change the hash of the on-chain constitution and the associated guardrails script. - -#### Guardrails - -**NEW-CONSTITUTION-01** (x) A **New Constitution** **or Guardrails Script** governance action **must** be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action. - -### 7. GUARDRAILS AND GUIDELINES ON NO CONFIDENCE ACTIONS - -**No confidence** actions signal a state of no confidence in the governance system. No guardrails are imposed on **No Confidence** actions. - -#### Guardrails - -- None - -### 8. GUARDRAILS AND GUIDELINES ON INFO ACTIONS - -**Info** actions are not enacted on-chain. No guardrails are imposed on **Info** actions. - -#### Guardrails - -- None - -### 9. GUARDRAILS DURING THE INTERIM PERIOD - -_Interim Period_ - -The Interim Period 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. +This plan should be followed if problems are observed following the parameter change. Note that not all changes can be reverted. Additional care must be taken when making changes to these parameters. -_Interim Period Technical Rollout:_ +--- -- The Chang Hard Fork will enable three initial CIP-1694 governance actions and enable the representative framework to be established. +#### 2.11. Non-Updatable Protocol Parameters -These actions are the **"Info"**, **"Hard-fork initiation"**, and **"Protocol parameter changes"** actions. - -ada holders will be able to register as and delegate to DReps immediately after the hard fork but, as described in CIP-1694, DRep voting will not be available, except on **"Info"** actions. This ensures that ada holders have sufficient time to choose their voting delegations. - -SPOs will be able to vote as described in CIP-1694. - -**"Hard-fork initiation"** and **"Protocol parameter changes"** actions will also be ratified by the Constitutional Committee. - -ada holders will be able to withdraw their staking rewards as usual. - -- A subsequent hard fork, ratified by the Constitutional Committee and SPOs, shortly after the Chang Hard Fork, will enable the four remaining CIP-1694 governance actions: - - - **"Treasury withdrawals"**, - - **"Motion of no-confidence"**, - - **"Update constitutional committee and/or threshold and/or terms"**, and - - **"New constitution or guardrails script"**. - -At this point, DRep voting will be enabled and staking rewards can only be withdrawn if the ada holder has delegated their vote (including to the pre-defined Abstain/No Confidence voting options). - -#### Guardrails - -**INTERIM-01** (x) To provide sufficient time for DReps to register and campaign and for ada holders to choose their initial voting delegations, at least 18 epochs (90 days, or approximately 3 months) **must** elapse after the Chang hard fork before the subsequent hard fork can be ratified. Once the subsequent hard fork is enacted, DRep voting can occur as described in CIP-1694. - -**INTERIM-02** (x) Treasury withdrawals **must not** be ratified until there is a community-approved Cardano Blockchain Ecosystem budget then in effect pursuant to a previous on-chain governance action. - -**INTERIM-03** (x) Treasury withdrawals **must** be consistent with the community-approved Cardano Blockchain ecosystem budget(s). - -**INTERIM-04** (x) ada holders **must** have ratified the Final Constitution as specified in Appendix II before ratifying any other proposed **"new constitution"**, **"update constitutional committee and/or threshold and/or terms"**, and **"motion of no-confidence"** governance actions. - -**INTERIM-05** (x) **"New guardrails script"** actions that are consistent with the Interim Constitution may be ratified during the interim period, provided the Interim Constitution itself is not changed. +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. -### 10. LIST OF PROTOCOL PARAMETER GROUPS +### LIST OF PROTOCOL PARAMETER GROUPS The protocol parameters are grouped by type, allowing different thresholds to be set for each group. -_The network group consists of:_ - -- *maximum block body size* (*maxBlockBodySize*) -- *maximum transaction size* (*maxTxSize*) -- *maximum block header size* (*maxBlockHeaderSize*) -- *maximum size of a serialized asset value* (*maxValueSize*) -- *maximum script execution units in a single transaction* (*maxTxExecutionUnits[steps]*) -- *maximum script execution units in a single block* (*maxBlockExecutionUnits[steps]*) -- *maximum number of collateral inputs* (*maxCollateralInputs*) - -_The economic group consists of:_ - -- *minimum fee coefficient* (*txFeePerByte*) -- *minimum fee constant* (*txFeeFixed*) -- *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*) -- *delegation key Lovelace deposit* (*stakeAddressDeposit*) -- *pool registration Lovelace deposit* (*stakePoolDeposit*) -- *monetary expansion* (*monetaryExpansion*) -- *treasury expansion* (*treasuryCut*) -- *minimum fixed rewards cut for pools* (*minPoolCost*) -- *minimum Lovelace deposit per byte of serialized UTxO* (*utxoCostPerByte*) -- *prices of Plutus execution units* (*executionUnitPrices[priceSteps/priceMemory]*) - -_The technical group consists of:_ - -- *pool pledge influence* (*poolPledgeInfluence*) -- *pool retirement maximum epoch* (*poolRetireMaxEpoch*) -- *desired number of pools* (*stakePoolTargetNum*) -- *Plutus execution cost models* (*costModels*) -- *proportion of collateral needed for scripts* (*collateralPercentage*) - -_The governance group consists of all the new protocol parameters that are introduced in CIP-1694:_ - -- *governance voting thresholds* (*dRepVotingThresholds[...], poolVotingThresholds[...]*) -- *governance action maximum lifetime in epochs* (*govActionLifetime*) -- *governance action deposit* (*govActionDeposit*) -- *DRep deposit amount* (*dRepDeposit*) -- *DRep activity period in epochs* (*dRepActivity*) -- *minimal constitutional committee size* (*committeeMinSize*) -- *maximum term length (in epochs) for the constitutional committee members* (*committeeMaxTermLimit*) - -## APPENDIX II: INTERIM CONSTITUTION - -### 1. PREAMBLE - -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. - -### 2. INTERIM GOVERNANCE STRUCTURE - -#### Section 1: Interim Constitutional Committee - -The Interim Constitutional Committee (ICC) shall be established to oversee the governance of the Cardano Blockchain during the Interim Period. The ICC shall have the authority to approve or reject governance actions, ensure compliance with the Interim Constitution, and oversee the transition to the Final Constitution. - -**Composition:** -- The ICC shall consist of a minimum of 3 and a maximum of 10 members. -- Members shall be selected based on their expertise, contributions to the Cardano ecosystem, and commitment to decentralized governance. - -**Term:** -- The term of the ICC members shall not exceed 18 epochs (90 days) unless extended by a community vote. - -**Powers:** -- The ICC shall have the power to veto governance actions that are deemed unconstitutional or detrimental to the Cardano ecosystem. -- The ICC shall ensure that all governance actions comply with the guardrails established in this Interim Constitution. - -**Dissolution:** -- The ICC shall be dissolved upon the ratification of the Final Constitution, at which point a new Constitutional Committee shall be established. - -#### Section 2: Interim Voting Mechanisms - -During the Interim Period, governance actions shall be subject to the following voting mechanisms: - -**DReps Voting:** -- Delegated Representatives (DReps) shall vote on governance actions on behalf of ADA holders. -- DRep votes shall be weighted according to the amount of ADA delegated to them. -- A simple majority of the active voting stake is required to approve a governance action. - -**SPOs Voting:** -- Stake Pool Operators (SPOs) shall vote on specific governance actions, particularly those related to protocol parameters and technical changes. -- SPO votes shall be weighted according to the amount of ADA staked in their pools. -- A simple majority of the active stake pool stake is required to approve a governance action. - -**Community Sentiment Votes:** -- Community sentiment votes (Info actions) shall be conducted to gauge the community's opinion on non-binding governance actions. -- Info actions shall not have any on-chain effects other than recording the outcome of the vote. - -### 3. TRANSITION TO FINAL CONSTITUTION - -#### Section 1: Development and Ratification - -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: - -1. **Community Consultation:** - - The Cardano community shall be actively involved in the consultation process, providing input and feedback on the draft Final Constitution. - -2. **Drafting Committee:** - - A Drafting Committee shall be established to compile and refine the input from the community into a cohesive Final Constitution. - - The Drafting Committee shall consist of representatives from various stakeholder groups, including ADA holders, DReps, SPOs, and developers. - -3. **Public Review:** - - The draft Final Constitution shall be made available for public review and comment for a minimum of 6 epochs (30 days). - -4. **Ratification Vote:** - - A ratification vote shall be conducted to approve the Final Constitution. - - A minimum of 67% of the active voting stake must support the Final Constitution for it to be ratified. - -#### Section 2: Implementation - -Upon ratification of the Final Constitution: - -1. **Establishment of the Constitutional Committee:** - - A new Constitutional Committee shall be established in accordance with the Final Constitution. - - The Interim Constitutional Committee shall be dissolved. - -2. **Transition of Governance Powers:** - - All governance powers and responsibilities shall transition from the Interim Constitutional Committee to the new Constitutional Committee. - - Any pending governance actions under the Interim Constitution shall be carried over and processed under the Final Constitution. - -3. **Guardrails and Protocol Parameters:** - - 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. - -### 4. AMENDMENTS TO THE INTERIM CONSTITUTION - -Amendments to this Interim Constitution may be proposed by any ADA holder, DRep, or SPO. The process for amending the Interim Constitution is as follows: - -1. **Proposal Submission:** - - The proposed amendment shall be submitted as a governance action, accompanied by a rationale and supporting documentation. - -2. **Review by the ICC:** - - The Interim Constitutional Committee shall review the proposed amendment for compliance with the guardrails and overall impact on the Cardano ecosystem. - -3. **Community Vote:** - - The proposed amendment shall be put to a community vote, requiring a minimum of 67% of the active voting stake to approve the amendment. - -4. **Implementation:** - - If approved, the amendment shall be implemented and the Interim Constitution shall be updated accordingly. - -### 5. FINAL PROVISIONS - -#### Section 1: Supremacy Clause - -In the event of a conflict between this Interim Constitution and any governance action or protocol parameter, this Interim Constitution shall prevail. - -#### Section 2: Continuity Clause - -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. - -#### Section 3: Interpretation - -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. - -#### Section 4: Dissolution of Interim Governance Structures - -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. - -## APPENDIX III: GLOSSARY OF TERMS - -**ADA:** The native cryptocurrency of the Cardano Blockchain. - -**Cardano Blockchain:** A decentralized blockchain platform that enables the development of smart contracts, decentralized applications (DApps), and digital assets. - -**CIP-1694:** A Cardano Improvement Proposal that outlines the governance framework for the Cardano Blockchain. - -**Constitutional Committee:** The governance body responsible for ensuring that governance actions are consistent with the Cardano Constitution. - -**DRep (Delegated Representative):** An individual or entity that represents ADA holders in the on-chain governance process by voting on governance actions on their behalf. - -**Epoch:** A time period used in the Cardano Blockchain, typically lasting 5 days. - -**Final Constitution:** The permanent governance framework for the Cardano Blockchain, to be ratified by the community and replace the Interim Constitution. - -**Guardrails:** Specific guidelines and constraints that govern the parameters and actions within the Cardano Blockchain ecosystem. - -**Hard Fork:** A protocol upgrade that changes the blockchain's rules and requires all nodes to upgrade to the new version. - -**Interim Constitution:** The temporary governance framework for the Cardano Blockchain during the transition to the Final Constitution. - -**SPO (Stake Pool Operator):** An individual or entity responsible for operating a stake pool, which participates in the consensus mechanism of the Cardano Blockchain. - -**Treasury:** A pool of ADA used to fund development and other initiatives within the Cardano ecosystem. - -## APPENDIX IV: INTERIM PERIOD ACTIONS AND TIMELINE - -### 1. INITIAL GOVERNANCE ACTIONS - -During the Interim Period, the following initial governance actions shall be prioritized: - -1. **Establishment of the Interim Constitutional Committee (ICC):** - - The ICC shall be established within 2 epochs following the Chang Hard Fork. - -2. **Delegated Representative (DRep) Registration:** - - DReps shall be allowed to register immediately following the Chang Hard Fork. - - ADA holders shall have the option to delegate their voting rights to registered DReps. - -3. **Community Sentiment (Info) Actions:** - - Info actions shall be used to gauge community sentiment on key governance topics. - - These actions shall not have on-chain effects but shall inform future governance decisions. - -4. **Initial Hard Fork Initiation:** - - The first hard fork initiation action shall be proposed to enable additional governance actions, such as Treasury withdrawals. - -### 2. TIMELINE FOR FINAL CONSTITUTION DEVELOPMENT - -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. - -1. **Community Consultation Phase:** - - Duration: 6 epochs (30 days). - - Purpose: Engage the Cardano community in discussions and solicit feedback on the principles, structure, and content of the Final Constitution. - - Actions: Conduct workshops, surveys, and community forums to gather input. - -2. **Drafting Phase:** - - Duration: 6 epochs (30 days). - - Purpose: The Drafting Committee compiles and integrates community feedback into a cohesive draft of the Final Constitution. - - Actions: The Drafting Committee meets regularly to refine the draft, considering all input from the community consultation phase. - -3. **Public Review Phase:** - - Duration: 6 epochs (30 days). - - Purpose: Present the draft Final Constitution to the Cardano community for public review and comment. - - Actions: The draft is published online, and a dedicated platform is made available for comments, suggestions, and discussion. - -4. **Revision Phase:** - - Duration: 4 epochs (20 days). - - Purpose: The Drafting Committee revises the draft based on community feedback from the public review phase. - - Actions: Final adjustments are made, and the draft is prepared for the ratification vote. - -5. **Ratification Vote:** - - Duration: 2 epochs (10 days). - - Purpose: Conduct a vote among ADA holders to ratify the Final Constitution. - - Threshold: A minimum of 67% of the active voting stake must support the Final Constitution for it to be ratified. - - Actions: Voting takes place on-chain, with results published immediately after the vote concludes. - -6. **Transition Phase:** - - Duration: 2 epochs (10 days). - - Purpose: Implement the Final Constitution and transition governance powers to the new governance structures. - - Actions: Dissolution of the Interim Constitutional Committee, establishment of the Constitutional Committee, and activation of the governance framework as outlined in the Final Constitution. - -### 3. INTERIM PERIOD GOVERNANCE ACTIONS - -During the Interim Period, specific governance actions shall be prioritized to ensure the smooth transition to the Final Constitution. These actions include: - -1. **Guardrails Implementation:** - - Purpose: Ensure all critical guardrails are in place to protect the integrity and stability of the Cardano Blockchain during the Interim Period. - - Actions: Establish, review, and amend guardrails as necessary. - -2. **Budget Proposal and Approval:** - - Purpose: Develop and approve a budget for the ongoing maintenance and development of the Cardano Blockchain during the Interim Period. - - Actions: The Interim Constitutional Committee, in collaboration with the community, shall propose a budget that must be approved through an on-chain governance vote. - -3. **Hard Fork Preparation:** - - Purpose: Prepare for necessary hard forks that may be required to implement changes during the Interim Period. - - Actions: Engage with developers, SPOs, and the community to ensure a smooth transition during hard fork events. - -4. **Treasury Management:** - - Purpose: Oversee the management and distribution of funds from the Cardano Treasury. - - Actions: Review treasury withdrawal proposals, ensuring alignment with community goals and budgetary constraints. - -5. **Community Engagement and Education:** - - Purpose: Ensure that the Cardano community remains informed and engaged throughout the Interim Period. - - Actions: Conduct regular updates, educational sessions, and community events to explain governance processes and encourage participation. - -## APPENDIX V: IMPLEMENTATION GUIDELINES FOR CIP-1694 - -### 1. INTRODUCTION TO CIP-1694 IMPLEMENTATION - -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. - -### 2. ESTABLISHMENT OF GOVERNANCE BODIES - -#### Section 1: Delegated Representatives (DReps) - -DReps play a crucial role in representing ADA holders in the governance process. The following steps outline the process for establishing DReps: - -1. **Registration:** - - DReps must register on-chain, providing information about their qualifications, experience, and governance philosophy. - - Registration fees may apply, as specified in the governance parameters. - -2. **Delegation:** - - ADA holders can delegate their voting power to registered DReps. - - Delegation is flexible, allowing ADA holders to change their DRep at any time. - -3. **Responsibilities:** - - DReps are expected to vote on governance actions, represent the interests of their delegators, and adhere to the code of conduct. - -4. **Accountability:** - - DReps must disclose any conflicts of interest and provide regular updates to their delegators. - - Failure to act in the best interests of delegators may result in loss of delegation or other penalties. - -#### Section 2: Stake Pool Operators (SPOs) - -SPOs contribute to the security and decentralization of the Cardano Blockchain and participate in governance actions. The following guidelines apply to SPOs: - -1. **Participation:** - - SPOs are automatically eligible to vote on certain governance actions, particularly those related to protocol parameters and technical changes. - -2. **Voting Power:** - - SPO voting power is weighted according to the amount of ADA staked in their pools. - - SPOs must act transparently and in the best interests of the Cardano community. - -3. **Conflicts of Interest:** - - SPOs must disclose any potential conflicts of interest and refrain from voting on actions where such conflicts may arise. - -4. **Compliance:** - - SPOs must comply with all governance guidelines and adhere to the code of conduct. - -#### Section 3: Constitutional Committee - -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: - -1. **Selection:** - - Members of the Constitutional Committee shall be selected based on their expertise, contributions to the Cardano ecosystem, and commitment to decentralized governance. - - The number of members and term limits are specified in the governance parameters. - -2. **Responsibilities:** - - The Constitutional Committee reviews all governance actions to ensure they comply with the Cardano Constitution. - - The Committee may veto any governance action that violates the Constitution. - -3. **Transparency:** - - The Constitutional Committee must operate transparently, publishing its decisions and the rationale behind them. - - All meetings and votes of the Committee should be documented and made available to the public. - -4. **Accountability:** - - Members of the Constitutional Committee are accountable to the Cardano community and must act in the best interests of the ecosystem. - - The community may propose changes to the Committee's composition or powers through governance actions. - -### 3. VOTING PROCEDURES - -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: - -#### Section 1: Proposal Submission - -1. **Eligibility:** - - Any ADA holder, DRep, or SPO may submit a governance proposal. - - Proposals must be submitted in a standardized format, including a clear rationale, potential impact, and supporting documentation. - -2. **Submission Process:** - - Proposals are submitted on-chain and are subject to a deposit fee, as specified in the governance parameters. - - The proposal is then reviewed by the relevant governance bodies (e.g., DReps, SPOs, Constitutional Committee). - -3. **Review and Approval:** - - Proposals are reviewed for completeness, compliance with guardrails, and potential impact on the Cardano ecosystem. - - Once approved, proposals are scheduled for a vote. - -#### Section 2: Voting Process - -1. **Voting Period:** - - The voting period for each proposal is defined in the governance parameters and typically lasts between 5 to 15 epochs. - - During this period, ADA holders, DReps, and SPOs can cast their votes. - -2. **Voting Mechanisms:** - - Votes are cast on-chain, and each vote is weighted according to the voter's stake (for ADA holders) or delegation (for DReps). - - The results of the vote are automatically recorded on the blockchain. - -3. **Thresholds:** - - Different types of proposals may require different thresholds for approval (e.g., simple majority, supermajority). - - Thresholds are defined in the governance parameters and vary based on the type and significance of the proposal. - -4. **Result Publication:** - - The results of the vote are published immediately after the voting period ends. - - All votes and outcomes are recorded on-chain, ensuring transparency and immutability. - -#### Section 3: Implementation of Approved Proposals - -1. **Execution:** - - Approved proposals are automatically executed by smart contracts, where applicable. - - For proposals requiring manual implementation (e.g., changes to off-chain processes), the responsible parties are notified, and a timeline for implementation is established. - -2. **Monitoring:** - - The implementation of approved proposals is monitored by the relevant governance bodies to ensure compliance and effectiveness. - - Any issues or deviations from the approved proposal must be reported and addressed promptly. - -3. **Feedback Loop:** - - The Cardano community is encouraged to provide feedback on the implementation and outcomes of approved proposals. - - This feedback may be used to refine future proposals or governance processes. - -### 4. ONGOING GOVERNANCE MAINTENANCE - -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: - -#### Section 1: Regular Reviews - -1. **Periodic Audits:** - - Governance processes, including voting procedures, the role of DReps, SPOs, and the Constitutional Committee, shall undergo periodic audits. - - Audits will assess compliance with the Constitution, effectiveness, and areas for improvement. - - The results of these audits will be made public and may inform future governance proposals. - -2. **Annual Governance Review:** - - An annual review of the governance framework shall be conducted by the Constitutional Committee in collaboration with the Cardano community. - - This review will consider the performance of the governance structures, the effectiveness of the guardrails, and any evolving needs of the Cardano ecosystem. - - Recommendations from the review may lead to proposed amendments or updates to the Constitution or governance parameters. - -3. **Community Feedback:** - - Continuous feedback from the Cardano community will be solicited to ensure the governance framework remains responsive to community needs. - - Mechanisms for gathering feedback include surveys, forums, and public consultations. - -4. **Review of Guardrails:** - - Guardrails that govern protocol parameters and governance actions should be reviewed regularly to ensure they remain relevant and effective. - - Changes to guardrails may be proposed as governance actions and must go through the standard voting process. - -#### Section 2: Governance Updates and Amendments - -1. **Amendment Proposals:** - - Any member of the Cardano community may propose amendments to the Constitution, guardrails, or other governance parameters. - - Proposals must include a clear rationale, potential impacts, and a detailed plan for implementation. - -2. **Review Process:** - - Amendment proposals will be reviewed by the Constitutional Committee for compliance with the existing governance framework. - - The Committee may provide recommendations or request revisions before the proposal is put to a vote. - -3. **Voting on Amendments:** - - Amendments to the Constitution or guardrails require a supermajority (e.g., 67% of the active voting stake) to be approved. - - The results of the vote will be binding, and approved amendments will be implemented as specified. - -4. **Implementation of Amendments:** - - Once an amendment is approved, it will be incorporated into the governance framework. - - Any necessary updates to documentation, processes, or smart contracts will be executed to reflect the amendment. - -5. **Communication of Changes:** - - All amendments and updates to the governance framework will be communicated to the Cardano community through official channels. - - Educational resources may be provided to help the community understand the implications of the changes. - -#### Section 3: Emergency Governance Actions - -1. **Definition of Emergencies:** - - An emergency is defined as any situation that poses an immediate threat to the security, stability, or functionality of the Cardano Blockchain. - - Examples include severe security vulnerabilities, catastrophic failures, or unforeseen critical issues. - -2. **Emergency Action Procedures:** - - In the event of an emergency, the Constitutional Committee may expedite the governance process to address the issue. - - Emergency actions may include temporary changes to protocol parameters, suspension of certain governance processes, or other measures necessary to mitigate the threat. - -3. **Community Notification:** - - The Cardano community must be notified immediately of any emergency governance actions, including the rationale, expected impact, and duration. - - A full report on the emergency and the actions taken must be provided once the situation is resolved. - -4. **Review and Ratification:** - - Any emergency actions taken must be reviewed and ratified by the community through a governance vote as soon as possible. - - If the community does not ratify the emergency actions, they must be rolled back, and alternative solutions must be proposed. - -5. **Post-Emergency Evaluation:** - - 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. - - The findings of this evaluation may inform updates to the emergency governance procedures. - -### 5. COMMUNITY ENGAGEMENT AND EDUCATION - -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: - -#### Section 1: Governance Education Programs - -1. **Workshops and Webinars:** - - 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. - - These sessions will be open to all community members and will be recorded and made available online. - -2. **Educational Resources:** - - Comprehensive educational materials, including guides, FAQs, and video tutorials, will be developed to explain the governance processes in detail. - - These resources will be accessible through the official Cardano website and other community platforms. - -3. **Onboarding for New Participants:** - - 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. - - This program will include step-by-step instructions on how to participate in governance actions, delegate voting power, and submit proposals. - -#### Section 2: Community Outreach - -1. **Regular Updates:** - - The Cardano governance bodies will provide regular updates to the community on ongoing governance actions, upcoming votes, and other relevant developments. - - Updates will be shared through multiple channels, including the official Cardano blog, social media, and community forums. - -2. **Open Forums:** - - Open forums and discussion groups will be established to facilitate dialogue between community members and governance bodies. - - These forums will provide a platform for community members to ask questions, share ideas, and provide feedback on governance matters. - -3. **Community Ambassadors:** - - A network of community ambassadors will be established to represent different regions and demographic groups within the Cardano ecosystem. - - Ambassadors will play a key role in disseminating information, gathering feedback, and ensuring that diverse perspectives are considered in governance decisions. - -4. **Surveys and Polls:** - - Regular surveys and polls will be conducted to gauge community sentiment on various governance issues and proposals. - - The results of these surveys will be used to inform decision-making and prioritize governance actions. - -#### Section 3: Transparency and Accountability - -1. **Public Reporting:** - - All governance bodies, including the Constitutional Committee, DReps, and SPOs, will publish regular reports on their activities, decisions, and the outcomes of governance actions. - - These reports will be made available to the entire Cardano community to ensure transparency and accountability. - -2. **Audit and Oversight:** - - Independent audits of the governance processes and financial management (e.g., Treasury withdrawals) will be conducted periodically. - - The results of these audits will be published and any recommendations for improvement will be considered and implemented as appropriate. - -3. **Feedback Mechanisms:** - - Formal mechanisms will be established to allow community members to provide feedback on the performance and conduct of governance bodies. - - This feedback will be reviewed regularly, and governance bodies will be expected to address any issues or concerns raised by the community. - -### 6. CONCLUSION - -The implementation of CIP-1694 and the ongoing development of the Cardano governance framework represent a significant step toward a truly decentralized, community-driven ecosystem. By adhering to the principles of transparency, inclusivity, and accountability, the Cardano community can ensure the long-term success and sustainability of the blockchain. - -As the governance framework continues to evolve, the active participation and engagement of all stakeholders will be crucial. Through collaboration, education, and a shared commitment to the principles outlined in the Cardano Constitution, the community can achieve its vision of a decentralized, fair, and resilient blockchain ecosystem. - -This document, along with the Cardano Constitution, shall serve as a living framework, continuously adapted and improved in response to the needs and aspirations of the Cardano community. +The network group consists of: +- `maxBlockBodySize` (maximum block body size) +- `maxTxSize` (maximum transaction size) +- `maxBlockHeaderSize` (maximum block header size) +- `maxValueSize` (maximum size of a serialized asset value) +- `maxTxExecutionUnits[steps]` (maximum script execution units in a single transaction) +- `maxBlockExecutionUnits[steps]` (maximum script execution units in a single block) +- `maxCollateralInputs` (maximum number of collateral inputs) + +The economic group consists of: +- `txFeePerByte` (minimum fee coefficient) +- `txFeeFixed` (minimum fee constant) +- `minFeeRefScriptCoinsPerByte` (minimum fee per byte for reference scripts) +- `stakeAddressDeposit` (delegation key Lovelace deposit) +- `stakePoolDeposit` (pool registration Lovelace deposit) +- `monetaryExpansion` (monetary expansion) +- `treasuryCut` (treasury expansion) +- `minPoolCost` (minimum fixed rewards cut for pools) +- `utxoCostPerByte` (minimum Lovelace deposit per byte of serialized UTxO) +- `executionUnitPrices[priceSteps/priceMemory]` (prices of Plutus execution units) + +The technical group consists of: +- `poolPledgeInfluence` (pool pledge influence) +- `poolRetireMaxEpoch` (pool retirement maximum epoch) +- `stakePoolTargetNum` (desired number of pools) +- `costModels` (Plutus execution cost models) +- `collateralPercentage` (proportion of collateral needed for scripts) + +The governance group consists of all the new protocol parameters that are introduced in CIP-1694: +- `dRepVotingThresholds[...]`, `poolVotingThresholds[...]` (governance voting thresholds) +- `govActionLifetime` (governance action maximum lifetime in epochs) +- `govActionDeposit` (governance action deposit) +- `dRepDeposit` (DRep deposit amount) +- `dRepActivity` (DRep activity period in epochs) +- `committeeMinSize` (minimal constitutional committee size) +- `committeeMaxTermLimit` (maximum term length in epochs for the constitutional committee members) \ No newline at end of file From c89d80b629218125563871ac69a6e17a5a6bd9fb Mon Sep 17 00:00:00 2001 From: rwiley <30681834+Cerkoryn@users.noreply.github.com> Date: Mon, 11 Nov 2024 16:07:06 -0500 Subject: [PATCH 04/17] Cerkoryn Draft Release --- CONSTITUTION.md | 562 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 548 insertions(+), 14 deletions(-) diff --git a/CONSTITUTION.md b/CONSTITUTION.md index b7e57ff..902f631 100644 --- a/CONSTITUTION.md +++ b/CONSTITUTION.md @@ -10,23 +10,31 @@ Through the adoption of this Constitution, the Cardano Blockchain ecosystem esta ### Section 1 -Transactions on the Cardano Blockchain should not be intentionally degraded or censored. +Transactions on the Cardano Blockchain shall not be intentionally degraded or censored. -The cost of transactions on the Cardano Blockchain should be predictable and not unreasonable. +The cost of transactions on the Cardano Blockchain should be predictable and reasonable. -Any individual or entity desiring to develop and deploy non-malicious applications on the Cardano Blockchain should not unreasonably be prevented from deploying such applications as-intended. +Any individual or entity desiring to develop and deploy non-malicious applications on the Cardano Blockchain shall not be prevented from deploying such applications as-intended. -The Cardano Blockchain shall not lock in an ADA owner’s value without an owner’s consent. +When contributions to the system are recognized, recorded, or processed, they should be done so fairly. -The Cardano Blockchain shall preserve in a safe manner any value and information an owner of ADA seeks to store on the Cardano Blockchain. +The system shall not spend, delegate, or stake any ADA owner’s assets without the owner’s consent. -The Cardano Blockchain shall not unnecessarily waste system, network, or economic resources. +The Cardano Blockchain shall reasonably preserve any value and information an owner of ADA seeks to store, while accommodating evolving innovations that ensure sustainable resource management. + +Resources, whether system, network, or economic, shall not be unnecessarily wasted. + +Users shall be treated fairly, and the system shall adapt in alignment with their collective will, ensuring long-term sustainability and viability. + +The system shall not require users to violate local laws and regulations, and should provide alternatives whenever feasible. + +Operations should be transparent, predictable, verifiable, and interpretable, ensuring fairness and balance, while also supporting privacy-focused use cases where appropriate. ### Section 2 -The Cardano Blockchain shall operate in accordance with the Cardano Blockchain Guardrails as set forth in the Guardrails on-chain scripts or built-in ledger rules. +Operations shall be in accordance with the Guardrails as set forth in the Guardrails appendix and on-chain scripts. -The Cardano community may modify the Cardano Blockchain Guardrails after a proposal to change them is voted on and ratified. +The Cardano community may modify the Guardrails after a proposal to change them is voted on and ratified. ## ARTICLE II. THE CARDANO BLOCKCHAIN COMMUNITY @@ -44,8 +52,7 @@ Reasonable fees and/or deposits may be set via parameters to prevent spam and ab ### Section 1 -The Cardano Blockchain ecosystem shall be governed by a decentralized, on-chain governance -model. +The Cardano Blockchain ecosystem shall be governed by a decentralized, on-chain governance model. ### Section 2 @@ -61,11 +68,13 @@ No withdrawals from the Cardano treasury shall be permitted except as part of a No withdrawals from the Cardano treasury in excess of 1,000,000 ADA shall be permitted without sufficient independent audits, oversight metrics, and a reasonable amount of ADA to cover the cost of such audits. +The total supply of ADA shall not be modified to be less or more than 45,000,000,000. + ## ARTICLE IV. DELEGATED REPRESENTATIVES ### Section 1 -Any owner of ADA shall have the option to register as a dRep. +Any owner of ADA shall have the permissionless option to register as a dRep. Any owner of ADA shall be allowed to delegate their voting stake to one or more registered dReps, including themselves. @@ -73,6 +82,8 @@ Any owner of ADA shall be allowed to delegate their voting stake to one or more ### Section 1 +Any owner of ADA shall have the permissionless option to register a stake pool. + Any owner of ADA shall be allowed to delegate their voting stake to one or more registered stake pools, including their own. ## ARTICLE VI. CONSTITUTIONAL COMMITTEE @@ -83,11 +94,11 @@ The Constitutional Committee shall be limited to voting on the constitutionality ### Section 2 -The Constitutional Committee shall be composed of a set number of members and must pass any proposals via a voting threshold defined by the Cardano Blockchain Guardrails and on-chain ledger rules. +The Constitutional Committee shall be composed of a set number of members and must pass any proposals via a voting threshold defined by the Cardano Blockchain Guardrails. ### Section 3 -Members of the Constitutional Committee shall serve terms for a specific period of time as-defined by the Cardano Blockchain Guardrails and on-chain ledger rules. +Members of the Constitutional Committee shall serve terms for a specific period of time as-defined by the Cardano Blockchain Guardrails. ### Section 4 @@ -97,4 +108,527 @@ The Constitutional Committee shall transparently publish each decision and provi ### Section 1 -Amendments to this Constitution require approval through an on-chain governance action by ADA owners, meeting a threshold set by an on-chain parameter for constitutional amendments. \ No newline at end of file +Amendments to this Constitution require approval through an on-chain governance action by ADA owners, meeting a threshold set by the Cardano Blockchain Guardrails and corresponding parameters for constitutional amendments. + +### Section 2 + +In case of inconsistencies between the Guardrails documented in the Appendix and the Guardrails implemented on-chain, the on-chain version shall prevail, and the Constitutional Committee shall work to reconcile such inconsistencies through appropriate governance actions. + +## APPENDIX I: CARDANO BLOCKCHAIN GUARDRAILS + +### 1. Introduction + +This Appendix sets forth guardrails that must be applied to Cardano on-chain governance actions. These guardrails cover both essential, intrinsic limits on settings, and recommendations that are based on experience, measurement and governance objectives. + +These guardrails are designed to avoid unexpected problems with the operation of the Cardano Blockchain. They are intended to guide the choice of sensible parameter settings and avoid potential problems with security, performance or functionality. As described below, some of these guardrails are automatable and will be enforced via an on-chain script or built-in ledger rules.  However, many of them require the input of human experts which will be enforced by the Constitutional Committee through referencing this document. + +#### Automated Checking ("Guardrails Script") + +A script hash is associated with the constitution hash when a New Constitution or Guardrails Script governance action is enacted. It acts as an additional safeguard to the ledger rules and types, filtering non-compliant governance actions. + +The guardrails script only affects two types of governance actions: + +- Parameter Update actions. +- Treasury Withdrawal actions. + +The script is executed when either of these types of governance action is submitted on-chain. The purpose of this script is to avoid scenarios where an erroneous script could prevent the chain from ever enacting a Hard Fork action, resulting in deadlock. + +##### Symbol and Explanation + +- (y) The script can be used to enforce the guardrail. +- (x) The script cannot be used to enforce the guardrail. +- (~ - reason) The script cannot be used to enforce the guardrail for the reason given, but future ledger changes could enable this. + +Guardrails may overlap: in this case, the most restrictive set of guardrails will apply. + +### 2. GUARDRAILS AND GUIDELINES ON PROTOCOL PARAMETER UPDATE ACTIONS + +- PARAM-01 (y) Any protocol parameter that is not explicitly named in this document must not be changed by a Parameter update governance action. +- PARAM-02 (y) Where a protocol parameter is explicitly listed in this document but no checkable guardrails are specified, the guardrails script must not impose any constraints on changes to the parameter. Checkable guardrails are shown by a (y). + +#### 2.1 Critical Protocol Parameters + +##### Parameters that are Critical to the Operation of the Blockchain + +- `maxBlockBodySize` (maximum block body size) +- `maxTxSize` (maximum transaction size) +- `maxBlockHeaderSize` (maximum block header size) +- `maxValueSize` (maximum size of a serialized asset value) +- `maxBlockExecutionUnits` (maximum script execution/memory units in a single block) +- `txFeePerByte` (minimum fee coefficient) +- `txFeeFixed` (minimum fee constant) +- `minFeeRefScriptCoinsPerByte` (minimum fee per byte for reference scripts) +- `utxoCostPerByte` (minimum Lovelace deposit per byte of serialized UTxO) +- `govDeposit` (governance action deposit) + +Guardrails: +- PARAM-03 (y) Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs must say "yes" with a collective support of more than 50% of all active block production stake. This is enforced by the guardrails on the stake pool voting threshold. +- PARAM-04 (x) At least 3 months should 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 an emergency network issue following careful technical discussion and evaluation. + +--- + +##### Parameters that are Critical to the Governance System + +- `stakeAddressDeposit` (delegation key Lovelace deposit) +- `stakePoolDeposit` (pool registration Lovelace deposit) +- `minPoolCost` (minimum fixed rewards cut for pools) +- `dRepDeposit` (DRep deposit amount) +- `committeeMinSize` (minimal Constitutional Committee size) +- `committeeMaxTermLimit` (maximum term length in epochs for the Constitutional Committee members) + +Guardrails: +- PARAM-05 (y) DReps must vote "yes" with a collective support of more than 50% of all active voting stake. This is enforced by the guardrails on the DRep voting thresholds. +- PARAM-06 (x) At least 3 months should 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 an emergency network issue following careful technical discussion and evaluation. + +--- + +#### 2.2. Economic Parameters + +##### `txFeePerByte` (transaction fee per byte) + +Guardrails: +- TFPB-01 (y) `txFeePerByte` must not be lower than 30 (0.000030 ada). This protects against low-cost denial of service attacks. +- TFPB-02 (y) `txFeePerByte` must not exceed 1,000 (0.001 ada). This ensures that transactions can be paid for. +- TFPB-03 (y) `txFeePerByte` must not be negative. + +--- + +##### `txFeeFixed` (fixed transaction fee) + +Guardrails: +- TFF-01 (y) `txFeeFixed` must not be lower than 100,000 (0.1 ada). This protects against low-cost denial of service attacks. +- TFF-02 (y) `txFeeFixed` must not exceed 10,000,000 (10 ada). This ensures that transactions can be paid for. +- TFF-03 (y) `txFeeFixed` must not be negative. +- TFGEN-01 (x - "should") To maintain a consistent level of protection against denial-of-service attacks, `txFeeFixed` and `txFeePerByte` should be adjusted whenever Plutus Execution prices are adjusted (`executionUnitPrices[steps/memory]`). +- TFGEN-02 (x - unquantifiable) Any changes to `txFeeFixed` or `txFeePerByte` must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee so that it becomes impossible to construct a transaction. + +--- + +##### `utxoCostPerByte` (UTxO cost per byte) + +Guardrails: +- UCPB-01 (y) `utxoCostPerByte` must not be lower than 3,000 (0.003 ada). +- UCPB-02 (y) `utxoCostPerByte` must not exceed 6,500 (0.0065 ada). +- UCPB-03 (y) `utxoCostPerByte` must not be zero. +- UCPB-04 (y) `utxoCostPerByte` must not be negative. +- UCPB-05 (x - "should") Changes should account for: + - The acceptable cost of attack. + - The acceptable time for an attack (at least one epoch is assumed). + - The acceptable memory configuration for full node users (assumed to be 16GB for wallets or 24GB for stake pools). + - The sizes of UTxOs (~200B per UTxO minimum, up to about 10KB). + - The current total node memory usage. + + --- + +##### `stakeAddressDeposit` (Stake address deposit) + +Guardrails: +- SAD-01 (y) `stakeAddressDeposit` must not be lower than 1,000,000 (1 ada). +- SAD-02 (y) `stakeAddressDeposit` must not exceed 5,000,000 (5 ada). +- SAD-03 (y) `stakeAddressDeposit` must not be negative. + +--- + +##### `stakePoolDeposit` (Stake pool deposit) + +Guardrails: +- SPD-01 (y) `stakePoolDeposit` must not be lower than 250,000,000 (250 ada). +- SPD-02 (y) `stakePoolDeposit` must not exceed 500,000,000 (500 ada). +- SPD-03 (y) `stakePoolDeposit` must not be negative. + +--- + +##### `minPoolCost` (Minimum Pool Cost) + +Guardrails: +- MPC-01 (y) `minPoolCost` must not be negative. +- MPC-02 (y) `minPoolCost` must not exceed 500,000,000 (500 ada). +- MPC-03 (x - "should") `minPoolCost` should be set in line with the economic cost for operating a pool. + +--- + +##### `treasuryCut` (Treasury Cut) + +Guardrails: +- TC-01 (y) `treasuryCut` must not be lower than 0.1 (10%). +- TC-02 (y) `treasuryCut` must not exceed 0.3 (30%). +- TC-03 (y) `treasuryCut` must not be negative. +- TC-04 (y) `treasuryCut` must not exceed 1.0 (100%). +- TC-05 (~ - no access to change history) `treasuryCut` must not be changed more than once in any 36-epoch period (approximately 6 months). + +--- + +##### `monetaryExpansion` (Monetary Expansion Rate) + +Guardrails: +- ME-01 (y) `monetaryExpansion` must not exceed 0. +- ME-02 (y) `monetaryExpansion` must not be lower than 0. +- ME-03 (y) `monetaryExpansion` must not be negative. +- ME-04 (x - "should") `monetaryExpansion` should not be varied by more than +/- 10% in any 73-epoch period (approximately 12 months). +- ME-05 (x - "should") `monetaryExpansion` should not be changed more than once in any 36-epoch period (approximately 6 months). + +--- + +##### `executionUnitPrices` (Plutus Script Execution Prices [priceSteps/priceMemory]) + +Guardrails: +- EIUP-PS-01 (y) `executionUnitPrices[priceSteps]` must not exceed 2,000 / 10,000,000. +- EIUP-PS-02 (y) `executionUnitPrices[priceSteps]` must not be lower than 500 / 10,000,000. +- EIUP-PM-01 (y) `executionUnitPrices[priceMemory]` must not exceed 2,000 / 10,000. +- EIUP-PM-02 (y) `executionUnitPrices[priceMemory]` must not be lower than 400 / 10,000. +- EIUP-GEN-01 (x - "similar to") The execution prices must be set so that: + - i) the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum-sized non-script transaction and + - ii) the cost of executing a transaction with maximum memory units is similar to the cost of a maximum-sized non-script transaction. +- EIUP-GEN-02 (x - "should") The execution prices should be adjusted whenever transaction fees are adjusted (`txFeeFixed`/`txFeePerByte`). The goal is to ensure that the processing delay is similar for "full" transactions, regardless of their type, and to ensure that the requirements on block diffusion/propagation times are met. + +--- + +##### `minFeeRefScriptCoinsPerByte` (Transaction fee per byte for a reference script) + +Guardrails: +- MFRS-01 (y) `minFeeRefScriptCoinsPerByte` must not exceed 1,000 (0.001 ada). +- MFRS-02 (y) `minFeeRefScriptCoinsPerByte` must not be negative. +- MFRS-03 (x - "should") To maintain a consistent level of protection against denial-of-service attacks, `minFeeRefScriptCoinsPerByte` should be adjusted whenever Plutus Execution prices are adjusted (`executionUnitPrices[steps/memory]`) and whenever `txFeeFixed` is adjusted. +- MFRS-04 (x - unquantifiable) Any changes to `minFeeRefScriptCoinsPerByte` must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee. + +--- + +#### 2.3. Network Parameters + +Guardrails: +- NETWORK-01 (x - "should") No individual network parameter should change more than once per two epochs. +- NETWORK-02 (x - "should") Only one network parameter should be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits. + +--- + +##### `maxBlockBodySize` (Block Size) + +Guardrails: +- MBBS-01 (y) `maxBlockBodySize` must not exceed 122,880 Bytes (120KB). +- MBBS-02 (y) `maxBlockBodySize` must not be lower than 24,576 Bytes (24KB). +- MBBS-03 (x - "exceptional circumstances") `maxBlockBodySize` must not be decreased, other than in exceptional circumstances where there are potential problems with security, performance, or functionality. +- MBBS-04 (~ - no access to existing parameter values) `maxBlockBodySize` must be large enough to include at least one transaction (that is, `maxBlockBodySize` must be at least `maxTxSize`). +- MBBS-05 (x - "should") `maxBlockBodySize` should be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch. +- MBBS-06 (x - "should") The block size should not induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation, and benchmarking. +- MBBS-07 (x - "unquantifiable") The impact of any change to `maxBlockBodySize` must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to `maxBlockBodySize` must also consider future requirements for Plutus script execution (`maxBlockExecutionUnits[steps]`) against the total block diffusion target of 3s with 95% block propagation within 5s. The limit on maximum block size may be increased in the future if this is supported by benchmarking and monitoring results. + +--- + +##### `maxTxSize` (Transaction Size) + +Guardrails: +- MTS-01 (y) `maxTxSize` must not exceed 32,768 Bytes (32KB). +- MTS-02 (y) `maxTxSize` must not be negative. +- MTS-03 (~ - no access to existing parameter values) `maxTxSize` must not be decreased. +- MTS-04 (~ - no access to existing parameter values) `maxTxSize` must not exceed `maxBlockBodySize`. +- MTS-05 (x - "should") `maxTxSize` should not be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably should be increased by 2,048 Bytes (2KB) or less per epoch. +- MTS-06 (x - "should") `maxTxSize` should not exceed 1/4 of the block size. + +--- + +##### `maxBlockExecutionUnits` (Block memory execution unit limits) + +Guardrails: +- MBEU-M-01 (y) `maxBlockExecutionUnits[memory]` must not exceed 120,000,000 units. +- MBEU-M-02 (y) `maxBlockExecutionUnits[memory]` must not be negative. +- MBEU-M-03 (x - "should") `maxBlockExecutionUnits[memory]` should not be changed (increased or decreased) by more than 10,000,000 units in any epoch. +- MBEU-M-04 (x - unquantifiable) The impact of any change to `maxBlockExecutionUnits[memory]` must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the diffusion/propagation time budgets, as also impacted by `maxBlockExecutionUnits[steps]`. Any increase must also consider previously agreed future requirements for the total block size (`maxBlockBodySize`) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. + +--- + +##### `maxTxExecutionUnits` (Transaction memory execution unit limits) + +Guardrails: +- MTEU-M-01 (y) `maxTxExecutionUnits[memory]` must not exceed 40,000,000 units. +- MTEU-M-02 (y) `maxTxExecutionUnits[memory]` must not be negative. +- MTEU-M-03 (~ - no access to existing parameter values) `maxTxExecutionUnits[memory]` must not be decreased. +- MTEU-M-04 (x - "should") `maxTxExecutionUnits[memory]` should not be increased by more than 2,500,000 units in any epoch. + +--- + +##### `maxBlockExecutionUnits` (CPU block limits in steps) + +Guardrails: +- MBEU-S-01 (y) `maxBlockExecutionUnits[steps]` must not exceed 40,000,000,000 (40Bn) units. +- MBEU-S-02 (y) `maxBlockExecutionUnits[steps]` must not be negative. +- MBEU-S-03 (x - "should") `maxBlockExecutionUnits[steps]` should not be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days). +- MBEU-S-04 (x - unquantifiable) The impact of the change to `maxBlockExecutionUnits[steps]` must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by `maxBlockExecutionUnits[memory]`. Any increase must also consider previously identified future requirements for the total block size (`maxBlockBodySize`) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. + +--- + +##### `maxTxExecutionUnits` (CPU transaction limits in steps) + +Guardrails: +- MTEU-S-01 (y) `maxTxExecutionUnits[steps]` must not exceed 15,000,000,000 (15Bn) units. +- MTEU-S-02 (y) `maxTxExecutionUnits[steps]` must not be negative. +- MTEU-S-03 (~ - no access to existing parameter values) `maxTxExecutionUnits[steps]` must not be decreased. +- MTEU-S-04 (x - "should") `maxTxExecutionUnits[steps]` should not be increased by more than 500,000,000 (500M) units in any epoch (5 days). + +--- + +##### `maxBlockHeaderSize` (Block Header Size) + +Guardrails: +- MBHS-01 (y) `maxBlockHeaderSize` must not exceed 5,000 Bytes. +- MBHS-02 (y) `maxBlockHeaderSize` must not be negative. +- MBHS-03 (x - "largest valid header" is subject to change) `maxBlockHeaderSize` must be large enough for the largest valid header. +- MBHS-04 (x - "should") `maxBlockHeaderSize` should only normally be increased if the protocol changes. +- MBHS-05 (x - "should") `maxBlockHeaderSize` should be within TCP's initial congestion window (3 or 10 MTUs). + +--- + +#### 2.4. Technical/Security Parameters + +##### `stakePoolTargetNum` (Target Number of Stake Pools) + +Guardrails: +- SPTN-01 (y) `stakePoolTargetNum` must not be lower than 250. +- SPTN-02 (y) `stakePoolTargetNum` must not exceed 2,000. +- SPTN-03 (y) `stakePoolTargetNum` must not be negative. +- SPTN-04 (y) `stakePoolTargetNum` must not be zero. + +--- + +##### `poolPledgeInfluence` (Pledge Influence Factor) + +Guardrails: +- PPI-01 (y) `poolPledgeInfluence` must not be lower than 0.1. +- PPI-02 (y) `poolPledgeInfluence` must not exceed 1.0. +- PPI-03 (y) `poolPledgeInfluence` must not be negative. +- PPI-04 (x - "should") `poolPledgeInfluence` should not vary by more than +/- 10% in any 18-epoch period (approximately 3 months). + +--- + +##### `poolRetireMaxEpoch` (Pool Retirement Window) + +Guardrails: +- PRME-01 (y) `poolRetireMaxEpoch` must not be negative. +- PRME-02 (x - "should") `poolRetireMaxEpoch` should not be lower than 1. + +--- + +##### `collateralPercentage` (Collateral Percentage) + +Guardrails: +- CP-01 (y) `collateralPercentage` must not be lower than 100. +- CP-02 (y) `collateralPercentage` must not exceed 200. +- CP-03 (y) `collateralPercentage` must not be negative. +- CP-04 (y) `collateralPercentage` must not be zero. + +--- + +##### `maxCollateralInputs` (Maximum number of collateral inputs) + +Guardrails: +- MCI-01 (y) `maxCollateralInputs` must not be lower than 1. + +--- + +##### `maxValueSize` + +Guardrails: +- MVS-01 (y) `maxValueSize` must not exceed 12,288 Bytes (12KB). +- MVS-02 (y) `maxValueSize` must not be negative. +- MVS-03 (~ - no access to existing parameter values) `maxValueSize` must be less than `maxTxSize`. +- MVS-04 (~ - no access to existing parameter values) `maxValueSize` must not be reduced. +- MVS-05 (x - "sensible output" is subject to interpretation) `maxValueSize` must be large enough to allow sensible outputs (e.g., any existing on-chain output or anticipated outputs that could be produced by new ledger rules). + +--- + +##### `costModels` (Plutus Cost Models) + +Guardrails: +- PCM-01 (x - unquantifiable) Cost model values must be set by benchmarking on a reference architecture. +- PCM-02 (x - primitives and language versions aren't introduced in transactions) The cost model must be updated if new primitives are introduced or a new Plutus language version is added. +- PCM-03 (~ - no access to Plutus cost model parameters) Cost model values should not be negative. +- PCM-04 (~ - no access to Plutus cost model parameters) A cost model must be supplied for each Plutus language version that the protocol supports. + +--- + +#### 2.5. Governance Parameters + +##### `govDeposit` (Deposit for Governance Actions) + +Guardrails: +- GD-01 (y) `govDeposit` must not be negative. +- GD-02 (y) `govDeposit` must not be lower than 1,000,000 (1 ada). +- GD-03 (y) `govDeposit` must not exceed 10,000,000,000,000 (10 million ada). +- GD-04 (x - "should") `govDeposit` should be adjusted in line with fiat changes. + +--- + +##### `dRepDeposit` (Deposit for DReps) + +Guardrails: +- DRD-01 (y) `dRepDeposit` must not be negative. +- DRD-02 (y) `dRepDeposit` must not be lower than 1,000,000 (1 ada). +- DRD-03 (y) `dRepDeposit` must not exceed 100,000,000,000 (100,000 ada). +- DRD-04 (x - "should") `dRepDeposit` should be adjusted in line with fiat changes. + +--- + +##### `dRepActivity` (DRep Activity Period) + +Guardrails: +- DRA-01 (y) `dRepActivity` must not be lower than 13 epochs (2 months). +- DRA-02 (y) `dRepActivity` must not exceed 37 epochs (6 months). +- DRA-03 (y) `dRepActivity` must not be negative. +- DRA-04 (~ - no access to existing parameter values) `dRepActivity` must be greater than `govActionLifetime`. +- DRA-05 (x - "should") `dRepActivity` should be calculated in human terms (2 months, etc.). + +--- + +##### dRepVotingThresholds + +- `dvtCommitteeNoConfidence` +- `dvtCommitteeNormal` +- `dvtHardForkInitiation` +- `dvtMotionNoConfidence` +- `dvtPPEconomicGroup` +- `dvtPPGovGroup` +- `dvtPPNetworkGroup` +- `dvtPPTechnicalGroup` +- `dvtTreasuryWithdrawal` +- `dvtUpdateToConstitution` + +##### poolVotingThresholds + +- `pvtCommitteeNoConfidence` +- `pvtCommitteeNormal` +- `pvtHardForkInitiation` +- `pvtMotionNoConfidence` +- `pvtPPSecurityGroup` + +Guardrails: +- VT-GEN-01 (y) All thresholds must be greater than 50% and less than or equal to 100%. +- VT-GEN-02 (y) Economic, network, and technical parameter thresholds must be in the range 51%-75%. +- VT-GEN-03 (y) Governance parameter thresholds must be in the range 75%-90%. +- VT-HF-01 (y) Hard fork action thresholds must be in the range 51%-80%. +- VT-CON-01 (y) New Constitution or guardrails script action thresholds must be in the range 65%-90%. +- VT-CC-01 (y) Update Constitutional Committee action thresholds must be in the range 51%-90%. +- VT-NC-01 (y) No confidence action thresholds must be in the range 51%-75%. + +--- + +##### `govActionLifetime` (Governance Action Lifetime) + +Guardrails: +- GAL-01 (y) `govActionLifetime` must not be lower than 1 epoch (5 days). +- GAL-03 (x - "should") `govActionLifetime` should not be lower than 2 epochs (10 days). +- GAL-02 (y) `govActionLifetime` must not exceed 15 epochs (75 days). +- GAL-04 (x - "should") `govActionLifetime` should be calibrated in human terms (e.g., 30 days, two weeks) to allow sufficient time for voting, etc., to take place. +- GAL-05 (~ - no access to existing parameter values) `govActionLifetime` must be less than `dRepActivity`. + +--- + +##### `committeeMaxTermLimit` (Maximum Constitutional Committee Term) + +Guardrails: +- CMTL-01 (y) `committeeMaxTermLimit` must not be zero. +- CMTL-02 (y) `committeeMaxTermLimit` must not be negative. +- CMTL-03 (y) `committeeMaxTermLimit` must not be lower than 18 epochs (90 days, or approximately 3 months). +- CMTL-04 (y) `committeeMaxTermLimit` must not exceed 293 epochs (approximately 4 years). +- CMTL-05 (x - "should") `committeeMaxTermLimit` should not exceed 220 epochs (approximately 3 years). + +--- + +##### `committeeMinSize` (Minimum Size of the Constitutional Committee) + +Guardrails: +- CMS-01 (y) `committeeMinSize` must not be negative. +- CMS-02 (y) `committeeMinSize` must not be lower than 3. +- CMS-03 (y) `committeeMinSize` must not exceed 10. + +#### 2.6. Guardrails and Guidelines on Treasury Withdrawal Actions + +Guardrails: +- TREASURY-01 (x) DReps must define a net change limit for the Cardano Treasury's balance per period of time. +- TREASURY-02 (x) The budget for the Cardano Treasury must not exceed the net change limit for the Cardano Treasury's balance per period of time. +- TREASURY-03 (x) The budget for the Cardano Treasury must be denominated in ADA. +- TREASURY-04 (x) Treasury withdrawals must not be ratified until there is a community-approved Cardano budget then in effect pursuant to a previous on-chain governance action agreed by the DReps with a threshold of greater than 50% of the active voting stake. + +--- + +#### 2.7 Guardrails and Guidelines on Hard Fork Initiation Actions + +Guardrails: +- HARDFORK-01 (~ - no access to existing parameter values) The major protocol version must be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version must be zero. +- HARDFORK-02 (~ - no access to existing parameter values) The minor protocol version must be no less than the minor version that will be enacted immediately prior to this change. +- HARDFORK-03 (~ - no access to existing parameter values) At least one of the protocol versions (major or minor or both) must change. +- HARDFORK-04 (x) At least 85% of stake pools by active stake should have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version. +- HARDFORK-05 (x) Any new updatable protocol parameters that are introduced with a hard fork must be included in this Appendix and suitable guardrails defined for those parameters. +- HARDFORK-06 (x) Settings for any new protocol parameters that are introduced with a hard fork must be included in the appropriate Genesis file. +- HARDFORK-07 (x) Any deprecated protocol parameters must be indicated in this Appendix. +- HARDFORK-08 (~ - no access to Plutus cost model parameters) New Plutus versions must be supported by a version-specific Plutus cost model that covers each primitive that is available in the new Plutus version. + +--- + +#### 2.8 Guardrails and Guidelines on Update Constitutional Committee or Threshold Actions + +Guardrails: +- UPDATE-CC-01 (x) Update Constitutional Committee and/or threshold and/or term governance actions must not be ratified until ADA holders have ratified through an on-chain governance action the Final Constitution. + +--- + +#### 2.9 Guardrails and Guidelines on New Constitution or Guardrails Script Actions + +Guardrails: +- NEW-CONSTITUTION-01 (x) A New Constitution or Guardrails Script governance action must be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action. + +--- + +#### 2.10. Monitoring and Reversion of Parameter Changes + +A specific reversion/recovery plan must be produced for each parameter change. This plan must include: + +- Which parameters need to change and in which ways in order to return to the previous state (or a similar state). +- How to recover the network in the event of a disastrous failure. + +This plan should be followed if problems are observed following the parameter change. Note that not all changes can be reverted. Additional care must be taken when making changes to these parameters. + +--- + +#### 2.11. Non-Updatable Protocol Parameters + +Some fundamental protocol parameters cannot be changed by the Protocol Parameter Update governance action. These parameters can only be changed in a new Genesis file as part of a hard fork. It is not necessary to provide specific guardrails on updating these parameters. + +### LIST OF PROTOCOL PARAMETER GROUPS + +The protocol parameters are grouped by type, allowing different thresholds to be set for each group. + +The network group consists of: +- `maxBlockBodySize` (maximum block body size) +- `maxTxSize` (maximum transaction size) +- `maxBlockHeaderSize` (maximum block header size) +- `maxValueSize` (maximum size of a serialized asset value) +- `maxTxExecutionUnits[steps]` (maximum script execution units in a single transaction) +- `maxBlockExecutionUnits[steps]` (maximum script execution units in a single block) +- `maxCollateralInputs` (maximum number of collateral inputs) + +The economic group consists of: +- `txFeePerByte` (minimum fee coefficient) +- `txFeeFixed` (minimum fee constant) +- `minFeeRefScriptCoinsPerByte` (minimum fee per byte for reference scripts) +- `stakeAddressDeposit` (delegation key Lovelace deposit) +- `stakePoolDeposit` (pool registration Lovelace deposit) +- `monetaryExpansion` (monetary expansion) +- `treasuryCut` (treasury expansion) +- `minPoolCost` (minimum fixed rewards cut for pools) +- `utxoCostPerByte` (minimum Lovelace deposit per byte of serialized UTxO) +- `executionUnitPrices[priceSteps/priceMemory]` (prices of Plutus execution units) + +The technical group consists of: +- `poolPledgeInfluence` (pool pledge influence) +- `poolRetireMaxEpoch` (pool retirement maximum epoch) +- `stakePoolTargetNum` (desired number of pools) +- `costModels` (Plutus execution cost models) +- `collateralPercentage` (proportion of collateral needed for scripts) + +The governance group consists of all the new protocol parameters that are introduced in CIP-1694: +- `dRepVotingThresholds[...]`, `poolVotingThresholds[...]` (governance voting thresholds) +- `govActionLifetime` (governance action maximum lifetime in epochs) +- `govActionDeposit` (governance action deposit) +- `dRepDeposit` (DRep deposit amount) +- `dRepActivity` (DRep activity period in epochs) +- `committeeMinSize` (minimal constitutional committee size) +- `committeeMaxTermLimit` (maximum term length in epochs for the constitutional committee members) \ No newline at end of file From 57b2737e85f413aee759917049a62ef16c7aa26e Mon Sep 17 00:00:00 2001 From: rwiley <30681834+Cerkoryn@users.noreply.github.com> Date: Mon, 11 Nov 2024 16:09:49 -0500 Subject: [PATCH 05/17] Adjusted typo in monetaryExpansion guardrails --- CONSTITUTION.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONSTITUTION.md b/CONSTITUTION.md index 902f631..06330ed 100644 --- a/CONSTITUTION.md +++ b/CONSTITUTION.md @@ -261,8 +261,8 @@ Guardrails: ##### `monetaryExpansion` (Monetary Expansion Rate) Guardrails: -- ME-01 (y) `monetaryExpansion` must not exceed 0. -- ME-02 (y) `monetaryExpansion` must not be lower than 0. +- ME-01 (y) `monetaryExpansion` must not exceed 0.005 +- ME-02 (y) `monetaryExpansion` must not be lower than 0.001 - ME-03 (y) `monetaryExpansion` must not be negative. - ME-04 (x - "should") `monetaryExpansion` should not be varied by more than +/- 10% in any 73-epoch period (approximately 12 months). - ME-05 (x - "should") `monetaryExpansion` should not be changed more than once in any 36-epoch period (approximately 6 months). From a41e9279f46c6340698ed68ad2ef0cc03c05db0e Mon Sep 17 00:00:00 2001 From: rwiley <30681834+Cerkoryn@users.noreply.github.com> Date: Sun, 24 Nov 2024 12:23:27 -0500 Subject: [PATCH 06/17] Added CommunityDrafts and WorkingNotes --- CommunityDrafts/AdamDean.md | 2173 ++++++++++++++++++++++++++ CommunityDrafts/AlfonsoTenets.md | 36 + CommunityDrafts/CardanoFoundation.md | 324 ++++ CommunityDrafts/ColinSmith.md | 51 + CommunityDrafts/Intersect.md | 935 +++++++++++ CommunityDrafts/Jane.md | 969 ++++++++++++ CommunityDrafts/KevinMohr.md | 453 ++++++ CommunityDrafts/README.md | 12 + CommunityDrafts/gpt-4o.md | 137 ++ CommunityDrafts/gpt-o1-preview.md | 108 ++ WorkingNotes/23-Nov-2024-Workshop.md | 206 +++ 11 files changed, 5404 insertions(+) create mode 100644 CommunityDrafts/AdamDean.md create mode 100644 CommunityDrafts/AlfonsoTenets.md create mode 100644 CommunityDrafts/CardanoFoundation.md create mode 100644 CommunityDrafts/ColinSmith.md create mode 100644 CommunityDrafts/Intersect.md create mode 100644 CommunityDrafts/Jane.md create mode 100644 CommunityDrafts/KevinMohr.md create mode 100644 CommunityDrafts/README.md create mode 100644 CommunityDrafts/gpt-4o.md create mode 100644 CommunityDrafts/gpt-o1-preview.md create mode 100644 WorkingNotes/23-Nov-2024-Workshop.md diff --git a/CommunityDrafts/AdamDean.md b/CommunityDrafts/AdamDean.md new file mode 100644 index 0000000..88c9ea6 --- /dev/null +++ b/CommunityDrafts/AdamDean.md @@ -0,0 +1,2173 @@ +`Draft 2024-07-29` + +# CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION + +## PREAMBLE + +The Cardano Blockchain ecosystem, comprising Ada holders, individuals, builders, +developers, enterprises, stake pools, users of the Cardano Blockchain and +others, operates in a truly decentralized manner. + +Recognizing the need for a dynamic governance framework, one that utilizes +wherever possible blockchain technology in the governance process, the Cardano +community hereby establishes this Cardano Constitution. It shall serve as a set +of principles for the operation and governance of an environment where all +participants can contribute to the betterment of the Cardano Blockchain +ecosystem. + +The Cardano community shall uphold principles of transparency, openness, and +responsible governance, promoting a culture of trust and collaboration. +Together, the Cardano community commits to uphold these principles and to work +together towards the continuous improvement, growth, and success of our +decentralized blockchain ecosystem known as the Cardano Blockchain. + +All members of the Cardano community are entitled to participate in its +governance processes, and are encouraged to work collaboratively towards the +betterment of the Cardano Blockchain ecosystem, contributing to its growth, +sustainability, and success. The Cardano Blockchain shall be governed on a +vote-based decision-making model, fostering inclusivity, a diversity of views, +innovation and adaptability. + +## ARTICLE I. CARDANO BLOCKCHAIN TENETS AND GUARDRAILS + +### Section 1 + +These Tenets shall guide all actors in the Cardano Blockchain ecosystem and +proposed governance actions shall be evaluated in accordance with these Tenets. + +Transactions on the Cardano Blockchain should not be slowed down or censored and +should be expediently served for their intended purpose. The Cardano Blockchain +should scale. + +The cost of transactions on the Cardano Blockchain should be predictable. + +The Cardano Blockchain shall not lock an Ada owner’s value without owner’s +consent. The Cardano Blockchain should promote interoperability. + +The Cardano Blockchain shall preserve in a safe manner any information an owner +of Ada seeks to store on the Cardano Blockchain. + +All users of the Cardano Blockchain shall be treated equally. + +### Section 2 + +The Cardano Blockchain shall operate in accordance with the Guardrails as set +forth in the Guardrails Appendix to this Constitution. + +## ARTICLE II. THE CARDANO BLOCKCHAIN COMMUNITY + +### Section 1 + +No membership shall be required to use, participate in and benefit from the +Cardano Blockchain. All owners of Ada, all developers of, all those building on, +and all those otherwise supporting, maintaining or using the Cardano Blockchain +are beneficiaries of the Cardano Blockchain ecosystem and, as such, are +collectively members of the Cardano community. All Cardano community members are +accordingly beneficiaries of this Constitution, entitled to its rights, +privileges and protections and, as such, are expected to support and uphold this +Constitution. + +### Section 2 + +Members of the Cardano community who own Ada are entitled to access and +participate in the on-chain decision-making processes of the Cardano Blockchain +ecosystem, including voting. + +## ARTICLE III. PARTICIPATORY GOVERNANCE + +### Section 1 + +The Cardano Blockchain ecosystem shall be governed by an on-chain governance +model, utilizing, to the extent possible, smart contracts and other +blockchain-based tools to facilitate decision-making and transparency. On-chain +voting for governance actions shall follow the process outlined in the Cardano +Blockchain Guardrails. + +### Section 2 + +Three governance bodies shall participate in voting for on-chain governance +actions to provide checks and balances for the Cardano Blockchain consisting of +Delegated Representatives (dRep), Stake Pool Operators (SPO) and the +Constitutional Committee (CC). + +### Section 3 + +On-chain governance decisions shall be made through a collective decision-making +process, with specific consensus threshold requirements as required by the +Cardano Blockchain Guardrails. All on-chain governance actions shall be voted +upon in accordance with the Cardano Blockchain Guardrails. + +### Section 4 + +All owners of Ada shall have the right to vote in on-chain governance action +processes, subject to any restrictions or requirements provided for in this +Constitution and the Cardano Blockchain Guardrails. + +### Section 5 + +Any proposed on-chain governance action shall require a standardized and legible +format including a URI and hash linked to documented content. Sufficient +rationale shall be provided to justify the requested change to the Cardano +Blockchain. The rationale shall include, at a minimum, a title, abstract, reason +for the proposal, and supporting materials. + +“Hard Fork Initiation” and “Protocol Parameter Change” governance actions should +undergo sufficient technical review and scrutiny as mandated by the Cardano +Blockchain Guardrails to ensure that the governance action does not endanger the +security, functionality or performance of the Cardano Blockchain. On-chain +governance actions' rationale should address their expected impact on the +Cardano Blockchain ecosystem. + +### Section 6 + +The Cardano community is expected to enact, not less than on an annual basis, a +budget for the ongoing maintenance and future development of the Cardano +Blockchain. No withdrawals from the Cardano treasury shall be permitted unless a +budget for the Cardano Blockchain is then in effect as required by the Cardano +Blockchain Guardrails. + +## ARTICLE IV. DELEGATED REPRESENTATIVES + +### Section 1 + +In order to participate in governance actions, owners of Ada may register as +dReps and vote on governance actions or may delegate their voting rights to +other registered dReps who shall vote on their behalf. + +### Section 2 + +dReps may be individuals or coordinated groups. dReps are entitled to cast votes +directly for on-chain governance actions and represent those Ada holders +delegating their voting rights to them. + +## ARTICLE V. STAKE POOL OPERATORS + +### Section 1 + +SPOs shall have a specific role in approving critical on-chain governance +actions which require additional oversight and independence, voting separately +and independently of dReps as set forth in the Cardano Blockchain Guardrails. +SPOs shall participate in hard fork initiation processes as the operators of the +nodes that participate in Cardano Blockchain’s consensus mechanism. + +### Section 2 + +SPOs act as a check on the power of the Constitutional Committee by separately +voting on "Motion of no-confidence" and "Update committee/threshold" governance +actions. + +## ARTICLE VI. CONSTITUTIONAL COMMITTEE + +### Section 1 + +A Constitutional Committee shall be established as the branch of Cardano's +on-chain governance process that ensures governance actions are consistent with +this Constitution. The Constitutional Committee shall be limited to voting on +the constitutionality of governance actions. + +### Section 2 + +The Constitutional Committee shall be composed as consistent with the Cardano +Blockchain Guardrails. + +Members of the Constitutional Committee shall serve such terms as consistent +with the Cardano Blockchain Guardrails, provided that terms shall not be less +than one year. To assure continuity in the operation of Constitutional +Committee, the terms for Constitutional Committee members shall be staggered. + +### Section 3 + +The Cardano community shall establish a process from time to time for election +of members of the Constitutional Committee consistent with the requirements of +the Cardano Blockchain Guardrails. + +### Section 4 + +No governance action, other than a "Motion of no-confidence" or "Update +constitutional committee/threshold" may be implemented on-chain unless the +Constitutional Committee shall have first determined and affirmed through an +on-chain action that such proposal does not violate this Constitution. + +The Constitutional Committee shall be considered to be in one of the following +two states at all times: a state of confidence or a state of no-confidence. In a +state of no-confidence, members of the then standing Constitutional Committee +must be reinstated or replaced using the "Update committee/threshold" governance +action before any other on-chain governance action may go forward. + +### Section 5 + +The Constitutional Committee should operate pursuant to a standard operating +procedure published by the Constitutional Committee and shall adopt such +policies and procedures as the Constitutional Committee shall deem necessary in +carrying out its duties. + +## ARTICLE VII. AMENDMENTS + +### Section 1 + +Except as otherwise so provided in the Cardano Blockchain Guardrails Appendix, +amendments to this Constitution, including to the Cardano Blockchain Guardrails +Appendix, shall be approved by a collective decision-making process, requiring +an on-chain governance action by owners of Ada satisfying a threshold of not +less than 67% of the then active voting stake. + +## APPENDIX I: CARDANO BLOCKCHAIN GUARDRAILS + +### 1. INTRODUCTION + +This Appendix sets forth guardrails that must be applied to Cardano Blockchain +on-chain governance actions, including changes to the protocol parameters and +limits on treasury withdrawals. + +These guardrails are designed to avoid unexpected problems with the operation of +the Cardano Blockchain. They are intended to guide the choice of parameter +settings and avoid potential problems with security, performance or +functionality. + +These guardrails apply to the Cardano Blockchain Layer 1 mainnet environment. +They are not intended to apply to test environments or to other blockchains that +use the Cardano Blockchain software. + +The guardrails set forth in this Appendix may be amended pursuant to an on-chain +governance action that satisfies the applicable voting threshold set forth in +this Appendix. + +### Terminology and Guidance + +**Should/Should not.** Where this Appendix says that a value "should not" be set +below or above some value, this means that the guardrail is a recommendation or +guideline, and the specific value could be open to discussion or alteration by a +suitably expert group recognized by the Cardano community. + +**Must/Must not.** Where this Appendix says that a value "must not" be set below +or above some value, this means that the guardrail is a requirement that will be +enforced by Cardano Blockchain ledger rules, types or other built-in mechanisms +where possible, and that if not followed could cause a protocol failure, +security breach or other undesirable outcome. + +**Benchmarking.** Benchmarking refers to careful system level performance +evaluation that is designed to show a-priori that, for example, 95% of blocks +will be diffused across a global network of Cardano Blockchain nodes within the +required 5s time interval in all cases. + +**Performance analysis.** Performance analysis refers to projecting theoretical +performance, empirical benchmarking or simulation results to predict actual +system behavior. + +**Simulation.** Simulation refers to synthetic execution that is designed to +inform performance/functionality decisions in a repeatable way. + +**Performance Monitoring.** Performance monitoring involves measuring the actual +behavior of the Cardano Blockchain network. It complements benchmarking and +performance analysis by providing information about actual system behavior that +cannot be obtained using simulated workloads or theoretical analysis. + +**Reverting Changes.** Where performance monitoring shows that actual network +behavior following a change is inconsistent with the performance requirements +for the Cardano Blockchain, then the change must be reverted to its previous +state if that is possible. For example, if the block size is increased from +100KB to 120KB and 95% of blocks are no longer diffused within 5s, then a change +must be made to revert the block size to 100KB. If this is not possible, then +one or more alternative changes must be made that will ensure that the +performance requirements are met. + +**Severity Levels.** Issues that affect the Cardano Blockchain network are +classified by severity level, where: + +- Severity 1 is a critical incident or issue with very high impact to the + security, performance, or functionality of the Cardano Blockchain network. +- Severity 2 is a major incident or issue with significant impact to the + security, performance, or functionality of the Cardano Blockchain network. +- Severity 3 is a minor incident or issue with low impact to the security, + performance, or functionality of the Cardano Blockchain network. + +### Automated Checking ("Guardrails Script") + +A script hash is associated with the constitution hash when a **New Constitution +or Guardrails Script** governance action is enacted. It acts as an additional +safeguard to the ledger rules and types, filtering non-compliant governance +actions. + +The guardrails script only affects two types of governance actions: + +- **Parameter Update** actions, and +- **Treasury Withdrawal** actions. + +The script is executed when either of these types of governance action is +submitted on-chain. There are three different situations that apply to script +usage. + +**Symbol and Explanation** + +- (y) The script can be used to enforce the guardrail. +- (x) The script cannot be used to enforce the guardrail. +- (~ - reason) The script cannot be used to enforce the guardrail for the reason + given, but future ledger changes could enable this. + +Guardrails may overlap: in this case, the most restrictive set of guardrails +will apply. + +> **IMPORTANT** +> Where a parameter is not explicitly listed in this document, then the script * +> *must not** permit any changes to the parameter. + +Conversely, where a parameter is explicitly listed in this document but no +checkable guardrails are specified, the script **must not** impose any +constraints on changes to the parameter. + +### 2. GUARDRAILS AND GUIDELINES ON PROTOCOL PARAMETER UPDATE ACTIONS + +Below are guardrails and guidelines for changing updatable protocol parameter +settings via the protocol parameter update governance action such that the +Cardano Blockchain is never in an unrecoverable state as a result of such +changes. + +Note that there are at least five different sources of parameter names, and +these are not always consistent: + +1. The name used in the Genesis file +2. The name used in protocol parameter update governance actions +3. The name used internally in ledger rules +4. The name used in the formal ledger specification +5. The name used in research papers + +Where these parameter names differ, this Appendix uses the second convention. + +#### Guardrails + +**PARAM-01** (y) Any protocol parameter that is not explicitly named in this +document **must not** be changed by a Parameter update governance action. + +**PARAM-02** (y) Where a protocol parameter is explicitly listed in this +document but no checkable guardrails are specified, the guardrails script **must +not** impose any constraints on changes to the parameter. Checkable guardrails +are shown by a (y). + +### 2.1. Critical Protocol Parameters + +The below protocol parameters are critical from a security point of view. + +_Parameters that are Critical to the Operation of the Blockchain_ + +- *maximum block body size* (*maxBlockBodySize*) +- *maximum transaction size* (*maxTxSize*) +- *maximum block header size* (*maxBlockHeaderSize*) +- *maximum size of a serialized asset value* (*maxValueSize*) +- *maximum script execution/memory units in a single block* ( + *maxBlockExecutionUnits[steps/memory]*) +- *minimum fee coefficient* (*txFeePerByte*) +- *minimum fee constant* (*txFeeFixed*) +- *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*) +- *minimum Lovelace deposit per byte of serialized UTxO* (*utxoCostPerByte*) +- *governance action deposit* (*govDeposit*) + +#### Guardrails + +**PARAM-03** (y) Critical protocol parameters require an SPO vote in addition to +a dRep vote: SPOs **must** say "yes" with a collective support of more than 50% +of all active block production stake. This is enforced by the guardrails on the +stake pool voting threshold. + +**PARAM-04** (x) At least 3 months **should** normally pass between the +publication of an off-chain proposal to change a critical protocol parameter and +the submission of the corresponding on-chain governance action. This guardrail +may be relaxed in the event of a Severity 1 or Severity 2 network issue +following careful technical discussion and evaluation. + +_Parameters that are Critical to the Governance System_ + +- *delegation key Lovelace deposit* (*stakeAddressDeposit*) +- *pool registration Lovelace deposit* (*stakePoolDeposit*) +- *minimum fixed rewards cut for pools* (*minPoolCost*) +- *dRep deposit amount* (*dRepDeposit*) +- *minimal Constitutional Committee size* (*committeeMinSize*) +- *maximum term length (in epochs) for the Constitutional Committee members* ( + *committeeMaxTermLimit*) + +#### Guardrails + +**PARAM-05** (y) dReps **must** vote "yes" with a collective support of more +than 50% of all active voting stake. This is enforced by the guardrails on the +dRep voting thresholds. + +**PARAM-06** (x) At least 3 months **should** normally pass between the +publication of an off-chain proposal to change a parameter that is critical to +the governance system and the submission of the corresponding on-chain +governance action. This guardrail may be relaxed in the event of a Severity 1 or +Severity 2 network issue following careful technical discussion and evaluation. + +### 2.2. Economic Parameters + +The overall goals when managing economic parameters are to: + +1. Enable long-term economic sustainability for the Cardano Blockchain + ecosystem; +2. Ensure that stake pools are adequately rewarded for maintaining the Cardano + Blockchain; +3. Ensure that Ada holders are adequately rewarded for using stake in + constructive ways, including when delegating Ada for block production; and +4. Balance economic incentives for different Cardano Blockchain ecosystem + stakeholders, including but not limited to Stake Pool Operators, Ada holders, + DeFi users, infrastructure users, developers (e.g., DApps), and financial + intermediaries (e.g., exchanges). + +_Triggers for Change_ + +1. Significant changes in the fiat value of Ada resulting in potential problems + with security, performance, or functionality. +2. Changes in transaction volumes or types. +3. Community requests or suggestions. +4. Emergency situations that require changes to economic parameters. + +_Counter-indicators_ + +Changes to the economic parameters should not be made in isolation. They need to +account for: + +- External economic factors. +- Network security concerns. + +_Core Metrics_ + +- Fiat value of Ada resulting in potential problems with security, performance, + or functionality. +- Transaction volumes and types. +- Number and health of stake pools. +- External economic factors. + +_Changes to Specific Economic Parameters_ + +**Transaction fee per byte (txFeePerByte) and fixed transaction fee (txFeeFixed) +** + +Defines the cost for basic transactions in Lovelace: + +fee(tx) = txFeeFixed + txFeePerByte x nBytes(tx) + +#### Guardrails + +**TFPB-01** (y) *txFeePerByte* **must not** be lower than 30 (0.000030 Ada). +This protects against low-cost denial of service attacks. + +**TFPB-02** (y) *txFeePerByte* **must not** exceed 1,000 (0.001 Ada). This +ensures that transactions can be paid for. + +**TFPB-03** (y) *txFeePerByte* **must not** be negative. + +**TFF-01** (y) *txFeeFixed* **must not** be lower than 100,000 (0.1 Ada). This +protects against low-cost denial of service attacks. + +**TFF-02** (y) *txFeeFixed* **must not** exceed 10,000,000 (10 Ada). This +ensures that transactions can be paid for. + +**TFF-03** (y) *txFeeFixed* **must not** be negative. + +**TFGEN-01** (x - "should") To maintain a consistent level of protection against +denial-of-service attacks, *txFeeFixed* and *txFeePerByte* **should** be +adjusted whenever Plutus Execution prices are adjusted ( +executionUnitPrices[steps/memory]). + +**TFGEN-02** (x - unquantifiable) Any changes to *txFeeFixed* or *txFeePerByte* +**must** consider the implications of reducing the cost of a denial-of-service +attack or increasing the maximum transaction fee so that it becomes impossible +to construct a transaction. + +_UTxO cost per byte (utxoCostPerByte)_ + +Defines the cost for storage in UTxOs: + +- Sets a minimum threshold on Ada that is held within a single UTxO (~1 Ada + minimum, could be >= 50 Ada in the worst case). +- Provides protection against low-cost denial of service attack on UTxO storage. + This attack has been executed on other chains; it is not theoretical. +- DoS protection decreases in line with the free node memory (proportional to + UTxO growth). +- Helps reduce long-term storage costs. +- Provides an incentive to return UTxOs when no longer needed. +- Should significantly exceed minimum tx cost (~0.15 Ada). + +#### Guardrails + +**UCPB-01** (y) *utxoCostPerByte* **must not** be lower than 3,000 (0.003 Ada). + +**UCPB-02** (y) *utxoCostPerByte* **must not** exceed 6,500 (0.0065 Ada). + +**UCPB-03** (y) *utxoCostPerByte* **must not** be zero. + +**UCPB-04** (y) *utxoCostPerByte* **must not** be negative. + +**UCPB-05** (x - "should") Changes **should** account for: + +i) The acceptable cost of attack. ii) The acceptable time for an attack (at +least one epoch is assumed). iii) The acceptable memory configuration for full +node users (assumed to be 16GB for wallets or 24GB for stake pools). iv) The +sizes of UTxOs (~200B per UTxO minimum, up to about 10KB). v) The current total +node memory usage. + +_Stake address deposit (stakeAddressDeposit)_ + +Ensures that stake addresses are retired when no longer needed: + +- Helps reduce long-term storage costs. +- Helps limit CPU and memory costs in the ledger. + +The rationale for the deposit is to incentivize that scarce memory resources are +returned when they are no longer required. Reducing the number of active stake +addresses also reduces processing and memory costs at the epoch boundary when +calculating stake snapshots. + +#### Guardrails + +**SAD-01** (y) *stakeAddressDeposit* **must not** be lower than 1,000,000 (1 +Ada). + +**SAD-02** (y) *stakeAddressDeposit* **must not** exceed 5,000,000 (5 Ada). + +**SAD-03** (y) *stakeAddressDeposit* **must not** be negative. + +_Stake pool deposit (stakePoolDeposit)_ + +Ensures that stake pools are retired by the stake pool operator when no longer +needed by them: + +- Helps reduce long-term storage costs. + +The rationale for the deposit is to incentivize that scarce memory resources are +returned when they are no longer required. Rewards and stake snapshot +calculations are also impacted by the number of active stake pools. + +#### Guardrails + +**SPD-01** (y) *stakePoolDeposit* **must not** be lower than 250,000,000 (250 +Ada). + +**SPD-02** (y) *stakePoolDeposit* **must not** exceed 500,000,000 (500 Ada). + +**SPD-03** (y) *stakePoolDeposit* **must not** be negative. + +_Minimum Pool Cost (minPoolCost)_ + +Part of the rewards mechanism: + +- The minimum pool cost is transferred to the pool rewards address before any + delegator rewards are paid. + +#### Guardrails + +**MPC-01** (y) *minPoolCost* **must not** be negative. + +**MPC-02** (y) *minPoolCost* **must not** exceed 500,000,000 (500 Ada). + +**MPC-03** (x - "should") *minPoolCost* **should** be set in line with the +economic cost for operating a pool. + +__Treasury Cut (treasuryCut)_ + +Part of the rewards mechanism: + +- The treasury cut portion of the monetary expansion is transferred to the + treasury before any pool rewards are paid. +- Can be set in the range 0.0-1.0 (0%-100%). + +#### Guardrails + +**TC-01** (y) *treasuryCut* **must not** be lower than 0.1 (10%). + +**TC-02** (y) *treasuryCut* **must not** exceed 0.3 (30%). + +**TC-03** (y) *treasuryCut* **must not** be negative. + +**TC-04** (y) *treasuryCut* **must not** exceed 1.0 (100%). + +**TC-05** (~ - no access to change history) *treasuryCut* **must not** be +changed more than once in any 36-epoch period (approximately 6 months). + +_Monetary Expansion Rate (monetaryExpansion)_ + +Part of the rewards mechanism: + +- The monetary expansion controls the amount of reserves that is used for + rewards each epoch. +- Governs the long-term sustainability of Cardano. +- The reserves are gradually depleted until no rewards are supplied. + +#### Guardrails + +**ME-01** (y) *monetaryExpansion* **must not** exceed 0. + +**ME-02** (y) *monetaryExpansion* **must not** be lower than 0. + +**ME-03** (y) *monetaryExpansion* **must not** be negative. + +**ME-04** (x - "should") *monetaryExpansion* **should not** be varied by more +than +/- 10% in any 73-epoch period (approximately 12 months). + +**ME-05** (x - "should") *monetaryExpansion* **should not** be changed more than +once in any 36-epoch period (approximately 6 months). + +_Plutus Script Execution Prices (executionUnitPrices[priceSteps/priceMemory])_ + +Defines the fees for executing Plutus scripts: + +- Gives an economic return for Plutus script execution. +- Provides security against low-cost DoS attacks. + +#### Guardrails + +**EIUP-PS-01** (y) *executionUnitPrices[priceSteps]* **must not** exceed 2,000 / +10,000,000. + +**EIUP-PS-02** (y) *executionUnitPrices[priceSteps]* **must not** be lower than +500 / 10,000,000. + +**EIUP-PM-01** (y) *executionUnitPrices[priceMemory]* **must not** exceed +2,000 / 10,000. + +**EIUP-PM-02** (y) *executionUnitPrices[priceMemory]* **must not** be lower than +400 / 10,000. + +**EIUP-GEN-01** (x - "similar to") The execution prices **must** be set so that: + +- i) the cost of executing a transaction with maximum CPU steps is similar to + the cost of a maximum-sized non-script transaction and +- ii) the cost of executing a transaction with maximum memory units is similar + to the cost of a maximum-sized non-script transaction. + +**EIUP-GEN-02** (x - "should") The execution prices **should** be adjusted +whenever transaction fees are adjusted (*txFeeFixed/txFeePerByte*). The goal is +to ensure that the processing delay is similar for "full" transactions, +regardless of their type. + +- This helps ensure that the requirements on block diffusion/propagation times + are met. + +_Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte)_ + +Defines the cost for using Plutus reference scripts in Lovelace. + +#### Guardrails + +**MFRS-01** (y) *minFeeRefScriptCoinsPerByte* **must not** exceed 1,000 (0.001 +Ada). + +- This ensures that transactions can be paid for. + +**MFRS-02** (y) *minFeeRefScriptCoinsPerByte* **must not** be negative. + +**MFRS-03** (x - "should") To maintain a consistent level of protection against +denial-of-service attacks, *minFeeRefScriptCoinsPerByte* **should** be adjusted +whenever Plutus Execution prices are adjusted ( +*executionUnitPrices[steps/memory]*) and whenever *txFeeFixed* is adjusted. + +**MFRS-04** (x - unquantifiable) Any changes to *minFeeRefScriptCoinsPerByte* * +*must** consider the implications of reducing the cost of a denial-of-service +attack or increasing the maximum transaction fee. + +### 2.3. Network Parameters + +The overall goals when managing the Cardano Blockchain network parameters are +to: + +1. 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. +2. Balance traffic demands for different user groups, including payment + transactions, minters of Fungible/Non-Fungible Tokens, Plutus scripts, DeFi + developers, Stake Pool Operators, and voting transactions. + +_Triggers for Change_ + +Changes to network parameters may be triggered by: + +1. Measured changes in traffic demands over a 2-epoch period (10 days). +2. Anticipated changes in traffic demands. +3. Community requests. + +_Counter-indicators_ + +Changes may need to be reversed and/or should not be enacted in the event of: + +- Excessive block propagation delays. +- Stake pools being unable to handle traffic volume. +- Scripts being unable to complete execution. + +_Core Metrics_ + +All decisions on parameter changes should be informed by: + +- Block propagation delay profile. +- Traffic volume (block size over time). +- Script volume (size of scripts and execution units). +- Script execution cost benchmarks. +- Block propagation delay/diffusion benchmarks. + +Detailed benchmarking results are required to confirm the effect of any changes +on mainnet performance or behavior prior to enactment. The effects of different +transaction mixes must be analyzed, including normal transactions, Plutus +scripts, and governance actions. + +#### Guardrails + +**NETWORK-01** (x - "should") No individual network parameter **should** change +more than once per two epochs. + +**NETWORK-02** (x - "should") Only one network parameter **should** be changed +per epoch unless they are directly correlated, e.g., per-transaction and +per-block memory unit limits. + +_Changes to Specific Network Parameters_ + +_Block Size (maxBlockBodySize)_ + +The maximum size of a block, in Bytes. + +#### Guardrails + +**MBBS-01** (y) *maxBlockBodySize* **must not** exceed 122,880 Bytes (120KB). + +**MBBS-02** (y) *maxBlockBodySize* **must not** be lower than 24,576 Bytes ( +24KB). + +**MBBS-03** (x - "exceptional circumstances") *maxBlockBodySize* **must not** be +decreased, other than in exceptional circumstances where there are potential +problems with security, performance, or functionality. + +**MBBS-04** (~ - no access to existing parameter values) *maxBlockBodySize* * +*must** be large enough to include at least one transaction (that is, +*maxBlockBodySize* **must** be at least *maxTxSize*). + +**MBBS-05** (x - "should") *maxBlockBodySize* **should** be changed by at most +10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or +less per epoch. + +**MBBS-06** (x - "should") The block size **should not** induce an additional +Transmission Control Protocol (TCP) round trip. Any increase beyond this must be +backed by performance analysis, simulation, and benchmarking. + +**MBBS-07** (x - "unquantifiable") The impact of any change to +*maxBlockBodySize* **must** be confirmed by detailed benchmarking/simulation and +not exceed the requirements of the block diffusion/propagation time budgets, as +described below. Any increase to *maxBlockBodySize* must also consider future +requirements for Plutus script execution (*maxBlockExecutionUnits[steps]*) +against the total block diffusion target of 3s with 95% block propagation within +5s. The limit on maximum block size may be increased in the future if this is +supported by benchmarking and monitoring results. + +_Transaction Size (maxTxSize)_ + +The maximum size of a transaction, in Bytes. + +#### Guardrails + +**MTS-01** (y) *maxTxSize* **must not** exceed 32,768 Bytes (32KB). + +**MTS-02** (y) *maxTxSize* **must not** be negative. + +**MTS-03** (~ - no access to existing parameter values) *maxTxSize* **must not** +be decreased. + +**MTS-04** (~ - no access to existing parameter values) *maxTxSize* **must not** +exceed *maxBlockBodySize*. + +**MTS-05** (x - "should") *maxTxSize* **should not** be increased by more than +2,560 Bytes (2.5KB) in any epoch, and preferably **should** be increased by +2,048 Bytes (2KB) or less per epoch. + +**MTS-06** (x - "should") *maxTxSize* **should not** exceed 1/4 of the block +size. + +_Memory Unit Limits (maxBlockExecutionUnits[memory], +maxTxExecutionUnits[memory])_ + +The limit on the maximum number of memory units that can be used by Plutus +scripts, either per-transaction or per-block. + +#### Guardrails + +**MTEU-M-01** (y) *maxTxExecutionUnits[memory]* **must not** exceed 40,000,000 +units. + +**MTEU-M-02** (y) *maxTxExecutionUnits[memory]* **must not** be negative. + +**MTEU-M-03** (~ - no access to existing parameter values) +*maxTxExecutionUnits[memory]* **must not** be decreased. + +**MTEU-M-04** (x - "should") *maxTxExecutionUnits[memory]* **should not** be +increased by more than 2,500,000 units in any epoch. + +**MBEU-M-01** (y) *maxBlockExecutionUnits[memory]* **must not** exceed +120,000,000 units. + +**MBEU-M-02** (y) *maxBlockExecutionUnits[memory]* **must not** be negative. + +**MBEU-M-03** (x - "should") *maxBlockExecutionUnits[memory]* **should not** be +changed (increased or decreased) by more than 10,000,000 units in any epoch. + +**MBEU-M-04** (x - unquantifiable) The impact of any change to +*maxBlockExecutionUnits[memory]* **must** be confirmed by detailed +benchmarking/simulation and not exceed the requirements of the +diffusion/propagation time budgets, as also impacted by +*maxBlockExecutionUnits[steps]*. Any increase **must** also consider previously +agreed future requirements for the total block size (*maxBlockBodySize*) +measured against the total block diffusion target of 3s with 95% block +propagation within 5s. Future Plutus performance improvements may allow the +per-block limit to be increased, but must be balanced against the overall +diffusion limits as specified in the previous sentence, and future requirements. + +**MEU-M-01** (~ - no access to existing parameter values) +*maxBlockExecutionUnits[memory]* **must not** be less than +*maxTxExecutionUnits[memory]*. + +_CPU Unit Limits (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps])_ + +The limit on the maximum number of CPU steps that can be used by Plutus scripts, +either per-transaction or per-block. + +#### Guardrails + +**MTEU-S-01** (y) *maxTxExecutionUnits[steps]* **must not** exceed +15,000,000,000 (15Bn) units. + +**MTEU-S-02** (y) *maxTxExecutionUnits[steps]* **must not** be negative. + +**MTEU-S-03** (~ - no access to existing parameter values) +*maxTxExecutionUnits[steps]* **must not** be decreased. + +**MTEU-S-04** (x - "should") *maxTxExecutionUnits[steps]* **should not** be +increased by more than 500,000,000 (500M) units in any epoch (5 days). + +**MBEU-S-01** (y) *maxBlockExecutionUnits[steps]* **must not** exceed +40,000,000,000 (40Bn) units. + +**MBEU-S-02** (y) *maxBlockExecutionUnits[steps]* **must not** be negative. + +**MBEU-S-03** (x - "should") *maxBlockExecutionUnits[steps]* **should not** be +changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any +epoch (5 days). + +**MBEU-S-04** (x - unquantifiable) The impact of the change to +*maxBlockExecutionUnits[steps]* **must** be confirmed by detailed +benchmarking/simulation and not exceed the requirements of the block +diffusion/propagation time budgets, as also impacted by +*maxBlockExecutionUnits[memory]*. Any increase **must** also consider previously +identified future requirements for the total block size (*maxBlockBodySize*) +measured against the total block diffusion target of 3s with 95% block +propagation within 5s. Future Plutus performance improvements may allow the +per-block limit to be increased, but **must** be balanced against the overall +diffusion limits as specified in the previous sentence, and future requirements. + +**MEU-S-01** (~ - no access to existing parameter values) +*maxBlockExecutionUnits[steps]* **must not** be less than +*maxTxExecutionUnits[steps]*. + +_Block Header Size (maxBlockHeaderSize)_ + +The size of the block header. + +**Note:** Increasing the block header size may affect the overall block size ( +*maxBlockBodySize*). + +#### Guardrails + +**MBHS-01** (y) *maxBlockHeaderSize* **must not** exceed 5,000 Bytes. + +**MBHS-02** (y) *maxBlockHeaderSize* **must not** be negative. + +**MBHS-03** (x - "largest valid header" is subject to change) +*maxBlockHeaderSize* **must** be large enough for the largest valid header. + +**MBHS-04** (x - "should") *maxBlockHeaderSize* **should** only normally be +increased if the protocol changes. + +**MBHS-05** (x - "should") *maxBlockHeaderSize* **should** be within TCP's +initial congestion window (3 or 10 MTUs). + +### 2.4. Technical/Security Parameters + +The overall goals when managing the technical/security parameters are: + +1. Ensure the security of the Cardano network in terms of decentralization, + protection against Sybil and 51% attacks, and protection against denial of + service attacks. +2. Enable changes to the Plutus language. + +_Triggers for Change_ + +1. Changes in the number of active SPOs. +2. Changes to the Plutus language. +3. Security threats. +4. Community requests. + +_Counter-indicators_ + +- Economic concerns, e.g., when changing the number of stake pools. + +_Core Metrics_ + +- Number of stake pools. +- Level of decentralization. + +_Changes to Specific Technical/Security Parameters_ + +_Target Number of Stake Pools (stakePoolTargetNum)_ + +Sets the target number of stake pools: + +- The expected number of pools when the network is in the equilibrium state. +- Primarily a security parameter, ensuring decentralization by pool + division/replication. +- Has an economic effect as well as a security effect; economic advice is also + required when changing this parameter. +- Large changes in this parameter will trigger mass redelegation events. + +#### Guardrails + +**SPTN-01** (y) *stakePoolTargetNum* **must not** be lower than 250. + +**SPTN-02** (y) *stakePoolTargetNum* **must not** exceed 2,000. + +**SPTN-03** (y) *stakePoolTargetNum* **must not** be negative. + +**SPTN-04** (y) *stakePoolTargetNum* **must not** be zero. + +_Pledge Influence Factor (poolPledgeInfluence)_ + +Enables the pledge protection mechanism: + +- Provides protection against Sybil attack. +- Higher values reward pools that have more pledge and penalize pools that have + less pledge. +- Has an economic effect as well as technical effect; economic advice is also + required. +- Can be set in the range 0.0-infinity. + +#### Guardrails + +**PPI-01** (y) *poolPledgeInfluence* **must not** be lower than 0.1. + +**PPI-02** (y) *poolPledgeInfluence* **must not** exceed 1.0. + +**PPI-03** (y) *poolPledgeInfluence* **must not** be negative. + +**PPI-04** (x - "should") *poolPledgeInfluence* **should not** vary by more +than +/- 10% in any 18-epoch period (approximately 3 months). + +_Pool Retirement Window (poolRetireMaxEpoch)_ + +Defines the maximum number of epochs notice that a pool can give when planning +to retire. + +#### Guardrails + +**PRME-01** (y) *poolRetireMaxEpoch* **must not** be negative. + +**PRME-02** (x - "should") *poolRetireMaxEpoch* **should not** be lower than 1. + +_Collateral Percentage (collateralPercentage)_ + +Defines how much collateral must be provided when executing a Plutus script as a +percentage of the normal execution cost: + +- Collateral is additional to fee payments. +- If a script fails to execute, then the collateral is lost. +- The collateral is never lost if a script executes successfully. +- Provides security against low-cost attacks by making it more expensive rather + than less expensive to execute failed scripts. + +#### Guardrails + +**CP-01** (y) *collateralPercentage* **must not** be lower than 100. + +**CP-02** (y) *collateralPercentage* **must not** exceed 200. + +**CP-03** (y) *collateralPercentage* **must not** be negative. + +**CP-04** (y) *collateralPercentage* **must not** be zero. + +_Maximum number of collateral inputs (maxCollateralInputs)_ + +Defines the maximum number of inputs that can be used for collateral when +executing a Plutus script. + +#### Guardrails + +**MCI-01** (y) *maxCollateralInputs* **must not** be lower than 1. + +The limit on the serialized size of the Value in each output. + +#### Guardrails + +**MVS-01** (y) *maxValueSize* **must not** exceed 12,288 Bytes (12KB). + +**MVS-02** (y) *maxValueSize* **must not** be negative. + +**MVS-03** (~ - no access to existing parameter values) *maxValueSize* **must** +be less than *maxTxSize*. + +**MVS-04** (~ - no access to existing parameter values) *maxValueSize* **must +not** be reduced. + +**MVS-05** (x - "sensible output" is subject to interpretation) *maxValueSize* * +*must** be large enough to allow sensible outputs (e.g., any existing on-chain +output or anticipated outputs that could be produced by new ledger rules). + +_Plutus Cost Models (costModels)_ + +Defines the base costs for each Plutus primitive in terms of CPU and memory +units: + +- There are about 150 distinct micro-parameters in total. +- Cost models are defined for each Plutus language version. A new language + version may introduce additional micro-parameters or remove existing + micro-parameters. + +#### Guardrails + +**PCM-01** (x - unquantifiable) *Cost model* values **must** be set by +benchmarking on a reference architecture. + +**PCM-02** (x - primitives and language versions aren't introduced in +transactions) The *cost model* **must** be updated if new primitives are +introduced or a new Plutus language version is added. + +**PCM-03** (~ - no access to *Plutus cost model* parameters) *Cost model* values +**should not** be negative. + +**PCM-04** (~ - no access to *Plutus cost model* parameters) A *cost model* * +*must** be supplied for each Plutus language version that the protocol supports. + +### 2.5. Governance Parameters + +The overall goals when managing the governance parameters are to: + +1. Ensure governance stability. +2. Maintain a representative form of governance as outlined in CIP-1694. + +_Triggers for Change_ + +Changes to governance parameters may be triggered by: + +1. Community requests. +2. Regulatory requirements. +3. Unexpected or unwanted governance outcomes. +4. Entering a state of no confidence. + +_Counter-indicators_ + +Changes may need to be reversed and/or should not be enacted in the event of: + +- Unexpected effects on governance. +- Excessive Layer 1 load due to on-chain voting or excessive numbers of + governance actions. + +_Core Metrics_ + +All decisions on parameter changes should be informed by: + +- Governance participation levels. +- Governance behaviors and patterns. +- Regulatory considerations. +- Confidence in the governance system. +- The effectiveness of the governance system in managing necessary change. + +_Changes to Specific Governance Parameters_ + +_Deposit for Governance Actions (govDeposit)_ + +The deposit that is charged when submitting a governance action: + +- Helps to limit the number of actions that are submitted. + +#### Guardrails + +**GD-01** (y) *govDeposit* **must not** be negative. + +**GD-02** (y) *govDeposit* **must not** be lower than 1,000,000 (1 Ada). + +**GD-03** (y) *govDeposit* **must not** exceed 10,000,000,000,000 (10 million +Ada). + +**GD-04** (x - "should") *govDeposit* **should** be adjusted in line with fiat +changes. + +_Deposit for dReps (dRepDeposit)_ + +The deposit that is charged when registering a dRep: + +- Helps to limit the number of active dReps. + +#### Guardrails + +**DRD-01** (y) *dRepDeposit* **must not** be negative. + +**DRD-02** (y) *dRepDeposit* **must not** be lower than 1,000,000 (1 Ada). + +**DRD-03** (y) *dRepDeposit* **must not** exceed 100,000,000,000 (100,000 Ada). + +**DRD-04** (x - "should") *dRepDeposit* **should** be adjusted in line with fiat +changes. + +_DRep Activity Period (dRepActivity)_ + +The period (as a whole number of epochs) after which a dRep is considered to be +inactive for vote calculation purposes, if they do not vote on any proposal. + +#### Guardrails + +**DRA-01** (y) *dRepActivity* **must not** be lower than 13 epochs (2 months). + +**DRA-02** (y) *dRepActivity* **must not** exceed 37 epochs (6 months). + +**DRA-03** (y) *dRepActivity* **must not** be negative. + +**DRA-04** (~ - no access to existing parameter values) *dRepActivity* **must** +be greater than *govActionLifetime*. + +**DRA-05** (x - "should") *dRepActivity* **should** be calculated in human +terms (2 months, etc.). + +_DRep and SPO Governance Action Thresholds (dRepVotingThresholds[...], +poolVotingThresholds[...])_ + +Thresholds on the active voting stake that is required to ratify a specific type +of governance action by either dReps or SPOs: + +- Ensures legitimacy of the action. + +The threshold parameters are listed below: + +**dRepVotingThresholds**: + +- *dvtCommitteeNoConfidence* +- *dvtCommitteeNormal* +- *dvtHardForkInitiation* +- *dvtMotionNoConfidence* +- *dvtPPEconomicGroup* +- *dvtPPGovGroup* +- *dvtPPNetworkGroup* +- *dvtPPTechnicalGroup* +- *dvtTreasuryWithdrawal* +- *dvtUpdateToConstitution* + +**poolVotingThresholds**: + +- *pvtCommitteeNoConfidence* +- *pvtCommitteeNormal* +- *pvtHardForkInitiation* +- *pvtMotionNoConfidence* +- *pvtPPSecurityGroup* + +#### Guardrails + +**VT-GEN-01** (y) All thresholds **must** be greater than 50% and less than or +equal to 100%. + +**VT-GEN-02** (y) Economic, network, and technical parameter thresholds **must** +be in the range 51%-75%. + +**VT-GEN-03** (y) Governance parameter thresholds **must** be in the range +75%-90%. + +**VT-HF-01** (y) **Hard fork** action thresholds **must** be in the range +51%-80%. + +**VT-CON-01** (y) **New Constitution or guardrails script action** thresholds * +*must** be in the range 65%-90%. + +**VT-CC-01** (y) **Update Constitutional Committee action** thresholds **must** +be in the range 51%-90%. + +**VT-NC-01** (y) **No confidence** action thresholds **must** be in the range +51%-75%. + +_Governance Action Lifetime (govActionLifetime)_ + +The period after which a governance action will expire if it is not enacted: + +- As a whole number of epochs. + +#### Guardrails + +**GAL-01** (y) *govActionLifetime* **must not** be lower than 1 epoch (5 days). + +**GAL-03** (x - "should") *govActionLifetime* **should not** be lower than 2 +epochs (10 days). + +**GAL-02** (y) *govActionLifetime* **must not** exceed 15 epochs (75 days). + +**GAL-04** (x - "should") *govActionLifetime* **should** be calibrated in human +terms (e.g., 30 days, two weeks) to allow sufficient time for voting, etc., to +take place. + +**GAL-05** (~ - no access to existing parameter values) *govActionLifetime* * +*must** be less than *dRepActivity*. + +_Maximum Constitutional Committee Term (committeeMaxTermLimit)_ + +The limit on the maximum term that a committee member may serve. + +#### Guardrails + +**CMTL-01** (y) *committeeMaxTermLimit* **must not** be zero. + +**CMTL-02** (y) *committeeMaxTermLimit* **must not** be negative. + +**CMTL-03** (y) *committeeMaxTermLimit* **must not** be lower than 18 epochs (90 +days, or approximately 3 months). + +**CMTL-04** (y) *committeeMaxTermLimit* **must not** exceed 293 epochs ( +approximately 4 years). + +**CMTL-05** (x - "should") *committeeMaxTermLimit* **should not** exceed 220 +epochs (approximately 3 years). + +_The minimum size of the Constitutional Committee (committeeMinSize)_ + +The least number of members that can be included in a Constitutional Committee +following a governance action to change the Constitutional Committee. + +#### Guardrails + +**CMS-01** (y) *committeeMinSize* **must not** be negative. + +**CMS-02** (y) *committeeMinSize* **must not** be lower than 3. + +**CMS-03** (y) *committeeMinSize* **must not** exceed 10. + +### 2.6. Monitoring and Reversion of Parameter Changes + +All network parameter changes **must** be monitored carefully for no less than 2 +epochs (10 days): + +- Changes **must** be reverted as soon as possible if block propagation delays + exceed 4.5s for more than 5% of blocks over any 6-hour rolling window. + +All other parameter changes should be monitored carefully for any adverse +effects on performance, security, or functionality. If such effects are +observed, appropriate actions, including reversion to previous parameters, +should be taken. + +A specific reversion/recovery plan **must be** produced for each parameter +change. This plan must include: + +- Which parameters need to change and in which ways in order to return to the + previous state (or a similar state). +- How to recover the network in the event of a disastrous failure. + +This plan **should** be followed if problems are observed following the +parameter change. Note that not all changes can be reverted. Additional care +must be taken when making changes to these parameters. + +### 2.7. Non-Updatable Protocol Parameters + +Some fundamental protocol parameters cannot be changed by the Protocol Parameter +Update governance action. These parameters can only be changed in a new Genesis +file as part of a hard fork. It is not necessary to provide specific guardrails +on updating these parameters. + +### 3. GUARDRAILS AND GUIDELINES ON TREASURY WITHDRAWAL ACTIONS + +**Treasury withdrawal** actions specify the destination and amount of a number +of withdrawals from the Cardano treasury. + +#### Guardrails + +**TREASURY-01** (x) dReps **must** define a net change limit for the Cardano +Treasury's balance per period of time. + +**TREASURY-02** (x) The budget for the Cardano Treasury **must not** exceed the +net change limit for the Cardano Treasury's balance per period of time. + +**TREASURY-03** (x) The budget for the Cardano Treasury **must** be denominated +in Ada. + +**TREASURY-04** (x) Treasury withdrawals **must not** be ratified until there is +a community-approved Cardano budget then in effect pursuant to a previous +on-chain governance action agreed by the dReps with a threshold of greater than +50% of the active voting stake. + +### 4. GUARDRAILS AND GUIDELINES ON HARD FORK INITIATION ACTIONS + +The **hard fork initiation** action requires both a new major and a new minor +protocol version to be specified: + +- As positive integers. + +As the result of a hard fork, new updatable protocol parameters may be +introduced. Guardrails may be defined for these parameters, which will take +effect following the hard fork. Existing updatable protocol parameters may also +be deprecated by the hard fork, in which case the guardrails become obsolete for +all future changes. + +#### Guardrails + +**HARDFORK-01** (~ - no access to existing parameter values) The major protocol +version **must** be the same as or one greater than the major version that will +be enacted immediately prior to this change. If the major protocol version is +one greater, then the minor protocol version **must** be zero. + +**HARDFORK-02** (~ - no access to existing parameter values) The minor protocol +version **must** be no less than the minor version that will be enacted +immediately prior to this change. + +**HARDFORK-03** (~ - no access to existing parameter values) At least one of the +protocol versions (major or minor or both) **must** change. + +**HARDFORK-04** (x) At least 85% of stake pools by active stake **should** have +upgraded to a Cardano node version that is capable of processing the rules +associated with the new protocol version. + +**HARDFORK-05** (x) Any new updatable protocol parameters that are introduced +with a hard fork **must** be included in this Appendix and suitable guardrails +defined for those parameters. + +**HARDFORK-06** (x) Settings for any new protocol parameters that are introduced +with a hard fork **must** be included in the appropriate Genesis file. + +**HARDFORK-07** (x) Any deprecated protocol parameters **must** be indicated in +this Appendix. + +**HARDFORK-08** (~ - no access to *Plutus cost model* parameters) New Plutus +versions **must** be supported by a version-specific *Plutus cost model* that +covers each primitive that is available in the new Plutus version. + +### 5. GUARDRAILS AND GUIDELINES ON UPDATE CONSTITUTIONAL COMMITTEE OR THRESHOLD ACTIONS + +**Update Constitutional Committee or Threshold** governance actions may change +the size, composition, or required voting thresholds for the Constitutional +Committee. + +#### Guardrails + +**UPDATE-CC-01** (x) **Update Constitutional Committee and/or threshold** * +*and/or term** governance actions **must not** be ratified until Ada holders +have ratified through an on-chain governance action the Final Constitution. + +### 6. GUARDRAILS AND GUIDELINES ON NEW CONSTITUTION OR GUARDRAILS SCRIPT ACTIONS + +New constitution or guardrails script actions change the hash of the on-chain +constitution and the associated guardrails script. + +#### Guardrails + +**NEW-CONSTITUTION-01** (x) A **New Constitution** **or Guardrails Script** +governance action **must** be submitted to define any required guardrails for +new parameters that are introduced via a Hard Fork governance action. + +### 7. GUARDRAILS AND GUIDELINES ON NO CONFIDENCE ACTIONS + +**No confidence** actions signal a state of no confidence in the governance +system. No guardrails are imposed on **No Confidence** actions. + +#### Guardrails + +- None + +### 8. GUARDRAILS AND GUIDELINES ON INFO ACTIONS + +**Info** actions are not enacted on-chain. No guardrails are imposed on **Info** +actions. + +#### Guardrails + +- None + +### 9. GUARDRAILS DURING THE INTERIM PERIOD + +_Interim Period_ + +The Interim Period begins with the Chang Hard-Fork and ends after a +community-ratified Final Constitution is enacted on-chain. Throughout the +Interim Period, technical and constitution-enforced triggers will progressively +turn on the features of CIP-1694. + +_Interim Period Technical Rollout:_ + +- The Chang Hard Fork will enable three initial CIP-1694 governance actions and + enable the representative framework to be established. + +These actions are the **"Info"**, **"Hard-fork initiation"**, and **"Protocol +parameter changes"** actions. + +Ada holders will be able to register as and delegate to dReps immediately after +the hard fork but, as described in CIP-1694, dRep voting will not be available, +except on **"Info"** actions. This ensures that Ada holders have sufficient time +to choose their voting delegations. + +SPOs will be able to vote as described in CIP-1694. + +**"Hard-fork initiation"** and **"Protocol parameter changes"** actions will +also be ratified by the Constitutional Committee. + +Ada holders will be able to withdraw their staking rewards as usual. + +- A subsequent hard fork, ratified by the Constitutional Committee and SPOs, + shortly after the Chang Hard Fork, will enable the four remaining CIP-1694 + governance actions: + + - **"Treasury withdrawals"**, + - **"Motion of no-confidence"**, + - **"Update constitutional committee and/or threshold and/or terms"**, and + - **"New constitution or guardrails script"**. + +At this point, dRep voting will be enabled and staking rewards can only be +withdrawn if the Ada holder has delegated their vote (including to the +pre-defined Abstain/No Confidence voting options). + +#### Guardrails + +**INTERIM-01** (x) To provide sufficient time for dReps to register and campaign +and for Ada holders to choose their initial voting delegations, at least 18 +epochs (90 days, or approximately 3 months) **must** elapse after the Chang hard +fork before the subsequent hard fork can be ratified. Once the subsequent hard +fork is enacted, dRep voting can occur as described in CIP-1694. + +**INTERIM-02** (x) Treasury withdrawals **must not** be ratified until there is +a community-approved Cardano Blockchain Ecosystem budget then in effect pursuant +to a previous on-chain governance action. + +**INTERIM-03** (x) Treasury withdrawals **must** be consistent with the +community-approved Cardano Blockchain ecosystem budget(s). + +**INTERIM-04** (x) Ada holders **must** have ratified the Final Constitution as +specified in Appendix II before ratifying any other proposed **"new +constitution"**, **"update constitutional committee and/or threshold and/or +terms"**, and **"motion of no-confidence"** governance actions. + +**INTERIM-05** (x) **"New guardrails script"** actions that are consistent with +the Interim Constitution may be ratified during the interim period, provided the +Interim Constitution itself is not changed. + +### 10. LIST OF PROTOCOL PARAMETER GROUPS + +The protocol parameters are grouped by type, allowing different thresholds to be +set for each group. + +_The network group consists of:_ + +- *maximum block body size* (*maxBlockBodySize*) +- *maximum transaction size* (*maxTxSize*) +- *maximum block header size* (*maxBlockHeaderSize*) +- *maximum size of a serialized asset value* (*maxValueSize*) +- *maximum script execution units in a single transaction* ( + *maxTxExecutionUnits[steps]*) +- *maximum script execution units in a single block* ( + *maxBlockExecutionUnits[steps]*) +- *maximum number of collateral inputs* (*maxCollateralInputs*) + +_The economic group consists of:_ + +- *minimum fee coefficient* (*txFeePerByte*) +- *minimum fee constant* (*txFeeFixed*) +- *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*) +- *delegation key Lovelace deposit* (*stakeAddressDeposit*) +- *pool registration Lovelace deposit* (*stakePoolDeposit*) +- *monetary expansion* (*monetaryExpansion*) +- *treasury expansion* (*treasuryCut*) +- *minimum fixed rewards cut for pools* (*minPoolCost*) +- *minimum Lovelace deposit per byte of serialized UTxO* (*utxoCostPerByte*) +- *prices of Plutus execution units* ( + *executionUnitPrices[priceSteps/priceMemory]*) + +_The technical group consists of:_ + +- *pool pledge influence* (*poolPledgeInfluence*) +- *pool retirement maximum epoch* (*poolRetireMaxEpoch*) +- *desired number of pools* (*stakePoolTargetNum*) +- *Plutus execution cost models* (*costModels*) +- *proportion of collateral needed for scripts* (*collateralPercentage*) + +_The governance group consists of all the new protocol parameters that are +introduced in CIP-1694:_ + +- *governance voting thresholds* (*dRepVotingThresholds[...], + poolVotingThresholds[...]*) +- *governance action maximum lifetime in epochs* (*govActionLifetime*) +- *governance action deposit* (*govActionDeposit*) +- *dRep deposit amount* (*dRepDeposit*) +- *dRep activity period in epochs* (*dRepActivity*) +- *minimal constitutional committee size* (*committeeMinSize*) +- *maximum term length (in epochs) for the constitutional committee members* ( + *committeeMaxTermLimit*) + +## APPENDIX II: INTERIM CONSTITUTION + +### 1. PREAMBLE + +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. + +### 2. INTERIM GOVERNANCE STRUCTURE + +#### Section 1: Interim Constitutional Committee + +The Interim Constitutional Committee (ICC) shall be established to oversee the +governance of the Cardano Blockchain during the Interim Period. The ICC shall +have the authority to approve or reject governance actions, ensure compliance +with the Interim Constitution, and oversee the transition to the Final +Constitution. + +**Composition:** + +- The ICC shall consist of a minimum of 3 and a maximum of 10 members. +- Members shall be selected based on their expertise, contributions to the + Cardano ecosystem, and commitment to decentralized governance. + +**Term:** + +- The term of the ICC members shall not exceed 18 epochs (90 days) unless + extended by a community vote. + +**Powers:** + +- The ICC shall have the power to veto governance actions that are deemed + unconstitutional or detrimental to the Cardano ecosystem. +- The ICC shall ensure that all governance actions comply with the guardrails + established in this Interim Constitution. + +**Dissolution:** + +- The ICC shall be dissolved upon the ratification of the Final Constitution, at + which point a new Constitutional Committee shall be established. + +#### Section 2: Interim Voting Mechanisms + +During the Interim Period, governance actions shall be subject to the following +voting mechanisms: + +**dReps Voting:** + +- Delegated Representatives (dReps) shall vote on governance actions on behalf + of ADA holders. +- dRep votes shall be weighted according to the amount of ADA delegated to them. +- A simple majority of the active voting stake is required to approve a + governance action. + +**SPOs Voting:** + +- Stake Pool Operators (SPOs) shall vote on specific governance actions, + particularly those related to protocol parameters and technical changes. +- SPO votes shall be weighted according to the amount of ADA staked in their + pools. +- A simple majority of the active stake pool stake is required to approve a + governance action. + +**Community Sentiment Votes:** + +- Community sentiment votes (Info actions) shall be conducted to gauge the + community's opinion on non-binding governance actions. +- Info actions shall not have any on-chain effects other than recording the + outcome of the vote. + +### 3. TRANSITION TO FINAL CONSTITUTION + +#### Section 1: Development and Ratification + +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: + +1. **Community Consultation:** + - The Cardano community shall be actively involved in the consultation + process, providing input and feedback on the draft Final Constitution. + +2. **Drafting Committee:** + - A Drafting Committee shall be established to compile and refine the input + from the community into a cohesive Final Constitution. + - The Drafting Committee shall consist of representatives from various + stakeholder groups, including ADA holders, dReps, SPOs, and developers. + +3. **Public Review:** + - The draft Final Constitution shall be made available for public review and + comment for a minimum of 6 epochs (30 days). + +4. **Ratification Vote:** + - A ratification vote shall be conducted to approve the Final Constitution. + - A minimum of 67% of the active voting stake must support the Final + Constitution for it to be ratified. + +#### Section 2: Implementation + +Upon ratification of the Final Constitution: + +1. **Establishment of the Constitutional Committee:** + - A new Constitutional Committee shall be established in accordance with the + Final Constitution. + - The Interim Constitutional Committee shall be dissolved. + +2. **Transition of Governance Powers:** + - All governance powers and responsibilities shall transition from the + Interim Constitutional Committee to the new Constitutional Committee. + - Any pending governance actions under the Interim Constitution shall be + carried over and processed under the Final Constitution. + +3. **Guardrails and Protocol Parameters:** + - 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. + +### 4. AMENDMENTS TO THE INTERIM CONSTITUTION + +Amendments to this Interim Constitution may be proposed by any ADA holder, dRep, +or SPO. The process for amending the Interim Constitution is as follows: + +1. **Proposal Submission:** + - The proposed amendment shall be submitted as a governance action, + accompanied by a rationale and supporting documentation. + +2. **Review by the ICC:** + - The Interim Constitutional Committee shall review the proposed amendment + for compliance with the guardrails and overall impact on the Cardano + ecosystem. + +3. **Community Vote:** + - The proposed amendment shall be put to a community vote, requiring a + minimum of 67% of the active voting stake to approve the amendment. + +4. **Implementation:** + - If approved, the amendment shall be implemented and the Interim + Constitution shall be updated accordingly. + +### 5. FINAL PROVISIONS + +#### Section 1: Supremacy Clause + +In the event of a conflict between this Interim Constitution and any governance +action or protocol parameter, this Interim Constitution shall prevail. + +#### Section 2: Continuity Clause + +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. + +#### Section 3: Interpretation + +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. + +#### Section 4: Dissolution of Interim Governance Structures + +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. + +## APPENDIX III: GLOSSARY OF TERMS + +**ADA:** The native cryptocurrency of the Cardano Blockchain. + +**Cardano Blockchain:** A decentralized blockchain platform that enables the +development of smart contracts, decentralized applications (DApps), and digital +assets. + +**CIP-1694:** A Cardano Improvement Proposal that outlines the governance +framework for the Cardano Blockchain. + +**Constitutional Committee:** The governance body responsible for ensuring that +governance actions are consistent with the Cardano Constitution. + +**dRep (Delegated Representative):** An individual or entity that represents ADA +holders in the on-chain governance process by voting on governance actions on +their behalf. + +**Epoch:** A time period used in the Cardano Blockchain, typically lasting 5 +days. + +**Final Constitution:** The permanent governance framework for the Cardano +Blockchain, to be ratified by the community and replace the Interim +Constitution. + +**Guardrails:** Specific guidelines and constraints that govern the parameters +and actions within the Cardano Blockchain ecosystem. + +**Hard Fork:** A protocol upgrade that changes the blockchain's rules and +requires all nodes to upgrade to the new version. + +**Interim Constitution:** The temporary governance framework for the Cardano +Blockchain during the transition to the Final Constitution. + +**SPO (Stake Pool Operator):** An individual or entity responsible for operating +a stake pool, which participates in the consensus mechanism of the Cardano +Blockchain. + +**Treasury:** A pool of ADA used to fund development and other initiatives +within the Cardano ecosystem. + +## APPENDIX IV: INTERIM PERIOD ACTIONS AND TIMELINE + +### 1. INITIAL GOVERNANCE ACTIONS + +During the Interim Period, the following initial governance actions shall be +prioritized: + +1. **Establishment of the Interim Constitutional Committee (ICC):** + - The ICC shall be established within 2 epochs following the Chang Hard + Fork. + +2. **Delegated Representative (dRep) Registration:** + - dReps shall be allowed to register immediately following the Chang Hard + Fork. + - ADA holders shall have the option to delegate their voting rights to + registered dReps. + +3. **Community Sentiment (Info) Actions:** + - Info actions shall be used to gauge community sentiment on key governance + topics. + - These actions shall not have on-chain effects but shall inform future + governance decisions. + +4. **Initial Hard Fork Initiation:** + - The first hard fork initiation action shall be proposed to enable + additional governance actions, such as Treasury withdrawals. + +### 2. TIMELINE FOR FINAL CONSTITUTION DEVELOPMENT + +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. + +1. **Community Consultation Phase:** + - Duration: 6 epochs (30 days). + - Purpose: Engage the Cardano community in discussions and solicit feedback + on the principles, structure, and content of the Final Constitution. + - Actions: Conduct workshops, surveys, and community forums to gather input. + +2. **Drafting Phase:** + - Duration: 6 epochs (30 days). + - Purpose: The Drafting Committee compiles and integrates community feedback + into a cohesive draft of the Final Constitution. + - Actions: The Drafting Committee meets regularly to refine the draft, + considering all input from the community consultation phase. + +3. **Public Review Phase:** + - Duration: 6 epochs (30 days). + - Purpose: Present the draft Final Constitution to the Cardano community for + public review and comment. + - Actions: The draft is published online, and a dedicated platform is made + available for comments, suggestions, and discussion. + +4. **Revision Phase:** + - Duration: 4 epochs (20 days). + - Purpose: The Drafting Committee revises the draft based on community + feedback from the public review phase. + - Actions: Final adjustments are made, and the draft is prepared for the + ratification vote. + +5. **Ratification Vote:** + - Duration: 2 epochs (10 days). + - Purpose: Conduct a vote among ADA holders to ratify the Final + Constitution. + - Threshold: A minimum of 67% of the active voting stake must support the + Final Constitution for it to be ratified. + - Actions: Voting takes place on-chain, with results published immediately + after the vote concludes. + +6. **Transition Phase:** + - Duration: 2 epochs (10 days). + - Purpose: Implement the Final Constitution and transition governance powers + to the new governance structures. + - Actions: Dissolution of the Interim Constitutional Committee, + establishment of the Constitutional Committee, and activation of the + governance framework as outlined in the Final Constitution. + +### 3. INTERIM PERIOD GOVERNANCE ACTIONS + +During the Interim Period, specific governance actions shall be prioritized to +ensure the smooth transition to the Final Constitution. These actions include: + +1. **Guardrails Implementation:** + - Purpose: Ensure all critical guardrails are in place to protect the + integrity and stability of the Cardano Blockchain during the Interim + Period. + - Actions: Establish, review, and amend guardrails as necessary. + +2. **Budget Proposal and Approval:** + - Purpose: Develop and approve a budget for the ongoing maintenance and + development of the Cardano Blockchain during the Interim Period. + - Actions: The Interim Constitutional Committee, in collaboration with the + community, shall propose a budget that must be approved through an + on-chain governance vote. + +3. **Hard Fork Preparation:** + - Purpose: Prepare for necessary hard forks that may be required to + implement changes during the Interim Period. + - Actions: Engage with developers, SPOs, and the community to ensure a + smooth transition during hard fork events. + +4. **Treasury Management:** + - Purpose: Oversee the management and distribution of funds from the Cardano + Treasury. + - Actions: Review treasury withdrawal proposals, ensuring alignment with + community goals and budgetary constraints. + +5. **Community Engagement and Education:** + - Purpose: Ensure that the Cardano community remains informed and engaged + throughout the Interim Period. + - Actions: Conduct regular updates, educational sessions, and community + events to explain governance processes and encourage participation. + +## APPENDIX V: IMPLEMENTATION GUIDELINES FOR CIP-1694 + +### 1. INTRODUCTION TO CIP-1694 IMPLEMENTATION + +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. + +### 2. ESTABLISHMENT OF GOVERNANCE BODIES + +#### Section 1: Delegated Representatives (dReps) + +dReps play a crucial role in representing ADA holders in the governance process. +The following steps outline the process for establishing dReps: + +1. **Registration:** + - dReps must register on-chain, providing information about their + qualifications, experience, and governance philosophy. + - Registration fees may apply, as specified in the governance parameters. + +2. **Delegation:** + - ADA holders can delegate their voting power to registered dReps. + - Delegation is flexible, allowing ADA holders to change their dRep at any + time. + +3. **Responsibilities:** + - dReps are expected to vote on governance actions, represent the interests + of their delegators, and adhere to the code of conduct. + +4. **Accountability:** + - dReps must disclose any conflicts of interest and provide regular updates + to their delegators. + - Failure to act in the best interests of delegators may result in loss of + delegation or other penalties. + +#### Section 2: Stake Pool Operators (SPOs) + +SPOs contribute to the security and decentralization of the Cardano Blockchain +and participate in governance actions. The following guidelines apply to SPOs: + +1. **Participation:** + - SPOs are automatically eligible to vote on certain governance actions, + particularly those related to protocol parameters and technical changes. + +2. **Voting Power:** + - SPO voting power is weighted according to the amount of ADA staked in + their pools. + - SPOs must act transparently and in the best interests of the Cardano + community. + +3. **Conflicts of Interest:** + - SPOs must disclose any potential conflicts of interest and refrain from + voting on actions where such conflicts may arise. + +4. **Compliance:** + - SPOs must comply with all governance guidelines and adhere to the code of + conduct. + +#### Section 3: Constitutional Committee + +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: + +1. **Selection:** + - Members of the Constitutional Committee shall be selected based on their + expertise, contributions to the Cardano ecosystem, and commitment to + decentralized governance. + - The number of members and term limits are specified in the governance + parameters. + +2. **Responsibilities:** + - The Constitutional Committee reviews all governance actions to ensure they + comply with the Cardano Constitution. + - The Committee may veto any governance action that violates the + Constitution. + +3. **Transparency:** + - The Constitutional Committee must operate transparently, publishing its + decisions and the rationale behind them. + - All meetings and votes of the Committee should be documented and made + available to the public. + +4. **Accountability:** + - Members of the Constitutional Committee are accountable to the Cardano + community and must act in the best interests of the ecosystem. + - The community may propose changes to the Committee's composition or powers + through governance actions. + +### 3. VOTING PROCEDURES + +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: + +#### Section 1: Proposal Submission + +1. **Eligibility:** + - Any ADA holder, dRep, or SPO may submit a governance proposal. + - Proposals must be submitted in a standardized format, including a clear + rationale, potential impact, and supporting documentation. + +2. **Submission Process:** + - Proposals are submitted on-chain and are subject to a deposit fee, as + specified in the governance parameters. + - The proposal is then reviewed by the relevant governance bodies (e.g., + dReps, SPOs, Constitutional Committee). + +3. **Review and Approval:** + - Proposals are reviewed for completeness, compliance with guardrails, and + potential impact on the Cardano ecosystem. + - Once approved, proposals are scheduled for a vote. + +#### Section 2: Voting Process + +1. **Voting Period:** + - The voting period for each proposal is defined in the governance + parameters and typically lasts between 5 to 15 epochs. + - During this period, ADA holders, dReps, and SPOs can cast their votes. + +2. **Voting Mechanisms:** + - Votes are cast on-chain, and each vote is weighted according to the + voter's stake (for ADA holders) or delegation (for dReps). + - The results of the vote are automatically recorded on the blockchain. + +3. **Thresholds:** + - Different types of proposals may require different thresholds for + approval (e.g., simple majority, supermajority). + - Thresholds are defined in the governance parameters and vary based on the + type and significance of the proposal. + +4. **Result Publication:** + - The results of the vote are published immediately after the voting period + ends. + - All votes and outcomes are recorded on-chain, ensuring transparency and + immutability. + +#### Section 3: Implementation of Approved Proposals + +1. **Execution:** + - Approved proposals are automatically executed by smart contracts, where + applicable. + - For proposals requiring manual implementation (e.g., changes to off-chain + processes), the responsible parties are notified, and a timeline for + implementation is established. + +2. **Monitoring:** + - The implementation of approved proposals is monitored by the relevant + governance bodies to ensure compliance and effectiveness. + - Any issues or deviations from the approved proposal must be reported and + addressed promptly. + +3. **Feedback Loop:** + - The Cardano community is encouraged to provide feedback on the + implementation and outcomes of approved proposals. + - This feedback may be used to refine future proposals or governance + processes. + +### 4. ONGOING GOVERNANCE MAINTENANCE + +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: + +#### Section 1: Regular Reviews + +1. **Periodic Audits:** + - Governance processes, including voting procedures, the role of dReps, + SPOs, and the Constitutional Committee, shall undergo periodic audits. + - Audits will assess compliance with the Constitution, effectiveness, and + areas for improvement. + - The results of these audits will be made public and may inform future + governance proposals. + +2. **Annual Governance Review:** + - An annual review of the governance framework shall be conducted by the + Constitutional Committee in collaboration with the Cardano community. + - This review will consider the performance of the governance structures, + the effectiveness of the guardrails, and any evolving needs of the Cardano + ecosystem. + - Recommendations from the review may lead to proposed amendments or updates + to the Constitution or governance parameters. + +3. **Community Feedback:** + - Continuous feedback from the Cardano community will be solicited to ensure + the governance framework remains responsive to community needs. + - Mechanisms for gathering feedback include surveys, forums, and public + consultations. + +4. **Review of Guardrails:** + - Guardrails that govern protocol parameters and governance actions should + be reviewed regularly to ensure they remain relevant and effective. + - Changes to guardrails may be proposed as governance actions and must go + through the standard voting process. + +#### Section 2: Governance Updates and Amendments + +1. **Amendment Proposals:** + - Any member of the Cardano community may propose amendments to the + Constitution, guardrails, or other governance parameters. + - Proposals must include a clear rationale, potential impacts, and a + detailed plan for implementation. + +2. **Review Process:** + - Amendment proposals will be reviewed by the Constitutional Committee for + compliance with the existing governance framework. + - The Committee may provide recommendations or request revisions before the + proposal is put to a vote. + +3. **Voting on Amendments:** + - Amendments to the Constitution or guardrails require a supermajority ( + e.g., 67% of the active voting stake) to be approved. + - The results of the vote will be binding, and approved amendments will be + implemented as specified. + +4. **Implementation of Amendments:** + - Once an amendment is approved, it will be incorporated into the governance + framework. + - Any necessary updates to documentation, processes, or smart contracts will + be executed to reflect the amendment. + +5. **Communication of Changes:** + - All amendments and updates to the governance framework will be + communicated to the Cardano community through official channels. + - Educational resources may be provided to help the community understand the + implications of the changes. + +#### Section 3: Emergency Governance Actions + +1. **Definition of Emergencies:** + - An emergency is defined as any situation that poses an immediate threat to + the security, stability, or functionality of the Cardano Blockchain. + - Examples include severe security vulnerabilities, catastrophic failures, + or unforeseen critical issues. + +2. **Emergency Action Procedures:** + - In the event of an emergency, the Constitutional Committee may expedite + the governance process to address the issue. + - Emergency actions may include temporary changes to protocol parameters, + suspension of certain governance processes, or other measures necessary to + mitigate the threat. + +3. **Community Notification:** + - The Cardano community must be notified immediately of any emergency + governance actions, including the rationale, expected impact, and + duration. + - A full report on the emergency and the actions taken must be provided once + the situation is resolved. + +4. **Review and Ratification:** + - Any emergency actions taken must be reviewed and ratified by the community + through a governance vote as soon as possible. + - If the community does not ratify the emergency actions, they must be + rolled back, and alternative solutions must be proposed. + +5. **Post-Emergency Evaluation:** + - 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. + - The findings of this evaluation may inform updates to the emergency + governance procedures. + +### 5. COMMUNITY ENGAGEMENT AND EDUCATION + +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: + +#### Section 1: Governance Education Programs + +1. **Workshops and Webinars:** + - 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. + - These sessions will be open to all community members and will be recorded + and made available online. + +2. **Educational Resources:** + - Comprehensive educational materials, including guides, FAQs, and video + tutorials, will be developed to explain the governance processes in + detail. + - These resources will be accessible through the official Cardano website + and other community platforms. + +3. **Onboarding for New Participants:** + - 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. + - This program will include step-by-step instructions on how to participate + in governance actions, delegate voting power, and submit proposals. + +#### Section 2: Community Outreach + +1. **Regular Updates:** + - The Cardano governance bodies will provide regular updates to the + community on ongoing governance actions, upcoming votes, and other + relevant developments. + - Updates will be shared through multiple channels, including the official + Cardano blog, social media, and community forums. + +2. **Open Forums:** + - Open forums and discussion groups will be established to facilitate + dialogue between community members and governance bodies. + - These forums will provide a platform for community members to ask + questions, share ideas, and provide feedback on governance matters. + +3. **Community Ambassadors:** + - A network of community ambassadors will be established to represent + different regions and demographic groups within the Cardano ecosystem. + - Ambassadors will play a key role in disseminating information, gathering + feedback, and ensuring that diverse perspectives are considered in + governance decisions. + +4. **Surveys and Polls:** + - Regular surveys and polls will be conducted to gauge community sentiment + on various governance issues and proposals. + - The results of these surveys will be used to inform decision-making and + prioritize governance actions. + +#### Section 3: Transparency and Accountability + +1. **Public Reporting:** + - All governance bodies, including the Constitutional Committee, dReps, and + SPOs, will publish regular reports on their activities, decisions, and the + outcomes of governance actions. + - These reports will be made available to the entire Cardano community to + ensure transparency and accountability. + +2. **Audit and Oversight:** + - Independent audits of the governance processes and financial management ( + e.g., Treasury withdrawals) will be conducted periodically. + - The results of these audits will be published and any recommendations for + improvement will be considered and implemented as appropriate. + +3. **Feedback Mechanisms:** + - Formal mechanisms will be established to allow community members to + provide feedback on the performance and conduct of governance bodies. + - This feedback will be reviewed regularly, and governance bodies will be + expected to address any issues or concerns raised by the community. + +### 6. CONCLUSION + +The implementation of CIP-1694 and the ongoing development of the Cardano +governance framework represent a significant step toward a truly decentralized, +community-driven ecosystem. By adhering to the principles of transparency, +inclusivity, and accountability, the Cardano community can ensure the long-term +success and sustainability of the blockchain. + +As the governance framework continues to evolve, the active participation and +engagement of all stakeholders will be crucial. Through collaboration, +education, and a shared commitment to the principles outlined in the Cardano +Constitution, the community can achieve its vision of a decentralized, fair, and +resilient blockchain ecosystem. + +This document, along with the Cardano Constitution, shall serve as a living +framework, continuously adapted and improved in response to the needs and +aspirations of the Cardano community. \ No newline at end of file diff --git a/CommunityDrafts/AlfonsoTenets.md b/CommunityDrafts/AlfonsoTenets.md new file mode 100644 index 0000000..04e353f --- /dev/null +++ b/CommunityDrafts/AlfonsoTenets.md @@ -0,0 +1,36 @@ +# 10 Crucial Tenets/Protections to Append to Cardano’s Constitution + +1. **Updating the Ledger** + - **Guaranteed Inclusion**: All valid ledger state transitions (transactions) shall be included in a block, in a time no longer than `` seconds after being broadcasted to the network ``. + - **Tier-assignment and Expediency**: Transactions will be assigned a tier, proportional to an attached ADA fee, and where the number of tiers is determined by the protocol. For a given tier, transactions shall be included in a block in an order determined by their age since broadcasting (older transactions first). + +2. **Transaction Creation** + - **Predictability**: The specific outcomes of any potential transaction, the required fee costs to include it in the ledger, and whether it’s a valid or invalid ledger transition, shall be knowable by the issuer before broadcasting it. + +3. **Access, Usage, and Deployment of Transactions and Logic** + - **Pseudonymity**: Users of the chain shall not be required to identify themselves or prove their worthiness before being able to access or use the chain. + - **Fungibility of Actors**: Any information gatherable from, or broadcasted by users using the chain, shall not compromise the fungibility of actors. This means any two users should be as indistinguishable as possible from one another when looking at how they interact with the chain, or the chain itself. + - **Censoring**: The chain shall not censor the deployment of valid transactions of any type or logic in the form of smart contracts, as long as they don’t compromise any of the other tenets listed here. + +4. **Guaranteed Ownership Over Assets and Data** + - **Ownership**: Ownership shall be defined as the exclusive and non-revocable ability of an individual or collection of individuals to unilaterally spend, move, revoke, or create assets and data. Ownership shall be enforced/enabled via secure cryptographic means. + +5. **Privacy** + - **Frugality**: Actors in the space will minimize the amount of data and information collected from users, beyond the minimum necessary to perform their duties or offer their services. + - **Disclosure and Consent**: Users shall be promptly and properly informed of any data a service requests, or may gather from them, before such gathering happens. This gathering shall only happen with the express consent of users. + +6. **Conservation of Value (ADA) and Information (Transaction History)** + - **Value**: There will be no issuance of any further ADA tokens beyond the expected 45 billion units. ADA will always be an acceptable currency to pay for fees and engage in on-chain governance. + - **Information**: The entire transaction history of the Cardano blockchain shall be preserved somewhere, in perpetuity, so that any actor has the means to access it. Furthermore, the chain will guarantee the cryptographic verification of all transactions since the Genesis block to the present day, requiring only the knowledge of the information contained in the Genesis block (Ouroboros Genesis). + +7. **Optimization of Resources** + - **Efficiency**: As a default, Cardano shall maximize efficiency in operations, processes, logic, resource consumption. Non-efficient alternatives must be properly justified/argued for before being implemented, on a case-by-case basis. + +8. **Trust in Governance** + - **Legitimacy**: Cardano shall strive to achieve and maintain sufficient levels of decentralization and representation in order to preserve the legitimacy of governance. No key governance actions will happen without the express consent of a majority of ADA holders, and other key actors when relevant, such as stake pools, institutions, the constitutional committee. + +9. **Compliance and Regulations** + - **Opt-in Conditional Logic**: Cardano shall offer optional compliance mechanisms for those who wish to use the Cardano blockchain while abiding by further regulations and requirements; which we’ll refer to here as—additional conditional logic—that requires providing personal or otherwise additional data beyond the typical necessary to engage with the chain (that necessary to prove ownership of assets or data, or consent by a third party whose assets or data are being managed, usually in the form of private cryptographic keys). But these shall never be implemented at the ledger level, which will remain agnostic to particular regulations, permissioned usage, and other forms of additional conditional logic—such as KYC, AML, and others. + +10. **Non-secrecy** + - **Transparency and Access**: Cardano is a public permissionless blockchain, and will therefore make the entire history of the chain auditable and accessible by any party. Furthermore, Cardano shall strive to maximize levels of transparency and mechanisms for accountability in governance. Transactions containing private or obfuscated information are still allowed, but are nonetheless recorded on the history of the chain. \ No newline at end of file diff --git a/CommunityDrafts/CardanoFoundation.md b/CommunityDrafts/CardanoFoundation.md new file mode 100644 index 0000000..8cce67e --- /dev/null +++ b/CommunityDrafts/CardanoFoundation.md @@ -0,0 +1,324 @@ + +# Proposal for Constitution of the Cardano Blockchain + +## Table of Contents + +- [Preamble](#preamble) +- [Article I. Defined Terms](#article-i-defined-terms) +- [Article II. Applicability](#article-ii-applicability) +- [Article III. Tenets and Guardrails](#article-iii-tenets-and-guardrails) + - [Section 1: Purpose and Scope](#section-1-purpose-and-scope) + - [Section 2: Cardano Tenets](#section-2-cardano-tenets) + - [Section 3: Blockchain Neutrality](#section-3-blockchain-neutrality) + - [Section 4: Guardrails](#section-4-guardrails) +- [Article IV. Cardano Blockchain Parameters](#article-iv-cardano-blockchain-parameters) + - [Section 1: Economic Parameters](#section-1-economic-parameters) + - [Section 2: Network Parameters](#section-2-network-parameters) + - [Section 3: Governance Parameters](#section-3-governance-parameters) + - [Section 4: Technical and Security Parameters](#section-4-technical-and-security-parameters) +- [Article V. Cardano Blockchain Governance](#article-v-cardano-blockchain-governance) + - [Section 1: Governance Model](#section-1-governance-model) + - [Section 2: Governance Bodies](#section-2-governance-bodies) + - [Section 3: Governance Actions](#section-3-governance-actions) + - [Section 4: Voting](#section-4-voting) + - [Section 5: Voting Thresholds and Quorums](#section-5-voting-thresholds-and-quorums) +- [Article VI. The Cardano Community](#article-vi-the-cardano-community) +- [Article VII. Constitutional Committee](#article-vii-constitutional-committee) + - [Section 1: Constitutional Committee Function and Participation](#section-1-constitutional-committee-function-and-participation) + - [Section 2: Constitutional Committee Composition](#section-2-constitutional-committee-composition) + - [Section 3: Election of Constitutional Committee Members](#section-3-election-of-constitutional-committee-members) + - [Section 4: State of No-Confidence](#section-4-state-of-no-confidence) + - [Section 5: Constitutional Committee Voting and Conduct](#section-5-constitutional-committee-voting-and-conduct) + - [Section 6: Community Support](#section-6-community-support) + - [Section 7: Compensation](#section-7-compensation) +- [Article VIII. Delegated Representatives](#article-viii-delegated-representatives) + - [Section 1: DRep Governance Function](#section-1-drep-governance-function) + - [Section 2: DRep Registration](#section-2-drep-registration) + - [Section 3: DRep Selection](#section-3-drep-selection) + - [Section 4: DRep Compensation](#section-4-drep-compensation) +- [Article IX. Stake Pool Operators](#article-ix-stake-pool-operators) + - [Section 1: SPO Governance Function](#section-1-spo-governance-function) + - [Section 2: Hard Fork Initiation](#section-2-hard-fork-initiation) +- [Article X. Net Change Limit, Cardano Budget and Treasury Withdrawals](#article-x-net-change-limit-cardano-budget-and-treasury-withdrawals) + - [Section 1: Net Change Limit Amount](#section-1-net-change-limit-amount) + - [Section 2: Cardano Budget](#section-2-cardano-budget) + - [Section 3: Treasury Withdrawals](#section-3-treasury-withdrawals) + +## Preamble + +Recognizing that the three pioneering entities, Input-Output Hong Kong, Emurgo, and the Cardano Foundation, in collaboration with the Cardano Community, have fostered the emergence of the Cardano Blockchain, laying the foundation for a decentralized digital infrastructure that empowers individuals and promotes collaboration and innovation. Their efforts have shaped a vibrant and diverse environment of individuals and organizations where anyone can choose to contribute to the Cardano Ecosystem's growth and success. + +Recognizing that the Cardano Blockchain exists within a decentralized ecosystem of blockchain technology, smart contracts, and community governance that is committed to improving economic, political, and social systems globally. The Cardano Blockchain offers a foundational infrastructure which empowers individuals and communities to manage their identity, value, and governance, fostering the emergence of decentralized applications, businesses, and networks. + +Acknowledging that the Cardano Ecosystem has expanded significantly and is operated in a decentralized and permissionless manner, further strengthening the resilience and autonomy of the Cardano Blockchain. + +Considering that as the Cardano Ecosystem continues to grow, its governance model needs to similarly adapt and evolve to reflect the principles of decentralization, community involvement, accountability, inclusivity, and collaboration as a foundation of self-governance and new approaches to human interaction and collaboration. + +Recognizing the need for a more robust and adaptable governance framework that utilizes blockchain technology to establish on-chain governance wherever reasonably possible and beneficial, the Cardano Community hereby establishes this Cardano Constitution including its technical Guardrails that provide a set of safeguards for permissible Governance Actions. The Cardano Constitution sets out the principles for the operation and governance of the Cardano Blockchain as a foundation for anyone to contribute to the development of the Cardano Ecosystem. + +Pursuing a culture of trust and collaboration that ensures decisions are made in the best interest of the Cardano Ecosystem in accordance with the principles of transparency, openness, and accountability, the Cardano Community strives to work together towards the continuous improvement, growth, and success of the Cardano Blockchain and Cardano Ecosystem. + +Recognizing the importance of providing SPOs and all Ada Holders with an opportunity to contribute to the governance of the Cardano Blockchain to foster a diversity of viewpoints. + +Acknowledging the freedom of choice of Ada Holders to contribute to the governance of the Cardano Blockchain independently from any organization or collaborative body. + +Recognizing the nature of the Cardano Blockchain as a construct ultimately implemented by software code and hence the critical role of and expectations towards its developers and engineers in upholding and implementing this Constitution. + +Recognizing the essential role of the Constitutional Committee in upholding this Constitution and the importance of DReps as representatives of Ada Holders. + +Recognizing the necessity of a framework for sustainable, accountable, and effective utilization of the resources available to the Cardano Community in the Cardano Treasury. + +Recognizing the right of the Cardano Community to form new collaborative bodies between them to take on the challenges facing the Cardano Ecosystem. + +## Article I. Defined Terms + +1. **Active block production stake**: Means, in relation to SPOs, the number of Lovelace which is actively delegated to the SPO for the purpose of block production. +2. **Active voting stake**: Refers to the total number of Lovelace which is considered active, based upon required voting activity and registration to vote as specified in the Guardrails, and counted for the purposes of determining a vote. +3. **ada**: Refers to the cryptocurrency which is native to the Cardano Blockchain. +4. **Ada Holders**: This refers to persons who directly or indirectly control the private key(s) to ada token(s). +5. **Cardano Blockchain**: A public, proof-of-stake, peer-to-peer, distributed ledger system operating under the name "Cardano". +6. **Cardano Community**: Refers to all Ada Holders. +7. **Cardano Ecosystem**: Refers to all the participants conducting activity on the Cardano Blockchain, including but not limited to SPOs, DReps, the Cardano Community, and the Constitutional Committee. +8. **Cardano Treasury**: The Cardano treasury is a decentralized on-chain ada management system that holds and releases ada received from transaction fees and monetary expansion. +9. **Constitutional Committee**: Means the governing body responsible for ensuring that the Constitution's principles are upheld and enforced. +10. **Delegator**: An Ada Holder, who has delegated their stake to a stake pool (for block production), and/or to a DRep (for governance). +11. **DRep or Delegated Representative**: A duly registered Delegated Representative, who votes on Governance Actions. +12. **Governance Action**: Means an action to record information on, take action in relation to or modify the parameters of the Cardano blockchain which is submitted for voting by eligible voting bodies on the Cardano blockchain. +13. **Governance action proposals**: Means a proposal for a prospective Governance Action which is submitted by a Cardano Community member or Constitutional Committee member for discussion or consideration by the Cardano Community. +14. **Governance Body**: Means an organization or group with authority to vote on a Governance Action as described in the Constitution, currently consisting of DReps, the Constitutional Committee, and SPOs. +15. **Guardrail**: Guardrails refer to conditions and parameters required to maintain the functionality, security, and performance of the Cardano Blockchain, some of which, but not all, are directly implemented on the Cardano Blockchain. +16. **Guardrails Script**: The Plutus script that is recorded on-chain with the constitution, and that enforces the automatable guardrails when a Governance Action is submitted on chain. +17. **Lovelace**: Means a unit of ada, with one million Lovelace to every one ada. +18. **Low Cost Attack**: An attack that is deemed to require too little ada, effort, or other resources to execute. Acceptable values for these metrics need to be determined. +19. **Mainnet environment**: Means the base layer of the Cardano Blockchain protocol which is live and operational. +20. **Net Change Limit Amount**: Means the limit in ada by which the Cardano Treasury shall not change in a given period. +21. **Net Change Limit Period**: This refers to the period comprising 73 epochs (approximately one calendar year) over which a Net Change Limit Amount is in effect. +22. **On-chain and off-chain**: "On-chain" refers to actions which are reflected on the Cardano Blockchain. "Off-chain" refers to actions which are not reflected on the Cardano Blockchain, but are governed by this Constitution. +23. **Parameters**: Means settings and limits for the implementation of the Cardano Blockchain which are specified in the Constitution. +24. **Protocol**: Means the algorithms, rules, and procedures governing the operation of the Cardano Blockchain. +25. **SDR**: Means "Special Drawing Rights", which refers to an international reserve asset based on the value of a basket of world currencies created by the International Monetary Fund. References to “fiat” shall constitute references to SDR. +26. **SPO**: Stake Pool Operator, who runs a Cardano block-producing node. +27. **Vote**: Refers to a decision expressed on the Cardano Blockchain on proposed Governance Actions. + +## Article II. Applicability + +1. This Constitution shall apply to all Cardano Community members, DReps, SPOs, and Constitutional Committee members insofar as they interact with the Cardano Blockchain and with each other in the Cardano Ecosystem. +2. While the Preamble provides the rationale for this Constitution, it shall be considered non-binding for the purpose of assessing the constitutionality of proposed Governance Actions. +3. This Constitution shall be interpreted to give effect to the tenets set out in Article III below. + +## Article III. Tenets and Guardrails + +### Section 1: Purpose and Scope + +The tenets in this Article are intended to guide all actors in the Cardano Ecosystem, including the Cardano Constitutional Committee, SPOs, DReps, and Ada Holders. All Governance Actions shall be evaluated in accordance with these tenets. + +### Section 2: Cardano Tenets + +1. The Cardano Blockchain shall maintain its public and permissionless nature. +2. The Cardano Blockchain governance processes shall be accessible, transparent, and adaptable. +3. Cardano Blockchain development and operation shall prioritize security, reliability, and resilience, including but not limited to avoiding single points of failure or dependency. +4. The Cardano Ecosystem shall strive for financial stability. +5. The total supply of ada shall not exceed 45,000,000,000 ada (45,000,000,000,000,000 Lovelace). +6. To assure protection of value and information, the Cardano Blockchain shall strive for post-quantum security, decentralized storage, and robust key management approaches. +7. The Cardano Ecosystem shall strive for the decentralization of the Cardano Blockchain including scalable on- and off-chain solutions that consider throughput, sharding, settlement, and dynamic pricing without undue trade-offs with accessibility, economic sustainability, security, and performance. +8. The Cardano Blockchain shall pursue long-term sustainability and viability, as reflected in characteristics such as fairness, neutrality, sustainability, robust governance, promotion of decentralized identity, collaboration, and participation by the Cardano Community. +9. The Cardano Blockchain shall be developed in an open-source, collaborative methodology to promote security, resilience, and accessibility and to mitigate centralization risks, and shall be available at all times under a permissive open-source license. +10. All participants in the Cardano Ecosystem shall be treated fairly and their interests accounted for when considering Governance Actions. +11. The Cardano Blockchain should foster interoperability and access to other blockchains. +12. The Cardano Blockchain shall not unnecessarily spend on-chain resources. +13. The Cardano Blockchain shall promote efficient design and utilization of hardware resources. +14. The Cardano Blockchain shall recognize, record, and reward contributions to its operations through fair and appropriate tokenomics. + +### Section 3: Blockchain Neutrality + +1. Transactions on the Cardano Blockchain shall not be slowed down or censored, and should be processed expediently for their intended purpose. +2. The Cardano Blockchain shall not lock in ada without the Ada Holder's consent. +3. The Cardano Blockchain's design should facilitate a cost-effective, accessible, and predictable transaction cost model. +4. Anyone desiring to develop and deploy applications on the Cardano Blockchain should not unreasonably be prevented from doing so. The Cardano Community should promote features to assist in developing and deploying applications. + +### Section 4: Guardrails + +1. The Cardano Blockchain shall operate in accordance with the Guardrails as set forth in Appendix I to this Constitution. The Guardrails reflect the current best technical understanding of the Cardano Blockchain and shall remain open to change based on new information, in accordance with this Constitution. +2. The Guardrails shall enable the Cardano Blockchain to operate in a secure and sustainable way by avoiding disruptions, security, and performance issues. They shall apply to the Cardano Blockchain mainnet environment, and are not intended to apply to test environments or to other blockchains that use the Cardano Blockchain software. +3. The parameters of the Cardano Blockchain set out in the Guardrails shall be read together and shall not be considered in isolation. Known interactions between parameters are noted in the Guardrails. +4. The Guardrails apply to Governance Actions on the Cardano Blockchain, including but not limited to protocol parameter changes and Cardano Treasury withdrawals. The Guardrails cover both essential and intrinsic limits on protocol parameters and settings, and are based on recommendations derived from experience, measurement, and governance objectives. +5. Where technically possible, the Guardrails shall be automated and enforced through an on-chain script or built-in ledger rules. +6. The Guardrails may be amended pursuant to Governance Actions that satisfy the applicable voting threshold (if any). Generally, amendments to the Guardrails set out in Appendix I shall be deemed to be an amendment to the Constitution itself and be subject to voting thresholds required for a New Constitution or Guardrails Script Governance Action. +7. The Guardrails shall be published with a clear version number and date of effect denoted on the first page of the Guardrails. +8. In the event of inconsistencies between the Guardrails and the implemented parameters on the Cardano Blockchain, the implemented parameters shall prevail. Members of the Constitutional Committee shall seek to reconcile such inconsistencies through the suggestion or encouragement of an appropriate Governance Action. + +## Article IV. Cardano Blockchain Parameters + +1. The Parameters of the Cardano Blockchain may be changed by ratifying the necessary Governance Action in accordance with this Constitution. +2. The Parameters fall into the following categories: economic, network, governance, technical, and security parameters. Any proposed changes to the Parameters shall be assessed according to the preamble and tenets of this Constitution as well as the main goals outlined below and shall be based on diligent impact assessments and technical analysis that makes transparent any material trade-offs involved. + +### Section 1: Economic Parameters + +The main goals of the economic parameters of the Cardano Blockchain are to enable long-term economic sustainability for the Cardano Blockchain, ensure that SPOs are adequately rewarded for maintaining the Cardano Blockchain, ensure that Ada Holders are adequately rewarded for using their ada in constructive ways, and balance economic incentives for different Cardano Ecosystem participants. + +### Section 2: Network Parameters + +The main goals of the network parameters of the Cardano Blockchain are to match the available Cardano Blockchain network capacity to current or future traffic demands and balance traffic demands for different Cardano Ecosystem participants. + +### Section 3: Governance Parameters + +The main goals of the governance parameters of the Cardano Blockchain are to ensure stability of the governance system of the Cardano Blockchain and maintain a system of governance pursuant to this Constitution. + +### Section 4: Technical and Security Parameters + +The main goals of the technical and security parameters of the Cardano Blockchain are to ensure the security of the Cardano Blockchain network in terms of decentralization, protection against Sybil and 51% attacks, and protection against denial of service attacks. The technical and security parameters also govern changes to smart contract execution limits and associated cost models. + +## Article V. Cardano Blockchain Governance + +### Section 1: Governance Model + +1. The Cardano Blockchain shall use a model of participatory governance under which Ada Holders may make proposals for Governance Actions and vote on such proposals, pursuant to the checks and balances of this Article V. +2. The process for participating in, submitting, and voting on Governance Actions shall be transparent and protected from manipulation. + +### Section 2: Governance Bodies + +Governance of the Cardano Blockchain shall be conducted through three Governance Bodies: DReps, SPOs, and the Constitutional Committee. These Governance Bodies shall provide checks and balances for the Cardano Blockchain. + +### Section 3: Governance Actions + +1. Ada Holders may at any time propose Governance Action on the Cardano Blockchain. This Constitution currently foresees the following Governance Actions: + - Motion of No-Confidence, to reject/forfeit/discard the current Constitutional Committee until a replacement is elected/designated; + - Update Committee and/or threshold and/or term, to change the members or threshold or term of Constitutional Committee members, or any combination thereof; + - New Constitution or Guardrails Script, to amend the Constitution including the Guardrails or update or remove the guardrails script; + - Hard-Fork Initiation, to trigger a non-backwards compatible upgrade of the Cardano Blockchain software; + - Protocol Parameter Change, to trigger one or more changes to updatable parameters of the Cardano Blockchain; + - Treasury Withdrawal, to withdraw funds from the Cardano Treasury; + - Info Actions, to allow Cardano Community sentiment to be gauged without committing to any protocol changes. +2. Governance Action proposals shall be in a standardized and legible format and contain sufficient rationale for the proposal, including, as relevant, any suggested changes to the Cardano Blockchain. Where originally written in a language other than the language of this Constitution, Governance Action proposals shall be accompanied by a translation of the Governance Action proposal to the language of this Constitution (English). +3. Treasury withdrawal Governance Actions shall, in particular, include information which specifies whether the contemplated Treasury withdrawal is included within the Cardano Budget or not. +4. Sufficient rationale shall mean that the proposal demonstrates how the proposed Governance Action achieves the intended purpose. Supporting documentation, clear and understandable language and structure, including but not limited to title, an abstract, reason for the proposal, and relevant supporting links, are indicators of sufficient rationale. +5. Governance Action proposals shall include a URL and a hash digest derived from the content pointed to by the URL. An Action shall be deemed constitutional only if the content can be independently verified to produce the same hash digest. +6. Governance Actions for Hard Fork Initiation and Protocol Parameter Change shall undergo sufficient technical review and scrutiny, as set out in the Guardrails. Such Governance Actions shall not endanger the security, functionality, or performance of the Cardano Blockchain. +7. Proposed Governance Actions shall be voted on by the applicable Governance Bodies in order to be ratified and later enacted on-chain as applicable. +8. Info Actions shall be voted on by DReps, SPOs, and the Constitutional Committee. Info Actions have no effect other than to record the outcome of such a vote on the Cardano Blockchain. Info Governance Actions are expressions of Cardano Community sentiment and do not require a “Yes” outcome in order to pass. + +### Section 4: Voting + +1. Decisions on proposed Governance Actions shall be made by the Constitutional Committee, SPOs, and DReps through the voting process in accordance with the requirements of this Constitution and the Guardrails. +2. DReps and SPOs shall have voting power in proportion to the Lovelace delegated to them. One Lovelace shall equal one vote. +3. Constitutional Committee members shall each have one vote. +4. Votes may be cast as "Yes", "No", or "Abstain". + +### Section 5: Voting Thresholds and Quorums + +1. Voting thresholds for each Governing Body which are in effect as at the date of first issue of this Constitution have been set in the Conway genesis file and can be changed by a Protocol Parameter Updates Governance Action. Such a Protocol Parameter Update Governance Action shall not constitute an amendment to this Constitution. +2. The voting thresholds shall not fall outside of the following ranges: + - Constitutional Committee: Votes on all Governance Actions shall pass at a threshold set within the range of 51% - 100%. As at the date of first issue of this Constitution, this threshold is 66.67% of Constitutional Committee members. + - DReps and SPOs: Voting threshold ranges as specified by the “Guardrails to Voting Thresholds” at 3.6.4 of the Guardrails. +3. The current voting threshold applicable to a Governance Action by a particular Governance Body may be found by consulting the parameters currently implemented on-chain. +4. In addition to a Constitutional Committee vote where required by this Constitution, the following quorums shall apply to the Governance Actions: + - Parameter changes shall require an affirmative SPO vote and an affirmative DRep vote in order to pass. + - Hard fork initiations shall require an affirmative SPO vote and an affirmative DRep vote in order to pass. + - Motion of no confidence and update committee/threshold shall require an affirmative SPO vote and an affirmative DRep vote in order to pass. + - Treasury withdrawals shall require an affirmative DRep vote in order to pass. + - Info Governance Actions shall require an SPO vote and a DRep vote, however, no outcome is required as these Governance Actions are used only to gauge and record Cardano Community sentiment. + - Constitutional amendments shall require an affirmative DRep vote in order to pass. +5. All other Governance Actions shall require an affirmative DRep vote in order to pass. + +## Article VI. The Cardano Community + +1. No formal membership shall be required for Cardano Community members to engage in the Cardano Ecosystem and the governance of the Cardano Blockchain. +2. Cardano Community members are expected to support and uphold the provisions of this Constitution and to resolve disputes in a fair, constructive, and transparent manner. +3. The Cardano Community shall support the creation, maintenance, and ongoing administration of off-chain governance processes as may be necessary to give effect to this Constitution and to ensure that there is awareness of and an opportunity to debate and shape Governance Actions for the Cardano Blockchain. +4. The Community is encouraged to collaborate in developing, maintaining, and building applications for the Cardano Blockchain. + +## Article VII. Constitutional Committee + +### Section 1: Constitutional Committee Function and Participation + +1. The Constitutional Committee is established as an independent body to ensure that all proposed Governance Actions are consistent with the provisions of this Constitution, before they are voted on and implemented. +2. No Governance Actions, other than a "Motion of No-Confidence" or "Update Constitutional Committee/Threshold" may be implemented on-chain unless the Constitutional Committee shall have first affirmed through an on-chain vote that such proposal does not violate this Constitution. + +### Section 2: Constitutional Committee Composition + +1. Constitutional Committee members shall be composed of a number as specified by the Cardano Guardrails from time to time, which shall in any case be an uneven number no less than 3 and no more than 9, to avoid a voting deadlock within the Constitutional Committee. They should have the required technical and/or governance expertise to ensure compliance with this Constitution. +2. Members of the Constitutional Committee shall serve terms as consistent with the Guardrails. +3. To assure continuity in the operation of the Constitutional Committee, the terms for Constitutional Committee members shall be staggered. + +### Section 3: Election of Constitutional Committee Members + +1. The Cardano Community shall establish and publish a process from time to time for election of members of the Constitutional Committee consistent with the requirements of the Guardrails. +2. If no new Constitutional Committee is elected prior to the end of the term of the current Constitutional Committee, or if the Constitutional Committee shall ever fail to meet the requirements of Section 3(1) above, the current Constitutional Committee shall submit a Governance Action to elect new member(s) as may be required to replace any outgoing Constitutional Committee members or achieve the required number of Constitutional Committee members. + +### Section 4: State of No-Confidence + +The Constitutional Committee shall be in one of the following two states at all times: a state of confidence or a state of no-confidence. In a state of no-confidence, members of the then standing Constitutional Committee must either be reinstated or replaced using the "Update committee/threshold" Governance Action before any other on-chain Governance Action may proceed. + +### Section 5: Constitutional Committee Voting and Conduct + +1. Constitutional Committee members shall publish reasonable information on their processes and each decision made shall be published. +2. Each Constitutional Committee member shall have one vote. +3. When rejecting a Governance Action, each member of the Constitutional Committee shall set forth the rationale for its vote including references to the applicable provisions of this Constitution. +4. The Constitutional Committee members may make recommendations to the Cardano Community to improve proposals which they have rejected. +5. The Constitutional Committee shall establish and publish for itself a code of conduct and shall adopt such policies and procedures, including any ethical guidelines, as the Constitutional Committee deems necessary. + +### Section 6: Community Support + +The Cardano Community shall support the creation, maintenance, and ongoing administration of tools as may be necessary and appropriate for the Constitutional Committee to perform its constitutional functions. + +### Section 7: Compensation + +Constitutional Committee members may be compensated for their role as Constitutional Committee members, provided that such compensation is foreseen by the Cardano Budget, is publicly disclosed, and is limited in amount to cover actual and reasonable costs incurred in fulfilling the role. + +## Article VIII. Delegated Representatives + +### Section 1: DRep Governance Function + +1. Ada Holders can directly vote on Governance Actions by registering as DReps themselves or by delegating their voting rights to other registered DReps. +2. DReps shall have voting power equal to the number of Lovelace delegated to them. +3. DReps are encouraged to adopt, publish, and maintain codes of conduct, including ethical guidelines, to govern their activities as DReps. + +### Section 2: DRep Registration + +1. Any Ada Holder shall be allowed to register as a DRep. A DRep may act in the interest of one or more Ada Holders. +2. Any Ada Holder shall be allowed to delegate their voting stake to one or more registered DReps, including themselves. +3. Ada Holders shall be allowed to change the delegation of their voting stake at any time. + +### Section 3: DRep Selection + +The Cardano Community is expected to support the creation, maintenance, and ongoing administration of tools to enable Ada Holders to select DReps for their voting delegation. + +### Section 4: DRep Compensation + +DReps may be compensated for their efforts. They must publicly disclose any compensation received in connection with their activities as a DRep. + +## Article IX. Stake Pool Operators + +### Section 1: SPO Governance Function + +1. SPOs shall function as an additional check on specified Governance Actions, where they shall vote separately from DReps as set forth in the Guardrails. +2. SPOs shall publicly disclose if they are simultaneously voting as a DRep on the same Governance Actions. + +### Section 2: Hard Fork Initiation + +1. As the operators of the nodes of the Cardano Blockchain, SPOs shall vote on Hard Fork Initiation process pursuant to this Constitution and the Guardrails. +2. SPOs shall consider the readiness of the Cardano Blockchain when casting their votes on Hard Fork Initiation. + +## Article X. Net Change Limit, Cardano Budget and Treasury Withdrawals + +### Section 1: Net Change Limit Amount + +1. A Net Change Limit Amount may be proposed by any Cardano Community member for every Net Change Limit Period following the preceding Governance Action establishing the preceding Net Change Limit Amount. +2. Net Change Limit Amounts shall be proposed as an Info Governance Action and be subject to voting in accordance with applicable thresholds. DReps shall approve a Net Change Limit Amount for each Net Change Limit Period. +3. If no new Net Change Limit Amount is approved for a Net Change Limit Period, the previous Net Change Limit Amount shall continue to apply. + +### Section 2: Cardano Budget + +1. The Cardano Budget comprises the resources reasonably necessary for ongoing operations, maintenance, and development of the Cardano Blockchain for each Net Change Limit Period. +2. The Cardano Budget may also include the resources reasonably necessary for the administration, management, contracting, third-party audit, and assurance of such positions as well as Cardano governance orchestration, including compensation for the Constitutional Committee members. +3. The Cardano Community shall propose a Cardano Budget for each Net Change Limit Period, which shall take the form of an Info Governance Action and be subject to voting in accordance with applicable thresholds. +4. Any Cardano Community member, including any collaborative bodies which Cardano Community members may form, may propose a Cardano Budget. +5. The total amount of the Cardano Budget shall not exceed the applicable Net Change Limit Amount for the corresponding Net Change Limit Period. + +### Section 3: Treasury Withdrawals + +1. Subject to the requirements set out in this Constitution and the Guardrails, anyone may propose a Cardano Treasury withdrawal Governance Action. +2. No Cardano Treasury withdrawal Governance Action shall be permitted unless a Cardano Budget has been approved and a Net Change Limit is in force. +3. Any ada withdrawn for the Cardano Budget shall not be delegated to DReps and SPOs or otherwise utilized to influence Cardano Blockchain governance. This does not apply to other Cardano Treasury withdrawals. +4. Any ada withdrawn pursuant to a Cardano Treasury withdrawal Governance Action shall exclusively be used for the purpose declared in the Governance Action. +5. Any ada withdrawn through a Cardano Treasury withdrawal shall be administered and managed pursuant to financial industry best practices. \ No newline at end of file diff --git a/CommunityDrafts/ColinSmith.md b/CommunityDrafts/ColinSmith.md new file mode 100644 index 0000000..fc549ec --- /dev/null +++ b/CommunityDrafts/ColinSmith.md @@ -0,0 +1,51 @@ + +# Preamble + +The Cardano Blockchain gives everyone access to a decentralized consensus mechanism where they can participate in a trustless, transparent, and immutable environment if they so choose. Anyone can participate. Anyone can be a Stake Pool Operator. + +## Section 1: General Rules + +There will be no unenforceable rules in the Constitution. If something cannot be controlled and settled by a smart contract in a trustless manner, it must be handled by a Members Based Organization (MBO). This Constitution governs a Blockchain. If you want a rule, make a CIP. + +*Process for making a CIP* + +## Section 2: Budget + +The total Cardano Budget shall be determined algorithmically. (I put a framework for this in ICC civics) + +- *Algorithm for determining total budget here* +- *Mechanic for splitting budget distributions to MBOs here* + +Distributions from the treasury require on-chain voting by Delegated Representatives (DReps) with voting power determined by delegated stake. Different actions can have different voting rules and stake calculations if defined by a CIP. + +- *Algorithms that change voting power/weight go here* + +Cardano Treasury Distributions must be routed through and governed by a Members Based Organization that meets the following requirements: + +- *Requirements* + +Cardano Treasury actions and distributions are meant to become more decentralized over time. When a region/group meets these requirements, it can choose to become its own MBO and will be algorithmically appropriated a portion of the treasury: + +- A specified percentage of transaction volume +- A set level of SPO delegation to associated Stake Pools +- An MBO meeting the requirements delineated in Section 2 +- *Other requirements* + +## Stake Pool Operators + +Anyone can be an SPO as long as they perform to standards. Stake Pool Operators can have their keys removed and be removed by a vote of 51% of SPOs if: + +- They fail to produce 2 or more blocks in a timely and effective manner as defined by: + - *Definitions here* +- They participate in a scheme that allows third-party software to scan the mempool and build blocks with reordered transactions. +- *Other reasons that can be added* + +## Delegated Representatives + +Delegated Representatives are governed by these rules: + +- *Process to become a DRep:* + +DReps shall be able to vote in only one region/group as defined by Section 2 Part 4 for treasury disbursements. + +- *Expanded list…* \ No newline at end of file diff --git a/CommunityDrafts/Intersect.md b/CommunityDrafts/Intersect.md new file mode 100644 index 0000000..c1768c4 --- /dev/null +++ b/CommunityDrafts/Intersect.md @@ -0,0 +1,935 @@ + +# CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION + +## FRAMING NOTES + +*These Framing Notes Are Not Considered To Be A Part Of This Constitution* + +The Cardano Blockchain was established in 2017. In July 2020, the Cardano Blockchain was expanded to include independent block validators, and in September 2024, an on-chain governance system was introduced. This Constitution outlines the rights and responsibilities of governance actors in the decentralized system who represent the owners of ada, the governance token of the Cardano Blockchain. The Cardano Blockchain is presently a decentralized ecosystem of blockchain technology, smart contracts, and community governance. + +In approaching this Constitution, the Cardano Community recognizes that it must be remembered that this is not a constitution for only a blockchain but rather, it is a constitution for a blockchain ecosystem – a much more ambitious endeavor. Accordingly, how governance actions are approved, while extremely important, is not the sole focus of this Constitution. Rather, this Constitution provides the basis and fundamental framework through which all participants in the Cardano Community can come together to govern themselves and form radically new approaches to human interaction and collaboration. + +By necessity, this Constitution recognizes the role of and empowers the Constitutional Committee, confirms the right of the Cardano Community to participate in collective bodies for collaboration, gives effect to on-chain governance, and empowers DReps to act as the voice of ada owners for on-chain voting. + +The Constitution also recognizes the necessity of safeguarding access to and the use of funds of the Cardano treasury through the inclusion of the Cardano Guardrails in this Constitution. + +## PREAMBLE + +Cardano is a decentralized ecosystem of blockchain technology, smart contracts, and community governance, committed to improving economic, political, and social systems for everyone, everywhere. By offering this foundational infrastructure, Cardano empowers individuals and communities to manage their identity, value, and governance, by fostering the emergence of decentralized applications, businesses, and network states. + +Through unbiased processing of immutable data, we the participants of the Cardano Community, consisting of individuals, organizations, contributors, and others, choose to follow in the footsteps of the early Internet and cryptocurrency pioneers, who first forged bonds of community through digital technologies. We are guided by our shared principles and tenets as we exercise our self-governance by balancing decentralized decision-making with accountability and safeguarding the security of the Cardano Blockchain. + +Recognizing the need for a more robust and dynamic governance framework, that neither relies nor depends upon traditional nation-state governance systems, but instead relies on self-governance by the Cardano Community, utilizing, wherever possible and beneficial, blockchain technology in the governance process, we hereby establish this Cardano Constitution to govern the Cardano Blockchain ecosystem, ensure the continuity of the Cardano Blockchain, and guard the rights of those who utilize it. + +With these purposes in mind, we the Cardano Community affirm our intention to abide by this Constitution in order to participate in the governance of the Cardano Blockchain ecosystem. We invite all who share our values to join us but stand not in the way of any who wish to take another path. + +## ARTICLE I. CARDANO BLOCKCHAIN TENETS AND GUARDRAILS + +### Section 1 + +These below Tenets shall guide all participants of the Cardano Community, including the Constitutional Committee, and proposed governance actions shall be evaluated in accordance with these Tenets. The order in which the below Tenets appear is not intended to represent a priority among Tenets. + +- **TENET 1**: Transactions on the Cardano Blockchain shall not be slowed down or censored and shall be expediently served for their intended purpose. +- **TENET 2**: The cost of transactions on the Cardano Blockchain shall be predictable and not unreasonable. +- **TENET 3**: Anyone desiring to develop and deploy applications on the Cardano Blockchain shall not unreasonably be prevented from developing and deploying such applications as intended. +- **TENET 4**: Contributions by the Cardano Community on the Cardano Blockchain shall be recognized, recorded, and assessed fairly through reward sharing with SPOs and DReps, appropriate tokenomics, and multi-resource consensus approaches. +- **TENET 5**: The Cardano Blockchain shall not lock in an ada owner’s value without an owner’s consent. +- **TENET 6**: The Cardano Blockchain shall not unreasonably impede interoperability. +- **TENET 7**: The Cardano Blockchain shall preserve in a safe manner any value and information an ada owner seeks to store on the Cardano Blockchain. +- **TENET 8**: The Cardano Blockchain shall not unreasonably spend resources. +- **TENET 9**: All users of the Cardano Blockchain shall be treated equally, taking into account the collective desires of the Cardano Blockchain Community, consistent with the long-term sustainability and viability of the Cardano Blockchain. +- **TENET 10**: Financial stability shall be maintained and the total supply of ada shall not exceed 45,000,000,000 (45,000,000,000,000,000 lovelace). + +### Section 2 + +The Cardano Blockchain shall operate in accordance with the Cardano Blockchain Guardrails as set forth in the Guardrails Appendix to this Constitution. The Cardano community may from time to time digitally codify certain Cardano Blockchain Guardrails such that such Cardano Blockchain Guardrails are directly programmed and implemented on the Cardano Blockchain using on-chain scripts or built-in ledger rules. + +In the event there are inconsistencies between a Cardano Blockchain Guardrail as set forth in the Guardrails Appendix and any such Cardano Blockchain Guardrail that has been programmed and implemented on the Cardano Blockchain, the version of such Cardano Blockchain Guardrail that has been deployed directly on the Cardano Blockchain shall prevail and the Constitutional Committee shall seek to reconcile such inconsistencies through the encouragement of an appropriate on-chain governance action. + +## ARTICLE II. THE CARDANO BLOCKCHAIN COMMUNITY + +### Section 1 + +No formal membership shall be required to use, participate in, and benefit from the Cardano Blockchain. Instead, all owners of ada, all developers of, all those building on, and all those otherwise supporting, maintaining, or using the Cardano Blockchain are considered to be participants in the Cardano Community and are therefore recognized as beneficiaries of the Cardano Blockchain ecosystem. All participants in the Cardano Community are accordingly beneficiaries of this Constitution, entitled to its rights, privileges, and protections and, as such, are expected to support and uphold this Constitution. + +### Section 2 + +Participants in the Cardano Community who own ada are entitled to access and participate in the on-chain decision-making processes of the Cardano Blockchain ecosystem, including voting and taking part in on-chain governance actions regarding the Cardano Blockchain. + +### Section 3 + +The Cardano Community has a responsibility to maintain the integrity of the Cardano Blockchain ecosystem by following this Constitution, operating the Cardano Blockchain, participating in Cardano Blockchain governance activities, and resolving disputes in a fair and transparent manner. + +### Section 4 + +The Cardano Community is entitled and encouraged through the provisions of this Constitution to collaborate in developing, maintaining, and building applications for the Cardano Blockchain, and to form temporary and permanent organizations, associations, and other entities as the Cardano Community deems desirable or appropriate in support of the Cardano Blockchain ecosystem. + +## ARTICLE III. PARTICIPATORY AND DECENTRALIZED GOVERNANCE + +### Section 1 + +The Cardano Blockchain shall be governed by a decentralized, on-chain governance model, utilizing, to the extent possible and beneficial, smart contracts and other blockchain-based tools to facilitate decision-making and ensure transparency. On-chain voting for governance actions shall follow the process outlined in the Cardano Blockchain Guardrails. + +### Section 2 + +Three independent governance bodies shall participate in voting for on-chain governance actions to provide checks and balances for the Cardano Blockchain consisting of Delegated Representatives (DReps), Stake Pool Operators (SPOs), and the Constitutional Committee (CC). + +### Section 3 + +On-chain governance decisions shall be made through a collective decision-making process, with specific consensus threshold requirements as required by the Cardano Blockchain Guardrails. All on-chain governance actions shall be voted upon in accordance with the Cardano Blockchain Guardrails. + +### Section 4 + +All owners of ada shall have the right to vote in on-chain governance action decision-making processes, subject to any restrictions or requirements provided for in this Constitution and the Cardano Blockchain Guardrails. All owners of ada shall have the right to propose changes to the governance structure of the Cardano Blockchain ecosystem in accordance with the Cardano Blockchain Guardrails. Owners of ada who use third-party custodians or other designees to hold their ada, may authorize, or may withhold authorization for, such third-parties to vote on their behalf. + +### Section 5 + +A special form of on-chain governance action, an “Info” action, exists to allow community sentiment to be gauged without committing to any on-chain change of the Cardano Blockchain. "Info" actions have no on-chain effect other than to record the outcome of such a vote on the Cardano Blockchain. + +### Section 6 + +In order to promote transparency in the process of on-chain governance, prior to being recorded or enacted on-chain, all proposed governance actions are expected to follow a standardized and legible format including a URL and hash linked to documented off-chain content. Sufficient rationale shall be provided to justify the requested change to the Cardano Blockchain. The rationale shall include, at a minimum, a title, abstract, reason for the proposal, and relevant supporting materials. + +The content of every on-chain governance action must be identical to the final off-chain version of the proposed action. + +“Hard Fork Initiation” and “Protocol Parameter Change” governance actions shall undergo sufficient technical review and scrutiny as mandated by the Cardano Blockchain Guardrails to ensure that the governance action does not endanger the security, functionality, performance, or long-term sustainability of the Cardano Blockchain. On-chain governance actions should address their expected impact on the Cardano Blockchain ecosystem. + +All owners of ada shall have the right to ensure that the process for participating in, submitting, and voting on on-chain governance actions is open and transparent and is protected from undue influence and manipulation. + +### Section 7 + +The Cardano Community is expected to support the creation, maintenance, and ongoing administration of off-chain governance processes as may be necessary to give effect to this Constitution and to ensure that there is awareness of and an opportunity to debate and shape all future governance actions for the Cardano Blockchain. + +### Section 8 + +The Cardano Community is expected to propose, not less than on an annual basis, a budget for the ongoing maintenance and future development of the Cardano Blockchain. All owners of ada are expected to periodically approve the Cardano Blockchain budget through an on-chain “Info action.” No withdrawals from the Cardano Blockchain treasury shall be permitted unless such withdrawals have been authorized and are being made pursuant to a budget for the Cardano Blockchain that is then in effect as required by the Cardano Blockchain Guardrails, and which has not been determined by the Constitutional Committee to be unconstitutional. Cardano Blockchain budgets shall specify a process for overseeing use of funds from Cardano Blockchain treasury withdrawals including designating one or more administrators who shall be responsible for such oversight. + +Any governance action requesting ada from the Cardano Blockchain treasury 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 shall include dispute resolution provisions. + +## ARTICLE IV. DELEGATED REPRESENTATIVES + +### Section 1 + +In order to participate in governance actions, owners of ada may register as DReps and directly vote on such governance actions or may delegate their voting rights to other registered DReps who shall vote on their behalf. + +### Section 2 + +Any owner of ada shall have the option to register as a DRep. Owners of ada shall be allowed to delegate their voting stake to one or more registered DReps, including themselves. DReps may be individuals or coordinated groups. Owners of ada who use third-party custodians or other designees to hold their ada, may authorize, or may withhold authorization for, such third-parties to delegate the voting rights of the ada owner to registered DReps on the owner’s behalf. DReps are entitled to cast votes directly for on-chain governance actions and represent those ada owners delegating their voting rights to them. + +This voting system shall enshrine a liquid democracy model where owners of ada can seamlessly select among DReps, register as a DRep, and withdraw or change their delegation at any time. + +### Section 3 + +DReps acting on behalf of other ada owners are expected to periodically adopt, and update as they deem appropriate, codes of conduct governing their activities as DReps and make such codes of conduct publicly available. DReps are encouraged to include ethical guidelines in their codes of conduct. + +### Section 4 + +The Cardano Community is expected to support the creation, maintenance, and ongoing administration of tools to enable owners of ada to explore and evaluate DRep candidates, access and evaluate DRep codes of conduct, and select DReps on such criteria as they deem relevant. + +### Section 5 + +DReps acting on behalf of other ada owners may be compensated for their efforts. DReps shall ensure that any compensation received in connection with their activities as a DRep is disclosed. DReps may not pay compensation to an ada owner or to an owner’s designee in exchange for being appointed a DRep by such ada owner or by its designee or for voting on behalf of such ada owner or its designee. + +## ARTICLE V. STAKE POOL OPERATORS + +### Section 1 + +SPOs shall have a specific role in approving critical on-chain governance actions which require additional oversight and independence, voting separately and independently from DReps as set forth in the Cardano Blockchain Guardrails. SPOs shall participate in hard fork initiation processes as the operators of the nodes that participate in Cardano Blockchain’s consensus mechanism. + +### Section 2 + +SPOs shall act as a check on the power of the Constitutional Committee under exceptional circumstances by separately voting on "Motion of no-confidence" and "Update committee/threshold" governance actions, and on “Parameter Update” governance actions that affect security-critical parameters. + +### Section 3 + +SPOs are encouraged to periodically adopt, and update as they deem appropriate, codes of conduct governing their activities as SPOs and make such codes of conduct publicly available. SPOs are encouraged to include ethical guidelines in their codes of conduct. + +### Section 4 + +Owners of ada who are both SPOs and acting as DReps shall publicly disclose that they are participating in on-chain governance actions in both such capacities prior to exercising any on-chain governance rights. + +## ARTICLE VI. CONSTITUTIONAL COMMITTEE + +### Section 1 + +A Constitutional Committee shall be established as the branch of Cardano's on-chain governance process that ensures governance actions to be enacted on-chain are consistent with this Constitution. The Constitutional Committee shall comprise a set of owners of ada that is collectively responsible for ensuring that on-chain governance actions prior to enactment on chain, are constitutional. With limited exceptions as provided in this Constitution, the Constitutional Committee shall be limited to voting on the constitutionality of governance actions to be enacted on-chain. Constitutional Committee members are expected to have appropriate expertise to carry out their required responsibilities, considering their past contributions and involvement in the Cardano Blockchain ecosystem. + +### Section 2 + +The Constitutional Committee shall be composed of such number of members as shall be determined from time to time by owners of ada, as consistent with the Cardano Blockchain Guardrails, and as shall be sufficient to assure the ongoing integrity of the Cardano Blockchain. + +Members of the Constitutional Committee shall serve such term lengths as shall be determined from time to time by owners of ada as consistent with the minimum and maximum term lengths as set forth in the Cardano Blockchain Guardrails. To assure continuity in the operation of the Constitutional Committee, the terms for Constitutional Committee members shall be staggered. + +### Section 3 + +The Cardano Community shall establish and make public a process from time to time for election of members of the Constitutional Committee consistent with the requirements of the Cardano Blockchain Guardrails. + +### Section 4 + +No governance action, other than a "Motion of no-confidence," or "Update constitutional committee/threshold" may be implemented on-chain unless a requisite percentage as specified by the Guardrails of the members of the Constitutional Committee shall have first determined and affirmed through an on-chain action that such proposal does not violate this Constitution. Because “Info” actions have no on-chain effect and, accordingly, are neither constitutional nor unconstitutional, Constitutional Committee members may not prevent “Info” actions from being recorded on-chain. Members of the Constitutional Committee may nevertheless record a vote on-chain regarding an “Info” action in order to express their view on such “Info” action, including whether the suggested course of action proposed in such “Info” action, would be, in the view of such member, unconstitutional if it were to be enforced by on-chain mechanisms. + +In the case of “Info actions” that propose a Cardano Blockchain budget, Constitutional Committee members shall record a vote on-chain that sets forth their opinion as to whether the proposed budget, if it were to be implemented in the form contained in the “Info” action, would violate this Constitution. + +In the case of “Info” actions that propose a withdrawal from the Cardano treasury pursuant to a previously approved budget, Constitutional Committee members shall record a vote on-chain that sets forth their opinion as to whether such proposed withdrawal, if made in accordance with such “Info” action, would violate this Constitution. + +### Section 5 + +The Constitutional Committee shall be considered to be in one of the following two states at all times: a state of confidence or a state of no-confidence. In a state of no-confidence, members of the then standing Constitutional Committee must be reinstated or replaced using the "Update committee/threshold" governance action before any other on-chain governance action, other than “Info” actions, may go forward. During a state of no-confidence, “Info” actions other than “Info” actions relating to budget proposals or treasury withdrawal proposals, may continue to be recorded on-chain. + +If a member of the Constitutional Committee is not carrying out its responsibilities as required by this Constitution, as so determined by a requisite percentage as specified by the Guardrails of SPOs and DReps, voting separately pursuant to a "Motion of no-confidence" governance action, such member shall be removed from the Constitutional Committee upon the implementation of the governance action. Thereafter, an election shall be held as soon as practical to replace the member so removed. + +In the event of a “Motion of no-confidence” governance action to remove all members of the Constitutional Committee at the same time, that is approved by a requisite percentage as specified by the Guardrails of DReps and SPOs, upon implementation of the governance action, the Constitutional Committee shall be considered to be a state of no-confidence until such time as an election has been held either to reinstate the existing Constitutional Committee members in whole or in part, or to elect new Constitutional Committee members. + +### Section 6 + +Constitutional Committee processes shall be transparent. The Constitutional Committee shall publish each decision. When voting that a governance action proposed to be executed on-chain is unconstitutional, the Constitutional Committee collectively, or each member of the Constitutional Committee casting such a vote separately, shall set forth the basis for its decision with reference to specific Articles of this Constitution or provisions of the Guardrails Appendix that are in conflict with a given proposal. Internal deliberation among members of the Constitutional Committee, prior to casting votes, are not required to be publicly disclosed. + +The Constitutional Committee shall operate pursuant to a code of conduct periodically adopted and published by the Constitutional Committee. The Constitutional Committee is encouraged to include ethical guidelines in its code of conduct. The Constitutional Committee shall periodically adopt and publish such policies and procedures as the Constitutional Committee shall deem necessary in carrying out its duties. + +### Section 7 + +The Cardano Community is expected to support the creation, maintenance, and ongoing administration of tools as may be necessary and appropriate for the Constitutional Committee to perform its required functions. + +### Section 8 + +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 may 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 shall provide for periodic administrative costs of the Constitutional Committee in such amounts as requested from time to time by the Constitutional Committee and as approved by ada owners. + +## ARTICLE VII. AMENDMENTS + +### Section 1 + +This Constitution should be treated as a living document. Technical advancements, changes in the desires, needs, and expectations of the Cardano Community, and unforeseen circumstances may give rise to the need in the future to amend this Constitution. The Cardano Community is encouraged to periodically review and debate the provisions of this Constitution, and when so desired, come together in such forums as the Cardano Community may deem appropriate, to propose amendments to this Constitution. Amendments may be made as provided in this Article VII. + +### Section 2 + +Except as otherwise so provided in the Cardano Blockchain Guardrails Appendix, amendments to this Constitution, including to the Cardano Blockchain Guardrails Appendix, shall be approved by a collective decision-making process, requiring an on-chain governance action by owners of ada satisfying a threshold of not less than 67% of the then active voting stake. + +### Section 3 + +If the Cardano Blockchain Guardrails Appendix sets forth an amendment threshold for a Cardano Blockchain Guardrail that is different than the amendment threshold contained in Section 2 of this Article VII, then the threshold set forth in the Cardano Blockchain Guardrails Appendix for such Cardano Blockchain Guardrail shall apply. + +## APPENDIX I: CARDANO BLOCKCHAIN GUARDRAILS + +### 1. INTRODUCTION + +To implement Cardano Blockchain on-chain governance, it is necessary to establish sensible guardrails that will enable the Cardano Blockchain to continue to operate in a secure and sustainable way. + +This Appendix sets forth guardrails that must be applied to Cardano Blockchain on-chain governance actions, including changes to the protocol parameters and limits on treasury withdrawals. These guardrails cover both essential, intrinsic limits on settings, and recommendations that are based on experience, measurement, and governance objectives. + +These guardrails are designed to avoid unexpected problems with the operation of the Cardano Blockchain. They are intended to guide the choice of sensible parameter settings and avoid potential problems with security, performance, functionality, or long-term sustainability. As described below, some of these guardrails are automatable and will be enforced via an on-chain script or built-in ledger rules. + +These guardrails apply only to the Cardano Blockchain Layer 1 mainnet environment. They are not intended to apply to test environments or to other blockchains that use the Cardano Blockchain software. + +Not all parameters for the Cardano Blockchain can be considered independently. Some parameters interact with other settings in an intrinsic way. Where known, these interactions are addressed in this Appendix. + +While the guardrails in this Appendix presently reflect the current state of technical insight, this Appendix should be treated as a living document. Implementation improvements, new simulations, or performance evaluation results for the Cardano Blockchain may allow some of the restrictions contained in these guardrails to be relaxed (or, in some circumstances, require them to be tightened) in due course. + +Additional guardrails may also be needed where, for example, new protocol parameters are introduced. + +#### Amending, Adding or Deprecating Guardrails + +The guardrails set forth in this Appendix may be amended from time to time pursuant to an on-chain governance action that satisfies the applicable voting threshold as set forth in this Appendix. Any such amendment to any guardrails shall require and be deemed to be an amendment to the Constitution itself, including any new guardrails. Each guardrail has a unique label. If the text of a guardrail is amended, the existing guardrail will be deprecated and a new label will be used in this Appendix. Similarly, if a guardrail is completely deprecated, its label will never be reused in the future. In all cases, the guardrails that apply to a governance action will be those in force at the time that the governance action is submitted on chain, regardless of any later amendments. + +#### Terminology and Guidance + +- **Should/Should not.** Where this Appendix says that a value "should not" be set below or above some value, this means that the guardrail is a recommendation or guideline, and the specific value could be open to discussion or alteration by a suitably expert group recognized by the Cardano community in light of experience with the Cardano Blockchain governance system or the operation of the Cardano Blockchain. + +- **Must/Must not.** Where this Appendix says that a value “must” or "must not" be set below or above some value, this means that the guardrail is a requirement that will be enforced by Cardano Blockchain ledger rules, types, or other built-in mechanisms where possible, and that if not followed could cause a protocol failure, security breach, or other undesirable outcome. + +- **Benchmarking.** Benchmarking refers to careful system-level performance evaluation that is designed to show a-priori that, for example, 95% of blocks will be diffused across a global network of Cardano Blockchain nodes within the required 5s time interval in all cases. This may require construction of specific test workflows and execution on a large test network of Cardano Blockchain nodes, simulating a global Cardano Blockchain network. + +- **Performance analysis.** Performance analysis refers to projecting theoretical performance, empirical benchmarking, or simulation results to predict actual system behavior. For example, performance results obtained from tests in a controlled test environment (such as a collection of data centers with known networking properties) may be extrapolated to inform likely performance behavior in a real Cardano Blockchain network environment. + +- **Simulation.** Simulation refers to synthetic execution that is designed to inform performance/functionality decisions in a repeatable way. For example, the IOSim Cardano Blockchain module allows the operation of the networking stack to be simulated in a controlled and repeatable way, allowing issues to be detected before code deployment. + +- **Performance Monitoring.** Performance monitoring involves measuring the actual behavior of the Cardano Blockchain network, for example, by using timing probes to evaluate round-trip times, or test blocks to assess overall network health. It complements benchmarking and performance analysis by providing information about actual system behavior that cannot be obtained using simulated workloads or theoretical analysis. + +- **Reverting Changes.** Where performance monitoring shows that actual network behavior following a change is inconsistent with the performance requirements for the Cardano Blockchain, then the change must be reverted to its previous state if that is possible. For example, if the block size is increased from 100KB to 120KB and 95% of blocks are no longer diffused within 5s, then a change must be made to revert the block size to 100KB. If this is not possible, then one or more alternative changes must be made that will ensure that the performance requirements are met. + +- **Severity Levels.** Issues that affect the Cardano Blockchain network are classified by severity level, where: + - Severity 1 is a critical incident or issue with very high impact on the security, performance, functionality, or long-term sustainability of the Cardano Blockchain network. + - Severity 2 is a major incident or issue with significant impact on the security, performance, functionality, or long-term sustainability of the Cardano Blockchain network. + - Severity 3 is a minor incident or issue with low impact on the security, performance, functionality, or long-term sustainability of the Cardano Blockchain network. + +- **Future Performance Requirements.** Planned development such as new mechanisms for out-of-memory storage may impact block diffusion or other times. When changing parameters, it is necessary to consider these future performance requirements as well as the current operation of the Cardano Blockchain. Until development is complete, the requirements will be conservative but may then be relaxed to account for actual timing behavior. + +#### Automated Checking ("Guardrails Script") + +A script hash is associated with the constitution hash when a **New Constitution or Guardrails Script** governance action is enacted. It acts as an additional safeguard to the ledger rules and types, filtering non-compliant governance actions. + +The guardrails script only affects two types of governance actions: +- **Parameter Update** actions, and +- **Treasury Withdrawal** actions. + +The script is executed when either of these types of governance action is submitted on-chain. This avoids scenarios where, for example, an erroneous script could prevent the chain from ever enacting a Hard Fork action, resulting in deadlock. There are three different situations that apply to script usage. + +- **Symbol and Explanation** + - (y) The script can be used to enforce the guardrail. + - (x) The script cannot be used to enforce the guardrail. + - (~ - reason) The script cannot be used to enforce the guardrail for the reason given, but future ledger changes could enable this. + +Guardrails may overlap: in this case, the most restrictive set of guardrails will apply. Where a parameter is not explicitly listed in this document, then the script **must not** permit any changes to the parameter. Conversely, where a parameter is explicitly listed in this document but no checkable guardrails are specified, the script **must not** impose any constraints on changes to the parameter. + +### 2. GUARDRAILS AND GUIDELINES ON PROTOCOL PARAMETER UPDATE ACTIONS + +Below are guardrails and guidelines for changing updatable protocol parameter settings via the protocol parameter update governance action such that the Cardano Blockchain is never in an unrecoverable state as a result of such changes. Note that, to avoid ambiguity, this Appendix uses the parameter name that is used in protocol parameter update governance actions rather than any other convention. + +#### Guardrails + +- **PARAM-01 (y)** Any protocol parameter that is not explicitly named in this document **must not** be changed by a Parameter update governance action. +- **PARAM-02 (y)** Where a protocol parameter is explicitly listed in this document but no checkable guardrails are specified, the guardrails script **must not** impose any constraints on changes to the parameter. Checkable guardrails are shown by a (y). + +#### 2.1. Critical Protocol Parameters + +The below protocol parameters are critical from a security point of view. + +- **Parameters that are Critical to the Operation of the Blockchain** + - *maximum block body size* (*maxBlockBodySize*) + - *maximum transaction size* (*maxTxSize*) + - *maximum block header size* (*maxBlockHeaderSize*) + - *maximum size of a serialized asset value* (*maxValueSize*) + - *maximum script execution/memory units in a single block* (*maxBlockExecutionUnits[steps/memory]*) + - *minimum fee coefficient* (*txFeePerByte*) + - *minimum fee constant* (*txFeeFixed*) + - *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*) + - *minimum Lovelace deposit per byte of serialized UTxO* (*utxoCostPerByte*) + - *governance action deposit* (*govDeposit*) + +#### Guardrails + +- **PARAM-03 (y)** Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs **must** say "yes" with a collective support of more than 50% of all active block production stake. This is enforced by the guardrails on the stake pool voting threshold. +- **PARAM-04 (x)** At least 3 months **should** normally pass between the publication of an off-chain proposal to change a critical protocol parameter and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation. + +- **Parameters that are Critical to the Governance System** + - *delegation key Lovelace deposit* (*stakeAddressDeposit*) + - *pool registration Lovelace deposit* (*stakePoolDeposit*) + - *minimum fixed rewards cut for pools* (*minPoolCost*) + - *DRep deposit amount* (*dRepDeposit*) + - *minimal Constitutional Committee size* (*committeeMinSize*) + - *maximum term length (in epochs) for the Constitutional Committee members* (*committeeMaxTermLength*) + +#### Guardrails + +- **PARAM-05 (y)** DReps **must** vote "yes" with a collective support of more than 50% of all active voting stake. This is enforced by the guardrails on the DRep voting thresholds. +- **PARAM-06 (x)** At least 3 months **should** normally pass between the publication of an off-chain proposal to change a parameter that is critical to the governance system and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation. + +#### 2.2. Economic Parameters + +The overall goals when managing economic parameters are to: + +1. Enable long-term economic sustainability for the Cardano Blockchain ecosystem; +2. Ensure that stake pools are adequately rewarded for maintaining the Cardano Blockchain; +3. Ensure that ada holders are adequately rewarded for using stake in constructive ways, including when delegating ada for block production; and +4. Balance economic incentives for different Cardano Blockchain ecosystem stakeholders, including but not limited to Stake Pool Operators, ada holders, DeFi users, infrastructure users, developers (e.g. DApps), and financial intermediaries (e.g. exchanges). + +**Triggers for Change** + +1. Significant changes in the fiat value of ada resulting in potential problems with security, performance, functionality, or long-term sustainability. +2. Changes in transaction volumes or types. +3. Community requests or suggestions. +4. Emergency situations that require changes to economic parameters. + +**Counter-indicators** + +Changes to the economic parameters should not be made in isolation. They need to account for: + +- External economic factors. +- Network security concerns. + +**Core Metrics** + +- Fiat value of ada resulting in potential problems with security, performance, functionality, or long-term sustainability. +- Transaction volumes and types. +- Number and health of stake pools. +- External economic factors. + +**Changes to Specific Economic Parameters** + +- **Transaction fee per byte (txFeePerByte) and fixed transaction fee (txFeeFixed)** + - Defines the cost for basic transactions in Lovelace: *fee(tx) = txFeeFixed + txFeePerByte x nBytes(tx)* + +#### Guardrails + +- **TFPB-01 (y)** *txFeePerByte* **must not** be lower than 30 (0.000030 ada). This protects against low-cost denial of service attacks. +- **TFPB-02 (y)** *txFeePerByte* **must not** exceed 1,000 (0.001 ada). This ensures that transactions can be paid for. +- **TFPB-03 (y)** *txFeePerByte* **must not** be negative. +- **TFF-01 (y)** *txFeeFixed* **must not** be lower than 100,000 (0.1 ada). This protects against low-cost denial of service attacks. +- **TFF-02 (y)** *txFeeFixed* **must not** exceed 10,000,000 (10 ada). This ensures that transactions can be paid for. +- **TFF-03 (y)** *txFeeFixed* **must not** be negative. +- **TFGEN-01 (x - "should")** To maintain a consistent level of protection against denial-of-service attacks, *txFeeFixed* and *txFeeFixed* **should** be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory]). +- **TFGEN-02 (x - unquantifiable)** Any changes to *txFeeFixed* or *txFeeFixed* **must** consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee so that it becomes impossible to construct a transaction. + +- **UTxO cost per byte (utxoCostPerByte)** + - Defines the deposit (in Lovelace) that is charged for each byte of storage that is held in a UTxO. This deposit is returned when the UTxO is no longer active. + - Sets a minimum threshold on ada that is held within a single UTxO. + - Provides protection against low-cost denial of service attack on UTxO storage. DoS protection decreases in line with the free node memory (proportional to UTxO growth). + - Helps reduce long-term storage costs for node users by providing an incentive to return UTxOs when no longer needed, or to merge UTxOs. + +#### Guardrails + +- **UCPB-01 (y)** *utxoCostPerByte* **must not** be lower than 3,000 (0.003 ada). +- **UCPB-02 (y)** *utxoCostPerByte* **must not** exceed 6,500 (0.0065 ada). +- **UCPB-03 (y)** *utxoCostPerByte* **must not** be zero. +- **UCPB-04 (y)** *utxoCostPerByte* **must not** be negative. +- **UCPB-05a (x - "should")** Changes **should** account for: + - i) The acceptable cost of attack. + - ii) The acceptable time for an attack. + - iii) The acceptable memory configuration for full node users. + - iv) The sizes of UTxOs and. + - v) The current total node memory usage. + +- **Stake address deposit (stakeAddressDeposit)** + - Ensures that stake addresses are retired when no longer needed. + - Helps reduce long-term storage costs. + - Helps limit CPU and memory costs in the ledger. + - The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Reducing the number of active stake addresses also reduces processing and memory costs at the epoch boundary when calculating stake snapshots. + +#### Guardrails + +- **SAD-01 (y)** *stakeAddressDeposit* **must not** be lower than 1,000,000 (1 ada). +- **SAD-02 (y)** *stakeAddressDeposit* **must not** exceed 5,000,000 (5 ada). +- **SAD-03 (y)** *stakeAddressDeposit* **must not** be negative. + +- **Stake pool deposit (stakePoolDeposit)** + - Ensures that stake pools are retired by the stake pool operator when no longer needed by them. + - Helps reduce long-term storage costs. + - The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Rewards and stake snapshot calculations are also impacted by the number of active stake pools. + +#### Guardrails + +- **SPD-01 (y)** *stakePoolDeposit* **must not** be lower than 250,000,000 (250 ada). +- **SPD-02 (y)** *stakePoolDeposit* **must not** exceed 500,000,000 (500 ada). +- **SPD-03 (y)** *stakePoolDeposit* **must not** be negative. + +- **Minimum Pool Cost (minPoolCost)** + - Part of the rewards mechanism. + - The minimum pool cost is transferred to the pool rewards address before any delegator rewards are paid. + +#### Guardrails + +- **MPC-01 (y)** *minPoolCost* **must not** be negative. +- **MPC-02 (y)** *minPoolCost* **must not** exceed 500,000,000 (500 ada). +- **MPC-03 (x - "should")** *minPoolCost* **should** be set in line with the economic cost for operating a pool. + +- **Treasury Cut (treasuryCut)** + - Part of the rewards mechanism. + - The treasury cut portion of the monetary expansion is transferred to the treasury before any pool rewards are paid. + - Can be set in the range 0.0-1.0 (0%-100%). + +#### Guardrails + +- **TC-01 (y)** *treasuryCut* **must not** be lower than 0.1 (10%). +- **TC-02 (y)** *treasuryCut* **must not** exceed 0.3 (30%). +- **TC-03 (y)** *treasuryCut* **must not** be negative. +- **TC-04 (y)** *treasuryCut* **must not** exceed 1.0 (100%). +- **TC-05 (~ - no access to change history)** *treasuryCut* **must not** be changed more than once in any 36 epoch period (approximately 6 months). + +- **Monetary Expansion Rate (monetaryExpansion)** + - Part of the rewards mechanism. + - The monetary expansion controls the amount of reserves that is used for rewards each epoch. + - Governs the long-term sustainability of Cardano. + - The reserves are gradually depleted until no rewards are supplied. + +#### Guardrails + +- **ME-01 (y)** *monetaryExpansion* **must not** exceed 0.005. +- **ME-02 (y)** *monetaryExpansion* **must not** be lower than 0.001. +- **ME-03 (y)** *monetaryExpansion* **must not** be negative. +- **ME-04 (x - "should")** *monetaryExpansion* **should not** be varied by more than +/- 10% in any 73-epoch period (approximately 12 months). +- **ME-05 (x - "should")** *monetaryExpansion* **should not** be changed more than once in any 36-epoch period (approximately 6 months). + +- **Plutus Script Execution Prices (executionUnitPrices[priceSteps/priceMemory])** + - Define the fees for executing Plutus scripts. + - Gives an economic return for Plutus script execution. + - Provides security against low-cost DoS attacks. + +#### Guardrails + +- **EIUP-PS-01 (y)** *executionUnitPrices[priceSteps]* **must not** exceed 2,000 / 10,000,000. +- **EIUP-PS-02 (y)** *executionUnitPrices[priceSteps]* **must not** be lower than 500 / 10,000,000. +- **EIUP-PM-01 (y)** *executionUnitPrices[priceMemory]* **must not** exceed 2,000 / 10,000. +- **EIUP-PM-02 (y)** *executionUnitPrices[priceMemory]* **must not** be lower than 400 / 10,000. +- **EIUP-GEN-01 (x - "similar to")** The execution prices **must** be set so that: + - i) the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum sized non-script transaction and. + - ii) the cost of executing a transaction with maximum memory units is similar to the cost of a maximum sized non-script transaction. +- **EIUP-GEN-02 (x - "should")** The execution prices **should** be adjusted whenever transaction fees are adjusted (*txFeeFixed/txFeePerByte*). The goal is to ensure that the processing delay is similar for "full" transactions, regardless of their type. + +- **Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte)** + - Defines the cost for using Plutus reference scripts in Lovelace. + +#### Guardrails + +- **MFRS-01 (y)** *minFeeRefScriptCoinsPerByte* **must not** exceed 1,000 (0.001 ada). This ensures that transactions can be paid for. +- **MFRS-02 (y)** *minFeeRefScriptCoinsPerByte* **must not** be negative. +- **MFRS-03 (x - "should")** To maintain a consistent level of protection against denial-of-service attacks, *minFeeRefScriptCoinsPerByte* **should** be adjusted whenever Plutus Execution prices are adjusted (*executionUnitPrices[steps/memory]*) and whenever *txFeeFixed* is adjusted. +- **MFRS-04 (x - unquantifiable)** Any changes to *minFeeRefScriptCoinsPerByte* **must** consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee. + +#### 2.3. Network Parameters + +The overall goals when managing the Cardano Blockchain network parameters are to: + +1. 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. +2. Balance traffic demands for different user groups, including payment transactions, minters of Fungible/Non-Fungible Tokens, Plutus scripts, DeFi developers, Stake Pool Operators, and voting transactions. + +**Triggers for Change** + +Changes to network parameters may be triggered by: + +1. Measured changes in traffic demands over a 2-epoch period (10 days). +2. Anticipated changes in traffic demands. +3. Community requests. + +**Counter-indicators** + +Changes may need to be reversed and/or should not be enacted in the event of: + +- Excessive block propagation delays. +- Stake pools being unable to handle traffic volume. +- Scripts being unable to complete execution. + +**Core Metrics** + +All decisions on parameter changes should be informed by: + +- Block propagation delay profile. +- Traffic volume (block size over time). +- Script volume (size of scripts and execution units). +- Script execution cost benchmarks. +- Block propagation delay/diffusion benchmarks. + +Detailed benchmarking results are required to confirm the effect of any changes on mainnet performance or behavior prior to enactment. The effects of different transaction mixes must be analyzed, including normal transactions, Plutus scripts, and governance actions. + +#### Guardrails + +- **NETWORK-01 (x - "should")** No individual network parameter **should** change more than once per two epochs. +- **NETWORK-02 (x - "should")** Only one network parameter **should** be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits. + +**Changes to Specific Network Parameters** + +- **Block Size (maxBlockBodySize)** + - The maximum size of a block, in Bytes. + +#### Guardrails + +- **MBBS-01 (y)** *maxBlockBodySize* **must not** exceed 122,880 Bytes (120KB). +- **MBBS-02 (y)** *maxBlockBodySize* **must not** be lower than 24,576 Bytes (24KB). +- **MBBS-03a (x - "exceptional circumstances")** *maxBlockBodySize* **must not** be decreased, other than in exceptional circumstances where there are potential problems with security, performance, functionality, or long-term sustainability. +- **MBBS-04 (~ - no access to existing parameter values)** *maxBlockBodySize* **must** be large enough to include at least one transaction (that is, *maxBlockBodySize* **must** be at least *maxTxSize*). +- **MBBS-05 (x - "should")** *maxBlockBodySize* **should** be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch. +- **MBBS-06 (x - "should")** The block size **should not** induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation, and benchmarking. +- **MBBS-07 (x - "unquantifiable")** The impact of any change to *maxBlockBodySize* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to *maxBlockBodySize* must also consider future requirements for Plutus script execution (*maxBlockExecutionUnits[steps]*) against the total block diffusion target of 3s with 95% block propagation within 5s. The limit on maximum block size may be increased in the future if this is supported by benchmarking and monitoring results. + +- **Transaction Size (maxTxSize)** + - The maximum size of a transaction, in Bytes. + +#### Guardrails + +- **MTS-01 (y)** *maxTxSize* **must not** exceed 32,768 Bytes (32KB). +- **MTS-02 (y)** *maxTxSize* **must not** be negative. +- **MTS-03 (~ - no access to existing parameter values)** *maxTxSize* **must not** be decreased. +- **MTS-04 (~ - no access to existing parameter values)** *maxTxSize* **must not** exceed *maxBlockBodySize*. +- **MTS-05 (x - "should")** *maxTxSize* **should not** be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably **should** be increased by 2,048 Bytes (2KB) or less per epoch. +- **MTS-06 (x - "should")** *maxTxSize* **should not** exceed 1/4 of the block size. + +- **Memory Unit Limits (maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory])** + - The limit on the maximum number of memory units that can be used by Plutus scripts, either per-transaction or per-block. + +#### Guardrails + +- **MTEU-M-01 (y)** *maxTxExecutionUnits[memory]* **must not** exceed 40,000,000 units. +- **MTEU-M-02 (y)** *maxTxExecutionUnits[memory]* **must not** be negative. +- **MTEU-M-03 (~ - no access to existing parameter values)** *maxTxExecutionUnits[memory]* **must not** be decreased. +- **MTEU-M-04 (x - "should")** *maxTxExecutionUnits[memory]* **should not** be increased by more than 2,500,000 units in any epoch. +- **MBEU-M-01 (y)** *maxBlockExecutionUnits[memory]* **must not** exceed 120,000,000 units. +- **MBEU-M-02 (y)** *maxBlockExecutionUnits[memory]* **must not** be negative. +- **MBEU-M-03 (x - "should")** *maxBlockExecutionUnits[memory]* **should not** be changed (increased or decreased) by more than 10,000,000 units in any epoch. +- **MBEU-M-04a (x - unquantifiable)** The impact of any change to *maxBlockExecutionUnits[memory]* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by *maxBlockExecutionUnits[steps]* and *maxBlockBodySize*. Any increase **must** also consider previously agreed future requirements for the total block size (*maxBlockBodySize*) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block memory limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. +- **MEU-M-01 (~ - no access to existing parameter values)** *maxBlockExecutionUnits[memory]* **must not** be less than *maxTxExecutionUnits[memory]*. + +- **CPU Unit Limits (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps])** + - The limit on the maximum number of CPU steps that can be used by Plutus scripts, either per-transaction or per-block. + +#### Guardrails + +- **MTEU-S-01 (y)** *maxTxExecutionUnits[steps]* **must not** exceed 15,000,000,000 (15Bn) units. +- **MTEU-S-02 (y)** *maxTxExecutionUnits[steps]* **must not** be negative. +- **MTEU-S-03 (~ - no access to existing parameter values)** *maxTxExecutionUnits[steps]* **must not** be decreased. +- **MTEU-S-04 (x - "should")** *maxTxExecutionUnits[steps]* **should not** be increased by more than 500,000,000 (500M) units in any epoch (5 days). +- **MBEU-S-01 (y)** *maxBlockExecutionUnits[steps]* **must not** exceed 40,000,000,000 (40Bn) units. +- **MBEU-S-02 (y)** *maxBlockExecutionUnits[steps]* **must not** be negative. +- **MBEU-S-03 (x - "should")** *maxBlockExecutionUnits[steps]* **should not** be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days). +- **MBEU-S-04a (x - unquantifiable)** The impact of the change to *maxBlockExecutionUnits[steps]* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by *maxBlockExecutionUnits[memory]* and *maxBlockBodySize*. Any increase **must** also consider previously identified future requirements for the total block size (*maxBlockBodySize*) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block step limit to be increased, but **must** be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. +- **MEU-S-01 (~ - no access to existing parameter values)** *maxBlockExecutionUnits[steps]* **must not** be less than *maxTxExecutionUnits[steps]*. + +- **Block Header Size (maxBlockHeaderSize)** + - The size of the block header. + +#### Guardrails + +- **MBHS-01 (y)** *maxBlockHeaderSize* **must not** exceed 5,000 Bytes. +- **MBHS-02 (y)** *maxBlockHeaderSize* **must not** be negative. +- **MBHS-03 (x - "largest valid header" is subject to change)** *maxBlockHeaderSize* **must** be large enough for the largest valid header. +- **MBHS-04 (x - "should")** *maxBlockHeaderSize* **should** only normally be increased if the protocol changes. +- **MBHS-05 (x - "should")** *maxBlockHeaderSize* **should** be within TCP's initial congestion window (3 or 10 MTUs). + +#### 2.4. Technical/Security Parameters + +The overall goals when managing the technical/security parameters are: + +1. Ensure the security of the Cardano network in terms of decentralization, protection against Sybil and 51% attacks, and protection against denial of service attacks. +2. Enable changes to the Plutus language. + +**Triggers for Change** + +1. Changes in the number of active SPOs. +2. Changes to the Plutus language. +3. Security threats. +4. Community requests. + +**Counter-indicators** + +- Economic concerns, e.g. when changing the number of stake pools. + +**Core Metrics** + +- Number of stake pools. +- Level of decentralization. + +**Changes to Specific Technical/Security Parameters** + +- **Target Number of Stake Pools (stakePoolTargetNum)** + - Sets the target number of stake pools. + - The expected number of pools when the network is in the equilibrium state. + - Primarily a security parameter, ensuring decentralization by pool division/replication. + - Has an economic effect as well as a security affect - economic advice is also required when changing this parameter. + - Large changes in this parameter will trigger mass redelegation events. + +#### Guardrails + +- **SPTN-01 (y)** *stakePoolTargetNum* **must not** be lower than 250. +- **SPTN-02 (y)** *stakePoolTargetNum* **must not** exceed 2,000. +- **SPTN-03 (y)** *stakePoolTargetNum* **must not** be negative. +- **SPTN-04 (y)** *stakePoolTargetNum* **must not** be zero. + +- **Pledge Influence Factor (poolPledgeInfluence)** + - Enables the pledge protection mechanism. + - Provides protection against Sybil attack. + - Higher values reward pools that have more pledge and penalize pools that have less pledge. + - Has an economic effect as well as technical effect - economic advice is also required. + +#### Guardrails + +- **PPI-01 (y)** *poolPledgeInfluence* **must not** be lower than 0.1. +- **PPI-02 (y)** *poolPledgeInfluence* **must not** exceed 1.0. +- **PPI-03 (y)** *poolPledgeInfluence* **must not** be negative. +- **PPI-04 (x - "should")** *poolPledgeInfluence* **should not** vary by more than +/- 10% in any 18-epoch period (approximately 3 months). + +- **Pool Retirement Window (poolRetireMaxEpoch)** + - Defines the maximum number of epochs notice that a pool can give when planning to retire. + +#### Guardrails + +- **PRME-01 (y)** *poolRetireMaxEpoch* **must not** be negative. +- **PRME-02 (x - "should")** *poolRetireMaxEpoch* **should not** be lower than 1. + +- **Collateral Percentage (collateralPercentage)** + - Defines how much collateral must be provided when executing a Plutus script as a percentage of the normal execution cost. + - Collateral is additional to fee payments. + - If a script fails to execute, then the collateral is lost. + - The collateral is never lost if a script executes successfully. + - Provides security against low-cost attacks by making it more expensive rather than less expensive to execute failed scripts. + +#### Guardrails + +- **CP-01 (y)** *collateralPercentage* **must not** be lower than 100. +- **CP-02 (y)** *collateralPercentage* **must not** exceed 200. +- **CP-03 (y)** *collateralPercentage* **must not** be negative. +- **CP-04 (y)** *collateralPercentage* **must not** be zero. + +- **Maximum number of collateral inputs (maxCollateralInputs)** + - Defines the maximum number of inputs that can be used for collateral when executing a Plutus script. + +#### Guardrails + +- **MCI-01 (y)** *maxCollateralInputs* **must not** be lower than 1. + +- **Maximum Value Size (maxValueSize)** + - The limit on the serialized size of the Value in each output. + +#### Guardrails + +- **MVS-01 (y)** *maxValueSize* **must not** exceed 12,288 Bytes (12KB). +- **MVS-02 (y)** *maxValueSize* **must not** be negative. +- **MVS-03 (~ - no access to existing parameter values)** *maxValueSize* **must** be less than *maxTxSize*. +- **MVS-04 (~ - no access to existing parameter values)** *maxValueSize* **must not** be reduced. +- **MVS-05 (x - "sensible output" is subject to interpretation)** *maxValueSize* **must** be large enough to allow sensible outputs (e.g. any existing on-chain output or anticipated outputs that could be produced by new ledger rules). + +- **Plutus Cost Models (costModels)** + - Define the base costs for each Plutus primitive in terms of CPU and memory unit. + - A different cost model is required for each Plutus version. Each cost model comprises many distinct cost model values. Cost models are defined for each Plutus language version. A new language version may introduce additional cost model values or remove existing cost model values. + +#### Guardrails + +- **PCM-01 (x - unquantifiable)** *Cost model* values **must** be set by benchmarking on a reference architecture. +- **PCM-02 (x - primitives and language versions aren't introduced in transactions)** The *cost model* **must** be updated if new primitives are introduced or a new Plutus language version is added. +- **PCM-03a (~ - no access to *Plutus cost model* parameters)** *Cost model* values **should not** normally be negative. Negative values must be justified against the underlying cost model for the associated primitives. +- **PCM-04 (~ - no access to *Plutus cost model* parameters)** A *cost model* **must** be supplied for each Plutus language version that the protocol supports. + +#### 2.5. Governance Parameters + +The overall goals when managing the governance parameters are to: + +1. Ensure governance stability. +2. Maintain a representative form of governance. + +**Triggers for Change** + +Changes to governance parameters may be triggered by: + +1. Community requests. +2. Regulatory requirements. +3. Unexpected or unwanted governance outcomes. +4. Entering a state of no confidence. + +**Counter-indicators** + +Changes may need to be reversed and/or should not be enacted in the event of: + +- Unexpected effects on governance. +- Excessive Layer 1 load due to on-chain voting or excessive numbers of governance actions. + +**Core Metrics** + +All decisions on parameter changes should be informed by: + +- Governance participation levels. +- Governance behaviors and patterns. +- Regulatory considerations. +- Confidence in the governance system. +- The effectiveness of the governance system in managing necessary change. + +**Changes to Specific Governance Parameters** + +- **Deposit for Governance Actions (govDeposit)** + - The deposit that is charged when submitting a governance action. + - Helps to limit the number of actions that are submitted. + +#### Guardrails + +- **GD-01 (y)** *govDeposit* **must not** be negative. +- **GD-02 (y)** *govDeposit* **must not** be lower than 1,000,000 (1 ada). +- **GD-03 (y)** *govDeposit* **must not** exceed 10,000,000,000,000 (10 Million ada). +- **GD-04 (x - "should")** *govDeposit* **should** be adjusted in line with fiat changes. + +- **Deposit for DReps (dRepDeposit)** + - The deposit that is charged when registering a DRep. + - Helps to limit the number of active DReps. + +#### Guardrails + +- **DRD-01 (y)** *dRepDeposit* **must not** be negative. +- **DRD-02 (y)** *dRepDeposit* **must not** be lower than 1,000,000 (1 ada). +- **DRD-03 (y)** *dRepDeposit* **must not** exceed 100,000,000,000 (100,000 ada). +- **DRD-04 (x - "should")** *dRepDeposit* **should** be adjusted in line with fiat changes. + +- **DRep Activity Period (dRepActivity)** + - The period (as a whole number of epochs) after which a DRep is considered to be inactive for vote calculation purposes, if they do not vote on any proposal. + +#### Guardrails + +- **DRA-01 (y)** *dRepActivity* **must not** be lower than 13 epochs (2 months). +- **DRA-02 (y)** *dRepActivity* **must not** exceed 37 epochs (6 months). +- **DRA-03 (y)** *dRepActivity* **must not** be negative. +- **DRA-04 (~ - no access to existing parameter values)** *dRepActivity* **must** be greater than *govActionLifetime*. +- **DRA-05 (x - "should")** *dRepActivity* **should** be calculated in human terms (2 months etc). + +- **DRep and SPO Governance Action Thresholds (dRepVotingThresholds[...], poolVotingThresholds[...])** + - Thresholds on the active voting stake that is required to ratify a specific type of governance action by either DReps or SPOs. + - Ensures legitimacy of the action. + +**The threshold parameters are listed below:** + +- *dRepVotingThresholds*: + - *dvtCommitteeNoConfidence* + - *dvtCommitteeNormal* + - *dvtHardForkInitiation* + - *dvtMotionNoConfidence* + - *dvtPPEconomicGroup* + - *dvtPPGovGroup* + - *dvtPPNetworkGroup* + - *dvtPPTechnicalGroup* + - *dvtTreasuryWithdrawal* + - *dvtUpdateToConstitution* + +- *poolVotingThresholds*: + - *pvtCommitteeNoConfidence* + - *pvtCommitteeNormal* + - *pvtHardForkInitiation* + - *pvtMotionNoConfidence* + - *pvtPPSecurityGroup* + +#### Guardrails + +- **VT-GEN-01 (y)** All thresholds **must** be greater than 50% and less than or equal to 100%. +- **VT-GEN-02 (y)** Economic, network, and technical parameter thresholds **must** be in the range 51%-75%. +- **VT-GEN-03 (y)** Governance parameter thresholds **must** be in the range 75%-90%. +- **VT-HF-01 (y)** **Hard fork** action thresholds **must** be in the range 51%-80%. +- **VT-CON-01 (y)** **New Constitution or guardrails script action** thresholds **must** be in the range 65%-90%. +- **VT-CC-01 (y)** **Update Constitutional Committee action** thresholds **must** be in the range 51%-90%. +- **VT-NC-01 (y)** **No confidence** action thresholds **must** be in the range 51%-75%. + +- **Governance Action Lifetime (govActionLifetime)** + - The period after which a governance action will expire if it is not enacted - As a whole number of epochs. + +#### Guardrails + +- **GAL-01 (y)** *govActionLifetime* **must not** be lower than 1 epoch (5 days). +- **GAL-03 (x - "should")** *govActionLifetime* **should not** be lower than 2 epochs (10 days). +- **GAL-02 (y)** *govActionLifetime* **must not** exceed 15 epochs (75 days). +- **GAL-04 (x - "should")** *govActionLifetime* **should** be calibrated in human terms (eg 30 days, two weeks), to allow sufficient time for voting etc. to take place. +- **GAL-05 (~ - no access to existing parameter values)** *govActionLifetime* **must** be less than *dRepActivity*. + +- **Maximum Constitutional Committee Term (committeeMaxTermLength)** + - The limit on the maximum term length that a committee member may serve. + +#### Guardrails + +- **CMTL-01a (y)** *committeeMaxTermLength* **must not** be zero. +- **CMTL-02a (y)** *committeeMaxTermLength* **must not** be negative. +- **CMTL-03a (y)** *committeeMaxTermLength* **must not** be lower than 18 epochs (90 days, or approximately 3 months). +- **CMTL-04a (y)** *committeeMaxTermLength* **must not** exceed 293 epochs (approximately 4 years). +- **CMTL-05a (x - "should")** *committeeMaxTermLength* **should not** exceed 220 epochs (approximately 3 years). + +- **The minimum size of the Constitutional Committee (committeeMinSize)** + - The least number of members that can be included in a Constitutional Committee following a governance action to change the Constitutional Committee. + +#### Guardrails + +- **CMS-01 (y)** *committeeMinSize* **must not** be negative. +- **CMS-02 (y)** *committeeMinSize* **must not** be lower than 3. +- **CMS-03 (y)** *committeeMinSize* **must not** exceed 10. + +#### 2.6. Monitoring and Reversion of Parameter Changes + +All network parameter changes **must be** monitored carefully for no less than 2 epochs (10 days). + +- Changes **must** be reverted as soon as possible if block propagation delays exceed 4.5s for more than 5% of blocks over any 6-hour rolling window. + +All other parameter changes should be monitored. + +- The reversion plan **should** be implemented if the overall effect on performance, security, functionality, or long-term sustainability is unacceptable. + +A specific reversion/recovery plan **must be** produced for each parameter change. This plan must include: + +- Which parameters need to change and in which ways in order to return to the previous state (or a similar state). +- How to recover the network in the event of disastrous failure. + +This plan **should** be followed if problems are observed following the parameter change. Note that not all changes can be reverted. Additional care must be taken when making changes to these parameters. + +#### 2.7. Non-Updatable Protocol Parameters + +Some fundamental protocol parameters cannot be changed by the Protocol Parameter Update governance action. These parameters can only be changed in a new Genesis file as part of a hard fork. It is not necessary to provide specific guardrails on updating these parameters. + +### 3. GUARDRAILS AND GUIDELINES ON TREASURY WITHDRAWAL ACTIONS + +**Treasury withdrawal** actions specify the destination and amount of a number of withdrawals from the Cardano treasury. + +#### Guardrails + +- **TREASURY-01a (x)** A net change limit for the Cardano Treasury's balance per period of time **must** be agreed by the DReps via an on-chain governance action with a threshold of greater than 50% of the active voting stake. +- **TREASURY-02 (x)** The budget for the Cardano Treasury **must not** exceed the net change limit for the Cardano Treasury's balance per period of time. +- **TREASURY-03 (x)** The budget for the Cardano Treasury **must** be denominated in ada. +- **TREASURY-04 (x)** Treasury withdrawals **must not** be ratified until there is a community-approved Cardano budget then in effect pursuant to a previous on-chain governance action agreed by the DReps with a threshold of greater than 50% of the active voting stake. + +### 4. GUARDRAILS AND GUIDELINES ON HARD FORK INITIATION ACTIONS + +The **hard fork initiation** action requires both a new major and a new minor protocol version to be specified. + +- As positive integers. + +As the result of a hard fork, new updatable protocol parameters may be introduced. Guardrails may be defined for these parameters, which will take effect following the hard fork. Existing updatable protocol parameters may also be deprecated by the hard fork, in which case the guardrails become obsolete for all future changes. + +#### Guardrails + +- **HARDFORK-01 (~ - no access to existing parameter values)** The major protocol version **must** be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version **must** be zero. +- **HARDFORK-02a (~ - no access to existing parameter values)** Unless the major protocol version is also changed, the minor protocol version **must** be greater than the minor version that will be enacted immediately prior to this change. +- **HARDFORK-03 (~ - no access to existing parameter values)** At least one of the protocol versions (major or minor or both) **must** change. +- **HARDFORK-04 (x)** At least 85% of stake pools by active stake **should** have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version. +- **HARDFORK-05 (x)** Any new updatable protocol parameters that are introduced with a hard fork **must** be included in this Appendix and suitable guardrails defined for those parameters. +- **HARDFORK-06 (x)** Settings for any new protocol parameters that are introduced with a hard fork **must** be included in the appropriate Genesis file. +- **HARDFORK-07 (x)** Any deprecated protocol parameters **must** be indicated in this Appendix. +- **HARDFORK-08 (~ - no access to *Plutus cost model* parameters)** New Plutus versions **must** be supported by a version-specific *Plutus cost model* that covers each primitive that is available in the new Plutus version. + +### 5. GUARDRAILS AND GUIDELINES ON UPDATE CONSTITUTIONAL COMMITTEE OR THRESHOLD ACTIONS + +**Update Constitutional Committee or Threshold** governance actions may change the size, composition, or required voting thresholds for the Constitutional Committee. + +#### Guardrails + +- **UPDATE-CC-01a (x)** **Update Constitutional Committee and/or threshold** **and/or term** governance actions **must not** be ratified until ada holders have ratified through an on-chain governance action this Constitution. + +### 6. GUARDRAILS AND GUIDELINES ON NEW CONSTITUTION OR GUARDRAILS SCRIPT ACTIONS + +New constitution or guardrails script actions change the hash of the on-chain constitution and the associated guardrails script. + +#### Guardrails + +- **NEW-CONSTITUTION-01a (x)** A **New Constitution** **or Guardrails Script** governance action **must** be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action. +- **NEW-CONSTITUTION-02 (x)** If specified, the new guardrails script must be consistent with this Constitution. + +### 7. GUARDRAILS AND GUIDELINES ON NO CONFIDENCE ACTIONS + +**No confidence** actions signal a state of no confidence in the governance system. No guardrails are imposed on **No Confidence** actions. + +#### Guardrails + +- None + +### 8. GUARDRAILS AND GUIDELINES ON INFO ACTIONS + +**Info** actions are not enacted on-chain. No guardrails are imposed on **Info** actions. + +#### Guardrails + +- None + +### 9. LIST OF PROTOCOL PARAMETER GROUPS + +The protocol parameters are grouped by type, allowing different thresholds to be set for each group. + +- **The network group consists of:** + - *maximum block body size* (*maxBlockBodySize*) + - *maximum transaction size* (*maxTxSize*) + - *maximum block header size* (*maxBlockHeaderSize*) + - *maximum size of a serialized asset value* (*maxValueSize*) + - *maximum script execution units in a single transaction* (*maxTxExecutionUnits[steps]*) + - *maximum script execution units in a single block* (*maxBlockExecutionUnits[steps]*) + - *maximum number of collateral inputs* (*maxCollateralInputs*) + +- **The economic group consists of:** + - *minimum fee coefficient* (*txFeePerByte*) + - *minimum fee constant* (*txFeeFixed*) + - *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*) + - *delegation key Lovelace deposit* (*stakeAddressDeposit*) + - *pool registration Lovelace deposit* (*stakePoolDeposit*) + - *monetary expansion* (*monetaryExpansion*) + - *treasury expansion* (*treasuryCut*) + - *minimum fixed rewards cut for pools* (*minPoolCost*) + - *minimum Lovelace deposit per byte of serialized UTxO* (*coinsPerUTxOByte*) + - *prices of Plutus execution units* (*executionUnitPrices[priceSteps/priceMemory]*) + +- **The technical group consists of:** + - *pool pledge influence* (*poolPledgeInfluence*) + - *pool retirement maximum epoch* (*poolRetireMaxEpoch*) + - *desired number of pools* (*stakePoolTargetNum*) + - *Plutus execution cost models* (*costModels*) + - *proportion of collateral needed for scripts* (*collateralPercentage*) + +- **The governance group consists of:** + - *governance voting thresholds* (*dRepVotingThresholds[...], poolVotingThresholds[...]*) + - *governance action maximum lifetime in epochs* (*govActionLifetime*) + - *governance action deposit* (*govActionDeposit*) + - *DRep deposit amount* (*dRepDeposit*) + - *DRep activity period in epochs* (*dRepActivity*) + - *minimal constitutional committee size* (*committeeMinSize*) + - *maximum term length (in epochs) for the constitutional committee members* (*committeeMaxTermLength*) \ No newline at end of file diff --git a/CommunityDrafts/Jane.md b/CommunityDrafts/Jane.md new file mode 100644 index 0000000..3529e34 --- /dev/null +++ b/CommunityDrafts/Jane.md @@ -0,0 +1,969 @@ + +# The Cardano Constitution + +## PREAMBLE + +The Cardano blockchain is a software protocol enabling development of contracts, applications, and digital assets in a permissionless, decentralized manner. Cardano, named for 16th century mathematician Girolamo Cardano, was launched in Japan in 2017. Its three pioneering founders, Input Output Hong Kong, Emurgo, and Cardano Foundation, chose peer review as a method to develop an open-source blockchain that is secure, scalable, and decentralized. + +Early on-chain governance utilized on-chain parameters as well as off-chain decisions made by majority vote of the founders, who held seven genesis keys allowing them to make agreed changes to the protocol. The founders took input on Cardano’s development from scientists, academic experts, developers, and many others, including holders of ADA, the native currency of the blockchain. From creation of Cardano’s whitepaper, the aim was to fully decentralize governance. + +On September __, 2024, an important milestone was realized when the genesis keys were turned over to community members all over the world, elected to its first Constitutional Committee. The goal of this Constitution is to set forth a governance framework which will keep the Cardano blockchain ecosystem alive, and thriving, for generations to come. + +## Article 1 - PRINCIPLES + +### Section 1 + +These principles are important to the community for the maintenance and growth of the Cardano blockchain, and proposed governance actions shall be evaluated in accordance with them. + +- The Cardano blockchain ecosystem has the right to exist. In order for it to thrive, governance actions should strive to improve the scale, efficiency, and speed of transactions, without unduly compromising security and decentralization. +- The cost of transactions on the Cardano Blockchain should be based upon an accessible, and predictable pricing model. +- The Cardano Blockchain should promote interoperability with other blockchain protocols including sidechains and partnerchains. +- The Cardano Blockchain shall strive always to preserve all transactions on the blockchain and their accompanying on-chain information. +- The Cardano Blockchain shall maintain a Treasury of ADA governed in accordance with this document. +- The Cardano Blockchain should promote efficient design, memory, and storage. +- The Cardano blockchain shall continue to utilize ADA as its base currency. +- The Cardano blockchain shall take no action to abridge the current supply of ADA of 45 billion tokens. +- The Cardano blockchain shall take no action to remove the right of ADA holders to hold ADA in their own wallets in an unlocked manner, without the consent of such ADA holders. +- Unless otherwise agreed in an amendment to this Constitution, the Cardano blockchain shall continue to operate via proof-of-stake consensus mechanism, but may partner with chains operating with proof-of-work or other consensus mechanisms. + +### Section 2 + +The Cardano Blockchain shall operate in accordance with the Cardano Blockchain Guardrails as set forth in Article VII. The Cardano community may digitally codify Cardano Blockchain Guardrails to allow their implementation on the blockchain using on-chain scripts or built-in ledger rules. Where possible, on-chain implementation is desired and encouraged. + +In the event of inconsistency between a Guardrail in this Constitution and a Guardrail programmed and implemented on the blockchain, the version deployed on the blockchain shall prevail and the Constitutional Committee shall seek to reconcile such inconsistency through on-chain governance action. + +## Article II - THE CARDANO BLOCKCHAIN COMMUNITY + +### Section 1 + +No formal membership shall be required to hold ADA or participate in the Cardano Blockchain ecosystem. All owners of ADA are beneficiaries of the Cardano Blockchain ecosystem. + +### Section 2 + +Members of the Cardano community who own ADA are entitled to access and participate in the on-chain decision-making processes of the blockchain ecosystem, either directly or through the appointment of delegates in accordance with this Constitution, including voting in accordance with this Constitution. + +## Article III - GOVERNANCE FRAMEWORK + +### Section 1 + +The Cardano Blockchain ecosystem shall utilize a decentralized, on-chain governance model for decision on changes to the blockchain or its governance, using, to the extent possible and beneficial, programmable “smart” contracts and other blockchain-based tools to facilitate decision-making and ensure transparency. On-chain voting for governance actions shall follow the processes outlined in this Constitution. + +### Section 2 + +Three governance bodies have been created to participate in voting on the Cardano Blockchain. These consist of Delegated Representatives (DReps), Stake Pool Operators (SPOs), and the Constitutional Committee (CC). Acting as a member of more than one of these groups fosters centralization, and could result in conflicts of interest to the detriment of the blockchain. Therefore, governance actions are favored which discourage the same parties from holding more than one position in governance, or which allow parties to disclose potential conflicts, and abstain from potentially conflicting votes. + +DReps, SPOs, and Constitutional Committee members may be individual ADA holders or ADA holders who have organized as a group. + +DReps, SPOs, and Constitutional Committee members will necessarily be required to incur transaction fees for voting. It shall not be unconstitutional for the community to vote for reimbursement for such fees or to compensate for the time expended to act as a DRep so long as allocation for such is made within an approved budget. + +### Section 3 + +On-chain governance decisions shall be made through a collective decision-making process, with specific consensus threshold requirements as required by Article VII of this Constitution, the Cardano Blockchain Guardrails. All on-chain governance actions shall be voted upon in accordance with such Guardrails. + +Except as set forth in the Interim Period Guardrails of Article VII, every governance vote must be ratified by two of the three governance bodies, by the percentages specified in this Constitution. + +### Section 4 + +A special form of governance action exists to gauge community sentiment without committing to on-chain change of the Cardano Blockchain. These "info" actions have no on-chain effect other than to record the outcome of a vote on the blockchain. + +### Section 5 + +Any proposed on-chain governance action shall require a standardized and legible format including a URL and hash linked to documented off-chain content. Rationale shall be provided to justify the requested change to the blockchain. The rationale shall include, at a minimum, a title, abstract, reason for the proposal, and relevant supporting materials. + +Any governance action proposal reaching the on-chain governance stage shall be identical in content as to the final off-chain version of such governance action proposal. + +“Hard Fork Initiation” and “Protocol Parameter Change” governance actions shall undergo technical review and scrutiny as mandated by the Guardrails to ensure that the governance action does not endanger the security, functionality, or performance of the Cardano Blockchain. On-chain governance actions should address their expected impact on the blockchain ecosystem. + +### Section 6 + +The Cardano community is expected to propose, not less than on an annual basis, (nor more than on a ___ basis?) a budget for the ongoing maintenance and future development of the Cardano Blockchain. The budget shall be voted on through on-chain voting. No withdrawals from the Cardano treasury shall be permitted unless a budget for the Cardano Blockchain is then in effect. + +[Any governance action requesting ADA from the Cardano Blockchain treasury in excess of [1,000,000] ADA shall require an allocation of ADA as a part of such funding request to cover the cost of periodic independent audits and the implementation of oversight metrics as to the use of such ADA.] [Contractual obligations governing the use of ADA received from the Cardano Blockchain treasury pursuant to a Cardano budget in excess of [1,000,000] shall include dispute resolution provisions.]? + +## Article IV - DELEGATED REPRESENTATIVES + +### Section 1 + +In order to participate in on-chain voting, owners of ADA must either register as DReps to directly vote on governance actions, or delegate their voting rights to other registered DReps who shall vote on their behalf. + +### Section 2 + +Any owner of ADA shall have the option to register as a DRep. Any owner of ADA shall be allowed to delegate their voting stake to one or more registered DReps, including themselves. DReps may be individuals or coordinated groups. DReps are entitled to cast votes directly for on-chain governance actions and represent those ADA holders delegating their voting rights to them. This voting system shall enshrine a liquid democracy model where owners of ADA can seamlessly select among DReps, register as a DRep, and change their delegation at any time. + +### Section 3 + +DReps may choose to adopt codes of conduct governing their activities as DReps and make such codes of conduct publicly available. However, codes of conduct are not expressly required, and it is hoped that any code of conduct which may be adopted will consider the enforceability of it in global jurisdictions, as well as the goals set forth in this document. + +### Section 4 + +DReps shall have the power to act as a check on the power of the Constitutional Committee under exceptional circumstances by voting on "Motion of no-confidence" and "Update committee/threshold" governance actions, as described in this document. + +## Article V - STAKE POOL OPERATORS + +### Section 1 + +A Stake Pool Operator (SPO) is an individual or entity responsible for operating a stake pool, which participates in the consensus mechanism of the Cardano Blockchain. SPOs shall have a specific role in approving critical on-chain governance actions which require additional oversight and independence, voting as set forth in this Constitution. SPOs shall participate in hard fork initiation processes as the operators of the nodes that participate in Cardano Blockchain’s consensus mechanism. + +### Section 2 + +SPOs shall have the power to act as a check on the power of the Constitutional Committee under exceptional circumstances by voting on "Motion of no-confidence" and "Update committee/threshold" governance actions, as described in this document. + +## Article VI - CONSTITUTIONAL COMMITTEE + +### Section 1 + +A Constitutional Committee shall be established to ensure that governance actions are consistent with this Constitution. The Constitutional Committee shall comprise owners of ADA responsible for ensuring that on-chain governance actions prior to enactment on-chain, are constitutional. The Constitutional Committee shall be limited to voting on the constitutionality of governance actions. + +### Section 2 + +The Constitutional Committee shall be formed in accordance with this Constitution, and members shall serve terms such terms in accordance with this Constitution, provided that terms shall not be less than one year unless otherwise approved by voting on chain. To assure continuity in the operation of the Constitutional Committee, the terms for Constitutional Committee members shall be staggered. Where a motion of no confidence requires immediate replacement of Constitutional Committee members, the end dates of each term shall be maintained for the incoming members, unless otherwise agreed. + +### Section 3 + +Election of members to the Constitutional Committee shall take place in accordance with the requirements of this Constitution. + +### Section 4 + +No governance action, other than a "Motion of no-confidence" or "Update constitutional committee/threshold" may be implemented on-chain unless the Constitutional Committee shall have first determined and affirmed through an on-chain action that such proposal does not violate this Constitution. + +The Constitutional Committee shall be considered to be in one of the following two states at all times: a state of confidence or a state of no-confidence. In a state of no-confidence, members of the then standing Constitutional Committee must be reinstated or replaced using the "Update committee/threshold" governance action before any other on-chain governance action may go forward. + +### Section 5 + +The Constitutional Committee shall publish each decision. When voting against a proposal, a member shall set forth the basis for its decision with reference to specific Articles of this Constitution that are in conflict with a given proposal. + +## Article VII - BLOCKCHAIN GUARDRAILS + +### Section 1 + +To implement Cardano Blockchain on-chain governance it is necessary to establish guardrails that will enable the Cardano Blockchain to continue to operate in a secure and sustainable way. + +These guardrails apply to the Cardano Blockchain Layer 1 mainnet environment. They are not intended to apply to test environments or to other blockchains that use the Cardano Blockchain software. + +Not all parameters for the Cardano Blockchain can be considered independently. Some parameters interact with other settings in an intrinsic way. Where known, these interactions are addressed herein. While the guardrails presently reflect the current state of technical insight, this Article should be treated as a living document. Implementation improvements, new simulations or performance evaluation results for the Cardano Blockchain may allow some of the restrictions contained in these guardrails to be relaxed (or, in some circumstances, require them to be tightened) in due course. + +Additional guardrails may also be needed where, for example, new protocol parameters are introduced. + +The guardrails set forth in this Article may be amended pursuant to an on-chain governance action that satisfies the applicable voting threshold as set forth in this Constitution. Any such amendment to any guardrails shall require and be deemed to be an amendment to the Constitution itself. + +**Terminology and Guidance** + +- **Should/Should not**: Where this Article says that a value "should not" be set below or above some value, this means that the guardrail is a recommendation or guideline, and the specific value could be open to discussion or alteration by a suitably expert group recognized by the Cardano community in light of experience with the Cardano Blockchain governance system or the operation of the Cardano Blockchain. + +- **Must/Must not**: Where this Article says that a value "must not" be set below or above some value, this means that the guardrail is a requirement that will be enforced by Cardano Blockchain ledger rules, types, or other built-in mechanisms where possible, and that if not followed could cause a protocol failure, security breach, or other undesirable outcome. + +- **Benchmarking**: Benchmarking refers to careful system-level performance evaluation that is designed to show a-priori that, for example, 95% of blocks will be diffused across a global network of Cardano Blockchain nodes within the required 5s time interval in all cases. This may require construction of specific test workflows and execution on a large test network of Cardano nodes, simulating a global Cardano Blockchain network. + +- **Performance analysis**: Performance analysis refers to projecting theoretical performance, empirical benchmarking, or simulation results to predict actual system behavior. For example, performance results obtained from tests in a controlled test environment (such as a collection of data centers with known networking properties) may be extrapolated to inform likely performance behavior in a real Cardano Blockchain network environment. + +- **Simulation**: Simulation refers to synthetic execution that is designed to inform performance/functionality decisions in a repeatable way. For example, the IOSim Cardano Blockchain module allows the operation of the networking stack to be simulated in a controlled and repeatable way, allowing issues to be detected before code deployment. + +- **Performance Monitoring**: Performance monitoring involves measuring the actual behavior of the Cardano Blockchain network, for example, by using timing probes to evaluate round-trip times, or test blocks to assess overall network health. It complements benchmarking and performance analysis by providing information about actual system behavior that cannot be obtained using simulated workloads or theoretical analysis. + +- **Reverting Changes**: Where performance monitoring shows that actual network behavior following a change is inconsistent with the performance requirements for the Cardano Blockchain, then the change must be reverted to its previous state if that is possible. For example, if the block size is increased from 100KB to 120KB and 95% of blocks are no longer diffused within 5s, then a change must be made to revert the block size to 100KB. If this is not possible, then one or more alternative changes must be made that will ensure that the performance requirements are met. + +- **Severity Levels**: Issues that affect the Cardano Blockchain network are classified by severity level, where: + - Severity 1 is a critical incident or issue with very high impact to the security, performance, or functionality of the Cardano Blockchain network. + - Severity 2 is a major incident or issue with significant impact to the security, performance, or functionality of the Cardano Blockchain network. + - Severity 3 is a minor incident or issue with low impact to the security, performance, or functionality of the Cardano Blockchain network. + +- **Future Performance Requirements**: Planned development such as new mechanisms for out-of-memory storage may impact block diffusion or other times. When changing parameters, it is necessary to consider these future performance requirements as well as the current operation of the Cardano Blockchain. Until development is complete, the requirements will be conservative; they may then be relaxed to account for actual timing behavior. + +**Automated Checking ("Guardrails Script")** + +A script hash is associated with the constitution hash when a New Constitution or Guardrails Script governance action is enacted. It acts as an additional safeguard to the ledger rules and types, filtering non-compliant governance actions. + +The guardrails script only affects two types of governance actions: + +- Parameter Update actions, and +- Treasury Withdrawal actions. + +The script is executed when either of these types of governance action is submitted on-chain. This avoids scenarios where, for example, an erroneous script could prevent the chain from ever enacting a Hard Fork action, resulting in deadlock. There are three different situations that apply to script usage. + +**Symbol and Explanation** + +- (y) The script can be used to enforce the guardrail. +- (x) The script cannot be used to enforce the guardrail. +- (~ - reason) The script cannot be used to enforce the guardrail for the reason given, but future ledger changes could enable this. + +Guardrails may overlap: in this case, the most restrictive set of guardrails will apply. + +Where a parameter is not explicitly listed in this document, then the script must not permit any changes to the parameter. + +Conversely, where a parameter is explicitly listed in this document but no checkable guardrails are specified, the script must not impose any constraints on changes to the parameter. + +## 2. Guardrails and Guidelines on Protocol Parameter Update Actions + +Below are guardrails and guidelines for changing updatable protocol parameter settings via the protocol parameter update governance action such that the Cardano Blockchain is never in an unrecoverable state as a result of such changes. + +Note that there are at least five different sources of parameter names, and these are not always consistent: + +- The name used in the Genesis file +- The name used in protocol parameter update governance actions +- The name used internally in ledger rules +- The name used in the formal ledger specification +- The name used in research papers + +Where these parameter names differ, this Article uses the second convention. + +### Guardrails + +- **PARAM-01 (y)**: Any protocol parameter that is not explicitly named in this document must not be changed by a Parameter update governance action. +- **PARAM-02 (y)**: Where a protocol parameter is explicitly listed in this document but no checkable guardrails are specified, the guardrails script must not impose any constraints on changes to the parameter. Checkable guardrails are shown by a (y). + +### 2.1. Critical Protocol Parameters + +The below protocol parameters are critical from a security point of view. + +#### Parameters that are Critical to the Operation of the Blockchain + +- Maximum block body size (`maxBlockBodySize`) +- Maximum transaction size (`maxTxSize`) +- Maximum block header size (`maxBlockHeaderSize`) +- Maximum size of a serialized asset value (`maxValueSize`) +- Maximum script execution/memory units in a single block (`maxBlockExecutionUnits[steps/memory]`) +- Minimum fee coefficient (`txFeePerByte`) +- Minimum fee constant (`txFeeFixed`) +- Minimum fee per byte for reference scripts (`minFeeRefScriptCoinsPerByte`) +- Minimum Lovelace deposit per byte of serialized UTxO (`utxoCostPerByte`) +- Governance action deposit (`govDeposit`) + +#### Guardrails + +- **PARAM-03 (y)**: Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs must say "yes" with a collective support of more than 50% of all active block production stake. This is enforced by the guardrails on the stake pool voting threshold. +- **PARAM-04 (x)**: At least 3 months should normally pass between the publication of an off-chain proposal to change a critical protocol parameter and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation. + +#### Parameters that are Critical to the Governance System + +- Delegation key Lovelace deposit (`stakeAddressDeposit`) +- Pool registration Lovelace deposit (`stakePoolDeposit`) +- Minimum fixed rewards cut for pools (`minPoolCost`) +- DRep deposit amount (`dRepDeposit`) +- Minimal Constitutional Committee size (`committeeMinSize`) +- Maximum term length (in epochs) for the Constitutional Committee members (`committeeMaxTermLimit`) + +#### Guardrails + +- **PARAM-05 (y)**: DReps must vote "yes" with a collective support of more than 50% of all active voting stake. This is enforced by the guardrails on the DRep voting thresholds. +- **PARAM-06 (x)**: At least 3 months should normally pass between the publication of an off-chain proposal to change a parameter that is critical to the governance system and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation. + +### 2.2. Economic Parameters + +The overall goals when managing economic parameters are to: + +- Enable long-term economic sustainability for the Cardano Blockchain ecosystem; +- Ensure that stake pools are adequately rewarded for maintaining the Cardano Blockchain; +- Ensure that ADA holders are adequately rewarded for using stake in constructive ways, including when delegating ADA for block production; and +- Balance economic incentives for different Cardano Blockchain ecosystem stakeholders, including but not limited to Stake Pool Operators, ADA holders, DeFi users, infrastructure users, developers (e.g., DApps), and financial intermediaries (e.g., exchanges). + +#### Triggers for Change + +- Significant changes in the fiat value of ADA resulting in potential problems with security, performance, or functionality. +- Changes in transaction volumes or types. +- Community requests or suggestions. +- Emergency situations that require changes to economic parameters. + +#### Counter-indicators + +Changes to the economic parameters should not be made in isolation. They need to account for: + +- External economic factors. +- Network security concerns. + +#### Core Metrics + +- Fiat value of ADA resulting in potential problems with security, performance, or functionality. +- Transaction volumes and types. +- Number and health of stake pools. +- External economic factors. + +#### Changes to Specific Economic Parameters + +**Transaction fee per byte (`txFeePerByte`) and fixed transaction fee (`txFeeFixed`)** + +Defines the cost for basic transactions in Lovelace: +`fee(tx) = txFeeFixed + txFeePerByte * nBytes(tx)` + +**Guardrails** + +- **TFPB-01 (y):** `txFeePerByte` must not be lower than 30 (0.000030 ADA). This protects against low-cost denial of service attacks. +- **TFPB-02 (y):** `txFeePerByte` must not exceed 1,000 (0.001 ADA). This ensures that transactions can be paid for. +- **TFPB-03 (y):** `txFeePerByte` must not be negative. +- **TFF-01 (y):** `txFeeFixed` must not be lower than 100,000 (0.1 ADA). This protects against low-cost denial of service attacks. +- **TFF-02 (y):** `txFeeFixed` must not exceed 10,000,000 (10 ADA). This ensures that transactions can be paid for. +- **TFF-03 (y):** `txFeeFixed` must not be negative. +- **TFGEN-01 (x - "should"):** To maintain a consistent level of protection against denial-of-service attacks, `txFeeFixed` and `txFeePerByte` should be adjusted whenever Plutus Execution prices are adjusted (`executionUnitPrices[steps/memory]`). +- **TFGEN-02 (x - unquantifiable):** Any changes to `txFeeFixed` or `txFeePerByte` must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee so that it becomes impossible to construct a transaction. + +**UTxO cost per byte (`utxoCostPerByte`)** + +Defines the cost for storage in UTxOs: + +- Sets a minimum threshold on ADA that is held within a single UTxO (~1 ADA minimum, could be >= 50 ADA in the worst case). +- Provides protection against low-cost denial of service attack on UTxO storage. This attack has been executed on other chains; it is not theoretical. +- DoS protection decreases in line with the free node memory (proportional to UTxO growth). +- Helps reduce long-term storage costs. +- Provides an incentive to return UTxOs when no longer needed. +- Should significantly exceed minimum tx cost (~0.15 ADA). + +**Guardrails** + +- **UCPB-01 (y):** `utxoCostPerByte` must not be lower than 3,000 (0.003 ADA). +- **UCPB-02 (y):** `utxoCostPerByte` must not exceed 6,500 (0.0065 ADA). +- **UCPB-03 (y):** `utxoCostPerByte` must not be zero. +- **UCPB-04 (y):** `utxoCostPerByte` must not be negative. +- **UCPB-05 (x - "should"):** Changes should account for: + - i) The acceptable cost of attack. + - ii) The acceptable time for an attack (at least one epoch is assumed). + - iii) The acceptable memory configuration for full node users (assumed to be 16GB for wallets or 24GB for stake pools). + - iv) The sizes of UTxOs (~200B per UTxO minimum, up to about 10KB). + - v) The current total node memory usage. + +**Stake address deposit (`stakeAddressDeposit`)** + +Ensures that stake addresses are retired when no longer needed: + +- Helps reduce long-term storage costs. +- Helps limit CPU and memory costs in the ledger. +- The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Reducing the number of active stake addresses also reduces processing and memory costs at the epoch boundary when calculating stake snapshots. + +**Guardrails** + +- **SAD-01 (y):** `stakeAddressDeposit` must not be lower than 1,000,000 (1 ADA). +- **SAD-02 (y):** `stakeAddressDeposit` must not exceed 5,000,000 (5 ADA). +- **SAD-03 (y):** `stakeAddressDeposit` must not be negative. + +**Stake pool deposit (`stakePoolDeposit`)** + +Ensures that stake pools are retired by the stake pool operator when no longer needed by them: + +- Helps reduce long-term storage costs. +- The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Rewards and stake snapshot calculations are also impacted by the number of active stake pools. + +**Guardrails** + +- **SPD-01 (y):** `stakePoolDeposit` must not be lower than 250,000,000 (250 ADA). +- **SPD-02 (y):** `stakePoolDeposit` must not exceed 500,000,000 (500 ADA). +- **SPD-03 (y):** `stakePoolDeposit` must not be negative. + +**Minimum Pool Cost (`minPoolCost`)** + +Part of the rewards mechanism: + +- The minimum pool cost is transferred to the pool rewards address before any delegator rewards are paid. + +**Guardrails** + +- **MPC-01 (y):** `minPoolCost` must not be negative. +- **MPC-02 (y):** `minPoolCost` must not exceed 500,000,000 (500 ADA). +- **MPC-03 (x - "should"):** `minPoolCost` should be set in line with the economic cost for operating a pool. + +**Treasury Cut (`treasuryCut`)** + +Part of the rewards mechanism: + +- The treasury cut portion of the monetary expansion is transferred to the treasury before any pool rewards are paid. +- Can be set in the range 0.0-1.0 (0%-100%). + +**Guardrails** + +- **TC-01 (y):** `treasuryCut` must not be lower than 0.1 (10%). +- **TC-02 (y):** `treasuryCut` must not exceed 0.3 (30%). +- **TC-03 (y):** `treasuryCut` must not be negative. +- **TC-04 (y):** `treasuryCut` must not exceed 1.0 (100%). +- **TC-05 (~ - no access to change history):** `treasuryCut` must not be changed more than once in any 36-epoch period (approximately 6 months). + +**Monetary Expansion Rate (`monetaryExpansion`)** + +Part of the rewards mechanism: + +- The monetary expansion controls the amount of reserves that is used for rewards each epoch. +- Governs the long-term sustainability of Cardano. +- The reserves are gradually depleted until no rewards are supplied. + +**Guardrails** + +- **ME-01 (y):** `monetaryExpansion` must not exceed 0. +- **ME-02 (y):** `monetaryExpansion` must not be lower than 0. +- **ME-03 (y):** `monetaryExpansion` must not be negative. +- **ME-04 (x - "should"):** `monetaryExpansion` should not be varied by more than +/- 10% in any 73-epoch period (approximately 12 months). +- **ME-05 (x - "should"):** `monetaryExpansion` should not be changed more than once in any 36-epoch period (approximately 6 months). + +**Plutus Script Execution Prices (`executionUnitPrices[priceSteps/priceMemory]`)** + +Defines the fees for executing Plutus scripts: + +- Gives an economic return for Plutus script execution. +- Provides security against low-cost DoS attacks. + +**Guardrails** + +- **EIUP-PS-01 (y):** `executionUnitPrices[priceSteps]` must not exceed 2,000 / 10,000,000. +- **EIUP-PS-02 (y):** `executionUnitPrices[priceSteps]` must not be lower than 500 / 10,000,000. +- **EIUP-PM-01 (y):** `executionUnitPrices[priceMemory]` must not exceed 2,000 / 10,000. +- **EIUP-PM-02 (y):** `executionUnitPrices[priceMemory]` must not be lower than 400 / 10,000. +- **EIUP-GEN-01 (x - "similar to"):** The execution prices must be set so that: + - i) the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum-sized non-script transaction and + - ii) the cost of executing a transaction with maximum memory units is similar to the cost of a maximum-sized non-script transaction. +- **EIUP-GEN-02 (x - "should"):** The execution prices should be adjusted whenever transaction fees are adjusted (`txFeeFixed/txFeePerByte`). The goal is to ensure that the processing delay is similar for "full" transactions, regardless of their type. + +This helps ensure that the requirements on block diffusion/propagation times are met. + +**Transaction fee per byte for a reference script (`minFeeRefScriptCoinsPerByte`)** + +Defines the cost for using Plutus reference scripts in Lovelace. + +**Guardrails** + +- **MFRS-01 (y):** `minFeeRefScriptCoinsPerByte` must not exceed 1,000 (0.001 ADA). This ensures that transactions can be paid for. +- **MFRS-02 (y):** `minFeeRefScriptCoinsPerByte` must not be negative. +- **MFRS-03 (x - "should"):** To maintain a consistent level of protection against denial-of-service attacks, `minFeeRefScriptCoinsPerByte` should be adjusted whenever Plutus Execution prices are adjusted (`executionUnitPrices[steps/memory]`) and whenever `txFeeFixed` is adjusted. +- **MFRS-04 (x - unquantifiable):** Any changes to `minFeeRefScriptCoinsPerByte` must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee. + +### 2.3. Network Parameters + +The overall goals when managing the Cardano Blockchain network parameters are to: + +- Match the available Cardano Blockchain Layer 1 network capacity to current or future traffic demands, including payment transactions, layer 1 DApps, sidechain management, and governance needs. +- Balance traffic demands for different user groups, including payment transactions, minters of Fungible/Non-Fungible Tokens, Plutus scripts, DeFi developers, Stake Pool Operators, and voting transactions. + +**Triggers for Change** + +Changes to network parameters may be triggered by: + +- Measured changes in traffic demands over a 2-epoch period (10 days). +- Anticipated changes in traffic demands. +- Community requests. + +**Counter-indicators** + +Changes may need to be reversed and/or should not be enacted in the event of: + +- Excessive block propagation delays. +- Stake pools being unable to handle traffic volume. +- Scripts being unable to complete execution. + +**Core Metrics** + +All decisions on parameter changes should be informed by: + +- Block propagation delay profile. +- Traffic volume (block size over time). +- Script volume (size of scripts and execution units). +- Script execution cost benchmarks. +- Block propagation delay/diffusion benchmarks. + +Detailed benchmarking results are required to confirm the effect of any changes on mainnet performance or behavior prior to enactment. The effects of different transaction mixes must be analyzed, including normal transactions, Plutus scripts, and governance actions. + +**Guardrails** + +- **NETWORK-01 (x - "should"):** No individual network parameter should change more than once per two epochs. +- **NETWORK-02 (x - "should"):** Only one network parameter should be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits. + +**Changes to Specific Network Parameters** + +**Block Size (`maxBlockBodySize`)** + +The maximum size of a block, in Bytes. + +**Guardrails** + +- **MBBS-01 (y):** `maxBlockBodySize` must not exceed 122,880 Bytes (120KB). +- **MBBS-02 (y):** `maxBlockBodySize` must not be lower than 24,576 Bytes (24KB). +- **MBBS-03 (x - "exceptional circumstances"):** `maxBlockBodySize` must not be decreased, other than in exceptional circumstances where there are potential problems with security, performance, or functionality. +- **MBBS-04 (~ - no access to existing parameter values):** `maxBlockBodySize` must be large enough to include at least one transaction (that is, `maxBlockBodySize` must be at least `maxTxSize`). +- **MBBS-05 (x - "should"):** `maxBlockBodySize` should be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch. +- **MBBS-06 (x - "should"):** The block size should not induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation, and benchmarking. +- **MBBS-07 (x - "unquantifiable"):** The impact of any change to `maxBlockBodySize` must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to `maxBlockBodySize` must also consider future requirements for Plutus script execution (`maxBlockExecutionUnits[steps]`) against the total block diffusion target of 3s with 95% block propagation within 5s. The limit on maximum block size may be increased in the future if this is supported by benchmarking and monitoring results. + +**Transaction Size (`maxTxSize`)** + +The maximum size of a transaction, in Bytes. + +**Guardrails** + +- **MTS-01 (y):** `maxTxSize` must not exceed 32,768 Bytes (32KB). +- **MTS-02 (y):** `maxTxSize` must not be negative. +- **MTS-03 (~ - no access to existing parameter values):** `maxTxSize` must not be decreased. +- **MTS-04 (~ - no access to existing parameter values):** `maxTxSize` must not exceed `maxBlockBodySize`. +- **MTS-05 (x - "should"):** `maxTxSize` should not be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably should be increased by 2,048 Bytes (2KB) or less per epoch. +- **MTS-06 (x - "should"):** `maxTxSize` should not exceed 1/4 of the block size. + +**Memory Unit Limits (`maxBlockExecutionUnits[memory]`, `maxTxExecutionUnits[memory]`)** + +The limit on the maximum number of memory units that can be used by Plutus scripts, either per-transaction or per-block. + +**Guardrails** + +- **MTEU-M-01 (y):** `maxTxExecutionUnits[memory]` must not exceed 40,000,000 units. +- **MTEU-M-02 (y):** `maxTxExecutionUnits[memory]` must not be negative. +- **MTEU-M-03 (~ - no access to existing parameter values):** `maxTxExecutionUnits[memory]` must not be decreased. +- **MTEU-M-04 (x - "should"):** `maxTxExecutionUnits[memory]` should not be increased by more than 2,500,000 units in any epoch. +- **MBEU-M-01 (y):** `maxBlockExecutionUnits[memory]` must not exceed 120,000,000 units. +- **MBEU-M-02 (y):** `maxBlockExecutionUnits[memory]` must not be negative. +- **MBEU-M-03 (x - "should"):** `maxBlockExecutionUnits[memory]` should not be changed (increased or decreased) by more than 10,000,000 units in any epoch. +- **MBEU-M-04 (x - unquantifiable):** The impact of any change to `maxBlockExecutionUnits[memory]` must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the diffusion/propagation time budgets, as also impacted by `maxBlockExecutionUnits[steps]`. Any increase must also consider previously agreed future requirements for the total block size (`maxBlockBodySize`) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. + +- **MEU-M-01 (~ - no access to existing parameter values):** `maxBlockExecutionUnits[memory]` must not be less than `maxTxExecutionUnits[memory]`. + +**CPU Unit Limits (`maxBlockExecutionUnits[steps]`, `maxTxExecutionUnits[steps]`)** + +The limit on the maximum number of CPU steps that can be used by Plutus scripts, either per-transaction or per-block. + +**Guardrails** + +- **MTEU-S-01 (y):** `maxTxExecutionUnits[steps]` must not exceed 15,000,000,000 (15Bn) units. +- **MTEU-S-02 (y):** `maxTxExecutionUnits[steps]` must not be negative. +- **MTEU-S-03 (~ - no access to existing parameter values):** `maxTxExecutionUnits[steps]` must not be decreased. +- **MTEU-S-04 (x - "should"):** `maxTxExecutionUnits[steps]` should not be increased by more than 500,000,000 (500M) units in any epoch (5 days). +- **MBEU-S-01 (y):** `maxBlockExecutionUnits[steps]` must not exceed 40,000,000,000 (40Bn) units. +- **MBEU-S-02 (y):** `maxBlockExecutionUnits[steps]` must not be negative. +- **MBEU-S-03 (x - "should"):** `maxBlockExecutionUnits[steps]` should not be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days). +- **MBEU-S-04 (x - unquantifiable):** The impact of the change to `maxBlockExecutionUnits[steps]` must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by `maxBlockExecutionUnits[memory]`. Any increase must also consider previously identified future requirements for the total block size (`maxBlockBodySize`) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. + +- **MEU-S-01 (~ - no access to existing parameter values):** `maxBlockExecutionUnits[steps]` must not be less than `maxTxExecutionUnits[steps]`. + +**Block Header Size (`maxBlockHeaderSize`)** + +The size of the block header. + +*Note:* Increasing the block header size may affect the overall block size (`maxBlockBodySize`). + +**Guardrails** + +- **MBHS-01 (y):** `maxBlockHeaderSize` must not exceed 5,000 Bytes. +- **MBHS-02 (y):** `maxBlockHeaderSize` must not be negative. +- **MBHS-03 (x - "largest valid header" is subject to change):** `maxBlockHeaderSize` must be large enough for the largest valid header. +- **MBHS-04 (x - "should"):** `maxBlockHeaderSize` should only normally be increased if the protocol changes. +- **MBHS-05 (x - "should"):** `maxBlockHeaderSize` should be within TCP's initial congestion window (3 or 10 MTUs). + +### 2.4. Technical/Security Parameters + +The overall goals when managing the technical/security parameters are: + +- Ensure the security of the Cardano network in terms of decentralization, protection against Sybil and 51% attacks, and protection against denial of service attacks. +- Enable changes to the Plutus language. + +**Triggers for Change** + +- Changes in the number of active SPOs. +- Changes to the Plutus language. +- Security threats. +- Community requests. + +**Counter-indicators** + +- Economic concerns, e.g., when changing the number of stake pools. + +**Core Metrics** + +- Number of stake pools. +- Level of decentralization. + +**Changes to Specific Technical/Security Parameters** + +**Target Number of Stake Pools (`stakePoolTargetNum`)** + +Sets the target number of stake pools: + +- The expected number of pools when the network is in the equilibrium state. +- Primarily a security parameter, ensuring decentralization by pool division/replication. +- Has an economic effect as well as a security effect; economic advice is also required when changing this parameter. +- Large changes in this parameter will trigger mass redelegation events. + +**Guardrails** + +- **SPTN-01 (y):** `stakePoolTargetNum` must not be lower than 250. +- **SPTN-02 (y):** `stakePoolTargetNum` must not exceed 2,000. +- **SPTN-03 (y):** `stakePoolTargetNum` must not be negative. +- **SPTN-04 (y):** `stakePoolTargetNum` must not be zero. + +**Pledge Influence Factor (`poolPledgeInfluence`)** + +Enables the pledge protection mechanism: + +- Provides protection against Sybil attack. +- Higher values reward pools that have more pledge and penalize pools that have less pledge. +- Has an economic effect as well as technical effect; economic advice is also required. +- Can be set in the range 0.0-infinity. + +**Guardrails** + +- **PPI-01 (y):** `poolPledgeInfluence` must not be lower than 0.1. +- **PPI-02 (y):** `poolPledgeInfluence` must not exceed 1.0. +- **PPI-03 (y):** `poolPledgeInfluence` must not be negative. +- **PPI-04 (x - "should"):** `poolPledgeInfluence` should not vary by more than +/- 10% in any 18-epoch period (approximately 3 months). + +**Pool Retirement Window (`poolRetireMaxEpoch`)** + +Defines the maximum number of epochs notice that a pool can give when planning to retire. + +**Guardrails** + +- **PRME-01 (y):** `poolRetireMaxEpoch` must not be negative. +- **PRME-02 (x - "should"):** `poolRetireMaxEpoch` should not be lower than 1. + +**Collateral Percentage (`collateralPercentage`)** + +Defines how much collateral must be provided when executing a Plutus script as a percentage of the normal execution cost: + +- Collateral is additional to fee payments. +- If a script fails to execute, then the collateral is lost. +- The collateral is never lost if a script executes successfully. +- Provides security against low-cost attacks by making it more expensive rather than less expensive to execute failed scripts. + +**Guardrails** + +- **CP-01 (y):** `collateralPercentage` must not be lower than 100. +- **CP-02 (y):** `collateralPercentage` must not exceed 200. +- **CP-03 (y):** `collateralPercentage` must not be negative. +- **CP-04 (y):** `collateralPercentage` must not be zero. + +**Maximum number of collateral inputs (`maxCollateralInputs`)** + +Defines the maximum number of inputs that can be used for collateral when executing a Plutus script. + +**Guardrails** + +- **MCI-01 (y):** `maxCollateralInputs` must not be lower than 1. + +**The limit on the serialized size of the Value in each output.** + +**Guardrails** + +- **MVS-01 (y):** `maxValueSize` must not exceed 12,288 Bytes (12KB). +- **MVS-02 (y):** `maxValueSize` must not be negative. +- **MVS-03 (~ - no access to existing parameter values):** `maxValueSize` must be less than `maxTxSize`. +- **MVS-04 (~ - no access to existing parameter values):** `maxValueSize` must not be reduced. +- **MVS-05 (x - "sensible output" is subject to interpretation):** `maxValueSize` must be large enough to allow sensible outputs (e.g., any existing on-chain output or anticipated outputs that could be produced by new ledger rules). + +**Plutus Cost Models (`costModels`)** + +Defines the base costs for each Plutus primitive in terms of CPU and memory units: + +- There are about 150 distinct micro-parameters in total. +- Cost models are defined for each Plutus language version. A new language version may introduce additional micro-parameters or remove existing micro-parameters. + +**Guardrails** + +- **PCM-01 (x - unquantifiable):** Cost model values must be set by benchmarking on a reference architecture. +- **PCM-02 (x - primitives and language versions aren't introduced in transactions):** The cost model must be updated if new primitives are introduced or a new Plutus language version is added. +- **PCM-03 (~ - no access to Plutus cost model parameters):** Cost model values should not be negative. +- **PCM-04 (~ - no access to Plutus cost model parameters):** A cost model must be supplied for each Plutus language version that the protocol supports. + +### 2.5. Governance Parameters + +The overall goals when managing the governance parameters are to: + +- Ensure governance stability. +- Maintain a representative form of governance as outlined herein. + +**Triggers for Change** + +Changes to governance parameters may be triggered by: + +- Community requests. +- Regulatory requirements. +- Unexpected or unwanted governance outcomes. +- Entering a state of no confidence. + +**Counter-indicators** + +Changes may need to be reversed and/or should not be enacted in the event of: + +- Unexpected effects on governance. +- Excessive Layer 1 load due to on-chain voting or excessive numbers of governance actions. + +**Core Metrics** + +All decisions on parameter changes should be informed by: + +- Governance participation levels. +- Governance behaviors and patterns. +- Regulatory considerations. +- Confidence in the governance system. +- The effectiveness of the governance system in managing necessary change. + +**Changes to Specific Governance Parameters** + +**Deposit for Governance Actions (`govDeposit`)** + +The deposit that is charged when submitting a governance action: + +- Helps to limit the number of actions that are submitted. + +**Guardrails** + +- **GD-01 (y):** `govDeposit` must not be negative. +- **GD-02 (y):** `govDeposit` must not be lower than 1,000,000 (1 ADA). +- **GD-03 (y):** `govDeposit` must not exceed 10,000,000,000,000 (10 million ADA). +- **GD-04 (x - "should"):** `govDeposit` should be adjusted in line with fiat changes. + +**Deposit for DReps (`dRepDeposit`)** + +The deposit that is charged when registering a DRep: + +- Helps to limit the number of active DReps. + +**Guardrails** + +- **DRD-01 (y):** `dRepDeposit` must not be negative. +- **DRD-02 (y):** `dRepDeposit` must not be lower than 1,000,000 (1 ADA). +- **DRD-03 (y):** `dRepDeposit` must not exceed 100,000,000,000 (100,000 ADA). +- **DRD-04 (x - "should"):** `dRepDeposit` should be adjusted in line with fiat changes. + +**DRep Activity Period (`dRepActivity`)** + +The period (as a whole number of epochs) after which a DRep is considered to be inactive for vote calculation purposes, if they do not vote on any proposal. + +**Guardrails** + +- **DRA-01 (y):** `dRepActivity` must not be lower than 13 epochs (2 months). +- **DRA-02 (y):** `dRepActivity` must not exceed 37 epochs (6 months). +- **DRA-03 (y):** `dRepActivity` must not be negative. +- **DRA-04 (~ - no access to existing parameter values):** `dRepActivity` must be greater than `govActionLifetime`. +- **DRA-05 (x - "should"):** `dRepActivity` should be calculated in human terms (2 months, etc.). + +**DRep and SPO Governance Action Thresholds (`dRepVotingThresholds[...]`, `poolVotingThresholds[...]`)** + +Thresholds on the active voting stake that is required to ratify a specific type of governance action by either DReps or SPOs: + +- Ensures legitimacy of the action. + +The threshold parameters are listed below: + +- **dRepVotingThresholds:** + - `dvtCommitteeNoConfidence` + - `dvtCommitteeNormal` + - `dvtHardForkInitiation` + - `dvtMotionNoConfidence` + - `dvtPPEconomicGroup` + - `dvtPPGovGroup` + - `dvtPPNetworkGroup` + - `dvtPPTechnicalGroup` + - `dvtTreasuryWithdrawal` + - `dvtUpdateToConstitution` + +- **poolVotingThresholds:** + - `pvtCommitteeNoConfidence` + - `pvtCommitteeNormal` + - `pvtHardForkInitiation` + - `pvtMotionNoConfidence` + - `pvtPPSecurityGroup` + +**Guardrails** + +- **VT-GEN-01 (y):** All thresholds must be greater than 50% and less than or equal to 100%. +- **VT-GEN-02 (y):** Economic, network, and technical parameter thresholds must be in the range 51%-75%. +- **VT-GEN-03 (y):** Governance parameter thresholds must be in the range 75%-90%. +- **VT-HF-01 (y):** Hard fork action thresholds must be in the range 51%-80%. +- **VT-CON-01 (y):** New Constitution or guardrails script action thresholds must be in the range 65%-90%. +- **VT-CC-01 (y):** Update Constitutional Committee action thresholds must be in the range 51%-90%. +- **VT-NC-01 (y):** No confidence action thresholds must be in the range 51%-75%. + +**Governance Action Lifetime (`govActionLifetime`)** + +The period after which a governance action will expire if it is not enacted: + +- As a whole number of epochs. + +**Guardrails** + +- **GAL-01 (y):** `govActionLifetime` must not be lower than 1 epoch (5 days). +- **GAL-03 (x - "should"):** `govActionLifetime` should not be lower than 2 epochs (10 days). +- **GAL-02 (y):** `govActionLifetime` must not exceed 15 epochs (75 days). +- **GAL-04 (x - "should"):** `govActionLifetime` should be calibrated in human terms (e.g., 30 days, two weeks) to allow sufficient time for voting, etc., to take place. +- **GAL-05 (~ - no access to existing parameter values):** `govActionLifetime` must be less than `dRepActivity`. + +**Maximum Constitutional Committee Term (`committeeMaxTermLimit`)** + +The limit on the maximum term that a committee member may serve. + +**Guardrails** + +- **CMTL-01 (y):** `committeeMaxTermLimit` must not be zero. +- **CMTL-02 (y):** `committeeMaxTermLimit` must not be negative. +- **CMTL-03 (y):** `committeeMaxTermLimit` must not be lower than 18 epochs (90 days, or approximately 3 months). +- **CMTL-04 (y):** `committeeMaxTermLimit` must not exceed 293 epochs (approximately 4 years). +- **CMTL-05 (x - "should"):** `committeeMaxTermLimit` should not exceed 220 epochs (approximately 3 years). + +**The minimum size of the Constitutional Committee (`committeeMinSize`)** + +The least number of members that can be included in a Constitutional Committee following a governance action to change the Constitutional Committee. + +**Guardrails** + +- **CMS-01 (y):** `committeeMinSize` must not be negative. +- **CMS-02 (y):** `committeeMinSize` must not be lower than 3. +- **CMS-03 (y):** `committeeMinSize` must not exceed 10. + +### 2.6. Monitoring and Reversion of Parameter Changes + +An epoch consists of 5 calendar days. All network parameter changes must be monitored carefully for no less than 2 epochs (10 days): + +- Changes must be reverted as soon as possible if block propagation delays exceed 4.5s for more than 5% of blocks over any 6-hour rolling window. +- All other parameter changes should be monitored carefully for any adverse effects on performance, security, or functionality. If such effects are observed, appropriate actions, including reversion to previous parameters, should be taken. + +A specific reversion/recovery plan must be produced for each parameter change. This plan must include: + +- Which parameters need to change and in which ways in order to return to the previous state (or a similar state). +- How to recover the network in the event of a disastrous failure. + +This plan should be followed if problems are observed following the parameter change. Note that not all changes can be reverted. Additional care must be taken when making changes to these parameters. + +### 2.7. Non-Updatable Protocol Parameters + +Some fundamental protocol parameters cannot be changed by the Protocol Parameter Update governance action. These parameters can only be changed in a new Genesis file as part of a hard fork. It is not necessary to provide specific guardrails on updating these parameters. + +## 3. Guardrails and Guidelines on Treasury Withdrawal Actions + +Treasury withdrawal actions specify the destination and amount of a number of withdrawals from the Cardano treasury. + +**Guardrails** + +- **TREASURY-01 (x):** DReps must define a net change limit for the Cardano Treasury's balance per period of time. +- **TREASURY-02 (x):** The budget for the Cardano Treasury must not exceed the net change limit for the Cardano Treasury's balance per period of time. +- **TREASURY-03 (x):** The budget for the Cardano Treasury must be denominated in ADA. +- **TREASURY-04 (x):** Treasury withdrawals must not be ratified until there is a community-approved Cardano budget then in effect pursuant to a previous on-chain governance action agreed by the DReps with a threshold of greater than 50% of the active voting stake. + +## 4. Guardrails and Guidelines on Hard Fork Initiation Actions + +The hard fork initiation action requires both a new major and a new minor protocol version to be specified: + +- As positive integers. +- As the result of a hard fork, new updatable protocol parameters may be introduced. Guardrails may be defined for these parameters, which will take effect following the hard fork. Existing updatable protocol parameters may also be deprecated by the hard fork, in which case the guardrails become obsolete for all future changes. + +**Guardrails** + +- **HARDFORK-01 (~ - no access to existing parameter values):** The major protocol version must be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version must be zero. +- **HARDFORK-02 (~ - no access to existing parameter values):** The minor protocol version must be no less than the minor version that will be enacted immediately prior to this change. +- **HARDFORK-03 (~ - no access to existing parameter values):** At least one of the protocol versions (major or minor or both) must change. +- **HARDFORK-04 (x):** At least 85% of stake pools by active stake should have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version. +- **HARDFORK-05 (x):** Any new updatable protocol parameters that are introduced with a hard fork must be included in this Article and suitable guardrails defined for those parameters. +- **HARDFORK-06 (x):** Settings for any new protocol parameters that are introduced with a hard fork must be included in the appropriate Genesis file. +- **HARDFORK-07 (x):** Any deprecated protocol parameters must be indicated in this Article. +- **HARDFORK-08 (~ - no access to Plutus cost model parameters):** New Plutus versions must be supported by a version-specific Plutus cost model that covers each primitive that is available in the new Plutus version. + +## 5. Guardrails and Guidelines on Update Constitutional Committee or Threshold Actions + +Update Constitutional Committee or Threshold governance actions may change the size, composition, or required voting thresholds for the Constitutional Committee. + +**Guardrails** + +- **UPDATE-CC-01 (x):** Update Constitutional Committee and/or threshold and/or term governance actions must not be ratified until ADA holders have ratified through an on-chain governance action the Final Constitution. + +## 6. Guardrails and Guidelines on New Constitution or Guardrails Script Actions + +New constitution or guardrails script actions change the hash of the on-chain constitution and the associated guardrails script. + +**Guardrails** + +- **NEW-CONSTITUTION-01 (x):** A New Constitution or Guardrails Script governance action must be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action. + +## 7. Guardrails and Guidelines on No Confidence Actions + +No confidence actions signal a state of no confidence in the governance system. No guardrails are imposed on No Confidence actions. + +**Guardrails** + +- None + +## 8. Guardrails and Guidelines on Info Actions + +Info actions are not enacted on-chain. No guardrails are imposed on Info actions. + +**Guardrails** + +- None + +## 9. Guardrails During the Interim Period + +**Interim Period** + +The Interim Period began with the Chang Hard-Fork on September __ 2024, and ends after a community-ratified Final Constitution is enacted on-chain. Throughout the Interim Period, technical and constitution-enforced triggers will progressively turn on governance features. + +**Interim Period Technical Rollout:** + +The Chang Hard Fork enabled three initial governance actions proposed by Cardano Improvement Proposal (CIP) 1694, and enabled the representative governance framework to be established. These actions are the "Info", "Hard-fork initiation", and "Protocol parameter changes" actions. + +ADA holders were able to register as and delegate to DReps immediately after the Chang hard fork but DRep voting will not be available, except on "Info" actions. This ensures that ADA holders have sufficient time to choose their voting delegations. SPOs are able to vote as described in CIP-1694. + +"Hard-fork initiation" and "Protocol parameter changes" actions will also be ratified by the Constitutional Committee. + +ADA holders will be able to withdraw their staking rewards as usual. + +A subsequent hard fork, ratified by the Constitutional Committee and SPOs, shortly after the Chang Hard Fork, will enable the four remaining CIP-1694 governance actions: + +- "Treasury withdrawals", +- "Motion of no-confidence", +- "Update constitutional committee and/or threshold and/or terms", and +- "New constitution or guardrails script". + +At this point, DRep voting will be enabled and staking rewards can only be withdrawn if the ADA holder has delegated their vote (including to themselves and to the pre-defined Abstain/No Confidence voting options). + +**Guardrails** + +- **INTERIM-01 (x):** To provide sufficient time for DReps to register and campaign and for ADA holders to choose their initial voting delegations, at least 18 epochs (90 days, or approximately 3 months) must elapse after the Chang hard fork before the subsequent hard fork can be ratified. Once the subsequent hard fork is enacted, DRep voting can occur as described in CIP-1694. +- **INTERIM-02 (x):** Treasury withdrawals must not be ratified until there is a community-approved Cardano Blockchain Ecosystem budget then in effect pursuant to a previous on-chain governance action. +- **INTERIM-03 (x):** Treasury withdrawals must be consistent with the community-approved Cardano Blockchain ecosystem budget(s). +- **INTERIM-04 (x):** ADA holders must have ratified the Final Constitution as specified in this Article II before ratifying any other proposed "new constitution", "update constitutional committee and/or threshold and/or terms", and "motion of no-confidence" governance actions. +- **INTERIM-05 (x):** "New guardrails script" actions that are consistent with the Interim Constitution may be ratified during the interim period, provided the Interim Constitution itself is not changed. + +## 10. List of Protocol Parameter Groups + +The protocol parameters are grouped by type, allowing different thresholds to be set for each group. + +**The network group consists of:** + +- maximum block body size (`maxBlockBodySize`) +- maximum transaction size (`maxTxSize`) +- maximum block header size (`maxBlockHeaderSize`) +- maximum size of a serialized asset value (`maxValueSize`) +- maximum script execution units in a single transaction (`maxTxExecutionUnits[steps]`) +- maximum script execution units in a single block (`maxBlockExecutionUnits[steps]`) +- maximum number of collateral inputs (`maxCollateralInputs`) + +**The economic group consists of:** + +- minimum fee coefficient (`txFeePerByte`) +- minimum fee constant (`txFeeFixed`) +- minimum fee per byte for reference scripts (`minFeeRefScriptCoinsPerByte`) +- delegation key Lovelace deposit (`stakeAddressDeposit`) +- pool registration Lovelace deposit (`stakePoolDeposit`) +- monetary expansion (`monetaryExpansion`) +- treasury expansion (`treasuryCut`) +- minimum fixed rewards cut for pools (`minPoolCost`) +- minimum Lovelace deposit per byte of serialized UTxO (`utxoCostPerByte`) +- prices of Plutus execution units (`executionUnitPrices[priceSteps/priceMemory]`) + +**The technical group consists of:** + +- pool pledge influence (`poolPledgeInfluence`) +- pool retirement maximum epoch (`poolRetireMaxEpoch`) +- desired number of pools (`stakePoolTargetNum`) +- Plutus execution cost models (`costModels`) +- proportion of collateral needed for scripts (`collateralPercentage`) + +**The governance group consists of all the new protocol parameters that are introduced in CIP-1694:** + +- governance voting thresholds (`dRepVotingThresholds[...]`, `poolVotingThresholds[...]`) +- governance action maximum lifetime in epochs (`govActionLifetime`) +- governance action deposit (`govActionDeposit`) +- DRep deposit amount (`dRepDeposit`) +- DRep activity period in epochs (`dRepActivity`) +- minimal constitutional committee size (`committeeMinSize`) +- maximum term length (in epochs) for the constitutional committee members (`committeeMaxTermLimit`) + +**Appendix II** + +### Article VIII - Amendments + +Except as otherwise provided herein, amendments to this Constitution shall be approved by on-chain governance action by the authorized governance bodies by a threshold of not less than 67% of the then active voting stake. + +Changes to the Guardrails may be made by on-chain governance action satisfying a threshold of a majority of then-active stake of voting SPOs. + +### Article IX - Dispute Resolution + +Resolving disputes in a cost-effective manner is critical to the Cardano Blockchain ecosystem. A Dispute Resolution Committee shall be established (within ninety (90) days?) after ratification of the Constitution, comprised of DReps, SPOs and members of the Constitutional Committee, with the goal of researching on-chain and off-chain dispute resolution methods suitable for blockchain, and coming up with a framework for dispute resolution for those disputes which are suitable to be resolved on-chain or with agreed off-chain procedures. Within one (1) year (?) after ratification of this Constitution on-chain, an amendment to the Constitution shall be proposed to govern dispute resolution. If no such framework is ratified, treasury withdrawals to Catalyst or to individuals or companies seeking funds to develop on the blockchain must provide details of agreed dispute resolution mechanisms as part of their proposals. The adequacy of same shall be evaluated by those voting on such proposals, and shall be a key factor in determining whether funding is provided. + +This Constitution seeks to encourage members of the Cardano blockchain community to become involved in governance. To facilitate this, it is agreed that SPOs, DReps, Constitutional Committee members and Dispute Resolution Committee members, as well as others participating in governance, shall be immune from liability and suit for actions taken in the ordinary course of their duties. This immunity shall not apply if the actions of such members are determined to fall outside the ordinary course and scope of their duties or are determined to violate criminal law in an applicable jurisdiction. Mere disagreement with the votes of such individuals is not sufficient basis for suit. \ No newline at end of file diff --git a/CommunityDrafts/KevinMohr.md b/CommunityDrafts/KevinMohr.md new file mode 100644 index 0000000..76e2cbc --- /dev/null +++ b/CommunityDrafts/KevinMohr.md @@ -0,0 +1,453 @@ +# CIP-1694: Codified Law (Draft) + +## Divided We Stand United + +The Cardano Community is dispersed throughout the world, and though historically constitutions are ratified to unite a set of people geographically, we ratify this constitution here today knowing that we may be physically, politically, and culturally divided from one another but ideologically we are united in the pursuit of a better world through blockchain technology. We use this constitution here today to prove to the world that decentralization is our strength and that we can keep our own respected beliefs while being subservient to the ethical and moral objective standards that the Cardano Blockchain has enshrined upon humanity. In this way, cryptographic technology has bridged the gap between our day-to-day subjective realities and the objectivity of ‘Code is Law'. Paradoxically, and against all common sense, we stand divided in our beliefs but united by code. The code currently infeasible to enforce or build within the blockchain is outlined throughout the rest of this document. All in hopes that we can continue to bridge subjectivity and objectivity through blockchain not only for our personal sakes, but for the sake of humanity. + +## Rules and Procedure of Cardano + +### Rule 1: Normal State Constitutional Conventions + +- **(a) In general.** The Constitutional Committee shall be considered to be in one of the following two states at all times: a state of confidence or a state of no-confidence. A constitutional convention is created by a 5/7 standing member vote. (Normal State). A constitutional convention must take place in person and the location of the convention must be announced 3 months (90 days) before the start date. + +- **(b) Who may convene a general convention.** Unless otherwise limited by superior competent authority, general convention may be convened by persons occupying positions designated in Article 1 but not sub-designated or considered an “Other” and by any representative designated by the constitutional committee concerned or empowered by a member of the committee. + +- **(c)** If new members are elected during a constitutional convention, the size of the constitutional convention cannot be increased or decreased. + +### Rule 2: State of No-Confidence Constitutional Conventions + +- **(a) In general.** In a state of no-confidence, members of the then standing Constitutional Committee must be reinstated or replaced using the "Update committee/threshold" governance action before any other governance action may go forward. A state of No-Confidence Constitutional Convention is created when a motion of no-confidence has passed. In order to elect a host (See Article 13 for hosting) to a new constitutional convention, a constitutional committee must be elected. (See Article 2 for election procedure) + +- **(b)** A state of No-Confidence Constitutional Convention does not need to be held in person. + +- **(c)** All newly elected Constitutional Committees will remain in a state of no confidence until they have passed a constitution, however, they will still have the ability to vote on constitutionality. The state of no confidence is symbolic. + +### Rule 3: Special Elections: Constitutional Committee Members who can no Longer Perform their Duty + +- **(a) In general.** A special election can be called for the following reasons: + 1. A constitutional committee member is jailed or incriminated. + 2. A constitutional committee falls below the minimum threshold (5/7) to ratify governance actions. + 3. In the case of a constitutional committee member dying. + 4. A constitutional committee member has been medically incapacitated for more than 30 days. + 5. A constitutional committee member that uses a multisig wallet no longer has enough active participants to use the multisig wallet. + 6. A constitutional committee member resigns. + +### Rule 4: Replacing the Constitutional Committee In Its Entirety + +- **(a) The text.** The constitutional committee can be replaced via a specific governance action "New Constitutional Committee", that requires the approval of both the SPOs and the DReps. + +- **(b)** It is valid to replace the CC with no CC for 36 Epochs (180 days). + +- **(c)** The constitutional committee may be replaced via a vote of no confidence for the following reasons: + - Two or more members fail to vote on a governance proposal without abstaining from the governance proposal. + +- **(d) Elements.** + _Discussion:_ The purpose of this section came from the community discussion surrounding the fact that several ICC members did not vote on the first governance action proposed by community member Hosky to rename Chang+1, Hosky. + +### Rule 5: Scope of Constitutional Committee’s Power + +- **(a) The text.** The constitutional committee is only supposed to vote on the constitutionality of governance actions. + +- **(b)** The term limit for each constitutional committee member will be 73 Epochs (365 Days). + +- **(c)** A Constitutional Committee shall be established as the branch of Cardano's on-chain governance process that ensures governance actions are consistent with this Constitution. + +- **(d)** No governance action, other than a "Motion of no-confidence" or "Update constitutional committee/threshold" may be implemented on-chain unless the Constitutional Committee shall have first determined and affirmed through an on-chain action that such proposal does not violate this Constitution. + +### Rule 6: DREP Retirement + +- **(a)** The community may vote to retire a DREP credential if the DREP has not voted on a governance action for 73 Epochs (365 Days) or has missed 15 votes consecutively. The DREP will be assumed inactive. + +### Rule 7: Identity Verification + +- **(a)** Identity verification is required through a DREP address when running or nominating someone for a governance position. +- **(b)** Identity verification is required when receiving funds in the amount outlined in Rule 20. + +### Rule 9: Ethical Limitations + +- **(a)** At this time there are no ethical limitations in place that prevent someone from being one, two, or all of the following at once: DREP, SPO, or Constitutional Committee member. Ethical limitations may go into effect subject to Rule 26. + +### Rule 10: Technical Requirements + +- **(a)** All Technical guardrails and requirements will be published here and will be updated within 2 epochs of any change. + +### Rule 11: Constitutional Committee Backup Keys + +- **(a) The text.** If a member of the Cardano Community seeks to run for a seat on the constitutional committee, they must submit a contingency plan that explains how they may transfer their keys in the case of an emergency. + +- **(b) Elements.** + _Discussion:_ During the “Meet your candidates” twitter space, hosted by Intersect, the topic of ‘How one would guarantee their transfer of their key’ came up and was asked to every candidate. The community made it clear that a contingency plan was necessary. + +- **(c) Explanation:** There are several ways one can keep their keys safe. These include through traditional means such as estate planning, DAOs, and multi-sigs. A constitutionally appropriate plan of action will be approved by the previous constitutional committee in order to guarantee the safe transfer of keys in case of emergency. + +### Rule 12: Publishing of Opinions + +- **(a) The text.** Each member of the constitutional committee is required to submit at least one (1) method in which they designate a platform to publish their opinions on why they voted a certain way. Additionally, they must have a backup platform which they will publish their opinions to in the case of the first platform no longer being viable. + +- **(b)** Every constitutional committee member is required to publish their opinions at least weekly or designate a representative to publish their opinions. + +- **(c)** If a member of the constitutional committee fails to regularly publish their opinions, then the said member must abstain from voting on the legitimacy of future governance actions until their opinions are up to date. If the committee member refuses to update their opinions, the rest of the constitutional committee reserves the right to abstain from voting on all governance actions. + +- **(d) Elements.** + _Discussion:_ During the “Meet your candidates” twitter space, hosted by Intersect, the topic of ‘How one would communicate their decisions and publish works if a member of the constitutional committee’ came up and was asked to every candidate. The community made it clear that a publishing plan was necessary. + +### Rule 13: Multiple Member Constitutional Committee Multi-sigs + +- **(a)** If a constitutional committee member uses a multisig wallet as a basis for voting and the active members of a multisig wallet fall below the minimum threshold to use the multisig wallet, then the constitutional committee member must resign or call a special election. Multisig wallets do not give the owners of the multisig authority to replace their own committee members without the consent of the community. (See Rule 3). + +- **(b) Elements.** + _Discussion:_ During the “Meet your candidates” twitter space, hosted by Intersect, the topic of ‘How one would guarantee their transfer of their key’ came up and was asked to every candidate. The community made it clear that a contingency plan was necessary. + +### Rule 14: The Transfer of Keys if an Independent Constitutional Committee Member Is Deceased, Resigns, or is Incapacitated + +- **(a)** If a constitutional committee member is controlled by one individual person and that person is to pass away, that seat cannot be transferred to another member of Cardano without either a special election or the seat’s term expiring. + +- **(b)** If a special election is not held, during the time that the seat exists without a living, capacitated, or active member, the vote for that member will be counted as ‘abstained’. + +- **(c) Elements.** + _Discussion:_ During a discussion with Adam Dean, the topic of ‘How one would handle the resignation, death, or incapacitation of an independent constitutional committee member’ it was made clear that a rule needed to be codified to clarify the limitations when it came to transferring the keys for a constitutional committee member who met the aforementioned circumstance and how such a member’s vote would be counted. + +### Rule 15: MBO’s/Legal Entity’s and Governance Actions + +- **(a)** Any MBO/Legal Entity that has an approved treasury withdrawal must fulfill all promises made by said MBO/Legal Entity concerning the withdrawal to withdraw more ADA including but not limited to the following: + 1. Any milestones the MBO has promised to reach before the end of the Epoch in which the treasury’s funds will be distributed. + 2. Any promised updates to text and code-based repositories such as Github. + 3. Any and all other forms of notification. + 4. Any promises made with undesignated or future disbursements of funds. + +- **(b) Elements.** + _Discussion:_ During the “Q&A With ICC Candidates - Public Forum” twitter space, hosted by @TitlePendnGames, the topic of ‘How one would guarantee MBO’s did not abuse their power’ came up and was asked to every candidate. The community made it clear that a contingency plan was necessary. + +### Rule 16: SPO’s & Their Role + +- **(a)** SPOs shall have a specific role in approving critical on-chain governance actions which require additional oversight and independence, voting separately and independently from DReps as set forth in the Cardano Blockchain Guardrails. SPOs shall participate in hard fork initiation processes as the operators of the nodes that participate in Cardano Blockchain’s consensus mechanism. + +### Rule 17: Term Limits + +- **(a)** No constitutional committee member may serve on the constitutional committee for more than 146 consecutive epochs. + +### Rule 18: Info Actions Effect + +- **(a)** Info Actions will have the same effect as any other governance action even if not enforced via the Cardano Blockchain. + +### Rule 19: Limitations of Appeals + +- **(a)** Appeals cannot be made to appeal a state of no confidence. + +### Rule 20: Budget Restrictions + +- **(a)** Any governance action requesting ada from the Cardano treasury in excess of 1,000,000 ADA or $10,000 USD shall require periodic independent audits by the oversight committee in charge of overseeing independent audits as outlined in Article 11. + +### Rule 21: How and When the Constitutional Committee Votes + +- **(a)** The Constitutional Committee must vote Yes, No, or Abstain on all of the following regular Governance Actions excluding an action defined as a temperature check: + - Info Actions + - Treasury Withdrawals + - Protocol Parameter Changes + - Hard Fork Initiation + - New Constitution or Guardrail Script + - Any proposal submitted where the proposer asks for the constitutional committee to vote on the constitutionality of the proposal + +- **(b)** The Constitutional Committee does not have to vote Yes, No, or Abstain on all of the following irregular actions: + - Update Committee and/or threshold and/or Actions + - Motions that the constitutional committee believes are temperature checks on other governance actions or are stated to be a temperature check by the proposer. + +- **(c)** The Constitutional Committee is forbidden from voting Yes, No, or abstain on all of the following actions: + - Motions of no Confidence + - Any proposal to reinstate a past Constitutional Committee. + - Treasury withdrawals where no specific use case for the funds has been stated. Specific use case meaning any funds that the full amount in ADA cannot be directly tied to a specific project or benefit to the community. + +- **(d)** The Constitutional Committee must vote No to the following proposals: + - Any proposal written in a language not specified in Article 6. + - Any proposal to host a constitutional convention while a constitutional convention is in progress. + +- **(e)** The Constitutional Committee must vote Yes to any of the following proposals: + - Any proposal for a constitutional convention submitted while no other constitutional convention is taking place. + - Any proposal for a constitutional convention submitted during the same epoch as another proposal for a constitutional convention. + +- **(f) Elements.** + _Discussion:_ This provision was asked for by Eastern Cardano Council Member Yuta via twitter. + _Discussion:_ Example for (c3): Funds used to pay for a specific feature such as displaying an NFT within a wallet when developing a wallet is considered detailed enough to meet the requirement but funds for NFT development within a wallet is not detailed enough. + +### Rule 22: Not Approved Governance Actions or Unconstitutional Governance Actions + +- **(a)** A governance action that is not approved by the community or deemed unconstitutional by the constitutional committee may not be resubmitted for a period of 6 Epochs. + +### Rule 23: Foreign Entity Governance Actions + +- **(a)** A governance action submitted by an organization or individual with the express intent of their proposal to affect another blockchain shall be deemed unconstitutional unless the community approves that action with a voting threshold of 75% or more. In the case of this happening, any rulings of unconstitutionality prior to the end of the vote will be reversed. + +### Rule 24: Burning and Increasing the Supply of ADA + +- **(a)** The amount of ADA total will be 45 Billion (45,000,000,000) and will not be burnt or increased in supply. + +### Rule 25: Reinstating the Constitutional Committee + +- **(a)** A Constitutional Committee may be reinstated after a vote of No-Confidence has passed for the following reasons: + - No Election to replace the Constitutional Committee has been called for within 6 Epochs (30 Days). + - An Appeal in regards to Election Procedure (Article 2) has been found valid and there would be no semblance of fairness if the election results were finalized. + - An interim constitution has not been finalized within 9 Epochs (45 days) of electing the Constitutional Committee. + - An official constitution has not been finalized within 36 Epochs (180 days). + +### Rule 26: Sunsetting Multiple Governance Roles + +- **(a)** Community Members shall not simultaneously exercise power in more than one of the DRep, SPO, and CCM roles after the date of 31 December 2025; nor shall they subvert the intent underlying this prohibition, whether through the strategic frequency or timing of role changes, or otherwise (See Punitive Article 1). + +_Elements._ +_Discussion:_ Section (a) shall go into effect on 31 December 2025, upon which date section 6 will have no force or effect. This rule was proposed in a similar form via x.com by Ken Ladd. The main article can be found here. + +## Cardano Constitution + +### Article 1: Legal Entities and Titles Within Cardano Governance + +- **(a) In general.** A legal entity is defined as a designated entity within a branch forborn through the tricameral system of Cip-1694. Legally defined entities and terms for entities at the onset of this publication consist of: + - DREP + - Self-Delegation + - Constitutional Committee - We define a constitutional committee (which represents a set of individuals or entities) as a collective responsible for ensuring that the Constitution is respected. + - Interim Constitutional Committee Member + - Retired Constitutional Committee + - Constitutional Committee Member + - SPO + - OTHER: + - MBO + - DAO (Sub-designated) + - Intersect + - Voting Platform + - Summon + - IOG + - Cardano Foundation + - Emurgo + - Node + - Traditional Legal Entity (C-Corp, S-Corp, LLC, Partnership) + +- **(b)** Three independent governance bodies shall participate in voting for on-chain governance actions to provide checks and balances for the Cardano Blockchain consisting of Delegated Representatives (DRep), Stake Pool Operators (SPO), and the Constitutional Committee (CC). + +- **(c)** On-chain governance decisions shall be made through a collective decision-making process, with specific consensus threshold requirements as required by CIP-1694. All on-chain governance actions shall be voted upon in accordance with CIP-1694, the Cardano Blockchain Guardrails, and this constitution. + +### Article 2: Election Procedure + +- **(a) In general.** A period of at least 6 Epochs will be given to notify the community of an election. During the 7th Epoch, all nominations for open seats will be collected. The community will have the next 6 proceeding Epochs (Epoch 8 - 14) to vote on the candidates. At the start of the 15th Epoch, all election results will be finalized. Results will be published and finalized within the next 2 Epochs. An appeal may be made by any member of the community before the end of the 15th Epoch. In total, elections will last 60 days. + + - An election for the Oversight Committee may be held for the following reasons: + - To Establish an Oversight Committee when an entity/MBO has met the requirements outlined in Rule 20. + - The seat held by the Oversight Committee member is up for reelection due to natural vacancy and there is a need for the oversight committee to continue to operate. + - The constitutional committee has found the actions of the Oversight Committee to be in violation of the constitution and thus may disband the Oversight Committee. + - A state of no confidence cannot be appealed as outlined under Rule 19. + + - An election for the Constitutional Committee may be held for the following reasons: + - The seat held by the constitutional committee member is up for reelection due to natural vacancy. + - The constitutional committee member has succumbed to a circumstance as outlined in Rule 3. + - The constitutional committee has reached a state of no confidence as outlined in Rule 4, section 3. + - A state of no confidence cannot be appealed as outlined under Rule 19. + +- **(b) Special Circumstances.** In the case of emergency or special circumstances, a period of at least 2 Epochs will be given to notify the community of an election. All special circumstances will follow election procedure outlined in Rule 3. + +- **(c)** All elections must occur on-chain via a designated entity such as gov.tools. A valid entity must be approved by the Constitutional Committee and voted on by DReps. + +- **(d)** Election procedure for constitutional conventions and committees will follow all constraints outlined in Rule 1, Rule 2, Rule 4, and Rule 14. + +- **(e) Elements.** + _Discussion:_ Many in the Cardano community complained of various factors such as they did not have enough time to get to know the candidates or the election was rushed. This ensures that a very minimal but effective standard is at least in place when it comes to how elections will be run in the future. + + On-chain governance, if run smoothly and correctly, creates a better form of voting than anything outside of crypto. The problem is the first election did not utilize on-chain governance to its full extent. This clarifies and sets a standard to host better elections. + +### Article 3: Appeals Procedure + +- **(a) In general.** The general appeals form that the Constitutional Committee or a designated entity by the constitutional committee has the power to review can be found here. Anyone may submit a general appeal. + +- **(b) In general.** If one wishes to seek an appeal to election results, they must exhibit all three tenants of standing as outlined under U.S. law. + +- **(c) Elements.** + _Discussion:_ The elements of standing under U.S. law are as follows: + 1. Injury in Fact + 2. Causation + 3. Redressability + + _Specifications:_ If it is found that the submitter of an election-based petition did so maliciously, fraudulently, or with ignorance of the law, they may be fined or may lose any monies in holding subject to this article. + +### Article 4: Governance Actions + +**Figure 1: Definitions & Names** + +1. Motion of no-confidence + A motion to create a state of no-confidence in the current constitutional committee +2. New constitutional committee and/or threshold and/or terms + Changes to the members of the constitutional committee and/or to its signature threshold and/or terms +3. Update to the Constitution or proposal policy + A modification to the Constitution or proposal policy, recorded as on-chain hashes +4. Hard-Fork2 Initiation + Triggers a non-backwards compatible upgrade of the network; requires a prior software upgrade +5. Protocol Parameter Changes + Any change to one or more updatable protocol parameters, excluding changes to major protocol versions ("hard forks") +6. Treasury Withdrawals + Withdrawals from the treasury +7. Info + An action that has no effect on-chain, other than an on-chain record + +- **(b)** Any governance action submitted to Ada holders for approval shall require a standardized and legible format including a URL and hash linked to any documented off-chain content. Sufficient rationale shall be provided to justify the requested change to the Cardano Blockchain. The rationale shall include, at a minimum, a title, abstract, reason for the proposal, and relevant supporting materials. + +- **(c)** Any governance action proposal reaching the on-chain governance stage shall be identical in content as to the final off-chain version of such governance action proposal. + +- **(d) Elements.** + _Discussion:_ What constitutes a governance action or the elements of a governance action are the following: + 1. The governance action is submitted by a DREP or Self-DREP. + 2. The submission meets the deposit threshold of 100,000 ADA for the governance action. + 3. The governance action must be constitutional if required to be constitutional by the constitutional committee. + +### Article 5: Changing the Size of the Constitutional Committee + +- **(a) In general.** To change the size of the constitutional committee all three governing entities within Cardano governance must approve the change through a hard fork to the chain. + +- **(b)** All 7 members of the constitutional committee must agree to the change in size. + +- **(c)** An 80% voter threshold must be met and an 80% approval rating by DREPs and Self-DREPs must be met cumulatively. + +- **(d)** SPO’s must upgrade their Nodes to approve this change. + +### Article 6: Valid Proposal Languages + +- **(a)** The official dialects of the Cardano Blockchain are English, French, Japanese, Swahili, and Spanish. All proposals must be submitted in one of these languages to be deemed constitutional. + +### Article 7: Publishing via NFT + +- **(a) Content.** After the end of the Epoch all votes and reasons for votes must be published via a Non-Fungible Token (NFT) so that the information may be publicly available for the community within two Epochs. For each governance action passed, the following must be included in the NFT: + - A summary of the decision by all opposing and supporting members. + - Any statements a constitutional committee member has made in regard to abstaining. + - The date this decision was made and when the decision will take effect. + - Any opinions or discussions by the general community on 1694.io and gov.tools must be included in the NFT. + +- **(b) Elements.** + _Discussion:_ This Article was asked for by @LifeIsFunThankU + +### Article 8: CIP’s & Hardforks + +- **(a) Content.** Hard Fork Initiation and Protocol Parameter Change governance actions should undergo sufficient technical review and scrutiny as mandated by the Cardano Blockchain Guardrails to ensure that the governance action does not endanger the security, functionality, or performance of the Cardano Blockchain. Governance actions should address their expected impact on the Cardano Blockchain ecosystem. + +### Article 9: Changing the K Parameter and Max Pool Size + +- **(a)** The K Parameter will be dictated by the following equation: + `k = ( 35bn / 500 ) = 70m` + +- **(b)** The Maximum Pool Size will be dictated by the following equation: + `Maximum pool size = (45bn - reserves)` with 45bn being an unchangeable amount both in supply and in this equation as outlined in Rule 24. + +- **(c)** The K Parameter may only be changed if it will incentivize 1% of the total supply of ADA (450 Million) to move pools or experience oversaturation. + +- **(d)** A proposal looking to change the K parameter will be considered unconstitutional if the only reason given to change the K parameter is to make more profit from staking. + +- **(e) Elements.** + _Discussion:_ As of October 2022, the value of k is 500. Previously, IOG had suggested that this value could be safely raised to 1,000, but ultimately any final decision was postponed due to three factors: + i) surveying the community did not give a conclusive result; + ii) there was an IOG operational focus on delivering Vasil capability; + iii) and there was a possibly disruptive effect on ada users delegating to pools near the current saturation level so proper planning and communicating was required. + (https://iohk.io/en/blog/posts/2022/10/27/staking-parameters-and-network-optimization-where-next-for-k-and-min-fee/) + +### Article 10: Treasury Withdrawal Procedure + +- **(a)** To withdraw from the treasury, a treasury withdrawal governance action deemed constitutional by the constitutional committee must be submitted and valid. The community must then vote on the proposal. If the proposal is approved, the proposer may withdraw funds subject to the constraints outlined in Rule 20. + +### Article 11: Oversight and Independent Audits + +- **(a) Content.** If the requested funds in ADA or USD exceed the amount outlined in Rule 20, then the funds for that project must 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. + +- **(b)** The oversight committee and the independent party must agree to a legally binding contract to start fund distribution and for the duration of the fund distribution. The oversight committee and the independent party must agree to the nature of the independent audit and whoever carries out the independent audit before fund distribution. + +- **(c)** The oversight committee must establish regular reporting dates for projects which will be carried out in the form of an independent audit and report the results of those independent audits within 2 Epochs to both the constitutional committee and to the public. + +- **(d)** Anyone who receives funding must disclose their identity to the oversight committee as outlined in Rule 7(b). + +- **(e) Elements.** + _Discussion:_ The Cardano Community has recently debated the need for an oversight committee and the concept of identity verification when it comes to large treasury withdrawals. Most notably due to a post by Richard McKraken via X in which Charles Hoskinson commented. This Article stems from that discussion. + +### Article 12: Electing the Oversight Committee + +- **(a) Content.** The oversight committee will be elected via the same procedure as outlined in Article 2. + +### Article 13: Electing a Host to a Constitutional Convention + +- **(a)** To elect a host to a constitutional convention, an info action must be submitted outlining the plan for a Constitutional Convention 120 days in advance. The community will vote on the plan and if approved, there will be an official constitutional convention. + +- **(b)** If multiple plans for hosting a constitutional convention are submitted within the same epoch, then the plan with the highest approval percentage will be deemed the legitimate constitutional convention. + +- **(c)** No Constitutional Convention may take place at the same time as another constitutional convention. + +### Article 14: Defining a Legal Entity for Treasury Withdrawals + +- **(a)** A legal entity to control treasury withdrawals may be chosen by the community via an info-action vote with an in favor threshold of at least 75%. If such an entity is chosen, the entity is fully responsible for any treasury withdrawals where the proposer has specified that entity will be in charge of their funds throughout the course of the proposal. + +- **(b)** The legal entity must ensure the following: + - All treasury withdrawals follow all legal requirements in the proposer's country(s) of origin. + - Funds are distributed fairly amongst all passed proposals. + - Proposals are subject to regular audits as outlined in Rule 20 and Article 11. + - It relinquishes control of funds if not reelected to control treasury withdrawals. + +- **(c) Elements.** + _Discussion:_ Many in the Intersect organization have expressed concern over the need to hold those who withdraw from the treasury legally accountable. After speaking with LLoyd Duhon, a financial expert and specialist within the Intersect Budget Committee via a private call, I, Kevin Mohr, decided to add this provision into the constitution. + +## Punitive Articles + +### Punitive Article 1: Failure to Disclose or Hold One Governance Role + +- **(a) Text of Statute.** + Community members have the express ethical obligation to, and thus shall prominently disclose each and any of the three roles they exercise power through. + +- **(b)** This article will go into effect after 31 December 2025. Before this article goes into effect, the community must be notified of this change via email, gov.tools, x.com, discord, telegram, forums posting, and the blockchain. The community must be notified within intervals of 1, epochs, 3 epochs, 5 epochs, 10 epochs, 20 epochs, and 40 epochs before this article goes into effect. There must be documented proof this happened otherwise this Punitive Article immediately becomes null and void. The entity responsible for carrying out this action will be a designated entity by the constitutional committee. + +- **(c) Elements.** + - That the accused willingly or unwillingly held multiple governance positions subject to the constraints of Rule 26. + - The accused sought to or failed to inform the community of holding multiple governance positions. + - The actively used these accounts after the date of 31 December 2025 for constitutionally recognized proposals + +- **(d) Maximum Punishment.** + The Maximum Punishment for violating this article is the blacklisting of all accounts associated with the said governance roles in question and a fine of up to 5000 ADA. + +- **(e) Sample Specification.** + In that __________ (personal jurisdiction data) (subject-matter jurisdiction data, if required), did, at __________, on or about _____ 20 __, while accompanying (his) (her) organization (__________), wrongfully hold multiple governance roles, and that such conduct was to the prejudice of the Cardano community. + +_Discussion:_ This rule was proposed in a similar form via x.com by Ken Ladd. The main article can be found here. + +## Bill of Rights + +### AMENDMENT I: CARDANO BLOCKCHAIN ECOSYSTEM PRINCIPLES + +The governance of Cardano will ensure that decisions are made in the best interest of the Cardano community acting in a sense like a fiduciary. The Cardano community shall uphold principles of transparency, openness, and responsible governance, promoting a culture of trust and collaboration. + +### AMENDMENT II: THE CARDANO BLOCKCHAIN COMMUNITY + +No formal membership shall be required to use, participate in, and benefit from the Cardano Blockchain. Instead, all Ada holders are beneficiaries of the Cardano Blockchain ecosystem and, as such, are collectively members of the Cardano community. All Cardano community members are accordingly beneficiaries of this Constitution, entitled to its rights, privileges, and protections. Members of the Cardano community who hold ada are entitled to access and participate in the on-chain decision-making processes of the Cardano Blockchain ecosystem, including voting and taking part in on-chain governance regarding the Cardano Blockchain. In order to participate in governance actions, holders of ada may register as DReps and directly vote on such governance actions or may delegate their voting rights to other registered DReps who shall vote on their behalf. Any Ada holder shall have the option to register as a DRep. Any Ada holder shall be allowed to delegate their voting stake to one or more registered DReps, including themselves. + +### AMENDMENT III: PARTICIPATORY GOVERNANCE + +All Ada holders shall have the right to propose changes to the governance structure of the Cardano Blockchain ecosystem in accordance with CIP-1694 and Cardano Blockchain Guardrails. All Ada holders shall have the right to ensure that the process for participating in, submitting, and voting on governance actions is open and transparent and is protected from undue influence and manipulation. + +### AMENDMENT IV: DREP CODE OF CONDUCT + +DREPs may agree to follow the DREP Code of conduct as outlined here, however, it is ultimately up to the community to decide if the behavior of a DREP is appropriate. DREPs shall never have to swear allegiance to a code of conduct. + +### AMENDMENT V: MEDICAL TYRANNY + +The Cardano Blockchain may be used to keep medical records but it shall not be used to enforce restrictions on any individual's personal medical choices. + +### AMENDMENT VI + +Transactions cannot be slowed down or censored and will be expediently served for their intended purpose. + +### AMENDMENT VII + +The cost of a transaction should be predictable and cannot be unreasonable. + +### AMENDMENT VIII + +The value and data users contribute and/or create will not be locked or processed without their consent. Users’ privacy, both in terms of their actions and their data, should be preserved. + +### AMENDMENT IX + +All members of the Cardano Community shall have the right to run for any position within governance unless guilty of a disqualifying punitive article. + +## Sources and Acknowledgments + +This document was drafted using the following material: +- CIP-1694 Github +- MCM +- DREP Code of Conduct (Nordic Cardano Community) +- Intersect Draft Constitution diff --git a/CommunityDrafts/README.md b/CommunityDrafts/README.md new file mode 100644 index 0000000..1bdb57a --- /dev/null +++ b/CommunityDrafts/README.md @@ -0,0 +1,12 @@ + +Below are links to various alternate community drafts of the Cardano Constitution. Each version represents a unique perspective and contribution from different members of the Cardano community. These drafts are part of an ongoing effort to shape the governance and future of the Cardano blockchain. When necessary, the versions were converted to markdown using gpt-4o. + +- [Cerkoryn's Version](https://github.com/Cerkoryn/draft-constitution/blob/cerkoryn-version/CONSTITUTION.md) +- [Intersect's Community Version](https://2024constitutionalconsultation.docs.intersectmbo.org/cardanos-constitution/draft-cardano-constitution) +- [Cardano Foundation's Version](https://cardanofoundation.org/blog/proposal-for-cardano-constitution) +- [Adam Dean's Version](https://github.com/Crypto2099/draft-constitution/blob/adam-dean-version/CONSTITUTION.md) +- [Kevin Mohr's Version](https://docs.google.com/document/d/1ODPsFj1wBc8NqAwdxvgwJvBIg7hAkCR5B0N-IOQx7K8/edit?tab=t.0) +- [Jane's Version](https://docs.google.com/document/u/0/d/1ZHPSvXKfZKSCzeZFshMMqL_9SWg3X-58DHkKXn0h3xU/mobilebasic) +- [Alfonso Spencer's Version](https://x.com/AlfonsoSpencer9/status/1853342796666515527) +- [Attonasi's Version](https://x.com/Attonasi/status/1858879911068303499) +- [ChatGPT's Version](https://x.com/adamKDean/status/1859795419427225689) diff --git a/CommunityDrafts/gpt-4o.md b/CommunityDrafts/gpt-4o.md new file mode 100644 index 0000000..a9ded75 --- /dev/null +++ b/CommunityDrafts/gpt-4o.md @@ -0,0 +1,137 @@ +# **Cardano Blockchain Ecosystem Constitution** + +## **Preamble** +The Cardano Blockchain is a decentralized system of technology, smart contracts, and community-driven governance. It exists to improve economic, political, and social systems for everyone, everywhere. By providing a fair and secure foundation, Cardano allows people and communities to manage their identity, value, and decision-making while enabling the creation of decentralized applications, businesses, and network communities. + +We, the Cardano Community, consist of individuals, organizations, and contributors. We follow the path of early internet and cryptocurrency pioneers who built communities using digital technologies. Guided by shared principles, we balance decentralized decision-making with accountability to maintain the security of the Cardano Blockchain. + +This Constitution provides a framework for the Cardano Community to govern itself. It ensures the Blockchain's continuity and protects the rights of its users. We invite everyone who shares our values to join us but respect the choice of those who wish to pursue other paths. + +## **Article I: Tenets and Guardrails of the Cardano Blockchain** + +### Section 1: Tenets +The following tenets guide the Cardano Community and its governance. These principles should be used to evaluate governance actions: +1. **Uninterrupted Transactions**: Transactions must not be delayed or censored and should process quickly. +2. **Fair Transaction Costs**: Transaction costs should be predictable and reasonable. +3. **Open Development**: Developers should have fair access to build and deploy applications. +4. **Fair Recognition**: Community contributions should be rewarded fairly. +5. **Consent for Value Locking**: Ada owners' assets cannot be restricted without their permission. +6. **Support for Interoperability**: The Blockchain should work well with other systems. +7. **Secure Storage**: Stored value and information must be kept safe. +8. **Efficient Use of Resources**: The Blockchain must avoid wasting resources. +9. **Equality for All Users**: All users should be treated equally while ensuring the Blockchain’s sustainability. +10. **Financial Stability**: The total supply of ada will not exceed 45 billion. + +### Section 2: Guardrails +The Blockchain will operate according to the rules in the Guardrails Appendix. In case of differences between written Guardrails and coded rules, the coded rules will take priority. The Constitutional Committee must resolve inconsistencies by promoting appropriate governance actions. + +## **Article II: The Cardano Blockchain Community** + +### Section 1: Membership +There is no formal membership requirement. Any ada owner, developer, or user of the Blockchain is part of the Cardano Community and benefits from this Constitution. + +### Section 2: Participation Rights +Ada owners can vote and take part in on-chain governance. They may also propose changes to improve the Blockchain. + +### Section 3: Responsibilities +Community members must uphold this Constitution, maintain the Blockchain, participate in governance, and resolve disputes fairly and openly. + +### Section 4: Collaboration +The Community is encouraged to work together to develop and maintain applications and form groups or organizations to support the Blockchain. + +## **Article III: Participatory and Decentralized Governance** + +### Section 1: Governance Model +The Blockchain is governed through a decentralized on-chain system that uses smart contracts for transparency and decision-making. + +### Section 2: Governance Bodies +Three groups contribute to governance: +1. **Delegated Representatives (DReps)**: Represent ada owners in governance. +2. **Stake Pool Operators (SPOs)**: Operate nodes and provide checks and balances. +3. **Constitutional Committee (CC)**: Ensures governance actions follow this Constitution. + +### Section 3: Decision-Making +Governance decisions must meet specific voting thresholds defined in the Guardrails Appendix. All governance actions require on-chain voting. + +### Section 4: Voting Rights +Ada owners can vote directly or delegate their voting rights. Those holding ada through third parties may authorize those parties to vote on their behalf. + +### Section 5: "Info" Actions +These non-binding votes allow the Community to gauge sentiment without making changes. Outcomes are recorded on the Blockchain. + +### Section 6: Proposal Transparency +Governance proposals must include clear titles, abstracts, reasons, and supporting materials. Content must match on-chain and off-chain records exactly. + +### Section 7: Off-Chain Processes +The Community is expected to maintain off-chain forums for discussions about governance actions. + +### Section 8: Budgeting +The Community must propose an annual budget for Blockchain maintenance. No treasury funds can be withdrawn without an approved budget and oversight mechanisms. + +## **Article IV: Delegated Representatives (DReps)** + +### Section 1: Role +Ada owners can register as DReps to vote directly or have others delegate their votes to them. + +### Section 2: Liquid Democracy +Owners can change their DRep delegation anytime. DReps may represent individuals or groups. + +### Section 3: Conduct +DReps should adopt and publicly share codes of conduct, including ethical guidelines. + +### Section 4: Selection Tools +The Community should create tools for evaluating and selecting DReps based on publicly available information. + +### Section 5: Compensation +DReps may be compensated for their work but must disclose any payments received. + +## **Article V: Stake Pool Operators (SPOs)** + +### Section 1: Governance Role +SPOs vote on critical governance actions and oversee security-related decisions. + +### Section 2: Checks and Balances +SPOs provide oversight for the Constitutional Committee and vote on parameter updates affecting security. + +### Section 3: Conduct +SPOs are encouraged to develop and share ethical guidelines. + +### Section 4: Dual Roles +SPOs who also act as DReps must disclose both roles before voting. + +## **Article VI: Constitutional Committee (CC)** + +### Section 1: Purpose +The CC ensures governance actions comply with this Constitution. + +### Section 2: Composition +The CC is made up of members selected by ada owners. Members serve staggered terms to ensure continuity. + +### Section 3: Election Process +The Community will define and maintain an election process for CC members. + +### Section 4: Constitutional Review +The CC must determine the constitutionality of all governance actions before they are enacted. "Info" actions cannot be blocked by the CC but may be commented on. + +### Section 5: No-Confidence States +If the CC enters a "no-confidence" state, it must be replaced or reinstated before governance actions can proceed. + +### Section 6: Transparency +The CC must publish all decisions and provide reasoning when declaring a governance action unconstitutional. + +### Section 7: Support Tools +The Community must provide tools and resources for the CC to perform its duties. + +### Section 8: Compensation +CC members may be compensated, with funds allocated in the annual Blockchain budget. + +## **Article VII: Amendments** + +### Section 1: Living Document +This Constitution may be amended to reflect changes in technology or the Community’s needs. + +### Section 2: Amendment Process +Amendments must be approved through on-chain governance with at least 67% of the active voting stake. + +### Section 3: Guardrail Amendments +Changes to Guardrails follow the thresholds defined in the Guardrails Appendix. \ No newline at end of file diff --git a/CommunityDrafts/gpt-o1-preview.md b/CommunityDrafts/gpt-o1-preview.md new file mode 100644 index 0000000..03a8fbb --- /dev/null +++ b/CommunityDrafts/gpt-o1-preview.md @@ -0,0 +1,108 @@ + +# Draft Constitution of the Cardano Blockchain + +## Preamble + +We, the participants of the Cardano Community, in recognition of the foundational efforts by Input Output Global, EMURGO, the Cardano Foundation, and in collaboration with all stakeholders, establish this Constitution to govern the Cardano Blockchain. This Constitution embodies our commitment to a decentralized, transparent, and inclusive ecosystem that empowers individuals and fosters innovation. + +## Article I: Fundamental Principles + +### Section 1: Decentralization and Participation + +The Cardano Blockchain shall be a decentralized platform where all participants have the right to use, develop, and benefit from the network without undue barriers. All owners of ADA, developers, builders, and users are recognized as participants in the Cardano Community and are entitled to its rights and protections. + +### Section 2: Inclusivity and Accessibility + +Participation in the Cardano Blockchain shall be open to all, without discrimination. The network shall strive to provide equal opportunity for all participants to contribute to and benefit from the ecosystem. + +### Section 3: Transparency and Accountability + +All governance processes, decision-making, and operations of the Cardano Blockchain shall be conducted transparently. Governance bodies and participants are accountable to the community, with regular reporting and open forums for dialogue. + +### Section 4: Security and Integrity + +The Cardano Blockchain shall prioritize the security, integrity, and sustainability of the network. Measures shall be taken to protect against malicious actions, ensure the reliability of transactions, and maintain the immutability of the ledger. + +### Section 5: Censorship Resistance + +Valid transactions shall not be unjustly censored or hindered from inclusion in the blockchain. The network shall process transactions in a fair and timely manner, promoting a permissionless environment. + +### Section 6: Ownership and Privacy + +Participants have the exclusive right to control their assets and data through secure cryptographic means. The network shall respect the privacy of users, collecting only necessary data and obtaining consent for any additional information. + +### Section 7: Interoperability and Innovation + +The Cardano Blockchain shall encourage interoperability and composability, fostering collaboration and innovation both within the network and with external systems, provided such interactions do not compromise security or integrity. + +## Article II: Governance Structure + +### Section 1: Participatory Governance + +The Cardano Blockchain shall be governed through a decentralized, on-chain governance model utilizing blockchain-based tools to facilitate decision-making and ensure transparency. All ADA holders have the right to participate in governance actions, including proposing changes and voting. + +### Section 2: Governance Bodies + +Governance shall be conducted through the collaboration of the following bodies: + +- **Delegated Representatives (DReps):** Individuals or entities chosen by ADA holders to represent their interests in governance matters. +- **Stake Pool Operators (SPOs):** Operators who maintain the network's infrastructure and participate in governance decisions. +- **Constitutional Committee (CC):** A group responsible for overseeing the integrity of the governance process and ensuring adherence to the Constitution. + +### Section 3: Decision-Making Processes + +On-chain governance decisions shall be made through collective decision-making processes with defined consensus thresholds. Proposals shall be transparently documented, and sufficient rationale provided to justify changes to the Cardano Blockchain. + +### Section 4: Dispute Resolution + +Mechanisms shall be established for the fair and transparent resolution of disputes within the Cardano Community. These mechanisms aim to uphold the rights and responsibilities outlined in this Constitution. + +## Article III: Roles and Responsibilities + +### Section 1: Delegated Representatives (DReps) + +DReps represent the interests of ADA holders in governance decisions. They shall act in good faith, with integrity, and in the best interests of the community. Registration and participation processes for DReps shall be transparent and accessible. + +### Section 2: Stake Pool Operators (SPOs) + +SPOs are responsible for maintaining the Cardano network's infrastructure. They shall meet performance standards and act in accordance with the network's principles. SPOs participate in governance decisions, particularly those affecting network operations. + +### Section 3: Constitutional Committee (CC) + +The CC oversees the governance process, ensuring compliance with the Constitution. The committee operates transparently, with members elected or appointed according to processes defined by the community. + +## Article IV: Community Engagement + +### Section 1: Education and Onboarding + +The Cardano Community shall provide resources and programs to educate and onboard new participants, including ADA holders, DReps, and SPOs, to promote informed participation in governance. + +### Section 2: Communication and Outreach + +Regular updates, open forums, and discussion groups shall be maintained to facilitate dialogue between the community and governance bodies. Community ambassadors may represent various regions and demographics to ensure diverse perspectives are included. + +## Article V: Amendments and Revisions + +### Section 1: Amendment Process + +This Constitution may be amended through a defined governance process that requires broad community consensus. Proposals for amendments shall be transparent, well-documented, and subject to rigorous review. + +### Section 2: Periodic Review + +The Constitution shall be subject to periodic review to ensure its continued relevance and effectiveness. Reviews shall consider technological advancements, community feedback, and the evolving needs of the Cardano ecosystem. + +## Article VI: Final Provisions + +### Section 1: Supremacy of the Constitution + +This Constitution is the supreme guiding document of the Cardano Blockchain. All participants and governance bodies shall act in accordance with its provisions. + +### Section 2: Interpretation + +In the event of ambiguity or disputes regarding the interpretation of this Constitution, the established dispute resolution mechanisms shall be utilized to arrive at a fair and equitable outcome. + +### Section 3: Entry into Force + +This Constitution shall take effect upon its ratification by the Cardano Community through the agreed governance processes. + + diff --git a/WorkingNotes/23-Nov-2024-Workshop.md b/WorkingNotes/23-Nov-2024-Workshop.md new file mode 100644 index 0000000..83cfa6f --- /dev/null +++ b/WorkingNotes/23-Nov-2024-Workshop.md @@ -0,0 +1,206 @@ + +## Discussion Summary + +Here is the refined summary with references to sections of the document being discussed where possible: + +### 1. General Goals and Process + +- **Purpose:** The group aimed to synthesize multiple drafts of the Cardano Constitution into a unified document that reflects community feedback and principles. +- **Approach:** Discussions were focused on sections like preambles, the tenets (Article 1), and procedural sections, analyzed line by line for clarity, inclusivity, and alignment with Cardano’s ethos. + +### 2. Prefaces and Preambles + +- **Section Discussed:** Preface/Preamble (potentially preceding Article 1). +- **Perspectives:** + - Acknowledgment of the governance transition from founding entities to the community was seen as essential. + - Aspirational language was proposed to make the document inspiring while maintaining legal clarity. + - Concerns arose about whether a preamble could create legal conflicts or ambiguities if its status (binding or non-binding) isn’t clearly defined. +- **Draft Variations:** + - One draft excluded the preamble entirely, while others included it with an explicit statement about its non-binding nature. + +### 3. Tenets of the Blockchain + +- **Section Discussed:** Article 1 – The Tenets. +- **Key Points:** + - **Tenet 1: Transactions Shall Not Be Slowed or Censored:** + - Concerns about potential conflicts with recent technical updates related to mempool sanitization. + - Questions about enforceability against external entities or systems prioritizing certain transactions (e.g., private relays). + - Comparison with the Cardano Foundation (CF) Draft, which condensed this idea into maintaining the blockchain’s public and permissionless nature. + - **Tenet 6: Interoperability:** + - Some suggested that the tenet should actively foster interoperability and composability (both human and technical aspects). + - Others favored a passive stance where the blockchain simply doesn’t impede interoperability. + - Revised drafts sought to balance these perspectives. + - **Tenet 9: Equality:** + - Concerns were raised about interpreting "equal treatment," especially regarding AI actors and potential conflicts with majority rule. + - Suggestions included focusing on "equal opportunity" rather than strict equality. + - **Tenet 4: Reward Sharing:** + - Questions about the inclusion of DReps in reward-sharing mechanisms, signaling possible implicit approval of their compensation. +- **General Observations:** + - Some tenets (e.g., Tenet 2 on predictable fees) were critiqued for ambiguous language and subjective terms like "reasonable." + +### 4. Technical and Legal Definitions + +- **Sections Discussed:** Preamble and Glossary. +- **Key Points:** + - The CF Draft’s glossary was praised for defining terms like "on-chain" and providing clarity on governance actors (e.g., DReps, CC members). + - This approach was seen as a way to avoid interpretational ambiguity in future disputes. + +### 5. Philosophical and Long-Term Considerations + +- **Section Discussed:** Article 1 – The Tenets. +- **Key Points:** + - Recognition of the need for adaptability and periodic revisions, as no concept or rule is universally applicable forever. + - Concerns about future challenges, including the rise of AI actors, the definition of "blockchain sustainability," and the evolution of governance mechanisms. + +### 6. Specific Sections of Debate + +- **Sections Discussed:** + - **Article 1 – The Tenets:** + - Focus on rewarding mechanisms (Tenet 4) and whether they implicitly approve DRep compensation. + - Explicit language on tokenomics and multi-resource consensus (Minotaur) was critiqued for being overly prescriptive. + - **Article 2 – Dispute Resolution:** + - The absence of clear jurisdictions or mechanisms for resolving disputes and enforcing rights raised concerns. + - Suggestions included building internal arbitration systems and utilizing escrow mechanisms for automated resolution. + +### 7. Procedural and Structural Feedback + +- **Sections Discussed:** Entire Document, especially Articles 1 and 2. +- **Key Points:** + - The Intersect Draft was critiqued for assuming prior knowledge, while the CF Draft was praised for formal definitions of governance roles. + - Some felt the Intersect Draft’s tenets were overly verbose, while the CF Draft offered a more concise and formal layout. + +This summary references specific sections and articles for greater clarity. Let me know if you'd like further details on any particular point! + +## Key Points Analysis + +Here’s a synthesis identifying the most important points based on the perspectives of security, future workflow, and discussion prominence from the workshop: + +### 1. Security Perspective + +- **Key Points:** + - **Tenet 1: Transactions Shall Not Be Slowed or Censored** + - **Importance:** This tenet underpins Cardano’s security model by ensuring the network's public and permissionless nature. Concerns were raised about the recent mempool sanitization update potentially enabling selective transaction filtering, which could conflict with this principle. + - **Implications:** Future rules around transaction prioritization (e.g., for preventing DDoS or spam attacks) must balance maintaining security with the Constitution’s non-censorship mandate. + - **Tenet 9: Equality and Collective Desires** + - **Importance:** This tenet's emphasis on "equal treatment" raised concerns about how it applies to bots, AI actors, and potential exploitation. Defining "users" and "transactions" clearly is critical to ensuring that bad actors (e.g., malicious bots) do not exploit the blockchain under the guise of equality. + - **Proposals:** Shift the focus to "equal opportunity" while ensuring robust safeguards against misuse. + - **Interoperability and Composability (Tenet 6):** + - **Importance:** Promoting openness to interoperability was noted as a security and stability factor for Cardano. However, active interoperability could expose the system to vulnerabilities from less secure chains or malicious actors. + - **Proposal:** Balance passive ("shall not impede") and proactive ("shall foster") approaches while setting safeguards for interacting with potentially insecure ecosystems. + +### 2. Future Workflow Perspective + +- **Key Points:** + - **Dispute Resolution (Article 2, Section 3):** + - **Importance:** This section is critical for maintaining trust and workflow efficiency in governance and treasury operations. Without clear mechanisms for arbitration, disputes could escalate, undermining governance stability. + - **Suggestions:** Build an internal arbitration framework, possibly with escrow systems or decentralized dispute resolution panels, to ensure quick and transparent conflict resolution. + - **Flexibility and Revisions:** + - **Importance:** As blockchain technology and governance evolve, static tenets or rules may hinder adaptability. Participants emphasized the need for built-in mechanisms for periodic review or amendments to the Constitution. + - **Proposal:** Include provisions for regular review cycles or mechanisms for addressing future scenarios (e.g., AI integration, quantum threats) without undermining core principles. + - **DRep Roles and Payment (Tenet 4, Article 3):** + - **Importance:** Defining whether DReps are compensated and the mechanisms for their accountability is crucial for ensuring the sustainability and efficiency of Cardano’s governance structure. Concerns were raised about potential bureaucracy and inequities. + - **Proposal:** Clearly define DRep responsibilities, incentivization models, and the checks and balances on their actions. + +### 3. Most Discussed Points + +- **Key Areas:** + - **The Tenets (Article 1):** + - Received the most detailed attention, with discussions spanning clarity, enforceability, and the balance between aspirational and practical principles. + - Specific tenets debated included: + - Tenet 1: Censorship and prioritization of transactions. + - Tenet 6: Interoperability, including human and technical collaboration. + - Tenet 9: Equality and fairness versus the risk of exploitation. + - Tenet 4: Reward sharing and implications for DReps and SPOs. + - **Definitions and Glossary:** + - Praised for providing clarity on terms like "on-chain" and governance actors (e.g., DReps, CC members). Seen as essential to avoiding disputes and ensuring transparency. + - **Procedural Clarity:** + - Comparison between drafts highlighted the need for consistency in language and layout. The Cardano Foundation (CF) Draft was praised for its structure and clear definitions, while the Intersect Draft was critiqued for assuming prior knowledge. + +## Key Takeaways by Perspective + +- **Security:** + - Maintain robust protections against censorship, abuse by bots/AI, and vulnerabilities from interoperability. Clear definitions and explicit safeguards are vital. +- **Future Workflow:** + - Build mechanisms for dispute resolution, revisions, and flexibility. Clarify roles and compensation for governance actors like DReps to ensure sustainable workflows. +- **Discussion Prominence:** + - The tenets dominated discussions, with equality, transaction censorship, and interoperability drawing the most attention. Definitions and procedural clarity were also recurring themes. + +This summary provides a comprehensive look at the most critical issues discussed during the workshop. Let me know if you'd like further exploration of any point! + +## Future Workshop Prompts + +Here are tailored workshop prompts for future sessions that build on the discussions from the workshop and focus on advancing key topics: + +### 1. Security and Governance + +- **Defining Transaction Censorship and Prioritization:** + - What mechanisms can ensure transactions remain public and permissionless while balancing security needs (e.g., spam mitigation, DDoS prevention)? + - How should the Constitution define "censorship" and "expediently served" in practical terms? +- **AI and Non-Human Actors in Governance:** + - Should AI entities or bots interacting with the blockchain have rights or restrictions? If so, how should these be codified? + - What measures can prevent abuse by non-human actors while maintaining inclusivity for legitimate use cases? +- **Interoperability:** + - Should the Constitution promote interoperability proactively, or simply ensure it isn’t impeded? + - What safeguards should be implemented to protect Cardano from vulnerabilities introduced by interacting with less secure ecosystems? +- **Dispute Resolution Mechanisms:** + - What frameworks (e.g., arbitration panels, smart contract-based escrow) can resolve disputes fairly and efficiently? + - How should disputes between governance actors, treasury recipients, or other stakeholders be escalated and addressed? + +### 2. Future-Proofing and Flexibility + +- **Periodic Review and Amendments:** + - How often should the Constitution undergo review, and what mechanisms should trigger amendments? + - What criteria should be used to evaluate whether a tenet or article remains relevant and effective? +- **Preparing for Technological and Social Changes:** + - How can the Constitution address future challenges, such as quantum computing, evolving AI capabilities, or shifts in global governance norms? + - Should specific language or principles be added to ensure adaptability without undermining stability? +- **Ensuring Long-Term Sustainability:** + - What principles or workflows are needed to maintain the blockchain’s sustainability, particularly regarding fees, resources, and governance structures? + - How can economic models balance incentives for participants with equitable access for all users? + +### 3. Governance and Stakeholder Roles + +- **Clarifying DRep Roles and Compensation:** + - What responsibilities should DReps have, and how should their performance be measured? + - Should DReps be compensated, and if so, how can compensation models avoid creating unnecessary bureaucracy? +- **Stake Pool Operators (SPOs):** + - Should SPOs have explicit protections or rights within the Constitution, given their foundational role in the network? + - How can governance ensure that changes to parameters affecting SPOs (e.g., reward rates) are fair and transparent? +- **Community and Governance Inclusivity:** + - How can the Constitution ensure all stakeholders (e.g., developers, SPOs, small holders) have a voice in governance processes? + - Should the Constitution explicitly mandate governance structures to be inclusive of global and cultural diversity? + +### 4. Clarity and Procedural Refinement + +- **Improving Constitutional Layout and Definitions:** + - How can the glossary of terms and definitions be expanded or improved to provide better clarity? + - Should definitions and key terms (e.g., “blockchain sustainability,” “on-chain”) appear at the beginning of the document for easier reference? +- **Simplifying the Tenets:** + - How can the tenets be rephrased to maintain clarity while avoiding ambiguity and legal pitfalls? + - Should the tenets include explicit prioritization of principles, or remain balanced and flexible? +- **Guardrails and Procedural Alignment:** + - How can the guardrails section be aligned with constitutional tenets to avoid contradictions? + - Should guardrails include specific references to scenarios (e.g., changes to fees, block sizes) for clarity? + +### 5. Strategic and Philosophical Questions + +- **Balancing Aspirational vs. Practical Goals:** + - How can the Constitution balance its aspirational vision with the technical and practical realities of blockchain governance? + - Should certain sections (e.g., preambles or tenets) be explicitly labeled as aspirational or legally binding? +- **Defining Blockchain Values:** + - Should the Constitution prioritize human-centric values (e.g., supporting humanity over machines) or remain neutral about technology? + - How can global diversity and differing ethical systems be reflected in the Constitution without creating conflicts? + +### 6. Specific Workshops for Subsections + +- **Workshop Series on Individual Articles:** + - Dedicated workshops for each tenet (Article 1) to refine language and principles. + - Focused sessions on procedural articles (e.g., Dispute Resolution, Treasury, Voting) to ensure clarity and feasibility. + - Separate workshops on governance actor roles, such as the Constitutional Committee, DReps, and SPOs. +- **Scenario-Based Discussions:** + - Use real-world scenarios to test constitutional language, such as: + - Handling a blockchain DDoS attack. + - Disputes over treasury allocations. + - Changes to key parameters (e.g., fees or block size). + +These prompts can guide focused, actionable discussions that build on the foundation laid in this workshop. Let me know if you’d like to expand or refine any of these! From 269fff02ced1e0c00ca58306df43081fb33532d3 Mon Sep 17 00:00:00 2001 From: Eric Nichols <9997910+nicholseric@users.noreply.github.com> Date: Sun, 24 Nov 2024 20:33:10 -0800 Subject: [PATCH 07/17] Create Grok.md --- CommunityDrafts/Grok.md | 55 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 CommunityDrafts/Grok.md diff --git a/CommunityDrafts/Grok.md b/CommunityDrafts/Grok.md new file mode 100644 index 0000000..f9c7fac --- /dev/null +++ b/CommunityDrafts/Grok.md @@ -0,0 +1,55 @@ +This GitHub repo https://github.com/Cerkoryn/draft-constitution/tree/cerkoryn-version/CommunityDrafts +Has many constitution drafts for a cardano constitution. Chatgpt attempted to consolidate them with the prompt "Synthesize all the community drafts with the working notes to distill the common values and principles into a new draft. For different opinions, try to expand the section to be inclusive of all viewpoints. If the viewpoints are in direct conflict, then omit that section. + +Strive to use clear and concise language." + +Please do your best with the same prompt with markdown output that I can download. + +****************** +Here's my attempt at synthesizing the common values and principles from the Cardano community drafts into a new draft, following the prompt you provided: + +Cardano Constitution - Community Synthesized Draft +Preamble +We, the members of the Cardano community, commit to the following values and principles to guide our governance, interactions, and the development of our ecosystem. + +Values and Principles +Decentralization +Commitment to Decentralization: We uphold the principle that power and decision-making should be distributed across the network to prevent centralization and promote resilience. + +Openness +Transparency: All processes, decisions, and changes should be transparent to the community. +Inclusivity: Encouragement of participation from all members of the community, regardless of their stake or background. + +Security +Safety of the Network: Protecting the network from vulnerabilities is paramount. +Privacy: Ensuring that individual privacy rights are respected within the bounds of legal and ethical considerations. + +Innovation +Fostering Development: We encourage innovation through support for developers, experimentation, and the integration of new technologies that benefit the network. + +Accountability +Responsibility: Those with governance roles must act responsibly, with the community's interest at heart. +Governance Feedback Loop: Mechanisms for feedback, review, and accountability are essential. + +Sustainability +Long-Term Vision: Actions taken should consider the longevity and sustainability of the Cardano ecosystem. + +Equality and Fairness +Non-Discrimination: No discrimination based on stake size, nationality, ethnicity, or any other basis. +Fair Distribution: Resources and opportunities within the ecosystem should be distributed fairly. + +Community +Community Engagement: Active engagement with the community for decision-making processes. +Education: Commitment to educating users and stakeholders about Cardano's principles and technology. + +Legal Compliance +Adherence to Law: While striving for autonomy, we recognize the necessity to comply with applicable laws and regulations. + +Omitted Sections Due to Conflict: +Consensus Mechanisms: Due to varied and conflicting opinions on the best approach for consensus, this section has been omitted. +Economic Model: The specifics of monetary policy, staking rewards, and taxation within the Cardano ecosystem show significant divergence, hence, this is not included. + +Conclusion +This draft aims to encapsulate the spirit of the Cardano community, promoting a balanced, inclusive, and forward-looking governance model. It serves as a living document, subject to change as our community evolves. + +You can download this markdown by copying the text above into a text editor and saving it with a .md extension. Remember, this synthesis is based on the community drafts available at the time of this request, and it's by no means exhaustive or final. The beauty of Cardano's governance is in its continuous, community-driven evolution. Now, go forth and govern with wit and wisdom! From fc1ba4c039f2b0cf86a9dde935028f3d585b0f3d Mon Sep 17 00:00:00 2001 From: Latino_Staking_Pool <75137920+CL-LLC@users.noreply.github.com> Date: Mon, 25 Nov 2024 13:09:07 -0500 Subject: [PATCH 08/17] Create Cluade 2 Opus version --- ...s (Excels at writing and complex tasks).md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 CommunityDrafts/Unified Cardano Constitution Draft - Claude 3 Opus (Excels at writing and complex tasks).md diff --git a/CommunityDrafts/Unified Cardano Constitution Draft - Claude 3 Opus (Excels at writing and complex tasks).md b/CommunityDrafts/Unified Cardano Constitution Draft - Claude 3 Opus (Excels at writing and complex tasks).md new file mode 100644 index 0000000..8ace611 --- /dev/null +++ b/CommunityDrafts/Unified Cardano Constitution Draft - Claude 3 Opus (Excels at writing and complex tasks).md @@ -0,0 +1,74 @@ +Here is a synthesized draft of the Cardano Constitution based on the common values and principles from the community drafts, incorporating the insights from the working notes: + +# CARDANO CONSTITUTION + +## PREAMBLE + +Recognizing that the Cardano Blockchain has grown into a decentralized ecosystem of technology, smart contracts, and community governance, committed to improving systems globally, we the Cardano Community hereby establish this Constitution. + +The Cardano Blockchain empowers individuals and communities to collaboratively manage identity, value, and governance. It is now operated in a decentralized manner, strengthening its resilience and autonomy. + +As Cardano evolves, its governance must adapt to reflect principles of decentralization, accountability, and inclusivity. Through blockchain-based on-chain governance wherever possible, this Constitution provides a framework for all to contribute to Cardano's development. + +This Constitution is a living document to be interpreted giving effect to the following core tenets. The Preamble provides context but is non-binding. + +## ARTICLE I. CORE TENETS + +### SECTION 1. GUIDING PRINCIPLES + +The Cardano Blockchain shall strive to uphold these guiding principles: + +1. Maintain a secure, transparent, inclusive and decentralized public blockchain. +2. Promote efficient functionality and resource usage without compromising accessibility or sustainability. +3. Enable community-driven governance based on legitimacy and broad representation. +4. Ensure financial stability and a predictable long-term economic model. +5. Preserve and incentivize stakeholder contributions to the ecosystem. +6. Uphold user privacy and control over personal data and assets. +7. Foster open innovation, interoperability and collaboration. +8. Continuously adapt to technological, social and regulatory evolutions. + +### SECTION 2. BLOCKCHAIN FUNCTIONALITY + +1. Transactions shall be processed efficiently for their intended purpose without undue delay or censorship. +2. Transaction costs should follow an accessible and predictable model. +3. The Cardano Blockchain shall not unreasonably restrict application development or impede interoperability. +4. Ledger history shall be immutable and assets therein securely preserved. + +### SECTION 3. GOVERNANCE VALUES + +1. Majority rule shall prevail in governance decisions while respecting minority views and avoiding marginalization of any segment of the community. +2. All users shall have fair opportunity to participate in governance proportional to their stake. +3. No stakeholder group (SPOs, DReps, CC members, Ada holders) shall unilaterally impose decisions without required approvals. +4. Governance shall remain decentralized and avoid undue accumulation of power. + +## ARTICLE II. COMMUNITY AND MEMBERSHIP + +1. All Ada holders, developers, SPOs and other supporters of the Cardano Blockchain shall be considered part of the Cardano Community and beneficiaries of this Constitution. Formal membership is not required for participation. +2. Ada holders are entitled to participate in on-chain governance, including proposing and voting on actions, in accordance with this Constitution and the Cardano Blockchain's technical Guardrails. + +## ARTICLE III. GOVERNANCE MODEL + +1. On-chain governance shall serve as the primary decision-making model utilizing smart contracts and blockchain-based tools. +2. Governance bodies - the Constitutional Committee (CC), Delegated Representatives (DReps), and Stake Pool Operators (SPOs) - shall provide decentralized checks and balances, with specified quorums and thresholds. +3. DReps shall represent Ada holders' stake and vote on their behalf. SPOs shall approve technical changes like hard forks and parameter updates. CC shall ensure actions comply with this Constitution. +4. Details on governance processes, voting, and quorums shall be as specified in the Blockchain Guardrails document, subject to change via on-chain updates. +5. An annual on-chain budget shall govern the usage of the Cardano Treasury, with funds disbursed transparently for ecosystem development and sustainability as approved by the Community. + +## ARTICLE IV. AMENDMENTS AND INTERPRETATION + +1. Amendments to this Constitution shall require approval via on-chain action by DReps with a minimum 67% threshold of active stake. +2. CC shall be the arbiter for interpretation of this Constitution and conformity of actions to it. +3. In case of conflict between this Constitution and the technical Guardrails implemented on-chain, the on-chain rules shall prevail while CC works to resolve the inconsistency. +4. This Constitution shall be reviewed periodically to adapt to evolutions in technology, governance needs, and regulations. + +## APPENDIX: COMMUNITY GOVERNANCE DEFINITIONS + +Key terms used in this Constitution shall be understood as defined here: +- Ada holders: Persons controlling private keys of Ada assets. +- Cardano Blockchain: The public proof-of-stake blockchain operated by the Cardano protocol. +- Cardano Treasury: An on-chain reserve of Ada for ecosystem funding. +- CC: Constitutional Committee ensuring governance conforms to this Constitution. +- DRep: Delegated Representative voting on behalf of Ada holders. +- Guardrails: Technical implementation of governance parameters on-chain. +- On-chain: Actions recorded and executed on the Cardano Blockchain. +- SPO: Stake Pool Operator running Cardano protocol nodes. \ No newline at end of file From 502957bc4472c84e1c8db2c961deb1afbdff7e43 Mon Sep 17 00:00:00 2001 From: Latino_Staking_Pool <75137920+CL-LLC@users.noreply.github.com> Date: Mon, 25 Nov 2024 13:10:55 -0500 Subject: [PATCH 09/17] Create Cluade 3.5 Sonnet version --- ...et (Most Intelligent model from Claude).md | 438 ++++++++++++++++++ 1 file changed, 438 insertions(+) create mode 100644 CommunityDrafts/Unified Cardano Constitution Draft - Claude 3.5 Sonnet (Most Intelligent model from Claude).md diff --git a/CommunityDrafts/Unified Cardano Constitution Draft - Claude 3.5 Sonnet (Most Intelligent model from Claude).md b/CommunityDrafts/Unified Cardano Constitution Draft - Claude 3.5 Sonnet (Most Intelligent model from Claude).md new file mode 100644 index 0000000..84cba33 --- /dev/null +++ b/CommunityDrafts/Unified Cardano Constitution Draft - Claude 3.5 Sonnet (Most Intelligent model from Claude).md @@ -0,0 +1,438 @@ +# CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION + +## PREAMBLE + +*Note: This preamble provides context but is non-binding for the purpose of assessing the constitutionality of proposed governance actions.* + +The Cardano blockchain emerged as a collaborative effort between Input Output Hong Kong, Emurgo, and the Cardano Foundation, who together with the broader community established a foundation for decentralized infrastructure. Through rigorous academic research, peer review, and community input, Cardano has evolved into a public, permissionless blockchain that empowers individuals and communities globally. + +Recognizing the transition from federated governance to community stewardship, we establish this Constitution to guide the continued development and governance of the Cardano blockchain. While we may be geographically, politically, and culturally diverse, we are united in our commitment to leveraging blockchain technology to foster positive change. + +This Constitution reflects our collective dedication to maintaining a secure, scalable, and decentralized ecosystem that serves humanity through technological innovation and collaborative governance. + +## ARTICLE I - APPLICABILITY AND GOVERNANCE MODEL + +### Section 1: Applicability + +This Constitution: +1. Applies to all Cardano Community members insofar as they interact with the Cardano Blockchain +2. Governs both on-chain and off-chain activities related to the Cardano ecosystem +3. Shall be interpreted to give effect to the tenets set forth herein + +### Section 2: Governance Model + +1. The Cardano Blockchain shall use a model of participatory governance that: + - Enables direct participation by Ada holders + - Utilizes blockchain technology for transparency and verification + - Maintains checks and balances through multiple governance bodies + - Protects minority rights while enabling majority decision-making + +### Section 3: Defined Terms + +For the purposes of this Constitution: + +1. **Ada**: The native cryptocurrency of the Cardano blockchain. +2. **Ada Holders**: Persons who control the private key(s) to ada token(s). +3. **Active Voting Stake**: The total lovelace considered active for voting purposes based on registration and activity requirements. +4. **Cardano Blockchain**: A public, proof-of-stake, peer-to-peer distributed ledger system operating under the name "Cardano". +5. **Cardano Community**: All participants in the Cardano ecosystem, including Ada holders, developers, operators, and users. +6. **Constitutional Committee (CC)**: The governing body responsible for ensuring governance actions comply with this Constitution. +7. **Delegated Representatives (DReps)**: Registered participants who vote on governance actions, either directly or on behalf of other Ada holders. +8. **Governance Action**: An on-chain proposal to modify the Cardano blockchain or its governance. +9. **Lovelace**: The smallest unit of ada (1/1,000,000 ada). +10. **Stake Pool Operators (SPOs)**: Operators of nodes that participate in block production. + +## ARTICLE II - ECOSYSTEM PRINCIPLES AND VALUES + +### Section 1: Core Values + +1. **Decentralization** + - Power and control shall be distributed among participants + - No single entity shall have disproportionate influence + - Decision-making shall be collaborative and inclusive + +2. **Transparency** + - Governance processes shall be visible and verifiable + - Decision rationales shall be documented and accessible + - Financial operations shall be auditable + +3. **Security** + - The blockchain shall maintain robust security measures + - User assets shall be protected through cryptographic means + - Security measures shall adapt to emerging threats + +4. **Sustainability** + - The ecosystem shall operate in an environmentally conscious manner + - Economic models shall support long-term viability + - Resource usage shall be efficient and justified + +### Section 2: Fundamental Tenets + +These tenets guide all participants in the Cardano ecosystem and shall be used to evaluate proposed governance actions. + +### Section 1: Core Principles + +1. The Cardano blockchain shall remain public and permissionless. +2. Valid transactions shall not be censored and shall be processed expediently. +3. Transaction costs shall be predictable and reasonable. +4. The blockchain shall preserve and protect stored value and information. +5. The total supply of ada shall not exceed 45 billion tokens. +6. The blockchain shall operate efficiently, minimizing unnecessary resource consumption. +7. The blockchain shall strive for security, reliability, and resilience. +8. The blockchain shall support interoperability while maintaining security. +9. All users shall have equal access to core blockchain functions. +10. The blockchain shall promote decentralization in its operation and governance. + +### Section 2: Technical Implementation + +1. The blockchain shall utilize peer-reviewed research and open-source development. +2. Changes to the protocol shall prioritize security, scalability, and sustainability. +3. The blockchain shall maintain post-quantum security readiness. +4. Protocol parameters shall be governed according to the Guardrails specified in Appendix I. + +### Section 3: Governance Principles + +1. Governance shall be transparent, inclusive, and accountable. +2. Decisions shall be made through structured on-chain voting mechanisms. +3. The community shall have the right to propose and vote on changes. +4. Treasury management shall require community oversight and approval. + +## ARTICLE III - PARTICIPATION AND RIGHTS + +### Section 1: Community Rights + +1. **Access Rights** + - All persons may participate in the Cardano ecosystem + - No formal membership requirements shall be imposed + - Access to core functions shall be unrestricted + +2. **Governance Rights** + - Ada holders may participate in governance directly or through delegation + - Proposal submission shall be open to all participants + - Voting rights shall be proportional to stake + +3. **Development Rights** + - Anyone may develop and deploy applications + - Open-source collaboration shall be encouraged + - Innovation shall not be unreasonably restricted + +4. **Privacy Rights** + - User privacy shall be protected + - Data collection shall be minimized + - Consent shall be required for data gathering + +## ARTICLE IV - GOVERNANCE FRAMEWORK + +### Section 1: Governance Bodies + +The Cardano blockchain shall be governed through three independent bodies: + +1. **Delegated Representatives (DReps)** + - May be individuals or coordinated groups + - Register to vote on behalf of Ada holders + - Voting power proportional to delegated stake + - May adopt and publish codes of conduct + +2. **Stake Pool Operators (SPOs)** + - Operate consensus nodes + - Vote on technical parameters and hard forks + - Provide additional oversight on critical changes + - Must disclose if also acting as DReps + +3. **Constitutional Committee** + - Reviews governance actions for constitutionality + - Comprises 3-9 members serving staggered terms + - Operates transparently and publishes decisions + - Members selected through community election + +### Section 2: Governance Actions + +The following types of governance actions are recognized: + +1. Motion of No-Confidence +2. Update Committee/Threshold/Term +3. New Constitution or Guardrails +4. Hard Fork Initiation +5. Protocol Parameter Changes +6. Treasury Withdrawals +7. Info Actions + +### Section 3: Voting Process + +1. Each governance action requires specified thresholds from relevant bodies +2. Votes may be cast as "Yes", "No", or "Abstain" +3. Voting power is proportional to stake or delegation +4. Results are recorded on-chain for transparency + +## ARTICLE V - CONSENSUS AND TECHNICAL OPERATIONS + +### Section 1: Network Operations + +1. **Transaction Processing** + - Valid transactions shall be processed without discrimination + - Transaction ordering shall be based on objective criteria + - Network performance shall be continuously monitored + +2. **Protocol Updates** + - Changes shall undergo thorough testing and review + - Updates shall maintain backward compatibility where possible + - Emergency procedures shall exist for critical issues + +3. **Resource Management** + - Network resources shall be allocated fairly + - Scaling solutions shall be implemented as needed + - Performance impacts shall be carefully evaluated + +### Section 2: Technical Parameters + +1. **Parameter Governance** + - Changes shall follow established procedures + - Technical impacts shall be thoroughly assessed + - Community input shall be considered + +2. **Security Measures** + - Security shall be proactively maintained + - Threats shall be actively monitored + - Responses shall be timely and proportional + +## ARTICLE VI - TREASURY MANAGEMENT + +### Section 1: Principles + +1. The treasury shall be managed for the benefit of the Cardano ecosystem +2. Withdrawals require community approval through governance actions +3. Funded projects shall provide regular updates and undergo audits +4. The community shall establish and maintain oversight mechanisms + +### Section 2: Budget Process + +1. Annual budgets shall be proposed and approved by the community +2. Budgets shall specify oversight mechanisms and auditing requirements +3. Treasury withdrawals must align with approved budgets +4. Regular reporting on fund utilization shall be required + +## ARTICLE VII - DISPUTE RESOLUTION + +### Section 1: Resolution Framework + +1. **General Principles** + - Disputes shall be resolved fairly and transparently + - Resolution mechanisms shall be accessible to all parties + - Procedures shall be clearly documented + +2. **Resolution Methods** + - On-chain resolution shall be preferred where possible + - Off-chain mechanisms shall be available when needed + - Multiple resolution paths shall be provided + +### Section 2: Implementation + +1. **Resolution Bodies** + - The community shall establish appropriate bodies + - Resolution procedures shall be documented + - Appeals processes shall be available + +2. **Enforcement** + - Decisions shall be enforced through appropriate mechanisms + - Compliance shall be monitored + - Consequences shall be proportional + +## ARTICLE VIII - AMENDMENTS + +1. This Constitution may be amended through governance action +2. Amendments require approval from 67% of active voting stake +3. The Guardrails appendix may be updated through specified processes +4. Amendments shall not violate the fundamental tenets + +## ARTICLE IX - INTEROPERABILITY AND COLLABORATION + +### Section 1: Interoperability + +1. **Technical Interoperability** + - Standards shall promote interconnection + - Security shall not be compromised + - Innovation shall be encouraged + +2. **Ecosystem Collaboration** + - Cross-chain cooperation shall be supported + - Standards development shall be collaborative + - Best practices shall be shared + +### Section 2: External Relations + +1. **Community Relations** + - External engagement shall be encouraged + - Communication shall be transparent + - Partnerships shall benefit the ecosystem + +2. **Regulatory Compliance** + - Legal requirements shall be respected + - Compliance shall be voluntary + - Privacy shall be protected + +## APPENDIX I: GUARDRAILS + +[Technical specifications from current guardrails document to be included here] + +## APPENDIX II: INTERIM PERIOD PROVISIONS + +This appendix governs the transition period until full implementation of this Constitution. + +### Section 1: Timeline +1. The interim period begins with the Chang Hard Fork +2. Transitions shall occur in planned phases +3. Community readiness shall guide progression + +### Section 2: Governance +1. Initial governance actions shall be limited +2. Additional features shall be enabled progressively +3. Community preparation shall be prioritized + +### Section 3: Implementation +1. Technical rollout shall be carefully managed +2. Community feedback shall be incorporated +3. Progress shall be transparent + +## APPENDIX III: GLOSSARY + +### A + +**Active Block Production Stake**: The amount of ada actively delegated to SPOs for the purpose of block production. + +**Active Voting Stake**: The total amount of ada considered active for voting purposes, based on registration and activity requirements specified in the Guardrails. + +**Ada**: The native cryptocurrency of the Cardano blockchain, named after Ada Lovelace. The primary unit of value and governance participation within the Cardano ecosystem. + +**Ada Holders**: Persons or entities who control the private key(s) to ada token(s), whether directly or through authorized custodians. + +### B + +**Block**: A fundamental unit of the blockchain containing transactions and other data, produced by SPOs according to the consensus protocol. + +**Blockchain Neutrality**: The principle that transactions should not be censored or unreasonably delayed, and that all users should have fair access to the network. + +### C + +**Cardano Blockchain**: A public, proof-of-stake, peer-to-peer distributed ledger system operating under the name "Cardano". + +**Cardano Community**: All participants in the Cardano ecosystem, including but not limited to Ada holders, developers, SPOs, DReps, and users. + +**Cardano Ecosystem**: The entire environment of technology, applications, services, and community initiatives built around the Cardano blockchain. + +**Cardano Treasury**: The decentralized on-chain fund that holds and manages ada received from transaction fees, staking rewards, and monetary expansion. + +**Chang Hard Fork**: The network upgrade that enabled initial CIP-1694 governance features, marking the beginning of the interim period. + +**Constitutional Committee (CC)**: The governing body responsible for ensuring governance actions comply with this Constitution. + +**Consensus Protocol**: The mechanism by which the network agrees on the state of the blockchain, currently implemented as Ouroboros. + +### D + +**DApp**: Decentralized Application - software applications that run on the Cardano blockchain. + +**Delegated Representatives (DReps)**: Registered participants who vote on governance actions, either directly or on behalf of other Ada holders. + +**Deposit**: An amount of ada required to perform certain actions (e.g., governance proposals, stake delegation) that may be returned under specified conditions. + +### E + +**Epoch**: A fixed time period (approximately 5 days) used for various blockchain operations including staking rewards calculation and governance timing. + +### F + +**Final Constitution**: The permanent version of the Constitution that will replace any interim versions after community ratification. + +### G + +**Genesis Block**: The first block of the Cardano blockchain, containing the initial distribution of ada. + +**Governance Action**: A formal proposal submitted on-chain to modify the Cardano blockchain or its governance, including but not limited to parameter changes, treasury withdrawals, and constitutional amendments. + +**Guardrails**: Technical specifications and limitations designed to maintain the security, stability, and performance of the Cardano blockchain. + +### H + +**Hard Fork**: A non-backwards compatible upgrade to the network protocol, requiring all nodes to upgrade to maintain consensus. + +### I + +**Info Action**: A special type of governance action used to gauge community sentiment without making on-chain changes. + +**Interim Period**: The transition period between the Chang Hard Fork and the full implementation of this Constitution. + +### L + +**Liquid Democracy**: The governance model where Ada holders can either vote directly or delegate their voting power to representatives. + +**Lovelace**: The smallest unit of ada (1/1,000,000 ada), named after Ada Lovelace. + +### M + +**Mainnet**: The primary Cardano blockchain network where real ada transactions occur. + +**Motion of No-Confidence**: A governance action to reject the current Constitutional Committee. + +### N + +**Net Change Limit**: The maximum allowed change in Treasury balance over a specified period. + +**Node**: Software that participates in the Cardano network by validating and relaying transactions and blocks. + +### O + +**On-chain**: Actions or data recorded directly on the Cardano blockchain. + +**Off-chain**: Activities or information that exist outside the blockchain but may interact with or support it. + +### P + +**Parameter**: A configurable value that affects the operation of the Cardano blockchain. + +**Protocol**: The set of rules governing the operation of the Cardano blockchain. + +### Q + +**Quorum**: The minimum participation required for a governance action to be valid. + +### R + +**Reward**: Ada distributed to stake pools and delegators for participating in network consensus. + +### S + +**Stake**: The amount of ada held or delegated, representing voting power and potential block production rights. + +**Stake Pool**: A node configured to participate in block production, operated by an SPO. + +**Stake Pool Operator (SPO)**: An individual or entity that operates a stake pool, participating in block production and certain governance actions. + +### T + +**Treasury Withdrawal**: A governance action to distribute ada from the Cardano Treasury. + +### U + +**UTxO**: Unspent Transaction Output - the accounting model used by Cardano to track ada ownership. + +### V + +**Voting Power**: The influence an entity has in governance decisions, typically proportional to stake. + +### Additional Technical Terms + +**Plutus**: The smart contract platform of Cardano. + +**Protocol Parameters**: Configurable values that control various aspects of the blockchain's operation: + +- **maxBlockBodySize**: Maximum allowed size of a block body +- **maxTxSize**: Maximum allowed size of a transaction +- **minPoolCost**: Minimum fixed cost for running a stake pool +- **poolPledgeInfluence**: Parameter affecting rewards based on pool pledge +- **treasuryCut**: Portion of rewards allocated to the Treasury +- **executionUnitPrices**: Costs for executing Plutus scripts +- **maxBlockExecutionUnits**: Limits on script execution resources +- **dRepDeposit**: Required deposit to register as a DRep +- **govActionDeposit**: Required deposit for governance actions + +This glossary may be updated through governance actions to reflect new terms and evolving understanding of the ecosystem. \ No newline at end of file From 2660af397155965a34dff897a363149a3d84131f Mon Sep 17 00:00:00 2001 From: Latino_Staking_Pool <75137920+CL-LLC@users.noreply.github.com> Date: Mon, 25 Nov 2024 13:16:11 -0500 Subject: [PATCH 10/17] Rename Unified Cardano Constitution Draft - Claude 3 Opus (Excels at writing and complex tasks).md to Claude 3 Opus.md Changed name file --- ...Excels at writing and complex tasks).md => Claude 3 Opus.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename CommunityDrafts/{Unified Cardano Constitution Draft - Claude 3 Opus (Excels at writing and complex tasks).md => Claude 3 Opus.md} (98%) diff --git a/CommunityDrafts/Unified Cardano Constitution Draft - Claude 3 Opus (Excels at writing and complex tasks).md b/CommunityDrafts/Claude 3 Opus.md similarity index 98% rename from CommunityDrafts/Unified Cardano Constitution Draft - Claude 3 Opus (Excels at writing and complex tasks).md rename to CommunityDrafts/Claude 3 Opus.md index 8ace611..4957d69 100644 --- a/CommunityDrafts/Unified Cardano Constitution Draft - Claude 3 Opus (Excels at writing and complex tasks).md +++ b/CommunityDrafts/Claude 3 Opus.md @@ -71,4 +71,4 @@ Key terms used in this Constitution shall be understood as defined here: - DRep: Delegated Representative voting on behalf of Ada holders. - Guardrails: Technical implementation of governance parameters on-chain. - On-chain: Actions recorded and executed on the Cardano Blockchain. -- SPO: Stake Pool Operator running Cardano protocol nodes. \ No newline at end of file +- SPO: Stake Pool Operator running Cardano protocol nodes. From 6a8b149c682252f457762d98625470f419af9210 Mon Sep 17 00:00:00 2001 From: Latino_Staking_Pool <75137920+CL-LLC@users.noreply.github.com> Date: Mon, 25 Nov 2024 13:17:19 -0500 Subject: [PATCH 11/17] Rename Unified Cardano Constitution Draft - Claude 3.5 Sonnet (Most Intelligent model from Claude).md to Claude 3.5 Sonnet.md Changed file name --- ...t Intelligent model from Claude).md => Claude 3.5 Sonnet.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename CommunityDrafts/{Unified Cardano Constitution Draft - Claude 3.5 Sonnet (Most Intelligent model from Claude).md => Claude 3.5 Sonnet.md} (99%) diff --git a/CommunityDrafts/Unified Cardano Constitution Draft - Claude 3.5 Sonnet (Most Intelligent model from Claude).md b/CommunityDrafts/Claude 3.5 Sonnet.md similarity index 99% rename from CommunityDrafts/Unified Cardano Constitution Draft - Claude 3.5 Sonnet (Most Intelligent model from Claude).md rename to CommunityDrafts/Claude 3.5 Sonnet.md index 84cba33..62eb847 100644 --- a/CommunityDrafts/Unified Cardano Constitution Draft - Claude 3.5 Sonnet (Most Intelligent model from Claude).md +++ b/CommunityDrafts/Claude 3.5 Sonnet.md @@ -435,4 +435,4 @@ This appendix governs the transition period until full implementation of this Co - **dRepDeposit**: Required deposit to register as a DRep - **govActionDeposit**: Required deposit for governance actions -This glossary may be updated through governance actions to reflect new terms and evolving understanding of the ecosystem. \ No newline at end of file +This glossary may be updated through governance actions to reflect new terms and evolving understanding of the ecosystem. From b2ddc83ee4172689bfa628e1a316d2a097303da7 Mon Sep 17 00:00:00 2001 From: Latino_Staking_Pool <75137920+CL-LLC@users.noreply.github.com> Date: Mon, 25 Nov 2024 13:38:13 -0500 Subject: [PATCH 12/17] Update Claude 3 Opus.md --- CommunityDrafts/Claude 3 Opus.md | 51 +++++++++++++++++++++++++++++++- 1 file changed, 50 insertions(+), 1 deletion(-) diff --git a/CommunityDrafts/Claude 3 Opus.md b/CommunityDrafts/Claude 3 Opus.md index 4957d69..743f49c 100644 --- a/CommunityDrafts/Claude 3 Opus.md +++ b/CommunityDrafts/Claude 3 Opus.md @@ -54,7 +54,56 @@ The Cardano Blockchain shall strive to uphold these guiding principles: 4. Details on governance processes, voting, and quorums shall be as specified in the Blockchain Guardrails document, subject to change via on-chain updates. 5. An annual on-chain budget shall govern the usage of the Cardano Treasury, with funds disbursed transparently for ecosystem development and sustainability as approved by the Community. -## ARTICLE IV. AMENDMENTS AND INTERPRETATION +## ARTICLE IV. BLOCKCHAIN PARAMETERS AND GUARDRAILS + +1. The technical parameters and limitations of the Cardano Blockchain, including those related to economic, network, governance, and security aspects, shall be detailed in the Cardano Blockchain Guardrails document. +2. The Guardrails shall aim to ensure the blockchain operates securely and sustainably, avoiding disruptions or vulnerabilities. They apply to on-chain governance actions like parameter changes and Treasury usage. +3. Where possible, Guardrails shall be automated and enforced through on-chain scripts or ledger rules. Amendments to the Guardrails shall follow the process for Constitutional amendments. +4. Inconsistencies between the implemented on-chain parameters and the Guardrails document shall be resolved by deeming the on-chain implementation authoritative while the CC works to rectify the documentation. + +## ARTICLE V. GOVERNANCE BODIES AND PROCEDURES + +### SECTION 1. DELEGATED REPRESENTATIVES (DReps) + +1. Any Ada holder may register as a DRep to represent the stake delegated to them in governance votes. Registration procedures and fees shall be as specified in the Guardrails. +2. DReps shall vote on behalf of their delegators in accordance with delegator instructions where provided, or otherwise at their discretion in line with their published policies and the best interests of the Cardano ecosystem. +3. DReps shall maintain public transparency about their voting policies, rationales, and potential conflicts of interest. They may be compensated for their efforts as approved by the Community. + +### SECTION 2. STAKE POOL OPERATORS (SPOs) + +1. SPOs shall participate in governance decisions related to the operation and integrity of the Cardano Blockchain, with voting power proportional to their stake. +2. SPOs must abide by the technical requirements and performance standards defined in the Guardrails to ensure network security and liveness. +3. SPOs shall disclose if they are also voting as DReps or CC members on any given proposal to avoid conflicts of interest. + +### SECTION 3. CONSTITUTIONAL COMMITTEE (CC) + +1. The CC shall be composed of 3-9 members serving staggered terms as defined in the Guardrails, elected by Ada holders via on-chain voting. +2. The CC shall review all governance proposals for compliance with this Constitution before such proposals proceed to a vote by DReps or SPOs. +3. The CC may veto proposals deemed unconstitutional but shall otherwise remain neutral. CC deliberations and decisions shall be made public. +4. A proposal to remove and replace all or some CC members may be brought via a DRep-initiated on-chain action subject to required thresholds. + +### SECTION 4. GOVERNANCE ACTIONS AND VOTING + +1. Any community member may submit a governance proposal in the required format, subject to any deposit requirements in the Guardrails. +2. Proposals shall be classified into standardized types like Treasury Withdrawals, Parameter Changes, Constitutional Amendments, etc. as defined in the Guardrails, each with specified procedures and thresholds. +3. Voting on proposals shall be recorded on-chain, with outcomes determined by the applicable DRep, SPO, or Ada holder majority thresholds reached. +4. For expedited action in emergencies, the CC may provisionally approve temporary measures which must then be ratified or rejected via a standard governance vote within a defined timeframe. + +## ARTICLE VI. TREASURY AND FUNDS MANAGEMENT + +1. The Cardano Treasury shall be governed by an annual on-chain budget proposed by the community and approved by Ada holders. +2. Treasury withdrawals shall only be permitted in accordance with the approved Budget and subject to any transparency and reporting requirements in the Guardrails. +3. Community members may bring proposals for Treasury funding, which shall be approved via on-chain voting by DReps and Ada holders as per defined thresholds. +4. An elected Treasury Committee of experts may be established to provide oversight and auditing of significant expenditures as defined in the Guardrails. + +## ARTICLE VII. DISPUTE RESOLUTION + +1. The community shall work to resolve disputes internally wherever possible via transparent, documented discussions and established governance procedures. +2. An on-chain arbitration mechanism may be established to adjudicate disputes related to on-chain actions. Its decisions shall be considered binding where not contradicted by applicable external laws. +3. For disputes not resolvable internally, the community shall develop guidelines for which external jurisdictions and mechanisms are acceptable to resolve different classes of issues. +4. The CC may mediate disputes and recommend resolutions, but shall not be a mandatory arbitrator. The CC should help develop the on-chain dispute resolution system. + +## ARTICLE VIII. AMENDMENTS AND INTERPRETATION 1. Amendments to this Constitution shall require approval via on-chain action by DReps with a minimum 67% threshold of active stake. 2. CC shall be the arbiter for interpretation of this Constitution and conformity of actions to it. From 67ade17d164882695986db81f656600b0f4b6fb8 Mon Sep 17 00:00:00 2001 From: Latino_Staking_Pool <75137920+CL-LLC@users.noreply.github.com> Date: Mon, 25 Nov 2024 14:44:48 -0500 Subject: [PATCH 13/17] Update Claude 3.5 Sonnet.md --- CommunityDrafts/Claude 3.5 Sonnet.md | 522 ++++++++------------------- 1 file changed, 152 insertions(+), 370 deletions(-) diff --git a/CommunityDrafts/Claude 3.5 Sonnet.md b/CommunityDrafts/Claude 3.5 Sonnet.md index 62eb847..eb5f706 100644 --- a/CommunityDrafts/Claude 3.5 Sonnet.md +++ b/CommunityDrafts/Claude 3.5 Sonnet.md @@ -1,438 +1,220 @@ -# CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION +# Explanation -## PREAMBLE +I'll help synthesize a new constitutional draft that incorporates the common values and principles from all the provided drafts while being inclusive of different viewpoints. Let me analyze the key areas of agreement and potential conflicts. +Here are some key decisions made in the synthesis: -*Note: This preamble provides context but is non-binding for the purpose of assessing the constitutionality of proposed governance actions.* +1. **Preamble**: Kept relatively brief while acknowledging both historical origins and future vision. Avoided contentious claims about specific goals or methods. -The Cardano blockchain emerged as a collaborative effort between Input Output Hong Kong, Emurgo, and the Cardano Foundation, who together with the broader community established a foundation for decentralized infrastructure. Through rigorous academic research, peer review, and community input, Cardano has evolved into a public, permissionless blockchain that empowers individuals and communities globally. +2. **Tenets**: Organized into clear categories that appeared consistently across drafts. Focused on principles with broad agreement. -Recognizing the transition from federated governance to community stewardship, we establish this Constitution to guide the continued development and governance of the Cardano blockchain. While we may be geographically, politically, and culturally diverse, we are united in our commitment to leveraging blockchain technology to foster positive change. +3. **Governance Structure**: Maintained the three-body structure (DReps, SPOs, CC) which had consensus across drafts. -This Constitution reflects our collective dedication to maintaining a secure, scalable, and decentralized ecosystem that serves humanity through technological innovation and collaborative governance. +4. **Technical Details**: Moved most specific parameters to the Guardrails appendix to allow for evolution. -## ARTICLE I - APPLICABILITY AND GOVERNANCE MODEL +5. **Areas of Agreement**: +- Fixed ADA supply +- Permissionless access +- Transparent governance +- Balanced power structure +- Treasury oversight -### Section 1: Applicability +6. **Handled Divergent Views By**: +- Using inclusive language +- Focusing on principles over specifics +- Allowing flexibility in implementation +- Maintaining room for evolution -This Constitution: -1. Applies to all Cardano Community members insofar as they interact with the Cardano Blockchain -2. Governs both on-chain and off-chain activities related to the Cardano ecosystem -3. Shall be interpreted to give effect to the tenets set forth herein +7. **Omitted Areas of Conflict**: +- Specific compensation models +- Detailed power distribution +- Rigid operational requirements +- Prescriptive technical standards -### Section 2: Governance Model +Would you like me to expand on any particular section or explain the reasoning behind specific synthesis choices? -1. The Cardano Blockchain shall use a model of participatory governance that: - - Enables direct participation by Ada holders - - Utilizes blockchain technology for transparency and verification - - Maintains checks and balances through multiple governance bodies - - Protects minority rights while enabling majority decision-making -### Section 3: Defined Terms +# CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION -For the purposes of this Constitution: +## PREAMBLE -1. **Ada**: The native cryptocurrency of the Cardano blockchain. -2. **Ada Holders**: Persons who control the private key(s) to ada token(s). -3. **Active Voting Stake**: The total lovelace considered active for voting purposes based on registration and activity requirements. -4. **Cardano Blockchain**: A public, proof-of-stake, peer-to-peer distributed ledger system operating under the name "Cardano". -5. **Cardano Community**: All participants in the Cardano ecosystem, including Ada holders, developers, operators, and users. -6. **Constitutional Committee (CC)**: The governing body responsible for ensuring governance actions comply with this Constitution. -7. **Delegated Representatives (DReps)**: Registered participants who vote on governance actions, either directly or on behalf of other Ada holders. -8. **Governance Action**: An on-chain proposal to modify the Cardano blockchain or its governance. -9. **Lovelace**: The smallest unit of ada (1/1,000,000 ada). -10. **Stake Pool Operators (SPOs)**: Operators of nodes that participate in block production. +The Cardano blockchain represents a decentralized digital infrastructure empowering individuals and communities to manage their identity, value, and governance in an open and permissionless manner. Through the evolution from its founding by Input Output Hong Kong, Emurgo, and the Cardano Foundation to the present community-driven governance model, Cardano has demonstrated its commitment to decentralization, transparency, and continuous improvement. -## ARTICLE II - ECOSYSTEM PRINCIPLES AND VALUES +This Constitution establishes a governance framework that balances the technical implementation of "code as law" with human judgment through the Constitutional Committee, while preserving the core values of decentralization, security, and sustainability. It serves as a living document to guide the ongoing development and governance of the Cardano ecosystem. -### Section 1: Core Values +## ARTICLE I. CARDANO BLOCKCHAIN TENETS AND GUARDRAILS -1. **Decentralization** - - Power and control shall be distributed among participants - - No single entity shall have disproportionate influence - - Decision-making shall be collaborative and inclusive +### Section 1: Purpose and Scope -2. **Transparency** - - Governance processes shall be visible and verifiable - - Decision rationales shall be documented and accessible - - Financial operations shall be auditable +These tenets shall guide all participants in the Cardano ecosystem and inform the evaluation of governance actions. The order of presentation does not imply priority among tenets. -3. **Security** - - The blockchain shall maintain robust security measures - - User assets shall be protected through cryptographic means - - Security measures shall adapt to emerging threats +### Section 2: Core Tenets -4. **Sustainability** - - The ecosystem shall operate in an environmentally conscious manner - - Economic models shall support long-term viability - - Resource usage shall be efficient and justified +1. **Transaction Processing** + - Transactions shall not be intentionally degraded or censored + - Transactions shall be processed expediently for their intended purpose + - The network shall maintain reasonable performance and reliability standards -### Section 2: Fundamental Tenets +2. **Economic Accessibility** + - Transaction costs shall be predictable + - Fees shall be structured to balance accessibility with network security + - The system shall prevent wasteful resource consumption -These tenets guide all participants in the Cardano ecosystem and shall be used to evaluate proposed governance actions. +3. **Development Freedom** + - Any individual or entity may develop and deploy non-malicious applications + - Innovation and experimentation shall be encouraged while maintaining security + - The ecosystem shall support both technical and social forms of composability -### Section 1: Core Principles +4. **Value Preservation** + - The total supply of ADA shall remain fixed at 45 billion + - The system shall preserve stored value and information in a secure manner + - No assets shall be spent, delegated, or staked without owner consent -1. The Cardano blockchain shall remain public and permissionless. -2. Valid transactions shall not be censored and shall be processed expediently. -3. Transaction costs shall be predictable and reasonable. -4. The blockchain shall preserve and protect stored value and information. -5. The total supply of ada shall not exceed 45 billion tokens. -6. The blockchain shall operate efficiently, minimizing unnecessary resource consumption. -7. The blockchain shall strive for security, reliability, and resilience. -8. The blockchain shall support interoperability while maintaining security. -9. All users shall have equal access to core blockchain functions. -10. The blockchain shall promote decentralization in its operation and governance. +5. **Equal Access** + - The blockchain shall remain permissionless and accessible to all + - Users shall be treated fairly while respecting collective governance decisions + - The system shall adapt based on community needs and technological progress -### Section 2: Technical Implementation +6. **Sustainability and Evolution** + - The ecosystem shall promote long-term sustainability + - Governance shall balance innovation with stability + - Resource usage shall be optimized through efficient design -1. The blockchain shall utilize peer-reviewed research and open-source development. -2. Changes to the protocol shall prioritize security, scalability, and sustainability. -3. The blockchain shall maintain post-quantum security readiness. -4. Protocol parameters shall be governed according to the Guardrails specified in Appendix I. +7. **Interoperability** + - The system shall not unreasonably impede interoperability + - Cross-chain collaboration shall be supported where feasible + - Standards and protocols shall promote ecosystem growth -### Section 3: Governance Principles +8. **Privacy and Transparency** + - The system shall support privacy-preserving use cases + - Core operations shall remain transparent and verifiable + - User privacy shall be protected while maintaining system integrity -1. Governance shall be transparent, inclusive, and accountable. -2. Decisions shall be made through structured on-chain voting mechanisms. -3. The community shall have the right to propose and vote on changes. -4. Treasury management shall require community oversight and approval. +### Section 3: Guardrails -## ARTICLE III - PARTICIPATION AND RIGHTS +The Cardano blockchain shall operate according to the technical guardrails defined in Appendix I. These guardrails: -### Section 1: Community Rights +- Set boundaries for protocol parameters +- Ensure secure and stable operation +- May be automated through on-chain scripts +- Can be updated through governance processes +- Take precedence in their on-chain implementation -1. **Access Rights** - - All persons may participate in the Cardano ecosystem - - No formal membership requirements shall be imposed - - Access to core functions shall be unrestricted +## ARTICLE II. THE CARDANO COMMUNITY -2. **Governance Rights** - - Ada holders may participate in governance directly or through delegation - - Proposal submission shall be open to all participants - - Voting rights shall be proportional to stake +### Section 1: Membership -3. **Development Rights** - - Anyone may develop and deploy applications - - Open-source collaboration shall be encouraged - - Innovation shall not be unreasonably restricted +No formal membership shall be required to use or participate in the Cardano blockchain. All ADA holders are considered beneficiaries of the ecosystem. -4. **Privacy Rights** - - User privacy shall be protected - - Data collection shall be minimized - - Consent shall be required for data gathering +### Section 2: Rights and Responsibilities -## ARTICLE IV - GOVERNANCE FRAMEWORK +Members of the Cardano community who own ADA: +- May participate in governance processes +- May delegate their voting rights +- Are expected to contribute constructively to governance +- Should respect collective decisions while maintaining individual rights -### Section 1: Governance Bodies +## ARTICLE III. GOVERNANCE FRAMEWORK -The Cardano blockchain shall be governed through three independent bodies: +### Section 1: Structure -1. **Delegated Representatives (DReps)** - - May be individuals or coordinated groups - - Register to vote on behalf of Ada holders - - Voting power proportional to delegated stake - - May adopt and publish codes of conduct - -2. **Stake Pool Operators (SPOs)** - - Operate consensus nodes - - Vote on technical parameters and hard forks - - Provide additional oversight on critical changes - - Must disclose if also acting as DReps +The governance framework consists of three bodies: +- Delegated Representatives (DReps) +- Stake Pool Operators (SPOs) +- Constitutional Committee -3. **Constitutional Committee** - - Reviews governance actions for constitutionality - - Comprises 3-9 members serving staggered terms - - Operates transparently and publishes decisions - - Members selected through community election +These bodies provide checks and balances while enabling efficient decision-making. ### Section 2: Governance Actions -The following types of governance actions are recognized: - -1. Motion of No-Confidence -2. Update Committee/Threshold/Term -3. New Constitution or Guardrails -4. Hard Fork Initiation -5. Protocol Parameter Changes -6. Treasury Withdrawals -7. Info Actions +Valid governance actions include: +- Motion of no-confidence +- Constitutional Committee updates +- Constitutional amendments +- Hard fork initiation +- Protocol parameter changes +- Treasury withdrawals +- Information actions ### Section 3: Voting Process -1. Each governance action requires specified thresholds from relevant bodies -2. Votes may be cast as "Yes", "No", or "Abstain" -3. Voting power is proportional to stake or delegation -4. Results are recorded on-chain for transparency - -## ARTICLE V - CONSENSUS AND TECHNICAL OPERATIONS - -### Section 1: Network Operations - -1. **Transaction Processing** - - Valid transactions shall be processed without discrimination - - Transaction ordering shall be based on objective criteria - - Network performance shall be continuously monitored - -2. **Protocol Updates** - - Changes shall undergo thorough testing and review - - Updates shall maintain backward compatibility where possible - - Emergency procedures shall exist for critical issues - -3. **Resource Management** - - Network resources shall be allocated fairly - - Scaling solutions shall be implemented as needed - - Performance impacts shall be carefully evaluated - -### Section 2: Technical Parameters - -1. **Parameter Governance** - - Changes shall follow established procedures - - Technical impacts shall be thoroughly assessed - - Community input shall be considered - -2. **Security Measures** - - Security shall be proactively maintained - - Threats shall be actively monitored - - Responses shall be timely and proportional - -## ARTICLE VI - TREASURY MANAGEMENT - -### Section 1: Principles - -1. The treasury shall be managed for the benefit of the Cardano ecosystem -2. Withdrawals require community approval through governance actions -3. Funded projects shall provide regular updates and undergo audits -4. The community shall establish and maintain oversight mechanisms - -### Section 2: Budget Process - -1. Annual budgets shall be proposed and approved by the community -2. Budgets shall specify oversight mechanisms and auditing requirements -3. Treasury withdrawals must align with approved budgets -4. Regular reporting on fund utilization shall be required - -## ARTICLE VII - DISPUTE RESOLUTION - -### Section 1: Resolution Framework - -1. **General Principles** - - Disputes shall be resolved fairly and transparently - - Resolution mechanisms shall be accessible to all parties - - Procedures shall be clearly documented - -2. **Resolution Methods** - - On-chain resolution shall be preferred where possible - - Off-chain mechanisms shall be available when needed - - Multiple resolution paths shall be provided - -### Section 2: Implementation - -1. **Resolution Bodies** - - The community shall establish appropriate bodies - - Resolution procedures shall be documented - - Appeals processes shall be available - -2. **Enforcement** - - Decisions shall be enforced through appropriate mechanisms - - Compliance shall be monitored - - Consequences shall be proportional - -## ARTICLE VIII - AMENDMENTS - -1. This Constitution may be amended through governance action -2. Amendments require approval from 67% of active voting stake -3. The Guardrails appendix may be updated through specified processes -4. Amendments shall not violate the fundamental tenets - -## ARTICLE IX - INTEROPERABILITY AND COLLABORATION - -### Section 1: Interoperability - -1. **Technical Interoperability** - - Standards shall promote interconnection - - Security shall not be compromised - - Innovation shall be encouraged - -2. **Ecosystem Collaboration** - - Cross-chain cooperation shall be supported - - Standards development shall be collaborative - - Best practices shall be shared - -### Section 2: External Relations - -1. **Community Relations** - - External engagement shall be encouraged - - Communication shall be transparent - - Partnerships shall benefit the ecosystem - -2. **Regulatory Compliance** - - Legal requirements shall be respected - - Compliance shall be voluntary - - Privacy shall be protected - -## APPENDIX I: GUARDRAILS - -[Technical specifications from current guardrails document to be included here] - -## APPENDIX II: INTERIM PERIOD PROVISIONS - -This appendix governs the transition period until full implementation of this Constitution. - -### Section 1: Timeline -1. The interim period begins with the Chang Hard Fork -2. Transitions shall occur in planned phases -3. Community readiness shall guide progression - -### Section 2: Governance -1. Initial governance actions shall be limited -2. Additional features shall be enabled progressively -3. Community preparation shall be prioritized - -### Section 3: Implementation -1. Technical rollout shall be carefully managed -2. Community feedback shall be incorporated -3. Progress shall be transparent - -## APPENDIX III: GLOSSARY +- Proposals must be clear and well-documented +- Voting power is proportional to stake +- Decisions require specified thresholds +- Results are recorded on-chain +- The process must remain transparent -### A +### Section 4: Treasury Management -**Active Block Production Stake**: The amount of ada actively delegated to SPOs for the purpose of block production. +- Withdrawals require approved budgets +- Large withdrawals need independent audits +- Funds must be used as specified +- Management must follow best practices -**Active Voting Stake**: The total amount of ada considered active for voting purposes, based on registration and activity requirements specified in the Guardrails. +## ARTICLE IV. DELEGATED REPRESENTATIVES -**Ada**: The native cryptocurrency of the Cardano blockchain, named after Ada Lovelace. The primary unit of value and governance participation within the Cardano ecosystem. +### Section 1: Role and Registration -**Ada Holders**: Persons or entities who control the private key(s) to ada token(s), whether directly or through authorized custodians. +- Any ADA holder may register as a DRep +- Registration requires a deposit +- DReps vote on governance actions +- Term limits may apply -### B +### Section 2: Responsibilities -**Block**: A fundamental unit of the blockchain containing transactions and other data, produced by SPOs according to the consensus protocol. +- Vote on governance proposals +- Represent delegated interests +- Maintain transparent operations +- Follow ethical guidelines -**Blockchain Neutrality**: The principle that transactions should not be censored or unreasonably delayed, and that all users should have fair access to the network. +## ARTICLE V. STAKE POOL OPERATORS -### C +### Section 1: Role -**Cardano Blockchain**: A public, proof-of-stake, peer-to-peer distributed ledger system operating under the name "Cardano". +- Operate network nodes +- Participate in block production +- Vote on technical proposals +- Maintain operational standards -**Cardano Community**: All participants in the Cardano ecosystem, including but not limited to Ada holders, developers, SPOs, DReps, and users. +### Section 2: Rights and Duties -**Cardano Ecosystem**: The entire environment of technology, applications, services, and community initiatives built around the Cardano blockchain. +- May accept stake delegation +- Must maintain reliable operations +- Participate in governance +- Follow network protocols -**Cardano Treasury**: The decentralized on-chain fund that holds and manages ada received from transaction fees, staking rewards, and monetary expansion. +## ARTICLE VI. CONSTITUTIONAL COMMITTEE -**Chang Hard Fork**: The network upgrade that enabled initial CIP-1694 governance features, marking the beginning of the interim period. +### Section 1: Purpose -**Constitutional Committee (CC)**: The governing body responsible for ensuring governance actions comply with this Constitution. +The Constitutional Committee ensures governance actions align with this Constitution. -**Consensus Protocol**: The mechanism by which the network agrees on the state of the blockchain, currently implemented as Ouroboros. +### Section 2: Structure -### D +- Size defined by guardrails +- Members serve staggered terms +- Requires diverse expertise +- Maintains operational independence -**DApp**: Decentralized Application - software applications that run on the Cardano blockchain. +### Section 3: Powers and Duties -**Delegated Representatives (DReps)**: Registered participants who vote on governance actions, either directly or on behalf of other Ada holders. +- Review governance actions +- Publish decisions with rationale +- Maintain transparent processes +- Foster community engagement -**Deposit**: An amount of ada required to perform certain actions (e.g., governance proposals, stake delegation) that may be returned under specified conditions. +## ARTICLE VII. AMENDMENTS -### E +### Section 1: Process -**Epoch**: A fixed time period (approximately 5 days) used for various blockchain operations including staking rewards calculation and governance timing. +Amendments require: +- Clear proposal documentation +- Community discussion period +- Specified voting thresholds +- Constitutional Committee review -### F - -**Final Constitution**: The permanent version of the Constitution that will replace any interim versions after community ratification. - -### G - -**Genesis Block**: The first block of the Cardano blockchain, containing the initial distribution of ada. - -**Governance Action**: A formal proposal submitted on-chain to modify the Cardano blockchain or its governance, including but not limited to parameter changes, treasury withdrawals, and constitutional amendments. - -**Guardrails**: Technical specifications and limitations designed to maintain the security, stability, and performance of the Cardano blockchain. - -### H - -**Hard Fork**: A non-backwards compatible upgrade to the network protocol, requiring all nodes to upgrade to maintain consensus. - -### I - -**Info Action**: A special type of governance action used to gauge community sentiment without making on-chain changes. - -**Interim Period**: The transition period between the Chang Hard Fork and the full implementation of this Constitution. - -### L - -**Liquid Democracy**: The governance model where Ada holders can either vote directly or delegate their voting power to representatives. - -**Lovelace**: The smallest unit of ada (1/1,000,000 ada), named after Ada Lovelace. - -### M - -**Mainnet**: The primary Cardano blockchain network where real ada transactions occur. - -**Motion of No-Confidence**: A governance action to reject the current Constitutional Committee. - -### N - -**Net Change Limit**: The maximum allowed change in Treasury balance over a specified period. - -**Node**: Software that participates in the Cardano network by validating and relaying transactions and blocks. - -### O - -**On-chain**: Actions or data recorded directly on the Cardano blockchain. - -**Off-chain**: Activities or information that exist outside the blockchain but may interact with or support it. - -### P - -**Parameter**: A configurable value that affects the operation of the Cardano blockchain. - -**Protocol**: The set of rules governing the operation of the Cardano blockchain. - -### Q - -**Quorum**: The minimum participation required for a governance action to be valid. - -### R - -**Reward**: Ada distributed to stake pools and delegators for participating in network consensus. - -### S - -**Stake**: The amount of ada held or delegated, representing voting power and potential block production rights. - -**Stake Pool**: A node configured to participate in block production, operated by an SPO. - -**Stake Pool Operator (SPO)**: An individual or entity that operates a stake pool, participating in block production and certain governance actions. - -### T - -**Treasury Withdrawal**: A governance action to distribute ada from the Cardano Treasury. - -### U - -**UTxO**: Unspent Transaction Output - the accounting model used by Cardano to track ada ownership. - -### V - -**Voting Power**: The influence an entity has in governance decisions, typically proportional to stake. - -### Additional Technical Terms - -**Plutus**: The smart contract platform of Cardano. - -**Protocol Parameters**: Configurable values that control various aspects of the blockchain's operation: - -- **maxBlockBodySize**: Maximum allowed size of a block body -- **maxTxSize**: Maximum allowed size of a transaction -- **minPoolCost**: Minimum fixed cost for running a stake pool -- **poolPledgeInfluence**: Parameter affecting rewards based on pool pledge -- **treasuryCut**: Portion of rewards allocated to the Treasury -- **executionUnitPrices**: Costs for executing Plutus scripts -- **maxBlockExecutionUnits**: Limits on script execution resources -- **dRepDeposit**: Required deposit to register as a DRep -- **govActionDeposit**: Required deposit for governance actions +### Section 2: Implementation -This glossary may be updated through governance actions to reflect new terms and evolving understanding of the ecosystem. +- Changes recorded on-chain +- Clear transition processes +- Maintaining system stability +- Community notification From 7e48ce914c5e0c068d4ccdd1b9609cc3ed960201 Mon Sep 17 00:00:00 2001 From: Latino_Staking_Pool <75137920+CL-LLC@users.noreply.github.com> Date: Mon, 25 Nov 2024 14:47:12 -0500 Subject: [PATCH 14/17] Update Claude 3 Opus.md --- CommunityDrafts/Claude 3 Opus.md | 192 +++++++++++++++++-------------- 1 file changed, 106 insertions(+), 86 deletions(-) diff --git a/CommunityDrafts/Claude 3 Opus.md b/CommunityDrafts/Claude 3 Opus.md index 743f49c..6bc787f 100644 --- a/CommunityDrafts/Claude 3 Opus.md +++ b/CommunityDrafts/Claude 3 Opus.md @@ -1,123 +1,143 @@ -Here is a synthesized draft of the Cardano Constitution based on the common values and principles from the community drafts, incorporating the insights from the working notes: +Here is my draft synthesis of the community Constitution documents provided: -# CARDANO CONSTITUTION +# Cardano Blockchain Ecosystem Constitution -## PREAMBLE +## Preamble -Recognizing that the Cardano Blockchain has grown into a decentralized ecosystem of technology, smart contracts, and community governance, committed to improving systems globally, we the Cardano Community hereby establish this Constitution. +The Cardano Blockchain enables the development of contracts, applications, and digital assets in a permissionless, decentralized manner. It was founded to improve economic, political, and social systems for everyone worldwide through unbiased processing of immutable data and the emergence of decentralized applications, businesses, and network states. -The Cardano Blockchain empowers individuals and communities to collaboratively manage identity, value, and governance. It is now operated in a decentralized manner, strengthening its resilience and autonomy. +Recognizing the need for a dynamic governance framework that relies on self-governance by the Cardano Community utilizing blockchain technology, we hereby establish this Constitution. It serves as a set of principles for the operation and governance of the Cardano Blockchain as a foundation that empowers individuals and communities to manage their identity, value, and governance. -As Cardano evolves, its governance must adapt to reflect principles of decentralization, accountability, and inclusivity. Through blockchain-based on-chain governance wherever possible, this Constitution provides a framework for all to contribute to Cardano's development. +The Cardano Community affirms our intention to abide by this Constitution in order to participate in the governance of the Cardano Blockchain ecosystem. We invite all who share our values to join us but stand not in the way of any who wish to take another path. -This Constitution is a living document to be interpreted giving effect to the following core tenets. The Preamble provides context but is non-binding. +## Article I. Tenets and Guardrails -## ARTICLE I. CORE TENETS +### Section 1: Tenets -### SECTION 1. GUIDING PRINCIPLES +These Tenets shall guide all participants of the Cardano Community. Proposed governance actions shall be evaluated in accordance with them. -The Cardano Blockchain shall strive to uphold these guiding principles: +1. Transactions on the Cardano Blockchain shall not be intentionally slowed down or censored. -1. Maintain a secure, transparent, inclusive and decentralized public blockchain. -2. Promote efficient functionality and resource usage without compromising accessibility or sustainability. -3. Enable community-driven governance based on legitimacy and broad representation. -4. Ensure financial stability and a predictable long-term economic model. -5. Preserve and incentivize stakeholder contributions to the ecosystem. -6. Uphold user privacy and control over personal data and assets. -7. Foster open innovation, interoperability and collaboration. -8. Continuously adapt to technological, social and regulatory evolutions. +2. The cost of transactions should be predictable and reasonable. -### SECTION 2. BLOCKCHAIN FUNCTIONALITY +3. Anyone desiring to develop and deploy non-malicious applications on the Cardano Blockchain shall not unreasonably be prevented from doing so. -1. Transactions shall be processed efficiently for their intended purpose without undue delay or censorship. -2. Transaction costs should follow an accessible and predictable model. -3. The Cardano Blockchain shall not unreasonably restrict application development or impede interoperability. -4. Ledger history shall be immutable and assets therein securely preserved. +4. The Cardano Blockchain shall recognize contributions through reward sharing with stake pools and DReps via appropriate tokenomics and consensus mechanisms. -### SECTION 3. GOVERNANCE VALUES +5. The Cardano Blockchain shall not modify an ADA owner's value without consent. -1. Majority rule shall prevail in governance decisions while respecting minority views and avoiding marginalization of any segment of the community. -2. All users shall have fair opportunity to participate in governance proportional to their stake. -3. No stakeholder group (SPOs, DReps, CC members, Ada holders) shall unilaterally impose decisions without required approvals. -4. Governance shall remain decentralized and avoid undue accumulation of power. +6. The Cardano Blockchain shall not unreasonably impede interoperability with other blockchains. -## ARTICLE II. COMMUNITY AND MEMBERSHIP +7. The Cardano Blockchain shall preserve in a safe manner any information an ADA owner seeks to store on the blockchain. -1. All Ada holders, developers, SPOs and other supporters of the Cardano Blockchain shall be considered part of the Cardano Community and beneficiaries of this Constitution. Formal membership is not required for participation. -2. Ada holders are entitled to participate in on-chain governance, including proposing and voting on actions, in accordance with this Constitution and the Cardano Blockchain's technical Guardrails. +8. The Cardano Blockchain shall not unnecessarily spend or waste resources. -## ARTICLE III. GOVERNANCE MODEL +9. All users shall be treated fairly, taking into account the collective desires of the community, consistent with the long-term sustainability and viability of Cardano. -1. On-chain governance shall serve as the primary decision-making model utilizing smart contracts and blockchain-based tools. -2. Governance bodies - the Constitutional Committee (CC), Delegated Representatives (DReps), and Stake Pool Operators (SPOs) - shall provide decentralized checks and balances, with specified quorums and thresholds. -3. DReps shall represent Ada holders' stake and vote on their behalf. SPOs shall approve technical changes like hard forks and parameter updates. CC shall ensure actions comply with this Constitution. -4. Details on governance processes, voting, and quorums shall be as specified in the Blockchain Guardrails document, subject to change via on-chain updates. -5. An annual on-chain budget shall govern the usage of the Cardano Treasury, with funds disbursed transparently for ecosystem development and sustainability as approved by the Community. +10. The total supply of ADA shall not exceed 45 billion and will not be burned or increased. -## ARTICLE IV. BLOCKCHAIN PARAMETERS AND GUARDRAILS +### Section 2: Guardrails -1. The technical parameters and limitations of the Cardano Blockchain, including those related to economic, network, governance, and security aspects, shall be detailed in the Cardano Blockchain Guardrails document. -2. The Guardrails shall aim to ensure the blockchain operates securely and sustainably, avoiding disruptions or vulnerabilities. They apply to on-chain governance actions like parameter changes and Treasury usage. -3. Where possible, Guardrails shall be automated and enforced through on-chain scripts or ledger rules. Amendments to the Guardrails shall follow the process for Constitutional amendments. -4. Inconsistencies between the implemented on-chain parameters and the Guardrails document shall be resolved by deeming the on-chain implementation authoritative while the CC works to rectify the documentation. +The Cardano Blockchain shall operate in accordance with the Guardrails as set forth in the Guardrails Appendix to this Constitution. The community may digitally codify Guardrails to allow their implementation on-chain. Where there are inconsistencies between the Guardrails Appendix and what is implemented on-chain, the on-chain version shall prevail and the Constitutional Committee shall reconcile the inconsistencies. -## ARTICLE V. GOVERNANCE BODIES AND PROCEDURES +## Article II. The Cardano Community -### SECTION 1. DELEGATED REPRESENTATIVES (DReps) +### Section 1 -1. Any Ada holder may register as a DRep to represent the stake delegated to them in governance votes. Registration procedures and fees shall be as specified in the Guardrails. -2. DReps shall vote on behalf of their delegators in accordance with delegator instructions where provided, or otherwise at their discretion in line with their published policies and the best interests of the Cardano ecosystem. -3. DReps shall maintain public transparency about their voting policies, rationales, and potential conflicts of interest. They may be compensated for their efforts as approved by the Community. +No formal membership shall be required to use, participate in, and benefit from the Cardano Blockchain. All ADA owners are beneficiaries of the Cardano ecosystem and collectively members of the Cardano community. -### SECTION 2. STAKE POOL OPERATORS (SPOs) +### Section 2 -1. SPOs shall participate in governance decisions related to the operation and integrity of the Cardano Blockchain, with voting power proportional to their stake. -2. SPOs must abide by the technical requirements and performance standards defined in the Guardrails to ensure network security and liveness. -3. SPOs shall disclose if they are also voting as DReps or CC members on any given proposal to avoid conflicts of interest. +ADA owners are entitled to access and participate in the on-chain governance processes of the Cardano ecosystem, including voting, subject to this Constitution. -### SECTION 3. CONSTITUTIONAL COMMITTEE (CC) +## Article III. Governance -1. The CC shall be composed of 3-9 members serving staggered terms as defined in the Guardrails, elected by Ada holders via on-chain voting. -2. The CC shall review all governance proposals for compliance with this Constitution before such proposals proceed to a vote by DReps or SPOs. -3. The CC may veto proposals deemed unconstitutional but shall otherwise remain neutral. CC deliberations and decisions shall be made public. -4. A proposal to remove and replace all or some CC members may be brought via a DRep-initiated on-chain action subject to required thresholds. +### Section 1 -### SECTION 4. GOVERNANCE ACTIONS AND VOTING +The Cardano ecosystem shall be governed by a decentralized, on-chain model, utilizing smart contracts and blockchain tools to facilitate decision-making and transparency. On-chain voting shall follow the processes in the Guardrails. -1. Any community member may submit a governance proposal in the required format, subject to any deposit requirements in the Guardrails. -2. Proposals shall be classified into standardized types like Treasury Withdrawals, Parameter Changes, Constitutional Amendments, etc. as defined in the Guardrails, each with specified procedures and thresholds. -3. Voting on proposals shall be recorded on-chain, with outcomes determined by the applicable DRep, SPO, or Ada holder majority thresholds reached. -4. For expedited action in emergencies, the CC may provisionally approve temporary measures which must then be ratified or rejected via a standard governance vote within a defined timeframe. +### Section 2 -## ARTICLE VI. TREASURY AND FUNDS MANAGEMENT +Three independent governance bodies shall participate in voting to provide checks and balances: -1. The Cardano Treasury shall be governed by an annual on-chain budget proposed by the community and approved by Ada holders. -2. Treasury withdrawals shall only be permitted in accordance with the approved Budget and subject to any transparency and reporting requirements in the Guardrails. -3. Community members may bring proposals for Treasury funding, which shall be approved via on-chain voting by DReps and Ada holders as per defined thresholds. -4. An elected Treasury Committee of experts may be established to provide oversight and auditing of significant expenditures as defined in the Guardrails. +1. Delegated Representatives (DReps) +2. Stake Pool Operators (SPOs) +3. Constitutional Committee (CC) -## ARTICLE VII. DISPUTE RESOLUTION +### Section 3 -1. The community shall work to resolve disputes internally wherever possible via transparent, documented discussions and established governance procedures. -2. An on-chain arbitration mechanism may be established to adjudicate disputes related to on-chain actions. Its decisions shall be considered binding where not contradicted by applicable external laws. -3. For disputes not resolvable internally, the community shall develop guidelines for which external jurisdictions and mechanisms are acceptable to resolve different classes of issues. -4. The CC may mediate disputes and recommend resolutions, but shall not be a mandatory arbitrator. The CC should help develop the on-chain dispute resolution system. +On-chain governance decisions shall be made through a collective process, with consensus thresholds as required by the Guardrails. All governance actions shall be voted on in accordance with the Guardrails. -## ARTICLE VIII. AMENDMENTS AND INTERPRETATION +### Section 4 -1. Amendments to this Constitution shall require approval via on-chain action by DReps with a minimum 67% threshold of active stake. -2. CC shall be the arbiter for interpretation of this Constitution and conformity of actions to it. -3. In case of conflict between this Constitution and the technical Guardrails implemented on-chain, the on-chain rules shall prevail while CC works to resolve the inconsistency. -4. This Constitution shall be reviewed periodically to adapt to evolutions in technology, governance needs, and regulations. +All ADA owners shall have the right to propose changes to the governance structure according to the Guardrails. The process for participating in, submitting, and voting on governance actions shall be open, transparent, and protected from undue influence. -## APPENDIX: COMMUNITY GOVERNANCE DEFINITIONS +### Section 5 -Key terms used in this Constitution shall be understood as defined here: -- Ada holders: Persons controlling private keys of Ada assets. -- Cardano Blockchain: The public proof-of-stake blockchain operated by the Cardano protocol. -- Cardano Treasury: An on-chain reserve of Ada for ecosystem funding. -- CC: Constitutional Committee ensuring governance conforms to this Constitution. -- DRep: Delegated Representative voting on behalf of Ada holders. -- Guardrails: Technical implementation of governance parameters on-chain. -- On-chain: Actions recorded and executed on the Cardano Blockchain. -- SPO: Stake Pool Operator running Cardano protocol nodes. +Any proposed governance action shall require a standardized format including a hash linked to off-chain content. Rationale shall be provided to justify the requested change. "Hard Fork" and "Protocol Parameter Change" governance actions shall undergo technical scrutiny to ensure they do not endanger the security, functionality, or performance of Cardano. + +### Section 6 + +The community is expected to propose, at least annually, a budget for ongoing maintenance and development. No treasury withdrawals shall occur unless a budget is in effect per the Guardrails. Any treasury request over 1,000,000 ADA shall require a periodic independent audit. + +## Article IV. Delegated Representatives (DReps) + +### Section 1 + +ADA owners may register as DReps and vote directly on governance actions or may delegate their voting rights to registered DReps to vote on their behalf. + +### Section 2 + +Any ADA owner can register as a DRep. ADA owners can delegate voting stake to one or more registered DReps, including themselves. This enshrines a liquid democracy model. + +### Section 3 + +DReps may adopt and publish codes of conduct for their activities as DReps but are not expressly required. + +### Section 4 + +DReps shall act as a check on the Constitutional Committee by voting on motions of no-confidence and updates to the committee/threshold. + +## Article V. Stake Pool Operators (SPOs) + +### Section 1 + +SPOs shall approve critical governance actions requiring additional oversight, voting independently from DReps as set forth in the Guardrails. SPOs shall participate in hard fork initiation as the node operators. + +### Section 2 + +SPOs shall act as a check on the Constitutional Committee by voting on motions of no-confidence and updates to the committee/threshold. + +## Article VI. Constitutional Committee (CC) + +### Section 1 + +A Constitutional Committee shall be established to ensure governance actions are consistent with this Constitution. The CC shall be limited to voting on the constitutionality of governance actions. + +### Section 2 + +The CC shall be composed of a number of ADA owners as determined by the Guardrails. CC members shall serve staggered terms as consistent with the Guardrails, no less than one year unless approved on-chain. + +### Section 3 + +The community shall establish a process for electing CC members consistent with the Guardrails. + +### Section 4 + +No governance action, other than a motion of no-confidence or update to the CC, may be implemented on-chain unless the CC has affirmed it does not violate this Constitution. + +The CC shall be in a state of confidence or no-confidence at all times. In a state of no-confidence, CC members must be reinstated or replaced before any other governance action may go forward. + +### Section 5 + +The CC shall publish each decision. When rejecting an action, the CC shall set forth the basis with reference to specific Articles of this Constitution. + +The CC shall operate pursuant to a code of conduct published by the CC and adopt policies and procedures as the CC deems necessary. + +## Article VII. Amendments + +Amendments to this Constitution require approval through an on-chain governance action by ADA owners satisfying a threshold of 67% of active stake, except as otherwise provided in the Guardrails Appendix. + +## Appendix I: Cardano Guardrails + +The Guardrails Appendix sets forth the full technical parameters and voting thresholds required to maintain the functionality, security and performance of the Cardano Blockchain. It is an integral part of this Constitution but has been attached separately given its length and technical nature. From b4975c0c628e4b376190c3a6a9a800100b6e282d Mon Sep 17 00:00:00 2001 From: rwiley <30681834+Cerkoryn@users.noreply.github.com> Date: Tue, 26 Nov 2024 22:35:29 -0500 Subject: [PATCH 15/17] Alternate languages and separate AI drafts --- .../Claude 3 Opus.md | 0 .../Claude 3.5 Sonnet.md | 0 {CommunityDrafts => AI_Drafts}/Grok.md | 0 {CommunityDrafts => AI_Drafts}/gpt-4o.md | 0 .../gpt-o1-preview.md | 0 AlternateLanguageDrafts/Hindi.md | 373 +++++++++++++++++ AlternateLanguageDrafts/Japanese.md | 376 ++++++++++++++++++ AlternateLanguageDrafts/Portuguese.md | 280 +++++++++++++ AlternateLanguageDrafts/Spanish.md | 280 +++++++++++++ 9 files changed, 1309 insertions(+) rename {CommunityDrafts => AI_Drafts}/Claude 3 Opus.md (100%) rename {CommunityDrafts => AI_Drafts}/Claude 3.5 Sonnet.md (100%) rename {CommunityDrafts => AI_Drafts}/Grok.md (100%) rename {CommunityDrafts => AI_Drafts}/gpt-4o.md (100%) rename {CommunityDrafts => AI_Drafts}/gpt-o1-preview.md (100%) create mode 100644 AlternateLanguageDrafts/Hindi.md create mode 100644 AlternateLanguageDrafts/Japanese.md create mode 100644 AlternateLanguageDrafts/Portuguese.md create mode 100644 AlternateLanguageDrafts/Spanish.md diff --git a/CommunityDrafts/Claude 3 Opus.md b/AI_Drafts/Claude 3 Opus.md similarity index 100% rename from CommunityDrafts/Claude 3 Opus.md rename to AI_Drafts/Claude 3 Opus.md diff --git a/CommunityDrafts/Claude 3.5 Sonnet.md b/AI_Drafts/Claude 3.5 Sonnet.md similarity index 100% rename from CommunityDrafts/Claude 3.5 Sonnet.md rename to AI_Drafts/Claude 3.5 Sonnet.md diff --git a/CommunityDrafts/Grok.md b/AI_Drafts/Grok.md similarity index 100% rename from CommunityDrafts/Grok.md rename to AI_Drafts/Grok.md diff --git a/CommunityDrafts/gpt-4o.md b/AI_Drafts/gpt-4o.md similarity index 100% rename from CommunityDrafts/gpt-4o.md rename to AI_Drafts/gpt-4o.md diff --git a/CommunityDrafts/gpt-o1-preview.md b/AI_Drafts/gpt-o1-preview.md similarity index 100% rename from CommunityDrafts/gpt-o1-preview.md rename to AI_Drafts/gpt-o1-preview.md diff --git a/AlternateLanguageDrafts/Hindi.md b/AlternateLanguageDrafts/Hindi.md new file mode 100644 index 0000000..9f5702d --- /dev/null +++ b/AlternateLanguageDrafts/Hindi.md @@ -0,0 +1,373 @@ +# कार्डेनो ब्लॉकचेन का संविधान + +## प्रस्तावना + +1. इस बात को स्वीकार करना कि तीन प्रमुख संगठनों, इनपुट-आउटपुट हॉन्ग कॉन्ग, एमर्गो और कार्डेनो फाउंडेशन ने, कार्डेनो समुदाय के सहयोग से, कार्डेनो ब्लॉकचेन के उद्भव को बढ़ावा दिया है, जिसने एक विकेन्द्रीकृत डिजिटल आधारभूत ढाँचे की नींव रखी है जो व्यक्तियों को सशक्त बनाता है और सहयोग तथा नवाचार को प्रोत्साहित करता है। उनके प्रयासों ने व्यक्तियों और संगठनों का एक जीवंत और विविधतापूर्ण वातावरण तैयार किया है जहां कोई भी कार्डेनो इकोसिस्टम के विकास और सफलता में योगदान दे सकता है। + +2. इस बात को स्वीकार करना कि कार्डेनो ब्लॉकचेन, ब्लॉकचेन टेक्नोलॉजी, स्मार्ट अनुबंधों और सामुदायिक प्रशासन के विकेन्द्रीकृत परिवेश के भीतर मौजूद है जो वैश्विक आर्थिक, राजनीतिक और सामाजिक प्रणालियों में सुधार के लिए प्रतिबद्ध है। कार्डेनो ब्लॉकचेन एक आधारभूत ढाँचा प्रदान करती है जो व्यक्तियों और समुदायों को उनकी पहचान, मूल्यों और प्रशासन का प्रबंधन करने के लिए सशक्त बनाता है, जो विकेंद्रीकृत अनुप्रयोगों, व्यवसायों और नेटवर्क के उद्भव को प्रोत्साहित करता है। + +3. इस बात को स्वीकार करना कि कार्डेनो इकोसिस्टम का काफी विस्तार हुआ है और यह विकेंद्रीकृत और अनुमति-रहित तरीके से संचालित होता है, जिससे कार्डेनो ब्लॉकचेन की अनुकूलन क्षमता और स्वायत्तता और अधिक सशक्त हुई है। + +4. यह बात को ध्यान में रखते हुए कि कार्डेनो इकोसिस्टम का विकास जारी है, इसके प्रशासन मॉडल को भी इसके सिद्धांतों को प्रतिबिंबित करने के लिए अनुकूलित और विकसित करने की आवश्यकता है, जिसमें विकेंद्रीकरण, सामुदायिक भागीदारी, जवाबदेही, समावेशिता और सहयोग शामिल हैं, जो स्व-शासन और मानव संपर्क सहयोग के नए तरीकों का आधार हैं। + +5. इस बात को स्वीकार करना कि शासन का एक अधिक सशक्त और अनुकूलनीय ढाँचे की आवश्यकता है, जो जहाँ भी संभव और लाभकारी हो, ऑन-चेन शासन को स्थापित करने के लिए ब्लॉकचेन तकनीक का उपयोग करता है, कार्डेनो समुदाय इसके तकनीकी गार्डरेल्स सहित इस कार्डेनो संविधान की स्थापना करता है जो अनुमेय प्रशासनिक कार्रवाईयों के लिए सुरक्षा उपायों का एक संकलन प्रदान करता है। कार्डेनो संविधान कार्डेनो ब्लॉकचेन के संचालन और शासन के लिए सिद्धांतों को कार्डेनो इकोसिस्टम के विकास में योगदान देने के लिए एक नींव के रूप में निर्धारित करता है। + +6. विश्वास और सहयोग वाले परिवेश का पालन करना, जो यह सुनिश्चित करता है कि पारदर्शिता, खुलेपन और उत्तरदायित्व के सिद्धांतों के अनुसार कार्डेनो इकोसिस्टम के सर्वोत्तम हित में निर्णय लिए जाएं, कार्डेनो कम्युनिटी कार्डेनो ब्लॉकचेन और कार्डेनो इकोसिस्टम के निरंतर सुधार, विकास और सफलता की दिशा में मिलकर काम करने का प्रयास करता है। + +7. इस बात को स्वीकार करना कि SPOs और सभी Ada धारकों को कार्डेनो ब्लॉकचेन के प्रशासन में योगदान करने का अवसर प्रदान करना महत्वपूर्ण है, ताकि दृष्टिकोणों की विविधता को बढ़ावा दिया जा सके। + +8. इस बात को स्वीकार करना कि Ada धारक किसी भी संगठन या सहयोगी से स्वतंत्र रूप से कार्डेनो ब्लॉकचेन के शासन में योगदान करने के लिए स्वतंत्र हैं। + +9. इस बात को स्वीकार करना कि कार्डेनो ब्लॉकचेन की प्रकृति अंततः सॉफ्टवेयर कोड द्वारा कार्यान्वित एक निर्माण है और इसलिए इस संविधान को बनाए रखने और लागू करने में इसके डेवलपर्स और इंजीनियरों की एक महत्वपूर्ण भूमिका और अपेक्षा है। + +10. इस बात को स्वीकार करना कि संविधान को यथावत रखने में संवैधानिक समिति की आवश्यक भूमिका और Ada धारकों के प्रतिनिधियों के रूप में DReps का महत्व है। + +11. इस बात को स्वीकार करना कि कार्डेनो की ट्रेज़री को कार्डेनो समुदाय के लिए उपलब्ध संसाधनों के स्थायी, उत्तरदायी और प्रभावी उपयोग के लिए एक ढाँचे की आवश्यकता है। + +12. इस बात को स्वीकार करना कि कार्डेनो समुदाय को कार्डेनो इकोसिस्टम के सामने आने वाली चुनौतियों का समाधान करने के लिए आपस में नए सहयोगी संगठन बनाने का अधिकार है। + +## अनुच्छेद I. परिभाषित नियम + +1. **सक्रिय ब्लॉक के उत्पादन की भागीदारी** + इसका अर्थ है, SPO के संबंध में, लवलेस की संख्या जो सक्रिय रूप से ब्लॉक के उत्पादन कार्य के लिए SPO को सौंपी गई है। + +2. **सक्रिय मतदान की भागीदारी** + सक्रिय मतदान हिस्सेदारी लवलेस की कुल संख्या को संदर्भित करती है जिसे सक्रिय माना जाता है, आवश्यक मतदान गतिविधि और मतदान के लिए पंजीकरण के आधार पर जैसा कि गार्डरेल्स में निर्दिष्ट है, और मत निर्धारित करने के उद्देश्यों के लिए गिना जाता है। + +3. **ada** + इसका अर्थ है वह क्रिप्टोकरेंसी जो मूलतः कार्डेनो ब्लॉकचेन की है। + +4. **Ada धारक** + इसका अर्थ है ऐसे व्यक्ति हैं जो प्रत्यक्ष या अप्रत्यक्ष रूप से ada टोकन(नों) के लिए निजी कुंजी(यों) को नियंत्रित करते हैं। + +5. **कुल परिवर्तन की सीमा अवधि** + इसका अर्थ है 73 युगों (लगभग एक वर्ष) की अवधि जिसमें कुल परिवर्तन सीमा की एक राशि प्रभावी रहती है। + +6. **कार्डेनो ब्लॉकचेन** + "कार्डेनो" नाम से संचालित एक सार्वजनिक, प्रूफ-ऑफ-स्टेक, पीयर-टू-पीयर, वितरित लेज़र प्रणाली। + +7. **कार्डेनो समुदाय** + कार्डेनो समुदाय सभी Ada धारकों को संदर्भित करता है। + +8. **कार्डेनो इकोसिस्टम** + कार्डेनो इकोसिस्टम से कार्डेनो ब्लॉकचेन पर गतिविधि करने वाले सभी प्रतिभागियों का संदर्भ होता है, जिसमें SPO, DRep, कार्डेनो समुदाय और CC शामिल हैं, लेकिन यह इन्हीं तक सीमित नहीं हैं। + +9. **कार्डेनो ट्रेज़री** + कार्डेनो ट्रेज़री एक विकेन्द्रीकृत ऑन-चेन ada प्रबंधन प्रणाली है जो लेन-देन के शुल्क और मौद्रिक विस्तार से प्राप्त एडा को अपने पास रखती है और प्रदान करती है। + +10. **संवैधानिक समिति** + इसका अर्थ है संविधान के सिद्धांतों को बनाए रखने और लागू करने के लिए उत्तरदायी शासकीय निकाय। + +11. **नियुक्तक** + Ada धारक, जिसने अपनी हिस्सेदारी को हिस्सेदारी के किसी पूल (ब्लॉक उत्पादन के लिए) और/या एक DRep (प्रशासन के लिए) को सौंप दिया है। + +12. **DRep या नियुक्त प्रतिनिधि** + एक विधिवत पंजीकृत प्रतिनिधि, जो प्रशासनिक कार्रवाईयों पर मतदान करता है। + +13. **प्रशासनिक कार्रवाई** + इसका अर्थ है कार्डेनो ब्लॉकचेन के मापदंडों पर जानकारी रिकॉर्ड करने की क्रिया, उसके संबंध में कार्रवाई करना या उसे संशोधित करना, जिसे कार्डेनो ब्लॉकचेन पर मतदान के योग्य संस्थानों द्वारा मतदान के लिए प्रस्तुत किया जाता है। + +14. **प्रशासन की कार्रवाई का प्रस्ताव** + इसका अर्थ है शासन की संभावित कार्रवाई के लिए प्रस्ताव जो कार्डेनो समुदाय के सदस्य या संवैधानिक समिति के सदस्य द्वारा कार्डेनो समुदाय द्वारा चर्चा या विचार के लिए प्रस्तुत किया जाता है। + +15. **शासनिक निकाय** + इसका अर्थ है कोई संगठन या समूह जिसके पास संविधान में वर्णित प्रशासन की कार्रवाई पर मतदान करने का अधिकार होता है, जिसमें वर्तमान में DRep, संवैधानिक समिति और SPO शामिल हैं। + +16. **गार्डरेल** + गार्डरेल से कार्डेनो ब्लॉकचेन की कार्यक्षमता, सुरक्षा और प्रदर्शन को बनाए रखने के लिए आवश्यक शर्तों और मापदंडों का संदर्भ होता है, जिनमें से कुछ, परंतु सभी नहीं, सीधे कार्डेनो ब्लॉकचेन पर लागू होते हैं। + +17. **गार्डरेल आलेख** + प्लूटस आलेख जो संविधान के साथ चेन पर दर्ज किया जाता है, और जो चेन पर शासन की कार्र्वाई को जमा किए जाने पर स्वचालन योग्य गार्डरेल को लागू करती है। + +18. **लवलेस** + इसका अर्थ है ada की एक इकाई, जिसमें प्रत्येक ada के लिए एक मिलियन लवलेस होते हैं। + +19. **कम लागत वाला आक्रमण** + ऐसा आक्रमण जिसके लिए बहुत कम ada, प्रयास या अन्य संसाधनों की आवश्यकता होती है। इन मात्रिकों के लिए स्वीकार्य मूल्य निर्धारित किए जाने की आवश्यकता है। + +20. **मेननेट वातावरण** + इसका अर्थ है कार्डेनो ब्लॉकचेन प्रोटोकॉल की आधार परत जो लाइव है और परिचलन में है। + +21. **कुल परिवर्तन की सीमा राशि** + इसका अर्थ है ada में वह सीमा जिसके द्वारा कार्डेनो ट्रेज़री किसी निश्चित अवधि में नहीं बदलेगी। + +22. **ऑन-चेन और ऑफ-चेन** + "ऑन-चेन" का अर्थ है वह क्रियाएं जो कार्डेनो ब्लॉकचेन पर दिखाई देती हैं। "ऑफ-चेन" का अर्थ है वह क्रियायेंएं जो कार्डेनो ब्लॉकचेन पर दिखाई नहीं देती हैं, परंतु इस संविधान द्वारा शासित होती हैं। + +23. **मापदंड** + इसका अर्थ है कार्डेनो ब्लॉकचेन के कार्यान्वयन के लिए व्यवस्थाएं और सीमाएं जो संविधान में निर्दिष्ट हैं। + +24. **प्रोटोकॉल** + इसका अर्थ है कार्डेनो ब्लॉकचेन SDR के संचालन को नियंत्रित करने वाले एल्गोरिदम, नियम और + +25. **प्रक्रियाएं** + इसका अर्थ है "विशेष आहरण अधिकार", जो अंतर्राष्ट्रीय मुद्रा कोष द्वारा बनाई गई विश्व मुद्राओं के एक संग्रहण के मूल्य के आधार पर एक अंतर्राष्ट्रीय आरक्षित संपत्ति को संदर्भित करता है। "फ़िएट" के संदर्भ SDR के संदर्भ बनेंगे। + +26. **SPO** + स्टेक पूल ऑपरेटर, जो कार्डेनो ब्लॉक-उत्पादक नोड को चलाता है। + +27. **मतदान** + का अर्थ है कार्डेनो ब्लॉकचेन पर प्रस्तावित प्रशासनिक कार्रवाईयों पर व्यक्त किए गए निर्णय। + +## अनुच्छेद II प्रयोजनीयता + +1. यह संविधान कार्डेनो समुदाय के सभी सदस्यों, DRep, SPO और संवैधानिक समिति के सदस्यों पर लागू होगा, जब तक कि वे कार्डेनो ब्लॉकचेन और कार्डेनो इकोसिस्टम में एक दूसरे के साथ पारस्परिक संवाद करते हैं। + +2. चूँकि यह प्रस्तावना इस संविधान के लिए तर्क प्रदान करती है, इसे प्रस्तावित प्रशासनिक कार्यर्र्वाईयों की संवैधानिकता का आँकलन करने के उद्देश्य से गैर-बाध्यकारी माना जायेगा। + +3. नीचे दिए गए अनुच्छेद III में निर्धारित सिद्धांतों को प्रभावी बनाने के लिए इस संविधान की व्याख्या की जायेगी। + +## अनुच्छेद III सिद्धांत और गार्डरेल + +### अनुभाग 1: उद्देश्य और दायरा + +इस अनुच्छेद में दिए गए सिद्धांतों का उद्देश्य कार्डेनो इकोसिस्टम में सभी कार्यकर्त्ताओं का मार्गदर्शन करना है, जिसमें कार्डेनो संवैधानिक समिति, SPO, DRep और Ada धारक शामिल हैं। सभी प्रशासनिक कार्रवाईयों का मूल्यांकन इन सिद्धांतों के अनुसार किया जायेगा। + +### अनुभाग 2: कार्डेनो के सिद्धांत + +1. कार्डेनो ब्लॉकचेन अपनी सार्वजनिक और अनुमतिहीन प्रकृति को बनाए रखेगी। +2. कार्डेनो ब्लॉकचेन प्रशासन की प्रक्रियाएं सुलभ, पारदर्शी और अनुकूलनीय होंगी। +3. कार्डेनो ब्लॉकचेन का विकास और संचालन सुरक्षा, विश्वसनीयता और अनुकूलनीयता को प्राथमिकता देगा, जिसमें विफलता या निर्भरता के एकल बिंदुओं से बचना शामिल है, लेकिन यह इन्हीं तक सीमित नहीं है। +4. कार्डेनो इकोसिस्टम वित्तीय स्थिरता के लिए प्रयास करेगा। +5. ada की कुल आपूर्ति 45,000,000,000 ada (45,000,000,000,000,000 लवलेस) से अधिक नहीं होगी। +6. मूल्य और जानकारी की सुरक्षा सुनिश्चित करने के लिए, कार्डेनो ब्लॉकचेन पोस्ट-क्वांटम सुरक्षा, विकेंद्रीकृत भंडारण और कुंजी के तटस्थ प्रबंधन के दृष्टिकोणों के लिए प्रयास करेगा। +7. कार्डेनो इकोसिस्टम कार्डेनो ब्लॉकचेन के विकेंद्रीकरण के लिए प्रयास करेगा जिसमें स्केलेबल ऑन- एवं ऑफ-चेन समाधान शामिल हैं जो पहुँच, आर्थिक स्थिरता, सुरक्षा और प्रदर्शन के साथ अनुचित व्यवसाय क्रियाओं के बिना प्रवाह क्षमता, टुकड़े, निपटान और गतिशील मूल्य निर्धारण पर विचार करते हैं। +8. कार्डेनो ब्लॉकचेन दीर्घकालिक स्थिरता और व्यवहार्यता का पालन करेगी, जैसे कि निष्पक्षता, तटस्थता, स्थिरता, शसक्त प्रशासन, विकेंद्रीकृत पहचान को बढ़ावा देने, कार्डेनो कम्युनिटी द्वारा सहयोग और भागीदारी जैसी विशेषताओं में परिलक्षित होता है। +9. कार्डेनो ब्लॉकचेन को सुरक्षा, अनुकूलता और पहुँच को बढ़ावा देने और केंद्रीकरण के जोखिमों को कम करने के लिए एक मुक्त-स्रोत वाली, सहयोगात्मक पद्धति में विकसित किया जायेगा, और यह हर समय एक अनुमेय मुक्त-स्रोत वाले लाइसेंस के तहत उपलब्ध रहेगा। +10. कार्डेनो इकोसिस्टम में सभी प्रतिभागियों के साथ निष्पक्ष व्यवहार किया जाएगा और प्रशासनिक कार्यवाहियों पर विचार करते समय उनके हितों को ध्यान में रखा जायेगा। +11. कार्डेनो ब्लॉकचेन को अन्य ब्लॉकचेन के साथ अंतर-संचालन क्षमता और पहुँच को बढ़ावा देना चाहिए। +12. कार्डेनो ब्लॉकचेन अनावश्यक रूप से ऑन-चेन संसाधनों पर खर्च नहीं करेगी। +13. कार्डेनो ब्लॉकचेन हार्डवेयर संसाधनों के कुशल डिज़ाइन और उपयोग को बढ़ावा देगी। +14. कार्डेनो ब्लॉकचेन निष्पक्ष और उचित टोकनोमिक्स के माध्यम से अपने संचालन में योगदान को पहचानेगी, रिकॉर्ड करेगी और पुरस्कृत करेगी। + +### अनुभाग 3: ब्लॉकचेन तटस्थता + +1. कार्डेनो ब्लॉकचेन पर लेन-देन को धीमा नहीं किया जायेगा या सेंसर नहीं लगाया जायेगा, और उन्हें उनके इच्छित कार्य के लिए शीघ्रता से संसाधित किया जायेगा। +2. कार्डेनो ब्लॉकचेन Ada धारक की सहमति के बिना Ada में लॉक नहीं होगी। +3. कार्डेनो ब्लॉकचेन के डिज़ाइन को किफ़ायती, सुलभ और पूर्वानुमानित लेन-देन की लागत वाले मॉडल की सुविधा प्रदान की जायेगी। +4. कार्डेनो ब्लॉकचेन पर एप्लिकेशन विकसित और उपयोग करने की इच्छा रखने वाले किसी भी व्यक्ति को ऐसा करने से अनुचित रूप से नहीं रोका जायेगा। कार्डेनो समुदाय को एप्लिकेशन विकसित करने और उपयोग करने में सहायता करने के लिए सुविधाओं को बढ़ावा दिया जायेगा। + +### अनुभाग 4: गार्डरेल + +1. कार्डेनो ब्लॉकचेन इस संविधान के परिशिष्ट I में निर्धारित गार्डरेल्स के अनुसार काम करेगी। गार्डरेल कार्डेनो ब्लॉकचेन की इस समय की सर्वश्रेष्ठ तकनीकी समझ को दर्शाते हैं और इस संविधान के अनुसार नई जानकारी के आधार पर बदलाव के लिए खुले रहेंगे। +2. गार्डरेल कार्डेनो ब्लॉकचेन को व्यवधान, सुरक्षा और प्रदर्शन संबंधी समस्याओं से बचाकर सुरक्षित और स्थायी तरीके से संचालित करने में सक्षम बनायेंगे। वे कार्डेनो ब्लॉकचेन मेननेट परिवेश पर लागू होंगे, और परीक्षण के परिवेशों या कार्डेनो ब्लॉकचेन सॉफ़्टवेयर का उपयोग करने वाले अन्य ब्लॉकचेन पर लागू होने के लिए नहीं है। +3. गार्डरेल में निर्धारित कार्डेनो ब्लॉकचेन के मापदंडों को एक साथ पढ़ा जायेगा और उनपर अलग से विचार नहीं किया जायेगा। मापदंडों के बीच ज्ञात पारस्परिक संवाद को गार्डरेल में नोट किया जाता है। +4. गार्डरेल कार्डेनो ब्लॉकचेन पर प्रशासन की क्रियाओं पर लागू होते हैं, जिसमें प्रोटोकॉल के मापदंडों के परिवर्तन और कार्डेनो ट्रेज़री से निकासी शामिल होते हैं, लेकिन यह इन्हीं तक सीमित नहीं होते हैं। गार्डरेल प्रोटोकॉल के मापदंडों और व्यवस्थाओं पर आवश्यक और आंतरिक दोनों सीमाओं को शामिल करते हैं, और अनुभव, माप और प्रशासन के उद्देश्यों से प्राप्त अनुसंशाओं पर आधारित होते हैं। +5. जहाँ तकनीकी आधार पर संभव हो, गार्डरेल को स्वचालित किया जायेगा और ऑन-चेन आलेख या बहीखाता के अंतर्निहित नियमों के माध्यम से लागू किया जाएगा। +6. गार्डरेल को प्रशासनिक कार्रवाईयों के अनुसार संशोधित किया जा सकता है जो लागू मतदान सीमा (यदि कोई हो) को पूरा करते हों। प्रायः, परिशिष्ट I में निर्धारित गार्डरेल में किए गए संशोधन को संविधान में ही संशोधन माना जाएगा और नए संविधान या गार्डरेल का आलेख प्रशासन की कार्रवाई के लिए आवश्यक मतदान सीमा के अधीन होगा। +7. गार्डरेलों को गार्डरेल के पहले पेज पर स्पष्ट संस्करण संख्या और प्रभावी तिथि के साथ प्रकाशित किया जायेगा। +8. गार्डरेलों और कार्डेनो ब्लॉकचेन पर लागू किए गए मापदंडों के बीच विसंगतियों होने पर, लागू किए गए मापदंड लागू होंगे। संवैधानिक समिति के सदस्य शासन की उचित कार्रवाई के सुझाव या प्रोत्साहन के माध्यम से ऐसी विसंगतियों को सुलझाने का प्रयास करेंगे। + +## अनुच्छेद IV कार्डेनो ब्लॉकचेन के मापदंड + +1. कार्डेनो ब्लॉकचेन के मापदंड इस संविधान के अनुसार आवश्यक शासन कार्रवाई की पुष्टि करके परिवर्तित किए जा सकते हैं। +2. ये मापदंड निम्नलिखित श्रेणियों में आते हैं: आर्थिक, नेटवर्क, प्रशासन, तकनीकी और सुरक्षा के मापदंड। मापदंडों में किसी भी प्रस्तावित परिवर्तन का मूल्यांकन इस संविधान की प्रस्तावना और सिद्धांतों के साथ-साथ नीचे उल्लिखित मुख्य उद्देश्यों के अनुसार किया जायेगा और यह प्रभाव के सतत आकलन और तकनीकी विश्लेषण पर आधारित होगा जो इसमें शामिल किसी भी भौतिक व्यापार को पारदर्शी बनाता है। + +### अनुभाग 1: आर्थिक मापदंड + +कार्डेनो ब्लॉकचेन के आर्थिक मापदंडों का मुख्य उद्देश्य कार्डेनो ब्लॉकचेन के लिए दीर्घकालिक आर्थिक स्थिरता को सक्षम करना, कार्डेनो ब्लॉकचेन को बनाए रखने के लिए SPO को पर्याप्त रूप से पुरस्कृत किया जाना यह सुनिश्चित करना, ada धारकों को उनके ada को रचनात्मक तरीकों से उपयोग करने के लिए पर्याप्त रूप से पुरस्कृत किया जाना यह सुनिश्चित करना और कार्डेनो इकोसिस्टम के विभिन्न प्रतिभागियों के लिए आर्थिक प्रोत्साहन को संतुलित करना है। + +### अनुभाग 2: नेटवर्क के मापदंड + +कार्डेनो ब्लॉकचेन के नेटवर्क के मापदंडों का मुख्य उद्देश्य कार्डेनो ब्लॉकचेन नेटवर्क की उपलब्ध क्षमता को वर्तमान या भविष्य की ट्रैफ़िक की माँगों से मेल खाना और कार्डेनो इकोसिस्टम के विभिन्न प्रतिभागियों के लिए ट्रैफ़िक की मांगों को संतुलित करना है। + +### अनुभाग 3: प्रशासनिक मापदंड + +कार्डेनो ब्लॉकचेन के प्रशासन के मापदंड का मुख्य उद्देश्य कार्डेनो ब्लॉकचेन की शासन प्रणाली की स्थिरता सुनिश्चित करना और इस संविधान के अनुसार शासन प्रणाली को बनाए रखना है। + +### अनुभाग 4: तकनीकी और सुरक्षा के मापदंड + +कार्डेनो ब्लॉकचेन के तकनीकी और सुरक्षा के मापदंडों का मुख्य उद्देश्य विकेंद्रीकरण, सिबिल और 51% आक्रमणों से सुरक्षा और सेवा संबंधी आक्रमणों से इनकार किए जाने पर कार्डेनो ब्लॉकचेन नेटवर्क की सुरक्षा सुनिश्चित करना है। तकनीकी और सुरक्षा संबंधी मापदंड अनुबंध के निष्पादन की बढ़िया सीमाओं और संबंधित लागत मॉडल में परिवर्तनों को भी नियंत्रित करते हैं। + +## अनुच्छेद V. कार्डेनो ब्लॉकचेन शासन + +### अनुभाग 1: प्रशासनिक मॉडल + +1. कार्डेनो ब्लॉकचेन सहभागी शासन के एक मॉडल का उपयोग करेगी जिसके अधीन ada धारक प्रशासनिक कार्र्वाईयों के लिए प्रस्ताव प्रस्तुत कर सकते हैं और इस अनुच्छेद V के जाँच और संतुलन के अनुसार ऐसे प्रस्तावों पर मतदान कर सकते हैं। +2. प्रशासनिक कार्र्वाईयों में भाग लेने, प्रस्तुत करने और मतदान करने की प्रक्रिया पारदर्शी होगी और हेर-फेर से सुरक्षित होगी। + +### अनुभाग 2: प्रशासनिक निकाय + +कार्डेनो ब्लॉकचेन का संचालन तीन प्रशासनिक निकायों के माध्यम से किया जायेगा: DRep, SPO और संवैधानिक समिति। ये प्रशासन निकाय कार्डानो ब्लॉकचेन के लिए जाँच और संतुलन प्रदान करेंगे। + +### अनुभाग 3: प्रशासनिक कार्रवाईयां + +1. Ada धारक किसी भी समय कार्डानो ब्लॉकचेन पर प्रशासनिक कार्यवाही का प्रस्ताव दे सकते हैं। इस समय यह संविधान निम्नलिखित प्रशासनिक कार्र्वाईयों यों का अनुमान लगाता है: + - अविश्वास प्रस्ताव, वर्तमान संवैधानिक समिति को अस्वीकार/ज़ब्त/त्याग करना जब तक कि प्रतिस्थापित समिति का चुनाव/नामांकन नहीं हो जाता; + - समिति और/या सीमा और/या अवधि को अपडेट करना, संवैधानिक समिति के सदस्यों या सीमा या अवधि को बदलने के लिए, या इसके किसी भी संयोजन को बदलने के लिए; + - नया संविधान या गार्डरेल आलेख, गार्डरेल सहित संविधान में संशोधन करने या गार्डरेल स्क्रिप्ट को अपडेट करने या हटाने के लिए; + - हार्ड-फोर्क आरंभ, कार्डानो ब्लॉकचेन सॉफ़्टवेयर के अग्रणी सुसंगत अपग्रेड को शुरु करना; + - प्रोटोकॉल के मापदंड में परिवर्तन, कार्डानो ब्लॉकचेन के अद्यतन योग्य मापदंडों में एक या अधिक परिवर्तन करना; + - ट्रेज़री से आहरण, कार्डानो ट्रेज़री से धन निकालना। + - सूचना कार्रवाईयां, किसी भी प्रोटोकॉल में परिवर्तन के लिए प्रतिबद्ध हुए बिना कार्डानो समुदाय की भावना को मापने की अनुमति देना + +2. प्रशासनिक कार्रवाईयों के प्रस्ताव एक मानकीकृत और सुपाठ्य प्रारूप में होंगे और प्रस्ताव के लिए पर्याप्त तर्क शामिल होंगे, जिसमें प्रासंगिक रूप से, कार्डानो ब्लॉकचेन में कोई भी सुझाया गया परिवर्तन शामिल होगा। जहाँ मूल रूप से इस संविधान की भाषा के अतिरिक्त किसी अन्य भाषा में लिखा गया हो, वहाँ प्रशासनिक कार्रवाई के प्रस्तावों के साथ प्रशासनिक कार्रवाई के प्रस्ताव का इस संविधान की भाषा (अंग्रेज़ी) में अनुवाद होना चाहिए। + +3. ट्रेज़री से आहरण की प्रशासनिक कार्रवाई में, विशेष रूप से, ऐसी जानकारी शामिल होगी जो निर्दिष्ट करती है कि विचाराधीन ट्रेज़री आहरण कार्डानो बजट में शामिल है या नहीं। + +4. पर्याप्त तर्क का अर्थ यह होगा कि प्रस्ताव यह दर्शाता है कि प्रस्तावित प्रशासनिक कार्रवाई किस तरह से इच्छित उद्देश्य को प्राप्त करती है। सहायक दस्तावेज़, स्पष्ट और समझने योग्य भाषा और संरचना, जिसमें शीर्षक, एक सार, प्रस्ताव का कारण और प्रासंगिक सहायक लिंक शामिल हैं, लेकिन यह इन्हीं तक सीमित नहीं हैं, वे पर्याप्त तर्क के संकेतक हैं। + +5. प्रशासनिक कार्रवाई के प्रस्तावों में एक URL और URL द्वारा इंगित विषय-सामग्री से प्राप्त एक हैश डाइजेस्ट शामिल होगा। किसी कार्रवाई को केवल तभी संवैधानिक माना जाएगा जब विषय-सामग्री को उसी हैश डाइजेस्ट का उत्पादन करने के लिए स्वतंत्र रूप से सत्यापित किया जा सके। + +6. हार्ड फोर्क आरंभ और प्रोटोकॉल पैरामीटर परिवर्तन के लिए प्रशासनिक कार्रवाई पर्याप्त तकनीकी समीक्षा और जाँच से गुजरेगी, जैसा कि गार्डरेल में निर्धारित किया गया है। ऐसी प्रशासनिक कार्रवाईयों से कार्डानो ब्लॉकचेन की सुरक्षा, कार्यक्षमता या प्रदर्शन को कोई खतरा नहीं होगा। + +7. प्रस्तावित प्रशासनिक कार्रवाईयों पर लागू शासन निकायों द्वारा मतदान किया जायेगा ताकि उन्हें अनुमोदित किया जा सके और बाद में लागू होने पर ऑन-चेन अधिनियमित किया जा सके। + +8. जानकारी की क्रियाओं पर DRep, SPO और संवैधानिक समिति द्वारा मतदान किया जायेगा। जानकारी की क्रियाओं का कार्डानो ब्लॉकचेन पर ऐसे मतदान के परिणाम को रिकॉर्ड करने के अतिरिक्त कोई प्रभाव नहीं होता है। प्रशासन की जानकारी की कार्रवाईयां कार्डानो समुदाय की भावना की अभिव्यक्ति हैं और उन्हें पारित होने के लिए "हाँ" परिणाम की आवश्यकता नहीं होती है। + +### अनुभाग 4: मतदान + +1. प्रस्तावित शासनिक कार्रवाईयों पर निर्णय संवैधानिक समिति, SPO और DRep द्वारा इस संविधान और गार्डरेल की आवश्यकताओं के अनुसार मतदान प्रक्रिया के माध्यम से किए जाएंगे। +2. DRep और SPO के पास उन्हें सौंपे गए लवलेस के अनुपात में मतदान का अधिकार होगा। एक लवलेस एक मत के बराबर होगा। +3. संवैधानिक समिति के प्रत्येक सदस्य के पास एक मत होगा। +4. वोट "हाँ", "नहीं" या "अलग रहना" के रूप में डाले जा सकते हैं। + +### अनुभाग 5: मतदान सीमा और गणपूर्ति + +1. प्रत्येक शासनिक निकाय के लिए मतदान सीमा जो इस संविधान के पहले जारी होने की तिथि पर प्रभावी है, कॉनवे उत्पत्ति फ़ाइल में निर्धारित की गई है और इसे प्रोटोकॉल पैरामीटर अपडेट की शासनिक कार्रवाई द्वारा बदला जा सकता है। ऐसी प्रोटोकॉल पैरामीटर अपडेट शासनिक कार्रवाई को इस संविधान में संशोधन नहीं माना जायेगा। + +2. मतदान की सीमा निम्नलिखित सीमाओं से परे नहीं होगी: + - संवैधानिक समिति: सभी पशासनिक कार्रवाईयों पर वोट 51% - 100% की सीमा के भीतर निर्धारित सीमा पर पारित होंगे। इस संविधान के पहले जारी होने की तिथि के अनुसार, यह सीमा संवैधानिक समिति के सदस्यों का 66.67% है। + - DRep और SPO: मतदान की सीमा, सीमा गार्डरेल के 3.6.4 पर "मतदान सीमा के लिए गार्डरेल" द्वारा निर्धारित की गई है। + +3. किसी विशेष शासनिक निकाय द्वारा शासनिक कार्रवाई पर लागू वर्तमान मतदान सीमा वर्तमान में ऑन-चेन पर लागू किए गए मापदंडों से परामर्श करके पाई जा सकती है। + +4. इस संविधान द्वारा आवश्यक होने पर संवैधानिक समिति के मतदान के अलावा, शासन कार्यों पर निम्नलिखित गणपूर्तियाँ लागू होंगी: + - मापदंडों में होने वाले परिवर्तनों को पारित होने के लिए एक सकारात्मक SPO वोट और एक सकारात्मक DRep मत की आवश्यकता होगी। + - हार्ड फोर्क आरंभों को पारित होने के लिए एक सकारात्मक SPO वोट और एक सकारात्मक DRep मत की आवश्यकता होगी। + - अविश्वास प्रस्ताव और अद्यतन समिति/सीमा को पारित होने के लिए एक सकारात्मक SPO वोट और एक सकारात्मक DRep वोट की आवश्यकता होगी। + - ट्रेज़री से आहरण को पारित करने के लिए एक सकारात्मक DRep वोट की आवश्यकता होगी। + - जानकारी की शासनिक कार्रवाईयों के लिए एक SPO वोट और एक DRep वोट की आवश्यकता होगी, हालाँकि कोई परिणाम की आवश्यकता नहीं होती है क्योंकि इन शासनिक कार्रवाईयों का उपयोग केवल कार्डेनो समुदाय की भावना को मापने और रिकॉर्ड करने के लिए किया जाता है। + - संवैधानिक संशोधनों को पारित होने के लिए एक सकारात्मक DRep वोट की आवश्यकता होगी। + +5. अन्य सभी शासनिक कार्रवाईयों को पारित होने के लिए एक सकारात्मक DRep मत की आवश्यकता होगी। + +## अनुच्छेद VI कार्डेनो समुदाय + +1. कार्डेनो इकोसिस्टम और कार्डेनो ब्लॉकचेन के प्रशासन में शामिल होने के लिए कार्डेनो समुदाय के सदस्यों के लिए किसी औपचारिक सदस्यता की आवश्यकता नहीं होगी। + +2. कार्डेनो समुदाय के सदस्यों से इस संविधान के प्रावधानों का सहयोग और समर्थन करने और विवादों को निष्पक्ष, रचनात्मक और पारदर्शी तरीके से हल करने की अपेक्षा की जाती है। + +3. कार्डेनो समुदाय प्रशासन की ऑफ-चेन प्रक्रियाओं के निर्माण, रखरखाव और मौजूदा प्रशासन का समर्थन करेगी, जैसा कि इस संविधान को प्रभावी बनाने के लिए आवश्यक हो सकता है और यह सुनिश्चित करने के लिए कि कार्डेनो ब्लॉकचेन के लिए शासनिक कार्रवाईयों पर बहस और उन्हें तैयार करने के लिए जागरूकता और अवसर हो। + +4. इस समुदाय को कार्डेनो ब्लॉकचेन के लिए अनुप्रयोगों के विकास, रखरखाव और निर्माण में सहयोग करने के लिए प्रोत्साहित किया जाता है। + +## अनुच्छेद VII संवैधानिक समिति + +### अनुभाग 1: संवैधानिक समिति के कार्य और भागीदारी + +1. संवैधानिक समिति को एक स्वतंत्र निकाय के रूप में स्थापित किया गया है ताकि यह सुनिश्चित किया जा सके कि सभी प्रस्तावित शासनिक कार्रवाईयां इस संविधान के प्रावधानों के अनुरूप हैं, इससे पहले कि उन पर मतदान किया जाये और उन्हें लागू किया जाएं। + +2. "अविश्वास प्रस्ताव" या "संवैधानिक समिति/सीमा को अद्यतन करें" के अतिरिक्त कोई भी शासनिक कार्रवाई ऑन-चेन लागू नहीं की जा सकती, जब तक कि संवैधानिक समिति ने पहले ऑन-चेन वोट के माध्यम से पुष्टि नहीं की हो कि ऐसा प्रस्ताव इस संविधान का उल्लंघन नहीं करता है। + +### अनुभाग 2: संवैधानिक समिति की संरचना + +1. संवैधानिक समिति के सदस्यों की संख्या कार्डेनो गार्डरेल्स द्वारा समय-समय पर निर्धारित की जाएगी, जो किसी भी मामले में एक विषम संख्या होगी जो 3 से कम नहीं होगी और 9 से अधिक नहीं होगी, ताकि संवैधानिक समिति के भीतर मतदान गतिरोध से बचा जा सके। इस संविधान के अनुपालन को सुनिश्चित करने के लिए उनके पास आवश्यक तकनीकी और/या शासन विशेषज्ञता होनी चाहिए। + +2. संवैधानिक समिति के सदस्य गार्डरेल के अनुरूप कार्यकाल पूरा करेंगे। + +3. संवैधानिक समिति के संचालन में निरंतरता सुनिश्चित करने के लिए, संवैधानिक समिति के सदस्यों के कार्यकाल अलग-अलग रखा जाएगा। + +### अनुभाग 3: संवैधानिक समिति के सदस्यों का चुनाव + +1. कार्डानो समुदाय गार्डरेल की आवश्यकताओं के अनुरूप संवैधानिक समिति के सदस्यों के चुनाव के लिए समय-समय पर एक प्रक्रिया स्थापित और प्रकाशित करेगी। + +2. यदि वर्तमान संवैधानिक समिति के कार्यकाल की समाप्ति से पहले कोई नई संवैधानिक समिति नहीं चुनी जाती है, या यदि संवैधानिक समिति कभी भी उपरोक्त धारा 3(1) की आवश्यकताओं को पूरा करने में विफल रहती है, तो वर्तमान संवैधानिक समिति किसी भी निवर्तमान संवैधानिक समिति के सदस्यों को बदलने या संवैधानिक समिति के सदस्यों की आवश्यक संख्या प्राप्त करने के लिए आवश्यक नए सदस्य(यों) को चुनने के लिए एक शासनिक कार्र्वाई प्रस्तुत करेगी। + +### अनुभाग 4: अविश्वास की स्थिति + +संवैधानिक समिति हर समय निम्नलिखित दो स्थितियों में से किसी एक में रहेगी: विश्वास की स्थिति या अविश्वास की स्थिति। अविश्वास की स्थिति में, किसी भी अन्य ऑन-चेन शासनिक कार्र्वाई के आगे बढ़ने से पहले, तत्कालीन स्थायी संवैधानिक समिति के सदस्यों को या तो बहाल किया जाना चाहिए या "अद्यतन समिति/सीमा" शासनिक कार्र्वाई का उपयोग करके प्रतिस्थापित किया जाना चाहिए। + +### अनुभाग 5: संवैधानिक समिति का मतदान और आचरण + +1. संवैधानिक समिति के सदस्य अपनी प्रक्रियाओं पर उचित जानकारी प्रकाशित करेंगे और लिए गए प्रत्येक निर्णय को प्रकाशित किया जायेगा। + +2. संवैधानिक समिति के प्रत्येक सदस्य के पास एक मत होगा। + +3. किसी शासनिक कार्र्वाई को अस्वीकार करते समय, संवैधानिक समिति का प्रत्येक सदस्य इस संविधान के लागू प्रावधानों के संदर्भों सहित अपने मत के लिए तर्क निर्धारित करेगा। + +4. संवैधानिक समिति के सदस्य कार्डानो समुदाय को उन प्रस्तावों में सुधार करने के लिए सिफारिशें कर सकते हैं जिन्हें उन्होंने अस्वीकार कर दिया है। + +5. संवैधानिक समिति: अपने लिए एक आचार संहिता स्थापित करेगी और प्रकाशित करेगी और ऐसी नीतियों और प्रक्रियाओं को अपनाएगी, जिसमें कोई भी नैतिक दिशानिर्देश शामिल होंगी, जिन्हें संवैधानिक समिति आवश्यक समझे। + +### अनुभाग 6: सामुदायिक सहयोग + +कार्डानो समुदाय संवैधानिक समिति के लिए आवश्यक और उचित उपकरणों के निर्माण, रखरखाव और मौजूदा प्रशासन का समर्थन करेगी ताकि वह अपने संवैधानिक कार्यों को पूरा कर सके। + +### अनुभाग 7: मुआवज़ा + +संवैधानिक समिति के सदस्यों को संवैधानिक समिति के सदस्यों के रूप में उनकी भूमिका के लिए मुआवज़ा दिया जा सकता है, बशर्ते कि इस तरह के मुआवज़े का कार्डानो बजट द्वारा पूर्वानुमान लगाया गया हो, सार्वजनिक रूप से प्रकट किया गया हो और भूमिका को पूरा करने में होने वाली वास्तविक और उचित ख़र्चों को शामिल करने के लिए राशि सीमित हो। + +## अनुच्छेद VIII नियुक्त प्रतिनिधि + +### अनुभाग 1: DRep के शासनिक कार्य + +1. Ada धारक स्वयं DRep के रूप में पंजीकरण करके या अन्य पंजीकृत DRep को अपने मतदान के अधिकार सौंपकर शासनिक कार्रवाईयों पर सीधे मतदान कर सकते हैं। + +2. DRep के पास उन्हें सौंपे गए लवलेस की संख्या के बराबर मतदान का अधिकार होगा। + +3. DRep को DRep के तौर पर अपनी गतिविधियों को संचालित करने के लिए नैतिक दिशा-निर्देशों सहित आचार संहिता को अपनाने, प्रकाशित करने और बनाए रखने के लिए प्रोत्साहित किया जाता है। + +### अनुभाग 2: DRep का पंजीकरण + +1. किसी भी Ada धारक को DRep के रूप में पंजीकरण करने की अनुमति होगी। DRep एक या अधिक Ada धारकों के हित में कार्य कर सकता है। + +2. किसी भी Ada धारक को अपने मतदान की हिस्सेदारी को एक या अधिक पंजीकृत DReps को सौंपने की अनुमति होगी, जिसमें वे स्वयं भी शामिल होंगे। + +3. Ada धारकों को किसी भी समय अपने मतदान की हिस्सेदारी की नियुक्ति को परिवर्तित करने की अनुमति होगी। + +### अनुभाग 3: DRep का चयन + +कार्डानो समुदाय से अपेक्षा की जाती है कि वह Ada धारकों को उनके मतदान प्रतिनिधिमंडल के लिए DReps चुनने में सक्षम बनाने के लिए उपकरणों के निर्माण, रखरखाव और मौजूदा प्रशासन के साथ सहयोग करे। + +### अनुभाग 4: DRep का मुआवज़ा + +DRep को उनके प्रयासों के लिए मुआवज़ा दिया जा सकता है। उन्हें DRep के रूप में अपनी गतिविधियों के संबंध में प्राप्त किसी भी मुआवज़े की सार्वजनिक रूप से जानकारी देनी होगी। + +## अनुच्छेद IX हिस्सेदारी पूल के संचालक (STAKE POOL OPERATORS) + +### अनुभाग 1: SPO के शासनिक कार्य + +1. SPO निर्धारित शासनिक कार्रवाईयों पर एक अतिरिक्त जाँच तत्व के रूप में कार्य करेंगे, जहाँ वे गार्डरेल में निर्धारित DRep से अलग से मतदान करेंगे। + +2. SPO सार्वजनिक रूप से खुलासा करेंगे यदि वे शासन की एक ही कार्रवाई पर एक साथ DRep के रूप में मतदान कर रहे हैं। + +### अनुभाग 2: हार्ड फोर्क आरंभ + +1. कार्डानो ब्लॉकचेन के नोड्स के संचालक के रूप में, SPO इस संविधान और गार्डरेल्स के अनुसार हार्ड फोर्क आरंभ प्रक्रिया पर मतदान करेंगे। + +2. SPO हार्ड फोर्क आरंभ पर अपना मतदान करते समय कार्डानो ब्लॉकचेन की तत्परता पर विचार करेंगे। + +## अनुच्छेद X. कुल परिवर्तन सीमा, कार्डानो बजट और ट्रेज़री से आहरण + +### अनुभाग 1: कुल परिवर्तन की सीमा राशि + +1. किसी भी कार्डानो समुदाय के सदस्य द्वारा बजट की प्रत्येक अवधि के लिए एक कुल परिवर्तन सीमा राशि प्रस्तावित की जा सकती है, जो पूर्ववर्ती शासनिक कार्रवाई के बाद पूर्ववर्ती कुल परिवर्तन सीमा राशि को स्थापित करती है। + +2. कुल परिवर्तन सीमा राशियों को एक जानकारी की शासनिक कार्रवाई के रूप में प्रस्तावित किया जायेगा और लागू सीमाओं के अनुसार मतदान के अधीन होगा। DRep प्रत्येक कुल परिवर्तन सीमा अवधि के लिए एक कुल परिवर्तन सीमा राशि को स्वीकृति देगा। + +3. यदि किसी कुल परिवर्तन सीमा अवधि के लिए कोई नई कुल परिवर्तन सीमा राशि स्वीकृत नहीं की जाती है, तो पिछली कुल परिवर्तन सीमा राशि लागू होती रहेगी। + +### अनुभाग 2: कार्डानो का बजट + +1. कार्डानो के बजट में प्रत्येक कुल परिवर्तन सीमा अवधि के लिए कार्डानो ब्लॉकचेन के मौजूदा संचालन, रखरखाव और विकास के लिए यथोचित रूप से आवश्यक संसाधन शामिल होते हैं। + +2. कार्डानो के बजट में प्रशासन, प्रबंधन, अनुबंध, तृतीय पक्ष के ऑडिट और ऐसे पदों के आश्वासन के साथ-साथ संवैधानिक समिति के सदस्यों के लिए मुआवज़े सहित कार्डानो की शासनिक व्यवस्था के लिए यथोचित रूप से आवश्यक संसाधन भी शामिल हो सकते हैं। + +3. कार्डानो समुदाय प्रत्येक कुल परिवर्तन सीमा अवधि के लिए एक कार्डानो बजट प्रस्तावित करेगी, जो जानकारी की एक शासनिक कार्रवाई का रूप लेगा और लागू सीमाओं के अनुसार मतदान के अधीन होगा। + +4. कार्डानो समुदाय का कोई भी सदस्य, जिसमें कार्डानो समुदाय के सदस्य द्वारा गठित कोई भी सहयोगी निकाय शामिल है, कार्डानो के बजट का प्रस्ताव कर सकता है। + +5. कार्डानो बजट की कुल राशि संबंधित कुल परिवर्तन सीमा अवधि के लिए लागू कुल परिवर्तन सीमा की राशि से अधिक नहीं होगी। + +### अनुभाग 3: ट्रेज़री से आहरण + +1. इस संविधान और गार्डरेल में निर्धारित आवश्यकताओं के अधीन, कोई भी व्यक्ति कार्डानो ट्रेज़री आहरण की शासनिक कार्रवाई का प्रस्ताव कर सकता है। + +2. जब तक कार्डानो के बजट को मंजूरी नहीं मिल जाती और कुल परिवर्तन सीमा लागू नहीं हो जाती, तब तक कार्डानो ट्रेज़री से आहरण की शासनिक कार्रवाई की अनुमति नहीं दी जायेगी। + +3. कार्डानो के बजट के लिए निकाली गई कोई भी ada DRep और SPO को नहीं सौंपी जाएगी या कार्डानो ब्लॉकचेन शासन को प्रभावित करने के लिए अन्यथा उपयोग नहीं की जायेगी। यह कार्डानो ट्रेज़री की अन्य आहरण पर लागू नहीं होता है। + +4. कार्डानो ट्रेज़री से आहरण की शासनिक कार्र्वाई के अनुसार निकाली गई कोई भी ada केवल शासनिक कार्र्वाई में घोषित कार्य के लिए उपयोग की जायेगी। + +5. कार्डानो ट्रेज़री की निकासी के माध्यम से निकाली गई किसी भी ada को वित्तीय उद्योग के सर्वश्रेष्ठ तौर-तरीकों के अनुसार प्रशासित और प्रबंधित किया जायेगा। diff --git a/AlternateLanguageDrafts/Japanese.md b/AlternateLanguageDrafts/Japanese.md new file mode 100644 index 0000000..d99c96e --- /dev/null +++ b/AlternateLanguageDrafts/Japanese.md @@ -0,0 +1,376 @@ +# CARDANOブロックチェーン憲法の提案 + +## 前文 + +1. [前文](#前文) +2. [第 I 条 用語の定義](#第-i-条-用語の定義) +3. [第 II 条 適用範囲](#第-ii-条-適用範囲) +4. [第 III 条 理念とガードレール](#第-iii-条-理念とガードレール) + - [第 1 節: 目的と範囲](#第-1-節-目的と範囲) + - [第 2 節: Cardanoの理念](#第-2-節-cardanoの理念) + - [第 3 節: ブロックチェーンの中立性](#第-3-節-ブロックチェーンの中立性) + - [第 4 節: ガードレール](#第-4-節-ガードレール) +5. [第 IV 条 Cardanoブロックチェーンのパラメータ](#第-iv-条-cardanoブロックチェーンのパラメータ) + - [第 1 節: 経済的パラメータ](#第-1-節-経済的パラメータ) + - [第 2 節: ネットワークパラメータ](#第-2-節-ネットワークパラメータ) + - [第 3 節: ガバナンスパラメータ](#第-3-節-ガバナンスパラメータ) + - [第 4 節: 技術およびセキュリティパラメータ](#第-4-節-技術およびセキュリティパラメータ) +6. [第 V 条 Cardanoブロックチェーンのガバナンス](#第-v-条-cardanoブロックチェーンのガバナンス) + - [第 1 節: ガバナンスモデル](#第-1-節-ガバナンスモデル) + - [第 2 節: ガバナンス機関](#第-2-節-ガバナンス機関) + - [第 3 節: ガバナンスアクション](#第-3-節-ガバナンスアクション) + - [第 4 節: 投票](#第-4-節-投票) + - [第 5 節: 投票しきい値とQuorum](#第-5-節-投票しきい値とquorum) +7. [第 VI 条 Cardanoコミュニティ](#第-vi-条-cardanoコミュニティ) +8. [第 VII 条 憲法委員会](#第-vii-条-憲法委員会) + - [第 1 節: 憲法委員会の機能と参加](#第-1-節-憲法委員会の機能と参加) + - [第 2 節: 憲法委員会の構成](#第-2-節-憲法委員会の構成) + - [第 3 節: 憲法委員会の委員選出](#第-3-節-憲法委員会の委員選出) + - [第 4 節: 不信任状態](#第-4-節-不信任状態) + - [第 5 節: 憲法委員会の投票と行動](#第-5-節-憲法委員会の投票と行動) + - [第 6 節: コミュニティの支援](#第-6-節-コミュニティの支援) + - [第 7 節: 報酬](#第-7-節-報酬) +9. [第 VIII 条 委任代表者](#第-viii-条-委任代表者) + - [第 1 節: DRep ガバナンス機能](#第-1-節-drep-ガバナンス機能) + - [第 2 節: DRep の登録](#第-2-節-drep-の登録) + - [第 3 節: DRep の選択](#第-3-節-drep-の選択) + - [第 4 節: DRep の報酬](#第-4-節-drep-の報酬) +10. [第 IX 条 ステークプール運営者](#第-ix-条-ステークプール運営者) + - [第 1 節: SPO ガバナンス機能](#第-1-節-spo-ガバナンス機能) + - [第 2 節: ハードフォークの開始](#第-2-節-ハードフォークの開始) +11. [第 X 条 純変動制限額、Cardano予算、トレジャリー引き出し](#第-x-条-純変動制限額cardano予算トレジャリー引き出し) + - [第 1 節: 純変動制限額](#第-1-節-純変動制限額) + - [第 2 節: Cardano予算](#第-2-節-cardano予算) + - [第 3 節: トレジャリー引き出し](#第-3-節-トレジャリー引き出し) + +## 前文 + +ここに、3 つの先駆的な事業体 Input-Output Hong Kong、Emurgo、Cardano Foundation が、Cardanoコミュニティと協力してCardanoブロックチェーンの台頭を促し、個人をエンパワーメントし、コラボレーションとイノベーションを促進する分散型デジタルインフラの基礎を築いてきたことを認識する。これらの事業体の尽力により、活気に満ちた多様な個人および組織の環境が形成され、誰もがCardanoエコシステムの成長と成功に貢献することを選択できる。 + +Cardanoブロックチェーンがブロックチェーン技術、スマートコントラクト、コミュニティガバナンスの分散型エコシステムの中に存在し、世界的な経済、政治、社会システムの改善に取り組んでいることを認識する。Cardanoブロックチェーンは、個人やコミュニティがアイデンティティ、価値、ガバナンスを管理するための基盤となるインフラを提供し、分散型アプリケーション、ビジネス、ネットワークの台頭を促進する。 + +Cardanoエコシステムが大幅に拡大し、分散型かつ許可不要で運営され、Cardanoブロックチェーンの回復力と自律性がさらに強化されていることを認める。 + +Cardanoエコシステムが成長を続けるにつれて、そのガバナンスモデルも同様に適応し、自治の基盤としての分散化、コミュニティ参加、説明責任、包括性、コラボレーションの原則を反映し、人間の相互作用とコラボレーションの新たなアプローチを進化させる必要があることを考慮する。 + +合理的に可能かつ有益な限り、ブロックチェーン技術を活用してオンチェーンガバナンスを確立する、より強固で適応可能なガバナンスフレームワークの必要性を認識し、Cardanoコミュニティは、許容されるガバナンス行為のための一連のセーフガードを提供する技術的ガードレールを含む、本Cardanoをここに制定する。Cardanoは、誰もがCardanoエコシステムの発展に貢献できる基盤として、Cardanoブロックチェーンの運営とガバナンスの原則を定める。 + +Cardanoコミュニティは、透明性、オープン性、説明責任の原則に従い、Cardanoエコシステムの最善の利益のために決定が行われるよう、信頼と協力の文化を追求し、CardanoブロックチェーンとCardanoエコシステムの継続的な改善、成長、成功に向けて協力して取り組むことを目指す。 + +Cardanoブロックチェーンのガバナンスに貢献する機会を SPO およびすべての ADA 保有者に提供し、多様な視点を育成することの重要性を認識する。 + +いかなる組織や強力団体からも独立してCardanoブロックチェーンのガバナンスに貢献する ADA 保有者の選択の自由を認める。 + +Cardanoブロックチェーンの性質が最終的にソフトウェアコードによって実装される構成物であること、そのゆえに、本憲法を支持し施行する上で、その開発者とエンジニアが果たす重要な役割および彼らへの期待を認識する。 + +本憲法を支持する上で憲法委員会が果たす重要な役割と、ADA 保有者代表としての DRep の重要性を認識する。 + +CardanoコミュニティがCardanoトレジャリーで利用可能なリソースを、持続可能で説明責任のある方法で効果的に活用するためのフレームワークの必要性を認識する。 + +Cardanoエコシステムが直面する課題に取り組むために、Cardanoコミュニティ間で新たな協力団体を形成する権利を認識する。 + +## 第 I 条 用語の定義 + +1. **アクティブなブロック生産ステーク** + SPO との関係において、ブロック生産の目的で SPO にアクティブに委任されている Lovelace の数を意味する。 + +2. **有効投票ステーク** + 有効投票ステークとは、ガードレールに規定された必要な投票活動および投票登録に基づいて有効とみなされ、投票を決定する目的でカウントされる Lovelace の総数を指す。 + +3. **ADA** + Cardanoブロックチェーンに固有の暗号通貨を指す。 + +4. **ADA 保有者** + ADA トークンの秘密鍵を直接的または間接的に管理する者を指す。 + +5. **純変動制限期間** + 純変動制限額が適用される 73 エポック (約 1 暦年) で構成される期間を指す。 + +6. **Cardanoブロックチェーン** + 「Cardano」という名称で運営されている、パブリック、プルーフオブステーク、ピアツーピア、分散型台帳システム。 + +7. **Cardanoコミュニティ** + Cardanoコミュニティとは、すべての ADA 保有者を指す。 + +8. **Cardanoエコシステム** + Cardanoエコシステムとは、SPO、DRep、Cardanoコミュニティ、CC を含むがこれらに限定されない、Cardanoブロックチェーン上で活動を行うすべての参加者を指す。 + +9. **Cardanoトレジャリー** + Cardanoトレジャリーは、取引手数料や通貨膨張から受け取った ADA を保有・放出する、分散型のオンチェーン ADA 管理システムである。 + +10. **憲法委員会** + 憲法の原則が守られ、施行されることを保証する責任を負う管理機関を意味する。 + +11. **委任者** + ステークプール (ブロック生産用)、および/または DRep (ガバナンス用) にステークを委任した ADA 保有者。 + +12. **DRep または委任代表者** + ガバナンスアクションに投票する、正式に登録された委任代表者。 + +13. **ガバナンスアクション** + Cardanoブロックチェーンに関して、その情報を記録する、それ関連するアクションを起こす、そのパラメータを変更するなどのアクションを意味する。これはCardanoブロックチェーン上の適格な投票機関によって投票のために提出される。 + +14. **ガバナンスアクション提案** + Cardanoコミュニティまたは憲法委員会の委員が、Cardanoコミュニティでの議論または検討のために提出する、将来のガバナンスアクションの提案を意味する。 + +15. **ガバナンス機関** + 憲法に規定されているガバナンスアクションに対して投票する権限を持つ組織またはグループを意味し、現在は DRep、憲法委員会、および SPO で構成されている。 + +16. **ガードレール** + ガードレールとは、Cardanoブロックチェーンの機能性、セキュリティ、パフォーマンスを維持するために必要な条件やパラメータを指す。その一部はCardanoブロックチェーンに直接実装されているが、すべてが実装されているわけではない。 + +17. **ガードレールスクリプト** + 憲法とともにチェーン上に記録され、ガバナンスアクションがチェーン上に提出されたときに自動化可能なガードレールを適用する Plutus スクリプト。 + +18. **Lovelace** + ADA の単位を意味し、1 ADA あたり 100 万 Lovelace となる。 + +19. **低コスト攻撃** + 実行するのに必要な ADA、労力、その他のリソースが少なすぎると判断される攻撃。これらの指標の許容値を決定する必要がある。 + +20. **メインネット環境** + ライブで稼動しているCardanoブロックチェーンプロトコルの基本レイヤーを意味する。 + +21. **純変動制限額** + Cardanoトレジャリーが一定期間内に変動してはならない ADA での制限を意味する。 + +22. **オンチェーンとオフチェーン** + 「オンチェーン」とは、Cardanoブロックチェーンに反映されるアクションを指す。「オフチェーン」とは、Cardanoブロックチェーンには反映されないが、本憲法によって管理されるアクションを指す。 + +23. **パラメータ** + Cardanoブロックチェーンの実装に関する設定および制限を意味し、憲法で規定されている。 + +24. **プロトコル** + Cardanoブロックチェーンの運用を管理するアルゴリズム、ルール、手続きを意味する。 + +25. **SDR** + 「特別引出権」を意味し、国際通貨基金が創設した世界通貨バスケットの価値に基づく国際準備資産を指す。「フィアット (法定通貨)」への言及があった場合、それは SDR を指すものとする。 + +26. **SPO** + Cardanoブロックを生成するノードを運営するステークプール運営者。 + +27. **投票** + 提案されたガバナンスアクションに関して、Cardanoブロックチェーン上で表明された決定を指す。 + +## 第 II 条 適用範囲 + +1. 本憲法は、Cardanoブロックチェーンと、およびCardanoエコシステム内で相互にやり取りする限りにおいて、すべてのCardanoコミュニティの委員、DRep、SPO、および憲法委員会の委員に適用される。 +2. 前文は本憲法の根拠を示すものであるが、提案されたガバナンスアクションとの合致度を評価する目的においては、拘束力を持たないものとみなされる。 +3. 本憲法は、下記第 III 条に定める理念を実現するように解釈されるものとする。 + +## 第 III 条 理念とガードレール + +### 第 1 節: 目的と範囲 + +本条の理念は、Cardano委員会、SPO、DRep、および ADA 保有者を含む、Cardanoエコシステムのすべての関係者の指針となることを意図している。すべてのガバナンスアクションは、これらの理念に従って評価されるものとする。 + +### 第 2 節: Cardanoの理念 + +1. Cardanoブロックチェーンはその公開性とトラストレス性を維持する。 +2. Cardanoブロックチェーンのガバナンスプロセスは、アクセス可能で、透明性があり、適応性を備えていなければならない。 +3. Cardanoブロックチェーンの開発および運用において、単一障害点または依存性の回避を含むがこれに限定されない、セキュリティ、信頼性、および回復力を優先するものとする。 +4. Cardanoエコシステムは財務の安定に努めるものとする。 +5. ADA の総供給量は 45,000,000,000 ADA (45,000,000,000,000,000 Lovelace) を超えてはならない。 +6. 価値と情報の保護を保証するため、Cardanoブロックチェーンはポスト量子セキュリティ、分散型ストレージ、堅牢な鍵管理アプローチを目指す。 +7. Cardanoエコシステムは、アクセシビリティ、経済的持続可能性、セキュリティ、パフォーマンスとの過度なトレードオフなしに、スループット、シャーディング、決済、ダイナミックプライシングを考慮したスケーラブルなオン/オフチェーンソリューションを含む、Cardanoブロックチェーンの分散化に努める。 +8. Cardanoブロックチェーンは、公平性、中立性、持続可能性、堅牢なガバナンス、分散型アイデンティティの推進、Cardanoコミュニティによる協力と参加といった特徴に反映されるように、長期的な持続可能性と実行可能性を追求する。 +9. Cardanoブロックチェーンは、セキュリティ、レジリエンス、アクセシビリティを促進し、集中化のリスクを軽減するため、オープンソースの共同開発手法で開発され、寛容なオープンソースライセンスの下で常に利用できるものとする。 +10. ガバナンスアクションを検討する際、Cardanoエコシステムの参加者すべては公平に扱われ、その利益が考慮されるものとする。 +11. Cardanoブロックチェーンは、相互運用性と他のブロックチェーンへのアクセスを促進すべきである。 +12. Cardanoブロックチェーンは、オンチェーンリソースを不必要に消費してはならない。 +13. Cardanoブロックチェーンは、ハードウェアリソースの効率的な設計と利用を促進する。 +14. Cardanoブロックチェーンは、公正かつ適切なトークノミクスを通じて、その運営への貢献を認識し、記録し、報酬を与えるものとする。 + +### 第 3 節: ブロックチェーンの中立性 + +1. Cardanoブロックチェーン上の取引は、速度を落としたり、検閲したりしてはならず、意図された目的のために迅速に処理されるべきである。 +2. Cardanoブロックチェーンは、ADA 保有者の同意なしに ADA をロックしない。 +3. Cardanoブロックチェーンの設計は、費用対効果が高く、アクセスしやすく、予測可能な取引コストモデルを促進するものであるべきである。 +4. Cardanoブロックチェーン上でアプリケーションを開発およびデプロイすることを望む者については、その実行を不当に妨げるべきではない。Cardanoコミュニティは、アプリケーションの開発とデプロイを支援する機能を促進すべきである。 + +### 第 4 節: ガードレール + +1. Cardanoブロックチェーンは、本憲法の付録 I に定めるガードレールに従って運営されるものとする。ガードレールは、Cardanoブロックチェーンに関する現時点での最善の技術的理解を反映したものであり、本憲法に従い、新たな情報に基づいて変更される可能性がある。 +2. ガードレールにより、Cardanoブロックチェーンは、中断、セキュリティ、パフォーマンスの問題を回避でき、安全かつ持続可能な方法で運用することが可能になる。これらはCardanoブロックチェーンのメインネット環境に適用されるものであり、テスト環境やCardanoブロックチェーンのソフトウェアを使用する他のブロックチェーンに適用することを意図したものではない。 +3. ガードレールに記載されたCardanoブロックチェーンのパラメータは合わせて読み取られるものであり、単独で考慮されるものではない。パラメータ間の既知の相互作用は、ガードレールに記されている。 +4. ガードレールは、Cardanoブロックチェーン上のガバナンスアクションに適用される。これには、プロトコルパラメータの変更やCardanoトレジャリーの引き出しが含まれるが、これらに限定されない。ガードレールは、プロトコルパラメータや設定に関する必須の制限と固有の制限の両方をカバーし、経験、測定、ガバナンスの目的から導き出された推奨事項に基づいている。 +5. 技術的に可能な場合、ガードレールは、オンチェーンスクリプトまたは組み込みの元帳ルールを通じて自動化され、強制されるものとする。 +6. ガードレールは、該当する投票しきい値 (存在する場合) を満たすガバナンスアクションに従って修正することができる。一般に、付録 I に記載されているガードレールの改正は、憲法自体の改正とみなされ、新たな憲法またはガードレールスクリプトガバナンスアクションに必要な投票しきい値に従うものとする。 +7. ガードレールは、その最初のページに明確なバージョン番号と発効日を明記して発行されるものとする。 +8. ガードレールとCardanoブロックチェーンに実装されたパラメータとの間に矛盾が生じた場合は、実装されたパラメータが優先される。憲法委員会の委員は、適切なガバナンスアクションの提案または奨励を通じて、かかる矛盾を調整するよう努める。 + +## 第 IV 条 Cardanoブロックチェーンのパラメータ + +1. Cardanoブロックチェーンのパラメータは、本憲法に従って必要なガバナンスアクションを批准することにより変更できる。 +2. パラメータは、経済、ネットワーク、ガバナンス、技術、セキュリティの各パラメータカテゴリに分類される。パラメータの変更提案は、本憲法の前文と理念、および以下に概説する主要目標に従って評価され、重大なトレードオフを明らかにするための真摯な影響評価と技術的分析に基づくものとする。 + +### 第 1 節: 経済的パラメータ + +Cardanoブロックチェーンの経済的パラメータの主な目標は、Cardanoブロックチェーンの長期的な経済的持続可能性を実現すること、SPO がCardanoブロックチェーンの維持に対して十分な報酬を得られるようにすること、ADA 保有者が ADAを建設的な方法で使用することに対して十分な報酬を得られるようにすること、およびさまざまなCardanoエコシステム参加者に対する経済的インセンティブのバランスをとることである。 + +### 第 2 節: ネットワークパラメータ + +Cardanoブロックチェーンのネットワークパラメータの主な目標は、利用可能なCardanoブロックチェーンのネットワーク容量を現在または将来のトラフィック需要に一致させ、さまざまなCardanoエコシステム参加者のトラフィック需要のバランスを取ることである。 + +### 第 3 節: ガバナンスパラメータ + +Cardanoブロックチェーンのガバナンスパラメータの主な目標は、Cardanoブロックチェーンのガバナンスシステムの安定性を確保し、本憲法に基づくガバナンスシステムを維持することである。 + +### 第 4 節: 技術およびセキュリティパラメータ + +Cardanoブロックチェーンの技術およびセキュリティパラメータの主な目標は、分散化、シビル攻撃および 51% 攻撃からの保護、サービス拒否攻撃からの保護という点で、Cardanoブロックチェーンネットワークのセキュリティを確保することである。技術およびセキュリティパラメータは、スマートコントラクトの実行制限と関連するコストモデルの変更も管理する。 + +## 第 V 条 Cardanoブロックチェーンのガバナンス + +### 第 1 節: ガバナンスモデル + +1. Cardanoブロックチェーンは、本条のチェックアンドバランスに従い、ADA 保有者がガバナンスアクションの提案を行い、かかる提案について投票を行うことができる参加型ガバナンスのモデルを使用する。 +2. ガバナンスアクションへの参加、提出、投票のプロセスは透明性が保たれ、操作から保護されるものとする。 + +### 第 2 節: ガバナンス機関 + +Cardanoブロックチェーンのガバナンスは、3 つのガバナンス機関(DRep、SPO、憲法委員会) を通じて行われる。これらのガバナンス機関は、Cardanoブロックチェーンのチェックやバランスを行う。 + +### 第 3 節: ガバナンスアクション + +1. ADA 保有者は、いつでもCardanoブロックチェーン上でガバナンスアクションを提案できる。本憲法では現在、以下のガバナンスアクションを想定している: + - 後任が選出/指名されるまで現在の憲法委員会を否決/資格剥奪/解任する不信任動議。 + - 委員会および/または基準および/または任期を更新し、憲法委員会の委員または委員の基準もしくは任期、あるいはそれらの組み合わせを変更する。 + - 新たな憲法またはガードレールスクリプト。ガードレールを含む憲法を修正するか、ガードレールスクリプトを更新または削除する。 + - ハードフォークの開始。Cardanoブロックチェーンソフトウェアの下位互換性のないアップグレードをトリガーする。 + - プロトコルパラメータの変更。Cardanoブロックチェーンの更新可能なパラメータに 1 つ以上の変更をトリガーする。 + - トレジャリー引き出し。Cardanoトレジャリーから資金を引き出す。 + - 情報アクション。プロトコルの変更を約束することなく、Cardanoコミュニティのセンチメントを測定する。 +2. ガバナンスアクション提案は、標準化された読みやすい形式とし、必要に応じ、Cardanoブロックチェーンへの変更案を含め、提案の十分な理論的根拠を含むものとする。ガバナンスアクション提案が本憲法の言語以外の言語で最初に書かれている場合、提案には本憲法の言語 (英語) への翻訳を添付する。 +3. トレジャリー引き出しのガバナンスアクションには、特に、予定されているトレジャリー引き出しがCardano予算に含まれているか否かを明記する情報を含むものとする。 +4. 十分な理論的根拠とは、提案されたガバナンスアクションが意図された目的をどのように達成するかを提案が実証することを意味している。タイトル、抄録、提案理由、関連する裏付けリンク (ただしこれらに限定されない) を含む裏付け文書、明確で理解しやすい言葉と構成は、十分な理論的根拠を示す指標となる。 +5. ガバナンスアクション提案には、URL と、その URL が指し示すコンテンツに由来するハッシュダイジェストを含めることとする。アクションは、コンテンツが同じハッシュダイジェストを生成することが独立して検証できる場合にのみ、合憲とみなされる。 +6. ハードフォーク開始とプロトコルパラメータ変更に関するガバナンスアクションは、ガードレールに規定されているように、十分な技術的レビューと精査を受けることとする。かかるガバナンスアクションは、Cardanoブロックチェーンのセキュリティ、機能、または性能を危険にさらさないものとする。 +7. 提案されたガバナンスアクションは、該当するガバナンス機関によって投票され、批准され、後に該当するオンチェーンで施行されるものとする。 +8. 情報アクションは、DRep、SPO、および憲法委員会の投票によって決定される。情報アクションには、かかる投票の結果をCardanoブロックチェーンに記録する以外の効果はない。情報ガバナンスアクションは、Cardanoコミュニティのセンチメントを表すものであり、可決するのに「はい」という結果を必要としない。 + +### 第 4 節: 投票 + +1. 提案されたガバナンスアクションに関する決定は、本憲法およびガードレールの要件に従い、投票プロセスを通じて憲法委員会、SPO、および DRep によって行われる。 +2. DRep および SPO は、委任された Lovelace に比例した投票権を有するものとする。1 Lovelace は 1 票に相当する。 +3. 憲法委員会の委員は、それぞれ 1 票を有する。 +4. 投票は「賛成」、「反対」「棄権」のいずれかで行うことができる。 + +### 第 5 節: 投票しきい値とQuorum + +1. 本憲法の初版発行時点で有効な各ガバナンス機関の投票しきい値は、Conway ジェネシスファイルで設定されており、プロトコルパラメータ更新ガバナンスアクションによって変更できる。かかるプロトコルパラメータ更新ガバナンスアクションは、本憲法の改正を構成するものとはならない。 +2. 投票しきい値は、以下の範囲を超えないものとする: + - 憲法委員会: すべてのガバナンス アクションに対する投票は、51% ～ 100% の範囲内で設定されたしきい値で可決されるものとする。本憲法の初版発行日現在、このしきい値は憲法委員会委員の 66.67% である。 + - DRep と SPO: ガードレールの 3.6.4「投票しきい値のガードレール」で規定されている投票しきい値の範囲。 +3. 特定のガバナンス機関によるガバナンスアクションに適用される現在の投票しきい値は、現在オンチェーンで実装されているパラメータを参照することで確認できる。 +4. 本憲法で必要とされる憲法委員会の投票に加え、ガバナンスアクションには以下のquorumが適用されるものとする: + - パラメータの変更を可決するには、SPO の賛成投票と DRep の賛成投票を必要とする。 + - ハードフォークを開始するには、SPO の賛成投票と DRep の賛成投票を必要とする。 + - 不信任決議および委員会/しきい値の更新決議を可決するには、SPO の賛成投票と DRep の賛成投票を必要とする。 + - トレジャリー引き出しが可決されるには、DRep の賛成投票を必要とする。 + - 情報ガバナンスアクションには SPO の投票と DRep の投票が必要であるが、これらのガバナンスアクションはCardanoコミュニティのセンチメントを測定および記録するためにのみ使用されるため、結果は不要である。 + - 憲法改正の可決には、DRep の賛成投票が必要である。 +5. その他すべてのガバナンスアクションの可決には、DRep の賛成投票が必要である。 + +## 第 VI 条 Cardanoコミュニティ + +1. CardanoコミュニティのメンバーがCardanoエコシステムおよびCardanoブロックチェーンのガバナンスに関与する上で、正式な会員資格は必要ないものとする。 +2. Cardanoコミュニティのメンバーは、本憲法の規定を支持し、遵守し、公正かつ建設的で透明性のある方法で紛争を解決することが期待されている。 +3. Cardanoコミュニティは、本憲法を施行し、Cardanoブロックチェーンのガバナンスアクションについての認識を高め、議論し、形成する機会を確保するために必要な、オフチェーンガバナンスプロセスの作成、維持、および継続的な管理をサポートすることとする。 +4. コミュニティは、Cardanoブロックチェーン向けのアプリケーションの開発、保守、構築に協力することが奨励される。 + +## 第 VII 条 憲法委員会 + +### 第 1 節: 憲法委員会の機能と参加 + +1. 憲法委員会は独立した機関として設置され、提案されたすべてのガバナンスアクションが、投票および実施される前に、本憲法の規定に準拠していることを確認する。 +2. 「不信任決動議」または「憲法委員会/しきい値の更新」以外のいかなるガバナンスアクションも、憲法委員会がオンチェーン投票を通じ、かかる提案が本憲法に違反しないことを最初に確認しない限り、オンチェーンで実施することはできない。 + +### 第 2 節: 憲法委員会の構成 + +1. 憲法委員会の委員は、Cardanoガードレールが随時指定する人数で構成されるものとし、いずれの場合も、憲法委員会内での投票の行き詰まりを避けるため、3 人以上 9 人以下の奇数とする。彼らは、本憲法を確実に遵守するために必要な技術および/またはガバナンスの専門知識を有していなければならない。 +2. 憲法委員会の委員の任期は、ガードレールに従って定められる。 +3. 憲法委員会の運営の継続性を確保するため、憲法委員会委員の任期には時差を設けるものとする。 + +### 第 3 節: 憲法委員会の委員選出 + +1. Cardanoコミュニティは、ガードレールの要件に従って、憲法委員会の委員を選出するためのプロセスを随時確立および公開する。 +2. 現行の憲法委員会の任期終了前に新たな憲法委員会が選出されなかった場合、または憲法委員会が上記第 3(1) 節の要件を満たさない場合、現行の憲法委員会は、退任する憲法委員会の委員を補充するため、または必要な憲法委員会の委員数を達成するために必要な新委員を選出するためのガバナンスアクションを提出するものとする。 + +### 第 4 節: 不信任状態 + +憲法委員会は、常に信任状態または不信任状態のいずれかの状態にあるものとする。不信任状態の場合、他のオンチェーンガバナンスアクションを進める前に、「委員会/しきい値の更新」ガバナンスアクションを使用して、その時点の憲法委員会の委員を復帰させるか、交代させる必要がある。 + +### 第 5 節: 憲法委員会の投票と行動 + +1. 憲法委員会の委員は、そのプロセスに関する合理的な情報を公表し、決定についてはすべて公表されるものとする。 +2. 憲法委員会の各委員は、1 票を有する。 +3. ガバナンスアクションを否決する場合、憲法委員会の各委員は、本憲法の適用条項への言及を含め、投票の理論的根拠を示すものとする。 +4. 憲法委員会の委員は、Cardanoコミュニティに対し、彼らが否決した提案を改善するよう勧告することがある。 +5. 憲法委員会は、自らの行動規範を定め、公表し、憲法委員会が必要とみなす倫理ガイドラインを含むポリシーと手続きを採用するものとする。 + +### 第 6 節: コミュニティの支援 + +Cardanoコミュニティは、憲法委員会がその憲法上の機能を果たすために必要かつ適切なツールの作成、維持、および継続的な管理を支援する。 + +### 第 7 節: 報酬 + +憲法委員会の委員は、憲法委員会委員としての役割に対して報酬を受け取ることができるが、その報酬はCardano予算によって予見され、公開され、その役割を果たすために発生した実際かつ合理的な費用を賄う金額に限定される。 + +## 第 VIII 条 委任代表者 + +### 第 1 節: DRep ガバナンス機能 + +1. ADA 保有者は、自ら DRep として登録するか、他の登録済み DRep に投票権を委任することで、ガバナンスアクションに直接投票できる。 +2. DRep は、委任された Lovelace の数に等しい投票権を有するものとする。 +3. DRep は、DRep としての活動を管理するために、倫理ガイドラインを含む行動規範を採択、公開、維持することが推奨される。 + +### 第 2 節: DRep の登録 + +1. ADA 保有者は誰でも DRep として登録できるものとする。DRep は、1 人またはそれ以上の ADA 保有者の利益のために行動する場合がある。 +2. ADA 保有者は誰でも、自分自身を含む 1 人以上の登録済み DRep に投票権を委任できる。 +3. ADA 保有者は、いつでも投票権行使の委任を変更できる。 + +### 第 3 節: DRep の選択 + +Cardanoコミュニティは、ADA 保有者が投票権行使の委任先として DRep を選択できるようにするためのツールの作成、保守、継続的な管理をサポートすることが期待されている。 + +### 第 4 節: DRep の報酬 + +DRep には、その労に対して報酬が獲得できる場合がある。DRep としての活動に関連して受け取った報酬は、すべて公表しなければならない。 + +## 第 IX 条 ステークプール運営者 + +### 第 1 節: SPO ガバナンス機能 + +1. SPO は、特定のガバナンスアクションに対する追加的なチェック機能を果たし、ガードレールに規定されている通り、DRep とは別個に投票を行うものとする。 +2. SPO は、同じガバナンスアクションに関して DRep として同時に投票権を行使する場合には、その旨を公表しなければならない。 + +### 第 2 節: ハードフォークの開始 + +1. SPO は、Cardanoブロックチェーンのノードの運営者として、本憲法およびガードレールに従い、ハードフォーク開始プロセスに投票するものとする。 +2. SPO は、ハードフォークの開始について投票する際、Cardanoブロックチェーンの準備状況を考慮するものとする。 + +## 第 X 条 純変動制限額、Cardano予算、トレジャリー引き出し + +### 第 1 節: 純変動制限額 + +1. 純変動制限額は、前回の純変動制限額を決定する前回のガバナンスアクション後の予算期間ごとに、Cardanoコミュニティのメンバーが提案できる。 +2. 純変動制限額は、情報ガバナンスアクションとして提案され、適用されるしきい値に従って投票に付されるものとする。DRep は、純変動制限期間ごとに純変動制限額を承認する。 +3. 純変動制限期間について新たな純変動制限額が承認されない場合、従前の純変動制限額が引き続き適用される。 + +### 第 2 節: Cardano予算 + +1. Cardano予算は、各純変動制限期間において、Cardanoブロックチェーンの継続的な運営、保守、開発に合理的に必要なリソースで構成される。 +2. Cardano予算には、憲法委員会委員の報酬を含むCardanoガバナンスの編成だけでなく、かかる役職の管理、運営、契約、第三者による監査、保証に合理的に必要なリソースも含めることができる。 +3. Cardanoコミュニティは、純変動制限期間ごとにCardano予算を提案するものとし、これは情報ガバナンスアクションの形式をとり、適用されるしきい値に従って投票の対象となる。 +4. Cardanoコミュニティのメンバーは、Cardanoコミュニティのメンバーが形成する共同体を含め、誰でもCardano予算を提案できる。 +5. Cardano予算の総額は、該当する純変動制限期間について、該当する純変動制限額を超えないものとする。 + +### 第 3 節: トレジャリー引き出し + +1. 本憲法およびガードレールに定める要件に従うことを条件として、誰でもCardanoトレジャリー引き出しガバナンスアクションを提案することができる。 +2. Cardano予算が承認され、純変動制限が有効でない限り、Cardanoトレジャリー引き出しガバナンスアクションは許可されないものとする。 +3. Cardano予算のために引き出された ADA は、DRep および SPO に委任したり、Cardanoブロックチェーンのガバナンスに影響を与えたりするために利用したりしてはならない。これは、他のCardanoトレジャリー引き出しには適用されない。 +4. Cardanoトレジャリー引き出しガバナンスアクションに従って引き出された ADA は、ガバナンスアクションで宣言された目的にのみ使用されるものとする。 +5. Cardanoトレジャリー引き出しにより引き出された ADA は、金融業界のベストプラクティスに従って管理および運用されるものとする。 diff --git a/AlternateLanguageDrafts/Portuguese.md b/AlternateLanguageDrafts/Portuguese.md new file mode 100644 index 0000000..868f28f --- /dev/null +++ b/AlternateLanguageDrafts/Portuguese.md @@ -0,0 +1,280 @@ +# CONSTITUIÇÃO DA BLOCKCHAIN CARDANO + +## PREÂMBULO + +Reconhecendo que as três entidades pioneiras, Input-Output Hong Kong, Emurgo e a fundação Cardano Foundation, em colaboração com a Comunidade Cardano, fomentaram o aparecimento da Blockchain Cardano, lançando as bases para uma infraestrutura digital descentralizada que dá poder aos indivíduos e promove a colaboração e a inovação. Os seus esforços moldaram um ambiente dinâmico e diversificado de indivíduos e organizações onde qualquer pessoa pode escolher contribuir para o crescimento e sucesso do Ecossistema Cardano. + +Reconhecendo que a Blockchain Cardano existe dentro de um ecossistema descentralizado de tecnologia blockchain, contratos inteligentes e governança comunitária empenhada em melhorar globalmente os sistemas económicos, políticos e sociais. A Blockchain Cardano oferece uma infraestrutura de base que capacita indivíduos e comunidades a administrar a sua identidade, valor e governança, promovendo o surgimento de aplicações descentralizadas, negócios e redes. + +Reconhecendo que o Ecossistema Cardano se expandiu significativamente e é operado de forma descentralizada e sem permissão, reforçando ainda mais a resiliência e autonomia da Blockchain Cardano. + +Considerando que, à medida que o Ecossistema Cardano continua a crescer, o seu modelo de governança tem de se adaptar e evoluir de forma semelhante para refletir os princípios de descentralização, envolvimento da comunidade, responsabilidade, inclusão e colaboração como base de auto governança e novas abordagens à interação e colaboração humanas. + +Reconhecendo a necessidade de um quadro de governança mais robusto e flexível que utilize a tecnologia blockchain para estabelecer a governança on-chain sempre que razoavelmente possível e benéfico, a Comunidade Cardano estabelece esta Constituição da Cardano, incluindo as respetivas disposições técnicas de segurança, as quais facultam um conjunto de salvaguardas para as Ações de Governança permitidas. A Constituição da Cardano estabelece os princípios para a operação e governança da Blockchain Cardano como fundamento para que qualquer pessoa possa contribuir para o desenvolvimento do Ecossistema Cardano. + +Em busca de uma cultura de confiança e colaboração que assegure que as decisões sejam tomadas no melhor interesse do Ecossistema Cardano de acordo com os princípios de transparência, abertura e responsabilidade, a Comunidade Cardano empenha-se em trabalhar coletivamente no sentido do aperfeiçoamento, crescimento e sucesso contínuos da Blockchain Cardano e do Ecossistema Cardano. + +Reconhecendo a importância de fornecer aos SPO e a todos os Detentores de ADA uma oportunidade de contribuir para a governança da Blockchain Cardano para promoção de diversidade de pontos de vista. + +Reconhecendo a liberdade de escolha dos Detentores de ADA para contribuir para a governança da Blockchain Cardano independentemente de qualquer organização ou entidade colaborativa. + +Reconhecendo a natureza da Blockchain Cardano como uma criação sobretudo implementada por código de software e, portanto, o papel crítico e as expectativas em relação aos seus programadores e engenheiros na defesa e implementação da presente Constituição. + +Reconhecendo o papel essencial do Comité Constitucional na defesa desta Constituição e a importância dos DRep como representantes dos detentores de ADA. + +Reconhecendo a necessidade de um enquadramento para a utilização sustentável, responsável e eficaz dos recursos disponíveis na Tesouraria Cardano para a Comunidade Cardano. + +Reconhecer o direito da Comunidade Cardano de formar entre si novas entidades colaborativas para fazer face aos desafios que o Ecossistema Cardano enfrenta. + +## ARTIGO I. DEFINIÇÃO DE TERMINOLOGIA + +1. **Participação ativa na produção de blocos**: Significa, em relação aos SPO, o número de Lovelace que é ativamente delegado ao SPO para efeitos de produção de blocos. +2. **Participação de voto ativa**: O número de votos ativos refere-se ao número total de Lovelace considerado ativo, com base na atividade de votação exigida e no registro para votar, tal como especificado nas Disposições Gerais e contado para efeitos de determinação de um voto. +3. **ADA**: A criptomoeda nativa da Blockchain Cardano. +4. **Detentores de ADA**: As pessoas que controlam direta ou indiretamente a(s) chave(s) privada(s) do(s) token(s) ADA. +5. **Período limite de variação líquida**: O período que compreende 73 épocas (aproximadamente um ano civil) durante o qual um Montante Limite de Variação Líquida está em vigor. +6. **Blockchain Cardano**: Um sistema de registro distribuído, público, de prova de participação, peer-to-peer, o qual opera sob o nome "Cardano". +7. **Comunidade Cardano**: A Comunidade Cardano refere-se a todos os detentores de ADA. +8. **Ecossistema Cardano**: O Ecossistema Cardano refere-se a todos os participantes que conduzem atividades na Blockchain Cardano, incluindo, mas não limitado aos SPO, DRep, a Comunidade Cardano e o Comité Constitucional (CC). +9. **Tesouraria Cardano**: A Tesouraria Cardano é um sistema descentralizado de governança de ADA na cadeia que detém e emite ADA proveniente das taxas de transação e da expansão monetária. +10. **Comité Constitucional**: O órgão diretivo responsável por garantir que os princípios da Constituição são respeitados e cumpridos. +11. **Delegado**: Um detentor de uma ADA que tenha delegado a sua participação numa pool de participações (para a produção de blocos) e/ou num DRep (para a governança). +12. **DRep ou Representante Delegado**: Um Representante Delegado devidamente registrado que vota nas Ações de Governança. +13. **Ação de Governança**: Uma ação para registrar informações, tomar medidas em relação a ou modificar os parâmetros da Blockchain Cardano submetida a votação por órgãos de votação elegíveis na Blockchain Cardano. +14. **Proposta de ações de governança**: A proposta para uma Ação de Governança prospetiva submetida por um membro da Comunidade Cardano ou membro do Comité Constitucional para discussão ou consideração pela Comunidade Cardano. +15. **Órgão de Governança**: A organização ou grupo com autoridade para votar uma Ação de Governança, tal como descrita na Constituição, atualmente composta pelos DRep, o Comité Constitucional e os SPO. +16. **Disposições Gerais**: As Disposições Gerais referem-se a condições e parâmetros necessários para manter a funcionalidade, segurança e desempenho da Blockchain Cardano, algumas das quais, mas não todas, são diretamente implementadas na Blockchain Cardano. +17. **Guia de disposições gerais**: O guia Plutus, o qual é registrado on-chain com a constituição e cumpre as Disposições Gerais automatizáveis quando uma ação de governança é apresentada on-chain. +18. **Lovelace**: Unidade de ADA, com um milhão de Lovelace para cada ADA. +19. **Ataque de baixo custo**: Um ataque considerado como exigindo demasiado pouca ADA, esforço ou outros recursos para ser executado. É necessário determinar os valores aceitáveis para estas métricas. +20. **Ambiente da Mainnet**: A base do protocolo da Blockchain Cardano que se encontra ativa e operacional. +21. **Montante limite de variação líquida**: O limite em ADA pelo qual a Tesouraria Cardano não deve mudar num determinado período. +22. **On-chain e Off-chain**: On-chain refere-se a ações que se encontram refletidas na Blockchain Cardano. Off-chain refere-se a ações que não se encontram refletidas na Blockchain Cardano, mas são regidas pela presente Constituição. +23. **Parâmetros**: As definições e limites para a implementação da Blockchain Cardano especificados na Constituição. +24. **Protocolo**: Os algoritmos, regras e procedimentos que regem o funcionamento da Blockchain Cardano. +25. **SDR**: "Special Drawing Rights” ou Direitos de Saque Especiais, referindo-se a um ativo de reserva internacional baseado no valor de um cabaz de moedas mundiais criado pelo Fundo Monetário Internacional. As referências a "fiat" constituem referências a SDR. +26. **SPO**: Stake Pool Operator, um operador que gere um nó de produção de Blockchain Cardano. +27. **Votação**: Uma decisão expressa na Blockchain de Cardano sobre as ações de governança propostas. + +## ARTIGO II. VIGÊNCIA + +1. Esta Constituição produz efeitos para todos os membros da Comunidade Cardano, os DRep, os SPO e os membros do Comité Constitucional na medida em que interagem com a Blockchain Cardano e entre si no Ecossistema Cardano. +2. Embora o Preâmbulo estabeleça os fundamentos da presente Constituição, deve ser considerado não vinculativo para efeitos de avaliação da constitucionalidade das ações de governança propostas. +3. A presente Constituição deve ser interpretada no sentido de dar cumprimento aos princípios enunciados no ARTIGO III infra. + +## ARTIGO III. PRINCÍPIOS E DISPOSIÇÕES GERAIS + +### Secção 1: Objetivo e âmbito de aplicação + +Os princípios deste Artigo destinam-se a orientar todos os intervenientes no Ecossistema Cardano, incluindo o Comité Constitucional da Cardano, os SPO, os DRep, e os Detentores de ADA. Todas as Ações de Governança devem ser avaliadas de acordo com estes princípios. + +### Secção 2: Princípios da Cardano + +1. A Blockchain Cardano manterá a sua natureza pública e sem permissões. +2. Os processos de governança da Blockchain Cardano devem ser acessíveis, transparentes e flexíveis. +3. O desenvolvimento e a operação da Blockchain Cardano devem dar prioridade à segurança, fiabilidade e resiliência, incluindo, mas não se limitando a, evitar casos isolados de falência ou dependência. +4. O Ecossistema Cardano deve esforçar-se por alcançar a estabilidade financeira. +5. O fornecimento total de ADA não deve exceder 45 000 000 000 ADA (45 000 000 000 000 000 Lovelace). +6. Para garantir a proteção do valor e da informação, a Blockchain Cardano tem de dispor de segurança pós-quântica, armazenamento descentralizado e abordagens robustas de governança de chaves. +7. O Ecossistema Cardano tem de trabalhar para a descentralização da Blockchain Cardano, incluindo soluções escaláveis On-chain e Off-chain que considerem o rendimento, fragmentação, liquidação e preços dinâmicos, sem compromissos indevidos com a acessibilidade, sustentabilidade económica, segurança e desempenho. +8. A Blockchain Cardano deve buscar a sustentabilidade e viabilidade a longo prazo, como refletido em caraterísticas como justiça, neutralidade, sustentabilidade, governança robusta, promoção da identidade descentralizada, colaboração e participação da Comunidade Cardano. +9. A Blockchain Cardano será desenvolvida numa metodologia colaborativa e de código aberto para promover a segurança, resiliência e acessibilidade e para mitigar os riscos de centralização, e estará sempre disponível sob uma licença permissiva de código aberto. +10. Todos os participantes no Ecossistema Cardano devem ser tratados de forma justa e os seus interesses devem ser tidos em conta ao considerar as Ações de Governança. +11. A Blockchain Cardano promoverá a interoperabilidade e o acesso a outras blockchains. +12. A Blockchain Cardano Blockchain não gastará desnecessariamente recursos on-chain. +13. A Blockchain Cardano Blockchain promoverá o design e a utilização de recursos de hardware eficientes. +14. A Blockchain Cardano reconhecerá, registrará e recompensará as contribuições para as suas operações através de tokenomics justos e apropriados. + +### Secção 3: Neutralidade da Blockchain + +1. As transações na Blockchain Cardano não devem ser abrandadas ou censuradas e devem ser processadas de forma expedita para o fim a que se destinam. +2. A Blockchain de Cardano não bloqueará ADA sem o consentimento do detentor da dita ADA. +3. A concepção da Blockchain Cardano deve facilitar um modelo de custos de transação rentável, acessível e previsível. +4. Qualquer pessoa que deseje desenvolver e implantar aplicações na Blockchain Cardano não deve ser impedida de o fazer sem justificação. A Comunidade Cardano deve promover caraterísticas para ajudar no desenvolvimento e implantação de aplicações. + +### Secção 4: Disposições Gerais + +1. A Blockchain Cardano deve operar de acordo com as Disposições Gerais, conforme estabelecido no Anexo I desta Constituição. As Disposições Gerais refletem a melhor compreensão técnica atual da Blockchain Cardano e devem permanecer abertas a alterações com base em novas informações, de acordo com esta Constituição. +2. As Disposições Gerais devem permitir que a Blockchain Cardano opere de forma segura e sustentável, evitando interrupções, problemas de segurança e desempenho. Aplicam-se ao ambiente Mainnet da Blockchain Cardano e não se destinam a ser aplicadas a ambientes de teste ou a outras blockchains que utilizem o software Blockchain Cardano. +3. Os parâmetros da Blockchain Cardano definidos nas Disposições Gerais devem ser lidos em conjunto e não devem ser considerados isoladamente. As interações conhecidas entre os parâmetros são indicadas nas Disposições Gerais. +4. As Disposições Gerais aplicam-se a Ações de Governança na Blockchain Cardano, incluindo, mas não limitado a alterações de parâmetros de protocolo e levantamentos da Tesouraria Cardano. As Disposições Gerais abrangem limites essenciais e intrínsecos aos parâmetros e definições do protocolo e baseiam-se em recomendações derivadas da experiência, aferição e objetivos de governança. +5. Sempre que tecnicamente possível, as barreiras de proteção devem ser automatizadas e aplicadas através de um guia on-chain ou de regras incorporadas no registro. +6. As Disposições Gerais podem ser alteradas de acordo com as Ações de Governança que satisfaçam o limiar de votação aplicável (caso exista). De um modo geral, as alterações às Disposições Gerais constantes do Anexo I serão consideradas como uma alteração à própria Constituição e estarão sujeitas aos limiares de votação exigidos para uma Nova Constituição ou para uma Ação de Governança respeitante ao Guia das Disposições Gerais. +7. As Disposições Gerais devem ser publicadas com o número da versão e a data de entrada em vigor claramente indicados na primeira página das Disposições Gerais. +8. Em caso de incoerências entre as Disposições Gerais e os parâmetros implementados na Blockchain Cardano, os parâmetros implementados prevalecerão. Os membros do Comité Constitucional procurarão reconciliar essas incoerências através da sua governança ou promovendo uma Ação de Governança apropriada para o efeito. + +## ARTIGO IV. PARÂMETROS DA BLOCKCHAIN CARDANO + +1. Os parâmetros da Blockchain Cardano podem ser alterados através de uma ratificação da Ação de Governança necessária, de acordo com esta Constituição. +2. Os parâmetros dividem-se nas seguintes categorias: parâmetros económicos, de rede, de governança, técnicos e de segurança. Quaisquer propostas de alteração dos parâmetros devem ser avaliadas de acordo com o preâmbulo e os princípios da presente Constituição, bem como com os principais objetivos a seguir enunciados, e devem ter como base avaliações de impacto diligentes e em análises técnicas que tornem transparentes quaisquer soluções de compromisso relevantes. + +### Secção 1: Parâmetros económicos + +Os principais objetivos dos parâmetros económicos da Blockchain Cardano são permitir a sustentabilidade económica a longo prazo para a Blockchain Cardano, garantir que os SPO sejam adequadamente recompensados por manter a Blockchain Cardano, assegurar que os detentores de ADA são adequadamente recompensados por usar a sua ADA de forma construtiva e equilibrar os incentivos económicos para os diferentes participantes do Ecossistema de Cardano. + +### Secção 2: Parâmetros de rede + +Os principais objetivos dos parâmetros de rede da Blockchain Cardano são fazer corresponder a capacidade disponível da rede da Blockchain Cardano às exigências de tráfego atuais ou futuras e equilibrar as exigências de tráfego para os diferentes participantes do Ecossistema de Cardano. + +### Secção 3: Parâmetros de governança + +Os principais objetivos dos parâmetros de governança da Blockchain Cardano são assegurar a estabilidade do sistema de governança da Blockchain Cardano e manter um sistema de governança de acordo com esta Constituição. + +### Secção 4: Parâmetros técnicos e de segurança + +Os principais objetivos dos parâmetros técnicos e de segurança da Blockchain Cardano são garantir a segurança da rede Blockchain de Cardano em termos de descentralização, proteção contra ataques Sybil e 51% e proteção contra ataques de negação de serviço. Os parâmetros técnicos e de segurança também regem as alterações aos limites de execução dos contratos inteligentes e aos modelos de custos associados. + +## ARTIGO V. GOVERNANÇA DA BLOCKCHAIN CARDANO + +### Secção 1: Modelo de governança + +1. A Blockchain Cardano utilizará um modelo de governança participativa ao abrigo do qual os Detentores de ADA podem fazer propostas de Ações de Governança e votar nessas mesmas propostas, de acordo com os freios e contrapesos do presente Artigo V. +2. O processo de participação, apresentação e votação das ações de governança deve ser transparente e protegido contra fraudes. + +### Secção 2: Órgãos de governança + +A governança da Blockchain Cardano será conduzida através de três Órgãos de Governança: os DRep, os SPO e o Comité Constitucional. Estes Órgãos de Governança devem facultar um sistema de freios e contrapesos para a Blockchain Cardano. + +### Secção 3: Ações de governança + +1. Os detentores de ADA podem, a qualquer momento, propor Ações de Governança na Blockchain Cardano. Atualmente, esta Constituição prevê as seguintes Ações de Governança: + - Moção de não-confiança, para rejeitar/afastar/suprimir a atual Comissão Constitucional até que seja eleito/designado um substituto; + - Atualizar o Comité e/ou o limiar e/ou o mandato, para alterar os membros ou o limiar ou o mandato dos membros do Comité Constitucional, ou qualquer combinação destes; + - Guia de Nova Constituição ou de Disposições Gerais para alterar a Constituição incluindo as Disposições Gerais ou atualizar ou cancelar o guia das mesmas; + - Iniciativa Hard-Fork, para desencadear uma atualização não compatível com o passado do software Blockchain Cardano; + - Protocol Parameter Change (Alteração de parâmetros do protocolo), para desencadear uma ou mais alterações aos parâmetros atualizáveis da Blockchain Cardano; + - Levantamento de Tesouraria, para levantar fundos da Tesouraria Cardano. + - Ações de informação, para permitir avaliar o sentimento da Comunidade Cardano sem se comprometer com quaisquer alterações ao protocolo. +2. As propostas de Ação de Governança devem ser apresentadas num formato normalizado e legível e conter uma justificação suficiente para a proposta, incluindo, se for caso disso, quaisquer sugestões de alterações à Blockchain de Cardano. Quando originalmente escritas num idioma diferente do idioma desta Constituição, as propostas de Ação de Governança devem ser acompanhadas por uma tradução da proposta de Ação de Governança para o idioma desta Constituição (inglês). +3. As Ações de Governança de Levantamento de Tesouraria devem, em particular, incluir informações que especifiquem se o levantamento de tesouraria previsto se encontra não contemplado no Orçamento Cardano. +4. Por fundamentação suficiente entende-se que a proposta demonstra de que forma a ação de governança proposta atinge o objetivo pretendido. A documentação de apoio, em linguagem e a estrutura claras e compreensíveis, incluindo, entre outros, o título, um resumo, a razão da proposta e os relevantes links de apoio são indicadores de fundamentação suficiente. +5. As propostas de Ações de Governança devem incluir um URL e um hash digest derivado do conteúdo desse URL. Uma ação só será considerada constitucional se o conteúdo puder ser verificado de forma independente para produzir o mesmo hash digest. +6. As Ações de Governança para Iniciativa Hard-Fork e para a Alteração dos Parâmetros do Protocolo devem ser submetidas a revisão técnica e escrutínio suficientes, tal como estabelecido nas Disposições Gerais. Essas ações de governança não devem pôr em risco a segurança, a funcionalidade ou o desempenho da Blockchain Cardano. +7. As ações de governança propostas devem ser votadas pelos devidos órgãos de governança, para serem ratificadas e posteriormente promulgadas na cadeia, se for o caso. +8. As Ações de Informação devem ser votadas pelos DRep, pelos SPO e pelo Comité Constitucional. As Ações de Informação não têm qualquer efeito para além de registrar o resultado de tal votação na Blockchain Cardano. As Ações de Governança para Informação são expressões do sentimento da Comunidade Cardano e não requerem um resultado "Sim" para serem aprovadas. + +### Secção 4: Votação + +1. As decisões sobre as propostas de Ações de Governança serão tomadas pelo Comité Constitucional, pelos SPO e os DRep através do processo de votação, em conformidade com os requisitos desta Constituição e das Disposições Gerais. +2. Os DRep e os SPO têm poder de voto proporcional ao Lovelace que lhes foi delegado. Um Lovelace equivale a um voto. +3. Cada membro do Comité Constitucional dispõe de um voto. +4. Os votos podem ser expressos como "Sim", "Não" ou "Abstenção". + +### Secção 5: Limiares e quóruns de votação + +1. Os limiares de votação para cada Órgão de Governança, em vigor à data da primeira emissão desta Constituição, encontram-se estabelecidos no ficheiro Conway genesis e podem ser alterados através de uma Ação de Governança para Atualização dos Parâmetros do Protocolo. Essa ação de governança para atualização dos parâmetros do protocolo não constitui uma alteração a esta Constituição. +2. Os limiares de votação não devem estar fora dos seguintes intervalos: + - Relativamente ao Comité Constitucional: as votações de todas as ações de governança devem ser aprovadas com um limiar fixado entre 51% e 100%. Na data da primeira publicação desta Constituição este limiar é de 66,67% dos membros do Comité Constitucional. + - Relativamente aos DRep e aos SPO: intervalos de limiares de votação, tal como especificado na secção 3.6.4 "Limiares de votação" como consta nas Disposições Gerais. +3. O atual limiar de votação aplicável a uma ação de governança por um determinado órgão de governança pode ser consultado nos parâmetros atualmente implementados on-chain. +4. Para além da votação do Comité Constitucional, sempre que exigido pela presente Constituição, as ações de governança requerem os seguintes quóruns: + - Para serem aprovadas, as alterações dos parâmetros requerem um voto afirmativo de SPO e um voto afirmativo de DRep. + - As iniciativas hard-fork requerem um voto afirmativo de SPO e um voto afirmativo de DRep para serem aprovadas. + - A moção de não-confiança e a atualização do comité/limiar requerem um voto afirmativo do SPO e um voto afirmativo do DRep para serem aprovadas. + - Os levantamentos de tesouraria requerem um voto favorável do DRep para serem aprovados. + - As Ações de Governança da Informação requerem uma votação SPO e uma votação DRep, no entanto não é necessário qualquer resultado, uma vez que estas Ações de Governança são utilizadas apenas para avaliar e registrar o sentimento da Comunidade Cardano. + - Para serem aprovadas, as alterações constitucionais requerem um voto favorável do DRep. +5. Todas as outras ações de governança requerem um voto afirmativo do DRep para serem aprovadas. + +## ARTIGO VI. COMUNIDADE CARDANO + +1. Não será exigida qualquer filiação formal para que os membros da Comunidade Cardano se envolvam no Ecossistema Cardano e na governança da Blockchain Cardano. +2. Espera-se que os membros da Comunidade Cardano apoiem e defendam as disposições desta Constituição e resolvam os litígios de uma forma justa, construtiva e transparente. +3. A Comunidade Cardano deve apoiar a criação, manutenção e administração contínua de processos de governança off-chain, conforme necessário, no cumprimento desta Constituição e para garantir que haja consciência e uma oportunidade para debater e moldar as Ações de Governança da Blockchain Cardano. +4. A Comunidade é encorajada a colaborar no desenvolvimento, manutenção e construção de aplicações para a Blockchain Cardano. + +## ARTIGO VII. COMITÉ CONSTITUCIONAL + +### Secção 1: Função e participação do Comité Constitucional + +1. O Comité Constitucional é criado como um órgão independente para garantir que todas as ações de governança propostas cumprem o disposto na presente Constituição, antes de serem votadas e implementadas. +2. Nenhuma ação de governança, para além de uma "Moção de não-confiança" ou de uma "Atualização do Comité/Limiar Constitucional", pode ser implementada on-chain, a menos que o Comité Constitucional tenha antes reiterado, através de uma votação on-chain, que essa proposta não viola a presente Constituição. + +### Secção 2: Composição do Comité Constitucional + +1. O Comité Constitucional deve ser composto por um número de membros especificado periodicamente pelas Disposições Gerais Cardano, e deve, em qualquer caso, ser em número ímpar, não inferior a 3 e não superior a 9, para evitar um impasse de votação no seio do Comité Constitucional. Devem possuir as competências técnicas e/ou de governança necessárias para assegurar o cumprimento da presente Constituição. +2. Os membros do Comité Constitucional exercem os seus mandatos em conformidade com as Disposições Gerais. +3. A fim de assegurar a continuidade do funcionamento do Comité Constitucional, os mandatos dos membros do Comité Constitucional serão desfasados. + +### Secção 3: Eleição dos membros do Comité Constitucional + +1. A Comunidade Cardano deve estabelecer e publicar periodicamente um processo para a eleição dos membros do Comité Constitucional, em conformidade com os requisitos estipulados nas Disposições Gerais. +2. Se não for eleito um novo Comité Constitucional antes do final do mandato do atual Comité Constitucional, ou se o Comité Constitucional não cumprir os requisitos da Secção 3(1) supra, o atual Comité Constitucional apresentará uma ação de governança para eleger novo(s) membro(s), conforme necessário, para substituir quaisquer membros cessantes do Comité Constitucional ou para atingir o número necessário de membros do Comité Constitucional. + +### Secção 4: Estado de não-confiança + +O Comité Constitucional deve estar sempre num dos dois estados seguintes: um estado de confiança ou um estado de não-confiança. Num estado de não-confiança, os membros da Comissão Constitucional então em funções devem ser reintegrados ou substituídos utilizando a Ação de Governança "Atualizar comité/limiar" antes de se poder proceder a qualquer outra Ação de Governança on-chain. + +### Secção 5: Votação e conduta do Comité Constitucional + +1. Os membros do Comité Constitucional devem publicar informações razoáveis sobre os seus processos e todas as decisões tomadas devem ser publicadas. +2. Cada membro do Comité Constitucional dispõe de um voto. +3. Ao rejeitar uma ação de governança, cada membro do Comité Constitucional exporá a fundamentação do seu voto, incluindo referências às disposições aplicáveis da presente Constituição. +4. Os membros do Comité Constitucional podem fazer recomendações à Comunidade Cardano para melhorar as propostas que tenham rejeitado. +5. O Comité Constitucional: estabelece e publica para si próprio um código de conduta e adopta as políticas e os procedimentos, incluindo quaisquer orientações éticas, que considere necessários. + +### Secção 6: Apoio da comunidade + +A Comunidade Cardano apoia a criação, a manutenção e a administração contínua dos instrumentos necessários e adequados para que o Comité Constitucional desempenhe as suas funções constitucionais. + +### Secção 7: Compensação + +Os membros do Comité Constitucional podem ser compensados pelo seu papel como membros do Comité Constitucional, desde que tal compensação esteja prevista no Orçamento da Cardano, seja divulgada publicamente e seja limitada no seu montante para cobrir os custos reais e razoáveis incorridos no desempenho das suas funções. + +## ARTIGO VIII. REPRESENTANTES DELEGADOS + +### Secção 1: Função de governança dos DRep + +1. Os detentores de ADA podem votar diretamente nas ações de governança registrándo-se como DRep ou delegando os seus direitos de voto a outros DRep registrados. +2. Os DRep terão um poder de voto igual ao número de Lovelace que lhes foi delegado. +3. Os DRep são incentivados a adoptar, publicar e manter códigos de conduta, incluindo orientações éticas, para reger as suas atividades como DRep. + +### Secção 2: Registro dos DRep + +1. Qualquer detentor de ADA pode registrar-se como DRep. Um DRep pode agir no interesse de um ou mais detentores de ADA. +2. Qualquer detentor de ADA pode delegar o seu direito de voto em um ou mais DRep registrados, incluindo em si próprio. +3. Os detentores de ADA estão autorizados a alterar a delegação da sua participação de voto em qualquer altura. + +### Secção 3: Escolha dos DRep + +Espera-se que a Comunidade Cardano apoie a criação, manutenção e administração contínua de ferramentas que permitam aos detentores de ADA escolher os DRep para a sua delegação de voto. + +### Secção 4: Compensação dos DRep + +Os DRep podem ser compensados pelos seus esforços. Devem divulgar publicamente qualquer compensação recebida no âmbito das suas atividades como DRep. + +## ARTIGO IX. STAKE POOL OPERATORS + +### Secção 1: Função de governança dos SPO + +1. Os SPO funcionarão como uma verificação adicional de ações de governança específicas, onde votarão separadamente dos DRep, tal como estabelecido nas Disposições Gerais. +2. Os SPO devem divulgar publicamente se estão simultaneamente a votar como DRep nas mesmas ações de governança. + +### Secção 2: Iniciativa Hard-Fork + +1. Como operadores dos nós da Blockchain Cardano, os SPO devem votar no processo de Iniciativa Hard-Fork de acordo com esta Constituição e as Disposições Gerais. +2. Os SPO devem considerar a prontidão da Blockchain Cardano quando votarem numa Iniciativa Hard-Fork. + +## ARTIGO X. LIMITE DE VARIAÇÃO LÍQUIDA, ORÇAMENTO DA CARDANO E LEVANTAMENTOS DE TESOURARIA + +### Secção 1: Montante limite de variação líquida + +1. Um Montante Limite de Variação Líquida pode ser proposto por qualquer membro da Comunidade Cardano para cada Período Orçamental após a precedente Ação de Governança, a qual estabeleceu o Montante Limite de Variação Líquida a aplicar. +2. Os Montantes Limite de Alteração Líquida devem ser propostos como uma Ação de Governança para Informação e estar sujeitos a votação de acordo com os limiares aplicáveis. Os DRep devem aprovar um montante limite de variação líquida para cada período limite de variação líquida. +3. Se não for aprovado um novo montante limite de variação líquida para um período limite de alteração líquida, continuará a aplicar-se o montante limite de variação líquida anterior. + +### Secção 2: Orçamento da Cardano + +1. O Orçamento da Cardano compreende os recursos razoavelmente necessários para as operações em curso, manutenção e desenvolvimento do Blockchain Cardano para cada Período Limite de Variação Líquida. +2. O Orçamento de Cardano pode também incluir os recursos razoavelmente necessários para a administração, governança, contratação, auditoria de terceiros e garantia de tais posições, bem como a orquestração da governança de Cardano, incluindo a compensação dos membros do Comité Constitucional. +3. A Comunidade Cardano deve propor o Orçamento da Cardano para cada Período Limite de Variação Líquida, o qual que deve assumir a forma de uma Ação de Governança para Informação e estar sujeito a votação de acordo com os limiares aplicáveis. +4. Qualquer membro da Comunidade Cardano, incluindo quaisquer organismos de colaboração que os membros da Comunidade Cardano possam formar, pode propor um Orçamento da Cardano. +5. O montante total do Orçamento da Cardano não deve exceder o Montante Limite de Variação Líquida aplicável para o Período do Limite de Variação Líquida correspondente. + +### Secção 3: Levantamentos de Tesouraria + +1. Sujeito aos requisitos estabelecidos nesta Constituição e nas Disposições Gerais, qualquer pessoa pode propor uma Ação de Governança para Levantamento de Tesouraria Cardano. +2. Nenhuma Ação de Governança para Levantamento de Tesouraria Cardano será permitida a menos que um Orçamento Cardano tenha sido aprovado e um Limite de Variação Líquida esteja em vigor. +3. Qualquer ADA retirado para o Orçamento da Cardano não deve ser delegado nem aos DRep nem aos SPO ou de outra forma utilizado para influenciar a governança da Blockchain Cardano. Isto não se aplica a outros levantamentos de tesouraria Cardano. +4. Qualquer ADA retirado de acordo com uma Ação de Governança para Levantamento de Tesouraria Cardano deve ser exclusivamente utilizado para o fim declarado na Ação de Governança. +5. Qualquer ADA levantado através de um levantamento de tesouraria Cardano deve ser administrado e gerido de acordo com as melhores práticas do sector financeiro. diff --git a/AlternateLanguageDrafts/Spanish.md b/AlternateLanguageDrafts/Spanish.md new file mode 100644 index 0000000..97b5cc9 --- /dev/null +++ b/AlternateLanguageDrafts/Spanish.md @@ -0,0 +1,280 @@ +# CONSTITUCIÓN DE LA CADENA DE BLOQUES CARDANO + +## PREÁMBULO + +Se reconoce que las tres entidades pioneras, Input-Output Hong Kong, Emurgo y la Fundación Cardano, en colaboración con la Comunidad de Cardano, han fomentado la aparición de la Cadena de bloques Cardano, sentando las bases de una infraestructura digital descentralizada que capacita a las personas y promueve la colaboración y la innovación. Sus esfuerzos han dado forma a un entorno vibrante y diverso de personas y organizaciones donde cualquiera puede elegir contribuir al crecimiento y éxito del Ecosistema de Cardano. + +Se reconoce que la Cadena de bloques Cardano existe dentro de un ecosistema descentralizado de tecnología de cadena de bloques, contratos inteligentes y gobierno comunitario que se ha comprometido a mejorar los sistemas económicos, políticos y sociales a escala mundial. La Cadena de bloques Cardano ofrece una infraestructura fundacional que permite a las personas y comunidades gestionar su identidad, valor y gobierno, fomentando la aparición de aplicaciones, empresas y redes descentralizadas. + +Se reconoce que el Ecosistema de Cardano ha crecido significativamente y opera de forma descentralizada y sin permisos, fortaleciendo aún más la resiliencia y autonomía de la Cadena de bloques Cardano. + +Se considera que a medida que el Ecosistema de Cardano sigue creciendo, su modelo de gobierno necesita adaptarse y evolucionar de forma similar para reflejar los principios de descentralización, participación de la comunidad, responsabilidad, inclusividad y colaboración como base del autogobierno y nuevos enfoques de la interacción y colaboración humanas. + +Se reconoce la necesidad de un marco de gobierno más sólido y adaptable que utilice la tecnología de cadena de bloques para establecer un gobierno dentro de la cadena siempre que sea razonablemente posible y beneficioso, la Comunidad de Cardano establece esta Constitución de Cardano, incluidas sus Barreras de seguridad técnicas que proporcionan un conjunto de medidas de protección para las Acciones de gobierno permisibles. La Constitución de Cardano establece los principios de funcionamiento y gobierno de la Cadena de bloques Cardano como base para que cualquiera pueda contribuir al desarrollo del Ecosistema de Cardano. + +Se persigue una cultura de confianza y colaboración que garantice que las decisiones se toman en el mejor interés del Ecosistema de Cardano de acuerdo con los principios de transparencia, apertura y responsabilidad, la Comunidad de Cardano se esfuerza por trabajar juntos hacia la mejora continua, el crecimiento y el éxito de la Cadena de bloques Cardano y el Ecosistema de Cardano. + +Se reconoce la importancia de proporcionar a los SPO y a todos los Titulares de ada la oportunidad de contribuir al gobierno de la Cadena de bloques Cardano para fomentar la diversidad de puntos de vista. + +Se reconoce la libertad de elección de los Titulares de ada para contribuir al gobierno de la Cadena de bloques Cardano independientemente de cualquier organización u organismo colaborativo. + +Se reconoce la naturaleza de la Cadena de bloques Cardano como un constructo implementado en última instancia por código de software y, por lo tanto, el papel fundamental de sus desarrolladores e ingenieros y las expectativas hacia ellos en la defensa y aplicación de esta Constitución. + +Se reconoce el papel esencial del Comité constitucional en la defensa de esta Constitución y la importancia de los DReps como representantes de los Titulares de ada. + +Se reconoce la necesidad de un marco para la utilización sostenible, responsable y eficaz de los recursos disponibles para la Comunidad de Cardano en la Tesorería de Cardano. + +Se reconoce el derecho de la Comunidad de Cardano a formar nuevos órganos de colaboración entre ellos para asumir los retos a los que se enfrenta el Ecosistema de Cardano. + +## ARTÍCULO I. TÉRMINOS DEFINIDOS + +1. **Participación en la producción de bloques activos**: Significa, en relación con los SPO, el número de Lovelace que se delega activamente en el SPO para la producción de bloques. +2. **Participación activa en las votaciones**: La participación activa en las votaciones se refiere al número total de Lovelace que se considera activo, en función de la actividad electoral requerida y en el registro para votar, tal y como se especifica en las Barreras de seguridad, y que se cuenta a efectos de determinar un voto. +3. **ada**: Se refiere a la criptomoneda nativa de la Cadena de bloques Cardano. +4. **Titulares de ada**: Se refiere a las personas que controlan directa o indirectamente la(s) clave(s) privada(s) de los tokens de ada. +5. **Período límite de cambio neto**: Se refiere al periodo que comprende 73 épocas (aproximadamente un año natural) durante el cual está en vigor un Importe límite de cambio neto. +6. **Cadena de bloques Cardano**: Un sistema de contabilidad distribuida público, de prueba de participación, entre pares, que opera bajo el nombre de «Cardano». +7. **Comunidad de Cardano**: La Comunidad de Cardano se refiere a todos los Titulares de ada. +8. **Ecosistema de Cardano**: El Ecosistema de Cardano se refiere a todos los participantes que llevan a cabo actividades en la Cadena de bloques Cardano, incluidos, entre otros, los SPO, DRep, la Comunidad de Cardano y el Comité constitucional. +9. **Tesorería de Cardano**: La Tesorería de Cardano es un sistema descentralizado de gestión de ada dentro de la cadena que guarda y libera los ada recibidos de las comisiones por transacciones y la expansión monetaria. +10. **Comité constitucional**: Órgano de gobierno encargado de velar por el respeto y la aplicación de los principios de la Constitución. +11. **Delegante**: Un Titular de ada que ha delegado su participación en un grupo de participaciones (para la producción de bloques) y/o en un DRep (para el gobierno). +12. **DRep o Representante delegado**: Representante delegado debidamente registrado que vota las Acciones de gobierno. +13. **Acción de gobierno**: Se refiere a una acción para registrar información, tomar medidas o modificar los parámetros de la Cadena de bloques Cardano que se somete a votación por los órganos de votación elegibles en la Cadena de bloques Cardano. +14. **Propuestas de Acciones de gobierno**: Se refiere a una propuesta de una posible Acción de gobierno presentada por un miembro de la Comunidad de Cardano o un miembro del Comité constitucional para su debate o consideración por parte de la Comunidad de Cardano. +15. **Órgano de gobierno**: Se refiere a una organización o grupo con autoridad para votar sobre una Acción de gobierno según lo descrito en la Constitución, actualmente compuesto por los DRep, el Comité constitucional y los SPO. +16. **Barreras de seguridad**: Las Barreras de seguridad se refieren a las condiciones y parámetros necesarios para mantener la funcionalidad, la seguridad y el rendimiento de la Cadena de bloques Cardano, algunos de los cuales, pero no todos, se implementan directamente en la Cadena de bloques Cardano. +17. **Script de las Barreras de protección**: El script Plutus que se registra dentro de la cadena con la Constitución y que aplica las Barreras de seguridad automatizables cuando se presenta una Acción de gobierno dentro de la cadena. +18. **Lovelace**: Significa una unidad de ada, con un millón de Lovelace por cada ada. +19. **Ataque de bajo coste**: Un ataque que se considera que requiere muy pocos ada, esfuerzo u otros recursos para ejecutarse. Es necesario determinar los valores aceptables para estas métricas. +20. **Entorno de mainnet**: Significa la capa base del protocolo de Cadena de bloques Cardano que está viva y operativa. +21. **Importe límite de cambio neto**: Significa el límite en ada por el cual la Tesorería de Cardano no cambiará en un periodo determinado. +22. **Dentro y fuera de la cadena**: «Dentro de la cadena» se refiere a las acciones que se reflejan en la Cadena de bloques Cardano. «Fuera de la cadena» se refiere a las acciones que no se reflejan en la Cadena de bloques Cardano, pero que se rigen por esta Constitución. +23. **Parámetros**: Significa los ajustes y límites para la implementación de la Cadena de bloques Cardano que se especifican en la Constitución. +24. **Protocolo**: Significa los algoritmos, reglas y procedimientos que rigen el funcionamiento de la Cadena de bloques Cardano. +25. **DEG**: Significa «derechos especiales de giro», que se refiere a un activo de reserva internacional basado en el valor de una cesta de monedas mundiales creada por el Fondo Monetario Internacional. Las referencias a «fiat» serán referencias a DEG. +26. **SPO**: Operador de grupos de participaciones, que gestiona un nodo productor de bloques Cardano. +27. **Voto**: Se refiere a una decisión expresada en la Cadena de bloques Cardano sobre Acciones de gobierno propuestas. + +## ARTÍCULO II. APLICABILIDAD + +1. Esta Constitución se aplicará a todos los miembros de la Comunidad de Cardano, DRep, SPO y miembros del Comité constitucional en la medida en que interactúen con la Cadena de bloques Cardano y entre sí en el Ecosistema de Cardano. +2. Aunque el Preámbulo proporciona los fundamentos de esta Constitución, se considerará no vinculante a efectos de evaluar la constitucionalidad de las Acciones de gobierno propuestas. +3. La presente Constitución se interpretará de conformidad con los principios enunciados en el Artículo III siguiente. + +## ARTÍCULO III. PRINCIPIOS Y BARRERAS DE SEGURIDAD + +### Sección 1: Finalidad y alcance + +Los principios de este Artículo pretenden guiar a todos los actores del Ecosistema de Cardano, incluidos el Comité constitucional de Cardano, los SPO, los DRep y los Titulares de ada. Todas las Acciones de gobierno se evaluarán de acuerdo con estos principios. + +### Sección 2: Principios de Cardano + +1. La Cadena de bloques Cardano mantendrá su naturaleza pública y sin permisos. +2. Los procesos de gobierno de la Cadena de bloques Cardano serán accesibles, transparentes y adaptables. +3. El desarrollo y funcionamiento de la Cadena de bloques Cardano dará prioridad a la seguridad, fiabilidad y resistencia, lo que incluye, entre otras cosas, evitar puntos únicos de fallo o dependencia. +4. El Ecosistema de Cardano se esforzará por lograr la estabilidad financiera. +5. La oferta total de ada no superará los 45 000 000 000 ada (45 000 000 000 000 000 Lovelace). +6. Para garantizar la protección del valor y la información, la Cadena de bloques Cardano se esforzará por lograr una seguridad postcuántica, un almacenamiento descentralizado y unos sólidos enfoques de gestión de claves. +7. El Ecosistema de Cardano se esforzará por la descentralización de la Cadena de bloques Cardano, incluyendo soluciones escalables dentro y fuera de la cadena que tengan en cuenta el rendimiento, la fragmentación, la liquidación y la fijación dinámica de precios sin compensaciones indebidas con la accesibilidad, la sostenibilidad económica, la seguridad y el rendimiento. +8. La Cadena de bloques Cardano perseguirá la sostenibilidad y la viabilidad a largo plazo, tal y como se refleja en características como la equidad, la neutralidad, la sostenibilidad, el gobierno sólido, la promoción de la identidad descentralizada, la colaboración y la participación de la Comunidad de Cardano. +9. La Cadena de bloques Cardano se desarrollará con una metodología colaborativa de código abierto para promover la seguridad, resistencia y accesibilidad y para mitigar los riesgos de centralización, y estará disponible en todo momento bajo una licencia de código abierto permisiva. +10. Todos los participantes en el Ecosistema de Cardano serán tratados de forma justa y sus intereses se tendrán en cuenta a la hora de considerar las Acciones de gobierno. +11. La Cadena de bloques Cardano debe fomentar la interoperabilidad y el acceso a otras cadenas de bloques. +12. La Cadena de bloques Cardano no gastará innecesariamente recursos dentro de la cadena. +13. La Cadena de bloques Cardano promoverá el diseño y la utilización eficientes de los recursos de hardware. +14. La Cadena de bloques Cardano reconocerá, registrará y recompensará las contribuciones a sus operaciones a través de una economía de tokens justa y apropiada. + +### Sección 3: Neutralidad de la Cadena de bloques + +1. Las transacciones en la Cadena de bloques Cardano no se ralentizarán ni censurarán, y deberán procesarse de forma expeditiva para el fin previsto. +2. La Cadena de bloques Cardano no bloqueará ada sin el consentimiento del Titular de ada. +3. El diseño de la Cadena de bloques Cardano deberá facilitar un modelo de costes de transacción rentable, accesible y predecible. +4. Cualquiera que desee desarrollar y desplegar aplicaciones en la Cadena de bloques Cardano no debería verse impedido de hacerlo de forma irrazonable. La Comunidad de Cardano deberá promover funciones que ayuden a desarrollar y desplegar aplicaciones. + +### Sección 4: Barreras de seguridad + +1. La Cadena de bloques Cardano funcionará de acuerdo con las Barreras de seguridad establecidas en el Apéndice I de esta Constitución. Las Barreras de protección reflejan el mejor conocimiento técnico actual de la Cadena de bloques Cardano y permanecerán abiertas a cambios basados en nueva información, de acuerdo con esta Constitución. +2. Las Barreras de seguridad permitirán que la Cadena de bloques Cardano funcione de forma segura y sostenible evitando interrupciones y problemas de seguridad y rendimiento. Se aplicarán al entorno de mainnet de la Cadena de bloques Cardano, y no se pretende que se apliquen a entornos de prueba o a otras cadenas de bloques que utilicen el software de la Cadena de bloques Cardano. +3. Los parámetros de la Cadena de bloques Cardano establecidos en las Barreras de seguridad se leerán juntos y no se considerarán de forma aislada. Las interacciones conocidas entre parámetros se indican en las Barreras de seguridad. +4. Las Barreras de seguridad se aplican a las Acciones de gobierno en la Cadena de bloques Cardano, incluidos, entre otras, los cambios en los parámetros de protocolo y retiradas de Tesorería de Cardano. Las Barreras de seguridad abarcan tanto los límites esenciales como los intrínsecos de los parámetros y ajustes del protocolo, y se basan en recomendaciones derivadas de la experiencia, las mediciones y los objetivos de gobierno. +5. Siempre que sea técnicamente posible, las Barreras de seguridad se automatizarán y se aplicarán mediante un script dentro de la cadena o mediante reglas integradas en el libro mayor. +6. Las Barreras de seguridad se podrán modificar en virtud de Acciones de gobierno que respeten el umbral de votación aplicable (si lo hubiera). Por lo general, las modificaciones de las Barreras de seguridad que figuran en el Apéndice I se considerarán una modificación de la propia Constitución y estarán sujetas a los umbrales de votación requeridos para una Nueva Constitución o una Acción de gobierno de Script de Barreras de seguridad. +7. Las Barreras de seguridad se publicarán con un número de versión claro y la fecha de entrada en vigor indicada en la primera página. +8. En caso de incoherencias entre las Barreras de seguridad y los parámetros implementados en la Cadena de bloques Cardano, prevalecerán los parámetros implementados. Los miembros del Comité constitucional tratarán de conciliar esas incoherencias mediante la sugerencia o el fomento de una Acción de gobierno adecuada. + +## ARTÍCULO IV. PARÁMETROS DE LA CADENA DE BLOQUES CARDANO + +1. Los Parámetros de la Cadena de bloques Cardano podrán modificarse mediante la ratificación de la Acción de gobierno necesaria de acuerdo con esta Constitución. +2. Los Parámetros se dividen en las siguientes categorías: económicos, de red, de gobierno, técnicos y de seguridad. Cualquier propuesta de modificación de los Parámetros se evaluará de acuerdo con el preámbulo y los principios de esta Constitución, así como con los objetivos principales que se exponen a continuación, y se basará en evaluaciones de impacto diligentes y en análisis técnicos que hagan transparentes las compensaciones materiales implicadas. + +### Sección 1: Parámetros económicos + +Los principales objetivos de los parámetros económicos de la Cadena de bloques Cardano son permitir la sostenibilidad económica a largo plazo para la misma, garantizar que los SPO sean recompensados adecuadamente por mantener la Cadena de bloques Cardano, garantizar que los Titulares de ada sean recompensados adecuadamente por utilizar sus ada de forma constructiva y equilibrar los incentivos económicos para los diferentes participantes en el Ecosistema de Cardano. + +### Sección 2: Parámetros de red + +Los principales objetivos de los parámetros de red de la Cadena de bloques Cardano son ajustar la capacidad de red disponible de la Cadena de bloques Cardano a las demandas de tráfico actuales o futuras y equilibrar las demandas de tráfico de los diferentes participantes del Ecosistema de Cardano. + +### Sección 3: Parámetros de gobierno + +Los principales objetivos de los parámetros de gobierno de la Cadena de bloques Cardano son garantizar la estabilidad del sistema de gobierno de la Cadena de bloques Cardano y mantener un sistema de gobierno conforme a esta Constitución. + +### Sección 4: Parámetros técnicos y de seguridad + +Los principales objetivos de los parámetros técnicos y de seguridad de la Cadena de bloques Cardano son garantizar la seguridad de la red de la Cadena de bloques Cardano en términos de descentralización, protección contra ataques Sybil y 51 % y la protección contra los ataques de denegación de servicio. Los parámetros técnicos y de seguridad también rigen los cambios en los límites de ejecución de los contratos inteligentes y los modelos de costes asociados. + +## ARTÍCULO V. GOBIERNO DE LA CADENA DE BLOQUES CARDANO + +### Sección 1: Modelo de gobierno + +1. La Cadena de bloques Cardano utilizará un modelo de gobierno participativo bajo el cual los Titulares de ada podrán hacer propuestas de Acciones de gobierno y votar sobre dichas propuestas, de conformidad con los controles y equilibrios del presente Artículo V. +2. El proceso de participación, presentación y votación de las Acciones de gobierno será transparente y estará protegido de cualquier manipulación. + +### Sección 2: Órganos de gobierno + +El gobierno de la Cadena de bloques Cardano se llevará a cabo a través de tres Órganos de gobierno: DRep, SPO y el Comité constitucional. Estos Órganos de gobierno proporcionarán controles y equilibrios para la Cadena de bloques Cardano. + +### Sección 3: Acciones de gobierno + +1. Los Titulares de ada podrán proponer en cualquier momento una Acción de gobierno en la Cadena de bloques Cardano. Esta Constitución prevé actualmente las siguientes Acciones de gobierno: + - **Moción de censura**: para rechazar/anular/destituir al actual Comité constitucional hasta que se elija/designe un sustituto. + - **Actualizar el Comité o el umbral o el mandato**: para cambiar los miembros o el umbral o el mandato de los miembros del Comité constitucional, o cualquier combinación de los mismos. + - **Nueva Constitución o Script de Barreras de seguridad**: para modificar la Constitución incluidas las Barreras de seguridad o actualizar o eliminar el Script de Barreras de seguridad. + - **Inicio de bifurcación dura**: para activar una actualización no retrocompatible del software de la Cadena de bloques Cardano. + - **Cambio de parámetros de protocolo**: para activar uno o más cambios en los parámetros actualizables de la Cadena de bloques Cardano. + - **Retirada de Tesorería**: para retirar fondos de la Tesorería de Cardano. + - **Acciones informativas**: para permitir que se sondee la opinión de la Comunidad de Cardano sin comprometerse a ningún cambio en el protocolo. +2. Las propuestas de Acciones de gobierno deberán estar en un formato estandarizado y legible y contener una justificación suficiente de las mismas, incluido, en su caso, cualquier cambio sugerido en la Cadena de bloques Cardano. Cuando estén redactadas originalmente en una lengua distinta de la de la presente Constitución, las propuestas de Acciones de gobierno irán acompañadas de una traducción a la lengua de la presente Constitución (inglés). +3. Las Acciones de gobierno de retirada de Tesorería incluirán, en particular, información que especifique si la retirada de Tesorería contemplada está incluida o no en el Presupuesto de Cardano. +4. Por justificación suficiente se entenderá que la propuesta demuestre cómo la Acción de gobierno propuesta logra el objetivo previsto. La documentación de apoyo, un lenguaje y una estructura claros y comprensibles, incluidos, entre otros, el título, un resumen, el motivo de la propuesta y los enlaces de apoyo pertinentes, son indicadores de una justificación suficiente. +5. Las propuestas de Acciones de gobierno incluirán una URL y un resumen de hash derivado del contenido apuntado por la URL. Una Acción solo se considerará constitucional si su contenido puede verificarse de forma independiente para obtener el mismo resumen de hash. +6. Las Acciones de gobierno para el Inicio de una bifurcación dura y el cambio de parámetros de protocolo se someterán a una revisión y escrutinio técnicos suficientes, tal y como se establece en las Barreras de seguridad. Dichas Acciones de gobierno no podrán poner en peligro la seguridad, funcionalidad o rendimiento de la Cadena de bloques Cardano. +7. Las Acciones de gobierno propuestas deberán ser votadas por los Órganos de gobierno correspondientes para ser ratificadas y posteriormente promulgadas dentro de la cadena, según proceda. +8. Las Acciones informativas serán votadas por los DRep, los SPO y el Comité constitucional. Las Acciones informativas no tendrán otro efecto que el de registrar el resultado de dicha votación en la Cadena de bloques Cardano. Las Acciones de gobierno informativas son expresiones del sentimiento de la Comunidad de Cardano y no requieren un resultado de «Sí» para su aprobación. + +### Sección 4: Votación + +1. Las decisiones sobre las Acciones de gobierno propuestas serán tomadas por el Comité constitucional, los SPO y los DRep a través del proceso de votación de acuerdo con los requisitos de esta Constitución y las Barreras de seguridad. +2. Los DRep y los SPO tendrán derechos de voto proporcionales a los Lovelace que se les hayan delegado. Un Lovelace equivaldrá a un voto. +3. Los miembros del Comité constitucional dispondrán de un voto cada uno. +4. Los votos podrán emitirse como «Sí», «No» o «Abstención». + +### Sección 5: Umbrales de votación y quorum + +1. Los umbrales de votación para cada Órgano de gobierno en vigor en la fecha de la primera edición de esta Constitución se han establecido en el archivo de génesis de Conway y pueden modificarse mediante una Acción de gobierno de actualización de parámetros de protocolo. Dicha Acción de gobierno de actualización de parámetros de protocolo no constituirá una modificación de la presente Constitución. +2. Los umbrales de votación no podrán situarse fuera de los intervalos siguientes: + - **Comité constitucional**: Las votaciones de todas las Acciones de gobierno se aprobarán en un umbral fijado entre el 51 % y el 100 %. En la fecha de la primera publicación de la presente Constitución, dicho umbral es del 66,67 % de los miembros del Comité constitucional. + - **DRep y SPO**: Rangos de umbrales de votación tal y como se especifica en las «Barreras de seguridad de los umbrales de votación» en 3.6.4 de las Barreras de seguridad. +3. El umbral de votación actual aplicable a una Acción de gobierno por parte de un Órgano de gobierno en particular puede encontrarse consultando los parámetros actualmente implementados dentro de la cadena. +4. Además de la votación del Comité constitucional cuando así lo exija la presente Constitución, se aplicarán los siguientes quorum a las Acciones de gobierno: + - Los cambios de parámetros requerirán un voto afirmativo de los SPO y un voto afirmativo de los DRep para su aprobación. + - Los Inicios de bifurcación dura requerirán un voto afirmativo de los SPO y un voto afirmativo de los DRep para su aprobación. + - Las mociones de censura y las actualizaciones de los comités/umbrales requerirán un voto afirmativo de los SPO y un voto afirmativo de los DRep para su aprobación. + - Las retiradas de Tesorería requerirán el voto afirmativo de los DRep para su aprobación. + - Las Acciones de gobierno informativas requerirán un voto de SPO y un voto de DRep; sin embargo no se requerirá ningún resultado ya que estas Acciones de gobierno se utilizan solo para medir y registrar la opinión de la Comunidad de Cardano. + - Las enmiendas constitucionales requerirán un voto afirmativo de los DRep para su aprobación. +5. Todas las demás Acciones de gobierno requerirán el voto afirmativo de los DRep para su aprobación. + +## ARTÍCULO VI. LA COMUNIDAD DE CARDANO + +1. No se exigirá a los miembros de la Comunidad de Cardano ninguna afiliación formal para participar en el Ecosistema de Cardano y en el gobierno de la Cadena de bloques Cardano. +2. Se espera que los miembros de la Comunidad de Cardano apoyen y defiendan las disposiciones de esta Constitución y resuelvan las disputas de manera justa, constructiva y transparente. +3. La Comunidad de Cardano apoyará la creación, el mantenimiento y la administración continua de los procesos de gobierno fuera de la cadena que puedan ser necesarios para dar efecto a esta Constitución y garantizar que exista conciencia y haya una oportunidad de debatir y dar forma a las Acciones de gobierno para la Cadena de bloques Cardano. +4. Se anima a la Comunidad a colaborar en el desarrollo, mantenimiento y creación de aplicaciones para la Cadena de bloques Cardano. + +## ARTÍCULO VII. COMITÉ CONSTITUCIONAL + +### Sección 1: Función del Comité constitucional y participación + +1. El Comité constitucional se crea como órgano independiente para garantizar que todas las Acciones de gobierno propuestas sean coherentes con las disposiciones de esta Constitución antes de que se voten y apliquen. +2. Ninguna Acción de gobierno que no sea una «moción de censura» o una «actualización del Comité constitucional/umbral» podrá aplicarse dentro de la cadena a menos que el Comité constitucional haya confirmado previamente mediante una votación dentro de la cadena que dicha propuesta no infringe la presente Constitución. + +### Sección 2: Composición del Comité constitucional + +1. Los miembros del Comité constitucional se compondrán de un número especificado por la Constitución de Cardano, que en cualquier caso será un número impar, no inferior a 3 y no superior a 9, para evitar los empates en las votaciones del Comité constitucional. Deberán tener los conocimientos técnicos o de gobierno necesarios para garantizar el cumplimiento de esta Constitución. +2. El mandato de los miembros del Comité constitucional se ajustará a la Constitución. +3. Para garantizar la continuidad en el funcionamiento del Comité constitucional, los mandatos de sus miembros serán escalonados. + +### Sección 3: Elección de los miembros del Comité constitucional + +1. La Comunidad de Cardano establecerá y publicará cada cierto tiempo un proceso para la elección de los miembros del Comité constitucional coherente con los requisitos de las Barreras de seguridad. +2. Si no se elige un nuevo Comité constitucional antes de que finalice el mandato del Comité constitucional en funciones, o si el Comité constitucional no cumple en algún momento los requisitos de la Sección 3(1) anterior, el Comité constitucional en funciones presentará una Acción de gobierno para elegir a los nuevos miembros que sean necesarios para sustituir a los miembros salientes o alcanzar el número exigido de miembros. + +### Sección 4: Estado de censura + +El Comité constitucional se encontrará en todo momento en uno de los dos estados siguientes: estado de confianza o estado de censura. En un estado de censura, los miembros del Comité constitucional en funciones deberán ser restituidos o sustituidos mediante la Acción de gobierno «Actualizar comité/umbral» antes de que pueda llevarse a cabo cualquier otra Acción de gobierno dentro de la cadena. + +### Sección 5: Votaciones y conducta del Comité constitucional + +1. Los miembros del Comité constitucional publicarán información razonable sobre sus procesos y también se publicará cada decisión tomada. +2. Cada miembro del Comité constitucional dispondrá de un voto. +3. Al rechazar una Acción de gobierno, cada miembro del Comité constitucional expondrá los motivos de su voto, incluyendo referencias a las disposiciones aplicables de la presente Constitución. +4. Los miembros del Comité constitucional podrán hacer recomendaciones a la Comunidad de Cardano para mejorar las propuestas que hayan rechazado. +5. El Comité constitucional establecerá y publicará para sí mismo un código de conducta y adoptará las políticas y procedimientos, incluidas cualesquiera directrices éticas, que el Comité constitucional considere necesarios. + +### Sección 6: Apoyo de la Comunidad + +La Comunidad de Cardano apoyará la creación, el mantenimiento y la administración permanente de las herramientas que sean necesarias y apropiadas para que el Comité constitucional desempeñe sus funciones constitucionales. + +### Sección 7: Remuneración + +Los miembros del Comité constitucional podrán recibir una remuneración por su función como miembros del mismo, siempre que dicha remuneración esté prevista en el Presupuesto de Cardano, sea pública y su importe se limite a cubrir los costes reales y razonables en los que incurran en el desempeño de su función. + +## ARTÍCULO VIII. REPRESENTANTES DELEGADOS + +### Sección 1: Función de gobierno de los DRep + +1. Los Titulares de ada podrán votar directamente con respecto a las Acciones de gobierno registrándose ellos mismos como DRep o delegando sus derechos de voto en otros DRep registrados. +2. Los DRep tendrán un poder de voto igual al número de Lovelace que se les haya delegado. +3. Se anima a los DRep a aprobar, publicar y mantener códigos de conducta, incluidas directrices éticas, que rijan sus actividades como tales. + +### Sección 2: Registro de los DRep + +1. Cualquier Titular de ada podrá inscribirse como DRep. Un DRep podrá actuar en interés de uno o varios Titulares de ada. +2. Cualquier Titular de ada podrá delegar su derecho de voto en uno o varios DRep registrados, incluido él mismo. +3. Los Titulares de ada podrán cambiar la delegación de su participación en las votaciones en cualquier momento. + +### Sección 3: Selección de los DRep + +Se espera que la Comunidad de Cardano apoye la creación, el mantenimiento y la administración continua de herramientas que permitan a los Titulares de ada seleccionar DRep delegar su voto. + +### Sección 4: Remuneración de los DRep + +Los DReps podrán ser remunerados por sus esfuerzos. Deberán revelar públicamente cualquier remuneración que reciban en relación con sus actividades como tales. + +## ARTÍCULO IX. OPERADORES DE GRUPOS DE PARTICIPACIONES + +### Sección 1: Función de gobierno de los SPO + +1. Los SPO funcionarán como un control adicional en determinadas Acciones de gobierno, en las que votarán por separado de los DRep, tal y como se establece en las Barreras de seguridad. +2. Los SPO informarán públicamente si votan simultáneamente como DRep sobre las mismas Acciones de gobierno. + +### Sección 2: Inicio de bifurcación dura + +1. Como operadores de los nodos de la Cadena de bloques Cardano, los SPO votarán en el proceso de Inicio de bifurcación dura de acuerdo con esta Constitución y las Barreras de seguridad. +2. Los SPO deberán considerar la disponibilidad de la Cadena de bloques Cardano cuando emitan sus votos sobre el Inicio de la bifurcación dura. + +## ARTÍCULO X. LÍMITE DE CAMBIO NETO, PRESUPUESTO DE CARDANO Y RETIRADAS DE TESORERÍA + +### Sección 1: Importe límite de cambio neto + +1. Cualquier miembro de la Comunidad de Cardano podrá proponer un Importe límite de cambio neto para cada período presupuestario posterior a la Acción de gobierno anterior que haya establecido el Importe límite de cambio neto anterior. +2. Los Importes límite de cambio neto se propondrán como una Acción de gobierno informativa y se someterán a votación de acuerdo con los umbrales aplicables. Los DRep aprobarán un Importe límite de cambio neto para cada Periodo de límite de cambio neto. +3. Si no se aprueba un nuevo Importe límite de cambio neto para un Periodo de límite de cambio neto, seguirá aplicándose el Importe límite de cambio neto anterior. + +### Sección 2: Presupuesto de Cardano + +1. El Presupuesto de Cardano incluye los recursos razonablemente necesarios para las operaciones en curso, el mantenimiento y el desarrollo de la Cadena de bloques Cardano para cada Período límite de cambio neto. +2. El Presupuesto de Cardano también podrá incluir los recursos razonablemente necesarios para la administración, la gestión, la contratación, la auditoría de terceros y la garantía de dichos cargos, así como la organización del gobierno de Cardano, incluida la remuneración de los miembros del Comité constitucional. +3. La Comunidad de Cardano propondrá un Presupuesto de Cardano para cada Período límite de cambio neto, que adoptará la forma de una Acción de gobierno informativa y estará sujeto a votación de conformidad con los umbrales aplicables. +4. Cualquier miembro de la Comunidad de Cardano, incluidos los Órganos colaborativos que puedan formar los miembros de la Comunidad de Cardano, podrá proponer un Presupuesto de Cardano. +5. El importe total del Presupuesto de Cardano no podrá superar el Importe límite de cambio neto aplicable para el Periodo límite de cambio neto correspondiente. + +### Sección 3: Retiradas de Tesorería + +1. Con sujeción a los requisitos establecidos en esta Constitución y en las Barreras de seguridad, cualquier persona podrá proponer una Acción de gobierno de retirada de Tesorería de Cardano. +2. No se permitirá ninguna Acción de gobierno de retirada de la Tesorería de Cardano a menos que se haya aprobado un Presupuesto de Cardano y esté en vigor un límite de cambio neto. +3. Ningún ada retirado para el Presupuesto de Cardano se delegará en los DRep y SPO ni se utilizará de otro modo para influir en el gobierno de la Cadena de bloques Cardano. Esto no será de aplicación a otras retiradas de Tesorería de Cardano. +4. Cualquier ada retirado en virtud de una Acción de gobierno de retirada de Tesorería de Cardano se utilizará exclusivamente para el fin declarado en la Acción de gobierno. +5. Cualquier ada retirado a través de una retirada de Tesorería de Cardano será administrado y gestionado de conformidad con las prácticas óptimas del sector financiero. From d0822630825bd2264b116d70c6604ee5474b0b73 Mon Sep 17 00:00:00 2001 From: rwiley <30681834+Cerkoryn@users.noreply.github.com> Date: Thu, 28 Nov 2024 08:19:48 -0500 Subject: [PATCH 16/17] Add Phil Lewis draft --- CommunityDrafts/PhilLewis.md | 1014 ++++++++++++++++++++++++++++++++++ CommunityDrafts/README.md | 2 +- 2 files changed, 1015 insertions(+), 1 deletion(-) create mode 100644 CommunityDrafts/PhilLewis.md diff --git a/CommunityDrafts/PhilLewis.md b/CommunityDrafts/PhilLewis.md new file mode 100644 index 0000000..68ccf0c --- /dev/null +++ b/CommunityDrafts/PhilLewis.md @@ -0,0 +1,1014 @@ +# CARDANO BLOCKCHAIN CONSTITUTION +## PREAMBLE +This Constitution serves to define the minimum necessary tenets and guardrails required to provide a balance between protecting the integrity of the Cardano blockchain, and the freedoms of the Cardano community wishing to contribute to or utilise the Cardano blockchain. + +## ARTICLE I. CARDANO BLOCKCHAIN TENETS AND GUARDRAILS +### Section 1 + +These below Tenets shall guide all participants of the Cardano community, including the Constitutional Committee, and proposed governance actions shall be evaluated in accordance with these Tenets. The order in which the below Tenets appear is not intended to represent a priority among Tenets. + +**TENET 1** Transactions on the Cardano blockchain shall not be slowed down or censored and shall be expediently served for their intended purpose. + +**TENET 2** The cost of transactions on the Cardano blockchain shall be predictable and not unreasonable. + +**TENET 3** Anyone desiring to develop and deploy applications on the Cardano blockchain shall not unreasonably be prevented from developing and deploying such applications as intended. + +**TENET 4** The Cardano blockchain shall not lock in an ada owner's value without an owner's consent. + +**TENET 5** The Cardano blockchain shall not unreasonably impede interoperability. + +**TENET 6** The Cardano blockchain shall preserve in a safe manner any value and information an ada owner seeks to store on the Cardano blockchain. + +**TENET 7** All users of the Cardano blockchain shall be treated equally, taking into account the collective desires of the Cardano blockchain community, consistent with the long-term sustainability and viability of the Cardano blockchain. + +**TENET 8** Financial stability shall be maintained and the total supply of ada shall not exceed 45,000,000,000 (45,000,000,000,000,000 lovelace). + +### Section 2 + +The Cardano blockchain shall operate in accordance with the Cardano Blockchain Guardrails Appendix. The Cardano community may from time to time digitally codify certain Cardano blockchain guardrails, such that they are directly programmed and implemented on the Cardano blockchain using on-chain scripts or built-in ledger rules. + +In the event there are inconsistencies between a Cardano blockchain guardrail as set forth in the Cardano Blockchain Guardrails Appendix and any such Cardano blockchain guardrail that has been programmed and implemented on the Cardano blockchain, the version of such Cardano blockchain guardrail that has been deployed directly on the Cardano blockchain shall prevail and the Constitutional Committee shall seek to reconcile such inconsistencies through the encouragement of an appropriate on-chain governance action. + +## ARTICLE II. THE CARDANO BLOCKCHAIN COMMUNITY +### Section 1 +The Cardano blockchain is permissionless infrastructure that may be used by **anyone** in accordance with how it is intended to operate at any given moment, noting that its function may change over time following governance actions to enact changes in accordance with the governance process described in this Constitution. + +## ARTICLE III. PARTICIPATORY AND DECENTRALIZED GOVERNANCE +### Section 1 +The Cardano blockchain shall be governed by a decentralised, on-chain governance model, as implemented in the Cardano blockchain software systems at the time of use. +### Section 2 +Three independent governance bodies shall participate in voting for on-chain governance actions, providing the checks and balances necessary to ensure the integrity of the Cardano blockchain, consisting of Delegated Representatives (DReps), Stake Pool Operators (SPOs), and the Constitutional Committee (CC). +### Section 3 +On-chain governance decisions shall be made through a collective decision-making process, with specific consensus threshold requirements as specified in the Cardano Blockchain Guardrails Appendix. +### Section 4 +The description of proposed governance actions are expected to follow a standardized and legible format including a URL and hash linked to documented off-chain content. Sufficient rationale shall be provided to justify the requested change to the Cardano blockchain. +### Section 5 +“Hard Fork Initiation” and “Protocol Parameter Change” governance actions shall undergo sufficient technical review and scrutiny as mandated in the Cardano Blockchain Guardrails Appendix, to ensure that the governance action does not endanger the security, functionality, performance, or long-term sustainability of the Cardano blockchain. On-chain governance actions should address their expected impact on the Cardano blockchain ecosystem. +### Section 6 +"Treasury Withdrawal" governance actions must request either a partial or full amount of a previously approved "Info" governance action that specifies a budget for the ongoing maintenance and future development of the Cardano blockchain. "Info" governance actions relating to a Cardano budget must be approved not less than on an annual basis. + +## ARTICLE IV. DELEGATED REPRESENTATIVES +### Section 1 +In order to participate in governance actions, owners of ada may register as DReps and directly vote on such governance actions or may delegate their voting rights to other registered DReps who shall vote on their behalf. + +## ARTICLE V. STAKE POOL OPERATORS +### Section 1 +Stake Pool Operators (SPOs) shall have a specific role in approving critical on-chain governance actions which require additional oversight and independence, voting separately and independently from DReps as set forth in the Cardano Blockchain Guardrails Appendix. SPOs shall participate in hard fork initiation processes as the operators of the nodes that participate in Cardano blockchain’s consensus mechanism. +### Section 2 +SPOs shall act as a check on the power of the Constitutional Committee under exceptional circumstances by separately voting on "Motion of no-confidence" and "Update committee/threshold" governance actions, and on “Parameter Update” governance actions that affect security-critical parameters. + +## ARTICLE VI. CONSTITUTIONAL COMMITTEE +### Section 1 +A Constitutional Committee shall be established in accordance with the Cardano Blockchain Guardrails Appendix, as a set of owners of ada, who are collectively responsible for ensuring that prior to enactment on-chain, governance actions are constitutional. + +### Section 2 +No governance action, other than a "Motion of no-confidence," or "Update constitutional committee/threshold" may be implemented on-chain unless a requisite percentage as specified by the guardrails of the members of the Constitutional Committee shall have first determined and affirmed through an on-chain action that such proposal does not violate this Constitution. + +### Section 3 +The Constitutional Committee shall be considered to be in one of the following two states at all times: a state of confidence or a state of no-confidence. In a state of no-confidence, members of the then standing Constitutional Committee must be reinstated or replaced using the "Update committee/threshold" governance action before any other on-chain governance action, other than “Info” actions, may go forward. + +If deemed necessary, an individual member of the Constitutional Committee may be removed following the enactment of an on-chain governance action in accordance with the Cardano Blockchain Guardrails Appendix. + +### Section 4 +Constitutional Committee processes shall be transparent. The Constitutional Committee shall publish each decision, either collectively or as individual voting members, with a rationale and references to specific Articles of this Constitution or provisions of the Guardrails Appendix used to justify the decision. + +## ARTICLE VII. AMENDMENTS +### Section 1 +Except as otherwise so provided in the Cardano Blockchain Guardrails Appendix, amendments to this Constitution, including to the Cardano Blockchain Guardrails Appendix, shall be approved by a collective decision-making process, requiring an on-chain governance action by owners of ada satisfying a threshold of not less than 67% of the then active voting stake. + +### Section 2 +If the Cardano Blockchain Guardrails Appendix sets forth an amendment threshold for a Cardano blockchain guardrail that is different than the amendment threshold contained in Section 1 of this Article VII, then the threshold set forth in the Cardano Blockchain Guardrails Appendix for such Cardano blockchain guardrail shall apply. + +## APPENDIX I: CARDANO BLOCKCHAIN GUARDRAILS +### 1. INTRODUCTION + +To implement Cardano blockchain on-chain governance, it is necessary to establish sensible guardrails that will enable the Cardano blockchain to continue to operate in a secure and sustainable way. + +This Appendix sets forth guardrails that must be applied to Cardano blockchain on-chain governance actions, including changes to the protocol parameters and limits on treasury withdrawals. These guardrails cover both essential, intrinsic limits on settings, and recommendations that are based on experience, measurement and governance objectives. + +These guardrails are designed to avoid unexpected problems with the operation of the Cardano blockchain. They are intended to guide the choice of sensible parameter settings and avoid potential problems with security, performance, functionality or long-term sustainability. As described below, some of these guardrails are automatable and will be enforced via an on-chain script or built-in ledger rules. + +These guardrails apply only to the Cardano blockchain Layer 1 mainnet environment. They are not intended to apply to test environments or to other blockchains that use the Cardano blockchain software. + +Not all parameters for the Cardano blockchain can be considered independently. Some parameters interact with other settings in an intrinsic way. Where known, these interactions are addressed in this Appendix. + +While the guardrails in this Appendix presently reflect the current state of technical insight, this Appendix should be treated as a living document. Implementation improvements, new simulations or performance evaluation results for the Cardano blockchain may allow some of the restrictions contained in these guardrails to be relaxed (or, in some circumstances, require them to be tightened) in due course. + +Additional guardrails may also be needed where, for example, new protocol parameters are introduced. + +#### Amending, Adding or Deprecating Guardrails +The guardrails set forth in this Appendix may be amended from time to time pursuant to an on chain governance action that satisfies the applicable voting threshold as set forth in this Appendix. Any such amendment to any guardrails shall require and be deemed to be an amendment to the Constitution itself, including any new guardrails. Each guardrail has a unique label. If the text of a guardrail is amended, the existing guardrail will be deprecated and a new label will be used in this Appendix. Similarly, if a guardrail is completely deprecated, its label will never be reused in the future. In all cases, the guardrails that apply to a governance action will be those in force at the time that the governance action is submitted on chain, regardless of any later amendments. + +#### Terminology and Guidance + +**Should/Should not.** Where this Appendix says that a value "should not" be set below or above some value, this means that the guardrail is a recommendation or guideline, and the specific value could be open to discussion or alteration by a suitably expert group recognized by the Cardano community in light of experience with the Cardano blockchain governance system or the operation of the Cardano blockchain. + +**Must/Must not.** Where this Appendix says that a value “must” or "must not" be set below or above some value, this means that the guardrail is a requirement that will be enforced by Cardano blockchain ledger rules, types or other built-in mechanisms where possible, and that if not followed could cause a protocol failure,security breach or other undesirable outcome. + +**Benchmarking.** Benchmarking refers to careful system level performance evaluation that is designed to show a-priori that, for example, 95% of blocks will be diffused across a global network of Cardano blockchain nodes within the required 5s time interval in all cases. This may require construction of specific test workflows and execution on a large test network of Cardano blockchain nodes, simulating a global Cardano blockchain network. + +**Performance analysis.** Performance analysis refers to projecting theoretical performance,empirical benchmarking or simulation results to predict actual system behavior. For example,performance results obtained from tests in a controlled test environment (such as a collection of data centers with known networking properies) may be extrapolated to inform likely performance behavior in a real Cardano blockchain network environment. + +**Simulation.** Simulation refers to synthetic execution that is designed to inform performance/functionality decisions in a repeatable way. For example, the IOSim Cardano blockchain module allows the operation of the networking stack to be simulated in a controlled and repeatable way, allowing issues to be detected before code deployment. + +**Performance Monitoring.** Performance monitoring involves measuring the actual behavior of the Cardano blockchain network, for example, by using timing probes to evaluate round-trip times, or test blocks to assess overall network health. It complements benchmarking and performance analysis by providing information about actual system behavior that cannot be obtained using simulated workloads or theoretical analysis. + +**Reverting Changes.** Where performance monitoring shows that actual network behavior following a change is inconsistent with the performance requirements for the Cardano blockchain, then the change must be reverted to its previous state if that is possible.For example,if the block size is increased from 100KB to 120KB and 95% of blocks areno longer diffused within 5s, then a change must be made to revert the block size to 100KB. If this is not possible, then one or more alternative changes must be made that will ensure that the performance requirements are met. + +**Severity Levels.** Issues that affect the Cardano blockchain network are classified by severity level, where: + +* Severity 1 is a critical incident or issue with very high impact to the security,performance, functionality or long-term sustainability of the Cardano blockchain network +* Severity 2 is a major incident or issue with significant impact to the security,performance, functionality or long-term sustainability of the Cardano blockchain network +* Severity 3 is a minor incident or issue with low impact to the security,performance,functionality or long-term sustainability of the Cardano blockchain network + +**Future Performance Requirements.** Planned development such as new mechanisms for out of memory storage may impact block diffusion or other times. When changing parameters, it is necessary to consider these future performance requirements as well as the current operation of the Cardano blockchain. Until development is complete, the requirements will be conservative but may then be relaxed to account for actual timing behavior. + +#### Automated Checking ("Guardrails Script") + +A script hash is associated with the constitution hash when a **New Constitution or Guardrails Script** governance action is enacted. It acts as an additional safeguard to the ledger rules and types,filtering non-compliant governance actions. + +The guardrails script only affects two types of governance actions: + +* **Parameter Update** actions, and +* **Treasury Withdrawal** actions. + +The script is executed when either of these types of governance action is submitted on-chain.This avoids scenarios where, for example, an erroneous script could prevent the chain from ever enacting a Hard Fork action, resulting in deadlock. There are three different situations that apply to script usage. + +#### Symbol and Explanation + +* (y) The script can be used to enforce the guardrail. +* (x) The script cannot be used to enforce the guardrail. +* (~-reason) The script cannot be used to enforce the guardrail for the reason given,but future ledger changes could enable this. + +Guardrails may overlap: in this case, the most restrictive set of guardrails will apply. + +Where a parameter is not explicitly listed in this document, then the script **must not** permits any changes to the parameter. + +Conversely,where a parameter is explicitly listed in this document but no checkable guardrails are specified, the script **must not** imposes any constraints on changes to the parameter. + +### 2. GUARDRAILS AND GUIDELINES ON PROTOCOL PARAMETER UPDATE ACTIONS + +Below are guardrails and guidelines for changing updatable protocol parameter settings via the protocol parameter update governance action such that the Cardano blockchain is never in an unrecoverable state as a result of such changes. + +Note that, to avoid ambiguity, this Appendix uses the parameter name that is used in protocol parameter update governance actions rather than any other convention. + +#### Guardrails + +PARAM-01 (y) Any protocol parameter that is not explicitly named in this document **must not** be changed by a Parameter update governance action + +PARAM-02 (y) Where a protocol parameter is explicitly listed in this document but no checkable guardrails are specified, the guardrails script **must not** impose any constraints on changes to the parameter. Checkable guardrails are shown by a (y) + +#### 2.1. Critical Protocol Parameters + +The below protocol parameters are critical from a security point of view. + +##### Parameters that are Critical to the Operation of the Blockchain + +* *maximum block body size*(*maxBlockBodySize*) +* *maximum transaction size* (*maxTxSize*) +* *maximum block header size* (*maxBlockHeaderSize*) +* *maximum size of a serialized asset value* (*maxValueSize*) +* *maximum script execution/memory units in a single block* (*maxBlockExecutionUnits[steps/memory]*) +* *minimum fee coefficient*(*txFeePerByte*) +* *minimum fee constant*(*txFeeFixed*) +* *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*) +* *minimum Lovelace deposit per byte of serialized UTxO* (*utxoCostPerByte*) +* *governance action deposit* (*govDeposit*) + +##### Guardrails + +PARAM-03 (y) Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs **must** say "yes" with a collective support of more than 50% of all active block production stake. This is enforced by the guardrails on the stake pool voting threshold. + +PARAM-04 (x) At least 3 months **should** normally pass between the publication of an off-chain proposal to change a critical protocol parameter and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation. + +##### Parameters that are Critical to the Governance System + +* *delegation key Lovelace deposit* (*stakeAddressDeposit*) +* *pool registration Lovelace deposit* (*stakePoolDeposit*) +* *minimum fixed rewards cut for pools* (*minPoolCost*) +* *DRep deposit amount* (*dRepDeposit*) +* *minimal Constitutional Committee size* (*committeeMinSize*) +* *maximum term length (in epochs) for the Constitutional Committee members* (*committeeMaxTermLimit*) + +##### Guardrails + +PARAM-05 (y) DReps **must** vote "yes" with a collective support of more than 50% of all active voting stake. This is enforced by the guardrails on the DRep voting thresholds. + +PARAM-06 (x) At least 3 months **should** normally pass between the publication of an off-chain proposal to change a parameter that is critical to the governance system and the submission of the corresponding on-chain governance action. This guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation. + +#### 2.2. Economic Parameters + +The overall goals when managing economic parameters are to: + +* Enable long-term economic sustainability for the Cardano blockchain ecosystem; +* Ensure that stake pools are adequately rewarded for maintaining the Cardano blockchain; +* Ensure that ada holders are adequately rewarded for using stake in constructive ways,including when delegating ada for block production; and +* Balance economic incentives for different Cardano blockchain ecosystem stakeholders, including but not limited to Stake Pool Operators, ada holders, DeFi users,infrastructure users, developers (e.g. DApps) and financial intermediaries (e.g.exchanges) + +##### Triggers for Change + +* Significant changes in the fiat value of ada resulting in potential problems with security, performance, functionality or long-term sustainability +* Changes in transaction volumes or types +* Community requests or suggestions +* Emergency situations that require changes to economic parameters + +##### Counter-indicators + +Changes to the economic parameters should not be made in isolation. They need to account for: + +* External economic factors +* Network security concerns + +##### Core Metrics + +* Fiat value of ada resulting in potential problems with security,performance, functionality or long-term sustainability +* Transaction volumes and types +* Number and health of stake pools +* External economic factors + +##### Changes to Specific Economic Parameters + +Transaction fee per byte (txFeePerByte) and fixed transaction fee (txFeeFixed) + +Defines the cost for basic transactions in Lovelace: + +*fee(tx) =txFeeFixed+ txFeePerByte x nBytes(tx)* + +##### Guardrails + +TFPB-01 (y) *txFeePerByte* **must not** be lower than 30 (0.000030 ada) + +This protects against low-cost denial of service attacks + +TFPB-02 (y) *txFeePerByte* **must not** exceed 1,000 (0.001 ada) + +This ensures that transactions can be paid for + +TFPB-03 (y) *txFeePerByte* **must not** be negative + +TFF-01 (y) *txFeeFixed* **must not** be lower than 100,000 (0.1 ada) + +This protects against low-cost denial of service attacks + +TFF-02 (y) *txFeeFixed* **must not** exceed 10,000,000(10 ada) + +This ensures that transactions can be paid for + +TFF-03 (y) *txFeeFixed* **must not** be negative. + +TFGEN-01 (x - "should") To maintain a consistent level of protection against denial-of-service attacks, *txFeeFixed* and *txFeePerByte* **should** be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory]). + +TFGEN-02 (x - unquantifiable) Any changes to *txFeeFixed* or *txFeePerByte* **must** consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee so that it becomes impossible to construct a transaction. + +##### UTxO cost per byte (utxoCostPerByte) + +Defines the deposit (in Lovelace) that is charged for each byte of storage that is held in a UTxO.This deposit is returned when the UTxO is no longer active. + +* Sets a minimum threshold on ada that is held within a single UTxO +* Provides protection against low-cost denial of service attack on UTxO storage. +* DoS protection decreases in line with the free node memory (proportional to UTxO growth) +* Helps reduce long term storage costs for node users by providing an incentive to return UTxOs when no longer needed, or to merge UTxOs. + +##### Guardrails + +UCPB-01 (y) *utxoCostPerByte* **must not** be lower than 3,000 (0.003 ada) + +UCPB-02 (y) *utxoCostPerByte* **must not** exceed 6,500 (0.0065 ada) + +UCPB-03 (y) *utxoCostPerByte* **must not** be zero + +UCPB-04 (y) *utxoCostPerByte* **must not** be negative + +UCPB-05a (x -"should") Changes **should** account for + +i) The acceptable cost of attack + +ii) The acceptable time for an attack + +iii) The acceptable memory configuration for full node users + +iv) The sizes of UTxOs and + +v) The current total node memory usage + +##### Stake address deposit (stakeAddressDeposit) + +Ensures that stake addresses are retired when no longer needed + +* Helps reduce long term storage costs +* Helps limit CPU and memory costs in the ledger + +The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Reducing the number of active stake addresses also reduces processing and memory costs at the epoch boundary when calculating stake snapshots. + +##### Guardrails + +SAD-01 (y) *stakeAddressDeposit* **must not** be lower than 1,000,000 (1 ada) + +SAD-02 (y) *stakeAddressDeposit* **must not** exceed 5,000,000 (5ada) + +SAD-03 (y) *stakeAddressDeposit* **must not** be negative + +#### Stake pool deposit (stakePoolDeposit) + +Ensures that stake pools are retired by the stake pool operator when no longer needed by them + +* Helps reduce long term storage costs + +The rationale for the deposit is to incentivize that scarce memory resources are returned when they are no longer required. Rewards and stake snapshot calculations are also impacted by the number of active stake pools. + +##### Guardrails + +SPD-01 (y) *stakePoolDeposit* **must not** be lower than 250,000,000 (250 ada) + +SPD-02 (y) *stakePoolDeposit* **must not** exceed 500,000,000 (500 ada) + +SPD-03 (y) *stakePoolDeposit* **must not** be negative + +#### Minimum Pool Cost (minPoolCost) + +Part of the rewards mechanism + +* The minimum pool cost is transferred to the pool rewards address before any delegator rewards are paid + +##### Guardrails + +MPC-01 (y) *minPoolCost* **must not** be negative + +MPC-02 (y) *minPoolCost* **must not** exceed 500,000,000 (500 ada) + +MPC-03 (x -"should") *minPoolCost* **should** be set in line with the economic cost for operating a pool + +#### Treasury Cut (treasuryCut) + +Part of the rewards mechanism + +The treasury cut portion of the monetary expansion is transferred to the treasury before any pool rewards are paid + +* Can be set in the range 0.0-1.0 (0%-100%) + +##### Guardrails + +TC-01 (y) *treasuryCut* **must not** be lower than 0.1(10%) + +TC-02 (y) *treasuryCut* **must not** exceed 0.3(30%) + +TC-03 (y) *treasuryCut* **must not** be negative + +TC-04 (y) *treasuryCut* **must not** exceed 1.0(100%) + +TC-05 (~-no access to change history) *treasuryCut* **must not** be changed more than once in any 36 epoch period (approximately 6 months) + +#### Monetary Expansion Rate (monetaryExpansion) + +Part of the rewards mechanism + +* The monetary expansion controls the amount of reserves that is used for rewards each epoch +* Governs the long-term sustainability of Cardano +* The reserves are gradually depleted until no rewards are supplied + +##### Guardrails + +ME-01 (y) *monetaryExpansion***must not** exceed 0.005 + +ME-02 (y) *monetaryExpansion* **must not** be lower than 0.001 + +ME-03 (y) *monetaryExpansion** must not'**be negative + +ME-04 (x - "should") *monetaryExpansion* **should not** be varied by more than +/- 10% in any 73-epoch period (approximately 12 months) + +ME-05 (x- "should") *monetaryExpansion* **should not** be changed more than once in any 36-epoch period (approximately 6 months) + +#### Plutus Script Execution Prices (executionUnitPrices[priceSteps/priceMemory]) + +Define the fees for executing Plutus scripts + +Gives an economic return for Plutus script execution + +Provides security against low-cost DoS attacks + +##### Guardrails + +EIUP-PS-01 (y) *executionUnitPrices[priceSteps]* **must not** exceed 2,000/10,000,000 + +EIUP-PS-02 (y) *executionUnitPrices[priceSteps]* **must not** be lower than 500/10,000,000 + +EIUP-PM-01 (y) *executionUnitPrices[priceMemory]* **must not** exceed 2,000/10,000 + +EIUP-PM-02 (y) *executionUnitPrices[priceMemory]* **must not** be lower than 400 / 10,000. + +EIUP-GEN-01 (x - "similar to") The execution prices **must** be set so that: + +i) the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum sized non-script transaction and + +ii) the cost of executing a transaction with maximum memory units is similar to the cost of a maximum sized non-script transaction + +EIUP-GEN-02 (x - "should") The execution prices **should** be adjusted whenever transaction fees are adjusted (*txFeeFixed/txFeePerByte*). The goal is to ensure that the processing delay is similar for "full" transactions, regardless of their type. + +* This helps ensure that the requirements on block diffusion/propagation times are met. + +#### Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte) + +Defines the cost for using Plutus reference scripts in Lovelace + +##### Guardrails + +MFRS-01 (y) *minFeeRefScriptCoinsPerByte* **must not** exceed 1,000 (0.001 ada). + +* This ensures that transactions can be paid for + +MFRS-02 (y) *minFeeRefScriptCoinsPerByte* **must not** be negative + +MFRS-03 (x - "should") To maintain a consistent level of protection against denial-of-service attacks, *minFeeRefScriptCoinsPerByte* **should** be adjusted whenever Plutus Execution prices are adjusted (*executionUnitPrices[steps/memory]*) and whenever *txFeeFixed* is adjusted + +MFRS-04 (x - unquantifiable) Any changes to *minFeeRefScriptCoinsPerByte'* **must** consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee + +#### 2.3. Network Parameters + +The overall goals when managing the Cardano blockchain network parameters are to: + +1. 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 +2. Balance traffic demands for different user groups, including payment transactions,minters of Fungible/Non-Fungible Tokens, Plutus scripts, DeFi developers, Stake Pool Operators and voting transactions + +##### Triggers for Change + +Changes to network parameters may be triggered by: + +* Measured changes in traffic demands over a 2-epoch period (10 days) +* Anticipated changes in traffic demands +* Community requests + +##### Counter-indicators + +Changes may need to be reversed and/or should not be enacted in the event of: + +* Excessive block propagation delays +* Stake pools being unable to handle traffic volume +* Scripts being unable to complete execution + +##### Core Metrics + +All decisions on parameter changes should be informed by: + +* Block propagation delay profile +* Traffic volume (block size over time) +* Script volume (size of scripts and execution units) +* Script execution cost benchmarks +* Block propagation delay/diffusion benchmarks + +Detailed benchmarking results are required to confirm the effect of any changes on mainnet performance or behavior prior to enactment. The effects of different transaction mixes must be analyzed, including normal transactions, Plutus scripts, and governance actions. + +##### Guardrails + +NETWORK-01 (x - "should") No individual network parameter **should** change more than once per two epochs + +NETWORK-02 (x - "should") Only one network parameter **should** be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits + +Changes to Specific Network Parameters + +#### Block Size (maxBlockBodySize) + +The maximum size of a block,in Bytes. + +##### Guardrails + +MBBS-01 (y) *maxBlockBodySize* ***must not** exceed 122,880 Bytes (120KB) + +MBBS-02 (y) *maxBlockBodySize* **must not** be lower than 24,576 Bytes (24KB) + +MBBS-03a (x-"exceptional circumstances") *maxBlockBodySize* **must not** be decreased, other than in exceptional circumstances where there are potential problems with security, performance, functionality or long-term sustainability + +MBBS-04 (~ no access to existing parameter values) *maxBlockBodySize* **must** be large enough to include at least one transaction (that is, *maxBlockBodySize* **must** be at least *maxTxSize*) + +MBBS-05 (x- "should") *maxBlockBodySize* **should** be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch + +MBBS-06 (x - "should") The block size **should not** induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation, and benchmarking. + +MBBS-07 (x - "unquantifiable") The impact of any change to *maxBlockBodySize* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to *maxBlockBodySize* must also consider future requirements for Plutus script execution (*maxBlockExecutionUnits[steps]*) against the total block diffusion target of 3s with 95% block propagation within 5s. The limit on maximum block size may be increased in the future if this is supported by benchmarking and monitoring results. + +#### TransactionSize(maxTxSize) + +The maximum size of a transaction, in Bytes. + +##### Guardrails + +MTS-01 (y) *maxTxSize* **must not** exceed 32,768 Bytes (32KB) + +MTS-02 (y) *maxTxSize* **must not** be negative + +MTS-03 (~-no access to existing parameter values) *maxTxSize* **must not** be decreased + +MTS-04 (~-no access to existing parameter values) *maxTxSize* **must not** exceed *maxBlockBodySize* + +MTS-05 (x - "should") *maxTxSize* **should not** be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably **should** be increased by 2,048 Bytes (2KB) or less per epoch + +MTS-06 (x - "should") *maxTxSize* **should not** exceed 1/4 of the block size + +#### Memory Unit Limits(maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory]) + +The limit on the maximum number of memory units that can be used by Plutus scripts, either per-transaction or per-block. + +##### Guardrails + +MTEU-M-01 (y) *maxTxExecutionUnits[memory]* **must not** exceed 40,000,000 units + +MTEU-M-02 (y) *maxTxExecutionUnits[memory]* **must not** be negative + +MTEU-M-03 (~ - no access to existing parameter values) *maxTxExecutionUnits[memory]* **must not** be decreased + +MTEU-M-04 (x-"should") *maxTxExecutionUnits[memory]* **should not** be increased by more than 2,500,000 units in any epoch + +MBEU-M-01 (y) *maxBlockExecutionUnits[memory]* **must not** exceed 120,000,000 units + +MBEU-M-02 (y) *maxBlockExecutionUnits[memory]* **must not** be negative + +MBEU-M-03 (x - "should") *maxBlockExecutionUnits[memory]* **should not** be changed (increased or decreased) by more than 10,000,000 units in any epoch + +MBEU-M-04a (x - unquantifiable) The impact of any change to *maxBlockExecutionUnits[memory]* **must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the diffusion/propagation time budgets, as also impacted by *maxBlockExecutionUnits[steps]*. Any increase **must** also consider previously agreed future requirements for the total block size (*maxBlockBodySize*) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements. + +MEU-M-01 (~ - no access to existing parameter values) *maxBlockExecutionUnits[memory]* **must not** be less than *maxTxExecutionUnits[memory]* + +#### CPU Unit Limits (maxBlockExecutionUnits[steps].maxTxExecutionUnits[steps]) + +The limit on the maximum number of CPU steps that can be used by Plutus scripts, either per transaction or per-block. + +##### Guardrails + +MTEU-S-01 (y) *maxTxExecutionUnits[steps]* **must not** exceed 15,000,000,000(15Bn)units + +MTEU-S-02 (y) *maxTxExecutionUnits[steps]* **must not** be negative + +MTEU-S-03 (~- no access to existing parameter values) *maxTxExecutionUnits[steps]* **must not** be decreased + +MTEU-S-04 (x-"should") *maxTxExecutionUnits[steps]* **should not** be increased by more than 500,000,000 (500M) units in any epoch(5 days) + +MBEU-S-01 (y) *maxBlockExecutionUnits[steps]* **must not** exceed 40,000,000,000(40Bn) units + +MBEU-S-02 (y) *maxBlockExecutionUnits[steps]* **must not** be negative + +MBEU-S-03 (x -"should") *maxBlockExecutionUnits[steps]* **should not** be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days) + +MBEU-S-04a (x-unquantifiable) The impact of the change to *maxBlockExecutionUnits[steps]* **1 must** be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by *maxBlockExecutionUnits[memory]* and *maxBlockBodySize*.Any increase **must** also consider previously identified future requirements for the total block size (*maxBlockBodySize*) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block step limit to be increased,but **must** be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements + +MEU-S-01 (~-no access to existing parameter values) *maxBlockExecutionUnits[steps]* **must not** be less than *maxTxExecutionUnits[steps]* + +#### Block Header Size (maxBlockHeaderSize) + +The size of the block header. + +##### Guardrails + +MBHS-01 (y) *maxBlockHeaderSize* **must not** exceed 5,000 Bytes + +MBHS-02 (y) *maxBlockHeaderSize* **must not** be negative + +MBHS-03 (x - "largest valid header" is subject to change) *maxBlockHeaderSize* **must** be large enough for the largest valid header. + +MBHS-04 (x - "should") *maxBlockHeaderSize* **should** only normally be increased if the protocol changes + +MBHS-05 (x - "should") *maxBlockHeaderSize* **should** be within TCP's initial congestion window (3 or 10 MTUs) + +#### 2.4. Technical/Security Parameters + +The overall goals when managing the technical/security parameters are: + +1. Ensure the security of the Cardano network in terms of decentralization, protection against Sybil and 51% attacks and protection against denial of service attacks +2. Enable changes to the Plutus language + +##### Triggers for Change + +* Changes in the number of active SPOs +* Changes to the Plutus language +* Security threats +* Community requests + +##### Counter-indicators + +* Economic concerns, e.g. when changing the number of stake pools + +##### Core Metrics + +* Number of stake pools +* Level of decentralization + +#### Changes to Specific Technical/Security Parameters + +##### Target Number of Stake Pools (stakePoolTargetNum) + +Sets the target number of stake pools + +* The expected number of pools when the network is in the equilibrium state +* Primarily a security parameter, ensuring decentralization by pool division/replication +* Has an economic effect as well as a security affect-economic advice is also required when changing this parameter +* Large changes in this parameter will trigger mass redelegation events + +##### Guardrails + +SPTN-01 (y) *stakePoolTargetNum* **must not** be lower than 250 + +SPTN-02 (y) *stakePoolTargetNum* **must not** exceed 2,000 + +SPTN-03 (y) *stakePoolTargetNum* **must not** be negative + +SPTN-04 (y) *stakePoolTargetNum* **must not** be zero + +#### Pledge Influence Factor (poolPledgeInfluence) + +Enables the pledge protection mechanism + +* Provides protection against Sybil attack +* Higher values reward pools that have more pledge and penalize pools that have less pledge +* Has an economic effect as well as technical effect - economic advice is also required + +##### Guardrails + +PPI-01 (y) *poolPledgeInfluence* **must not** be lower than 0.1 + +PPI-02 (y) *poolPledgeInfluence* **must not** exceed 1.0 + +PPI-03 (y) *poolPledgeInfluence* **must not** be negative + +PPI-04 (x-"should") *poolPledgeInfluence* **should not** vary by more than +/-10% in any 18-epoch period (approximately 3 months) + +#### Pool Retirement Window (poolRetireMaxEpoch) + +Defines the maximum number of epochs notice that a pool can give when planning to retire + +##### Guardrails + +PRME-01 (y) *poolRetireMaxEpoch* **must not** be negative + +PRME-02 (x - "should") *poolRetireMaxEpoch* **should not** be lower than 1 + +#### Collateral Percentage (collateralPercentage) + +Defines how much collateral must be provided when executing a Plutus script as a percentage of the normal execution cost + +* Collateral is additional to fee payments +* If a script fails to execute, then the collateral is lost +* The collateral is never lost if a script executes successfully + +Provides security against low-cost attacks by making it more expensive rather than less expensive to execute failed scripts + +##### Guardrails + +CP-01 (y) *collateralPercentage* **must not** be lower than 100 + +CP-02 (y) *collateralPercentage* **must not** exceed 200 + +CP-03 (y) *collateralPercentage* **must not** be negative + +CP-04 (y) *collateralPercentage* **must not** be zero + +#### Maximum number of collateral inputs (maxCollateralInputs) + +Defines the maximum number of inputs that can be used for collateral when executing a Plutus script + +##### Guardrails + +MCI-01 (y) *maxCollateralInputs* **must not** be lower than 1 + +#### Maximum Value Size (maxValueSize) + +The limit on the serialized size of the Value in each output. + +##### Guardrails + +MVS-01 (y) *max ValueSize* **must not** exceed 12,288 Bytes (12KB) + +MVS-02 (y) *maxValueSize* **must not** be negative + +MVS-03 (~ -no access to existing parameter values) *max ValueSize* **must** be less than *maxTxSize* + +MVS-04 (~ - no access to existing parameter values) *maxValueSize* **must not** be reduced + +MVS-05 (x- "sensible output" is subject to interpretation) *maxValueSize* **must** be large enough to allow sensible outputs (e.g. any existing on-chain output or anticipated outputs that could be produced by new ledger rules) + +#### Plutus Cost Models (costModels) + +Define the base costs for each Plutus primitive in terms of CPU and memory unit + +A different cost model is required for each Plutus version. Each cost model comprises many distinct cost model values. Cost models are defined for each Plutus language version. A new language version may introduce additional cost model values or remove existing cost model values. + +##### Guardrails + +PCM-01 (x-unquantifiable) *Cost model* values **must** be set by benchmarking on a reference architecture + +PCM-02 (x -primitives and language versions aren't introduced in transactions) The *cost model* **must** be updated if new primitives are introduced or a new Plutus language version is added + +PCM-03a (~- no access to *Plutus cost model* parameters) *Cost model* values **should not** normally be negative. Negative values must be justified against the underlying cost model for the associated primitives + +PCM-04 (~ -no access to *Plutus cost model* parameters) A *cost model* **must** be supplied for each Plutus language version that the protocol supports + +#### 2.5. Governance Parameters + +The overall goals when managing the governance parameters are to: + +* Ensure governance stability +* Maintain a representative form of governance + +##### Triggers for Change + +Changes to governance parameters may be triggered by: + +* Community requests +* Regulatory requirements +* Unexpected or unwanted governance outcomes +* Entering a state of no confidence + +##### Counter-indicators + +Changes may need to be reversed and/or should not be enacted in the event of: + +* Unexpected effects on governance +* Excessive Layer 1 load due to on-chain voting or excessive numbers of governance actions + +##### Core Metrics + +All decisions on parameter changes should be informed by: + +* Governance participation levels +* Governance behaviors and patterns +* Regulatory considerations +* Confidence in the governance system +* The effectiveness of the governance system in managing necessary change + +Changes to Specific Governance Parameters + +#### Deposit for Governance Actions (govDeposit) + +The deposit that is charged when submitting a governance action. + +* Helps to limit the number of actions that are submitted + +##### Guardrails + +GD-01 (y) *govDeposit* **must not** be negative + +GD-02 (y) *govDeposit* **must not** be lower than 1,000,000 (1 ada) + +GD-03 (y) *govDeposit* **must not** exceed 10,000,000,000,000 (10 Million ada) + +GD-04 (x - "should") *govDeposit* **should** be adjusted in line with fiat changes + +#### Deposit for DReps (dRepDeposit) + +The deposit that is charged when registering a DRep. + +* Helps to limit the number of active DReps + +###### Guardrails + +DRD-01 (y) *dRepDeposit* **must not** be negative + +DRD-02 (y) *dRepDeposit* **must not** be lower than 1,000,000 (1 ada) + +DRD-03 (y) *dRepDeposit* **must not** exceed 100,000,000,000 (100,000 ada) + +DRD-04 (x- "should") *dRepDeposit* **should** be adjusted in line with fiat changes + +#### DRep Activity Period (dRepActivity) + +The period (as a whole number of epochs) after which a DRep is considered to be inactive for vote calculation purposes, if they do not vote on any proposal. + +##### Guardrails + +DRA-01 (y) *dRepActivity* **must not** be lower than 13 epochs (2 months) + +DRA-02 (y) *dRepActivity* **must not** exceed 37 epochs (6 months) + +DRA-03 (y) *dRepActivity* **must not** be negative + +DRA-04 (~- no access to existing parameter values) *dRepActivity* **must** be greater than *govActionLifetime* + +DRA-05 (x-"should") *dRepActivity* **should** be calculated in human terms (2 months etc) + +#### DRep and SPO Governance Action Thresholds (dRepVotingThesholds[...].poolVotingThresholds(..)) + +Thresholds on the active voting stake that is required to ratify a specific type of governance action by either DReps or SPOs. + +* Ensures legitimacy of the action + +The threshold parameters are listed below: + +*dRepVotingThresholds*: + +* *dvtCommitteeNoConfidence* +* *dvtCommitteeNormal* +* *dvtHardForkInitiation* +* *dvtMotionNoConfidence* +* *dvtPPEconomicGroup* +* *dvtPPGovGroup* +* *dvtPPNetworkGroup* +* *dvtPPTechnicalGroup* +* *dvtTreasuryWithdrawal* +* *dvtUpdateToConstitution* + +*poolVotingThresholds*: + +* *pvtCommitteeNoConfidence* +* *pvtCommitteeNormal* +* *pvtHardForkInitiation* +* *pvtMotionNoConfidence* +* *pvtPPSecurityGroup* + +##### Guardrails + +VT-GEN-01 (y) All thresholds **must** be greater than 50% and less than or equal to 100% + +VT-GEN-02 (y) Economic, network and technical parameter thresholds **must** be in the range 51%-75% + +VT-GEN-03 (y) Governance parameter thresholds **must** be in the range 75%-90% + +VT-HF-01 (y) **Hard fork** action thresholds **must** be in the range 51%-80% + +VT-CON-01 (y) **New Constitution or guardrails script action** thresholds **must** be in the range 65%-90% + +VT-CC-01 (y) **Update Constitutional Committee action** thresholds **must** be in the range 5%-90% + +VT-NC-01(y) **No confidence** action thresholds **must** be in the range 51%-75% + +#### Governance Action Lifetime (govActionLifetime) + +The period after which a governance action will expire if it is not enacted - As a whole number of epochs + +##### Guardrails + +GAL-01 (y) *govActionLifetime* **must not** be lower than 1 epoch (5 days) + +GAL-03 (x - "should") *govActionLifetime* **should not** be lower than 2 epochs (10 days) + +GAL-02 (y) *govActionLifetime* **must not** exceed 15 epochs (75 days) + +GAL-04 (x -"should") *govActionLifetime* **should** be calibrated in human terms (eg 30 days, two weeks), to allow sufficient time for voting etc. to take place + +GAL-05 (~ - no access to existing parameter values) *govActionLifetime* **must** be less than *dRepActivity* + +#### Maximum Constitutional Committee Term (committeeMaxTermLength) + +The limit on the maximum term length that a committee member may serve + +##### Guardrails + +CMTL-01a (y) *committeeMaxTermLength* **must not** be zero + +CMTL-02a (y) *committeeMaxTermLength* **must not** be negative + +CMTL-03a (y) *committeeMaxTermLength* **must not** be lower than 18 epochs (90 days, or approximately 3 months) + +CMTL-04a (y) *committeeMaxTermLength* **must not** exceed 293 epochs (approximately 4 years) + +CMTL-05a (x -"should") *committeeMaxTermLength* **should not** exceed 220 epochs (approximately 3 years) + +#### The minimum size of the Constitutional Committee (committeeMinSize) + +The least number of members that can be included in a Constitutional Committee following a governance action to change the Constitutional Committee. + +##### Guardrails + +CMS-01 (y) *committeeMinSize* **must not** be negative + +CMS-02 (y) *committeeMinSize* **must not** be lower than 3 + +CMS-03 (y) *committeeMinSize* **must not** exceed 10 + +#### 2.6. Monitoring and Reversion of Parameter Changes + +All network parameter changes **must be** monitored carefully for no less than 2 epochs (10 days) + +* Changes **must** be reverted as soon as possible if block propagation delays exceed 4.5s for more than 5% of blocks over any 6 hour rolling window + +All other parameter changes should be monitored + +* The reversion plan **should** be implemented if the overall effect on performance,security, functionality or long-term sustainability is unacceptable. + +A specific reversion/recovery plan **must be** produced for each parameter change. This plan must include: + +* Which parameters need to change and in which ways in order to return to the previous state (or a similar state) +* How to recover the network in the event of disastrous failure + +This plan **should** be followed if problems are observed following the parameter change. Note that not all changes can be reverted. Additional care must be taken when making changes to these parameters. + +#### 2.7. Non-Updatable Protocol Parameters** + +Some fundamental protocol parameters cannot be changed by the Protocol Parameter Update governance action. These parameters can only be changed in a new Genesis file as part of a hard fork. It is not necessary to provide specific guardrails on updating these parameters. + +### 3. GUARDRAILS AND GUIDELINES ON TREASURY WITHDRAWAL ACTIONS + +**Treasury withdrawal** actions specify the destination and amount of a number of withdrawals from the Cardano treasury. + +##### Guardrails + +TREASURY-01a (x) A net change limit for the Cardano Treasury's balance per period of time **must** be agreed by the DReps via an on-chain governance action with a threshold of greater than 50% of the active voting stake + +TREASURY-02 (x) The budget for the Cardano Treasury **must not** exceed the net change limit for the Cardano Treasury's balance per period of time + +TREASURY-03 (x) The budget for the Cardano Treasury **must** be denominated in ada + +TREASURY-04 (x) Treasury withdrawals **must not** be ratified until there is a community approved Cardano budget then in effect pursuant to a previous on-chain governance action agreed by the DReps with a threshold of greater than 50% of the active voting stake + +### 4. GUARDRAILS AND GUIDELINES ON HARD FORK INITIATION ACTIONS + +The **hard fork initiation** action requires both a new major and a new minor protocol version to be specified. + +* As positive integers + +As the result of a hard fork, new updatable protocol parameters may be introduced. Guardrails may be defined for these parameters, which will take effect following the hard fork. Existing updatable protocol parameters may also be deprecated by the hard fork, in which case the guardrails become obsolete for all future changes. + +##### Guardrails + +HARDFORK-01 (~- no access to existing parameter values) The major protocol version **must** be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version **must** be zero + +HARDFORK-02a (~- no access to existing parameter values) Unless the major protocol version is also changed, the minor protocol version **must** be greater than the minor version that will be enacted immediately prior to this change + +HARDFORK-03(~-no access to existing parameter values) At least one of the protocol versions (major or minor or both) **must** change + +HARDFORK-04 (x) At least 85% of stake pools by active stake **should** have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version + +HARDFORK-05 (x) Any new updatable protocol parameters that are introduced with a hard fork **must** be included in this Appendix and suitable guardrails defined for those parameters + +HARDFORK-06 (x) Settings for any new protocol parameters that are introduced with a hard fork **must** be included in the appropriate Genesis file + +HARDFORK-07 (x) Any deprecated protocol parameters **must** be indicated in this Appendix + +HARDFORK-08 (~- no access to *Plutus cost model* parameters) New Plutus versions **must** be supported by a version-specific *Plutus cost model* that covers each primitive that is available in the new Plutus version + +### 5. GUARDRAILS AND GUIDELINES ON UPDATE CONSTITUTIONAL + +#### COMMITTEE OR THRESHOLD ACTIONS + +**Update Constitutional Committee or Threshold** governance actions may change the size,composition or required voting thresholds for the Constitutional Committee. + +##### Guardrails + +UPDATE-CC-01a (x) **Update Constitutional Committee and/or threshold** **and/or term** governance actions **must not** be ratified until ada holders have ratified through an on-chain governance action this Constitution + +### 6. GUARDRAILS AND GUIDELINES ON NEW CONSTITUTION OR GUARDRAILS SCRIPT ACTIONS + +New constitution or guardrails script actions change the hash of the on-chain constitution and the associated guardrails script. + +#### Guardrails + +NEW-CONSTITUTION-01a (x) A **New Constitution** **or Guardrails Script** governance action **must** be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action + +NEW-CONSTITUTION-02(x) If specified, the new guardrails script must be consistent with this Constitution + +### 7. GUARDRAILS AND GUIDELINES ON NO CONFIDENCE ACTIONS + +**No confidence** actions signal a state of no confidence in the governance system. No guardrails are imposed on **No Confidence** actions. + +#### Guardrails + +* None + +### 8. GUARDRAILS AND GUIDELINES ON INFO ACTIONS + +**Info** actions are not enacted on-chain. No guardrails are imposed on **Info** actions. + +#### Guardrails + +* None + +### 9. LIST OF PROTOCOL PARAMETER GROUPS + +The protocol parameters are grouped by type, allowing different thresholds to be set for each group. + +The network group consists of: + +* *maximum block body size* (*maxBlockBodySize*) +* *maximum transaction size*(*maxTxSize*) +* *maximum block header size* (*maxBlockHeaderSize*) +* *maximum size of a serialized asset value* (*maxValueSize*) +* *maximum script execution units in a single transaction* (*maxTxExecutionUnits[steps]*) +* *maximum script execution units in a single block* (*maxBlockExecutionUnits[steps]*) +* *maximum number of collateral inputs* (*maxCollateralInputs*) + +The economic group consists of: + +* *minimum fee coefficient* (*txFeePerByte*) +* *minimum fee constant* (*txFeeFixed*) +* *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*) +* *delegation key Lovelace deposit* (*stakeAddressDeposit*) +* *pool registration Lovelace deposit*(*stakePoolDeposit*) +* *monetary expansion*(*monetaryExpansion*) +* *treasury expansion* (*treasuryCut*) +* *minimum fixed rewards cut for pools* (*minPoolCost*) +* *minimum Lovelace deposit per byte of serialized UTxO* (*coinsPerUTxOByte*) +* *rices of Plutus execution units* (*executionUnitPrices[priceSteps/priceMemory]*) + +The technical group consists of: + +* *pool pledge influence*(*poolPledgeInfluence*) +* *pool retirement maximum epoch* (*poolRetireMaxEpoch*) +* *desired number of pools* (*stakePoolTargetNum*) +* *Plutus execution cost models* (*costModels*) +* *proportion of collateral needed for scripts* (*collateralPercentage*) + +The governance group consists of: + +* *governance voting thresholds* (*dRepVotingThresholds[...], poolVotingThresholds[...]*) +* *governance action maximum lifetime in epochs* (*govActionLifetime*) +* *governance action deposit* (*govActionDeposit*) +* *DRep deposit amount* (*dRepDeposit*) +* *DRep activity period in epochs* (*dRepActivity*) +* *minimal constitutional committee size* (*committeeMinSize*) +* *maximum term length (in epochs) for the constitutional committee members* (*committeeMaxTermLength*) \ No newline at end of file diff --git a/CommunityDrafts/README.md b/CommunityDrafts/README.md index 1bdb57a..4d87dc7 100644 --- a/CommunityDrafts/README.md +++ b/CommunityDrafts/README.md @@ -9,4 +9,4 @@ Below are links to various alternate community drafts of the Cardano Constitutio - [Jane's Version](https://docs.google.com/document/u/0/d/1ZHPSvXKfZKSCzeZFshMMqL_9SWg3X-58DHkKXn0h3xU/mobilebasic) - [Alfonso Spencer's Version](https://x.com/AlfonsoSpencer9/status/1853342796666515527) - [Attonasi's Version](https://x.com/Attonasi/status/1858879911068303499) -- [ChatGPT's Version](https://x.com/adamKDean/status/1859795419427225689) +- [Phil Lewis's Version](https://github.com/phillewis/cardano-constitution/blob/main/phillewis/phillewis-draft-constitution.md) From a3d9a09f55dc7373bf0e81e95b508a1f6a4f5abc Mon Sep 17 00:00:00 2001 From: rwiley <30681834+Cerkoryn@users.noreply.github.com> Date: Tue, 17 Dec 2024 09:49:43 -0500 Subject: [PATCH 17/17] Add Yuta's 1.0 and 1.1 versions in CSV format --- CommunityDrafts/README.md | 1 + CommunityDrafts/Yuta.csv | 668 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 669 insertions(+) create mode 100644 CommunityDrafts/Yuta.csv diff --git a/CommunityDrafts/README.md b/CommunityDrafts/README.md index 4d87dc7..f80a16c 100644 --- a/CommunityDrafts/README.md +++ b/CommunityDrafts/README.md @@ -10,3 +10,4 @@ Below are links to various alternate community drafts of the Cardano Constitutio - [Alfonso Spencer's Version](https://x.com/AlfonsoSpencer9/status/1853342796666515527) - [Attonasi's Version](https://x.com/Attonasi/status/1858879911068303499) - [Phil Lewis's Version](https://github.com/phillewis/cardano-constitution/blob/main/phillewis/phillewis-draft-constitution.md) +- [Yuta's Version](https://docs.google.com/spreadsheets/d/1v7Hdn9mPsjTUvY7C3hhPJG6J58eGtjCIuc8T-9i08ek/edit?usp=sharing) diff --git a/CommunityDrafts/Yuta.csv b/CommunityDrafts/Yuta.csv new file mode 100644 index 0000000..d178418 --- /dev/null +++ b/CommunityDrafts/Yuta.csv @@ -0,0 +1,668 @@ +Creation policy of v1.1 [Simple version] ,,,, +"The important thing is to respect the Constitution of the Constitutional Convention, not to make any essential changes to it, and to focus only on simplifying it. The aim is not to deny the Constitution of the Constitutional Convention, but to strengthen it by simplifying it.",,,, +1. Carefully correct duplicated and redundant expressions to make them simple. Carefully confirm that there are no changes to the intended content or effect from the version approved by the Constitutional Convention.,,,, +"2. We remove language that we believe will have no practical effect if removed, and we are careful to make sure that no one is harmed by this removal.",,,, +3. No new ideas added. v1.1 will focus on simplification.,,,, +4. We will be ignoring Guardrails and TENET in order to focus on submitting v1.1 for GA in January or February.,,,, +https://docs.google.com/document/d/1o9B3JsYAdTF1ycEkRcAWm_i095Ns7CBd_fxJiU6G0iY/edit?tab=t.0#heading=h.4h2z8okq9vgc,,,, +v1.0,v1.1,,Diff & Reason, +CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION,CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION,TRUE,-,OK +PREAMBLE,PREAMBLE,TRUE,-,OK +"Cardano is a decentralized ecosystem of blockchain technology, smart contracts, and community governance, committed to improving economic, political, and social systems for everyone, everywhere. By offering this foundational infrastructure, Cardano empowers individuals and communities to manage their identity, value and governance, fostering the emergence of decentralized applications, businesses and network states.","Cardano is a decentralized ecosystem of blockchain technology, smart contracts, and community governance, committed to improving economic, political, and social systems for everyone, everywhere. By offering this foundational infrastructure, Cardano empowers individuals and communities to manage their identity, value and governance, fostering the emergence of decentralized applications, businesses and network states.",TRUE,-,OK +"Through unbiased processing of immutable data, we, the participants of the Cardano Community, consisting of individuals, organizations, contributors and others, choose to follow in the footsteps of the early Internet and cryptocurrency pioneers, who first forged bonds of community through digital technologies. We are guided by our shared principles and tenets as we exercise our self-governance by balancing decentralized decision-making with accountability and safeguarding the security of the Cardano Blockchain.","Through unbiased processing of immutable data, we, the participants of the Cardano Community, consisting of individuals, organizations, contributors and others, choose to follow in the footsteps of the early Internet and cryptocurrency pioneers, who first forged bonds of community through digital technologies. We are guided by our shared principles and tenets as we exercise our self-governance by balancing decentralized decision-making with accountability and safeguarding the security of the Cardano Blockchain.",TRUE,-,OK +"Recognizing the need for a more robust and dynamic governance framework, that neither relies nor depends upon traditional nation-state governance systems, but instead relies on self-governance by the Cardano Community, utilizing, wherever possible and beneficial, blockchain technology in the governance process, we hereby establish this Cardano Constitution to govern the Cardano Blockchain ecosystem, ensure the continuity of the Cardano Blockchain, and guard the rights of those who utilize it.","Recognizing the need for a more robust and dynamic governance framework, that neither relies nor depends upon traditional nation-state governance systems, but instead relies on self-governance by the Cardano Community, utilizing, wherever possible and beneficial, blockchain technology in the governance process, we hereby establish this Cardano Constitution to govern the Cardano Blockchain ecosystem, ensure the continuity of the Cardano Blockchain, and guard the rights of those who utilize it.",TRUE,-,OK +"With these purposes in mind, we, the Cardano Community, affirm our intention to abide by this Constitution in order to participate in the governance of the Cardano Blockchain ecosystem. We invite all who share our values to join us but stand not in the way of any who wish to take another path.","With these purposes in mind, we, the Cardano Community, affirm our intention to abide by this Constitution in order to participate in the governance of the Cardano Blockchain ecosystem. We invite all who share our values to join us but stand not in the way of any who wish to take another path.",TRUE,-,OK +ARTICLE I. CARDANO BLOCKCHAIN TENETS AND GUARDRAILS,ARTICLE I. CARDANO BLOCKCHAIN TENETS AND GUARDRAILS,TRUE,-,OK +Section 1,Section 1,TRUE,-,OK +"These below Tenets shall guide all participants of the Cardano Community, including the Constitutional Committee, and proposed governance actions shall be evaluated in accordance with these Tenets. The order in which the below Tenets appear is not intended to represent a priority among Tenets.","These below Tenets shall guide all participants of the Cardano Community, including the Constitutional Committee, and proposed governance actions shall be evaluated in accordance with these Tenets. The order in which the below Tenets appear is not intended to represent a priority among Tenets.",TRUE,-,OK +TENET 1 Transactions on the Cardano Blockchain shall not be slowed down or censored and shall be expediently served for their intended purpose.,TENET 1 Transactions on the Cardano Blockchain shall not be slowed down or censored and shall be expediently served for their intended purpose.,TRUE,-,OK +TENET 2 The cost of transactions on the Cardano Blockchain shall be predictable and not unreasonable.,TENET 2 The cost of transactions on the Cardano Blockchain shall be predictable and not unreasonable.,TRUE,-,OK +TENET 3 Anyone desiring to develop and deploy applications on the Cardano Blockchain shall not unreasonably be prevented from developing and deploying such applications as intended.,TENET 3 Anyone desiring to develop and deploy applications on the Cardano Blockchain shall not unreasonably be prevented from developing and deploying such applications as intended.,TRUE,-,OK +"TENET 4 Contributions by the Cardano Community on the Cardano Blockchain shall be recognized, recorded and assessed fairly through reward sharing with SPOs, potential compensation to DReps and CC members, and appropriate tokenomics.","TENET 4 Contributions by the Cardano Community on the Cardano Blockchain shall be recognized, recorded and assessed fairly through reward sharing with SPOs, potential compensation to DReps and CC members, and appropriate tokenomics.",TRUE,-,OK +TENET 5 The Cardano Blockchain shall not lock in an ada owner's value or data without the owner's consent.,TENET 5 The Cardano Blockchain shall not lock in an ada owner's value or data without the owner's consent.,TRUE,-,OK +TENET 6 The Cardano Blockchain shall not unreasonably impede interoperability.,TENET 6 The Cardano Blockchain shall not unreasonably impede interoperability.,TRUE,-,OK +TENET 7 The Cardano Blockchain shall preserve in a safe manner any value and information stored on the Cardano Blockchain.,TENET 7 The Cardano Blockchain shall preserve in a safe manner any value and information stored on the Cardano Blockchain.,TRUE,-,OK +TENET 8 The Cardano Blockchain shall not unreasonably spend resources.,TENET 8 The Cardano Blockchain shall not unreasonably spend resources.,TRUE,-,OK +"TENET 9 All users of the Cardano Blockchain shall be treated fairly and impartially, taking into account the collective desires of the Cardano Blockchain Community, consistent with the long-term sustainability and viability of the Cardano Blockchain.","TENET 9 All users of the Cardano Blockchain shall be treated fairly and impartially, taking into account the collective desires of the Cardano Blockchain Community, consistent with the long-term sustainability and viability of the Cardano Blockchain.",TRUE,-,OK +"TENET 10 Financial stability shall be maintained and the total supply of ada shall not exceed 45,000,000,000 (45,000,000,000,000,000 lovelace).","TENET 10 Financial stability shall be maintained and the total supply of ada shall not exceed 45,000,000,000 (45,000,000,000,000,000 lovelace).",TRUE,-,OK +Section 2,Section 2,TRUE,-,OK +The Cardano Blockchain shall operate in accordance with the Guardrails for the Cardano Blockchain as set forth in the Cardano Blockchain Guardrails Appendix to this Constitution. The Cardano Community may from time to time digitally codify certain Guardrails such that the Guardrails are directly programmed and implemented on the Cardano Blockchain using on-chain Guardrails Scripts or built-in ledger rules.,The Cardano Blockchain shall operate in accordance with the Guardrails for the Cardano Blockchain as set forth in the Cardano Blockchain Guardrails Appendix to this Constitution. The Cardano Community may from time to time digitally codify certain Guardrails such that the Guardrails are directly programmed and implemented on the Cardano Blockchain using on-chain Guardrails Scripts or built-in ledger rules.,TRUE,-,OK +"In the event there are inconsistencies between a Guardrail as set forth in the Cardano Blockchain Guardrails Appendix and any such Guardrail that has been programmed and implemented on the Cardano Blockchain, the version of such Guardrail that has been deployed directly on the Cardano Blockchain shall prevail unless and until replaced or revised pursuant to an on-chain governance action. The Constitutional Committee shall seek to reconcile such inconsistencies through the encouragement of an appropriate on-chain governance action.","In the event there are inconsistencies between a Guardrail as set forth in the Cardano Blockchain Guardrails Appendix and any such Guardrail that has been programmed and implemented on the Cardano Blockchain, the version of such Guardrail that has been deployed directly on the Cardano Blockchain shall prevail unless and until replaced or revised pursuant to an on-chain governance action. The Constitutional Committee shall seek to reconcile such inconsistencies through the encouragement of an appropriate on-chain governance action.",TRUE,-,OK +ARTICLE II. THE CARDANO BLOCKCHAIN COMMUNITY,ARTICLE II. THE CARDANO BLOCKCHAIN COMMUNITY,TRUE,-,OK +Section 1,Section 1,TRUE,-,OK +"No formal membership shall be required to use, participate in and benefit from the Cardano Blockchain. Instead, all owners of ada, all developers of, all those building on, and all those otherwise supporting, maintaining or using the Cardano Blockchain are considered to be participants in the Cardano Community and are therefore recognized as beneficiaries of the Cardano Blockchain ecosystem. All participants in the Cardano Community are accordingly beneficiaries of this Constitution, entitled to its rights, privileges and protections and, as such, are expected to support and uphold this Constitution.","No formal membership shall be required to use, participate in and benefit from the Cardano Blockchain. Instead, all owners of ada, all developers of, all those building on, and all those otherwise supporting, maintaining or using the Cardano Blockchain are considered to be participants in the Cardano Community and are therefore recognized as beneficiaries of the Cardano Blockchain ecosystem. All participants in the Cardano Community are accordingly beneficiaries of this Constitution, entitled to its rights, privileges and protections and, as such, are expected to support and uphold this Constitution.",TRUE,-,OK +Section 2,Section 2,TRUE,-,OK +"Participants in the Cardano Community who own ada are entitled to access and participate in the on-chain decision-making processes of the Cardano Blockchain ecosystem, including voting and taking part in on-chain governance actions regarding the Cardano Blockchain.","Participants in the Cardano Community who own ada are entitled to access and participate in the on-chain decision-making processes of the Cardano Blockchain ecosystem, including voting and taking part in on-chain governance actions regarding the Cardano Blockchain.",TRUE,-,OK +Section 3,Section 3,TRUE,-,OK +"The Cardano Community has a responsibility to maintain the integrity of the Cardano Blockchain ecosystem by following this Constitution, operating the Cardano Blockchain, participating in Cardano Blockchain governance activities, and resolving disputes in a fair and transparent manner.","The Cardano Community has a responsibility to maintain the integrity of the Cardano Blockchain ecosystem by following this Constitution, operating the Cardano Blockchain, participating in Cardano Blockchain governance activities, and resolving disputes in a fair and transparent manner.",TRUE,-,OK +Section 4,-,FALSE,"This is a right that goes without saying, so there is no problem with deleting it.",OK +"The Cardano Community is entitled and encouraged through the provisions of this Constitution to collaborate in developing, maintaining and building applications for the Cardano Blockchain, and to form temporary and permanent organizations, associations and other entities as the Cardano Community deems desirable or appropriate in support of the Cardano Blockchain ecosystem.",-,FALSE,"This is a right that goes without saying, so there is no problem with deleting it.",OK +ARTICLE III. PARTICIPATORY AND DECENTRALIZED GOVERNANCE,ARTICLE III. PARTICIPATORY AND DECENTRALIZED GOVERNANCE,TRUE,,OK +Section 1,Section 1,TRUE,,OK +"The Cardano Blockchain shall be governed by a decentralized, on-chain governance model, utilizing, to the extent possible and beneficial, smart contracts and other blockchain based tools to facilitate decision-making and ensure transparency. On-chain voting for governance actions shall follow the process outlined in this Constitution, including the Cardano Blockchain Guardrails Appendix. On-chain governance actions shall be effected through a collective decision-making process, with specific consensus threshold requirements, as required by the Cardano Blockchain Guardrails.","The Cardano Blockchain shall be governed by a decentralized, on-chain governance model, utilizing, to the extent possible and beneficial, smart contracts and other blockchain based tools to facilitate decision-making and ensure transparency. On-chain voting for governance actions shall follow the process outlined in this Constitution, including the Cardano Blockchain Guardrails Appendix. On-chain governance actions shall be effected through a collective decision-making process, with specific consensus threshold requirements, as required by the Cardano Blockchain Guardrails.",TRUE,,OK +Section 2,Section 2,TRUE,,OK +"Three independent governance bodies shall participate in voting for on-chain governance actions to provide checks and balances for the Cardano Blockchain, consisting of Delegated Representatives (DReps), Stake Pool Operators (SPOs) and the Constitutional Committee (CC).","Three independent governance bodies shall participate in voting for on-chain governance actions to provide checks and balances for the Cardano Blockchain, consisting of Delegated Representatives (DReps), Stake Pool Operators (SPOs) and the Constitutional Committee (CC).Members who serve in more than one of these three roles shall publicly disclose their participation in on-chain governance activities in more than one capacity before voting on any on-chain governance activity. However, public disclosure is not required for members who are both Constitution Committee members and acting as SPOs but not as DReps.",FALSE,The provisions of ARTICLE VII.Section 9 and ARTICLE VI Section 4 will be consolidated and set forth in ARTICLE III Section 2.,OK +Section 3,Section 3,TRUE,,OK +"All owners of ada shall have the right to vote in on-chain governance decision-making processes, as provided for in this Constitution and the Cardano Blockchain Guardrails Appendix. All owners of ada shall have the right to propose changes to the governance structure of the Cardano Blockchain ecosystem in accordance with the Guardrails. Owners of ada who use third-party custodians or other designees to hold their ada, may authorize or may withhold authorization for, such third-parties to vote on their behalf.","Owners of ada who use third-party custodians or other designees to hold their ada, may authorize, or may withhold authorization for, such third-parties to delegate the voting rights of the ada owner to registered DReps on the owner's behalf or to vote on their behalf.",FALSE,"1)“All owners of ada shall have the right to vote in on-chain governance decision-making processes, as provided for in this Constitution and the Cardano Blockchain Guardrails Appendix.” overlaps with ARTICLE IISection 2 + +2)All owners of ada shall have the right to propose changes to the governance structure of the Cardano Blockchain ecosystem in accordance with the Guardrails. overlaps with ARTICLE VIII. + +3)It would be simpler to combine the following: +ARTICLE III Section 3 +ARTICLE V Section 1 ""Owners of ada who use third-party custodians or other designees to hold their ada, may authorize, or may withhold authorization for, such third-parties to delegate the voting rights of the ada owner to registered DReps on the owner's behalf.""",OK +Section 4,-,FALSE,,OK +"A special form of on-chain governance action, an ""Info"" action, exists to allow the Cardano Community to propose potential future on-chain governance actions and to allow community sentiment to be gauged without committing to any on-chain change to the Cardano Blockchain. Such ""Info"" actions have no on-chain effect other than to record such ""Info"" actions on the Cardano Blockchain. In accordance with Article VII Section 4, ""Info"" actions shall also be used in connection with proposed Cardano Blockchain ecosystem budgets and Cardano Blockchain treasury withdrawals.",-,FALSE,"""In accordance with Article VII Section 4, """"Info"""" actions shall also be used in connection with proposed Cardano Blockchain ecosystem budgets and Cardano Blockchain treasury withdrawals."" overlaps with Article VII Section 4. + +""A special form of on-chain governance action, an """"Info"""" action, exists to allow the Cardano Community to propose potential future on-chain governance actions and to allow community sentiment to be gauged without committing to any on-chain change to the Cardano Blockchain. Such """"Info"""" actions have no on-chain effect other than to record such """"Info"""" actions on the Cardano Blockchain."" This merely explains the content of information actions, and there is no benefit to explicitly stating this in the Constitution.",OK +Section 5,Section 4,FALSE,,OK +"In order to promote transparency in the process of on-chain governance, prior to being recorded or enacted on-chain, all proposed governance actions are expected to follow a standardized and legible format including a URL and hash of all documented off-chain content to the Cardano Blockchain. Sufficient rationale shall be provided to justify the requested change to the Cardano Blockchain. The rationale shall include, at a minimum, a title, abstract, reason for the proposal, and relevant supporting materials.","In order to promote transparency in the process of on-chain governance, prior to being recorded or enacted on-chain, all proposed governance actions are expected to follow a standardized and legible format including a URL and hash of all documented off-chain content to the Cardano Blockchain. Sufficient rationale shall be provided to justify the requested change to the Cardano Blockchain. The rationale shall include, at a minimum, a title, abstract, reason for the proposal, and relevant supporting materials.",TRUE,,OK +The content of every on-chain governance action must be identical to the final off-chain version of the proposed action.,The content of every on-chain governance action must be identical to the final off-chain version of the proposed action.,TRUE,,OK +"""Hard Fork Initiation"" and ""Protocol Parameter Change"" governance actions shall undergo sufficient technical review and scrutiny as mandated by the Guardrails to ensure that the governance action does not endanger the security, functionality, performance or long-term sustainability of the Cardano Blockchain. On-chain governance actions should address their expected impact on the Cardano Blockchain ecosystem.","""Hard Fork Initiation"" and ""Protocol Parameter Change"" governance actions shall undergo sufficient technical review and scrutiny as mandated by the Guardrails to ensure that the governance action does not endanger the security, functionality, performance or long-term sustainability of the Cardano Blockchain. On-chain governance actions should address their expected impact on the Cardano Blockchain ecosystem.",TRUE,,OK +"All owners of ada shall have the right to ensure that the process for participating in, submitting and voting on on-chain governance actions is open and transparent and is protected from undue influence and manipulation.","All owners of ada shall have the right to ensure that the process for participating in, submitting and voting on on-chain governance actions is open and transparent and is protected from undue influence and manipulation.",TRUE,,OK +Section 6,Section 5,FALSE,,OK +"The Cardano Community is expected to support the creation, maintenance and ongoing administration of off-chain governance processes as may be necessary to give effect to this Constitution and to ensure that there is awareness of and an opportunity to debate and shape all future governance actions for the Cardano Blockchain.","The Cardano Community shall establish and make public a process from time to time for election of members of the Constitutional Committee consistent with the requirements of the Guardrails. The Cardano Community is expected to support the creation, maintenance and ongoing administration of off-chain governance processes as may be necessary to give effect to this Constitution and to ensure that there is awareness of and an opportunity to debate and shape all future governance actions for the Cardano Blockchain.This includes the development and ongoing maintenance of tools to help the Constitutional Committee do its job, and to assist ADA holders in appropriately delegating to the DRep in accordance with the Code of Conduct.",FALSE,"ARTICLE V Section 4, ARTICLE VII Section 3, and Section 7, which state our expectations of the Cardano community, will be consolidated into ARTICLE III Section 6.",OK +ARTICLE IV. THE CARDANO BLOCKCHAIN ECOSYSTEM BUDGET,ARTICLE IV. THE CARDANO BLOCKCHAIN ECOSYSTEM BUDGET,TRUE,,OK +Section 1,Section 1,TRUE,,OK +"Any participant in the Cardano Community may propose a Cardano Blockchain ecosystem budget at any time. The Cardano Community is expected to periodically propose one or more budgets for the ongoing operation, maintenance and future development of the Cardano Blockchain ecosystem and for covering other costs related to the implementation, administration and maintenance of the decentralized, on-chain governance processes provided for in this Constitution. The Cardano Community may propose one aggregate budget or multiple budgets for the Cardano Blockchain ecosystem. Such budgets are expected to cover not less than a period of 73 epochs (approximately one calendar year) but nothing shall prevent the Cardano Community from proposing budgets for shorter or longer time periods. All owners of ada are expected to periodically approve one or more Cardano Blockchain ecosystem budgets through an on-chain ""Info"" action. As provided in Section 3 of this Article IV, withdrawals may be made from the Cardano Blockchain treasury as necessary from time to time to give effect to the Cardano Blockchain ecosystem budget or budgets then in effect. Existing budgets may be amended following the same process as provided in this Section 1.","Any participant in the Cardano Community may propose a Cardano Blockchain ecosystem budget at any time. The Cardano Community is expected to periodically propose one or more budgets for the ongoing operation, maintenance and future development of the Cardano Blockchain ecosystem and for covering other costs related to the implementation, administration and maintenance of the decentralized, on-chain governance processes provided for in this Constitution. The Cardano Community may propose one aggregate budget or multiple budgets for the Cardano Blockchain ecosystem. Such budgets are expected to cover not less than a period of 73 epochs (approximately one calendar year) but nothing shall prevent the Cardano Community from proposing budgets for shorter or longer time periods. All owners of ada are expected to periodically approve one or more Cardano Blockchain ecosystem budgets through an on-chain ""Info"" action. As provided in Section 3 of this Article IV, withdrawals may be made from the Cardano Blockchain treasury as necessary from time to time to give effect to the Cardano Blockchain ecosystem budget or budgets then in effect. Existing budgets may be amended following the same process as provided in this Section 1.",TRUE,,OK +Section 2,Section 2,TRUE,,OK +"Development of Cardano Blockchain ecosystem budgets and the administration of such budgets shall utilize, to the extent possible and beneficial, smart contracts and other blockchain based tools to facilitate decision-making and ensure transparency. Cardano Blockchain budgets shall specify a process for overseeing use of funds from Cardano Blockchain treasury withdrawals including designating one or more administrators who shall be responsible for such oversight.","Development of Cardano Blockchain ecosystem budgets and the administration of such budgets shall utilize, to the extent possible and beneficial, smart contracts and other blockchain based tools to facilitate decision-making and ensure transparency. Cardano Blockchain budgets shall specify a process for overseeing use of funds from Cardano Blockchain treasury withdrawals including designating one or more administrators who shall be responsible for such oversight.",TRUE,,OK +Section 3,Section 3,TRUE,,OK +"Withdrawals from the Cardano Blockchain treasury that would cause the Cardano Blockchain treasury balance to violate the then applicable net change limit shall not be permitted. No withdrawals from the Cardano Blockchain treasury shall be permitted unless such withdrawals have been authorized and are being made pursuant to a budget for the Cardano Blockchain that is then in effect as required by the Cardano Blockchain Guardrails Appendix, and which has not been determined by the Constitutional Committee to be unconstitutional.","Withdrawals from the Cardano Blockchain treasury that would cause the Cardano Blockchain treasury balance to violate the then applicable net change limit shall not be permitted. No withdrawals from the Cardano Blockchain treasury shall be permitted unless such withdrawals have been authorized and are being made pursuant to a budget for the Cardano Blockchain that is then in effect as required by the Cardano Blockchain Guardrails Appendix, and which has not been determined by the Constitutional Committee to be unconstitutional.",TRUE,,OK +Section 4,Section 4,TRUE,,OK +Any governance action requesting ada from the Cardano Blockchain treasury 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 Blockchain ecosystem budget shall include dispute resolution provisions.,Any governance action requesting ada from the Cardano Blockchain treasury 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 Blockchain ecosystem budget shall include dispute resolution provisions.,TRUE,,OK +Section 5,Section 5,TRUE,,OK +"Any ada received from a Cardano Blockchain treasury withdrawal, so long as such ada is being held directly or indirectly by an administrator prior to further disbursement, must be kept in one or more separate accounts that can be audited by the Cardano Community, and such accounts shall not be delegated to an SPO but must be delegated to the predefined auto abstain voting option.","Any ada received from a Cardano Blockchain treasury withdrawal, so long as such ada is being held directly or indirectly by an administrator prior to further disbursement, must be kept in one or more separate accounts that can be audited by the Cardano Community, and such accounts shall not be delegated to an SPO but must be delegated to the predefined auto abstain voting option.",TRUE,,OK +ARTICLE V. DELEGATED REPRESENTATIVES,ARTICLE V. DELEGATED REPRESENTATIVES,TRUE,,OK +Section 1,-,FALSE,,OK +"In order to participate in governance actions, owners of ada may register as DReps and directly vote on such governance actions or may delegate their voting rights to other registered DReps who shall vote on their behalf.",-,FALSE,"It is merely an explanation of DRep, and there is no merit in including it. (If such an explanation were necessary for some reason, it should be included in the SPO Article, but it is not there.)",OK +Section 2,-,FALSE,,OK +"Any owner of ada shall have the option to register as a DRep. Owners of ada shall be allowed to delegate their voting stake to one or more registered DReps, including themselves. DReps may be individuals or coordinated groups. Owners of ada who use third-party custodians or other designees to hold their ada, may authorize, or may withhold authorization for, such third-parties to delegate the voting rights of the ada owner to registered DReps on the owner's behalf. DReps are entitled to cast votes directly for on-chain governance actions and represent those ada owners delegating their voting rights to them. DRep voting thresholds are set forth in the Cardano Blockchain Guardrails Appendix.",-,FALSE,"The following is just a description of DRep, and there is no merit in including it. (If such an explanation were necessary for some reason, it should be included in the SPO Article, but it is not there.) + +・Any owner of ada shall have the option to register as a DRep. Owners of ada shall be allowed to delegate their voting stake to one or more registered DReps, including themselves. DReps may be individuals or coordinated groups. +・DReps are entitled to cast votes directly for on-chain governance actions and represent those ada owners delegating their voting rights to them. DRep voting thresholds are set forth in the Cardano Blockchain Guardrails Appendix. + +It would be simpler to combine the following: + +ARTICLE III Section 3 +ARTICLE V Section 1 ""Owners of ada who use third-party custodians or other designees to hold their ada, may authorize, or may withhold authorization for, such third-parties to delegate the voting rights of the ada owner to registered DReps on the owner's behalf.""",OK +"This voting system shall enshrine a liquid democracy model where owners of ada can seamlessly select among DReps, register as a DRep, and withdraw or change their delegation at any time.",-,FALSE,There is no merit in restating the fluid democratic model.,OK +Section 3,Section 1,FALSE,,OK +"DReps who are representing delegators are expected to periodically adopt, and update as they deem appropriate, codes of conduct governing their activities as DReps and make such codes of conduct publicly available. DReps are encouraged to include ethical guidelines in their codes of conduct.","DReps who are representing delegators are expected to periodically adopt, and update as they deem appropriate, codes of conduct governing their activities as DReps and make such codes of conduct publicly available. DReps are encouraged to include ethical guidelines in their codes of conduct.",TRUE,,OK +Section 4,-,FALSE,,OK +"The Cardano Community is expected to support the creation, maintenance and ongoing administration of tools to enable owners of ada to explore and evaluate DRep candidates, access and evaluate DRep codes of conduct and select DReps on such criteria as they deem relevant.",-,FALSE,"ARTICLE V Section 4, ARTICLE VII Section 3, and Section 7, which state our expectations of the Cardano community, will be consolidated into ARTICLE III Section 6.",OK +Section 5,Section 2,FALSE,,OK +DReps who are representing delegators may be compensated for their efforts. DReps shall ensure that any compensation received in connection with their activities as a DRep is disclosed.,DReps who are representing delegators may be compensated for their efforts. DReps shall ensure that any compensation received in connection with their activities as a DRep is disclosed.,TRUE,,OK +Section 6,Section 3,FALSE,,OK +DReps shall not pay compensation to an ada owner or to an owner's designee in exchange for being appointed a DRep by such ada owner or by its designee or for voting on behalf of such ada owner or its designee.,DReps shall not pay compensation to an ada owner or to an owner's designee in exchange for being appointed a DRep by such ada owner or by its designee or for voting on behalf of such ada owner or its designee.,TRUE,,OK +ARTICLE VI. STAKE POOL OPERATORS,ARTICLE VI. STAKE POOL OPERATORS,TRUE,,OK +Section 1,Section 1,TRUE,,OK +"SPOs shall have a specific role in approving critical on-chain governance actions that require additional oversight and independence, voting separately and independently from DReps as set forth in the Cardano Blockchain Guardrails Appendix. SPOs shall participate in hard fork initiation processes as the operators of the nodes that participate in Cardano Blockchain's consensus mechanism.","SPOs vote on the following governance actions: ""Motion of no-confidence"", ""Update committee/threshold and/or term"", ""Hard-fork initiation"", and on ""Parameter Update"" governance actions that affect security-critical parameters set forth under Parameters that are Critical to the Operation of the Blockchain in Section 2.1 of the Cardano Blockchain Guardrails Appendix.",FALSE,"A brief explanation of the SPO voting items. To simplify things, we will combine Section2 with Section 1.",OK +Section 2,-,FALSE,,OK +"SPOs shall act as a check on the power of the Constitutional Committee under exceptional circumstances by separately voting on ""Motion of no confidence"" and ""Update committee/threshold and/or term"" governance actions, and on ""Parameter Update"" governance actions that affect security-critical parameters set forth under Parameters that are Critical to the Operation of the Blockchain in Section 2.1 of the Cardano Blockchain Guardrails Appendix.",-,FALSE,"To simplify things, we will combine it with Section 1.",OK +Section 3,Section 2,FALSE,,OK +"SPOs are encouraged to periodically adopt, and update as they deem appropriate, codes of conduct governing their activities as SPOs and make such codes of conduct publicly available. SPOs are encouraged to include ethical guidelines in their codes of conduct.","SPOs are encouraged to periodically adopt, and update as they deem appropriate, codes of conduct governing their activities as SPOs and make such codes of conduct publicly available. SPOs are encouraged to include ethical guidelines in their codes of conduct.",TRUE,,OK +Section 4,-,FALSE,,OK +Owners of ada who are both SPOs and acting as DReps shall publicly disclose that they are participating in on-chain governance actions in both such capacities prior to exercising any on-chain governance rights.,-,FALSE,The provisions of ARTICLE VII.Section 9 and ARTICLE VI Section 4 will be consolidated and set forth in ARTICLE III Section 2.,OK +ARTICLE VII. CONSTITUTIONAL COMMITTEE,ARTICLE VII. CONSTITUTIONAL COMMITTEE,TRUE,,OK +Section 1,Section 1,TRUE,,OK +"A Constitutional Committee shall be established as the branch of Cardano's on-chain governance process that ensures governance actions to be enacted on-chain are consistent with this Constitution. The Constitutional Committee shall comprise a set of owners of ada that is collectively responsible for ensuring that on-chain governance actions prior to enactment on-chain, are constitutional. Except as otherwise provided in Section 4 of this Article VII, the Constitutional Committee shall be limited to voting on the constitutionality of governance actions to be enacted on-chain. Constitutional Committee members are expected to have appropriate expertise to carry out their required responsibilities, considering their past contributions and involvement in the Cardano Blockchain ecosystem.","A Constitutional Committee shall be established as the branch of Cardano's on-chain governance process that ensures governance actions to be enacted on-chain are consistent with this Constitution. The Constitutional Committee shall comprise a set of owners of ada that is collectively responsible for ensuring that on-chain governance actions prior to enactment on-chain, are constitutional. Except as otherwise provided in Section 4 of this Article VII, the Constitutional Committee shall be limited to voting on the constitutionality of governance actions to be enacted on-chain. Constitutional Committee members are expected to have appropriate expertise to carry out their required responsibilities, considering their past contributions and involvement in the Cardano Blockchain ecosystem.",TRUE,,OK +Section 2,Section 2,TRUE,,OK +The Constitutional Committee shall be composed of such number of members sufficient to assure the ongoing integrity of the Cardano Blockchain as determined from time to time by owners of ada. The minimum and maximum number of members of the Constitutional Committee shall be consistent with the minimum and maximum number of members as set forth in the Cardano Blockchain Guardrails Appendix.,The Constitutional Committee shall be composed of such number of members sufficient to assure the ongoing integrity of the Cardano Blockchain as determined from time to time by owners of ada. The minimum and maximum number of members of the Constitutional Committee shall be consistent with the minimum and maximum number of members as set forth in the Cardano Blockchain Guardrails Appendix.,TRUE,,OK +"Members of the Constitutional Committee shall serve such term lengths as shall be determined from time to time by owners of ada as consistent with the minimum and maximum term lengths as set forth in the Cardano Blockchain Guardrails Appendix. To assure continuity in the operation of the Constitutional Committee, the terms for Constitutional Committee members shall be staggered.","Members of the Constitutional Committee shall serve such term lengths as shall be determined from time to time by owners of ada as consistent with the minimum and maximum term lengths as set forth in the Cardano Blockchain Guardrails Appendix. To assure continuity in the operation of the Constitutional Committee, the terms for Constitutional Committee members shall be staggered.",TRUE,,OK +Section 3,-,FALSE,,OK +The Cardano Community shall establish and make public a process from time to time for election of members of the Constitutional Committee consistent with the requirements of the Guardrails.,-,FALSE,"ARTICLE V Section 4, ARTICLE VII Section 3, and Section 7, which state our expectations of the Cardano community, will be consolidated into ARTICLE III Section 6.",OK +Section 4,Section 3,FALSE,,OK +"No governance action, other than a ""Motion of no confidence,"" or ""Update Constitutional Committee/threshold and/or term"" may be implemented on-chain unless a requisite percentage of the members of the Constitutional Committee as specified by the Guardrails shall have first determined and affirmed through an on-chain action that such proposal does not violate this Constitution. Each Constitutional Committee member shall have one vote.","No governance action, other than a ""Motion of no confidence,"" or ""Update Constitutional Committee/threshold and/or term"" may be implemented on-chain unless a requisite percentage of the members of the Constitutional Committee as specified by the Guardrails shall have first determined and affirmed through an on-chain action that such proposal does not violate this Constitution. Each Constitutional Committee member shall have one vote.",TRUE,,OK +"Because ""Info"" actions have no on-chain effect and, accordingly, are neither constitutional nor unconstitutional, Constitutional Committee members may not prevent ""Info"" actions from being recorded on-chain. Members of the Constitutional Committee may nevertheless record a vote on-chain regarding an ""Info"" action in order to express their view on such ""Info"" action, including whether the suggested course of action proposed in such ""Info"" action, would be, in the view of such member, unconstitutional if it were to be enforced by on-chain mechanisms.","Because ""Info"" actions have no on-chain effect and, accordingly, are neither constitutional nor unconstitutional, Constitutional Committee members may not prevent ""Info"" actions from being recorded on-chain. Members of the Constitutional Committee may nevertheless record a vote on-chain regarding an ""Info"" action in order to express their view on such ""Info"" action, including whether the suggested course of action proposed in such ""Info"" action, would be, in the view of such member, unconstitutional if it were to be enforced by on-chain mechanisms.",TRUE,,OK +"In the case of ""Info"" actions that propose a Cardano Blockchain ecosystem budget, Constitutional Committee members shall record a vote on-chain that sets forth their opinion as to whether the proposed budget, if it were to be implemented in the form contained in the ""Info"" action, would violate this Constitution.","In the case of ""Info"" actions that propose a Cardano Blockchain ecosystem budget, Constitutional Committee members shall record a vote on-chain that sets forth their opinion as to whether the proposed budget, if it were to be implemented in the form contained in the ""Info"" action, would violate this Constitution.",TRUE,,OK +"In the case of ""Info"" actions that propose a withdrawal from the Cardano Blockchain treasury pursuant to a previously approved budget, Constitutional Committee members shall record a vote on-chain that sets forth their opinion as to whether such proposed withdrawal, if made in accordance with such ""Info"" action, would violate this Constitution.","In the case of ""Info"" actions that propose a withdrawal from the Cardano Blockchain treasury pursuant to a previously approved budget, Constitutional Committee members shall record a vote on-chain that sets forth their opinion as to whether such proposed withdrawal, if made in accordance with such ""Info"" action, would violate this Constitution.",TRUE,,OK +Section 5,Section 4,FALSE,,OK +"The Constitutional Committee shall be considered to be in one of the following two states at all times: a state of confidence or a state of no-confidence. In a state of no-confidence, members of the then standing Constitutional Committee must be reinstated or replaced using the ""Update committee/threshold"" governance action before any other on-chain governance action, other than ""Info"" actions, may go forward. During a state of no-confidence, ""Info"" actions other than ""Info"" actions relating to budget proposals or treasury withdrawal proposals, may continue to be recorded on-chain.","The Constitutional Committee shall be considered to be in one of the following two states at all times: a state of confidence or a state of no-confidence. In a state of no-confidence, members of the then standing Constitutional Committee must be reinstated or replaced using the ""Update committee/threshold"" governance action before any other on-chain governance action, other than ""Info"" actions, may go forward. During a state of no-confidence, ""Info"" actions other than ""Info"" actions relating to budget proposals or treasury withdrawal proposals, may continue to be recorded on-chain.",TRUE,,OK +"If a member of the Constitutional Committee is not carrying out its responsibilities as required by this Constitution, as so determined by a requisite percentage as specified by the Guardrails of SPOs and DReps, voting separately pursuant to an ""Update Constitutional Committee/threshold and/or term"" governance action, such member shall be removed from the Constitutional Committee upon the implementation of the governance action. Thereafter, an election shall be held as soon as practical to replace the member so removed.","If a member of the Constitutional Committee is not carrying out its responsibilities as required by this Constitution, as so determined by a requisite percentage as specified by the Guardrails of SPOs and DReps, voting separately pursuant to an ""Update Constitutional Committee/threshold and/or term"" governance action, such member shall be removed from the Constitutional Committee upon the implementation of the governance action. Thereafter, an election shall be held as soon as practical to replace the member so removed.",TRUE,,OK +"In the event of a ""Motion of no confidence"" governance action to remove all members of the Constitutional Committee at the same time, that is approved by a requisite percentage as specified by the Guardrails of DReps and SPOs, upon implementation of the governance action, the Constitutional Committee shall be considered to be a state of no-confidence until such time as an election has been held either to reinstate the existing Constitutional Committee members in whole or in part, or to elect new Constitutional Committee members.","In the event of a ""Motion of no confidence"" governance action to remove all members of the Constitutional Committee at the same time, that is approved by a requisite percentage as specified by the Guardrails of DReps and SPOs, upon implementation of the governance action, the Constitutional Committee shall be considered to be a state of no-confidence until such time as an election has been held either to reinstate the existing Constitutional Committee members in whole or in part, or to elect new Constitutional Committee members.",TRUE,,OK +Section 6,Section 5,FALSE,,OK +"Constitutional Committee processes shall be transparent. The Constitutional Committee shall publish each decision. When voting that a governance action proposed to be executed on-chain is unconstitutional, the Constitutional Committee collectively, or each member of the Constitutional Committee casting such a vote separately, shall set forth the basis for its decision with reference to specific Articles of this Constitution or provisions of the Cardano Blockchain Guardrails Appendix that are in conflict with a given proposal. Internal deliberations among members of the Constitutional Committee, prior to casting votes, are not required to be publicly disclosed.","Constitutional Committee processes shall be transparent. The Constitutional Committee shall publish each decision. When voting that a governance action proposed to be executed on-chain is unconstitutional, the Constitutional Committee collectively, or each member of the Constitutional Committee casting such a vote separately, shall set forth the basis for its decision with reference to specific Articles of this Constitution or provisions of the Cardano Blockchain Guardrails Appendix that are in conflict with a given proposal. Internal deliberations among members of the Constitutional Committee, prior to casting votes, are not required to be publicly disclosed.",TRUE,,OK +The Constitutional Committee shall operate pursuant to a code of conduct periodically adopted and published by the Constitutional Committee. The Constitutional Committee is encouraged to include ethical guidelines in its code of conduct. The Constitutional Committee shall periodically adopt and publish such policies and procedures as the Constitutional Committee shall deem necessary in carrying out its duties.,The Constitutional Committee shall operate pursuant to a code of conduct periodically adopted and published by the Constitutional Committee. The Constitutional Committee is encouraged to include ethical guidelines in its code of conduct. The Constitutional Committee shall periodically adopt and publish such policies and procedures as the Constitutional Committee shall deem necessary in carrying out its duties.,TRUE,,OK +Section 7,-,FALSE,,OK +"The Cardano Community is expected to support the creation, maintenance and ongoing administration of tools as may be necessary and appropriate for the Constitutional Committee to perform its required functions.",-,FALSE,"ARTICLE V Section 4, ARTICLE VII Section 3, and Section 7, which state our expectations of the Cardano community, will be consolidated into ARTICLE III Section 6.",OK +Section 8,Section 6,FALSE,,OK +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 ecosystem may 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. Cardano Blockchain ecosystem budgets shall provide for periodic administrative costs of the Constitutional Committee in such amounts as requested from time to time by the Constitutional Committee and as approved by ada owners.,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 ecosystem may 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. Cardano Blockchain ecosystem budgets shall provide for periodic administrative costs of the Constitutional Committee in such amounts as requested from time to time by the Constitutional Committee and as approved by ada owners.,TRUE,,OK +Section 9,-,FALSE,,OK +"Constitutional Committee members who are also acting as DReps, as SPOs, or both, shall publicly disclose that they are participating in on-chain governance actions in more than one such capacity prior to voting with respect to on-chain governance actions.",-,FALSE,The provisions of ARTICLE VII.Section 9 and ARTICLE VI Section 4 will be consolidated and set forth in ARTICLE III Section 2.,OK +ARTICLE VIII. AMENDMENT PROCESS,ARTICLE VIII. AMENDMENT PROCESS,TRUE,ARTICLE VIII. AMENDMENT PROCESS, +Section 1,Section 1,TRUE,Section 1, +"This Constitution should be treated as a living document. Technical advancements, changes in the desires, needs and expectations of the Cardano Community, and unforeseen circumstances may give rise to the need in the future to amend this Constitution. The Cardano Community is encouraged to periodically review and debate its provisions, and when so desired, come together in such forums as the Cardano Community may deem appropriate, to propose amendments to this Constitution. Amendments may be made as provided in this Article VIII.","This Constitution should be treated as a living document. The Cardano Community is encouraged to periodically review and debate its provisions, and when so desired, come together in such forums as the Cardano Community may deem appropriate, to propose amendments to this Constitution. The threshold required to amend this constitution is set out in the Cardano Blockchain Guardrails Appendix. If not specified in the Cardano Blockchain Guardrails Appendix, approval of a threshold of no less than 65% of the then active voting stake is required.",FALSE,"Technical advancements, changes in the desires, needs and expectations of the Cardano Community, and unforeseen circumstances may give rise to the need in the future to amend this Constitution. ：This repeats the previous sentence. Delete it. + +Amendments may be made as provided in this Article VIII.：To be consistent with this, it would have to be at the end of every section. It doesn't make sense, so delete it. +", +Section 2,-,FALSE,-, +"Except as otherwise so provided in the Cardano Blockchain Guardrails Appendix, amendments to this Constitution, including to the Cardano Blockchain Guardrails Appendix, shall be approved by a collective decision-making process, requiring an on-chain governance action by owners of ada satisfying a threshold of no less than 65% of the then active voting stake.",-,FALSE,"Sections 2 and 3 can be expressed more simply as follows. This will be added to Section 1. + +The threshold required to amend this constitution is set out in the Cardano Blockchain Guardrails Appendix. If not specified in the Cardano Blockchain Guardrails Appendix, approval of a threshold of no less than 65% of the then active voting stake is required.", +Section 3,-,FALSE,-, +"If the Cardano Blockchain Guardrails Appendix sets forth an amendment threshold for a Guardrail that is different than the amendment threshold contained in Section 2 of this Article VIII, then the threshold set forth in the Cardano Blockchain Guardrails Appendix for such Guardrail shall apply.",-,FALSE,"Sections 2 and 3 can be expressed more simply as follows. This will be added to Section 1. + +The threshold required to amend this constitution is set out in the Cardano Blockchain Guardrails Appendix. If not specified in the Cardano Blockchain Guardrails Appendix, approval of a threshold of no less than 65% of the then active voting stake is required.", +APPENDIX I: CARDANO BLOCKCHAIN GUARDRAILS,APPENDIX I: CARDANO BLOCKCHAIN GUARDRAILS,,0.APPENDIX, +1. Introduction,1. Introduction,,0.APPENDIX, +"To implement Cardano Blockchain on-chain governance, it is necessary to establish sensible Guardrails that will enable the Cardano Blockchain to continue to operate in a secure and sustainable way.","To implement Cardano Blockchain on-chain governance, it is necessary to establish sensible Guardrails that will enable the Cardano Blockchain to continue to operate in a secure and sustainable way.",,0.APPENDIX, +"This Appendix sets forth Guardrails that must be applied to Cardano Blockchain on-chain governance actions, including changes to the protocol parameters and limits on treasury withdrawals. These Guardrails cover both essential, intrinsic limits on settings, and recommendations that are based on experience, measurement and governance objectives.","This Appendix sets forth Guardrails that must be applied to Cardano Blockchain on-chain governance actions, including changes to the protocol parameters and limits on treasury withdrawals. These Guardrails cover both essential, intrinsic limits on settings, and recommendations that are based on experience, measurement and governance objectives.",,0.APPENDIX, +"These Guardrails are designed to avoid unexpected problems with the operation of the Cardano Blockchain. They are intended to guide the choice of sensible parameter settings and avoid potential problems with security, performance, functionality or long-term sustainability. As described below, some of these Guardrails are automatable and will be enforced via an on-chain Guardrails Script or built-in ledger rules.","These Guardrails are designed to avoid unexpected problems with the operation of the Cardano Blockchain. They are intended to guide the choice of sensible parameter settings and avoid potential problems with security, performance, functionality or long-term sustainability. As described below, some of these Guardrails are automatable and will be enforced via an on-chain Guardrails Script or built-in ledger rules.",,0.APPENDIX, +These Guardrails apply only to the Cardano Blockchain Layer 1 mainnet environment. They are not intended to apply to test environments or to other blockchains that use Cardano Blockchain software.,These Guardrails apply only to the Cardano Blockchain Layer 1 mainnet environment. They are not intended to apply to test environments or to other blockchains that use Cardano Blockchain software.,,0.APPENDIX, +"Not all parameters for the Cardano Blockchain can be considered independently. Some parameters interact with other settings in an intrinsic way. Where known, these interactions are addressed in this Appendix.","Not all parameters for the Cardano Blockchain can be considered independently. Some parameters interact with other settings in an intrinsic way. Where known, these interactions are addressed in this Appendix.",,0.APPENDIX, +"While the Guardrails in this Appendix presently reflect the current state of technical insight, this Appendix should be treated as a living document. Implementation improvements, new simulations or performance evaluation results for the Cardano Blockchain may allow some of the restrictions contained in these Guardrails to be relaxed (or, in some circumstances, require them to be tightened) in due course.","While the Guardrails in this Appendix presently reflect the current state of technical insight, this Appendix should be treated as a living document. Implementation improvements, new simulations or performance evaluation results for the Cardano Blockchain may allow some of the restrictions contained in these Guardrails to be relaxed (or, in some circumstances, require them to be tightened) in due course.",,0.APPENDIX, +"Additional Guardrails may also be needed where, for example, new protocol parameters are introduced.","Additional Guardrails may also be needed where, for example, new protocol parameters are introduced.",,0.APPENDIX, +"Amending, Adding or Deprecating Guardrails","Amending, Adding or Deprecating Guardrails",,0.APPENDIX, +"The Guardrails set forth in this Appendix may be amended from time to time pursuant to an on-chain governance action that satisfies the applicable voting threshold as set forth in this Appendix. Any such amendment to any Guardrails shall require and be deemed to be an amendment to the Constitution itself, including any new Guardrails. Each Guardrail has a unique label. If the text of a Guardrail is amended, the existing Guardrail will be deprecated and a new label will be used in this Appendix. Similarly, if a Guardrail is completely deprecated, its label will never be reused in the future. In all cases, the Guardrails that apply to a governance action will be those in force at the time that the governance action is submitted on chain, regardless of any later amendments.","The Guardrails set forth in this Appendix may be amended from time to time pursuant to an on-chain governance action that satisfies the applicable voting threshold as set forth in this Appendix. Any such amendment to any Guardrails shall require and be deemed to be an amendment to the Constitution itself, including any new Guardrails. Each Guardrail has a unique label. If the text of a Guardrail is amended, the existing Guardrail will be deprecated and a new label will be used in this Appendix. Similarly, if a Guardrail is completely deprecated, its label will never be reused in the future. In all cases, the Guardrails that apply to a governance action will be those in force at the time that the governance action is submitted on chain, regardless of any later amendments.",,0.APPENDIX, +Terminology and Guidance,Terminology and Guidance,,0.APPENDIX, +"Should/Should not. Where this Appendix says that a value ""should not"" be set below or above some value, this means that the Guardrail is a recommendation or guideline, and the specific value could be open to discussion or alteration by a suitably expert group recognized by the Cardano Community in light of experience with the Cardano Blockchain governance system or the operation of the Cardano Blockchain.","Should/Should not. Where this Appendix says that a value ""should not"" be set below or above some value, this means that the Guardrail is a recommendation or guideline, and the specific value could be open to discussion or alteration by a suitably expert group recognized by the Cardano Community in light of experience with the Cardano Blockchain governance system or the operation of the Cardano Blockchain.",,0.APPENDIX, +"Must/Must not. Where this Appendix says that a value ""must"" or ""must not"" be set below or above some value, this means that the Guardrail is a requirement that will be enforced by Cardano Blockchain ledger rules, types or other built-in mechanisms where possible, and that if not followed could cause a protocol failure, security breach or other undesirable outcome.","Must/Must not. Where this Appendix says that a value ""must"" or ""must not"" be set below or above some value, this means that the Guardrail is a requirement that will be enforced by Cardano Blockchain ledger rules, types or other built-in mechanisms where possible, and that if not followed could cause a protocol failure, security breach or other undesirable outcome.",,0.APPENDIX, +"Benchmarking. Benchmarking refers to careful system level performance evaluation that is designed to show a priori that, for example, 95% of blocks will be diffused across a global network of Cardano Blockchain nodes within the required 5s time interval in all cases. This may require construction of specific test workflows and execution on a large test network of Cardano Blockchain nodes, simulating a global Cardano Blockchain network.","Benchmarking. Benchmarking refers to careful system level performance evaluation that is designed to show a priori that, for example, 95% of blocks will be diffused across a global network of Cardano Blockchain nodes within the required 5s time interval in all cases. This may require construction of specific test workflows and execution on a large test network of Cardano Blockchain nodes, simulating a global Cardano Blockchain network.",,0.APPENDIX, +"Performance analysis. Performance analysis refers to projecting theoretical performance, empirical benchmarking or simulation results to predict actual system behavior. For example, performance results obtained from tests in a controlled test environment (such as a collection of data centers with known networking properties) may be extrapolated to inform likely performance behavior in a real Cardano Blockchain network environment.","Performance analysis. Performance analysis refers to projecting theoretical performance, empirical benchmarking or simulation results to predict actual system behavior. For example, performance results obtained from tests in a controlled test environment (such as a collection of data centers with known networking properties) may be extrapolated to inform likely performance behavior in a real Cardano Blockchain network environment.",,0.APPENDIX, +"Simulation. Simulation refers to synthetic execution that is designed to inform performance/functionality decisions in a repeatable way. For example, the IOSim Cardano Blockchain module allows the operation of the networking stack to be simulated in a controlled and repeatable way, allowing issues to be detected before code deployment.","Simulation. Simulation refers to synthetic execution that is designed to inform performance/functionality decisions in a repeatable way. For example, the IOSim Cardano Blockchain module allows the operation of the networking stack to be simulated in a controlled and repeatable way, allowing issues to be detected before code deployment.",,0.APPENDIX, +"Performance Monitoring. Performance monitoring involves measuring the actual behavior of the Cardano Blockchain network, for example, by using timing probes to evaluate round-trip times, or test blocks to assess overall network health. It complements benchmarking and performance analysis by providing information about actual system behavior that cannot be obtained using simulated workloads or theoretical analysis.","Performance Monitoring. Performance monitoring involves measuring the actual behavior of the Cardano Blockchain network, for example, by using timing probes to evaluate round-trip times, or test blocks to assess overall network health. It complements benchmarking and performance analysis by providing information about actual system behavior that cannot be obtained using simulated workloads or theoretical analysis.",,0.APPENDIX, +"Reverting Changes. Where performance monitoring shows that actual network behavior following a change is inconsistent with the performance requirements for the Cardano Blockchain, then the change must be reverted to its previous state if that is possible. For example, if the block size is increased from 100KB to 120KB and 95% of blocks are no longer diffused within 5s, then a change must be made to revert the block size to 100KB. If this is not possible, then one or more alternative changes must be made that will ensure that the performance requirements are met.","Reverting Changes. Where performance monitoring shows that actual network behavior following a change is inconsistent with the performance requirements for the Cardano Blockchain, then the change must be reverted to its previous state if that is possible. For example, if the block size is increased from 100KB to 120KB and 95% of blocks are no longer diffused within 5s, then a change must be made to revert the block size to 100KB. If this is not possible, then one or more alternative changes must be made that will ensure that the performance requirements are met.",,0.APPENDIX, +"Severity Levels. Issues that affect the Cardano Blockchain network are classified by severity level, where:","Severity Levels. Issues that affect the Cardano Blockchain network are classified by severity level, where:",,0.APPENDIX, +"Severity 1 is a critical incident or issue with very high impact to the security, performance, functionality or long-term sustainability of the Cardano Blockchain network","Severity 1 is a critical incident or issue with very high impact to the security, performance, functionality or long-term sustainability of the Cardano Blockchain network",,0.APPENDIX, +"Severity 2 is a major incident or issue with significant impact to the security, performance, functionality or long-term sustainability of the Cardano Blockchain network","Severity 2 is a major incident or issue with significant impact to the security, performance, functionality or long-term sustainability of the Cardano Blockchain network",,0.APPENDIX, +"Severity 3 is a minor incident or issue with low impact to the security, performance, functionality or long-term sustainability of the Cardano Blockchain network","Severity 3 is a minor incident or issue with low impact to the security, performance, functionality or long-term sustainability of the Cardano Blockchain network",,0.APPENDIX, +"Future Performance Requirements. Planned development such as new mechanisms for out of memory storage may impact block diffusion or other times. When changing parameters, it is necessary to consider these future performance requirements as well as the current operation of the Cardano Blockchain. Until development is complete, the requirements will be conservative but may then be relaxed to account for actual timing behavior.","Future Performance Requirements. Planned development such as new mechanisms for out of memory storage may impact block diffusion or other times. When changing parameters, it is necessary to consider these future performance requirements as well as the current operation of the Cardano Blockchain. Until development is complete, the requirements will be conservative but may then be relaxed to account for actual timing behavior.",,0.APPENDIX, +"Automated Checking (""Guardrails Script"")","Automated Checking (""Guardrails Script"")",,0.APPENDIX, +"A script hash is associated with the Constitution hash when a New Constitution or Guardrails Script governance action is enacted. It acts as an additional safeguard to the ledger rules and types, filtering non-compliant governance actions.","A script hash is associated with the Constitution hash when a New Constitution or Guardrails Script governance action is enacted. It acts as an additional safeguard to the ledger rules and types, filtering non-compliant governance actions.",,0.APPENDIX, +The Guardrails Script only affects two types of governance actions:,The Guardrails Script only affects two types of governance actions:,,0.APPENDIX, +"Parameter Update actions, and","Parameter Update actions, and",,0.APPENDIX, +Treasury Withdrawal actions.,Treasury Withdrawal actions.,,0.APPENDIX, +"The Guardrails Script is executed when either of these types of governance action is submitted on-chain. This avoids scenarios where, for example, an erroneous script could prevent the Cardano Blockchain from ever enacting a Hard Fork action, resulting in deadlock. There are three different situations that apply to Guardrail Script usage.","The Guardrails Script is executed when either of these types of governance action is submitted on-chain. This avoids scenarios where, for example, an erroneous script could prevent the Cardano Blockchain from ever enacting a Hard Fork action, resulting in deadlock. There are three different situations that apply to Guardrail Script usage.",,0.APPENDIX, +Symbol and Explanation,Symbol and Explanation,,0.APPENDIX, +(y) The Guardrail Script can be used to enforce the Guardrail,(y) The Guardrail Script can be used to enforce the Guardrail,,0.APPENDIX, +(x) The Guardrail Script cannot be used to enforce the Guardrail,(x) The Guardrail Script cannot be used to enforce the Guardrail,,0.APPENDIX, +"(~ - reason) The Guardrail Script cannot be used to enforce the Guardrail for the reason given, but future ledger changes could enable this.","(~ - reason) The Guardrail Script cannot be used to enforce the Guardrail for the reason given, but future ledger changes could enable this.",,0.APPENDIX, +"Guardrails may overlap: in this case, the most restrictive set of Guardrails will apply.","Guardrails may overlap: in this case, the most restrictive set of Guardrails will apply.",,0.APPENDIX, +"Where a parameter is not explicitly listed in this document, then the Guardrail Script must not permit any changes to the parameter.","Where a parameter is not explicitly listed in this document, then the Guardrail Script must not permit any changes to the parameter.",,0.APPENDIX, +"Conversely, where a parameter is explicitly listed in this document but no checkable Guardrails are specified, the Guardrail Script must not impose any constraints on changes to the parameter.","Conversely, where a parameter is explicitly listed in this document but no checkable Guardrails are specified, the Guardrail Script must not impose any constraints on changes to the parameter.",,0.APPENDIX, +2. Guardrails and Guidelines on Protocol Parameter Update Actions,2. Guardrails and Guidelines on Protocol Parameter Update Actions,,0.APPENDIX, +Below are Guardrails and guidelines for changing updatable protocol parameter settings via the protocol parameter update governance action such that the Cardano Blockchain is never in an unrecoverable state as a result of such changes.,Below are Guardrails and guidelines for changing updatable protocol parameter settings via the protocol parameter update governance action such that the Cardano Blockchain is never in an unrecoverable state as a result of such changes.,,0.APPENDIX, +"Note that, to avoid ambiguity, this Appendix uses the parameter name that is used in protocol parameter update governance actions rather than any other convention.","Note that, to avoid ambiguity, this Appendix uses the parameter name that is used in protocol parameter update governance actions rather than any other convention.",,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +PARAM-01 (y) Any protocol parameter that is not explicitly named in this document must not be changed by a Parameter update governance action,PARAM-01 (y) Any protocol parameter that is not explicitly named in this document must not be changed by a Parameter update governance action,,0.APPENDIX, +"PARAM-02a (y) Where a protocol parameter is explicitly listed in this document but no checkable Guardrails are specified, the Guardrails Script must not impose any constraints on changes to the parameter. Checkable Guardrails are shown by a (y)","PARAM-02a (y) Where a protocol parameter is explicitly listed in this document but no checkable Guardrails are specified, the Guardrails Script must not impose any constraints on changes to the parameter. Checkable Guardrails are shown by a (y)",,0.APPENDIX, +2.1. Critical Protocol Parameters,2.1. Critical Protocol Parameters,,0.APPENDIX, +The below protocol parameters are critical from a security point of view.,The below protocol parameters are critical from a security point of view.,,0.APPENDIX, +Parameters that are Critical to the Operation of the Blockchain,Parameters that are Critical to the Operation of the Blockchain,,0.APPENDIX, +maximum block body size (maxBlockBodySize),maximum block body size (maxBlockBodySize),,0.APPENDIX, +maximum transaction size (maxTxSize),maximum transaction size (maxTxSize),,0.APPENDIX, +maximum block header size (maxBlockHeaderSize),maximum block header size (maxBlockHeaderSize),,0.APPENDIX, +maximum size of a serialized asset value (maxValueSize),maximum size of a serialized asset value (maxValueSize),,0.APPENDIX, +maximum script execution/memory units in a single block (maxBlockExecutionUnits[steps/memory]),maximum script execution/memory units in a single block (maxBlockExecutionUnits[steps/memory]),,0.APPENDIX, +minimum fee coefficient (txFeePerByte),minimum fee coefficient (txFeePerByte),,0.APPENDIX, +minimum fee constant (txFeeFixed),minimum fee constant (txFeeFixed),,0.APPENDIX, +minimum fee per byte for reference scripts (minFeeRefScriptCoinsPerByte),minimum fee per byte for reference scripts (minFeeRefScriptCoinsPerByte),,0.APPENDIX, +minimum lovelace deposit per byte of serialized UTxO (utxoCostPerByte),minimum lovelace deposit per byte of serialized UTxO (utxoCostPerByte),,0.APPENDIX, +governance action deposit (govDeposit),governance action deposit (govDeposit),,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"PARAM-03a (y) Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs must say ""yes"" with a collective support of more than 50% of all active block production stake. This is enforced by the Guardrails on the stake pool voting threshold.","PARAM-03a (y) Critical protocol parameters require an SPO vote in addition to a DRep vote: SPOs must say ""yes"" with a collective support of more than 50% of all active block production stake. This is enforced by the Guardrails on the stake pool voting threshold.",,0.APPENDIX, +PARAM-04a (x) At least 3 months should normally pass between the publication of an off-chain proposal to change a critical protocol parameter and the submission of the corresponding on-chain governance action. This Guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation.,PARAM-04a (x) At least 3 months should normally pass between the publication of an off-chain proposal to change a critical protocol parameter and the submission of the corresponding on-chain governance action. This Guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation.,,0.APPENDIX, +Parameters that are Critical to the Governance System,Parameters that are Critical to the Governance System,,0.APPENDIX, +delegation key lovelace deposit (stakeAddressDeposit),delegation key lovelace deposit (stakeAddressDeposit),,0.APPENDIX, +pool registration lovelace deposit (stakePoolDeposit),pool registration lovelace deposit (stakePoolDeposit),,0.APPENDIX, +minimum fixed rewards cut for pools (minPoolCost),minimum fixed rewards cut for pools (minPoolCost),,0.APPENDIX, +DRep deposit amount (dRepDeposit),DRep deposit amount (dRepDeposit),,0.APPENDIX, +minimal Constitutional Committee size (committeeMinSize),minimal Constitutional Committee size (committeeMinSize),,0.APPENDIX, +maximum term length (in epochs) for the Constitutional Committee members (committeeMaxTermLength),maximum term length (in epochs) for the Constitutional Committee members (committeeMaxTermLength),,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"PARAM-05a (y) DReps must vote ""yes"" with a collective support of more than 50% of all active voting stake. This is enforced by the Guardrails on the DRep voting thresholds.","PARAM-05a (y) DReps must vote ""yes"" with a collective support of more than 50% of all active voting stake. This is enforced by the Guardrails on the DRep voting thresholds.",,0.APPENDIX, +PARAM-06a (x) At least 3 months should normally pass between the publication of an off-chain proposal to change a parameter that is critical to the governance system and the submission of the corresponding on-chain governance action. This Guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation.,PARAM-06a (x) At least 3 months should normally pass between the publication of an off-chain proposal to change a parameter that is critical to the governance system and the submission of the corresponding on-chain governance action. This Guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation.,,0.APPENDIX, +2.2. Economic Parameters,2.2. Economic Parameters,,0.APPENDIX, +The overall goals when managing economic parameters are to:,The overall goals when managing economic parameters are to:,,0.APPENDIX, +Enable long-term economic sustainability for the Cardano Blockchain;,Enable long-term economic sustainability for the Cardano Blockchain;,,0.APPENDIX, +Ensure that stake pools are adequately rewarded for maintaining the Cardano Blockchain;,Ensure that stake pools are adequately rewarded for maintaining the Cardano Blockchain;,,0.APPENDIX, +"Ensure that ada owners are adequately rewarded for using stake in constructive ways, including when delegating ada for block production; and","Ensure that ada owners are adequately rewarded for using stake in constructive ways, including when delegating ada for block production; and",,0.APPENDIX, +"Balance economic incentives for different Cardano Blockchain ecosystem stakeholders, including but not limited to Stake Pool Operators, ada owners, DeFi users, infrastructure users, developers (e.g. DApps) and financial intermediaries (e.g. exchanges)","Balance economic incentives for different Cardano Blockchain ecosystem stakeholders, including but not limited to Stake Pool Operators, ada owners, DeFi users, infrastructure users, developers (e.g. DApps) and financial intermediaries (e.g. exchanges)",,0.APPENDIX, +Triggers for Change,Triggers for Change,,0.APPENDIX, +"Significant changes in the fiat value of ada resulting in potential problems with security, performance, functionality or long-term sustainability","Significant changes in the fiat value of ada resulting in potential problems with security, performance, functionality or long-term sustainability",,0.APPENDIX, +Changes in transaction volumes or types,Changes in transaction volumes or types,,0.APPENDIX, +Community requests or suggestions,Community requests or suggestions,,0.APPENDIX, +Emergency situations that require changes to economic parameters,Emergency situations that require changes to economic parameters,,0.APPENDIX, +Counter-indicators,Counter-indicators,,0.APPENDIX, +Changes to the economic parameters should not be made in isolation. They need to account for:,Changes to the economic parameters should not be made in isolation. They need to account for:,,0.APPENDIX, +External economic factors,External economic factors,,0.APPENDIX, +Network security concerns,Network security concerns,,0.APPENDIX, +Core Metrics,Core Metrics,,0.APPENDIX, +"Fiat value of ada resulting in potential problems with security, performance, functionality or long-term sustainability","Fiat value of ada resulting in potential problems with security, performance, functionality or long-term sustainability",,0.APPENDIX, +Transaction volumes and types,Transaction volumes and types,,0.APPENDIX, +Number and health of stake pools,Number and health of stake pools,,0.APPENDIX, +External economic factors,External economic factors,,0.APPENDIX, +Changes to Specific Economic Parameters,Changes to Specific Economic Parameters,,0.APPENDIX, +Transaction fee per byte (txFeePerByte) and fixed transaction fee (txFeeFixed),Transaction fee per byte (txFeePerByte) and fixed transaction fee (txFeeFixed),,0.APPENDIX, +Defines the cost for basic transactions in lovelace:,Defines the cost for basic transactions in lovelace:,,0.APPENDIX, +fee(tx) = txFeeFixed + txFeePerByte x nBytes(tx),fee(tx) = txFeeFixed + txFeePerByte x nBytes(tx),,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +TFPB-01 (y) txFeePerByte must not be lower than 30 (0.000030 ada) This protects against low-cost denial of service attacks,TFPB-01 (y) txFeePerByte must not be lower than 30 (0.000030 ada) This protects against low-cost denial of service attacks,,0.APPENDIX, +"TFPB-02 (y) txFeePerByte must not exceed 1,000 (0.001 ada) This ensures that transactions can be paid for","TFPB-02 (y) txFeePerByte must not exceed 1,000 (0.001 ada) This ensures that transactions can be paid for",,0.APPENDIX, +TFPB-03 (y) txFeePerByte must not be negative,TFPB-03 (y) txFeePerByte must not be negative,,0.APPENDIX, +"TFF-01 (y) txFeeFixed must not be lower than 100,000 (0.1 ada) This protects against low-cost denial of service attacks","TFF-01 (y) txFeeFixed must not be lower than 100,000 (0.1 ada) This protects against low-cost denial of service attacks",,0.APPENDIX, +"TFF-02 (y) txFeeFixed must not exceed 10,000,000 (10 ada) This ensures that transactions can be paid for","TFF-02 (y) txFeeFixed must not exceed 10,000,000 (10 ada) This ensures that transactions can be paid for",,0.APPENDIX, +TFF-03 (y) txFeeFixed must not be negative,TFF-03 (y) txFeeFixed must not be negative,,0.APPENDIX, +"TFGEN-01 (x - ""should"") To maintain a consistent level of protection agains denial-of-service attacks, txFeeFixed and txFeeFixed should be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory])","TFGEN-01 (x - ""should"") To maintain a consistent level of protection agains denial-of-service attacks, txFeeFixed and txFeeFixed should be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory])",,0.APPENDIX, +TFGEN-02 (x - unquantifiable) Any changes to txFeeFixed or txFeeFixed must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee so that it becomes impossible to construct a transaction.,TFGEN-02 (x - unquantifiable) Any changes to txFeeFixed or txFeeFixed must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee so that it becomes impossible to construct a transaction.,,0.APPENDIX, +UTxO cost per byte (utxoCostPerByte),UTxO cost per byte (utxoCostPerByte),,0.APPENDIX, +Defines the deposit (in lovelace) that is charged for each byte of storage tha is held in a UTxO. This deposit is returned when the UTxO is no longer active.,Defines the deposit (in lovelace) that is charged for each byte of storage tha is held in a UTxO. This deposit is returned when the UTxO is no longer active.,,0.APPENDIX, +Sets a minimum threshold on ada that is held within a single UTxO,Sets a minimum threshold on ada that is held within a single UTxO,,0.APPENDIX, +Provides protection against low-cost denial of service attack on UTxO storage. DoS protection decreases in line with the free node memory (proportional to UTxO growth),Provides protection against low-cost denial of service attack on UTxO storage. DoS protection decreases in line with the free node memory (proportional to UTxO growth),,0.APPENDIX, +"Helps reduce long-term storage costs for node users by providing an incentive to return UTxOs when no longer needed, or to merge UTxOs.","Helps reduce long-term storage costs for node users by providing an incentive to return UTxOs when no longer needed, or to merge UTxOs.",,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"UCPB-01 (y) utxoCostPerByte must not be lower than 3,000 (0.003 ada)","UCPB-01 (y) utxoCostPerByte must not be lower than 3,000 (0.003 ada)",,0.APPENDIX, +"UCPB-02 (y) utxoCostPerByte must not exceed 6,500 (0.0065 ada)","UCPB-02 (y) utxoCostPerByte must not exceed 6,500 (0.0065 ada)",,0.APPENDIX, +UCPB-03 (y) utxoCostPerByte must not be zero,UCPB-03 (y) utxoCostPerByte must not be zero,,0.APPENDIX, +UCPB-04 (y) utxoCostPerByte must not be negative,UCPB-04 (y) utxoCostPerByte must not be negative,,0.APPENDIX, +"UCPB-05a (x - ""should"") Changes should account for","UCPB-05a (x - ""should"") Changes should account for",,0.APPENDIX, +The acceptable cost of attack,The acceptable cost of attack,,0.APPENDIX, +The acceptable time for an attack,The acceptable time for an attack,,0.APPENDIX, +The acceptable memory configuration for full node users,The acceptable memory configuration for full node users,,0.APPENDIX, +The sizes of UTxOs and,The sizes of UTxOs and,,0.APPENDIX, +The current total node memory usage,The current total node memory usage,,0.APPENDIX, +Stake address deposit (stakeAddressDeposit),Stake address deposit (stakeAddressDeposit),,0.APPENDIX, +Ensures that stake addresses are retired when no longer needed,Ensures that stake addresses are retired when no longer needed,,0.APPENDIX, +Helps reduce long-term storage costs,Helps reduce long-term storage costs,,0.APPENDIX, +Helps limit CPU and memory costs in the ledger,Helps limit CPU and memory costs in the ledger,,0.APPENDIX, +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.,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.,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"SAD-01 (y) stakeAddressDeposit must not be lower than 1,000,000 (1 ada)","SAD-01 (y) stakeAddressDeposit must not be lower than 1,000,000 (1 ada)",,0.APPENDIX, +"SAD-02 (y) stakeAddressDeposit must not exceed 5,000,000 (5 ada)","SAD-02 (y) stakeAddressDeposit must not exceed 5,000,000 (5 ada)",,0.APPENDIX, +SAD-03 (y) stakeAddressDeposit must not be negative,SAD-03 (y) stakeAddressDeposit must not be negative,,0.APPENDIX, +Stake pool deposit (stakePoolDeposit),Stake pool deposit (stakePoolDeposit),,0.APPENDIX, +Ensures that stake pools are retired by the stake pool operator when no longer needed by them,Ensures that stake pools are retired by the stake pool operator when no longer needed by them,,0.APPENDIX, +Helps reduce long-term storage costs,Helps reduce long-term storage costs,,0.APPENDIX, +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.,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.,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"SPD-01 (y) stakePoolDeposit must not be lower than 250,000,000 (250 ada)","SPD-01 (y) stakePoolDeposit must not be lower than 250,000,000 (250 ada)",,0.APPENDIX, +"SPD-02 (y) stakePoolDeposit must not exceed 500,000,000 (500 ada)","SPD-02 (y) stakePoolDeposit must not exceed 500,000,000 (500 ada)",,0.APPENDIX, +SPD-03 (y) stakePoolDeposit must not be negative,SPD-03 (y) stakePoolDeposit must not be negative,,0.APPENDIX, +Minimum Pool Cost (minPoolCost),Minimum Pool Cost (minPoolCost),,0.APPENDIX, +Part of the rewards mechanism,Part of the rewards mechanism,,0.APPENDIX, +The minimum pool cost is transferred to the pool rewards address before any delegator rewards are paid,The minimum pool cost is transferred to the pool rewards address before any delegator rewards are paid,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +MPC-01 (y) minPoolCost must not be negative,MPC-01 (y) minPoolCost must not be negative,,0.APPENDIX, +"MPC-02 (y) minPoolCost must not exceed 500,000,000 (500 ada)","MPC-02 (y) minPoolCost must not exceed 500,000,000 (500 ada)",,0.APPENDIX, +"MPC-03 (x - ""should"") minPoolCost should be set in line with the economic cost for operating a pool","MPC-03 (x - ""should"") minPoolCost should be set in line with the economic cost for operating a pool",,0.APPENDIX, +Treasury Cut (treasuryCut),Treasury Cut (treasuryCut),,0.APPENDIX, +Part of the rewards mechanism,Part of the rewards mechanism,,0.APPENDIX, +The treasury cut portion of the monetary expansion is transferred to the treasury before any pool rewards are paid,The treasury cut portion of the monetary expansion is transferred to the treasury before any pool rewards are paid,,0.APPENDIX, +Can be set in the range 0.0-1.0 (0%-100%),Can be set in the range 0.0-1.0 (0%-100%),,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +TC-01 (y) treasuryCut must not be lower than 0.1 (10%),TC-01 (y) treasuryCut must not be lower than 0.1 (10%),,0.APPENDIX, +TC-02 (y) treasuryCut must not exceed 0.3 (30%),TC-02 (y) treasuryCut must not exceed 0.3 (30%),,0.APPENDIX, +TC-03 (y) treasuryCut must not be negative,TC-03 (y) treasuryCut must not be negative,,0.APPENDIX, +TC-04 (y) treasuryCut must not exceed 1.0 (100%),TC-04 (y) treasuryCut must not exceed 1.0 (100%),,0.APPENDIX, +TC-05 (~ - no access to change history) treasuryCut must not be changed more than once in any 36 epoch period (approximately 6 months),TC-05 (~ - no access to change history) treasuryCut must not be changed more than once in any 36 epoch period (approximately 6 months),,0.APPENDIX, +Monetary Expansion Rate (monetaryExpansion),Monetary Expansion Rate (monetaryExpansion),,0.APPENDIX, +Part of the rewards mechanism,Part of the rewards mechanism,,0.APPENDIX, +The monetary expansion controls the amount of reserves that is used for rewards each epoch,The monetary expansion controls the amount of reserves that is used for rewards each epoch,,0.APPENDIX, +Governs the long-term sustainability of the Cardano Blockchain,Governs the long-term sustainability of the Cardano Blockchain,,0.APPENDIX, +The reserves are gradually depleted until no rewards are supplied,The reserves are gradually depleted until no rewards are supplied,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +ME-01 (y) monetaryExpansion must not exceed 0.005,ME-01 (y) monetaryExpansion must not exceed 0.005,,0.APPENDIX, +ME-02 (y) monetaryExpansion must not be lower than 0.001,ME-02 (y) monetaryExpansion must not be lower than 0.001,,0.APPENDIX, +ME-03 (y) monetaryExpansion must not be negative,ME-03 (y) monetaryExpansion must not be negative,,0.APPENDIX, +"ME-04 (x - ""should"") monetaryExpansion should not be varied by more than +/- 10% in any 73-epoch period (approximately 12 months)","ME-04 (x - ""should"") monetaryExpansion should not be varied by more than +/- 10% in any 73-epoch period (approximately 12 months)",,0.APPENDIX, +"ME-05 (x - ""should"") monetaryExpansion should not be changed more than once in any 36-epoch period (approximately 6 months)","ME-05 (x - ""should"") monetaryExpansion should not be changed more than once in any 36-epoch period (approximately 6 months)",,0.APPENDIX, +Plutus Script Execution Prices (executionUnitPrices[priceSteps/priceMemory]),Plutus Script Execution Prices (executionUnitPrices[priceSteps/priceMemory]),,0.APPENDIX, +Define the fees for executing Plutus scripts,Define the fees for executing Plutus scripts,,0.APPENDIX, +Gives an economic return for Plutus script execution,Gives an economic return for Plutus script execution,,0.APPENDIX, +Provides security against low-cost DoS attacks,Provides security against low-cost DoS attacks,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"EIUP-PS-01 (y) executionUnitPrices[priceSteps] must not exceed 2,000 / 10,000,000","EIUP-PS-01 (y) executionUnitPrices[priceSteps] must not exceed 2,000 / 10,000,000",,0.APPENDIX, +"EIUP-PS-02 (y) executionUnitPrices[priceSteps] must not be lower than 500 / 10,000,000","EIUP-PS-02 (y) executionUnitPrices[priceSteps] must not be lower than 500 / 10,000,000",,0.APPENDIX, +"EIUP-PM-01 (y) executionUnitPrices[priceMemory] must not exceed 2,000 / 10,000","EIUP-PM-01 (y) executionUnitPrices[priceMemory] must not exceed 2,000 / 10,000",,0.APPENDIX, +"EIUP-PM-02 (y) executionUnitPrices[priceMemory] must not be lower than 400 / 10,000","EIUP-PM-02 (y) executionUnitPrices[priceMemory] must not be lower than 400 / 10,000",,0.APPENDIX, +"EIUP-GEN-01 (x - ""similar to"") The execution prices must be set so tha","EIUP-GEN-01 (x - ""similar to"") The execution prices must be set so tha",,0.APPENDIX, +the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum sized non-script transaction and,the cost of executing a transaction with maximum CPU steps is similar to the cost of a maximum sized non-script transaction and,,0.APPENDIX, +the cost of executing a transaction with maximum memory units is similar to the cost of a maximum sized non-script transaction,the cost of executing a transaction with maximum memory units is similar to the cost of a maximum sized non-script transaction,,0.APPENDIX, +"EIUP-GEN-02 (x - ""should"") The execution prices should be adjusted whenever transaction fees are adjusted (txFeeFixed/txFeePerByte). The goal is to ensure that the processing delay is similar for ""full"" transactions, regardless of their type.","EIUP-GEN-02 (x - ""should"") The execution prices should be adjusted whenever transaction fees are adjusted (txFeeFixed/txFeePerByte). The goal is to ensure that the processing delay is similar for ""full"" transactions, regardless of their type.",,0.APPENDIX, +This helps ensure that the requirements on block diffusion/propagation times are met.,This helps ensure that the requirements on block diffusion/propagation times are met.,,0.APPENDIX, +Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte),Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte),,0.APPENDIX, +Defines the cost for using Plutus reference scripts in lovelace,Defines the cost for using Plutus reference scripts in lovelace,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"MFRS-01 (y) minFeeRefScriptCoinsPerByte must not exceed 1,000 (0.001 ada)","MFRS-01 (y) minFeeRefScriptCoinsPerByte must not exceed 1,000 (0.001 ada)",,0.APPENDIX, +This ensures that transactions can be paid for,This ensures that transactions can be paid for,,0.APPENDIX, +MFRS-02 (y) minFeeRefScriptCoinsPerByte must not be negative,MFRS-02 (y) minFeeRefScriptCoinsPerByte must not be negative,,0.APPENDIX, +"MFRS-03 (x - ""should"") To maintain a consistent level of protection against denial-of-service attacks, minFeeRefScriptCoinsPerByte should be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory]) and whenever txFeeFixed is adjusted","MFRS-03 (x - ""should"") To maintain a consistent level of protection against denial-of-service attacks, minFeeRefScriptCoinsPerByte should be adjusted whenever Plutus Execution prices are adjusted (executionUnitPrices[steps/memory]) and whenever txFeeFixed is adjusted",,0.APPENDIX, +MFRS-04 (x - unquantifiable) Any changes to minFeeRefScriptCoinsPerByte must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee,MFRS-04 (x - unquantifiable) Any changes to minFeeRefScriptCoinsPerByte must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee,,0.APPENDIX, +2.3. Network Parameters,2.3. Network Parameters,,0.APPENDIX, +The overall goals when managing the Cardano Blockchain network parameters are to:,The overall goals when managing the Cardano Blockchain network parameters are to:,,0.APPENDIX, +"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","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",,0.APPENDIX, +"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","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",,0.APPENDIX, +Triggers for Change,Triggers for Change,,0.APPENDIX, +Changes to network parameters may be triggered by:,Changes to network parameters may be triggered by:,,0.APPENDIX, +Measured changes in traffic demands over a 2-epoch period (10 days),Measured changes in traffic demands over a 2-epoch period (10 days),,0.APPENDIX, +Anticipated changes in traffic demands,Anticipated changes in traffic demands,,0.APPENDIX, +Cardano Community requests,Cardano Community requests,,0.APPENDIX, +Counter-indicators,Counter-indicators,,0.APPENDIX, +Changes may need to be reversed and/or should not be enacted in the event of:,Changes may need to be reversed and/or should not be enacted in the event of:,,0.APPENDIX, +Excessive block propagation delays,Excessive block propagation delays,,0.APPENDIX, +Stake pools being unable to handle traffic volume,Stake pools being unable to handle traffic volume,,0.APPENDIX, +Scripts being unable to complete execution,Scripts being unable to complete execution,,0.APPENDIX, +Core Metrics,Core Metrics,,0.APPENDIX, +All decisions on parameter changes should be informed by:,All decisions on parameter changes should be informed by:,,0.APPENDIX, +Block propagation delay profile,Block propagation delay profile,,0.APPENDIX, +Traffic volume (block size over time),Traffic volume (block size over time),,0.APPENDIX, +Script volume (size of scripts and execution units),Script volume (size of scripts and execution units),,0.APPENDIX, +Script execution cost benchmarks,Script execution cost benchmarks,,0.APPENDIX, +Block propagation delay/diffusion benchmarks,Block propagation delay/diffusion benchmarks,,0.APPENDIX, +"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.","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.",,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"NETWORK-01 (x - ""should"") No individual network parameter should change more than once per two epochs","NETWORK-01 (x - ""should"") No individual network parameter should change more than once per two epochs",,0.APPENDIX, +"NETWORK-02 (x - ""should"") Only one network parameter should be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits","NETWORK-02 (x - ""should"") Only one network parameter should be changed per epoch unless they are directly correlated, e.g., per-transaction and per-block memory unit limits",,0.APPENDIX, +Changes to Specific Network Parameters,Changes to Specific Network Parameters,,0.APPENDIX, +Block Size (maxBlockBodySize),Block Size (maxBlockBodySize),,0.APPENDIX, +"The maximum size of a block, in Bytes.","The maximum size of a block, in Bytes.",,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"MBBS-01 (y) maxBlockBodySize must not exceed 122,880 Bytes (120KB)","MBBS-01 (y) maxBlockBodySize must not exceed 122,880 Bytes (120KB)",,0.APPENDIX, +"MBBS-02 (y) maxBlockBodySize must not be lower than 24,576 Bytes (24KB)","MBBS-02 (y) maxBlockBodySize must not be lower than 24,576 Bytes (24KB)",,0.APPENDIX, +"MBBS-03a (x - ""exceptional circumstances"") maxBlockBodySize must not be decreased, other than in exceptional circumstances where there are potential problems with security, performance, functionality or long-term sustainability","MBBS-03a (x - ""exceptional circumstances"") maxBlockBodySize must not be decreased, other than in exceptional circumstances where there are potential problems with security, performance, functionality or long-term sustainability",,0.APPENDIX, +"MBBS-04 (~ - no access to existing parameter values) maxBlockBodySize must be large enough to include at least one transaction (that is, maxBlockBodySize must be at least maxTxSize)","MBBS-04 (~ - no access to existing parameter values) maxBlockBodySize must be large enough to include at least one transaction (that is, maxBlockBodySize must be at least maxTxSize)",,0.APPENDIX, +"MBBS-05 (x - ""should"") maxBlockBodySize should be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch","MBBS-05 (x - ""should"") maxBlockBodySize should be changed by at most 10,240 Bytes (10KB) per epoch (5 days), and preferably by 8,192 Bytes (8KB) or less per epoch",,0.APPENDIX, +"MBBS-06 (x - ""should"") The block size should not induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation and benchmarking","MBBS-06 (x - ""should"") The block size should not induce an additional Transmission Control Protocol (TCP) round trip. Any increase beyond this must be backed by performance analysis, simulation and benchmarking",,0.APPENDIX, +"MBBS-07 (x - ""unquantifiable"") The impact of any change to maxBlockBodySize must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to maxBlockBodySize must also consider future requirements for Plutus script execution (maxBlockExecutionUnits[steps]) against the total block diffusion target of 3s with 95% block propagation within 5s. The limit on maximum block size may be increased in the future if this is supported by benchmarking and monitoring results","MBBS-07 (x - ""unquantifiable"") The impact of any change to maxBlockBodySize must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as described below. Any increase to maxBlockBodySize must also consider future requirements for Plutus script execution (maxBlockExecutionUnits[steps]) against the total block diffusion target of 3s with 95% block propagation within 5s. The limit on maximum block size may be increased in the future if this is supported by benchmarking and monitoring results",,0.APPENDIX, +Transaction Size (maxTxSize),Transaction Size (maxTxSize),,0.APPENDIX, +"The maximum size of a transaction, in Bytes.","The maximum size of a transaction, in Bytes.",,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"MTS-01 (y) maxTxSize must not exceed 32,768 Bytes (32KB)","MTS-01 (y) maxTxSize must not exceed 32,768 Bytes (32KB)",,0.APPENDIX, +MTS-02 (y) maxTxSize must not be negative,MTS-02 (y) maxTxSize must not be negative,,0.APPENDIX, +MTS-03 (~ - no access to existing parameter values) maxTxSize must not be decreased,MTS-03 (~ - no access to existing parameter values) maxTxSize must not be decreased,,0.APPENDIX, +MTS-04 (~ - no access to existing parameter values) maxTxSize must not exceed maxBlockBodySize,MTS-04 (~ - no access to existing parameter values) maxTxSize must not exceed maxBlockBodySize,,0.APPENDIX, +"MTS-05 (x - ""should"") maxTxSize should not be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably should be increased by 2,048 Bytes (2KB) or less per epoch","MTS-05 (x - ""should"") maxTxSize should not be increased by more than 2,560 Bytes (2.5KB) in any epoch, and preferably should be increased by 2,048 Bytes (2KB) or less per epoch",,0.APPENDIX, +"MTS-06 (x - ""should"") maxTxSize should not exceed 1/4 of the block size","MTS-06 (x - ""should"") maxTxSize should not exceed 1/4 of the block size",,0.APPENDIX, +"Memory Unit Limits (maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory])","Memory Unit Limits (maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory])",,0.APPENDIX, +"The limit on the maximum number of memory units that can be used by Plutus scripts, either per-transaction or per-block.","The limit on the maximum number of memory units that can be used by Plutus scripts, either per-transaction or per-block.",,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"MTEU-M-01 (y) maxTxExecutionUnits[memory] must not exceed 40,000,000 units","MTEU-M-01 (y) maxTxExecutionUnits[memory] must not exceed 40,000,000 units",,0.APPENDIX, +MTEU-M-02 (y) maxTxExecutionUnits[memory] must not be negative,MTEU-M-02 (y) maxTxExecutionUnits[memory] must not be negative,,0.APPENDIX, +MTEU-M-03 (~ - no access to existing parameter values) maxTxExecutionUnits[memory] must not be decreased,MTEU-M-03 (~ - no access to existing parameter values) maxTxExecutionUnits[memory] must not be decreased,,0.APPENDIX, +"MTEU-M-04 (x - ""should"") maxTxExecutionUnits[memory] should not be increased by more than 2,500,000 units in any epoch","MTEU-M-04 (x - ""should"") maxTxExecutionUnits[memory] should not be increased by more than 2,500,000 units in any epoch",,0.APPENDIX, +"MBEU-M-01 (y) maxBlockExecutionUnits[memory] must not exceed 120,000,000 units","MBEU-M-01 (y) maxBlockExecutionUnits[memory] must not exceed 120,000,000 units",,0.APPENDIX, +MBEU-M-02 (y) maxBlockExecutionUnits[memory] must not be negative,MBEU-M-02 (y) maxBlockExecutionUnits[memory] must not be negative,,0.APPENDIX, +"MBEU-M-03 (x - ""should"") maxBlockExecutionUnits[memory] should not be changed (increased or decreased) by more than 10,000,000 units in ANY epoch","MBEU-M-03 (x - ""should"") maxBlockExecutionUnits[memory] should not be changed (increased or decreased) by more than 10,000,000 units in ANY epoch",,0.APPENDIX, +"MBEU-M-04a (x - unquantifiable) The impact of any change to maxBlockExecutionUnits[memory] must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by maxBlockExecutionUnits[steps] and maxBlockBodySize. Any increase must also consider previously agreed future requirements for the total block size (maxBlockBodySize) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block memory limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements","MBEU-M-04a (x - unquantifiable) The impact of any change to maxBlockExecutionUnits[memory] must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by maxBlockExecutionUnits[steps] and maxBlockBodySize. Any increase must also consider previously agreed future requirements for the total block size (maxBlockBodySize) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block memory limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements",,0.APPENDIX, +MEU-M-01 (~ - no access to existing parameter values) maxBlockExecutionUnits[memory] must not be less than maxTxExecutionUnits[memory],MEU-M-01 (~ - no access to existing parameter values) maxBlockExecutionUnits[memory] must not be less than maxTxExecutionUnits[memory],,0.APPENDIX, +"CPU Unit Limits (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps])","CPU Unit Limits (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps])",,0.APPENDIX, +"The limit on the maximum number of CPU steps that can be used by Plutus scripts, either per transaction or per-block.","The limit on the maximum number of CPU steps that can be used by Plutus scripts, either per transaction or per-block.",,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"MTEU-S-01 (y) maxTxExecutionUnits[steps] must not exceed 15,000,000,000 (15Bn) units","MTEU-S-01 (y) maxTxExecutionUnits[steps] must not exceed 15,000,000,000 (15Bn) units",,0.APPENDIX, +MTEU-S-02 (y) maxTxExecutionUnits[steps] must not be negative,MTEU-S-02 (y) maxTxExecutionUnits[steps] must not be negative,,0.APPENDIX, +MTEU-S-03 (~ - no access to existing parameter values) maxTxExecutionUnits[steps] must not be decreased,MTEU-S-03 (~ - no access to existing parameter values) maxTxExecutionUnits[steps] must not be decreased,,0.APPENDIX, +"MTEU-S-04 (x - ""should"") maxTxExecutionUnits[steps] should not be increased by more than 500,000,000 (500M) units in any epoch (5 days)","MTEU-S-04 (x - ""should"") maxTxExecutionUnits[steps] should not be increased by more than 500,000,000 (500M) units in any epoch (5 days)",,0.APPENDIX, +"MBEU-S-01 (y) maxBlockExecutionUnits[steps] must not exceed 40,000,000,000 (40Bn) units","MBEU-S-01 (y) maxBlockExecutionUnits[steps] must not exceed 40,000,000,000 (40Bn) units",,0.APPENDIX, +MBEU-S-02 (y) maxBlockExecutionUnits[steps] must not be negative,MBEU-S-02 (y) maxBlockExecutionUnits[steps] must not be negative,,0.APPENDIX, +"MBEU-S-03 (x - ""should"") maxBlockExecutionUnits[steps] should not be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days)","MBEU-S-03 (x - ""should"") maxBlockExecutionUnits[steps] should not be changed (increased or decreased) by more than 2,000,000,000 (2Bn) units in any epoch (5 days)",,0.APPENDIX, +"MBEU-S-04a (x - unquantifiable) The impact of the change to maxBlockExecutionUnits[steps] must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by maxBlockExecutionUnits[memory] and maxBlockBodySize. Any increase must also consider previously identified future requirements for the total block size (maxBlockBodySize) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block step limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements","MBEU-S-04a (x - unquantifiable) The impact of the change to maxBlockExecutionUnits[steps] must be confirmed by detailed benchmarking/simulation and not exceed the requirements of the block diffusion/propagation time budgets, as also impacted by maxBlockExecutionUnits[memory] and maxBlockBodySize. Any increase must also consider previously identified future requirements for the total block size (maxBlockBodySize) measured against the total block diffusion target of 3s with 95% block propagation within 5s. Future Plutus performance improvements may allow the per-block step limit to be increased, but must be balanced against the overall diffusion limits as specified in the previous sentence, and future requirements",,0.APPENDIX, +MEU-S-01 (~ - no access to existing parameter values) maxBlockExecutionUnits[steps] must not be less than maxTxExecutionUnits[steps],MEU-S-01 (~ - no access to existing parameter values) maxBlockExecutionUnits[steps] must not be less than maxTxExecutionUnits[steps],,0.APPENDIX, +Block Header Size (maxBlockHeaderSize),Block Header Size (maxBlockHeaderSize),,0.APPENDIX, +The size of the block header.,The size of the block header.,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"MBHS-01 (y) maxBlockHeaderSize must not exceed 5,000 Bytes","MBHS-01 (y) maxBlockHeaderSize must not exceed 5,000 Bytes",,0.APPENDIX, +MBHS-02 (y) maxBlockHeaderSize must not be negative,MBHS-02 (y) maxBlockHeaderSize must not be negative,,0.APPENDIX, +"MBHS-03 (x - ""largest valid header"" is subject to change) maxBlockHeaderSize must be large enough for the largest valid header","MBHS-03 (x - ""largest valid header"" is subject to change) maxBlockHeaderSize must be large enough for the largest valid header",,0.APPENDIX, +"MBHS-04 (x - ""should"") maxBlockHeaderSize should only normally be increased if the protocol changes","MBHS-04 (x - ""should"") maxBlockHeaderSize should only normally be increased if the protocol changes",,0.APPENDIX, +"MBHS-05 (x - ""should"") maxBlockHeaderSize should be within TCP's initial congestion window (3 or 10 MTUs)","MBHS-05 (x - ""should"") maxBlockHeaderSize should be within TCP's initial congestion window (3 or 10 MTUs)",,0.APPENDIX, +2.4. Technical/Security Parameters,2.4. Technical/Security Parameters,,0.APPENDIX, +The overall goals when managing the technical/security parameters are:,The overall goals when managing the technical/security parameters are:,,0.APPENDIX, +Ensure the security of the Cardano Blockchain network in terms of decentralization and protection against adversarial actions,Ensure the security of the Cardano Blockchain network in terms of decentralization and protection against adversarial actions,,0.APPENDIX, +Enable changes to the Plutus language,Enable changes to the Plutus language,,0.APPENDIX, +Triggers for Change,Triggers for Change,,0.APPENDIX, +Changes in the number of active SPOs,Changes in the number of active SPOs,,0.APPENDIX, +Changes to the Plutus language,Changes to the Plutus language,,0.APPENDIX, +Security threats,Security threats,,0.APPENDIX, +Cardano Community requests,Cardano Community requests,,0.APPENDIX, +Counter-indicators,Counter-indicators,,0.APPENDIX, +"Economic concerns, e.g. when changing the number of stake pools","Economic concerns, e.g. when changing the number of stake pools",,0.APPENDIX, +Core Metrics,Core Metrics,,0.APPENDIX, +Number of stake pools,Number of stake pools,,0.APPENDIX, +Level of decentralization,Level of decentralization,,0.APPENDIX, +Changes to Specific Technical/Security Parameters,Changes to Specific Technical/Security Parameters,,0.APPENDIX, +Target Number of Stake Pools (stakePoolTargetNum),Target Number of Stake Pools (stakePoolTargetNum),,0.APPENDIX, +Sets the target number of stake pools,Sets the target number of stake pools,,0.APPENDIX, +The expected number of stake pools when the network is in the equilibrium state,The expected number of stake pools when the network is in the equilibrium state,,0.APPENDIX, +"Primarily a security parameter, ensuring decentralization by stake pool division/replication","Primarily a security parameter, ensuring decentralization by stake pool division/replication",,0.APPENDIX, +Has an economic effect as well as a security effect - economic advice is also required when changing this parameter,Has an economic effect as well as a security effect - economic advice is also required when changing this parameter,,0.APPENDIX, +Large changes in this parameter will trigger mass redelegation events,Large changes in this parameter will trigger mass redelegation events,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +SPTN-01 (y) stakePoolTargetNum must not be lower than 250,SPTN-01 (y) stakePoolTargetNum must not be lower than 250,,0.APPENDIX, +"SPTN-02 (y) stakePoolTargetNum must not exceed 2,000","SPTN-02 (y) stakePoolTargetNum must not exceed 2,000",,0.APPENDIX, +SPTN-03 (y) stakePoolTargetNum must not be negative,SPTN-03 (y) stakePoolTargetNum must not be negative,,0.APPENDIX, +SPTN-04 (y) stakePoolTargetNum must not be zero,SPTN-04 (y) stakePoolTargetNum must not be zero,,0.APPENDIX, +Pledge Influence Factor (poolPledgeInfluence),Pledge Influence Factor (poolPledgeInfluence),,0.APPENDIX, +Enables the pledge protection mechanism,Enables the pledge protection mechanism,,0.APPENDIX, +Provides protection against Sybil attack,Provides protection against Sybil attack,,0.APPENDIX, +Higher values reward pools that have more pledge and penalize pools that have less pledge,Higher values reward pools that have more pledge and penalize pools that have less pledge,,0.APPENDIX, +Has an economic effect as well as technical effect - economic advice is also required,Has an economic effect as well as technical effect - economic advice is also required,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +PPI-01 (y) poolPledgeInfluence must not be lower than 0.1,PPI-01 (y) poolPledgeInfluence must not be lower than 0.1,,0.APPENDIX, +PPI-02 (y) poolPledgeInfluence must not exceed 1.0,PPI-02 (y) poolPledgeInfluence must not exceed 1.0,,0.APPENDIX, +PPI-03 (y) poolPledgeInfluence must not be negative,PPI-03 (y) poolPledgeInfluence must not be negative,,0.APPENDIX, +"PPI-04 (x - ""should"") poolPledgeInfluence should not vary by more than +/- 10% in any 18-epoch period (approximately 3 months)","PPI-04 (x - ""should"") poolPledgeInfluence should not vary by more than +/- 10% in any 18-epoch period (approximately 3 months)",,0.APPENDIX, +Pool Retirement Window (poolRetireMaxEpoch),Pool Retirement Window (poolRetireMaxEpoch),,0.APPENDIX, +Defines the maximum number of epochs notice that a pool can give when planning to retire,Defines the maximum number of epochs notice that a pool can give when planning to retire,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +PRME-01 (y) poolRetireMaxEpoch must not be negative,PRME-01 (y) poolRetireMaxEpoch must not be negative,,0.APPENDIX, +"PRME-02 (x - ""should"") poolRetireMaxEpoch should not be lower than 1","PRME-02 (x - ""should"") poolRetireMaxEpoch should not be lower than 1",,0.APPENDIX, +Collateral Percentage (collateralPercentage),Collateral Percentage (collateralPercentage),,0.APPENDIX, +Defines how much collateral must be provided when executing a Plutus script as a percentage of the normal execution cost,Defines how much collateral must be provided when executing a Plutus script as a percentage of the normal execution cost,,0.APPENDIX, +Collateral is additional to fee payments,Collateral is additional to fee payments,,0.APPENDIX, +"If a script fails to execute, then the collateral is lost","If a script fails to execute, then the collateral is lost",,0.APPENDIX, +The collateral is never lost if a script executes successfully,The collateral is never lost if a script executes successfully,,0.APPENDIX, +Provides security against low-cost attacks by making it more expensive rather than less expensive to execute failed scripts,Provides security against low-cost attacks by making it more expensive rather than less expensive to execute failed scripts,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +CP-01 (y) collateralPercentage must not be lower than 100,CP-01 (y) collateralPercentage must not be lower than 100,,0.APPENDIX, +CP-02 (y) collateralPercentage must not exceed 200,CP-02 (y) collateralPercentage must not exceed 200,,0.APPENDIX, +CP-03 (y) collateralPercentage must not be negative,CP-03 (y) collateralPercentage must not be negative,,0.APPENDIX, +CP-04 (y) collateralPercentage must not be zero,CP-04 (y) collateralPercentage must not be zero,,0.APPENDIX, +Maximum number of collateral inputs (maxCollateralInputs),Maximum number of collateral inputs (maxCollateralInputs),,0.APPENDIX, +Defines the maximum number of inputs that can be used for collateral when executing a Plutus script,Defines the maximum number of inputs that can be used for collateral when executing a Plutus script,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +MCI-01 (y) maxCollateralInputs must not be lower than 1,MCI-01 (y) maxCollateralInputs must not be lower than 1,,0.APPENDIX, +Maximum Value Size (maxValueSize),Maximum Value Size (maxValueSize),,0.APPENDIX, +The limit on the serialized size of the Value in each output.,The limit on the serialized size of the Value in each output.,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"MVS-01 (y) maxValueSize must not exceed 12,288 Bytes (12KB)","MVS-01 (y) maxValueSize must not exceed 12,288 Bytes (12KB)",,0.APPENDIX, +MVS-02 (y) maxValueSize must not be negative,MVS-02 (y) maxValueSize must not be negative,,0.APPENDIX, +MVS-03 (~ - no access to existing parameter values) maxValueSize must be less than maxTxSize,MVS-03 (~ - no access to existing parameter values) maxValueSize must be less than maxTxSize,,0.APPENDIX, +MVS-04 (~ - no access to existing parameter values) maxValueSize must not be reduced,MVS-04 (~ - no access to existing parameter values) maxValueSize must not be reduced,,0.APPENDIX, +"MVS-05 (x - ""sensible output"" is subject to interpretation) maxValueSize must be large enough to allow sensible outputs (e.g. any existing on-chain output or anticipated outputs that could be produced by new ledger rules)","MVS-05 (x - ""sensible output"" is subject to interpretation) maxValueSize must be large enough to allow sensible outputs (e.g. any existing on-chain output or anticipated outputs that could be produced by new ledger rules)",,0.APPENDIX, +Plutus Cost Models (costModels),Plutus Cost Models (costModels),,0.APPENDIX, +Define the base costs for each Plutus primitive in terms of CPU and memory unit,Define the base costs for each Plutus primitive in terms of CPU and memory unit,,0.APPENDIX, +A different cost model is required for each Plutus version. Each cost model comprises many distinct cost model values. Cost models are defined for each Plutus language version. A new language version may introduce additional cost model values or remove existing cost model values.,A different cost model is required for each Plutus version. Each cost model comprises many distinct cost model values. Cost models are defined for each Plutus language version. A new language version may introduce additional cost model values or remove existing cost model values.,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +PCM-01 (x - unquantifiable) Cost model values must be set by benchmarking on a reference architecture,PCM-01 (x - unquantifiable) Cost model values must be set by benchmarking on a reference architecture,,0.APPENDIX, +PCM-02 (x - primitives and language versions aren't introduced in transactions) The cost model must be updated if new primitives are introduced or a new Plutus language version is added,PCM-02 (x - primitives and language versions aren't introduced in transactions) The cost model must be updated if new primitives are introduced or a new Plutus language version is added,,0.APPENDIX, +PCM-03a (~ - no access to Plutus cost model parameters) Cost model values should not normally be negative. Negative values must be justified against the underlying cost model for the associated primitives,PCM-03a (~ - no access to Plutus cost model parameters) Cost model values should not normally be negative. Negative values must be justified against the underlying cost model for the associated primitives,,0.APPENDIX, +PCM-04 (~ - no access to Plutus cost model parameters) A cost model must be supplied for each Plutus language version that the protocol supports,PCM-04 (~ - no access to Plutus cost model parameters) A cost model must be supplied for each Plutus language version that the protocol supports,,0.APPENDIX, +2.5. Governance Parameters,2.5. Governance Parameters,,0.APPENDIX, +The overall goals when managing the governance parameters are to:,The overall goals when managing the governance parameters are to:,,0.APPENDIX, +Ensure governance stability,Ensure governance stability,,0.APPENDIX, +Maintain a representative form of governance,Maintain a representative form of governance,,0.APPENDIX, +Triggers for Change,Triggers for Change,,0.APPENDIX, +Changes to governance parameters may be triggered by:,Changes to governance parameters may be triggered by:,,0.APPENDIX, +Cardano Community requests,Cardano Community requests,,0.APPENDIX, +Regulatory requirements,Regulatory requirements,,0.APPENDIX, +Unexpected or unwanted governance outcomes,Unexpected or unwanted governance outcomes,,0.APPENDIX, +Entering a state of no confidence,Entering a state of no confidence,,0.APPENDIX, +Counter-indicators,Counter-indicators,,0.APPENDIX, +Changes may need to be reversed and/or should not be enacted in the event of:,Changes may need to be reversed and/or should not be enacted in the event of:,,0.APPENDIX, +Unexpected effects on governance,Unexpected effects on governance,,0.APPENDIX, +Excessive Layer 1 load due to on-chain voting or excessive numbers of governance actions,Excessive Layer 1 load due to on-chain voting or excessive numbers of governance actions,,0.APPENDIX, +Core Metrics,Core Metrics,,0.APPENDIX, +All decisions on parameter changes should be informed by:,All decisions on parameter changes should be informed by:,,0.APPENDIX, +Governance participation levels,Governance participation levels,,0.APPENDIX, +Governance behaviors and patterns,Governance behaviors and patterns,,0.APPENDIX, +Regulatory considerations,Regulatory considerations,,0.APPENDIX, +Confidence in the governance system,Confidence in the governance system,,0.APPENDIX, +The effectiveness of the governance system in managing necessary change,The effectiveness of the governance system in managing necessary change,,0.APPENDIX, +Changes to Specific Governance Parameters,Changes to Specific Governance Parameters,,0.APPENDIX, +Deposit for Governance Actions (govDeposit),Deposit for Governance Actions (govDeposit),,0.APPENDIX, +The deposit that is charged when submitting a governance action.,The deposit that is charged when submitting a governance action.,,0.APPENDIX, +Helps to limit the number of actions that are submitted,Helps to limit the number of actions that are submitted,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +GD-01 (y) govDeposit must not be negative,GD-01 (y) govDeposit must not be negative,,0.APPENDIX, +"GD-02 (y) govDeposit must not be lower than 1,000,000 (1 ada)","GD-02 (y) govDeposit must not be lower than 1,000,000 (1 ada)",,0.APPENDIX, +"GD-03a (y) govDeposit must not exceed 10,000,000,000,000 (10 million ada)","GD-03a (y) govDeposit must not exceed 10,000,000,000,000 (10 million ada)",,0.APPENDIX, +"GD-04 (x - ""should"") govDeposit should be adjusted in line with fiat changes","GD-04 (x - ""should"") govDeposit should be adjusted in line with fiat changes",,0.APPENDIX, +Deposit for DReps (dRepDeposit),Deposit for DReps (dRepDeposit),,0.APPENDIX, +The deposit that is charged when registering a DRep.,The deposit that is charged when registering a DRep.,,0.APPENDIX, +Helps to limit the number of active DReps,Helps to limit the number of active DReps,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +DRD-01 (y) dRepDeposit must not be negative,DRD-01 (y) dRepDeposit must not be negative,,0.APPENDIX, +"DRD-02 (y) dRepDeposit must not be lower than 1,000,000 (1 ada)","DRD-02 (y) dRepDeposit must not be lower than 1,000,000 (1 ada)",,0.APPENDIX, +"DRD-03 (y) dRepDeposit must not exceed 100,000,000,000 (100,000 ada)","DRD-03 (y) dRepDeposit must not exceed 100,000,000,000 (100,000 ada)",,0.APPENDIX, +"DRD-04 (x - ""should"") dRepDeposit should be adjusted in line with fiat changes","DRD-04 (x - ""should"") dRepDeposit should be adjusted in line with fiat changes",,0.APPENDIX, +DRep Activity Period (dRepActivity),DRep Activity Period (dRepActivity),,0.APPENDIX, +"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.","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.",,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +DRA-01 (y) dRepActivity must not be lower than 13 epochs (2 months),DRA-01 (y) dRepActivity must not be lower than 13 epochs (2 months),,0.APPENDIX, +DRA-02 (y) dRepActivity must not exceed 37 epochs (6 months),DRA-02 (y) dRepActivity must not exceed 37 epochs (6 months),,0.APPENDIX, +DRA-03 (y) dRepActivity must not be negative,DRA-03 (y) dRepActivity must not be negative,,0.APPENDIX, +DRA-04 (~ - no access to existing parameter values) dRepActivity must be greater than govActionLifetime,DRA-04 (~ - no access to existing parameter values) dRepActivity must be greater than govActionLifetime,,0.APPENDIX, +"DRA-05 (x - ""should"") dRepActivity should be calculated in human terms (2 months etc)","DRA-05 (x - ""should"") dRepActivity should be calculated in human terms (2 months etc)",,0.APPENDIX, +"DRep and SPO Governance Action Thresholds (dRepVotingThresholds[...],poolVotingThresholds[...])","DRep and SPO Governance Action Thresholds (dRepVotingThresholds[...],poolVotingThresholds[...])",,0.APPENDIX, +Thresholds on the active voting stake that is required to ratify a specific type of governance action by either DReps or SPOs.,Thresholds on the active voting stake that is required to ratify a specific type of governance action by either DReps or SPOs.,,0.APPENDIX, +Ensures legitimacy of the action,Ensures legitimacy of the action,,0.APPENDIX, +The threshold parameters are listed below:,The threshold parameters are listed below:,,0.APPENDIX, +dRepVotingThresholds:,dRepVotingThresholds:,,0.APPENDIX, +dvtCommitteeNoConfidence,dvtCommitteeNoConfidence,,0.APPENDIX, +dvtCommitteeNormal,dvtCommitteeNormal,,0.APPENDIX, +dvtHardForkInitiation,dvtHardForkInitiation,,0.APPENDIX, +dvtMotionNoConfidence,dvtMotionNoConfidence,,0.APPENDIX, +dvtPPEconomicGroup,dvtPPEconomicGroup,,0.APPENDIX, +dvtPPGovGroup,dvtPPGovGroup,,0.APPENDIX, +dvtPPNetworkGroup,dvtPPNetworkGroup,,0.APPENDIX, +dvtPPTechnicalGroup,dvtPPTechnicalGroup,,0.APPENDIX, +dvtTreasuryWithdrawal,dvtTreasuryWithdrawal,,0.APPENDIX, +dvtUpdateToConstitution,dvtUpdateToConstitution,,0.APPENDIX, +poolVotingThresholds:,poolVotingThresholds:,,0.APPENDIX, +pvtCommitteeNoConfidence,pvtCommitteeNoConfidence,,0.APPENDIX, +pvtCommitteeNormal,pvtCommitteeNormal,,0.APPENDIX, +pvtHardForkInitiation,pvtHardForkInitiation,,0.APPENDIX, +pvtMotionNoConfidence,pvtMotionNoConfidence,,0.APPENDIX, +pvtPPSecurityGroup,pvtPPSecurityGroup,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +VT-GEN-01 (y) All thresholds must be greater than 50% and less than or equal to 100%,VT-GEN-01 (y) All thresholds must be greater than 50% and less than or equal to 100%,,0.APPENDIX, +"VT-GEN-02a (y) Economic, network and technical/security parameter thresholds must be in the range 51%-75%","VT-GEN-02a (y) Economic, network and technical/security parameter thresholds must be in the range 51%-75%",,0.APPENDIX, +VT-GEN-03 (y) Governance parameter thresholds must be in the range 75%-90%,VT-GEN-03 (y) Governance parameter thresholds must be in the range 75%-90%,,0.APPENDIX, +VT-HF-01 (y) Hard fork action thresholds must be in the range 51%-80%,VT-HF-01 (y) Hard fork action thresholds must be in the range 51%-80%,,0.APPENDIX, +VT-CON-01 (y) New Constitution or Guardrails Script action thresholds must be in the range 65%-90%,VT-CON-01 (y) New Constitution or Guardrails Script action thresholds must be in the range 65%-90%,,0.APPENDIX, +VT-CC-01 (y) Update Constitutional Committee action thresholds must be in the range 51%-90%,VT-CC-01 (y) Update Constitutional Committee action thresholds must be in the range 51%-90%,,0.APPENDIX, +VT-NC-01 (y) No confidence action thresholds must be in the range 51%-75%,VT-NC-01 (y) No confidence action thresholds must be in the range 51%-75%,,0.APPENDIX, +Governance Action Lifetime (govActionLifetime),Governance Action Lifetime (govActionLifetime),,0.APPENDIX, +The period after which a governance action will expire if it is not enacted - as a whole number of epochs,The period after which a governance action will expire if it is not enacted - as a whole number of epochs,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +GAL-01 (y) govActionLifetime must not be lower than 1 epoch (5 days),GAL-01 (y) govActionLifetime must not be lower than 1 epoch (5 days),,0.APPENDIX, +"GAL-03 (x - ""should"") govActionLifetime should not be lower than 2 epochs (10 days)","GAL-03 (x - ""should"") govActionLifetime should not be lower than 2 epochs (10 days)",,0.APPENDIX, +GAL-02 (y) govActionLifetime must not exceed 15 epochs (75 days),GAL-02 (y) govActionLifetime must not exceed 15 epochs (75 days),,0.APPENDIX, +"GAL-04 (x - ""should"") govActionLifetime should be calibrated in human terms (eg 30 days, two weeks), to allow sufficient time for voting etc. to take place","GAL-04 (x - ""should"") govActionLifetime should be calibrated in human terms (eg 30 days, two weeks), to allow sufficient time for voting etc. to take place",,0.APPENDIX, +GAL-05 (~ - no access to existing parameter values) govActionLifetime must be less than dRepActivity,GAL-05 (~ - no access to existing parameter values) govActionLifetime must be less than dRepActivity,,0.APPENDIX, +Maximum Constitutional Committee Term (committeeMaxTermLength),Maximum Constitutional Committee Term (committeeMaxTermLength),,0.APPENDIX, +The limit on the maximum term length that a committee member may serve,The limit on the maximum term length that a committee member may serve,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +CMTL-01a (y) committeeMaxTermLength must not be zero,CMTL-01a (y) committeeMaxTermLength must not be zero,,0.APPENDIX, +CMTL-02a (y) committeeMaxTermLength must not be negative,CMTL-02a (y) committeeMaxTermLength must not be negative,,0.APPENDIX, +"CMTL-03a (y) committeeMaxTermLength must not be lower than 18 epochs (90 days, or approximately 3 months)","CMTL-03a (y) committeeMaxTermLength must not be lower than 18 epochs (90 days, or approximately 3 months)",,0.APPENDIX, +CMTL-04a (y) committeeMaxTermLength must not exceed 293 epochs (approximately 4 years),CMTL-04a (y) committeeMaxTermLength must not exceed 293 epochs (approximately 4 years),,0.APPENDIX, +"CMTL-05a (x - ""should"") committeeMaxTermLength should not exceed 220 epochs (approximately 3 years)","CMTL-05a (x - ""should"") committeeMaxTermLength should not exceed 220 epochs (approximately 3 years)",,0.APPENDIX, +The minimum size of the Constitutional Committee (committeeMinSize),The minimum size of the Constitutional Committee (committeeMinSize),,0.APPENDIX, +The least number of members that can be included in a Constitutional Committee following a governance action to change the Constitutional Committee.,The least number of members that can be included in a Constitutional Committee following a governance action to change the Constitutional Committee.,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +CMS-01 (y) committeeMinSize must not be negative,CMS-01 (y) committeeMinSize must not be negative,,0.APPENDIX, +CMS-02 (y) committeeMinSize must not be lower than 3,CMS-02 (y) committeeMinSize must not be lower than 3,,0.APPENDIX, +CMS-03 (y) committeeMinSize must not exceed 10,CMS-03 (y) committeeMinSize must not exceed 10,,0.APPENDIX, +2.6. Monitoring and Reversion of Parameter Changes,2.6. Monitoring and Reversion of Parameter Changes,,0.APPENDIX, +All network parameter changes must be monitored carefully for no less than 2 epochs (10 days),All network parameter changes must be monitored carefully for no less than 2 epochs (10 days),,0.APPENDIX, +Changes must be reverted as soon as possible if block propagation delays exceed 4.5s for more than 5% of blocks over any 6 hour rolling window,Changes must be reverted as soon as possible if block propagation delays exceed 4.5s for more than 5% of blocks over any 6 hour rolling window,,0.APPENDIX, +All other parameter changes should be monitored,All other parameter changes should be monitored,,0.APPENDIX, +"The reversion plan should be implemented if the overall effect on performance, security, functionality or long-term sustainability is unacceptable.","The reversion plan should be implemented if the overall effect on performance, security, functionality or long-term sustainability is unacceptable.",,0.APPENDIX, +A specific reversion/recovery plan must be produced for each parameter change. This plan must include:,A specific reversion/recovery plan must be produced for each parameter change. This plan must include:,,0.APPENDIX, +Which parameters need to change and in which ways in order to return to the previous state (or a similar state),Which parameters need to change and in which ways in order to return to the previous state (or a similar state),,0.APPENDIX, +How to recover the network in the event of disastrous failure,How to recover the network in the event of disastrous failure,,0.APPENDIX, +This plan should be followed if problems are observed following the parameter change. Note that not all changes can be reverted. Additional care must be taken when making changes to these parameters.,This plan should be followed if problems are observed following the parameter change. Note that not all changes can be reverted. Additional care must be taken when making changes to these parameters.,,0.APPENDIX, +2.7. Non-Updatable Protocol Parameters,2.7. Non-Updatable Protocol Parameters,,0.APPENDIX, +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.,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.,,0.APPENDIX, +3. Guardrails and Guidelines on Treasury Withdrawal Actions,3. Guardrails and Guidelines on Treasury Withdrawal Actions,,0.APPENDIX, +Treasury withdrawal actions specify the destination and amount of a number of withdrawals from the Cardano treasury.,Treasury withdrawal actions specify the destination and amount of a number of withdrawals from the Cardano treasury.,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +TREASURY-01a (x) A net change limit for the Cardano treasury's balance per period of time must be agreed by the DReps via an on-chain governance action with a threshold of greater than 50% of the active voting stake,TREASURY-01a (x) A net change limit for the Cardano treasury's balance per period of time must be agreed by the DReps via an on-chain governance action with a threshold of greater than 50% of the active voting stake,,0.APPENDIX, +TREASURY-02a (x) Withdrawals from the Cardano Blockchain treasury made pursuant to an approved Cardano Blockchain ecosystem budget must not exceed the net change limit for the Cardano Treasury's balance per period of time,TREASURY-02a (x) Withdrawals from the Cardano Blockchain treasury made pursuant to an approved Cardano Blockchain ecosystem budget must not exceed the net change limit for the Cardano Treasury's balance per period of time,,0.APPENDIX, +TREASURY-03a (x) Withdrawals from the Cardano Blockchain treasury must be denominated in ada,TREASURY-03a (x) Withdrawals from the Cardano Blockchain treasury must be denominated in ada,,0.APPENDIX, +TREASURY-04a (x) Withdrawals from the Cardano Blockchain treasury must not be ratified until there is a Cardano Community approved Cardano Blockchain ecosystem 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,TREASURY-04a (x) Withdrawals from the Cardano Blockchain treasury must not be ratified until there is a Cardano Community approved Cardano Blockchain ecosystem 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,,0.APPENDIX, +4. Guardrails and Guidelines on Hard Fork Initiation Actions,4. Guardrails and Guidelines on Hard Fork Initiation Actions,,0.APPENDIX, +The hard fork initiation action requires both a new major and a new minor protocol version to be specified.,The hard fork initiation action requires both a new major and a new minor protocol version to be specified.,,0.APPENDIX, +As positive integers,As positive integers,,0.APPENDIX, +"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.","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.",,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +"HARDFORK-01 (~ - no access to existing parameter values) The major protocol version must be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version must be zero","HARDFORK-01 (~ - no access to existing parameter values) The major protocol version must be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version must be zero",,0.APPENDIX, +"HARDFORK-02a (~ - no access to existing parameter values) Unless the major protocol version is also changed, the minor protocol version must be greater than the minor version that will be enacted immediately prior to this change","HARDFORK-02a (~ - no access to existing parameter values) Unless the major protocol version is also changed, the minor protocol version must be greater than the minor version that will be enacted immediately prior to this change",,0.APPENDIX, +HARDFORK-03 (~ - no access to existing parameter values) At least one of the protocol versions (major or minor or both) must change,HARDFORK-03 (~ - no access to existing parameter values) At least one of the protocol versions (major or minor or both) must change,,0.APPENDIX, +HARDFORK-04a (x) At least 85% of stake pools by active stake should have upgraded to a Cardano Blockchain node version that is capable of processing the rules associated with the new protocol version,HARDFORK-04a (x) At least 85% of stake pools by active stake should have upgraded to a Cardano Blockchain node version that is capable of processing the rules associated with the new protocol version,,0.APPENDIX, +HARDFORK-05 (x) Any new updatable protocol parameters that are introduced with a hard fork must be included in this Appendix and suitable guardrails defined for those parameters,HARDFORK-05 (x) Any new updatable protocol parameters that are introduced with a hard fork must be included in this Appendix and suitable guardrails defined for those parameters,,0.APPENDIX, +HARDFORK-06 (x) Settings for any new protocol parameters that are introduced with a hard fork must be included in the appropriate Genesis file,HARDFORK-06 (x) Settings for any new protocol parameters that are introduced with a hard fork must be included in the appropriate Genesis file,,0.APPENDIX, +HARDFORK-07 (x) Any deprecated protocol parameters must be indicated in this Appendix,HARDFORK-07 (x) Any deprecated protocol parameters must be indicated in this Appendix,,0.APPENDIX, +HARDFORK-08 (~ - no access to Plutus cost model parameters) New Plutus versions must be supported by a version-specific Plutus cost model that covers each primitive that is available in the new Plutus version,HARDFORK-08 (~ - no access to Plutus cost model parameters) New Plutus versions must be supported by a version-specific Plutus cost model that covers each primitive that is available in the new Plutus version,,0.APPENDIX, +5. Guardrails and Guidelines on Update Constitutional Committee or Threshold Actions,5. Guardrails and Guidelines on Update Constitutional Committee or Threshold Actions,,0.APPENDIX, +"Update Constitutional Committee or Threshold governance actions may change the size, composition or required voting thresholds for the Constitutional Committee.","Update Constitutional Committee or Threshold governance actions may change the size, composition or required voting thresholds for the Constitutional Committee.",,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +UPDATE-CC-01a (x) Update Constitutional Committee and/or threshold and/or term governance actions must not be ratified until ada holders have ratified through an on-chain governance action this Constitution,UPDATE-CC-01a (x) Update Constitutional Committee and/or threshold and/or term governance actions must not be ratified until ada holders have ratified through an on-chain governance action this Constitution,,0.APPENDIX, +6. Guardrails and Guidelines on New Constitution or Guardrails Script Actions,6. Guardrails and Guidelines on New Constitution or Guardrails Script Actions,,0.APPENDIX, +New constitution or Guardrails Script actions change the hash of the on-chain Constitution and the associated Guardrails Script.,New constitution or Guardrails Script actions change the hash of the on-chain Constitution and the associated Guardrails Script.,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +NEW-CONSTITUTION-01a (x) A New Constitution or Guardrails Script governance action must be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action,NEW-CONSTITUTION-01a (x) A New Constitution or Guardrails Script governance action must be submitted to define any required guardrails for new parameters that are introduced via a Hard Fork governance action,,0.APPENDIX, +"NEW-CONSTITUTION-02 (x) If specified, the new Guardrails Script must be consistent with this Constitution","NEW-CONSTITUTION-02 (x) If specified, the new Guardrails Script must be consistent with this Constitution",,0.APPENDIX, +7. Guardrails and Guidelines on No Confidence Actions,7. Guardrails and Guidelines on No Confidence Actions,,0.APPENDIX, +No confidence actions signal a state of no confidence in the governance system. No guardrails are imposed on No Confidence actions.,No confidence actions signal a state of no confidence in the governance system. No guardrails are imposed on No Confidence actions.,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +None,None,,0.APPENDIX, +8. GUARDRAILS AND GUIDELINES ON INFO ACTIONS,8. GUARDRAILS AND GUIDELINES ON INFO ACTIONS,,0.APPENDIX, +Info actions are not enacted on-chain. No guardrails are imposed on Info actions.,Info actions are not enacted on-chain. No guardrails are imposed on Info actions.,,0.APPENDIX, +GUARDRAILS,GUARDRAILS,,0.APPENDIX, +None,None,,0.APPENDIX, +9. List of Protocol Parameter Groups,9. List of Protocol Parameter Groups,,0.APPENDIX, +"The protocol parameters are grouped by type, allowing different thresholds to be set for each group.","The protocol parameters are grouped by type, allowing different thresholds to be set for each group.",,0.APPENDIX, +The network parameter group consists of:,The network parameter group consists of:,,0.APPENDIX, +maximum block body size (maxBlockBodySize),maximum block body size (maxBlockBodySize),,0.APPENDIX, +maximum transaction size (maxTxSize),maximum transaction size (maxTxSize),,0.APPENDIX, +maximum block header size (maxBlockHeaderSize),maximum block header size (maxBlockHeaderSize),,0.APPENDIX, +maximum size of a serialized asset value (maxValueSize),maximum size of a serialized asset value (maxValueSize),,0.APPENDIX, +maximum script execution units in a single transaction (maxTxExecutionUnits[steps]),maximum script execution units in a single transaction (maxTxExecutionUnits[steps]),,0.APPENDIX, +maximum script execution units in a single block (maxBlockExecutionUnits[steps]),maximum script execution units in a single block (maxBlockExecutionUnits[steps]),,0.APPENDIX, +maximum number of collateral inputs (maxCollateralInputs),maximum number of collateral inputs (maxCollateralInputs),,0.APPENDIX, +The economic parameter group consists of:,The economic parameter group consists of:,,0.APPENDIX, +minimum fee coefficient (txFeePerByte),minimum fee coefficient (txFeePerByte),,0.APPENDIX, +minimum fee constant (txFeeFixed),minimum fee constant (txFeeFixed),,0.APPENDIX, +minimum fee per byte for reference scripts (minFeeRefScriptCoinsPerByte),minimum fee per byte for reference scripts (minFeeRefScriptCoinsPerByte),,0.APPENDIX, +delegation key lovelace deposit (stakeAddressDeposit),delegation key lovelace deposit (stakeAddressDeposit),,0.APPENDIX, +pool registration lovelace deposit (stakePoolDeposit),pool registration lovelace deposit (stakePoolDeposit),,0.APPENDIX, +monetary expansion (monetaryExpansion),monetary expansion (monetaryExpansion),,0.APPENDIX, +treasury expansion (treasuryCut),treasury expansion (treasuryCut),,0.APPENDIX, +minimum fixed rewards cut for pools (minPoolCost),minimum fixed rewards cut for pools (minPoolCost),,0.APPENDIX, +minimum lovelace deposit per byte of serialized UTxO (coinsPerUTxOByte),minimum lovelace deposit per byte of serialized UTxO (coinsPerUTxOByte),,0.APPENDIX, +prices of Plutus execution units (executionUnitPrices[priceSteps/priceMemory]),prices of Plutus execution units (executionUnitPrices[priceSteps/priceMemory]),,0.APPENDIX, +The technical/security parameter group consists of:,The technical/security parameter group consists of:,,0.APPENDIX, +pool pledge influence (poolPledgeInfluence),pool pledge influence (poolPledgeInfluence),,0.APPENDIX, +pool retirement maximum epoch (poolRetireMaxEpoch),pool retirement maximum epoch (poolRetireMaxEpoch),,0.APPENDIX, +desired number of pools (stakePoolTargetNum),desired number of pools (stakePoolTargetNum),,0.APPENDIX, +Plutus execution cost models (costModels),Plutus execution cost models (costModels),,0.APPENDIX, +proportion of collateral needed for scripts (collateralPercentage),proportion of collateral needed for scripts (collateralPercentage),,0.APPENDIX, +The governance parameter group consists of:,The governance parameter group consists of:,,0.APPENDIX, +"governance voting thresholds (dRepVotingThresholds[...], poolVotingThresholds[...])","governance voting thresholds (dRepVotingThresholds[...], poolVotingThresholds[...])",,0.APPENDIX, +governance action maximum lifetime in epochs (govActionLifetime),governance action maximum lifetime in epochs (govActionLifetime),,0.APPENDIX, +governance action deposit* (govActionDeposit),governance action deposit* (govActionDeposit),,0.APPENDIX, +DRep deposit amount (dRepDeposit),DRep deposit amount (dRepDeposit),,0.APPENDIX, +DRep activity period in epochs (dRepActivity),DRep activity period in epochs (dRepActivity),,0.APPENDIX, +minimal constitutional committee size (committeeMinSize),minimal constitutional committee size (committeeMinSize),,0.APPENDIX, +maximum term length (in epochs) for the constitutional committee members (committeeMaxTermLength),maximum term length (in epochs) for the constitutional committee members (committeeMaxTermLength),,0.APPENDIX, +APPENDIX II: SUPPORTING GUIDANCE,APPENDIX II: SUPPORTING GUIDANCE,,0.APPENDIX, +This Appendix II is intended to provide guidance in interpreting the Constitution and the Constitutional Committee shall consider this Appendix II as it deems relevant and useful in carrying out its constitutional duties.,This Appendix II is intended to provide guidance in interpreting the Constitution and the Constitutional Committee shall consider this Appendix II as it deems relevant and useful in carrying out its constitutional duties.,,0.APPENDIX, +1. Framing Notes,1. Framing Notes,,0.APPENDIX, +"The Cardano Blockchain was established in 2017. In July 2020 the Cardano Blockchain was expanded to include independent block validators and in September 2024 an on-chain governance system was introduced. This Constitution outlines the rights and responsibilities of governance actors in the decentralized system who represent the owners of ada, the governance token of the Cardano Blockchain. The Cardano Blockchain is presently a decentralized ecosystem of blockchain technology, smart contracts, and community governance.","The Cardano Blockchain was established in 2017. In July 2020 the Cardano Blockchain was expanded to include independent block validators and in September 2024 an on-chain governance system was introduced. This Constitution outlines the rights and responsibilities of governance actors in the decentralized system who represent the owners of ada, the governance token of the Cardano Blockchain. The Cardano Blockchain is presently a decentralized ecosystem of blockchain technology, smart contracts, and community governance.",,0.APPENDIX, +"In approaching this Constitution, the Cardano Community recognizes that it must be remembered that this is not a constitution for only a blockchain but rather a constitution for a blockchain ecosystem – a much more ambitious endeavor. Accordingly, how governance actions are approved, while extremely important, is not the sole focus of this Constitution. Rather, this Constitution provides the basis and fundamental framework through which all participants in the Cardano Community can come together to govern themselves and form radically new approaches to human interaction and collaboration.","In approaching this Constitution, the Cardano Community recognizes that it must be remembered that this is not a constitution for only a blockchain but rather a constitution for a blockchain ecosystem – a much more ambitious endeavor. Accordingly, how governance actions are approved, while extremely important, is not the sole focus of this Constitution. Rather, this Constitution provides the basis and fundamental framework through which all participants in the Cardano Community can come together to govern themselves and form radically new approaches to human interaction and collaboration.",,0.APPENDIX, +"By necessity, this Constitution recognizes the role of and empowers the Constitutional Committee, confirms the right of the Cardano Community to participate in collective bodies for collaboration, gives effect to on-chain governance, and empowers DReps to act as the voice of ada owners for on-chain voting.","By necessity, this Constitution recognizes the role of and empowers the Constitutional Committee, confirms the right of the Cardano Community to participate in collective bodies for collaboration, gives effect to on-chain governance, and empowers DReps to act as the voice of ada owners for on-chain voting.",,0.APPENDIX, +The Constitution also recognizes the necessity of safeguarding access to and the use of funds of the Cardano Blockchain treasury through the inclusion of the Cardano Blockchain Guardrails in this Constitution.,The Constitution also recognizes the necessity of safeguarding access to and the use of funds of the Cardano Blockchain treasury through the inclusion of the Cardano Blockchain Guardrails in this Constitution.,,0.APPENDIX, +2. Other Guidance,2. Other Guidance,,0.APPENDIX, +"The drafters of the Constitution, together with other participants from the Cardano Community, have published and in the future may publish guidance for interpreting the Constitution, including, without limitation, a definition booklet that has been released contemporaneously with the on-chain ratification of the Constitution. So long as any such published guidance has been hashed to the Cardano Blockchain pursuant to an ""Info"" action, the Constitutional Committee shall not be precluded from considering and utilizing such guidance as it deems appropriate.","The drafters of the Constitution, together with other participants from the Cardano Community, have published and in the future may publish guidance for interpreting the Constitution, including, without limitation, a definition booklet that has been released contemporaneously with the on-chain ratification of the Constitution. So long as any such published guidance has been hashed to the Cardano Blockchain pursuant to an ""Info"" action, the Constitutional Committee shall not be precluded from considering and utilizing such guidance as it deems appropriate.",,0.APPENDIX, \ No newline at end of file