hazync

How it works

A block goes in; a proof comes out that anyone can check in milliseconds. In between, Bitcoin Core's own validation code runs inside a zero-knowledge virtual machine, spread across as many GPUs as are available.

Why Core's own code

To prove Bitcoin's rules were followed, you have to run those rules inside the prover. The tempting route is to rewrite them in whatever language the prover likes. Every rewrite then carries a question it can never fully answer: does it match Bitcoin Core in every edge case, forever? If it differs by one quirk, the proof says "valid" for something the network would reject.

Hazync does not rewrite the hard part. Bitcoin Core v28.0's script interpreter, its signature hashing, its transaction checks and libsecp256k1 are compiled to RISC-V and run inside the RISC Zero zkVM. Difficulty adjustment is Core's own pow.cpp too. What is re-expressed is short arithmetic: the halving schedule and the heights where soft forks switch on, each checked against Core.

One component is not Core's: the Utreexo accumulator that tracks the set of unspent coins. It is the most likely place for any remaining bug, and the first thing an audit should look at.

From block to proof

Seven steps. Only the sixth has to happen in order; everything else runs in parallel.

Block 1 gather chunk on GPU chunk on GPU ⋮ chunk on GPU chunk on GPU 2 split 3 prove Join one proof per block 4 join 5 fold genesis Genesis proof 6 grow, in order 7 check

  1. Gather the block's inputs

    A bridge, an archive Bitcoin node, packages each block with the coins it spends and proof that those coins exist. None of this is trusted: the prover re-derives everything it can and rejects anything that does not add up.

  2. Split the work

    A cost packer divides the block's inputs into chunks of roughly equal cost. Each chunk proves on its own, so one block fans out across many GPUs.

  3. Prove each chunk

    Each GPU runs Core's checks for its chunk inside the zkVM and returns a receipt: a proof that this exact program ran on this exact input.

  4. Join the chunks

    An aggregate step checks every chunk receipt and joins them into one proof for the block. A worker can fail to return a receipt; it cannot forge one.

  5. Fold blocks together

    Proofs of neighbouring ranges fold into one proof for the combined range, in any order, on any machine. Every single-block proof is kept, so any one block can still be checked alone.

  6. Grow the genesis proof

    One proof anchored at the genesis block grows by absorbing the next range. It is the only step that has to happen in sequence.

  7. Check it anywhere

    The verifier needs no node, no peers and no chain data. It ships as a 1.7 MB program, a C library for node software, and a WebAssembly build that runs in a browser in under 2 MiB of memory. Try it in the explorer.

Proving the whole chain

The plan for going from a fraction of the chain to all of it: work from both ends at once.

Genesis Tip Proof party Tip cluster Anchor Anchor warp idle time proves the block below the anchor the gap closes from both ends

The proof party proves upwards from genesis. A dedicated tip cluster starts from an anchor, a checkpoint near the tip, and proves every new block as it is mined. Whenever the cluster is waiting for the next block, it proves the block just below the anchor and folds it in, so the anchor walks backwards one block at a time.

Until the two ends meet, a proof that starts at the anchor rests on that checkpoint, much as Bitcoin Core's assumeutxo rests on a snapshot hash. When they meet, the checkpoint is no longer something anyone has to trust: the whole chain is proven from genesis.

This is the plan. The tip cluster starts when funding is in place; the proof party is running now. See the targets.

One block, measured

Proving is expensive and done by a few. Checking is cheap and done by everyone.

Inputs checked
9,079
Block to verified proof
544.0 s
RTX 4090 cards
27
GPU cost
$1.39

Block 966,256, with 4,741 transactions. Measured on 10 September 2026, run 4, on rented cards in six countries at about $0.34 per card-hour. The time comes from logs and telemetry, so it is attested rather than proved. Card counts for other blocks are models until they are run. The full record.

The build that ships leaves Core's consensus logic and libsecp256k1's signature code untouched, and makes two narrow concessions: a faster field arithmetic backend beneath libsecp256k1, through an interface the library already provides, and a public-key hint that Core's own arithmetic checks before accepting. On block 962,000 it used 3.36 billion cycles against 13.75 billion for the unmodified build, 4.1 times fewer, and produced a byte-identical result.

Measured in execute mode on one block, recorded in the v0.21.0 release notes.

What a proof tells you

For every block in its range, a Hazync proof shows three things, and a verifier needs no node, no peers and no chain data to check them:

  • every transaction is valid under Bitcoin Core's consensus rules, checked by Core's own code rather than a rewrite of it;
  • the set of unspent coins after the last block matches the root the proof commits to;
  • the proof of work adds up to the total the proof commits to.

Each proven block also keeps its own proof, so anyone can be handed a single block and check it alone.

What you are trusting

A proof removes the need to re-run the work. It does not remove every assumption.

When a Hazync proof verifies, you are relying on:

  • SHA-256;
  • the soundness of the RISC Zero proof system, and for the small wrapped proof, its trusted setup;
  • the prover program ID matching the published source, which you can check yourself with the reproducible build;
  • the accumulator code, the one component that is not Bitcoin Core's;
  • the genesis block as the starting point.

Bitcoin Core already skips signature checks for most of the chain by default, on the authority of an assumevalid hash its developers choose. Hazync replaces that chosen hash with a proven one: a smaller assumption than today's default, not zero.

What it does not do yet

  • It is not a full node. The rule against block timestamps more than two hours in the future is left to the node, by design.
  • It proves mainnet only.
  • It has had no commissioned audit. Two outside review rounds were AI-assisted, not a professional audit. Help change that.
  • It covers a small part of the chain so far. See exactly how much.

Questions

Does Hazync change Bitcoin?

No. There is no soft fork, no new rule, and nothing for miners or the network to adopt. Hazync proves that the existing rules were followed. Each node decides for itself whether to use a proof.

How is a proof different from a checkpoint?

A checkpoint, or Bitcoin Core's assumevalid hash, says "trust that the blocks up to here are fine". A proof shows that every one of those blocks followed Bitcoin Core's rules, and anyone can check it for themselves.

Could a bad proof trick my node?

Only if one of the assumptions fails: SHA-256, the RISC Zero proof system, or the accumulator code; or if you trust a program ID you have not checked against the source. That is why an independent audit is one of the targets. What you are trusting.

Why a zero-knowledge proof? Is something being hidden?

Nothing is hidden. Hazync uses a zero-knowledge proof system because its proofs are succinct: checking one takes milliseconds, however much work went into making it.

What is the haze in Hazync?

A hazed block is one a node keeps with its signatures stripped out. ghostd can store blocks that way, and a Hazync proof shows they were valid, so a node can hold less data and still know its chain is sound. Sync is the other half: starting a node from a proof instead of from the beginning.

Do I need a GPU?

Only to prove blocks. Checking a proof takes a browser or a small program on any computer.

Who runs the coordinator, and do I have to trust it?

The project runs the public one, but it cannot forge a proof, and every proof it holds can be downloaded and checked independently. Anyone can run their own.

Read further