This is an early stage document, a work in progress, and we expect this document to change.

All comments welcome

One urgent problem with voting are the high transaction costs. There is no real good solution for this, as of now. Concretely, the problem is to design a trustless process in which voting comes cheap or free for the user, while (a) keeping the definition of voting power on the (expensive) main net and (b) executing the results on chain.

Current de facto solution: Snapshot + multisig

A partial solution is given by Snapshot, cases by moving the expensive Voting Engine off-chain to a centralized server (i.e. Snapshot), while the Voting Power assignment and the execution are done on the main net:

For this process to be acceptable, one needs to trust two entities: the operator of the Snapshot server needs to follow the correct procedure to read the voting power data from the main net, execute the voting process fairly (and in particular not censor any votes), and to report the results correctly. Additionally, the operators of the Gnosis safe are trusted to execute the decisions correctly.

Snapsafe (by gnosis) mitigates some of the trust issues with snapshot by adding a using reality.eth to report the snapshot results to the main net - i.e. instead of the multisig owners "bridging" the snapshot decisions, this is done by a more decentralized oracle. This still leaves the Snapshot operator with a lot of power.

So while snapshot is great for polling, and has turned out to be a great tool for DAOs to make decisions, it is not an viable long term solution per se.

Obvious next step: keep voting power and assets on main net, and vote on a cheap L2 or Side Chain

This looks something like the following diagram:

For this solution to be viable, we need a number of pieces in place.

• It must be very cheap and easy to vote on the sidechain
• There must be a (cheap) way to bridge voting power from main net to the sidechain
• There must be a way to bridge the decision on the sidechain to an executed transaction on the main net
• The sidechain is, preferably, EVM compatible

**There is currently no solution that satisfies these requirements (**or even comes close) 🤷