F_RP vs Zcash, Tornado, RAILGUN, Aztec, Penumbra, Aleo, Namada, Monero

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:

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 →