Closing the Governance Privacy Gap On-Chain

Over the past two years, on-chain governance has leapt from niche experiments to the de-facto control layer for many of the largest crypto networks and DAOs. While that transparency has empowered communities, it also creates a new attack surface: every vote is a public signal - one that can be bought, coerced, front-run, or even socially punished. This has led to people asking: can we preserve verifiability without exposing individual voting choices?

Vitalik Said It Best: Governance Needs Privacy

That question has become especially urgent since Vitalik Buterin’s 21 May tweet, reminding the ecosystem that “just as we need privacy in finance and privacy in comms, we need privacy in governance.” His point is simple but profound: finance and communication are already forms of governance. If we want credible institutions, then protecting the governance layer itself is non-negotiable.

Answering the Call: Shielded Voting On-Chain

This blog post outlines a practical architecture to fill this privacy gap in governance: a fully on-chain Shielded Voting system built around Shutter’s threshold-encryption rails.

This approach is informed by real-world usage of a similar flow by Shutter - Snapshot’s off-chain Shielded Voting has already helped over 600 DAOs secure their voting processes. Here, we will show how those same privacy guarantees can be brought directly onto Ethereum (and EVM chains) with only minimal changes to existing Governor frameworks.

To do that, we walk through:

• Choosing the right encryption architecture for on-chain Shielded Voting
• The requirements, components, and transaction flow for a threshold-encryption design
• Architecture and transaction flow
• Problems & solutions for the threshold-encryption approach
• How the architecture can be adapted to future primitives

Choosing the Right Encryption Architecture for On-Chain Shielded Voting

Designing a privacy-preserving voting system means balancing security, decentralization, and user experience. Below we outline six common approaches and their trade-offs.

• On-Chain Decryption: Impossible today because smart contracts cannot keep secrets.
• Fully Homomorphic Encryption (FHE): Powerful but currently too heavy for real-time on-chain use.
• Custom Voting-Specific Homomorphic Schemes: Lighter than FHE but bespoke and still tricky to integrate.
• User-Based Encryption: Users reveal their own votes later - poor UX and easy to miss deadlines.
• Centralized Key Encryption: Simple but introduces a single point of trust and failure.
• VDFs + Homomorphic Encryption: Trust-minimized, yet hardware-heavy and complex.
• Threshold Encryption (our focus): A decentralized committee jointly manages keys, automatically reveals the results after the voting period, and avoids extra steps for voters while keeping trust assumptions small.

Threshold encryption therefore offers the best mix of decentralization, usability, and security for today’s production DAOs. Notably, zero-knowledge proofs alone cannot supply confidentiality; they can only attest to correctness.

On-Chain Shielded Voting with Threshold Encryption

Using Shutter’s threshold encryption, a proposer requests a fresh public encryption key from the Shutter API and stores it in the Governor contract. Voters encrypt their choices under that key and submit ciphertexts during the voting window. Once the window closes, Shutter Keypers release decryption-key shares; after which anyone can reconstruct the full key, decrypt the ballots, and post the plaintext tally on-chain.

Requirements

Bringing off-chain Shielded Voting mechanisms, such as those used by Snapshot, onto the blockchain presents several challenges: 

• Architecture: An on-chain Shielded Voting mechanism requires to design a solution that preserves the privacy of votes while maintaining verifiability and integrity of votes and preventing their premature revelation. 
• Implementation Complexity: A major constraint is to keep the implementation complexity low and avoid significant modifications to existing governance frameworks like Governor Alpha. 
• Security and Trust-Minimization: It is essential to ensure that premature revelation of shielded votes is prevented. This means that on the one hand votes must be encrypted via a secure encryption scheme (IND-CCA security) and no single party should hold the decryption key as this would introduce major trust assumptions. 

Components

Modified Governor Smart Contract: The contract manages the entire voting process. That is, it stores voting metadata (such as the voting period, number of voters, identity of voters, Shutter identity, eon public key), the encrypted votes, and the corresponding decrypted votes. It additionally implements a function that checks if the submitted decrypted votes are the correct decryption of the submitted encrypted votes.

