Lido contributors propose a temporary change to the top-up allocation mechanism in the Curated Module v2 (CMv2) with top-up switches.
It addresses a gap in how the allocation mechanism works today. The module splits top-up deposits between node operators, up to each operator’s capacity. It calculates that capacity from deposited keys and tracked balances. However, the module doesn’t know each validator’s current status on the consensus layer (CL). So two groups of validators still count toward capacity:
- validators that got their initial deposit but are still waiting for activation;
- validators that have exited or been withdrawn but whose withdrawal hasn’t been proven to the module yet.
Neither group can accept a top-up. An operator with many of these validators can get a significant portion of the allocation that it can’t use. The ETH stays in the protocol buffer, even when other operators have room.
As a short-term fix, each operator gets a top-up allocation enabled flag. When the flag is off, the allocator leaves that operator out and splits top-ups among the remaining operators. Initial deposits to new keys continue as normal.
Here’s who controls the flag and how it’s set initially:
- Only the operator’s owner can disable the flag. The owner is the manager address if
extendedManagerPermissionsis on. Otherwise it’s the reward address. - The Curated Module Committee (CMC) can enable the flag once the operator has enough usable capacity. CMC cannot disable it.
- New operators start with the flag off.
- At upgrade, the flag is enabled for existing operators that have deposited keys not yet reported as withdrawn.
The flag is a temporary, manual measure. A mechanism that reports validator CL status to the module is planned for Q1 2027 and is meant to replace it.
For use cases, migration details and limits, see Top-up Allocation Control in the Curated Module.