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) 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:

1.  
2.  
3. The Foundation
4.  

•  
•  
• Due to its mandate to support the ecosystem, issue grants, fund development, and manage
• public goods
•  

5.  
6.  
7. The Ecosystem Fund SV operated by 5N
8.  

•  
•  
• Due to its role in ecosystem support and capital deployment rather than reward accumulation
•  

9.  
10.  
11. Any SV that can prove its coins are already locked for greater than 1 Year 
12.  

•  
•  
• 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 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 only  

 

Best 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.

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:
  1. 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.
  2. 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 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:

1. 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.
2. 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 consideration

On 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:

1. 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.
2. 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.