The whole F_RP framework, as written today, is completely broken by Shor's algorithm. Every elliptic-curve assumption the construction rests on — DLOG on Curve25519, q-PKE on BN254, q-DLOG on the Pasta cycle — falls in polynomial time on a sufficiently large fault-tolerant quantum computer. Pedersen commitments lose binding. Groth16 loses soundness. Ed25519 signatures lose unforgeability. The entire stack is a pre-quantum house.

Today this is fine. NIST estimates a cryptographically-relevant quantum computer is still 10-20 years away. But "we'll fix it later" is exactly how we got into the SHA-1 / RSA-1024 / DES situation. The right time to design the migration path is before there's a deadline.

This is post 11 of 11 in the relayerless-privacy series — the finale.

What Shor breaks, in one paragraph

Shor's algorithm gives a quantum polynomial-time reduction from integer factoring and discrete log to period-finding. RSA, classical Diffie-Hellman, DSA, ECDSA, Ed25519, Schnorr signatures, BLS signatures, Pedersen commitments, Pairings — every cryptographic primitive that relies on the hardness of DLOG or factoring is compromised.

For F_RP specifically, the four broken pieces:

1. Groth16 over BN254. q-PKE / q-DLOG → polynomial-time forgery.
2. Pedersen commitments over BN254. DLOG → binding broken; commitments become equivocable.
3. Ed25519 signatures. DLOG → forgery, including FROST threshold variants.
4. CSIDH and other classical isogeny constructions. Kuperberg's quantum sub-exponential algorithm threatens them more aggressively than classical attacks.

Hash-based primitives survive: SHA-2, SHA-3, Keccak, Poseidon (modulo round-by-round cryptanalysis). FRI / STARK proofs survive because they only depend on hash collision resistance, not on any algebraic structure. Lattice-based primitives (Module-LWE, Module-SIS) survive under best-known quantum attacks.

The replacement stack

Post-quantum F_RP is 5-20 KB per proof instead of 128 bytes, ~300K CU on-chain instead of 150K, and **5 KB per signature** instead of 64 bytes. The framework still works; the costs grow ~50-100× on every dimension.

Lattice-based polynomial commitments

The replacement for KZG is a polynomial commitment based on Module-LWE / Module-SIS. Two leading candidates:

Brakedown (Golovnev, Lee, Setty, Thaler, Wahby — CRYPTO 2023)

Linear-time SNARK based on linear-code polynomial commitments. The prover commits to multilinear polynomials using a linear-time encodable error-correcting code, combined with the Spartan polynomial IOP.

• Prover: O(N) field operations for N-sized R1CS.
• Proof size: ~1.5 MB for 2^20 multiplication gates (before code-switching compression).
• Verification: linear in proof size.
• No trusted setup.
• Plausibly post-quantum secure (security from collision-resistant hashing + linear-code distance).

The O(√N) base proof size is the killer for Solana — even the 4,096-byte SIMD-0296 limit isn't enough for a raw Brakedown proof on a meaningful circuit.

Orion (Xie, Zhang, Song — CRYPTO 2022)

O(N) prover time with O(log²N) proof size via code-switching composition. The code-switching mechanism reduces proof size from O(√N) to polylogarithmic by proving that the witness of a secondary zero-knowledge argument coincides with the message in a linear code.

Numbers are still rough — ~10 KB proof for 2^20 constraints — but the trajectory is right. Orion is the most promising candidate for direct on-chain verification on Solana under SIMD-0296.

Open problem 7.1 — lattice commitment size

Current lattice-based commitments produce opening proofs of size O(k · d · log q) bits, yielding 4-50 KB concretely. Determine tight lower bounds for 128-bit post-quantum security; characterise the feasibility space within Solana's tx limit.

Hash-based STARKs as universal backend

STARKs are already post-quantum (security from collision-resistant hashing only). The migration is simpler in shape but more expensive in proof size:

• FRI over Goldilocks field ($p = 2^{64} - 2^{32} + 1$): efficient NTT, native to 64-bit hardware. Plonky3 uses this.
• FRI over M31 (Mersenne-31): SIMD-optimised arithmetic. StarkWare's Circle STARK construction uses M31.

Proof size scaling: O(λ · log²N). For 2^20 steps at 128-bit security, ~50-200 KB per proof.

A 400×-1600× blowup vs. Groth16's 128 bytes. Way over Solana's transaction limit. Three deployment paths:

Path 1: STARK-in-Lattice-SNARK (Open Problem 7.2)

Wrap the STARK verifier circuit inside a lattice-based SNARK to recover succinct on-chain verification. The STARK verifier circuit is O(log²N) hash evaluations + field operations. With Poseidon (250 R1CS constraints per hash), 2^20-step verification is `100K` constraints.

Recursive composition:

$$ \pi_{\mathrm{outer}} ;=; \mathsf{Prove}{\mathrm{Lattice}}\bigl(,\mathsf{Verify}{\mathrm{STARK}}(\pi_{\mathrm{inner}}) = 1,\bigr). $$

Estimated proof size: ~5-20 KB. Marginal fit for SIMD-0296 (4,096-byte transactions). Open whether the lattice outer is small enough.

Path 2: STARK aggregation (STARKPack)

Aggregate n STARK proofs into a single argument that's $(1 + 1/n)$× the size of a single proof, with ~2× faster verification.

Doesn't help individual transactions (still 100 KB per submission) but amortises validator-side cost dramatically.

Path 3: Off-chain STARK with on-chain commitment

The most pragmatic near-term path. Publish the full STARK proof to a data-availability layer (Solana ledger via call-data, or a separate DA chain). On-chain verify only a 32-byte hash commitment. Add a challenge period where any observer can verify the off-chain proof and dispute on-chain if it's invalid.

^* Requires off-chain proof availability + honest-verifier assumption for retrieval.

Isogeny-based group actions for credentials

For applications needing anonymous identity binding — compliance-compatible privacy, selective disclosure, "prove balance ≥ threshold without revealing balance" — isogeny-based cryptography offers post-quantum group actions that can replace DLOG-based constructions.

CSIDH-based ring signatures

CSIDH defines a commutative group action ★: Cl(O) × E(F_p) → E(F_p) between the ideal class group of an imaginary quadratic order and the set of supersingular elliptic curves over F_p. This group action instantiates Sigma protocols for "knowledge of an isogeny", which yields ring signatures via Fiat-Shamir.

Current status (cautious): CSIDH at NIST-1 security needs p ≈ 2^512, key sizes 64 B, computation ~50-100 ms. Quantum security analysis (Bonnetain-Schrottenloher, Peikert) shows Kuperberg's quantum sub-exponential algorithm threatens CSIDH more aggressively than classical attacks — proposed 128-bit classical / 64-bit quantum parameters can be broken in `2^35quantum key-exchange evaluations, not~2^62`.

So CSIDH at the 128-bit level is not secure at the originally advertised parameters. Larger parameters (p ≈ 2^4096+) restore the security but balloon costs.

SQIsign

SQIsign (De Feo, Kohel, Leroux, Petit, Wesolowski — NIST Round 2) offers compact post-quantum signatures (204 bytes) from quaternion isogeny problems. Signing time ~100 ms.

Verification is computationally expensive (~100 ms), which makes it impractical for direct on-chain verification on Solana — a single SQIsign verification would consume the entire 1.4M CU budget.

Open problem 7.3 — isogeny anonymous credentials

Design an anonymous credential scheme based on supersingular isogeny group actions that:

1. Supports selective attribute disclosure.
2. Has verification time < 10 ms (compatible with blockchain block times).
3. Achieves 128-bit post-quantum security with concrete parameter justification.
4. Is compatible with the SPST note model (credentials bound to note commitments).

This is wide open. The most promising shape is a hybrid architecture: isogeny-based credentials for identity binding, composed with STARK proofs for the transactional privacy layer.

What survives without modification

Two pieces of F_RP carry over unchanged into the post-quantum world:

1. Poseidon Merkle trees. Hash-based, no algebraic structure assumption beyond collision resistance.
2. Indexed Merkle Trees for nullifier non-membership. Same hashes, same structure, same constraints.

So the state layer of F_RP doesn't need to change. Only the proof and signature layers.

Migration timeline (rough)

This timeline is contingent on (a) NIST shipping PQC standards on schedule, (b) Solana adopting the syscalls within ~2 years of standardisation, and (c) lattice-based polynomial commitments achieving sub-10 KB proof sizes. None of these are certain. All three look likely.

What would have to change in F_RP itself

The protocol design is mostly insulated. Specifically:

1. The note model is unchanged. Notes, commitments, nullifiers, Merkle trees — all hash-based.
2. The five-tuple (Setup, Deploy, Invoke, Verify, Finalize) is unchanged. Just the proof system inside Invoke/Verify swaps out.
3. The simulation-based privacy theorem (3.12) survives. The hybrid argument's transitions are: ZK of proof system, pseudorandomness of hash, pseudorandomness of PRF, CCA2 of encryption. The ZK / PRF / CCA2 each get a post-quantum-secure replacement; the structure of the proof is the same.
4. The self-sovereignty theorem (3.13) survives unchanged. It only depends on chain liveness and proof system completeness.

What changes: byte sizes, CU costs, prover times. The math survives. That's a lucky property of having designed F_RP around the abstract Π_hybrid rather than committing to Groth16 in the relations.

Why this isn't urgent (today)

It's worth ending the series with the honest answer to "should I be worried right now?":

No. Not in 2026, not in 2028. A cryptographically-relevant quantum computer is plausibly a decade-plus away. The harvest-now-decrypt-later threat applies to confidentiality (encrypted communications today, decrypted later when QC arrives) — but most F_RP outputs are commitments and nullifiers, not encrypted plaintexts. The information-theoretic content of an old shielded transaction is bounded; an adversary who breaks it in 2040 learns transaction graph structure that's no longer interesting.

What does need attention: building the migration path now so that when the day comes, F_RP isn't a 2-year rewrite project. That's what this post is for.

Closing the series

Eleven posts:

1. Series intro — the F_RP framework and the five games.
2. The fee paradox — why every smart-contract privacy protocol needs a relayer.
3. SPST — self-paying shielded transactions, four security theorems.
4. PPST — private programmable state via R1CS embedding.
5. TAB — submitter anonymity via ring sigs and FROST.
6. Verifiable shuffles — Bayer-Groth network-layer mixing.
7. UPEE — composing the framework, the simulation-based privacy and self-sovereignty theorems.
8. Solana instantiation — concrete numbers: 656 bytes, 235K CU.
9. F_RP vs the rest — comparison with nine deployed privacy systems.
10. MEV resistance — sandwich-proof by construction; Theorem 7.4.
11. Post-quantum migration — the future-proofing plan you just read.

The full preprint will land at /papers/relayerless-privacy/ once typeset. Until then the series is the canonical reference. If you want to discuss any of it, book a call or open an issue on Dax911/zera-sdk.

Thanks for reading.

Bibliography

• Shor, P. W. (1997). Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. SIAM Journal on Computing.
• Golovnev, A., Lee, J., Setty, S., Thaler, J., Wahby, R. (2023). Brakedown. CRYPTO 2023.
• Xie, T., Zhang, Y., Song, D. (2022). Orion. CRYPTO 2022.
• Ben-Sasson, E. et al. (2018). STARKs. https://eprint.iacr.org/2018/046
• De Feo, L., Kohel, D., Leroux, A., Petit, C., Wesolowski, B. (2020). SQIsign. ASIACRYPT 2020. https://eprint.iacr.org/2020/1240
• Castryck, W. et al. (2018). CSIDH. ASIACRYPT 2018. https://eprint.iacr.org/2018/383
• Bonnetain, X., Schrottenloher, A. (2018). Quantum Security Analysis of CSIDH.
• Peikert, C. (2020). He gives C-sieves on the CSIDH.
• NIST PQC Round 4 — Post-Quantum Cryptography Standardization.

Previous: MEV resistance ← · Series: back to start

I've now spelled out the full F_RP framework. Two natural next questions:

1. Has someone built this already?
2. If not, what's the closest existing thing and why doesn't it cover the same ground?

This post answers both. We compare F_RP against nine deployed privacy systems on twelve axes. The TL;DR: no existing system simultaneously achieves relayer-free operation, Turing-complete computation privacy, and on-chain-verifiable proofs on a general-purpose Layer-1 blockchain. That's the gap F_RP fills.

This is post 9 of 11 in the relayerless-privacy series.

The matrix

Three things F_RP gets that nobody else gets simultaneously

1. Relayer-free on a smart-contract chain

Zcash, Penumbra, Monero, and Aleo are all relayer-free, but they're each their own L1 chain. Their consensus, validators, and fee mechanism are bespoke. They get relayer-freedom by being a chain, not by solving the smart-contract-layer problem.

Aztec is relayer-free on a smart-contract platform — but it's an L2 rollup with its own sequencer. The sequencer is the de facto relayer with extra steps; if it goes offline, the L2 stalls. Aztec's deployment model isn't applicable to Solana.

F_RP runs as a smart-contract program on Solana mainnet. Same validators that run Jupiter and Helium. No new chain, no new sequencer, no relayer. The only assumption is Solana's chain liveness — which is what every Solana program already assumes.

2. Turing-complete program privacy

Tornado Cash and RAILGUN provide value transfer only. No conditional logic, no AMM, no auctions — just shielded ERC-20 transfers (or fixed-denomination ETH). Adding programmability would require redesigning the protocol from the ground up.

Aztec and Aleo do offer programmability. Aztec ships Noir, Aleo ships Leo. Both work, both are L1-or-L2 specific.

F_RP's PPST construction puts arbitrary arithmetic circuits inside the proof on a chain that wasn't built for them. The R1CS for the user's program is embedded as a sub-circuit of the outer PPST relation. The Solana on-chain verifier doesn't care what the program is — it just verifies the wrapping Groth16 proof.

3. On-chain verification on a high-throughput L1

Solana's alt_bn128 syscalls verify Groth16 in 150K CU ($0.02 USD at typical priority fees). Block time ~600ms. Theoretical TPS in the tens of thousands.

The cost difference is ~250× and the latency difference is ~20×. For a privacy protocol that wants to compose with public DeFi (private swap → public AMM → private settlement), Solana's economics are the only ones that work for retail users.

Where F_RP loses to existing systems

Honest comparison cuts both ways. Three places F_RP loses:

To Zcash Orchard: trusted setup

Zcash Orchard uses Halo 2 with IPA over Pasta curves — fully transparent, no per-circuit ceremony. F_RP's primary instantiation uses Groth16 with a per-circuit MPC ceremony.

The migration path is the hybrid proof architecture (Theorem 3.8): inner STARK or Nova folding (transparent), outer Groth16 wrapper. Once SIMD-0302 ships on Solana (BN254 G2 syscall), we can switch the outer to PLONK with universal SRS — eliminating per-circuit ceremonies. Until then, Groth16 is the price of admission for cheap on-chain verification.

To Monero: simplicity of the threat model

Monero's privacy story fits in three sentences: ring signatures hide the sender, stealth addresses hide the receiver, RingCT hides the amount. No L2, no relayers, no shielded pool, no programmability. That simplicity is a feature — Monero has been deployed and battle-tested since 2014.

F_RP is more complex because it does more. Programmability is genuinely harder than value transfer. The pricing of that complexity is on the user; the gain is composability with the rest of the Solana ecosystem.

To Aztec: native privacy DSL

Aztec ships Noir, a Rust-like DSL purpose-built for ZK circuits. Compiles to ACIR, plugs into Honk / Barretenberg with first-class Aztec idioms (private functions, public functions, schedule-cross-boundary calls).

F_RP currently relies on Circom or Noir for circuit authoring, with the developer responsible for wiring the program into the PPST relation. There's no "F_RP DSL" yet. That's a tooling gap, not a protocol gap — Noir-to-PPST adapters are an obvious next step.

What F_RP and Zcash agree on

A pleasant surprise: F_RP's SPST construction and Zcash's Sapling spend description are mathematically isomorphic. Same note/commitment/nullifier model, same value-balance equation, same Pedersen value commitments.

The differences are deployment:

• Zcash runs on its own L1 with native fee handling.
• F_RP runs on Solana with the fee extracted from a program PDA reserve.

The cryptography is the same. F_RP is, in some sense, "Zcash's Sapling pool, ported to Solana, extended with PPST for programs and TAB for submitter anonymity, with fees handled by an in-program reserve."

What F_RP and Aleo agree on

Aleo's records model (from ZEXE) and F_RP's PPST share the core insight: a private program is an arithmetic circuit, and the proof attests to correct execution over committed state. Both use a notion of records / notes that get nullified on consumption.

The difference is again deployment:

• Aleo runs on its own L1 with a native delegated-prover marketplace.
• F_RP runs on Solana with prover delegation as a separate off-chain market.

And one big disagreement: Aleo has elected not to implement function privacy — the program ID is visible on-chain. F_RP makes the same trade-off in v1 but flags universal-circuit-based function privacy as a future extension.

The 2x2x2 decision lattice

Here's the same data as a decision tree:

