Permanent private voting is one of the most requested features in DAO governance. Vitalik Buterin has called for privacy. Governance platforms like Decent have championed it. It’s supported by significant efforts in both industry (e.g., Shutter, Cicada) and academia (e.g., 1, 2, 3). And across DAO communities, everyday voters continue to raise the same concern: when every vote is public, governance breaks down.
The cost of public voting is real - retaliation, pressure, vote-buying, and strategic signaling over honest conviction. It discourages participation and distorts outcomes. In modern elections, ballots are secret for a reason. DAOs need the same protection.
Shielded voting mechanisms - like Shutter’s Shielded Voting on Snapshot - offer a strong foundation. By keeping votes confidential during the voting period, Shutter’s Shielded Voting has already brought privacy to over 600 DAOs. However, once voting ends, individual votes are revealed.
That’s why we’re announcing the next major evolution of Shutter’s Shielded Voting: permanent Shielded Voting is now on our development roadmap.
What We're Building: Permanent Privacy Indefinitely
As part of this roadmap, we’re building the option for DAO governance platforms to offer permanent voting privacy - before, during, and after the vote - while still allowing anyone to verify the result on-chain.
In this post, we’ll explain how it works. We’ll walk through the technical architecture and share our working proof of concept. We discuss how the current Shutter Shielded Voting scheme can be extended to allow tallying of encrypted votes. Concretely, we describe how to extend Shutter to a form of threshold ElGamal encryption that when accompanied with zero-knowledge proofs allows to tally encrypted votes while maintaining public verifiability of the result.
Proof of Concept - Permanent Shielded Voting
We implemented the POC as explained below to prove its feasibility.
On-Chain Shielded Voting From Linearly Homomorphic Threshold Encryption
A popular approach for building voting mechanisms that preserve voter privacy - even after the voting period has ended - is to use linearly homomorphic threshold encryption (e.g., 4, or 5), such as ElGamal in the exponent or Paillier. These cryptographic schemes allow to compute the election result directly on encrypted data: individual votes remain encrypted, but thanks to their additive homomorphic properties, an encrypted tally can be computed. To obtain the election result, only the final tally is decrypted without ever revealing the individual votes. Decryption is performed in a threshold manner, i.e., the decryption key is distributed among a set of parties (Keypers), and only when a predefined threshold of Keypers collaborate can the final decryption be executed.
Figure 1. Illustration of linearly homomorphic operations. E(x) denotes the encryption of value x and ⊕ and ⊗ denote efficiently computable operations for ciphertext addition and multiplication with a constant respectively.
One example that demonstrates the feasibility of using linearly homomorphic threshold encryption for shielded voting is the DAVINCI protocol, which uses threshold ElGamal in the exponent. Unlike general-purpose FHE, which supports arbitrary computations but remains costly, ElGamal offers a practical, efficient alternative that’s scalable and viable for real-world use today. In this post, we follow a similar approach and describe that Shutter already has all the necessary components and only requires minor modifications to implement threshold ElGamal in the exponent.
Making Shutter Linearly Homomorphic
Shutter already provides an encryption scheme with threshold decryption, but it is not linearly homomorphic, i.e., it lacks the ability to compute the sum of encrypted values. But here is the good news: it is easy to add that property to Shutter!
Without going into too much technical detail, here are the main reasons why Shutter can easily implement ElGamal in the exponent, a popular linearly homomorphic encryption scheme:
- Shutter operates over cryptographic groups that are suitable for ElGamal in the exponent
- Shutter’s distributed key generation protocol already generates keys that are compatible with ElGamal in the exponent
- Shutter already operates a set of Keypers
In other words, all the foundational components needed for linearly homomorphic threshold encryption are already part of Shutter’s architecture. Only minimal modifications to the encryption and decryption procedures are required to make Shutter a linearly homomorphic threshold encryption scheme.
Are We Done Then?
Is it enough to make Shutter linearly homomorphic to build a Shielded Voting mechanism with long-term voter privacy? Not quite, but it’s a critical step in the right direction!
Linearly homomorphic threshold encryption enables encrypted vote aggregation and threshold decryption of the final tally, but on its own it cannot provide a secure voting system. It must be complemented with zero-knowledge proofs that prove correct behavior by the system’s participants: on the one hand, voters must prove that when they submit an encrypted vote, the vote is indeed valid; on the other hand, Keypers must prove that the tally was decrypted correctly.
We illustrate the vote initialization and the actual voting process in Figure 2 below.
Side note: An additional crucial requirement for any voting system is authenticating voters to ensure that only authorized participants can cast a vote. A straightforward approach for such an authentication mechanism is to maintain an on-chain registry of voters’ public keys and require each encrypted vote to be signed by the corresponding private key. In this post, however, we abstract away from the specifics of voter authentication, as it is separate from the question of how to preserve vote privacy beyond the voting period.
Figure 2. Illustration of the vote initialization and the voting process using linearly homomorphic threshold encryption.
A Simple Example
Consider a basic vote with three options: Yes, No, and Abstain, which we represent as 1, −1, and 0, respectively. Each voter encrypts their chosen option using the public key provided by Shutter and generates a zero-knowledge proof showing that their encrypted vote is valid, i.e., that it encodes one of the allowed values (−1, 0, or 1). The encrypted vote and the accompanying proof are then submitted on-chain.
After the voting period ends, the tallying authority - which could be a smart contract, the Shutter Keypers, or any other designated party - verifies all submitted zero-knowledge proofs. It then homomorphically aggregates all valid encrypted votes to compute the encrypted tally. The Keypers collaboratively decrypt this tally using threshold decryption, ensuring that individual votes remain private, and generate a zero-knowledge proof that the decryption was performed correctly.
To implement this voting mechanism, we require three cryptographic building blocks:
- A linearly homomorphic threshold encryption scheme – As discussed above, we can adapt Shutter to implement ElGamal in the exponent to support linearly homomorphic operations.
- A zero-knowledge proof system for vote validity – This ensures that each encrypted vote corresponds to a valid choice (−1, 0, or 1). This can be implemented using a technique similar to the one used in a16z’s Cicada voting system, which relies on an OR-composition of discrete log equality proofs.
- A zero-knowledge proof system for correct decryption – This allows the Keypers to demonstrate that the decryption of the tally was done correctly. This proof can again be implemented by a proof of equality of two discrete logarithms.
Limitations and Comparison with Other Approaches
While using linearly homomorphic encryption for private voting offers strong privacy and verifiability guarantees, it also comes with important limitations. The first is the threshold trust assumption: the system relies on a designated set of Keypers, assuming that a certain threshold of them will behave honestly. If this assumption fails, two critical risks emerge: (1) a subset of Keypers could stall the system by refusing to cooperate in decrypting the tally, effectively blocking the publication of results; or (2) Keypers could collude to decrypt individual votes, potentially even before the voting period has ended, undermining both privacy and fairness.
Secondly, in the case of ElGamal in the exponent, recovering the plaintext during decryption requires computing a discrete logarithm - a computationally intensive task. While this is practical for small message spaces (e.g., vote tallies of size up to 2³², or around 4.3 billion), it becomes increasingly expensive as the range grows.
There are alternative approaches that should be considered when thinking about on-chain Shielded Voting.
Secret sharing: An interesting alternative is to use a secret sharing based approach, where voters share their vote to a committee of parties via a publicly verifiable secret sharing scheme. At the same time, voters prove that the secret they share is a valid vote. The committee members then publish the sum of all valid shares and the sums can be used to reconstruct the tally. Unfortunately, this approach suffers from the same threshold trust assumption as it requires a certain threshold of committee members to act honestly. It also introduces significant complexity for voters, as they are required to perform a publicly verifiable secret sharing protocol. This not only adds computational overhead but also requires direct interaction with the committee, rather than simply submitting encrypted votes on-chain, making the voting process more cumbersome.
Mixnets: Another direction is to build Shielded Voting using mixnets (e.g., 6), where voters encrypt their votes and send them to a mixnet that verifiably shuffles the encrypted votes so as to break the link between voter identity and vote. However, to compute the tally, mixnet schemes typically reveal all individual votes after the voting period ends. A promising approach is to combine mixnets with linearly homomorphic threshold encryption to get the best of both approaches: vote/voter unlinkability and individual votes being shielded for longer than the voting period.
Timelock-based approaches: An alternative approach, used by Cicada, leverages homomorphic timelock puzzles to hide votes for a fixed time (e.g., until the end of the voting period). While this ensures short-term privacy, it falls short of our goal to keep individual votes shielded indefinitely. To overcome this, Cicada proposes to anonymize voters’ identities. However, as Haines et al. point out, anonymizing voters’ identities relies on the use of anonymous communication channels, a strong and often impractical assumption. Moreover, even if all voters do use such channels, anonymity is not guaranteed: information about voter identities can still leak through indirect means, e.g., when the voter set is small. Additional downsides of the timelock-based approach are that (1) it requires a setup which needs to be computed initially, (2) the timing parameter, which determines for how long votes are hidden, is tied to the setup so the duration of a voting period is fixed, (3) it is resource-intensive to solve timelock puzzles, and (4) it takes time to reconstruct the final result after the voting period ends. The upside of Cicada compared to using secret sharing or linearly homomorphic threshold encryption is that it does not rely on the threshold trust assumption (it does rely on hardware assumptions though).
Conclusion and Future Work
Using linearly homomorphic threshold encryption is a highly effective approach for implementing on-chain Shielded Voting, as it allows individual votes to remain private even after the voting period ends. This method enables the aggregation of encrypted votes into an encrypted tally, which can then be decrypted in a threshold manner - ensuring that no single party has the power to compromise voter privacy.
The main trust assumption in this model is that a threshold of Keypers behaves honestly during decryption. While this threshold trust model is a limitation, ongoing research in academia and industry is actively exploring ways to reduce or eliminate it (see, e.g., ShutterTEE, secret sharing with snitching, or the proposal for an anti-collusion mechanism for threshold encrypted mempools).
Looking forward, there is significant potential to build on this foundation and achieve additional desirable properties in Shielded Voting systems. These include:
- Receipt-freeness and coercion-resistance, which ensure voters cannot prove how they voted and thus cannot be coerced or bribed.
- Vote delegation, which allows users to delegate their voting power while preserving vote privacy. A recent paper has demonstrated how this can be achieved using linearly homomorphic threshold encryption, providing yet another strong argument for adopting this cryptographic approach.
- Accountability, ensures that any misbehavior during vote aggregation or decryption can be detected and attributed to the responsible parties.
- Voter anonymity, which ensures that not only the content of each vote remains hidden, but also the identity of the voter who cast it. As a result, the system reveals only the total number of valid votes, without disclosing who submitted them.
By extending Shutter’s Shielded Voting with permanent private voting, we’re making it possible for DAOs to protect individual votes indefinitely - without compromising public verifiability.
The proof of concept is complete, and the next phase of development is underway.
If you're a governance platform interested in integrating this new permanent Shielded Voting, or a developer who wants to collaborate, reach out to us. We'd love to collaborate with you.
