GIP-0045: Enable beneficiary change for indexers' tokenlock smart contracts

Governance & GIPs Graph Improvement Proposals (GIP)
1 
GIP: 0045
Title: Enable beneficiary change for indexers' tokenlock smart-contracts
Author: Anton Gaev <anton.g@p2p.org>
Created: 2022-02-09
Stage: Candidate
Category: "Protocol Logic", "Protocol Interfaces", "Economic Parameters"

Abstract

Many indexers have been operating for a long time and want to continue supporting the project for many years to come. But businesses grow and evolve and some changes may lead to the necessity to switch the beneficiary wallet for indexers without affecting its delegators in any way. In this GIP we propose to return previously removed changeBeneficiary function to the GraphTokenLock contract.

Motivation

There are many reasons why indexers may want to change their rewards destination:

  • it is a good practice to change hot wallets from time to time as a security measure
  • a company can go through a restructuring process and beneficiary wallets, especially if they were used by multiple projects, may become a property of a separate entity
  • the beneficiary wallet may be compromised
  • a person who had an access to the beneficiary wallet may leave the company
  • an indexer may be required to change the beneficiary address for tax purposes

But at this moment the only possible way to change the beneficiary wallet is shutting down an indexer and creating a brand new one thus making the delegators undelegate their tokens and lose the rewards.

High-level description

Previously, the changeBeneficiary function in the GraphTokenLock contract was removed:

But now as all vesting contracts for indexers are already fully vested. Businesses that grew from The Graph Indexers may require some flexibility to reflect the changes that have happened to them throughout these years. Many indexers have been here since the beginning of the protocol, built a reputation and have responsibilities in front of their delegators to provide them with sustainable profit, and in front of the network to provide clients with data in the most efficient way possible.

As there is no way to change the beneficiary address at the moment the only option for an indexer is to completely shut it down and to start a brand new indexer. But the main victim in this process will be delegators that will be required to go through 28 epochs unbonding period. Moreover, most of the delegators are dormant and invested their GRT with expectation for their delegation to grow over the years. They do not check the updates on forums, discord or telegram channels and their losses may be way bigger than 28 epochs of missed rewards.

This minor issue of changing the beneficiary wallet for indexers should not become a burden for delegators as it does not affect the common indexers operations and the changes for indexers due to internal or security reasons should not affect its delegators.

Validation

This proposal has not yet been reviewed nor audited.

2 Likes
2

As far as I know, the lockToken contracts are immutable, but cc @ari

2 Likes
3

Yes, the token lock contracts are not upgradeable so there’s no way to modify existing ones. So sadly I don’t think there’s a way to do what you propose @toxf1.

I can think of two alternative workarounds:

  • we’re working on the L2 migration helpers which should hopefully be ready soon. For fully vested locks, it might be possible to allow migrating to a different address that owns the stake in L2. (GIP for this coming soon)
  • someone could propose a GIP to make indexer stake transferrable directly on the Staking contract. This is tricky though, as the proposal would need to address the economic impact of making stake more liquid and make sure there are no attacks that come out of that. It might also be problematic for delegators as they may think they are delegating to someone and then the stake is transferred to someone they don’t support. Maybe only the full stake and config could be transferred as an “address swap” rather than making it liquid?

Of these 2 I think waiting for the L2 migration helper is the easiest / most sensible for existing token lock beneficiaries.

For the future, general case of making stake transferrable, maybe using account abstraction would be the way to go, so the indexer stakes from a smart contract wallet (e.g. a Safe) that can exchange owner addresses.

1 Like
4

But what about the delegators for the first scenario?
We can not force them to migrate to L2 and they will still delegate to an indexer with the tokenlock contract underneath. And it will be required to keep the stake there to support those delegators, so, it does not solve an issue completely.
Or am I missing something for that option?

1 Like
5

What will be proposed in the GIP is for delegators to be able to migrate to L2 to the migrated indexer; and no, it would not be required to keep stake in L1, you can migrate all and then delegators can choose to withdraw or migrate too.
Assuming the community and Council approve the proposal, of course.

1 Like
6

so, this option will save “active” delegators that follow the news on migration, etc. But the “dormant” delegators will end up on the L1 indexer without self-stake as it has moved to L2

1 Like
7

Yes, that would be the case. But there would be a big communications push to make people aware that this is happening, and it should affect all indexers similarly. Eventually the hope is that everyone will want to be on L2 anyways, this L1/L2 split we have now should only be temporary.

(And imho there is a minimum due diligence as a delegator in periodically checking that your indexer is still operating properly)

1 Like
8

Yes, I agree with you
But we still feel the responsibility to support all delegators and an option to abandon L1 completely is not that good.
We will try to develop on the second idea that you’ve proposed initially. But still, I think that it will take too much time and effort to implement those.

Of course, we will support both L1 & L2 Graph implementations. That’s just we’ve faced a necessity to change the beneficiary and ended up discovering that it is not possible and we wanted to raise a concern.
As for us this is a small restructuring inconvenience, but one day for some indexer it may become an issue to continue operating without changing the beneficiary address for one of many different reasons described in the Motivation section above.
I think it is better to propose changes now as nothing bad has happened.

1 Like
9

One more question on the first option:

Is this a one-way process?
Will there be 1 connection between L1 & L2 indexer addresses or you can migrate to a different address in L2 and then to another address in L1 that is different from initial one?

1 Like
10

Great to hear that you plan to run on both networks :slight_smile:

But yeah, I agree and I think what you’re raising is a very valid concern. For me in the long run it comes down to account abstraction, so the “indexer” could be abstracted into a smart contract wallet / account that can have several owners / roles, social recovery, etc… there’s a lot of brainstorming going on about this topic so hopefully we can have some more concrete proposals about this eventually…

If you’d like to work on a stake transfer proposal as an intermediate step, I think that could work too, as long as the concerns mentioned before are addressed (i.e. risks to delegators, possible economic attacks, impact on the overall health of the network). Implementation approach is also not so clear, we’d have to be creative with the Staking contract storage to make it work.

1 Like
11

So far we’re thinking about this as a 1 way migration, because the hope is that eventually everyone will be on L2 and the L1 network won’t be needed anymore.

So migration is always from the L1 indexer to one L2 indexer address, just allowing to send parts of the stake at a time (as long as both sides are over the minimum stake).

Edit: @toxf1 I just published GIP-0046, that describes the migration helpers I mentioned here: GIP-0046: L2 Migration Helpers - feedback welcome!

2 Likes