Vote Masking and the Problem of Receipt-Freeness

Voting is one of the clearest examples of confidential coordination: multiple independent participants must produce a legitimate shared outcome without exposing their private inputs.

Within the Interfold, voting is implemented as an encrypted execution primitive. One such primitive is CRISP (Coercion-Resistant Impartial Selection Protocol), a reference application that protects not only vote confidentiality, but also receipt-freeness: voters cannot prove how they voted, even under coercion. CRISP achieves this through a masking mechanism that makes genuine vote update computationally indistinguishable from decoy operations.

In practice, masking allows participants to produce legitimate-looking updates to encrypted vote state without changing the underlying selection. This breaks the link between observable onchain activity and actual voter behaviour, making it impossible to verify whether a visible update reflects a voter’s true actions or final choice.

For more background information on CRISP, the Interfold's encrypted voting primitive, read our earlier post. To try it out, visit our proof-of-concept demo or secret ballots demo on Aragon.

The Core Problem

In voting systems, coercion means forcing a voter to act under threat or supervision. Collusion includes vote-buying and similar coordinated manipulation where voters are pressured or paid to demonstrate compliance.

In traditional in-person voting, coercion is mitigated through secret ballots, physical isolation, and controlled polling environments. In onchain governance, transactions are public, persistent, and attributable. Even when vote contents are encrypted, participation and timing remain observable, creating new coercion and collusion vectors.

Coercion risk
An attacker who controls or monitors a voter may try to:

• force the voter to cast a vote while being observed
• require the voter to reveal private keys or other cryptographic material
• demand proof that the voter submitted a transaction at a particular time
• verify that an encrypted vote corresponds to a demanded plaintext choice

Collusion risk
A vote buyer or coordinating party may try to:

• require a voter to prove they voted for a purchased or agreed choice
• demand that the voter submit a transaction during a supervised session
• condition payment on evidence that a particular encrypted vote was submitted
• treat the voter’s cryptographic material or transaction history as a receipt

Private voting through encryption is a good start, but privacy alone doesn't prevent coercion or collusion. Even when vote contents are fully encrypted, voters can be forced to prove how and when they voted.

The fundamental issue: standard encrypted voting may provide confidentiality, but not receipt-freeness. If a voter can still prove how they voted, encryption alone is insufficient.

This is especially dangerous in:

• High-stakes governance votes where significant value is at stake
• Situations where voters face pressure from employers, family, or organizations
• Vote-buying schemes in onchain governance with financial incentives
• Any context where voters might be monitored or required to prove their voting behaviour

This is precisely the failure of receipt-freeness. Vote masking solves this by providing plausible deniability even after apparent compliance. A voter could submit a vote under pressure, then later change it to their true preference or have that slot masked (or let others mask it).

Because real vote updates and masks are indistinguishable, the coercer cannot verify whether their demanded vote remained final or was changed or masked afterward.

How Vote Masking Works

Within CRISP, vote masking creates indistinguishability between genuine vote updates and decoy updates through a specific cryptographic construction.

All CRISP votes are encrypted using BFV (Brakerski-Fan-Vercauteren) fully homomorphic encryption (FHE). Due to randomness in the encryption process, encrypting the same plaintext twice results in different ciphertexts.

CRISP uses this property to encrypt zero and add it homomorphically to an existing ciphertext. To an outside observer, the resulting ciphertext is indistinguishable from a genuine vote update.

A legitimate voter path:

1. Authentication: The voter proves their identity inside a zero-knowledge circuit using:
   • An ECDSA signature that must come from a wallet that’s part of the eligible voters (census)
   • A Merkle inclusion proof for the address derived by the signed message showing they're in the voter registry
2. Vote Encryption: The circuit proves that the ciphertext was encrypted correctly using the public key of the Interfold committee for that voting round. This uses GRECO (for more detail, see this deep-dive post).
3. The circuit outputs the ciphertext, which is then submitted onchain to the smart contract, alongside a zero-knowledge proof (ZKP).

The Masking Path

Here's where it gets interesting. A masker (which could be any participant, even the voter themselves at a different time) can:

