ZKvote.cc

To vote in DAO protocols, voting tokens (VT) are required. But what happens if VTs are scattered across multiple networks at the same time?

Two problems will arise:

1. Difficulty synchronizing voting results from several networks at once.
2. Inability to deploy VT in other networks due to the bridge architecture (due to VT → ERC20 conversion).

Our solution is a crosschain governance protocol that:

1. Uses a trustless & universal architecture to support many L2 networks with VT on L1.
2. Uses standard ERC-20 to remove conflict with the bridge architecture.
3. Transfers the execution of L2-voting mechanisms to the ZK module instead of using VT.
4. Uses ZKP to prove the correct delivery of L2 State data.

Protocol working flow: Step 1. VT → Bridge → ERC-20

Step 2. Since regular ERC-20 does not have voting functionality, and changing the bridge logic to use custom ERC-20 is too difficult, we use standard ERC-20, and process all voting functions off-chain. (verb)

Step 3. After this, based on the balances recorded in the snapshot, our Proving System generates a SNARK proof and commits it to L1 in one transaction.

Step 4. The main voting contract aggregates proofs from all networks, adds them to the quorum and distributes them among the voting options.

This project uses the following scope of technologies:

1. Solidity + Hardhat | on-chain contracts;
2. Circom | off-chain ZK Proof Generator (Scroll);
3. Noir + Rust | Recursive ZK-SNARKs Proof Generator;
4. Javascipt + TypeScript | Frontend + Backend;
5. React, VueM, Wagmi, Web3Model, WalletConnect.