Minimal Anti-Collusion Infrastructure (MACI)

Minimal Anti-Collusion Infrastructure (MACI) is a cryptographic protocol that secures on-chain voting and decision-making by making votes private, preventing collusion, and ensuring coercion-resistance. It enables applications like quadratic funding, decentralized governance, and collective decision-making where the integrity of the outcome depends on participants voting their true preferences without being bribed or forced. Developed by the Ethereum community, MACI combines zero-knowledge proofs, public-key cryptography, and a trusted coordinator to achieve these properties while maintaining auditability.

The core mechanism of MACI relies on a central coordinator, a semi-trusted entity that processes votes but cannot alter them. Participants encrypt their votes using the coordinator's public key and submit them on-chain. After the voting period ends, the coordinator processes all valid votes off-chain, generates a zero-knowledge proof (zk-SNARK) that the tally was computed correctly, and posts this proof along with the final result to the blockchain. This structure ensures vote privacy—individual choices are never revealed—while providing cryptographic assurance that the outcome is valid.

MACI's anti-collusion property stems from its ability to make votes non-reassignable and unforgeable. A user can only change their vote by sending a new, signed message with their private key before the deadline; they cannot prove to a third party how they voted after the fact. This breaks the trust required for bribery schemes, as a bribee could simply change their vote after receiving payment without the briber knowing. This feature is critical for protecting processes like quadratic funding, where large donors could otherwise manipulate grant matching by coordinating votes.

Key technical components include keypairs for user identity and signing, the state tree managed by the coordinator to track user public keys and votes, and the zk-SNARK circuit that generates proofs of correct state transition. While the coordinator is a potential point of centralization or censorship, the protocol is designed to be minimal and verifiable: anyone can cryptographically verify the coordinator's work via the zk-proof, and the system can be designed with multiple coordinators or a decentralized set to reduce trust assumptions.

Primary use cases for MACI include decentralized autonomous organization (DAO) governance, retroactive public goods funding (like Gitcoin Grants), and any community decision where financial incentives might distort honest participation. By ensuring votes are private and unprovable, MACI creates a more robust social layer for blockchain applications, aligning cryptographic guarantees with real-world social and economic behaviors to produce more legitimate and attack-resistant outcomes.

The term Minimal Anti-Collusion Infrastructure (MACI) was coined by Ethereum researcher Vitalik Buterin in a 2018 blog post, where he proposed a system to make bribery and collusion in blockchain-based voting economically irrational. The name is a direct descriptor: Minimal refers to the goal of minimal trust and complexity, Anti-Collusion is its primary security objective, and Infrastructure denotes its role as a foundational layer for applications like quadratic funding and decentralized autonomous organization (DAO) governance.

The intellectual origin of MACI lies in the synthesis of several cryptographic primitives. Its core mechanism builds upon zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) for privacy and verification, and employs a central, non-colluding coordinator—a trusted execution environment or a single honest actor—to perform critical computations. This design is a direct response to the inherent transparency of blockchains, which, while ensuring auditability, makes simple voting schemes vulnerable to vote buying and coercion.

MACI's development was primarily driven by the need for secure quadratic funding rounds, a democratic funding mechanism for public goods. The first major implementation, clr.fund, demonstrated its practical utility. The protocol's evolution continues within the Ethereum ecosystem, with ongoing research focused on reducing trust assumptions in the coordinator role, moving towards a more decentralized and robust anti-collusion infrastructure for the next generation of on-chain governance.

The MACI process begins with user registration. Each participant generates a public-private key pair, submitting their public key to a smart contract to become an authorized voter. A critical design choice is that users should never reveal their private key, as it is the sole mechanism for submitting valid votes and prevents others from voting on their behalf. This initial registration establishes the cryptographic basis for all subsequent anti-collusion guarantees.

During the voting phase, users encrypt their votes with the public key of a trusted, neutral party called the Coordinator and submit them on-chain. Crucially, users must also sign their encrypted vote message with their private key. This creates a cryptographic link between the voter's identity and their ballot, which is essential for later verification. The Coordinator is the only entity that can decrypt the votes using its private key, keeping the votes confidential during the voting period to prevent real-time bribery schemes.

After the voting period ends, the Coordinator initiates the tallying phase. It downloads all encrypted votes, decrypts them offline, and computes the final result. To prove the tally's correctness without revealing individual votes, the Coordinator generates a zero-knowledge proof (zk-SNARK). This proof cryptographically verifies that: every counted vote came from a registered user, no votes were altered or omitted, and the final tally correctly sums the decrypted votes. Only this proof and the final result are published on-chain.

The protocol's final step is the public key change window. To prevent retrospective coercion—where a briber demands proof of how someone voted after the fact—MACI allows users to submit a command to change their public key. If a user changes their key, any votes signed with their old private key become invalid. This means a coerced voter can simply change their key after voting, rendering any proof of their original vote useless to an attacker, thus nullifying the coercion attempt.

The MACI data flow begins with the Coordinator deploying the core smart contracts: the Poll contract for a specific voting event, the MessageProcessor for validating votes, and the Tally contract for computing results. Users then sign up by submitting a public key to the SignUp contract, which records their initial state and grants them a stateIndex. This registration phase is critical, as it establishes the set of authorized participants whose subsequent messages will be processed.

During the voting period, a user submits an encrypted command (e.g., a vote for an option). This command is packaged into a Message and sent to the Poll contract. Crucially, each message includes a zk-SNARK proof (generated client-side) that cryptographically verifies the user's right to vote without revealing their identity. The contract batches these messages, and any observer can download them. To change their vote, a user simply submits a new message with a higher nonce, which will supersede the previous one during processing.

Once voting closes, the processing phase begins. The Coordinator downloads all messages and runs them through the MessageProcessor circuit off-chain. This circuit performs the core MACI logic: it decrypts each message using the Coordinator's private key, validates the user's stateIndex and signature, checks the nonce for correctness, and updates an internal state tree to reflect the latest valid command. The output is a state transition proof, which attests that the new state root was computed correctly from the previous root and the batch of messages.

Finally, the tallying phase computes the results. Using the final state from processing, the Coordinator runs the Tally circuit. This circuit aggregates votes per option, again producing a zk-SNARK proof of correct tally computation. The Coordinator then submits both the final state root, the tally result, and the corresponding proofs to the Ethereum blockchain. Anyone can verify these proofs independently, ensuring the outcome is correct without needing to trust the Coordinator, while the encryption prevents the Coordinator from linking votes to individual users, preserving coercion-resistance.