Hi all, as Chris mentioned during today’s Tokenomics meeting, please see below for the draft CIP for reducing SV weight.  Feel free to respond with any thoughts or questions.

 

---

 

CIP‑01XX: Process for Reducing Super Validator Weight

Type: Governance
Status: Draft
Author(s): Chris Zuehlke / Andrew Bryan / Alex Chen
Created: 2026-03-11
License: CC0-1.0

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 or entirely remove an SV’s weight.  Illustrative cases in which an SV’s weight should be considered for be reduction or removal 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 or removed; 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:
  • Creates a vote request to action “Offboard Member” and
  • Configures the “Offboard Member” action with the SV Party ID whose weight should be reduced to 0 ”Reduced SV”.
• If a hosted SV should be entirely reduced (weight = 0), the Proposer:
  • Creates a vote request to action “Update SV Reward Weight”,
  • Configures the “Update SV Reward Weight” action with the  Host SV node, and
  • Reduces the current weight of the Host SV Party ID by the entire weight of the Reduced SV.
  • 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:
  • Creates a vote request to action “Update SV Reward Weight”,
  •  Configures the “Update SV Reward Weight” action with the Reduced SV, and
  • Reduces the weight of the Reduced SV Party ID by the weight amount attributed to the missed milestones as per AComm’s recommendation.
• If a hosted SV should be partially reduced (reduce weight to a value > 0), the Proposer:
  • Creates a vote request to action “Update SV Reward Weight”, 
  • Configures the “Update SV Reward Weight” with the elects host SV node Party ID, and
  • Reduce the weight of the host SV node by the amount attributed to the missed milestones as per AComm’s recommendation.
• If an SV (node or hosted) were to have a weight of 0 as a result of these actions, the SV should be offboarded and entirely removed.  Weight equal to zero in practice means the participant is no longer operating a SV and should have their ability to participate in governance votes revoked.

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.  However, because these CC were never minted, they cannot be burned.  To account for this, and avoid unintentionally inflating CC supply, we propose a formal calculation for unminted SV rewards.  

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. issuancePerSvRewardCoupon * total_ghost_coupons as the total unminted CC for ghost SVs; referred to as total_ghost_cc
4. Take the concurrent amuletToIssuePerYear / ( 365 * 144 ) as the maximum number of CC available to be minted; referred to as max_mints
5. Take max_mints - total_ghost_cc as the number of unminted CC excluding CC originally escrowed for both unreduced and reduced ghost SVs

Copyright

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

Appendix: On-Chain Vote Diagram

 

 

This e-mail and any attachments may contain information that is confidential and proprietary and otherwise protected from disclosure. If you are not the intended recipient of this e-mail, do not read, duplicate or redistribute it by any means. Please immediately delete it and any attachments and notify the sender that you have received it by mistake. Unintended recipients are prohibited from taking action on the basis of information in this e-mail or any attachments. The DRW Companies make no representations that this e-mail or any attachments are free of computer viruses or other defects.

Thanks for the comments, Eric - I've adjusted the text from the original post to include these considerations. 

 

Kind regards,

Alex

 

--

Cumberland

Hi All,

 

Cumberland would like to propose the following path forward for this CIP based on feedback from the community:

 

• Remove the offboarding of a SV node if the operator's weight goes to 0.  While we do think this is an important element of the CIP, offboarding SV nodes without a formal process for onboarding new SV operator nodes may decrease Global Synchronizer reliability and a decreased size of the  SV operator set
• Introduce a follow-up CIP that addresses both offboarding SV operator nodes and introducing new SV operator nodes as part of a consolidated proposal
• Retain other portions of this SV, such that its reduced scope is restricted to reducing weight of existing SVs

 

We'd like to discuss this as part of the Canton Foundation Tokenomics Working Group meeting tomorrow to gather feedback and potentially move the reduced scope CIP to a vote.

 

Andrew

Alex -  many thanks for this update. MPCH would like to sponsor or endorse. 

Get Outlook for Mac

From: cip-discuss@... <cip-discuss@...> on behalf of Alex Chen via lists.sync.global <alechen=cumberland.io@...>
Date: Wednesday, April 22, 2026 at 11:11 AM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Process for Reducing Super Validator Weight - Alex Chen

Hi all, following today’s TWG discussion, please see below for the updated draft CIP for SV Weight Reduction.

 

---

CIP‑01XX: Process for Reducing Super Validator Weight

Type: Governance
Status: Draft
Author(s): Chris Zuehlke / Andrew Bryan / Alex Chen
Created: 2026-03-18; Updated: 2026-04-22
License: CC0-1.0

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

Copyright

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

Appendix: On-Chain Vote Diagram

This e-mail and any attachments may contain information that is confidential and proprietary and otherwise protected from disclosure. If you are not the intended recipient of this e-mail, do not read, duplicate or redistribute it by any means. Please immediately delete it and any attachments and notify the sender that you have received it by mistake. Unintended recipients are prohibited from taking action on the basis of information in this e-mail or any attachments. The DRW Companies make no representations that this e-mail or any attachments are free of computer viruses or other defects.