Threat model, limits & practitioner synthesis

Pin down the exact threat the paper defends against, map every condition under which the deniability guarantee degrades, separate the structural guarantees from the residual operational gap, and extract transferable lessons for engineers — above all, how to locate where a vulnerability actually lives (contract accounting vs proof system).

Track

Research

Module

5 · Research case studies

Prerequisites

Evaluation deep-dive (case study, part 5) · Trust boundaries and threat models

The adversary is the standard privacy-pool adversary, augmented with physical coercion. The baseline: observes all on-chain data, may operate relayers, and knows the full protocol specification — including that a wallet-layer decoy may exist. The augmentation: can compel the user, in person, to execute a withdrawal and to disclose a credential the user admits to holding. This is the "$5 wrench attack" — the attacker does not break the cryptography, they break the human. The entire problem exists because unlinkability against an on-chain observer says nothing about a coercer standing in the room.

The defender's goal is narrow by design: coercion deniability, meaning under duress the user surrenders one credential that yields a valid, credible withdrawal while other funds stay untouched and no protocol-introduced link is exposed. The paper calls this plausible deniability and states once, up front, that it is not absolute coercion resistance.

The paper states explicitly where the guarantee stops holding. These are not footnotes — they define the boundary of the claim.

(a) All passphrases compelled

The guarantee relies on the real passphrase being an additional secret the user can deny. If the adversary compels disclosure of ALL passphrases, there is no held-back secret and deniability collapses.

(b) Full device derivation state inspected

The memory-hard derivation makes possessing the device insufficient on its own, but if the adversary can inspect the complete derivation state, the hidden note may be exposed.

(c) Operational metadata correlated

Deposit timing, funding source, relayer, amount, and network fingerprint can correlate the two deposits. The protocol introduces no cryptographic link, but it cannot erase these. Avoiding this is the wallet's responsibility.

(d) Funding source controlled

If the adversary controls where the funds originate, they can link the two notes off-chain regardless of on-chain unlinkability.

The paper separates the linkage the protocol rules out from the linkage it does not, and the claim is exactly the first set. Three structural guarantees: (1) no explicit cryptographic linkage — no on-chain value for one note is a function of the other; (2) no derivation path between secrets — independent passphrases and salts; (3) no shared protocol handle — no shared commitment, nullifier, root-membership witness, or stored handle. One explicitly open item: (4) operational correlation may remain.

So the precise claim is: absence of protocol-introduced cryptographic linkage, up to anonymity-set size and operational metadata — NOT unconditional unlinkability. Two amounts to internalize. First, privacy is bounded by the anonymity-set size, the number of deposits sharing the denomination; a tiny set gives weak privacy no matter how clean the cryptography. Second, item (4) is a residual gap the deployment must manage, not a solved problem.

Theorem 1 is proven, but its fourth assumption (H4) is that the deployed Groth16 verifier is sound under its trusted setup. The paper is blunt: the result is "exactly as strong as the trusted setup." The deployed verifier uses a development powers-of-tau, so the proven guarantee is against the real generated verifier under a development setup — not a production security guarantee.

Concretely, Groth16 requires a per-circuit setup that produces a structured reference string; if the setup's toxic waste is known to an adversary, they can forge proofs and the soundness assumption fails. A development setup is fine for demonstrating the construction and running the [V] tests, but it is a single point of trust. The paper states a production guarantee additionally requires a multi-party Phase-2 ceremony with a published transcript, so that soundness holds as long as at least one ceremony participant was honest.

The paper names, rather than hides, what is unfinished. Treat these as the honest to-do list between the preprint and a deployable system.

• ▸Empirical anonymity is unmeasured: the paper reports no classifier-based indistinguishability experiment, and the current testnet set does not provide a meaningful anonymity set. The relevant metric — anonymity-set size on a populated deployment — is future work.
• ▸Several facets ([C]-level: value conservation, selective disclosure, shielded transfer) have verifier contracts but are not yet wired on-chain; a production deployment must wire them to real verifiers.
• ▸Trusted setup: a multi-party Phase-2 ceremony with a published transcript is required before mainnet; the development setup is for demonstration only.
• ▸The deployed testnet pools use mock verifiers predating the corrected circuits, so reaching a live, corrected pool is itself a redeployment step.
• ▸An independent professional audit is named as a prerequisite for mainnet; this case study and the paper are not a substitute for one.
• ▸Performance is deliberately unbenchmarked: only indicative component-level estimates exist, which the paper declines to use as a contribution.

The deepest transferable lesson has nothing to do with privacy pools specifically. The dual-nullifier failure was a value-safety bug in which the cryptography was flawless: Groth16 verified every proof correctly, Poseidon hashed correctly, the selector behaved as designed. The money leaked because the contract deduplicated on a spend identifier while the real invariant was about consuming an economic unit — a mismatch in state accounting, one layer above the math.

Generalize the move. When auditing any system that combines a cryptographic gadget with stateful bookkeeping, ask which object the invariant is really about and which object the code actually gates on. If those differ — here, "the note is consumed" versus "this identifier is unseen" — a correct proof can escort an incorrect state transition straight past verification.

1. 1Name the invariant in value terms, not implementation terms: "at most one value-consuming withdrawal per deposited note," not "nullifiers are unique."
2. 2Identify the exact predicate the code gates on, and the exact object it marks consumed. Here: gates on nullifierHash membership; marks the identifier, never the commitment.
3. 3Check whether one protected object can map to many gated predicates. If yes (one commitment, many valid nullifierHashes), the gate is defeatable without breaking any cryptography.
4. 4Locate the fix at the layer where the mismatch lives — constrain the mapping to be one-to-one (one note, one spend) — rather than hardening the cryptographic layer, which was never the problem.
5. 5Separate the countermeasure's placement from its mechanism: a feature that is unsafe on the spend path (an in-circuit decoy) can be safe off it (a wallet-layer decoy). Placement is a design decision with security consequences.

Expected direction: Ask: can one underlying deposit/entitlement produce more than one distinct valid receipt id that each passes the "not already used" gate, given that the gate marks the receipt id consumed and never the entitlement itself? A dangerous answer is "yes" — e.g. the proof authorizes redemption of an entitlement but the circuit does not bind the receipt id to be a unique deterministic function of that entitlement, so one entitlement yields several valid receipt ids. Then each redemption passes the gate and the vault pays out multiple times, a value-safety failure with perfectly valid proofs. The fix is to constrain the receipt id to be one-to-one with the entitlement (the analogue of one note, one spend), at the accounting layer, not to strengthen the proof system.

In one sentence, why is the deniability guarantee plausible rather than unconditional?

Because the protocol only rules out protocol-introduced cryptographic linkage; privacy remains bounded by anonymity-set size and by operational metadata (timing, funding source, relayer, amount, network fingerprint) that the wallet, not the protocol, must manage.

Name two of the four conditions under which the paper says deniability degrades.

Any two of: the adversary compels all passphrases; inspects the full device derivation state; correlates the two deposits via operational metadata; or controls the funding source.

What does "exactly as strong as the trusted setup" mean for Theorem 1?

The value-safety guarantee holds only if the deployed Groth16 verifier's setup is sound; the paper uses a development powers-of-tau, so production security additionally requires a multi-party Phase-2 ceremony with a published transcript.

What is the paper's most transferable engineering lesson about locating a vulnerability?

A security failure can live entirely in state accounting while the cryptography is flawless. Always separate the object the invariant is about (an economic note being consumed) from the predicate the code gates on (a spend identifier being unseen); if one protected object can map to many gated predicates, the gate is defeatable without breaking any crypto.