Here is a proposal for an updated L2 stake migration design to address the drawbacks with the current design described in LIP-73 as described in this post.
The design consists of two phases:
- Phase 1: Enable orchestrator migration to L2
- Phase 2: Enable delegator stake claiming on L2
When the first phase begins, orchestrators will be able to submit a L1 transaction to migrate their entire delegated stake to L2. As soon as an orchestrator migrates to L2, its entire delegated stake will immediately be able to accrue LPT rewards and ETH fees on L2 if the orchestrator calls reward or redeems tickets on L2. Delegators will need to wait until the start of the next phase to actually claim their stake on L2. However, if a delegator’s orchestrator migrates to L2 before the start of the next phase then the delegator will be able to access LPT rewards and ETH fees accrued to its stake when it claims in the next phase. If a delegator wants to opt-out of having its stake migrated by its orchestrator it has the option of unstaking and withdrawing prior to the upgrade.
When the second phase begins, delegators will be able to submit a L2 transaction with a proof of their L1 state in order to claim their stake and fees on L2. Since delegators only have to submit a L2 transaction they can avoid paying L1 transaction costs. The delegator’s claimed stake will be added to its stake in the L2 BondingManager. If the delegator’s orchestrator migrated prior to the delegator’s claim then the delegator will be able to collect any accrued LPT rewards and ETH fees since the orchestrator’s migration.
The reason for having two phases is because in order to allow delegators to claim their stake on L2 without paying L1 transaction costs there is a snapshot of L1 delegator state created at the start of first phase that needs to be reviewed by the community (similar to the snapshot process used for LIP-52) before the snapshot can be used as a part of the delegator claiming process in the second phase. Since the snapshot needs to be reviewed before it can be used for the second phase there would be at least a week long delay between the start of the first and second phases.
Phase 1: Enable orchestrator migration to L2
First, let’s assume that there is a Confluence LIP that bundles together LIP-73 (L2 Stake Migration) as well as any other LIPs pertaining to Confluence (i.e. updates to how protocol inflation works) which is voted on by the community.
If the Confluence LIP is approved by the community and deployed then immediately after deployment the following happens:
- The L1 Minter will transfer all of its LPT (i.e. all staked LPT on L1) across the bridge to the L2 Migrator so that it can stake in the L2 BondingManager on behalf of orchestrators and delegators that claim in the second phase
- The L1 Minter will transfer all of its ETH across the bridge to the L2 Migrator so that it can credit fees to orchestrators that migrate and delegators that claim in the second phase
- L1 protocol inflation is disabled to prevent the stake of orchestrators and delegators on L1 from increasing and L2 protocol inflation is enabled
- The L1 BondingManager will be upgraded to disable all state modifying actions in order to prevent the state of orchestrators and delegators from changing 
- A Merkle tree based state snapshot of L1 delegator state is created such that a proof of a delegator’s L1 state can be created based on the root of the tree
- A LIP that references the above snapshot will be proposed and be the subject of a governance poll giving the community the opportunity to review the correctness of the snapshot off-chain
At the smart contract level, in order to allow an orchestrator to migrate its entire delegated stake to L2, a delegator pool contract can be deployed on L2 for each migrating orchestrator. The orchestrator’s delegated stake would be owned by the delegator pool contract and would begin to accrue LPT rewards and ETH fees while that stake is delegated to the orchestrator.
 Will need to ensure that any unbonding locks can be withdrawn, but not used to rebond to an orchestrator which would change the stake of the delegator.
Phase 2: Enable delegator stake claiming on L2
If the snapshot LIP is approved by the community and deployed then immediately after deployment, delegators will be able to claim their stake on L2 by providing a proof of their L1 state based on the snapshot.
If the delegator’s orchestrator migrated, then the L2 transaction submitted by the delegator would also take ownership of the stake and fees owed to the delegator by the L2 delegator pool contract for the delegator’s orchestrator. A pro rata share calculation can be performed to determine how much stake and fees from the delegator pool the delegator should be entitled to. For example, if the delegator owns 20% of the delegator pool’s initial stake then it is entitled to 20% of the delegator pool’s current stake (which includes accrued LPT rewards) and fees.
While the snapshot mechanism to support delegator claiming on L2 is not trustless, the motivations for including it in this design are:
- L1 gas prices make it especially tough for smaller delegators to migrate on their own to access value that they are entitled to within the protocol. Based on some rough back of the napkin math, we estimate that there could be as many as 2000+ delegators for which the L1 transaction cost for migration would exceed the value of their stake and as many as 4000+ delegators for which the L1 transaction cost for withdrawing fees would exceed the value of their earned fees. We estimate that avoiding L1 transaction costs altogether for these delegators could “unlock” a cumulative total as much as 1000+ LPT and 2+ ETH that could otherwise be inaccessible to delegators from an economic POV
- There is precedent for using a snapshot process to unlock value in the protocol with LIP-52 given the ability for the community to properly evaluate the correctness of the snapshot off-chain before it is used on-chain
Questions for the community’s consideration
- Does the tradeoff with the snapshot based claiming process for delegators on L2 seem reasonable?
- Does the delay before delegators can claim on L2 seem reasonable given that if a delegator’s orchestrator migrates the delegator’s stake will already be accruing rewards and fees on L2?