Indexing rewards should be withdrawable to a separate address

Most early Indexers in the network are interacting with the protocol via a Token Lock Wallet contract where their holdings of GRT are vesting.

These vesting contracts allow any GRT balance in excess of the locked amount to be withdrawn. This provides a path for Indexers to withdraw rewards, however, only if Indexers unstake all their tokens and withdraw their rewards into the vesting contract, which involves waiting for a 28-day unstaking period. During this time the Indexer is not earning rewards, and worse yet, any Delegators they had are likely to lose trust in them for rug pulling them in order to withdraw rewards.

We have gotten feedback that the way things work currently hurts small Indexers who were relying on indexer rewards to pay for infrastructure and other operation costs.

I would love to hear from Indexers whom this is impacting to get a sense for the scope and the severity of the issue. Thank you!

19 Likes

I think this is impacting all indexers to some degree. Related:

Although not confirmed, we have observed what looks something like a “reverse sandwich attack” whereby a 100% reward cut indexer whose only delegators are their own delegated funds will drop their cut to 0%, settle onchain to get all rewards including indexer rewards, put the cut back up to 100% and re-allocate. This is a clever way of retrieving the indexer revenue and only suffering the delegator thaw rather than the complete 28 day shutdown of the indexer. This is probably not healthy for the network and might become prevalent among lower delegation indexers if times get tough meeting operational costs.

4 Likes

I agree, if nothing changes, we will see more indexers who are engaged in unhealthy similar behavior and this will further confuse delegates who, due to all these frequent rewards cut changes, will be afraid to delegate.

2 Likes

Hi Brandon,

Great that you have started a conversation on the subject! I believe this is an issue for an indexer of any size and type.

Let me express my view on the fees and rewards:

First of all, indexing rewards as well as query fees should either restake automatically (default behaviour ), or not restake optionally. As per the issue thread here the INDEXER_AGENT_RESTAKE_REWARDS=false seem to be designed to work only for the query fees, which is not fully understood why indexing rewards are not subject to the same logic.

Secondly, while 28-day unstaking period make perfect sense for GRT staked on the protocol, there seems to be no reason for the rewards to follow the 28-day period if those are not restaked automatically. Also, the logic introduced by recent indexer-agent update to collect query fees by defined threshold can be a tactical way to explore, for the indexing rewards withdrawal as well.

Finally, the race to the bottom on the rewards cuts reinforced by the biggest indexers, may encourage smaller indexers to convert fully or partially into delegators. Cost/benefit analysis may trigger even stronger signal for the above as more subgraphs are introduced, and/or global market conditions change.

As it currently stand, it is a delegator’s market, which is indeed a good support for the GRT price. However, as the fundamental idea for The Graph Network to be a query market, indexers who’s role, effort and risks are not comparable with delegators should stand in better off position.

Having flexibility to withdraw rewards would encourage indexers to invest in infrastructure and services to better serve our ultimate customers (dApps).

Regards,
vict@grassets-tech

3 Likes

I think if we had a function to set a rewards destination (beneficiary) that an indexer could set, then the Staking contract could check if the rewards should be sent to a different address after minting them instead of re-staking. I’ll write a proposal in a different post.

11 Likes

Brandon, thank you for initiating this.

You are right that early Indexers are unduly and unnecessarily restricted in accessing earned rewards that they will need to pay for ongoing operational costs as well as providing them compensation for the significant amount of time necessary to set up and manage a competent indexing operation.

To have only one path for accessing these rewards that necessitates effectively dismantling the indexer operation for 28 days is bizarre. It clearly cannot be what was intended and should be classified as a bug. Given the fact that this bug may drive smaller indexers out of the protocol if they cannot get hold of their rewards to pay their costs it represents an existential threat to the network and should be regarded as critical and dealt with urgently.

Ariel’s approach of setting up a rewards distribution function sounds as if it may be a good way of resolving this problem. It would be nice to understand both how long this would take to implement and what other options there may be.

It is indeed a delegators’ market at the moment which is good for the delegators and the price of GRT but we should not overlook the prime objective of building a sustainable query market. We will only do this by properly motivating Indexers; at the moment we risk losing them.

5 Likes

Tax liabilities

To expand further on my colleague’s comments. There is also another dimension that has been overlooked so far and that is tax liability. Indexers in most jurisdictions will be required to calculate tax due on the assets they receive as income, priced at the time of receipt. Therefore most Indexers are now incurring significant tax liabilities and this is particularly precarious with markets that are no stranger to significant price volatility. If the market moves against Indexers by the time the rewards are actually liquid this could not only erode profits but has the potential to generate substantial losses!

The only sensible approach for a responsible business is to be liquidating the tax due on each reward as close to time of receipt as possible, to minimize downside risk.

Therefore, whilst there may be some Indexers, such as ourselves, who are self-hosted and can afford to underwrite operational expenses for a longer period than say smaller indexers using expensive pay-per use cloud services, it is unlikely many would be prepared to tolerate this signficant tax liability exposure for a protracted period and in my view this needs to be treated with the utmost urgency.

Ariel’s solution sounds fantastic for dealing with future rewards but what do we propose we do with those rewards that have already been earnt (and have incurred a tax liability)?

5 Likes

Hi Brandon and team,

I am in agreement that this is a good idea. I was under the impression initially when embarking on becoming an indexer that rewards would be available to cover infrastructure costs as well as supply us an income to cover the time spent towards maintaining our service (including cost modelling, optimisation etc.)

As an individual enthusiast that does not have the backing of a team or alternative source of income other than my day job to keep things running I am not sure that I will be able to compete with keeping my indexing service up to the competition, which would be a shame as I really would love for this to be an opportunity I embrace with as much effort as can be made available.

