Vanta: a Bitcoin fork with ZK at consensus

You can read this post as the technical version of Why I started Zera Labs. The strategy lived there. The code lives in Dax911/vanta, and the README opens with a sentence that took me a long time to feel comfortable writing:

Vanta L1 — ZK-privacy Layer 1 blockchain — fork of Bitcoin Core v27.0.

If you spent any time on crypto Twitter in 2024, the words fork of Bitcoin Core were code for “vanity chain that nobody serious will run.” I want to make the case that this fork is different — not because the C++ source tree is different (most of it isn’t) but because the consensus rules are.

What it is

The headline parameters are deliberate departures from Bitcoin:

A 1-minute block time and a 42-billion supply are not “Bitcoin with a different ticker.” They are calibrated to make this chain feel like a payments rail rather than a settlement rail. You can confirm a payment in two blocks (2 minutes, ~95% confidence) instead of three blocks (30 minutes). The 100,000-per-block subsidy makes the unit economics of running a node + miner actually work for a small operator.

I have opinions about small-operator unit economics that come from running a Bitaxe BM1368 against this chain for the past several months.

The fork strategy: keep what works

The monorepo structure is a direct read on the strategy:

zl1/
├── src/              # Vanta Core (C++ — Bitcoin Core v27.0 fork)
├── wallet/           # Web wallet (Rust/Axum)
├── txbot/            # Transaction bot (Rust)
├── explorer/         # Block explorer (Node.js — patched btc-rpc-explorer)
├── vanta/            # ZK circuits (Rust/RISC Zero)
├── pool/             # Stratum server (Python)
└── …

Bitcoin Core v27.0 is the most-tested codebase on the planet by node-hours. We did not fork it because we thought we could write something better. We forked it because we wanted a chain that ships day-one with the same tooling humans have spent fifteen years building around Bitcoin — wallets that can be ported, RPCs that can be wrapped, block explorers that can be patched. The price of admission is that the C++ surface area is huge and you respect it.

We did not fork the cryptography. The ZK layer is in the vanta/ subtree, written in Rust against RISC Zero’s zkVM, running entirely outside the C++ core. The C++ core verifies one thing: a SHA-256 hash of the proof witness root. That’s it. The proof itself is computed and verified in a Rust program that runs as a sidecar. This split means we can change the proof system without forking the chain again, which matters in 2026 because the proof-system landscape is moving fast.

What’s at consensus, what’s not

Here is the part I want to dwell on, because every privacy-coin design eventually crashes into this question.

At consensus (i.e. nodes will reject blocks that don’t satisfy these):

1. ZK proof-to-UTXO binding. A spending transaction must include a witness v2 input commitment that matches the proof’s public input. The C++ validator verifies the binding before the proof is even consulted; the proof confirms it.
2. SMT root cross-verification. Every block has a coinbase commitment to the sparse-Merkle-tree root of the post-block nullifier set. The proof root and the coinbase commitment must match. A miner cannot lie about state.
3. L1 nullifier set tracking. The nullifier set is part of consensus state, not a wallet-side hint. Two valid blocks attempting to mine a transaction whose nullifier was spent in either block create a hard chain split. Double-spend prevention is a property of the chain, not a property of the wallet.

Not at consensus:

1. The proof system itself. Today it’s Groth16 over the RISC Zero zkVM. We can swap to Halo2 or Nova-style recursion in a soft fork by adding a new opcode and grandfathering the old. The chain doesn’t know what proof system it’s running; it knows how to verify a witness root.
2. Address format. Z-legacy and zer1-bech32 are wallet-side. The chain treats them all as OP_PUSHBYTES-style script commitments.
3. Wallet-level shield/unshield UX. The README lists shield and unshield as commands for moving between transparent and private. Those are wallet conveniences; the chain itself sees commitments and nullifiers, not “shielded” and “unshielded” as states.

This split is load-bearing. If your fork tries to put the proof system into consensus, you have two terrible choices when the proof system improves: hard-fork the world, or live with worse cryptography forever. Vanta lives somewhere in between: the binding is at consensus, the proof system is not.

