This is a description of a proposed scalable voting system for Alchemy / future governance systems:
This voting system is an attempt to find a more optimal point in the tradeoff between usability and security for voting.
In this system, most users can have the voting / proposing experience of snapshot.page, while proposals can still be executed on-chain with the same level of security current on-chain DAOs provide.
This is achieved by connecting Snapshot to our Genesis protocol voting system and creating a new story for proposals that follows this flow:
polling → confirmation → (optional: challenge confirmation) → execution
Below is a draft of how the UX for this might work:
Voting happens in two stages:
Polling – free, fast, no on-chain actions (Snapshot)
Confirmation – costly, slower, on-chain actions
In polling, cryptographically signed proposals and votes are uploaded to IPFS by our relaying service. This is fairly secure, but because there are some vulnerabilities, proposals must pass through confirmation to be executed.
In confirmation, proposals are put on-chain, where they reach a final result and the DAO can execute them (sending funds, calling a function, and so on).
In order to move a proposal into confirmation, you must upload it onto the Ethereum blockchain, vote for it, and stake a minimum number of tokens. This stake proves your confidence that the proposal will pass. The minimum number of tokens is decided by the voting protocol, which you can find here, and the type of token is unique to each DAO.
Once in confirmation, the process has two sub-stages.
In confirmation stage 1, anyone may “challenge” the proposal by 1) adding a vote or 2) stake of their own.
- Challenging by vote is simple: a proposal with more “no” than “yes” votes will always fail.
- When challenging by stake, you have the option to stake enough tokens “against” the proposal to derail it. A derailed proposal remains on-chain but is no longer in confirmation; however, if someone stakes enough additional tokens on it before time runs out, the proposal can restart the confirmation process.
If a proposal survives confirmation stage 1 without being derailed, it will progress to confirmation stage 2. Here, only challenges by vote are allowed, and when time runs out, the proposal will succeed or fail according to whether the “yes” or “no” votes are greater. If a proposal succeeds, anyone may execute it (this may be often done automatically by a bot).
When a proposal succeeds, those who staked for it receive their stakes back plus their share of the tokens staked against the proposal. When a proposal fails, the reverse occurs.
We’re highly considering building this into Alchemy in February – thoughts?