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. Vitalik Buterin's 2016 survey of privacy tools named one route: a linkable ring signature lets a voter prove that their key is one of a published set of eligible keys without revealing which, and exposes any key that signs twice, so each eligible voter counts once (Privacy on the Blockchain). It fits a roll where every member has one vote; a token-weighted ballot would also have to hide the weight, which would otherwise point back to the voter.

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, and confirming that in 2026 turns up a trap worth stating for anyone repeating this measurement. The space the trial ran in, aave.eth, no longer exists: queried on 19 August 2026, hub.snapshot.org returns null for it and an empty proposal set, which is indistinguishable from a live space that has simply never shielded a vote. Aave governs at aavedao.eth – 975 proposals, privacy setting unset – so the finding holds and the pointer did not. A space id is a name, not an organization, and a renamed one fails silent.

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.

The reference implementation is no longer maintained. privacy-scaling-explorations/maci now redirects to privacy-ethereum/maci, and that repository is archived – last pushed 23 July 2026, a month after v3.0.0 shipped in June 2026. So is every other public repository the lab owns: all 142 in the PSE organisation were archived, read through the GitHub API on 26 August 2026. None of that is visible from outside the repository. maci.pse.dev and pse.dev both still answer 200, the README carries no wind-down notice, and every documentation link cited above still resolves – so a link checker sees a healthy project.

Work on the protocol continued in a fork. DoraFactory/maci is a CosmWasm port with commits through 19 August 2026, and it ships aMACI: MACI plus rerandomisable encryption, later reworked around 2-of-2 multi-party computation, aimed at exactly the trusted-coordinator cost described above. It runs on Dora Vota, a Cosmos chain built for voting, whose mainnet vota-ash was at height 17,006,099 on 26 August 2026.

The record that fork has produced is large, and it is still not DAO governance. Read on 26 August 2026 through the mainnet GraphQL indexer named in the SDK’s network config, Vota held 1,688 voting rounds going back to 10 October 2024 – 1,582 aMACI-1p1v and 106 aMACI-QV, and not one plain-MACI round. The titles say what they are: 197 begin “E2E”, 211 contain “test”, 27 are validator key rotations, and most of the remainder are public-opinion questions (“Should governments provide universal high income for AI-driven unemployment?”) rather than treasury decisions. MACI’s own case studies are still quadratic funding rounds at conferences (ETH Mexico, Devcon SEA, ETH Argentina, ETHCon Korea and similar), ending in 2024, and clr.fund, the flagship MACI application, has had no commits since 1 August 2024. Its most recent deployment of consequence is a funding round rather than a governance one: the Privacy domain of Gitcoin’s GG24 (donations 14–28 October 2025) ran on MACI private voting to protect donor preferences, one of six allocation mechanisms in that cycle – see DeSci funding. Aragon announced a MACI plugin for its OSx framework on 20 August 2025, built with the MACI team, and offered it as a custom build rather than a standard plugin (Aragon). Agora described a MACI voting module for its own governor in March 2026, still a prototype: each MACI poll maps to one proposal, and if the coordinator misses a deadline to post the tally, the encrypted ballots can be replayed through a different coordinator (Agora). 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.

Cicada is not the first design without a trusted party. The oldest is commit-reveal, which needs nothing beyond a hash function. Each voter first publishes a hash of their choice combined with a secret password, and after the commit period closes publishes the choice and the password so anyone can check them against the hash. A 2017 walkthrough of a commit-reveal election contract by the Ethereum developer Karl Floersch gives its purpose as stopping voters from basing their judgement on votes already cast (Learning Solidity Part 2: Commit-Reveal Voting), which is running-tally privacy. It also shows the cost: every voter has to return for a second transaction, and his contract cannot finish an election while any committed vote is unrevealed, so a deployed version needs a reveal deadline. Commit-reveal is not receipt-free either, since a voter can hand the password to a briber, who can check it against the published hash. A time-lock puzzle removes the second step, because anyone who does the work can open it.

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.

Encrypted tallies in a DAO framework

On 10 September 2026 Aragon released Confidential Voting, an OSx plugin that keeps each ballot encrypted with Zama’s fully homomorphic encryption while it is weighted and summed. Measured against the three properties above, it provides running-tally privacy and goes further than shielded voting on one axis: individual choices are never decrypted, only the Yes, No and Abstain totals, so the voter-to-choice link is not published at the end as it is when Shutter’s Keypers release their key. The voter’s address and weight are still visible, so it is not anonymity. Voters may replace an encrypted vote until close, the same move MACI’s key change makes, and Aragon claims coercion resistance on that basis. The trust assumption moves rather than disappears: the tally is opened by threshold decryption, and the plugin can be configured to let a designated party such as an auditor decrypt more. It is the first of these designs shipped as a standard plugin in a DAO framework rather than as a space setting or a research repository; no adoption figures had been published when this was read on 18 September 2026.

A second encrypted-tally plugin for OSx removes the single decrypting party but is not yet in production. CRISP (Coercion-Resistant Impartial Selection Protocol) comes from Gnosis Guild's Enclave project, since renamed the Interfold. Ballots are encrypted to a key nobody holds whole: for each vote a committee of independent ciphernodes is drawn from the Interfold network, the ballots are summed under fully homomorphic encryption, and the committee jointly decrypts only the result, with multi-party computation and zero-knowledge proofs covering the steps between. MACI's coordinator can read every ballot and Confidential Voting's threshold network decrypts the totals; here no single ciphernode holds a complete key. Aragon announced the integration on 10 November 2025 (Aragon) and published the plugin on 30 June 2026; it runs on testnet, and production waits on the Interfold network's rollout (Aragon).

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 that arrived without a record – bought, swapped or transferred in, with no ballot behind it – cannot capture a decision at all. 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).
• Karl Floersch, Learning Solidity Part 2: Commit-Reveal Voting (2017).
• Vitalik Buterin, Privacy on the Blockchain (Ethereum Foundation blog, 2016).
• Aragon, Introducing private voting on Aragon with MACI (August 2025), Verifiable Secret Ballots on Aragon with Enclave (November 2025) and Verifiable Secret Ballots with Interfold and Aragon (June 2026).