Optimistic Constitutionality

alxaex · 19 March 2026 15:46

This CIP introduces Optimistic Constitutionality, changing how governance actions are approved under CIP-1694.

It can be discussed either in the comment section below, or directly on the CIP repo: Create CIP Optimistic Constitutionality by ptrdsh · Pull Request #1164 · cardano-foundation/CIPs · GitHub

Summary

Overview

Learning from the last nearly 100 Governance Actions onchain, no proposal that DReps wanted approved got rejected by the CC. The CCs effort however was insurmountable despite this perfect agreement.

It turned out that DReps are excellent in filtering wrongful/bad proposals naturally by voting on their personal preference, regardless of constitutionality. This fact can be used to the network’s advantage and reduce the cost of constitutional review drastically by borrowing from Zero Knowledge applications, where Optimistic Rollups (TRUE until someone says otherwise) is an effective expensive-verification-mitigation technique.

Optimistic Constitutionality shifts the CC from constant involvement to on-demand oversight, dramatically reducing workload and, among others, providing constructive aid to the ongoing debates around CC compensation.

Changes proposed

Instead of requiring the Constitutional Committee (CC) to actively approve every action, proposals are assumed constitutional by default and move forward unless one CC member raises an objection by voting “No”/“Unconstitutional” - a “constitutional challenge” or veto. If such a challenge occurs, the original CIP-1694 approval process resumes, requiring full CC voting and the other CC members then either confirm the veto-ing CC’s challenge by voting no/unconstitutional as well, or overrule it by voting yes/constitutional with the defined majority threshold.

The required change is happening in the ledger logic for ratification, which is changed to:

$$\text{RATIFIED} \iff \left(V_{\text{CC}}^{\text{no}} = 0 \;\lor\; \frac{V_{\text{CC}}^{\text{yes}}}{|CC|} \geq T_{\text{CC}}\right) \wedge \left(\frac{S_{\text{DRep}}^{\text{yes}}}{S_{\text{DRep}}^{\text{active}}} \geq T_{\text{DRep}}\right) \wedge \left(\frac{S_{\text{SPO}}^{\text{yes}}}{S_{\text{SPO}}^{\text{delegated}}} \geq T_{\text{SPO}}\right)$$

RATIFIED = (zero CC no votes exist **OR** (CC Yes votes ≥ CC threshold)) **AND** (DRep Yes stake ≥ DRep threshold) **AND** (SPO Yes stake ≥ SPO threshold)

And, the introduction of a new protocol parameter ccOptimisticEnabled :: Bool to control whether Optimistic Constitutionality is active or not, is helpful.

Path to Active

This CIP requires additional code in the ledger, and can only be activated with a hardfork. Due to this, it will be beneficial to let the ecosystem vote on this via an info action, as this change will be packaged within a fork containing countless changes.

Possible Action NOW:
In order to not wait for the hard fork after the next hard fork to activate this and alleviate the CCs current pain, there is nice “soft activation” path forward, which could double as testing/confirmation period:
An info action, in which the CC announces it will from now insta-vote yes on everything by default without commentary, and only vote no once they are called or see issues themselves.

RISKS

sleeping at the wheel
Given that CC members are, and in fact must, be active community members, “sleeping at the wheel” risks are diminishingly low, as CC members (are assumed) to already follow Cardano Governance naturally anyway. This is additionally mitigated by now massively increased redundancy: Only 1 of (currently) 7 members must vote no.
power abuse
CC members could single-handedly block all approved, near-ratified Governance Actions by voting No/ calling out a “constitutional challenge” up until the last block of an epoch. This risk is real, and currently known possible mitigations for it, such as introducing approval window extensions are only increasing complexity a lot, introduce other issues, and overall provide no actual benefit.
I postulate that the best mitigation for such power abuse would be to acknowledge the risk and rely on state of no confidence posteriori.

OPEN QUESTIONS

I am not a ledger developer, so the currently contained suggested code changes under “Ledger Rule Changes” critically need to be reviewed. I used Opus 4.6 to generate them.

###########################################################

BELOW FOLLOWS THE FULL CIP

unedited as of 19.03.26.
Find the most up to date version here:

github.com/cardano-foundation/CIPs

