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.
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.
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:
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:
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.
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! 
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
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.”
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?
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.
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.
Completely agree with your thoughts. 
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.
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
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.
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.
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)
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.
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.
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.
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.
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.
I’ve had a lot of conversations today with many stakeholders on this topic, as well as with @cryptovestor (in context of our recent Council meeting vs ‘the now’) and i appreciate being able to witness a lot of people making their voices heard in here and elsewhere. It’s no surprise to myself that Indexers, after a long period of patience and understanding, are being vocal about their grievances with all of this. It is the exact sentiment i expected.
I just wanted to lend my support to the above and say that the extra context provided by time, thought, discussion and the newly-revealed Subgraph Migration timeline has made it even clearer to me just how critical a solution is to this matter. In my opinion, one that adds further runway in addition to a thawing period is simply no longer a feasible consideration as our immediate next step. Not unless we’re OK with seeing many Indexers leave the set, once faced with the additional unpaid work/infra/costs that shall come along with this next step for the network.
The tax considerations/timelines presented above by some may not apply to every Indexer, due to jurisdiction, but i’ve seen this topic deliberated over for many weeks/months at this point. And i’ve noticed that many of those who have been vocal on this particular matter, were some of those who were motivated enough to join the new (unpaid) testnet, lending their time and energy, and even testing the GIP 0002 implementation as part of that. People willing to do unpaid testnet work are the types we should aim to retain, and their efforts stretch far prior to mainnet or the ‘new’ testnet…
Of course, the current ‘tax’ deadlines facing some may not be reason enough to move forward with the GIP. But it’s something that affects all Indexers to a various degree. And this is still only one part of the many other factors that contribute to the urgency of this situation, such as:
… and many other points - all come together in convincing me that we should move forward with this GIP as soon as possible, and then address any perceived imbalances or improvements (preferably, very) shortly after.
There’s a lot of people here with nothing to show for the past 8 months other than gains on paper, or a dashboard. Not even something to cover their time and expenses thus far.
If we want those people to stick around, we need to start allowing them to see something tangible for their efforts. Not working for ‘free’ while also indebting themselves further, just to stay involved in their role. And aside from that, for the network to thrive, it needs them to be able to perform their role well, with whatever infrastructure required being covered as part of that equation. The network can not be propped up by goodwill or expected to scale through what is essentially still ‘donated’ infrastructure.
And we can’t expect the network to not centralize, while also observing that the realistic, continued lack of realized compensation, is now on a course that could see us hitting the 1 year mark.
Side note: I would appreciate further clarity (from an E&N developer) on how exactly the unthawing mechanism in GIP 0004 works. I’ve spoken with a number of people on this and seen/heard some concerns over this implementation. It’s not possible for any Council member to deliberate over this, whether it’s implemented now or later, without further information.
Good opportunity to provide some deeper insight into the voting results of GIP2. Beside the token support of 99.72%, GIP2 also received a broad wallet support of about 90%. Moreover, the engagement of the voting also extended to the Delegator community that casted 37% (135) of all votes with 82% of them supporting GIP2. Below chart provides more details.
While some valid concerns were raised during the GIP2 discussions which the community seems committed to address, I think the voting data demonstrates that the Delegator community at large also supported this GIP for all the reasons mentioned in this thread.
