hi @jaywalkingjew, great question. The L2-related GIPs that we have for now (GIP-0031, GIP-0034 and GIP-0037) would only create a separate deployment on Arbitrum, without doing any migrations of indexer stake or subgraphs. Any users wanting to stake, delegate or curate on L2 would have to manually bridge the tokens before performing those actions. So your delegated tokens will definitely stay in L1 with these changes.
The way we’re thinking about this is in 3 phases:
- Deploy the L2 and the bridge (GIP-0031) with rewards disabled
- Deploy a solution to enable rewards (either GIP-0034 or GIP-0037, though there seems to be rough consensus that GIP-0037 is better)
- Deploy helpers to migrate stake, delegation and/or subgraphs (no GIPs yet).
So for now only stages 1 and 2 have a relatively clear path, and your delegated tokens will stay in L1 during those stages.
In stage 3, if the community supports this, we might end up deploying tools for indexers to migrate their stake together with delegation to L2 (and same for subgraphs and curation). But if we do this, we will 1) ensure it’s communicated ahead of time and 2) certainly include ways for people in your situation to be able to recover their delegated tokens. For instance, we could have a contract that you can call in L1 that uses the Arbitrum bridge to send a message to L2, claiming your delegation to a separate address on L2. There are a lot of people in your situation (e.g. using multisigs), so I don’t think the community and the Council would ever support a move like that, that makes you lose access to your tokens because you can’t interact with L2 from your wallet. In the experiments I’ve been working on for phase 3 ((WIP/experimental) migration of subgraphs to L2 through GNS by pcarranzav · Pull Request #585 · graphprotocol/contracts · GitHub - so far only for subgraphs on GNS), I’m including this “claim from L1” functionality from the beginning.