Create CIP Optimistic Constitutionality (#1164)

master ← ptrdsh:patch-2

opened 10:13AM - 19 Mar 26 UTC

ptrdsh

+269 -0

This CIP introduces **Optimistic Constitutionality**, changing how governance ac…tions are approved under CIP-1694. # Overview Learning from the last nearly 100 Governance Actions onchain, no proposal that DReps wanted approved got rejected by the CC. The CCs effort however was insurmountable despite this perfect agreement. It turned out that DReps are excellent in filtering wrongful/bad proposals naturally by voting on their personal preference, regardless of constitutionality. This fact can be used to the network's advantage and reduce the cost of constitutional review drastically by borrowing from Zero Knowledge applications, where Optimistic Rollups (TRUE until someone says otherwise) is an effective expensive-verification-mitigation technique. Optimistic Constitutionality shifts the CC from constant involvement to on-demand oversight, dramatically reducing workload and, among others, providing constructive aid to the ongoing debates around CC compensation. # Changes proposed Instead of requiring the Constitutional Committee (CC) to actively approve every action, proposals are assumed constitutional by default and move forward unless one CC member raises an objection by voting "No"/"Unconstitutional" - a "constitutional challenge" or veto. If such a challenge occurs, the original CIP-1694 approval process resumes, requiring full CC voting and the other CC members then either confirm the veto-ing CC's challenge by voting no/unconstitutional as well, or overrule it by voting yes/constitutional with the defined majority threshold. The required change is happening in the ledger logic for ratification, which is changed to: ```math $$\text{RATIFIED} \iff \left(V_{\text{CC}}^{\text{no}} = 0 \;\lor\; \frac{V_{\text{CC}}^{\text{yes}}}{|CC|} \geq T_{\text{CC}}\right) \wedge \left(\frac{S_{\text{DRep}}^{\text{yes}}}{S_{\text{DRep}}^{\text{active}}} \geq T_{\text{DRep}}\right) \wedge \left(\frac{S_{\text{SPO}}^{\text{yes}}}{S_{\text{SPO}}^{\text{delegated}}} \geq T_{\text{SPO}}\right)$$ ``` `RATIFIED = (zero CC no votes exist **OR** (CC Yes votes ≥ CC threshold)) **AND** (DRep Yes stake ≥ DRep threshold) **AND** (SPO Yes stake ≥ SPO threshold)` And, the introduction of a new protocol parameter `ccOptimisticEnabled :: Bool` to control whether Optimistic Constitutionality is active or not, is helpful. # Path to Active This CIP requires additional code in the ledger, and can only be activated with a hardfork. Due to this, it will be beneficial to let the ecosystem vote on this via an info action, as this change will be packaged within a fork containing countless changes. > Possible Action NOW: In order to not wait for the hard fork after the next hard fork to activate this and alleviate the CCs current pain, there is nice "soft activation" path forward, which could double as testing/confirmation period: An info action, in which the CC announces it will from now insta-vote yes on everything by default without commentary, and only vote no once they are called or see issues themselves. # RISKS - **sleeping at the wheel** Given that CC members are, and in fact must, be active community members, "sleeping at the wheel" risks are diminishingly low, as CC members (are assumed) to already follow Cardano Governance naturally anyway. This is additionally mitigated by now massively increased redundancy: Only 1 of (currently) 7 members must vote no. - **power abuse** CC members could single-handedly block all approved, near-ratified Governance Actions by voting No/ calling out a "constitutional challenge" up until the last block of an epoch. This risk is real, and currently known possible mitigations for it, such as introducing approval window extensions are only increasing complexity a lot, introduce other issues, and overall provide no actual benefit. I postulate that the best mitigation for such power abuse would be to acknowledge the risk and rely on state of no confidence posteriori. # OPEN QUESTIONS - I am not a ledger developer, so the currently contained suggested code changes under "Ledger Rule Changes" critically need to be reviewed. I used Opus 4.6 to generate them.

###########################################################

CIP: XXXX
Title: Optimistic Constitutionality
Category: Ledger, Governance
Status: Proposed

Authors:

Alex Moser alexander.moser@cardanofoundation.org (X: @alxaex)

Implementors:

N/A

Discussions:

tbd

Created: 2026-03-18
License: CC-BY-4.0

Abstract

This CIP proposes Optimistic Constitutionality, a modification to the governance ratification rules introduced by CIP-1694. Under the current model, every governance action requires the Constitutional Committee (CC) to reach a positive vote threshold before it can be ratified. This proposal inverts that requirement: governance actions are presumed constitutional by default and proceed to ratification without dedicated CC approval, unless one or more CC members explicitly file an objection (a “constitutionality challenge”). When a CC member votes ‘No’ (when such a “constitutionality challenge” is triggered), the current model for CC approval, as originally designed by CIP-1694, re-activates and all other CC members should vote too, to either support the “constitutionality challenge” or overwrite it with approvals.

This change reduces the CC’s operational burden from active interaction with every governance action to reactive oversight “on demand”. The approach aligns with the empirical reality that DReps already filter harmful proposals effectively through their votes of preference. As a second-order effect, Optimistic Constitutionality substantially changes the cost of constitutionality verification for the network, and provides relief to the contentious question of CC compensation, which could still be enabled separately - but under different assumptions for effort spent.

Motivation

A structural observation:

Across the first ~100 governance actions on mainnet, no proposal was rejected by the CC where DReps would otherwise have approved it. Every proposal the CC found unconstitutional was independently rejected by DRep vote. DReps, acting in rational self-interest to protect their stake and the infrastructure their businesses rely on, have proven effective at identifying bad proposals without CC guidance.

This observation is the empirical foundation for Optimistic Constitutionality: if the CC almost never needs to override DRep consensus, why require the CC to actively approve every action?

The Current Model’s Inefficiencies

Under CIP-1694, the CC must reach its approval threshold for every governance action type that requires CC consent (all types except Info actions and No Confidence motions against themselves). This creates several problems:

Late voting. CC members empirically tend to vote in the final 20% of a governance action’s lifetime, after DReps have already cast votes. This wastes DRep effort on proposals that the CC ultimately rejects.
DRep discouragement. When CC rejections arrive late, DReps who already spent time evaluating proposals see their work invalidated. Over time, this suppresses DRep participation.
False urgency. The requirement that CC members evaluate every proposal creates a baseline workload that scales linearly with governance activity, regardless of whether the proposals are contentious.
Compensation pressure. The active-approval model makes the “CC members must be compensated” argument seem self-evident, because their workload is indeed real and ongoing. Regardless, since the activation of Conway-era governance, the community has been unable to reach consensus on whether and how Constitutional Committee members should be compensated, despite mentions of this in (all versions so far of the) constitution. Optimistic Constitutionality aids to dissolve this by dramatically reducing the expected workload, and introduces new, more transparent possibilities for CC compensation, should that remain a desire.

Specification

Overview

The core change is to the ratification logic in the Conway ledger rules.
After CIP-1694, and simplified, ignoring the different Action types, a governance action is ratified when all these 3 conditions are met:

After CIP-1694

RATIFIED = (CC Yes votes ≥ CC threshold) AND (DRep Yes stake ≥ DRep threshold) AND (SPO Yes stake ≥ SPO threshold

LaTex for this equation. it doesnt render on the forum:

$$\text{RATIFIED} \iff \left(\frac{V_{\text{CC}}^{\text{yes}}}{|CC|} \geq T_{\text{CC}}\right) \wedge \left(\frac{S_{\text{DRep}}^{\text{yes}}}{S_{\text{DRep}}^{\text{active}}} \geq T_{\text{DRep}}\right) \wedge \left(\frac{S_{\text{SPO}}^{\text{yes}}}{S_{\text{SPO}}^{\text{delegated}}} \geq T_{\text{SPO}}\right)$$

Under Optimistic Constitutionality, this logic scheme changes to:

RATIFIED = (zero CC no votes exist **OR** (CC Yes votes ≥ CC threshold)) **AND** (DRep Yes stake ≥ DRep threshold) **AND** (SPO Yes stake ≥ SPO threshold)

LaTex for this equation. it doesnt render on the forum:

$$\text{RATIFIED} \iff \left(V_{\text{CC}}^{\text{no}} = 0 \;\lor\; \frac{V_{\text{CC}}^{\text{yes}}}{|CC|} \geq T_{\text{CC}}\right) \wedge \left(\frac{S_{\text{DRep}}^{\text{yes}}}{S_{\text{DRep}}^{\text{active}}} \geq T_{\text{DRep}}\right) \wedge \left(\frac{S_{\text{SPO}}^{\text{yes}}}{S_{\text{SPO}}^{\text{delegated}}} \geq T_{\text{SPO}}\right)$$

Note that a CC ‘yes’ vote has no effect. Every CC member can voluntarily provide a yes vote, or abstain, to e.g. provide commentary.

Definitions

Constitutionality Challenge: A CC member voting No on a governance action. This is the trigger that activates full CC threshold evaluation.
Unchallenged Action: A governance action where no CC member has voted No. Such actions are considered constitutionally presumed-valid.
Challenged Action: A governance action where at least one CC member has voted No. Full CC threshold logic applies.

Detailed Ratification Rules

Unchallenged Actions (no CC `No` votes)

For any governance action type that currently requires CC approval:

If zero CC members have cast a No vote, the CC approval condition is satisfied automatically.
CC members MAY still vote Yes or Abstain on unchallenged actions, but these votes are not required for ratification.
The DRep and SPO thresholds remain unchanged and must still be met for their respective Governance Action types.

Challenged Actions (one or more CC `No` votes)

If one or more CC members cast a No vote for their respective allowed Governance Action types, the governance action transitions to “challenged” status.
Once challenged, the existing CIP-1694 CC threshold logic applies in full: the action requires CC Yes votes ≥ CC threshold to satisfy the CC approval condition.
The threshold is evaluated as today: each current committee member has one vote, and the threshold is the governance parameter committeeMinSize / committeeThreshold.
The DRep and SPO thresholds remain unchanged.

Actions That Do Not Require CC Approval

The following governance action types are unaffected by this proposal, as they do not require CC approval under CIP-1694:

Info Actions: No ratification required.
Motion of No Confidence: CC does not vote on motions against itself.
New Constitutional Committee / Threshold / Terms (during no-confidence state): CC does not participate.

Guardrails Script

The guardrails script (proposal policy) continues to apply to Protocol Parameter Updates and Treasury Withdrawals exactly as today. Optimistic Constitutionality changes only the CC vote evaluation, not script-based enforcement.

Vote Semantics

CC Vote	Current Meaning	New Meaning Under This CIP
`Yes`	Approve constitutionality	Approve constitutionality (optional)
`No`	Reject as unconstitutional	File a constitutionality challenge; triggers full CC evaluation
`Abstain`	Explicit abstention	Explicit abstention
(no vote)	Treated as `No` for threshold calculation	Treated as implicit approval

Critical change: Under CIP-1694, a CC member who does not vote is effectively counted against the action (since the threshold requires a sufficient number of Yes votes). Under this CIP, a CC member who does not vote is counted as implicitly approving. Only an explicit No vote signals disapproval.

Ledger Rule Changes

The changes are localized to the RATIFY transition rule in the Conway ledger specification.

Current `ccApproved` Predicate (Simplified)

-- Current: CC must reach threshold of Yes votes
ccApproved :: GovAction -> ConwayState -> Bool
ccApproved action st =
  let ccYes   = countCCVotes Yes action st
      ccSize  = committeeSize st
      thresh  = committeeThreshold st
  in  ccYes % ccSize >= thresh

Proposed `ccApproved` Predicate

-- Proposed: Presumed approved unless challenged, then standard threshold
ccApproved :: GovAction -> ConwayState -> Bool
ccApproved action st =
  let ccNo    = countCCVotes No action st
      ccYes   = countCCVotes Yes action st
      ccSize  = committeeSize st
      thresh  = committeeThreshold st
  in  if ccNo == 0
      then True                         -- Unchallenged: optimistically approved
      else ccYes % ccSize >= thresh     -- Challenged: standard threshold applies

State Query Extensions

The local-state-query protocol should be extended to expose:

Whether a governance action is currently challenged (has any CC No vote).
The identity of the challenging CC member(s).
Whether the action is in “optimistic” or “challenged” ratification mode.

New Governance Protocol Parameter (Optional)

This CIP proposes an optional new governance protocol parameter:

ccOptimisticEnabled :: Bool — Controls whether Optimistic Constitutionality is active. Default: True after activation. Can be set to False via a Protocol Parameter Change governance action to revert to CIP-1694 behavior.

This parameter provides a safety valve: if the community determines that Optimistic Constitutionality is being exploited or producing poor outcomes, it can be disabled through normal governance without requiring a hard fork.

Interaction with CC Expiry and No-Confidence

Expired CC members: An expired CC member’s prior votes (including No votes) are discarded at expiry, consistent with current behavior. An action that was challenged only by a now-expired member reverts to unchallenged status.
No-confidence state: When the CC is in a state of no-confidence, Optimistic Constitutionality does not apply — no governance actions can be ratified in this state, consistent with CIP-1694.

Versioning

This specification is versioned by the CIP document itself. Changes to the specification require an amendment to this CIP or a superseding CIP.

Rationale

Why Not Just Remove the CC?

The CC serves a necessary constitutional function. Even if DReps empirically catch bad proposals, the CC provides a formalized, accountable body that acts as last line of defense and upholds the standard of the Constitution. Optimistic Constitutionality preserves this role while making it reactive rather than proactive. The CC remains essential as the body authorized to formally declare “this violates the Constitution” — a declaration that carries specific meaning and consequences.

Effect on CC Compensation

Optimistic Constitutionality does not prescribe a compensation model, but it fundamentally reframes the economics:

Baseline workload drops dramatically. CC members no longer need to review and vote on every governance action. They monitor governance activity and intervene only when they identify constitutional concerns.
“Sleeping at the wheel” risk. an optimistic model creates a risk that CC members disengage entirely and miss the one action that requires intervention. This is a real concern, but it is mitigated by:
- CC members are, and in fact must be, active Cardano community members who follow governance activity through their own stake, DRep delegations, or community participation already anyway.
- Off-chain signaling (community forums, social media, direct outreach) creates organic alerting mechanisms.
- Sufficient Redundancy: One single Constitutinality Challenge is enough to stop the optimistic approval - with 5 to 7 CC member seats, the risk of everyone missing their call for intervention becomes marginal, but definitely even lower than today’s chance of not enough CCs voting in time.
- A Code of Conduct (developed in parallel) can establish minimum monitoring expectations.
Compensation models become lighter. If compensation is still desired, it can be structured as a modest retainer for monitoring duty rather than a per-action payment, dramatically reducing costs to the treasury.
Alternative incentive models become viable. With reduced expected effort, models such as proposer-funded constitutionality (where a governance action proposer pays for expedited CC review, in case it gets rejected) become more practical.
CIP-0149 (Optional DRep Compensation) already establishes a metadata-based, opt-in, no-ledger-change compensation standard for DReps. A similar lightweight mechanism could be explored for CC members if compensation is desired, without burdening the treasury.

Addressing Community Concerns

Concern	How This CIP Addresses It
CC members must be paid because their workload is high	Workload becomes reactive and low by default
Compensation attracts wrong candidates	Reduced workload means reduced compensation pressure; candidates motivated by reputation and influence remain competitive
Unpaid CC is unsustainable long-term	Monitoring duty is substantially lighter than active review; comparable to advisory board participation
CC votes too late, wasting DRep effort	Under optimistic model, DRep votes count regardless unless a CC challenge occurs; late CC action is a feature (they intervene only when needed)
Quality of CC votes is heterogeneous	Challenge mechanism incentivizes CC members to vote `No` only with genuine constitutional reasoning, not as a default
GAs are too generic, need better structure	Orthogonal concern (see CIP-0108 for governance metadata standards); this CIP does not preclude improved GA structure

Backward Compatibility

This proposal changes the semantics of CC non-voting from “implicit No” to “implicit approval.” This is a breaking change to the ratification logic and requires a hard fork.

Governance actions submitted before the activation epoch follow the pre-existing rules. Actions whose voting period spans the activation boundary should be evaluated under the new rules from the activation epoch onward.

All existing CC credentials, hot/cold key infrastructure (CIP-0105), governance metadata standards (CIP-0100, CIP-0108, CIP-0136), and wallet integrations (CIP-0030, CIP-0095) remain compatible. The change is entirely within the ledger’s RATIFY rule and does not affect transaction formats, certificate types, or on-chain data structures.

Remaining Risk

Power Abuse

Under Optimistic Constitutionality, CC members could single-handedly block all DRep- and SPO-approved, near-ratified Governance Actions by voting No up until the last block of an epoch, which would leave no time for the remaining CC to overrule the Constitutional Challenge. This risk is real, and currently known possible mitigations for it, such as introducing approval window extensions upon the first CC no vote are only increasing complexity, introduce new more complicated issues and are practically infeasible.
At the moment, the best mitigation for such power abuse would be to acknowledge this risk and rely on the possibilty to call out a state of no confidence - after a Governance Action got maliciously CC-blocked last minute.

Path to Active

Acceptance Criteria

The formal Conway ledger specification (cardano-ledger) is updated to reflect the modified RATIFY rule as described in this CIP.
The implementation is deployed on the preview testnet and exercised with both challenged and unchallenged governance actions.
The implementation is deployed on the preprod testnet with a functioning Constitutional Committee.
A hard fork governance action activating the new ledger era is ratified and enacted on Cardano mainnet.
The local-state-query protocol exposes challenge status for governance actions.

Info Action

A community vote is most likely beneficial or even required for such a change, as it cannot individually be voted on within the hardfork GA, with which it would get activated.

Implementation Plan

This CIP requires a hard fork to activate, as it changes the ledger’s ratification semantics.

Phase 1: Specification & Review

Formal specification update to the Conway ledger rules (Agda/Haskell in IntersectMBO/cardano-ledger, pragma-org/amaru, blinklabs-io/dingo and others).
Community review period (minimum 3 months) + .
CIP editors and Ledger team review.

Phase 2: Testnet Deployment

Implementation in cardano-ledger behind a feature flag tied to the new era.
Deployment on preview testnet.
Integration testing with governance tooling (GovTool, cardano-cli, Eternl, Lace).
Deployment on preprod testnet.

Phase 3: Mainnet Activation

Hard fork governance action submitted, requiring approval from the CC, DReps, and SPOs under the current (pre-Optimistic) rules.
Upon ratification and enactment at the subsequent epoch boundary, Optimistic Constitutionality becomes active with ccOptimisticEnabled :: Bool set to TRUE.

Optional: Off-Chain Convention (Pre-Hard-Fork)

Before the hard fork, the current CC could voluntarily adopt an “optimistic” convention:

CC members agree (via off-chain coordination or an Info Action) to vote Yes on all governance actions unless they intend to challenge constitutionality.
CC members who identify a constitutional concern vote No and publish a rationale (per CIP-0136 metadata).
This convention achieves the behavioral outcome of Optimistic Constitutionality without ledger changes, serving as a live experiment to validate the model.

References

Copyright

This CIP is licensed under CC-BY-4.0.

Jeremy_Otieno · 20 March 2026 04:07

I think this is a very thoughtful shift in how we interpret the role of the CC. The observation that DReps already act as an effective first filter is important, and it makes sense to question whether mandatory CC approval for every action is still justified.

Moving toward a more “optimistic” model feels aligned with decentralization in spirit, especially if it reduces friction and preserves DRep effort.

That said, it also introduces an interesting tradeoff — we are relying more on active vigilance rather than structured review. It will be important to see how the ecosystem handles that responsibility over time.

Overall, this feels like a meaningful direction worth exploring, especially if tested first through off-chain convention.

Topic		Replies	Views
Eastern Cardano Council - Further Statement on the Net Change Limit Constitutional Committee	4	73	28 March 2026
:netherlands: CIP-1694: Een On-Chain gedecentraliseerd bestuursmechanisme voor Voltaire Translations translation , dutch	0	765	23 January 2023
:es: SPANISH DUBBING Constitución Cardano 2.0 \| Día Dev y de Gobernanza en Rare Evo \| IOG 8 Ago 2025 Anuncios español-🇪🇸	0	40	15 August 2025
🇪🇸 CIP 1694 - Mecanismo de gobernanza descentralizada en la cadena para Voltaire Recursos traducción	1	1076	17 January 2023
🇪🇸 Un Primer Paso Hacia la Gobernanza Descentralizada en Cadena: Nuevo Borrador CIP-1694 Recursos traducción	2	1092	18 March 2023

Optimistic Constitutionality

Summary

Overview

Changes proposed

Path to Active

RISKS

OPEN QUESTIONS

BELOW FOLLOWS THE FULL CIP

Created: 2026-03-18 License: CC-BY-4.0

Abstract

Motivation

The Current Model’s Inefficiencies

Specification

Overview

After CIP-1694

Under Optimistic Constitutionality, this logic scheme changes to:

Definitions

Detailed Ratification Rules

Unchallenged Actions (no CC No votes)

Challenged Actions (one or more CC No votes)

Actions That Do Not Require CC Approval

Guardrails Script

Vote Semantics

Ledger Rule Changes

Current ccApproved Predicate (Simplified)

Proposed ccApproved Predicate

State Query Extensions

New Governance Protocol Parameter (Optional)

Interaction with CC Expiry and No-Confidence

Versioning

Rationale

Why Not Just Remove the CC?

Effect on CC Compensation

Addressing Community Concerns

Backward Compatibility

Remaining Risk

Power Abuse

Path to Active

Acceptance Criteria

Info Action

Implementation Plan

Phase 1: Specification & Review

Phase 2: Testnet Deployment

Phase 3: Mainnet Activation

Optional: Off-Chain Convention (Pre-Hard-Fork)

References

Copyright

Related topics

Created: 2026-03-18
License: CC-BY-4.0

Unchallenged Actions (no CC `No` votes)

Challenged Actions (one or more CC `No` votes)

Current `ccApproved` Predicate (Simplified)

Proposed `ccApproved` Predicate