Great work on this proposal @ari !
I also think the most fair decision for all participants in the network will be both indexers and delegators to got their rewards. Indexers deserve their rewards since they have their cost per month for infrastructure and because they put a lot of work for keeping the network alive, but also they get they % from delegators reward. Delegators are also important part for the network and tax issues is a problem also for them not only for the indexers, big part from the delegators trusted in Graph in the very beginning and risked their own capital and even the people who managed to be part from the Graph after the mainnet have risked even more. The most honest way for all participants is both indexers and delegators to have their rewards transferable not just benefiting one part of the network’s participants.
1 Like
Who should make the proposal? How are upgrades handled? Super excited to get the ball rolling. The PR looks good nice work @ari
How soon can the implementation of this be deployed to the testnet? I assume this can happen in parallel to the governance processes being established.
1 Like
Anyone can make a proposal.
Proposals only get presented to the council, and then given an official number such as GIP-1, by editors. The exact details of how this will all work will be published soon, but the idea is that anyone can make a proposal, and then there is a filtering process to make official GIPs, as to not overload the council with numerous proposals from anyone
It is being done in parallel.
Probably no more than a few days
1 Like
How will initial implementation be done ? If you do nothing, everything keeps as it is, automatic restaking of indexer rewards ? Or will everyone need to take action before their next allocation close ?
By default not changing the settings would keep the re-staking behaviour. Once you set a change in the rewards destination it is used for every allocation closed.
1 Like
These are two alternative implementations we are evaluating:
-
Direct send of rewards to a destination address on close allocation
https://github.com/graphprotocol/contracts/pull/450 -
Deposit into a rewards pool on close allocation
staking: set rewards destination using rewards pool by abarmat · Pull Request #451 · graphprotocol/contracts · GitHub
The first one is a simpler implementation, the second one introduces a rewards pool where all rewards goes and then the indexer needs to withdraw them from there.
The reason for evaluating this is UX and gas costs.
Solution #2 is a bit more efficient when closing allocations as it takes less gas to update the rewards pool than to transfer, but the savings depends very much on how an indexer operates. Gas usage is also dependent on whether the pool or destination address is empty or not as an SSTORE on used storage takes less gas.
Gas Benchmark
closeAllocation()
- #1 direct destination-address-no-balance: 271898
- #1 direct destination-address-with-balance: 256886
- #2 rewardsPool no-balance: 265438
- #2 rewardsPool with-balance: 250438
For option 2, gas usage also needs to take into account the actual withdraw TX ?
Any thoughts on setting a percentage between restake and RewardDestination ?
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 ?