Every vote cast in a typical DAO is public the moment it lands: the address, the choice, the weight, and the running tally are all readable by anyone, live, for the whole voting period. That is the opposite of how almost every political democracy runs an election, and it is not an oversight – it is what makes on-chain governance auditable. Private voting is the family of mechanisms that give some of that transparency back in exchange for a property a public ledger cannot otherwise offer: a voter who cannot be watched, followed, or paid.

The term covers three different guarantees that are routinely collapsed into one, and the difference decides which problem a given system actually solves.

Three properties, usually confused

• Running-tally privacy. Nobody – including the voters – can see the intermediate result while voting is open. Everything is revealed at close. This defeats the bandwagon effect, discouragement of the trailing side, and last-minute strategic voting by large delegates. It does not hide who voted for what afterwards.
• Receipt-freeness. A voter cannot prove to a third party how they voted, even if they want to. This is the property that defeats bribery and coercion, because a briber cannot verify what they bought. It is strictly harder than running-tally privacy and requires the voter to be able to lie convincingly about their own ballot.
• Voter anonymity. The link between a voter and their ballot is never revealed, at any point. This is the classic secret ballot, and it is the hardest of the three on a public ledger where eligibility itself must be proven from a token balance or a membership record.

The point of separating them: the only widely-deployed system in DAO governance today provides the first and neither of the others. When Shutter’s own team was asked directly in Aave’s forum whether shielded voting stopped bribery, the answer was blunt – it “doesn’t prevent bribery or enhance individual voters privacy”. Treating running-tally privacy as a defence against vote markets is a category error.

Shielded voting: threshold encryption in production

Snapshot ships one privacy option, and it is a space setting rather than a protocol change. Snapshot’s own documentation describes it plainly: shielded voting is “powered by Shutter, it uses threshold encryption so that voters’ choices are private during the voting period and revealed when the proposal closes”. A space admin selects Shutter from a Privacy dropdown on the Voting tab; individual proposals inherit or override it.

The cryptography sits with Shutter Network, a threshold-encryption protocol better known for encrypted mempools and MEV protection. A set of nodes called Keypers run a distributed key generation ceremony; ballots are encrypted to the resulting public key, and the ciphertext can only be opened once a threshold of Keypers releases their shares – which, for governance, happens when the proposal closes (Shutter protocol overview). No single party can open a ballot early, but the Keyper set collectively can, so the guarantee is a threshold-honest-majority assumption rather than a cryptographic impossibility.

What a DAO gives up is smaller than it sounds and larger than it looks. Ballots are decrypted and published in full at close, so voting records stay auditable and delegates remain accountable for how they voted. But Snapshot does not allow a written reason on a shielded vote, which removes the single most useful artefact of the deliberation stage: the delegate rationale posted alongside the ballot.

What the adoption record actually shows

Claims about private voting in DAOs are usually made in the abstract. They are cheap to check: Snapshot’s public GraphQL hub (hub.snapshot.org/graphql) exposes a privacy field on every proposal and on every space’s voting settings. Sampling the most recent 100 proposals (or all of them, where a space has fewer) across 19 flagship spaces – 1,597 proposals in total – shielded voting appears in exactly three places:

Space	Shielded / sampled	Space default
Shutter DAO 0x36	65 / 65	shutter
Arbitrum DAO	14 / 100	any
ENS	2 / 98	any
Uniswap, Aave, Lido, Gitcoin, SafeDAO, Balancer, Curve, Optimism, ApeCoin, Starknet, Stargate, PancakeSwap, The Sandbox, Aura, Decentraland, Nouns	0 / 1,334	unset

One of the three builds the technology. Of the other two, the pattern is unmistakable once the titles are read: Arbitrum’s shielded proposals are overwhelmingly elections – the ARDC V2 Security, Risk, Research and Supervisory Council seats (Dec 2024), all four Season 3 D.A.O. category elections (Jan 2025), the OpCo Oversight and Transparency Committee elections (Mar 2025 and Jul 2026), the Audit Committee technical-expert election (Jun 2025) and the AGV 2026 council elections. ENS’s two are its Term 7 Meta-Governance Working Group election and the election of its new DAO Security Council (Jul 2026), both run under ENS’s Copeland ranked method.

