What's in vanta/papers — reading 17 design docs in 2026

A privacy chain in 2026 cannot ship as a one-page marketing site with a PDF link. The serious audience — auditors, exchanges, regulators, other engineers — needs to read the design without filling out a form. So Vanta’s whitepaper isn’t a PDF on a website. It’s a directory: papers/ in the main repo, 17 markdown files, MIT-licensed, version-controlled, diffable.

This post is a tour. One paragraph per doc, plus the planning notes that aren’t in papers/ but are in planning/. At the end I call out the wording bug the audit flagged but I haven’t fixed yet.

Why design docs in the repo

Three reasons.

Diffability. A change to the chain rules is a commit. The doc that explains the rule change is also a commit. Over time the doc diff and the code diff are in the same git history, so you can check whether the prose ever lagged the code.

No marketing intermediary. A PDF on a website goes through whoever owns the website. A markdown file in the repo is the artefact; nobody can mis-summarize it without me noticing. This matters more than I expected when the audience for the docs is “people who will run nodes” rather than “people who will buy the token.”

They’re the input to the LLMs that read the codebase. Increasingly, technical evaluation in 2026 is mediated by AI assistants reading the repo. Markdown in the repo is what those tools index. PDF on a website is not. TODO: Dax confirm this is still our framing once the docs/ ship has matured.

The 17 papers

00-master.md — index of everything else. If you only read one, this is the one to not read; jump to 01.

01-executive-summary.md — the headline pitch in long form. The opening line is the design: “Vanta Protocol is the first sovereign Layer 1 blockchain where financial privacy is enforced by consensus on every non-coinbase transaction.” The interesting bits: the explicit refusal of Zcash-style optional shielding, the rule name bad-vanta-v2-output-nonzero-value that fires on any v2 output with non-zero nValue, the “fast privacy decay” coinbase pattern (one confirmation transparent, private after).

02-technical-whitepaper.md — the deep dive. Witness v2 layout, the VantaJournal struct, the value_balance semantics (>0 burns hidden value to L1, <0 mints it from L1, =0 is a pure shielded transfer). The arithmetic of the consensus rule. This is the paper an auditor reads.

03-comparative-technical-analysis.md — Vanta vs Zcash, vs Monero, vs Penumbra, vs CoinJoin-on-Bitcoin. Honest about where each peer is ahead and where each is behind. Calls out that Penumbra is on the wrong chain base (Cosmos SDK + Tendermint BFT) for our specific bet on PoW.

04-market-analysis.md — TAM and competitive positioning. Not technical, but useful for understanding the framing. TODO: Dax confirm the market sizing before I quote it elsewhere.

05-layer-taxonomy.md — the taxonomy of L1 / L2 / sidechain / app-layer privacy and where Vanta sits. Most useful for readers who have already absorbed Penumbra, Zcash, Tornado Cash, and want to triangulate.

06-pitch-deck.md — the slides version. Repeats the executive summary at lower resolution.

07-business-plan.md — operations, deployment, infra. Mostly internal but in the open repo because there’s nothing actually private in a fair-launch chain’s business plan.

08-tokenomics.md — the supply schedule, halvings, fair launch. The numbers are the ones in the original L1 post: 100k VANTA per block, 42B total supply, 210k-block halving (~146 days). Zero premine, zero founders allocation. TODO: Dax confirm we’re not making any forward statements about $VANTA price or fundraising; I have not read these tokenomics with that lens and I won’t quote any forward-looking number.

09-performance-analysis.md — block-time, propagation, proof-time benchmarks. Prover takes 30–60s on CPU, verifier ~30ms. Block validation overhead is the verifier cost amortised across block transactions. Acceptable for 1-minute blocks.

10-novelty-analysis.md — what’s new vs prior art. The honest version: very little is new at the primitive level (Pedersen commitments, nullifiers, SMTs, all known); the synthesis (mandatory privacy + Bitcoin Core fork + SP1 backend + AuxPoW path) is the contribution.

11-paradigm-research.md — the broader research positioning. Reads as a literature review. Useful if you want to know where the design borrows ideas from (Zcash, Penumbra, Aleo) and where it deliberately diverges.

