I think we can all agree that indexers being able to withdrawing rewards without unstaking is not the problem.
However, withdrawing rewards without a thawing period might create a correlation between “rewards remaining in the network” and “token price”. E.g. a surge in price might create a surge in withdrawals, while a decrease in price would keep the rewards in the network. Letting the market dictate actions taken on the network probably isn’t a good thing. A thawing period could prevent this.
1 Like
Indexers won’t be able to withdraw rewards that have been re-rolled back into the stake.
They’ll have a switch between keeping rewards in-protocol and locking them, or having the rewards sent straight into another wallet.
Meaning, if I make 1M GRT whilst having the option disabled, I won’t be able to take them out.
We’ll only be able to withdraw future rewards, with the option active. That option is completely up to me as an indexer, if I set it on or off.
But more often than not you’ll have to restake in order to maintain your network APY and not get outpaced by other indexers that have that option active and continuously compounding their rewards. 
I don’t mind to have a thawing period, but I find it unnecessary, and Ariel also said the same.
5 Likes
Alright, that makes a lot of sense and makes thawing kind of stupid to have. I was under the impression the already compounded rewards would be withdrawable after the GIP execution. Thanks for clearing that up. I think a lot of people misunderstand this, judging by the heated discussions on 3rd party channels.
4 Likes
Yes, I think the GIP should’ve been presented in a better fashion tbh.
I also notice a lot of misunderstanding and confusion around it.
1 Like
If indexers get to bypass the 28-day thawing period, then wouldn’t that place delegators at the mercy of indexer actions in the market? I think a fairer approach would have been to allow delegators to do the same as well.
Please re-read the thread and review the GIP, you don’t seem to understand the proposal.
You’re right. The phrasing of the proposal made it sound that way. Makes no sense to have to un-delegate everything just to get rewards. On board with this.
3 Likes
I am new here but I think without a % parameter, it is too cumbersome to enable and disable this setting as needed to cover operating costs / income every few months.
It would make much more sense for this use case to set a % of the rewards to be sent to the external wallet that is enough to cover that, and compound the rest.
Otherwise would have to spend gas to compound again.
Will this be considered in the future? Or am I missing something?
I don’t think so. It is simply an update to the staking contract, 1 value.
The gas fees for doing this are fairly paltry as well, it cost me $8 for a transaction to this contract today.
I think that allowing a split like this would likely increase the gas cost of each allocation closure, and increases the complexity of the solution unnecessarily. The proposed solution has been audited and tested on mainnet, and is being widely accepted in the snapshot vote in its current state.
But this parameter can be changed anytime or only between allocations?
If anytime its ok, but if its after 1 month, the % of rewards that need to be set aside may be small and so would need restaking of the rest every month to compound.
Its ok but I don’t see why its that complex, instead of a boolean value it would be a % number, and its a simple multiplication to get the amount to send to the address instead of all of it.
Its like one extra line of code.
But fair enough…
It can be changed at any time.
1 Like
Sorry I got the old discussion thread confused with this proposal and hadn’t seen the code.
I understood this only runs on closeAllocation.
So by running setRewardsDestination before every closeAllocation we can set aside rewards per allocation.
So in principle we could make an allocation that is about the right size for the rewards that we need to take out, and have all other big allocations compound.
Is this a good approach?
Thanks
I agree, I am all in favor of letting indexers get access to their rewards to cover costs but bypassing the 28 day thawing period would open up the possibility of indexers operating to optimize on short term market conditions and not long term health of the network. I don’t see any reason why there is a need to bypass this period. If the indexers are the complex operations that they claim to be I see no reason why they cannot plan out 28 days in advance
5 Likes
I had actually suggested to have a % restake-withdraw, it didn’t get implemented. The way it works is not by boolean, but by string, a.k.a. an address being set (or 0x0 to automatically restake).
To me, the argument there isn’t about them being able to react to price movements (they could just wait for their target price). It would be more about them being able to repeat these steps without a 28 day lockup slowing them down.
The problem is, this is also part of a bigger issue and separate proposal - the need for a better parameter cooldown (and maybe reputation) feature that protects Delegators from bad actors and allows Indexers to signal good intent.
1 Like
I wasn’t disagreeing with the point you were making. I was saying that a bigger issue (imo), in addition, would be that they could remove that stake (maybe wash it via exchanges) and reintroduce it as a ‘new’ indexer (address) without the 28 day period.
And then the issue is - how to prevent bad actors rejoining the Indexer set and attracting Delegators so easily, even if it’s a case of 1 day, or 28. But i was actually adding somewhat to your concern. I’m not sure the complete solution for either case is found within the bounds of this particular proposal.
And “better than the alternative” also depends whether you think that scenario being able to play out overrides the need or want that Indexers have voiced for the proposal at hand. It’s not so clear cut.
As i’ve said before, I would have prefferred a thaw period on this mechanic, too.
remove that stake (maybe wash it via exchanges) and reintroduce it as a ‘new’ indexer (address) without the 28 day period.
That’s not possible. They would have to earn 100k in rewards to start a new indexer. Then, the new indexer starts with only 100k stake, which means they certainly won’t earn 100k rewards for many more months.
The time and effort to recruit new delegators, and the service operation time for query selection ensure that this “exploit” is not worth the effort.
2 Likes
Hey all, The Graph Council met to discuss GIP-0002 yesterday. Full meeting notes are incoming, but I’d like to post a quick update from E&N’s perspective since I know a lot of folks are eager for more information here.
First off, I’ve loved seeing all the thoughtful and civil discourse on this issue. Thank you!! I’ve tried not to put our thumb on the scales of the conversation too much, so as to foster as much community input as possible (would welcome feedback on this approach!).
Second, I appreciate everyone’s patience as I can confidently say this has taken longer than I think any of us would have liked. There’s been a substantial amount of work to get The Foundation and Council’s governance tooling and processes in place, and for our (E&N’s) part, switching modes to contributing to The Graph as external contributors has been a learning process as well. Finding auditors’ time has also been extremely challenging, given the recent renewed interest in crypto, but we are working on getting multiple retainers set up so that we have dedicated auditor time blocked out for future protocol changes. I expect this process to become much smoother in the future.
After synthesizing all the ideas discussed here, as well as the Snapshot poll we came away with the following main takeaways:
- There is nearly unanimous support for giving Indexers a way to withdraw rewards to cover their operational expenses.
- A number of Indexers and Delegators see the removing of the thawing period for Indexers’ indexing rewards as problematic.
In response to this, and the specific points made, the Edge & Node team has started working on an alternative proposal and we (Yaniv and I) made the following recommendation to the rest of The Council, which they agreed to:
Defer making the upgrade described for a little while longer so we can evaluate it against an alternative implementation that allows Indexers to withdraw indexing rewards to a separate address, but keeps the 28-day thawing period.
We recommended this plan for the following reasons:
- While it was never the intent of the V1 protocol for Indexers’ indexing rewards to be locked for withdraw, it was also never the intent of GIP-0002 to shift the power dynamics between Indexers and Delegators. One of the principles laid out in the original Graph Council blog post was to avoid zero sum games and so we have a responsibility to at least evaluate an alternate implementation that accomplishes the same result as the original proposal without introducing a zero-sum game.
- Allowing indexing rewards to be withdrawn immediately could lead to erratic or unpredictable allocation opening/closing behaviors as Indexers attempt to time the market for selling indexing rewards.
- Allowing indexing rewards to be withdrawn immediately, but not Delegators, could lead to extra-protocol arrangements in which Indexers agree to immediately share indexing rewards with their Delegators. This could provide a vector to centralization and protocol disintermediation.
As some of you have already noticed from commits in Github, Ariel is working on a reference implementation of this alternative design and we expect to have a GIP (0004) published on Radicle within the next day or two.
As noted earlier, The Council consented to delaying the GIP-0002 upgrade until we have a chance to evaluate against the alternative proposal. Part of that evaluation will include the timeframe on which these proposals could be rolled out: A major pro in GIP-0002’s favor is that it has already been audited by OpenZeppelin. GIP-0004, on the other hand, is still pending an audit—and as noted earlier getting these audits scheduled has gotten substantially more difficult.
I take the time consideration seriously and would not personally support delaying on GIP-0002 if it meant Indexers waiting substantially longer to claim their indexing rewards. I hope to have more information on the timing of audits by EOW. The Council is meeting again in two weeks so it can move quickly on whatever approach ends up being decided.
One possibility could be to upgrade to GIP-0002 in the near term, and then upgrade to the alternative approach in a second step, though this introduces additional overhead and bloats the smart contract state as a result of the additional proxy upgrade.
Stay tuned for full meeting notes from the Council. I’ll link to them here, once they are available.
10 Likes
I want to thank everyone on the graph council and E&N for taking the time to decide the best approach! It really makes me, as a delegator, feel great about the graph over the long term! 
4 Likes
Hi Brandon,
Thank you for the update and the time and effort you have put in to this issue so far.
Like many, I am deeply disappointed in how long this is taking, and there are legitimate concerns that some people are simply not be comprehending the gravity of a situation in which the majority of small indexers may be forced to leave the protocol.
Our Indexer operation, like many others, has already incurred significant tax liability for rewards credited so far. Once past the end of our tax year in the UK (April 5th) this will be “locked in” and if we see a subsequent deterioration in token price we will not be able to efficiently offset this liability and may end up needing to sell all future rewards in the short to medium term just to meet this.
Unsurprisingly, we are beginning to see some Indexers actively discussing winding up their operations - just to get access to their rewards now. We are at real risk of losing capable small-indexers, and moving slowly, including waiting for another council meeting in 2 weeks, is really no longer a viable option if we are to avoid this.
To take the reasons you have cited for delaying further:
1) Not wishing to shift the power dynamics between Indexers and Delegators
- Given the prospect of imminent changes to provide delegators access to their rewards without a thaw, which we support, I don’t see this as a big-issue. Indexers and Delegators perform different roles and it is not unreasonable that there may be differences at times between them.
2) “Allowing indexing rewards to be withdrawn immediately could lead to erratic or unpredictable allocation opening/closing behaviors as Indexers attempt to time the market for selling indexing rewards.”
-
I think this is a non-issue, Indexers are expected to optimize operations by responding to the market for other aspects of the protocol eg. reallocating based on curation signals, adjusting query pricing in respect of demand, so why there is concern that an Indexer may also take the GRT market into account?
-
The only sane way to run a business and manage tax liabilities requires making sufficient token sales to cover tax due, as close to time of receipt as possible. By ensuring rewards are liquid as soon as possible you are enabling good business practice, which should help build a robust network. 28-day thaws, applicable only to the initial stake to dampen stake volatility, make sense, but this logic should be completely separate to that applied to rewards.
-
A lot of concern seems due to unfounded worries that somehow GRT price may be negatively affected by Indexers having access to their rewards. Our job as a community should not be to try and manage the GRT price - it will always be subject to a complex mix of factors outside our control.
-
Large wealthy indexing operations can already access tools to manage their exposure and limit tax liability (and potentially influence the GRT market) through short-selling GRT when they receive locked rewards. By passing GIP-0002 you will enable even the smallest Indexer to manage their exposure and tax liability, without needing potentially expensive access to these tools, thus actually increasing fairness in the protocol!
3) “Allowing indexing rewards to be withdrawn immediately, but not Delegators, could lead to extra-protocol arrangements in which Indexers agree to immediately share indexing rewards with their Delegators. This could provide a vector to centralization and protocol disintermediation.”
- Sufficiently wealthy Indexers can already engage in this behaviour! By passing GIP-0002 you would actually level the playing field and enable all Indexers, regardless of size to be able to do this if they wished, again increasing fairness in the protocol. The prospect of imminent changes to provide delegators access to their rewards without a thaw would effectively discourage anyone from going to the effort of doing this though. However, if we end up in a situation where we don’t pass GIP-0002 and instead opt for both Indexer and Delegator rewards to be locked for 28 days then you actually increase the risk of centralization and protocol disintermediation happening through the route you’ve described!
Therefore, in the strongest possible terms, I encourage you to pass GIP-0002 as soon as possible, so Indexers can cover their long-overdue expenses and those in in tax jurisdictions with similar rules and fiscal year to the UK can get access to some rewards before the end of their tax year (April 5th) to minimize a significant downside risk. We have already had an overwhelming vote for this outcome, if we are not going to respect that, why did we wait yet another week for it to conclude?
19 Likes