Summary: Shielded CSV is a lower-layer Bitcoin payment protocol, not another wallet app and not generic privacy marketing. The point is the split: transaction validity and history carriage move offchain between counterparties, while Bitcoin is reduced mostly to nullifier publication and ordering. That makes it a strong baseline for comparing zkCoins, RGB-style client-side validation, and other systems that push state and validation away from the chain.
What it does:
Specifies a private client-side-validation payment protocol in which users send coins together with validity proofs directly to recipients instead of asking the base chain to replay and validate every transaction
Writes only a 64-byte nullifier per transaction to the blockchain, shrinking the chain’s role toward double-spend prevention and ordering rather than full semantic transaction execution
Uses proof-carrying data so a receiver verifies a constant-size proof of valid ancestry rather than a proof that grows with transaction history
Separates roles between sender, receiver, and publisher, where publishers aggregate and post nullifier-related data while receivers validate proofs offchain
Defines the protocol around sign-to-contract Schnorr signatures, nullifier accumulation, and NISSHAC-style half-aggregation rather than ordinary Bitcoin transaction publication
Proposes practical implementation paths using Folding Schemes and Recursive STARKs, plus extensions such as shared accounts, time-locked transactions, atomic swaps, and multi-asset support
Key claims:
Shielded CSV clears the bar because it is the protocol layer beneath wallet implementations like zkCoins. Without this entry, it is too easy to treat the design as only a product feature or implementation experiment rather than a reusable payment architecture.
The paper’s strongest analytical contribution is how aggressively it compresses Bitcoin’s onchain role. Only nullifier data must be published, while transaction validity, history interpretation, and proof handoff move to users and counterparties.
The proof-carrying-data framing matters because it changes what client-side validation means in practice. Older CSV-style systems often make proof burden grow with history; Shielded CSV is explicit that receiver proof size and verification cost should remain independent of that history.
The sender / publisher / receiver split is the other reason this note matters. Publishers become a distinct operational role with aggregation, posting, and fee-handling responsibilities, which makes the control plane much easier to inspect than in generic Bitcoin privacy writeups.
The paper also keeps several lower-layer mechanisms visible instead of flattening them together: sign-to-contract binding, aggregate nullifiers, conditional NAV for reorg handling, and trustless publisher-fee flow. Those details decide whether CSV stays a protocol primitive or quietly recentralizes around operators.
Shielded CSV belongs under references because it is the paper-level baseline needed to evaluate later implementations and productizations. It sharpens comparison against zkCoins in particular by separating the full design from what a current deployable stack has and has not implemented yet.
Whitepaper: The canonical whitepaper is the ePrint paper Shielded CSV: Private and Efficient Client-Side Validation (2025/068). Supporting primary-source notes are collected in ../../whitepapers/shielded-csv-primary-sources-2026-05-13.md.