CIP-0105: Super Validator (SV) Staking
- Please see below for open discussion.
Number: CIP-TBD Title: Super Validator (SV) Staking Author(s): W Eric Saraniecki Type: Tokenomics Status: Draft Created: 2026-01-21 License: CC0-1.0
SV Staking
Summary
This proposal introduces Super Validator (SV) Staking to the Canton Network. Under this mechanism, SVs must lock a defined percentage of their lifetime earned SV rewards in order to maintain SV weight going forward.
If an SV does not meet the required threshold, any Canton Coin (CC) holder may lock CC to fill the gap and earn a pro-rata share of the remaining SV rewards.
The objective is to:
Align long-term incentives between SVs and the network
Open SV reward participation to the broader CC holder base
Specification
1. SV Staking Requirement
To earn SV weight going forward, an SV must lock a percentage of its lifetime earned SV rewards into a staking contract with an indefinite lock.
Only actively locked CC is counted toward the SV weighting algorithm.
Stakers may unlock staked CC at any time; however, unlocks take 365 days to become effective.
2. Staking-to-Weight Schedule
SV weight going forward is determined by the percentage of required stake that is actively locked:
Min % of Lifetime Earnings Required to be Locked
Forward SV Reward Earned
80%
100%
60%
60%
40%
40%
20%
20%
< 20%
0%
This is a tiered model, not a continuous curve, to encourage clear commitment thresholds.
3. Forward Staking of Newly Earned Rewards
Once an SV is configured at a given Weight Tier, it must continue to lock the same percentage of newly earned SV rewards in order to maintain that tier going forward.
Failure to do so results in an automatic downgrade to the appropriate tier at the next calculation epoch.
4. Third-Party Staking (Gap Filling)
If an SV does not fully stake to the threshold required for its maximum historical weight:
The unstaked Weight is transferred to an SV Staking Pool
Any CC holder may stake CC to the Staking Pool
Third-party stakers earn a pro-rata share of the SV rewards corresponding to the unstaked portion
These rewards are distributed according to the same unlock mechanics as SV-locked rewards
5. Phased Implementation
To reduce operational risk and allow a smooth transition to fully automated SV staking, this proposal will be implemented in three phases.
Phase 1: Transitional Enforcement (Manual)
Timing
Goes into effect within 30 days of CIP approval
Requirements
SVs must move CC intended to count toward SV staking into a segregated, auditable PartyId
The PartyId information must be shared with the Foundation
Only CC held in the disclosed PartyId will be considered for SV staking calculations
Weight Calculation
SV reward weights will be adjusted manually:
Once at the 30-day threshold
Then once every 10 days thereafter
Under-Staked Weight Handling
A Foundation-controlled “ghost” Validator will be created
Any SV weight not backed by sufficient disclosed stake will be:
Removed from the SV
Assigned to the ghost Validator
Rewards associated with this weight will accrue to the ghost Validator pending Phase 3
Phase 2: On-Chain Locking (Automated SV Staking)
Activation
Begins once the CC locking mechanism is deployed to MainNet
Requirements
SVs must utilize the on-chain lock mechanism
Only actively locked CC will count toward SV weight
PartyId-based accounting is deprecated
Weight Calculation
SV weights will be adjusted automatically every block
Weight tiers are determined solely by actively locked CC
Unlocking Rules
SVs may initiate an unlock at any time
Unlocks take 365 days to become effective
Phase 3: Open Market Gap Filling (Third-Party Staking)
Activation
Begins after a staked CC distribution mechanism is deployed to MainNet
Mechanism
Any under-staked SV weight is made available to the market
Any CC holder may lock CC to claim a pro-rata share of the under-staked SV rewards
CC holders use the same locking mechanism introduced in Phase 2
Parity Requirement
Third-party staking must follow the exact same rules as SV staking
The Foundation’s ghost Validator:
Is subject to the same lifetime staking thresholds
Must maintain the required lock levels (historically and forward)
May only distribute rewards backed by valid locked CC
Examples
Example 1: Fully Staked SV
SV1 has earned 1B CC as an SV since genesis
SV1 is currently a W10 SV
To maintain W10 going forward, SV1 must lock 800M CC (80%)
SV1 continues earning 100% of W10 rewards, and must lock 80% of new rewards locked forward to maintain 100% earnings
Example 2: Partially Staked SV
SV2 has earned 1B CC as an SV since genesis
SV2 locks 400M CC (40%)
SV2 earns W4 going forward
SV2 must continue locking 40% of newly earned W4 rewards to maintain W4
The remaining W6 rewards are made available to third-party CC stakers
Exemptions
The following entities are exempt from the SV staking requirement:
The Foundation
Due to its mandate to support the ecosystem, issue grants, fund development, and manage public goods
The Ecosystem Fund SV operated by 5N
Due to its role in ecosystem support and capital deployment rather than reward accumulation
Any SV that can prove its coins are already locked for greater than 1 Year
Once those coins are unlocked, the exemption will lapse
Backwards Compatibility
This proposal does not modify:
Historical SV rewards
Previously earned distributions
Existing SV designations
All changes apply prospectively to forward SV reward calculations.
Future CIPs will propose implementation details for Phases 2 and 3.
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.
- 2025-01-27: Initial draft of the proposal
- toggle quoted message Show quoted textEric, thank you again for taking the initial draft on this idea.Echoing what was said on the tokenomics call earlier today- I think conceptually a form of 'locking' or 'bonding' makes a ton of sense but we should be a bit careful with the terminology 'staking' as it implies Proof of Stake, which is different from the Canton architecture. There's clearly been a trend in the last ~6 months to evolve staking practices across legacy PoS blockchains and I think this is a great opportunity for Canton to become a leader. Happy to collaborate with anyone that wants to brainstorm semantics/ definitions on this rollout.Also I thought it'd be helpful to open up a few questions:
- Will there be a way to automate the 80% (or other tiers) SVs choose to bond?
- It could be burdensome for an SV to constantly manage their 'staked position' to maintain their desired tier
- Would SV rewards accumulating in a ghost validator as part of a milestone release count toward the 'staked' amount?
- Any thoughts on the construction of the stake pool?
- Would there be a max amount a party can stake?
- Are the tokens being locked by SVs eligible for this stake pool?
- Since this SV bucket will essentially turn into the yield for stakers, are there any rough calculations various APYs could look like in different scenarios?
- IE we could expect __ % APY if 'X' percent of the SV pool is no longer fully minted
On Wed, Jan 21, 2026 at 11:43 AM Amanda Martin via lists.sync.global <amanda=canton.foundation@...> wrote:Please see below for open discussion.Number: CIP-TBD Title: Super Validator (SV) Staking Author(s): W Eric Saraniecki Type: Tokenomics Status: Draft Created: 2026-01-21 License: CC0-1.0
SV Staking
Summary
This proposal introduces Super Validator (SV) Staking to the Canton Network. Under this mechanism, SVs must lock a defined percentage of their lifetime earned SV rewards in order to maintain SV weight going forward.
If an SV does not meet the required threshold, any Canton Coin (CC) holder may lock CC to fill the gap and earn a pro-rata share of the remaining SV rewards.
The objective is to:
Align long-term incentives between SVs and the network
Open SV reward participation to the broader CC holder base
Specification
1. SV Staking Requirement
To earn SV weight going forward, an SV must lock a percentage of its lifetime earned SV rewards into a staking contract with an indefinite lock.
Only actively locked CC is counted toward the SV weighting algorithm.
Stakers may unlock staked CC at any time; however, unlocks take 365 days to become effective.
2. Staking-to-Weight Schedule
SV weight going forward is determined by the percentage of required stake that is actively locked:
Min % of Lifetime Earnings Required to be Locked
Forward SV Reward Earned
80%
100%
60%
60%
40%
40%
20%
20%
< 20%
0%
This is a tiered model, not a continuous curve, to encourage clear commitment thresholds.
3. Forward Staking of Newly Earned Rewards
Once an SV is configured at a given Weight Tier, it must continue to lock the same percentage of newly earned SV rewards in order to maintain that tier going forward.
Failure to do so results in an automatic downgrade to the appropriate tier at the next calculation epoch.
4. Third-Party Staking (Gap Filling)
If an SV does not fully stake to the threshold required for its maximum historical weight:
The unstaked Weight is transferred to an SV Staking Pool
Any CC holder may stake CC to the Staking Pool
Third-party stakers earn a pro-rata share of the SV rewards corresponding to the unstaked portion
These rewards are distributed according to the same unlock mechanics as SV-locked rewards
5. Phased Implementation
To reduce operational risk and allow a smooth transition to fully automated SV staking, this proposal will be implemented in three phases.
Phase 1: Transitional Enforcement (Manual)
Timing
Goes into effect within 30 days of CIP approval
Requirements
SVs must move CC intended to count toward SV staking into a segregated, auditable PartyId
The PartyId information must be shared with the Foundation
Only CC held in the disclosed PartyId will be considered for SV staking calculations
Weight Calculation
SV reward weights will be adjusted manually:
Once at the 30-day threshold
Then once every 10 days thereafter
Under-Staked Weight Handling
A Foundation-controlled “ghost” Validator will be created
Any SV weight not backed by sufficient disclosed stake will be:
Removed from the SV
Assigned to the ghost Validator
Rewards associated with this weight will accrue to the ghost Validator pending Phase 3
Phase 2: On-Chain Locking (Automated SV Staking)
Activation
Begins once the CC locking mechanism is deployed to MainNet
Requirements
SVs must utilize the on-chain lock mechanism
Only actively locked CC will count toward SV weight
PartyId-based accounting is deprecated
Weight Calculation
SV weights will be adjusted automatically every block
Weight tiers are determined solely by actively locked CC
Unlocking Rules
SVs may initiate an unlock at any time
Unlocks take 365 days to become effective
Phase 3: Open Market Gap Filling (Third-Party Staking)
Activation
Begins after a staked CC distribution mechanism is deployed to MainNet
Mechanism
Any under-staked SV weight is made available to the market
Any CC holder may lock CC to claim a pro-rata share of the under-staked SV rewards
CC holders use the same locking mechanism introduced in Phase 2
Parity Requirement
Third-party staking must follow the exact same rules as SV staking
The Foundation’s ghost Validator:
Is subject to the same lifetime staking thresholds
Must maintain the required lock levels (historically and forward)
May only distribute rewards backed by valid locked CC
Examples
Example 1: Fully Staked SV
SV1 has earned 1B CC as an SV since genesis
SV1 is currently a W10 SV
To maintain W10 going forward, SV1 must lock 800M CC (80%)
SV1 continues earning 100% of W10 rewards, and must lock 80% of new rewards locked forward to maintain 100% earnings
Example 2: Partially Staked SV
SV2 has earned 1B CC as an SV since genesis
SV2 locks 400M CC (40%)
SV2 earns W4 going forward
SV2 must continue locking 40% of newly earned W4 rewards to maintain W4
The remaining W6 rewards are made available to third-party CC stakers
Exemptions
The following entities are exempt from the SV staking requirement:
The Foundation
Due to its mandate to support the ecosystem, issue grants, fund development, and manage public goods
The Ecosystem Fund SV operated by 5N
Due to its role in ecosystem support and capital deployment rather than reward accumulation
Any SV that can prove its coins are already locked for greater than 1 Year
Once those coins are unlocked, the exemption will lapse
Backwards Compatibility
This proposal does not modify:
Historical SV rewards
Previously earned distributions
Existing SV designations
All changes apply prospectively to forward SV reward calculations.
Future CIPs will propose implementation details for Phases 2 and 3.
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.
- 2025-01-27: Initial draft of the proposal
- toggle quoted message Show quoted textI echo Chris comments on the PoS and the confusion this could create. We should use words like Bond/Lock and avoid confusions.Also, something that is also material: Some SVs operate in the US and rewards count as income at the time that are being generated. I believe that a 70% is more appropriate number, allowing those who need to sell to cover operations etc to actually do it.And another thing: since we allow 3rd parties to ‘back on behalf of’, will this backing also be subject to lock? Thinking that this can be gamed in a bad way and create situations where SV are left with not enough backing.Y.On Thu, Jan 22, 2026 at 00:52 Chris Matturri via lists.sync.global <chris=proofgroup.xyz@...> wrote:Eric, thank you again for taking the initial draft on this idea.Echoing what was said on the tokenomics call earlier today- I think conceptually a form of 'locking' or 'bonding' makes a ton of sense but we should be a bit careful with the terminology 'staking' as it implies Proof of Stake, which is different from the Canton architecture. There's clearly been a trend in the last ~6 months to evolve staking practices across legacy PoS blockchains and I think this is a great opportunity for Canton to become a leader. Happy to collaborate with anyone that wants to brainstorm semantics/ definitions on this rollout.Also I thought it'd be helpful to open up a few questions:
- Will there be a way to automate the 80% (or other tiers) SVs choose to bond?
- It could be burdensome for an SV to constantly manage their 'staked position' to maintain their desired tier
- Would SV rewards accumulating in a ghost validator as part of a milestone release count toward the 'staked' amount?
- Any thoughts on the construction of the stake pool?
- Would there be a max amount a party can stake?
- Are the tokens being locked by SVs eligible for this stake pool?
- Since this SV bucket will essentially turn into the yield for stakers, are there any rough calculations various APYs could look like in different scenarios?
- IE we could expect __ % APY if 'X' percent of the SV pool is no longer fully minted
On Wed, Jan 21, 2026 at 11:43 AM Amanda Martin via lists.sync.global <amanda=canton.foundation@...> wrote:Please see below for open discussion.Number: CIP-TBD Title: Super Validator (SV) Staking Author(s): W Eric Saraniecki Type: Tokenomics Status: Draft Created: 2026-01-21 License: CC0-1.0
SV Staking
Summary
This proposal introduces Super Validator (SV) Staking to the Canton Network. Under this mechanism, SVs must lock a defined percentage of their lifetime earned SV rewards in order to maintain SV weight going forward.
If an SV does not meet the required threshold, any Canton Coin (CC) holder may lock CC to fill the gap and earn a pro-rata share of the remaining SV rewards.
The objective is to:
Align long-term incentives between SVs and the network
Open SV reward participation to the broader CC holder base
Specification
1. SV Staking Requirement
To earn SV weight going forward, an SV must lock a percentage of its lifetime earned SV rewards into a staking contract with an indefinite lock.
Only actively locked CC is counted toward the SV weighting algorithm.
Stakers may unlock staked CC at any time; however, unlocks take 365 days to become effective.
2. Staking-to-Weight Schedule
SV weight going forward is determined by the percentage of required stake that is actively locked:
Min % of Lifetime Earnings Required to be Locked
Forward SV Reward Earned
80%
100%
60%
60%
40%
40%
20%
20%
< 20%
0%
This is a tiered model, not a continuous curve, to encourage clear commitment thresholds.
3. Forward Staking of Newly Earned Rewards
Once an SV is configured at a given Weight Tier, it must continue to lock the same percentage of newly earned SV rewards in order to maintain that tier going forward.
Failure to do so results in an automatic downgrade to the appropriate tier at the next calculation epoch.
4. Third-Party Staking (Gap Filling)
If an SV does not fully stake to the threshold required for its maximum historical weight:
The unstaked Weight is transferred to an SV Staking Pool
Any CC holder may stake CC to the Staking Pool
Third-party stakers earn a pro-rata share of the SV rewards corresponding to the unstaked portion
These rewards are distributed according to the same unlock mechanics as SV-locked rewards
5. Phased Implementation
To reduce operational risk and allow a smooth transition to fully automated SV staking, this proposal will be implemented in three phases.
Phase 1: Transitional Enforcement (Manual)
Timing
Goes into effect within 30 days of CIP approval
Requirements
SVs must move CC intended to count toward SV staking into a segregated, auditable PartyId
The PartyId information must be shared with the Foundation
Only CC held in the disclosed PartyId will be considered for SV staking calculations
Weight Calculation
SV reward weights will be adjusted manually:
Once at the 30-day threshold
Then once every 10 days thereafter
Under-Staked Weight Handling
A Foundation-controlled “ghost” Validator will be created
Any SV weight not backed by sufficient disclosed stake will be:
Removed from the SV
Assigned to the ghost Validator
Rewards associated with this weight will accrue to the ghost Validator pending Phase 3
Phase 2: On-Chain Locking (Automated SV Staking)
Activation
Begins once the CC locking mechanism is deployed to MainNet
Requirements
SVs must utilize the on-chain lock mechanism
Only actively locked CC will count toward SV weight
PartyId-based accounting is deprecated
Weight Calculation
SV weights will be adjusted automatically every block
Weight tiers are determined solely by actively locked CC
Unlocking Rules
SVs may initiate an unlock at any time
Unlocks take 365 days to become effective
Phase 3: Open Market Gap Filling (Third-Party Staking)
Activation
Begins after a staked CC distribution mechanism is deployed to MainNet
Mechanism
Any under-staked SV weight is made available to the market
Any CC holder may lock CC to claim a pro-rata share of the under-staked SV rewards
CC holders use the same locking mechanism introduced in Phase 2
Parity Requirement
Third-party staking must follow the exact same rules as SV staking
The Foundation’s ghost Validator:
Is subject to the same lifetime staking thresholds
Must maintain the required lock levels (historically and forward)
May only distribute rewards backed by valid locked CC
Examples
Example 1: Fully Staked SV
SV1 has earned 1B CC as an SV since genesis
SV1 is currently a W10 SV
To maintain W10 going forward, SV1 must lock 800M CC (80%)
SV1 continues earning 100% of W10 rewards, and must lock 80% of new rewards locked forward to maintain 100% earnings
Example 2: Partially Staked SV
SV2 has earned 1B CC as an SV since genesis
SV2 locks 400M CC (40%)
SV2 earns W4 going forward
SV2 must continue locking 40% of newly earned W4 rewards to maintain W4
The remaining W6 rewards are made available to third-party CC stakers
Exemptions
The following entities are exempt from the SV staking requirement:
The Foundation
Due to its mandate to support the ecosystem, issue grants, fund development, and manage public goods
The Ecosystem Fund SV operated by 5N
Due to its role in ecosystem support and capital deployment rather than reward accumulation
Any SV that can prove its coins are already locked for greater than 1 Year
Once those coins are unlocked, the exemption will lapse
Backwards Compatibility
This proposal does not modify:
Historical SV rewards
Previously earned distributions
Existing SV designations
All changes apply prospectively to forward SV reward calculations.
Future CIPs will propose implementation details for Phases 2 and 3.
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.
- 2025-01-27: Initial draft of the proposal
Eric and Community,
I support bonding for long-term alignment, especially for SVs with higher weights.
On the exemptions point, I want to sanity-check whether exempting the Foundation and Ecosystem Fund is actually what we want.
There is a separate proposal to require Featured Apps to bond 10M CC each. The Canton Foundation and Ecosystem Fund are explicitly mandated to invest in and support the ecosystem, so they seem uniquely well-positioned to support new FA applicants by bonding on their behalf.
Given that, are we sure we want to exempt them entirely? An alternative would be to require these entities to bond under the same rules as other SVs, which would:
• Keep the rules consistent across all SVs
• Create an explicit incentive for them to deploy bonded CC in support of others (e.g. FAs) rather than sitting idleI agree they won’t know on day one which FAs to back. But they could still bond their CC upfront and later assign portions of that already-bonded stake to new FA applicants as they come online.
Curious what people think about this tradeoff and whether exemption is actually the right default here.
Aki
- Hi Aki,
I agree that instead of having coins sitting idle, Fund/Foundation could bond for FA status for apps but
there is more to the function of these entities that dictates more flexibility.Specifically, both entities participate in funding rounds or give grants (Foundation) to companies that need capitalto build and pay the bills. When we participate in a funding round we will need to send CC to the companyor even sell to stables and participate.So although I truly like the idea of Fund/Foundation to bond instead of having idle cc,reality is that they need more flexibility and can't be bound to just bonding.
Y. We’re strongly opposed to any implementation of “staking” for SVs that penalizes recipients for the way they treat rewards, in particular retroactively. We understand and have been generally supportive of ongoing initiatives to change how incentives flow throughout the network, but the current proposal seems misguided and fundamentally flawed from our perspective.
While the stated intent of this proposal is to “align long term incentives between SVs and the network”, in practice it penalizes entities who sell CC earned from SV weights, which I’d argue is not the same. It is of course reasonable to say that an SV holding the majority of their CC earnings is demonstrating long term alignment, but the inverse is not necessarily true. It's unreasonable to assume that an SV who sells their rewards must not be a long-term aligned participant.
Figment is a textbook example of this. As an infrastructure operator, we are compensated predominantly in the native tokens of networks we support. Running institutional grade infrastructure is a labor and capital intensive process that requires fiat to fund. With that in mind, it’s our company policy to periodically sell the tokens we earn from operating blockchain networks. In doing so, we accept that we'll miss out on some upside as compared to holding all of the tokens we earn. However, this enables us to be highly resilient, and operate at scale through the extended periods of adverse market conditions that regularly affect our industry. We believe this is an exceedingly important capability for a provider of critical infrastructure, but it's incompatible with maintaining the level of exposure and risk this proposal requires of us to earn the rewards we were promised for providing our services to the network.
This principle doesn't only apply to validators. I think Modulo put it well in their response to the featured app proposal when they highlighted that builders on Canton are structurally extremely long the network. The same applies for the type of participants who have received Super Validator weights - we've all made meaningful capital investments into the network by supporting it and governance has agreed to compensate us for this work with a share of emissions from the SV rewards pool. Because these emissions are constant, it's always in the interest of an SV weight holder for Canton Coin price to be higher. In effect, this proposal punishes recipients of SV weights who chose to sell their rightfully-earned rewards under the assumption that selling is indicative of a lack of long term alignment.
Long term aligned participants can and in many cases do sell assets to trade some upside potential for a higher degree of certainty they'll be able to weather storms so that they can build for the long term. Many companies sell their own equity to raise money to help them grow and achieve their goals and it would be unreasonable to assume that said companies are not focused on a long term vision without further evidence.
If we collectively believe that Canton is a valuable network and that Canton Coin becomes more valuable as a function of network usage, then the free market should price Canton Coin appropriately eventually regardless of whether SV weight recipients are selling their rewards. This may take time, but as long term aligned participants we believe the network is most likely to reach its full potential if recipients of SV rewards are able to use them as they see fit and without penalties.
- Dear Tokenomics committee,We appreciate the thoughtful discussion around this CIP and want to contribute constructively to the Canton ecosystem's development. Overall, we're supportive of initiatives that strengthen the network's long-term sustainability and validator participation. We'd like to raise several important considerations regarding the current proposal:1. Source of yield
In the absence of a Proof-of-Stake mechanism, we'd like to better understand where the proposed yield for staked Canton Coins would originate. Clarity on the economic mechanics underpinning this yield is essential for evaluating the sustainability and risk profile of the proposal.2. Retroactive tokenomics changes, creating a precedent
Our primary concern centers on the retroactive nature of this proposal and the precedent it would set for the Canton ecosystem. The current tokenomics rules were established as the framework under which all participants operate. Some Super Validators may have made legitimate treasury management decisions, including selling Canton Coins to cover operational costs, fully within the bounds of these rules, particularly in an environment where yield-generating options were not available.Retroactively changing these rules creates significant uncertainty. It's analogous to a legal framework where activities that are legal today become illegal tomorrow, with penalties applied retrospectively. We believe rule-based tokenomics provide critical predictability for network participants. Establishing a precedent for retroactive changes, even with good intentions, undermines this predictability and may discourage long-term commitment to the ecosystem.3. Treatment of yield-generated Canton coins
We'd also welcome clarification on:- The anticipated liquidity characteristics of staked positions- Whether operations performed on yield-generated Canton Coins (e.g., selling, transferring) would trigger de-incentivization penalties
Overall, we strongly support Canton's growth and the goal of aligned, long-term Super Validator participation. We simply want to ensure that any changes preserve the predictability and rule-based foundation that makes tokenomics credible and sustainable. We'd welcome further discussion on how to achieve the proposal's objectives while avoiding retroactive rule changes.Great end of the week to all and speak soon.Best, - Hi Eric,Generally we are supportive of the proposal and its intent to align incentives to the network. I believe some tweaks are needed from some of the comments already raised. I do think it is important to think about how a firm like Tharimmune might be able to assist in solving some of the issues. I think Tharimmune is uniquely positioned with access to capital markets to help firms meet the requirements in the proposal along with ongoing needs they face today. I think this applies across SVs, validators and featured aps. Happy to discuss and assist in any way we can. See below example of our funding raise this week along with our mandate to help support/grow the ecosystem.
https://www.prnewswire.com/news-releases/tharimmune-inc-announces-closing-of-55-million-underwritten-registered-direct-offering-302668522.html - Hi,
It's a long discussion so I might be missing something along the lines, I'd appreciate pointing me to where the bellow is clarified if it's the case.
If implemented:
- How would this apply to SVs not hosting a node?- Would the holdings for staking have to be hosted on the SV itself or hosting on an external party (read "cold wallet") would also be acceptable? If it's the former some network participants may have security concerns and regulation implications.
Stas - Dar All,
We agree with Ambre’s comments regarding retroactive changes to tokenomics and governance precedent, and we support those concerns.
Building on that, we want to add context from the perspective of a founding Super Validator that actively operates a production node. Although the proposal is framed as forward-looking, anchoring future SV weight to lifetime earned rewards effectively revisits decisions made under a different tokenomics model. Early SVs used rewards to fund infrastructure, security, and operations at a time when there were no staking or lockup expectations. Using historical earnings as the baseline therefore impacts early operators differently.
It is also important to recognize the cost structure of operating an SV node. Infrastructure, security, monitoring, and operational costs scale with the size and complexity of the network, not with SV weight. As the Canton Network grows, the infrastructure we operate and fund grows with it. For low-weight operating SVs, rewards have already been compressed by additional SVs joining and by halving, while costs continue to increase. SV rewards are therefore not excess capital; they are used to subsidize expanding network infrastructure and security. Locking those rewards further limits the ability to meet these obligations.
More broadly, the proposal’s reliance on SV weight rather than committed capital has an important implication that should be made explicit. A weight-based bonding model reallocates rewards away from early Super Validators toward later participants or third-party stakers, even though early SVs assumed materially more risk when the network was less mature. In practice, this means that operators who supported and sustained the network early are penalized, while new participants are subsidized through redistributed rewards rather than through new value creation. Those dynamic risks sending a discouraging signal to long-term contributors.There is also a concern around the locking mechanism itself and custody of funds. The proposal implies moving CC into a staking or pooled mechanism, which raises questions about control and exit guarantees. From an operator perspective, retaining clear, unilateral control over our assets is critical. If coins are transferred into a shared contract or pool, there needs to be absolute clarity and enforceability around withdrawal rights. Without that, Super Validators are being asked to accept the risk that capital could be effectively locked indefinitely due to governance changes, implementation details, or contract behavior. That level of custody and exit risk is difficult to justify, particularly when combined with an indefinite lock model and a 365-day unlock delay.
There are also mechanical aspects of the proposal that deserve reconsideration. Using lifetime earned rewards as the staking baseline, relying on step-function weight tiers with no clear mechanism to earn weight back, and imposing an indefinite lock with a 365-day unlock are all unusually restrictive compared to other crypto-native systems. Taken together, these choices reduce liquidity and flexibility while primarily redistributing existing rewards rather than creating forward-looking alignment.
From an operator standpoint, long-term alignment has come from continued reinvestment into node security, redundancy, and tooling. Indefinite locks and long unlock delays create incentives to retain earned coins to preserve weight rather than deploying them back into operations, which works against network resilience.
Based on the above, we propose considering the following adjustments:-
Use a fixed balance snapshot, such as CC balances as of January 1, 2026, rather than lifetime earned rewards.
-
Replace step-function tiers with a continuous model or a clear mechanism to earn weight back as commitment increases.
-
Tie rewards directly to committed CC amounts rather than abstract SV weight, so rewards scale with forward-looking capital commitment rather than historical role.
-
Introduce bounded lock terms with materially shorter and predictable unlock periods.
-
Preserve a minimum operational weight of at least Weight 1 for Super Validators that actively operate nodes and remain in good standing, without requiring any bonding or staking to maintain that baseline weight.
-
Ensure any staking or locking mechanism preserves clear asset custody and unilateral withdrawal rights, with explicit guarantees that Super Validators cannot be indefinitely locked in due to governance or implementation changes.
We support the goal of long-term alignment and believe it can be achieved without effective retroactivity, excessive illiquidity, or mechanisms that unintentionally penalize early and operating Super Validators who helped build and sustain the network.
Dear Tokenomics committee,
We appreciate the thoughtful discussion around this CIP and want to contribute constructively to the Canton ecosystem's development. Overall, we're supportive of initiatives that strengthen the network's long-term sustainability and validator participation. We'd like to raise several important considerations regarding the current proposal:
1. Source of yield
In the absence of a Proof-of-Stake mechanism, we'd like to better understand where the proposed yield for staked Canton Coins would originate. Clarity on the economic mechanics underpinning this yield is essential for evaluating the sustainability and risk profile of the proposal.
2. Retroactive tokenomics changes, creating a precedent
Our primary concern centers on the retroactive nature of this proposal and the precedent it would set for the Canton ecosystem. The current tokenomics rules were established as the framework under which all participants operate. Some Super Validators may have made legitimate treasury management decisions, including selling Canton Coins to cover operational costs, fully within the bounds of these rules, particularly in an environment where yield-generating options were not available.
Retroactively changing these rules creates significant uncertainty. It's analogous to a legal framework where activities that are legal today become illegal tomorrow, with penalties applied retrospectively. We believe rule-based tokenomics provide critical predictability for network participants. Establishing a precedent for retroactive changes, even with good intentions, undermines this predictability and may discourage long-term commitment to the ecosystem.
3. Treatment of yield-generated Canton coins
We'd also welcome clarification on:- The anticipated liquidity characteristics of staked positions- Whether operations performed on yield-generated Canton Coins (e.g., selling, transferring) would trigger de-incentivization penalties
Overall, we strongly support Canton's growth and the goal of aligned, long-term Super Validator participation. We simply want to ensure that any changes preserve the predictability and rule-based foundation that makes tokenomics credible and sustainable. We'd welcome further discussion on how to achieve the proposal's objectives while avoiding retroactive rule changes.
Great end of the week to all and speak soon.
Best,Ambre
-
Hi All,
In coordination with Demo and the broader team, we have consolidated our feedback and identified several key areas for questions and refinement.
Background and Institutional Context
Blockdaemon generally supports the proposals aimed at ensuring the long-term stability and growth of the Canton network. However, we share the operational concerns recently raised by Luke (Figment) and Kinga (MPCH); specifically, that maintaining institutional-grade infrastructure is a labor and capital-intensive process requiring consistent fiat liquidity.Furthermore, our participation is governed by financial and operational standards not typically found within the DeFi ecosystem. These include the necessity for audited financial statements, rigorous internal controls, and strict compliance requirements that dictate how we manage and stake assets.
We must also consider the accounting implications, specifically regarding GAAP revenue recognition of tokens and the impact of any lock-up periods on our ability to recognize revenue.
Staking Tiers and Weighting Logic
-
Weight Integration: Regarding the new staking proposal, does this weighting supersede the milestone-unlock mechanism, or are they intended to stack?
-
Given the significant capital and labor already committed by recently onboarded SVs, we believe that applying a second lock-up on top of existing requirements would be redundant. We propose choosing only one locking mechanism to better reflect the substantial resources already deployed by those actively building.
-
Escrow Eligibility: If intended specifically to stack, is escrowed CC eligible to be staked to contribute toward a Super Validator's (SV) tier requirements?
Operational Costs and Liquidity Management
If the escrow program remains unchanged, minting-beneficiary-SVs face monthly infrastructure and maintenance overhead of approximately $10,000.
-
Liquidity Proposal: For new SVs subject to the 365-day lockup required for the higher tier, how does the Foundation propose ensuring sufficient liquidity to cover ongoing operational costs? Additionally, if validators are subject to both escrow and staking requirements, what mechanisms are in place to offset the resulting overhead?
-
We propose a mechanism that allows operators to withdraw a portion of their rewards to offset monthly operational expenses.
Incentive Structure and Yield
-
Staking Rationale: While this CIP is discussed in terms of APY, the model functions more as a participation lockup. The structure prioritizes liquidity stability; because rewards plateau after the initial tiers, this incentivizes time-based commitments rather than capital volume. Essentially, the lock is designed to maintain current status rather than provide incremental gains for higher stakes. It is also worth noting that lock-up volume is not always a direct proxy for network commitment.
-
We should ensure that the weighting earned through complex milestones remains tied to the entity that performed the work. If third-party stakers can "buy into" an SV’s status without having contributed to the network’s development, it risks diluting the value of the milestone-based system and prioritizing capital over proven commitment. This creates a disconnect where passive capital, rather than technical achievement and ecosystem value, captures the rewards generated by the SV labor.
Security, Compliance, and Custody
We are required to adhere to strict financial and security protocols governing our node and token operations. This includes certifying compliance with multiple third-party auditors by maintaining documented internal policies and procedures and providing evidence of adherence to those controls.
As a best practice, we do not hold tokens in excess of the minimum required stake on public validators.
-
Wallet Separation: Accordingly, can locked and liquid CC be held in separate, Blockdaemon-controlled wallets independent of our validator?
-
Secure Storage: We would be in favor of a supported path for using secure, institutional-grade solutions (e.g., Blockdaemon’s wallet infrastructure) to store these locked funds.
Status of Unlocking Funds
-
Attribution during Vesting: Are funds considered "staked" and counted toward the SV’s tier status throughout the duration of the 365-day unlock period?
We look forward to discussing these refinements further. Our objective is to ensure that the network's changes promote collective growth while maintaining the rigorous operational standards we have all worked to establish.
Thanks,
Jesse-
Eric,
Thank you for drafting these proposals and being open to feedback. While we agree with the intent of staking for SVs, we’d like to build upon the discussion around what should constitute fair use of reward revenue.
Beyond the points already covered, we’re concerned that locking the majority of current and future CC will unintentionally limit ecosystem support, particularly if Featured Apps require a minimum staked amount. While it would be difficult to police the past, certain CC usage that definitively promotes ecosystem growth should be exempt, such as FA sponsorships and DAT investments.
As an SV and an early contributor, we want to continue to be able to reinvest CC into the ecosystem without drawing down excess (non-staked) holdings that may be needed for operational costs.
With that in mind, we propose the following for consideration:
- Allow CC that SVs reinvest into the ecosystem to count toward their staking threshold
- In the near term, this would likely entail staking/sponsoring FAs, but new mechanisms could be proposed over time
- Future investment in the current or new DATs, for example
- Any exemptions should be easily verifiable on the network and avoid unnecessary qualitative judgement, otherwise we’d risk diverting from the motive of the proposal
To reiterate, we’re aligned with the approach that is being considered, but we believe this alteration allows SVs more flexibility while preserving the integrity of the model.
Best,
Billy Goodwin | Associate, Digital Assets
245 Park Avenue • New York, NY 10167
billy.goodwin@...- toggle quoted message Show quoted text
Liberty City Ventures' Position on the CIP
Liberty City Ventures opposes the CIP in its current form. Liberty City Ventures was one of the earliest supporters of the network and one of the earliest SVs. Our firm and our investors have invested significant time, effort, and capital in support of Canton. This proposal represents a dramatic alteration of the economic terms of that engagement and is detrimental to our investors who took risk at the earliest stages.The apparent but unstated goal of the CIP is to restrict the amount of Canton Coin available for sale. Token supply or float concerns should be addressed through other mechanisms.
Liberty City Ventures supports rationalizing market dynamics and remains a rational economic actor like other SVs.
Concerns About Reward Structure and Economics
Super Validator (SV) operators contributed capital and effort to launch and grow the Canton Network and were rewarded with Canton Coin. The CIP effectively defers the receipt of those rewards without recalibrating the underlying economics.
Without changes to reward weighting or timing, the CIP does not achieve its goals of:- Aligning long‑term incentives between SVs and the network.
- The proposal may have the opposite effect by causing SVs to cease operating on the network as they evaluate the risk of locking up 80% of the tokens to earn diminishing future rewards.
- The proposal introduces a prisoner’s dilemma that may result in suboptimal outcomes. For example, if a limited number of Super Validators choose not to lock-up their tokens, that group can dump large blocks damaging the market and harming SVs that chose to lock.
- Opening reward participation to the broader Canton Coin holder base.
- Locking tokens reduces the number available to support future transaction volume and to provide liquidity or financing on network
Objections Based on Burden to Existing SVs
The CIP imposes an undue burden on current SVs. Many of these objections have been previously raised.- U.S.-based SVs have federal income tax obligations as tokens are earned.
- The CIP limits the ability of SVs to recoup previous cash outlays for setup and operations.
- Liberty City Ventures’ investors were told they would receive unrestricted tokens and expected liquidity.
- The proposal materially alters both the economic structure and timing of potential investor distributions.
- SVs that have sold Canton Coin to fund operations and taxes may not have sufficient token balances to continue to earn maximum rewards.
Issues With Lock‑Up Period
- The one‑year lock‑up is too long and disadvantages the original SVs as more recently admitted SVs have not accumulated large balances.
- There is no expiration on the 80% bonding requirement.
- This is not a permanent problem, and the solution should not be permanent
- Any lock‑up or bonding requirement should:
- Expire after a defined period,
- Be phased out, or
- Decline gradually over time.
- A permanent requirement significantly delays returns for investors.
- A one‑year lock‑up also reduces flexibility to react to market conditions.
- Investors expect distributions and profits; the lock‑up eliminates the ability to capitalize on price spikes in Canton Coin.
Issues with the Lock‑Up Amount
- The lock-up amount exceeds the after-tax net Canton Coin earnings of a US SV.
- The US Federal Corporate tax rate is 21%
- State taxes might range from 5% to 9%
- After taxes with an 80% lock-up requirement, an operator of a U.S. based SV would need to contribute additional capital to maintain the threshold.
- A requirement to continually inject capital to maintain reward receipt will limit participation of new developers on the network.
- The lock-up amount limits the financial flexibility of Super Validators to participate in treasury and risk management vehicles that add liquidity to the market.
- Ultimately, a robust liquid market for Canton Coin supports the long-term price and ensures broad investor participation.
- The effective yield on locked tokens for early SVs will be significantly lower than for new Super Validators.
- Newer Super Validators of the same weight will earn significantly higher yields as the number of tokens required to be locked-up is significantly lower. This penalizes early supporters at the expense of new entrants.
- Canton has traditionally rewarded the first movers with the first validators and apps in a category receiving higher weightings than followers. This proposal runs contrary.
Impact on Participation
The lock up requirement is an additional expense which increases the cost of being a Super Validator and may limit participation from new validators which may ultimately harm the network.
Recommendations for Improving the Proposal
Liberty City Ventures would support a significantly lower lock‑up requirement applied only to future rewards. Our recommendations cover both the lock-up term and the quantity requirement.- The CIP should apply prospectively, not retroactively.
- This addresses the attempt to renegotiate the original terms and preserves the expectations of our investors,
- Lock‑up requirements should apply only to rewards earned after the effective date.
- This equalizes the requirements across validators of different weights and effectively makes the rewards coin weighted.
- Proposed thresholds are too high and should be lowered to account for potential U.S. SV tax liability, to cover funding of operating expenses, and to allow for the return capital to investors.
- Proposed thresholds are too high and should be lowered or should allow SVs to receive credit for participation in treasury management and liquidity providing activities.
- The bonding period should have an expiration date or a step down of the amount bonded. The token over supply problem is not permanent and dissipates as network transaction volume increases and the number of participants holding stocks of Canton Coin to fund transactions grows.
- This relieves SVs of the constraints as the network expands.
Recommendations for Addressing the Underlying Issue
Liberty City Ventures would welcome the opportunity to discuss alternatives. The most effective approach involves expanding network participation and usage.From: cip-discuss@... <cip-discuss@...> On Behalf Of Amanda Martin via lists.sync.global
Sent: Wednesday, January 21, 2026 11:42 AM
To: cip-discuss@...
Subject: [cip-discuss] CIP-TBD: Super Validator (SV) StakingPlease see below for open discussion.
Number: CIP-TBDTitle: Super Validator (SV) StakingAuthor(s): W Eric SaranieckiType: TokenomicsStatus: DraftCreated: 2026-01-21License: CC0-1.0SV Staking
Summary
This proposal introduces Super Validator (SV) Staking to the Canton Network. Under this mechanism, SVs must lock a defined percentage of their lifetime earned SV rewards in order to maintain SV weight going forward.
If an SV does not meet the required threshold, any Canton Coin (CC) holder may lock CC to fill the gap and earn a pro-rata share of the remaining SV rewards.
The objective is to:
- Align long-term incentives between SVs and the network
- Open SV reward participation to the broader CC holder base
Specification
1. SV Staking Requirement
To earn SV weight going forward, an SV must lock a percentage of its lifetime earned SV rewards into a staking contract with an indefinite lock.
Only actively locked CC is counted toward the SV weighting algorithm.
Stakers may unlock staked CC at any time; however, unlocks take 365 days to become effective.
2. Staking-to-Weight Schedule
SV weight going forward is determined by the percentage of required stake that is actively locked:
Min % of Lifetime Earnings Required to be Locked
Forward SV Reward Earned
80%
100%
60%
60%
40%
40%
20%
20%
< 20%
0%
This is a tiered model, not a continuous curve, to encourage clear commitment thresholds.
3. Forward Staking of Newly Earned Rewards
Once an SV is configured at a given Weight Tier, it must continue to lock the same percentage of newly earned SV rewards in order to maintain that tier going forward.
Failure to do so results in an automatic downgrade to the appropriate tier at the next calculation epoch.
4. Third-Party Staking (Gap Filling)
If an SV does not fully stake to the threshold required for its maximum historical weight:
- The unstaked Weight is transferred to an SV Staking Pool
- Any CC holder may stake CC to the Staking Pool
- Third-party stakers earn a pro-rata share of the SV rewards corresponding to the unstaked
- portion
- These rewards are distributed according to the same unlock mechanics as SV-locked rewards
5. Phased Implementation
To reduce operational risk and allow a smooth transition to fully automated SV staking, this proposal will be implemented in three phases.
Phase 1: Transitional Enforcement (Manual)
Timing
- Goes into effect within 30 days of CIP approval
Requirements
- SVs must move CC intended to count toward SV staking into a segregated, auditable PartyId
- The PartyId information must be shared with the Foundation
- Only CC held in the disclosed PartyId will be considered for SV staking calculations
Weight Calculation
- SV reward weights will be adjusted manually:
- Once at the 30-day threshold
- Then once every 10 days thereafter
Under-Staked Weight Handling
- A Foundation-controlled “ghost” Validator will be created
- Any SV weight not backed by sufficient disclosed stake will be:
- Removed from the SV
- Assigned to the ghost Validator
- Rewards associated with this weight will accrue to the ghost Validator pending Phase
- 3
Phase 2: On-Chain Locking (Automated SV Staking)
Activation
- Begins once the CC locking mechanism is deployed to MainNet
Requirements
- SVs must utilize the on-chain lock mechanism
- Only actively locked CC will count toward SV weight
- PartyId-based accounting is deprecated
Weight Calculation
- SV weights will be adjusted automatically every block
- Weight tiers are determined solely by actively locked CC
Unlocking Rules
- SVs may initiate an unlock at any time
- Unlocks take 365 days to become effective
Phase 3: Open Market Gap Filling (Third-Party Staking)
Activation
- Begins after a staked CC distribution mechanism is deployed to MainNet
Mechanism
- Any under-staked SV weight is made available to the market
- Any CC holder may lock CC to claim a pro-rata share of the under-staked SV rewards
- CC holders use the same locking mechanism introduced in Phase 2
Parity Requirement
- Third-party staking must follow the exact same rules as SV staking
- The Foundation’s ghost Validator:
- Is subject to the same lifetime staking thresholds
- Must maintain the required lock levels (historically and forward)
- May only distribute rewards backed by valid locked CC
Examples
Example 1: Fully Staked SV
- SV1 has earned
- 1B CC
- as an SV since genesis
- SV1 is currently a
- W10 SV
- To maintain W10 going forward, SV1 must lock
- 800M CC (80%)
- SV1 continues earning
- 100% of W10 rewards,
- and must lock 80% of new rewards locked forward
- to maintain 100% earnings
Example 2: Partially Staked SV
- SV2 has earned
- 1B CC
- as an SV since genesis
- SV2 locks
- 400M CC (40%)
- SV2 earns
- W4
- going forward
- SV2 must continue locking
- 40% of newly earned W4 rewards
- to maintain W4
- The remaining
- W6 rewards
- are made available to third-party CC stakers
Exemptions
The following entities are exempt from the SV staking requirement:
- The Foundation
- Due to its mandate to support the ecosystem, issue grants, fund development, and manage
- public goods
- The Ecosystem Fund SV operated by 5N
- Due to its role in ecosystem support and capital deployment rather than reward accumulation
- Any SV that can prove its coins are already locked for greater than 1 Year
- Once those coins are unlocked, the exemption will lapse
Backwards Compatibility
This proposal does not modify:
- Historical SV rewards
- Previously earned distributions
- Existing SV designations
All changes apply prospectively to forward SV reward calculations.
Future CIPs will propose implementation details for Phases 2 and 3.
Copyright
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.
Changelog
- 2025-01-27: Initial draft of the proposal
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 everyoneThank you very much for all the feedback on this SV Locking proposal.I am attaching a revised draft (and will ask Amanda to distribute in git as well).I want to reiterate that this proposal is not intended to be punitive or shame anyone who has sold CC. To my knowledge, every SV has sold some CC along the past 18 months.This proposal is about the opportunity to show the world how committed we are as a community. Will we rise to the occasion?I have taken a lot of the feedback received into account in this new draft and look forward to continuing to drive this process to a prompt conclusion. I've also reduced its scope to only be about handling the locking mechanism for existing SVs and leave the topic of what to do with any under-backed SV weight to be addressed in a future CIPOn Thu, Jan 29, 2026 at 12:51 PM James Lang via lists.sync.global <james=libertycityventures.com@...> wrote:
Liberty City Ventures' Position on the CIP
Liberty City Ventures opposes the CIP in its current form. Liberty City Ventures was one of the earliest supporters of the network and one of the earliest SVs. Our firm and our investors have invested significant time, effort, and capital in support of Canton. This proposal represents a dramatic alteration of the economic terms of that engagement and is detrimental to our investors who took risk at the earliest stages.The apparent but unstated goal of the CIP is to restrict the amount of Canton Coin available for sale. Token supply or float concerns should be addressed through other mechanisms.
Liberty City Ventures supports rationalizing market dynamics and remains a rational economic actor like other SVs.
Concerns About Reward Structure and Economics
Super Validator (SV) operators contributed capital and effort to launch and grow the Canton Network and were rewarded with Canton Coin. The CIP effectively defers the receipt of those rewards without recalibrating the underlying economics.
Without changes to reward weighting or timing, the CIP does not achieve its goals of:- Aligning long‑term incentives between SVs and the network.
- The proposal may have the opposite effect by causing SVs to cease operating on the network as they evaluate the risk of locking up 80% of the tokens to earn diminishing future rewards.
- The proposal introduces a prisoner’s dilemma that may result in suboptimal outcomes. For example, if a limited number of Super Validators choose not to lock-up their tokens, that group can dump large blocks damaging the market and harming SVs that chose to lock.
- Opening reward participation to the broader Canton Coin holder base.
- Locking tokens reduces the number available to support future transaction volume and to provide liquidity or financing on network
Objections Based on Burden to Existing SVs
The CIP imposes an undue burden on current SVs. Many of these objections have been previously raised.- U.S.-based SVs have federal income tax obligations as tokens are earned.
- The CIP limits the ability of SVs to recoup previous cash outlays for setup and operations.
- Liberty City Ventures’ investors were told they would receive unrestricted tokens and expected liquidity.
- The proposal materially alters both the economic structure and timing of potential investor distributions.
- SVs that have sold Canton Coin to fund operations and taxes may not have sufficient token balances to continue to earn maximum rewards.
Issues With Lock‑Up Period
- The one‑year lock‑up is too long and disadvantages the original SVs as more recently admitted SVs have not accumulated large balances.
- There is no expiration on the 80% bonding requirement.
- This is not a permanent problem, and the solution should not be permanent
- Any lock‑up or bonding requirement should:
- Expire after a defined period,
- Be phased out, or
- Decline gradually over time.
- A permanent requirement significantly delays returns for investors.
- A one‑year lock‑up also reduces flexibility to react to market conditions.
- Investors expect distributions and profits; the lock‑up eliminates the ability to capitalize on price spikes in Canton Coin.
Issues with the Lock‑Up Amount
- The lock-up amount exceeds the after-tax net Canton Coin earnings of a US SV.
- The US Federal Corporate tax rate is 21%
- State taxes might range from 5% to 9%
- After taxes with an 80% lock-up requirement, an operator of a U.S. based SV would need to contribute additional capital to maintain the threshold.
- A requirement to continually inject capital to maintain reward receipt will limit participation of new developers on the network.
- The lock-up amount limits the financial flexibility of Super Validators to participate in treasury and risk management vehicles that add liquidity to the market.
- Ultimately, a robust liquid market for Canton Coin supports the long-term price and ensures broad investor participation.
- The effective yield on locked tokens for early SVs will be significantly lower than for new Super Validators.
- Newer Super Validators of the same weight will earn significantly higher yields as the number of tokens required to be locked-up is significantly lower. This penalizes early supporters at the expense of new entrants.
- Canton has traditionally rewarded the first movers with the first validators and apps in a category receiving higher weightings than followers. This proposal runs contrary.
Impact on Participation
The lock up requirement is an additional expense which increases the cost of being a Super Validator and may limit participation from new validators which may ultimately harm the network.
Recommendations for Improving the Proposal
Liberty City Ventures would support a significantly lower lock‑up requirement applied only to future rewards. Our recommendations cover both the lock-up term and the quantity requirement.- The CIP should apply prospectively, not retroactively.
- This addresses the attempt to renegotiate the original terms and preserves the expectations of our investors,
- Lock‑up requirements should apply only to rewards earned after the effective date.
- This equalizes the requirements across validators of different weights and effectively makes the rewards coin weighted.
- Proposed thresholds are too high and should be lowered to account for potential U.S. SV tax liability, to cover funding of operating expenses, and to allow for the return capital to investors.
- Proposed thresholds are too high and should be lowered or should allow SVs to receive credit for participation in treasury management and liquidity providing activities.
- The bonding period should have an expiration date or a step down of the amount bonded. The token over supply problem is not permanent and dissipates as network transaction volume increases and the number of participants holding stocks of Canton Coin to fund transactions grows.
- This relieves SVs of the constraints as the network expands.
Recommendations for Addressing the Underlying Issue
Liberty City Ventures would welcome the opportunity to discuss alternatives. The most effective approach involves expanding network participation and usage.From: cip-discuss@... <cip-discuss@...> On Behalf Of Amanda Martin via lists.sync.global
Sent: Wednesday, January 21, 2026 11:42 AM
To: cip-discuss@...
Subject: [cip-discuss] CIP-TBD: Super Validator (SV) StakingPlease see below for open discussion.
Number: CIP-TBDTitle: Super Validator (SV) StakingAuthor(s): W Eric SaranieckiType: TokenomicsStatus: DraftCreated: 2026-01-21License: CC0-1.0SV Staking
Summary
This proposal introduces Super Validator (SV) Staking to the Canton Network. Under this mechanism, SVs must lock a defined percentage of their lifetime earned SV rewards in order to maintain SV weight going forward.
If an SV does not meet the required threshold, any Canton Coin (CC) holder may lock CC to fill the gap and earn a pro-rata share of the remaining SV rewards.
The objective is to:
- Align long-term incentives between SVs and the network
- Open SV reward participation to the broader CC holder base
Specification
1. SV Staking Requirement
To earn SV weight going forward, an SV must lock a percentage of its lifetime earned SV rewards into a staking contract with an indefinite lock.
Only actively locked CC is counted toward the SV weighting algorithm.
Stakers may unlock staked CC at any time; however, unlocks take 365 days to become effective.
2. Staking-to-Weight Schedule
SV weight going forward is determined by the percentage of required stake that is actively locked:
Min % of Lifetime Earnings Required to be Locked
Forward SV Reward Earned
80%
100%
60%
60%
40%
40%
20%
20%
< 20%
0%
This is a tiered model, not a continuous curve, to encourage clear commitment thresholds.
3. Forward Staking of Newly Earned Rewards
Once an SV is configured at a given Weight Tier, it must continue to lock the same percentage of newly earned SV rewards in order to maintain that tier going forward.
Failure to do so results in an automatic downgrade to the appropriate tier at the next calculation epoch.
4. Third-Party Staking (Gap Filling)
If an SV does not fully stake to the threshold required for its maximum historical weight:
- The unstaked Weight is transferred to an SV Staking Pool
- Any CC holder may stake CC to the Staking Pool
- Third-party stakers earn a pro-rata share of the SV rewards corresponding to the unstaked
- portion
- These rewards are distributed according to the same unlock mechanics as SV-locked rewards
5. Phased Implementation
To reduce operational risk and allow a smooth transition to fully automated SV staking, this proposal will be implemented in three phases.
Phase 1: Transitional Enforcement (Manual)
Timing
- Goes into effect within 30 days of CIP approval
Requirements
- SVs must move CC intended to count toward SV staking into a segregated, auditable PartyId
- The PartyId information must be shared with the Foundation
- Only CC held in the disclosed PartyId will be considered for SV staking calculations
Weight Calculation
- SV reward weights will be adjusted manually:
- Once at the 30-day threshold
- Then once every 10 days thereafter
Under-Staked Weight Handling
- A Foundation-controlled “ghost” Validator will be created
- Any SV weight not backed by sufficient disclosed stake will be:
- Removed from the SV
- Assigned to the ghost Validator
- Rewards associated with this weight will accrue to the ghost Validator pending Phase
- 3
Phase 2: On-Chain Locking (Automated SV Staking)
Activation
- Begins once the CC locking mechanism is deployed to MainNet
Requirements
- SVs must utilize the on-chain lock mechanism
- Only actively locked CC will count toward SV weight
- PartyId-based accounting is deprecated
Weight Calculation
- SV weights will be adjusted automatically every block
- Weight tiers are determined solely by actively locked CC
Unlocking Rules
- SVs may initiate an unlock at any time
- Unlocks take 365 days to become effective
Phase 3: Open Market Gap Filling (Third-Party Staking)
Activation
- Begins after a staked CC distribution mechanism is deployed to MainNet
Mechanism
- Any under-staked SV weight is made available to the market
- Any CC holder may lock CC to claim a pro-rata share of the under-staked SV rewards
- CC holders use the same locking mechanism introduced in Phase 2
Parity Requirement
- Third-party staking must follow the exact same rules as SV staking
- The Foundation’s ghost Validator:
- Is subject to the same lifetime staking thresholds
- Must maintain the required lock levels (historically and forward)
- May only distribute rewards backed by valid locked CC
Examples
Example 1: Fully Staked SV
- SV1 has earned
- 1B CC
- as an SV since genesis
- SV1 is currently a
- W10 SV
- To maintain W10 going forward, SV1 must lock
- 800M CC (80%)
- SV1 continues earning
- 100% of W10 rewards,
- and must lock 80% of new rewards locked forward
- to maintain 100% earnings
Example 2: Partially Staked SV
- SV2 has earned
- 1B CC
- as an SV since genesis
- SV2 locks
- 400M CC (40%)
- SV2 earns
- W4
- going forward
- SV2 must continue locking
- 40% of newly earned W4 rewards
- to maintain W4
- The remaining
- W6 rewards
- are made available to third-party CC stakers
Exemptions
The following entities are exempt from the SV staking requirement:
- The Foundation
- Due to its mandate to support the ecosystem, issue grants, fund development, and manage
- public goods
- The Ecosystem Fund SV operated by 5N
- Due to its role in ecosystem support and capital deployment rather than reward accumulation
- Any SV that can prove its coins are already locked for greater than 1 Year
- Once those coins are unlocked, the exemption will lapse
Backwards Compatibility
This proposal does not modify:
- Historical SV rewards
- Previously earned distributions
- Existing SV designations
All changes apply prospectively to forward SV reward calculations.
Future CIPs will propose implementation details for Phases 2 and 3.
Copyright
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.
Changelog
- 2025-01-27: Initial draft of the proposal
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.
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. Super Validator Locking CIP v0.2
Number: CIP-TBD
Title:Super Validator (SV) Staking & Long-Term Commitment Framework
Author(s): Eric Saraniecki w/Community Proposal
Type: Tokenomics
Status: Draft
Created: 2026-01-30
License: CC0-1.0
1. Abstract
This proposal introduces a long-term locking and commitment framework for Super Validators (SVs) on the Canton Network.
SVs will be asked to lock a portion of their historical and future earned SV rewards in order to maintain SV Weight going forward. This lock creates a visible, on-chain commitment to the network and directly ties SV influence to long-term alignment.
If an SV does not meet the required lock threshold, the under-backed portion of its SV Weight is removed and assigned to a Foundation-controlled ghost validator. A future Canton Improvement Proposal will define how under-locked SV weight is ultimately handled.
This framework is designed to:
-
Align SV incentives with the long-term success of the network
-
Replace reputational promises with cryptographic proof of alignment
2. Specification
This proposal defines a locking requirement for Super Validators whereby a specified percentage of lifetime earned Super Validator rewards must be locked in a Canton locking contract to earn Super Validator Weight. Only actively locked Canton Coin counts toward the weighting algorithm.
Locked rewards follow a vesting-based unlock model. Validators may initiate an unlock at any time, after which 1/365.25 of the locked balance vests daily. Only the unvested portion continues to count toward Super Validator Weight.
Implementation proceeds in two phases: an initial manual enforcement period followed by fully on-chain enforcement once locking contracts are deployed to MainNet.
3. Motivation
The Canton community already knows that Super Validators are deeply committed to the network. Many have invested years of engineering effort, commercial relationships, and institutional credibility to make Canton successful.
However, as Canton becomes increasingly public-facing, the external market does not know how deeply committed this tight-knit community is.
Public blockchains are evaluated not just on technology, but on:
-
Who controls them
-
How long insiders are economically bound
-
Whether operators can exit suddenly
-
Whether incentives favor short-term extraction or long-term growth
Today, Canton relies primarily on reputation and narrative to communicate alignment. This is an opportunity to make that commitment even stronger and publicly verifiable.
This proposal replaces ‘trust us’ with verifiable proof.
By asking SVs to lock a meaningful portion of their earned rewards over multi-year horizons, Canton creates:
-
Publicly observable skin-in-the-game
-
A strong deterrent to short-termism
-
A credible signal to investors, builders, asset issuers, and institutions that the network’s stewards are in it for the long haul
This is not punitive. It is reputation-reinforcing for a network that is replacing global financial infrastructure.
4. SV Locking Requirement
To earn SV Weight going forward, an SV must lock a defined percentage of its lifetime earned SV rewards into a Canton locking contract.
Only actively locked CC counts toward the SV weighting algorithm.
Locked CC follows a vesting-based unlock:
-
An SV may initiate an unlock at any time
-
Once initiated, 1 / 365.25 of the locked amount vests and becomes liquid each day
-
The remaining unvested portion continues to count as locked
-
Only the still-locked portion counts toward SV weight
This creates a rolling, continuously bonded commitment rather than a single cliff.
5. SV Locking and SV Weight Schedule
This section defines the schedule governing Super Validator locking and SV weight from activation until the next Canton halving.
SVs earn SV weight based on the percentage of their lifetime earned SV rewards that are actively locked. The maximum required lock declines over time, and SV weight is awarded according to fixed commitment tiers defined as absolute offsets from that maximum.
Only actively locked CC counts toward SV weight.
Year from Activation
Max Lock % of Lifetime SV Earnings
Tier 1 (100% SV Weight)
Tier 2 (60% SV Weight)
Tier 3 (40% SV Weight)
Tier 4 (20% SV Weight)
Below Bottom Tier
Turbo-Eligible Tier
Start
70%
70%
50%
30%
10%
0%
50%
+1 Year
65%
65%
45%
25%
5%
0%
45%
+2 Years
60%
60%
40%
20%
—
0%
40%
+3 Years
55%
55%
35%
15%
—
0%
35%
Tier thresholds are defined as absolute offsets from the Max Lock for that year: Max, Max minus 20, Max minus 40, and Max minus 60.
If Max minus 60 is less than or equal to zero, Tier 4 is removed and any SV below Tier 3 earns zero SV weight.
An SV at or above the Turbo-Eligible Tier may elect to lock 100 percent of all newly earned SV rewards. While in this mode, the SV earns 100 percent of SV weight regardless of historical lock tier. This continues until the SV accumulates enough locked CC to satisfy the current Max Lock requirement, at which point it may revert to the standard forward-lock requirement for that tier.
The schedule defined above applies until the next Canton halving, at which point a new CIP will define the commitment regime going forward.
6. Under-Locked SV Weight
If an SV does not lock sufficient CC to support its historical or current tier:
-
The unsupported portion of its SV weight is removed
-
That weight is assigned to a Foundation-controlled ghost validator
A future Canton Improvement Proposal will define how under-locked SV weight is ultimately handled.
7. Phased Implementation
Phase 1 — Transitional Enforcement (Manual)
-
Begins within 30 days of CIP approval
-
SVs disclose a segregated PartyId holding their locked CC
-
SV weights adjusted manually every 10 days
-
Under-locked weight assigned to the ghost validator
Phase 2 — On-Chain Locking
-
Activates when CC locking is deployed to MainNet
-
Only on-chain locked CC counts
-
Vesting-based unlocks apply
-
Weights update automatically
8. Exemptions
The following entities are exempt:
-
The Foundation
-
The 5N-operated Ecosystem Fund SV
-
Any SV with CC already provably locked
-
- toggle quoted message Show quoted text
Thank you Eric. One question.
For anyone who contributed CC in kind to the DAT, would you see these count as locked in as long as one hold the shares in THAR?
Veronica
V E R O N I C A A U G U S T S S O N / P A R T N E R
7RIDGE IS A PRIVATE MARKETS ASSET MANAGER INVESTED IN TRANSFORMATIVE TECHNOLOGY FOR FINANCIAL SERVICES TO POWER THE GLOBAL ECONOMY Signature for V e r o n i c a A u g u s t s s o n From: cip-discuss@... <cip-discuss@...> On Behalf Of Eric Saraniecki via lists.sync.global
Sent: Friday, 30 January 2026 23:49
To: cip-discuss@...
Subject: Re: [cip-discuss] CIP-TBD: Super Validator (SV) Staking - Eric SaranieckiHi everyone
Thank you very much for all the feedback on this SV Locking proposal.
I am attaching a revised draft (and will ask Amanda to distribute in git as well).
I want to reiterate that this proposal is not intended to be punitive or shame anyone who has sold CC. To my knowledge, every SV has sold some CC along the past 18 months.
This proposal is about the opportunity to show the world how committed we are as a community. Will we rise to the occasion?
I have taken a lot of the feedback received into account in this new draft and look forward to continuing to drive this process to a prompt conclusion. I've also reduced its scope to only be about handling the locking mechanism for existing SVs and leave the topic of what to do with any under-backed SV weight to be addressed in a future CIP
On Thu, Jan 29, 2026 at 12:51 PM James Lang via lists.sync.global <james=libertycityventures.com@...> wrote:
Liberty City Ventures' Position on the CIP
Liberty City Ventures opposes the CIP in its current form. Liberty City Ventures was one of the earliest supporters of the network and one of the earliest SVs. Our firm and our investors have invested significant time, effort, and capital in support of Canton. This proposal represents a dramatic alteration of the economic terms of that engagement and is detrimental to our investors who took risk at the earliest stages.The apparent but unstated goal of the CIP is to restrict the amount of Canton Coin available for sale. Token supply or float concerns should be addressed through other mechanisms.
Liberty City Ventures supports rationalizing market dynamics and remains a rational economic actor like other SVs.
Concerns About Reward Structure and Economics
Super Validator (SV) operators contributed capital and effort to launch and grow the Canton Network and were rewarded with Canton Coin. The CIP effectively defers the receipt of those rewards without recalibrating the underlying economics.
Without changes to reward weighting or timing, the CIP does not achieve its goals of:- Aligning long‑term incentives between SVs and the network.
- The proposal may have the opposite effect by causing SVs to cease operating on the network as they evaluate the risk of locking up 80% of the tokens to earn diminishing future rewards.
- The proposal introduces a prisoner’s dilemma that may result in suboptimal outcomes. For example, if a limited number of Super Validators choose not to lock-up their tokens, that group can dump large blocks damaging the market and harming SVs that chose to lock.
- Opening reward participation to the broader Canton Coin holder base.
- Locking tokens reduces the number available to support future transaction volume and to provide liquidity or financing on network
Objections Based on Burden to Existing SVs
The CIP imposes an undue burden on current SVs. Many of these objections have been previously raised.- U.S.-based SVs have federal income tax obligations as tokens are earned.
- The CIP limits the ability of SVs to recoup previous cash outlays for setup and operations.
- Liberty City Ventures’ investors were told they would receive unrestricted tokens and expected liquidity.
- The proposal materially alters both the economic structure and timing of potential investor distributions.
- SVs that have sold Canton Coin to fund operations and taxes may not have sufficient token balances to continue to earn maximum rewards.
Issues With Lock‑Up Period
- The one‑year lock‑up is too long and disadvantages the original SVs as more recently admitted SVs have not accumulated large balances.
- There is no expiration on the 80% bonding requirement.
- This is not a permanent problem, and the solution should not be permanent
- Any lock‑up or bonding requirement should:
- Expire after a defined period,
- Be phased out, or
- Decline gradually over time.
- A permanent requirement significantly delays returns for investors.
- A one‑year lock‑up also reduces flexibility to react to market conditions.
- Investors expect distributions and profits; the lock‑up eliminates the ability to capitalize on price spikes in Canton Coin.
Issues with the Lock‑Up Amount
- The lock-up amount exceeds the after-tax net Canton Coin earnings of a US SV.
- The US Federal Corporate tax rate is 21%
- State taxes might range from 5% to 9%
- After taxes with an 80% lock-up requirement, an operator of a U.S. based SV would need to contribute additional capital to maintain the threshold.
- A requirement to continually inject capital to maintain reward receipt will limit participation of new developers on the network.
- The lock-up amount limits the financial flexibility of Super Validators to participate in treasury and risk management vehicles that add liquidity to the market.
- Ultimately, a robust liquid market for Canton Coin supports the long-term price and ensures broad investor participation.
- The effective yield on locked tokens for early SVs will be significantly lower than for new Super Validators.
- Newer Super Validators of the same weight will earn significantly higher yields as the number of tokens required to be locked-up is significantly lower. This penalizes early supporters at the expense of new entrants.
- Canton has traditionally rewarded the first movers with the first validators and apps in a category receiving higher weightings than followers. This proposal runs contrary.
Impact on Participation
The lock up requirement is an additional expense which increases the cost of being a Super Validator and may limit participation from new validators which may ultimately harm the network.Recommendations for Improving the Proposal
Liberty City Ventures would support a significantly lower lock‑up requirement applied only to future rewards. Our recommendations cover both the lock-up term and the quantity requirement.- The CIP should apply prospectively, not retroactively.
- This addresses the attempt to renegotiate the original terms and preserves the expectations of our investors,
- Lock‑up requirements should apply only to rewards earned after the effective date.
- This equalizes the requirements across validators of different weights and effectively makes the rewards coin weighted.
- Proposed thresholds are too high and should be lowered to account for potential U.S. SV tax liability, to cover funding of operating expenses, and to allow for the return capital to investors.
- Proposed thresholds are too high and should be lowered or should allow SVs to receive credit for participation in treasury management and liquidity providing activities.
- The bonding period should have an expiration date or a step down of the amount bonded. The token over supply problem is not permanent and dissipates as network transaction volume increases and the number of participants holding stocks of Canton Coin to fund transactions grows.
- This relieves SVs of the constraints as the network expands.
Recommendations for Addressing the Underlying Issue
Liberty City Ventures would welcome the opportunity to discuss alternatives. The most effective approach involves expanding network participation and usage.From: cip-discuss@... <cip-discuss@...> On Behalf Of Amanda Martin via lists.sync.global
Sent: Wednesday, January 21, 2026 11:42 AM
To: cip-discuss@...
Subject: [cip-discuss] CIP-TBD: Super Validator (SV) StakingPlease see below for open discussion.
Number: CIP-TBDTitle: Super Validator (SV) StakingAuthor(s): W Eric SaranieckiType: TokenomicsStatus: DraftCreated: 2026-01-21License: CC0-1.0SV Staking
Summary
This proposal introduces Super Validator (SV) Staking to the Canton Network. Under this mechanism, SVs must lock a defined percentage of their lifetime earned SV rewards in order to maintain SV weight going forward.
If an SV does not meet the required threshold, any Canton Coin (CC) holder may lock CC to fill the gap and earn a pro-rata share of the remaining SV rewards.
The objective is to:
- Align long-term incentives between SVs and the network
- Open SV reward participation to the broader CC holder base
Specification
1. SV Staking Requirement
To earn SV weight going forward, an SV must lock a percentage of its lifetime earned SV rewards into a staking contract with an indefinite lock.
Only actively locked CC is counted toward the SV weighting algorithm.
Stakers may unlock staked CC at any time; however, unlocks take 365 days to become effective.
2. Staking-to-Weight Schedule
SV weight going forward is determined by the percentage of required stake that is actively locked:
Min % of Lifetime Earnings Required to be Locked
Forward SV Reward Earned
80%
100%
60%
60%
40%
40%
20%
20%
< 20%
0%
This is a tiered model, not a continuous curve, to encourage clear commitment thresholds.
3. Forward Staking of Newly Earned Rewards
Once an SV is configured at a given Weight Tier, it must continue to lock the same percentage of newly earned SV rewards in order to maintain that tier going forward.
Failure to do so results in an automatic downgrade to the appropriate tier at the next calculation epoch.
4. Third-Party Staking (Gap Filling)
If an SV does not fully stake to the threshold required for its maximum historical weight:
- The unstaked Weight is transferred to an SV Staking Pool
- Any CC holder may stake CC to the Staking Pool
- Third-party stakers earn a pro-rata share of the SV rewards corresponding to the unstaked
- portion
- These rewards are distributed according to the same unlock mechanics as SV-locked rewards
5. Phased Implementation
To reduce operational risk and allow a smooth transition to fully automated SV staking, this proposal will be implemented in three phases.
Phase 1: Transitional Enforcement (Manual)
Timing
- Goes into effect within 30 days of CIP approval
Requirements
- SVs must move CC intended to count toward SV staking into a segregated, auditable PartyId
- The PartyId information must be shared with the Foundation
- Only CC held in the disclosed PartyId will be considered for SV staking calculations
Weight Calculation
- SV reward weights will be adjusted manually:
- Once at the 30-day threshold
- Then once every 10 days thereafter
Under-Staked Weight Handling
- A Foundation-controlled “ghost” Validator will be created
- Any SV weight not backed by sufficient disclosed stake will be:
- Removed from the SV
- Assigned to the ghost Validator
- Rewards associated with this weight will accrue to the ghost Validator pending Phase
- 3
Phase 2: On-Chain Locking (Automated SV Staking)
Activation
- Begins once the CC locking mechanism is deployed to MainNet
Requirements
- SVs must utilize the on-chain lock mechanism
- Only actively locked CC will count toward SV weight
- PartyId-based accounting is deprecated
Weight Calculation
- SV weights will be adjusted automatically every block
- Weight tiers are determined solely by actively locked CC
Unlocking Rules
- SVs may initiate an unlock at any time
- Unlocks take 365 days to become effective
Phase 3: Open Market Gap Filling (Third-Party Staking)
Activation
- Begins after a staked CC distribution mechanism is deployed to MainNet
Mechanism
- Any under-staked SV weight is made available to the market
- Any CC holder may lock CC to claim a pro-rata share of the under-staked SV rewards
- CC holders use the same locking mechanism introduced in Phase 2
Parity Requirement
- Third-party staking must follow the exact same rules as SV staking
- The Foundation’s ghost Validator:
- Is subject to the same lifetime staking thresholds
- Must maintain the required lock levels (historically and forward)
- May only distribute rewards backed by valid locked CC
Examples
Example 1: Fully Staked SV
- SV1 has earned
- 1B CC
- as an SV since genesis
- SV1 is currently a
- W10 SV
- To maintain W10 going forward, SV1 must lock
- 800M CC (80%)
- SV1 continues earning
- 100% of W10 rewards,
- and must lock 80% of new rewards locked forward
- to maintain 100% earnings
Example 2: Partially Staked SV
- SV2 has earned
- 1B CC
- as an SV since genesis
- SV2 locks
- 400M CC (40%)
- SV2 earns
- W4
- going forward
- SV2 must continue locking
- 40% of newly earned W4 rewards
- to maintain W4
- The remaining
- W6 rewards
- are made available to third-party CC stakers
Exemptions
The following entities are exempt from the SV staking requirement:
- The Foundation
- Due to its mandate to support the ecosystem, issue grants, fund development, and manage
- public goods
- The Ecosystem Fund SV operated by 5N
- Due to its role in ecosystem support and capital deployment rather than reward accumulation
- Any SV that can prove its coins are already locked for greater than 1 Year
- Once those coins are unlocked, the exemption will lapse
Backwards Compatibility
This proposal does not modify:
- Historical SV rewards
- Previously earned distributions
- Existing SV designations
All changes apply prospectively to forward SV reward calculations.
Future CIPs will propose implementation details for Phases 2 and 3.
Copyright
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.
Changelog
- 2025-01-27: Initial draft of the proposal
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.
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. - toggle quoted message Show quoted textVery open to discuss it but I don't consider that as being locked in this proposalOn Feb 1, 2026, at 2:22 PM, Veronica Augustsson via lists.sync.global <veronica=7ridge.com@...> wrote:
Thank you Eric. One question.
For anyone who contributed CC in kind to the DAT, would you see these count as locked in as long as one hold the shares in THAR?
Veronica
V E R O N I C A A U G U S T S S O N / P A R T N E R
<image788166.png>7RIDGE IS A PRIVATE MARKETS ASSET MANAGER INVESTED IN TRANSFORMATIVE TECHNOLOGY FOR FINANCIAL SERVICES TO POWER THE GLOBAL ECONOMY Signature for V e r o n i c a A u g u s t s s o n From: cip-discuss@... <cip-discuss@...> On Behalf Of Eric Saraniecki via lists.sync.global
Sent: Friday, 30 January 2026 23:49
To: cip-discuss@...
Subject: Re: [cip-discuss] CIP-TBD: Super Validator (SV) Staking - Eric SaranieckiHi everyone
Thank you very much for all the feedback on this SV Locking proposal.
I am attaching a revised draft (and will ask Amanda to distribute in git as well).
I want to reiterate that this proposal is not intended to be punitive or shame anyone who has sold CC. To my knowledge, every SV has sold some CC along the past 18 months.
This proposal is about the opportunity to show the world how committed we are as a community. Will we rise to the occasion?
I have taken a lot of the feedback received into account in this new draft and look forward to continuing to drive this process to a prompt conclusion. I've also reduced its scope to only be about handling the locking mechanism for existing SVs and leave the topic of what to do with any under-backed SV weight to be addressed in a future CIP
On Thu, Jan 29, 2026 at 12:51 PM James Lang via lists.sync.global <james=libertycityventures.com@...> wrote:
Liberty City Ventures' Position on the CIP
Liberty City Ventures opposes the CIP in its current form. Liberty City Ventures was one of the earliest supporters of the network and one of the earliest SVs. Our firm and our investors have invested significant time, effort, and capital in support of Canton. This proposal represents a dramatic alteration of the economic terms of that engagement and is detrimental to our investors who took risk at the earliest stages.The apparent but unstated goal of the CIP is to restrict the amount of Canton Coin available for sale. Token supply or float concerns should be addressed through other mechanisms.
Liberty City Ventures supports rationalizing market dynamics and remains a rational economic actor like other SVs.
Concerns About Reward Structure and Economics
Super Validator (SV) operators contributed capital and effort to launch and grow the Canton Network and were rewarded with Canton Coin. The CIP effectively defers the receipt of those rewards without recalibrating the underlying economics.
Without changes to reward weighting or timing, the CIP does not achieve its goals of:- Aligning long‑term incentives between SVs and the network.
- The proposal may have the opposite effect by causing SVs to cease operating on the network as they evaluate the risk of locking up 80% of the tokens to earn diminishing future rewards.
- The proposal introduces a prisoner’s dilemma that may result in suboptimal outcomes. For example, if a limited number of Super Validators choose not to lock-up their tokens, that group can dump large blocks damaging the market and harming SVs that chose to lock.
- Opening reward participation to the broader Canton Coin holder base.
- Locking tokens reduces the number available to support future transaction volume and to provide liquidity or financing on network
Objections Based on Burden to Existing SVs
The CIP imposes an undue burden on current SVs. Many of these objections have been previously raised.- U.S.-based SVs have federal income tax obligations as tokens are earned.
- The CIP limits the ability of SVs to recoup previous cash outlays for setup and operations.
- Liberty City Ventures’ investors were told they would receive unrestricted tokens and expected liquidity.
- The proposal materially alters both the economic structure and timing of potential investor distributions.
- SVs that have sold Canton Coin to fund operations and taxes may not have sufficient token balances to continue to earn maximum rewards.
Issues With Lock‑Up Period
- The one‑year lock‑up is too long and disadvantages the original SVs as more recently admitted SVs have not accumulated large balances.
- There is no expiration on the 80% bonding requirement.
- This is not a permanent problem, and the solution should not be permanent
- Any lock‑up or bonding requirement should:
- Expire after a defined period,
- Be phased out, or
- Decline gradually over time.
- A permanent requirement significantly delays returns for investors.
- A one‑year lock‑up also reduces flexibility to react to market conditions.
- Investors expect distributions and profits; the lock‑up eliminates the ability to capitalize on price spikes in Canton Coin.
Issues with the Lock‑Up Amount
- The lock-up amount exceeds the after-tax net Canton Coin earnings of a US SV.
- The US Federal Corporate tax rate is 21%
- State taxes might range from 5% to 9%
- After taxes with an 80% lock-up requirement, an operator of a U.S. based SV would need to contribute additional capital to maintain the threshold.
- A requirement to continually inject capital to maintain reward receipt will limit participation of new developers on the network.
- The lock-up amount limits the financial flexibility of Super Validators to participate in treasury and risk management vehicles that add liquidity to the market.
- Ultimately, a robust liquid market for Canton Coin supports the long-term price and ensures broad investor participation.
- The effective yield on locked tokens for early SVs will be significantly lower than for new Super Validators.
- Newer Super Validators of the same weight will earn significantly higher yields as the number of tokens required to be locked-up is significantly lower. This penalizes early supporters at the expense of new entrants.
- Canton has traditionally rewarded the first movers with the first validators and apps in a category receiving higher weightings than followers. This proposal runs contrary.
Impact on Participation
The lock up requirement is an additional expense which increases the cost of being a Super Validator and may limit participation from new validators which may ultimately harm the network.Recommendations for Improving the Proposal
Liberty City Ventures would support a significantly lower lock‑up requirement applied only to future rewards. Our recommendations cover both the lock-up term and the quantity requirement.- The CIP should apply prospectively, not retroactively.
- This addresses the attempt to renegotiate the original terms and preserves the expectations of our investors,
- Lock‑up requirements should apply only to rewards earned after the effective date.
- This equalizes the requirements across validators of different weights and effectively makes the rewards coin weighted.
- Proposed thresholds are too high and should be lowered to account for potential U.S. SV tax liability, to cover funding of operating expenses, and to allow for the return capital to investors.
- Proposed thresholds are too high and should be lowered or should allow SVs to receive credit for participation in treasury management and liquidity providing activities.
- The bonding period should have an expiration date or a step down of the amount bonded. The token over supply problem is not permanent and dissipates as network transaction volume increases and the number of participants holding stocks of Canton Coin to fund transactions grows.
- This relieves SVs of the constraints as the network expands.
Recommendations for Addressing the Underlying Issue
Liberty City Ventures would welcome the opportunity to discuss alternatives. The most effective approach involves expanding network participation and usage.From: cip-discuss@... <cip-discuss@...> On Behalf Of Amanda Martin via lists.sync.global
Sent: Wednesday, January 21, 2026 11:42 AM
To: cip-discuss@...
Subject: [cip-discuss] CIP-TBD: Super Validator (SV) StakingPlease see below for open discussion.
Number: CIP-TBDTitle: Super Validator (SV) StakingAuthor(s): W Eric SaranieckiType: TokenomicsStatus: DraftCreated: 2026-01-21License: CC0-1.0SV Staking
Summary
This proposal introduces Super Validator (SV) Staking to the Canton Network. Under this mechanism, SVs must lock a defined percentage of their lifetime earned SV rewards in order to maintain SV weight going forward.
If an SV does not meet the required threshold, any Canton Coin (CC) holder may lock CC to fill the gap and earn a pro-rata share of the remaining SV rewards.
The objective is to:
- Align long-term incentives between SVs and the network
- Open SV reward participation to the broader CC holder base
Specification
1. SV Staking Requirement
To earn SV weight going forward, an SV must lock a percentage of its lifetime earned SV rewards into a staking contract with an indefinite lock.
Only actively locked CC is counted toward the SV weighting algorithm.
Stakers may unlock staked CC at any time; however, unlocks take 365 days to become effective.
2. Staking-to-Weight Schedule
SV weight going forward is determined by the percentage of required stake that is actively locked:
Min % of Lifetime Earnings Required to be Locked
Forward SV Reward Earned
80%
100%
60%
60%
40%
40%
20%
20%
< 20%
0%
This is a tiered model, not a continuous curve, to encourage clear commitment thresholds.
3. Forward Staking of Newly Earned Rewards
Once an SV is configured at a given Weight Tier, it must continue to lock the same percentage of newly earned SV rewards in order to maintain that tier going forward.
Failure to do so results in an automatic downgrade to the appropriate tier at the next calculation epoch.
4. Third-Party Staking (Gap Filling)
If an SV does not fully stake to the threshold required for its maximum historical weight:
- The unstaked Weight is transferred to an SV Staking Pool
- Any CC holder may stake CC to the Staking Pool
- Third-party stakers earn a pro-rata share of the SV rewards corresponding to the unstaked
- portion
- These rewards are distributed according to the same unlock mechanics as SV-locked rewards
5. Phased Implementation
To reduce operational risk and allow a smooth transition to fully automated SV staking, this proposal will be implemented in three phases.
Phase 1: Transitional Enforcement (Manual)
Timing
- Goes into effect within 30 days of CIP approval
Requirements
- SVs must move CC intended to count toward SV staking into a segregated, auditable PartyId
- The PartyId information must be shared with the Foundation
- Only CC held in the disclosed PartyId will be considered for SV staking calculations
Weight Calculation
- SV reward weights will be adjusted manually:
- Once at the 30-day threshold
- Then once every 10 days thereafter
Under-Staked Weight Handling
- A Foundation-controlled “ghost” Validator will be created
- Any SV weight not backed by sufficient disclosed stake will be:
- Removed from the SV
- Assigned to the ghost Validator
- Rewards associated with this weight will accrue to the ghost Validator pending Phase
- 3
Phase 2: On-Chain Locking (Automated SV Staking)
Activation
- Begins once the CC locking mechanism is deployed to MainNet
Requirements
- SVs must utilize the on-chain lock mechanism
- Only actively locked CC will count toward SV weight
- PartyId-based accounting is deprecated
Weight Calculation
- SV weights will be adjusted automatically every block
- Weight tiers are determined solely by actively locked CC
Unlocking Rules
- SVs may initiate an unlock at any time
- Unlocks take 365 days to become effective
Phase 3: Open Market Gap Filling (Third-Party Staking)
Activation
- Begins after a staked CC distribution mechanism is deployed to MainNet
Mechanism
- Any under-staked SV weight is made available to the market
- Any CC holder may lock CC to claim a pro-rata share of the under-staked SV rewards
- CC holders use the same locking mechanism introduced in Phase 2
Parity Requirement
- Third-party staking must follow the exact same rules as SV staking
- The Foundation’s ghost Validator:
- Is subject to the same lifetime staking thresholds
- Must maintain the required lock levels (historically and forward)
- May only distribute rewards backed by valid locked CC
Examples
Example 1: Fully Staked SV
- SV1 has earned
- 1B CC
- as an SV since genesis
- SV1 is currently a
- W10 SV
- To maintain W10 going forward, SV1 must lock
- 800M CC (80%)
- SV1 continues earning
- 100% of W10 rewards,
- and must lock 80% of new rewards locked forward
- to maintain 100% earnings
Example 2: Partially Staked SV
- SV2 has earned
- 1B CC
- as an SV since genesis
- SV2 locks
- 400M CC (40%)
- SV2 earns
- W4
- going forward
- SV2 must continue locking
- 40% of newly earned W4 rewards
- to maintain W4
- The remaining
- W6 rewards
- are made available to third-party CC stakers
Exemptions
The following entities are exempt from the SV staking requirement:
- The Foundation
- Due to its mandate to support the ecosystem, issue grants, fund development, and manage
- public goods
- The Ecosystem Fund SV operated by 5N
- Due to its role in ecosystem support and capital deployment rather than reward accumulation
- Any SV that can prove its coins are already locked for greater than 1 Year
- Once those coins are unlocked, the exemption will lapse
Backwards Compatibility
This proposal does not modify:
- Historical SV rewards
- Previously earned distributions
- Existing SV designations
All changes apply prospectively to forward SV reward calculations.
Future CIPs will propose implementation details for Phases 2 and 3.
Copyright
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.
Changelog
- 2025-01-27: Initial draft of the proposal
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.
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.
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 Eric,Thank you for the updated version of the proposal.I'm leaving discussion of tokenomics to the right owners, but I would like to get some clarification on the technical part:- Does "Validators may initiate an unlock at any time, after which 1/365.25 of the locked balance vests daily" mean that it's all or nothing — i.e., an SV cannot unlock a subset of coins?
- What does "on-chain locked CC" mean in the context of this CIP? Does it mean that the private key of the party holding the coins must be on the SV, or could the key also be off-chain (e.g., an external party with a delegation running on the SV to prove the holdings)?
- What happens to the locked coins if an SV is offboarded?
- A significant portion of SVs today don't run their own nodes. This CIP seems to cover only SVs that operate their own nodes. If this is the case, I believe it should be stated more explicitly in the text.Best regards,
Stas - hi Stas - in line below...On Tue, Feb 3, 2026 at 1:31 AM Stanislav German-Evtushenko via lists.sync.global <stasge=sbisecsol.com@...> wrote:Hi Eric,Thank you for the updated version of the proposal.I'm leaving discussion of tokenomics to the right owners, but I would like to get some clarification on the technical part:- Does "Validators may initiate an unlock at any time, after which 1/365.25 of the locked balance vests daily" mean that it's all or nothing — i.e., an SV cannot unlock a subset of coins?implementation TBD but I think it would make sense to unlock any size amount- What does "on-chain locked CC" mean in the context of this CIP? Does it mean that the private key of the party holding the coins must be on the SV, or could the key also be off-chain (e.g., an external party with a delegation running on the SV to prove the holdings)?implementation TBD but I'm imagining a smart contract lock mechanism you can utilize from an external wallet or custodian - I would not want to introduce operational risk and move away from wallet and custody infrastructure- What happens to the locked coins if an SV is offboarded?offboarded? assuming you mean SV status is revoked, the holder should be able unlock and it would go through the normal vesting schedule- A significant portion of SVs today don't run their own nodes. This CIP seems to cover only SVs that operate their own nodes. If this is the case, I believe it should be stated more explicitly in the text.this is drafted to apply to all SVs universally - not sure what language makes you think it's for the operators onlyBest regards,
Stas
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 Friday everyoneMany more rounds of feedback and discussion since v0.2. I'm attaching v0.3 for consideration.Noteworthy changes from last version:1. Remove all exemptions. Ultimately, there is plenty of supply at each participant and there is expected to be a sufficiently deep lending market that I think avoiding any and all exemptions is the best path forward.2. Remove the 'turbo tier' in v0.2. Some asked for the ability to move back up into top tier via overlocking the forward supply. Unfortunately, the logical decision would be for everyone to lock at the 50% tier and 100% of forward rewards, effectively eliminating the top tier.3. I added a recommendation on what to do with the SV Weight that would not be backed. I think the best thing to do is remove it from the total SV weight after 30 days. There are a bunch of games one can play with locking/unlocking if you leave the free option to regain your SV Weight in perpetuity. It would be better to return the weight to the rest of the locked SVs promptly.Thanks for continuing to engage on this topic - I think we are getting quite close to having more than enough votes for this idea to pass.EricOn Tue, Feb 3, 2026 at 2:53 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:hi Stas - in line below...On Tue, Feb 3, 2026 at 1:31 AM Stanislav German-Evtushenko via lists.sync.global <stasge=sbisecsol.com@...> wrote:Hi Eric,Thank you for the updated version of the proposal.I'm leaving discussion of tokenomics to the right owners, but I would like to get some clarification on the technical part:- Does "Validators may initiate an unlock at any time, after which 1/365.25 of the locked balance vests daily" mean that it's all or nothing — i.e., an SV cannot unlock a subset of coins?implementation TBD but I think it would make sense to unlock any size amount- What does "on-chain locked CC" mean in the context of this CIP? Does it mean that the private key of the party holding the coins must be on the SV, or could the key also be off-chain (e.g., an external party with a delegation running on the SV to prove the holdings)?implementation TBD but I'm imagining a smart contract lock mechanism you can utilize from an external wallet or custodian - I would not want to introduce operational risk and move away from wallet and custody infrastructure- What happens to the locked coins if an SV is offboarded?offboarded? assuming you mean SV status is revoked, the holder should be able unlock and it would go through the normal vesting schedule- A significant portion of SVs today don't run their own nodes. This CIP seems to cover only SVs that operate their own nodes. If this is the case, I believe it should be stated more explicitly in the text.this is drafted to apply to all SVs universally - not sure what language makes you think it's for the operators onlyBest regards,
Stas
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.
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 Eric and GSF members,
At Zenith, we are fully supportive of the CIP in its current form, and believe that it strengthens the network's long-term sustainability and ensures alignment among stakeholders. We would, however, like to raise a practical implementation consideration that could impact the tax implications of many SVs significantly. This does not change the structure of the CIP itself, but rather how rewards are distributed and locked in practice.
Problem statement
For U.S.-based, EU-based, and other SV entities across various jurisdictions, SV rewards are treated as taxable income at the time the tokens are earned and distributed.
Under the current proposal, U.S.-based SVs incur federal corporate income tax of 21%, with additional state taxes typically ranging from 5%–9%. Similar immediate tax obligations apply in several EU and other jurisdictions.- The tax implications will apply to the full reward received, and will force SVs to immediately sell a large portion of their rewards on a recurring basis, creating significant and continued sell pressure for the token.
Proposed implementation-level solution
We believe this situation can be addressed solely through its implementation, without altering the structure of the CIP itself:- The liquid portion of SV rewards (e.g., 30%, depending on tier) would be distributed directly to the SV’s active PartyID.
- The locked portion could be handled in two ways based on the individual SVs' strategy allowing them to choose their preferred option:
- The locked portion of SV rewards would be automatically allocated to an on-chain locking contract at the time of reward issuance. Alternatively, locked rewards could also be formally minted to the SV only at the time of the unlock. This would allow the taxable event to be delayed until the locked rewards are getting unlocked.
- SVs could claim the full rewards, and settle their taxes accordingly upon distribution of the full rewards..
We believe these implementation directions offer significant benefits for the network and network participants by greatly decreasing immediate sell pressure for tax reasons and avoiding timing related issues.
Thank you for your consideration,
Norbert - Hi everyone - further revisions based on feedback receivedNorbert - it's a good idea but there are also reasons one would prefer to recognize the revenue at time of reward. I suspect we can raise the way in which the reward is claimed in the implementation of the lock CIP that will follow (if this passes)ThanksOn Thu, Feb 12, 2026 at 5:11 AM Norbert Vadas via lists.sync.global <norbert.vadas=zenith.network@...> wrote:Hi Eric and GSF members,
At Zenith, we are fully supportive of the CIP in its current form, and believe that it strengthens the network's long-term sustainability and ensures alignment among stakeholders. We would, however, like to raise a practical implementation consideration that could impact the tax implications of many SVs significantly. This does not change the structure of the CIP itself, but rather how rewards are distributed and locked in practice.
Problem statement
For U.S.-based, EU-based, and other SV entities across various jurisdictions, SV rewards are treated as taxable income at the time the tokens are earned and distributed.
Under the current proposal, U.S.-based SVs incur federal corporate income tax of 21%, with additional state taxes typically ranging from 5%–9%. Similar immediate tax obligations apply in several EU and other jurisdictions.- The tax implications will apply to the full reward received, and will force SVs to immediately sell a large portion of their rewards on a recurring basis, creating significant and continued sell pressure for the token.
Proposed implementation-level solution
We believe this situation can be addressed solely through its implementation, without altering the structure of the CIP itself:- The liquid portion of SV rewards (e.g., 30%, depending on tier) would be distributed directly to the SV’s active PartyID.
- The locked portion could be handled in two ways based on the individual SVs' strategy allowing them to choose their preferred option:
- The locked portion of SV rewards would be automatically allocated to an on-chain locking contract at the time of reward issuance. Alternatively, locked rewards could also be formally minted to the SV only at the time of the unlock. This would allow the taxable event to be delayed until the locked rewards are getting unlocked.
- SVs could claim the full rewards, and settle their taxes accordingly upon distribution of the full rewards..
We believe these implementation directions offer significant benefits for the network and network participants by greatly decreasing immediate sell pressure for tax reasons and avoiding timing related issues.
Thank you for your consideration,
Norbert
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 -As discussed on this week's Tokenomics call, we have been thinking the values in the SV Locking and SV Weight schedule in section 5. Specifically, we believe there is an opportunity to improve on it a bit. Some thoughts and then an updated schedule:
- Currently the realized award to locked asset ratios are unintuitive with, in some cases, better ratios existing for lower lock %'s. We believe the realized award to locked asset ratios should strive to have a near linear shape with a downward slope as you traverse the tiers within a year. This can be accomplished in most cases* by changing the percent of locks required for each tier.
- Currently, the schedule is structured to provide flexibility to SVs as they adopt these changes, but maintains that complexity over time. We are supportive of the former, but think that latter can be improved. For example, in the furthest dated year, we question the need for 3 tiers as, by that time, existing SV's will have had time to adopt the changes and new SV's will have launch under the new mechanism. We propose structuring the schedule with flexibility in the early years but converging on a single tier in the later years--flexibility & complexity converging to efficiency & simplicity. This also helps address (1)
As for the * in (1), there are some boundary conditions that are complex to design for such as SVs that have very recently launched. In those cases, there is an upward slope as you traverse tiers, but it evolves to a downward slope a few months after launch. We think this is an acceptable corner case.
We propose the following schedule. Using the same format as the draft CIP offers, anything with a 0% represents an out of scope tier. - thanks Zuehlke - this makes a lot of sense to me - I'll update the table I presented in v0.4 and submit another version for everyone's considerationOn Fri, Feb 20, 2026 at 1:49 PM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:Hi all -As discussed on this week's Tokenomics call, we have been thinking the values in the SV Locking and SV Weight schedule in section 5. Specifically, we believe there is an opportunity to improve on it a bit. Some thoughts and then an updated schedule:
- Currently the realized award to locked asset ratios are unintuitive with, in some cases, better ratios existing for lower lock %'s. We believe the realized award to locked asset ratios should strive to have a near linear shape with a downward slope as you traverse the tiers within a year. This can be accomplished in most cases* by changing the percent of locks required for each tier.
- Currently, the schedule is structured to provide flexibility to SVs as they adopt these changes, but maintains that complexity over time. We are supportive of the former, but think that latter can be improved. For example, in the furthest dated year, we question the need for 3 tiers as, by that time, existing SV's will have had time to adopt the changes and new SV's will have launch under the new mechanism. We propose structuring the schedule with flexibility in the early years but converging on a single tier in the later years--flexibility & complexity converging to efficiency & simplicity. This also helps address (1)
As for the * in (1), there are some boundary conditions that are complex to design for such as SVs that have very recently launched. In those cases, there is an upward slope as you traverse tiers, but it evolves to a downward slope a few months after launch. We think this is an acceptable corner case.
We propose the following schedule. Using the same format as the draft CIP offers, anything with a 0% represents an out of scope tier.
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. - See v0.5 attached for consideration pleaseonly changed some language around the schedule and the schedule itself - otherwise didn't update any other sectionOn Fri, Feb 20, 2026 at 1:58 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:thanks Zuehlke - this makes a lot of sense to me - I'll update the table I presented in v0.4 and submit another version for everyone's considerationOn Fri, Feb 20, 2026 at 1:49 PM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:Hi all -As discussed on this week's Tokenomics call, we have been thinking the values in the SV Locking and SV Weight schedule in section 5. Specifically, we believe there is an opportunity to improve on it a bit. Some thoughts and then an updated schedule:
- Currently the realized award to locked asset ratios are unintuitive with, in some cases, better ratios existing for lower lock %'s. We believe the realized award to locked asset ratios should strive to have a near linear shape with a downward slope as you traverse the tiers within a year. This can be accomplished in most cases* by changing the percent of locks required for each tier.
- Currently, the schedule is structured to provide flexibility to SVs as they adopt these changes, but maintains that complexity over time. We are supportive of the former, but think that latter can be improved. For example, in the furthest dated year, we question the need for 3 tiers as, by that time, existing SV's will have had time to adopt the changes and new SV's will have launch under the new mechanism. We propose structuring the schedule with flexibility in the early years but converging on a single tier in the later years--flexibility & complexity converging to efficiency & simplicity. This also helps address (1)
As for the * in (1), there are some boundary conditions that are complex to design for such as SVs that have very recently launched. In those cases, there is an upward slope as you traverse tiers, but it evolves to a downward slope a few months after launch. We think this is an acceptable corner case.
We propose the following schedule. Using the same format as the draft CIP offers, anything with a 0% represents an out of scope tier.
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.
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, Eric
Could you maybe map this back to the more complete chart in the original proposal? I'm assuming that the v0.5 chart you've provided in the most recent message is missing the column for "Max Lock % of Lifetime SV Earnings" column, but wanted to be sure. - toggle quoted message Show quoted textThank you Chris, Eric, and everyone for their contributions to this proposal. Although a difficult conversation, we believe this will become a key milestone and serve as an important signal to the market on the long-term committment of SVs to the ecosystem going forward.Proof Group is one of the early SV's that will be impacted here, but given its importance we would like to indicate our support to the latest V5 proposal and officially sponsor it to a vote.On Mon, Feb 23, 2026 at 11:25 AM Wayne Collier via lists.sync.global <wayne.collier=digitalasset.com@...> wrote:Hi, Eric
Could you maybe map this back to the more complete chart in the original proposal? I'm assuming that the v0.5 chart you've provided in the most recent message is missing the column for "Max Lock % of Lifetime SV Earnings" column, but wanted to be sure. - 5 North would like to formally sponsor / endorse this cip and move it to vote.
- Hey guys,Do we have an idea of when this will be enforced - is it the 1st of April?Is there a lock mechanism in place from that date, or planned to be in place for delivery of this CIP - not just for the initial lock, but timelines on when auto-locking of SV rewards will be in place?Thanks,
- toggle quoted message Show quoted textAlso it would be helpful to know the mechanism. Additionally, the network needs to provide the calculation for the lock up requirement for the lifetime earnings component
Get Outlook for iOS
From: cip-discuss@... <cip-discuss@...> on behalf of john.mulreany via lists.sync.global <john.mulreany=kiln.fi@...>
Sent: Wednesday, March 18, 2026 7:31:22 AM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-0105: Super Validator (SV) Staking - Eric SaranieckiYou don't often get email from john.mulreany=kiln.fi@.... Learn why this is importantHey guys,Do we have an idea of when this will be enforced - is it the 1st of April?Is there a lock mechanism in place from that date, or planned to be in place for delivery of this CIP - not just for the initial lock, but timelines on when auto-locking of SV rewards will be in place?Thanks,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.
- toggle quoted message Show quoted textI am not sure of the exact timing of when this goes live, but assuming sometime April 1-15th.
CNTN will be offering locking as a service for anyone in the SV community that is interested. We have a tactical solution that will meet the CIP's/Foundations requirements. This will likely be a temporary mechanism until an on-chain solution is built. I would be happy to discuss with anyone that has interest. Feel free to reach out to me separately.
Thanks,Mark
From: cip-discuss@... <cip-discuss@...> on behalf of James Lang via lists.sync.global <james=libertycityventures.com@...>
Sent: Wednesday, March 18, 2026 9:38 AM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-0105: Super Validator (SV) Staking - Eric Saraniecki
Also it would be helpful to know the mechanism. Additionally, the network needs to provide the calculation for the lock up requirement for the lifetime earnings component
Get Outlook for iOS
From: cip-discuss@... <cip-discuss@...> on behalf of john.mulreany via lists.sync.global <john.mulreany=kiln.fi@...>
Sent: Wednesday, March 18, 2026 7:31:22 AM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-0105: Super Validator (SV) Staking - Eric SaranieckiYou don't often get email from john.mulreany=kiln.fi@.... Learn why this is importantHey guys,Do we have an idea of when this will be enforced - is it the 1st of April?Is there a lock mechanism in place from that date, or planned to be in place for delivery of this CIP - not just for the initial lock, but timelines on when auto-locking of SV rewards will be in place?Thanks,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.
Hello all,
Please find the operational guidelines that the SV operators, including the Foundation, plan to follow for implementing CIP-0105.
https://github.com/canton-foundation/configs/blob/main/processes/SV-Locking-Process.md
These guidelines outline how locking, monitoring, and enforcement will be handled during the Transitional Enforcement period ahead of full automation.
- Thanks, Amanda.It looks like the link has moved. Believe this is the new one?
https://github.com/canton-foundation/configs/blob/main/Super%20Validator%20Operational%20Processes/SV-Locking-Process.mdAs for the guidance, I see that there is no specific timeline proposed. Just a date for the earliest possible time. Given that, I'd like to suggest April 16, 2026 at 12:00 AM UTC as the start time for the locking CIP in mainnet to start the discussion. All, please share any thoughts/concerns you have about this timing.Separately, we've reviewed the operational guidelines and believe some additional detail as to how the process will work would be helpful. We're finalizing our feedback and will share in this thread soon.ThanksChris Hi All,
Sharing some feedback and suggested changes on the operational guidelines based on our initial review. Generally speaking, these are all points of clarification we’d like to see within the doc to make it as clear as possible for operators to execute on the process.
We welcome any feedback.
- As I understand it, if an SV meets the locking threshold at any time during the 30-day grace period, their weight can be restored. As such, can we clarify a couple points in the operational process:
- If an SV has met the locking requirement for their current tier between the time an initial weight reduction vote has been proposed and it passing, SV Operators should vote to reject the reduction.
- Similarly, can the guidelines specify explicitly that any time above the threshold is ok to meet the cure during the cure period to make this clearer for the operators?
- I understand that calculations for monitoring locked balances are still in progress, but once available can we add reference calculation methodology to the guidelines document? This help ensure all SVs can independently verify whether they meet locking requirements.
- Can we clarify in the document how SV Operators will receive notice from the foundation that an SV has communicated that they have restored their locked balance during the cure period so that SV Operators can ensure appropriate monitoring of that channel?
- Can we add some clarity as to any required process around notification of balances being unlocked? Will each SV be required to notify SV Operators or will this just be monitored based on when CC moves from the lock wallet to the unlock wallet?
Thanks,Andrew
- As I understand it, if an SV meets the locking threshold at any time during the 30-day grace period, their weight can be restored. As such, can we clarify a couple points in the operational process:
- One obvious thing that stands out to me is that no one is ready for the Apr 1 date as proposed in this guidanceWhat is a reasonable date given this guidance is still being discussed and refined? April 15th ?On Tue, Mar 31, 2026 at 8:58 AM Andrew Bryan via lists.sync.global <abryan=cumberland.io@...> wrote:
Hi All,
Sharing some feedback and suggested changes on the operational guidelines based on our initial review. Generally speaking, these are all points of clarification we’d like to see within the doc to make it as clear as possible for operators to execute on the process.
We welcome any feedback.
- As I understand it, if an SV meets the locking threshold at any time during the 30-day grace period, their weight can be restored. As such, can we clarify a couple points in the operational process:
- If an SV has met the locking requirement for their current tier between the time an initial weight reduction vote has been proposed and it passing, SV Operators should vote to reject the reduction.
- Similarly, can the guidelines specify explicitly that any time above the threshold is ok to meet the cure during the cure period to make this clearer for the operators?
- I understand that calculations for monitoring locked balances are still in progress, but once available can we add reference calculation methodology to the guidelines document? This help ensure all SVs can independently verify whether they meet locking requirements.
- Can we clarify in the document how SV Operators will receive notice from the foundation that an SV has communicated that they have restored their locked balance during the cure period so that SV Operators can ensure appropriate monitoring of that channel?
- Can we add some clarity as to any required process around notification of balances being unlocked? Will each SV be required to notify SV Operators or will this just be monitored based on when CC moves from the lock wallet to the unlock wallet?
Thanks,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. - As I understand it, if an SV meets the locking threshold at any time during the 30-day grace period, their weight can be restored. As such, can we clarify a couple points in the operational process:
- I had suggested April 16 2026 at 12:00 AM UTC above so generally ok with the 15th, but I think its worth adding some precision so there is no question as to the start time.
- sorry - missed that somehow - no need to alter from your proposalOn Tue, Mar 31, 2026 at 11:53 AM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:I had suggested April 16 2026 at 12:00 AM UTC above so generally ok with the 15th, but I think its worth adding some precision so there is no question as to the start time.
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. - toggle quoted message Show quoted textHave a basic question:What is the ‘source or truth’ on how many rewards have been minted per SV and will be minted moving forward?Explorers do disagree in some cases.Y.On Tue, Mar 31, 2026 at 11:55 Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:sorry - missed that somehow - no need to alter from your proposalOn Tue, Mar 31, 2026 at 11:53 AM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:I had suggested April 16 2026 at 12:00 AM UTC above so generally ok with the 15th, but I think its worth adding some precision so there is no question as to the start time.
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. Hello everyone,
It would be helpful to align on what needs to be accomplished by the target date(s). Could we please establish a requirements timeline for the following items:
-
Locking/unlocking wallets set up (April 1?)
-
Tiers communicated to GSF (April 1?)
-
Future lock tiers set up and automated by operators (April 1?) to allocate new rewards into locked wallets
-
Transfer of lifetime funds into lock wallet completed (dependent on dashboard availability) (April 15?)
-
Audit of funds received (Date?)
-
Notification of underfunded status (Date?)
-
Cure period (Deadline Date?)
Many thanks,
Kinga
sorry - missed that somehow - no need to alter from your proposalOn Tue, Mar 31, 2026 at 11:53 AM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:I had suggested April 16 2026 at 12:00 AM UTC above so generally ok with the 15th, but I think its worth adding some precision so there is no question as to the start time.-
- toggle quoted message Show quoted text
Hi folks,
Just wanted to confirm a couple things which I think make sense, but aren't explicitly stated in the CIP:
- Is it OK to, at least in the Transitional Enforcment period, just designate our SV party as one of the locked parties, so that we auto-lock as we earn?
- In the event that we have >70% locked, is it OK to withdraw amounts over 70% without a 1-year hold?
- Is there a way to move locked funds from one custodian to another (while remaining locked), without needing to wait a year?
Best,
Ryan
On 3/31/26 12:12, Kinga Bosse via lists.sync.global wrote:
Hello everyone,
It would be helpful to align on what needs to be accomplished by the target date(s). Could we please establish a requirements timeline for the following items:
-
Locking/unlocking wallets set up (April 1?)
-
Tiers communicated to GSF (April 1?)
-
Future lock tiers set up and automated by operators (April 1?) to allocate new rewards into locked wallets
-
Transfer of lifetime funds into lock wallet completed (dependent on dashboard availability) (April 15?)
-
Audit of funds received (Date?)
-
Notification of underfunded status (Date?)
-
Cure period (Deadline Date?)
Many thanks,
Kinga
sorry - missed that somehow - no need to alter from your proposalOn Tue, Mar 31, 2026 at 11:53 AM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:I had suggested April 16 2026 at 12:00 AM UTC above so generally ok with the 15th, but I think its worth adding some precision so there is no question as to the start time. - Hi all,We'd like to flag a few Phase 2 implementation considerations that we think are worth discussing early, before the
on-chain locking mechanism is designed:
1. What qualifies as "actively locked CC"?The CIP says only actively locked CC counts toward SV weight, but doesn't define the boundaries. As Phase 2 moves to
on-chain enforcement, this matters:- Does CC need to be in a specific locking contract, or can it be in any auditable on-chain position with equivalent
lock properties (time-lock, vesting schedule, transparency)?
- If an SV's CC is held in a vault or structured product that enforces equivalent lock constraints (same vesting,
same unlock period), does that satisfy the requirement?
- Should the locking interface be generic enough that different custody and lock vehicles can implement it, or does
it need to be a single canonical contract?
We think the answer should be a generic locking interface to provide a standard that any qualifying lock vehicle can
implement. This would address Stanislav's cold wallet question, support multi-custodian setups, and give SVs
flexibility without weakening the enforcement. It also keeps the door open for future innovation on how locked CC can remain productive.
2. Custody flexibility for Phase 2Several participants raised questions about custody requirements. We'd suggest Phase 2's on-chain mechanism explicitly support:- Locking from multiple PartyIds (aggregate threshold, as the CIP intends)
- Locking via institutional custodians (the SV shouldn't need to self-custody to lock)
- A clean separation between "who controls the lock" and "who benefits from the weight"Our engineering team is working on Splice contributions and we'd be happy to contribute to the Phase 2 locking
mechanism design and implementation. We're here to build and would welcome a conversation with whoever is scoping the Phase 2 contracts and share our candidate implementation plan too.
Happy to coordinate with Eric, Wayne, or anyone else driving the implementation timeline.
Ian
Avro Digital | avrofi.com - I'd say May 1st at the earliest. still a lot of open questions from members, and we want to have a chance to host Q&A sessions if required.
- toggle quoted message Show quoted textI agree that it would be helpful to have a solid understanding of what the expected structure is of wallets in order to make the monitoring for this straightforward, both for Phase 1 and future phases. I don't know that there was really specific guidance given on that and so our current wallet structure, where we sweep all of our rewards for both V/SVs above a certain USD threshold to a single special wallet where its setup was witnessed by our external auditors and has the proper attestations and sign-offs, isn't ideal for this CIP. I gave that party ID for monitoring, but it means that we're locking just about all of our CC until our wallet structure is changed, which we can't just do without a lot of ceremony. For the purposes of informal enforcement in Phase 1, I feel that a simple and easy-to-understand solution is to say our current main wallet has 1616MM CC, we'd guarantee we'll keep ~1200MM CC in it to stay above the 70% threshold, nobody needs to do math to add up nearly 90000 rounds of SV reward coupons and figure out the actual exact number unless they really want to.
As for the eventual Phase 2 technical implementation, the way Cantonscan shows the UTXOs in the wallet (e.g. https://www.cantonscan.com/party/twmain-kms-01%3A%3A12200ada298fab88ca8f3a0ea7b9c2817240ce33d038e24b0283536cab042743c6e4) seems to imply that locking is a flag on a UTXO itself, which to me would imply that we could have a locked UTXO coexist in one wallet with unlocked UTXOs, and there could be a smart contract to split SV reward coupons into a locked and unlocked portion and append the new locked UTXO to the existing big one. Is that the way it is expected to work in P2, or is it expected that entire wallets will be marked "locked" and then the accounting and lock/unlock mechanisms will operate at a wallet level rather than UTXO level?
CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.
Hi folks,
Just wanted to confirm a couple things which I think make sense, but aren't explicitly stated in the CIP:
- Is it OK to, at least in the Transitional Enforcment period, just designate our SV party as one of the locked parties, so that we auto-lock as we earn?
- In the event that we have >70% locked, is it OK to withdraw amounts over 70% without a 1-year hold?
- Is there a way to move locked funds from one custodian to another (while remaining locked), without needing to wait a year?
Best,
Ryan
On 3/31/26 12:12, Kinga Bosse via lists.sync.global wrote:
Hello everyone,
It would be helpful to align on what needs to be accomplished by the target date(s). Could we please establish a requirements timeline for the following items:
-
Locking/unlocking wallets set up (April 1?)
-
Tiers communicated to GSF (April 1?)
-
Future lock tiers set up and automated by operators (April 1?) to allocate new rewards into locked wallets
-
Transfer of lifetime funds into lock wallet completed (dependent on dashboard availability) (April 15?)
-
Audit of funds received (Date?)
-
Notification of underfunded status (Date?)
-
Cure period (Deadline Date?)
Many thanks,
Kinga
sorry - missed that somehow - no need to alter from your proposalOn Tue, Mar 31, 2026 at 11:53 AM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:I had suggested April 16 2026 at 12:00 AM UTC above so generally ok with the 15th, but I think its worth adding some precision so there is no question as to the start time. - With regards to the pace of unlocks when they don't impact tier, we've been speaking with a number of participants and would like to propose a potential mechanism for Phase 1 that could help with clarification and increased efficiency of capital markets that are forming to support SV locks. As a guiding principle we propose that CC should be available for immediate unlock in cases when the SV is substituting CC. In other words:
- The amount unlocked is less than the amount "recently" locked, and
- The amount unlocked does not result in a change in Tier.
More specifically, we propose the following logic to determine eligible immediate unlock amounts under this case:immediate_unlock = min(unlock_amount, recent_locked_amount, total_locked – beginning_tier_lock)
unbonding_unlock = unlock_amount – immediate_unlockWhere:-
- total_locked is the total amount locked at time of the attempted unlock
- unlock_amount is the total amount of the attempted unlock
- immediate_unlock is the portion of the unlock that is immediately liquid
- unbonding_unlock is the portion of the unlock that is subject to the 365 day unbonding period
- beginning_tier_lock is the minimum CC lock threshold for the SV lock tier at the beginning of the most recent 24-hour (140 round) window
- recent_locked_amount is the amount locked in the most recent 24-hour (140 round) window
In a Phase 2, we'd propose atomic substitution mechanism be implemented in place of the above eligibility criteria, allowing SVs to be able to replace locked CC without the unbonding period only if it is substituted as part of the same transaction. - toggle quoted message Show quoted text
Beyond the scenario where an SV is substituting CC, there are other scenarios like transferring from one custodian to another where it might be necessary to unlock and relock with those transactions not necessarily occurring simultaneously.
From: cip-discuss@... <cip-discuss@...> On Behalf Of Andrew Bryan via lists.sync.global
Sent: Thursday, April 2, 2026 2:49 PM
To: cip-discuss@...
Subject: Re: [cip-discuss] CIP-0105: Super Validator (SV) StakingWith regards to the pace of unlocks when they don't impact tier, we've been speaking with a number of participants and would like to propose a potential mechanism for Phase 1 that could help with clarification and increased efficiency of capital markets that are forming to support SV locks. As a guiding principle we propose that CC should be available for immediate unlock in cases when the SV is substituting CC. In other words:
- The amount unlocked is less than the amount "recently" locked, and
- The amount unlocked does not result in a change in Tier.
More specifically, we propose the following logic to determine eligible immediate unlock amounts under this case:
immediate_unlock = min(unlock_amount, recent_locked_amount, total_locked – beginning_tier_lock)
unbonding_unlock = unlock_amount – immediate_unlockWhere:
·
- total_locked is the total amount locked at time of the attempted unlock
- unlock_amount is the total amount of the attempted unlock
- immediate_unlock is the portion of the unlock that is immediately liquid
- unbonding_unlock is the portion of the unlock that is subject to the 365 day unbonding period
- beginning_tier_lock is the minimum CC lock threshold for the SV lock tier at the beginning of the most recent 24-hour (140 round) window
- recent_locked_amount is the amount locked in the most recent 24-hour (140 round) window
In a Phase 2, we'd propose atomic substitution mechanism be implemented in place of the above eligibility criteria, allowing SVs to be able to replace locked CC without the unbonding period only if it is substituted as part of the same transaction.
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.During phase 1, if the SV reports both the source wallet and the target wallet are listed as locking wallets, the SV's locked balance wouldn't change when they moved funds from one custodian to another. This is a manual stage: there are no technical locks, only a list of wallets that the SV has indicated will together hold its total locked balance.
- Hi All,I'd like to make one slight adjustment to my above formal definition of the "lock substitution" mechanism that would allow for immediate unlock of CC. In the above, I incorrectly stated that the immediate unlock amount should not be greater than the difference between the current total locked amount and the locking tier threshold at the beginning of the rolling 24-hour "recent_lock_amount" period. This should instead be the difference between the current total locked amount and the currently applicable SV locking tier threshold. In this way, any immediate unlock amount will ensure that no change in SV lock tier occurs as a result of the immediately unlocked portion.This is corrected in the below:immediate_unlock = min(unlock_amount, recent_locked_amount, total_locked – current_tier_lock)
unbonding_unlock = unlock_amount – immediate_unlockWhere:-
- total_locked is the total amount locked at time of the attempted unlock
- unlock_amount is the total amount of the attempted unlock
- immediate_unlock is the portion of the unlock that is immediately liquid
- unbonding_unlock is the portion of the unlock that is subject to the 365 day unbonding period
- current_tier_lock is the minimum CC lock threshold for the SV lock tier at the time of the unlock request (i.e., the currently applicable SV lock tier)
- recent_locked_amount is the amount locked in the most recent 24-hour (140 round) window
-
- toggle quoted message Show quoted textThanks Andrew- I think this minor adjustment of a 24 hour window to unlock/ relock CC makes sense.This should help SVs looking at lending facilities to source CC needed to lock- which would be awesome to see done onchain.On Mon, Apr 6, 2026 at 4:45 PM Andrew Bryan via lists.sync.global <abryan=cumberland.io@...> wrote:Hi All,I'd like to make one slight adjustment to my above formal definition of the "lock substitution" mechanism that would allow for immediate unlock of CC. In the above, I incorrectly stated that the immediate unlock amount should not be greater than the difference between the current total locked amount and the locking tier threshold at the beginning of the rolling 24-hour "recent_lock_amount" period. This should instead be the difference between the current total locked amount and the currently applicable SV locking tier threshold. In this way, any immediate unlock amount will ensure that no change in SV lock tier occurs as a result of the immediately unlocked portion.This is corrected in the below:immediate_unlock = min(unlock_amount, recent_locked_amount, total_locked – current_tier_lock)
unbonding_unlock = unlock_amount – immediate_unlockWhere:-
- total_locked is the total amount locked at time of the attempted unlock
- unlock_amount is the total amount of the attempted unlock
- immediate_unlock is the portion of the unlock that is immediately liquid
- unbonding_unlock is the portion of the unlock that is subject to the 365 day unbonding period
- current_tier_lock is the minimum CC lock threshold for the SV lock tier at the time of the unlock request (i.e., the currently applicable SV lock tier)
- recent_locked_amount is the amount locked in the most recent 24-hour (140 round) window
-
- Building on Andrew's definitions above, attached (and below) is a document with proposed detailed Supplier Substitution workflows during manual Phase1, for discussion on May 6th (tomorrow) Tokenomics committee meetingThanks
CIP-0105 : Supplier Substitution
Liquid credit markets for locked and vesting CC are beneficial to long term growth of Canton. While complying with network rules, allowing duration exposure to be actively distributed based on CC supplier’s risk requirements will increase investment activity by enabling competitive funding for SVs and FAs.Proposed Requirements:
-
Allow for substitution of CC supplier partyID in both Actively Locked + Vesting states
-
Continuous tier weight credit during/after substitution (no tier changes permitted)
-
Original supplier receives immediate liquid CC, not subject to vesting period
-
for Vesting positions, release schedule/sizes and final ‘maturity date’ are preserved
-
Same workflow for both SV + FA locking
3rd party delegation operational workflows (Phase1 manual)
-
Activating Initial Lock
-
Supplier (Delegator) holds CC in unique partyID (lockedWallet)
-
Canton Foundation is provided the below variables via email to CF Operations team:
-
CC size
-
targetPartyID (SV/FA beneficiary)
-
lockedWallet partyID (supplier)
-
unlockWallet partyID (supplier)
-
supplier institution name
-
contact names/emails for both parties
-
Quorum agreement of the delegation by both parties
-
Proposed: 3rd party / marketplaces can provide initial instructions - subject to quorum confirmation (via group email cc)
-
Supplier Substitution of Actively Locked CC
-
Existing supplier holds CC in lockedWallet, with tier credit currently attributed to targetPartyID
-
New supplier holds CC in unique partyID (new_lockedWallet)
-
Packaged instruction submitted to Canton Foundation Operations via email (can be provided by 3rd party / marketplace):
-
CC size of substitution
-
new_lockedWallet partyID (new supplier ; requesting new_lock)
-
new_unlockWallet partyID (new supplier)
-
new supplier institution name
-
new supplier contact names/emails
-
existing lockedWallet (requesting immediate_unlock)
-
Subject to validating the below Enforcement Formula:
-
existing lockedWallet CC is instantly released to liquid state (100% moved to unlockWallet)
-
new_lockedWallet enters actively Locked state
-
no change to SV/FA attribution
-
Enforcement Formula = same 24 hour window
immediate_unlock = min(unlock_amount, recent_locked_amount, total_locked – current_tier_lock) unbonding_unlock = unlock_amount – immediate_unlock
Where: -
total_locked is the total amount locked at time of the attempted unlock
-
unlock_amount is the total amount of the attempted unlock
-
immediate_unlock is the portion of the unlock that is immediately liquid
-
unbonding_unlock is the portion of the unlock that is subject to the 365 day unbonding period
-
current_tier_lock is the minimum CC lock threshold for the SV lock tier at the time of the unlock request (i.e., the currently applicable SV lock tier)
-
recent_locked_amount is the amount locked in the most recent 24-hour (140 round) window
-
Supplier Substitution of Vesting CC
-
Existing supplier holds vesting CC in unlockWallet
Certain attributes are known and fixed: -
Maturity Date = initial unlock date + 365.25 days
-
CC amount vest per day = initial unlock amount / 365.25
-
vesting CC does not count towards any tier weight = no targetPartyID / beneficiary
-
Packaged instruction submitted to Canton Foundation Operations via email (can be provided by 3rd party / marketplace):
-
CC size of substitution (full or partial)
-
the offset would be against specified maturity date, as holder/seller of that vesting stream would have needs to offset their specific obligation
-
Initial unlock date (or CC vest per day)
-
Maturity date
-
existing unlockWallet (requesting immediate_unlock)
-
new supplier institution name
-
new supplier contact names/emails
-
new_unlockWallet
-
new supplier assumes existing static data of vesting CC
Phase2 (future on-chain) : Above requirements to be scoped into architecture with CIP-0105 Phase2 implementation working group
-
- As a update: the working group for scoping phase2 Splice requirements has included supplier substitution on both actively locked CC + vesting locked CC
I want to request if there is any feedback on the above process list during phase1 (manual enforcement), so that we can formally move it forward as standard operating procedure. This formalization will be helpful for how 3rd party delegation deals are managed before on-chain contracts are implemented.Thanks In addition, the ability to transfer locked tokens among custodians, exchanges, and self-custody solutions should be formalized. Locking Canton via a 3rd party vendor should not result in that vendor being locked in.
