Comparisons
How does zkCoins compare to other privacy and scaling approaches — and what, precisely, makes it different?
Where zkCoins sits
zkCoins is an implementation of two whitepapers:
- the Shielded CSV construction by Jonas Nick (Blockstream), Liam Eagen (Alpen Labs), and Robin Linus (ZeroSync) — eprint 2025/068;
- the original zkCoins concept, prototyped as ZeroSync/ZKCoins.
The project at zkcoins.app does not compete with these papers — it realizes them, with every load-bearing deviation registered in the Paper-Deviation Analysis. It claims no invention of the underlying scheme; its contribution is bringing the design to a running node, wallet, and the off-chain transport/recovery layer needed to operate it. Where this page says "zkCoins", read "the Shielded CSV scheme as realized by zkCoins v1, registered deviations included".
The differentiator is a combination, not a single property
Privacy alone is not new. Decentralization alone is not new. Even privacy + decentralization together is not new — Monero and Zcash have shipped both for years. What is rare is a specific triple:
- Bitcoin-anchored — settles on Bitcoin L1, with no own chain, token, or consensus to bootstrap. It inherits Bitcoin's decentralization instead of building a new one.
- Shielded — a real anonymity set with ZK unlinkability, not merely "data kept off the public chain".
- Trustless — correctness enforced by cryptography and Bitcoin, with no trusted operator, mint, or federation.
Almost every related protocol nails two of the three and misses the third:
| Protocol(s) | Bitcoin-anchored | Shielded (anon-set) | Trustless | Misses |
|---|---|---|---|---|
| Monero, Zcash, Penumbra, Namada, Firo, Iron Fish | ✗ own chain | ✓ | ✓ | not Bitcoin — own security budget/token |
| RGB, Taproot Assets | ✓ | ✗ counterparty sees full provenance | ✓ | no anonymity set |
| Cashu, Fedimint | ✓ | ✓ (blinded) | ✗ custodial / federated | not trustless |
| Railgun, Aztec, Tornado Cash | ✗ Ethereum, on-chain data | ✓ | ~ | not Bitcoin, on-chain data |
| Liquid, Statechains / Mercury | ✓ | ~ / ✗ | ✗ federation | federated |
| Shade | ✗ Secret Network | ✓ (via TEE) | ~ | privacy via trusted hardware, not ZK |
| zkCoins (Shielded CSV) | ✓ | ✓ | ✓ | — |
The trustless corner is fully specified: every node rebuilds the public nullifier accumulator from Bitcoin alone, while each private CoinProof remains content-addressed, independently verifiable, and retained under the store-everything invariant plus the §4.3 recovery-discoverable overlap for recovery (spec §3.6–§3.7, §4.5–§4.6).
Footprint figures in the tables below quote the normative spec design — a ~64-byte half-aggregated nullifier per transition (~16 vB), constant in the transition's input count (spec §3.8).
Deep dives
vs. RGB
Both use Client-Side Validation on Bitcoin, but serve different purposes.
| zkCoins (Shielded CSV) | RGB | |
|---|---|---|
| Focus | Private payments | Smart contracts + tokens |
| Privacy | Full against the public-chain observer (global anonymity set); bounded counterparty residuals (D-17–D-19, Risks) | Limited (history revealed to counterparty) |
| Proof size | Constant (independent of history) | Grows with transaction history |
| On-chain footprint | ~64-byte half-aggregated nullifier per transition (~16 vB), constant in input count (spec §3.8) | Commitment in a host TX; off-chain consignment grows |
| Smart contracts | No | Yes (zk-AluVM, Turing-complete) |
| DeFi/Lending | Not yet | Possible (bilateral) |
zkCoins for the payment layer (privacy + scalability), RGB for programmable logic (lending, tokens). Both use Client-Side Validation on Bitcoin L1.
vs. Taproot Assets
The closest "assets on Bitcoin via CSV" cousin, from Lightning Labs.
| zkCoins (Shielded CSV) | Taproot Assets | |
|---|---|---|
| Validation | Client-Side Validation + ZK | Client-Side Validation (Merkle proofs) |
| Privacy | Full shield (anonymity set) | Transparent — proofs reveal asset, amount, lineage to the counterparty |
| Data availability | Private CoinProof off-chain (store-everything + §4.3 recovery-discoverable overlap, no fixed replica count); public nullifiers on Bitcoin | Universe servers (off-chain proof archives) |
| Anchor | Bitcoin Taproot | Bitcoin Taproot |
Taproot Assets shares the Bitcoin anchor and the off-chain-data model, but has no shielding — it is the "Bitcoin + decentralized, but not private" corner of the triangle.
vs. Lightning Network
| zkCoins (Shielded CSV) | Lightning | |
|---|---|---|
| Layer | L1 (Client-Side Validation) | L2 (payment channels) |
| Privacy | Full (ZK proofs) | Good (onion routing) |
| Interactivity | Receiver must be reachable | Routing path required |
| Capacity | Bounded by Bitcoin L1 (one ~64-byte nullifier per transition, ~16 vB) | Theoretically unlimited |
| Offline receive | No | No |
Lightning and Shielded CSV are complementary; CSV assets could theoretically flow through Lightning channels.
vs. Zcash
| zkCoins (Shielded CSV) | Zcash | |
|---|---|---|
| Blockchain | Bitcoin (existing) | Own chain |
| Consensus change | None needed | Own consensus |
| Privacy model | Mandatory for CSV users | Optional (~10-20% usage) |
| ZK system | Plonky2 (cyclic recursion, FRI) | Halo2 |
| Trusted setup | None | Eliminated since NU5 |
| On-chain footprint | ~64-byte half-aggregated nullifier per transition (~16 vB) | Full transaction |
Zcash is the conceptual parent of the commitment/nullifier shield. The key divergence: Zcash secures its own chain; zkCoins inherits Bitcoin's.
vs. Monero
| zkCoins (Shielded CSV) | Monero | |
|---|---|---|
| Blockchain | Bitcoin | Own chain |
| Privacy approach | ZK proofs | Ring signatures + Stealth + RingCT |
| Anonymity set | All coins ever created | Ring of 16 decoys |
| Scalability | ~64 B per transition on-chain (~16 vB), constant in input count | ~2-3 KB per TX |
| Statistical attacks | Decoy-selection analysis: not applicable (no decoys, full anonymity set); per-block transition count and inscription timing remain publicly visible (Risks) | Possible (decoy-selection analysis) |
vs. CoinJoin
| zkCoins (Shielded CSV) | CoinJoin (Wasabi/JoinMarket) | |
|---|---|---|
| Anonymity set | All coins | Round participants only |
| Amounts hidden | Yes | No (equal-output) |
| Coordinator | None | Required |
| On-chain analysis | Amount/decoy-based analysis not possible (no decoys, all amounts hidden); per-transition count, inscription timing, and (toward a repeatedly reused publisher) the pre-anchor Pkᵢ of each hand-off remain visible (Risks) | Difficult but not impossible |
| Cost | One ~64-byte nullifier per transition (~16 vB) | Multiple UTXOs (expensive) |
| Regulatory risk | Low (no coordinator) | High (coordinators prosecuted) |
vs. Silent Payments (BIP352)
| zkCoins (Shielded CSV) | Silent Payments | |
|---|---|---|
| Goal | Full transaction privacy | Receive-only privacy |
| Amounts hidden | Yes | No |
| Transaction graph hidden | Yes | No |
| Complexity | High | Moderate |
Silent Payments solve a different problem (reusable addresses) and could serve as a receive mechanism for Shielded CSV in the future.
The wider landscape
The protocols below all rhyme with zkCoins on at least one axis. They are grouped by how they relate, with the one difference that matters most for each.
Client-Side Validation on Bitcoin (the closest family)
Off-chain data, on-chain commitment, validation by the client.
| Protocol | What it is | Key difference from zkCoins |
|---|---|---|
| Shielded CSV | The construction zkCoins implements | — (the basis, not a competitor) |
| RGB | CSV smart contracts + tokens on Bitcoin | No anonymity set; counterparty sees full provenance |
| Taproot Assets (repo) | Assets in a Taproot tree, universe servers | Transparent — no shielding |
| Single-use seals (Peter Todd) | The primitive RGB / TA build on | A building block, not a payment system |
Shielded ZK value transfer (on their own chains)
Private and decentralized — but each runs its own chain, token, and security budget.
| Protocol | What it is | Key difference from zkCoins |
|---|---|---|
| Zcash | Shielded pool, note commitments + nullifiers | Own chain (the model zkCoins borrows, on Bitcoin) |
| Monero | Ring signatures + RingCT + stealth addresses | Own chain; decoy-ring privacy, not a ZK anonymity set |
| Penumbra | Shielded Cosmos zone (private DEX/staking) | Own PoS chain |
| Namada | Multi-asset shielded pool (MASP), Cosmos | Own PoS chain |
| Iron Fish | Account-based shielded L1 | Own chain |
| Firo | Lelantus Spark, one-time addresses | Own chain |
| Zano | Confidential L1 with auditable wallets | Own chain |
| Aleo | Private-by-default L1, ZK execution (snarkVM) | Own chain; general computation |
Privacy on smart-contract chains
Shielded, but on Ethereum-class chains with on-chain data.
| Protocol | What it is | Key difference from zkCoins |
|---|---|---|
| Railgun (repo) | Shielded pool as an EVM smart contract | Ethereum; on-chain data; depends on that chain |
| Aztec | ZK privacy L2, private contracts (Noir) | Ethereum L2; not Bitcoin |
| Tornado Cash | Fixed-denomination mixer (commitment/nullifier) | Ethereum; mixer, not a payment system; sanctioned |
Client-data / stateless ZK rollups
Mechanically the nearest non-Bitcoin relatives: the client holds the data, the chain holds a commitment.
| Protocol | What it is | Key difference from zkCoins |
|---|---|---|
| Intmax / Intmax2 | Stateless ZK-rollup, client-held data, minimal on-chain footprint | Ethereum-anchored; privacy is not the primary goal |
| Plasma (historical) | Off-chain state + on-chain commitments + fraud proofs | Fraud-proof model, not ZK; largely superseded |
Bitcoin asset overlays (on-chain data, no privacy)
The historical "issue assets on Bitcoin" lineage. Data is on-chain and transparent.
| Protocol | What it is | Key difference from zkCoins |
|---|---|---|
| Omni Layer (ex-Mastercoin) | OP_RETURN asset metadata; carried early USDT | On-chain data, no privacy, no CSV |
| Counterparty (XCP) | Assets + DEX encoded in Bitcoin transactions | On-chain, transparent |
| Colored Coins / Open Assets | Tag specific satoshis as assets | Earliest, fully transparent |
| Ordinals / Runes / BRC-20 | Inscriptions and Runes for issuance | On-chain data, no privacy |
Off-chain Bitcoin value / Chaumian ecash
Off-chain value with a Bitcoin peg; privacy via blind signatures rather than ZK.
| Protocol | What it is | Key difference from zkCoins |
|---|---|---|
| Cashu | Chaumian ecash (blinded bearer tokens) | Custodial — the mint holds the funds |
| Fedimint | Federated Chaumian ecash | Federated custody (threshold of guardians) |
| Ark | Off-chain Bitcoin via shared VTXOs | Not asset/privacy focused; liquidity-provider dependent |
| Statechains / Mercury | Off-chain transfer of UTXO ownership | Relies on a federation/entity; weak privacy |
Confidential, but a different trust model
| Protocol | What it is | Key difference from zkCoins |
|---|---|---|
| Liquid | Confidential Transactions sidechain | Federated (functionaries), not trustless |
| MimbleWimble (Grin / Beam) | CT + cut-through, no persistent addresses | Own chain; CoinJoin-style privacy, no anonymity set |
| Shade (repo) | Privacy DeFi on Secret Network | Privacy via TEE/SGX (trusted hardware), not ZK/CSV |
Bitcoin privacy landscape (2025/2026)
| Technology | Privacy level | Status |
|---|---|---|
| Shielded CSV | Full against the public-chain observer; bounded counterparty residuals (D-17–D-19) | |
| Silent Payments (BIP352) | Receive-only | Near production |
| PayJoin (BIP77/78) | Send-privacy | Production |
| CoinJoin | Medium (statistical) | Under regulatory pressure |
| Lightning (BOLT12) | Good (routing) | Production |
Shielded CSV is the most ambitious privacy solution for Bitcoin. Silent Payments are the pragmatic short-term choice; Shielded CSV is the long game on the Bitcoin · Shield · Trustless triangle.