Onchain Atlas

MACI

Ethereum-ecosystem infrastructure for collusion-resistant private on-chain voting, using encrypted key-change messages plus zk-SNARK-verified tallying so voters cannot credibly prove (and therefore cannot sell) their votes.

▶ Run interactive simulation animated mechanism with editable parameters

Statusongoing
Launched2019-05-04
ChainsEthereum, Gnosis Chain (xDai, via clr.fund), Arbitrum, Optimism, Base, Dora Vota (Cosmos app-chain, derivative implementation)
Mechanismscollusion-resistant voting, key-change deniability, zk-SNARK verified off-chain tally, trusted-coordinator with tamper-evidence, quadratic funding/voting integration
Official sitehttps://maci.pse.dev/
Project X@zkMACI (verified_by_official_website)
FoundersVitalik Buterin (originator of the mechanism design) (@VitalikButerin), Kendrick Tan (initial implementation, EF grantee), Koh Wei Jie (initial implementation, EF grantee), Chih-Cheng Liang (initial implementation, EF grantee)

How it works onchain

Diagram of how MACI's mechanism worksOpen full-size diagram
Original diagram derived from this entry’s researched mechanism description.

Summary

MACI (Minimal Anti-Collusion Infrastructure) is one of the canonical mechanism-design artifacts of the Ethereum research ecosystem: a scheme for on-chain voting that makes vote-buying and coercion economically irrational by making votes unprovable to third parties. Vitalik Buterin proposed the design on ethresear.ch on May 4, 2019; an initial codebase was built in late 2019–early 2020 by Ethereum Foundation grantees Kendrick Tan, Koh Wei Jie, and Chih-Cheng Liang, and the project has since been maintained by the EF's Privacy & Scaling Explorations (PSE) team. Its core insight — collusion resistance via deniable key changes plus zk-SNARK-verified tallying — has powered clr.fund's quadratic funding rounds since ETHDenver 2020, Gitcoin/Allo experiments, and derivative systems such as DoraHacks/Dora Factory's anonymous MACI (aMACI) on the Dora Vota app-chain. It remains actively developed (v1.0 in October 2021; v2 and v3 through 2024–2025) rather than a finished product with mass adoption.

Design (Mechanism)

The problem MACI attacks: on a transparent blockchain, votes are publicly verifiable, which is exactly what a briber needs — a voter can prove how they voted and get paid. MACI breaks that proof.

  • Sign-up: eligible voters register a public key in a MACI smart contract (eligibility gating — token holding, attestation, Sybil-check — is pluggable).
  • Encrypted messages: every action (a vote, or a key-change command) is encrypted and posted on-chain to the contract. Outside observers cannot read message contents; the chain guarantees censorship resistance and ordering.
  • Key-change deniability: a voter can at any time submit an encrypted message replacing their voting key. Because a briber cannot tell whether any given ciphertext was a vote or a key change, a voter who "sells" their vote can secretly invalidate it first — any receipt they show the briber is worthless. This is the anti-collusion core.
  • Trusted coordinator, trust-minimized tally: a coordinator holds the decryption key, processes all messages off-chain in order, and publishes the tally with a zk-SNARK proving the result is the correct output of processing every message against the registered state. An adversarial coordinator can see votes (weakening privacy vs. them) and could decline to finish, but cannot censor messages, forge votes, or publish a wrong tally.
  • Applications: the message-processing circuit supports vote weights/voice credits, making it a natural substrate for quadratic voting and quadratic funding, where bribery and collusion are the classic attacks.

v1.0 (October 2021) restructured the system around multiple polls per MACI instance, cheaper message submission, and faster proving; v3 (2024–2025) added per-poll gatekeeping, customizable voice credits, and hash-chain message accumulation. Canonical deployments exist on Arbitrum, Optimism, and Base, with instances deployed per voting round.

Outcome

