diff --git a/CIP-0001/README.md b/CIP-0001/README.md index b6e010b4c..0f2de7c00 100644 --- a/CIP-0001/README.md +++ b/CIP-0001/README.md @@ -83,7 +83,7 @@ Motivation: why is this CIP necessary? | A clear explanation that intro Specification | The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely based on the design outlined in the CIP. A complete and unambiguous design is necessary to facilitate multiple interoperable implementations.

This section must address the [Versioning](#versioning) requirement unless this is addressed in an optional Versioning section.

If a proposal defines structure of on-chain data it must include a CDDL schema. Rationale: how does this CIP achieve its goals? | The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.

It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a [CPS][], the 'Rationale' section should explain how it addresses the CPS and answer any questions that the CPS poses for potential solutions. Path to Active | Organised in two sub-sections (see [Path to Active](#path-to-active) for detail):
Acceptance Criteria
Describes what are the acceptance criteria whereby a proposal becomes _'Active'_.
Implementation Plan
Either a plan to meet those criteria or `N/A` if not applicable. -_optional sections_ | May appear in any order, or with custom titles, at author and editor discretion:
**Versioning**: if [Versioning](#versioning) is not addressed in Specification
**References**
**Appendices** +_optional sections_ | May appear in any order, or with custom titles, at author and editor discretion:
**Versioning**: if [Versioning](#versioning) is not addressed in Specification
**References**
**Appendices**
**Acknowledgements** Copyright | The CIP must be explicitly licensed under acceptable copyright terms ([see below](#licensing)). > **Note** Each of these section titles (*Abstract* onward) should be an H2 heading (beginning with markdown `##`). Subsections like _Versioning_ or _Acceptance Criteria_ should be H3 headings (e.g. `### Versioning`). Don't include a H1 title heading (markdown `#`): for web friendly contexts, this will be generated from the Preamble. diff --git a/CIP-1694/README.md b/CIP-1694/README.md index c49127a80..38c65d8db 100644 --- a/CIP-1694/README.md +++ b/CIP-1694/README.md @@ -55,1950 +55,1951 @@ Voting rights will be based on the total Ada that is delegated, as a whole numbe The most crucial aspect of this proposal is therefore the notion of **"one Lovelace = one vote"**. -#### Acknowledgements +For the many contributors to this proposal, see [Acknowledgements](#acknowledgements). +## Motivation: why is this CIP necessary? -
- First draft ++ [Goal](#goal) ++ [Current design](#current-governance-mechanism-design) ++ [Shortcomings of the Shelley governance design](#shortcomings-of-the-shelley-governance-design) ++ [Out of scope](#out-of-scope) -Many people have commented on and contributed to the first draft of this document, which was published in November 2022. -We would especially like to thank the following people for providing their wisdom and insights: +### Goal - * Jack Briggs - * Tim Harrison - * Philip Lazos - * Michael Madoff - * Evangelos Markakis - * Joel Telpner - * Thomas Upfield +We're heading into the age of Voltaire, laying down the foundations for decentralized decision-making. +This CIP describes a mechanism for on-chain governance that will underpin the Voltaire phase of Cardano. +The CIP builds on and extends the original Cardano governance scheme that was based on a fixed number of governance keys. +It aims to provide a **first step** that is both valuable and, importantly, is also technically achievable +in the **near term** as part of the proposed Voltaire governance system. -We would also like to thank those who have commented via Github and other channels. -
+It also seeks to act as a jumping-off point for continuing community input, +including on appropriate threshold settings and other on-chain settings. -
- 2023 Colorado Workshop (28/02 → 01/03) +Subsequent proposals may adapt and extend this proposal to meet emerging governance needs. -In addition, we would like to thank all the attendees of the workshop that was held in Longmont, Colorado on February 28th and March 1st 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +### Current governance mechanism design -* Adam Rusch, ADAO & Summon -* Addie Girouard -* Andrew Westberg -* Darlington Wleh, LidoNation -* Eystein Hansen -* James Dunseith, Gimbalabs -* Juana Attieh -* Kenric Nelson -* Lloyd Duhon, DripDropz -* Marcus Jay Allen -* Marek Mahut, 5 Binaries -* Markus Gufler -* Matthew Capps -* Mercy, Wada -* Michael Dogali -* Michael Madoff -* Patrick Tobler, NMKR -* Philip Lazos -* π Lanningham, SundaeSwap -* Rick McCracken -* Romain Pellerin -* Sergio Sanchez Ferreros -* Tim Harrison -* Tsz Wai Wu -
+The on-chain Cardano governance mechanism that was introduced in the Shelley ledger era is capable of: -
- 2023 Mexico City, Mexico Workshop (20/05) +1. modifying the values of the protocol parameters (including initiating "hard forks") +2. transferring Ada out of the reserves and the treasury (and also moving Ada between the reserves and the treasury) -In addition, we would like to thank all the attendees of the workshop that was held in Mexico City, Mexico on May 20th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +In the current scheme, governance actions are initiated by special transactions that require `Quorum-Many` authorizations +from the governance keys (5 out of 7 on the Cardano mainnet)[^1]. +Fields in the transaction body provide details of the proposed governance action: +either i) protocol parameter changes; or ii) initiating funds transfers. +Each transaction can trigger both kinds of governance actions, and a single action can have more than one effect (e.g. changing two or more protocol parameters). -* Donovan Riaño -* Cristian Jair Rojas -* Victor Hernández -* Ramón Aceves -* Sergio Andrés Cortés -* Isaías Alejandro Galván -* Abigail Guzmán -* Jorge Fernando Murguía -* Luis Guillermo Santana +- Protocol parameter updates use [transaction field nº6](https://github.com/input-output-hk/cardano-ledger/blob/8884d921c8c3c6e216a659fca46caf729282058b/eras/babbage/test-suite/cddl-files/babbage.cddl#L56) of the transaction body. +- Movements of the treasury and the reserves use [Move Instantaneous Rewards (abbrev. MIR) certificates](https://github.com/input-output-hk/cardano-ledger/blob/8884d921c8c3c6e216a659fca46caf729282058b/eras/babbage/test-suite/cddl-files/babbage.cddl#L180). -
+Properly authorized governance actions are applied on an epoch boundary (they are **enacted**). -
- 2023 Buenos Aires, Argentina Workshop (20/05) +#### Hard Forks -In addition, we would like to thank all the attendees of the workshop that was held in Buenos Aires, Argentina on May 20th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +One of the protocol parameters is sufficiently significant to merit special attention: +changing the major protocol version enables Cardano to enact controlled hard forks. +This type of protocol parameter update therefore has a special status, since stake pools +must upgrade their nodes so they can support the new protocol version once the hard fork is enacted. -* Lucas Macchiavelli -* Alejando Pestchanker -* Juan Manuel Castro Pippo -* Federico Weill -* Jose Otegui -* Mercedes Ruggeri -* Mauro Andreoli -* Elias Aires -* Jorge Nasanovsky -* Ulises Barreiro -* Martin Ochoa -* Facundo Lopez -* Vanina Estrugo -* Luca Pestchanker -
+### Shortcomings of the Shelley governance design -
- 2023 Johannesburg, South Africa Workshop (25/05) +The Shelley governance design was intended to provide a simple, transitional approach to governance. +This proposal aims to address a number of shortcomings with that design +that are apparent as we move into Voltaire. -In addition, we would like to thank all the attendees of the workshop that was held in Johannesburg, South Africa on May 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +1. The Shelley governance design gives no room for active on-chain participation of Ada holders. +While changes to the protocol are usually the results of discussions with selected community actors, +the process is currently driven mainly by the founding entities. +Ensuring that everyone can voice their concern is cumbersome, and can be perceived as arbitrary at times. -* Celiwe Ngwenya -* Bernard Sibanda -* Dumo Mbobo -* Shaolyn Dzwedere -* Kunoshe Muchemwa -* Siphiwe Mbobo -* Lucas Sibindi -* DayTapoya -* Mdu Ngwenya -* Lucky Khumalo -* Skhangele Malinga -* Joyce Ncube -* Costa Katenhe -* Bramwell Kasanga -* Precious Abimbola -* Ethel Q Tshuma -* Panashe Sibanda -* Radebe Tefo -* Kaelo Lentsoe -* Richmond Oppong -* Israel Ncube -* Sikhangele Malinga -* Nana Safo -* Ndaba Delsie -* Collen Tshepang -* Dzvedere Shaolyn -* Thandazile Sibanda -* Ncube Joyce -* Lucas Sibindi -* Pinky Ferro -* Ishmael Ntuta -* Khumalo Lucky -* Fhulufelo -* Thwasile Ngwenya -* Kunashe Muchemwa -* Dube Bekezela -* Tinyiko Baloi -* Dada Nomathemba -
+2. Movements from the treasury constitute a critical and sensitive topic. +However, they can be hard to track. It is important to have more transparency +and more layers of control over these movements. +3. While they need to be treated specially by SPOs, hard forks are not differentiated from other protocol parameter changes. -
- 2023 Bogota, Colombia Workshop (27/05) +4. Finally, while there is currently a somewhat common vision for _Cardano_ that is shared by its founding entities and also by many community members, +there is no clearly defined document where these guiding principles are recorded. +It makes sense to leverage the Cardano blockchain to record the shared Cardano ethos in an immutable fashion, as a formal Cardano Constitution. -In addition, we would like to thank all the attendees of the workshop that was held in Bogota, Colombia on May 27th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +### Out of scope -* Alvaro Moncada -* Jaime Andres Posada Castro -* Jose Miguel De Gamboa -* Nicolas Gomez -* Luis Restrepo (Moxie) -* Juanita Jaramillo R. -* Daniel Vanegas -* Ernesto Rafael Pabon Moreno -* Carlos Eduardo Escobar -* Manuel Fernando Briceño -* Sebastian Pabon -
+The following topics are considered to be out of the scope of this CIP. -
- 2023 Caracas, Venezuela Workshop (27/05) +#### The contents of the constitution -In addition, we would like to thank all the attendees of the workshop that was held in Caracas, Venezuela on May 27th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +This CIP focuses only on on-chain mechanisms. The provisions of the initial constitution are extremely important, as are any processes that +will allow it to be amended. These merit their own separate and focused discussion. -* Jean Carlo Aguilar -* Wilmer Varón -* José Erasmo Colmenares -* David Jaén -* Félix Dávila -* Yaneth Duarte -* Nando Vitti -* Wilmer Rojas -* Andreina García -* Carmen Galban -* Osmarlina Agüero -* Ender Linares -* Carlos A. Palacios R -* Dewar Rodríguez -* Lennys Blanco -* Francys García -* Davidson Arenas -
+#### The membership of the constitutional committee -
- 2023 Manizales, Colombia Workshop (27/05) +This is an off-chain issue. -In addition, we would like to thank all the attendees of the workshop that was held in Manizales, Colombia on May 27th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +#### Legal issues -* Yaris Cruz -* Yaneth Duarte -* Ciro Gelvez -* Kevin Chacon -* Juan Sierra -* Caue Chianca -* Sonia Malagon -* Facundo Ramirez -* Hope R. -
+Any potential legal enforcement of either the Cardano protocol or the Cardano Constitution are completely out of scope for this CIP. -
- 2023 Addis Ababa, Ethiopia Workshop (27/05 & 28/5) -In addition, we would like to thank all the attendees of the workshop that was held in Addis Ababa, Ethiopia on May 27th and 28th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +#### Off chain standards for governance actions -* Kaleb Dori -* Eyassu Birru -* Matthew Thornton -* Tamir Kifle -* Kirubel Tabu -* Bisrat Miherete -* Emmanuel Khatchadourian -* Tinsae Teka -* Yoseph Ephrem -* Yonas Eshetu -* Hanna Kaleab -* Tinsae Teka -* Robee Meseret -* Matias Tekeste -* Eyasu Birhanu -* yonatan berihun -* Nasrallah Hassan -* Andinet Assefa -* Tewodros Sintayehu -* KIDUS MENGISTEAB -* Djibril Konate -* Nahom Mekonnen -* Eyasu Birhanu -* Eyob Aschenaki -* Tinsae Demissie -* Yeabsira Tsegaye -* Tihitna Miroche -* Mearaf Tadewos -* Yab Mitiku -* Habtamu Asefa -* Dawit Mengistu -* Nebiyu Barsula -* Nebiyu Sultan -* Nathan Samson -
+The Cardano community must think deeply about the correct standards and processes for handling the creation of the governance actions that are specified in this CIP. +In particular, the role of Project Catalyst in creating treasury withdrawal actions is completely outside the scope of this CIP. -
- 2023 Kyoto and Fukuoka, Japan Workshop (27/05 & 10/06 ) -In addition, we would like to thank all the attendees of the workshop that was held in Kyoto and Fukuoka, Japan on May 27th and June 10th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +#### Ada holdings and delegation -* Arimura -* Hidemi -* Nagamaru(SASApool) -* shiodome47(SODMpool) -* Wakuda(AID1pool) -* Yuta(Yuki Oishi) -* Andrew -* BANCpool -* Miyatake -* Muen -* Riekousagi -* SMAN8(SA8pool) -* Tatsuya -* カッシー -* 松 -* ポンタ -* リサ -* Mako -* Ririco -* ながまる -* Baku -* マリア -* たりふん -* JUNO -* Kinoko -* Chikara -* ET -* Akira555 -* Kent -* Ppp -* Shiodome47 -* Sam -* ポール -* Concon -* Sogame -* ハンド -* Demi -* Nonnon -* banC -* SMAN8(SA8pool) -* りんむ -* Kensin -* りえこうさぎ -* アダマンタイト -* の/ゆすけ -* MUEN -* いちごだいふく -* Ranket -* A.yy -* N S -* Kazuya -* Daikon -
+How any private companies, public or private institutions, individuals etc. choose to hold or delegate their Ada, including delegation to stake pools or DReps, is outside the scope of this CIP. -
- 2023 Monterey, California Workshop (28/05) +## Specification -In addition, we would like to thank all the attendees of the workshop that was held in Monterey, California on May 28th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: ++ [The Cardano Constitution](#the-cardano-constitution) ++ [The constitutional committee](#the-constitutional-committee) + - [State of no-confidence](#state-of-no-confidence) + - [Constitutional committee keys](#constitutional-committee-keys) + - [Replacing the constitutional committee](#replacing-the-constitutional-committee) + - [Size of the constitutional committee](#size-of-the-constitutional-committee) + - [Term limits](#term-limits) ++ [Delegated representatives (DReps)](#delegated-representatives-dreps) + - [Pre-defined DReps](#pre-defined-dreps) + - [Registered DReps](#registered-dreps) + - [New stake distribution for DReps](#new-stake-distribution-for-dreps) + - [Incentives for Ada holders to delegate voting stake](#incentives-for-ada-holders-to-delegate-voting-stake) + - [DRep incentives](#drep-incentives) ++ [Governance actions](#governance-actions) + - [Ratification](#ratification) + * [Requirements](#requirements) + * [Restrictions](#restrictions) + - [Enactment](#enactment) + - [Lifecycle](#lifecycle) + - [Content](#content) + - [Protocol parameter groups](#protocol-parameter-groups) ++ [Votes](#votes) + - [Governance state](#governance-state) + - [Changes to the stake snapshot](#changes-to-the-stake-snapshot) + - [Definitions relating to voting stake](#definitions-relating-to-voting-stake) -* Shane Powser -* Rodrigo Gomez -* Adam K. Dean -* John C. Valdez -* Kyle Solomon -* Erick "Mag" Magnana -* Bryant Austin -* John Huthmaker -* Ayori Selassie -* Josh Noriega -* Matthias Sieber -
+### The Cardano Constitution -
- 2023 Tlaxcala, Mexico Workshop (01/06) +The Cardano Constitution is a text document that defines Cardano's shared values and guiding principles. +At this stage, the Constitution is an informational document that unambiguously captures the core values of Cardano +and acts to ensure its long-term sustainability. +At a later stage, we can imagine the Constitution perhaps evolving into a smart-contract based set of rules that drives the entire governance framework. +For now, however, the Constitution will remain an off-chain document whose hash digest value will be recorded on-chain. +As discussed above, the Constitution is not yet defined and its content is out of scope for this CIP. -In addition, we would like to thank all the attendees of the workshop that was held in Tlaxcala, Mexico on June 1st 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: + -* Victor Hernández -* Cristian Jair Rojas -* Miriam Mejia -* Josmar Cabañas -* Lizbet Delgado -* José Alberto Sánchez -* Fátima Valeria Zamora -* Julio César Montiel -* Jesús Pérez -* José Adrián López -* Lizbeth Calderón -* Zayra Molina -* Nayelhi Pérez -* Josué Armas -* Diego Talavera -* Darían Gutiérrez -
+### The constitutional committee -
- 2023 LATAM Virtual Workshop (03/06) +We define a _constitutional committee_ which represents a set of individuals or entities +(each associated with a Ed25519 or native or Plutus script credential) that are collectively responsible for **ensuring that the Constitution is respected**. -In addition, we would like to thank all the attendees of the workshop that was held in LATAM Virtual on June 3rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +Though it **cannot be enforced on-chain**, the constitutional committee is **only** supposed to vote +on the constitutionality of governance actions (which should thus ensure the long-term sustainability of the blockchain) and should be replaced +(via the **no confidence** action) if they overstep this boundary. +Said differently, there is a social contract between the constitutional committee and the actors of the network. +Although the constitutional committee could reject certain governance actions (by voting 'No' on them), +they should only do so when those governance actions are in conflict with the Constitution. -* Juan Sierra -* @CaueChianca -* Ernesto Rafael -* Pabon Moreno -* Sonia Malagon -* Facundo Ramírez -* Mercedes Ruggeri -* Hope R. -* Yaris Cruz -* Yaneth Duarte -* Ciro Gélvez -* Kevin Chacon -* Juanita Jaramillo -* Sebastian Pabon -
+For example, if we consider the hypothetical Constitution rule "The Cardano network must always be able to produce new blocks", +then a governance action that would reduce the maximum block size to `0` would be, in effect, +unconstitutional and so might not be ratified by the constitutional committee. The rule does +not, however, specify the smallest acceptable maximum block size, so the constitutional committee would need to determine this number +and vote accordingly. -
- 2023 Worcester, Massachusetts Workshop (08/06) +#### State of no-confidence -In addition, we would like to thank all the attendees of the workshop that was held in Worcester, Massachusetts on June 8th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +The constitutional committee is considered to be in one of the following two states at all times: -* CardanoSharp -* Kenric Nelson -* Matthias Sieber -* Roberto Mayen -* Ian Burzynski -* omdesign -* Chris Gianelloni -
+1. a normal state (i.e. a state of confidence) +2. a state of no-confidence -
- 2023 Chicago, Illinois Workshop (10/06) +In a _state of no-confidence_, the current committee is no longer able to participate in governance actions +and must be replaced before any governance actions can be ratified (see below). -In addition, we would like to thank all the attendees of the workshop that was held in Chicago, Illinois on June 10th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +#### Constitutional committee keys -* Adam Rusch -* Jose Martinez -* Michael McNulty -* Vanessa Villanueva Collao -* Maaz Jedh -
+The constitutional committee will use a hot and cold key setup, similar to the existing "genesis delegation certificate" mechanism. -
- 2023 Virtual Workshop (12/06) +#### Replacing the constitutional committee -In addition, we would like to thank all the attendees of the workshop that was held virtually on June 12th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +The constitutional committee can be replaced via a specific governance action +("New constitutional committee", described below) that requires the approval of both +the **SPOs** and the **DReps**. +The threshold for ratification might be different depending on if the governance is +in a state of confidence or a state of no confidence. -* Rojo Kaboti -* Tommy Frey -* Tevo Saks -* Slate -* UBIO OBU -
+The new constitutional committee could, in principle, be identical to or partially overlap the outgoing committee as long as the action is properly ratified. +This might happen, for example, if the electorate has collective confidence in all or part of the committee and wishes to extend its term of office. -
- 2023 Toronto, Canada Workshop (15/06) -In addition, we would like to thank all the attendees of the workshop that was held in Toronto, Canada on June 15th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +#### Size of the constitutional committee -* John MacPherson -* Lawrence Ley -
+Unlike the Shelley governance design, the size of the constitutional committee is not fixed and can be any nonnegative number. +It may be changed whenever a new committee is elected ("New constitutional committee and/or threshold"). +Likewise, the committee threshold (the fraction of committee `Yes` votes that are required to ratify governance actions) is not fixed and +can also be varied by the governance action. +This gives a great deal of flexibility to the composition of the committee. +In particular, it is possible to elect an empty committee if the community wishes to abolish the constitutional committee entirely. Note that this is different from a state of no-confidence and still constitutes a governance system capable of enacting proposals. -
- 2023 Philadelphia, Pennsylvania Workshop (17/06) +There will be a new protocol parameter for the minimal size of the committee, +itself a nonnegative number. -In addition, we would like to thank all the attendees of the workshop that was held in Philadelphia, Pennsylvania on June 17th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +#### Terms -* NOODZ -* Jarhead -* Jenny Brito -* Shepard -* BONE Pool -* type_biggie -* FLAWWD -* A.I. Scholars -* Eddie -* Joker -* Lex -* Jerome -* Joey -* SwayZ -* Cara Mia -* PHILLY 1694 -
+Each newly elected constitutional committee will have a term. +Per-member terms allow for a rotation scheme, such as a third of the committee +expiring every year. +Expired members can no longer vote. +Member can also willingly resign early, which will be marked on-chain as an expired member. -
- 2023 Santiago de Chile Workshop (17/06) +If the number of non-expired committee members falls below the minimal +size of the committee, the constitutional committee will be unable to +ratify governance actions. This means that only governance actions +that don't require votes from the constitutional committee can still +be ratified. -In addition, we would like to thank all the attendees of the workshop that was held in Santiago de Chile on June 17th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +For example, a committee of size five with a threshold of 3/5 a minimum size +of three and two expired members can still +pass governance actions if two non-expired members vote `Yes`. +However, if one more member expires then the constitutional committee becomes +unable to ratify any more governance actions. -* Rodrigo Oyarsun -* Sebastián Aravena -* Musashi Fujio -* Geo Gavo -* Lucía Escobar -* Juan Cruz Franco -* Natalia Rosa -* Cristian M. García -* Alejandro Montalvo -
+The maximum term is a governance protocol parameter, specified as a number of epochs. +During a state of no-confidence, no action can be ratified, +so the committee should plan for its own replacement if it wishes to avoid disruption. -
- 2023 Virtual Workshop (17/06) +#### Proposal policy -In addition, we would like to thank all the attendees of the workshop that was held virtually on June 17th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +While the constitution is an informal, off-chain document, there will +also be an optional script that can enforce some guidelines. This script +acts to supplement the constitutional committee by restricting some +proposal types. For example, if the community wishes to have some hard +rules for the treasury that cannot be violated, a script that enforces +these rules can be voted in as the proposal policy. -* Juana Attieh -* Nadim Karam -* Amir Azem -* Rami Hanania -* LALUL Stake Pool -* HAWAK Stake Pool -
+The proposal policy applies only to protocol parameter update and +treasury withdrawal proposals. -
- 2023 Taipai, Taiwan Workshop (18/06) + -In addition, we would like to thank all the attendees of the workshop that was held in Taipai, Taiwan on June 18th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +### Delegated representatives (DReps) -* Michael Rogero -* Ted Chen -* Mic -* Jeremy Firster -* Eric Tsai -* Dylan Chiang -* JohnsonCai -* DavidCHIEN -* Zach Gu -* Jimmy WANG -* JackTsai -* Katherine Hung -* Will Huang -* Kwicil -
+> **Warning** +> CIP-1694 DReps **should not be conflated** with Project Catalyst DReps. -
- 2023 Midgard Vikingcenter Horten, Norway Workshop (19/06) + -In addition, we would like to thank all the attendees of the workshop that was held in Midgard Vikingcenter Horten, Norway on June 19th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +#### Pre-defined DReps -* Daniel D. Johnsen -* Thomas Lindseth -* Eystein Hansen -* Gudbrand Tokerud -* Lally McClay -* $trym -* Arne Rasmussen -* Lise WesselTVVIN -* Bjarne -* Jostein Aanderaa -* Ken-Erik Ølmheim -* DimSum -
+In order to participate in governance, a stake credential must be delegated to a DRep. +Ada holders will generally delegate their voting rights to a registered DRep +that will vote on their behalf. In addition, two pre-defined DRep options are available: -
- 2023 Virtual Workshop (19/06) +* `Abstain` -In addition, we would like to thank all the attendees of the workshop that was held virtually on June 19th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: + If an Ada holder delegates to `Abstain`, then their stake is actively marked + as not participating in governance. -* Nicolas Cerny -* Nils Peuser -* Riley Kilgore -* Alejandro Almanza -* Jenny Brito -* John C. Valdez -* Rhys -* Thyme -* Adam Rusch -* Devryn -
+ The effect of delegating to `Abstain` on chain is that the delegated stake *will not* be considered to be + a part of the active voting stake. However, the stake *will* be considered to be registered for the + purpose of the incentives that are described in [Incentives for Ada holders to delegate voting stake](#incentives-for-ada-holders-to-delegate-voting-stake). -
- 2023 New York City, New York Workshop (20/06) +* `No Confidence` -In addition, we would like to thank all the attendees of the workshop that was held in New York City, New York on June 20th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: + If an Ada holder delegates to `No Confidence`, then their stake is counted + as a `Yes` vote on every `No Confidence` action and a `No` vote on every other action. + The delegated stake *will* be considered part of the active voting stake. + It also serves as a directly auditable measure of the confidence of Ada holders in the constitutional + committee. -* John Shearing -* Geoff Shearing -* Daniela Balaniuc -* SDuffy -* Garry Golden -* Newman -* Emmanuel Batse -* Ebae -* Mojira -
-
- 2023 La Cumbre, Argentina Workshop (23/06) +> **Note** +> The pre-defined DReps do not cast votes inside of transactions, their behavior is accounted for at the protocol level. +> The `Abstain` DRep may be chosen for a variety of reasons, including the desire to not +> participate in the governance system. -In addition, we would like to thank all the attendees of the workshop that was held in La Cumbre, Argentina on June 23rd 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +> **Note** +> Any Ada holder may register themselves as a DRep and delegate to themselves if they wish to actively participate in +> voting. -* Ulises Barreiro -* Daniel F. Rodriguez -* Dominique Gromez -* Leandro Chialvo -* Claudia Vogel -* Guillermo Lucero -* Funes, Brian Carrasco -* Melisa Carrasco -* Carlos Carrasco -
+#### Registered DReps -
- 2023 Minneapolis, Minnesota Workshop (23/06) +In Voltaire, existing stake credentials will be +able to delegate their stake to DReps for voting purposes, +in addition to the current delegation to stake pools for block production. +DRep delegation will mimic the existing stake delegation mechanisms (via on-chain certificates). +Similarly, DRep registration will mimic the existing stake registration mechanisms. +Additionally, registered DReps will need to vote regularly to still be considered active. +Specifically, if a DRep does not submit any votes for `drepActivity`-many epochs, the DRep is considered inactive, +where `drepActivity` is a new protocol parameter. +Inactive DReps do not count towards the active voting stake anymore, and can become active again for `drepActivity`-many epochs by voting on any governance actions. +The reason for marking DReps as inactive is so that DReps who stop participating but still have +stake delegated to them do not eventually leave the system in a state where no governance +action can pass. -In addition, we would like to thank all the attendees of the workshop that was held in Minneapolis, Minnesota on June 23rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +Registered DReps are identified by a credential that can be either: -* Stephanie King -* Darlington Wleh -
+* A verification key (Ed25519) +* A native or Plutus script -
- 2023 La Plata, Argentina Workshop (23/06) +The blake2b-224 hash digest of a serialized DRep credential is called the _DRep ID_. -In addition, we would like to thank all the attendees of the workshop that was held in La Plata, Argentina on June 23rd 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +The following new types of certificates will be added for DReps: +DRep registration certificates, DRep retirement certificates, and +vote delegation certificates. -* Mauro Andreoli -* Rodolfo Miranda -* Agustin Francella -* Federico Sting -* Elias Aires -* Lucas Macchiavelli -* Pablo Hernán Mazzitelli -
+##### DRep registration certificates -
- 2023 Puerto Madryn, Argentina Workshop (23/06) +DRep registration certificates include: -In addition, we would like to thank all the attendees of the workshop that was held in Puerto Madryn, Argentina on June 23rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +* a DRep ID +* a deposit +* an optional anchor -* Andres Torres Borda -* Federico Ledesma Calatayud -* Maximiliano Torres -* Federico Prado -* Domingo Torres -* Floriana Pérez Barria -* Martin Real -* Florencia García -* Roberto Neme -
+An **anchor** is a pair of: -
- 2023 Accra, Ghana Workshop (24/06) +* a URL to a JSON payload of metadata +* a hash of the contents of the metadata URL -In addition, we would like to thank all the attendees of the workshop that was held in Accra, Ghana on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +The structure and format of this metadata is deliberately left open in this CIP. +The on-chain rules will not check either the URL or the hash. +Client applications should, however, perform the usual sanity checks when fetching content from the provided URL. -* Wada -* Laurentine -* Christopher A. -* Nathaniel D. -* Edufua -* Michael -* Augusta -* Jeremiah -* Boaz -* Mohammed -* Richmond O. -* Ezekiel -* Megan -* Josue -* Michel T. -* Bineta -* Afia O. -* Mercy -* Enoch -* Kofi -* Awura -* Emelia -* Richmond S. -* Solomon -* Phillip -* Faakor -* Manfo -* Josh -* Daniel -* Mermose -
-
- 2023 Virtual Workshop (24/06) +##### DRep retirement certificates -In addition, we would like to thank all the attendees of the workshop that was held virtually on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +DRep retirement certificates include: -* Jonas Riise -* Thomas Lindseth -* André "Eilert" Eilertsen -* Eystein Hansen -
+* a DRep ID -
- 2023 Seoul, South Korea Workshop (24/06) +Note that a DRep is retired immediately upon the chain accepting a retirement certificate, +and the deposit is returned as part of the transaction that submits the retirement certificate +(the same way that stake credential registration deposits are returned). -In addition, we would like to thank all the attendees of the workshop that was held in Seoul, South Korea on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +##### Vote delegation certificates -* Oscar Hong (JUNGI HONG) -* SPO_COOL (Kevin Kordano) -* SPO_KTOP (KT OH) -* WANG JAE LEE -* JAE HYUN AN -* INYOUNG MOON (Penny) -* HOJIN JEON -* SEUNG KYU BAEK -* SA SEONG MAENG -* JUNG MYEONG HAN -* BRIAN KIM -* JUNG HOON KIM -* SEUNG WOOK JUNG (Peter) -* HYUNG WOO PARK -* EUN JAE CHOI -* NA GYEONG KIM -* JADEN CHOI -
+Vote delegation certificates include: -
- 2023 Abu Dhabi, UAE Workshop (25/06) +* the DRep ID to which the stake should be delegated +* the stake credential for the delegator -In addition, we would like to thank all the attendees of the workshop that was held in Abu Dhabi, UAE on June 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +> **Note** +> +> DRep delegation always maps a stake credential to a DRep credential. +> This means that a DRep cannot delegate voting stake to another DRep. -* Amir Azem -* Ian Arden -* Madina Abdibayeva -* BTBF (Yu Kagaya) -* محمد الظاهري -* Tegegne Tefera -* Rami Hanania -* Tania Debs -* Khalil Jad -* Mohamed Jamal -* Ruslan Yakubov -* OUSHEK Mohamed eisa -* Shehryar -* Wael Ben Younes -* Santosh Ray -* Juana Attieh -* Nadim Karam -* DubaistakePool -* HAWAK Pool -* LALKUL Stake Pools -
+##### Certificate authorization schemes -
- 2023 Williamsburg, New York Workshop (25/06) +The authorization scheme (i.e. which signatures are required for registration, retirement or delegation) mimics the existing stake delegation certificate authorization scheme. -In addition, we would like to thank all the attendees of the workshop that was held in Williamsburg, New York on June 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: + -* Pi -* Joseph -* Skyler -* Forrest -* Gabriel -* Newman -
-
- 2023 Lagos, Nigeria Workshop (28/06) +#### New stake distribution for DReps -In addition, we would like to thank all the attendees of the workshop that was held in Lagos, Nigeria on June 28th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +In addition to the existing per-stake-credential distribution and the +per-stake-pool distribution, the ledger will now also determine the per-DRep stake +distribution. This distribution will determine how much stake each vote from a DRep +is backed by. -* Jonah Benson -* Augusta -* Ubio Obu -* Olumide Hrosuosegbe -* Veralyn Chinenye -* Ona Ohimer -* William Ese -* Ruth Usoro -* William P -* Esther Simi -* Daniel Effiom -* Akinkurai Toluwalase -
+> **Warning** +> +> **Unlike** the distribution that is used for block production, we will always use the most +> current version of the per-DRep stake distribution as given on the epoch boundary. +> +> This means that **for any topic which individual voters care deeply about, +> they have time to delegate to themselves as a DRep and vote directly**. +> However, it means that there may be a difference between the stake that is used for block +> production and the stake that is used for voting in any given epoch. -
- 2023 Sao Paulo, Brazil Workshop (01/07) -In addition, we would like to thank all the attendees of the workshop that was held in Sao Paulo, Brazil on July 1st 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +#### Incentives for Ada holders to delegate voting stake -* Otávio Lima -* Rodrigo Pacini -* Maria Carmo -* Cauê Chianca -* Daniela Alves -* Jose Lins Dias -* Felipe Barcelos -* Rosana Melo -* Johnny Oliveira -* Lucas Ravacci -* Cristofer Ramos -* Weslei Menck -* Leandro Tsutsumi -* Izaias Pessoa -* Gabriel Melo -* Yuri Nabeshima -* Alexandre Fernandes -* Vinicius Ferreiro -* Lucas Fernandes -* Alessandro Benicio -* Mario Cielho -* Lory Fernandes Lima -* Larissa Nogueira -* Latam Cardano Community -
+There will be a short [bootstrapping phase](#bootstrapping-phase) during which rewards will be earned +for stake delegation etc. and may be withdrawn at any time. +After this phase, although rewards will continue to be earned for block delegation etc., reward accounts will be +**blocked from withdrawing any rewards** unless their associated stake credential is also delegated to a DRep. +This helps to ensure high participation, and so, legitimacy. -
- 2023 Brazil Virtual Workshop (04/07) +> **Note** +> +> Even though rewards cannot be withdrawn, they are not lost. As soon as a stake credential is delegated +> (including to a pre-defined DRep), the rewards can be withdrawn. -In addition, we would like to thank all the attendees of the workshop that was held in Brazil on July 4th 2023 for their valuable contributions -to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: +#### DRep incentives -* Lincon Vidal -* Thiago da Silva Nunes -* Rodrigo Pacini -* Livia Corcino de Albuquerque -* Cauê Chianca -* Otávio Lima -
+DReps arguably need to be compensated for their work. Research on incentive models is still ongoing, +and we do not wish to hold up implementation of this CIP while this is resolved. -## Motivation: why is this CIP necessary? +Our interim proposal is therefore to escrow Lovelace from the existing Cardano treasury until this +extremely important decision can be agreed on by the community, through the on-chain governance +mechanism that is being constructed. -+ [Goal](#goal) -+ [Current design](#current-governance-mechanism-design) -+ [Shortcomings of the Shelley governance design](#shortcomings-of-the-shelley-governance-design) -+ [Out of scope](#out-of-scope) +Alternatively, DReps could pay themselves through instances of the "Treasury withdrawal" governance action. +Such an action would be auditable on-chain, and should reflect an off-chain agreement between DReps and delegators. -### Goal + + -We're heading into the age of Voltaire, laying down the foundations for decentralized decision-making. -This CIP describes a mechanism for on-chain governance that will underpin the Voltaire phase of Cardano. -The CIP builds on and extends the original Cardano governance scheme that was based on a fixed number of governance keys. -It aims to provide a **first step** that is both valuable and, importantly, is also technically achievable -in the **near term** as part of the proposed Voltaire governance system. +### Governance actions -It also seeks to act as a jumping-off point for continuing community input, -including on appropriate threshold settings and other on-chain settings. +We define seven different types of **governance actions**. +A governance action is an on-chain event that is triggered by a transaction and has a deadline after which it cannot be enacted. -Subsequent proposals may adapt and extend this proposal to meet emerging governance needs. +- An action is said to be **ratified** when it gathers enough votes in its favor (through the rules and parameters that are detailed below). +- An action that fails to be ratified before its deadline is said to have **expired**. +- An action that has been ratified is said to be **enacted** once it has been activated on the network. -### Current governance mechanism design -The on-chain Cardano governance mechanism that was introduced in the Shelley ledger era is capable of: +| Action | Description | +|:--------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------| +| 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-Fork[^2] 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 | -1. modifying the values of the protocol parameters (including initiating "hard forks") -2. transferring Ada out of the reserves and the treasury (and also moving Ada between the reserves and the treasury) +**Any Ada holder** can submit a governance action to the chain. +They must provide a deposit of `govActionDeposit` Lovelace, which will be returned when the action is finalized +(whether it is **ratified** or has **expired**). +The deposit amount will be added to the _deposit pot_, similar to stake key deposits. +It will also be counted towards the stake of the reward address it will be paid back to, to not reduce the submitter's voting power to vote on their own (and competing) actions. -In the current scheme, governance actions are initiated by special transactions that require `Quorum-Many` authorizations -from the governance keys (5 out of 7 on the Cardano mainnet)[^1]. -Fields in the transaction body provide details of the proposed governance action: -either i) protocol parameter changes; or ii) initiating funds transfers. -Each transaction can trigger both kinds of governance actions, and a single action can have more than one effect (e.g. changing two or more protocol parameters). +If a proposal policy is present, the transaction must include that +policy in the witness set either directly, or via reference inputs, +and any other requirements that the proposal policy makes must be +satisfied. -- Protocol parameter updates use [transaction field nº6](https://github.com/input-output-hk/cardano-ledger/blob/8884d921c8c3c6e216a659fca46caf729282058b/eras/babbage/test-suite/cddl-files/babbage.cddl#L56) of the transaction body. -- Movements of the treasury and the reserves use [Move Instantaneous Rewards (abbrev. MIR) certificates](https://github.com/input-output-hk/cardano-ledger/blob/8884d921c8c3c6e216a659fca46caf729282058b/eras/babbage/test-suite/cddl-files/babbage.cddl#L180). +Note that a motion of no-confidence is an extreme measure that enables Ada holders to revoke the power +that has been granted to the current constitutional committee. -Properly authorized governance actions are applied on an epoch boundary (they are **enacted**). +> **Note** +> A **single** governance action might contain **multiple** protocol parameter updates. Many parameters are inter-connected and might require moving in lockstep. -#### Hard Forks +#### Ratification -One of the protocol parameters is sufficiently significant to merit special attention: -changing the major protocol version enables Cardano to enact controlled hard forks. -This type of protocol parameter update therefore has a special status, since stake pools -must upgrade their nodes so they can support the new protocol version once the hard fork is enacted. +Governance actions are **ratified** through on-chain voting actions. +Different kinds of governance actions have different ratification requirements but always involve **two of the three** governance bodies, +with the exception of a hard-fork initiation and security-relevant protocol parameters, which requires ratification by all governance bodies. +Depending on the type of governance action, an action will thus be ratified when a combination of the following occurs: -### Shortcomings of the Shelley governance design +* the constitutional committee approves of the action (the number of members who vote `Yes` meets the threshold of the constitutional committee) +* the DReps approve of the action (the stake controlled by the DReps who vote `Yes` meets a certain threshold of the total active voting stake) +* the SPOs approve of the action (the stake controlled by the SPOs who vote `Yes` meets a certain threshold over the total delegated active stake for the epoch) -The Shelley governance design was intended to provide a simple, transitional approach to governance. -This proposal aims to address a number of shortcomings with that design -that are apparent as we move into Voltaire. +> **Warning** +> As explained above, different stake distributions apply to DReps and SPOs. -1. The Shelley governance design gives no room for active on-chain participation of Ada holders. -While changes to the protocol are usually the results of discussions with selected community actors, -the process is currently driven mainly by the founding entities. -Ensuring that everyone can voice their concern is cumbersome, and can be perceived as arbitrary at times. +A successful motion of no-confidence, election of a new constitutional committee, +a constitutional change, or a hard-fork, delays +ratification of all other governance actions until the first epoch after their enactment. This gives +a new constitutional committee enough time to vote on current proposals, re-evaluate existing proposals +with respect to a new constitution, and ensures that the in principle arbitrary semantic changes caused +by enacting a hard-fork do not have unintended consequences in combination with other actions. -2. Movements from the treasury constitute a critical and sensitive topic. -However, they can be hard to track. It is important to have more transparency -and more layers of control over these movements. +##### Requirements -3. While they need to be treated specially by SPOs, hard forks are not differentiated from other protocol parameter changes. +The following table details the ratification requirements for each governance action scenario. The columns represent: -4. Finally, while there is currently a somewhat common vision for _Cardano_ that is shared by its founding entities and also by many community members, -there is no clearly defined document where these guiding principles are recorded. -It makes sense to leverage the Cardano blockchain to record the shared Cardano ethos in an immutable fashion, as a formal Cardano Constitution. +* **Governance action type**
+ The type of governance action. Note that the protocol parameter updates are grouped into four categories. -### Out of scope - -The following topics are considered to be out of the scope of this CIP. +* **Constitutional committee (abbrev. CC)**
+ A value of ✓ indicates that the constitutional committee must approve this action.
+ A value of - means that constitutional committee votes do not apply. -#### The contents of the constitution +* **DReps**
+ The DRep vote threshold that must be met as a percentage of *active voting stake*. -This CIP focuses only on on-chain mechanisms. The provisions of the initial constitution are extremely important, as are any processes that -will allow it to be amended. These merit their own separate and focused discussion. +* **SPOs**
+ The SPO vote threshold which must be met as a percentage of the stake held by all stake pools.
+ A value of - means that SPO votes do not apply. -#### The membership of the constitutional committee +| Governance action type | CC | DReps | SPOs | +|:------------------------------------------------------------------|:---|:---------|:---------| +| 1. Motion of no-confidence | \- | $P_1$ | $Q_1$ | +| 2a. New committee/threshold (_normal state_) | \- | $P_{2a}$ | $Q_{2a}$ | +| 2b. New committee/threshold (_state of no-confidence_) | \- | $P_{2b}$ | $Q_{2b}$ | +| 3. Update to the Constitution or proposal policy | ✓ | $P_3$ | \- | +| 4. Hard-fork initiation | ✓ | $P_4$ | $Q_4$ | +| 5a. Protocol parameter changes, network group | ✓ | $P_{5a}$ | \- | +| 5b. Protocol parameter changes, economic group | ✓ | $P_{5b}$ | \- | +| 5c. Protocol parameter changes, technical group | ✓ | $P_{5c}$ | \- | +| 5d. Protocol parameter changes, governance group | ✓ | $P_{5d}$ | \- | +| 6. Treasury withdrawal | ✓ | $P_6$ | \- | +| 7. Info | ✓ | $100$ | $100$ | -This is an off-chain issue. +Each of these thresholds is a governance parameter. There is one +additional threshold, `Q5`, related to security relevant protocol +parameters, which is explained below. +The initial thresholds should be chosen by the Cardano community as a whole. +The two thresholds for the Info action are set to 100% since setting it any lower +would result in not being able to poll above the threshold. -#### Legal issues +Some parameters are relevant to security properties of the system. Any +proposal attempting to change such a parameter requires an additional +vote of the SPOs, with the threshold `Q5`. -Any potential legal enforcement of either the Cardano protocol or the Cardano Constitution are completely out of scope for this CIP. +The security relevant protocol parameters are: +* `maxBBSize` +* `maxTxSize` +* `maxBHSize` +* `maxValSize` +* `maxBlockExUnits` +* `minFeeA` +* `minFeeB` +* `coinsPerUTxOByte` +* `govActionDeposit` +* `minFeeRefScriptsCoinsPerByte` +> **Note** +> It may make sense for some or all thresholds to be adaptive with respect to the Lovelace that is actively registered to vote. +> For example, a threshold could vary between 51% for a high level of registration and 75% for a low level registration. +> Moreover, the treasury threshold could also be adaptive, depending on the total Lovelace that is being withdrawn, +> or different thresholds could be set for different levels of withdrawal. -#### Off chain standards for governance actions +> **Note** +> To achieve legitimacy, the minimum acceptable threshold should be no less than 50% of the delegated stake. -The Cardano community must think deeply about the correct standards and processes for handling the creation of the governance actions that are specified in this CIP. -In particular, the role of Project Catalyst in creating treasury withdrawal actions is completely outside the scope of this CIP. +##### Restrictions -#### Ada holdings and delegation +Apart from _Treasury withdrawals_ and _Infos_, we include a mechanism for ensuring that governance +actions of the same type do not accidentally clash with each other in an unexpected way. -How any private companies, public or private institutions, individuals etc. choose to hold or delegate their Ada, including delegation to stake pools or DReps, is outside the scope of this CIP. +Each governance action must include the governance action ID for the most recently enacted action of its given type. +This means that two actions of the same type can be enacted at the same time, +but they must be *deliberately* designed to do so. -## Specification -+ [The Cardano Constitution](#the-cardano-constitution) -+ [The constitutional committee](#the-constitutional-committee) - - [State of no-confidence](#state-of-no-confidence) - - [Constitutional committee keys](#constitutional-committee-keys) - - [Replacing the constitutional committee](#replacing-the-constitutional-committee) - - [Size of the constitutional committee](#size-of-the-constitutional-committee) - - [Term limits](#term-limits) -+ [Delegated representatives (DReps)](#delegated-representatives-dreps) - - [Pre-defined DReps](#pre-defined-dreps) - - [Registered DReps](#registered-dreps) - - [New stake distribution for DReps](#new-stake-distribution-for-dreps) - - [Incentives for Ada holders to delegate voting stake](#incentives-for-ada-holders-to-delegate-voting-stake) - - [DRep incentives](#drep-incentives) -+ [Governance actions](#governance-actions) - - [Ratification](#ratification) - * [Requirements](#requirements) - * [Restrictions](#restrictions) - - [Enactment](#enactment) - - [Lifecycle](#lifecycle) - - [Content](#content) - - [Protocol parameter groups](#protocol-parameter-groups) -+ [Votes](#votes) - - [Governance state](#governance-state) - - [Changes to the stake snapshot](#changes-to-the-stake-snapshot) - - [Definitions relating to voting stake](#definitions-relating-to-voting-stake) +#### Enactment -### The Cardano Constitution +Actions that have been ratified in the current epoch are prioritized as follows for enactment: -The Cardano Constitution is a text document that defines Cardano's shared values and guiding principles. -At this stage, the Constitution is an informational document that unambiguously captures the core values of Cardano -and acts to ensure its long-term sustainability. -At a later stage, we can imagine the Constitution perhaps evolving into a smart-contract based set of rules that drives the entire governance framework. -For now, however, the Constitution will remain an off-chain document whose hash digest value will be recorded on-chain. -As discussed above, the Constitution is not yet defined and its content is out of scope for this CIP. +1. Motion of no-confidence +2. New committee/threshold +3. Update to the Constitution or proposal policy +4. Hard Fork initiation +5. Protocol parameter changes +6. Treasury withdrawals +7. Info - +> **Note** Enactment for _Info_ actions is a null action, since they do not have any effect on the protocol. -### The constitutional committee +##### Order of enactment -We define a _constitutional committee_ which represents a set of individuals or entities -(each associated with a Ed25519 or native or Plutus script credential) that are collectively responsible for **ensuring that the Constitution is respected**. +Governance actions are enacted in order of acceptance to the chain. +This resolves conflicts where, e.g. there are two competing parameter changes. -Though it **cannot be enforced on-chain**, the constitutional committee is **only** supposed to vote -on the constitutionality of governance actions (which should thus ensure the long-term sustainability of the blockchain) and should be replaced -(via the **no confidence** action) if they overstep this boundary. -Said differently, there is a social contract between the constitutional committee and the actors of the network. -Although the constitutional committee could reject certain governance actions (by voting 'No' on them), -they should only do so when those governance actions are in conflict with the Constitution. +#### Lifecycle -For example, if we consider the hypothetical Constitution rule "The Cardano network must always be able to produce new blocks", -then a governance action that would reduce the maximum block size to `0` would be, in effect, -unconstitutional and so might not be ratified by the constitutional committee. The rule does -not, however, specify the smallest acceptable maximum block size, so the constitutional committee would need to determine this number -and vote accordingly. +Governance actions are checked for ratification only on an epoch boundary. +Once ratified, actions are staged for enactment. -#### State of no-confidence +All submitted governance actions will therefore either: -The constitutional committee is considered to be in one of the following two states at all times: +1. be **ratified**, then **enacted** +2. or **expire** after a number of epochs -1. a normal state (i.e. a state of confidence) -2. a state of no-confidence +In all of those cases, deposits are returned immediately. -In a _state of no-confidence_, the current committee is no longer able to participate in governance actions -and must be replaced before any governance actions can be ratified (see below). +All governance actions are enacted on the epoch boundary after their ratification. -#### Constitutional committee keys +#### Content -The constitutional committee will use a hot and cold key setup, similar to the existing "genesis delegation certificate" mechanism. +Every governance action will include the following: -#### Replacing the constitutional committee +* a deposit amount (recorded since the amount of the deposit is an updatable protocol parameter) +* a reward address to receive the deposit when it is repaid +* an anchor for any metadata that is needed to justify the action +* a hash digest value to prevent collisions with competing actions of the same type (as described earlier) -The constitutional committee can be replaced via a specific governance action -("New constitutional committee", described below) that requires the approval of both -the **SPOs** and the **DReps**. -The threshold for ratification might be different depending on if the governance is -in a state of confidence or a state of no confidence. + -The new constitutional committee could, in principle, be identical to or partially overlap the outgoing committee as long as the action is properly ratified. -This might happen, for example, if the electorate has collective confidence in all or part of the committee and wishes to extend its term of office. +In addition, each action will include some elements that are specific to its type: +| Governance action type | Additional data | +|:-------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 1. Motion of no-confidence | None | +| 2. New committee/threshold | The set of verification key hash digests (members to be removed), a map of verification key hash digests to epoch numbers (new members and their term limit), and a fraction (new threshold) | +| 3. Update to the Constitution or proposal policy | An anchor to the Constitution and an optional script hash of the proposal policy | +| 4. Hard-fork initiation | The new (greater) major protocol version | +| 5. Protocol parameters changes | The changed parameters | +| 6. Treasury withdrawal | A map from stake credentials to a positive number of Lovelace | +| 7. Info | None | -#### Size of the constitutional committee +> **Note** +> The new major protocol version must be precisely one greater than the current protocol version. +> Any two consecutive epochs will therefore either have the same major protocol version, or the +> later one will have a major protocol version that is one greater. -Unlike the Shelley governance design, the size of the constitutional committee is not fixed and can be any nonnegative number. -It may be changed whenever a new committee is elected ("New constitutional committee and/or threshold"). -Likewise, the committee threshold (the fraction of committee `Yes` votes that are required to ratify governance actions) is not fixed and -can also be varied by the governance action. -This gives a great deal of flexibility to the composition of the committee. -In particular, it is possible to elect an empty committee if the community wishes to abolish the constitutional committee entirely. Note that this is different from a state of no-confidence and still constitutes a governance system capable of enacting proposals. +> **Note** +> There can be no duplicate committee members - each pair of credentials in a committee must be unique. -There will be a new protocol parameter for the minimal size of the committee, -itself a nonnegative number. +Each governance action that is accepted on the chain will be assigned a unique identifier (a.k.a. the **governance action ID**), +consisting of the transaction hash that created it and the index within the transaction body that points to it. -#### Terms +#### Protocol Parameter groups -Each newly elected constitutional committee will have a term. -Per-member terms allow for a rotation scheme, such as a third of the committee -expiring every year. -Expired members can no longer vote. -Member can also willingly resign early, which will be marked on-chain as an expired member. +We have grouped the protocol parameter changes by type, +allowing different thresholds to be set for each group. -If the number of non-expired committee members falls below the minimal -size of the committee, the constitutional committee will be unable to -ratify governance actions. This means that only governance actions -that don't require votes from the constitutional committee can still -be ratified. +We are not, however, restricting each protocol parameter governance action to be contained within one group. +In case where a governance action carries updates for multiple parameters from different groups, +the maximum threshold of all the groups involved will apply to any given such governance action. -For example, a committee of size five with a threshold of 3/5 a minimum size -of three and two expired members can still -pass governance actions if two non-expired members vote `Yes`. -However, if one more member expires then the constitutional committee becomes -unable to ratify any more governance actions. +The _network_, _economic_ and _technical_ parameter groups collect existing protocol parameters that were introduced during the Shelley, Alonzo and Babbage eras. +In addition, we introduce a new _governance_ group that is specific to the new governance parameters that will be introduced by CIP-1694. -The maximum term is a governance protocol parameter, specified as a number of epochs. -During a state of no-confidence, no action can be ratified, -so the committee should plan for its own replacement if it wishes to avoid disruption. +The **network group** consists of: +* maximum block body size (`maxBBSize`) +* maximum transaction size (`maxTxSize`) +* maximum block header size (`maxBHSize`) +* maximum size of a serialized asset value (`maxValSize`) +* maximum script execution units in a single transaction (`maxTxExUnits`) +* maximum script execution units in a single block (`maxBlockExUnits`) +* maximum number of collateral inputs (`maxCollateralInputs`) -#### Proposal policy +The **economic group** consists of: +* minimum fee coefficient (`minFeeA`) +* minimum fee constant (`minFeeB`) +* delegation key Lovelace deposit (`keyDeposit`) +* pool registration Lovelace deposit (`poolDeposit`) +* monetary expansion (`rho`) +* treasury expansion (`tau`) +* minimum fixed rewards cut for pools (`minPoolCost`) +* minimum Lovelace deposit per byte of serialized UTxO (`coinsPerUTxOByte`) +* prices of Plutus execution units (`prices`) -While the constitution is an informal, off-chain document, there will -also be an optional script that can enforce some guidelines. This script -acts to supplement the constitutional committee by restricting some -proposal types. For example, if the community wishes to have some hard -rules for the treasury that cannot be violated, a script that enforces -these rules can be voted in as the proposal policy. +The **technical group** consists of: +* pool pledge influence (`a0`) +* pool retirement maximum epoch (`eMax`) +* desired number of pools (`nOpt`) +* Plutus execution cost models (`costModels`) +* proportion of collateral needed for scripts (`collateralPercentage`) -The proposal policy applies only to protocol parameter update and -treasury withdrawal proposals. +The **governance group** consists of all the new protocol parameters that are introduced in this CIP: +* governance voting thresholds ($P_1$, $P_{2a}$, $P_{2b}$, $P_3$, $P_4$, $P_{5a}$, $P_{5b}$, $P_{5c}$, $P_{5d}$, $P_6$, $Q_1$, $Q_{2a}$, $Q_{2b}$, $Q_4$) +* 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 (`ccMinSize`) +* maximum term length (in epochs) for the constitutional committee members (`ccMaxTermLength`) - + -> **Warning** -> CIP-1694 DReps **should not be conflated** with Project Catalyst DReps. + - + -#### Pre-defined DReps +### Votes -In order to participate in governance, a stake credential must be delegated to a DRep. -Ada holders will generally delegate their voting rights to a registered DRep -that will vote on their behalf. In addition, two pre-defined DRep options are available: +Each vote transaction consists of the following: -* `Abstain` +* a governance action ID +* a role - constitutional committee member, DRep, or SPO +* a governance credential witness for the role +* an optional anchor (as defined above) for information that is relevant to the vote +* a 'Yes'/'No'/'Abstain' vote - If an Ada holder delegates to `Abstain`, then their stake is actively marked - as not participating in governance. +For SPOs and DReps, the number of votes that are cast (whether 'Yes', 'No' or 'Abstain') is proportional to the Lovelace that is delegated to them at the point the +action is checked for ratification. For constitututional committee members, each current committee member has one vote. - The effect of delegating to `Abstain` on chain is that the delegated stake *will not* be considered to be - a part of the active voting stake. However, the stake *will* be considered to be registered for the - purpose of the incentives that are described in [Incentives for Ada holders to delegate voting stake](#incentives-for-ada-holders-to-delegate-voting-stake). +> **Warning** 'Abstain' votes are not included in the "active voting stake". +> +> Note that an explicit vote to abstain differs from abstaining from voting. +> Unregistered stake that did not vote behaves like an 'Abstain' vote, +> while registered stake that did not vote behaves like a 'No' vote. +> To avoid confusion, we will only use the word 'Abstain' from this point onward to mean an on-chain vote to abstain. -* `No Confidence` +The governance credential witness will trigger the appropriate verifications in the ledger according to the existing `UTxOW` ledger rule +(i.e. a signature check for verification keys, and a validator execution with a specific vote redeemer and new Plutus script purpose for scripts). - If an Ada holder delegates to `No Confidence`, then their stake is counted - as a `Yes` vote on every `No Confidence` action and a `No` vote on every other action. - The delegated stake *will* be considered part of the active voting stake. - It also serves as a directly auditable measure of the confidence of Ada holders in the constitutional - committee. +Votes can be cast multiple times for each governance action by a single credential. +Correctly submitted votes override any older votes for the same credential and role. +That is, the voter may change their position on any action if they choose. +As soon as a governance action is ratified, voting ends and transactions containing further votes are invalid. +#### Governance state -> **Note** -> The pre-defined DReps do not cast votes inside of transactions, their behavior is accounted for at the protocol level. -> The `Abstain` DRep may be chosen for a variety of reasons, including the desire to not -> participate in the governance system. +When a governance action is successfully submitted to the chain, its progress will be tracked by the ledger state. +In particular, the following will be tracked: -> **Note** -> Any Ada holder may register themselves as a DRep and delegate to themselves if they wish to actively participate in -> voting. +* the governance action ID +* the epoch that the action expires +* the deposit amount +* the rewards address that will receive the deposit when it is returned +* the total 'Yes'/'No'/'Abstain' votes of the constitutional committee for this action +* the total 'Yes'/'No'/'Abstain' votes of the DReps for this action +* the total 'Yes'/'No'/'Abstain' votes of the SPOs for this action -#### Registered DReps -In Voltaire, existing stake credentials will be -able to delegate their stake to DReps for voting purposes, -in addition to the current delegation to stake pools for block production. -DRep delegation will mimic the existing stake delegation mechanisms (via on-chain certificates). -Similarly, DRep registration will mimic the existing stake registration mechanisms. -Additionally, registered DReps will need to vote regularly to still be considered active. -Specifically, if a DRep does not submit any votes for `drepActivity`-many epochs, the DRep is considered inactive, -where `drepActivity` is a new protocol parameter. -Inactive DReps do not count towards the active voting stake anymore, and can become active again for `drepActivity`-many epochs by voting on any governance actions. -The reason for marking DReps as inactive is so that DReps who stop participating but still have -stake delegated to them do not eventually leave the system in a state where no governance -action can pass. +#### Changes to the stake snapshot -Registered DReps are identified by a credential that can be either: +Since the stake snapshot changes at each epoch boundary, a new tally must be calculated when each unratified governance action +is checked for ratification. This means that an action could be enacted even though the DRep or SPO votes have not changed +(since the vote delegation could have changed). -* A verification key (Ed25519) -* A native or Plutus script +#### Definitions relating to voting stake -The blake2b-224 hash digest of a serialized DRep credential is called the _DRep ID_. +We define a number of new terms related to voting stake: -The following new types of certificates will be added for DReps: -DRep registration certificates, DRep retirement certificates, and -vote delegation certificates. +* Lovelace contained in a transaction output is considered **active for voting** (that is, it forms the "active voting stake"): + * It contains a registered stake credential. + * The registered stake credential has delegated its voting rights to a DRep. +* Relative to some percentage `P`, a DRep (SPO) **vote threshold has been met** if the sum of the relative stake that has been delegated to the DReps (SPOs) + that vote `Yes` to a governance action + is at least `P`. -##### DRep registration certificates +## Rationale -DRep registration certificates include: ++ [Role of the constitutional committee](#role-of-the-constitutional-committee) ++ [Intentional omission of identity verification](#intentional-omission-of-identity-verification) ++ [Reducing the power of entities with large amounts of Ada](#reducing-the-power-of-entities-with-large-amounts-of-ada) ++ [Piggybacking on stake pool stake distribution](#piggybacking-on-stake-pool-stake-distribution) ++ [Separation of hard-fork initiation from standard protocol parameter changes](#separation-of-hard-fork-initiation-from-standard-protocol-parameter-changes) ++ [The purpose of the DReps](#the-purpose-of-the-dreps) ++ [Ratification requirements table](#ratification-requirements-table) ++ [Motion of no-confidence](#motion-of-no-confidence) ++ [New committee/threshold (state of no-confidence)](#new-committeethreshold-state-of-no-confidence) ++ [The versatility of the info governance action](#the-versatility-of-the-info-governance-action) ++ [Hard-fork initiation](#hard-fork-initiation) ++ [New metadata structures](#new-metadata-structures) ++ [Controlling the number of active governance actions](#controlling-the-number-of-active-governance-actions) ++ [No AVST](#no-avst) -* a DRep ID -* a deposit -* an optional anchor +### Role of the constitutional committee -An **anchor** is a pair of: +At first sight, the constitutional committee may appear to be a special committee that has been granted extra power over DReps. +However, because DReps can replace the constitutional committee at any time and DRep votes are also required to ratify every governance action, +the constitutional committee has no more (and may, in fact, have less) power than the DReps. +Given this, what role does the committee play, and why is it not superfluous? +The answer is that the committee solves the bootstrapping problem of the new governance framework. +Indeed, as soon as we pull the trigger and enable this framework to become active on-chain, then without a constitutional committee, +there would rapidly need to be sufficient DReps, so that the system did not rely solely on SPO votes. +We cannot yet predict how active the community will be in registering as DReps, nor how reactive other Ada holders will be regarding delegation of votes. -* a URL to a JSON payload of metadata -* a hash of the contents of the metadata URL +Thus, the constitutional committee comes into play to make sure that the system can transition from +its current state into fully decentralized governance in due course. +Furthermore, in the long run, the committee can play a mentoring and advisory role in the governance +decisions by being a set of elected representatives who are put under the spotlight for their judgment and guidance in governance decisions. +Above all, the committee is required at all times to adhere to the Constitution and to ratify proposals in accordance with the provisions of the Constitution. -The structure and format of this metadata is deliberately left open in this CIP. -The on-chain rules will not check either the URL or the hash. -Client applications should, however, perform the usual sanity checks when fetching content from the provided URL. +### Intentional Omission of Identity Verification +Note that this CIP does not mention any kind of identity validation or verification for the members of the constitutional committee or the DReps. -##### DRep retirement certificates +This is intentional. -DRep retirement certificates include: +We hope that the community will strongly consider only voting for and delegating to those DReps who provide something like a DID to identify themselves. +However, enforcing identity verification is very difficult without some centralized oracle, which we consider to be a step in the wrong direction. -* a DRep ID +### Reducing the power of entities with large amounts of Ada -Note that a DRep is retired immediately upon the chain accepting a retirement certificate, -and the deposit is returned as part of the transaction that submits the retirement certificate -(the same way that stake credential registration deposits are returned). +Various mechanisms, such as quadratic voting, have been proposed to guard against entities with a large amount of influence. +In a system based on "1 Lovelace, 1 vote", however, it is trivially easy to split stake into small amounts and undo the protections. +Without an on-chain identity verification system we cannot adopt any such measures. -##### Vote delegation certificates +### Piggybacking on stake pool stake distribution -Vote delegation certificates include: +The Cardano protocol is based on a Proof-of-Stake consensus mechanism, so using a stake-based governance approach is sensible. +However, there are many ways that could be used to define how to record the stake distribution between participants. +As a reminder, network addresses can currently contain two sets of credentials: one to identify who can unlock funds at an address +(a.k.a. payment credentials) and one that can be delegated to a stake pool (a.k.a. delegation credentials). -* the DRep ID to which the stake should be delegated -* the stake credential for the delegator +Rather than defining a third set of credentials, we instead propose to re-use the existing delegation credentials, +using a new on-chain certificate to determine the governance stake distribution. This implies that the set of DReps can (and likely will) differ from the set of SPOs, +so creating balance. On the flip side, it means that the governance stake distribution suffers from the same shortcomings as that for block production: +for example, wallet software providers must support multi-delegation schemes and must facilitate the partitioning of stake into sub-accounts should an Ada holder desire to delegate to multiple DReps, +or an Ada holder must manually split their holding if their wallet does not support this. -> **Note** -> -> DRep delegation always maps a stake credential to a DRep credential. -> This means that a DRep cannot delegate voting stake to another DRep. +However, this choice also limits future implementation effort for wallet providers and minimizes the effort that is needed for end-users to participate in the governance protocol. +The latter is a sufficiently significant concern to justify the decision. By piggybacking on the existing structure, +the system remains familiar to users and reasonably easy to set up. This maximizes both the chance of success of, and the rate of participation in, the governance framework. -##### Certificate authorization schemes +### Separation of Hard Fork Initiation from Standard Protocol Parameter Changes -The authorization scheme (i.e. which signatures are required for registration, retirement or delegation) mimics the existing stake delegation certificate authorization scheme. +In contrast to other protocol parameter updates, hard forks (or, more correctly, changes to the protocol's major version number) require much more attention. +Indeed, while other protocol parameter changes can be performed without significant software changes, +a hard fork assumes that a super-majority of the network has upgraded the Cardano node to support the new set of features that are introduced by the upgrade. +This means that the timing of a hard fork event must be communicated well ahead of time to all Cardano users, and requires coordination between stake pool operators, wallet providers, DApp developers, and the node release team. - +Hence, this proposal, unlike the Shelley scheme, promotes hard fork initiations as a standalone governance action, distinct from protocol parameter updates. +### The purpose of the DReps -#### New stake distribution for DReps +Nothing in this proposal limits SPOs from becoming DReps. +Why do we have DReps at all? +The answer is that SPOs are chosen purely for block production and not all SPOs will want to become DReps. +Voters can choose to delegate their vote to DReps without needing to consider whether they are +also a good block producer, and SPOs can choose to represent Ada holders or not. -In addition to the existing per-stake-credential distribution and the -per-stake-pool distribution, the ledger will now also determine the per-DRep stake -distribution. This distribution will determine how much stake each vote from a DRep -is backed by. +### Ratification Requirements Table -> **Warning** -> -> **Unlike** the distribution that is used for block production, we will always use the most -> current version of the per-DRep stake distribution as given on the epoch boundary. -> -> This means that **for any topic which individual voters care deeply about, -> they have time to delegate to themselves as a DRep and vote directly**. -> However, it means that there may be a difference between the stake that is used for block -> production and the stake that is used for voting in any given epoch. +The requirements in the [ratification requirement table](#requirements) are explained here. +Most of the governance actions have the same kind of requirements: +the constitutional committee and the DReps must reach a sufficient number of +'Yes' votes. +This includes these actions: +* New committee/threshold (normal state) +* Update to the Constitution +* Protocol parameter changes +* Treasury withdrawal +### Motion of no-confidence -#### Incentives for Ada holders to delegate voting stake +A motion of no-confidence represents a lack of confidence by the Cardano community in the +current constitutional committee, and hence the constitutional committee should not +be included in this type of governance action. +In this situation, the SPOs and the DReps are left to represent the will of the community. -There will be a short [bootstrapping phase](#bootstrapping-phase) during which rewards will be earned -for stake delegation etc. and may be withdrawn at any time. -After this phase, although rewards will continue to be earned for block delegation etc., reward accounts will be -**blocked from withdrawing any rewards** unless their associated stake credential is also delegated to a DRep. -This helps to ensure high participation, and so, legitimacy. +### New committee/threshold (state of no-confidence) -> **Note** -> -> Even though rewards cannot be withdrawn, they are not lost. As soon as a stake credential is delegated -> (including to a pre-defined DRep), the rewards can be withdrawn. +Similar to the motion of no-confidence, electing a constitutional committee +depends on both the SPOs and the DReps to represent the will of the community. -#### DRep incentives +### The versatility of the info governance action -DReps arguably need to be compensated for their work. Research on incentive models is still ongoing, -and we do not wish to hold up implementation of this CIP while this is resolved. +While not binding on chain, the Info governance action could be useful in an number of +situations. These include: -Our interim proposal is therefore to escrow Lovelace from the existing Cardano treasury until this -extremely important decision can be agreed on by the community, through the on-chain governance -mechanism that is being constructed. +* ratifying a CIP +* deciding on the genesis file for a new ledger era +* recording initial feedback for future governance actions -Alternatively, DReps could pay themselves through instances of the "Treasury withdrawal" governance action. -Such an action would be auditable on-chain, and should reflect an off-chain agreement between DReps and delegators. +### Hard-Fork initiation - - +Regardless of any governance mechanism, SPO participation is needed for any hard fork since they must upgrade their node software. +For this reason, we make their cooperation explicit in the hard fork initiation governance action, +by always requiring their vote. +The constitutional committee also votes, signaling the constitutionality of a hard fork. +The DReps also vote, to represent the will of every stake holder. -### Governance actions +### New Metadata structures -We define seven different types of **governance actions**. -A governance action is an on-chain event that is triggered by a transaction and has a deadline after which it cannot be enacted. - -- An action is said to be **ratified** when it gathers enough votes in its favor (through the rules and parameters that are detailed below). -- An action that fails to be ratified before its deadline is said to have **expired**. -- An action that has been ratified is said to be **enacted** once it has been activated on the network. +The governance actions, the votes and the certificates and the Constitution use new metadata fields, +in the form of URLs and integrity hashes +(mirroring the metadata structure for stake pool registration). +The metadata is used to provide context. +Governance actions need to explain why the action is needed, +what experts were consulted, etc. +Since transaction size constraints should not limit this explanatory data, +we use URLs instead. +This does, however, introduce new problems. +If a URL does not resolve, what should be the expectation for voting on that action? +Should we expect everyone to vote 'No'? +Is this an attack vector against the governance system? +In such a scenario, the hash pre-image could be communicated in other ways, but we should be +prepared for the situation. +Should there be a summary of the justification on chain? -| Action | Description | -|:--------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------| -| 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-Fork[^2] 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 | +#### Alternative: Use of transaction metadata -**Any Ada holder** can submit a governance action to the chain. -They must provide a deposit of `govActionDeposit` Lovelace, which will be returned when the action is finalized -(whether it is **ratified** or has **expired**). -The deposit amount will be added to the _deposit pot_, similar to stake key deposits. -It will also be counted towards the stake of the reward address it will be paid back to, to not reduce the submitter's voting power to vote on their own (and competing) actions. +Instead of specific dedicated fields in the transaction format, we could instead use the existing transaction metadata field. -If a proposal policy is present, the transaction must include that -policy in the witness set either directly, or via reference inputs, -and any other requirements that the proposal policy makes must be -satisfied. +Governance-related metadata can be clearly identified by registering a CIP-10 metadata label. +Within that, the structure of the metadata can be determined by this CIP (exact format TBD), using an index to map the vote or governance action ID to the corresponding metadata URL and hash. -Note that a motion of no-confidence is an extreme measure that enables Ada holders to revoke the power -that has been granted to the current constitutional committee. +This avoids the need to add additional fields to the transaction body, at the risk of making it easier for submitters to ignore. +However, since the required metadata can be empty (or can point to a non-resolving URL), +it is already easy for submitters to not provide metadata, and so it is unclear whether this makes the situation worse. -> **Note** -> A **single** governance action might contain **multiple** protocol parameter updates. Many parameters are inter-connected and might require moving in lockstep. +Note that transaction metadata is never stored in the ledger state, so it would be up to clients +to pair the metadata with the actions and votes in this alternative, and would not be available +as a ledger state query. -#### Ratification +### Controlling the number of active governance actions -Governance actions are **ratified** through on-chain voting actions. -Different kinds of governance actions have different ratification requirements but always involve **two of the three** governance bodies, -with the exception of a hard-fork initiation and security-relevant protocol parameters, which requires ratification by all governance bodies. -Depending on the type of governance action, an action will thus be ratified when a combination of the following occurs: +Since governance actions are available for anyone to submit, we need some mechanism to prevent those +individuals responsible for voting from becoming overwhelmed with a flood of proposals. +A large deposit is one such mechanism, but this comes at the unfortunate cost of being a barrier +for some people to submit an action. +Note, however, that crowd-sourcing with a Plutus script is always an option to gather the deposit. -* the constitutional committee approves of the action (the number of members who vote `Yes` meets the threshold of the constitutional committee) -* the DReps approve of the action (the stake controlled by the DReps who vote `Yes` meets a certain threshold of the total active voting stake) -* the SPOs approve of the action (the stake controlled by the SPOs who vote `Yes` meets a certain threshold over the total delegated active stake for the epoch) +We could, alternatively, accept the possibility of a large number of actions active at any given +time, and instead depend on off-chain socialization to guide voters' attention to those that merit it. +In this scenario, the constitutional committee might choose to only consider proposals which have +already garnered enough votes from the DReps. -> **Warning** -> As explained above, different stake distributions apply to DReps and SPOs. +### No AVST -A successful motion of no-confidence, election of a new constitutional committee, -a constitutional change, or a hard-fork, delays -ratification of all other governance actions until the first epoch after their enactment. This gives -a new constitutional committee enough time to vote on current proposals, re-evaluate existing proposals -with respect to a new constitution, and ensures that the in principle arbitrary semantic changes caused -by enacting a hard-fork do not have unintended consequences in combination with other actions. +An earlier draft of this CIP included the notion of an "active voting stake threshold", or AVST. +The purpose of AVST was to ensure the legitimacy of each vote, removing the possibility that, for example, +9 out of 10 Lovelace could decide the fate of millions of entities on Cardano. +There are really two concerns here, which are worth separating. -##### Requirements +The first concern is that of bootstrapping the system, i.e. reaching the initial moment when +sufficient stake is registered to vote. +The second concern is that the system could lose participation over time. +One problem with the AVST is that it gives an incentive for SPOs to desire a low voting registration +(since their votes then hold more weight). +This is absolutely not a slight on the existing SPOs, but an issue with bad incentives. -The following table details the ratification requirements for each governance action scenario. The columns represent: +We have chosen, therefore, to solve the two concerns differently. +We solve the bootstrapping problem as described in the section on bootstrapping. +We solve the long-term participation problem by not allowing reward withdrawals +(after the bootstrap phase) unless the stake is delegated to a DRep +(including the two special cases, namely 'Abstain' and 'No confidence'). -* **Governance action type**
- The type of governance action. Note that the protocol parameter updates are grouped into four categories. +### Changelog -* **Constitutional committee (abbrev. CC)**
- A value of ✓ indicates that the constitutional committee must approve this action.
- A value of - means that constitutional committee votes do not apply. +#### Changes post Longmont workshop (March 2023) -* **DReps**
- The DRep vote threshold that must be met as a percentage of *active voting stake*. +* Thank the workshop attendees. +* We have added Constitutional Committee terms. +* Two new "pre-defined" DRep options: abstain and no confidence. +* New "Info" governance action. +* Use the most recent DRep stake distribution for ratification. + This means that if ever your DRep votes how you do not like, + you can immediately make yourself a DRep and vote how you want. +* Escrow some ADA from the current treasury for potential future DRep + incentives. +* Remove the tiered treasury actions in favor of something adaptive + (so the "yes" threshold would depend on: + 1) how much ada, + 2) how high the registered voting stake, and maybe + 3) how much ada is released every epoch +* Split the protocol parameter updates into four groups: + network, economic, technical, and governmental. +* Most governmental actions can be enacted (upon ratification) + right away. All but: protocol parameters and hard forks. +* Remove "one action per type per epoch" restriction in favor of + tracking the last action ID of each type, and including this in + the action. +* No AVST. +* Bootstrap phase: Until X% of ADA is registered to vote or Y epochs + have elapsed, only parameter changes and hard forks can happen. + PP changes just need CC quorum, HFs need CC and SPOs. + After the bootstrap phase, we put in place the incentive to keep low + DReps, but this mechanism **automatically** relaxes. +* New plutus script purpose for DReps. +* Multiple treasury withdrawals in one epoch. +* A section on the recursive problem of "how do we ratify this CIP". +* Changes to the local state-query protocol. +* New ideas, time permitting: + * Weigh SPO stake vote by pledge somehow. + * DReps can specify which other DRep gets their delegators + in the event that they retire. + * Reduced government action deposit if one member of the CC signs off + on it (which presumably means it has gone through some process). + * Include hash of (future) genesis configuration within HF proposal. -* **SPOs**
- The SPO vote threshold which must be met as a percentage of the stake held by all stake pools.
- A value of - means that SPO votes do not apply. +#### Changes post Edinburgh workshop (July 2023) -| Governance action type | CC | DReps | SPOs | -|:------------------------------------------------------------------|:---|:---------|:---------| -| 1. Motion of no-confidence | \- | $P_1$ | $Q_1$ | -| 2a. New committee/threshold (_normal state_) | \- | $P_{2a}$ | $Q_{2a}$ | -| 2b. New committee/threshold (_state of no-confidence_) | \- | $P_{2b}$ | $Q_{2b}$ | -| 3. Update to the Constitution or proposal policy | ✓ | $P_3$ | \- | -| 4. Hard-fork initiation | ✓ | $P_4$ | $Q_4$ | -| 5a. Protocol parameter changes, network group | ✓ | $P_{5a}$ | \- | -| 5b. Protocol parameter changes, economic group | ✓ | $P_{5b}$ | \- | -| 5c. Protocol parameter changes, technical group | ✓ | $P_{5c}$ | \- | -| 5d. Protocol parameter changes, governance group | ✓ | $P_{5d}$ | \- | -| 6. Treasury withdrawal | ✓ | $P_6$ | \- | -| 7. Info | ✓ | $100$ | $100$ | +* Add proposal policy, which can control what treasury withdrawals and + protocol parameter changes are allowed. +* Remove dropping of governance actions. The only effect this has is + that in case a no confidence action passes, actions stay + around. However, only new committee proposals that have been + designed to build on top of that no confidence action can be + enacted. If a new committee gets elected while some of those actions + haven't expired, those actions can be ratified but the new committee + has to approve them. +* All governance actions are enacted one epoch after they are ratified. +* Move post-bootstrapping restrictions into 'Other Ideas'. +* Add a section on different deposit amounts to 'Other Ideas'. +* Add a section for a minimum AVS to 'Other Ideas'. +* Rename some protocol parameters. +* Rename `TALLY` to `GOV`. +* Turn the Constitution into an anchor. +* Rework which anchors are required and which are optional. +* Clean up various inconsistencies and leftovers from older versions. -Each of these thresholds is a governance parameter. There is one -additional threshold, `Q5`, related to security relevant protocol -parameters, which is explained below. -The initial thresholds should be chosen by the Cardano community as a whole. -The two thresholds for the Info action are set to 100% since setting it any lower -would result in not being able to poll above the threshold. +#### Security-relevant changes and other fixes -Some parameters are relevant to security properties of the system. Any -proposal attempting to change such a parameter requires an additional -vote of the SPOs, with the threshold `Q5`. +* Guard security-relevant changes behind SPO votes. +* The system does not enter a state of no confidence with insufficient + active CC members, the CC just becomes unable to act. +* Clarify that CC members can use any kind of credential. -The security relevant protocol parameters are: -* `maxBBSize` -* `maxTxSize` -* `maxBHSize` -* `maxValSize` -* `maxBlockExUnits` -* `minFeeA` -* `minFeeB` -* `coinsPerUTxOByte` -* `govActionDeposit` -* `minFeeRefScriptsCoinsPerByte` +## Path to Active -> **Note** -> It may make sense for some or all thresholds to be adaptive with respect to the Lovelace that is actively registered to vote. -> For example, a threshold could vary between 51% for a high level of registration and 75% for a low level registration. -> Moreover, the treasury threshold could also be adaptive, depending on the total Lovelace that is being withdrawn, -> or different thresholds could be set for different levels of withdrawal. +### Acceptance Criteria -> **Note** -> To achieve legitimacy, the minimum acceptable threshold should be no less than 50% of the delegated stake. +- [ ] A new ledger era is enabled on the Cardano mainnet, which implements the above specification. +### Implementation Plan -##### Restrictions +The features in this CIP require a hard fork. -Apart from _Treasury withdrawals_ and _Infos_, we include a mechanism for ensuring that governance -actions of the same type do not accidentally clash with each other in an unexpected way. +This document describes an ambitious change to Cardano governance. +We propose to implement the changes via **one hard fork**. -Each governance action must include the governance action ID for the most recently enacted action of its given type. -This means that two actions of the same type can be enacted at the same time, -but they must be *deliberately* designed to do so. +In the following sections, we give more details about the various implementation work items that have already been identified. +In addition, the final section exposes a few open questions which will need to be finalized. +We hope that those questions can be addressed through community workshops and discussions. +#### Ratification of this proposal -#### Enactment +The ratification of this proposal is something of a circular problem: we need some form of governance framework in order to agree on what the final governance framework should be. +As has been stated many times, CIPs are not authoritative, nor are they a governance mechanism. +Rather, they describe technical solutions that have been deemed sound (from a technical standpoint) by community of experts. -Actions that have been ratified in the current epoch are prioritized as follows for enactment: +CIP-1694 arguably goes beyond the usual scope of the CIP process and there is a strong desire to ratify this CIP through _some process_. +However, that process is yet to be defined and it remains an open question. +The final ratification process is likely to be a blend of various ideas, such as: -1. Motion of no-confidence -2. New committee/threshold -3. Update to the Constitution or proposal policy -4. Hard Fork initiation -5. Protocol parameter changes -6. Treasury withdrawals -7. Info +- [ ] Gather opinions from community-held workshops, akin to the Colorado workshop of February-March 2023. +- [ ] Exercise voting actions on a public testnet, with sufficient participation. +- [ ] Poll the established SPOs. +- [ ] Leverage Project Catalyst to gather inputs from the existing voting community (albeit small in terms of active stake). -> **Note** Enactment for _Info_ actions is a null action, since they do not have any effect on the protocol. +#### Changes to the transaction body -##### Order of enactment +- [ ] New elements will be added to the transaction body, and existing update and MIR capabilities will be removed. In particular, -Governance actions are enacted in order of acceptance to the chain. -This resolves conflicts where, e.g. there are two competing parameter changes. + The governance actions and votes will comprise two new transaction body fields. -#### Lifecycle +- [ ] Three new kinds of certificates will be added in addition to the existing ones: -Governance actions are checked for ratification only on an epoch boundary. -Once ratified, actions are staged for enactment. + * DRep registration + * DRep de-registration + * Vote delegation -All submitted governance actions will therefore either: + And similarly, the current MIR and genesis certificates will be removed. -1. be **ratified**, then **enacted** -2. or **expire** after a number of epochs +- [ ] A new `Voting` purpose will be added to Plutus script contexts. + This will provide, in particular, the vote to on-chain scripts. -In all of those cases, deposits are returned immediately. +> **Warning** As usual, we will provide a CDDL specification for each of those changes. -All governance actions are enacted on the epoch boundary after their ratification. +#### Changes to the existing ledger rules -#### Content +* The `PPUP` transition rule will be rewritten and moved out of the `UTxO` rule and into the `LEDGER` rule as a new `GOV` rule. -Every governance action will include the following: + It will process and record the governance actions and votes. -* a deposit amount (recorded since the amount of the deposit is an updatable protocol parameter) -* a reward address to receive the deposit when it is repaid -* an anchor for any metadata that is needed to justify the action -* a hash digest value to prevent collisions with competing actions of the same type (as described earlier) +* The `NEWEPOCH` transition rule will be modified. +* The `MIR` sub-rule will be removed. +* A new `RATIFY` rule will be introduced to stage governance actions for enactment. - + It will ratify governance actions, and stage them for enactment in the current or next epoch, as appropriate. -In addition, each action will include some elements that are specific to its type: +* A new `ENACTMENT` rule will be called immediately after the `EPOCH` rule. This rule will enact governance actions that have previously been ratified. +* The `EPOCH` rule will no longer call the `NEWPP` sub-rule or compute whether the quorum is met on the PPUP state. -| Governance action type | Additional data | -|:-------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 1. Motion of no-confidence | None | -| 2. New committee/threshold | The set of verification key hash digests (members to be removed), a map of verification key hash digests to epoch numbers (new members and their term limit), and a fraction (new threshold) | -| 3. Update to the Constitution or proposal policy | An anchor to the Constitution and an optional script hash of the proposal policy | -| 4. Hard-fork initiation | The new (greater) major protocol version | -| 5. Protocol parameters changes | The changed parameters | -| 6. Treasury withdrawal | A map from stake credentials to a positive number of Lovelace | -| 7. Info | None | +#### Changes to the local state-query protocol -> **Note** -> The new major protocol version must be precisely one greater than the current protocol version. -> Any two consecutive epochs will therefore either have the same major protocol version, or the -> later one will have a major protocol version that is one greater. +The on-chain governance workload is large, but the off-chain workload for tools and applications will arguably be even larger. +To build an effective governance ecosystem, the ledger will have to provide interfaces to various governance elements. -> **Note** -> There can be no duplicate committee members - each pair of credentials in a committee must be unique. +While votes and DReps (de)registrations are directly visible in blocks and will, therefore, be accessible via the existing local-chain-sync protocols; we will need to upgrade the local-state-query protocol to provide extra insights on information which are harder to infer from blocks (i.e. those that require maintaining a ledger state). New state queries should cover (at least): -Each governance action that is accepted on the chain will be assigned a unique identifier (a.k.a. the **governance action ID**), -consisting of the transaction hash that created it and the index within the transaction body that points to it. +- Governance actions currently staged for enactment +- Governance actions under ratification, with the total and percentage of yes stake, no stake and abstain stake +- The current constitutional committee, and constitution hash digest -#### Protocol Parameter groups +#### Bootstrapping Phase -We have grouped the protocol parameter changes by type, -allowing different thresholds to be set for each group. +We will need to be careful how we bootstrap this fledgling government. All the parties +that are involved will need ample time to register themselves and to become familiar with the process. -We are not, however, restricting each protocol parameter governance action to be contained within one group. -In case where a governance action carries updates for multiple parameters from different groups, -the maximum threshold of all the groups involved will apply to any given such governance action. +Special provisions will apply in the initial bootstrap phase. +Firstly, during the bootstrap phase, a vote from the constitutional committee +is sufficient to change the protocol parameters. +Secondly, during the bootstrap phase, a vote from the constitutional committee, +together with a sufficient SPO vote, is sufficient to initiate a hard fork. +No other actions are possible during the bootstrap phase. -The _network_, _economic_ and _technical_ parameter groups collect existing protocol parameters that were introduced during the Shelley, Alonzo and Babbage eras. -In addition, we introduce a new _governance_ group that is specific to the new governance parameters that will be introduced by CIP-1694. +The bootstrap phase ends when a given number of epochs has elapsed, +as specified in the next ledger era configuration file. +This is likely to be a number of months after the hard fork. -The **network group** consists of: -* maximum block body size (`maxBBSize`) -* maximum transaction size (`maxTxSize`) -* maximum block header size (`maxBHSize`) -* maximum size of a serialized asset value (`maxValSize`) -* maximum script execution units in a single transaction (`maxTxExUnits`) -* maximum script execution units in a single block (`maxBlockExUnits`) -* maximum number of collateral inputs (`maxCollateralInputs`) +Moreover, there will be an interim Constitutional committee, +also specified in the next ledger era configuration file, +whose term limits will be set to expire when the bootstrap phase ends. +The rotational schedule of the first non-bootstrap committee could be included in the constitution itself. +Note, however, that since the constitutional committee never votes on new committees, +it cannot actually enforce the rotation. -The **economic group** consists of: -* minimum fee coefficient (`minFeeA`) -* minimum fee constant (`minFeeB`) -* delegation key Lovelace deposit (`keyDeposit`) -* pool registration Lovelace deposit (`poolDeposit`) -* monetary expansion (`rho`) -* treasury expansion (`tau`) -* minimum fixed rewards cut for pools (`minPoolCost`) -* minimum Lovelace deposit per byte of serialized UTxO (`coinsPerUTxOByte`) -* prices of Plutus execution units (`prices`) +#### Other Ideas / Open Questions -The **technical group** consists of: -* pool pledge influence (`a0`) -* pool retirement maximum epoch (`eMax`) -* desired number of pools (`nOpt`) -* Plutus execution cost models (`costModels`) -* proportion of collateral needed for scripts (`collateralPercentage`) +##### Pledge-weighted SPO voting -The **governance group** consists of all the new protocol parameters that are introduced in this CIP: -* governance voting thresholds ($P_1$, $P_{2a}$, $P_{2b}$, $P_3$, $P_4$, $P_{5a}$, $P_{5b}$, $P_{5c}$, $P_{5d}$, $P_6$, $Q_1$, $Q_{2a}$, $Q_{2b}$, $Q_4$) -* 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 (`ccMinSize`) -* maximum term length (in epochs) for the constitutional committee members (`ccMaxTermLength`) +The SPO vote could additionally be weighted by each SPO's pledge. +This would provide a mechanism for allowing those with literal stake in the game to have a stronger vote. +The weighting should be carefully chosen. - +A DRep could optionally list another DRep credential in their registration certificate. +Upon retirement, all of the DRep's delegations would be automatically transferred to the +given DRep credential. If that DRep had already retired, the delegation would be transfer +to the 'Abstain' DRep. - +##### No DRep registration - +Since the DRep registration does not perform any necessary functions, +the certificates for (de-)registering DReps could be removed. This +makes the democracy more liquid since it removes some bureaucracy and +also removes the need for the DRep deposit, at the cost of moving the anchor that is part of the +DRep registration certificate into the transaction metadata. -### Votes +##### Reduced deposits for some government actions -Each vote transaction consists of the following: +The deposit that is attached to governance actions exists to prevent a flood of non-serious governance +actions, each of which would require time and attention from the Cardano community. +We could reduce this deposit for proposals which go through some agreed upon off-chain process. +This would be marked on-chain by the endorsement of at least one constitutional committee member. +The downside of this idea is that it gives more power to the constitutional committee. -* a governance action ID -* a role - constitutional committee member, DRep, or SPO -* a governance credential witness for the role -* an optional anchor (as defined above) for information that is relevant to the vote -* a 'Yes'/'No'/'Abstain' vote +##### Different deposit amounts for different governance actions -For SPOs and DReps, the number of votes that are cast (whether 'Yes', 'No' or 'Abstain') is proportional to the Lovelace that is delegated to them at the point the -action is checked for ratification. For constitututional committee members, each current committee member has one vote. +Multiple workshops for this CIP have proposed to introduce a different +deposit amount for each type of governance action. It was not clear +whether a majority was in favor of this idea, but this may be +considered if it becomes clear that it is necessary. -> **Warning** 'Abstain' votes are not included in the "active voting stake". -> -> Note that an explicit vote to abstain differs from abstaining from voting. -> Unregistered stake that did not vote behaves like an 'Abstain' vote, -> while registered stake that did not vote behaves like a 'No' vote. -> To avoid confusion, we will only use the word 'Abstain' from this point onward to mean an on-chain vote to abstain. +##### Minimum active voting stake -The governance credential witness will trigger the appropriate verifications in the ledger according to the existing `UTxOW` ledger rule -(i.e. a signature check for verification keys, and a validator execution with a specific vote redeemer and new Plutus script purpose for scripts). +As a further guarantee to ensure governance actions cannot be proposed +right before a hard fork, be voted on by one DRep with a large amount +of stake and be enacted immediately, there could be an additional +requirement that a certain fixed absolute amount of stake needs to +cast a 'Yes' vote on the action to be enacted. -Votes can be cast multiple times for each governance action by a single credential. -Correctly submitted votes override any older votes for the same credential and role. -That is, the voter may change their position on any action if they choose. -As soon as a governance action is ratified, voting ends and transactions containing further votes are invalid. +This does not seem necessary in the current design, since the stake of +all registered DReps behaves like a 'No' vote until they have actually +cast a vote. This means that for this scenario to occur, the malicious +actor needs at least to be in control of the fraction of DRep stake +corresponding to the relevant threshold, at which point this might as +well be considered a legitimate action. -#### Governance state +##### Include hash of (future) genesis configuration within hard-fork proposal -When a governance action is successfully submitted to the chain, its progress will be tracked by the ledger state. -In particular, the following will be tracked: +Some hard-forks require new genesis configurations. +This has been the case for the Shelley and Alonzo hard forks (but not Allegra, Mary, Vasil or Valentine), may be the case in the future. +At the moment, this proposal doesn't state anything about such a genesis configuration: +it is implicitly assumed to be an off-chain agreement. +We could however, enforce that (the hash of) a specific genesis configuration is also captured within a hard-fork governance action. -* the governance action ID -* the epoch that the action expires -* the deposit amount -* the rewards address that will receive the deposit when it is returned -* the total 'Yes'/'No'/'Abstain' votes of the constitutional committee for this action -* the total 'Yes'/'No'/'Abstain' votes of the DReps for this action -* the total 'Yes'/'No'/'Abstain' votes of the SPOs for this action +##### Adaptive thresholds +As discussed above, it may make sense for some or all thresholds to be adaptive with respect to the Lovelace that is actively registered to vote, +so that the system provides greater legitimacy when there is only a low level of active voting stake. +The bootstrapping mechanism that is proposed above may subsume this, however, by ensuring that the governance system is activated +only when a minimum level of stake has been delegated to DReps. -#### Changes to the stake snapshot -Since the stake snapshot changes at each epoch boundary, a new tally must be calculated when each unratified governance action -is checked for ratification. This means that an action could be enacted even though the DRep or SPO votes have not changed -(since the vote delegation could have changed). +##### Renaming DReps / state of no-confidence? -#### Definitions relating to voting stake +It has been stated several times that "DReps" as presented here, might be confused with Project Catalst DReps. +Similarly, some people have expressed confusion between the state of no-confidence, the motion of no-confidence and the no-confidence DReps. -We define a number of new terms related to voting stake: +We could imagine finding better terms for these concepts. -* Lovelace contained in a transaction output is considered **active for voting** (that is, it forms the "active voting stake"): - * It contains a registered stake credential. - * The registered stake credential has delegated its voting rights to a DRep. -* Relative to some percentage `P`, a DRep (SPO) **vote threshold has been met** if the sum of the relative stake that has been delegated to the DReps (SPOs) - that vote `Yes` to a governance action - is at least `P`. +##### Rate-limiting treasury movements -## Rationale +Nothing prevents money being taken out of the treasury other than the proposed votes and voting thresholds. Given that the Cardano treasury is a quite fundamental component of its monetary policy, we could imagine enforcing (at the protocol level) the maximum amount that can removed from the treasury over any period of time. -+ [Role of the constitutional committee](#role-of-the-constitutional-committee) -+ [Intentional omission of identity verification](#intentional-omission-of-identity-verification) -+ [Reducing the power of entities with large amounts of Ada](#reducing-the-power-of-entities-with-large-amounts-of-ada) -+ [Piggybacking on stake pool stake distribution](#piggybacking-on-stake-pool-stake-distribution) -+ [Separation of hard-fork initiation from standard protocol parameter changes](#separation-of-hard-fork-initiation-from-standard-protocol-parameter-changes) -+ [The purpose of the DReps](#the-purpose-of-the-dreps) -+ [Ratification requirements table](#ratification-requirements-table) -+ [Motion of no-confidence](#motion-of-no-confidence) -+ [New committee/threshold (state of no-confidence)](#new-committeethreshold-state-of-no-confidence) -+ [The versatility of the info governance action](#the-versatility-of-the-info-governance-action) -+ [Hard-fork initiation](#hard-fork-initiation) -+ [New metadata structures](#new-metadata-structures) -+ [Controlling the number of active governance actions](#controlling-the-number-of-active-governance-actions) -+ [No AVST](#no-avst) +##### Final safety measure, post bootstrapping -### Role of the constitutional committee +Many people have stated that they believe that the actual voting turnout will not be so large +as to be a strain on the throughput of the system. +We also believe that this is likely to be the case, but when the bootstrap phase ends we might +put one final, temporary safety measure in place (this will also allow us to justify a low DRep deposit amount). -At first sight, the constitutional committee may appear to be a special committee that has been granted extra power over DReps. -However, because DReps can replace the constitutional committee at any time and DRep votes are also required to ratify every governance action, -the constitutional committee has no more (and may, in fact, have less) power than the DReps. -Given this, what role does the committee play, and why is it not superfluous? -The answer is that the committee solves the bootstrapping problem of the new governance framework. -Indeed, as soon as we pull the trigger and enable this framework to become active on-chain, then without a constitutional committee, -there would rapidly need to be sufficient DReps, so that the system did not rely solely on SPO votes. -We cannot yet predict how active the community will be in registering as DReps, nor how reactive other Ada holders will be regarding delegation of votes. +For values of $X$ and $Y$ that are still to be determined, +as soon as the bootstrap phase has ended, +when we calculate the DReps stake distribution for the next epoch boundary, +we will consider _only_ those DReps that are _either_ in the top $X$-many DReps ranked by stake amount, +or those DReps that have at least $Y$ Lovelace. +Every epoch, the value of $X$ will _increase_ and the value of $Y$ will decrease, +so that eventually $X$ will be effectively infinite and $Y$ will be zero. +Note that this is only an incentive, and nothing actually stops any DRep from casting their +vote (though it will not be counted if it does not meet the requirements). -Thus, the constitutional committee comes into play to make sure that the system can transition from -its current state into fully decentralized governance in due course. -Furthermore, in the long run, the committee can play a mentoring and advisory role in the governance -decisions by being a set of elected representatives who are put under the spotlight for their judgment and guidance in governance decisions. -Above all, the committee is required at all times to adhere to the Constitution and to ratify proposals in accordance with the provisions of the Constitution. +If the community decides at some point that there is indeed a problem with congestion, +then a hard fork could be enacted that limits the number of DReps in a more restrictive way. -### Intentional Omission of Identity Verification +Reasonable numbers for the initial value of $X$ are probably 5,000-10,000. +Reasonable numbers for the initial value of $Y$ are probably the total number of Lovelace +divided by the initial value of $X$. -Note that this CIP does not mention any kind of identity validation or verification for the members of the constitutional committee or the DReps. +The mechanism should be set to relax at a rate where the restriction is completely eliminated after +a period of six months to one year. -This is intentional. +## Acknowledgements -We hope that the community will strongly consider only voting for and delegating to those DReps who provide something like a DID to identify themselves. -However, enforcing identity verification is very difficult without some centralized oracle, which we consider to be a step in the wrong direction. +
+ First draft -### Reducing the power of entities with large amounts of Ada +Many people have commented on and contributed to the first draft of this document, which was published in November 2022. +We would especially like to thank the following people for providing their wisdom and insights: -Various mechanisms, such as quadratic voting, have been proposed to guard against entities with a large amount of influence. -In a system based on "1 Lovelace, 1 vote", however, it is trivially easy to split stake into small amounts and undo the protections. -Without an on-chain identity verification system we cannot adopt any such measures. + * Jack Briggs + * Tim Harrison + * Philip Lazos + * Michael Madoff + * Evangelos Markakis + * Joel Telpner + * Thomas Upfield -### Piggybacking on stake pool stake distribution +We would also like to thank those who have commented via Github and other channels. +
-The Cardano protocol is based on a Proof-of-Stake consensus mechanism, so using a stake-based governance approach is sensible. -However, there are many ways that could be used to define how to record the stake distribution between participants. -As a reminder, network addresses can currently contain two sets of credentials: one to identify who can unlock funds at an address -(a.k.a. payment credentials) and one that can be delegated to a stake pool (a.k.a. delegation credentials). +
+ 2023 Colorado Workshop (28/02 → 01/03) -Rather than defining a third set of credentials, we instead propose to re-use the existing delegation credentials, -using a new on-chain certificate to determine the governance stake distribution. This implies that the set of DReps can (and likely will) differ from the set of SPOs, -so creating balance. On the flip side, it means that the governance stake distribution suffers from the same shortcomings as that for block production: -for example, wallet software providers must support multi-delegation schemes and must facilitate the partitioning of stake into sub-accounts should an Ada holder desire to delegate to multiple DReps, -or an Ada holder must manually split their holding if their wallet does not support this. +In addition, we would like to thank all the attendees of the workshop that was held in Longmont, Colorado on February 28th and March 1st 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -However, this choice also limits future implementation effort for wallet providers and minimizes the effort that is needed for end-users to participate in the governance protocol. -The latter is a sufficiently significant concern to justify the decision. By piggybacking on the existing structure, -the system remains familiar to users and reasonably easy to set up. This maximizes both the chance of success of, and the rate of participation in, the governance framework. +* Adam Rusch, ADAO & Summon +* Addie Girouard +* Andrew Westberg +* Darlington Wleh, LidoNation +* Eystein Hansen +* James Dunseith, Gimbalabs +* Juana Attieh +* Kenric Nelson +* Lloyd Duhon, DripDropz +* Marcus Jay Allen +* Marek Mahut, 5 Binaries +* Markus Gufler +* Matthew Capps +* Mercy, Wada +* Michael Dogali +* Michael Madoff +* Patrick Tobler, NMKR +* Philip Lazos +* π Lanningham, SundaeSwap +* Rick McCracken +* Romain Pellerin +* Sergio Sanchez Ferreros +* Tim Harrison +* Tsz Wai Wu +
-### Separation of Hard Fork Initiation from Standard Protocol Parameter Changes +
+ 2023 Mexico City, Mexico Workshop (20/05) -In contrast to other protocol parameter updates, hard forks (or, more correctly, changes to the protocol's major version number) require much more attention. -Indeed, while other protocol parameter changes can be performed without significant software changes, -a hard fork assumes that a super-majority of the network has upgraded the Cardano node to support the new set of features that are introduced by the upgrade. -This means that the timing of a hard fork event must be communicated well ahead of time to all Cardano users, and requires coordination between stake pool operators, wallet providers, DApp developers, and the node release team. +In addition, we would like to thank all the attendees of the workshop that was held in Mexico City, Mexico on May 20th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -Hence, this proposal, unlike the Shelley scheme, promotes hard fork initiations as a standalone governance action, distinct from protocol parameter updates. +* Donovan Riaño +* Cristian Jair Rojas +* Victor Hernández +* Ramón Aceves +* Sergio Andrés Cortés +* Isaías Alejandro Galván +* Abigail Guzmán +* Jorge Fernando Murguía +* Luis Guillermo Santana -### The purpose of the DReps +
-Nothing in this proposal limits SPOs from becoming DReps. -Why do we have DReps at all? -The answer is that SPOs are chosen purely for block production and not all SPOs will want to become DReps. -Voters can choose to delegate their vote to DReps without needing to consider whether they are -also a good block producer, and SPOs can choose to represent Ada holders or not. +
+ 2023 Buenos Aires, Argentina Workshop (20/05) -### Ratification Requirements Table +In addition, we would like to thank all the attendees of the workshop that was held in Buenos Aires, Argentina on May 20th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -The requirements in the [ratification requirement table](#requirements) are explained here. -Most of the governance actions have the same kind of requirements: -the constitutional committee and the DReps must reach a sufficient number of -'Yes' votes. -This includes these actions: -* New committee/threshold (normal state) -* Update to the Constitution -* Protocol parameter changes -* Treasury withdrawal +* Lucas Macchiavelli +* Alejando Pestchanker +* Juan Manuel Castro Pippo +* Federico Weill +* Jose Otegui +* Mercedes Ruggeri +* Mauro Andreoli +* Elias Aires +* Jorge Nasanovsky +* Ulises Barreiro +* Martin Ochoa +* Facundo Lopez +* Vanina Estrugo +* Luca Pestchanker +
-### Motion of no-confidence +
+ 2023 Johannesburg, South Africa Workshop (25/05) -A motion of no-confidence represents a lack of confidence by the Cardano community in the -current constitutional committee, and hence the constitutional committee should not -be included in this type of governance action. -In this situation, the SPOs and the DReps are left to represent the will of the community. +In addition, we would like to thank all the attendees of the workshop that was held in Johannesburg, South Africa on May 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -### New committee/threshold (state of no-confidence) +* Celiwe Ngwenya +* Bernard Sibanda +* Dumo Mbobo +* Shaolyn Dzwedere +* Kunoshe Muchemwa +* Siphiwe Mbobo +* Lucas Sibindi +* DayTapoya +* Mdu Ngwenya +* Lucky Khumalo +* Skhangele Malinga +* Joyce Ncube +* Costa Katenhe +* Bramwell Kasanga +* Precious Abimbola +* Ethel Q Tshuma +* Panashe Sibanda +* Radebe Tefo +* Kaelo Lentsoe +* Richmond Oppong +* Israel Ncube +* Sikhangele Malinga +* Nana Safo +* Ndaba Delsie +* Collen Tshepang +* Dzvedere Shaolyn +* Thandazile Sibanda +* Ncube Joyce +* Lucas Sibindi +* Pinky Ferro +* Ishmael Ntuta +* Khumalo Lucky +* Fhulufelo +* Thwasile Ngwenya +* Kunashe Muchemwa +* Dube Bekezela +* Tinyiko Baloi +* Dada Nomathemba +
-Similar to the motion of no-confidence, electing a constitutional committee -depends on both the SPOs and the DReps to represent the will of the community. -### The versatility of the info governance action +
+ 2023 Bogota, Colombia Workshop (27/05) -While not binding on chain, the Info governance action could be useful in an number of -situations. These include: +In addition, we would like to thank all the attendees of the workshop that was held in Bogota, Colombia on May 27th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -* ratifying a CIP -* deciding on the genesis file for a new ledger era -* recording initial feedback for future governance actions +* Alvaro Moncada +* Jaime Andres Posada Castro +* Jose Miguel De Gamboa +* Nicolas Gomez +* Luis Restrepo (Moxie) +* Juanita Jaramillo R. +* Daniel Vanegas +* Ernesto Rafael Pabon Moreno +* Carlos Eduardo Escobar +* Manuel Fernando Briceño +* Sebastian Pabon +
-### Hard-Fork initiation +
+ 2023 Caracas, Venezuela Workshop (27/05) -Regardless of any governance mechanism, SPO participation is needed for any hard fork since they must upgrade their node software. -For this reason, we make their cooperation explicit in the hard fork initiation governance action, -by always requiring their vote. -The constitutional committee also votes, signaling the constitutionality of a hard fork. -The DReps also vote, to represent the will of every stake holder. +In addition, we would like to thank all the attendees of the workshop that was held in Caracas, Venezuela on May 27th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -### New Metadata structures +* Jean Carlo Aguilar +* Wilmer Varón +* José Erasmo Colmenares +* David Jaén +* Félix Dávila +* Yaneth Duarte +* Nando Vitti +* Wilmer Rojas +* Andreina García +* Carmen Galban +* Osmarlina Agüero +* Ender Linares +* Carlos A. Palacios R +* Dewar Rodríguez +* Lennys Blanco +* Francys García +* Davidson Arenas +
-The governance actions, the votes and the certificates and the Constitution use new metadata fields, -in the form of URLs and integrity hashes -(mirroring the metadata structure for stake pool registration). -The metadata is used to provide context. -Governance actions need to explain why the action is needed, -what experts were consulted, etc. -Since transaction size constraints should not limit this explanatory data, -we use URLs instead. +
+ 2023 Manizales, Colombia Workshop (27/05) -This does, however, introduce new problems. -If a URL does not resolve, what should be the expectation for voting on that action? -Should we expect everyone to vote 'No'? -Is this an attack vector against the governance system? -In such a scenario, the hash pre-image could be communicated in other ways, but we should be -prepared for the situation. -Should there be a summary of the justification on chain? +In addition, we would like to thank all the attendees of the workshop that was held in Manizales, Colombia on May 27th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -#### Alternative: Use of transaction metadata +* Yaris Cruz +* Yaneth Duarte +* Ciro Gelvez +* Kevin Chacon +* Juan Sierra +* Caue Chianca +* Sonia Malagon +* Facundo Ramirez +* Hope R. +
-Instead of specific dedicated fields in the transaction format, we could instead use the existing transaction metadata field. +
+ 2023 Addis Ababa, Ethiopia Workshop (27/05 & 28/5) -Governance-related metadata can be clearly identified by registering a CIP-10 metadata label. -Within that, the structure of the metadata can be determined by this CIP (exact format TBD), using an index to map the vote or governance action ID to the corresponding metadata URL and hash. +In addition, we would like to thank all the attendees of the workshop that was held in Addis Ababa, Ethiopia on May 27th and 28th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -This avoids the need to add additional fields to the transaction body, at the risk of making it easier for submitters to ignore. -However, since the required metadata can be empty (or can point to a non-resolving URL), -it is already easy for submitters to not provide metadata, and so it is unclear whether this makes the situation worse. +* Kaleb Dori +* Eyassu Birru +* Matthew Thornton +* Tamir Kifle +* Kirubel Tabu +* Bisrat Miherete +* Emmanuel Khatchadourian +* Tinsae Teka +* Yoseph Ephrem +* Yonas Eshetu +* Hanna Kaleab +* Tinsae Teka +* Robee Meseret +* Matias Tekeste +* Eyasu Birhanu +* yonatan berihun +* Nasrallah Hassan +* Andinet Assefa +* Tewodros Sintayehu +* KIDUS MENGISTEAB +* Djibril Konate +* Nahom Mekonnen +* Eyasu Birhanu +* Eyob Aschenaki +* Tinsae Demissie +* Yeabsira Tsegaye +* Tihitna Miroche +* Mearaf Tadewos +* Yab Mitiku +* Habtamu Asefa +* Dawit Mengistu +* Nebiyu Barsula +* Nebiyu Sultan +* Nathan Samson +
-Note that transaction metadata is never stored in the ledger state, so it would be up to clients -to pair the metadata with the actions and votes in this alternative, and would not be available -as a ledger state query. +
+ 2023 Kyoto and Fukuoka, Japan Workshop (27/05 & 10/06 ) -### Controlling the number of active governance actions +In addition, we would like to thank all the attendees of the workshop that was held in Kyoto and Fukuoka, Japan on May 27th and June 10th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -Since governance actions are available for anyone to submit, we need some mechanism to prevent those -individuals responsible for voting from becoming overwhelmed with a flood of proposals. -A large deposit is one such mechanism, but this comes at the unfortunate cost of being a barrier -for some people to submit an action. -Note, however, that crowd-sourcing with a Plutus script is always an option to gather the deposit. +* Arimura +* Hidemi +* Nagamaru(SASApool) +* shiodome47(SODMpool) +* Wakuda(AID1pool) +* Yuta(Yuki Oishi) +* Andrew +* BANCpool +* Miyatake +* Muen +* Riekousagi +* SMAN8(SA8pool) +* Tatsuya +* カッシー +* 松 +* ポンタ +* リサ +* Mako +* Ririco +* ながまる +* Baku +* マリア +* たりふん +* JUNO +* Kinoko +* Chikara +* ET +* Akira555 +* Kent +* Ppp +* Shiodome47 +* Sam +* ポール +* Concon +* Sogame +* ハンド +* Demi +* Nonnon +* banC +* SMAN8(SA8pool) +* りんむ +* Kensin +* りえこうさぎ +* アダマンタイト +* の/ゆすけ +* MUEN +* いちごだいふく +* Ranket +* A.yy +* N S +* Kazuya +* Daikon +
-We could, alternatively, accept the possibility of a large number of actions active at any given -time, and instead depend on off-chain socialization to guide voters' attention to those that merit it. -In this scenario, the constitutional committee might choose to only consider proposals which have -already garnered enough votes from the DReps. +
+ 2023 Monterey, California Workshop (28/05) -### No AVST +In addition, we would like to thank all the attendees of the workshop that was held in Monterey, California on May 28th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -An earlier draft of this CIP included the notion of an "active voting stake threshold", or AVST. -The purpose of AVST was to ensure the legitimacy of each vote, removing the possibility that, for example, -9 out of 10 Lovelace could decide the fate of millions of entities on Cardano. -There are really two concerns here, which are worth separating. +* Shane Powser +* Rodrigo Gomez +* Adam K. Dean +* John C. Valdez +* Kyle Solomon +* Erick "Mag" Magnana +* Bryant Austin +* John Huthmaker +* Ayori Selassie +* Josh Noriega +* Matthias Sieber +
-The first concern is that of bootstrapping the system, i.e. reaching the initial moment when -sufficient stake is registered to vote. -The second concern is that the system could lose participation over time. -One problem with the AVST is that it gives an incentive for SPOs to desire a low voting registration -(since their votes then hold more weight). -This is absolutely not a slight on the existing SPOs, but an issue with bad incentives. +
+ 2023 Tlaxcala, Mexico Workshop (01/06) -We have chosen, therefore, to solve the two concerns differently. -We solve the bootstrapping problem as described in the section on bootstrapping. -We solve the long-term participation problem by not allowing reward withdrawals -(after the bootstrap phase) unless the stake is delegated to a DRep -(including the two special cases, namely 'Abstain' and 'No confidence'). +In addition, we would like to thank all the attendees of the workshop that was held in Tlaxcala, Mexico on June 1st 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -### Changelog +* Victor Hernández +* Cristian Jair Rojas +* Miriam Mejia +* Josmar Cabañas +* Lizbet Delgado +* José Alberto Sánchez +* Fátima Valeria Zamora +* Julio César Montiel +* Jesús Pérez +* José Adrián López +* Lizbeth Calderón +* Zayra Molina +* Nayelhi Pérez +* Josué Armas +* Diego Talavera +* Darían Gutiérrez +
-#### Changes post Longmont workshop (March 2023) +
+ 2023 LATAM Virtual Workshop (03/06) -* Thank the workshop attendees. -* We have added Constitutional Committee terms. -* Two new "pre-defined" DRep options: abstain and no confidence. -* New "Info" governance action. -* Use the most recent DRep stake distribution for ratification. - This means that if ever your DRep votes how you do not like, - you can immediately make yourself a DRep and vote how you want. -* Escrow some ADA from the current treasury for potential future DRep - incentives. -* Remove the tiered treasury actions in favor of something adaptive - (so the "yes" threshold would depend on: - 1) how much ada, - 2) how high the registered voting stake, and maybe - 3) how much ada is released every epoch -* Split the protocol parameter updates into four groups: - network, economic, technical, and governmental. -* Most governmental actions can be enacted (upon ratification) - right away. All but: protocol parameters and hard forks. -* Remove "one action per type per epoch" restriction in favor of - tracking the last action ID of each type, and including this in - the action. -* No AVST. -* Bootstrap phase: Until X% of ADA is registered to vote or Y epochs - have elapsed, only parameter changes and hard forks can happen. - PP changes just need CC quorum, HFs need CC and SPOs. - After the bootstrap phase, we put in place the incentive to keep low - DReps, but this mechanism **automatically** relaxes. -* New plutus script purpose for DReps. -* Multiple treasury withdrawals in one epoch. -* A section on the recursive problem of "how do we ratify this CIP". -* Changes to the local state-query protocol. -* New ideas, time permitting: - * Weigh SPO stake vote by pledge somehow. - * DReps can specify which other DRep gets their delegators - in the event that they retire. - * Reduced government action deposit if one member of the CC signs off - on it (which presumably means it has gone through some process). - * Include hash of (future) genesis configuration within HF proposal. +In addition, we would like to thank all the attendees of the workshop that was held in LATAM Virtual on June 3rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: + +* Juan Sierra +* @CaueChianca +* Ernesto Rafael +* Pabon Moreno +* Sonia Malagon +* Facundo Ramírez +* Mercedes Ruggeri +* Hope R. +* Yaris Cruz +* Yaneth Duarte +* Ciro Gélvez +* Kevin Chacon +* Juanita Jaramillo +* Sebastian Pabon +
-#### Changes post Edinburgh workshop (July 2023) +
+ 2023 Worcester, Massachusetts Workshop (08/06) -* Add proposal policy, which can control what treasury withdrawals and - protocol parameter changes are allowed. -* Remove dropping of governance actions. The only effect this has is - that in case a no confidence action passes, actions stay - around. However, only new committee proposals that have been - designed to build on top of that no confidence action can be - enacted. If a new committee gets elected while some of those actions - haven't expired, those actions can be ratified but the new committee - has to approve them. -* All governance actions are enacted one epoch after they are ratified. -* Move post-bootstrapping restrictions into 'Other Ideas'. -* Add a section on different deposit amounts to 'Other Ideas'. -* Add a section for a minimum AVS to 'Other Ideas'. -* Rename some protocol parameters. -* Rename `TALLY` to `GOV`. -* Turn the Constitution into an anchor. -* Rework which anchors are required and which are optional. -* Clean up various inconsistencies and leftovers from older versions. +In addition, we would like to thank all the attendees of the workshop that was held in Worcester, Massachusetts on June 8th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -#### Security-relevant changes and other fixes +* CardanoSharp +* Kenric Nelson +* Matthias Sieber +* Roberto Mayen +* Ian Burzynski +* omdesign +* Chris Gianelloni +
-* Guard security-relevant changes behind SPO votes. -* The system does not enter a state of no confidence with insufficient - active CC members, the CC just becomes unable to act. -* Clarify that CC members can use any kind of credential. +
+ 2023 Chicago, Illinois Workshop (10/06) -## Path to Active +In addition, we would like to thank all the attendees of the workshop that was held in Chicago, Illinois on June 10th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -### Acceptance Criteria +* Adam Rusch +* Jose Martinez +* Michael McNulty +* Vanessa Villanueva Collao +* Maaz Jedh +
-- [ ] A new ledger era is enabled on the Cardano mainnet, which implements the above specification. +
+ 2023 Virtual Workshop (12/06) -### Implementation Plan +In addition, we would like to thank all the attendees of the workshop that was held virtually on June 12th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -The features in this CIP require a hard fork. +* Rojo Kaboti +* Tommy Frey +* Tevo Saks +* Slate +* UBIO OBU +
-This document describes an ambitious change to Cardano governance. -We propose to implement the changes via **one hard fork**. +
+ 2023 Toronto, Canada Workshop (15/06) -In the following sections, we give more details about the various implementation work items that have already been identified. -In addition, the final section exposes a few open questions which will need to be finalized. -We hope that those questions can be addressed through community workshops and discussions. +In addition, we would like to thank all the attendees of the workshop that was held in Toronto, Canada on June 15th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -#### Ratification of this proposal +* John MacPherson +* Lawrence Ley +
-The ratification of this proposal is something of a circular problem: we need some form of governance framework in order to agree on what the final governance framework should be. -As has been stated many times, CIPs are not authoritative, nor are they a governance mechanism. -Rather, they describe technical solutions that have been deemed sound (from a technical standpoint) by community of experts. +
+ 2023 Philadelphia, Pennsylvania Workshop (17/06) -CIP-1694 arguably goes beyond the usual scope of the CIP process and there is a strong desire to ratify this CIP through _some process_. -However, that process is yet to be defined and it remains an open question. -The final ratification process is likely to be a blend of various ideas, such as: +In addition, we would like to thank all the attendees of the workshop that was held in Philadelphia, Pennsylvania on June 17th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -- [ ] Gather opinions from community-held workshops, akin to the Colorado workshop of February-March 2023. -- [ ] Exercise voting actions on a public testnet, with sufficient participation. -- [ ] Poll the established SPOs. -- [ ] Leverage Project Catalyst to gather inputs from the existing voting community (albeit small in terms of active stake). +* NOODZ +* Jarhead +* Jenny Brito +* Shepard +* BONE Pool +* type_biggie +* FLAWWD +* A.I. Scholars +* Eddie +* Joker +* Lex +* Jerome +* Joey +* SwayZ +* Cara Mia +* PHILLY 1694 +
-#### Changes to the transaction body +
+ 2023 Santiago de Chile Workshop (17/06) -- [ ] New elements will be added to the transaction body, and existing update and MIR capabilities will be removed. In particular, +In addition, we would like to thank all the attendees of the workshop that was held in Santiago de Chile on June 17th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: - The governance actions and votes will comprise two new transaction body fields. +* Rodrigo Oyarsun +* Sebastián Aravena +* Musashi Fujio +* Geo Gavo +* Lucía Escobar +* Juan Cruz Franco +* Natalia Rosa +* Cristian M. García +* Alejandro Montalvo +
-- [ ] Three new kinds of certificates will be added in addition to the existing ones: +
+ 2023 Virtual Workshop (17/06) - * DRep registration - * DRep de-registration - * Vote delegation +In addition, we would like to thank all the attendees of the workshop that was held virtually on June 17th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: - And similarly, the current MIR and genesis certificates will be removed. +* Juana Attieh +* Nadim Karam +* Amir Azem +* Rami Hanania +* LALUL Stake Pool +* HAWAK Stake Pool +
-- [ ] A new `Voting` purpose will be added to Plutus script contexts. - This will provide, in particular, the vote to on-chain scripts. +
+ 2023 Taipai, Taiwan Workshop (18/06) -> **Warning** As usual, we will provide a CDDL specification for each of those changes. +In addition, we would like to thank all the attendees of the workshop that was held in Taipai, Taiwan on June 18th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -#### Changes to the existing ledger rules +* Michael Rogero +* Ted Chen +* Mic +* Jeremy Firster +* Eric Tsai +* Dylan Chiang +* JohnsonCai +* DavidCHIEN +* Zach Gu +* Jimmy WANG +* JackTsai +* Katherine Hung +* Will Huang +* Kwicil +
-* The `PPUP` transition rule will be rewritten and moved out of the `UTxO` rule and into the `LEDGER` rule as a new `GOV` rule. +
+ 2023 Midgard Vikingcenter Horten, Norway Workshop (19/06) - It will process and record the governance actions and votes. +In addition, we would like to thank all the attendees of the workshop that was held in Midgard Vikingcenter Horten, Norway on June 19th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -* The `NEWEPOCH` transition rule will be modified. -* The `MIR` sub-rule will be removed. -* A new `RATIFY` rule will be introduced to stage governance actions for enactment. +* Daniel D. Johnsen +* Thomas Lindseth +* Eystein Hansen +* Gudbrand Tokerud +* Lally McClay +* $trym +* Arne Rasmussen +* Lise WesselTVVIN +* Bjarne +* Jostein Aanderaa +* Ken-Erik Ølmheim +* DimSum +
- It will ratify governance actions, and stage them for enactment in the current or next epoch, as appropriate. +
+ 2023 Virtual Workshop (19/06) -* A new `ENACTMENT` rule will be called immediately after the `EPOCH` rule. This rule will enact governance actions that have previously been ratified. -* The `EPOCH` rule will no longer call the `NEWPP` sub-rule or compute whether the quorum is met on the PPUP state. +In addition, we would like to thank all the attendees of the workshop that was held virtually on June 19th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -#### Changes to the local state-query protocol +* Nicolas Cerny +* Nils Peuser +* Riley Kilgore +* Alejandro Almanza +* Jenny Brito +* John C. Valdez +* Rhys +* Thyme +* Adam Rusch +* Devryn +
-The on-chain governance workload is large, but the off-chain workload for tools and applications will arguably be even larger. -To build an effective governance ecosystem, the ledger will have to provide interfaces to various governance elements. +
+ 2023 New York City, New York Workshop (20/06) -While votes and DReps (de)registrations are directly visible in blocks and will, therefore, be accessible via the existing local-chain-sync protocols; we will need to upgrade the local-state-query protocol to provide extra insights on information which are harder to infer from blocks (i.e. those that require maintaining a ledger state). New state queries should cover (at least): +In addition, we would like to thank all the attendees of the workshop that was held in New York City, New York on June 20th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -- Governance actions currently staged for enactment -- Governance actions under ratification, with the total and percentage of yes stake, no stake and abstain stake -- The current constitutional committee, and constitution hash digest +* John Shearing +* Geoff Shearing +* Daniela Balaniuc +* SDuffy +* Garry Golden +* Newman +* Emmanuel Batse +* Ebae +* Mojira +
-#### Bootstrapping Phase +
+ 2023 La Cumbre, Argentina Workshop (23/06) -We will need to be careful how we bootstrap this fledgling government. All the parties -that are involved will need ample time to register themselves and to become familiar with the process. +In addition, we would like to thank all the attendees of the workshop that was held in La Cumbre, Argentina on June 23rd 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -Special provisions will apply in the initial bootstrap phase. -Firstly, during the bootstrap phase, a vote from the constitutional committee -is sufficient to change the protocol parameters. -Secondly, during the bootstrap phase, a vote from the constitutional committee, -together with a sufficient SPO vote, is sufficient to initiate a hard fork. -No other actions are possible during the bootstrap phase. +* Ulises Barreiro +* Daniel F. Rodriguez +* Dominique Gromez +* Leandro Chialvo +* Claudia Vogel +* Guillermo Lucero +* Funes, Brian Carrasco +* Melisa Carrasco +* Carlos Carrasco +
-The bootstrap phase ends when a given number of epochs has elapsed, -as specified in the next ledger era configuration file. -This is likely to be a number of months after the hard fork. +
+ 2023 Minneapolis, Minnesota Workshop (23/06) -Moreover, there will be an interim Constitutional committee, -also specified in the next ledger era configuration file, -whose term limits will be set to expire when the bootstrap phase ends. -The rotational schedule of the first non-bootstrap committee could be included in the constitution itself. -Note, however, that since the constitutional committee never votes on new committees, -it cannot actually enforce the rotation. +In addition, we would like to thank all the attendees of the workshop that was held in Minneapolis, Minnesota on June 23rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: + +* Stephanie King +* Darlington Wleh +
-#### Other Ideas / Open Questions +
+ 2023 La Plata, Argentina Workshop (23/06) -##### Pledge-weighted SPO voting +In addition, we would like to thank all the attendees of the workshop that was held in La Plata, Argentina on June 23rd 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -The SPO vote could additionally be weighted by each SPO's pledge. -This would provide a mechanism for allowing those with literal stake in the game to have a stronger vote. -The weighting should be carefully chosen. +* Mauro Andreoli +* Rodolfo Miranda +* Agustin Francella +* Federico Sting +* Elias Aires +* Lucas Macchiavelli +* Pablo Hernán Mazzitelli +
-##### Automatic re-delegation of DReps +
+ 2023 Puerto Madryn, Argentina Workshop (23/06) -A DRep could optionally list another DRep credential in their registration certificate. -Upon retirement, all of the DRep's delegations would be automatically transferred to the -given DRep credential. If that DRep had already retired, the delegation would be transfer -to the 'Abstain' DRep. +In addition, we would like to thank all the attendees of the workshop that was held in Puerto Madryn, Argentina on June 23rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -##### No DRep registration +* Andres Torres Borda +* Federico Ledesma Calatayud +* Maximiliano Torres +* Federico Prado +* Domingo Torres +* Floriana Pérez Barria +* Martin Real +* Florencia García +* Roberto Neme +
-Since the DRep registration does not perform any necessary functions, -the certificates for (de-)registering DReps could be removed. This -makes the democracy more liquid since it removes some bureaucracy and -also removes the need for the DRep deposit, at the cost of moving the anchor that is part of the -DRep registration certificate into the transaction metadata. +
+ 2023 Accra, Ghana Workshop (24/06) -##### Reduced deposits for some government actions +In addition, we would like to thank all the attendees of the workshop that was held in Accra, Ghana on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -The deposit that is attached to governance actions exists to prevent a flood of non-serious governance -actions, each of which would require time and attention from the Cardano community. -We could reduce this deposit for proposals which go through some agreed upon off-chain process. -This would be marked on-chain by the endorsement of at least one constitutional committee member. -The downside of this idea is that it gives more power to the constitutional committee. +* Wada +* Laurentine +* Christopher A. +* Nathaniel D. +* Edufua +* Michael +* Augusta +* Jeremiah +* Boaz +* Mohammed +* Richmond O. +* Ezekiel +* Megan +* Josue +* Michel T. +* Bineta +* Afia O. +* Mercy +* Enoch +* Kofi +* Awura +* Emelia +* Richmond S. +* Solomon +* Phillip +* Faakor +* Manfo +* Josh +* Daniel +* Mermose +
-##### Different deposit amounts for different governance actions +
+ 2023 Virtual Workshop (24/06) -Multiple workshops for this CIP have proposed to introduce a different -deposit amount for each type of governance action. It was not clear -whether a majority was in favor of this idea, but this may be -considered if it becomes clear that it is necessary. +In addition, we would like to thank all the attendees of the workshop that was held virtually on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -##### Minimum active voting stake +* Jonas Riise +* Thomas Lindseth +* André "Eilert" Eilertsen +* Eystein Hansen +
-As a further guarantee to ensure governance actions cannot be proposed -right before a hard fork, be voted on by one DRep with a large amount -of stake and be enacted immediately, there could be an additional -requirement that a certain fixed absolute amount of stake needs to -cast a 'Yes' vote on the action to be enacted. +
+ 2023 Seoul, South Korea Workshop (24/06) -This does not seem necessary in the current design, since the stake of -all registered DReps behaves like a 'No' vote until they have actually -cast a vote. This means that for this scenario to occur, the malicious -actor needs at least to be in control of the fraction of DRep stake -corresponding to the relevant threshold, at which point this might as -well be considered a legitimate action. +In addition, we would like to thank all the attendees of the workshop that was held in Seoul, South Korea on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -##### Include hash of (future) genesis configuration within hard-fork proposal +* Oscar Hong (JUNGI HONG) +* SPO_COOL (Kevin Kordano) +* SPO_KTOP (KT OH) +* WANG JAE LEE +* JAE HYUN AN +* INYOUNG MOON (Penny) +* HOJIN JEON +* SEUNG KYU BAEK +* SA SEONG MAENG +* JUNG MYEONG HAN +* BRIAN KIM +* JUNG HOON KIM +* SEUNG WOOK JUNG (Peter) +* HYUNG WOO PARK +* EUN JAE CHOI +* NA GYEONG KIM +* JADEN CHOI +
-Some hard-forks require new genesis configurations. -This has been the case for the Shelley and Alonzo hard forks (but not Allegra, Mary, Vasil or Valentine), may be the case in the future. -At the moment, this proposal doesn't state anything about such a genesis configuration: -it is implicitly assumed to be an off-chain agreement. -We could however, enforce that (the hash of) a specific genesis configuration is also captured within a hard-fork governance action. +
+ 2023 Abu Dhabi, UAE Workshop (25/06) -##### Adaptive thresholds +In addition, we would like to thank all the attendees of the workshop that was held in Abu Dhabi, UAE on June 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -As discussed above, it may make sense for some or all thresholds to be adaptive with respect to the Lovelace that is actively registered to vote, -so that the system provides greater legitimacy when there is only a low level of active voting stake. -The bootstrapping mechanism that is proposed above may subsume this, however, by ensuring that the governance system is activated -only when a minimum level of stake has been delegated to DReps. +* Amir Azem +* Ian Arden +* Madina Abdibayeva +* BTBF (Yu Kagaya) +* محمد الظاهري +* Tegegne Tefera +* Rami Hanania +* Tania Debs +* Khalil Jad +* Mohamed Jamal +* Ruslan Yakubov +* OUSHEK Mohamed eisa +* Shehryar +* Wael Ben Younes +* Santosh Ray +* Juana Attieh +* Nadim Karam +* DubaistakePool +* HAWAK Pool +* LALKUL Stake Pools +
+
+ 2023 Williamsburg, New York Workshop (25/06) -##### Renaming DReps / state of no-confidence? +In addition, we would like to thank all the attendees of the workshop that was held in Williamsburg, New York on June 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -It has been stated several times that "DReps" as presented here, might be confused with Project Catalst DReps. -Similarly, some people have expressed confusion between the state of no-confidence, the motion of no-confidence and the no-confidence DReps. +* Pi +* Joseph +* Skyler +* Forrest +* Gabriel +* Newman +
-We could imagine finding better terms for these concepts. +
+ 2023 Lagos, Nigeria Workshop (28/06) -##### Rate-limiting treasury movements +In addition, we would like to thank all the attendees of the workshop that was held in Lagos, Nigeria on June 28th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -Nothing prevents money being taken out of the treasury other than the proposed votes and voting thresholds. Given that the Cardano treasury is a quite fundamental component of its monetary policy, we could imagine enforcing (at the protocol level) the maximum amount that can removed from the treasury over any period of time. +* Jonah Benson +* Augusta +* Ubio Obu +* Olumide Hrosuosegbe +* Veralyn Chinenye +* Ona Ohimer +* William Ese +* Ruth Usoro +* William P +* Esther Simi +* Daniel Effiom +* Akinkurai Toluwalase +
-##### Final safety measure, post bootstrapping +
+ 2023 Sao Paulo, Brazil Workshop (01/07) -Many people have stated that they believe that the actual voting turnout will not be so large -as to be a strain on the throughput of the system. -We also believe that this is likely to be the case, but when the bootstrap phase ends we might -put one final, temporary safety measure in place (this will also allow us to justify a low DRep deposit amount). +In addition, we would like to thank all the attendees of the workshop that was held in Sao Paulo, Brazil on July 1st 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -For values of $X$ and $Y$ that are still to be determined, -as soon as the bootstrap phase has ended, -when we calculate the DReps stake distribution for the next epoch boundary, -we will consider _only_ those DReps that are _either_ in the top $X$-many DReps ranked by stake amount, -or those DReps that have at least $Y$ Lovelace. -Every epoch, the value of $X$ will _increase_ and the value of $Y$ will decrease, -so that eventually $X$ will be effectively infinite and $Y$ will be zero. -Note that this is only an incentive, and nothing actually stops any DRep from casting their -vote (though it will not be counted if it does not meet the requirements). +* Otávio Lima +* Rodrigo Pacini +* Maria Carmo +* Cauê Chianca +* Daniela Alves +* Jose Lins Dias +* Felipe Barcelos +* Rosana Melo +* Johnny Oliveira +* Lucas Ravacci +* Cristofer Ramos +* Weslei Menck +* Leandro Tsutsumi +* Izaias Pessoa +* Gabriel Melo +* Yuri Nabeshima +* Alexandre Fernandes +* Vinicius Ferreiro +* Lucas Fernandes +* Alessandro Benicio +* Mario Cielho +* Lory Fernandes Lima +* Larissa Nogueira +* Latam Cardano Community +
-If the community decides at some point that there is indeed a problem with congestion, -then a hard fork could be enacted that limits the number of DReps in a more restrictive way. +
+ 2023 Brazil Virtual Workshop (04/07) -Reasonable numbers for the initial value of $X$ are probably 5,000-10,000. -Reasonable numbers for the initial value of $Y$ are probably the total number of Lovelace -divided by the initial value of $X$. +In addition, we would like to thank all the attendees of the workshop that was held in Brazil on July 4th 2023 for their valuable contributions +to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include: -The mechanism should be set to relax at a rate where the restriction is completely eliminated after -a period of six months to one year. +* Lincon Vidal +* Thiago da Silva Nunes +* Rodrigo Pacini +* Livia Corcino de Albuquerque +* Cauê Chianca +* Otávio Lima +
## Copyright diff --git a/CIP-9999/README.md b/CIP-9999/README.md index 853ceaafb..18a8d5950 100644 --- a/CIP-9999/README.md +++ b/CIP-9999/README.md @@ -47,7 +47,7 @@ Problem | A more detailed description of the problem and its context. Use cases | A concrete set of examples written from a user's perspective, describing what and why they are trying to do. When they exist, this section should give a sense of the current alternatives and highlight why they are unsuitable. Goals | A list of goals and non-goals a project is pursuing, ranked by importance. These goals should help understand the design space for the solution and what the underlying project is ultimately trying to achieve.

Goals may also contain requirements for the project. For example, they may include anything from a deadline to a budget (in terms of complexity or time) to security concerns.

Finally, goals may also serve as evaluation metrics to assess how good a proposed solution is. Open Questions | A set of questions to which any proposed solution should find an answer. Questions should help guide solutions design by highlighting some foreseen vulnerabilities or design flaws. Solutions in the form of CIP should thereby include these questions as part of their _'Rationale'_ section and provide an argued answer to each. -_optional sections_| If necessary, these sections may also be included in any order:
**References**
**Appendices**
Do not add material in an optional section if it pertains to one of the standard sections. +_optional sections_| If necessary, these sections may also be included in any order:
**References**
**Appendices**
**Acknowledgements**
Do not add material in an optional section if it pertains to one of the standard sections. Copyright | The CPS must be explicitly licensed under acceptable copyright terms (see [Licensing](#licensing)). ##### Header preamble