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 
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 
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! 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?
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.
At the moment there are no options chosen for the vote
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.
We need same for delegators too then no thwaning period also indexer should not be allowed to change reward cuts abruptly , they first keep it low to attract delegators and then change it before rewards
Thank you Ariel for proposing a practical solution to this problem which was discussed originally here.
At the moment there is no mechanism for Indexers to withdraw rewards without unstaking capital which is disruptive to Delegators, the Protocol and the Indexer. Consequently rewards are being accrued but not accessed. This has two effects:
Starves Indexers of revenue to fund operations (that they have run from the start without any form of accessible reward)
In a number of territories it incurs tax liabilities that could be difficult to meet if the market has a downturn before rewards are accessible
The result is that Indexers may be unable to afford to continue and in the extreme may incur tax bills greater than the income they can liquidate. From an Indexers perspective this erodes the encouragement to support and develop the Graph network. From a Delegators and Protocol perspective it potentially reduces decentralisation as Indexers struggle to stay afloat and only the wealthier Indexers survive. All parties are affected.
I can understand the concern from some Delegators that the liquidation of Indexer rewards may affect the market (price). Indeed they will - more so if the supply into the market is lumpy because of token-lock periods. Please don’t forget that Indexers are token holders too. They do not want to see adverse market consequences due to their actions. However we must not lose sight that the real driver of market price is usage. Usage which can only come from a healthy ecosystem in which all parties are appropriately rewarded.
In terms of implementation Koen’s suggestion of specifying a permanent address, that rewards are automatically withdrawn to, makes a lot of sense.
Starving Indexers of rewards was not intended and needs to be rectified urgently. For this to require an extensive build/test/approval process may be seen as excessive. If it is necessary then let us get on with it at pace and ensure that any governance processes that are absolutely required are pursued in parallel, so that the focus can rightly move to developing and growing the protocol.
Thank you for the post Mike.
It does require a built, test, approval process. Deploying smart contracts to ethereum mainnet is risky. Considering the team has not done any testing of this on mainnet with the current contracts, we must take the precautions to ensure the upgrade will be done properly. It is important to follow safe protocols, even when many in the community want a change to be implemented ASAP.
The last thing we want to do is deploy a bug. Even a small bug could be extremely detrimental, and set us back weeks, and a catastrophic bug would be detrimental to everyone.
It is also extremely beneficial to follow a standard governance process for every single GIP. This will allow all future GIPS to be done more efficiently, as everyone knows what the expected procedure and there is no debating how to go about it. If, for example, we skip procedures for this GIP - future parties involved in future GIPs will point back to this one and say that their problem is just as urgent, and also needs to be streamlined. Which becomes a distraction.
Any changes to the governance process in the future - would probably have to go through a GIP in order to get implemented.
Rest assured, things are being worked on in parallel. We have multiple people working on it
Usually when research is being done, there are two types of data - qualitative and quantitative. The vote is a perfect addition to the discussion here. It will give councils to better informed decision in regards tp the community sentiment on particular proposal.
Agreed. While it feels urgent, we must definitely not skip safety precautions nor governance. We don’t want a solution (or the implementation thereof) that’s worse than the problem being addressed.
Thanks for bringing this up @ari! I from Citadel.one would like to say that we are in favor of the proposed ideas, as 28 freeze period brings certain limitations to both indexers and delegators. Removing this freeze period for rewards claiming should not affect network’s security but will bring more flexibility.
We would love to assist in whatever processes where we can be helpful!
Falling firmly into the little guy indexer camp here, it reinforces my belief in The Graph as a project to see these discussions taking place. And the conversation being publicised so well. It’s true that not being able to access rewards will end up being unsustainable in the long term for us but having the proper oversight and ensuring everyone (who wants to) gets their say is the behaviour of a stable ecosystem and one I can be proud to be a part of.
I think a private rewards pool for each indexer is a fine way of solving the problem. Has any consideration been given to Koen’s suggestion about extending the interface such that it supports splitting rewards between the pool and restake? By absolute amount or percentage?
Just wanted to add my voice to the ayes WRT this feeling like steps toward a workable solution.
Hi Dave,
Thanks for your reply.
I am not suggesting that we shortcut the build and test processes. Having been involved in this space, both professionally and personally over the last 5 years, I am all too aware of the risk inherent in smart contracts and the need for robust processes. My concern was that, provided we do not take shortcuts on things like the necessary testing, we should not try to wrap this up with an extensive governance approval process. It could unnecessarily delay what should be seen as a critical security issue requiring prompt resolution.
I am a strong believer in establishing effective governance practices, having spent the last year or so deeply involved in restructuring the governance for another blockchain project. I would question the logic of the Graph having a single-speed governance process. Perhaps we should have a standard process and one that can be expedited for say critical security issues. It has been over 1.5 months since this issue was discovered. What happens if we discover a separate critical security flaw that if exploited by a malicious party could cause significant loss of funds and damage to the protocol? Surely in such extraordinary circumstances we should have governance tools at our disposal that can still enable us to act swiftly to prevent damage?
Hey Mike,
Great questions - thanks for taking the time to deep dive into the governance and ask the right questions.
Yes is has taken 1.5 months, but I would attribute that to the wave of engagement the team has had to handle upon network launch. We pushed hard to meet the December 17th date - which caused us to push off our internal processes and organization, which we paid for this year by organizing ourselves again. We have also had to handle the huge amount of inbound messages, and questions from the community, the public, investors, etc. etc. This has slowed down our amount of time we have to work on this fix. Although this has been an important issue for the last 6 weeks, we often will have new tasks to handle on the fly each week that cause us to juggle our priorities.
The team is currently hiring and growing. We will be working on improving processes once that is all done. Right now we’re trying to push this through but all of us get pulled in many directions.
We do have processes for emergency upgrades - I don’t believe these are made public yet. As they are probably not clean enough to be shared, and we are too busy with other things like trying to get this implemented 
. However we have all those things in place, and if I remember correctly most of this stuff has also been described to the Council so they are aware of the emergency procedure as well.