CSM Parameters Registry

This doc is closed!

Pls comment on and refer to https://hackmd.io/@lido/csm-v2-internal

One of the crucial features of CSM v2 is the introduction of the Node Operator types. Technical implementation of these features consists of two parts:

• Storage and management of the type members;
• Ability to set custom values for the node-operator-related parameters in CSM The letter can be solved by moving existing parameters and adding new ones to a separate registry contract that will store individual values of each parameter for each Node Operator type.

Since there might be many Node Operator types, and not all of them require a complete set of custom parameters, it is proposed that mandatory default values for each parameter be stored in the registry. If a custom value is set for the particular parameter and Node Operator type pair, the default value should be used.

It is proposed that this contract be called CSParametersRegistry. The general scheme for the contract looks as follows:

What parameters should be included?

Currently, CSM has several parameters that can be migrated to the CSParametersRegisty:

• keyRemovalCharge - an amount of stETH charged for the deletion of the validator key from the CSM deposit queue;
• elRewardsStealingAdditionalFine - an amount of ETH added to the amount of ETH EL rewards stolen or misdirected by the CSM validators while proposing blocks;
• performanceLeeway - a value in BP for the performance leeway used by CSM Performance Oracle to calculate Node Operator rewards distribution;

On top of these params, several new params can emerge within new features of CSM v2, like:

• priorityQueueLimit - number of seats a Node Operator is eligible to occupy in the priority deposit queue;
• rewardShare - a value in BP determining the share of the Node Operator rewards allocated to the module by the Staking Router a Node Operator is eligible for;
• strikesParams - parameters for the new strikes system (lifetime, threshold);