CIP-0111: Process for Reducing Super Validator Weight

Abstract

The CIP outlines the process by which the network reduces the weight of a Super Validator (“SV”) under certain circumstances. The process includes (i) a review of the circumstances associated with the SV, (ii) an off-chain governance procedure, and (iii) a corresponding on-chain vote and configuration change.

A “Ghost SV” refers to an SV in the process of completing milestones associated with an allocation of weight. While operating as a Ghost SV, unminted rewards associated with its total potential weight accrue in escrow. The process introduced in this CIP also addresses how to calculate and "burn” any unminted rewards associated with Ghost SV weight that have been reduced while preserving unminted rewards in escrow for Ghost SVs in good standing.

Rationale

As the network continues to grow and evolve, there may be circumstances that require the network to reduce an SV’s weight (partially or entirely to 0). Illustrative cases in which an SV’s weight should be considered for be reduction include, but are not limited to:

• A Ghost SV fails to achieve a milestone associated with the CIP granting it SV weight and therefore the network should no longer accrue and escrow SV rewards (i.e., weight removal) associated with the milestone / weight in question; or

• An SV fails to maintain the activity necessary to meet on-going activity-based milestone requirements and therefore should commensurately have its weight reduced (partially or entirely to 0); or

• An SV does not lock the requisite CC to maintain its current weight and thus has its weight reduced as set forth by CIP-0105 (SV Locking).

To avoid any doubt, any scenario in which an SV has its weight reduced (partially or entirely to 0), the process proposed in this CIP should be followed. We propose the following procedure and specification to ensure a fair, orderly, and transparent process associated with these actions.

Specification

Governance Procedure

1. The SVs delegate creating and administering a process to evaluate and recommend SVs for weight reductions to the Tokenomics Committee (“TWG”). The TWG may delegate this analysis and recommendation process to its sub-groups such as the Accountability Committee (“AComm”). This review and recommendation process must consider the requirements set forth in any CIPs associated with the SV in question or broadly established expectations, requirements, or opt-in constructs for SVs. It may also consider other factors including, but not limited to, additional commitments made or the SV’s participation in governance and other network functions. At a minimum, the TWG must review SVs for potential weight reduction whenever the deadline for a milestone associated with a milestone-based SV CIP passes.

2. When deemed appropriate, TWG or its delegates establish and communicate a formal recommendation with requisite details to the broader TWG participants and SVs to reduce the weight of the relevant SV.

3. SVs must review this recommended weight change and vote via its standard off-chain voting process to ratify as a formal recommendation to SVs. The scope of this vote and its results must be posted on the Canton Foundation’s (“CF”) tokenomics-announce discussion forum (or any other reasonable and public location).

In the event the vote completes in favor of reducing an SV’s weight, within three days the CF or another SV will propose an on-chain vote. Voting SVs must each evaluate the formal recommendation and, if accepted by that voting SV, vote to update the associated SV’s weight, to be effective at threshold. SVs should then vote with the standard on-chain voting process.

On-Chain Vote

The proposing SV (the “Proposer”) should send an on-chain vote request using the following criteria to specify the appropriate change:

• If an SV node should be entirely reduced (weight = 0) the Proposer:

  1. Creates a vote request to action “Update SV Reward Weight”.

  2. Configures the “Update SV Reward Weight” action with the Reduced SV to 0.

• If a hosted SV should be entirely reduced (weight = 0), the Proposer:

  1. Creates a vote request to action “Update SV Reward Weight”.

  2. Configures the “Update SV Reward Weight” action with the Host SV node.

  3. Reduces the current weight of the Host SV Party ID by the entire weight of the Reduced SV.

  4. Notifies each SV Operator to update their approved SV Onboarding config to adjust the weight of the Host SV node.

  5. Operational Note: A vote cannot currently force adjustment of a Host SV beneficiary list. The Host SV should simultaneously remove the Reduced SV from its beneficiaries list. Failing to do so may negatively impact the weight of other hosted SVs in good standing on the Host SV node.

• If an SV node should be partially reduced (reduce weight to a value > 0), the Proposer:

  1. Creates a vote request to action “Update SV Reward Weight”.

  2. Configures the “Update SV Reward Weight” action with the Reduced SV.

  3. Reduces the weight of the Reduced SV Party ID by the weight amount attributed to the missed milestones as per AComm’s recommendation.

  4. Notifies each SV Operator to update their approved SV Onboarding config to adjust the weight of the SV node.

• If a hosted SV should be partially reduced (reduce weight to a value > 0), the Proposer:

  1. Creates a vote request to action “Update SV Reward Weight”.

  2. Configures the “Update SV Reward Weight” with the elects host SV node Party ID.

  3. Reduce the weight of the host SV node by the amount attributed to the missed milestones as per AComm’s recommendation.

  4. Notifies each SV Operator to update their approved SV Onboarding config to adjust the weight of the Host SV node

  5. Operational Note: A vote cannot currently force adjustment of a Host SV beneficiary list. The Host SV should simultaneously remove the Reduced SV from its beneficiaries list. Failing to do so may negatively impact the weight of other hosted SVs in good standing on the Host SV node.

The vote should be effective at threshold and carried across Devnet, Testnet, and Mainnet environments. The vote request should also include (i) a summary of the proposed action (e.g., reduce “A” node by “X” weight for reducing “B” SV) and (ii) the tokenomics-announce subgroup URL link of the TWG update.

Calculating the Unminted Supply

Unminted CC allocated to ghost SVs that do not achieve SV milestones (and therefore do not mint these CC) should not be included in the unminted supply for future usage by Governance. These unminted CC are represented onchain as unminted SV reward coupons. These coupons should be burned to indicate the tokens associated with them are no longer in the unminted pool. Enabling this functionality will require a change to the Canton Coin SV Reward DAML model.

To calculate the total unminted supply excluding the number of coupons originally allocated to Reduced SVs, start with defining the range of rounds for which unminted supply figures are desired; then, in each round, calculate the following. The fields reference those in the corresponding minting templates.

1. Sum weight for all ghost SVs (including for Reduced SVs at their weight prior to this governance action); referred to as total_ghost_weight

2. numCouponsIssued * total_ghost_weight as sum of all unconverted SV reward coupons for ghost SVs in the round; referred to as total_ghost_coupons

3. total_ghost_coupons + total_burned_ghost_coupons as the total number of unminted coupons; referred to as total_unminted_coupons

4. issuancePerSvRewardCoupon * total_unminted_coupons as the total unminted CC for ghost SVs; referred to as total_ghost_cc

5. Take the corresponding amuletToIssuePerYear / ( 365 * 144 ) as the maximum number of CC available to be minted; referred to as max_mints

6. Take max_mints – total_ghost_cc as the number of unminted CC excluding CC originally escrowed for both unreduced and reduced ghost SVs

Appendix: On-Chain Vote Diagram

<p align="center"> <img src="0.jpeg" width="700"> </p>

Copyright

This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.

Changelog

• 2026-04-23: Approved
• 2026-04-22: Proposed
• 2026-03-20: draft published