Proposed CMv2 Parameters by Node Operator Type
Following the discussion in the original CMv2 landscape post, this update proposes parameters for each Node Operator type for Phase 1 of the Curated Module v2.
Proposed parameters
* Required Validator Exit Process Window will be proposed to be tightened in Phase 2.
Any of these parameters can be changed via a full DAO vote.
Additional global parameters
-
Bond lock period: 60 days
This parameter determines how long a bond locked by the Curated Module Committee (CMC) remains locked if no further action is taken.
-
Rewards interval: 14 days
This parameter determines how often rewards accumulate for claiming by Node Operators.
Parameter breakdown and explanation
1. Fees
The proposed fee levels are intended to remain aligned with the current CMv1 levels, with one change on the Public Good (formerly Client Teams) side.
-
Professional Operator — 2.5%
This is proposed as a lower-fee category for operators that are in a probation period (e.g. new or operating at reduced capacity following a significant incident) within the Curated Lido Node Operator set.
-
Professional Trusted Operator — 3.5%
This remains unchanged from the current CMv1 fee structure.
-
Public Good / Decentralization / Extra Effort Operators — 4%
In light of feedback received from the wider NO community, it is proposed to reduce the Public Good Operator fee from 4.5% to 4%, with the increased fee share now comparable to that of the Decentralization and Extra Effort types (an increase of ~14% from 3.5% rewards rate). Given the lack of specific requirements placed on Public Goods Node Operators and varying levels of contribution to the Lido Ecosystem, it is suggested that an incremental 0.50% of rewards compared to Standard Tier Node Operators meets a healthier balance, and that efforts to supporting public goods should instead move towards support of PG-funding mechanisms through protocol features (e.g. rewards splitters in CMv2, stVaults such as Obol’s Client Team vault) and/or more explicit PG-funding (e.g. donations by the DAO) based on surplus income vs as built in protocol costs.
-
Intra-Operator DVT Cluster — 3.5%
This type is proposed to have the same parameter values as the Professional Trusted Operator type, based on the idea that extra cost for operation of DVT infrastructure should be netted against likely provider incentives, and may be reconsidered at a later time.
2. Bond
The proposed bond structure is intended to satisfy two objectives at once:
- preserve a high first-validator bond for security and slashing coverage up to medium-severity events;
- avoid unnecessary capital inefficiencies created by the sub-node-operator structure.
In the initial bond analysis, it was proposed that the bond baseline for most types would be [11, (0.6)] ETH.
After further consideration, it became clear that this structure interacts poorly with the sub-node-operator mechanics.
More specifically, under that design, an operator with two sub-node operators would be required to post more bond than an operator with just one sub-node operator, even when the total number of keys remains the same. This creates an undesirable disincentive for configurations such as combining, for example, Professional Trusted Operator and Intra-Operator DVT Cluster types. In other words, the previous bond proposal could unintentionally discourage DVT-related setups simply because capital requirements would scale unfavorably across sub-node operators.
To address this, we propose the following bond curve for most types:
- 11 ETH for the first key
- 0.1 ETH for the next 17 keys
- 0.7 ETH flat for each subsequent key
This preserves the 11 ETH initial bond, which is important from a security standpoint and for slashing coverage, while modifying the post-baseline progression in a way that works better with the sub-node-operator model.
For Professional Operator, the proposed bond is:
- 11 ETH for the first key
- 1 ETH for each subsequent key
This type keeps a simpler and more conservative bond profile, as the Professional Operator type is not intended to be combined with any other Node Operator type.
3. Validator Exit Processing Window
The proposed Validator Exit Processing Window is up to 4 days across all types, as currently defined in the Validator Exits SNOP.
If a protocol-requested exit is not processed within this timeframe, exits will be effected using the Triggerable Withdrawals functionality of the Curated Module, and the Node Operator would be penalized through the exit delay fee outlined in the next section.
4. Exit Delay Fee
This fee is intended to serve as a disincentive against delaying validator exits and occurs if requested exit is not processed within the allowed exit delay timeframe.
The proposed Exit Delay Fee (for a fully deposited 0x02 key, the value decreases linearly to the actual validator balance, in 1 ETH increments) is:
- 0.64 ETH for Professional Operators
- 0.32 ETH for all other listed types
5. Penalty Fee
For non-fully-automated protocol rule violations (compared to fully automated ones, such as the exit delay fee), an additional Penalty Fee is levied for violations committed by a Node Operator that are reported by the Curated Module Committee. Those violations can include extended underperformance, EL rewards rerouting, out-of-order exits, etc. Details on the broader penalties framework are still pending and will be proposed separately.
The proposed Penalty Fee is:
- 0.1 ETH for Professional Operators
- 0.05 ETH for all other listed types
The higher fine for Professional Operators helps maintain stronger discipline for Node Operators without an established track record within the Lido Node Operator set.
6. ValMart Weight
ValMart Weight is a multiplier used to determine the target stake allocation for a Node Operator of a given type.
The proposed ValMart Weight is:
- 0.5 for Professional Operators
- 1 for most other types
The lower weight for Professional Operators serves as a security measure, limiting the protocol’s stake allocation to newcomers relative to more established Node Operators within the Lido Node Operator set.
The stake allocation weight is fixed in Phase 1 of the Curated Nodule, but in Phase 2, Node Operators will be able to increase or decrease their stake allocation weight.
Multi-Operator DVT will not be introduced in Phase 1
The Multi-Operator DVT Cluster type is not proposed for introduction in Phase 1 of the CMv2 release. Given complexities associated with the migration and ongoing discussions with Node Operators and DVT providers regarding how to best implement scalable multi-operator DVT within the Curated Module, it is expected that a more robust framework regarding Multi-Operator DVT utilization will be introduced within Phase 2.