Design a Crypto E-Voting for DAOs with Quadratic Voting

Problem statement

Design a crypto e-voting platform for DAOs using quadratic voting (QV). Every token holder receives a budget of voice credits derived from holdings, grants, or personhood attestation. Casting n votes on a single proposal costs n squared credits, so the marginal cost of the next vote is 2n plus 1. The platform must let voters spread credits across many live proposals, tally votes correctly, resist Sybil fragmentation, preserve partial anonymity where the DAO asks for it, and settle final results on-chain or in a verifiable off-chain registry.

The reason QV exists is that plain token-weighted voting is plutocratic: one whale with one million tokens outvotes one thousand holders with one thousand tokens each. Quadratic voting makes concentrated power expensive. A holder who wants 10 votes on one proposal pays 100 credits; a holder who wants 1 vote on each of 100 proposals pays 100 credits. Intensity is expressed, but concentration is taxed.

The mathematical trap that drives the whole architecture

QV only works if one person equals one budget. If a whale splits holdings across m wallets, each wallet gets its own quadratic curve, and total influence grows by roughly the square root of m for the same capital. One hundred Sybil wallets multiply voting power tenfold at identical cost. Therefore the hardest problem in this design is not tally arithmetic; it is identity integrity under adversarial wallet fragmentation while preserving the partial anonymity voters expect.

What makes this different from a normal poll backend

A poll backend can retry a failed write. A governance system cannot retry a settled vote: a double-counted ballot changes treasury outcomes, token emissions, and protocol parameters. The design therefore separates ballot durability from result freshness. Ballots are append-only, idempotent, cryptographically signed receipts that must survive relay failure, indexer lag, and chain reorganizations. Live tallies are projections that may lag and may be recomputed. Settlement is the only strongly consistent step, and it is guarded by proofs.

Public operating baseline versus design assumptions

Public evidence establishes that this category is operationally real. Gitcoin has allocated tens of millions of dollars through quadratic funding rounds, a close cousin of QV, and reports hundreds of thousands of contributors across recent rounds, with Passport-based Sybil scoring in production. Snapshot hosts off-chain signed-ballot voting for thousands of DAO spaces including ENS, Uniswap, and Aave, and reports millions of cumulative votes stored on IPFS. Compound Governor Bravo and OpenZeppelin Governor run fully on-chain checkpoint voting with quorum and timelock enforcement. MACI (Minimal Anti-Collusion Infrastructure), built from an idea by Vitalik Buterin and maintained by Privacy and Scaling Exploration teams, has been used by clr.fund and Gitcoin pilots to tally encrypted votes with zero-knowledge proofs.

These are cited public claims, not requirements for our fictional system. For capacity planning this answer explicitly assumes a mature multi-DAO platform with 2 million registered wallets, 400 thousand monthly active voters, 500 active DAO spaces, 50 concurrent live proposals, and a 10 times deadline-rush peak. Unless tied to a citation, every number is a stated design assumption.

The four architectural planes

1. Ballot plane: wallet-signed vote intents, relayers, idempotent ingestion, durable receipts.
2. Governance plane: proposals, voice-credit budgets, quadratic allocation engine, tallies, quorum, settlement.
3. Identity plane: personhood attestation, Sybil clustering, fragmentation scoring, credit caps.
4. Settlement plane: on-chain or registry commitment, Merkle proofs, execution timelock, dispute and re-tally.

A strong interview answer keeps these planes separate. The governance plane may degrade live results without weakening ballot durability, and the identity plane may tighten caps without changing the tally math.