Community Staking Module

Proposals
208

IDVTC additional params

The original IDVTC forum post and Snapshot vote cover 4 parameters for the proposed IDVTC type. Namely:

  • RewardShare - 3.5% for the first 64 keys, and 2% for the remaining keys.
  • Bond - 1.5 ETH for the first key, and 0.5 ETH for the remaining keys.
  • PriorityQueue - 40 priority seats with priority lower than ICS but above the default one.
  • Strikes - Threshold 2, Lifetime 4 frames.

However, we still need to define more parameters. Below are the proposed parameters.

  • keyRemovalCharge = 0.01 ETH. Same as for ICS.
  • generalDelayedPenaltyAdditionalFine = 0.05 ETH. Same as for ICS.
  • keysLimit = Unlimited. Same as for ICS and Default type.
  • allowedExitDelay = 5 days. Same as for ICS.
  • exitDelayFee = 0.05 ETH. Same as for ICS.
  • maxElWithdrawalRequestFee = 0.1 ETH. Same as for ICS and Default type.
  • avgPerfLeewayBP = 300. Same as for the Default type.
  • attestationsWeight = 54. Same as for the Default type.
  • blocksWeight = 8. Same as for the Default type.
  • syncWeight = 2. Same as for the Default type.

Additionally, it is proposed to change the Strikes params to Threshold 3, Lifetime 6 frames, same as for the Default type. Also, it is proposed to set badPerformancePenalty = 0.258 ETH, same as for the Default type.

The main motivation for changing these parameters is to avoid the situation where, after receiving 1 strike, the rational operator should exit the validators to avoid the badPerformancePenalty. Since 1 strike can result from an MEV relay issue that causes 1 missed block proposal, the 2-strikes threshold puts Node Operators in an uncomfortable position.

The initial reasoning behind choosing a threshold of 2 strikes was to ensure that, in the worst-case scenario (offline till the threshold and slashing after that), the bond is sufficient to cover penalties.

From a protocol security perspective, we can assume that IDVTC Node Operators will not attack the protocol by keeping their validators offline for the full 3 frames, then slashing them right after. Hence, the biggest expected penalty in case of 3 offline months is 0.428 ETH, which is below the bond of 0.5 ETH.

4 Likes
209

Staking Module Share Limit ET Params

As part of the upcoming CSMv3 release, a new EasyTrack (ET) factory UpdateStakingModuleShareLimits.sol will be added. This factory will facilitate management of the stakeShareLimit and priorityExitThreshold parameters for CSM by allowing a dedicated committee (CSMC) to propose minor changes to stakeShareLimit and priorityExitThreshold via ET motions within a predefined limit.

It is proposed to set the following values for the limits in UpdateStakingModuleShareLimits.sol:

  • maxStakeShareLimitIncrease = 500 BP
  • maxStakeShareLimitDecrease = 500 BP
  • maxPriorityExitShareThresholdIncrease = 600 BP
  • maxPriorityExitShareThresholdDecrease = 600 BP

These values ensure that a single ET motion cannot change the module’s stakeShareLimit by more than 0.5% in either direction (increase or decrease). The priorityExitThreshold is typically set to stakeShareLimit * 1.2 to ensure a buffer against protocol TVL fluctuations. Hence, the proposed limits for priorityExitThreshold are 20% wider than those for stakeShareLimit.

4 Likes
210

In light of the upcoming Staking Router v3 (SRv3) and Community Staking Module v3 (CSMv3) releases, a few Easy Track (ET) factories should be updated and created. Below is a short description of each.

New ET factories

ReportWithdrawalsForSlashedValidators.sol

In previous versions of CSM, slashing penalties were calculated automatically as the difference between the slashed validator’s withdrawal balance and 32 ETH. With the introduction of 0x02 validators with variable balances ranging from 32 to 2048 ETH, this approach is no longer applicable. Additionally, the previous approach was unable to account for rewards missed during the slashing period. Hence, an ET factory is introduced to produce motions that deliver precise information on total slashing penalties. Corresponding flow is described in the LIP-33.

This factory will be used for both CSMv3 and CMv2.

SetMerkleGateTree.sol

This factory is a generalized version of the existing CSMSetVettedGateTree.sol. This factory produces motions that update the list of addresses allowed to pass through the gate (create a Node Operator). While the original factory was able to serve a single gate, the updated version allows for a single factory to serve multiple gates in the scope of a single module, and supports both VettedGate.sol for CSM and CuratedGate.sol for CMv2.

This factory will be used for both CSMv3 and CMv2.

SettleGeneralDelayedPenalty.sol

This factory is an updated version of the existing CSMSettleELStealingPenalty.sol. The factory produces motions that settle (confirm) a penalty that was previously reported by the module committee. Settling means that the locked bond (as a result of the report) is burned. The updated version now supports both CSM and CMv2, and the updated interface for the GeneralDelayedPenalty.

This factory will be used for both CSMv3 and CMv2.

UpdateStakingModuleShareLimits.sol

Lido contributors use a staged approach to rollouts and further expansion of the essential parts of the protocol. While the Curated module has always been a core part of the Lido protocol and will be replaced entirely by CMv2, modules like CSM require frequent, gradual changes to stakeShareLimit and priorityExitShareThreshold. This factory is designed to facilitate the process. A detailed description of the factory can be found in the SRv3 spec.

This factory will be used for CSMv3. There are no plans to use this factory for CMv2 at this time.

Updated stakeShareLimit boundary for CSM

With the introduction of a dedicated ET factory to manage stakeShareLimits for CSM, it’s proposed to set the new upper bound for the existing CSM instance’s stakeShareLimit of 15% of the Lido protocol TVL. This limit will not be enforced on-chain. Instead, the CSMC will be responsible for ensuring that the CSM’s stakeShareLimit, as managed via Easy Track, does not exceed the agreed threshold, if approved.