Comparison
How Paraloom fits in the Solana privacy landscape, with a detailed comparison to Privacy Cash and a brief note on other options.
How Paraloom fits
Privacy on Solana is no longer empty space. Privacy Cash, Umbra, Mixoor, NOCtura, and others ship shielded transfers today. This page describes where Paraloom sits relative to them — what overlaps, what is structurally different, and what is honestly missing.
Privacy Cash vs Paraloom
Privacy Cash is the most-used Solana privacy product today: mainnet since August 2025, eighteen audits across Accretion, HashCloak, Kriko, Sherlock, Veridise, and Zigtur, and over $200M in processed volume. Their core code is open source. The on-chain program (programs/zkcash) is ~1,740 lines of Rust with a real on-chain Groth16 verifier — BN254, using Solana's alt_bn128_pairing precompile via Light Protocol's groth16-solana library.
The cryptographic primitives are the same family as Paraloom's: Poseidon commitments, append-only Merkle tree, nullifier replay protection, Groth16 zkSNARK. The differences sit at a different level — architecture, economics, scope.
| Dimension | Privacy Cash | Paraloom |
|---|---|---|
| Shape | On-chain program + relayer service | L2 network anchored on Solana |
| Settlement code | 1 Anchor program (~1,740 lines Rust) | 1 Anchor program + ~40K lines of L2 stack |
| Validator network | None — anyone may submit a valid proof; the team operates a relayer for convenience | Permissionless libp2p mesh with on-chain stake, slashing, reputation |
| Shielded transfers | Yes (mainnet) | Yes — 2-in/2-out, BFT-verified, encrypted note delivery (devnet, v0.5.0-rc4) |
| Off-chain compute | None | wasmtime sandbox with BFT verification (alpha) |
| Fee recipient | Single fee_recipient_account (team wallet) | Validator that led verification, via on-chain distribute_fee → claim_rewards |
| Pairing curve | BN254 | BLS12-381 today; BN254 migration is #165 |
| Proof verification | On-chain (Light Protocol groth16-solana) | L2 validator quorum (real Groth16 per validator, BFT 7-of-N gate); on-chain re-verifier ships with #165 (pending Solana SIMD-0388) |
| Multi-asset | SOL + multiple SPL tokens (USDC, USDT, ORE, ZEC, jlUSDC, jlWSOL) | SOL only |
| Cross-chain | Solana + Base (separate codebases per chain) | Chain-agnostic core; settlement layer is a pluggable module |
| Audits | 18 | None yet — pre-audit |
| Mainnet | Yes | No, v0.5.0-rc5 (pre-mainnet) |
Where they overlap
Both ship a UTXO-style shielded pool on Solana. A user deposits, receives a shielded note, can later withdraw to any address. Replay protection is enforced by nullifier PDAs on-chain. Both use Groth16 zkSNARKs over a pairing-friendly curve, both use Poseidon as the in-circuit hash. From a user-visible-operation perspective the basic flow looks the same.
Where they differ
Fee flow. Privacy Cash collects a 0.25% withdrawal fee and routes it to a single fee_recipient_account controlled by the team. The model is a private business operating a privacy product. Paraloom collects withdrawal fees on-chain and credits them to the ValidatorAccount.pending_rewards field of the validator that led the consensus path. Validators pull earnings out via claim_rewards. There is no founder-tier wallet receiving a cut.
Decentralization surface. Privacy Cash's transact instruction is permissionless — anyone may submit a valid proof, no admin signature required, so it is not centralized at the program level. The centralization is operational: the team runs the relayer that screens addresses (via CipherOwl) and abstracts fees. Paraloom is structured around a validator network: registered validators stake 1 SOL on-chain, run a libp2p node, verify proofs, and accept slashing for protocol violations. The validator-quorum daemon path is the security surface. That daemon path shipped in v0.5.0-rc4: deposit indexer (#163), consensus-to-submitter pipeline (#164), withdrawal-ingress HTTP endpoint and multi-node libp2p BFT consensus (#181, #184), and the shielded-transfer ingress + delivery path (#194, #196).
On-chain verification. Privacy Cash's transact calls Light Protocol's groth16-solana verifier inside the program. A malformed proof reverts on-chain. Paraloom's on-chain withdraw and shielded_transfer instructions record the proof blob and gate settlement on the bridge-authority signature; the real Groth16 verification happens on the L2 consensus path — each validator runs verify_withdrawal_parts / verify_transfer_parts (real Groth16ProofSystem::verify against the ceremony key) and a settlement only fires after a BFT quorum (7-of-N) votes the proof valid. A redundant on-chain re-verification requires migrating the circuit from BLS12-381 to BN254 — Solana's alt_bn128_pairing precompile is BN254-only — and is tracked in #165, pending Solana SIMD-0388 (~Q3'26).
Compute layer. Privacy Cash does shielded transfers and (since January 2026) private swaps via Jupiter. There is no general private-compute primitive. Paraloom ships an alpha private-compute layer: WASM jobs verified by the same BFT cohort that verifies withdrawals, with encrypted I/O and ownership-proof-bound output notes. This is a separate primitive from shielded transfers, not a re-skin.
Where Paraloom is honestly behind
- Audit coverage. Eighteen audits to zero. Privacy Cash has Sherlock, Veridise, Accretion, HashCloak, Kriko, Zigtur. Paraloom has none and is pre-audit.
- Mainnet volume. Privacy Cash has processed over $200M. Paraloom is on devnet only.
- Multi-asset. Privacy Cash supports a token whitelist. Paraloom is SOL-only at the on-chain program level today.
- Compliance plumbing. Privacy Cash routes through CipherOwl for sanctioned-address screening with selective-disclosure paths. Paraloom has no equivalent layer.
Where Paraloom is honestly different
- Validator-pays-fees economic model. The on-chain instructions (
register_validator,distribute_fee,claim_rewards,slash_validator) sit inprograms/paraloom/src/lib.rs, and the L2 auto-routing daemon (consensus-to-submitter pipeline) shipped in v0.5.0-rc4 (#164). - L2-scale stack. libp2p mesh, BFT consensus, coordinator HA, WASM compute, MPC trusted-setup tooling. None of these are part of Privacy Cash's design — they are different scope.
- Chain-agnostic core. Paraloom's privacy, compute, network, and consensus layers do not depend on Solana directly. The bridge module is the only chain-specific code path. Privacy Cash maintains separate codebases per chain (
privacy-cashfor Solana,privacy-cash-core-evmfor Base).
Other Solana privacy options
- Umbra — Arcium MPC backend, shielded pool, consumer wallet experience. Different cryptographic primitive (MPC rather than zkSNARK), different trust assumptions (MPC threshold vs validator quorum).
- Mixoor — zkSNARK-based unlinkable transfers, focused on retail user experience.
- NOCtura — Groth16/PLONK shielded transfers with an explicit compliance angle.
- Confidential Balances (Solana Token-22) — amount-only privacy; sender and receiver remain visible.
Paraloom does not aim to replace any of these. The structural choices — validator-run infrastructure, validator-pays-fees, programmable WASM compute, chain-agnostic settlement layer — describe a different product than a shielded-transfer service.
How to read this page
If you are evaluating Paraloom against an existing privacy product on Solana, the honest framing is: today, the leading product (Privacy Cash) ships on mainnet with eighteen audits and $200M+ volume; Paraloom is on devnet, pre-audit. The case for Paraloom is the structural design — open infrastructure rather than private service, validator economy rather than founder fee, programmable compute layer rather than transfer-only. As of v0.5.0-rc4 the validator daemon path is wired end-to-end on devnet (deposit indexer + BFT consensus + on-chain settlement + shielded transfers with encrypted note delivery). The remaining gates to mainnet are an external audit, the MPC trusted-setup ceremony run, and the on-chain Groth16 re-verifier (pending Solana SIMD-0388).