Hey Everyone!
Now that the Ampleforth Snapshot page is up (signal.ampleforth.org), and anyone can kick off a community snapshot vote, I thought it would be good for us to arrive at a set of guidelines for how they should be constructed. I propose the following:
Snapshot Proposal Standards
Voting period should start at least 24 hours in the future
Voting period should last at least 3 days
Poll question and choices should use neutral phrasing (avoid introducing bias)
Poll should include an abstain option (allows for participation without influencing vote)
Poll text should link to a discussion on the Ampleforth forum to allow for feedback and suggestions
Quadratic Voting should be avoided to sidestep Sybil manipulation
We might refine these are this gets used more often. In the meantime, if anyone has other suggestions, please share them!
What is Snapshot?
Snapshot is a gas-less, off chain voting mechanism. FORTH holders can cast votes with only a signed message from their wallet, which removes the need to pay transaction fees to participate in governance.
Where does Snapshot Fit?
As described on the governance page, the Ampleforth Protocol is governed through a series of sequential steps, each representing increasing levels of consensus from the community. Proposals and ideas are surfaced on the discord or our public forum, and are finalized when they are deployed onchain.
Snapshot is typically used to signal support before the binding onchain vote. It also makes full use of delegated powers, so you must delegate to yourself (or someone else) before your tokens can be used to vote.
Might be good to establish what methods for announcing a vote are used?
For example, a forum post would give people some heads up but many people donāt pay much heed here yet, so would we also say that the Ampleforth twitter account should announce an upcoming vote too? There are some other options like Discord and Telegram to consider too.
Other than that, I definitely think thatās a solid baseline. Do we need to establish a process for determining what happens when a vote is perceived to not have adequately followed the standards, and is thus deemed not binding?
One more open questionāThereās currently a distinction between āCommunityā proposals and āCoreā proposals. In the snapshot main page, you can filter the view based on the dropdown in the top right:
The only difference between these is that Core proposals can only be created by a whitelisted set of editors (i.e. Ethereum addresses). Otherwise, they are functionally equivalent.
One option is to keep this distinction. The same AIP editors would be editors of the Core section. This would allow some people to see only proposals attached to ācore AIPā process if they chose, and potentially cut down on noise or spam.
So far there have only been community proposals, as no AIP has yet proceeded to the signaling stage.
Another option is to remove the distinction, and treat all proposals equally. How proposals get applied comes down to community agreement anyway, since it has no onchain effect.
A model I like is that whoever is initiating the proposal takes responsibility for gathering support and ushering participants. Relying on centralized twitter handles introduces points of failure or censorship. (But that doesnāt mean that Ampleforth or other individual twitter accounts should be barred from announcing). If someone is unable to collect enough attention, then itās a sign that itās lacks support anyway.
Well, Signal votes themselves are non-binding
Ultimately, itās up to the community to decide how to interpret Signal/Snapshot. This is often a pre-step to the onchain vote and is useful for gaining knowledge about whether the real vote will pass. Itās a tool for gathering sentiment, rather than having direct end-effects like the onchain portion. If a Snapshot proposal is controversial or seen to not be adhering to standards, then onlookers will naturally give it less credit. Iām up for hearing ideas here, but nothing concretely useful comes to mind.
Couldnāt that be susceptible to malicious proposal initiating by someone who deliberately doesnāt advertise it? Though I suppose nothing stops someone who wants to see it succeed propose it again but properly.
I hope we can consider this to be normal. Systems change, people get more information. Revisiting ideas should be welcome! Naturally, reposting endlessly hoping for a different outcome is differentāand not very likely to succeed I donāt think.
Personally, I would support removing the distinction to not run into a āAll proposals are equal, but some proposals are more equal than othersā sentiment.
However, this is not a strong opinion and if there are valid reasons to keep the distinction I would go for it too,
but Iām not seeing the argument for āpotentially cutting down on noise or spamā.
There really werenāt a lot of proposals yet
Currently, every AIP editor is part of the team and I would imagine they would be able to make enough noise for every community member to know about an upcoming AIP proposal
First , regarding the question of whether to set up a core proposal, I think it should be set up.
Reason 1: We can look at the equal proposal situation of the sushi community, as the AMPL community grows, it will definitely encounter the sushi community as well, below I have listed some cases of invalid proposals, more cases can be seen everywhere on sushi-snapshot
Reason 2: The difference between a core proposal and an ordinary proposal is not only whether the proposer is a core member or not, but also that the proposal itself is part of the core communityās long-term planning for implementation.
Because of the large number of people in the community and the varying levels of users, it is difficult to stay on course in one direction, i.e., to have long-termism. This is when the community splits into a core community and a general community. The core community leads the project forward, but is accountable to all community members. This is when the core community and the general community have different responsibilities. Therefore the requirements of the proposal are also different.(I will elaborate on the core and general proposal requirements below)
Second, the difference and requirements between core and general proposals
First, we need to distinguish between core and general proposals.
A core proposal is a proposal that is initiated by a core member, but the content may be the result of a general community discussion. The basis for determining whether a proposal is a core proposal is that it is in line with the long term plan of the AMPL project, which can be determined by the AMPL project roadmap planning can be judged by [the AMPL project roadmap](https://www.ampleforth.org/roadmap/)
The ordinary proposal is the non-core proposal, which should be messy and numerous, but is the idea base of the core proposal, and where the community members are prancing around. Any proposal that has been discussed by the community and has a certain level of acceptance can be called a general proposal.
However, there is one condition for ordinary proposals: they should not be implemented by the project. (Because of the large number of proposals in this section, the project will not have time to implement the long-term plan of the project if it requires the cooperation of the project)
A distinction is made here between the basic core proposal and the ordinary proposal Core Proposal: Alignment with AMPL Roadmap Ordinary proposal: community self-governance proposal, not dependent on the project owner for completion
Third, the standard setting of normal proposals
To summarize, the following issues need to be addressed.
What kind of users are AMPL community governance users?
What kind of proposal is a qualified proposal?
How to ensure that users participate in voting and exercise their voting rights?
How to avoid cheating in voting
1. What kind of users are AMPL community governance users?
Forth token holders and LP token holders of Forth
Currently, Forthās LP tokens are mainly distributed in a total of 5 pools in UNI V2 and V3, so the AMPL team needs to solve the problem of how to include all LP tokens in the voting, or which pools of LPs can participate in the voting by the community vote.
2ćWhat kind of proposals are qualified proposalsļ¼
After detailed discussion in AMPL forum, only those proposals that have progressive meaning and feasibility for AMPL community can be qualified.
Proposal standardization: Proposals should use neutral wording, proposals should be linked to relevant proposals in the forum, and the options of proposals should include the option of abstention.
3ćHow to ensure users participate in voting and exercise their right to voteļ¼
to ensure that the proposal voting enough time frame: Voting period should start at least 24 hours in the future
Voting period should last at least 3 days
For qualified proposals, AMPL officials should forward them for support. For major proposals, we can consider doing corresponding activities to motivate users to participate.
4. How to avoid cheating in votingļ¼
The current snapshot voting will be snapshotted at a certain block height, so there is no possibility of double spending on voting. However, the problem with Forth tokens is that the token holdings are too centralized, so it is very easy for the big players to manipulate the voting results, which is a bad phenomenon.
According to intheblockās data, you can see that 69 addresses hold 89.39% of the Forth tokens, of which 11 giant whales directly hold 68.39% of the Forth tokensć
Therefore, quadratic voting should be adopted to weaken the power of large investors. (Although the large investors can currently fight against quadratic voting by subaddressing, the current independent identity system is not established, so we can only limit some lazy large investors in this way first)
This is part of my thinking on the current project side governance, and one of the directions Meter is trying on DAO (in the process of trying), hope it helps
But I donāt agree with quadratic voting. With nothing in place to ensure one vote per person, someone can split their FORTH stack across multiple addresses and have a far greater total voting power by doing so.
This is not a hypothetical threat either - such behaviour was already observed for the FORTH governance votes to pick the winning entries for the NFT design competition.
I did some analysis to see what impact was had, for which I have written a tool to display how the voting would have worked out under different counting strategies. The code and the results can be viewed at the following links:
Unfortunately, someone had in fact split their FORTH across a large number of addresses and delegated with a good chunk of them ahead of time, allowing them this unfair advantage. (This can be osberved by following their addresses through Etherscan as a chunk of FORTH is moved between many accounts, leaving 2 FORTH behind at each one)
Even more unfortunately, this person saw fit to push one entry into the winning bracket despite it receiving little interest from anyone else.
The entry in question was āChoice 1ā of the positive rebase category, and as per my analysis you can see that whilst under quadratic voting strategy it ranked #2 it would under regular linear voting strategy have ranked #12
Whilst itās possible that, had the need to delegate been clearer, greater participation would have overruled this userās āattackā it still demonstrates that a competitive advantage can be achieved in FORTH votes when using quadratic voting if one is willing to spend some time and gas on it.
(Closing thoughts - it should not be assumed that the person who voted for that entry is the person who submitted that entry. I do not wish to start a witchhunt. They might also not have had malicious intentions regarding voting, but instead been splitting their FORTH to speculate on potential future airdrops)
In conclusion, the details of that particular set of votes aside, I hope Iāve demonstrated that quadratic voting will not best serve the interests of FORTH governance.
