Relayerless privacy on a Turing-complete L1: an intro to F_RP

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.

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):

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:

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 →