I would appreciate you employing a solution to allow us to withdraw rewards without taking ourselves offline, as the penalty for doing so is absolutely something I would not want to incur to myself as well as my delegators.

Thanks

9 Likes

I agree with the others that this impacts the majority, if not all, indexers that are utilizing their GRT through the vested contract.

The largest issue on my end is not having the ability to scale up in preparation for the future. I’m fortunate enough to have a paid off server and operate a local archive eth node, so my opex is relatively low. I am currently looking to upgrade infrastructure in preparation of providing the best service possible but if I wanted to do that I would have to sink in a large investment out of my own pocket. If I were to withdraw current rewards, I risk losing Delegators and also the relationship/reputation that comes with that among other losing factors.

Aside from not being to upgrade/scale up, it is tax season coming up, and most will need these rewards to be able to properly pay taxes.

Personally, I think this needs to be addressed as soon as possible or more indexers will be forced to conduct unhealthy behaviors such as the ‘reverse sandwich attack’ brought up by @cryptovestor.

4 Likes

Tax-liabilities - is the most important reason. When you receive a “benefit” you will be taxed. The benefit is you have a higher stake and therefor can generate more GRT (even if they are locked).

Would be nice if we could set some percentage to go somewhere else than the contract, as most still have an interest to increase contract stake and delegation-cap.

3 Likes

I like the idea of partial redirecting, be it percentage of fixed number, while keeping the rest on auto redelegation. The usecase is there and it helps for gas cost if this is part of the feature.

3 Likes

Hey Everyone,

Ariel’s suggestion for implementation would not allow for recouping already earned indexing rewards. It would only work going forwards from when a contract upgrade is completed. We will brainstorm a bit more about if it would be possible to get these rewards out. But due to the token lock contracts not being upgradeable, it means we are quite limited in what we can do there.

How soon can we implement this? There are some things we need to do:

  • Write the smart contract upgrade (probably the shortest amount of time)
  • Set up a robust upgrade procedure so we don’t screw up the upgrade
  • Use this procedure to test the upgrade on the testnet
    • Get the testnet up and running so we can actually do this (we are half way there)
  • Once we are happy with how everything is, send an upgrade proposal to the Council
  • Council approves
  • We Upgrade on mainnet
  • One more thing to add - There are other upgrades that are important, and upgrades are laborious, so we might want to fit in 2 or 3 updates, which would slow down this upgrade.

As you can see, there are still some key things we need to set up. This is a result of launching so recently. In the future, these processes will be more ironed out and upgrades could happen quicker.

I think this is one of the most important upgrades. We should start moving quicky on all of the above, so that we can get this done ASAP.

Side comment on the taxes:

I would recommend to all to speak to an accountant if the sums of money get very high for tax implications. Each country is different, and the laws here are pretty new, and often not fully figured out by governing bodies. For sure there are some Indexers who have done their due diligence, and 100% know they must pay taxes. This is more so a message for people who may be learning of this for the first time. Everyone’s tax situation is unique, so it is worth it to figure out what your country expects to do. And how they treat a token that is truly in your possession to sell, or one that has been sent to you, but is still locked, etc.

5 Likes

Wouldn’t it be smarter to first get council decision ? In case they reject the rest of the work is void.

1 Like

In general, your point is a good one. GRPs should be submitted before lots of work is done.

In this case it can be assumed the council will already be aware of the upgrade coming along - in fact I think they already are.

2 Likes

I will support a quick, incomplete solution (like allowing withdraws from now on), over a perfect solution (withdrawing all accrued rewards) that would take several months to implement.

Let me simply reiterate what fellow indexers said previously: most small indexers will need the rewards to be able to invest in scaling their infrastructure to be able to compete during the first year of mainnet. Delaying by several months will handicap small indexers to the benefit of large players with deep pockets, and ultimately hurt the network.

Indexers are counting on mainnet rewards to:

  • Reimburse testnet investments (equipment, cloud credits, time)
  • Pay the current, arguably small, mainnet fees (similar to testnet expenses to which we must add ETH gas costs)
  • Invest time and resources in tooling, scripts, equipment, testing, etc. to prepare mainnet scaling
  • Pay future bandwidth and cloud credits when mainnet traffic is turned on
  • Pay their ever-growing tax liability

With 0 cashflow until December 2021, many indexers won’t be able to make it. Luckily, I’m among the indexers with enough resources to keep the lights on for a while, but I’m currently holding back on major investments until a conclusion is on the horizon.

6 Likes

I would like to second the sentiment that nuviba expressed that a quick solution that would allow withdrawal of rewards from hereon would be good to have as an interim sooner rather than later.

4 Likes

Hi, Dave.
Grassets-tech will be happy to help you with test-net.

If you need any help, please let us know.

Best regards,
Grassets-tech team

2 Likes

Hey dave,

Good to hear this, we were always under the impression the generated rewards would be available directly more or less.
We from the p-ops-team (myself and @mindstyle_p-ops ) are willingly to assist you with the testnet when needed!

Let’s make this work asap :+1:

3 Likes

I totally agree with what nuviba said, decentralization in danger if small indexers fell off because of the inability to support infrastructure long enough without getting rewards.

2 Likes

At Chainode Tech we are also in favor of a quick but not perfect solution that will allow at least a part of the indexing rewards if not all to be withdrawn to a separate address.

There are many reasons for this:

  • paying operational costs;

  • paying infrastructure costs;

  • have a network of healthy indexers that can operate under safe conditions on proper hardware and don’t behave malicious for this purpose

  • paying taxes;

The list can probably be expanded but the reasons above are really major to search already for a temporary solution. For tests we are ready to support the team on the new testnet.

Best,
Chainode Tech Team

4 Likes