[withdrawn] CIP-TBD: Validator Staking - Eric Saraniecki
Please see below for open discussion.Number: CIP-TBD Title: Validator Staking Author(s): W Eric Saraniecki Type: Tokenomics Status: Draft Created: 2026-01-21 License: CC0-1.0
Validator Staking CIPSummary
This proposal introduces Validator Staking as a requirement for operating an active Validator on the Canton Network.
To operate as an active Validator, an entity must:
Receive an allocation by the Foundation for IP whitelisting, and
Maintain a minimum amount of Canton Coin (CC) staked on its behalf.
If the required minimum lock is not maintained, the Validator will have its IP whitelist access revoked after a 30 day warning.
Any CC holder may stake CC on behalf of a Validator.
Motivation
Validators are a critical component of network reliability and performance. As the network matures, Validators should demonstrate not only technical capability but also durable economic commitment to Canton.
Validator staking:
Aligns incentives between Validators and the network
Introduces objective, on-chain criteria alongside qualitative approval
Enables community participation in backing reliable Validators
Creates a scalable framework as Validator participation grows
Specification
1. Validator Qualification Requirements
To operate as an active Validator, an entity must satisfy both of the following:
1.1 Foundation Approval and IP Whitelisting
The Foundation retains discretion over Validator approval and IP whitelisting based on qualitative criteria, including:
Operational competence
Security posture
Compliance with network policies
On-chain and off-chain behavior
1.2 Minimum CC Stake Requirement
A minimum amount of CC must be actively locked on behalf of the Validator.
Failure to satisfy either requirement results in loss of active Validator status.
2. Phased Implementation
To minimize operational risk and align with the rollout of SV and Featured App staking, Validator staking will be implemented in two phases, followed by ongoing parameter review.
Phase 1: Transitional Enforcement (Manual)
Activation
Goes into effect within 15 days of CIP approval
Staking Requirement
Minimum stake: 1 million CC per Validator
Requirements
CC intended to count toward Validator staking must be moved to a segregated, auditable PartyId
The PartyId information must be shared with the Foundation
Any CC holder may sponsor a Validator by:
Registering the PartyId holding the CC, and
Registering the PartyId of the Validator being sponsored
Enforcement
Validators that do not meet the minimum staking requirement by the deadline will be:
Issued a 30-day notice of impending IP whitelist removal
Validators receiving notice:
Will lose active Validator status at the end of the notice period
May re-enter the queue for IP whitelisting if they wish to return later
Phase 2: On-Chain Locking (Automated Validator Staking)
Activation
Begins once the CC locking mechanism used for SV staking is deployed to MainNet
Staking Requirement
Minimum stake: 2 million CC per Validator
Mechanism
Validators must utilize the on-chain locking mechanism
Only actively locked CC counts toward Validator eligibility
Any CC holder may lock CC on behalf of a Validator
Connectivity Rules
Validator connectivity to MainNet depends on meeting the locked CC requirement
If locked stake falls below the required threshold, the Validator:
Will be notified it will lose its connectivity to MainNet within 30 days
Unlocking Rules
CC may be unlocked at any time
Unlocks take 365 days to become effective
3. Third-Party Validator Backing
Any CC holder may stake CC on behalf of a Validator
Validator operators are not required to supply the stake themselves
Multiple CC holders may collectively satisfy the staking requirement
This enables:
Community support for reliable Validators
Capital-efficient participation for operators
Market-based signaling of Validator quality
4. Ongoing Parameter Review
The minimum CC stake required for active Validator status will be reviewed every 90 days
Reviews will be conducted by the Foundation’s Tokenomics Committee
Any changes will be:
Communicated in advance, and
Applied prospectively
This allows the network to adapt requirements as scale, performance expectations, and economic conditions evolve.
Backwards Compatibility
No historical Validator rewards or activity are modified
This proposal applies prospectively to Validator status
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.
- 2025-01-21: Initial draft of the proposal
We acknowledge the proposal's intent to align with the network's broader direction of favouring active application development over passive infrastructure operation.
For validators currently operating on the Canton Network MainNet who find themselves holding sufficient Canton Coins to meet Phase 1 requirements but falling short of the Phase 2 requirement (2 million CC minimum), the removal of liveness rewards will mean these validators have no passive mechanism to accumulate additional CC until such time that those actively developing applications will be able to provide economic commitment to Canton network and/or provide the ability to allow 3rd parties to stake on behalf of a validator.
We have the following questions to seek clarification on implementation details that directly affect our (and likely others') ability to plan for continued operation on Mainnet.1. What is the anticipated timeline for deploying the on-chain CC locking mechanism to MainNet, which triggers Phase 2 activation?
2. If a validator's IP whitelist is revoked after the 30-day warning period due to insufficient stake under Phase 2, does the 365-day unlock waiting period still apply to their locked CC?
3. If a validator voluntarily withdraws after Phase 1 implementation but before Phase 2 activation, does the 365-day unlock period apply?
4. If a validator loses connectivity to MainNet due to insufficient stake, how will the unlocked coins be returned?
5. What is the expected yield model or reward mechanism for staking (or the term to be used for Canton), and if rewards earned in CC from such staking also subject to the 365-day unlock periodThe following alternatives are offered in the spirit of achieving the proposal's stated objectives—aligning validator incentives with the network and objective qualification criteria—while addressing practical implementation concerns for affected validators.
1. Graduated Stake Requirement with Defined Timeline
Rather than doubling the requirement from 1 million CC (Phase 1) to 2 million CC (Phase 2) upon deployment of the locking mechanism, consider implementing an intermediate step:
- Phase 1: 1 million CC (current proposal)
- Phase 2a: 1.5 million CC (6 months after locking mechanism deployment)
- Phase 2b: 2 million CC (12 months after locking mechanism deployment)
This provides validators with a defined timeline and incremental milestones, enabling more realistic planning for stake accumulation or third-party staking arrangements.
2. Differentiated Unlock Periods Based on Circumstances
Consider applying different unlock periods based on the reason for withdrawal:
- Removal due to insufficient stake after warning period: 180-day unlock period
- Removal due to security, compliance, or behavioural violations: 365-day unlock period (as currently proposed)
This distinction maintains strong disincentives against harmful behaviour while reducing the capital lockup burden for validators who exit due to economic constraints rather than misconduct.
3. Provisional Status for Validators in Active Development
For validators who meet Phase 1 requirements but not Phase 2 requirements, and who are actively developing applications toward featured app status, consider a provisional category:
- Validators demonstrate active development through verifiable milestones (e.g., testnet deployment, application submission to the Foundation)
- Provisional status grants a defined extension period (e.g., 6-12 months) to meet Phase 2 requirements
- Failure to achieve featured app status or meet staking requirements by the end of the provisional period results in standard 30-day warning and removal process
This aligns with the network's preference for active development while providing a pathway for validators committed to building on Canton.
4. Defined Staking Reward Framework
To enable a functioning third-party staking market, consider publishing a defined reward framework or minimum APY guidance:
- Specify whether validators are expected to share a portion of any operational rewards with third-party stakers
- Clarify whether staking rewards (if any) are subject to the same 365-day unlock period as principal
- Provide guidance on acceptable staking arrangement structures
Without this clarity, validators cannot effectively design or market staking propositions to potential third-party backers.
5. Grace Period for Phase 1 Compliant Validators at Phase 2 Activation
When Phase 2 activates, consider granting validators who were compliant under Phase 1 an automatic grace period (e.g., 90-180 days) to meet the increased requirement, rather than immediate application of the 30-day warning period.
This acknowledges that validators acted in good faith under Phase 1 requirements and provides reasonable time to adjust to the doubled threshold.
We welcome further discussion and are committed to working constructively with the Foundation and the Tokenomics Committee to achieve outcomes that benefit the network's long-term health and maturity.
I think whether this CIP is good or bad really depends on the desired outcome.
If the goal is to mainly attract large institutions, then requiring 1 to 2 million CC to run a validator makes sense. It forces economic commitment, pushes more circulating supply into long-term locks, and raises the bar for participation in a clear way.
If the goal is to attract builders, new projects, experimentation, more DeFi activity, and liquidity from other ecosystems, then I don’t think this proposal helps. In that scenario it actually raises the barrier too much for newcomers.
Why this is different from staking on other networks
On most networks, staking comes with native yield. Validators earn block rewards and fees, and sponsors earn yield minus a commission. There is a clear economic loop. Operators can set commission rates, sponsors know what they earn, and everyone understands the incentive structure.
Some networks also require self-bonding to increase yield or even be eligible to validate, but again this is tied to a predictable reward system. Staking is the bedrock of their entire economic design which has proven to be flawed on most networks and therefore im reluctant to support introducing such a mechanism on Canton.
On Canton, liveness rewards are being phased out. That means validator revenue will mainly come from validating transfers tied to app activity. If I understand correctly, there is no passive incentive to run a validator unless you are already validating app traffic or building your own app.
The imbalance I see
So right now, a new validator needs:
-
A whitelisted key
-
A sponsor willing to lock 2 million CC
-
A sponsor lock of 365 days
-
And the risk that this sponsor can still pull out, forcing you to find a new one within 30 days
That is a lot of requirements for a potential opportunity to earn a profit.
From a builder’s perspective, this is not balanced. Especially when there is no clear way to compensate a sponsor for locking such a large amount of capital for such a long time.
The 365-day unlock combined with a 30-day replacement window also creates recurring risk for anyone close to launching an app. If a sponsor pulls out, you are suddenly scrambling for a new one without any clear incentive to offer.
What I would change
I fully agree that validators should show long-term economic commitment, and I agree that builders should not be paid just for showing up, therefore phasing out liveness rewards makes sense.
What I would like to propose to add to this CIP is a sponsor incentive mechanism. Something that encourages large CC holders to actively seek projects to sponsor, rather than putting the entire burden on builders to go begging for locked capital.
If done right, this could actually result in far more CC being locked long-term, while keeping the network open and attractive for new apps, new builders, and new ideas.
That balance feels important if we want Canton to grow beyond just a subset of large institutions. Curious to hear the thoughts of others on this.
-
Dear All,
We appreciate the Validator Staking CIP and the intent to introduce clearer, objective criteria as validator participation scales. We are responding from the perspective of an operator that manages multiple validator nodes. In that context, we would like to raise several considerations specific to the validator staking/bonding mechanism, particularly around capital sourcing, control, and lock mechanics.
First, while third-party staking is permitted, validator connectivity and IP whitelisting are directly tied to maintaining the required stake even when the validator operator does not control the staked capital. This creates material operational risk. A validator can remain fully compliant from a technical and security standpoint yet still lose connectivity due to sponsor actions, withdrawal decisions, or coordination failures outside the operator’s control. If third-party backing is expected to be common, the proposal should clearly define how validators are protected in these scenarios.
Second, as we pointed it out elsewhere the locking and unlock mechanics materially reduce capital flexibility. Although CC may be unlocked at any time, a fixed 365-day delay combined with an otherwise indefinite lock significantly limits liquidity. For operators responsible for infrastructure, staffing, and security across multiple nodes, this level of illiquidity makes it difficult to responsibly manage treasury and operational risk over time. This is more restrictive than most crypto-native staking systems.
Finally, validator staking is being introduced alongside Super Validator and application staking proposals. Consistent with feedback already provided by others, these requirements compound capital commitments and illiquidity for operators supporting validators across the stack. We believe the cumulative impact should be evaluated explicitly to avoid unintentionally raising participation barriers as the network grows.
Based on the above, we propose considering the following adjustments:
-
Clarify how validators are protected from loss of connectivity or IP whitelisting due to actions by third-party sponsors whose capital they do not control.
-
Define explicit guarantees around asset custody and withdrawal rights for any CC locked on behalf of validators, to prevent effective indefinite lock-in.
-
Reconsider the fixed 365-day unlock period in favor of shorter, bounded, or queue-based exit mechanisms.
-
Evaluate validator capital requirements in the broader context of SV and application staking to avoid compounding participation friction.
We support the goal of improving validator alignment and reliability and believe it can be achieved while preserving operator control, predictable exits, and reasonable liquidity expectations and happy to discuss.
Summary
This proposal introduces Validator Staking as a requirement for operating an active Validator on the Canton Network.
To operate as an active Validator, an entity must:
-
Receive an allocation by the Foundation for IP whitelisting, and
-
Maintain a minimum amount of Canton Coin (CC) staked on its behalf.
If the required minimum lock is not maintained, the Validator will have its IP whitelist access revoked after a 30 day warning.
Any CC holder may stake CC on behalf of a Validator.
Motivation
Validators are a critical component of network reliability and performance. As the network matures, Validators should demonstrate not only technical capability but also durable economic commitment to Canton.
Validator staking:
-
Aligns incentives between Validators and the network
-
Introduces objective, on-chain criteria alongside qualitative approval
-
Enables community participation in backing reliable Validators
-
Creates a scalable framework as Validator participation grows
Specification
1. Validator Qualification Requirements
To operate as an active Validator, an entity must satisfy both of the following:
1.1 Foundation Approval and IP Whitelisting
The Foundation retains discretion over Validator approval and IP whitelisting based on qualitative criteria, including:
-
Operational competence
-
Security posture
-
Compliance with network policies
-
On-chain and off-chain behavior
1.2 Minimum CC Stake Requirement
A minimum amount of CC must be actively locked on behalf of the Validator.
Failure to satisfy either requirement results in loss of active Validator status.
2. Phased Implementation
To minimize operational risk and align with the rollout of SV and Featured App staking, Validator staking will be implemented in two phases, followed by ongoing parameter review.
Phase 1: Transitional Enforcement (Manual)
Activation
-
Goes into effect within 15 days of CIP approval
Staking Requirement
-
Minimum stake: 1 million CC per Validator
Requirements
-
CC intended to count toward Validator staking must be moved to a segregated, auditable PartyId
-
The PartyId information must be shared with the Foundation
-
Any CC holder may sponsor a Validator by:
-
Registering the PartyId holding the CC, and
-
Registering the PartyId of the Validator being sponsored
Enforcement
-
Validators that do not meet the minimum staking requirement by the deadline will be:
-
Issued a 30-day notice of impending IP whitelist removal
-
Validators receiving notice:
-
Will lose active Validator status at the end of the notice period
-
May re-enter the queue for IP whitelisting if they wish to return later
Phase 2: On-Chain Locking (Automated Validator Staking)
Activation
-
Begins once the CC locking mechanism used for SV staking is deployed to MainNet
Staking Requirement
-
Minimum stake: 2 million CC per Validator
Mechanism
-
Validators must utilize the on-chain locking mechanism
-
Only actively locked CC counts toward Validator eligibility
-
Any CC holder may lock CC on behalf of a Validator
Connectivity Rules
-
Validator connectivity to MainNet depends on meeting the locked CC requirement
-
If locked stake falls below the required threshold, the Validator:
-
Will be notified it will lose its connectivity to MainNet within 30 days
Unlocking Rules
-
CC may be unlocked at any time
-
Unlocks take 365 days to become effective
3. Third-Party Validator Backing
-
Any CC holder may stake CC on behalf of a Validator
-
Validator operators are not required to supply the stake themselves
-
Multiple CC holders may collectively satisfy the staking requirement
This enables:
-
Community support for reliable Validators
-
Capital-efficient participation for operators
-
Market-based signaling of Validator quality
4. Ongoing Parameter Review
-
The minimum CC stake required for active Validator status will be reviewed every 90 days
-
Reviews will be conducted by the Foundation’s Tokenomics Committee
-
Any changes will be:
-
Communicated in advance, and
-
Applied prospectively
This allows the network to adapt requirements as scale, performance expectations, and economic conditions evolve.
Backwards Compatibility
-
No historical Validator rewards or activity are modified
-
This proposal applies prospectively to Validator status
Copyright
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.
Changelog
- 2025-01-21: Initial draft of the proposal
-
- Hi Amanda!
As someone before me already pointed out the long lockup coupled with pretty high locking prerequisite seems like it wont benefit good and reliable community validators, but instead just favour those that have ties to whales or people/projects with good connections within ecosystem (be it due to being apps, large validators/SVs, etc). I am pretty sure most people/CC holders will not risk or pool funds for a validator to get them online, there is only a few such occurences in a lot of protocols that we follow and support. In fact, in most protocols, most of the stake is bootstrapped by either investors or foundation, at least until they mature and projects like Lido for Ethereum come up. Community stake is usually much lower (check any chain you want, except Ethereum; even Solana has a lot of stake from foundation still and from large investors/whales).
I am pretty sure most of us community validators will only be able to be active if we put our own money in, and in that case we also run a high operational risk due to the long lockup of the funds.
I believe this should be better structured and thought out than it is now.
Have you considered Foundation front lining support for good community validators? Like we see in many other protocols, something like a Foundational delegation program. If so, happy to discuss and explore further (can be on Slack DM since we chatted there a few times already). Me and my team have experience with that and currently run the delegation program with Celestia, and we helped/worked on a few others as well. Hi All,
In coordination with Demo and the broader team, we have consolidated our feedback and identified several key areas for questions and refinement.
Like many of you, one way we participate in the network is as a Node-as-a-Service provider. Operating a diverse array of validators has given us a unique vantage point on scaling infrastructure alongside network growth. To ensure this proposal supports that long-term vision, we have outlined our key questions and feedback below:Early-Stage Validator Onboarding & Constraints
For newly onboarded validators who have not yet accumulated a significant token balance, the initial capital requirement under the sponsor model presents a barrier to entry. There are two potential solutions proposed to this instead:
-
Earned Token Locking: Could early-stage validators satisfy locking requirements by committing newly earned rewards in lieu of securing a third-party sponsor or purchasing a substantial CC position at genesis?
-
Phased Accumulation: If so, we could frame the expectation that only a percentage of initial rewards be locked immediately ensuring that validators be permitted to retain a percentage to offset operational costs until the minimum threshold is met. We suggest a tiered locking structure similar to the SV model to accommodate growth.
-
Participation Capital: Would the Foundation consider providing upfront liquidity, potentially via interest-free loans, to enable qualified validators to enter the active set and meet initial staking mandates? Once the validator meets the minimum requirements, the initial loan will be returned.This approach signals the Foundation’s commitment to investing in the very operators it approves to grow the network.
-
For all validators, even after the minimum 2M lock has been satisfied, will CC rewards be locked/”bonded” automatically? Or are they liquid when distributed?
Operator Communication & Transparency
Given the substantial engineering resources and operational effort invested by infrastructure providers, clear communication channels are vital.
-
Notification Mechanism: We recommend that the Foundation implement a notification system to alert operators when a customer’s validator approaches compliance or locking thresholds. Given the significant capital and operational resources required to establish and maintain these validators, such a system is essential for operators to mitigate risk and protect their long-term interests.
Slot Reversion & Succession Rights
-
Slot Continuity: In the event a validator fails to maintain compliance or meet threshold requirements, does the validator slot automatically revert to the original operator (provided that operator remains in good standing with the network)? Operators may then choose to reallocate that slot to another customer.
Thank you,
Jesse-
- Hi All,As both a node-as-a-service provider and a development partner within the ecosystem, we have had a number of conversations over the past week with current and prospective validators/builders on the proposed CIPs. We are aligned with the overall intention of this CIP in the sense that it creates an incentive to create/participate in Canton applications while simultaneously reducing the number of passive validators in the network by creating a barrier to entry.Given that liveness rewards will be eliminated as of April 30th, in theory the number of passive validators on the network should begin to decrease after that point as there would no longer be an incentive to run one based on the costs to self-host or pay an operator. However, we do see the value in creating an additional mechanism to ensure that validators continue to act in good faith to ensure the long-term success of the network.Building upon what others have previously suggested, could we consider a tiered approach in which validators would have to lock a percentage of the required CC based on how long they have had a validator active on mainnet before ultimately having to lock up the rest of the required amount?For example (timeframe and percentages TBD):
Live for 9 months or more: Lock 100% of the required CC upfront
Live for 3-6 months: Lock 50% upfront, 100% by the 9 month mark from date of onboarding
Live for 0-3 months: Lock 25% upfront, 50% by Month 6, 100% by Month 9
Net new post-CIP: Lock 10% upfront, 25% by Month 3, 50% by Month 6, 100% by Month 9This type of approach would create a barrier to entry for new validators to incentivize meaningful participation, reduce the number of passive validators by requiring locked CC, while still enabling a viable path for teams that have recently joined the ecosystem to deploy their applications and accrue enough CC to meet the requirements over the specified timeframes.Furthermore, similar to what others have voiced, we would be interested in learning more about a Foundation Delegation program moving forward and their role in potentially assisting good-faith validators to meet eligibility requirements.Look forward to discussing this more over the coming days.Best,ChrisChristopher Kelly
Head of Americas
IntellectEU
Where Innovation Meets Expertise
+1 (215) 962-3419
On Tue, Jan 27, 2026 at 6:10 PM Jesse Farese via lists.sync.global <jfarese=blockdaemon.com@...> wrote:Hi All,
In coordination with Demo and the broader team, we have consolidated our feedback and identified several key areas for questions and refinement.
Like many of you, one way we participate in the network is as a Node-as-a-Service provider. Operating a diverse array of validators has given us a unique vantage point on scaling infrastructure alongside network growth. To ensure this proposal supports that long-term vision, we have outlined our key questions and feedback below:Early-Stage Validator Onboarding & Constraints
For newly onboarded validators who have not yet accumulated a significant token balance, the initial capital requirement under the sponsor model presents a barrier to entry. There are two potential solutions proposed to this instead:
-
Earned Token Locking: Could early-stage validators satisfy locking requirements by committing newly earned rewards in lieu of securing a third-party sponsor or purchasing a substantial CC position at genesis?
-
Phased Accumulation: If so, we could frame the expectation that only a percentage of initial rewards be locked immediately ensuring that validators be permitted to retain a percentage to offset operational costs until the minimum threshold is met. We suggest a tiered locking structure similar to the SV model to accommodate growth.
-
Participation Capital: Would the Foundation consider providing upfront liquidity, potentially via interest-free loans, to enable qualified validators to enter the active set and meet initial staking mandates? Once the validator meets the minimum requirements, the initial loan will be returned.This approach signals the Foundation’s commitment to investing in the very operators it approves to grow the network.
-
For all validators, even after the minimum 2M lock has been satisfied, will CC rewards be locked/”bonded” automatically? Or are they liquid when distributed?
Operator Communication & Transparency
Given the substantial engineering resources and operational effort invested by infrastructure providers, clear communication channels are vital.
-
Notification Mechanism: We recommend that the Foundation implement a notification system to alert operators when a customer’s validator approaches compliance or locking thresholds. Given the significant capital and operational resources required to establish and maintain these validators, such a system is essential for operators to mitigate risk and protect their long-term interests.
Slot Reversion & Succession Rights
-
Slot Continuity: In the event a validator fails to maintain compliance or meet threshold requirements, does the validator slot automatically revert to the original operator (provided that operator remains in good standing with the network)? Operators may then choose to reallocate that slot to another customer.
Thank you,
Jesse
IMPORTANT! This message contains the confidential information intended for a specific individual and purpose and is protected by law. If you are not the intended recipient, you are instructed to delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited -
- Hi everyoneThank you very much for all the feedback on the Validator Staking proposal.While the SV and FA proposals have clear PROS and CONS, I feel this Validator proposal really only has clear CONS and I wish to withdraw this proposal.Appreciate all the thought and feedback that went into the responsesOn Tue, Jan 27, 2026 at 9:18 PM Chris Kelly via lists.sync.global <christopher.kelly=intellecteu.com@...> wrote:Hi All,As both a node-as-a-service provider and a development partner within the ecosystem, we have had a number of conversations over the past week with current and prospective validators/builders on the proposed CIPs. We are aligned with the overall intention of this CIP in the sense that it creates an incentive to create/participate in Canton applications while simultaneously reducing the number of passive validators in the network by creating a barrier to entry.Given that liveness rewards will be eliminated as of April 30th, in theory the number of passive validators on the network should begin to decrease after that point as there would no longer be an incentive to run one based on the costs to self-host or pay an operator. However, we do see the value in creating an additional mechanism to ensure that validators continue to act in good faith to ensure the long-term success of the network.Building upon what others have previously suggested, could we consider a tiered approach in which validators would have to lock a percentage of the required CC based on how long they have had a validator active on mainnet before ultimately having to lock up the rest of the required amount?For example (timeframe and percentages TBD):
Live for 9 months or more: Lock 100% of the required CC upfront
Live for 3-6 months: Lock 50% upfront, 100% by the 9 month mark from date of onboarding
Live for 0-3 months: Lock 25% upfront, 50% by Month 6, 100% by Month 9
Net new post-CIP: Lock 10% upfront, 25% by Month 3, 50% by Month 6, 100% by Month 9This type of approach would create a barrier to entry for new validators to incentivize meaningful participation, reduce the number of passive validators by requiring locked CC, while still enabling a viable path for teams that have recently joined the ecosystem to deploy their applications and accrue enough CC to meet the requirements over the specified timeframes.Furthermore, similar to what others have voiced, we would be interested in learning more about a Foundation Delegation program moving forward and their role in potentially assisting good-faith validators to meet eligibility requirements.Look forward to discussing this more over the coming days.Best,ChrisChristopher Kelly
Head of Americas
IntellectEU
Where Innovation Meets Expertise
+1 (215) 962-3419
On Tue, Jan 27, 2026 at 6:10 PM Jesse Farese via lists.sync.global <jfarese=blockdaemon.com@...> wrote:Hi All,
In coordination with Demo and the broader team, we have consolidated our feedback and identified several key areas for questions and refinement.
Like many of you, one way we participate in the network is as a Node-as-a-Service provider. Operating a diverse array of validators has given us a unique vantage point on scaling infrastructure alongside network growth. To ensure this proposal supports that long-term vision, we have outlined our key questions and feedback below:Early-Stage Validator Onboarding & Constraints
For newly onboarded validators who have not yet accumulated a significant token balance, the initial capital requirement under the sponsor model presents a barrier to entry. There are two potential solutions proposed to this instead:
-
Earned Token Locking: Could early-stage validators satisfy locking requirements by committing newly earned rewards in lieu of securing a third-party sponsor or purchasing a substantial CC position at genesis?
-
Phased Accumulation: If so, we could frame the expectation that only a percentage of initial rewards be locked immediately ensuring that validators be permitted to retain a percentage to offset operational costs until the minimum threshold is met. We suggest a tiered locking structure similar to the SV model to accommodate growth.
-
Participation Capital: Would the Foundation consider providing upfront liquidity, potentially via interest-free loans, to enable qualified validators to enter the active set and meet initial staking mandates? Once the validator meets the minimum requirements, the initial loan will be returned.This approach signals the Foundation’s commitment to investing in the very operators it approves to grow the network.
-
For all validators, even after the minimum 2M lock has been satisfied, will CC rewards be locked/”bonded” automatically? Or are they liquid when distributed?
Operator Communication & Transparency
Given the substantial engineering resources and operational effort invested by infrastructure providers, clear communication channels are vital.
-
Notification Mechanism: We recommend that the Foundation implement a notification system to alert operators when a customer’s validator approaches compliance or locking thresholds. Given the significant capital and operational resources required to establish and maintain these validators, such a system is essential for operators to mitigate risk and protect their long-term interests.
Slot Reversion & Succession Rights
-
Slot Continuity: In the event a validator fails to maintain compliance or meet threshold requirements, does the validator slot automatically revert to the original operator (provided that operator remains in good standing with the network)? Operators may then choose to reallocate that slot to another customer.
Thank you,
Jesse
IMPORTANT! This message contains the confidential information intended for a specific individual and purpose and is protected by law. If you are not the intended recipient, you are instructed to delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited
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. -
