We have recently published a paper “Burn Your Vote”,
Proposing a protocol in which voters “burn tokens” to pseudorandom addresses and submit zk‑SNARK proofs to prove a valid burn, achieving vote integrity, coercion resistance, and unlinkability with minimal gas overhead
No FHE, No MPC, No TLP, No heavy computation.
You can explore the code here:
GitHub ‑ Proof‑of‑Burn Voting
For a high‑level overview, see our paper:
Eprint ‑ Proof‑of‑Burn Voting
Why Burn Your Vote?
Current DAO voting tools either expose ballot choices, rely on heavy off‑chain MPC/FHE, or introduce trusted coordinators. Burn Your Vote plugs that gap by:
True On‑Chain Tallying: All proof verification and vote aggregation occur in smart contracts—no off‑chain authorities needed .
Privacy & Unlinkability: Voters burn tokens to pseudorandom addresses and submit zk‑SNARK proofs of a valid burn; tallies operate on plaintext votes but remain unlinkable to identities .
Coercion Resistance: Unlinkable burns + optional revoting let voters plausibly deny coerced ballots.
Scalable Performance: Constant‑time tally gas (~27 k) even at million‑voter scale—significantly lower than HTLP‑based systems like Cicada.
Reaserch focus:
Reducing Proving Time:
Right now we’re on Circom + Groth16 + rapid-snark clocking in at ~37 s per proof. We’ll look into what happens if we switch to Noir—can’t use rapid-snark there—so we’ll scope out other backends (Halo2/PLONK variants, GPU acceleration, incremental proving) or pipeline tricks to cut that down.
Receipt‑Freeness Feasibility:
Since we cant have protocol‑level randomness to add to the users proof to make it receipt‑free , we’ll explore if we can get real receipt‑freeness without breaking the system.(biggest challenge)
Circuit Optimization:
Current counts:
447 template instances
8,485,140 non‑linear constraints
3,898,619 linear constraints
We’ll try to slim down our circuits speacially heavy Merkle patricia trie since for each layer of the trie we have one keccak and one rlp.