1. Retrieve the previous ciphertext from a voting slot if there's any in the slot
2. Pass all necessary data to the ZK circuit to prove that the vote ciphertext is an encryption of zero and that it is encrypted correctly using the public key of the Interfold committee for this voting round
3. Prove the homomorphic addition of an encryption of zero to the previous ciphertext, or if the slot is empty, the circuit will simply return the encryption of zero as the new ciphertext to submit to the smart contract

In the masking case, authentication is skipped because the masker does not control the voter’s wallet.

The Indistinguishability Property

To an outside observer, both paths produce identical outputs:

• Both post a ciphertext to the same Merkle tree holding all votes on the main CRISP contract
• Both generate structurally identical ZKPs
• Both update the tree in the same way

The ZK proof does not reveal which path was taken. It establishes that either:

• a legitimate voter submitted a correctly formed vote, or
• a masker correctly updated the slot by adding an encryption of zero

Crucially, verifiers learn that the update is valid, but not which branch was satisfied.

Why This Matters

This construction provides several powerful features:

1. Temporal privacy. You cannot determine when a voter actually cast their final vote, because slots may be updated multiple times.
2. Participation privacy. You cannot build a reliable list of who has voted from observing slot updates alone.
3. Resistance to timing analysis. Observers cannot cleanly map on-chain activity to voting behaviour.
4. Coercion resistance. A voter can credibly deny that an observed update reflects their final choice.
5. Forced abstention resistance. Because masking can also occur on empty slots, an observer cannot confidently infer abstention from the absence of an apparent vote.

The Circuit Design

At a high level, the circuit implements an OR proof without revealing which branch is true.

(AuthenticationValid AND VoteIsEncryptedCorrectly)
OR
(VoteIsEncryptedCorrectly AND NewCiphertext = OldCiphertext + Enc(0))

Below is a diagram showing in detail all of the possible paths, as well as inputs and outputs:

In the voting path, the circuit verifies the ECDSA signature and Merkle inclusion proof, then proves the ciphertext was encrypted correctly.

In the masking path, signature verification is intentionally not satisfied (as the masker doesn't control the voter's wallet), but the circuit still proves correct formation of the new ciphertext as OldCiphertext + Enc(0) using the correct public key.

Both voting and masking branches produce valid ciphertexts and valid proofs, making them indistinguishable to verifiers. The prover knows which branch is satisfied; the verifier does not.

Tradeoffs

Vote masking materially improves the privacy of encrypted ballots, but it does not eliminate all constraints.

1. Masking is a paid operation (gas costs), so without incentives, it may be difficult to ensure sufficient masking activity by third parties or voters themselves. This is a coordination and incentive design problem rather than a cryptographic limitation.In practice, applications may want to reserve funds to support sustained masking activity.
2. Bribers/coercers could attempt to ensure their demanded vote remains valid by forcing the voter to submit at the exact end of the voting period, minimising the window for vote changes or masks.We do not think this attack scales, as attackers would need to fight for submission on the last valid block.
3. Attackers could potentially disrupt write operations to certain slots through frontrunning attacks. By monitoring the mempool and submitting their own transaction with higher gas, they could alter the slot's state before the original transaction is processed. This would cause the original transaction to fail verification (as it references outdated state). However, this attack is expensive and difficult to scale across many voters.

Conclusion

CRISP shows how confidential coordination can be applied to secret ballots without relying on a single trusted operator.

Vote masking demonstrates how creative use of ZKPs and homomorphic encryption can solve a seemingly intractable privacy problem.

The key idea is simple: if valid vote updates and valid masks are computationally indistinguishable, observers cannot extract reliable metadata about voter behaviour, even though the process remains publicly auditable and cryptographically verifiable.

That makes receipt-freeness a property of system design, not just ciphertext secrecy. –Alessandro Cara

Try it out

Would you like to try out encrypted ballots built on the Interfold? Currently, two deployments built on top of the CRISP reference implementations are live:

• Proof-of-concept Demo: Vote on fun polls
• Secret Ballots Demo on Aragon: CRISP on Aragon OSx for secure onchain governance

Background reading

• CRISP Voting on Aragon
• Introduction to CRISP
• GRECO for FHE + ZK Consistency
• Introduction to E3s
• Circuit code