Private payments on Bitcoin nothing legible on-chain
zkCoins brings true privacy to Bitcoin. Amounts, sender, receiver and history stay off-chain — proven with zero-knowledge, while each transfer publishes only a ~64-byte nullifier to Bitcoin.
No soft forkSelf-custodialZero-knowledgeNo coordinator
Coin data never touches the chain. Each transfer publishes a ~64-byte nullifier to Bitcoin — about 16 vBytes, versus ~140 for a regular transfer — constant no matter how many coins it moves.
"Use the chain for what the chain is good for — an immutable ordering of commitments to prevent double-spending."
— Robin Linus, co-author of Shielded CSV
Whitepaper · ePrint 2025/068
Shielded CSV: Private and Efficient Client-Side Validation
A privacy-preserving variant of Client-Side Validation, settled directly on Bitcoin.
Authors
Jonas Nick (Blockstream) · Liam Eagen (Alpen Labs) · Robin Linus (ZeroSync)
Published
January 2025 (ePrint) · September 2024 (whitepaper)
Client-Side Validation decouples transaction validation from Bitcoin consensus by moving it to the recipient. Shielded CSV improves on prior CSV designs by hiding the transaction history entirely: each transfer leaks only a 64-byte nullifier to the chain, with the rest verified client-side via succinct zero-knowledge proofs. The protocol is compatible with Bitcoin as-is — no soft fork, no hard fork — and targets roughly an order of magnitude more transactions per second than the base layer alone.
zkCoins v1 implements the paper's model faithfully: each transfer publishes its ~64-byte nullifier directly to Bitcoin as a half-aggregated signature, so the chain itself guarantees every nullifier a verifier needs for its double-spend checks — no off-chain batch data, no data-availability assumption. About 16 vBytes on-chain per transfer, on the order of ~100 transactions per second.
Coin data stays off-chain. Each transfer publishes only a ~64-byte nullifier to Bitcoin, proven with zero-knowledge — so privacy and a small on-chain footprint win at once.
On-chain footprint
A nullifier per transfer
Coin data never touches the chain. Each transfer publishes a ~64-byte nullifier to Bitcoin — nothing legible about amounts or parties.
Transaction graph
Nothing linkable
Unlike RGB or Taproot Assets, history stays hidden under a zero-knowledge proof. Recipients verify validity without ever seeing the lineage.
Compatibility
Bitcoin, unchanged
No soft fork, no hard fork. CSV protocols use the chain only for ordering and double-spend prevention.
Cost
A fraction of a Bitcoin transfer
Each transfer costs about 16 vBytes on-chain — a fraction of a ~140-vByte Bitcoin transfer, roughly an order of magnitude smaller — constant no matter how many coins it moves.
How it works
The chain orders, the recipient validates
Traditional blockchains ask every node to validate every transaction. Shielded CSV inverts that — validation moves to the recipient, and Bitcoin does only what it is uniquely good at.
1
Sender proves
The sender creates a transfer and generates a succinct validity proof of the coin's entire history — a constant size, no matter how old the coin is.
2
Proof goes to the receiver
The proof travels directly to the receiver, off-chain. Only sender and receiver ever see the amounts, parties and history — no amounts or parties are written to the chain.
3
The nullifier is published to Bitcoin
The transfer's ~64-byte nullifier is published to Bitcoin as a half-aggregated signature. Publishing is permissionless — any wallet can self-publish — and the chain itself holds every nullifier a verifier needs.
4
Receiver verifies client-side
The receiver re-verifies the coin's full zero-knowledge proof locally — a single constant-time check, no matter how long the coin's history — and accepts it without trusting any third party.
5
Bitcoin prevents double-spends
Bitcoin records each nullifier in canonical order, and the first on-chain occurrence of a coin's state key selects its one valid transition. The chain's one job: guarantee each coin is spent exactly once — with no off-chain data required.
By the numbers
Bitcoin, next to Shielded CSV
Metric
Bitcoin (regular)
zkCoins v1
On-chain data
full transaction (~140 vBytes)
~64-byte nullifier per transfer
Per-transfer cost
~140 vBytes
~16 vBytes per transfer
Privacy
None — fully public
Full — nothing legible on-chain
Verification
Full script per tx
1× transfer proof
Proof size
N/A
Constant, independent of history
Boundaries
What Shielded CSV is not
Privacy here is structural, not a bolt-on. It is worth being precise about what this protocol deliberately is not.
Not a sidechain
It uses Bitcoin L1 directly — no separate consensus, no bridge to a foreign chain.
Not a rollup
No sequencer, no data-availability layer — the nullifiers live on Bitcoin itself. Validity proofs move peer-to-peer between sender and receiver; each transfer's ~64-byte nullifier anchors to Bitcoin L1.
Not a mixer
Privacy is structural, not obfuscation — a global anonymity set of every coin, not a small per-round pool.
Not a token
No native protocol token to bootstrap. Value lives in client-side-validated coins.
Not a soft fork
It works on Bitcoin as it exists today — no consensus change, no new opcodes.
Roadmap
The path to mainnet
ActiveNextPlannedHorizon
Phase 01
Foundation
Q2 2026Active
The proving stack and the wallet–server boundary. Everything downstream depends on this.
Zero-knowledge circuit migration.Move the state-transition circuit onto a recursion-native proving system with a SNARK-friendly hash.
Server-side proving on commodity hardware.Single-host Apple Silicon target — no GPU farms, no cloud proving service. The wallet holds only the private key.
Wallet boundary via BIP-340 Schnorr.The wallet signs a SHA-256 digest of the server-computed state. No in-browser zero-knowledge.
End-to-end roundtrip on signet.Create account, mint, send, receive — the full user loop runs on a public Bitcoin testnet.
Phase 02
Pre-mainnet hardening
Q3 2026Next
Close the protocol gaps between "works on signet" and "safe with real Bitcoin".
Hiding recipient commitments.Eliminate the residual link between sender, recipient and coin identifier.
Reorg-safe nullifier accumulation.Gracefully degrade when the canonical chain reorganises rather than getting stuck.
Per-coin freshness proofs.Recipients verify a coin's age locally without trusting any third party.
Paper-derived security test suite.The full set of formal properties from the Shielded CSV paper, encoded as failing-witness tests.
Phase 03
Trustless BTC bridge
Q4 2026Planned
Mint and burn against native BTC without trusting the issuer. The biggest user-facing trust gap closes here.
BitVM2 / Clementine-style bridge.1-of-N honesty trust model. The same construction running on Citrea mainnet.
Recursive Bitcoin light client.A succinct proof that a deposit landed at depth ≥ 6 in the canonical chain.
Recursion → Groth16 wrapping.Bridge our recursion-friendly proofs into a verifier that Bitcoin script can check.
Federation scaling: N=3 → N=100.Start with a single-operator federation; grow to one hundred independent members, where one honest key deletion is enough.
Signet integration run.Full peg-in / peg-out roundtrip including a deliberately malicious operator scenario.
Phase 04
Lightning atomic swap
Q1 2027Planned
Move value between Lightning and zkCoins atomically — no provider trust, no custodial bridge.
HTLC on the nullifier funding transaction.Atomicity lives on Bitcoin layer 1, not on the private coin layer. Standard primitives, no soft fork.
Symmetric LN ↔ zkCoins flows.Buy with Lightning sats and sell back to Lightning sats, both directions trustless.
Provider-fronted liquidity.Anyone can run a swap provider; the protocol enforces honesty, not the operator.
Privacy-preserving swap pattern.A swap provider learns the LN side, never the zkCoins-internal graph.
Phase 05
Long-term positioning
2027 +Horizon
Replace the bridge technologies of today with the bridge technologies of tomorrow — without changing the protocol.
Next-generation proving system.Port to a smaller field with a faster hash once the upstream stack stabilises. Algorithmic structure stays.
Bridge construction upgrade.Drop-in successors to BitVM2 (Glock, Mosaic) cut on-chain dispute cost by two orders of magnitude. Circuit contract unchanged.
Federation diversity.Recruit independent organisations as federation members until one-honest-deletion is a meaningful assumption.
Bridge-verifier trusted setup.A 30–60 contributor ceremony replaces the single-contributor Groth16 parameter set used to test the bridge verifier — zkCoins' own proofs are transparent (FRI) and need no setup.
Note. Dates indicate target windows for the engineering work, not a guaranteed mainnet date. zkCoins runs in a public test environment until pre-mainnet hardening completes; no real Bitcoin is at risk before then.
zkCoins brings Shielded CSV to a self-custodial wallet — private Bitcoin on L1, no soft fork. We keep an open line for venture funds, family offices and strategic angels evaluating the project.
The protocol is built on published research (ePrint 2025/068), the stack is open source, and the roadmap is public. We are not actively raising — but we are open to conversations ahead of mainnet.
zkCoins is a self-custodial wallet for Shielded CSV, a privacy protocol for Bitcoin. Amounts, sender, receiver and transaction history stay off-chain, proven with zero-knowledge and verified client-side. Each transfer publishes only a ~64-byte nullifier to Bitcoin.
Is zkCoins a new token or altcoin?
No — zkCoins is not a separate blockchain, altcoin, or native protocol token. It is a client-side-validation layer anchored to Bitcoin L1; value lives in client-side-validated coins. Moving on-chain BTC in and out uses a bridge, which is on the roadmap.
Does zkCoins require a soft fork?
No. Shielded CSV works on Bitcoin as it exists today — no soft fork, no hard fork, no new opcodes. The chain is used only for ordering commitments and preventing double-spends.
How does zkCoins keep transactions private?
Each spend is proven with a zero-knowledge proof and shared off-chain. Coin data — amounts, parties and history — never touches Bitcoin; only a ~64-byte nullifier per transfer is published to the chain.
Is zkCoins self-custodial?
Yes. Keys are generated and stored locally in your browser and never leave your device. zkCoins is peer-to-peer with no coordinator or custodian that can freeze funds or shut the network down.
What is Shielded CSV?
Shielded CSV (Client-Side Validation) is a privacy-preserving Bitcoin protocol from the paper by Jonas Nick, Liam Eagen and Robin Linus (ePrint 2025/068). zkCoins v1 implements it faithfully: each transfer publishes a ~64-byte nullifier to Bitcoin, everything else verified client-side.
Is the publisher role actually decentralized?
Publishing is permissionless, and any wallet can self-publish its own transfers to Bitcoin at trivial cost — that caps what a dominant publisher can charge. Competitive economics do favor the fastest, best-capitalised operator, so some concentration is expected. It's a liveness risk only: a publisher never holds custody and can at most censor or delay a transfer, never steal or forge coins. Full breakdown on the docs' Risks page.
Where do the nullifiers live?
On Bitcoin. Each transfer publishes its ~64-byte nullifier directly to the chain as a half-aggregated signature, so Bitcoin itself guarantees the availability of every nullifier a verifier needs to check for double-spends — no off-chain batch data and no separate data-availability layer to trust. The coin data — amounts, parties and history — still stays off-chain, proven with zero-knowledge, and is never needed to reconstruct the public double-spend view.
Try private Bitcoin today
The zkCoins wallet runs in your browser. Keys are generated and stored locally — they never leave your device. Currently on a public test network; no real Bitcoin is at risk.