Arbitrum reached that position by voting on it. In August 2024 Entropy Advisors put a temperature check to the DAO asking whether it should default to shielded voting; 3,603 voters returned no majority for anything: Against led on 69.2M votes (42.6%), For Elections Only took 59.6M (36.7%), For all Snapshot Votes 32.6M (20.0%), abstain 1.2M. Two years later the DAO’s revealed practice matches the runner-up option almost exactly.

The turnout evidence cuts the other way

The standard case for shielded voting is that it reduces voter apathy – if a minority-opinion holder cannot see they are losing, they still vote. Aave ran the only two-month controlled trial anyone has published, and the numbers went the wrong way. LBS Blockchain Society, Michigan Blockchain and Flipside Crypto proposed it in April 2023, the DAO passed it, and Marc Zeller enabled the privacy option on 5 May 2023. The retrospective posted on 18 July 2023 compared like for like:

Period	Total votes	Unique voters	Proposals	YAE:NAE
Mar – May 2023 (public)	879.9k	32.6k	65	73%
May – Jul 2023 (shielded)	119k	14.2k	59	85.4%

The author’s reading was that “these numbers suggest there is more general participation without private voting,” with the caveat that much of the raw volume was airdrop-farming dust rather than considered voting. The qualitative notes were mixed in a more interesting way: shielding “forces you to form and define a clear opinion, not just defer to the largest / most passionate voter,” but it made outcomes impossible to anticipate, so the operational work that normally begins before a vote closes had to wait – and the space needed active admin management to keep features like the quorum display coherent. Aave never made it permanent. Its Snapshot space carries no privacy setting today, and none of its last 100 proposals were shielded.

Arbitrum’s own proposal was unusually honest about the second-order effect: hiding the tally does not remove information asymmetry, it privatises it. “Politically savvy parties who have the ability or connections to coordinate now have an even bigger advantage,” and delegates who publicly announce their position gain leverage over a silent opposition. Shielded voting moves the tally from a public dashboard into a backchannel, and only the well-connected have the backchannel.

Receipt-freeness: MACI

MACI (Minimal Anti-Collusion Infrastructure) is the serious attempt at the harder property. Originally an Ethereum research proposal and now maintained by Privacy & Scaling Explorations, it uses encryption plus zk-SNARKs to hide individual ballots while proving the published tally is correct. Its stated purpose is not privacy for its own sake but collusion resistance: because a voter cannot prove which option they chose, a briber cannot verify delivery, and the bribe loses its enforcement.

The mechanism that buys receipt-freeness is a key-change message. A voter identified by a MACI keypair can submit a message re-keying their identity, and the coordinator processes all messages in reverse order. That ordering is deliberate: if a briber has a voter re-key to a briber-controlled key and then votes with it, reverse processing means the voter’s own later message is counted and the briber’s is not. The briber can never be sure which of a voter’s messages survived.

The cost is a trusted party. MACI’s docs say so directly: once voting closes “the coordinator has the sole ability to decrypt all user votes”. A corrupt coordinator can decrypt ballots (to publish them, or to bribe individual voters) and can halt a round by never producing the proofs; what they cannot do is publish a wrong result, because the tally is proved in zero knowledge. The circuits are Groth16 in circom and the trusted setup is optional – teams may skip a ceremony, since “MACI’s security model presumes a trusted coordinator” regardless. The v3.0 ceremony artefacts also show the scale ceiling honestly: the small-batch set supports 16,384 users and 125 vote options per poll.

MACI is alive as software – v3.0.0 shipped in June 2026, with commits through July 2026 – but its deployment record is not DAO governance. Its case studies are quadratic funding rounds at conferences (ETH Mexico, Devcon SEA, ETH Argentina, ETHCon Korea and similar), ending in 2024. clr.fund, the flagship MACI application, has had no commits since August 2024. No major treasury DAO runs its binding votes through MACI.

Removing the trusted party: time-lock puzzles

The obvious objection to both approaches is that they replace a public tally with a trusted set – Keypers in one case, a coordinator in the other. Cicada, a16z crypto’s research implementation, is the attempt to delete that party entirely using homomorphic time-lock puzzles.

