This proposal presents a potential timeline to start issuing 100% of indexing rewards on the L2 instance of The Graph. It proposes four steps with L2 rewards going from 5% to 25%, 50%, staying for 95% for some time, and finally 100%. It presents requirements and an estimated time for executing each step.
Motivation
In several GIPs, we’ve presented various steps to scale The Graph Network by moving to Arbitrum One. Now that the L2 network has been deployed, and other important milestones have been met, it would be desirable to have a clear timeline and exit criteria for completing the move by switching 100% of indexing rewards to L2.
One issue with this statement would be - what if a lot of subgraphs are just unmaintained, not actively queried, yet still curated by their (inactive) owners or the community.
Good point, the purpose of this is to not leave subgraphs that take a bit longer to migrate without indexers, but maybe we can filter a bit more and say “90% of subgraphs that are over the minimum signal and have had queries in the last month” or something like that.
Do you think there are any issues we might hit with the potential for a large proportion of the delegation community being in “stasis” whereby they aren’t really paying attention and delegated in a “set and forget” mode?
I’m not sure if or where it fits within the milestones but I think the ratio of delegations migrated should definitely be considered as part of the decision process, in order to respect the need for economic security, as delivered by delegators, on l2.
which is pretty unfortunate for those of us who have attracted larger amounts of delegation.
Got alot of thoughts about this. The loss of delegation is a big concern, but more importantly (to me) the loss of reputation (data). We have worked hard to build out our reputation in the L1 network subgraph. We need to discuss ways to migrate our reputation (data) to the L2 network subgraph.
Topic for another thread, don’t want to go off on any more of a tangent on this thread.
Thanks for raising this, it’s a good point. I’d be wary of making this requirement too high, as it could mean inactive delegators stop the whole network from migrating. But I think we can try to find a sweet-spot where enough delegators have already migrated that the L2 network has good delegation volume, and then raising rewards in L2 incentivizes the rest to finish migrating?
Maybe we can go to 50% without setting explicit requirements for delegators, but require that, say, 1/3 of delegators have migrated before jumping to 95%? (or we could frame it as saying that delegation on L2 is 50% delegation on L1, like we did for indexers).
Would this address the concerns, or would you like to see requirements on previous steps, or a higher requirement for that 50-95 step?
Separately, I’m curious what you mean about the reputation data on the network subgraph, would love to read about it whether it’s on this thread or a new one.
Our indexer has produced the highest amount of query fees (which sorts us to the #1 spot on the participants page). During our indexers we have 0 forced closures. These two points are data points we’re particularly proud of and serve as ‘reputation data’. On L2 this resets.
I agree that you will have sleepers on the delegation side who are not actively monitoring their delegation. Naturally, I would assume the message will get pushed out on all off-chain communication platforms as hard as possible. We may also want to consider on-chain signals such as issuing a POAP for successfully migrating to L2 and/or creating a Snapshot vote (in this case just formulated as a cta). Creating such on-chain events gets picked up by sites like Daylight which then notify eligible wallet owners to take action.
Either way, a good communications strategy beyond the traditional off-chain channels (twitter, discord, forum, etc) could be making a noticeable difference in getting migration up to acceptable levels in short order.
Sure! Snapshot is probably the most commonly used platform for web3 voting, and is typically used for governance, treasury or community proposals. However, you can also use it for stimulating a call-to-action, essentially creating a “proposal” that is focused on the migration message for Delegators to move over to L2. If such a proposal would be generated, then sites like Daylight pick that up and send out an email notification to the wallet owner. For example, I just received an email a few days ago that a new Snapshot proposal was issued for DeveloperDAO. Since I have the DD NFT in my wallet, Daylight knew I was eligible to vote. We currently have The Graph community Snapshot org which is set up with a strategy that allows all Delegators to vote on proposals. Naturally, not all 10k+ Delegators are subscribed to sites like Daylight, but you may catch another 500 - 1,000 that might otherwise not have been aware of the migration.
You could even take it a step further and tie a small rewards bonus for Delegators to the Snapshot vote. Imagine you have only one voting choice with something like “I confirm that I have migrated to L2” and every Delegator who has successfully migrated (and confirmed/voted in Snapshot) is eligible to receive a small reward (something like 10 GRT) at the conclusion of the voting period. Economic incentives, however small, are a big motivator for many people. Instead of “rewards” you could also label it as a “reimbursement” for their effort and transaction costs for migrating.
Would be great to have a chat about both before putting anything to paper, because I am definitely not sure what numbers would make sense as thresholds, let’s crowdsource it a bit on IOH?
Sleeping delegators can really be a problem, I would suggest using gamification of the migration process for example L3 quest with a memorable POAP for the migration. So you can kill two birds with one stone, encourage old delegators and attract new ones.
I find interesting the idea of pairing each bump with an action focused to remind delegators that this is happening. Giving a POAPs to the ones that migrated sounds great, we did that in the past during the first missions. Something else would be to show a network-wide delegation APR in the explorer so they can compare L1 vs L2 and see what they miss by not supporting the highest value network.
Hi, as mentioned in GIP-0046, the “migration helpers” are now being called “L2 Transfer Tools” to avoid confusion, so I’ve edited this GIP to use the new naming.
I’ve also added some changes to incorporate the feedback from this thread and what was discussed in the IOH:
Proposed discussing in IOH before each increase to check that everything’s okay
Added a requirement that a third of delegation is in L2 for the 50->95% bump
Make the first 25% bump one week after deploying the transfer tools to give people some time to try them
Change the requirement for 90% of subgraphs having migrated, to only count subgraphs that have query fees
Let me know what you think, hopefully this addresses the main issues that people had raised. We’re moving forward with testing and dev for GIP-0046 so hopefully the transfer tools can be deployed in the next couple weeks. If there’s consensus about this we’d like to aim to do the first 25% bump around end of May or early June (assuming, of course, that the transfer tools deployment goes well and we meet the criteria described here).