The roadmap, annotated

The README’s roadmap is concise; let me unpack the items that are checked.

• [x] Fork Bitcoin Core v27.0 — the easy part. It’s a tree copy and a network-magic change.
• [x] Custom chain parameters — most of the work was rewriting src/chainparams.cpp and the genesis-block builder. Bitcoin Core makes you re-mine the genesis block locally; the script is in contrib/.
• [x] Solo mining with Bitaxe BM1368 — the Python Stratum server in pool/ is a from-scratch Stratum v1 implementation pointed at the local node’s RPC. I’ll write a separate post on the Bitaxe rig.
• [x] Web wallet + block explorer — Rust/Axum wallet, patched btc-rpc-explorer for the explorer. The wallet integrates with the ZK circuits; the explorer renders shielded transactions as opaque commitments.
• [x] Transaction bot for mempool activity — synthetic mempool activity is essential during testnet. The Rust txbot generates round-robin spends so you’re not staring at empty blocks.
• [x] RISC Zero ZK circuit integration — the big one. RISC Zero gives us a zkVM where the circuit is just Rust. We don’t write R1CS by hand. The witness for a spend is the same Rust struct the wallet uses; the prover takes that struct and emits a proof.
• [x] ZK proof-to-UTXO binding — wired into src/script/interpreter.cpp and the witness-v2 stack. A new OP_VANTA_VERIFY opcode pulls the proof root from the witness, hashes it with the input commitment, and compares against the script.
• [x] SMT root cross-verification — sparse-Merkle-tree state for the nullifier set is materialised in the block header’s coinbase. A node that doesn’t validate the SMT root rejects the block.
• [x] L1 nullifier set tracking — the chainstate db now has a nullifier table. Double-spend at L1, see my next post.
• [x] Shield/unshield wallet commands — vanta-cli shield 1.5 moves 1.5 VANTA from a transparent UTXO into a shielded note. unshield does the reverse with a destination address. Both produce normal-looking on-chain transactions; the difference is the witness contents.

The two unchecked items are the strategic ones. Mandatory privacy as a hard fork (so every transaction is a uniform shielded format and no information leaks from “this user used the shielded pool, this one didn’t”) is the long-term goal. A full Rust node rewrite is the longer-term goal — the C++ tree is fine for now, but a vantad written from scratch in Rust against the same RPC contract is the kind of project you can spend three years on without regretting it.

What I changed my mind about

When we started, I wanted to write the chain from scratch in Rust. A clean tree, no Bitcoin baggage, no boost:: types, modern async, the whole pitch.

Two things stopped me:

1. Time. Writing a UTXO chain from scratch is at least a year of work before you have something nodes will run. We had ~3 months of runway for the L1 proof-of-concept. That’s a fork-or-fold decision.
2. Bitcoin Core’s testing infrastructure is the actual product. The test/ directory is the most underrated part of the Bitcoin codebase. There are functional tests that cover edge cases nobody on a greenfield team will think of for years. Inheriting that is worth more than most people realise.

The compromise we landed on is in the README’s last roadmap line: full Rust node rewrite. That’s the path. Fork now to ship now; rewrite incrementally to own the long term. The Rust ZK sidecar is the first piece of that rewrite. The Rust wallet is the second.

What’s next

The next two posts will go deeper:

• L1 nullifier sets: enforcing no-double-spend at the consensus layer
• Mining VANTA with a Bitaxe BM1368 (forthcoming)

If you want the strategic frame, I wrote about the four curves that crossed in 2026 to make this whole thing tractable in Privacy’s broadband moment.

Further reading

• Dax911/vanta on GitHub — the codebase
• Dax911/vanta/README.md — chain parameters + roadmap
• Bitcoin Core v27.0 release notes — the fork base
• RISC Zero docs — the zkVM the proof system runs on
• Sparse Merkle trees: a brief overview — for the SMT root commitment
• Pedersen commitments, in production — sister piece on commitment schemes