[Proposal Idea] Update to the Association Delegation Policy

Proposal Discussion Proposal Ideas
1

Summary

This proposal introduces:

  • A rank-stable delegation allocation method
  • A deterministic, multi-stage overflow handling mechanism
  • An additional Testnet participation requirement
  • The removal of non-algorithmic (off-chain) eligibility criteria
  • A rank-aware undelegation recommendation

The goal is to ensure that delegation at the current treasury scale remains aligned with decentralization objectives while improving the objectivity and enforceability of validator eligibility.

This proposal is operational in nature and does not impact delegators directly.

Motivation

CVV002 was designed under a significantly smaller delegation base. With a substantially larger treasury stake:

  • A limited eligible validator set (e.g. ~36 validators after entity filtering) leads to very large per-validator allocations
  • Fixed-percentage allocation can distort validator rankings
  • Validators selected for decentralization support may be pushed into top ranks, defeating the policy’s intent

Additionally:

  • Some eligibility criteria currently rely on manual/off-chain verification, which is not scalable or objective
  • There is currently no enforced linkage between Mainnet and Testnet participation, limiting Testnet robustness

This proposal addresses both the allocation logic and eligibility framework.

Specification

Definitions

  • Let S10 be the total stake of the validator ranked #10 at the start of the allocation round
  • Let Target Stake (T) be defined as:

T = 0.9 × S10

  • “Eligible validators” refers to validators satisfying all CVV002 criteria, as modified by this proposal
  • The initial calculation of ranks and total stakes will be done omitting the association-delegated stake on all nodes.

Part A — Delegation Allocation