<Mermaid id="frp-decision-tree" code={graph TD Q1{Need on-chain<br/>smart contracts?} Q1 -->|No| Q2{Want<br/>programmability?} Q1 -->|Yes| Q3{Need it<br/>relayer-free?} Q2 -->|No| Z[Zcash / Monero] Q2 -->|Yes| A[Aleo / Penumbra] Q3 -->|No| T[Tornado / RAILGUN<br/>relayer-dependent] Q3 -->|Yes| Q4{Layer 1 or 2?} Q4 -->|L2| AZ[Aztec] Q4 -->|L1| F[F_RP] classDef leaf stroke:#4ade80,stroke-width:2px,fill:#0a0a0a,color:#fff classDef us stroke:#facc15,stroke-width:3px,fill:#0a0a0a,color:#fff class Z,A,T,AZ leaf class F us }/>

The branch where F_RP lives — "yes I want a smart-contract chain, yes I want relayer-free, yes I want L1, with cheap on-chain verification" — is the cell that was empty until now.

Bibliography

• Hopwood, D., Bowe, S., Hornby, T., Wilcox, N. Zcash Protocol Specification. https://zips.z.cash/protocol/protocol.pdf
• Pertsev, A., Semenov, R., Storm, R. Tornado Cash Privacy Solution v1.4.
• RAILGUN Documentation. Privacy System Architecture.
• Aztec Network. Client-side Proof Generation. https://aztec.network/blog/client-side-proof-generation
• Penumbra Labs. Penumbra Protocol Documentation. https://protocol.penumbra.zone/main/index.html
• Bowe, S., Chiesa, A., Green, M., Miers, I., Mishra, P., Wu, H. (2020). ZEXE. IEEE S&P 2020.
• Namada Network. Multi-Asset Shielded Pool. https://github.com/namada-net/masp
• Noether, S., Mackenzie, A. (2016). Ring Confidential Transactions. MRL-0005.

Previous: Solana instantiation ← · Next: MEV resistance →

SPST hides what value moved. PPST hides what program ran. Neither hides who submitted the transaction. On any chain that requires a signature on the outer transaction (Solana, Ethereum, Aptos, Sui — all of them), the public key of the submitter is right there in the transaction header.

Without a relayer, the submitter must sign with their own key. The Ed25519 public key tells the chain exactly which private actor authorised the proof. ZK on the inside; perfect plaintext on the outside.

This is post 5 of 11 in the relayerless-privacy series. Here we close the submitter-identification gap with two complementary network-layer primitives.

The submitter identification problem, formally

Definition (Active Participant Set). $\mathcal{S} = {(\mathsf{pk}_i, \mathsf{sk}i)}{i=1}^N$ — the set of active F_RP participants at a given epoch. Each holds a Curve25519 keypair registered on chain.

Definition (Anonymity Set Reduction Attack). Adversary $\mathcal{A}$ with full read access to $\sigma$. Define:

$$ \mathcal{A}{\text{eff}}(\mathsf{tx}) = {, i \in \mathcal{S} : \Pr[\text{participant } i \text{ submitted } \mathsf{tx} \mid \mathsf{View}{\mathcal{A}}] > 0 ,}. $$

Naive relayerless setting: $|\mathcal{A}_{\text{eff}}| = 1$. Ed25519 signatures are strongly unforgeable — there is exactly one $\mathsf{pk}_i$ that verifies. Conditional entropy:

$$ H(\text{submitter} \mid \mathsf{View}_{\mathcal{A}}) ;=; 0. $$

Worst possible. Even though the contents of the transaction (the SPST/PPST proof) reveal nothing about which notes were spent, the submitter's pubkey reveals exactly who authorised the spend. Off-chain metadata (IP, timing, prior-deposit history, exchange KYC) collapses any remaining anonymity.

Approach A — Fujisaki-Suzuki ring signature over Ed25519

Adapt the linkable ring signature framework of Fujisaki and Suzuki (2007) to the Ed25519 group. Let $\mathbb{G}$ be the prime-order Ed25519 subgroup with generator $G$ and order $\ell$. Two random oracles: $\mathsf{H}p : {0,1}^* \to \mathbb{Z}\ell$ and $\mathsf{H}_G : {0,1}^* \to \mathbb{G}$.

Sign with ring $R = {\mathsf{pk}_1, \ldots, \mathsf{pk}_n}$ at signer index $s$:

1. Key image. $I = \mathsf{sk}_s \cdot \mathsf{H}_G(\mathsf{pk}_s)$ — deterministic linkability tag, hides $s$.
2. Commitment. Sample $\alpha \xleftarrow{R} \mathbb{Z}_\ell$. Compute $L_s = \alpha G$, $R_s = \alpha \mathsf{H}_G(\mathsf{pk}_s)$.
3. Challenge propagation. For $i = s+1, s+2, \ldots, s-1 \pmod{n}$ sample $c_i, r_i \xleftarrow{R} \mathbb{Z}_\ell$ and compute $$ L_i = r_i G + c_i \mathsf{pk}_i, \quad R_i = r_i \mathsf{H}_G(\mathsf{pk}i) + c_i I, \quad c{i+1} = \mathsf{H}_p(m, L_i, R_i). $$
4. Close. Set $c_{s+1} = \mathsf{H}_p(m, L_s, R_s)$, propagate to obtain $c_s$, compute $r_s = \alpha - c_s \mathsf{sk}_s \pmod{\ell}$.
5. Output. $\sigma_{\text{ring}} = (I, c_1, r_1, \ldots, r_n)$.

Verify. Recompute every $L_i, R_i, c_{i+1}$. Accept iff $c_{n+1} = c_1$.

Signature size. $I \in \mathbb{G}$ (32 B compressed) + $c_1 \in \mathbb{Z}_\ell$ (32 B) + $n$ scalars $r_i$ (32 B each) = $64 + 32n$ bytes.

Solana transaction-size constraint

With ~300 bytes reserved for transaction metadata + nullifiers + Groth16 proof + recent blockhash, ~930 bytes are available for the ring signature inside the 1,232-byte limit:

$$ n_{\max} ;=; \left\lfloor \frac{930 - 64}{32} \right\rfloor ;=; 27. $$

Under SIMD-0296 (4,096-byte transactions, approved late 2025), this jumps to $n_{\max} \approx 119$.

Verification cost: each ring member needs 2 scalar multiplications + 1 hash ≈ 5,300 CU. For $n = 27$, that's $\sim 143{,}100$ CU on top of the ~150,000-200,000 CU for SPST verification. Total: ~340,000 CU — about 24% of the 1.4M CU budget.

Theorem 3.9 — Ring anonymity

Statement. In the random oracle model, for any ring $R$, any indices $i, j \in [n]$, and any PPT distinguisher $\mathcal{D}$:

$$ \bigl|\Pr[\mathcal{D}(m, R, \mathsf{RingSign}(\mathsf{sk}_i, m, R)) = 1] - \Pr[\mathcal{D}(m, R, \mathsf{RingSign}(\mathsf{sk}_j, m, R)) = 1]\bigr| = 0. $$

Perfect (information-theoretic) anonymity in the ROM.

Proof sketch (two steps).

Step 1 — Key image indistinguishability. $I_s = \mathsf{sk}_s \cdot \mathsf{H}_G(\mathsf{pk}_s)$. Since $\mathsf{H}_G$ is a random oracle independent of $G$, $\mathsf{H}_G(\mathsf{pk}_s)$ is a uniform random group element. The product $\mathsf{sk}_s \cdot \mathsf{H}_G(\mathsf{pk}_s)$ is uniform over $\mathbb{G}$ from the adversary's view (one-more discrete-log assumption).

Step 2 — Transcript simulation. For any $s$, the tuple $(c_1, r_1, \ldots, r_n)$ is uniform over $\mathbb{Z}\ell^{2n}$ subject to the ring-closure constraint. The simulator $\mathsf{Sim}(m, R)$ that knows no secret key produces an identically distributed output by sampling all $(c_i, r_i)$ uniformly and programming the random oracle to close the ring. The marginal distributions are identical for every $s \in [n]$, so $\mathsf{Adv}{\mathcal{D}}^{\text{anon}} = 0$. ∎

Corollary. Ring signature of size $n$ provides $\log_2(n)$ bits of submitter anonymity. For $n = 27$ that's $\sim 4.75$ bits; for $n = 119$ (SIMD-0296) that's $\sim 6.9$ bits. Real-world anonymity is bounded by side-channel leakage (timing, IP) but the on-chain view alone provides exactly $\log_2(n)$.

Approach B — FROST threshold Schnorr (TAB proper)

Ring signatures grow linearly with $n$. For high-throughput deployments where $n \gg 27$ is desired, we want a constant-size signature. Threshold Schnorr is the answer.

Setup. $n$ participants run a one-time Distributed Key Generation (Feldman VSS) producing:

• A group public key $\mathsf{pk}{\text{group}} = \mathsf{sk}{\text{group}} \cdot G$ (the group secret is never reconstructed).
• Individual shares $\mathsf{sk}_{\text{share},i}$ for each participant.
• A threshold $t \leq n$.

Sign (FROST round structure): Any subset $T \subseteq [n]$ with $|T| = t$ can co-produce a Schnorr signature on message $m$:

1. Commitment round. Each $i \in T$ samples nonces $d_i, e_i \xleftarrow{R} \mathbb{Z}_\ell$ and broadcasts $D_i = d_i G$, $E_i = e_i G$.
2. Signing round. Each $i$ computes $$ \rho_i = \mathsf{H}(i, m, {(D_j, E_j)}{j \in T}), \quad R = \sum{j \in T} (D_j + \rho_j E_j), $$ $$ c = \mathsf{H}(R, \mathsf{pk}{\text{group}}, m), \quad \lambda_i = \prod{j \in T \setminus {i}} \frac{j}{j - i} \pmod \ell, $$ $$ z_i = d_i + \rho_i e_i + c \lambda_i \mathsf{sk}_{\text{share},i} \pmod \ell. $$
3. Combine. $\sigma_{\text{threshold}} = (R, z)$ with $z = \sum_{i \in T} z_i$.

Verify. Standard Schnorr verification against $\mathsf{pk}_{\text{group}}$:

$$ z G ;\stackrel{?}{=}; R + c \cdot \mathsf{pk}_{\text{group}}. $$

Signature size. $(R, z)$ = 32 + 32 = 64 bytes. Independent of $n$ and $t$. Identical to a standard Ed25519 signature.

Theorem 3.10 — TAB privacy

Statement. For any two subsets $T, T' \subseteq [n]$ with $|T| = |T'| = t$, and any PPT $\mathcal{A}$ controlling up to $t-1$ participants, the threshold signature produced by $T$ is computationally indistinguishable from the one produced by $T'$.

Proof structure. Hybrid argument over the FROST protocol:

• Hybrid 0: real $T$. Adversary observes final $(R, z)$ + $t-1$ partial signatures from corrupted parties.
• Hybrid 1: replace $R$ with a uniform random $\mathbb{G}$ element. Honest participants' nonces $d_j, e_j$ for $j \in T \setminus \mathcal{C}$ are uniform; sum is uniform. Distribution identical.
• Hybrid 2: replace $z$ with the deterministic value $z = R/G + c \cdot \mathsf{sk}{\text{group}}$ (well-defined given $R, c, \mathsf{pk}{\text{group}}$). Same distribution.
• Hybrid 3: real $T'$. Same argument.

Honest partial signatures are never revealed to $\mathcal{A}$ (they're consumed in combination). The final $(R, z)$ depends only on the honest contribution to $R$ — uniform regardless of $T$. ∎

Anonymity: Unbounded. As long as $|T| \geq t$ and at least one honest participant in $T$ exists, the adversary cannot determine which subset signed. With $n$ in the thousands and $t$ in the hundreds, $|T|$ choices are combinatorial and indistinguishable.

Tradeoffs at a glance

<TradeoffTable rows={[ { aspect: 'Signature size', pros: 'TAB: O(1) = 64 B (constant)', cons: 'Ring: O(n) = 64 + 32n B' }, { aspect: 'Verification cost', pros: 'TAB: 1 scalar mul + 1 hash (≈2,500 CU)', cons: 'Ring: n × (2 scalar mul + 1 hash) (≈5,300n CU)' }, { aspect: 'Interaction', pros: 'Ring: non-interactive', cons: 'TAB: 2 rounds of signing + O(n²) DKG once' }, { aspect: 'Anonymity guarantee', pros: 'Both: perfect (ROM)', cons: '—' }, { aspect: 'Max ring/group size on Solana', pros: 'TAB: unbounded (sig is 64 B)', cons: 'Ring: ~27 (1,232 B) or ~119 (SIMD-0296)' }, { aspect: 'Trust model', pros: 'Ring: no setup trust', cons: 'TAB: DKG integrity (Feldman VSS verifiability)' }, { aspect: 'Linkability', pros: 'Ring: same signer → same key image (anti-sybil)', cons: 'TAB: signatures unlinkable across transactions' }, ]}/>

Why both, not one or the other

The two approaches cover different deployment regimes:

• Bootstrapping / low coordination: ring signatures. No DKG required; any user can sign with any ring composed of $n$ on-chain pubkeys. Anonymity scales to the size of the ring you can pack into the transaction.
• Established network with stable participants: TAB / FROST. One-time DKG cost amortises across all transactions; signatures are minimum-size; anonymity is bounded by the group size, not the transaction size.

In practice, F_RP starts in the ring-signature regime and migrates to TAB once the network has enough committed participants for a meaningful DKG. The constructions are not mutually exclusive — the on-chain verifier can accept either type and the wrapping Solana transaction looks identical in size in the TAB case.

What's still missing

Even with TAB, two leakage channels remain:

1. Network metadata. The TCP/QUIC packet that hits a Solana RPC node has a source IP. Without Tor, I2P, or Dandelion++, that IP links directly to the user. Post 6 addresses this with verifiable shuffles at the network layer.
2. Timing correlation. A user who shields and spends within the same minute is still linkable via temporal proximity, regardless of how many ring members they hide in. Mitigations are about user behaviour and client-side delay sampling.

Bibliography

• Fujisaki, E., Suzuki, K. (2007). Traceable Ring Signature. PKC 2007.
• Komlo, C., Goldberg, I. (2020). FROST: Flexible Round-Optimized Schnorr Threshold Signatures. SAC 2020. https://eprint.iacr.org/2020/852
• Feldman, P. (1987). A Practical Scheme for Non-Interactive Verifiable Secret Sharing. FOCS 1987.
• Goodell, B., Noether, S. (2020). Concise Linkable Ring Signatures and Forgery Against Adversarial Keys (CLSAG). https://eprint.iacr.org/2019/654
• Bernstein, D. J. et al. (2012). High-speed high-security signatures. Journal of Cryptographic Engineering.

Previous: PPST: private programmable state ← · Next: Bayer-Groth verifiable shuffles →

SPST gave us private value transfer with self-paying fees on a smart-contract chain. That's the Solana analogue of Zcash's Sapling — and exactly what every existing relayer-dependent privacy mixer (Tornado, RAILGUN, Light v1) does, just without the relayer.

But Tornado-style protocols are not the goal. The goal is Turing-complete private computation: a Solana program that runs on encrypted state and produces a proof of correct execution without leaking what the state was, what the inputs were, or what the program output. That's PPST.

This is post 4 of 11 in the relayerless-privacy series. Reading post 3 first will help, but the construction here stands alone.

What "private program" means here

Definition (Private Program). A private program is an arithmetic circuit

$$ C : \mathbb{F}p^{n{\mathsf{in}}} \to \mathbb{F}p^{n{\mathsf{out}}} $$

over the BN254 scalar field, specified by an R1CS constraint system $(A, B, C)$ of size $N_C$. Each program is identified by

$$ \mathsf{program_id} ;=; \mathsf{Poseidon}(\mathsf{vk}_C), $$

where $\mathsf{vk}_C$ is the Groth16 verification key. The program identifier is a public, deterministic commitment to the program's logic.

Definition (Private State). A vector $\mathsf{state} \in \mathbb{F}_p^k$ committed as

$$ \mathsf{cm}{\mathsf{state}} ;=; \mathsf{Poseidon}(\mathsf{state}[0], \ldots, \mathsf{state}[k-1], r{\mathsf{state}}). $$

State commitments are leaves in a state Merkle tree $\mathcal{T}_S$ of depth 32, root $\mathsf{rt}_S$. This is a separate tree from the SPST note-commitment tree.

Definition (State Transition). A triple $(\mathsf{state}{\mathsf{pre}}, \mathsf{aux}, \mathsf{state}{\mathsf{post}})$ where $\mathsf{aux}$ is private auxiliary input and

$$ C(\mathsf{state}{\mathsf{pre}}, \mathsf{aux}) ;=; \mathsf{state}{\mathsf{post}}. $$

The transition consumes $\mathsf{cm}{\mathsf{pre}}$ via nullification and produces $\mathsf{cm}{\mathsf{post}}$ as a new tree leaf. The program logic $C$ is never revealed to the verifier — only $\mathsf{program_id}$ is.

The PPST relation

The relation $\mathcal{R}_{\mathsf{PPST}}$ is the set of $(x, w)$ pairs:

Public instance $x = \bigl(\mathsf{rt}{\mathsf{pre}}, \mathsf{rt}{\mathsf{post}}, \mathsf{nf}{\mathsf{state}}, \mathsf{cm}{\mathsf{post}}, \mathsf{program_id}, f\bigr)$.

Private witness $w = \bigl(\mathsf{state}{\mathsf{pre}}, r{\mathsf{pre}}, \mathsf{path}{\mathsf{pre}}, sk{\mathsf{state}}, \mathsf{aux}, \mathsf{state}{\mathsf{post}}, r{\mathsf{post}}, \mathsf{vk}_C\bigr)$.

Nine constraints, all enforced by the outer PPST circuit:

P5 is the heart of the construction. The user-defined program $C$ — written in Circom, Noir, Leo, or any high-level circuit DSL — is embedded as a sub-circuit inside the outer PPST relation. The R1CS for $C$ becomes constraints inside the R1CS for $\mathcal{R}_{\mathsf{PPST}}$.

How the program embedding works

<Mermaid id="ppst-embedding" code={graph LR A[High-level program<br/>private fn swap{a,b}<br/>in Noir/Leo/Circom] --> B[Compiler] B --> C[R1CS for C<br/>~10K-1M constraints] C --> D[Merge into PPST circuit<br/>R1CS<sub>PPST</sub> = R1CS<sub>overhead</sub> + R1CS<sub>C</sub>] D --> E[Groth16.Setup<br/>per-program ceremony] E --> F[vk_C → on-chain PDA<br/>at addr_C = PDA{H{vk_C}}] classDef step stroke:#4ade80,stroke-width:2px,fill:#0a0a0a,color:#fff class A,B,C,D,E,F step }/>

The outer circuit sizes look like:

$$ N_{\mathsf{PPST}} ;\approx; N_{\mathsf{overhead}} ;+; N_C $$

where $N_{\mathsf{overhead}} \approx 25{,}000$ R1CS constraints (Merkle paths, commitment hashes, PRF evaluations — see SPST §3.1.6) and $N_C$ is the program circuit size.

Complex programs need IVC. PPST extends naturally: decompose the computation into $T$ uniform steps each running $C_{\mathsf{step}}$, fold them with Nova or SuperNova, then wrap the final accumulator in a Groth16 decider proof. The on-chain verifier always sees a constant-size 128-byte proof regardless of $T$. Off-chain proving is $O(T \cdot |C_{\mathsf{step}}|)$ but the chain doesn't care.

Theorem 3.6 — PPST soundness

Statement. If Groth16 is knowledge-sound and Poseidon is collision-resistant, no PPT adversary can cause the PPST verifier to accept a transaction corresponding to an invalid state transition (one where $C(\mathsf{state}{\mathsf{pre}}, \mathsf{aux}) \neq \mathsf{state}{\mathsf{post}}$) except with negligible probability.

Proof sketch. Suppose $\mathcal{A}$ produces a valid PPST transaction whose underlying transition is invalid. By Groth16 knowledge soundness, the extractor $\mathcal{E}$ recovers a witness $w^$ satisfying constraints P1–P9 — including P5: $C(\mathsf{state}^{\mathsf{pre}}, \mathsf{aux}^) = \mathsf{state}^{\mathsf{post}}$. Direct contradiction. ∎

Corollary (State Integrity). The state tree $\mathcal{T}_S$ maintains the invariant that every leaf is a commitment to a state that resulted from a valid execution of an authorized program starting from a previously valid state. By induction on accepted transactions, this invariant holds at all times.

Theorem 3.7 — PPST zero-knowledge

Statement. PPST reveals nothing about $\mathsf{state}{\mathsf{pre}}$, $\mathsf{state}{\mathsf{post}}$, $\mathsf{aux}$, or the internal logic of $C$ beyond the public outputs.

Proof sketch. Direct from perfect ZK of Groth16. The simulator $\mathcal{S}$ depends only on the public instance $x$, not on the witness. For any two valid witnesses $w_0, w_1$ consistent with the same $x$, the proof distributions are identical.

What does leak:

• program_id is intentionally public. It identifies which program executed so the verifier can pick the right verification key. Full function privacy (hiding the program identity) requires a universal circuit or a commitment-to-vk argument and is left as a future extension.
• The fact that some state transition occurred under that program.
• The fee $f$.

What does not leak:

• The specific state values.
• The auxiliary inputs.
• Which specific leaf in $\mathcal{T}_S$ was consumed.

Theorem 3.8 — PPST-SPST composability

This is the magic. PPST and SPST compose into a single atomic transaction: execute a private program AND transfer shielded value, in one ZK proof.

Construct the composite relation $\mathcal{R}{\mathsf{PPST+SPST}} = \mathcal{R}{\mathsf{PPST}} \wedge \mathcal{R}_{\mathsf{SPST}}$ with a linking constraint:

$$ \mathsf{link} ;=; \mathsf{Poseidon}(\mathsf{nf}_{\mathsf{state}}, \mathsf{nf}_1, \ldots, \mathsf{nf}_n) $$

binding the PPST state nullifier to the SPST input nullifiers. Both sub-proofs reference the same link value as a public input.

Cross-constraint (Value Mediation): if the program outputs a transfer amount $\Delta v$, the SPST component enforces

$$ \sum_i v^{(\mathsf{SPST})}{\mathsf{in},i} ;=; \sum_j v^{(\mathsf{SPST})}{\mathsf{out},j} ;+; f ;+; \Delta v_{\mathsf{to_program}}. $$

That is — value flowing from the SPST shielded pool into the program's state (or out of it) is reconciled inside the proof. An observer cannot tell whether the program consumed value, produced value, or merely transferred it.

Practical realisation. For a moderate program ($N_C \sim 50{,}000$):

$$ N_{\mathsf{comp}} = N_{\mathsf{PPST}} + N_{\mathsf{SPST}} + N_{\mathsf{link}} ;\approx; (50{,}000 + 25{,}000) + 24{,}000 + 400 ;\approx; 100{,}000 \text{ constraints}. $$

Groth16 prover time on commodity hardware: 5–10 seconds. Single 128-byte proof on-chain. ~200,000 CU verification cost on Solana.

Comparison with Aleo and Aztec

<TradeoffTable rows={[ { aspect: 'PPST (this work)', pros: 'Composes with SPST atomically; deployable as Solana smart-contract layer; relayer-free; 128-byte Groth16 proof', cons: 'program_id leaks (no function privacy); per-program Groth16 ceremony; complex programs need IVC' }, { aspect: 'Aleo records model (ZEXE)', pros: 'Universal Marlin/Varuna SRS; native L1 chain with prover marketplace; relayer-free', cons: 'Requires its own L1; program ID also visible; delegated proving leaks witness' }, { aspect: 'Aztec PXE + AVM', pros: 'Universal PLONK/Honk SRS; Noir DSL; client-side proving; relayer-free via FPCs', cons: 'L2 rollup architecture (separate sequencer); function call boundary L→public visible' }, ]}/>

The thing PPST gets that Aleo and Aztec don't is deployment as a protocol layer on a high-performance Layer-1. Aleo and Aztec each require running their own consensus or sequencer. PPST runs as a Solana program on the same validators as Jupiter and Helium — inheriting Solana's TPS, finality, and infrastructure.

What's left

PPST plus SPST gives us private value + private computation. That's two of the three privacy properties. The remaining gap is submitter anonymity: even with a perfect ZK proof, the wrapping Solana transaction is signed by an Ed25519 key whose public key is on-chain. Address graph analysis trivially links the "private" transaction to the submitter's identity.

The next post is about closing that gap — without a relayer, without a mixing service, and without a separate L1.

Bibliography

• Bowe, S., Chiesa, A., Green, M., Miers, I., Mishra, P., Wu, H. (2020). ZEXE: Enabling Decentralized Private Computation. IEEE S&P 2020.
• Chiesa, A., Hu, Y., Maller, M., Mishra, P., Vesely, N., Ward, N. (2020). Marlin: Preprocessing zkSNARKs with Universal and Updatable SRS. EUROCRYPT 2020. https://eprint.iacr.org/2019/1047
• Aztec Network. Client-side Proof Generation. https://aztec.network/blog/client-side-proof-generation
• Kothapalli, A., Setty, S., Tzialla, I. (2022). Nova: Recursive Zero-Knowledge Arguments from Folding Schemes. https://eprint.iacr.org/2021/370
• Noir Language Documentation. https://noir-lang.org/docs/

Previous: SPST: self-paying shielded transactions ← · Next: TAB: threshold-anonymous broadcast →

When Zcash open-sourced Halo2 in 2020, it was a research artefact attached to a single deployment target — Zcash's Orchard pool — and a single arithmetisation choice — IPA over the Pasta cycle of curves. Six years later it is a small ecosystem of forks, used by Scroll, Taiko, Axiom, and roughly half the EVM rollups under construction in 2026. The original repository has been in maintenance mode since 2024.

This post is the orientation I wish someone had handed me when I started auditing Halo2 circuits seriously. What stayed the same? The arithmetisation. The lookup argument. The mental model of chips inside regions inside columns. What evolved? The polynomial commitment scheme, the curve choices, the gadget library, and most of all the fork landscape. By the end you should have a defensible answer to "which Halo2 do you mean?" — which is the question every serious ZK conversation in 2026 reduces to within five minutes.

What stayed: the PLONKish arithmetisation

The shape of a Halo2 circuit hasn't changed since 2020. You define columns — advice (witness), fixed (constants), and instance (public inputs) — and a rectangular grid of cells indexed by row and column. The prover assigns values to advice cells; the constraint system asserts polynomial relations on those values, evaluated at every row.

Three families of constraints make up a Halo2 circuit:

1. Custom gates. A polynomial identity that must hold on every row, possibly gated by a selector column. q_mul · (a · b - c) = 0 is the canonical example: when q_mul = 1, the constraint forces a · b = c; when q_mul = 0, the constraint vanishes.
2. Permutation arguments. Cells that should be equal across rows or columns are wired into a permutation. This is what gives you "this output of gate A is the input to gate B" without paying the cost of an extra constraint per copy.
3. Lookup arguments. A cell must be in some pre-declared table. This is what makes range checks ($x < 2^{16}$) cost ~1 row per check instead of 16, and what makes XOR / S-box / SHA tables tractable inside a SNARK.

The novelty in 2020 wasn't any single one of those — PLONK had given us custom gates and permutations, plookup had given us lookups — but the combination, the user-facing API (chips, regions, layouters), and the recursion-friendly proof system underneath it.

The arithmetisation is so durable that every Halo2 fork in 2026 still uses the same Circuit trait, the same Layouter, the same Region, the same Selector. If you wrote a Halo2 chip in 2021, it compiles in 2026 against PSE-Halo2 with one or two trait-bound tweaks. That's an extraordinary track record for a 6-year-old framework.

What evolved: from IPA to KZG

The original Zcash Halo2 used IPA (inner-product argument) over the Pasta cycle of curves (Pallas + Vesta). That choice was deliberate: IPA needs no trusted setup, and the Pasta cycle let Zcash do recursion without pairings. Beautiful in theory; expensive in practice. IPA proofs are kilobytes; verification is logarithmic in circuit size and dominated by group operations.

The dominant 2026 fork — Privacy Scaling Explorations' privacy-scaling-explorations/halo2 — replaced IPA with KZG over BN254. The trade-off:

• You give up: trustless setup. KZG needs a Powers-of-Tau ceremony.
• You get: constant-size proofs (~600 bytes), pairing-based verification that's an order of magnitude cheaper, and Solidity verifier compatibility — which is the single feature that turned Halo2 from "Zcash internal tool" into "the EVM rollup substrate".

This is the trade-off every serious ZK design makes once. (The same trade-off shows up in Plonky3, the small-fast-cheap revolution on a different axis.) Trusted setup is back on the table in 2026 because the Ethereum KZG ceremony — 140,000+ participants — is good enough for the threat model most rollups operate under. See On the death of the trusted setup for the argument.

<Mermaid chart={flowchart TB Z[Zcash Halo2 - 2020] --> I[IPA + Pasta curves] Z --> P[PLONKish + lookups + chips] P --> P1[Custom gates] P --> P2[Permutations] P --> P3[Lookups] Z --> F[Forks 2022-2026] F --> PSE[PSE Halo2 - KZG over BN254] F --> AX[Axiom fork] F --> SCROLL[Scroll fork] F --> ZK[zkEVM forks: Taiko, Linea] PSE --> SOL[Solidity verifier compat] PSE --> M[Maintenance mode Jan 2025] AX --> ACTIVE[Active 2026] classDef ship fill:#0a4014,stroke:#4ade80,color:#fff classDef warn fill:#3a2a0a,stroke:#facc15,color:#fff class SOL ship class ACTIVE ship class M warn}/>

The fork landscape in 2026

The headline event of 2025 was that PSE-Halo2 went into maintenance and the community migrated to Axiom's fork as the upstream for new feature work. Existing deployments did not move — the API surface is identical and PSE-Halo2 still receives security backports — but the energy is on axiom-crypto/halo2-axiom and on halo2-base for ergonomic chip authoring.

What evolved: gadgets, lookups, and the Lagrange-form witness

Three quieter shifts since 2022 actually changed how circuits are written:

Gadget libraries got serious. The original Halo2 shipped with halo2_gadgets::poseidon and not much else. By 2026 the halo2-base and halo2-axiom crates ship range checks, ECC, Poseidon, Keccak, RSA, ECDSA, BN254 pairing, and a battery of lookup tables shared across circuits. The "I have to hand-roll a SHA chip" era is over for 90% of use cases.

Lookups became table-shareable. Halo2's original lookup design assumed each circuit declared its own tables. With circuits hitting 10 million rows, table reuse across sub-circuits became necessary. Both Axiom and PSE landed APIs for declaring a lookup table once and binding it across regions. The constraint-count savings on big circuits are 30–50%.

Lagrange-form witness committed. The witness used to be committed in coefficient form, requiring an NTT before commitment. Modern forks commit in Lagrange form (point-value), saving an NTT per commitment. On large circuits this is a 15–20% prover-time win — the kind of thing that doesn't show up in marketing copy and matters enormously when you're proving a million constraints.

A skeleton chip you can read in 30 seconds

Halo2 chips look intimidating. They are not. The shape is: declare the columns you need, declare the constraints in configure, and use them in synthesize. Below is a contrived multiplier chip — the smallest Halo2 chip that does anything — written against the kind of trait surface every fork shares.

// synthesize() is called once per proof. It assigns concrete values
// to advice cells.
pub fn assign_mul(&self, /* layouter, */ a_val: F, b_val: F) -> Cell<F> {
    // Pseudocode:
    //
    //   layouter.assign_region(|| "mul", |mut region| {
    //       self.config.q_mul.enable(&mut region, 0)?;
    //       region.assign_advice(|| "a", self.config.a, 0, || Ok(a_val))?;
    //       region.assign_advice(|| "b", self.config.b, 0, || Ok(b_val))?;
    //       let c_val = a_val * b_val;
    //       region.assign_advice(|| "c", self.config.c, 0, || Ok(c_val))
    //   })
    unimplemented!("see halo2_proofs::circuit::Layouter")
}

This is the shorter post that exists because people who don't read the long posts still ask the question. How did the Navy guy end up building a ZK SDK? The version that fits on LinkedIn. Three acts. One arc.

I'll keep it under two thousand words.

Act one: the watch

I came up as a Nuclear Electronics Technician in the US Navy. The Navy nuclear pipeline is — there is no nice way to say this — an unreasonable amount of school. You go through a screening that washes out most of the people who applied. Then you go through Nuclear Power School, which is twenty-six weeks of physics, reactor theory, thermo, fluids, and mathematics at a pace that is calibrated to break you exactly enough to find out whether you bend back. Then you go through prototype, where you actually run a real reactor, in a real plant, for thousands of hours of supervised watchstanding. Then you go to a hull, which is when the actual job starts.

Along the way you are taught — not as a soft skill, but as a hard skill — that the panel does not lie, the procedure is the contract, and the most dangerous person on the watchstation is the one who decides the indications are probably fine.

I got out with a stack of qualifications, a security clearance whose paperwork I am still slightly anxious about, and a bone-deep instinct for how safety-critical engineering is actually done. That instinct does not show up on a resume. You only see it when the system is on fire, and even then you only see it as the absence of panic.

If you want the long version: Nuclear reactors taught me to ship software.

Act two: the chips and the code

Out of the Navy, I took an unexpected detour through industrial Bitcoin mining at Foundry Digital. (TODO: Dax confirm length of stint and exact role title — keeping the short version short here.) ASICs in racks. Megawatts of power. Heat going out by every method physics allows. The unit economics live on a five-input spreadsheet, and the spreadsheet does not lie either.

The thing nobody tells you about working in mining operations is that it is the closest thing the modern economy has to a reactor compartment. The discipline transfers exactly. The watchstanding is the same. The brutal physical immediacy of a ten-thousand-amp electrical bus is a familiar object to a former reactor electronics tech. So I did a chapter, learned what I needed to learn about the depreciation curve and the cost of an electron, and moved on.

If you want the long version: What running a Bitcoin mine taught me about cloud margins.

After Foundry I went where most former-military, vaguely-technical thirty-somethings end up: into software. PMG first (TODO: Dax confirm). Then USAA (TODO: Dax confirm). Then ConsenSys, which is where the Web3 part of the story started — open-source work across the product surface, mentoring junior engineers, and starting to speak publicly at Permissionless and EthGlobal on developer experience and supply-chain risk.

The supply-chain risk thread is the one that became the Rusty Pipes series on this blog — a research thread on Rust binaries injected into npm packages, which is the kind of attack that is funny on a slide and very much not funny in a customer's CI. The series is the longest-running thing I've written and the thing I am most consistently invited to talk about. It also lined up, in a way I did not plan, with the technical posture I'd later need at Zera Labs: the moment your dependency surface is non-trivial, the registry becomes your threat model, not your library.

In act two I learned to ship software the way the modern industry ships it. Continuous deployment. Cloud-native everything. PR review culture, sometimes good, sometimes bad. I learned what a senior IC actually does, then I learned what a staff engineer actually does, then I started to notice that the ceiling was not where the interesting problems were.

Act three: the company

The third act starts with three things being true at the same time, in the same year. ZK got fast enough to be boring. Solana got cheap enough to make tokenisation a naming decision instead of a budgeting decision. AI agents stopped being demos and started being tools that needed to interact with money. Sitting at the intersection of those three things, I incorporated Zera Labs.

The technical surface — visible in github.com/Dax911 — is the zera-sdk (Solana-native ZK SDK with a Rust core), zera-wallet-demo (Tauri 2 with Groth16 in WASM), z_trade (zeraswap — first compressed-token AMM on Solana), zera_med_demo (a ZK-FHIR gateway because someone asked us to prove it works for things other than crypto bros), and a public Zera Design System we use across the product. Plus an MCP server for AI agents to call any of it. We are small (TODO: Dax confirm headcount when comfortable disclosing), the work is technically dense, and the schedule is short.

If you want the long version: Why I started Zera Labs. If you want the inside-the-week version: Being CEO and still shipping code.

What the arc actually is

Looking at the three acts side by side, the arc is not "Navy guy gets into crypto." That is the LinkedIn-recruiter version. The actual arc is something narrower:

Each chapter forced me to take seriously the gap between the system is correct and I have correctly observed that the system is correct.

In the Navy that gap is closed by watchstanding, two-person verification, and casualty drills. In mining it is closed by telemetry, redundant temperature sensors, and on-call. In software at scale (PMG → USAA → ConsenSys) it is closed by tests, code review, and post-mortems. In ZK it is closed by a Groth16 proof — a piece of math that is the closure of the gap. The whole story, condensed, is that I kept moving up the stack of "ways to know that the system is correct," and each step gave me a little more leverage than the last.

The reactor watchstander's tools are slow, expensive, and limited to a single plant. The miner's tools are faster and parallel, but only over a single workload. The senior IC's tools are general-purpose but soft — they assume an honest reviewer. The cryptographic tools at the end of the arc are general-purpose, fast, and don't assume an honest reviewer. They are, in a real sense, what every prior chapter was reaching for.

If I had to pin the arc to one sentence I'd say: I have spent fifteen years getting better at proving that systems are doing what they claim to be doing, and the most productive place to do that work, today, is at a company whose entire surface is about producing those proofs.

What I'd tell my younger selves

Three notes to three different versions of me — because I find this is the most useful summary for people whose careers are a few chapters earlier than mine.

To the kid in the reactor compartment: the discipline you are absorbing is the most valuable thing you are going to learn, and you will not realise this until you have been out for five years. Don't lose the watchstanding habits. Don't soften the procedure-in-hand instinct. Find a civilian career where they still apply.

To the operator at the mining site: pay attention to the unit economics. The five-input spreadsheet is a model that generalises beyond mining. Carry it with you. Whatever business you eventually find yourself in, you will be able to think about it more clearly than the people around you because you have seen what real unit economics actually look like.

To the senior IC at ConsenSys: the Rusty Pipes work is the start of a research thread, not the end of one. Don't drop it after the first post. The supply-chain question is going to be one of the defining infrastructure problems of the next decade, and you are early.

To present me: don't get cocky.

And to the reader

That's how I got here. The interesting question, though, is not how I got here. It is where everyone else is going.

If you came up the same way — Navy, military, technical — and you are thinking about the civilian transition, my email is at the bottom of every page. Reach out. The civilian-tech industry will tell you a lot of things about your discipline, almost none of them flattering, almost none of them correct. The reactor instincts are a superpower in a software org that has lost them. Bring them with you.

If you are a senior IC who is wondering whether to keep going up the staff ladder or jump sideways into a founder seat, I hope the CEO-still-shipping post is useful. The math is not as bad as the canon makes it sound.

If you are at the third act yourself, building cryptographic infrastructure or anything adjacent, I want to know. The ecosystem is small enough that we should know each other.

And if you are at the very beginning — looking at a screening package, or a Navy recruiter, or a dev bootcamp acceptance, or a first software job — pick the chapter that gives you the deepest forcing function. Pick the chapter that demands the most discipline up front. The discipline is the thing that compounds. The technology is the thing that changes.

That's the LinkedIn version. The longer versions are linked above. Thanks for reading.

In the previous post I argued that on account-model chains the fee paradox is what forces relayer dependence. The cleanest resolution — Approach A — extracts the transaction fee from inside the ZK proof itself. This post specifies that resolution.

The construction is called SPST (Self-Paying Shielded Transactions). It is the foundation that PPST, TAB, and UPEE build on. It also stands alone as a complete protocol for private value transfer with self-paying fees — the Solana analogue to Zcash's Sapling spend description, but adapted to a smart-contract environment.

The setting

Work over a prime-order elliptic curve group $\mathbb{G}$ of order $p$ with two independent generators $g, h \in \mathbb{G}$ for which no party knows $\log_g h$. Let $\mathbb{F}_p$ denote the scalar field. We use:

• Poseidon as the SNARK-friendly hash (width $t = 5$, HADES rounds $R_F = 8$ full + $R_P = 57$ partial, S-box $x^5$, ~324 R1CS constraints per 2-to-1 compression).
• PRF keyed by $sk \in \mathbb{F}_p$, instantiated as a domain-separated Poseidon evaluation.
• Groth16 over BN254 as the on-chain verifier (alt_bn128 syscalls on Solana).
• Indexed Merkle Trees for nullifier non-membership (depth-32 over 254-bit values; ~10,948 R1CS constraints per non-membership proof, vs 82,296 for naive sparse Merkle).

Definitions

Definition 3.1 (Shielded Note). A shielded note is a tuple

$$ \mathsf{note} = (\mathsf{pk}, v, \rho, r) $$

where $\mathsf{pk} = \mathsf{PRF}_{sk}(0)$ is the owner's public spending key, $v \in {0, \ldots, 2^{64}-1}$ is the note value, $\rho \in \mathbb{F}_p$ is unique per-note serial randomness, and $r \in \mathbb{F}_p$ is the commitment trapdoor.

Definition 3.2 (Note Commitment).

$$ \mathsf{cm} ;=; \mathsf{Poseidon}(\mathsf{pk},, v,, \rho,, r) ;\in; \mathbb{F}_p. $$

Note commitments are appended as leaves to a global Merkle tree $\mathcal{T}$ of depth $d = 32$ (capacity $2^{32}$ notes). The Merkle root at any epoch is $\mathsf{rt}$.

Definition 3.3 (Nullifier).

$$ \mathsf{nf} ;=; \mathsf{PRF}_{sk}(\rho) ;=; \mathsf{Poseidon}(sk, \rho). $$

Upon spending, $\mathsf{nf}$ is published to a global nullifier set $\mathcal{N}$. Double-spending is prevented by rejecting any transaction whose $\mathsf{nf}$ already lives in $\mathcal{N}$.

Definition 3.4 (SPST Transaction). With $n$ inputs and $m$ outputs:

$$ \mathsf{tx} ;=; \bigl(, {\mathsf{nf}i}{i=1}^{n},; {\mathsf{cm}j}{j=1}^{m},; \mathsf{rt},; f,; \pi ,\bigr) $$

where $f \in {0, \ldots, 2^{64}-1}$ is the public fee and $\pi$ is a Groth16 proof of the SPST relation.

The validator accepts iff (i) $\pi$ verifies, (ii) $\mathsf{rt}$ is a recent root, (iii) every $\mathsf{nf}i \notin \mathcal{N}$, and (iv) $f \geq f{\min}$.

The SPST relation

The relation $\mathcal{R}_{\mathsf{SPST}}$ is the set of $(x, w)$ pairs:

Public instance $x = \bigl({\mathsf{nf}_i}, {\mathsf{cm}_j}, \mathsf{rt}, f\bigr)$.

Private witness $w = \bigl({(\mathsf{note}_i, \mathsf{path}_i, sk_i)}, {\mathsf{note}'_j}\bigr)$.

Eight constraints, all enforced by the circuit:

C6 is the load-bearing constraint. It is what makes the transaction self-paying: the prover can only produce a valid proof if the input notes' values sum to exactly the output values plus the fee.

The self-paying property (Theorem 3.1)

Theorem. Let $\mathsf{tx} = ({\mathsf{nf}_i}, {\mathsf{cm}_j}, \mathsf{rt}, f, \pi)$ be a valid SPST transaction. Then:

1. The fee $f$ is funded entirely from consumed shielded notes.
2. No external account, relayer, or gas sponsor is required.
3. Validators extract $f$ as inclusion compensation without learning the private inputs/outputs beyond $f$ itself and the validity of $\pi$.

Proof sketch. (1) follows directly from C6. (2) follows because $\mathsf{tx}$ is a self-contained data structure that any party can broadcast; the on-chain verifier decrements the privacy program's lamport reserve by $f$ and credits the validator. (3) is the perfect zero-knowledge property of Groth16: the validator sees $f$ as a public input but learns nothing about $v_i$ or $v'_j$.

The full proof is in §3.1.3 of the paper. The takeaway: on Solana, the privacy program's PDA holds a reserve. Each shield deposit increments it. Each SPST transaction's proof authorises the validator to take $f$ from it. Replenishment is automatic.

Theorem 3.2 — Balance / value conservation

Statement. No PPT adversary can produce a valid SPST transaction that creates value (i.e., one for which $\sum_j v'_j + f > \sum_i v_i$) except with negligible probability.

The proof gives two complementary arguments — one from the SNARK's knowledge soundness, one from an independent Pedersen commitment cross-check that provides defense in depth.

Argument 1 (SNARK soundness)

C6 enforces $\sum_i v_i = \sum_j v'_j + f$ over $\mathbb{F}_p$. C7 and C8 enforce $v'_j, f \in [0, 2^{64})$. With at most $n \leq 2^{16}$ inputs each bounded by $2^{64}$, $\sum_i v_i < 2^{80} \ll p \approx 2^{254}$ — so field arithmetic faithfully represents integer arithmetic and no modular wraparound is possible.

By Groth16 knowledge soundness in the AGM, an extractor $\mathcal{E}$ can recover the witness $w^*$ satisfying all constraints C1–C8. C6 in the extracted witness gives $\sum_i v_i = \sum_j v'_j + f$ as an integer equation. Contradiction with the assumed inflation.

Argument 2 (Pedersen cross-check)

As defense in depth, attach Pedersen value commitments to each note. With $C_{\mathsf{in},i} = v_i \cdot g + r^{(\mathsf{vc})}i \cdot h$ and $C{\mathsf{out},j} = v'_j \cdot g + r^{(\mathsf{vc})}_j \cdot h$, the verifier checks

$$ \sum_i C_{\mathsf{in},i} ;=; \sum_j C_{\mathsf{out},j} ;+; f \cdot g ;+; r_\Delta \cdot h $$

where $r_\Delta = \sum_i r^{(\mathsf{vc})}_i - \sum_j r^{(\mathsf{vc})}_j$.

Suppose an adversary passes this check but with $\sum_j v'j + f \neq \sum_i v_i$. Let $\delta = \sum_i v_i - \sum_j v'j - f \neq 0$. Then $\delta \cdot g = r'\Delta \cdot h$ for some $r'\Delta$, which yields $\log_g h = \delta / r'_\Delta$ — contradicting DLOG. ∎

Theorem 3.3 — Double-spend resistance

Game. $\mathcal{A}$ may adaptively deposit and spend; wins if it produces two accepted transactions consuming the same note $\mathsf{note}^*$.

Cases.

• Case 1: The two transactions publish the same nullifier. Rejected by the protocol's nullifier-set check.
• Case 2: They publish different nullifiers $\mathsf{nf} \neq \mathsf{nf}'$ but consume the same note. By C4 both proofs authenticate the same commitment $\mathsf{cm}^$. By C1 we have $\mathsf{pk}^ = \mathsf{PRF}{sk^*}(0) = \mathsf{PRF}{sk'}(0)$.
  • If $sk^* = sk'$, then $\mathsf{nf} = \mathsf{nf}'$. Contradiction.
  • If $sk^* \neq sk'$, then $\mathsf{Poseidon}(sk^*, 0) = \mathsf{Poseidon}(sk', 0)$ — a collision in Poseidon. Reduces to collision resistance.

Both cases reach a contradiction. ∎

Theorem 3.4 — Transaction unlinkability

Statement. Under perfect zero-knowledge of Groth16 and computational hiding of Pedersen commitments under DDH, the SPST scheme satisfies transaction unlinkability: no PPT adversary can determine which input notes fund which output notes with non-negligible advantage.

Proof structure. Hybrid argument:

• Hybrid 0: real game.
• Hybrid 1: replace all Groth16 proofs with simulated proofs. By perfect ZK of Groth16, indistinguishable.
• Hybrid 2: in the simulated view, the multisets of nullifiers, commitments, roots, fees are identical for both branchings of the challenge. The fee is identical by construction. Each $\mathsf{cm}_j = \mathsf{Poseidon}(\mathsf{pk}'_j, v'_j, \rho'_j, r'_j)$ with fresh random $r'_j$ is computationally indistinguishable from a uniform field element. Each nullifier $\mathsf{nf}i = \mathsf{PRF}{sk_i}(\rho_i)$ with unique $\rho_i$ is pseudorandom. The Pedersen value commitments are computationally hiding under DDH.

Result: $\mathsf{Adv}_{\mathcal{A}} \leq \mathsf{negl}(\lambda)$. ∎

Theorem 3.5 — Non-malleability

Statement. No PPT adversary can take a valid SPST transaction and produce a distinct valid transaction with altered public inputs (e.g., a different fee), except with negligible probability.

Proof. Relies on the simulation-extractability of Groth16 in the Random Oracle Model — the Bowe-Gabizon construction (2019), refined by Ràfols-Baghery-Pindado (2023). An adversary mauling the proof to alter $f$ would need to extract a witness with a different $f'$ satisfying C6, but C6 plus the unchanged input commitments and output commitments uniquely determines $f$. Contradiction.

Circuit complexity

For an SPST circuit with $n$ inputs and $m$ outputs:

$$ C_{\mathsf{total}} ;\approx; 11{,}500 \cdot n ;+; 452 \cdot m ;+; 64. $$

A canonical 2-in / 2-out transaction:

$$ C_{2,2} ;=; 23{,}000 + 904 + 64 ;\approx; 24{,}000 \text{ constraints}. $$

On commodity hardware (Apple M2, 8-core), Groth16 proving for 24,000 constraints takes 0.5–1.5 seconds with arkworks or snarkjs. Proof size is 128 bytes compressed (BN254 G1/G2 compression on Solana). Verification is **150,000–200,000 CU** via sol_alt_bn128_* syscalls.

<TradeoffTable rows={[ { aspect: 'Proof size', pros: '128 bytes (BN254 compressed)', cons: 'Fits the 1,232-byte Solana limit with 1,100+ bytes for other tx data' }, { aspect: 'Verification cost', pros: '< 200,000 CU (≈ $0.02 USD)', cons: '~14% of the 1.4M CU per-tx budget; leaves room for nullifier checks + state updates' }, { aspect: 'Prover time (M2 laptop)', pros: '0.5–1.5 s for 2-in / 2-out', cons: 'Linear in circuit size; recursive proofs amplify this' }, { aspect: 'Trusted setup', pros: 'Per-circuit Groth16 MPC (Powers of Tau-style)', cons: 'Separate ceremony per circuit shape; PLONK alternative awaits SIMD-0302 G2 syscall' }, ]}/>

What SPST is not

SPST handles private value transfer — the Solana analogue of Zcash's Sapling. It does not:

• Handle private computation. The next post (PPST) extends the relation to arbitrary arithmetic circuits over private state.
• Hide the submitter. The transaction submitter is still publicly identified by their Ed25519 signature on the wrapping Solana transaction. TAB addresses that.
• Hide the fee amount. $f$ is necessarily public for validator compensation.

But it does the load-bearing thing: the user becomes self-sovereign with respect to fee payment. Combined with TAB and PPST, that's the whole framework.

Bibliography

• Ben-Sasson, E. et al. (2014). Zerocash. IEEE S&P 2014. https://eprint.iacr.org/2014/349
• Hopwood, D. et al. (2016–2026). Zcash Protocol Specification. https://zips.z.cash/protocol/protocol.pdf
• Groth, J. (2016). On the Size of Pairing-based Non-interactive Arguments. EUROCRYPT 2016. https://eprint.iacr.org/2016/260
• Bowe, S., Gabizon, A. (2019). Making Groth's zk-SNARK Simulation Extractable. https://eprint.iacr.org/2019/197
• Ràfols, C., Baghery, K., Pindado, Z. (2023). Simulation Extractable versions of Groth's zk-SNARK Revisited. https://doi.org/10.1007/s10207-023-00750-7
• Pedersen, T. P. (1991). Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing. CRYPTO 1991.
• Grassi, L. et al. (2021). Poseidon: A New Hash Function for Zero-Knowledge Proof Systems. USENIX Security 2021. https://eprint.iacr.org/2019/458
• Aztec Documentation. Indexed Merkle Tree (Nullifier Tree). https://docs.aztec.network/

Previous: The fee paradox ← · Next: PPST: private programmable state →

There are two ways to write a zero-knowledge circuit. You can spell out the algebraic constraints by hand — (a) * (b) === c, one line per multiplication, every wire indexed manually — or you can write something that reads like a program and let a compiler emit the constraints. The first approach gives you total control and zero leverage. The second approach gives you Circom.

Circom is the DSL Iden3 designed in 2018 to make Groth16-style circuit authoring tractable. Six years later, in 2026, it is still the language most production ZK pipelines reach for first. The reason is not that it is the most expressive — Halo2 and the Noir frontend Aztec ships are both more powerful — but that its compilation target (R1CS) is the format every Groth16 toolchain on Earth speaks, and its tooling (snarkjs, circomlib, circomlibjs) is the deepest in the ecosystem.

This post is a walk through Circom from the inside out, told via one circuit: prove I know x such that Poseidon(x, 0) == y without revealing x. Pre-image of a hash. The "hello world" of shielded systems. By the end you'll have read every Circom keyword that matters, seen the constraint graph it generates, and watched the witness get computed in your browser.

What R1CS actually is, in five paragraphs

Before any DSL, the substrate.

A rank-1 constraint system is a list of constraints of the form

$$ (\mathbf{a}_i \cdot \mathbf{w}),(\mathbf{b}_i \cdot \mathbf{w}) - (\mathbf{c}_i \cdot \mathbf{w}) = 0 $$

where $\mathbf{w}$ is the witness vector (every wire in your circuit, including inputs, outputs, intermediates, and a leading constant 1), and $\mathbf{a}_i, \mathbf{b}_i, \mathbf{c}_i$ are constant vectors that pick out which wires participate in the i-th constraint. Every constraint is of the form (linear combination) × (linear combination) = (linear combination). Hence "rank 1": each side is at most one multiplication.

What this means is: every constraint can express exactly one multiplication of two wires, plus arbitrary additions and constant scalings on either side. (2*x + 3*y) * (z) === w + 1 is one R1CS constraint. x * y * z === w is two — you need an intermediate t = x*y and then t * z === w. You can feel the shape of the cost function: addition is free, multiplication is expensive.

Why this exact shape? Because Groth16 (and its predecessors in the Pinocchio/QAP family) reduces an R1CS to a polynomial-divisibility check, and that reduction works exactly when each constraint is rank 1. The circuit's number of constraints becomes the dominant factor in proof time and zkey size. Constraints, not wires, not gates.

In production Circom, you'll see constraint counts ranging from ~50 (a single range check) to ~10,000 (a Merkle-32 path with Poseidon nodes) to ~2,000,000 (a circuit verifying an EVM block). Every increment is a multiplication that someone wrote, intentionally or not. A good Circom programmer thinks like an accountant.

The witness is generated outside the constraint system, by a witness-generator program the Circom compiler emits as WebAssembly. The constraint system checks the witness; it does not compute it. This separation is fundamental to how SNARKs work: prover knows everything, verifier checks much less.

A first circuit — knowledge of a Poseidon pre-image

pragma circom 2.1.5;

include "circomlib/poseidon.circom";

template KnowsPreimage() {
    signal input x;             // private witness — the value being hidden
    signal output y;            // public output — the published hash

    component hash = Poseidon(2);   // 2-input Poseidon hash gadget
    hash.inputs[0] <== x;            // wire x in
    hash.inputs[1] <== 0;            // pad with 0
    y <== hash.out;                  // expose the result
}

component main { public [y] } = KnowsPreimage();

That's the whole circuit. Every keyword, in order:

• pragma circom 2.1.5 — version pin. Circom is post-1.0; the language has minor breaking changes between minor versions, and circomlib's gadgets target specific ranges. Pin or suffer.
• include "circomlib/poseidon.circom" — the include resolves against the --node-modules flag or circomlib's install path. Includes are textual — there's no module system in the npm sense, only file inclusion.
• template KnowsPreimage() — a parameterised circuit fragment. Templates are like generic functions: you instantiate them with component foo = KnowsPreimage();. The lowercase/uppercase convention (Templates uppercase, components lowercase) is community style, not enforced.
• signal input x; — a wire that flows in to this template. signal output y; — flows out. Without input or output, signal foo; is an internal wire.
• component hash = Poseidon(2); — instantiate a sub-circuit. Poseidon is a template defined in circomlib; the (2) is its parameter (number of inputs). Components compose hierarchically; the compiler inlines them at constraint-emission time.
• hash.inputs[0] <== x; — the constraint operator. <== does two things at once: it (a) emits the R1CS constraint that wires x and hash.inputs[0] are equal, and (b) marks the right-hand side as the source for witness generation (so the WASM witness generator knows to copy x's value into hash.inputs[0]).
• y <== hash.out; — same operator, exposing the hash output.
• component main { public [y] } = KnowsPreimage(); — the entry point. The public annotation says: when the verifier checks the proof, y is the public input. Everything else (here, just x) is private to the prover.

Three operators every Circom programmer types daily:

<-- shows up when you compute something the constraint system can't (square-root, division, lookup) and then post-hoc constrain it with ===. === shows up alone when the relationship is implicit and you want to assert it. <== is the day-to-day workhorse.

What that circuit compiles to

The Circom compiler (circom2) emits four artifacts:

1. circuit.r1cs — the constraint system, in a binary format the rest of the toolchain consumes.
2. circuit.wasm — the witness generator, a WASM module that takes the inputs as JSON and returns the witness vector.
3. circuit.sym — symbol table mapping wire indices back to source-code names. Invaluable for debugging.
4. circuit.json (optional, --json) — the constraint system in human-readable JSON. Slow to parse; useful for one-off inspection.

For our pre-image circuit, the R1CS file contains roughly the constraints below — Poseidon's S-box rounds, MDS multiplications, output binding. The constraint graph looks like this:

<Mermaid chart={flowchart TB X[private input x] --> H0[Poseidon input 0] Z[constant 0] --> H1[Poseidon input 1] H0 --> S1[round 1 S-box] H1 --> S1 S1 --> M1[MDS mix] M1 --> S2[round 2 S-box] S2 --> M2[...64 more rounds...] M2 --> O[Poseidon output] O --> Y[public output y] classDef pub fill:#0a4014,stroke:#4ade80,color:#fff classDef priv fill:#3a0a0a,stroke:#f87171,color:#fff class Y pub class X priv}/>

Total constraint count for KnowsPreimage against BN254-Poseidon-128 with $t=3, R_F=8, R_P=57$: 243 constraints for the hash, plus ~3 for the input wiring. Call it 246 R1CS constraints. snarkjs Groth16 will prove it in under 80 ms in a browser, including witness generation. (Numbers from Proving in the browser, by the numbers.)

Compile and run, in your browser

circomlibjs ships a browser build that includes the witness generator and the Poseidon constants without requiring you to install the Rust-based circom2 compiler. Below is a Sandpack node template that takes the inputs to our circuit, computes the witness, and emits the expected hash. It's not a full proof — the proving step needs the zkey, which is megabytes — but it's the witness generation half of the pipeline, end-to-end, in a browser.

<Sandbox template="node" title="Knowledge of pre-image — witness generation" files={{ "/index.js": `// Witness generation for "I know x such that Poseidon(x, 0) = y" // using circomlibjs in pure Node/browser. This skips the proving step // (which needs a multi-MB zkey) and shows the witness side.

const { buildPoseidon } = require("circomlibjs");

async function main() { // Build the Poseidon hasher (this fetches the round constants). const poseidon = await buildPoseidon(); const F = poseidon.F; // the BN254 scalar field

// The "private" input — what we want to keep hidden. const x = 1234567890n;

// The two-input Poseidon, mirroring our Circom circuit. const yField = poseidon([x, 0n]); const y = F.toString(yField);

// What the prover would put in input.json: const proverInput = { x: x.toString(), }; // What the verifier sees on-chain: const publicInput = [y];

console.log("circuit: KnowsPreimage()"); console.log("private input: x =", x.toString()); console.log("public output: y =", y); console.log(); console.log("input.json (prover only):"); console.log(JSON.stringify(proverInput, null, 2)); console.log(); console.log("public.json (verifier sees this):"); console.log(JSON.stringify(publicInput, null, 2)); console.log(); console.log("constraint count: ~246 (243 Poseidon + 3 wiring)"); console.log("expected snarkjs prove time @ Merkle-32 quality:"); console.log(" ~80 ms (browser, threads on)"); console.log(" ~25 ms (arkworks-WASM, threads on)"); console.log(" ~3 ms (native Rust)"); }

main().catch(console.error); , "/package.json": { "name": "circom-preimage-witness", "version": "1.0.0", "main": "index.js", "dependencies": { "circomlibjs": "^0.1.7" } }`, }} />

What you should see when this runs: a public output y that is the Poseidon hash of (1234567890, 0) over BN254. That value is what would be posted on-chain or shipped over the wire. The proof would convince the verifier that someone knew an x mapping to that y, without revealing x.

Some Circom patterns worth internalising

A handful of patterns recur across every real circuit. They're idioms more than language features.

Bit decomposition. Circom doesn't have a native < 2^n predicate. You decompose into bits and constrain each bit to be 0 or 1:

template Num2Bits(n) {
    signal input in;
    signal output out[n];
    var lc1 = 0;
    var e2 = 1;
    for (var i = 0; i < n; i++) {
        out[i] <-- (in >> i) & 1;          // witness only
        out[i] * (out[i] - 1) === 0;       // constrain to 0 or 1
        lc1 += out[i] * e2;
        e2 *= 2;
    }
    lc1 === in;                             // re-aggregate must match
}

The <-- followed by === is the canonical witness-then-check pattern. The bits are computed outside the constraint system (you can't shift in R1CS) and then constrained to be valid.

Conditional selection. R1CS has no if. You select between two values with a Boolean:

// out = sel ? a : b, where sel must be 0 or 1
out <== a + (b - a) * (1 - sel);

MUX trees. A common pattern in Merkle paths: at each level, pick the left or right sibling based on the path bit. circomlib's MultiMux1 template does this efficiently for t-element vectors.

Circom vs the alternatives in 2026

<TradeoffTable rows={[ { option: "Circom (R1CS / Groth16)", cost: "Mature, big circomlib, 6 years of audits", latency: "Per-circuit trusted setup; proving is fast", blast_radius: "Medium — language warts, but well-understood", notes: "Default for any Groth16 deployment in 2026" }, { option: "Halo2 (PLONKish / KZG or IPA)", cost: "Steeper learning curve; chips/regions/lookups", latency: "Universal SRS, slower per-shot, lookup-friendly", blast_radius: "PSE fork in maintenance; Axiom fork active", notes: "Pick this when the circuit is dominated by lookups" }, { option: "Noir (Aztec)", cost: "Higher-level Rust-like syntax; ACIR backend", latency: "Backend-agnostic; pluggable to PLONK or Honk", blast_radius: "Newer; growing fast", notes: "What I'd pick for a greenfield 2026 project" }, { option: "arkworks (R1CS via traits)", cost: "Library, not a DSL; circuits are Rust types", latency: "Backend-agnostic; great for research", blast_radius: "Code = circuit; the abstraction is leaky in practice", notes: "Where the academic implementations live" }, ]} caption="Four ways to author a zero-knowledge circuit in 2026. Circom is still the default; Noir is what greenfield projects increasingly start with." />

The case for Circom in 2026 is one word: circomlib. Six years of accreted gadgets — Poseidon, MiMC, Pedersen, EdDSA, Merkle, range checks, Sigma protocols, set membership — that all interoperate cleanly because they target the same R1CS-over-BN254 substrate. The case against is also one word: expressivity. Circom is a templating engine over arithmetic constraints. It can't loop over a runtime-known length, can't recurse, has no first-class strings or arrays beyond fixed-size. For complex circuits the workarounds get baroque.

Inside zera-sdk we use Circom for the deposit / transfer / withdraw circuits because circomlib's Poseidon and MerkleTreeChecker gadgets are fight-tested and because snarkjs is the only browser prover that ships in a single npm install. The day we need lookups (or recursion) at scale, the discussion is Halo2 vs Noir, not Circom.

What I would change if I were Circom 2.5

Three things, ranked by how much I'd actually use them.

1. First-class lookup tables. Halo2 has them and they cut range-check costs by orders of magnitude. Plookup-as-a-tagged-include in Circom would close most of that gap.
2. Module system. include is textual. Circular includes silently drop. A real module graph with explicit exports would prevent a class of bug I see in every audit.
3. Compiler-level constraint optimisation. The compiler already does basic linear-combination flattening. Aggressive common-subexpression elimination across templates would shave 10–20% off circomlib's bigger gadgets at zero source-code cost.

None of these are coming, as far as I can tell. The Iden3 team has moved most of its energy to Polygon ID and the Circom roadmap has been relatively quiet through 2025–2026. That's fine — the language is done in the way that good DSLs eventually become done. If you want what comes next, you go look at Noir and Halo2.

Further reading

• Circom 2 documentation — the canonical language reference
• CIRCOM: A Robust and Scalable Language for Building Complex Zero-Knowledge Circuits — Bellés-Muñoz, Isabel, Muñoz-Tapia, Rubio, Baylina (2022)
• iden3/circom — the compiler source
• iden3/circomlib — the gadgets library that makes Circom usable in production
• iden3/circomlibjs — JavaScript port of the cryptographic primitives, what the Sandpack above uses
• Poseidon, by hand and by code — what the hash gadget actually is
• Proving in the browser, by the numbers — what happens after circom finishes compiling

The cheapest piece of state in a privacy pool — and the most contested one — is the commitment tree. Every shielded note's commitment goes in. Every spend proves an inclusion. The tree is read on every transfer and written on every deposit. If the tree state is expensive, every operation is expensive. If the inclusion proofs are big, every spend is big.

In 2024 Light Protocol shipped ZK Compression on Solana, and the production primitive for "store a lot of state cheaply, prove inclusion in zero-knowledge" became standard. This post is the math behind that primitive, the deployment shape, and a runnable inclusion-proof construction. It's a sibling piece to Pedersen commitments, in production and Nullifiers without the witchcraft — those tell you what we put into the tree; this one tells you how we prove things about the tree.

The minimum tree

A binary Merkle tree is the simplest commitment scheme that supports logarithmic-size inclusion proofs. Start with a sequence of leaves $\ell_0, \ell_1, \dots, \ell_{N-1}$. Define the tree recursively:

$$ \text{node}(i, j) = H(\text{node}(i, m) ,|, \text{node}(m+1, j)), \quad m = \lfloor (i+j)/2 \rfloor, $$

with $\text{node}(i, i) = \ell_i$ at the leaves. The root is $\text{node}(0, N-1)$. To prove that $\ell_k$ is in the tree, you reveal the root plus the co-path — for each level $j$, the sibling node along the path from leaf $k$ to the root. There are exactly $\log_2 N$ siblings.

The proof size is $\log_2 N$ hash outputs. At $N = 2^{32}$ leaves and 32-byte hashes, that's 1024 bytes. At $N = 2^{20}$ (about a million leaves), it's 640 bytes. The verifier cost is $\log_2 N$ hashes. Both numbers are unreasonably small compared to the account-state cost of storing all $N$ leaves directly on chain.

That's the entire shape. Two equations and a co-path. The reason it shows up everywhere is that nothing else hits the same combination of small proof, cheap verifier, and append-only update path.

<Mermaid chart={flowchart TD R[root] R --> A[h_AB] R --> B[h_CD] A --> A1[h_A] A --> A2[h_B] B --> B1[h_C] B --> B2[h_D] A1 --> L0[leaf 0: commitment_0] A2 --> L1[leaf 1: commitment_1] B1 --> L2[leaf 2: commitment_2] B2 --> L3[leaf 3: commitment_3] classDef leaf fill:#0a0a0a,stroke:#4ade80,color:#4ade80 classDef node fill:#1a1a1a,stroke:#a3a3a3,color:#e8e8e8 class L0,L1,L2,L3 leaf class R,A,B,A1,A2,B1,B2 node}/>

To prove inclusion of leaf 1 (commitment_1), the prover reveals the co-path [h_A, h_CD]. The verifier hashes up: h_B = leaf_1, h_AB = H(h_A || h_B), root = H(h_AB || h_CD), and checks that root matches the public root.

Inclusion proof size, exactly

For a tree of height $h$ (so $N \le 2^h$ leaves) with hash output size $s$ bytes, the inclusion proof is exactly $h \cdot s$ bytes plus the leaf index (typically 4 bytes). For Poseidon over BN254 with $s = 32$:

$$ |\pi_{\text{inclusion}}| = 32 h + 4 \text{ bytes}. $$

A useful table for production planning:

<TradeoffTable rows={[ { option: "h = 20 (1M leaves)", cost: "644 bytes inclusion proof", latency: "20 hashes verifier-side; ~0.2ms in WASM", blast_radius: "More than enough for testnet; comfortable for a typical L2", notes: "Light Protocol's default address tree height. The right choice for state-tree v1." }, { option: "h = 26 (67M leaves)", cost: "836 bytes inclusion proof", latency: "26 hashes; 0.3ms", blast_radius: "Used by Light Protocol for state trees; capacity for years of mainnet usage", notes: "The deployment-grade choice." }, { option: "h = 32 (4B leaves)", cost: "1028 bytes inclusion proof", latency: "32 hashes; 0.4ms", blast_radius: "Overkill for any single program; useful if multiple programs share one tree", notes: "Bitcoin-scale capacity. Almost never the right initial choice." }, { option: "MMR (variable height)", cost: "64 bytes per peak + log(n) per leaf", latency: "More complex update path; same verifier cost", blast_radius: "Append-only with no rewrite-on-grow; ideal for batched deposits", notes: "Worth it when you batch many leaves per slot. Niche today." }, ]} />

Light Protocol's state trees default to $h = 26$ — see their account-compression program — which gives 67 million leaves of capacity per tree. For zeraswap and the Dax911/z_trade/programs/zeraswap program, we use the same $h = 26$ default for the same reason: it's the right balance between proof size and capacity, and it's what the on-chain compression program is parameterised for.

Compressed accounts, in one diagram

The Light Protocol model is the cleanest way to think about "Solana accounts that don't take Solana account space." A compressed account is a tuple of fields hashed together; the hash is a leaf in a state tree; the tree's root is what lives in account state on chain.

<Mermaid chart={flowchart LR subgraph OffChain[Off-chain client / indexer] A[Compressed account] A --> AD[discriminator] A --> AO[owner] A --> AL[lamports] A --> ADH[data hash] A --> AAH[address hash] end subgraph OnChain[On-chain state tree] H[hash to leaf] --> L[leaf in Merkle tree] L --> R[Merkle root] R --> SA[Solana account: just the root] end A --> H classDef cell fill:#0a0a0a,stroke:#4ade80,color:#4ade80 classDef chain fill:#1a1a1a,stroke:#737373,color:#a3a3a3 class A,AD,AO,AL,ADH,AAH cell class H,L,R,SA chain}/>

The on-chain footprint is the root (32 bytes) plus the rolling-hash update buffer (a few KB amortised across many writes). The account data, the discriminator, the owner, the lamports — none of that lives in account state. It lives in the indexer's Postgres or in a Photon RPC node, and it's reconstructed at proof-construction time.

The inclusion proof is the trick that makes this work. To execute against a compressed account, the client constructs an inclusion proof against a recent root, the on-chain program verifies the proof against the root it has stored, and the program operates on the (now-trusted) account contents. The root is the only piece of state that has to live on chain. Everything else is reconstruction.

The reason this is the primitive for production privacy on Solana is that Solana's account-state cost is the load-bearing constraint. A normal Solana account is rent-exempt at roughly 0.002 SOL per kilobyte, meaning a megabyte of state costs ~2 SOL ($300+ at 2026 prices). A compressed account is storage-amortised across the tree, and the cost per leaf is sub-cent. Five orders of magnitude.

The Node simulator

Here is a working Merkle inclusion-proof construction over a 16-leaf tree, with the prover-side path construction and the verifier-side root check. It uses SHA-256 for readability — a real ZERA tree uses Poseidon — but the algorithmic shape is identical.

<Sandbox template="node" files={{ "/index.js": `// Inclusion proof construction + verification over a binary Merkle tree. // Uses SHA-256 for readability; a production ZERA / Light Protocol tree // uses Poseidon, which is constraint-friendly inside SNARKs. // // Tree of height h has 2^h leaves; inclusion proof is h hashes + index.

const { createHash } = require("crypto");

const H = (left, right) => createHash("sha256").update(Buffer.concat([left, right])).digest();

function buildTree(leaves) { // Pad to power of two with zero-leaves (Light Protocol does this with a // canonical default-leaf hash, so empty subtrees have known roots). const padTo = 1 << Math.ceil(Math.log2(Math.max(leaves.length, 1))); const padded = leaves.slice(); while (padded.length < padTo) padded.push(Buffer.alloc(32));

// Bottom-up construction. const levels = [padded]; while (levels[levels.length - 1].length > 1) { const cur = levels[levels.length - 1]; const next = []; for (let i = 0; i < cur.length; i += 2) { next.push(H(cur[i], cur[i + 1])); } levels.push(next); } return { root: levels[levels.length - 1][0], levels }; }

function inclusionProof(levels, index) { const path = []; const directions = []; let idx = index; for (let lvl = 0; lvl < levels.length - 1; lvl++) { const sibling = idx % 2 === 0 ? levels[lvl][idx + 1] : levels[lvl][idx - 1]; path.push(sibling); directions.push(idx % 2); // 0 = we are left, 1 = we are right idx = idx >> 1; } return { path, directions }; }

function verifyInclusion(leaf, index, path, root) { let cur = leaf; let idx = index; for (const sibling of path) { cur = idx % 2 === 0 ? H(cur, sibling) : H(sibling, cur); idx = idx >> 1; } return cur.equals(root); }

// Demo --------------------------------------------------------- function leafFor(i) { // In a real shielded pool: leaf = Poseidon(amount, asset, secret, ...) // Here: a synthetic leaf so we can read the demo output. return createHash("sha256").update(Buffer.from(`commitment-${i}`)).digest(); }

const N = 16; const leaves = Array.from({ length: N }, (_, i) => leafFor(i)); const { root, levels } = buildTree(leaves);

console.log(`tree height: ${levels.length - 1}`); console.log(`leaf count: ${N}`); console.log(`root: ${root.toString("hex").slice(0, 24)}...`); console.log("");

// Prove inclusion of leaf 7 const idx = 7; const { path, directions } = inclusionProof(levels, idx); const ok = verifyInclusion(leaves[idx], idx, path, root);

console.log(`proving inclusion of leaf ${idx}`); console.log(`co-path length: ${path.length}`); console.log(`directions: [${directions.join(", ")}]`); console.log(`verifies: ${ok}`); console.log("");

// Tampering: try to claim leaf 7 = leaves[3] (a different commitment) const fake = verifyInclusion(leaves[3], idx, path, root); console.log(`tampered claim verifies: ${fake} (expected false)`);

// Proof size in bytes const proofBytes = path.reduce((s, p) => s + p.length, 0) + 4; // +4 for index console.log(""); console.log(`inclusion proof size: ${proofBytes} bytes`); console.log(`(at h=26 it would be ${26 * 32 + 4} bytes)`); , "/package.json": { "name": "merkle-demo", "version": "1.0.0", "main": "index.js" }`, }} />

Two things to notice when you run this. The proof is 132 bytes for a 16-leaf tree (4 hashes + an index). Scaled to $h = 26$, it's 836 bytes — independent of how many leaves are in the tree. That's the O(\log n) argument with the constant factor pinned down. The other thing: the tampering attempt at the end fails because verifyInclusion(leaves[3], 7, path, root) re-hashes up the wrong path. The directions array is what makes this work; without it, the verifier doesn't know whether the sibling goes on the left or the right.

Batched inclusion via Merkle Mountain Ranges

The basic Merkle tree is append-only but expensive to grow — every new leaf forces a recompute of $\log_2 N$ internal nodes. For workloads that batch many leaves at once (rollups, periodic deposit windows, settlement layers), the Merkle Mountain Range is the structural improvement.

An MMR is a forest of perfect binary trees. New leaves are appended to the rightmost tree; when two trees of equal height exist, they're merged. The peaks (one per tree) are then "bagged" — hashed together — to produce the MMR root. The math:

$$ |\text{peaks}| = \text{popcount}(N) $$

so for $N = 2^k$ there's exactly one peak, and for $N$ between powers of two the peak count is bounded by $\lceil \log_2 N \rceil$. An inclusion proof for a leaf in an MMR is the path within its containing perfect tree (size $\le \log_2 N$), plus the peaks of the other trees (size $< \log_2 N$). Total:

$$ |\pi_{\text{MMR}}| \le 2 \log_2 N \cdot s $$

with $s$ the hash output size. Slightly larger than a balanced tree, but the update is $O(\log N)$ amortised with constant cost per appended leaf in the steady state, which matters for high-throughput deposit workloads. Todd's original spec and Robinson's optimality result (2025) are the references; FlyClient and Mina use MMRs in production.

For zeraswap we don't use an MMR — the deposit cadence is interactive enough that the balanced tree dominates — but the design seam is in programs/zeraswap/src/state.rs so we can swap if/when the deposit pattern shifts.

What the on-chain program checks

The on-chain inclusion check is two operations:

1. Recompute the root from the leaf, the index, and the co-path. This is $\log_2 N$ Poseidon hashes. On Solana with the sol_poseidon syscall, that's roughly $26 \times 1500 = 39{,}000$ compute units at $h = 26$.
2. Compare the recomputed root against a recent canonical root stored on-chain. Light Protocol keeps a sliding window of recent roots (the rolling-hash update buffer) so that proofs constructed against a root from 5-10 slots ago still verify. This is what makes high-throughput compressed accounts work — you can't force every prover to re-derive a proof on every slot tick.

The on-chain program does not store the leaves. It does not store the inner nodes. It stores the root and the change history, period. The state-cost difference between "32 bytes on chain plus an indexer" and "32 KB per account" is the entire reason ZK Compression got to mainnet on Solana.

What lives where, in the ZERA stack

To make this concrete:

crates/zera-sdk-core/src/merkle.rs        # Rust prover-side path construction
crates/zera-sdk-onchain/src/lib.rs        # on-chain root verification
packages/sdk/src/merkle.ts                # JS path construction (browser wallet)
programs/zeraswap/src/state.rs            # commitment-tree state account layout

All four read the same Poseidon parameters (see the Pedersen post for why we have four implementations of Poseidon and how they're cross-validated). The same way the Poseidon hash has to agree byte-for-byte across the four implementations, the Merkle tree construction has to agree on:

• Leaf encoding (which fields go into the leaf hash, in what order)
• Internal node encoding (left || right, both 32 bytes, big-endian)
• Default-leaf hash for empty subtrees (Light Protocol uses Poseidon of zero; we match)
• Root format (single 32-byte field element)

If any of these drift, the prover and verifier disagree silently and the protocol stops accepting proofs. We have integration tests in tests/merkle_cross_impl.rs that build the same tree from the JS and Rust sides and assert equality at every level. They run in CI on every commit.

Where this leaves the design space

The thing I keep coming back to: a Merkle tree is the cheapest possible primitive for "prove this thing is in this set" with a logarithmic-size proof. There is no clever lattice, no exotic accumulator, that comes close on the cost-per-byte budget Solana imposes. Verkle trees are interesting on paper and impractical in production for this surface (the polynomial commitment overhead dominates at the leaf counts we care about). KZG-based vector commitments are interesting for trusted-setup-tolerant rollups and overkill for a privacy pool.

So the answer is the boring one. A balanced binary Merkle tree, height 26, Poseidon hash, default-zero subtrees, sliding window of 32 recent roots. It is what Light Protocol shipped, what zera-sdk ships, and what every serious Solana privacy stack will ship through the rest of the decade. The interesting work is in the layers above (the SNARK that uses the inclusion proof, the nullifier set that enforces single-spend, the curve choice underneath the hash) — see the curve post for that.

Further reading

• ZK Compression Whitepaper — Light Protocol, 2024 — the canonical compressed-account spec.
• Merkle Mountain Ranges are optimal — Robinson (2025) — proves the MMR is space-optimal among append-only authenticated dictionaries.
• Light Protocol account-compression program — the on-chain implementation.
• Dax911/z_trade/programs/zeraswap — production Rust shape for the compressed-AMM use case.
• Pedersen commitments, in production — what we hash into the leaves.
• Nullifiers without the witchcraft — the dual structure that prevents double-spends.
• zeraswap: a compressed AMM — sister piece on the trading layer that lives on top of these trees.

The first time I read the Tornado Cash whitepaper I missed the fee paragraph. I noticed the Merkle inclusion, the nullifier hash, the snarkjs circuit. I did not notice the part where, to actually withdraw to a fresh address, you need somebody else to broadcast the transaction. It was buried under "operator/relayer" — a word I generously read as "convenience". It is not a convenience. It is the load-bearing wall of every smart-contract privacy mixer in production.

This post is post 2 of 11 in the relayerless-privacy series. Post 1 introduced the framework $\mathcal{F}_{\text{RP}}$ and outlined what the rest of the series builds. Here we slow down on the fee paradox itself — what it is, why every system using fees in a public token suffers it, and the three approaches that resolve it.

Definition: the fee paradox

On any blockchain $\mathcal{B}$ with a fee-based inclusion mechanism:

1. To submit a transaction, the submitter's address must pay a gas fee $f > 0$.
2. To hold gas, the address must have been previously funded.
3. Funding an address creates an on-chain link to the funding source.

Therefore, any address that submits a transaction has a traceable funding history. Any privacy-preserving withdrawal to a fresh (unfunded) address requires an external party to pay the gas fee.

Formally, in the fee paradox game:

1. User $\mathcal{U}$ deposits value $v$ into a shielded pool.
2. $\mathcal{U}$ wishes to withdraw to a fresh $\mathsf{addr}_{\mathsf{recv}}$ with no prior on-chain history.
3. Adversary $\mathcal{A}$ observes all transactions.
4. If $\mathcal{U}$ funds $\mathsf{addr}_{\mathsf{recv}}$ to pay gas, $\mathcal{A}$ traces the funding source.
5. $\mathcal{A}$ wins by linking the withdrawal to a prior deposit with non-negligible advantage.

$$ \mathsf{Adv}^{\mathsf{FeeParadox}}_{\mathcal{A}}(\lambda) ;\geq; 1 - \mathsf{negl}(\lambda) \quad \text{in standard blockchain models.} $$

The advantage is overwhelming. The deck is stacked because the chain literally requires an attestation from a funded account before it will include any state transition. Privacy at the cryptographic layer collides with funding at the consensus layer, and the consensus layer wins.

Why UTXO chains don't have this problem

Bitcoin and Zcash inherit a different model. A UTXO transaction's "fee" is the difference between input value and output value:

$$ f ;=; \sum_i v^{\mathrm{in}}_i ;-; \sum_j v^{\mathrm{out}}_j. $$

The miner takes $f$ as the implicit fee. There is no separate "gas account" that needs to exist beforehand. In Zcash specifically, a Sapling or Orchard transaction's valueBalance field — the net flow from the shielded pool to the transparent pool — is the fee. The binding signature proves the value commitment balance. The miner is paid out of value the prover is already moving, signed by the prover, with the prover's identity hidden by the ZK proof.

Result: Zcash is relayer-free by construction. Penumbra, Aleo, Namada, and Monero are too — for the same reason. They all run on chains whose native fee model is fee-from-balance, not gas-from-account.

The fee paradox is specific to account-model chains like Ethereum and Solana, where transactions require an explicit fee payer signature and the fee is debited from a known account.

Three approaches to resolution

The paper section §2.3 enumerates three approaches to resolving the paradox without a relayer:

Approach A — Protocol-Native Fee Abstraction via ZK Fee Proofs

The fee is extracted from the shielded pool inside the ZK proof itself. The proof attests that

$$ \sum_{i=1}^{n_{\mathsf{in}}} v_i ;=; \sum_{j=1}^{n_{\mathsf{out}}} v'_j ;+; f $$

where $f$ is a public input to the proof and $v_i, v'_j$ are private inputs. Pedersen commitments make this clean: with $C_i = v_i \cdot G + r_i \cdot H$ for input notes and $C'_j = v'_j \cdot G + r'_j \cdot H$ for output notes,

$$ \sum_i C_i ;=; \sum_j C'j ;+; f \cdot G ;+; r\Delta \cdot H, $$

where $r_\Delta = \sum_i r_i - \sum_j r'_j$ is a blinding-factor residual that the prover demonstrates equals the right thing.

The validator extracts $f$ as inclusion compensation directly. The submitter does not need a public balance. This is what SPST does, and it's the path the whole series builds toward.

Approach B — Nullifier-Derived Fee Authorization

A second derivation from the spending key, parallel to the nullifier:

$$ \mathsf{nullifier} = \mathsf{PRF}_k(\rho), \qquad \mathsf{fee_auth} = \mathsf{PRF}_k(\rho ,|, \text{``fee''} ,|, f). $$

The ZK proof proves both come from the same $(k, \rho)$, that $\mathsf{fee_auth}$ encodes $f$, and that the underlying note has sufficient balance. The fee is bound to the nullifier cryptographically — no party can alter the fee post-proof-generation.

This is more invasive than Approach A (changes the nullifier scheme) but gives a stronger non-malleability property. Most production designs use Approach A; Approach B becomes interesting when the protocol wants stricter binding for compliance audits.

Approach C — Recursive Fee Amortization via Batch Proofs

For high-frequency private transactions, fold $n$ proofs into a single Nova-style accumulator:

$$ \mathsf{FoldedProof}n ;=; \mathsf{Fold}(\mathsf{FoldedProof}{n-1}, , (\mathsf{tx}_n, w_n)). $$

The folded proof attests that all $n$ transactions are individually valid and that the cumulative fee $F_n = \sum_{k=1}^n f_k$ has been correctly accumulated. A single on-chain verification covers all $n$ transactions.

On Solana, with ~200,000 CU per Groth16 verification and a per-transaction limit of ~1,400,000 CU, batches of $n \leq 7$ fit within a single transaction's compute budget. The amortised per-transaction CU cost drops by an order of magnitude.

Tradeoff summary

<TradeoffTable rows={[ { aspect: 'Approach A (ZK fee proof)', pros: 'Smallest circuit overhead, no extra nullifier, clean Pedersen homomorphism', cons: 'Fee amount $f$ is public (necessary for validator compensation)' }, { aspect: 'Approach B (Nullifier-derived)', pros: 'Cryptographic binding of fee to spending key; non-malleable', cons: 'Doubles the PRF calls; fee changes mean new nullifier scheme' }, { aspect: 'Approach C (Folded batch)', pros: 'Amortises verification cost across $n$ transactions', cons: 'Requires Nova/SuperNova folding; off-chain coordination overhead' }, ]}/>

What the relayer-dependent protocols do instead

Tornado Cash, RAILGUN, and Light Protocol's older privacy phase all chose none of the above. They use a relayer who pays the gas in the host chain's native asset, takes a fee from the withdrawn amount, and broadcasts the transaction. The architecture is roughly:

<Mermaid id="relayer-flow" code={flowchart LR U[User] -->|"1- Build ZK proof locally"| U U -->|"2- Send proof + nullifier + recipient + fee"| R[Relayer] R -->|"3- Pay gas in native asset"| R R -->|"4- Broadcast withdrawal tx"| P[Privacy Contract] P -->|"5- Verify proof, check nullifier"| P P -->|"6- N minus f tokens to recipient"| U P -->|"7- f tokens fee to relayer"| R classDef actor stroke:#4ade80,stroke-width:2px,fill:#0a0a0a,color:#fff class U,R,P actor }/>

The proof is binding — the relayer cannot redirect funds, cannot change the fee — but the relayer can refuse to broadcast. They can also log the user's IP, timing, and metadata. In RAILGUN this is mitigated by routing over the Waku P2P network; in Tornado Cash it was just an HTTPS endpoint. Either way: the relayer is a third party, and that third party is a regulatory and operational single point of failure.

What changes when fees are folded into the proof

Once the fee comes from inside the proof, three things become different:

1. The submitter does not need a balance. The transaction can be broadcast by the user themselves from a fresh address that has zero of the host chain's native asset. The chain's transaction-broadcasting interface accepts transactions from any party with a valid signature; that signature now binds nothing to the user's identity.

2. The validator gets paid out of the shielded pool's escrow. On Solana, this is realised by having the privacy program's PDA hold a lamport reserve. The fee $f$ — proven inside the SPST proof — authorises a transfer from this reserve to the validator. The shielded pool's internal accounting decrements by $f$. Every deposit replenishes the reserve.

3. Censorship surface collapses. There is no "approved relayer list" for an adversary to attack. There is no operator to subpoena. The user's only dependency is chain liveness — and that's what Solana's PoS consensus guarantees.

This is the Self-Sovereignty Theorem in informal form. The next post (SPST) makes it formal.

Bibliography

• Pertsev, A., Semenov, R., Storm, R. (2019). Tornado Cash Privacy Solution v1.4. https://berkeley-defi.github.io/assets/material/Tornado%20Cash%20Whitepaper.pdf
• RAILGUN Documentation. Privacy System Architecture. https://docs.railgun.org
• Hopwood, D. et al. (2016–2026). Zcash Protocol Specification. https://zips.z.cash/protocol/protocol.pdf
• Pedersen, T. P. (1991). Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing. CRYPTO 1991.
• Kothapalli, A., Setty, S., Tzialla, I. (2022). Nova: Recursive Zero-Knowledge Arguments from Folding Schemes. https://eprint.iacr.org/2021/370

Previous: Series intro ← · Next: SPST: self-paying shielded transactions →

I've been writing a paper. Working title: Relayerless Full-Privacy Framework for Turing-Complete Blockchain Systems. I keep calling it $\mathcal{F}_{\text{RP}}$ in my notebook, and I'll keep doing that here. The shape of it is a quintuple of protocols — $\mathsf{Setup}$, $\mathsf{Shield}$, $\mathsf{Transfer}$, $\mathsf{Unshield}$, $\mathsf{Execute}$ — that together aim to do something every existing privacy system on a smart-contract chain refuses to do: let the user finish a private transaction without paying anyone but a validator.

This post is the orientation. Subsequent posts in the series step through each construction in detail with proofs, circuit costs, and Solana instantiation numbers. Here I want to set the table — what problem $\mathcal{F}_{\text{RP}}$ targets, what games formalise it, and how the four pieces compose.

The relayer problem, in one paragraph

Submit a private withdrawal on Tornado Cash from a fresh address. The contract runs the proof, accepts it, and tries to send 1 ETH to your fresh address. Except the fresh address has zero ETH and cannot pay gas. So you can't be the submitter — somebody else has to broadcast the transaction with their own ETH and bill you for it. That somebody is the relayer. The relayer breaks the on-chain link between your deposit and your withdrawal address, but in exchange they observe everything: your IP, your timing, the recipient address, the fee you accept, and which proof maps to which deposit. They are also a single regulatory point of failure, as everyone in the West learned in August 2022 when OFAC sanctioned Tornado Cash and the registered relayers stopped operating. The user funds were not seized — they were merely unspendable because the relayer infrastructure went dark.

Zcash, Penumbra, and Aleo don't need relayers because they are their own chains. Aztec doesn't need relayers because it is its own L2 with its own sequencer. Tornado Cash, RAILGUN, and Light Protocol's older privacy phase need relayers because they are smart-contract layers on a host chain whose fees must be paid in the host chain's native asset by an address that already has it.

What I want — and what $\mathcal{F}_{\text{RP}}$ delivers — is a privacy protocol that runs as a smart-contract layer on a Turing-complete L1, where the only thing the protocol needs from the outside world is liveness: the chain keeps making blocks, and any valid transaction eventually gets included.

Five games that pin down "relayer dependence"

Section 1 of the paper formalises five distinct failure modes that emerge from relayer dependence. Every one of them is an active threat against currently deployed protocols. I'll quote them tersely; the full game definitions are in the paper.

<TradeoffTable rows={[ { aspect: 'Liveness Failure', pros: 'Adversary forces relayer set offline → user cannot withdraw within $T_{\max}$ blocks.', cons: 'Wins with overwhelming probability when $\mathcal{A}$ controls all relayers; e.g. OFAC TC 2022.' }, { aspect: 'Information Leakage', pros: 'Relayer observes withdrawal metadata: timing, recipient, fee, IP.', cons: 'Distinguishing advantage non-negligible for any logging relayer.' }, { aspect: 'Trust & Censorship', pros: 'Relayer selectively refuses to submit based on $P(\mathsf{addr}_{\mathsf{recv}})$.', cons: 'Censorship probability = 1 when $\mathcal{A}$ controls $\mathcal{R}$. Funds binding does not save liveness.' }, { aspect: 'Regulatory Surface', pros: 'Government adversary identifies relayer operators as legally liable entities.', cons: 'Sanctions / criminal charges → all relayers offline → withdrawal mechanism disabled.' }, { aspect: 'Economic Extraction', pros: 'Relayer charges supracompetitive fees, frontruns correlated trades, sells ordering info to MEV searchers.', cons: 'Rational adversary extracts non-negligible profit; PPE binding does not bound timing/metadata leaks.' }, ]}/>

The point of formalising these as games is the same point Goldwasser, Micali, and Rackoff made about zero-knowledge proofs in 1985: until you've written down what an adversary can do and how it wins, you have no theorem to prove. The five games above are what every honest analysis of a privacy protocol owes the reader.

What we want, formally

$\mathcal{F}_{\text{RP}} = (\mathsf{Setup}, \mathsf{Shield}, \mathsf{Transfer}, \mathsf{Unshield}, \mathsf{Execute})$ — five protocols, each a PPT algorithm, with the following five desiderata:

D1 (Full Privacy). For any PPT adversary with full view of chain state $\sigma$ and any two valid transactions $\mathsf{tx}_0, \mathsf{tx}_1$ (different senders / recipients / amounts / programs):

$$ \mathsf{Adv}^{\mathsf{priv}}_{\mathcal{A}}(\lambda) ;=; \bigl|,\Pr[\mathcal{A}(\sigma, \mathsf{tx}_0) = 1] - \Pr[\mathcal{A}(\sigma, \mathsf{tx}_1) = 1],\bigr| ;\leq; \mathsf{negl}(\lambda). $$

D2 (Self-Sovereignty). For every protocol operation $\mathsf{Op}$ and any adversary controlling all network participants except the user $\mathcal{U}$, $\mathcal{U}$ still completes $\mathsf{Op}$ with overwhelming probability — assuming only that the underlying chain $\mathcal{B}$ provides liveness.

D3 (Composability). Private state transitions can invoke arbitrary smart contract logic. For any arithmetic circuit $C: \mathbb{F}^n \to \mathbb{F}^m$ with $|C|$ gates, the framework supports $\mathsf{Execute}(\mathsf{pp}, C, \cdot, \cdot)$ with proof generation cost polynomial in $|C|$.

D4 (Succinctness). On-chain verification cost $O(1)$ pairings or $O(\log n)$ hash evaluations. Proof size $O(1)$ or $O(\log^2 n)$.

D5 (No / Universal Trusted Setup). Either no setup (transparent) or a universal SRS that is updatable by any party.

If you've read the post on Halo2 you'll recognise D5 as the "no per-circuit ceremony" requirement. D1, D2, D3, D4 are the standard four for a privacy SNARK; D2 is the one the existing relayer-dependent protocols silently violate.

Four constructions

The framework decomposes into four primitives, each addressing one piece of the problem:

<Mermaid id="frp-construction-stack" code={graph TD A[SPST<br/>Self-Paying Shielded Transactions] --> D[UPEE<br/>Universal Private Execution Environment] B[PPST<br/>Private Programmable State Transitions] --> D C[TAB<br/>Threshold-Anonymous Broadcast] --> D D --> E[Theorem 3.12<br/>Simulation-Based Privacy] D --> F[Theorem 3.13<br/>Self-Sovereignty] classDef build stroke:#4ade80,stroke-width:2px,fill:#0a0a0a,color:#fff classDef thm stroke:#facc15,stroke-width:2px,fill:#0a0a0a,color:#fff class A,B,C,D build class E,F thm }/>

1. SPST — Self-Paying Shielded Transaction. A note/commitment/nullifier scheme where the fee $f$ is extracted inside the ZK proof itself via a Pedersen-commitment balance equation. The fee paradox dies here. (Post 3.)

2. PPST — Private Programmable State Transitions. SPST generalised so that the proof attests to correct execution of an arbitrary arithmetic circuit $C$ over committed pre-state and post-state. This is what makes the framework Turing-complete. (Post 4.)

3. TAB — Threshold-Anonymous Broadcast. Network-layer anonymity, using ring signatures (Approach A) or FROST-style threshold Schnorr (Approach B) to hide which of $n$ participants actually submitted the transaction. (Post 5.)

4. UPEE — Universal Private Execution Environment. The composition: $(\mathsf{Setup}, \mathsf{Deploy}, \mathsf{Invoke}, \mathsf{Verify}, \mathsf{Finalize})$. UPEE is what gets deployed to a chain. (Post 7.)

The two main theorems sit on top of the stack:

• Theorem 3.12 (Simulation-Based Privacy). For any PPT adversary controlling the blockchain there exists a PPT simulator $\mathcal{S}$ such that ${\mathsf{View}{\mathcal{A}}(\mathsf{Real})} \approx_c {\mathsf{View}{\mathcal{A}}(\mathsf{Ideal})}$, where $\mathcal{S}$ learns only that some valid transaction occurred and some fee was paid.
• Theorem 3.13 (Self-Sovereignty). $\Pr[\mathsf{Game}_{\mathrm{RF}}(\mathcal{A}, \lambda) = 1] = 1 - \mathsf{negl}(\lambda)$ for any adversary $\mathcal{A}$ controlling all network participants except the user.

The first theorem is the "this is private" theorem; the second is the "you don't need a relayer" theorem. The series will derive both.

Why Solana, specifically

I keep being asked why I'm building this on Solana instead of writing yet another L1. The honest answer:

1. The chain already exists, has 65k+ TPS theoretical throughput, and sub-second finality.
2. Native alt_bn128 syscalls (added in v1.16) make Groth16 verification cost < 200,000 CU on-chain — that's roughly $0.02 per private transaction.
3. The 1,232-byte transaction limit is tight but not impossible: SPST fits in 656 bytes. SIMD-0296 (approved late 2025) raises this to 4,096 bytes.
4. Light Protocol's ZK Compression infrastructure already provides Poseidon Merkle trees and Groth16 verification — most of the substrate I need.

Solana is also the only general-purpose Turing-complete L1 that has shipped pairing-friendly elliptic-curve precompiles to the validator runtime. Ethereum has had EIP-197 since the Byzantium fork (2017), but the gas costs make Groth16 verification on Ethereum L1 cost ~$5 per proof at typical gas prices. Solana's per-CU pricing brings that down by ~400×.

What's coming in the series

Bibliography for this post

• Aylor, H. (2026). Relayerless Full-Privacy Framework for Turing-Complete Blockchain Systems. Preprint, Zera Labs. (The paper this series is derived from. Final PDF will land at /papers/relayerless-privacy/ once typeset.)
• Ben-Sasson, E. et al. (2014). Zerocash: Decentralized Anonymous Payments from Bitcoin. IEEE S&P 2014.
• Hopwood, D. et al. (2016–2026). Zcash Protocol Specification. https://zips.z.cash/protocol/protocol.pdf
• Pertsev, A., Semenov, R., Storm, R. (2019). Tornado Cash Privacy Solution v1.4.
• Mayer Brown (2024). Federal Appeals Court Tosses OFAC Sanctions on Tornado Cash.

Next post: The fee paradox →

Two things share the name "sidecar" in this codebase and I want to disambiguate them up front:

1. The FFI verifier (vanta-verifier-ffi → libvanta_verifier.a) is linked into vantad. It runs in-process. It's what answers "does this SP1 proof verify" inside src/script/interpreter.cpp.
2. The L2 sidecar (vanta-node) is a separate daemon. It indexes commitments, holds the SMT, distributes encrypted notes, and serves a REST API to wallets. It does not participate in consensus.

This post is about both, because the architecture only makes sense when you see why one is in-process and the other isn't.

The audit-surface trade

Bitcoin Core has 280k+ lines of C++ that have been read by more eyes than any other consensus codebase on Earth. Adding a Rust dependency to that build is a non-trivial ask of a future Bitcoin-Core-style review. We made the call up-front: a minimal Rust footprint inside vantad, exposed through a hand-written C ABI, with everything else in a separate process.

The minimal footprint is libvanta_verifier.a. From the zkVM engineering paper, the contract:

The bridge between the ZK proof world and the consensus world is a 440-byte C-compatible structure called VantaJournal, declared in src/vanta/verifier.h:

typedef struct {
    uint8_t  smt_root[32];
    uint32_t input_commitment_count;
    uint8_t  input_commitments[VANTA_MAX_SLOTS][32];
    uint32_t nullifier_count;
    uint8_t  nullifiers[VANTA_MAX_SLOTS][32];
    uint32_t commitment_count;
    uint8_t  commitments[VANTA_MAX_SLOTS][32];
    int64_t  value_balance;
} VantaJournal;

The C++ never deserializes an SP1 proof. It calls vanta_verify_and_decode() with a byte slice; the function returns a boolean and populates the VantaJournal. From there the consensus engine looks at 32-byte hashes and a signed i64 and makes its decisions on bytes alone.

This is a deliberate cryptographic-engineering posture. The proof system can change underneath the FFI without changing the FFI. SP1 today, Halo 2 someday, whatever-comes-after-that the day after that — the C++ doesn't have to know.

Why isn't the L2 logic in vantad too?

This was the design conversation that took the longest to resolve.

Option A was to put everything in-process. One binary, one supervised PID, fewer moving parts. The problem: the L2 index isn't consensus. It's an indexed view of commitments, an SMT, and a REST API. Bundling that into vantad would mean every Bitcoin-Core-style operator who wanted to run the chain would inherit an HTTP server, an SQLite-backed index, and an iroh-based gossip layer. That's a footprint expansion that buys nothing for the consensus path.

Option B was a separate process with a clean network boundary. vanta-node talks down to vantad over standard JSON-RPC (the same getblock/getrawtransaction an explorer would use) and up to wallets over REST and iroh gossip. The footprint cost lives in the operator's discretion: if you don't want the L2 services, don't run vanta-node.

We went with B and I don't regret it. The trade-off is that the L2 sidecar is a piece of operational machinery to keep alive. The desktop app handles that automatically (see vanta-desktop); a server operator handles it the way they handle any daemon.

What vanta-node actually does

main.rs is a four-task tokio program:

let watcher_handle = tokio::spawn(async move {
    if let Err(e) = l1_watcher::run(watcher_config, watcher_state).await {
        tracing::error!("L1 watcher error: {e}");
    }
});

let gossip_handle_opt = match gossip::start(state.clone(), config.bootstrap_peers.clone()).await {
    Ok((handle, router)) => { ... }
    Err(e) => {
        tracing::warn!("Failed to start gossip (continuing without P2P): {e}");
        None
    }
};

let api_handle = tokio::spawn(async move {
    if let Err(e) = api::serve(api_state, &api_listen).await {
        tracing::error!("API server error: {e}");
    }
});

let save_handle = tokio::spawn(async move {
    let mut interval = tokio::time::interval(tokio::time::Duration::from_secs(10));
    loop {
        interval.tick().await;
        if let Err(e) = save_state.save() {
            tracing::warn!("Failed to save state: {e}");
        }
    }
});

Four jobs: watch L1 for new blocks, gossip with peers over iroh, serve the REST API, and snapshot state to disk every 10 seconds. Each tokio task runs against a shared L2State that's Arc-cloned across them.

The L1 watcher polls vantad's RPC every 2 seconds (configurable via VANTA_POLL_MS). For each new block it scans every transaction's outputs for the OP_RETURN anchor format we use to publish commitments and nullifiers — the byte sequence is OP_RETURN 0xbb 0x00 <32-byte commitment>, defined in the pool's stratum server where I wrote it in Python and reused the format on the Rust side. Hits get fed into the SMT.

The gossip layer uses iroh — pure-Rust, QUIC-based, NAT-traversing — to share encrypted notes between L2 peers. The bootstrap_peers come from an env var; the desktop app starts with that empty by default. Iroh's gossip is a per-topic channel and we use one topic per chain (mainnet, regtest). The architecture doc explains the pick:

P2P: iroh.computer — pure Rust, QUIC-based, NAT traversal, gossip protocol, content-addressed blobs. Chosen over libp2p for simplicity, built-in QUIC + NAT hole-punching, and document sync (useful for offline branch-and-merge).

The REST API is the thing wallets actually consume. The endpoints I care most about are /status (commitment count, nullifier count, SMT root, last block), /submit (push new commitments + encrypted notes from the pool or a wallet), /notes/scan (trial-decrypt encrypted notes against a wallet's secret key), and /proofs/recent (the 500-slot ring buffer of recently-verified proofs the explorer renders).

The save loop is 10-second snapshots. The state file is a bincode'd dump of the SMT plus the nullifier set plus the encrypted-note inbox. Drop on the L2State saves on shutdown too. If the process is killed -9 you lose at most 10 seconds of work, and the L1 watcher rebuilds the state by re-scanning from the last good height.

How the wallet uses the sidecar

The desktop wallet uses both vantad and vanta-node. From the wallet's perspective:

• vantad is the source of truth for L1 — block heights, transparent UTXOs, transaction broadcast.
• vanta-node is the source of truth for L2 — commitments, nullifiers, encrypted notes addressed to me.

When I press "send" on a private transaction in the desktop wallet:

1. The wallet asks vanta-node for the current SMT root and the membership proof for the input commitment I'm spending.
2. The wallet generates an SP1 proof locally (or, for low-end machines, against the SP1 proving network) using the membership proof and my secret key as private witness.
3. The wallet builds an L1 transaction that includes the SP1 proof in witness.stack[0] and an OP_RETURN anchor with the new commitment.
4. The wallet broadcasts the transaction via vantad's sendrawtransaction RPC.
5. vantad validates: standard script checks, then vanta_verify_and_decode() against the SP1 proof in the witness.
6. After the block is mined, vanta-node's L1 watcher picks up the OP_RETURN anchor and the new commitment lands in the SMT.

The recipient wallet /submits an encrypted-note query to its vanta-node, which trial-decrypts using the recipient's secret. If the trial decrypts cleanly, the note is mine.

This is the architecture the coinbase auto-shield feature also rides on: every miner reward is a witness v2 commitment paying into the miner's shielded address, with the encrypted note pushed to the L2 via the same /submit endpoint. From the pool's stratum server:

def save_shielded_note(height, commitment_hex, randomness_hex, value):
    """Persist mining note and submit encrypted note to L2 for wallet discovery.

    Called ONLY after a winning block is accepted by submitblock — never from
    the per-share job-template path, otherwise the L2 SMT fills up with phantom
    commitments for templates that never won the PoW race.
    """

That comment is load-bearing. The first version of the pool submitted the encrypted note on every share — that produced thousands of phantom commitments per block. Submitting only on submitblock accept fixes it.

Failure modes

The sidecar architecture has failure modes the in-process design wouldn't have. They're worth naming.

vanta-node is dead, vantad is alive. The wallet's L1 RPC works fine. The wallet's L2 calls all 503. The desktop app surfaces this as "L2 disconnected" and lets you keep using transparent functionality. Private send is gated behind L2 reachability.

vantad is dead, vanta-node is alive. L1 RPC fails. vanta-node's watcher logs polling failures. The L2 state is frozen at whatever block was last seen. The desktop app surfaces this as "L1 disconnected"; sending is impossible (no broadcast endpoint), but the wallet can still display historic state.

Both alive but vanta-node lost its data dir. The L1 watcher detects "I've seen no blocks" on startup and re-scans from genesis. On a small chain this is fine. On a large chain this is a known cost of recovery — measured in hours, not days, but not free.

vanta-node is alive but the SMT is corrupted. This one I worry about. Bincode + Drop-save + 10-second snapshots is a defensible steady state, but a partial write during a crash could in principle produce a non-loading state file. Recovery is "rm the state file, restart, let the watcher rebuild." We have monitoring on the fall-through path. TODO: Dax confirm we ship cryptographic checksums on the state file.

What this isn't

I want to head off two possible misreadings.

This is not a proof-on-server architecture. The proof generation happens in the wallet (or, optionally, on a remote SP1 prover the user trusts). vanta-node doesn't generate proofs. It distributes encrypted notes and indexes commitments. The only ZK code in vanta-node is the verifier path it uses to sanity-check proofs before accepting them into the proof event ring buffer.

This is not a custodial sidecar. vanta-node never sees secret keys. The encrypted notes are encrypted to the recipient's pubkey — vanta-node distributes ciphertext. Trial decryption happens client-side in the wallet using the recipient's secret. Lose the secret, lose the funds; lose the L2 sidecar, replay the chain. The cryptographic posture is the same as Zcash sapling notes.

What I changed my mind about

The original nullifier-set post hinted at this: "The actual ZK proof verification happens out of process in the Rust sidecar. The C++ node fires off the proof to a local Unix socket and waits for ok or not ok." That's how it was originally architected. We changed it.

The Unix-socket sidecar didn't survive contact with the SP1 backend. Spawning a sub-process every block to verify proofs is fine in regtest where blocks are minutes apart; on mainnet at 1-minute blocks with peak-hour transaction volume, the IPC overhead added up to milliseconds per verify, multiplied by every spend in every block. Statically linking libvanta_verifier.a into vantad brought the verifier into the same address space and the same allocator and dropped the per-verify cost to roughly what an in-Rust call would cost.

The audit-surface concern is real but mitigated by the minimal FFI: 440 bytes of struct, two C functions, deterministic output. A fuzzer can hammer that boundary and you'll know if it's broken.

What's still out of process is the L2 state — the SMT, the nullifier index, the encrypted-note inbox. That's the thing whose footprint we never want inside vantad, and there it's stayed.

Further reading

• vanta/vanta-node — the L2 sidecar
• vanta/vanta-verifier-ffi — the in-process FFI verifier
• papers/17-zkvm-engineering.md — the design rationale for the SP1/Plonky3 backend
• Vanta: a Bitcoin fork with ZK at consensus — the chain itself
• Vanta Desktop: a Tauri wallet that ships its own full node — the binary that supervises both processes
• iroh.computer — the QUIC-based P2P stack the gossip layer uses

The answer that landed in commit e624a8e7 on 2026-04-17 — desktop: scripts for BTC RPC tunnel + address watcher + rpc helper — is three tiny shell scripts that forward a remote bitcoind's RPC port to localhost over an SSH jump host, then wrap the JSON-RPC calls so the swap CLI can speak to a real mainnet node from any laptop.

This post walks the three scripts, explains why they're written the way they are, and ends with an unkind paragraph about the alternative (just exposing port 8332 directly).

The scripts

There are three of them, all in vanta/vanta-desktop/scripts/:

• btc-tunnel.sh — set up / tear down / probe the SSH tunnel
• btc-rpc.sh — make a single JSON-RPC call to the tunneled node
• btc-watch.sh — poll an address for state changes, with auto-reconnect

They are all bash, all set -euo pipefail, all under 100 lines. Code that looks like 1995. That's the right tool for what they do.

btc-tunnel.sh: the SSH-jump forward

The architecture: my laptop sits on whatever Wi-Fi I'm on. The bitcoind runs at 10.0.1.89 on my home LAN. I can't reach 10.0.1.89 from a coffee shop. I can reach a public-facing jump host (a small VPS on a port I won't share publicly), and the jump host can reach the LAN.

ssh -J jump@public:port lan-host does the routing. ssh -L 8332:127.0.0.1:8332 lan-host does the port forward. Combine them, daemonise the connection with -f -N -M, point a control socket at /tmp/btc-tunnel.sock, and you have a process you can up/down/status against from any shell.

The full flag set, from the script:

ssh_args=(
  -o StrictHostKeyChecking=accept-new
  -o IdentitiesOnly=yes
  -o ServerAliveInterval=30
  -o ServerAliveCountMax=3
  -o ExitOnForwardFailure=yes
  -i "$BTC_TUNNEL_KEY"
  -J "${JUMP_USER}@${JUMP_HOST}:${JUMP_PORT}"
  -L "${BTC_LOCAL_PORT}:127.0.0.1:${BTC_TUNNEL_RPC_PORT}"
  -S "$SOCKET"
)

Five of these flags are load-bearing. Let me unpack them.

StrictHostKeyChecking=accept-new. This is the "trust on first use" mode. It accepts a new host key on first connection but refuses any later mismatch. The strict-no setting (yes) would require pre-populating known_hosts; the strict-no-yes setting (no) would silently accept any host key including a man-in-the-middle. accept-new is the right middle ground for an interactive dev tool.

IdentitiesOnly=yes. Tells SSH to use only the key passed in -i, not whatever else is in ~/.ssh/. Without this, SSH will try every key in your agent, exhaust the server's MaxAuthTries, and fail with a confusing error.

ServerAliveInterval=30 + ServerAliveCountMax=3. Keep-alive every 30 seconds, kill the connection after 3 missed responses. A residential ISP will silently drop idle connections; this keeps the tunnel up for hours of intermittent use.

ExitOnForwardFailure=yes. If the local port bind fails — say something else is on :8332 already — exit immediately rather than maintaining a half-broken tunnel that can't actually carry traffic. The default behavior (silently keep the SSH connection up but not the forward) is a great way to spend twenty minutes wondering why your RPC calls hang.

-S "$SOCKET". Control socket. Lets a separate ssh invocation send commands to the same connection (-O check, -O exit). This is what makes is_up() work without parsing ps output:

is_up() {
  ssh -S "$SOCKET" -O check "$BTC_TUNNEL_HOST" >/dev/null 2>&1
}

That's the whole "is the tunnel alive" check. SSH manages it; we just ask.

btc-tunnel.sh: the RPC probe

Once the tunnel is up, the status command goes one step further — it actually makes an RPC call through the tunnel to verify the remote bitcoind is reachable and synced:

probe_rpc() {
  curl -s --max-time 5 --user "${BTC_RPC_USER}:${BTC_RPC_PASS}" \
    --data-binary '{"jsonrpc":"1.0","id":"s","method":"getblockchaininfo","params":[]}' \
    -H 'content-type:text/plain;' "http://127.0.0.1:${BTC_LOCAL_PORT}/"
}

The output gets parsed by an inline Python one-liner that prints the chain, block height, header height, sync state, and verification progress in one terse line. Why Python and not jq? Because jq isn't preinstalled on a fresh macOS, and Python 3 is. Portability wins over elegance here.

The getblockchaininfo RPC is the standard "is this node alive and what does it know" call. If it returns a coherent JSON body, the tunnel is end-to-end working. If it doesn't, you get a clear error and you know which layer to debug — the SSH connection (tunnel up but RPC dead) or the local port (tunnel down, no RPC at all).

btc-rpc.sh: the one-shot wrapper

This one is so small it fits in the post:

wallet_scoped=0
if [ "${1:-}" = "--wallet" ]; then
  wallet_scoped=1
  shift
fi

method="${1:?method required}"
params="${2:-[]}"
path=""
[ "$wallet_scoped" = "1" ] && path="/wallet/${BTC_RPC_WALLET}"

curl -s --user "${BTC_RPC_USER}:${BTC_RPC_PASS}" \
  --data-binary "{\"jsonrpc\":\"1.0\",\"id\":\"cli\",\"method\":\"${method}\",\"params\":${params}}" \
  -H 'content-type:text/plain;' \
  "${BTC_RPC_URL}${path}" | python3 -m json.tool

The whole point is to give me a one-line shorthand for bitcoind debugging that doesn't require remembering the JSON-RPC envelope. From any shell with the tunnel up:

$ btc-rpc.sh getblockchaininfo
$ btc-rpc.sh --wallet getbalance
$ btc-rpc.sh --wallet getnewaddress '["swap-test","bech32"]'
$ btc-rpc.sh getrawtransaction '["<txid>", true]'

The --wallet flag is the difference between core RPCs (chain state, mempool) and wallet-scoped RPCs (balance, send, sign). Bitcoin Core changed the RPC URL convention in v0.18 — wallet RPCs route to /wallet/<name>, core RPCs route to /. The wrapper handles that distinction by setting path and concatenating it onto BTC_RPC_URL.

The python3 -m json.tool at the end is a pretty-printer. Two seconds of latency on the JSON pretty-print is the right amount of overhead for terminal readability.

btc-watch.sh: the address watcher

This is the one I use most. When you're testing an HTLC, you fund a P2WSH output, broadcast the funding transaction, wait for it to confirm, then build the spending transaction. "Wait for it to confirm" is what btc-watch.sh automates:

addr="${1:?address required — see usage in header}"
log="${2:-/tmp/btc-watch.log}"

last_state=""
while true; do
  ensure_tunnel
  resp=$(rpc listunspent "[0, 9999999, [\"${addr}\"]]" || echo '{}')
  state=$(echo "$resp" | python3 -c "
import sys,json
try:
  r = json.load(sys.stdin).get('result') or []
  if not r: print('EMPTY'); sys.exit()
  parts = ['%s|%.8f|%d' % (u['txid'], u['amount'], u['confirmations']) for u in r]
  print(';'.join(sorted(parts)))
except Exception as e:
  print('ERR:'+str(e))
")
  if [ "$state" != "$last_state" ]; then
    # log + display the change
    last_state="$state"
  fi
  sleep "$BTC_WATCH_INTERVAL"
done

Three design choices in here that took longer than they should have to get right.

listunspent with minconf=0. Includes mempool. The HTLC funding transaction shows up first in the mempool with confirmations=0, then gains confirmations as blocks are mined. You want to know about both states. The default listunspent arguments are [1, 9999999] (confirmed-only); we override with [0, 9999999, [addr]] to include mempool and filter by address.

State diffing. The watcher prints when the state changes, not on every poll. Otherwise the log is unreadable. The state representation is txid|amount|confirmations, joined with ; and sorted. Sorted because listunspent doesn't guarantee output order; without sorting, two consecutive polls of the same UTXO set could produce different state strings.

ensure_tunnel. Before each RPC poll, check that the tunnel's still up. If it's not, try to bring it back up:

ensure_tunnel() {
  if rpc getblockcount '[]' '' >/dev/null 2>&1; then return 0; fi
  log_line "rpc unreachable — attempting tunnel up"
  if [ -x "${HERE}/btc-tunnel.sh" ]; then
    "${HERE}/btc-tunnel.sh" up || log_line "tunnel up failed"
  else
    log_line "btc-tunnel.sh not found next to this script; cannot auto-reconnect"
  fi
  sleep 2
}

The script is supposed to run for hours during a long swap test. If my coffee shop's Wi-Fi drops and reconnects, the tunnel breaks. Without ensure_tunnel, the watcher would silently fail every 10 seconds. With it, the tunnel comes back up automatically and the polling resumes. The first time this saved me a swap test was the moment I knew the script was worth committing.

On exposing 8332 directly

WARNING: Do not put port 8332 on the public internet. Do not put it on a "VPN-only" subnet that you can't audit. Do not assume rate-limiting at your router is enough.

If you read tutorials online — I have, you have, we all have — you'll find advice that says "just expose your bitcoind RPC port through your router." This is bad advice, and I'm going to be direct about why.

The bitcoind RPC exposes wallet operations behind HTTP basic auth. If RPCPASSWORD ever leaks (in a CI log, in a screenshot, in a .env file in a git history, in a commit message) the attacker has full access to your wallet. They can sign transactions. They can drain your funds. There is no "I locked my wallet" safety net here — the unlock is part of the same RPC and it accepts a passphrase that can also be brute-forced once the connection is open.

Even with no wallet, the RPC exposes call patterns that can be used to fingerprint your node, drain its mempool data, and probe for vulnerabilities. Bitcoin Core has a hardening guide for a reason.

The SSH tunnel architecture solves all of this in one move. The RPC port is bound to 127.0.0.1 on the bitcoind host. The only path to it is over an authenticated SSH connection. The jump host doesn't see the RPC traffic — it sees only the encrypted SSH stream. Your laptop talks to the jump host using key-based auth (the IdentitiesOnly flag). The RPC password lives in .env.local and never leaves your machine.

If your authoring environment doesn't have an SSH-jump architecture available, the second-best is to run a separate bitcoind on regtest mode, just for the development workflow. Mainnet RPC should not be on a public IP. Ever.

Pulling it together: a swap test

The end-to-end swap-test flow looks like this, on a fresh terminal:

# 1. Bring up the tunnel.
$ ./btc-tunnel.sh up
tunnel up: 127.0.0.1:8332 -> dax@10.0.1.89:8332

# 2. Sanity check.
$ ./btc-tunnel.sh status
forward: 127.0.0.1:8332 -> dax@10.0.1.89:8332
chain=main blocks=874632 headers=874632 synced=True progress=1.000000

# 3. Generate a fresh receiving address for the swap.
$ ./btc-rpc.sh --wallet getnewaddress '["swap-test","bech32"]'
"bc1qjh9pjnqs5486d08yg4aafdlphwl3rc6ls0lf7w"

# 4. Start watching the address in another window.
$ ./btc-watch.sh bc1qjh9pjnqs5486d08yg4aafdlphwl3rc6ls0lf7w &

# 5. Run the swap CLI from a third window.
$ vanta-swap participate --amount 0.001 --hash <h> ...

The watcher logs the funding transaction the moment it hits the mempool, and again every time it gains a confirmation. The CLI broadcasts the spending transaction. The watcher logs the spend.

That whole loop takes about 30 seconds end to end on a happy mainnet. Without the tunnel scripts, it'd take twenty minutes per iteration of fumbling with bitcoin-cli arguments and SSH commands.

What I changed my mind about

I wrote the first version of btc-tunnel.sh as a one-liner pasted into Notion. It worked. I copy-pasted it dozens of times before I realised that ssh would silently exit if the home host was momentarily unreachable, leaving me typing into a tunneled port that wasn't listening to anything.

The version that ships does three things the one-liner didn't: it uses a control socket so is_up is reliable, it sets ExitOnForwardFailure so the script crashes loudly instead of looking up, and it has a restart subcommand because manually re-running up after a network drop is the kind of friction that makes you stop using the tool.

The general lesson — and this is the kind of thing I'd put in a "scripts I keep around" post — is that the dev tools you use daily deserve the same care you give production code. Not the same test coverage. But the same observability. A 60-line bash script with set -euo pipefail, control sockets, and a clear status mode is a different beast from a 60-line bash script that just sshs and prays.

Further reading

• vanta/vanta-desktop/scripts/btc-tunnel.sh — the tunnel script
• vanta/vanta-desktop/scripts/btc-rpc.sh — the RPC wrapper
• vanta/vanta-desktop/scripts/btc-watch.sh — the address watcher
• Bitcoin Core's bitcoin.conf reference — every flag in the default config
• BIP-199 by hand — the swap CLI these scripts support
• Vanta Desktop: a Tauri wallet that ships its own full node — the dev workflow these scripts plug into

The L2 sidecar I wrote about previously has four jobs: watch L1, serve a REST API, snapshot state, and gossip with peers. The first three are well-trod tokio-task territory. The fourth is the one that actually matters for L2 decentralisation, because if every peer has to fetch encrypted notes from one REST server, that REST server is a centralisation point, and the privacy chain isn't really a privacy chain.

This post is the deep dive on the gossip layer specifically. The transport is iroh.computer — a pure-Rust QUIC stack with an opinionated NAT-traversal story and a built-in gossip protocol that does most of what we need. The integration code lives in vanta/vanta-node/src/gossip.rs, which is where I'd point you to read first if you want the unvarnished version.

Why iroh

The architecture doc puts the rationale tersely. From doc/vanta-architecture.md:

That's the polite version. Let me unpack it with a tradeoff table that does not pull punches.

<TradeoffTable caption="L2 gossip transport options I actually considered" rows={[ { option: "iroh.computer (chose this)", cost: "~1.5 MB extra binary; one Rust crate; fixed config", latency: "QUIC, per-stream ordering, hole-punching by default", blast_radius: "Production users at n0-computer; small but active maintainer team", notes: "Pure Rust. NAT-traversal-as-default is the killer feature." }, { option: "libp2p (rust-libp2p)", cost: "Bigger dependency tree, more configuration, more knobs", latency: "Comparable on QUIC transport once configured", blast_radius: "IPFS, Filecoin, Polkadot — battle-tested", notes: "Configuration tax was the killer. We do not need yamux, mplex, mdns, AND noise + tls. We need one of each." }, { option: "Custom yamux-over-QUIC", cost: "Maintenance burden of every NAT-traversal edge case", latency: "Whatever you implement", blast_radius: "Nobody else runs this", notes: "Reinvents NAT traversal. The interns will resent us." }, { option: "NATS or other broker", cost: "A broker. Defeats the entire premise of decentralised L2.", latency: "Fast, but topology-dependent", blast_radius: "Operations matter on a single-binary chain", notes: "Not seriously considered. Listed for completeness." }, ]} />

The "configuration tax" point is the one I want to underline. libp2p is in principle the right answer; we used it on an earlier prototype. The problem was that every libp2p deployment is a snowflake — yamux vs mplex, noise vs tls, mdns vs static seeds, gossipsub v1.0 vs v1.1 — and getting two different libp2p deployments to talk predictably across a real residential-NAT network was a recurring time sink.

iroh ships an opinionated default. There is one transport (QUIC), one ALPN per protocol, and one NAT-traversal story (n0-relay-assisted hole-punching). When it works it works the same way every time. When it fails, the failure modes are bounded and documented.

Topology

The Vanta L2 gossip topology is one topic per chain, with content-addressed blob references for any payload that's too big for the gossip message-size limit (we cap at 64 KB per message, which is enough headroom for a single encrypted note plus headers).

<Mermaid chart={`flowchart LR subgraph Chain["Vanta L2 — single gossip topic"] P1[vanta-node #1
Berkeley, CA] P2[vanta-node #2
Berlin] P3[vanta-node #3
Tokyo] P4[Wallet's embedded
vanta-node] end

P1 <-->|encrypted notes
+ commitments
+ nullifiers| P2 P2 <-->|gossip| P3 P3 <-->|gossip| P4 P1 <-->|hole-punched| P4

R[(N0 relay)] P1 -. relay if
direct fails .-> R P4 -. relay if
direct fails .-> R`}/>

Every node joins the same topic. Every message broadcast on that topic ends up at every other peer (eventually — this is gossip, not multicast, so it's O(log N) hops in expectation). The N0 relays are a fallback for peers behind symmetric NATs or other hole-punching-resistant boundaries; once a direct path is found, the relay drops out.

The topic is a SHA-256 of a fixed string in gossip.rs:42:

fn vanta_topic() -> TopicId {
    use sha2::{Sha256, Digest};
    let mut hasher = Sha256::new();
    hasher.update(b"Vanta/L2/Gossip/v1");
    let hash = hasher.finalize();
    let mut bytes = [0u8; 32];
    bytes.copy_from_slice(&hash);
    TopicId::from_bytes(bytes)
}

Vanta/L2/Gossip/v1. The v1 is intentional: when we ship a breaking change to the message format, we'll bump to v2 and the two networks will simply not see each other. That's the cleanest cross-version migration story we have, and it's a single-line change.

The message shape

Three message kinds, all bincode-serialised:

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum GossipMessage {
    NewCommitment { commitment: Hash },
    NullifierRevealed { nullifier: Hash },
    EncryptedNote(EncryptedNote),
}

Hash is a 32-byte alias from vanta_core. EncryptedNote is an opaque ciphertext blob plus a recipient hint that wallets use to do trial-decryption. The ciphertext is encrypted-to-recipient-pubkey using the same envelope scheme described in the nullifier-set post — vanta-node cannot decrypt a note even if it tries.

The relevant point is what's not here. There's no "request-response" message. There's no "inventory" or "bloom filter" or pull-based sync. iroh-gossip is broadcast-only; if a peer joins late, they catch up via the L1 watcher (which scans block history) and then receive new state via gossip going forward. Decoupling history-sync from real-time-sync is a simplification: gossip is always real-time, history is always re-derived from L1.

The send path

Three small fan-out helpers, one private send method, in gossip.rs:53:

impl GossipHandle {
    pub async fn broadcast_commitment(&self, commitment: Hash) -> Result<()> {
        let msg = GossipMessage::NewCommitment { commitment };
        self.broadcast(&msg).await
    }

    pub async fn broadcast_nullifier(&self, nullifier: Hash) -> Result<()> {
        let msg = GossipMessage::NullifierRevealed { nullifier };
        self.broadcast(&msg).await
    }

    pub async fn broadcast_encrypted_note(&self, enc: EncryptedNote) -> Result<()> {
        let msg = GossipMessage::EncryptedNote(enc);
        self.broadcast(&msg).await
    }

    async fn broadcast(&self, msg: &GossipMessage) -> Result<()> {
        let bytes = bincode::serialize(msg)?;
        self.sender.broadcast(Bytes::from(bytes)).await?;
        Ok(())
    }
}

The GossipHandle is Clone and gets passed to the API server, the L1 watcher, and the swap module. Whoever has the handle can broadcast. The handle is a wrapper around iroh_gossip::api::GossipSender, which is a tokio-friendly mpsc-style channel into iroh's outbound queue.

bincode::serialize is fine here because the message types are all simple plain-old-data with no #[serde(skip)] or recursion. The deserialization path (next section) is where the gotchas live.

The receive path

start() in gossip.rs:88 is the function that brings up the whole gossip stack. It does five things:

1. Build an Endpoint with the presets::N0 relay configuration.
2. Spawn a Gossip instance with a 64 KB max-message-size.
3. Wire a Router that accepts inbound gossip connections on the gossip ALPN.
4. Subscribe to the Vanta topic with the user's bootstrap peer list.
5. Spawn a tokio task to drain the inbound stream into apply_gossip_message.

let endpoint = Endpoint::builder(presets::N0)
    .bind()
    .await?;

let gossip = Gossip::builder()
    .max_message_size(65536)
    .spawn(endpoint.clone());

let router = Router::builder(endpoint.clone())
    .accept(GOSSIP_ALPN, gossip.clone())
    .spawn();

let topic_id = vanta_topic();
let topic = gossip.subscribe(topic_id, peer_ids).await?;
let (sender, mut receiver) = topic.split();

The accept(GOSSIP_ALPN, gossip.clone()) call is what tells the router "any inbound QUIC connection that negotiates the gossip ALPN gets handed to this Gossip instance." iroh multiplexes multiple protocols on one endpoint; today we only run gossip, but the same router could in principle accept blob-sync or document-sync ALPNs.

The receive loop calls receiver.try_next() in a tight loop and dispatches each event. There are three event types we care about:

async fn handle_gossip_event(
    state: &L2State,
    peer_counter: &std::sync::Arc<std::sync::atomic::AtomicUsize>,
    event: iroh_gossip::api::Event,
) {
    use std::sync::atomic::Ordering;
    match event {
        iroh_gossip::api::Event::Received(message) => {
            match bincode::deserialize::<GossipMessage>(&message.content) {
                Ok(msg) => apply_gossip_message(state, msg),
                Err(e) => {
                    tracing::debug!("Failed to deserialize gossip message: {e}");
                }
            }
        }
        iroh_gossip::api::Event::NeighborUp(peer_id) => {
            let n = peer_counter.fetch_add(1, Ordering::Relaxed) + 1;
            tracing::info!("Gossip peer joined: {} (now {n})", peer_id);
        }
        iroh_gossip::api::Event::NeighborDown(peer_id) => {
            peer_counter
                .fetch_update(Ordering::Relaxed, Ordering::Relaxed, |v| {
                    Some(v.saturating_sub(1))
                })
                .ok();
            let n = peer_counter.load(Ordering::Relaxed);
            tracing::info!("Gossip peer left: {} (now {n})", peer_id);
        }
        _ => {}
    }
}

The _ => {} is loud silence: iroh's Event enum has more variants than we care about (relay-state changes, lurker-mode signals) and we explicitly ignore them.

The saturating-decrement gotcha

The first version of NeighborDown was peer_counter.fetch_sub(1, Ordering::Relaxed). In a happy path this was fine — every NeighborUp pairs with exactly one NeighborDown, the counter goes up and down, and /status shows the right number.

In the actual iroh deployment, NeighborDown can fire without a corresponding NeighborUp ever having been observed. (Reasons: the event stream can drop messages under backpressure; a peer can be "down" from this node's perspective before this node has joined the topic enough to consider them "up.") The bug surfaced as /status returning peer_count: 18446744073709551614. I had wrapped from 0 → usize::MAX - 1. Counting backwards in unsigned arithmetic is a strict no.

The fix is the fetch_update + saturating_sub pattern in the snippet above. It's slower than a single atomic op (it's a CAS loop) but it's load-bearingly correct: the counter never goes negative, and on the rare double-down-without-up the counter just stays at its current value.

This is the kind of thing you don't notice until production. TODO: Dax confirm we want to ship peer_count over /status as a u32 and saturate there too — even with the in-memory fix, a 64-bit counter shipped to a frontend could in principle overflow JavaScript's Number.MAX_SAFE_INTEGER if something ever went really wrong upstream.

A toy iroh-shape demo

We can't actually run iroh in a Sandbox — iroh isn't WASM-portable, and it wants real UDP sockets. But we can simulate the message-flow shape in plain Node, which is sometimes useful for understanding the topology when you read the Rust code.

<Sandbox template="node" title="iroh-shape gossip demo" files={{ "/index.js": `// Simulate iroh-gossip's broadcast topology. // Three peers, one topic, encrypted notes flow between all of them. // Real iroh would use QUIC + NAT traversal; here we use plain Node IPC.

class Peer { constructor(name) { this.name = name; this.peers = new Set(); this.seen = new Set(); } connect(other) { this.peers.add(other); other.peers.add(this); } broadcast(msg) { this.seen.add(msg.id); for (const p of this.peers) { if (!p.seen.has(msg.id)) { console.log(` ${this.name} -> ${p.name}: ${msg.kind} ${msg.id}`); p.broadcast(msg); // recursive flood — gossip is O(log N) in practice } } } }

const a = new Peer("A"); const b = new Peer("B"); const c = new Peer("C"); a.connect(b); b.connect(c); // A is not directly connected to C

console.log("A broadcasts NewCommitment(0xdeadbeef)"); a.broadcast({ id: "0xdeadbeef", kind: "NewCommitment" });

console.log("\nC broadcasts EncryptedNote(0xcafebabe)"); c.broadcast({ id: "0xcafebabe", kind: "EncryptedNote" });

console.log("\nFinal seen sets:"); for (const p of [a, b, c]) { console.log(` ${p.name}: [${[...p.seen].join(", ")}]`); } , "/package.json": { "name": "iroh-shape-demo", "version": "1.0.0", "main": "index.js" } `, }} />

This is the shape of gossip flooding. iroh's actual implementation uses HyParView + Plumtree — more sophisticated, with eager-push trees and lazy-pull repair — but the user-facing semantic is the same: broadcast on a topic, every peer eventually sees the message, exactly once.

Encrypted notes specifically

The largest message type, EncryptedNote, is what wallets actually consume. The flow is:

1. Sender's wallet generates a shielded transaction. Part of the witness is an encrypted ciphertext addressed to the recipient's pubkey.
2. Sender's vanta-node (via the desktop app) calls broadcast_encrypted_note(ciphertext).
3. iroh-gossip floods every peer in the topic. Every L2 node — including the recipient's — has the ciphertext in memory.
4. The recipient's wallet calls /notes/scan against its local vanta-node, which trial-decrypts every recently-seen ciphertext against the wallet's secret key.
5. If a trial decryption succeeds, the wallet has detected a payment.

There is no "addressing." There is no "the recipient asks for their notes." Every peer has every note. Each peer's wallet decides which notes are theirs by trying to decrypt. This is the same architectural pattern Zcash sapling uses — a public ciphertext stream with private addressability — and it's why the gossip layer can be totally untrusted: peers see ciphertexts, recipients see plaintext.

What's not in this implementation

A few things to flag, both for honesty and for the next person to read this.

No gossip-layer backpressure. If a peer publishes 10,000 encrypted notes in a second, every other peer's tokio task for the receive loop has to deserialize all of them. There's no rate limit, no back-off, no "too many pending events" exception. This is fine on a 1-minute-block chain where the pool's submission rate is bounded, but it would be a real problem on a 250 ms-block chain.

No peer reputation. Every peer is equal. A misbehaving peer (sending malformed messages, spamming) is just ignored on a per-message basis. We don't disconnect them, ban them, or de-prefer them in routing. iroh has the primitives (endpoint.close_peer) but we don't use them.

No persistence across restarts. When vanta-node restarts, it forgets every peer it had ever seen and re-bootstraps from the static seed list. This costs ~2 seconds on warm starts. The L1 watcher catches state up from chain history regardless, so this isn't a correctness concern, but a peer cache would shave the startup window.

No multi-topic. All Vanta nodes are on one topic. We'll need at least mainnet/testnet split when there's a testnet to speak of; right now the topic is Vanta/L2/Gossip/v1 and that's literally the only topic that exists. TODO: Dax confirm we add Vanta/L2/Gossip/regtest when the regtest deploy lands.

What I changed my mind about

I'd been libp2p-curious for a long time. The crate is mature, it's used by IPFS and Polkadot, the docs are pretty good. I started the Vanta L2 with a libp2p prototype and it worked.

Two things made me switch.

The configuration burden is per-developer. Every new contributor who touches vanta-node would need to internalise the libp2p configuration matrix (or worse: would copy-paste it from somewhere and not understand what they were copying). iroh's presets::N0 is a single import. The cognitive load is bounded.

NAT traversal is solved-default. libp2p's NAT traversal is a la carte: configure DCUtR, configure STUN, configure relays. iroh's is built in. On a privacy chain whose users include anyone with a residential ISP, NAT traversal is not optional and the failure mode (peer can't be reached) cascades into "wallet stuck waiting for sync." Defaulting it on saved a class of bug I was tired of debugging.

The cost of the switch was about a week of integration work. I'd take that trade every time. iroh has bugs (the saturating-decrement story above is one of mine), but they're bugs at a scope I can hold in my head.

Further reading

• vanta/vanta-node/src/gossip.rs — the file this post walks
• doc/vanta-architecture.md — the rationale for picking iroh
• iroh.computer — the upstream project
• iroh-gossip on docs.rs — the crate API
• The vanta sidecar architecture — the daemon this gossip layer lives inside
• Cruiser: A Tauri Hookup App on iroh — how the same primitives ship in a different product