Rewards destination for indexer's indexing rewards

That would be even better! But I assume that ariel came up with the idea of a separate withdrawRewards() call to save gas, or because it simplifies the implementation, hence would make this change faster to deploy and less risky.

1 Like

I understand very well the desire of the indexers, delegators with vested contracts not to get access to their reward without the 28 thawing period but keep in mind like you spend your personal money to keep the network alive, the same way they trusted in the project and they’ve put significant amount of money too and they deserve to be able to get rewards in my humble opinion. Other thing is with some of the vested contracts when the time comes and depend on the contract there will be a problem when you get your first unlock you won’t be able to keep delegating if you want to move your unlock, so thats going to be another problem. In my opinion the changes should be made for all vested contracts not only for the indexers, they keep the network alive, but a lot of delegators with vested contracts believed in the Graph before it went on mainnnet and they also deserve their rewards.

P.S. The idea of thawing period is not to prevent delegators with vested contracts not to get their rewards, in the end the delgators should have the same rights with vested contract or not, at the current state there is difference between delegators and delegators with vested contracts, it makes sense to stay like that as far as all vested contracts has the same rights, but not if some of them don’t.

No changes are proposed to any token lock contracts.

If you wanted access to your GRT as it is unlocked by your vesting contract you should not have delegated the entirety of it (I assume this is what you have done).

1 Like

Bare with me, i am not tech guy, i just want to say if indexers have access to their rewards, like the delgators have, should be the same for delegators with vested contracts.

It sounds like you are wishing for a change to be made to all delegation behaviour, as the 28 day thaw period after undelegation to withdraw rewards from the network applies to all delegators (token lock contract or otherwise).

Delegators giving their 2 cents should bear in mind that while they share the same opportunity costs as Indexers on their collateral, they don’t bear the weight of ongoing expenditure opex for infra and gas. This proposal is an attempt to rebalance an already imbalanced situation that was not intended for mainnet in the first place.

That said, i wouldn’t mind if we also had to thaw our rewards, but that means additional gas and also the risk of price changes at the start/end point of thawing. Not to mention the tax-related issues already mentioned.

Delegators should consider, when giving their opinion, whether they want the costs of the above risks passing down and eating in to their own returns, because that’s what will happen. And at (currently) 21.5% of the network stake, the effect on the market from Indexers having this benefit would also be lessened, compared to allowing it for all. Not to mention already likely quite steady from some opex costs being naturally returned on an ongoing basis.

Let’s not forget that this is what the aim is here - to allow Indexers, especially smaller ones, to continue to function. And are people really opposed to the additional risks and efforts taken upon by Indexers having some kind of benefit returned anyway? If so, i’d remind you that anyone with enough stake could join team Indexer if they feel the odds are tipped in their favour at any point in time.

Incidentally, this would be a big plus for the network, so by all means, please consider it. :ok_hand:t2:

5 Likes

@ariel and @davekaj,

In an attempt to bring this conversation back on topic, what are the next steps here? I suppose you will want to give some more time for those affected (Indexers) to chime in with their thoughts but assuming what you’ve suggested is generally accepted will it then be deployed on testnet?

1 Like

The thawing period for indexer’s stake is a mechanism not mean to manage liquidity in the protocol but a way to provide security to avoid an indexer easily avoid being slashed by removing the stake immediately before a dispute is accepted.

Koen, thank you for the feedback, I see your point.

These are the reason for the proposed route:

  1. When we added the operator key feature we thought it to be used to perform operations that do not take tokens out or in any of the protocol contracts. All the functions that can be called by operator just move tokens already deposited to different allocations, or frees them, while the main indexer key is used for token-external operations.

  2. We considered that pulling tokens out by calling a specific function like withdrawRewards() is what we see in most UX where you claim accumulated tokens from a protocol, it is easy to understand and provides a way to explicitly check and set the beneficiary before you send the transaction.

  3. I’ll do some calculations of gas efficiency, if you withdraw a number of accumulated rewards from multiple allocations it would mean just the cost of one more SSTORE.

Hi Dan, we are already working on a PR with the implementation + tests while we monitoring the forum from good feedback from all of you :slight_smile:

We hope to be doing some local tests this week and maybe deploying to testnet next week while we prepare some governance tools.

Thanks for your response. In my suggestion it would still be the admin key that pre-sets the destination (until changed). So the ops key would only trigger distribution according to those instructions. But i understand that could still potentially shift the distinction / security.

Hi everyone,
I am not a tech person. I believe that the team will find the best solution. What I want to indicate is that The Graph Protocol should preserve its elasticity. Wrong decisions and errors are inevitable. But the Protocol should develop with trial-error-error elimination. But firstly on testnet. MHO :raised_hands: :slightly_smiling_face:

2 Likes

We (p-ops.eth) agree in general with the proposal made and will be available on to test this on testnet if needed.

Keep up the good work!

Yes, preparing governance tools so that all members of the community can have their voices heard. Of course this is a proposal for Indexers, but we expect feedback from Delegators, and in the future Curators and Subgraph Developers as well. Each stakeholder is important to the system - and so to see the discourse between delegators and indexers is a sign of a healthy network! :slight_smile: Delegators should be asking questions as to whether or not this is a fair proposal for them.

Ultimately the vote comes down to the Graph Council, whether or not it get’s implemented, which is something the community should begin to understand as we have the first vote.

How would voting process look like? Would we vote as per our stakes or all voices are equal? Would it be on chain or off chain?

We are still working on the governance process, but we are using Snapshot.

We will have different voting strategies for different stakeholders.

Likely for this proposal we will have a vote for all GRT holders to participate.

The final result of the vote however does not determine what will be implemented. The results of the vote are used as information provided to the council to make their final decision more informed.

Hi Dave,

Can I ask whether the vote will be in the way by which the fix is implemented and not on whether the fix should be made?

1 Like

Sorry for the off-track @davekaj but If there is no obligation to implement the will of people in a snapshot poll, does it really bring utility to have one on such a technical issue?

This forum thread contains thoughtful responses to pro’s and con’s- that should provide more than enough context for the deciders to make a decision, no? A token weighted vote, instead of a collection of thoughtful considerations feels a little like decentralization theater no?

The net outcome is, “The people can vote for whatever they want as long as they vote for what we decide”.

Food for thought.

2 Likes

At the moment there are no options chosen for the vote

1 Like

Using snapshot is a tool in the toolkit of fair decentralization and representation. It is another way to get feedback from the community.

We’ve researched many different protocols and how they have chosen to do governance. Some, like YFI, do token weighted voting. Others like Synthetix, use a council, similar to us. The Graph council was laid out in this blog post - Introducing The Graph Council .

Both snapshot and discourse provide different feedback mechanisms to help The Graph Council make the best informed decisions.

3 Likes