Step 1: Rank-Stable Gap Allocation (Entity-Filtered Set)

  • Apply existing eligibility rules, including entity-based filtering (one validator per entity)
  • For each entity, select the lowest-ranked validator node (by total stake) for inclusion in this step
  • Consider eligible validators ranked below the top 10 (rank #11 and lower)
  • Starting from the lowest-ranked validator and moving upward:
    • Allocate delegation only up to the amount required to reach Target Stake (T)

Continue until:

  • All such validators reach T, or
  • The available delegation pool is exhausted

Outcome:

  • Delegation does not elevate validators into the top-10 boundary
  • Entity-level decentralization is preserved
  • Allocation prioritizes weaker (lower-ranked) nodes within each entity

Step 2: Extended Gap Allocation (Entity Filter Lifted)

If excess delegation remains after Step 1:

  • Lift the entity-based filtering constraint
  • Allow multiple validators per entity
  • Recompute the eligible set

Apply the same logic:

  • Consider validators ranked below the top 10
  • Allocate only up to the amount required to reach Target Stake (T)

Outcome:

  • Additional allocation capacity
  • Rank stability preserved

Step 3: Overflow Distribution (Extended Eligible Set)

If excess delegation still remains after Step 2:

  • Expand the eligible set to include validators that satisfy all criteria except current top-10 exclusion
  • Distribute the remaining delegation equally per validator

Outcome:

  • Preserves relative ordering
  • Avoids material ranking distortion
  • Provides a simple, deterministic fallback

Part B — Eligibility Updates

1. Testnet Participation Requirement

All eligible Mainnet validators must:

  • Operate a Testnet validator node for each Mainnet validator node
  • Ensure the Testnet node is:
    • Paired via Casper Account Info Contract on Testnet
    • Achieving ≥ 99% monthly performance

Activation:

  • Effective starting July 01 (next stake distribution term)

Rationale:

  • Strengthens Testnet reliability
  • Ensures validators support network readiness and upgrades
  • Creates a measurable, on-chain verifiable participation signal

2. Removal of Off-Chain Eligibility Criteria

The following class of criteria is removed:

  • Any requirement relying on manual or off-chain verification, including:
    • Forum participation checks
    • Manual identity or activity validation by the Association

Rationale:

  • Improves objectivity and transparency
  • Eliminates operational bottlenecks
  • Ensures eligibility is fully algorithmic

Future Work:

  • These criteria may be reintroduced once trustless or algorithmic verification becomes available

Part C — Undelegation Recommendation

When undelegation of tokens is required, the Association is recommended to:

  • Prioritize undelegation from higher-ranking validators (by total stake weight) first
  • Ensure that any undelegation operation does not alter the relative ranking of validators

Rationale:

  • Maintains rank stability during both delegation and undelegation flows
  • Avoids unintended promotion or demotion of validators
  • Preserves the integrity of the allocation policy over time

Properties

This proposal ensures:

  • Rank stability: No promotion into top-10 positions due to delegation or undelegation
  • Decentralization alignment: Focus on sub-top-10 validators
  • Deterministic allocation: No discretionary decisions
  • Scalability: Suitable for large treasury delegation sizes
  • Objective eligibility: Fully algorithmic criteria
  • Testnet strengthening: Incentive alignment across networks

Backward Compatibility

  • Modifies CVV002 allocation logic
  • Removes certain eligibility criteria
  • Adds new Testnet requirement (delayed activation: July 01)
  • Introduces undelegation recommendation
  • Does not impact delegators

Implementation Notes

  • S10 must be measured at the start of each allocation round.
  • Allocation must use pre-delegation stake values.
  • Step 1 must select the lowest-ranked node per entity under entity filtering.
  • Step 2 requires temporarily lifting entity constraints during allocation only.
  • Testnet performance must be measured over monthly windows.
  • Pairing via Account Info Contract must be verifiable on-chain.
  • Undelegation operations should simulate post-action rankings to ensure no ordering violations.
  • The Association may, on an exceptional basis, exclude or suspend validators from consideration where required to address legal, regulatory, or contractual risk.

Conclusion

This proposal updates both delegation distribution and eligibility evaluation to ensure:

  • Delegation remains aligned with decentralization goals at scale
  • Allocation remains stable under large treasury participation
  • Validator requirements are objective and enforceable
  • Testnet participation is strengthened ahead of future upgrades
  • Undelegation behavior remains consistent with rank stability principles

Timeline

This is expected to be a fast-paced discussion and voting process to be able to provide the association with an updated policy before the start of the next quarter (April 01), which is the usual (re)delegation time.

Feedback is welcome.
Given the operational urgency, the goal is to finalize and implement this proposal promptly.

[CVV009] Update to the Association Delegation Policy
2

  1. Testnet participation requirement: since its a lottery based selection does this mean validators will run testnet nodes without getting rewarded for it? What happens if majority of the validators decides not to run testnet nodes(no eligible validators no stake)?

  2. Step 1 selects “the lowest-ranked validator per entity.” When Step 2 lifts entity filtering, it says “allow multiple validators per entity” — but which validator per entity gets priority? If Entity A has validators at ranks #15 and #22, and #15 was already filled to T in Step 1, does Step 2 re-allocate to #22 starting from zero, or skip it? The proposal doesn’t clarify.

  3. Step 2 encourages running multiple nodes which is quite the opposite of decentralization. I highly recommend to not lift the entity-based filtering or combining the multiple identical nodes into a single one and re-arrenging the list might be more suitable.

1 Like
3

Thank you for this proposal and for the effort put into it. While I share the goal of strengthening decentralization, the current approach seems difficult to apply. I believe we can simplify this framework to make it more inclusive and beneficial for a larger number of validators.

Here is why some parts of the proposal do not seem consistent to me:

  • The ‘Testnet Lottery’ Paradox: The proposal requires a 1:1 ratio (one Testnet node for each Mainnet node). However, since Testnet seats were reduced from 100 to 50, it is mathematically inconsistent to make this a strict requirement. A loyal, high-performing validator could be excluded simply because they didn’t “win” a Testnet slot in the lottery.

  • Top 10 Merit: Top 10 validators are active and essential to the network. They are deserving and also need these delegations to continue reinforcing their infrastructure. Excluding them automatically penalizes their commitment.

  • The Risk of Invisible Technical Centralization: The concentration of nodes within the same hosting providers is a major risk. Reducing the number of delegation beneficiaries does not help decentralization. We must give validators the financial means to diversify their infrastructure.

My proposal for a delegation policy that supports network sustainability:

  • One Delegation per Validator (Entity): To ensure fairness, delegation should target the entity (the validator). A validator with multiple nodes should only receive delegation on one of their nodes. This prevents further concentration and leaves room for others. (Let’s see if it’s possible with the current situation)

  • More Beneficiaries, Balanced Allocations: Instead of giving large amounts to only 30 nodes, it is better to open more slots. By distributing smaller amounts to a larger number of validators, we support more of the community and avoid pushing nodes into the Top 10 too quickly, which preserves natural ranking stability.

  • Delegation as a Driver for Viability: Server costs are real, and current rewards are often not enough. Delegation is a unique opportunity to provide extra income to fund a backup node (highly recommended) or to help with geographic decentralization.

My proposed criteria:

  • Seniority and Loyalty: Value presence on the network for 6 months. This is the best proof of commitment and reliability.

  • Testnet as a Bonus: The Testnet should not be a barrier to entry, but a bonus for seriousness. For example, active Testnet participation could unlock a priority delegation on a seconde node or help a new validator without seniority prove their technical skill.

  • Smoothed Performance: Keep a high performance requirement (>98%), but include a “force majeure” clause (proven provider outage, cut cables, etc.) to avoid unfairly punishing a validator for events beyond their control.

  • Technical Flexibility: One high-performing Testnet node should be enough to prove technical competence for all of a validator’s Mainnet nodes.

The priority is to stop the monthly decline in validator numbers. We recently voted for a minimum fee rate that is not yet applied; once active, this rate combined with an inclusive delegation policy will be a powerful tool to attract new participants. By being serious and opening a node, new validators will be sure to break even on their costs in the medium term. This will foster real decentralization across the entire blockchain, instead of staying with only 70 nodes where some validators own multiple nodes. This is a win-win solution to stabilize and grow the Casper ecosystem.

1 Like
4

Thanks a lot for the feedback and the questions. :folded_hands:

  • Testnet participation requirement: since its a lottery based selection does this mean validators will run testnet nodes without getting rewarded for it? What happens if majority of the validators decides not to run testnet nodes(no eligible validators no stake)?

Testnet is also permissionless, just like Mainnet, and there are ~50 empty slots in the Testnet validator set at the moment. There is no need to apply for any lotteries, and anyone can join Testnet as a validator any time they like, by setting up their node, getting fee Testnet tokens from the Testnet, and adding a bid. In parallel, anyone is also free to apply for the Testnet incentives as well although it’s not part of this requirement.

Less eligible nodes means more stake per node, but the aim and expectation is to have many eligible nodes as the possible gain seems higher than the cost.

  • Step 1 selects “the lowest-ranked validator per entity.” When Step 2 lifts entity filtering, it says “allow multiple validators per entity” — but which validator per entity gets priority? If Entity A has validators at ranks #15 and #22, and #15 was already filled to T in Step 1, does Step 2 re-allocate to #22 starting from zero, or skip it? The proposal doesn’t clarify.

The proposal clarifies that the node with the lower stake will be chosen for step 1. So for an entity with nodes ranking #15 and #22, the #22 would be filled at step 1, and the #15 would be filled at step 2 (if step 2 needs to happen at all). Good catch. I’ll try to further clarify this point on the proposal.

  • Step 2 encourages running multiple nodes which is quite the opposite of decentralization. I highly recommend to not lift the entity-based filtering or combining the multiple identical nodes into a single one and re-arrenging the list might be more suitable.

Very good/valid point/concern. We are aware that it’s a trade-off, but please note that it is just a fall-back/backup option, not the primary approach. And even when run by the same entity, more than one node means more decentralization (by geography or by machine etc, possibly improving fault-tolerance/resilience). Nonetheless, the predicted/expected behavior is more entities running nodes, so no need for step 2 after some point in the future.

5

Thanks a lot for the feedback. :folded_hands:

  • The ‘Testnet Lottery’ Paradox: The proposal requires a 1:1 ratio (one Testnet node for each Mainnet node). However, since Testnet seats were reduced from 100 to 50, it is mathematically inconsistent to make this a strict requirement. A loyal, high-performing validator could be excluded simply because they didn’t “win” a Testnet slot in the lottery.

This looks like a misconception/confusion. I believe we have clarified above, and also on Telegram, that there are ~50 free validator slots on Testnet at the moment, and any Mainnet validator can start their Testnet node and join the Testnet validator set any time they like.

  • Top 10 Merit: Top 10 validators are active and essential to the network. They are deserving and also need these delegations to continue reinforcing their infrastructure. Excluding them automatically penalizes their commitment.

The proposal does not bring any such restriction. On the contrary, it relaxes the restriction in effect which was accepted via CVV002, and includes top-10 validators in step 3.

  • The Risk of Invisible Technical Centralization: The concentration of nodes within the same hosting providers is a major risk. Reducing the number of delegation beneficiaries does not help decentralization. We must give validators the financial means to diversify their infrastructure.

Good point, and totally agreed. However, seems tangential to the current proposal.

  • One Delegation per Validator (Entity): To ensure fairness, delegation should target the entity (the validator). A validator with multiple nodes should only receive delegation on one of their nodes. This prevents further concentration and leaves room for others. (Let’s see if it’s possible with the current situation)

This is already the default behavior, which ensures there is room for other/new nodes always before falling back to the contingency step of including multiple nodes per entity. We’re going to clarify that on the proposal to make sure there is no ambiguity. Thanks for raising. :folded_hands:

  • More Beneficiaries, Balanced Allocations: Instead of giving large amounts to only 30 nodes, it is better to open more slots. By distributing smaller amounts to a larger number of validators, we support more of the community and avoid pushing nodes into the Top 10 too quickly, which preserves natural ranking stability.

This looks like a misconception/confusion. The previous policy (in effect) had limited slots, and was staking large amounts to a small number of nodes. The current/new proposal already removes the limitation, and ensures rank stability through gap-filling. In fact, this concern of yours was the main reason of drafting this new proposal. Good to see that others had the same concern. Thanks for the reiteration. :folded_hands:

  • Delegation as a Driver for Viability: Server costs are real, and current rewards are often not enough. Delegation is a unique opportunity to provide extra income to fund a backup node (highly recommended) or to help with geographic decentralization.

Although the main objective of the current and the new/proposed policy is decentralization, this is a good side effect of it. On top of that, it supports and requires having a Test node which is also recommended for any real world software/system. So, agreed.

  • Seniority and Loyalty: Value presence on the network for 6 months. This is the best proof of commitment and reliability.

This is already part of the current policy in effect (with a 3-month history), which is untouched/inherited by the new policy. If we establish consensus among the validators to increase it to 6 months, we can do it as well.

  • Testnet as a Bonus: The Testnet should not be a barrier to entry, but a bonus for seriousness. For example, active Testnet participation could unlock a priority delegation on a seconde node or help a new validator without seniority prove their technical skill.

As established above and on the previous message, it’s not a barrier to entry. It’s a very easy, cheap, quick, and permissionless process.

  • Smoothed Performance: Keep a high performance requirement (>98%), but include a “force majeure” clause (proven provider outage, cut cables, etc.) to avoid unfairly punishing a validator for events beyond their control.

Makes total sense. Thanks for the suggestion. :folded_hands:

  • Technical Flexibility: One high-performing Testnet node should be enough to prove technical competence for all of a validator’s Mainnet nodes.

Completely agree, but the main purpose of the Testnet node requirement is not to measure competence. And having a 1-to-1 matching between Mainnet and Testnet makes it much simpler to understand and implement.

The priority is to stop the monthly decline in validator numbers. We recently voted for a minimum fee rate that is not yet applied; once active, this rate combined with an inclusive delegation policy will be a powerful tool to attract new participants. By being serious and opening a node, new validators will be sure to break even on their costs in the medium term. This will foster real decentralization across the entire blockchain, instead of staying with only 70 nodes where some validators own multiple nodes. This is a win-win solution to stabilize and grow the Casper ecosystem.

I disagree with the monthly decline claim. Moreover, the current validator count is 74, not 70, and will likely increase a bit more once the last few validators who missed the recent upgrade come back online. Otherwise, we are aligned in terms of the rest of the goals. Thanks for reiterating. :folded_hands: