Great question. Yes, delegation migration is per-indexer, so you can choose when to migrate the delegation to each indexer separately, and choose a different L2 beneficiary for each delegation.
1 Like
Updated the GIP with a PR to the repo:
I’ll update the forum post above soon, but here’s a summary of the changes:
- Proposed modifying the Arbitration Charter to make L1 offenses slashable in L2 if the indexer tries to evade slashing by migrating the stake to L2 (noted during the audit)
- Subgraph IDs will have to be aliased in L2 to avoid conflicts, the GIP now specifies the aliasing formula
- Added more details about the vesting contract migration, for fully-vested and still-vesting contracts.
6 Likes
If someone is using their subgraph in production, this will cause a temporary service outage while indexers on arbitrum recognize and open an allocation (and possibly sync) since this does not allow for N-1 support.
From the indexer community I’d like to raise some awareness on this to ensure we jump on subgraphs as soon as we identify the migrate transaction from the subgraph developer. I’ll chat with the dev of the curation station bot to get some alerts broadcasted as these occur.
Edit: Will the endpoints be the same on L2 for the subgraph?
This is a very important point. There is ongoing work to allow Indexer Agent to support L1 and L2 simultaneously, which would also include a way for indexers to opt-in to keep serving these subgraphs for a while (maybe 24 hours?) after migration. This would give subgraph devs time to change the URLs to the L2 gateway after migration, and it would also allow indexers to use a single Graph Node instance, so they don’t need to re-sync the subgraph. (There’s ongoing work on the Gateway to also allow this by keeping the L1 URL active after the migration).
Hey guys, apologies i didnt read all the comments here, but as far as i know the migration basically resets indexers delegators, since they need to 1. be aware of the migration (which not everyone will be ofc) and 2. they dont need to stick with the original indexer
Imo this is a bit of a downer for existing indexers that did a lot to get delegation and now they potentially lose it. I am aware as well of the fact that its the delegators choice in the end what to do.
Maybe best thing here is to make sure all delegators are FULLY aware of the migration and what choice they have and what happens if they simply choose the same indexer on the L2. Hope that makes sense
So the L1 endpoint will differ from the L2 endpoint? Having 24 hours will be very useful, huge +1 to that.
Pablo, will the default option be to stick with the indexer if they have provided a L2 address? I would think that this would minimize delegator flight to other indexers.
We can probably utilize the help from the AdvocatesDAO to help raise awareness.
Delegators do need to stick with the original indexer if they’re migrating. If they want to switch indexers, they’d have to undelegate waiting for the 28 day period, or wait until the indexer has fully migrated (i.e. no stake left behind on L2), and only then undelegate without waiting.
5 Likes
Yes, there are separate Gateway instances for L1 and L2, so the endpoints will be different. There’s some work going on to see if we can make the L1 Gateway redirect or proxy to the L2 Gateway for migrated subgraphs but it’s not quite straightforward.
I agree communication will be important, core devs and the Foundation will be using all available channels, and I think Indexers also using their channels to reach Delegators will also be very useful.
1 Like
Hey folks, there’s some potential for confusion with the word “migration” as it’s been used to refer to migrating from the hosted service to the Network.
So we’re editing the proposal to rename the “Migration Helpers” to “L2 Transfer Tools”, and change function/contract/event names accordingly. I’ll be pushing the changes and editing the GIP above soon.
I’ll also edit GIP-0052 to reflect this.
Edit: this GIP has now been edited with this change.
4 Likes
Hey @Pablo ! I wanted to confirm if possible if curators/delegators would have to pay gas on each position if using the transfer tool. Or can they possibly do this in one transaction?
Hi @PaulieB, the delegation to each indexer and the curation to each subgraph have to be transferred separately.
While it might’ve been technically possible to “bundle” these into a single retryable ticket, the added complexity would increase the risk of a ticket being unable to redeem in L2, which would mean all the transferred state is lost, besides making the validation on each side much trickier. So we tried to keep it as simple as possible (and even with this it’s still a relatively complex solution in the end).
2 Likes
Makes sense. Thanks. This helps prepare for how to handle.
We have another question regarding migration of indexers with fully vested tokenlock contracts
Do i understand correctly that we have 2 options:
- create an indexer on Arbitrum without tokenlock contract
- create an indexer on Arbitrum with tokenlock contract
And in the 1st option we won’t be able to change the beneficiary of the tokenlock contract (aka owner of the indexer)?
If in 2 or 3 years we will have a necessity to change the owner address (reasons were highlighted in GIP-0045) would the only way to do it be to migrate via creating a new tokenlock contract on Arbitrum (option №2)?
I’m not sure I follow what you mean with those two options, but to hopefully clarify, vesting lock beneficiaries that are fully vested have only one option to transfer to L2, and that option is to use the token lock transfer tool to choose what their L2 address will be. This can be any L2 address, so generally it will be an EOA or Arbitrum multisig (e.g. a Safe). After setting this address (and depositing some ETH for L2 gas), they can use the transfer tool to send their stake to L2, where it will be owned by the address they have chosen.
Since this address is not a vesting lock, there is no beneficiary to set or change once you’re in L2. If you need to change the indexer address, that’s a whole different thing, and it would be quite tricky to allow it in the protocol as we discussed in that GIP-0045 thread. If you’re thinking about having to change the address you use for your indexer down the line, I’d suggest you use a multisig as your indexer address in L2 so that you can rotate the owner addresses or manage it however you prefer, but keeping the indexer address constant.
Not sure if this answers your question so please let me know!
Yes, ok, multisig will also do the trick with the change of indexer’s owners, thanks.
So, now we have the structure:
Beneficiary (=owner) → Tokenlock contract (Indexer) ← Operator
But in multisig case Indexer = Beneficiary (one address), correct?
How can we assign different address to receive rewards?
In the multisig case, the Indexer will be the multisig (one address), which can have many owners and can be changed/rotated as needed. The rewards will by default be restaked for the Indexer, but you can also use setRewardsDestination(address _destination) on the Staking contract to set an address where rewards are sent. And you can also have an Operator address (or many) to handle day to day operations, just like before - the Operator is set on the Staking contract, not the vesting lock.
1 Like