• Proposer: The party that initiates a vote. That is, it registers the voting metadata in the modified Governor smart contract.
• Voter: Retrieves voting metadata from the modified Governor smart contract and submits encrypted vote before the end of the voting period.
• Shutter Keypers: Hold shares of the eon decryption key. When a voting period ends, the Keypers derive shares of the corresponding epoch decryption key and release them.

Executor/Decrypter: Retrieves encrypted votes from the modified Governor smart contract as well as the released key shares from the Keypers. Reconstructs the full decryption key, decrypts the votes, and submits the decrypted votes to the modified Governor smart contract.

Architecture and Transaction Flow

The general architecture and transaction flow from initiating a new Shielded Voting proposal to settling it proceeds as follows:

• Proposer creates new shielded proposal (Steps 1+2 in Figure 1)
  • Retrieves encryption data (Step 1)
  • Registers new Shutter identity with decryption time, i.e., end of voting period (Step 2)
  • On-chain transaction with vote details, the Shutter identity, and the Shutter encryption key (Epoch key) (Step 2)
• Voter retrieves vote details/identity/encryption key from modified Governor smart contract (Step 3)
• Voter votes (Step 4)
  • Encrypts voting choice with eon encryption key and Shutter identity
  • Submits encrypted vote to the modified Governor smart contract (choice is encrypted, other details in plaintext)
• Voting period ends
• Executor decrypts votes and resolves proposal (Steps 5+6)
  • Retrieves Shutter identity and encrypted votes 
  • Retrieves epoch decryption key from Shutter API (Step 5)
  • Decrypts all votes
  • For each vote, generates a zk proof of correct decryption
  • Submits everything on-chain to the modified Governor smart contract: all plaintext votes, all zk proofs, resolve transaction (Step 6)
• Modified Governor smart contract verifies the zk proofs (Step 7)
  • If a zk proof does not verify for a ciphertext, decryption of that ciphertext has to be repeated by another party
  • If a decrypted vote is invalid but the corresponding zk proof is valid, the contract does not count the vote

Problems & Solutions for the Threshold-Encryption Approach

Sub-Problem 1: On-Chain Decryption Is Infeasible Today

Because Ethereum lacks the necessary pre-compiles, decryption must happen off-chain with an on-chain validity check. Four candidate solutions:

1. Proof-by-Decrypter (Preferred).  Executor posts zk-proofs of correct decryption.
2. Proof-by-Voter.  Voters prove their ciphertexts were well-formed; the executor reveals randomness.
3. Hash Commitment.  Voters commit to salted hashes on-chain; revealed later for verification.
4. Keyper-Side Decryption.  Keypers themselves decrypt and threshold-sign the result (no new trust assumption).

Sub-Problem 2: Keyper Threshold Trust Assumption

Risk A: failure to decrypt if too many Keypers are offline. Risk B: early decryption via collusion.

Mitigations:

• General Encryption Interface.  Pluggable back-ends (time-lock, FHE, TEE, etc.).
• Backup Paths.  Dual-encryption: threshold + VDF.
• ShutterTEE.  Keypers operate inside TEEs to prevent collusion.
• User-Side Fallback. In a worst case scenario, the voters can publish the plaintext votes..

Sub-Problem 3: Quorum Visibility During Voting

Because “yes” and “no” are indistinguishable while encrypted, you cannot know if the quorum has been met until decryption of the votes. Options include using a homomorphic tally + zk, or counting “no” votes toward quorum.

Generalized Architecture

Two capabilities define an encryption back-end:

1. Provide Initial Encryption Data.  A public key or equivalent so the proposers can start a vote.
2. Release Decryption Material on Time.  Or - in the time-lock case - enable decryption without secrets once the delay has passed.

Any technology (TEE, VDF, FHE, MPC, iO) that satisfies those hooks can slot into the same flow, preserving the majority of the implementation.

Outlook & Next Steps

The threshold-encryption design described here delivers practical, trust-minimized privacy for on-chain governance today, and the generalized hooks ensure future primitives can drop in with little friction. Long term, breakthroughs such as indistinguishability obfuscation could even allow contracts to decrypt directly without leaking secrets - eliminating the final off-chain step.

We’re already working on detailed implementation guides for both OpenZeppelin Governor-based and Safe-based governance frameworks -  stay tuned!

If you're a governance platform or if your DAO is using one, reach out to us. We'd love to work with you to implement on-chain Shielded Voting!