Introduction
The grant committee wishes to present a go-forward plan on how to resolve the “hung vote” situation that resulted from the first snapshot vote. Before describing the exact process and the decision process that led to it, it is important to express a couple of general points:
- This is a very difficult situation and the specific outcome of the vote (not just a hung vote, but TFA DAO being the only eligible team) seems to have caught the entire community by surprise.
- Because this outcome was so unexpected, it is entirely normal that community members are upset and questioning the overall process.
- The vote was (quite literally) a last minute nail biter and several teams that thought they were in the lead for most of the 7 days, saw that lead disappear within the last minute. Given how dramatic that was, it is not surprising people are reacting with strong emotions.
That being said, several things need to be pointed out:
- This is the exact same process that was followed for Tranche 1 and the general sentiment then was that it was an improvement over the process that preceded it.
- Of course, that doesn’t mean the process is perfect and can’t be improved upon (it clearly isn’t perfect and it definitely should be improved).
- At the same time, the Tranche 2 snapshot vote is merely following the process established by the Revised Grant Program that was voted in in March of this year; and so the hands of the committee on changing what the community had voted on were largely tied going into this.
- What changed for Tranche 2 is that a lot more teams applied (double the number) than for Tranche 1 and at the same time, the TWAP was now 41% lower. The combination of those two factors made a hung vote far more likely. To put it starkly - the combined ask from the 10 teams was 20M GLMR for an available 4.5M GLMR. There was no scenario where some people were not going to be extremely disappointed, regardless of the outcome.
- It is relatively easy, with the benefit of 20/20 hindsight, knowing the exact sequence of events and the outcome of the vote, to point out flaws. It’s a lot harder to do that prior to the vote taking place.
- The snapshot vote is merely a signal vote. It is to gauge the sentiment of the community. The actual vote that ratifies the grant award is the on-chain referendum. This means the community has TWO opportunities to approve or disapprove a specific proposal.
- It would indisputably be better to have a weighted voting process on Moonbeam. It would probably also be better if that voting process did not allow last minute vote switching (which is possible with snapshot.org on Ethereum). Unfortunately, Polkadot governance currently only supports binary voting (yes/no) and multiple choice voting is currently not supported. This is an issue that is being raised with the engineering team but it’s an unfortunate reality we have to deal with.
- The committee is trying to balance multiple competing concerns, including but not limited to:
- The difficulty in getting teams to commit to clear milestones so the community can make informed decisions.
- The challenge that often the teams themselves don’t know what can be achieved given the current economic climate affecting web3.
- The need to honor the wishes of the community which is partially composed of those self-same teams (who are highly motivated to vote and express opinions in their own self interest).
- The need to honor the principles of decentralization.
- The need to act as an even handed and impartial arbitrator of the rules, regardless of what the personal opinions of the council members may be, in a situation where teams are often in an adversarial competition for grants.
- The health of the overall ecosystem and the need to have a speedy and expedited process so that stimulus to the ecosystem (which is what this ecosystem grant process is supposed to provide) is provided in a timely manner to prevent liquidity from leaving the ecosystem.
- The fact that there are a lot of very high quality teams in this tranche and the opinions of the community (as evident from the vote) are very divided. Simply put - it’s a lot easier to identify what people don’t like. It’s a lot less clear what they DO like.
All these are extremely complex and difficult concerns to try and balance. On top of that, even in the feedback the committee is receiving, the community appears to be extremely divided. Some members want an entire do-over, regardless of how long that drags out the process. Some members want to expedite the process to reduce voter fatigue and make sure the stimulus from the tranche is quickly applied.
In such a contentious environment, the committee has to use its own best judgment. All it can do is try to look at every presented concern, discuss every possible angle, and then make a call. The committee believes it is making the right call with the information it has, but only time will tell. But this call is being made in good faith and with - this cannot be stressed enough - an extraordinary amount of deliberation. It is unavoidable that some community members will not agree with the decisions the committee makes, given the circumstances. But it is the committee’s hope that even if individual community members don’t agree with all of the decisions, they recognise these are extremely difficult decisions to make and there are no answers that will make everyone happy.
At the same time, the community should not lose sight of some of the positives here. It is better to have a community that is this passionate and engaged and have this many strong teams apply, than an ecosystem where barely anyone speaks out or interacts with governance and it is the web3 equivalent of tumbleweeds blowing by.
The rest of this post will outline the revised process the committee has agreed on; and how it arrived at that decision. This is being presented in the spirit of transparency and communication.
High level intent behind the process
The overall intent of the committee is to have the following (amended) voting process to resolve the conundrum:
- A signal snapshot vote to determine which teams the community wishes to support and to what extent (i.e. how much GLMR to allocate to a which team)
- A forum post from the applicant indicating what target metrics they intend to achieve with the allocated GLMR, once the amount is known
- An opportunity for the community to ask for clarification and provide feedback on that forum post
- A final on-chain referendum to either ratify or reject the result of the signal vote and the proposed metrics. Only this referendum can be actually binding and result in the grant being awarded.
With this in mind, the committee has decided on the following process to resolve the hung vote situation:
Output from the Committee deliberations
- TFA DAO should be recognized for winning the 1st signal snapshot vote and go on to an on-chain referendum.
- The on-chain referendum will be to award them the 1M GLMR they had asked for in their grant proposal.
- The grant is not final until that on-chain referendum passes. The community has a chance to participate in that referendum and is highly encouraged to do so.
- The remaining 3.5M GLMR will go on to a second snapshot vote.
- The second snapshot vote has the following rules:
- It is a signal vote to gauge community sentiment and the results will need to be ratified in an on-chain referendum.
- Only the 9 remaining teams will be added to the second snapshot vote.
- Only the top THREE (3) teams at the end of the second snapshot vote will be eligible to go on to the on-chain referendum, provided they meet a minimum awarded GLMR threshold requirement.
- Each team must secure a minimum of 500,000 awarded GLMR (not voting power), which means they need to secure at least 14.28% of the total votes
- If this threshold is not met, the % of the 3.5M will go to the Community Grants Bucket.
- Otherwise, teams will win a % of the 3.5M GLMR equal to their vote when the second snapshot vote closes.
- The most a team can win in the second snapshot vote is what they asked for in their original grant proposal - in other words, they are capped at their ask.
- No other adjustments will be made to their final amount.
- Amounts that would have gone to the remaining 6 teams are sent to the Community Grants Bucket instead.
- After the second snapshot vote completes, separate on-chain Moonbeam referenda will be created, at the same time:
- 1 referendum will be for TFA DAO.
- The other 3 referenda will be for the three winners of the 2nd signal vote, assuming that they met the threshold requirement.
- The community will need to ratify each one of those referenda.
- If any referendum is defeated, the amount instead goes to the Community Grants Bucket.
- Any team can then apply for a grant from the committee (teams that filed proposals or other teams), but the normal grant committee rules apply - i.e. the committee will research the project, perform diligence and vote; and grant requests are capped at 250K USD.
- Throughout the entire voting process (snapshot AND on-chain referendum) teams are encouraged to rally their communities to vote on their behalf, but they cannot offer any sort of financial reward to their communities to vote - this includes GLMR, their own native token, stable coins or fiat. NFTs are allowed; as long as these are along the lines of “I voted for team x” (i.e. no “Bored Apes” NFTs worth thousands of dollars, for obvious reasons).
Important Dates
The rest of this post will detail how the committee arrived at this process; what options it considered and what the voting record was.
Tuesday, 08/01, 03:00 pm UTC: date the second snapshot vote will go live
Tuesday, 08/08, 03:00 pm UTC: date the second snapshot vote will complete
Thursday, 08/10, 03:00 pm UTC: date by which the winners of the second snapshot vote will need to complete their updated milestones on the forum
Saturday, 08/12, 03:00 pm UTC: date until which the community can provide feedback and ask questions about the updated milestones on the forum
Monday, 08/14: date by which the individual proposals for the winners of the second snapshot vote will be put on Moonbeam as referenda
Monday, 08/28: date by which the second set of on-chain referenda will complete.
Summary of Committee Decisions
The rest of this post will detail how the committee arrived at this process; what options it considered and what the voting record was.
It took the committee 14 hours of deliberations to reach this series of decisions. A summary of the decisions the committee considered, the different options and the voting record is published below.
For a full detailed explanation of each decision, decision option and why the committee voted the way it did, please refer to the detailed notion site.