CIP-0111: Process for Reducing Super Validator Weight - Alex Chen
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-18
License: CC0-1.0Abstract
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
- 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.
- 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.
- 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”.
- Notifies each SV Operator to update their approved SV Onboarding config to remove the 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.
- Reduces the current weight of the Host SV Party ID by the entire weight of the Reduced SV.
- Notifies each SV Operator to update their approved SV Onboarding config to adjust the weight of the Host SV node.
- 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:
- Creates a vote request to action “Update SV Reward Weight”.
- Configures the “Update SV Reward Weight” action with the Reduced SV.
- Reduces the weight of the Reduced SV Party ID by the weight amount attributed to the missed milestones as per AComm’s recommendation.
- 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:
- Creates a vote request to action “Update SV Reward Weight”.
- Configures the “Update SV Reward Weight” with the elects host SV node Party ID.
- Reduce the weight of the host SV node by the amount attributed to the missed milestones as per AComm’s recommendation.
- Notifies each SV Operator to update their approved SV Onboarding config to adjust the weight of the Host SV node
- 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 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. If a Host SV node has their SV Weight reduced to 0, SVs hosted on that node must migrate to a different Host SV. It is recommended that this occurs prior to the Host SV being set to 0, as hosted SVs on that node will temporarily have their weight reduced to 0 until migrated.
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.
- Sum weight for all ghost SVs (including for Reduced SVs at their weight prior to this governance action); referred to as total_ghost_weight
- numCouponsIssued * total_ghost_weight as sum of all unconverted SV reward coupons for ghost SVs in the round; referred to as total_ghost_coupons
- total_ghost_coupons + total_burned_ghost_coupons as the total number of unminted coupons; referred to as total_unminted_coupons
- issuancePerSvRewardCoupon * total_unminted_coupons as the total unminted CC for ghost SVs; referred to as total_ghost_cc
- Take the concurrent amuletToIssuePerYear / ( 365 * 144 ) as the maximum number of CC available to be minted; referred to as max_mints
- 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
- thanks for drafting this - overall very good but i would recommend a small changeWRT Unminted supply, it is possible to burn the coupon. I understand there is some implementation work to be done but it would be fairly easy to do so. I think we should include in this CIP that we will retire the unminted coupons associated with the reduced weightThis would add further clarity to all CC holders and fully finalize the decisionOn Wed, Mar 11, 2026 at 2:00 PM Alex Chen via lists.sync.global <alechen=cumberland.io@...> wrote:
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.0Abstract
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
- 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.
- 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.
- 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.
- Sum weight for all ghost SVs (including for Reduced SVs at their weight prior to this governance action); referred to as total_ghost_weight
- numCouponsIssued * total_ghost_weight as sum of all unconverted SV reward coupons for ghost SVs in the round; referred to as total_ghost_coupons
- issuancePerSvRewardCoupon * total_ghost_coupons as the total unminted CC for ghost SVs; referred to as total_ghost_cc
- Take the concurrent amuletToIssuePerYear / ( 365 * 144 ) as the maximum number of CC available to be minted; referred to as max_mints
- 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.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - Thanks for the comments, Eric - I've adjusted the text from the original post to include these considerations.Kind regards,Alex--Cumberland
- ok - so do we have enough feedback to move this forward to a vote?On Wed, Mar 18, 2026 at 9:11 AM Alex Chen via lists.sync.global <alechen=cumberland.io@...> wrote:Thanks for the comments, Eric - I've adjusted the text from the original post to include these considerations.Kind regards,Alex--Cumberland
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - Any further comments/questions? There are some nuanced details for how this CIP will be implemented in practice (assuming it passes) so any and all feedback, including a simple confirmation that you believe the details are understandable/correct, is helpful.If there are no other comments in the next day or two Cumberland will sponsor.ThanksChris
- toggle quoted message Show quoted text
From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Sent: Monday, March 23, 2026 5:10:00 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-01XX: Process for Reducing Super Validator WeightAny further comments/questions? There are some nuanced details for how this CIP will be implemented in practice (assuming it passes) so any and all feedback, including a simple confirmation that you believe the details are understandable/correct, is helpful.If there are no other comments in the next day or two Cumberland will sponsor.ThanksChris - There are still some technical gaps in the proposed implementation details; I'll reach out to Cumberland.
- toggle quoted message Show quoted text
This CIP appears to remove an SV from the Canton Network if it does not lock tokens. Is this interpretation correct?
From: cip-discuss@... <cip-discuss@...> On Behalf Of Chris Zuehlke via lists.sync.global
Sent: Monday, March 23, 2026 5:10 PM
To: cip-discuss@...
Subject: Re: [cip-discuss] CIP-01XX: Process for Reducing Super Validator WeightAny further comments/questions? There are some nuanced details for how this CIP will be implemented in practice (assuming it passes) so any and all feedback, including a simple confirmation that you believe the details are understandable/correct, is helpful.
If there are no other comments in the next day or two Cumberland will sponsor.
Thanks
Chris
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. When in doubt, contact netGenius.
- Hi James -This CIP proposes to remove an SV if its weight is reduced to 0. There are multiple ways that can theoretically happen including as set forth by the SV Locking CIP or reasons not yet contemplated.I welcome all feed back on this topic or any other aspect of the proposed CIP. I recognize that what's proposed in this CIP is a meaningful step to take but in the interest providing a thorough CIP that considers all potential cases I thought it appropriate to address the case of an SV with weight of 0.Chris
- Thanks to all for the work on this CIP.Given its importance, I strongly believe this should be afforded a slot at our next foundation meeting for open discussion before finalization.
- 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 - fine by me - we need this general ability to remove weight from the pool for the SV Locking and we can address the other points at a later datethanks for advancing thisOn Tue, Apr 21, 2026 at 6:22 PM Andrew Bryan via lists.sync.global <abryan=cumberland.io@...> wrote: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
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. 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.0Abstract
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.
- Alex - many thanks for this update. MPCH would like to sponsor or endorse.
Get Outlook for Mac
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.0Abstract
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
- DA also happy to sponsor/endorseOn Wed, Apr 22, 2026 at 11:22 AM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote: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.0Abstract
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.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - Happy to have MPCH/DA sponsor/endorse.Great to see this level of support for such an important CIP.
