Rewards destination for indexer's indexing rewards

Yes, option 2 adds more gas when doing a withdraw, so it ends up being more efficient only in the cases where an indexer waits and bundle multiple rewards sent by closeAllocation into a single withdrawal.

Personally I would prefer option 1, this would make calculating taxes far easier as we can use a tool like tokentax or similar to monitor a receiving address and calculate the value of GRT at the time at which it is minted and received by our wallet.

The gas savings for implementing option 2 seem negligible in ariel’s provided benchmark and may be negated by the cost of the withdrawal transaction until we are batching up many allocations worth of rewards to withdraw.

3 Likes

In case of Option 1, would it be 2 x tx: one to close allocation and one to send reward to wallet? Who will pay for second one (Operator?)? What is the gas estimate?

In case of Option 2, seems to be more flexible where Indexer would accumulate their rewards and then transfer in one transaction (btw would it be called via Remix?).

Currently, for claim rebates there is a key INDEXER_AGENT_ALLOCATION_CLAIM_THRESHOLD: XX to set up threshold where Indexer can manage whether to claim or not - which is flexibility.

From flow control perspective I would propose to keep allocation closure and rewards transfering to external wallet in 2 separate calls (Option 2).

As today it seems to be pretty simple and straight forward to transfer rewards along with allocation closure, but in the future having/closing multiple allocations could cause unpredicitble confusion, mistakes etc

Could you please elaborate flows for both Options and for Rewads and Query Rebates, for instance:

Option 1.

  • Allocation Close ->tx to protocol → tx transfer Rewards and Query Rebates (Query Rebates Pool) to wallet
  • Claim Query Rebates (threshold) → tx to protocol → Query Rebates Pool

Option 2

  • Allocation Close → tx to protocol → Rewards Pool

  • Claim Query Rebates (threshold) → tx to protocol → Query Rebates Pool

  • withdrawRewards() → Reward Pool and Query Rebates Pool → tx transfer to Wallet

Regards,

@davekaj Can we get an update about the current status and ETA of making the rewards available for indexers (and maybe also other delegators with vested contracts, like curators)?

It’s now been a while already and I’m just curious!
If there’s a link available where we can follow the progress let me know.

Thanks in advance.,

JB

I posted some data about gas estimation on a previous comment in this thread. Any call to closeAllocation() or claim() are managed by the Operator.

The flows would be like:

A) Flow Option1 (Direct)

    tx1 -> closeAllocation() : Operator
        - If a rewards destination is set:
            -> send rewards to destination address
        else
            -> send rewards to stake

    tx2 -> claim() : Operator
        - If a rewards destination is set:
            -> send rewards to destination address
        else
            -> send rewards to stake

B) Flow Option2 (RewardsPool)

    tx1 -> closeAllocation() : Operator
        - If a rewards destination is set to rewardsPool:
            -> send rewards to rewardsPool
        else
            -> send rewards to stake

    tx2 -> claim() : Operator
        - If a rewards destination is set to rewardsPool:
            -> send rewards to rewardsPool
        else
            -> send rewards to stake

    tx3 -> withdrawRewards(destination) : Indexer
        -> send rewards from rewardsPool to destination

    Note: tx3 must be called by the indexer, in the case of TokenLocks via Remix
2 Likes

Hello all Indexers and Delegators,

A great discussion has started for a proposal on allowing delegators to realize their rewards, similar to how this proposal works for indexers. It can be found here Delegators rewards should be withdrawable to a separate address

This is great, as it allows us to speak on the two proposals separately on discourse, rather than mixing them together in this proposal.

Go and check it out!

We hope to get the contract upgrade on testnet today.

After that some testing - maybe for a week. We will need to test with Indexers on testnet, volunteers are welcome!

Then an official GIP created and presented to the council. From last I heard the council will vote asynchronously which is good for speed.

It is hard to promise anything but maybe ~2 weeks. As we get closer , we will be able to provide more accurate timelines. There is always the possibility of delays.

4 Likes

Hi Dave,

Just to let you know that I have tested the new contract on testnet and it has worked as expected (ariel’s option 1). I also had a rewards cut split set and the tokens were divided as they should have, with the indexer’s rewards being sent to the rewards destination wallet and the delegates rewards being made available for reallocation.

If there are any other scenarios you’d like tested please let me know, happy to help. I am very happy with this implementation by the way, thankyou.

2 Likes

Thank you dancube. The code is running on testnet since Friday night, anyone participating in testnet can test it by first setting setRewardsDestination(address) and then closing allocations should send funds to that address. To set back to re-staking you can setRewardsDestination(0x0).

You can get current testnet contract addresses from contracts/addresses.json at v1.1.0 · graphprotocol/contracts · GitHub

2 Likes

Hey guys, can we have actual ABI (json) there also GitHub - graphprotocol/contracts: The Graph Protocol ?

ABIs are generated from the repo and placed in the /build folder when you do npm install && npm run build.

You can get it from this gist too Graph Protocol - StakingV2 ABI (indexer-rewards) · GitHub

I’m just playing around with developing golang cli tool to manage allocations to be free from all these npm stuff, so if there will be a chance to have up to date ABIs inside repo that would be nice.
Thank you for gist!

I have tested setting the rewards destination address to ‘0x0000000000000000000000000000000000000000’ via remix and it has indeed reverted the behaviour back to re-staking instead of distributing to the previously defined address. :+1:

5 Likes

Worked for me as well, gas used 243,291

5 Likes

So,
Did we finally decide to go with Option 1 - direct tx to destination?
Are we planning to test Option 2 then?

Regards,

These are the mainnet addresses.

No, they’re not.
They’re Rinkeby.

EDIT: correction, they’re both mainnet AND rinkeby

Everything that’s under "1": { is chainID 1 which is mainnet.
Everything that’s under "4": { is chainID 4 which is Rinkeby

1 Like

Status update:

  • Testing by the community of indexers on testnet so far has showed no errors. Everything looks good.
  • Preliminary audit report from open zeppelin looks all good, only minor changes, mostly around documentation.
  • On track to do a snapshot vote this week on this proposal.
  • We are testing a safety script for updating on mainnet which is looking good.
  • The GIP process was laid out in the Townhall today, so now everyone should be able to understand how we will get this proposal to the Council.

So in summary I would say all the heavy lifting is done. It is mostly just coordination of all these moving pieces, and then also being extra careful with the actual upgrade on mainnet.

It is kind of hard to provide a final date for any of this stuff. I personally don’t really have any say here - ultimately it comes down to the council passing the vote. Once that is done, Edge and Node can deploy the fix to mainnet.

But, as someone reading through this forum and understanding what all of the moving parts mean, if I had to guess, maybe end of week next week?

I think overall as more GIPs are passed, everyone will understand the timelines on these proposals better. Even from the councils perspective - this is their first proposal they must vote on. Some of them are very busy with their full time jobs and likely the coordination around the vote might take a few days longer than it will in the future when these processes are streamlined.

8 Likes

We went ahead with testing option 1 as it is a simpler implementation, it requires less interactions, one less state variable and the gas reduction was not that great with option 2. We could make it more complex on a new version if we all find it necessary.

1 Like

Hi Dave,

How is the snapshot coming along?

Will the council await to see the results of this before voting themselves? If so, will the snapshot need to be left open for a given window before they can use that data?

How is prep for the mainnet upgrade look? Did the safety script perform as expected in your tests?

Thanks,
Dan