Proposal: Values for CSM v2 parameters
Incredible CSM v2 features were recently introduced to the community. Today, I want to suggest and bring to public discussion possible approaches and values for different parameters affecting the module and CSM Operators (both Permissionless and Identified Community Stakers)
The gist of the suggested approach is:
- Provide more beneficial values for Identified Community Stakers, given a lower level of risk and intention to incentivize the growth of the staking community. In particular, suggesting a priority queue for the first 10 validators, ensuring a sufficient starting level for any actor considering joining CSM.
- Provide a reasonable level of validator performance risk mitigation for the protocol and stakers, assuming up to a 10% level of CSM share.
- Limiting the possible effect on protocol APR by 0.2% (ex., 3%->2.99% APR) with PerformanceLeeway for a rare but not entirely impossible case of underperformance on a massive scale;
- Limiting the possible effect on protocol APR by 3.25% (ex., 3% → 2.9% APR) with the Bad Performance Strikes system for the case of an intentional malicious attack on the protocol, capturing a significant size of CSM;
While still keeping the performance requirements at a level achievable by anyone willing to participate, with the share of validators getting strikes based on being from 5% (for Identified Community Stakers) to 10% (for Permissionless Stakers). As per the suggestion, it’s still required to get a minimum of three strikes for one validator for ejection, which seems like a reasonable indication and timeframe for Node Operators to identify and fix any potential issues
- Create a disincentivization for malicious or operational errors that affect the protocol, while keeping penalties material but still reasonable and completely avoidable for Node Operators willing to comply with protocol rules.
| Parameter | Short description | Permissionless participants | Identified Community Stakers |
|---|---|---|---|
| PerformanceCoefficients | Coefficients used to calculate the Node Operator’s performance based on the validators’ effectiveness in performing duties, namely: attestation, proposing blocks, and sync committee participation | C_{a} = \frac{54}{64}, C_{b} = \frac{8}{64}, C_{s}= \frac{2}{64} | C_{a} = \frac{54}{60}, C_{b} = \frac{4}{60}, C_{s}= \frac{2}{60} |
| PerformanceLeeway | Difference in performance with the average network leading to a bad performance strike for the validator | 3% | 5% for the first 150 validators, 3% for the rest |
| StrikesLifetime | Number of the Performance Oracle frames during which the accumulated number of strikes is calculated | 6 Oracle fames | 6 Oracle fames |
| StrikesThreshold | A number of strikes required for the permissionless validator ejection | 3 | 4 |
| BadPerformancePenatly | A penalty for the validator that was ejected due to strikes accumulated for bad performance | 0.258 ETH | 0.172 ETH |
| ElRewardsStealingFine | Additional penalty for the confirmed and settled EL stealing incident | 0.1 ETH | 0.05 ETH |
| AllowedExitDelay | Allowed time to exit a validator after being requested by VEBO | 4 days | 5 days |
| ExitDelayPenalty | Penalty for not exiting a validator after requested by VEBO | 0.1 ETH | 0.05 ETH |
| KeyRemovalCharge | A charge to prevent “queue stuffing” with keys people never intend to use | 0.02 ETH | 0.01 ETH |
| PriorityQueueMaxDeposits | Priority in deposits for a limited number of validators | - | 10 keys |
| QueuePriority | Index of the priority queue | 5 (lowest priority) | 0 (top priority) |
| MaxWithdrawalRequestFee | A limit on the TW fee compensation | 0.1 ETH | 0.1 ETH |
The detailed approach and values are available here