Skip to content
VOUCHVOUCHDocs

Getting started

Introduction

Vouch is the disclosure layer for shielded Zcash. Instead of handing over a viewing key, a holder proves one fact about their coins, to one party, and reveals nothing else. Anyone can check the proof against the public chain, in about a tenth of a second.

On this page

#The problem

Shielded ZEC is private until it has to leave. At a swap rail, an exchange or an OTC desk, screeners cannot score shielded coins: there is no address history to look at. A large shielded deposit therefore lands as “unknown”, and unknown deposits get held.

Today the only thing a holder can offer to get one released is a viewing key. A viewing key shows every note, amount and memo the wallet has ever received, and everything it will receive, to whoever holds the key, for ever. It cannot be scoped and it cannot be revoked. It is the opposite of what a shielded pool is for.

Lenders and treasuries have the same problem from the other side. A lender cannot see collateral it cannot verify; a treasury holding shielded ZEC cannot show its users the reserves without showing them the wallet.

#What Vouch does

Vouch replaces the viewing key with a single-purpose proof: a file of about 12 KB that states exactly one fact, for exactly one verifier, until one date, and that can be revoked. The proof is a zero-knowledge proof over the chain’s own data, so the verifier needs nothing from the holder but the file, and nothing from anyone else but public chain data.

System overview: chain data, the holder, verifiers and SolanaZcash networkZcash chainIronwood poollightwalletdcompact blocksAnchor publisher · anyone can run itpof-anchorrebuilds the note treeand the nullifier IMT.vsnp snapshotevery commitmentand nullifierAnchor tableheight · nc_root · nf_root/api/anchorsrootsHolder's machineWallet seedread locallypof-provefinds notes,proves, signs.pof≈ 11.9 KBpublic dataAnyone can verifyBrowserpof-wasmpof-verifyCLIAttestorpof-attest.poftrusted rootsRelying partiesRail · exchange · deskchecks an exit certificate,matches the depositLender · counterpartyreads proof of funds,sees reuse in its periodValid · or why notSolanapof-gatereceiptspof-creditcredit linespof-reservereserves feedEd25519 verdict
Public chain data becomes trusted roots; the holder proves against them on their own machine; anyone verifies the .pof file; an attestor carries the verdict to Solana.

Nothing is bridged. The coins never leave Zcash and are never locked; only a proof moves. Where the party that needs the fact is a Solana program, which cannot verify a Zcash proof itself, an attestor runs the same open-source verifier and signs its verdict, and the program checks that signature.

#Three products, one engine

ProductThe fact provenWho checks itStatus
Exit certificates“At least X ZEC, in notes already in the chain at block H and unmoved since, and these are the notes I am sending you.”A swap rail, exchange or desk, before it releases a depositReal on testnet
Proof of funds“At least X ZEC”, to one named verifier, until one expiry, revocable; reuse of the same coins with that verifier in one period is visible to it.A lender, an OTC desk, a Solana programReal on testnet; devnet credit flow
ReservesSeveral proofs summed with no note counted twice, published as a Solana feed that a token can only mint within.A treasury’s users, a wrapped-ZEC issuerDemo ledger; devnet feed

All three are the same proof with different options. An exit certificate is a proof that also reveals which notes it covers, so the rail can match the deposit. A reserves batch is several proofs in one file. Proof of funds is the plain case.

#Why this only works on Zcash

  • The note-commitment tree is a clock. It only grows, so “this note was a leaf at block H” is a permanent, public fact about the past.
  • The nullifier set is a “not moved” proof. A note can only be spent by revealing its nullifier, so “its nullifier is not in the set at block H₁” means it has not moved.
  • Spend authority can be shown without spending. The proof is signed by the key that controls the notes; a viewing key alone cannot make one.
  • The circuit already exists. Vouch uses the Ironwood delegation circuit from Valar Group’s voting-circuits, the one the community used for the NU7 poll, with one added constraint.

Unlike association-set schemes, no provider decides which coins are acceptable: the chain’s own history is the allow-list, and the verifier picks the block.

#At a glance

Proof size11.9 KBone .pof file
Verify in a browser~93 msWASM, after warm-up
Notes per proofup to 5more: a batch
Trusted setupnoneHalo2 over Pasta

#Where to start

#What is real today

  • A real proof from a real Zcash testnet wallet: at least 1 TAZ at block 4,410,000. Check it on /verify.
  • A real testnet proof that 1 TAZ has been unmoved since block 4,410,000, as of 4,459,000, and a younger note refused.
  • A real testnet exit certificate matched against a real deposit (ff0a2488…) that spends exactly the certified notes. The first attempt, which had dummy spends, is kept as a documented mismatch.
  • Reserves batches: 4,018.125 ZEC across three proofs on the demo ledger, and a double-counted note refused.
  • pof-gate, pof-credit and pof-reserve deployed on Solana devnet, driven end to end from /demo and /reserves.
  • One Rust verifier, compiled natively and to WASM, agreeing on every test vector in CI; 26 LiteSVM tests of the programs, including the attacks.

A hackathon build

Not audited: not the circuit changes, not the programs, not the attestor. Testnet only. Read Where trust still sits and Threat model before relying on anything here.