Alchemy Improvement Draft -- Scalable Voting

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, 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?


Needs to be done to remain a competitive DAO provider.

We just did an analysis for PrimeDAO and continuing to use DAOstack sort of comes down to 6-12 months from now which framework has the cheapest/most reasonable governance costs. Snapshot/Aragon Govern both look promising but it’s sort of a “wait and see” affair.

It’s great DAOstack is thinking this way!

1 Like
  1. It is not stated what is the point of the polling phase. What role does it play? Is it simply a cheap way to compile votes prior to entering the staking (confirmation) phase? Do the results somehow gate entrance to the staking phase? For how long can the polling stage continue? What controls when it is possible to begin staking?
  2. what is different between the two confirmation stages and the already-existing pending and boosted stages, other than having an easier choice of staking token?
  3. why not call it the “staking” phase?
  4. The initial vote+stake ought to have its own name as, if I understand, it is a unique and singular action that pushes a proposal into Conf stage 1, the only time when both vote and stake are required together.
  5. “This stake proves your confidence that the proposal will pass.” – More precisely, it is a measure of one’s confidence that no one will be able/willing to down-stake your up-stake, and that the number of yes votes will ultimately exceed the number of no votes. (Well, maybe I am wrong if being outstaked by a down-stake results, after the proposal timing out, in a refund of my stake)
  6. there is no description of the effect of aggregated ‘yes’ or ‘no’ stakes
  7. if a proposal is down-staked out of the “conf” phase, can it re-enter the polling phase?
  8. “the type of token is unique to each DAO” - does this mean that no two DAOs can use the same token? Is it really meant to say that it will become easy for a DAO to choose what staking token it wants to use? What will be the impact on GEN of this change?
  9. what is the role of REPutation in this new process?
  10. is any change planned for the DAO “native” token? Can the native token be used for the staking token?
  11. will it be possible for a DAO to only do the polling phase, disabling the conf phase altogether?

Great post, and looking forward to seeing how this is implemented. Can you explain if passed snapshot proposals are automatically put up for a vote on chain or if an ETH address would need to put the proposal up for a vote?

Also, how long would the time frames for the confirmation stages 1 and 2 be? Similar to the current boosting structure?