CIP 1694 - An On-Chain
Decentralized Governance
Mechanism for Voltaire
We propose a revision of Cardano's on-chain governance system to support the new requirements for Voltaire. The existing specialized governance support for protocol parameter updates and MIR certificates will be removed, and two new fields will be added to normal transaction bodies : governance actions, votes.
Abstract
We propose a revision of Cardano's on-chain governance system to support the new requirements for Voltaire. The existing specialized governance support for protocol parameter updates and MIR certificates will be removed, and two new fields will be added to normal transaction bodies for:
Any Cardano user will be allowed to submit a governance action. We also introduce three distinct governance bodies that have specific functions in this new governance framework:
Every governance action must be ratified by at least two of these three governance bodies using their on-chain votes. The type of action and the state of the governance system determines which bodies must ratify it.
Ratified actions are then enacted on-chain, following a set of well-defined rules.
As with stake pools, any Ada holder may register to be a DRep and so choose to represent themselves and/or others. Also, as with stake pools, Ada holders may, instead, delegate their voting rights to any other DRep. Voting rights will be based on the total Ada that is delegated, as a whole number of Lovelace.
The most crucial aspect of this proposal is therefore the notion of "one Lovelace = one vote".
Motivation:
why is this CIP necessary?
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.
It also seeks to act as a jumping-off point for continuing community input, including on appropriate threshold settings and other on-chain settings.
Subsequent proposals may adapt and extend this proposal to meet emerging governance needs.
Current governance mechanism design
The on-chain Cardano governance mechanism that was introduced in the Shelley ledger era is capable of:
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).
Properly authorized governance actions are applied on an epoch boundary (they are enacted).
Hard Forks
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.
Shortcomings of the Shelley governance design
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.
Out of Scope
The contents of the constitution
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.
Legal issues
Any potential legal enforcement of either the Cardano protocol or the Cardano Constitution are completely out of scope for this CIP.
The contents Off chain standards for governance actions
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.
The membership of the constitutional committee
This is an off-chain issue.
Ada holdings and delegation
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.
Conversations
Specification
The Cardano Constitution
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.
The constitutional committee
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.
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.
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.
State of no-confidence
The constitutional committee is considered to be in one of the following two states at all times:
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).
Constitutional committee keys
The constitutional committee will use a hot and cold key setup, similar to the existing "genesis delegation certificate" mechanism.
Replacing the constitutional committee
The constitutional committee can be replaced via a specific governance action ("Update 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 normal state 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.
Size of the constitutional committee
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 ("Update committee"). 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.
There will be a new protocol parameter for the minimal size of the committee, itself a nonnegative number called committeeMinSize.
Terms
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.
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.
For example, a committee of size five with a threshold of 60% 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 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.
Guardrails Script
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 these rules can be voted in as the guardrails script.
The guardrails script applies only to protocol parameter update and treasury withdrawal proposals.
Delegated
Representatives (DReps)
Warning
CIP-1694 DReps should not be conflated with Project Catalyst DReps.
Pre-defined Voting Options
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 voting options are available:
Note
The pre-defined voting options do not cast votes inside of transactions, their behavior is accounted for at the protocol level. The `Abstain` option may be chosen for a variety of reasons, including the desire to not participate in the governance system.
Note
Any Ada holder may register themselves as a DRep and delegate to themselves if they wish to actively participate in voting.
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 or submitting a DRep update certificate. 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. Registered DReps are identified by a credential that can be either:
The blake2b-224 hash digest of a serialized DRep credential is called the DRep ID. The following new types of certificates will be added for DReps: DRep registration certificates, DRep retirement certificates, and vote delegation certificates. DRep registration certificates
Note
DRep delegation always maps a stake credential to a DRep credential. This means that a DRep cannot delegate voting stake to another DRep
New stake distribution
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.
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.
Incentives for Ada holders to delegate voting stake
There will be a short 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 or pre-defined voting option. This helps to ensure high participation, and so, legitimacy.
Warning
Even though rewards cannot be withdrawn, they are not lost. As soon as a stake credential is delegated (including to a pre-defined voting option), the rewards can be withdrawn.
DRep incentives
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. 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. 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.
Governance actions
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.
Actions | Description |
---|---|
1. Motion of no-confidence | A motion to create a state of no-confidence in the current constitutional committee |
2. Update 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. New Constitution or Guardrails Script | A modification to the Constitution or Guardrails Script, recorded as on-chain hashes |
4. Hard-Fork 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 |
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.
If a guardrails script is present, the transaction must include that script in the witness set either directly, or via reference inputs, and any other requirements that the guardrails script makes must be satisfied.
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.
Note
A single governance action might contain multiple protocol parameter updates. Many parameters are inter-connected and might require moving in lockstep.
Ratification
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:
Warning
As explained above, different stake distributions apply to DReps and SPOs.
A successful motion of no-confidence, update of the 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 an updated 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.
Requirements
The following table details the ratification requirements for each governance action scenario. The columns represent:
Governance action type | CC | DReps | SPOs |
---|---|---|---|
1. Motion of no-confidence | - | $P_1$ | $Q_1$ |
2. Update committee threshold (normal state) | - | $P_{2a}$ | $Q_{2a}$ |
3. Update committee threshold (state of no confidence) | - | $P_{2b}$ | $Q_{2b}$ |
4. New Constitution or Guardrails Script | ✓ | $P_3$ | - |
5. Hard-Fork Initiation | ✓ | $P_4$ | $Q_4$ |
6. Protocol Parameter Changes, economic group | ✓ | $P_{5a}$ | - |
7. Protocol Parameter Changes, economic group | ✓ | $P_{5b}$ | - |
8. Protocol Parameter Changes, technical group | ✓ | $P_{5c}$ | - |
9. Protocol Parameter Changes, governance group | ✓ | $P_{5d}$ | - |
10. Treasury Withdrawals | ✓ | $P_6$ | - |
11. Info | ✓ | $100$ | $100$ |
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. All 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.
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.
The security relevant protocol parameters are:
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.
Note
To achieve legitimacy, the minimum acceptable threshold should be no less than 50% of the delegated stake.
Restrictions
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.
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.
Enactment
Actions that have been ratified in the current epoch are prioritised as follows for enactment:
Note
Info actions cannot be ratified or enacted, since they do not have any effect on the protocol.
Order of enactment
Governance actions are enacted in order of acceptance to the chain. This resolves conflicts where, e.g. there are two competing parameter changes.
Lifecycle
Governance actions are checked for ratification only on an epoch boundary. Once ratified, actions are staged for enactment.
All submitted governance actions will therefore either:
In all of those cases, deposits are returned immediately.
All governance actions are enacted on the epoch boundary after their ratification.
Lifecycle
Every governance action will include the following:
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. Update 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. New Constitution or Guardrails Script | An anchor to the Constitution and an optional script hash of the Guardrails Script |
4. Hard-Fork Initiation | The new (greater) major protocol version |
5. Protocol Parameter Changes | The changed parameters |
6. Treasury Withdrawals | A map from stake credentials to a positive number of Lovelace |
7. Info | None |
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.
Note
There can be no duplicate committee members - each pair of credentials in a committee must be unique.
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.
Protocol Parameter Groups
We have grouped the protocol parameter changes by type, allowing different thresholds to be set for each group.
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.
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 network group consists of:
The economic group consists of:
The technical group consists of:
The governance group consisits of all the new protocol parameters that are introduced in this CIP:
Votes
Each vote transaction consists of the following:
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
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.'
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).
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
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:
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).
Definitions related to voting stake
We define a number of new terms related to voting stake:
Rationale
Role of the constitutional committee
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.
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.
Reducing the power of entities with large amounts of Ada
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.
Piggybanking on stake pool stake distribution
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).
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.
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.
Separation of Hard Fork Initiation from Standard Protocol Parameter Changes
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
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.
Ratification Requirements Table
The requirements in the ratification requirement table 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:
Motion of no-confidence
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.
Update committee/threshold (state-of-no-confidence)
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
While not binding on chain, the Info governance action could be useful in an number of situations. These include:
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.
New Metadata structures
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?
Alternative: Use of transaction metadata
Instead of specific dedicated fields in the transaction format, we could instead use the existing transaction metadata field.
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.
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 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.
Controlling the number of active governance actions
Instead of specific dedicated fields in the transaction format, we could instead use the existing transaction metadata field.
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.
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.
No AVST
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.
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.
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').
Changelog
Changes post Longmont workshop (March 2023)
Changes post Longmont workshop (March 2023)
Changes post Edinburgh workshop (July 2023)
Security-relevant changes and other fixes (January 2024)
May 2024
Path to Active
Acceptance criteria
Implementation Plan
The features in this CIP require a hard fork.
This document describes an ambitious change to Cardano governance. We propose to implement the changes via two hard forks: the first one containing all new features but some being disabled for a bootstrap period and the second one enabling all features.
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
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.
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:
Changes to the transaction body
Warning
As usual, we will provide a CDDL specification for each of those changes.
Changes to the existing ledger rules
Changes to the local state-query protocol
Bootstrapping Phase
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.
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.
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.
Thirdly, info actions will be available. No other actions other than those mentioned in this paragraph are possible during the bootstrap phase. The bootstrap phase ends when the Constitutional Committee and SPOs ratify a subsequent hard fork, enabling the remaining governance actions and DRep participation. This is likely to be a number of months after the Chang hard fork. Although all features will be technically available at this point, additional requirements for using each feature may be specified in the constitution.
Moreover, there will be an interim Constitutional committee with a set term, also specified in the next ledger era configuration file. The rotational schedule of the first non-interim 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.
Other Ideas / Open Questions
Pledge-weighted SPO voting
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.
Automatic re-delegation of DReps
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' voting option.
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.
Reduced deposits for some government actions
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.
Different deposit amounts for different governance actions
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.
Minimum active voting stake
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.
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.
Include hash of (future) genesis configuration within hard-fork proposal
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.
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.
Renaming DReps / state of no-confidence?
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 voting option.
We could imagine finding better terms for these concepts.
Rate-limiting treasury movements
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.
Final safety measure, post bootstrapping
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).
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).
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.
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$.
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.
Acknowledgements
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:
We would also like to thank those who have commented via Github and other channels.
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:
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 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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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, 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:
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:
Copyright
This CIP is licensed under CC-BY-4.0