[UPDATE]: the community voted in favor of this proposal (link to vote). The following policies and requirements are now effective.
The goal of this thread is to discuss and crystallize the process and policies of temperature checks (snapshot) votes.
This proposal will be linked in the snapshot space once ratified (*this very same proposal will be put up for vote, will edit post with link).
Scope
The purpose of snapshot proposals is to gauge community sentiment on serious topics under consideration for onchain governance votes that impact 0x protocol.
Temperature checks are non-binding. For example, while a temperature check might indicate community support to introduce a change in smart contracts, a team will have to submit a complete ZEIP vote to come into effect. The same applies to Treasury proposals, which always require an onchain-binding vote.
The domain upon which the community of ZRX holders has decision-making power is:
0x protocol (smart contracts and their deployments)
Posts regarding airdrops and frontend integrators (such as Matcha) do not meet these criteria and will be deleted.
Process and requirements
Temperature checks can be initiated by any ZRX holder or delegate with a voting power of at least 10k (ten thousand) ZRX.
A link to an existing discussion on gov.0x.org must be provided in the description of the vote.
The vote is considered valid once it reaches a quorum of 1M (one million) ZRX with at least 50 addresses voting. The quorum is intended to be set on the winning option (not on the sum of votes on all options).
A temperature check vote must last at least 5 days. In case of tighter deadlines, a 3 days (72 hours) duration could be accepted.
Any proposal that does not meet the criteria will be either ignored or deleted from the space.
Currently, @mintcloud@abandeali1 and @nikita are admins of the snapshot space.
Your feedback is needed!
Iāll update the above based on the preliminary feedback in the discussion. Please indicate your support too if you agree. In a few days Iāll open a snapshot vote to formally ratify this.
Iām agree, but I think a requirement should be to be subject to a topic here (gov.0x.org) where the context is explained and could be discussed, as well as you could easy way to add notifications, since snapshot does not warn of new proposals.
great idea. The only problem is when addresses with 2 ZRX show up.
Just to be safe, maybe we can set a minimum of 50 addresses?
If we want the quorum to be 1M ZRX, that would mean an average of 20K per voter. Seems fair.
These are not proposals, they are sentiment polls so not sure we need 50 addresses? As we have already seen, snapshot has been sybilād with more than 20 different addresses that are clearly from the same one voter with very small amounts of ZRX in each address, so that isnāt really a reliable metric. For example, you could have one delegate + 49 addresses associated with a single person with less than 1 ZRX in each address and it would be considered valid by these requirements.
What is the meaning of āvalidā and what happens after a poll is determined to be valid by meeting the minimum thresholds? For example, does being valid mean that the topic must proceed to a formal proposal with an onchain vote? Who would be responsible for writing/submitting the proposal if the snapshot creator doesnāt hold the minimum number of ZRX (currently 100k)? If a delegate, what if no delegates support the proposal but it is forced to proceed to an onchain vote anyway? Not sure this would be productive.
I tried to download/export the data from the previous snapshot polls to do some analysis but there doesnāt seem to be a good way to do that
All good points here, I think we need to be a bit flexible and use these as signaling. Requirements and thresholds are necessary, but yeah weāll have to take votes case by case.
For example:
when we put these up for vote, it kinda makes sense to have quorum thresholds to make this signaling thereās enough consensus. No further action is needed, and weāll use this forum post as the ātemperature checks rulesā
if a temperature check about using Treasury funds to do X is passed with at least 1M ZRX, I think it deserves a onchain vote (which will be ultimately binding). Yes, one delegate might be acting on their own to have the temp check passed. Other delegates might or not help setting up the onchain vote, but letās remember that they would be able to run it themselves too (as the threshold is 100k ZRX). If the onchain vote is ultimately set up, then the other delegates are incentivized to participate to block it, if they disagree
when it comes to protocol upgrades, that requires smart contract development. In that sense, whoever supports a temp check that passed will have to find someone willing to develop the smart contract updates and run the ZEIP process (including vote prior to deployment). That could very well be 0x Labs - we could be running signaling too), but again not binding. Someone has to do the smart contract work (+audits)
Again, thereās no clear cut line in everything, but I find these policies useful.
A minimum of addresses is better than no minimum in my opinion. Certainly, it can be gamed. We can set it to a higher number if you prefer, votes have historically been between 50 and 200 voters
Iām not against it, but Iām also not convinced itās a meaningful qualifier given the ease and low cost to circumvent it, which could make it easy for ābad actorsā to get around it while also making it overly burdensome for āgood actorsā to clear it. Itās fine to add it though. I guess a good test will be whether the snapshot posted on this topic is able to meet the requirement of 50 addresses and the nature of those addresses/balances. BTW I have always made temperature check votes at least 5 days long and IMO 3 days may be too short.
My bad, while the community voted in favor of this proposal (link to vote), less than 50 addresses voted, therefore invalidating one of the requirements.
Therefore, the updated proposal (removing the min addresses requirement) is up for a vote again