Hazync’s developer reports that a 1.7 MB standalone verifier checked a 226,434-byte cryptographic receipt covering the first 1,789 blocks of Bitcoin in 27 milliseconds. The Aug. 15 disclosure limits that result to an early stretch of Bitcoin’s history. A complete genesis-to-tip proof campaign remains unfinished.
Hazync is a research prototype that uses RISC Zero’s zero-knowledge virtual machine, or zkVM, to make Bitcoin validation reusable. The zkVM executes the validation program, and the resulting receipt gives other users a compact file to check. The developer’s design concentrates proof generation among provers and leaves receipt verification to a much larger population.
Those two jobs have radically different costs. The developer estimates roughly 17 GPU-years for the historical backfill, followed by capacity equivalent to about six Nvidia L40S GPUs to keep pace with new blocks. Cheap receipt checks arrive after provers, auditors and archive operators have supplied the expensive work upstream.
Verification is cheap; proving is expensive
A conventional new Bitcoin node independently replays the chain. Hazync runs Bitcoin’s rules inside the zkVM, proves that those rules accepted each covered block, and recursively folds block proofs into a single receipt.
The public Hazync repository describes a guest program built from substantial parts of Bitcoin Core v28’s consensus code and libsecp256k1, compiled for 32-bit RISC-V. Reusing Core’s code reduces the amount of consensus behavior that has to be restated in a separate circuit.
The block 741,000 benchmark measures proof-generation cost on recent Bitcoin data. The developer reports that the block contained 670 inputs and required 394 UTXO leaves. Proving it as 16 chunks across two L40S GPUs took about 55 minutes, including 27 minutes for aggregation.
That measurement informs the developer’s estimate of roughly 17 GPU-years for a genesis-to-tip backfill. The available material supplies representative project benchmarks instead of an audited measurement across every era of Bitcoin history. Hazync’s full-chain performance therefore remains an estimate until the campaign is completed.
Software changes can also erase completed work. Every Hazync receipt commits to a METHOD_ID, a fingerprint of the compiled guest program. A new guest build receives a new identifier, leaving earlier receipts tied to the previous version.
The project restarted its genesis board on Aug. 4 after an internal audit forced a new baseline. A later soundness fix could trigger the same reset after far more GPU time has accumulated. The proving budget therefore spans stable code, the historic backfill and continuous capacity for the tip.
Verification speed is the part visible to the final user. The 17 GPU-year estimate measures the concentrated industrial effort required to produce that experience.
What the receipt does not replace
A receipt compresses validity checking. Archive operators still supply transaction availability and retain historic witness and signature bytes. Future guest revisions need those bytes to prove the chain again, so succinct verification preserves a long-term storage role for archive infrastructure.
Best-chain selection stays with Bitcoin’s most-work rule. Hazync places cumulative work in the receipt’s public output, giving a verifier the value needed to compare competing tips. The receipt establishes rule compliance for its chain segment; the node still chooses which valid chain to follow.
An archive bridge also retains the power to waste prover resources. The project’s stated composition rules connect every state boundary to the genesis pin, causing forged state to fail when a receipt joins the spine. A hostile bridge can instead serve unusable inputs and consume a worker’s GPU time, turning availability into an economic denial-of-service risk.
The developer describes a proof composed from genesis as unconditional within Hazync’s software and cryptographic assumptions. A later checkpoint enters the system as an explicit trust input.
The guest itself contains an important review boundary as substantial Core consensus code runs inside it, alongside project-maintained slices for the subsidy schedule and script-activation heights. The project says its script-flag schedule is differentially tested as a sound superset of Core’s rules, allowing extra rejection in the direction intended to preserve soundness.
A C++ portability layer adapts Core for the zkVM, and a non-Core Utreexo accumulator commits changes to Bitcoin’s unspent-transaction-output set. The disclosed assumptions also cover RISC Zero’s proof system, SHA-256 and secp256k1. Hazync identifies the portability shims and accumulator as its highest-priority residual review targets.
The repository reports two AI-assisted external reviews in August that failed to find a path for the guest to accept an invalid chain. A commissioned professional audit remains outstanding. Public code enables outside scrutiny, and production assurance still rests on adversarial examination of the exact guest and every component inside its proof boundary.
Hazync splits trustless sync into several jobs with different operators and budgets. Receipt verification can reach milliseconds for a proven range. Proof generation consumes GPU capacity, archive operators retain the underlying data, nodes compare tips, and auditors assess the guest.
A stable implementation with sufficient compute and outside review could reduce repeated validation across new nodes. At the project’s current stage, the developer-reported 27-millisecond check covers a limited spine, while the 17 GPU-year estimate describes the unfinished path to Bitcoin’s tip.