12-academic-paper.md — the conference-paper version. Same content as 02, formatted to academic conventions. The version we’d submit to a privacy-coin venue if we were doing that.

13-security-model.md — what the chain protects against, what it doesn’t. The “what it doesn’t” list is the important part: targeted timing attacks on a single transaction, side-channel leakage through wallet behaviour, an adversary with control of the proof-network if the user uses one. Read this before you build on top.

14-public-roadmap.md — what’s shipped, what’s coming. Phase 1/2 complete, Phase 3 in progress (L2 privacy layer with iroh gossip), Phase 4 future (full Rust node rewrite). The dates are deliberate ranges, not commitments.

15-regulatory-framework.md — how the chain reads to a regulator. TODO: Dax confirm before I quote any specific position; I am not a lawyer and the regulatory narrative belongs to the legal review, not to me writing a blog post.

16-use-cases.md — what people will actually do with the chain. Treasury operations, individual savings, atomic-swap liquidity. Honest about which use cases need more than mandatory privacy (e.g. payroll, where the recipient set has to be opaque too — that’s a wallet UX problem, not a chain problem).

17-zkvm-engineering.md — the deep dive on SP1, Plonky3, why we picked them, the abstraction layer that makes zkVMs swappable. I cited this paper extensively in Why we shipped SP1 instead of RISC Zero. It’s the most useful paper for an engineer evaluating Vanta against another zkVM-based chain.

The planning notes

planning/ is not in papers/. It’s the loose work-in-progress notes I’m not ready to call canonical. Today there’s one file: price-discovery-for-private-swaps.md.

That doc is worth a separate post, which I wrote: Private atomic swaps and the price-discovery problem. The short version: if either side of an atomic swap is shielded, the rate btc_amount / vanta_amount is hidden from observers, which means no public price tape, which means no spot market formation. The doc walks through six options for how price could emerge without compromising the privacy property — voluntary post-trade rate publication, ZK-attested rate proofs, off-chain encrypted order books — and lands on a hybrid recommendation.

I’m holding it in planning/ rather than papers/ because it’s a design exploration, not a commitment. The status line at the top says exactly that: “Status: Design exploration, not a commitment. Written 2026-04-17.”

The wording bug I haven’t fixed

The repo’s CLAUDE.md flags an inconsistency I’m aware of:

Phase 2 papers wording is “code complete, activation pending” but code shows ALWAYS_ACTIVE from genesis — wording bug in papers/01-executive-summary.md to fix.

The executive summary in 01-executive-summary.md describes some of the privacy rules as “code complete, activation pending.” The actual chain has those rules ALWAYS_ACTIVE from genesis — they’re enforced from block 1, not gated behind a future activation. The doc lags the code.

This is the kind of thing that only happens when you’re rewriting both fast. The fix is a five-minute paragraph edit; I’m calling it out here because the right way to handle a doc-vs-code drift is to say “yep, doc lags, here’s the fix” rather than to silently update and hope nobody noticed. TODO: Dax confirm timing on shipping that fix.

Why the docs are the README’s older sibling

A reader who only reads the README.md gets the chain parameters and a roadmap. A reader who reads papers/ gets the case for the chain — why these parameters, why this proof system, why mandatory privacy, why fair launch.

The README is for someone who’s deciding whether to spend an hour. The papers are for someone who’s deciding whether to run a node, port a wallet, list the asset, write a regulatory memo, or audit the cryptography. Different audiences, different artefacts.

Both live in the repo. Both are diffable. Both are MIT-licensed. That’s the documentation discipline I’m trying to lock in: nothing about how the chain works lives behind a marketing page or a sales rep.

Further reading

• papers/ — the 17 markdown files
• papers/00-master.md — the index
• papers/01-executive-summary.md — the headline pitch
• papers/17-zkvm-engineering.md — the SP1/Plonky3 deep dive
• planning/price-discovery-for-private-swaps.md — the swap-price design exploration
• Vanta: a Bitcoin fork with ZK at consensus — the practitioner-flavored pitch
• Why we shipped SP1 instead of RISC Zero — the post that quotes paper 17 most