A time-lock puzzle hides a secret behind a fixed number of non-parallelisable sequential computations, so it can only be opened after real elapsed work, by anyone. Cicada’s README states the property this buys: time-lock puzzles “achieve running-tally privacy without relying on tallying authorities, threshold encryption or any other trusted parties.” Because the puzzles are linearly homomorphic, individual encrypted ballots can be summed into a single puzzle encoding the final tally, so one solve reveals the result rather than one solve per voter. The implementation swaps the source paper’s Paillier encryption for exponential ElGamal to keep on-chain ballot verification affordable, at the price of a tally that must be small enough to brute-force a discrete log – practically under 2³².

Cicada gets running-tally privacy with no trusted party and no anonymity: it is unaudited research, last touched in January 2025, and no DAO governs with it. It is worth knowing because it marks the frontier – the property production systems ship is achievable without a Keyper set, and the properties DAOs actually want are not.

What ballot privacy costs a DAO

• Live auditability. A public tally lets anyone spot a whale swinging a vote while there is still time to respond. Shielded voting defers that to after the close, which as one Aave delegate put it means collusion surfaces “only when it’s too late.”
• Delegate accountability. A delegate is an elected representative whose voting record is the whole basis of re-delegation (see voting and delegation). Shielded voting survives this test only because it reveals at close; a genuinely anonymous DAO ballot would not.
• Execution is still public. All of this applies to off-chain signalling. The binding on-chain vote that follows – a Governor call, a timelocked upgrade – is executed in the clear, so privacy covers only the first half of the proposal lifecycle.
• Operational drag. Quorum displays, vote reasons and outcome-anticipation all break or degrade, and the space needs more active administration.
• It does not touch the money. Bribe markets settle on a proof the ballot was cast a particular way. Shielded voting leaves that proof intact after the reveal; only receipt-freeness removes it, and no DAO runs receipt-free voting at scale.

The place the tradeoff clearly favours privacy is exactly where the evidence says DAOs use it: elections. Choosing between named human candidates is where coercion, reputational retaliation and bandwagon dynamics are strongest, where the tally is inherently zero-sum between people who have to keep working together afterwards, and where the accountability argument for a public record is weakest – nobody needs to audit which delegate preferred which candidate for a security council seat. For parameter votes and treasury spending, the same DAOs keep the ballots public.

How Caper approaches this

A caper sits on the transparent side of this tradeoff deliberately, and it is worth stating plainly rather than implying otherwise. Voting is a single on-chain call: the ballot is a full ranking of every option, encoded and appended to the proposal’s ballot store together with the account that cast it, and the state tier exposes reading those ballots as a public method. There is no encryption stage, no reveal stage, and no coordinator. The choice, the caster and the running count are all readable while voting is open, and casting a vote mints the voter a vote token, so participation itself is visible on-ledger too.

What a caper does instead is attack the underlying incentive rather than the information. The bandwagon and apathy problems that shielded voting targets are downstream of votes being costless and weightless – a holder with a large bag and no participation still carries the day. In a caper, a member’s weight is the product of the governance tokens they hold and the vote tokens they have accumulated, each normalised by its own total (voting mechanisms), so a bag alone cannot capture a decision without a record of showing up. The same quantity sets what a member can withdraw when they exit, which makes voting a claim on the treasury rather than unpaid homework.

That is a different answer to the same problem, not a privacy feature, and it comes with the honest cost: a caper offers no ballot secrecy at all. A DAO whose primary risk is voter coercion – a contested election among people who must keep collaborating – is describing a problem a caper does not solve.

References

• Snapshot, Space settings – shielded voting and FAQ (no vote reason on shielded proposals).
• Snapshot, Hub GraphQL API – the privacy field on Proposal and SpaceVoting, source of the adoption figures above (sampled 30 July 2026).
• Shutter Network, Protocol overview (Keypers, distributed key generation, threshold decryption).
• Arbitrum DAO, Should the DAO Default to using Shielded Voting for Snapshot Votes? (Aug 2024 temperature check, full result and rationale).
• Aave governance, [ARFC] Private Voting for Aave Governance [2-month Trial] – proposal, Shutter’s own caveats (post 17), and the results retrospective (post 31).
• Privacy & Scaling Explorations, MACI documentation – workflow and coordinator trust assumptions, key change, trusted setup, case studies.
• a16z crypto, Cicada and Building Cicada: private on-chain voting using time-lock puzzles.
• Malavolta and Thyagarajan, Homomorphic Time-Lock Puzzles and Applications (2019).
• Rivest, Shamir and Wagner, Time-lock puzzles and timed-release crypto (1996).