Status: ongoing — a long-lived, technically successful public-goods infrastructure project with real but niche production use.

  • clr.fund, born at ETHDenver in February 2020, has run repeated MACI-tallied quadratic funding rounds (Round 8 in late 2021: ~6,100 contributors, ~50,000 votes, ~33.5k wxDai matching pool; later rounds included a ~$350k EthStaker round in 2023), mostly on Gnosis Chain and then rollups due to gas costs.
  • Gitcoin explored MACI-based private QF rounds via its Allo stack; PSE also built QFI and MACI Platform on top of it.
  • DoraHacks/Dora Factory extended the design into aMACI (removing the coordinator's ability to link voters to votes) and shipped it on the Cosmos-based Dora Vota chain, used for Ethereum-research grant votes and community rounds (2023–2025).
  • A HashCloak audit (2021–2022 cycle) found and led to fixes of vulnerabilities before/around v1.x releases.
  • The team's own March 2025 roadmap candidly notes declining interest in private voting for public-goods funding and a pivot toward DAO-governance integrations (e.g., an Aragon OSX plugin) and research into decentralizing the coordinator via homomorphic encryption or collaborative SNARKs.

Why it worked

  • A genuinely novel mechanism, not a product bet: key-change deniability is a clean, minimal answer to a well-posed incentive problem (credible vote-selling), which is why it became canonical reference material for mechanism designers.
  • Right trust decomposition: MACI never claimed a trustless coordinator; it precisely scoped what a malicious coordinator can and cannot do, and enforced the "cannot" (no censorship, no false tallies) with on-chain data plus zk-SNARKs.
  • Institutional patronage: EF grants and then PSE stewardship let an unprofitable public good be iterated for 6+ years (v0 → v3), audited, and documented — a luxury venture-funded governance startups rarely get.
  • Composability with quadratic funding: QF is maximally bribery-sensitive (small collusions distort matching superlinearly), so clr.fund and DoraHacks gave MACI a use case where its complexity was actually justified.

Limitations and criticisms

  • Adoption stayed narrow. Most DAOs kept using transparent token voting (Snapshot, Governor); bribery markets (e.g., vote-incentive platforms) were often treated as a feature, not an attack, muting demand for collusion resistance.
  • Operational heaviness: every round needs a competent coordinator running trusted-setup-derived keys, proving infrastructure, and off-chain tally computation — far more friction than a Snapshot poll. Early versions were also gas-expensive on L1, pushing usage to xDai/rollups.
  • Residual trust and UX costs: the coordinator sees individual votes (privacy, though not integrity, depends on their honesty); voters must manage MACI keypairs and understand key-change semantics — a hard UX sell. aMACI exists precisely because this residual trust bothered adopters.
  • Its flagship niche shrank: by the team's own 2025 recap, interest in private voting for public-goods funding declined, prompting a pivot toward DAO tooling while product-market fit for the original use case remains unproven at scale.

Lessons

  • Unprovability beats secrecy. The deep design lesson: to stop vote markets you don't just hide votes, you destroy the voter's ability to credibly prove a vote. Receipt-freeness, not mere privacy, is the anti-bribery property.
  • Scope trust precisely. MACI's "coordinator can peek but cannot cheat" decomposition — integrity enforced cryptographically, privacy enforced socially — is a reusable template for practical systems that can't be fully trustless on day one.
  • Mechanism demand is not automatic. A cryptographically superior voting scheme underperforms if the governance culture tolerates (or monetizes) collusion; adoption depends on who actually experiences bribery as a cost.
  • Complexity must be amortized by stakes. MACI's overhead is justified where manipulation is cheap and consequential (QF matching pools), and unjustified for routine low-stakes polls — matching mechanism weight to attack surface is a design decision, not an afterthought.
  • Patient public funding sustains infrastructure that markets won't, but it can also delay the reckoning with weak demand; MACI took ~5 years to pivot from public-goods funding to DAO governance.

Redesign (EDITORIAL — hypothesis, not fact)

The following is the Atlas's editorial hypothesis, not a statement of fact or of the MACI team's plans. If redesigned today, we would (1) make the coordinator a threshold committee by default — split the decryption key via DKG among N operators with proofs per processing batch, converting "one party sees your vote" into "a quorum must collude," and adopt aMACI-style unlinkability where feasible; (2) ship MACI as a hosted, one-click "private round" primitive inside existing surfaces (Snapshot-style UI, Aragon/Governor plugins, Farcaster frames) so the coordinator/proving stack is invisible to organizers — MACI's history suggests the mechanism was never the blocker, the operations were; (3) target the highest-bribery venues rather than generic DAOs: vote-incentive-dominated gauge systems, grant juries, and elected councils, where receipt-freeness measurably changes payoffs; and (4) add an explicit economic layer — staked, slashable coordinators with liveness bonds — so the remaining honesty assumptions are priced rather than merely assumed. The bet: collusion resistance becomes valuable exactly when governance controls large treasuries and bribery is professionalized, so the redesign should position MACI as a drop-in upgrade at the moment a community first feels the cost of vote markets.

Sources

  1. Minimal anti-collusion infrastructure (Vitalik Buterin, ethresear.ch, May 4, 2019) — primary (docs)
  2. MACI official documentation — What is MACI? — primary (docs)
  3. Release Announcement: MACI 1.0 (Koh Wei Jie, PSE, Oct 12, 2021) — primary (retrospective)
  4. MACI deployed contracts (official docs) — primary (contract)
  5. 2025 High Level Roadmap and recap (MACI team blog, March 2025) — primary (retrospective)
  6. A Technical Introduction to MACI 1.0 (PSE Mirror) — primary (docs)
  7. MACI GitHub repository (privacy-scaling-explorations/maci) — primary (contract)
  8. Projects built using MACI (GitHub discussion #1314) — primary (docs)
  9. clr.fund blog — CLRFund Round 8 Final Splash (analysis)
  10. Pioneering Decentralized Governance: A Retrospective on DoraHacks' MACI/aMACI Study and Implementation (retrospective)

Related experiments

Last verified: 2026-07-26 · Spot an error? Suggest a correction