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.
9 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
We absolutelly agree with prev post espcially having the exciting news that new subgraphs are coming on mainnet which would lead to significant operational costs increase.
3 Likes
Thought I’d just knock this timeline together to give a bit of perspective on how this will impact indexers.
This is what I would consider the optimistic scenario for GIP4 progressing to making rewards available to indexers - that is an audit available within a timely manner and no delays relating to testing the implementation (bear in mind that GIP4 is a more complex solution than GIP2 so expect additional overhead here).
We are looking at approximately at least 3 more months of delay for indexers to start to cover (or recover) expenditures relating to opex and tax obligations. During this period indexers are expected to not scale back their operations but in fact expand on them both from a hardware perspective and ETH as well due to the migration of subgraphs to mainnet, incurring costs higher than seen previously throughout the 9 months of mission control+mainnet.
@Brandon and @yaniv , can I please implore you to make a decision on whether GIP2 can act as an interim solution as soon as you find out when audits can take place (I believe this may ultimately act as the deciding factor?). Brandon, I believe you mentioned you will find this out towards the end of this week.
13 Likes
Completely agree with your thoughts. 
1 Like
I am very disappointed with the timing on gip-02. I wish it were accepted as quickly as the network launch back in December. I understand its governance process and blah blah, but seriously, it’s already tested and voted. What do we waiting for? The “reasons” Brandon mentioned above won’t have a significant impact, and @Pete-LunaNova well described why it so.
But what’s really important is that right now a lot of small indexers who don’t have delegators or have a few (I checked it’s about 90-100 indexers with <1m delegated) are considering shutting down their nodes. They have a lot of rewards accumulated during this time which can be withdrawn entirely by unstaking all. Is it good for the network to lose them? Sorry if I seem rude. I’m not big into political correctness. The Graph.
7 Likes
I personally know several indexers who will unstake, what the point to wait 28 days to withdraw future rewards then? if they can take all… I would definitely do the same if I didn’t have delegates
2 Likes
Totally agree with the previous indexers. What was the point of discussing and voting on GIP-0002 for two months all together if the council effectively ignored it? If GIP-0002 is not implemented any time soon, we won’t have any other choice other than to stop and unbond our indexer for a month in order to extract the rewards.
2 Likes
What a cumbersome outcome for an already ironed solution with almost unanimously voting. I’m very surprised if not to say the least.
In the light of the last news about subgraphs migration to the mainnet, Indexers need to expand their infra, but instead of that, they will be willing to optimize their costs, and because of gas prices, it will be hard to join the party with new allocations for upcoming subgraphs.
3 Likes
Just wondering, what was the point to ask for opininion (voting process) and got >99% support to go ahead with tested and vetted solution, if at the same time minority < 1% (by fact a few users whose involvment and contribution in community is uncertain) could completely deminish and eliminate effort of whole community and active members. (this is obvious and absolutelly normal that it is impossible to meet and satisfy 100% of community, that’s why voting procces is in place which aim is to help to make a desicion which majority is asking for)
- This fact is at least not fair and disrespectfull to 99% of communty and as we can see it even pushes indexers to stop their nodes.
- It brought up a worry that voting procces is not matured enough where voice of majority of community still means “nothing”
We kindly ask you to go ahead and implement GIP-0002 as soon as possible - technicaly it could take just a few hours.
Once GIP-0002 is implemented we are open and happy to discuss any other proposals and changes which would improve network stability and community health.
5 Likes
Thank you for taking the time to post your suggestion.
The challenge here is how we get all stakeholders (delegators, developers, indexers, curators etc) to pull together in the best interests of the protocol. Those blocking this issue from moving forward need to recognise the severity of the problem and respond in an appropriate timescale. Without decisive action we run the risk that this situation continues to the point that Indexers are forced to withdraw, damaging the whole ecosystem in terms of both reputation and efficacy.
The GIP-0002 solution was presented by The Graph team (now Edge and Node), discussed at length, smart contract modifications implemented, audited, tested and finally a public vote for all stakeholders led to a near-unanimous decision to move forward with it. Those who now wish to potentially block GIP-0002 in favour of another solution should have been clear about this much earlier and we could have had a vote on multiple options. To attempt to switch to another proposal now, that delays an already untenable situation, puts the whole network at risk.
The real issue, is not that there are not other potentially viable solutions, it is that we are out of time to explore and then implement them!
Indexers need access to liquid rewards now, which was the original design intent – this problem is an error that needs to be corrected, not next week, not next month, but now. Indexers are keen to play their part in the ecosystem in partnership with delegators and other stakeholders, for this they have incurred significant operational expenses since the start of testnet 8 months ago, have put in substantial unpaid effort and now have accumulated serious tax liabilities. Preparation for the migration of more Subgraphs will require yet more expense and effort from these same parties.
8 Likes
You’re right. Why did The Graph Council not voice the issues they were concerned about when we discussed the GIP-0002 in the past? Why do they reject after voting and come up with another option that takes longer to complete? It was a vicious cycle and we spent 3 months on this problem but ended up waiting for at least another 2 to 3 months for another solution.
5 Likes
As a delegator, I have been following this discussion closely over the last few months. I feel the indexer community has described in sufficient enough details the logical need to obtain access to rewards and I think this is broadly understood at this point.
GIP2 is not without flaws and the councils decision shows they recognize that and take it serious. However, the decision to delay introduces indexer challenges that are not in the best interest of any network participant. If indexers start shutting down, then we all lose in the pursuit of our mutual goal to grow The Graph ecosystem.
I have full faith in this community and I believe most everyone here wants to do what’s right for the project, whether it’s the council, indexers, delegators, curators. Let’s not have our differing viewpoints lead to decisions that may result in serious damages to one network group.
I applaud that we are working on a new GIP that addresses concerns raised in GIP2. I have full trust that the new GIP will receive broader support across the aisles and will later be approved as a more equitable solution. With that trust in mind, I also support implementing GIP2 asap as an interim solution, so that indexers can address both their existential concerns as well as subgraph migration readiness over the coming weeks.
5 Likes
With the Graph Mainnet Migration Path announcement made here and the reaction to the proposal of GIP0004 to replace GIP0002 I feel the need to instill some urgency, to ensure that everyone fully understands the gravity of the time-to-revenue Indexers face and the impact of waiting for GIP0004. I am writing this now because waiting for the next Council meeting is too late. With hindsight and knowledge of the Mainnet Migration Plan, this is the strength of opinion I would have delivered to the Council meeting.
Indexers have made valid points about the burden of their financial situation and how waiting on GIP0004 worsens the it for many. These issues skew aggressively against smaller indexers. Please take the time to read their thoughts in this thread and understand the weight they carry. My focus here is on exploring realistic timeframes and getting this sorely needed fix in place as soon as possible.
The migration announcement sets out plans to start migration tests in April during which Indexers will see no revenue despite the requirement to scale up operations both opex (labor, hosting) and capex (compute). The migration announcement sets out plans to move into production apps after that. With GIP0004, Indexers will continue see no realized revenue until at least June/July at best so there is an expectation that they continue to scale and provide services into live migrations with no revenue. This is not acceptable in any business environment.
When taking into consideration governance process, technical review of GIP0004, auditing being an unknown timeline but critical path to a GIP0004 upgrade, we are looking at late June/July before rewards start to hit Indexer wallets as an optimistic case. Thank you to @Pete-LunaNova and @dancube for setting this out so clearly. Given the current bull market and how it creates extreme difficulty in sourcing auditors, especially auditors that already have knowledge of the codebase, we could be waiting any amount of time for a GIP0004 audit - Indexer’s cannot tolerate such uncertainty anymore.
We need our Indexers to move into testing and migration with their minds focussed on delivering an excellent service, not struggling to stay afloat or crushed under tax obligations because by the time they can access any of their revenue, a whole year has passed since Mission Control started.
The migration announcement crystallizes my personal opinion - we need to resolve the Indexer rewards issue now with GIP0002. I implore everyone that in responding to this, we focus on how we come together to fix the shortfall promptly. Lets move into Mainnet Migration with confidence that all stakeholders are financially positioned to play their part. If we have to resolve some GIP0002 risks and we have assessed those risks appropriately, lets do so retroactively and as promptly as we can.
Thank you to everyone that has contributed and continues to engage in the discussion.
21 Likes