Good points. The current LIP-73 design would result in an orchestrator losing its delegated stake on L1 when it migrates to L2 since the orchestrator’s delegators would have to migrate their own stake delegated to that orchestrator to L2. After some thinking, I agree with you that this is not only messy, but also disproportionally penalizes orchestrators with many delegators relative to orchestrators with few delegators. While delegators can certainly choose to move their stake away from an orchestrator on their own, I think it is important for this and other protocol upgrades to not disproportionally penalize a certain group (i.e. orchestrators with many delegators) if the members of the group are operating honestly and according to the rules of the protocol.
Similar to the governance process, I would propose a time window (3-4 weeks) where Os could signal if they plan to migrate or not. If an O decides to migrate, the stakers have enough time to overrule that decision and unbond from that O.
I agree that an opt-out process that involves an orchestrator by default migrating its entire delegated stake to L2 with the ability for delegators to opt-out beforehand could be reasonable. LIP-25 already defines a social convention for delaying protocol updates by a fixed period of time and the purpose of the delay is to give users the ability to exit if they disagree with the nature of the protocol update. So, during a delay period after staging a protocol update a delegator that does not want to have its stake migrated with an orchestrator has the option to opt-out by unbonding.
At the end of this window, every O that signaled migrates at the same time - with its entire stake.
While it is technically possible to move staked LPT from L1 to L2 in a single large batch (since the staked LPT is owned by the Minter contract), a couple things worth noting here.
Orchestrators/delegators would likely still have to at the very least submit a transaction on L2 in order to “claim” their stake on L2 which would be the same amount of stake that they had on L1. This is because the BondingManager contract on L1 tracks the stake of each orchestrator/delegator and there needs to be a process by which the BondingManager on L2 can “learn” the stake of each orchestrator/delegator. Additionally, if orchestrators need to “claim” their stake on L2, they wouldn’t be able to earn LPT rewards until that point since the BondingManager contract needs to know how much stake they have in order to calculate the LPT reward amount - depending on how you interpret the situation, the orchestrators would either be still considered on L1 at this point or in a sort of limbo state where they need to submit a transaction on L2 in order leave that state.
Thanks for all the feedback. We’re working on an an updated stake migration design to address the concerns shared thus far and will share back soon.