Deposits and consolidations tech plan
We need to ensure we have a clear plan for how deposits and consolidations will occur after the CMv2 release. Here is the proposed plan:
Period 1. Initial CMv2 release
Parameters
- CMv1
stakeShareLimit= 100% - CMv2
stakeShareLimit= 100%
Flows
Right after the CMv2 release, we enter Period 1 of the plan.
- Operators create their sub-Node-Operator entities on-chain and start uploading validator keys.
- CMC starts and executes EasyTracks to create Operator Groups, enabling Node Operators to start receiving seed deposits.
- During this period, CMv2 will have the highest priority to receive seed deposits.
- If all of the keys in CMv2 are deposited, the excess stake goes to CMv1 or CSM with respect to their priority and available capacity
- Top-up deposits are disabled.
- The consolidation process can begin once the first validators in CMv2 are active.
Transition
This period starts with the release of CMv2.
Period 1.5. Transition from CMv1 to CMv2
Parameters
- CMv1
stakeShareLimit= 100% - CMv2
stakeShareLimit= 100%
Flows
This period aligns with Period 1, with top-ups enabled for CMv2 and the consolidation process underway. Should there be a capacity shortage in CMv2, deposits can still be sent to CMv1.
Transition
This period does not require an on-chain vote to be started. The only thing needed is to enable top-ups and start consolidations.
Period 2. Full switch to CMv2
Parameters
- CMv1
stakeShareLimit= 0% - CMv2
stakeShareLimit= 100%
Flows
Once CMv2 has sufficient capacity (>350 active validators) to accept both consolidations and new stake, and Lido contributors are confident in CMv2’s reliability, we enter Period 2.
- Node Operators maintain a sufficient number of keys to accept consolidations and new stake via top-ups.
- CMv1 no longer accepts new stake. Exits to cover withdrawals are requested from CMv1 until it is empty.
- Top-up deposits are enabled.
- The consolidation process continues.
- Any depositable ETH is used first to make seed deposits in any module according to priority, and then for top-ups if there are no keys to seed.
Transition
This period requires an on-chain vote to change modules’ limits.
Deposits and consolidation targets
It is proposed that Node Operators consolidate their validators from CMv1 to the most recent validators in CMv2, while top-up deposits go to the oldest validators first.
This will allow us to keep the existing VEBO algorithm (old validators exit first) and keep the depositor bot simple (top up the oldest validator until it is full) for this release. Once we are done with the consolidation, the process will continue without the need to rush the next release.
Emergency plan
Should a vulnerability in CMv2 be discovered during stake migration, CMv2 should be paused, and CMv1 should be ready to accept deposits. It is proposed to transition to Period 2 only when there is a certain confidence in CMv2 reliability. Hence, Node Operators should maintain depositable capacity in CMv1 until the end of migration, and maybe sometime after.