Following the post above I want to share the list of the CSM parameters used for testnet contracts deployment. Deployment artifacts can be found in CSM GH repo.
Note that deploying the contracts does not mean that the testnet is active now. Actual activation will be performed in the same way as for the mainnet over the corresponding on-chain vote.
CSM parameters for the testnet
The doc aims to provide values for all configurable and constant CSM parameters and motivations for why they are proposed to be so.
Constants
DEPOSIT_SIZE
uint256 private constant DEPOSIT_SIZE = 32 ether;
Proposed value = 32 ETH
This constant represents the deposit size to activate a validator on the Beacon chain. Until EIP-7251 is implemented, 32 ETH will be the only possible value. Given that CSM would require an upgrade to smart contracts after EIP-7251, it is proposed to have a constant value of 32 ETH for the first version of CSM.
BEACON_ROOTS
address public constant BEACON_ROOTS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02;
Proposed value = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02
This constant represents the address of the EIP-4788 contract. The address is taken from the official EIP docs.
DEFAULT_BOND_CURVE_ID
uint256 public constant DEFAULT_BOND_CURVE_ID = 0;
Proposed value = 0
The first curve added to the CSAccounting.sol is used as a default curve for the CSM Node Operators. The initialize function of the CSAccounting.sol contract checks that the curve passed has ID=0 after addition (the curve added in the initialize function call is the first curve added).
Immutable variables
INITIAL_SLASHING_PENALTY
uint256 public immutable INITIAL_SLASHING_PENALTY;
Proposed value = 1 ETH
This immutable variable is used by CSM to penalize the Node Operator’s bond in case of validator slashing. Until EIP-7251 is implemented, 1 ETH will be the maximal possible value (given the effective balance is 32 ETH). Given that CSM would require an upgrade to smart contracts after EIP-7251, it is proposed to have an immutable value of 1 ETH for the first version of CSM.
Note: This immutable variable is set indirectly by setting minSlashingPenaltyQuotient = 32.
elRewardsStealingFine
uint256 public immutable EL_REWARDS_STEALING_FINE;
Proposed value = 0.1 ETH
This immutable variable is used by CSM to add an additional fine to the MEV stealing penalty in case the Node Operator has committed EL rewards (MEV) stealing.
It is proposed to set a 0.1 ETH value for this immutable variable since this creates a disincentivisation to commit MEV stealing and compensate it “free of charge”. Several actions are required from the DAO side in case of MEV stealing:
- Detect the fact of stealing;
- Report the fact of stealing to lock bond funds;
- Confirm the fact of stealing using Easy Track motion.
All these actions require effort and gas to perform; hence, the additional fine of 0.1 ETH seems reasonable.
maxKeysPerOperatorEA
uint256 public immutable MAX_SIGNING_KEYS_PER_OPERATOR_BEFORE_PUBLIC_RELEASE;
Proposed value = 10
This immutable variable is used by CSM to determine a maximal number of the validators operated by a single Node Operator in CSM during the Early Adoption period.
It is proposed to set a value of 10 for this immutable variable due to the following reasons:
- The Early Adoption period is aimed at attracting solo-stakers who typically operate no more than 10 validators due to hardware and financial limitations;
- Running 10 validators with CSM will be sufficient to cover operational costs with excess;
- Limit of 10 validators ensures that professional Node Operators will not be able to flood the module;
- Once the Early Adoption period ends, this limit will be removed.
maxCurveLength
uint256 internal immutable MAX_CURVE_LENGTH;
Proposed value = 10
This immutable variable is used by the CSM Accounting contract to determine a maximal number of validators starting from the very first one to have a custom bond requirements.
Given the focus of CSM on the Community Stakers and security considerations regarding MEV stealing protection, it is assumed that having a differing value for the bond of the 10th and further validators for CSM Node Operators makes no meaningful sense. Hence, it is proposed to allow custom bond values for the first 10 validators controlled by the CSM Node Operators while keeping the bond requirement constant for the rest of the validators.
minBondLockRetentionPeriod
uint256 public immutable MIN_BOND_LOCK_RETENTION_PERIOD;
Proposed value = 0
This immutable variable is used by the CSM Accounting contract to determine a minimal value for the configurable bondLockRetentionPeriod parameter, which determines the time for which bond funds will be locked, given no further actions.
bondLockRetentionPeriod is introduced to ensure that locked bond funds will be unlocked automatically once the bondLockRetentionPeriod ends. Unlike the mainnet, it is proposed to have more flexibility on the testnet, so 0 minimal value allows to test bond lock retention in a reasonable time.
maxBondLockRetentionPeriod
uint256 public immutable MAX_BOND_LOCK_RETENTION_PERIOD;
Proposed value = 365 days
This immutable variable is used by the CSM Accounting contract to determine a maximal value for the configurable bondLockRetentionPeriod parameter, which determines the time for which bond funds will be locked, given no further actions.
bondLockRetentionPeriod is introduced to ensure that locked bond funds will be unlocked automatically once the period ends. To provide a feasible unlock time without actions from the Lido DAO side, it is proposed to set the upper boundary for the period to 1 year (or 365 days).
earlyAdoptionTreeRoot
bytes32 public immutable TREE_ROOT;
Proposed value = 0xc9a9c1576cf4f3213ad9075b72a1f1b147914a252ad927fa4ca3460ff0723ca9
This variable is used by the CSM Early Adoption contract to determine the root of the Early Adoption eligible participants. The source tree can be found here.
Storage variables
keyRemovalCharge
uint256 public keyRemovalCharge;
Proposed value = 0.05 ETH
This variable is used by CSM to determine the amount of ETH to be confiscated from the Node Operator’s bond in case deposit data is deleted. Due to CSM’s optimistic FIFO stake allocation queue, deletion of deposit data might require a call to the cleanDepositQueue method to ensure proper queue operation.
According to the approximate gas estimations, a call of the csm.cleanDepositQueue(150) (clean the next 150 queue items) with 1 invalid batch in the queue costs around 1,000,000 gas. With a gas cost of 50 gwei (extreme value), the call will cost ~ 0.05 ETH.
Note: keyRemovalCharge value is configurable after deployment; hence, it can be set to a different value later (can even be 0)
bondLockRetentionPeriod
uint256 bondLockRetentionPeriod;
Proposed value = 8 weeks
This variable is used by the CSM Accounting contract to determine the time for which bond funds will be locked, given no further actions.
Given the limitations above, it is proposed that the actual value for the bondLockRetentionPeriod be set at 8 weeks. This will give enough time for the Lido DAO to act in case of MEV stealing detection and ensure no excessive lock time in case no actions are taken by the Lido DAO.
setResetBondCurveAddress
Proposed value = 0xc4DAB3a3ef68C6DFd8614a870D64D475bA44F164 (Dev team EOA)
This address will be granted with two roles: SET_BOND_CURVE_ROLE and RESET_BOND_CURVE_ROLE.
With these roles, the address will be able to set and reset the bond curve for the particular Node Operator.
chargeRecipient
address public chargeRecipient;
Proposed value = 0xE92329EC7ddB11D25e25b3c21eeBf11f15eB325d (Lido DAO Treasury contract)
This variable is used by the CSM Accounting contract to determine the recipient of the charge type penalty. A penalty that is not burned but confiscated with the following transfer.
Given that all operational costs for the Lido On Ethereum protocol are covered by the Lido DAO Treasury, it is proposed to transfer funds confiscated from the Node Operator’s bond to the Lido DAO Treasury.
bondCurve
Proposed value = [2 ether, 3.9 ether, 5.7 ether, 7.4 ether, 9 ether, 10.5 ether]
Validator 1 - 2 ETH
Validator 2 - 1.9 ETH
Validator 3 - 1.8 ETH
Validator 4 - 1.7 ETH
Validator 5 - 1.6 ETH
Validator >= 6 - 1.5 ETH
This variable is used by the CSM Accounting contract to determine the default bond requirements for the CSM Node Operators.
Corresponding research concerning the bond size can be found here.
earlyAdoptionBondCurve
Proposed value = [1.5 ether, 3.4 ether, 5.2 ether, 6.9 ether, 8.5 ether, 10 ether]
Validator 1 - 1.5 ETH
Validator 2 - 1.9 ETH
Validator 3 - 1.8 ETH
Validator 4 - 1.7 ETH
Validator 5 - 1.6 ETH
Validator >= 6 - 1.5 ETH
This variable is used by the CSM Accounting contract to determine the bond requirements for the Early Adoption participants.
Corresponding research concerning the bond size can be found here.
The Early Adoption benefits approach is described here.
elRewardsStealingReporter
Proposed value = 0xc4DAB3a3ef68C6DFd8614a870D64D475bA44F164 (Dev team EOA)
This address will be granted with the role: REPORT_EL_REWARDS_STEALING_PENALTY_ROLE.
With this role, the address will be able to report the facts of MEV or EL rewards stealing by CSM Node Operators to lock a bond amount equal to stolen ETH. Penalty application is performed by easyTrackEVMScriptExecutor granted with the SETTLE_EL_REWARDS_STEALING_PENALTY_ROLE role.
CSM Oracle
avgPerfLeewayBP
uint256 public avgPerfLeewayBP;
Proposed value = 500 BP
This variable is used by the CSM FeeOracle contract to determine the difference between average network validator performance and CSM validator performance that is treated as “good performance”. The actual formula is performanceThreshold = avgPerformance - avgPerfLeewayBP.
It is proposed to set the avgPerfLeewayBP to 500 BP (5%) to provide meaningful leeway for the community validator’s performance while keeping the threshold high enough to maintain compatible APR for the stETH holders.
oracleReportEpochsPerFrame
Proposed value = 225 * 7
This variable indicates the length of the CSM Performance Oracle frame. It is proposed that it be set at 7 days to ensure a meaningful number of the test cycles for CSM Performance Oracle.
oracleMembers
Proposed value = current Lido Oracle members
0xF0F23944EfC5A63c53632C571E7377b85d5E6B6f [Chorus One]
0xb29dD2f6672C0DFF2d2f173087739A42877A5172 [Staking Facilities]
0x31fa51343297FFce0CC1E67a50B2D3428057D1b1 [p2p]
0xD3b1e36A372Ca250eefF61f90E833Ca070559970 [Stakefish]
0x3799bDA7B884D33F79CEC926af21160dc47fbe05 [Rated]
0x4c75FA734a39f3a21C57e583c1c29942F021C6B7 [bloXroute]
0x81E411f1BFDa43493D7994F82fb61A415F6b8Fd4 [Instadapp]
0xf7aE520e99ed3C41180B5E12681d31Aa7302E4e5 [Chainlayer]
0x12A1D74F8697b9f4F1eEBb0a9d0FB6a751366399 [Lido]
0xD892c09b556b547c80B7d8c8cB8d75bf541B2284 [Lido]
Given that CSM Oracle has a form of the common Lido Oracle module, it is reasonable to ask existing Lido Oracle members to run CSM Oracle instances.
NOTE: The initial set of Oracle members will be different to allow for smooth migration of the existing Oracle members to a new version of the software.
hashConsensusQuorum
Proposed value = 6
Given that CSM Oracle will have the same members as the common Lido Oracle, it is reasonable to use the same value for the quorum = 6.
NOTE: The initial quorum will be different to allow for smooth migration of the existing Oracle members to a new version of the software.
fastLaneLengthSlots
Proposed value = 0
Calculation of the CSM Oracle report takes significantly more time than for the common Lido Oracles (AO, VEBO). Also, the report frame for the CSM Oracle is 28 days. Given that ‘fast lane’ was introduced in the Lido v2 upgrade to allow for performance and participation monitoring of the Oracle runners, non-zero value for the common Lido Oracles (AO, VEBO), and the facts about CSM Oracle outlined above it is reasonable not to use ‘fast lane’ feature for the CSM Oracle.
GateSeal
gateSealFactory
Proposed value = 0x1134F7077055b0B3559BE52AfeF9aA22A0E1eEC2 (Lido Gate Seal Factory)
The address of the deployed gateSealFactory.
sealDuration
Proposed value = 6 days
This variable indicates the length of pause activated by the corresponding GateSeal instance. It is proposed that it be set at 6 days (the same as for the WithdrawalQueue). 6 days is sufficient to prepare for an emergency upgrade and initiate on-chain votes to upgrade contracts or prologue pause.
sealExpiryTimestamp
Proposed value = deployTime + 365 days
This variable indicates the period during which the corresponding GateSeal instance can be used. It is proposed to set it at deployTime + 365 days (the same as for the WithdrawalQueue). 365 days is sufficient to ensure CSM code reliability or to deploy a new GateSeal instance.
sealingCommittee
Proposed value = 0xc4DAB3a3ef68C6DFd8614a870D64D475bA44F164 (Dev team EOA)
It is proposed that CSM Multisig (to be created) be used as the sealingCommittee address in CSM to allow for a fast reaction to unexpected situations during CSM operation.# CSM parameters
The doc aims to provide values for all configurable and constant CSM parameters and motivations for why they are proposed to be so.
Start exploring CSM 
Get prepared for CSM 
Check your eligibility for CSM Early Adoption 
Join CSM testnet 
Chat about the CSM testnet 
Celebrate the CSM launch 
