Skip to main content

Validator Exits

tip

Looking for a practical guide to run nodes? Follow the Curated Module v2 guide or the CSM guide.

exits-1

Exited and Withdrawn​

The Curated module uses the "exited" statuses of the validator (both Slashed and Exited and Unslashed and Exited) as the last meaningful status in accounting since, after this status, the validator is no longer responsible for any duties on the Beacon chain (except for the rare cases of the delayed sync committee participation).

CMv2 and CSM, in turn, need to know about each validator's exact withdrawal balance to decide on bond penalization. Hence, the module uses the "exited" counter reported by the accounting oracle only to return a correct number of "active" keys to the staking router, and implements permissionless reporting methods to report the validator's withdrawal balance once the validator is withdrawn.

Validator balance tracking​

The module keeps a confirmed balance for every deposited validator key: the highest balance ever proven on the Consensus Layer through Verifier. Anyone can update it with a balance proof as the validator grows from CL rewards, settled top-ups, consolidation inflows, or other CL activity. It never decreases while the validator is active, so it acts as a high-water mark capped at the validator MAX_EB.

It is used in three places:

  • Verifier checks it to confirm that a reported withdrawal is large enough to be treated as a full withdrawal.
  • The module uses it as the baseline for the withdrawal-balance penalty applied when the validator is withdrawn.
  • When the confirmed balance exceeds the validator's allocated amount, the module raises the allocated amount to match, so validator balance growth is reflected in the module's tracked stake and remaining top-up capacity. This keeps stake allocation fair.

This approach has two important caveats:

  • Stale balance proofs can cause under-penalization. If proof delivery lags behind settled top-ups or balance growth, the confirmed balance can be lower than the validator's actual high-water mark, so a later loss is measured from an outdated baseline.
  • Consensus Layer balance decreases are assessed without determining fault. Any decrease from the confirmed high-water mark to the withdrawal balance is charged to the Node Operator, regardless of its cause, so losses from systemic network conditions are not distinguished from operator-caused ones.
Prover bot

Confirmed balances stay accurate only if balance proofs are delivered on time, so reliable operation of the prover bot is more important to module health than in earlier versions.

Voluntary exits​

Node Operators exit their validators by publishing an exit message to the Ethereum Consensus Layer. Should a Node Operator decide to exit using EIP-7002 instead, they can do so via the Ejector contract.

In CMv2, exiting outside of a protocol-requested exit is discouraged. Operators planning to do so should notify the Curated Module Committee and the community in advance. In CSM, given its permissionless nature, operators can exit at any moment.

warning

Exiting validators using EIP-7002 is an emergency measure and should be used only in exceptional cases. It is recommended to exit validators using the standard method of publishing an exit message to the Ethereum Consensus Layer.

Protocol-initiated exits​

For consistency with the core protocol and other staking modules, these modules use VEBO to request or trigger validator exits. Details about the overall processes and mechanisms through which validator exits are requested by the protocol and why are explained in the Lido on Ethereum Validator Exits SNOP 3.0 (IPFS, GitHub)

From the core protocol side, validator exit can be requested to cover withdrawal requests from stETH holders or according to the DAO's decision.

From the module side, validator exits can be requested or triggered for:

  • Unbonded validators. These exits are requested automatically using the targetLimitMode = 2 (forced mode);
  • CSM validators with an excessive number of bad performance strikes. These exits are triggered via the permissionless method on the ValidatorStrikes contract. The strike parameters are set per Node Operator type, and are documented for CSM under Penalties.
info

targetLimitMode = 2 (forced mode) was introduced within the updated version of Staking Router. In short, it is similar to the existing targetLimit but exits for the validators above targetLimit with targetLimitMode = 2 (forced mode) can be requested within the next VEBO report, even without a need to fulfill withdrawal requests from stETH holders.

Node Operators should follow VEBO events, for example by using the Ejector, to ensure they exit validators on time.

If a Node Operator fails to exit requested validators in time:

  1. VEBO will trigger exits for the delayed validators;
  2. The module will penalize the Node Operator's bond tokens for the delayed exits;
  3. The module will confiscate withdrawalRequestFee paid by the protocol to trigger delayed validator exits from the Node Operator's bond tokens;

Also, in exceptional cases, Lido DAO can trigger exits for Node Operator's validators based on the DAO's decision.

Withdrawal balance reporting​

The module settles a validator's exit after receiving a withdrawal report. Processing the report marks the validator as withdrawn and applies any exit-related penalties and charges, documented per module under CMv2 Penalties and CSM Penalties.

Non-slashed validators​

After a full withdrawal is included in a beacon block, anyone can submit a withdrawal proof through Verifier. Reports are typically submitted by the prover bot or the Node Operator.

Verifier validates the proof against a beacon block root obtained through EIP-4788 and forwards the proof to the module to process.

If the withdrawal amount is below the confirmed expected balance, the difference is applied as a penalty. The module also settles any previously recorded delayed-exit penalty, bad-performance penalty, and applicable execution-layer withdrawal request fee. Some of these amounts are proportional to the validator's balance while others are flat, as documented for CMv2 and 0x02 CSM.

Slashed validators​

Slashed validators use a separate permissioned flow because their full losses, including missed rewards, cannot always be determined from the withdrawal amount alone:

  1. Anyone can submit a valid proof of the validator's slashed status through Verifier.processSlashedProof. This records the slashing in the module but does not settle the withdrawal.
  2. A dedicated committee, the Curated Module Committee or the CSM Committee depending on the module, calculates the slashing loss off-chain and submits the validator's exit balance and explicit slashing penalty through an Easy Track motion.
  3. When the motion is enacted, the module applies the slashing penalty and any other recorded exit penalties or charges, marks the validator as withdrawn, and updates the Node Operator's required bond.