Hey everyone, thanks for all your additional input. I appreciate everyone’s contributions to this discussion and commitment to finding the best solution.
I want to reiterate that we take the urgency of this issue very seriously, especially in light of the recent announcements around subgraph migration. As I noted in my previous update:
I would not personally support delaying on GIP-0002 if it meant Indexers waiting substantially longer to claim their indexing rewards
I do feel like we have an obligation to explore all viable proposals in working towards the best solution (and these extra few days have given us that opportunity), but we shouldn’t let great get in the way of good for a problem needs a short term solution.
Here are some updates that were promised in my previous post:
- Graph Council Meeting notes have been published and can be found here
- GIP-0004 has been published to my
mainbranch on Radicle (Ariel has already shared the Github PR). - The earliest we can get GIP-0004 reviewed by an external auditor is the first two weeks of May, which we feel is too long to wait on a fix for this issue.
The last option being explored is whether The Graph Council itself could sign off on GIP-0004, given that the changes are limited in scope, and that we have three external (to E&N) Solidity experts on The Council. This is a benefit of having technical domain experts on The Council.
We’re meeting tomorrow morning to walk through the code changes line by line and discuss whether we would be comfortable with this approach. After that, several Graph Council members have expressed willingness to do an async vote on GIP-0002/GIP-0004 in the next few days, to accelerate the schedule for an upgrade. We will have another update to post on this by EOD tomorrow.
Lastly, I’d like to clarify a few (what I consider to be) misunderstandings in some of the feedback above:
A lot of concern seems due to unfounded worries that somehow GRT price may be negatively affected by Indexers having access to their rewards.
This is not at all where the concern lies. Thawing periods in our protocol, and mechanisms for adding “slowness” to cryptoeconomic protocols in general (whether they involve voting, staking, etc.) serve many purposes, and it was never the goal of GIP-0002 to remove that. It was simply a side effect of trying to address another unrelated problem with a minimum viable solution.
I understand its governance process and blah blah
I realize decentralized governance, and the time it has taken to get the tooling and processes to support it set up, may seem like an unnecessary burden, but I believe strongly that there is value in doing things right from day one. Our commitment to this ethos is part of what has brought so many people into The Graph community and is a requirement of launching a decentralized network.
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.
During the early days of The Graph’s decentralized governance, the role of SnapShot community polls is to be a valuable information signal to The Graph Council and Foundation, along with other inputs like discussion in the forums and at Protocol Townhalls. It is not intended to be a direct governance mechanism, though I do believe that it could lay the groundwork for such a mechanism in the future.
One problem with adopting the results of any vote “as is” is that the community was never given the chance to vote between GIP-0002 and GIP-0004. They simply voted between GIP-0002 and an undesirable status quo, and I would wager that any proposal that improved upon the status quo (including GIP-0004) would have also likely received a “yes” vote. Voting mechanisms like this, in general, are extremely vulnerable to the ordering in which proposals are presented.
Currently, it’s the mandate of The Council to take into account both the quantitative feedback offered by polls, as well as the substance and content of specific feedback being offered. This mandate, more than anything, is why we felt it was appropriate to take a few extra days to consider all options and not out of some irrational desire to diminish the voice of anyone in the community.
All the processes and tooling that we’ve set up, from a transparent GIP process, to a Graph Council with representatives from all stakeholder groups, to SnapShot community polling, to Protocol Townhalls, has been with the intention of elevating the voice of as many folks in the community as possible. I know getting these self-same processes set up is part of what has taken so much time, but I promise this will get smoother and we’ll continue to iterate until we push the boundaries of what an effective decentralized governance process can look like. 