This article is the last in a four-part explanatory series about Community Staking Module (CSM). It explains how CSM allocates stake and handles validator exits or ejections. For the previous articles, please refer to the following list:

Stake Allocation

The allocation of stake to Node Operators within CSM depends on the protocol-wise and module-wise allocation mechanisms.

Each module has a predefined parameter (configurable by DAO vote) known as targetShare at the protocol level. This represents the maximum percentage of the total Lido protocol stake a module can get. Currently, stake at the protocol level is allocated as such:

Modules are prioritized based on current stake share, where modules with the fewest active validators receive priority;
Modules must have enough theoretical capacity (stake to be deposited <= difference between the module’s currentShare and targetShare);
Modules must have enough real capacity (i.e. sufficient validators submitted to validator registry) to absorb this stake.

At the estimated time of CSM launch, the module will be in the position to receive the highest priority for stake allocation, since it initially would have no stake. It was proposed to set the targetShare at 1% initially and then gradually increase it to a maximum of 10% via DAO vote as the module matures.

Inside the module, a FIFO (first in, first out) mechanism is employed to distribute stake. Every Node Operator has to lock their bond to upload new validator keys, so it is fair for them to get stake in the same or similar order they deposit bond funds. While a potential long Ethereum validator entry queue would result in delays in gaining validator rewards from running validators, the bond would be staked and immediately acquire staking rewards for operators. This is preferable to the bond being unproductive capital while operator validators are idle.

Validator Exits

Voluntary Exits

Given CSM’s permissionless nature, operators are allowed to exit validators at their discretion and subsequently claim their unlocked bond. Prior to the bond release, CSM has to know a validator’s withdrawal balance and decide whether losses took place. If so, losses are confiscated from the bond. Withdrawal balance information would be delivered in a trust-minimised way by leveraging EIP-4788. Once the final releasable amount of the bond is determined, it is eligible for them to claim it.

Passive Exits

According to the Lido on Ethereum Validator Exits Policy, each module should support validator exits to fulfill withdrawal requests for stakers. However, due to the existing VEBO algorithm, CSM validators will have the lowest priority when it comes to exiting validators. This also indicates that Lido encourages community stakers’ participation, and acknowledges the fact that bonded validators are more beneficial for the protocol in terms of economic security.

Once the Execution layer triggerable exits introduced by EIP-7002 are implemented, the Lido on Ethereum protocol will be able to eject validators through the protocol’s validator withdrawal credentials. The forced ejection can be triggered in case of a huge dip in a validator’s balance or a lack of bond coverage.

Aside from slashing, a validator’s balance rarely experiences a significant short-term drop. However, being offline or submitting incorrect attestations for an extended period could lead to substantial accumulated losses. It is assumed that something should be wrong with the validator in such a case (e.g. missing its validator key or ceasing maintenance), and it should be ejected to prevent additional losses for stakers.

In another scenario, when the validator’s bond can’t meet the minimum bond requirement after the application of a penalty, it should also be ejected from the economic security perspective.

What’s Next

The Lido DAO is dedicated to enhancing the security and decentralization of Ethereum. In line with this mission, the introduction of the Community Staking Module will mark a significant milestone by onboarding permissionless Node Operators and building a more robust validator set.

As mentioned before, CSM was expected to commence its testnet and mainnet in late 2024. Please join the CS discord forum to build a community-driven module together. Thanks for reading the whole blog series and feel free to claim the OAT via Galxe.