A developer for the Hazync project has reported that a 1.7 MB standalone verifier was able to check a 226,434-byte cryptographic receipt in just 27 milliseconds. According to the disclosure on Aug. 15, this receipt covered the initial 1,789 blocks of Bitcoin's history. This impressive result is currently limited to that early period, as a complete proving campaign from the genesis block to the current tip has not yet been finished.

How Hazync Reimagines Validation

Hazync is a research prototype designed to make Bitcoin validation reusable by employing RISC Zero's zero-knowledge virtual machine (zkVM). The validation program is executed within the zkVM, which then generates a receipt that serves as a compact, verifiable file for other users. The developer’s architecture divides the labor, concentrating the intensive proof-generation work among a few provers while allowing a much larger population to perform inexpensive receipt verification.

The computational costs for these two tasks are vastly different. An estimated 17 GPU-years of processing power will be required for the historical backfill of the entire chain, according to the developer. After that, maintaining pace with new blocks will demand capacity equivalent to approximately six Nvidia L40S GPUs. The quick receipt checks enjoyed by end-users are only possible after provers, auditors, and archive operators have completed the costly upstream work.

In contrast to a conventional new Bitcoin node, which must independently replay the entire chain, Hazync operates differently. It runs Bitcoin's rules inside the zkVM, proves that each block was accepted under those rules, and then recursively folds these individual block proofs into a single, comprehensive receipt.

Technical Foundations and Benchmarks

The public Hazync repository details a guest program constructed from significant portions of Bitcoin Core v28's consensus code and libsecp256k1. This code has been compiled for the 32-bit RISC-V architecture. By reusing code from Core, the project minimizes the amount of consensus logic that needs to be re-implemented in a separate circuit.

To gauge the cost of proof generation on recent Bitcoin data, a benchmark was conducted on block 741,000. The developer reported that this block contained 670 inputs and necessitated 394 UTXO leaves. It took about 55 minutes to prove this block, processed as 16 chunks across two L40S GPUs. That time included 27 minutes dedicated to aggregation.

This specific measurement is the basis for the developer's projection of roughly 17 GPU-years for a complete genesis-to-tip backfill. The available materials offer representative project benchmarks rather than an audited measurement covering every era of Bitcoin's history. Consequently, Hazync's full-chain performance will remain an estimate until the entire campaign is concluded.

Challenges and Operational Considerations

The project faces the risk that software changes could nullify already completed work. Every receipt generated by Hazync commits to a METHOD_ID, which acts as a fingerprint for the compiled guest program. If a new guest program is built, it receives a new identifier, rendering receipts from the previous version tied to the older software.

This exact scenario occurred on Aug. 4, when the project had to restart its genesis board following an internal audit that mandated a new baseline. A future fix for a soundness issue could prompt a similar reset, but after a much greater amount of GPU time has been invested. Therefore, the project's proving budget must account for achieving stable code, completing the historic backfill, and maintaining continuous capacity for the chain tip.

The ultimate user-facing benefit is verification speed. The 17 GPU-year estimate quantifies the massive, concentrated industrial effort needed to deliver that seamless experience.

A New Division of Labor

A receipt effectively compresses the work of validity checking. However, archive operators are still essential for supplying transaction availability and retaining the historic witness and signature bytes. These bytes are necessary for any future revisions of the guest program to prove the chain again, ensuring that succinct verification preserves a long-term storage role for archive infrastructure.

Best-chain selection continues to rely on Bitcoin's most-work rule. Hazync incorporates cumulative work into the public output of its receipts, providing verifiers with the value needed to compare competing chain tips. While a receipt establishes that a chain segment complies with the rules, the node operator still must choose which valid chain to follow.

An archive bridge also introduces a potential vulnerability by having the power to waste provers' resources. The project’s stated composition rules are designed to connect every state boundary back to the genesis pin, which causes any forged state to fail when its receipt is joined to the main spine. A hostile bridge, however, could serve unusable inputs, thereby consuming a worker's valuable GPU time and turning data availability into an economic denial-of-service risk.

Trust, Security, and Auditing

The developer describes a proof composed from genesis as unconditional, operating within the software and cryptographic assumptions of Hazync. Any later checkpoint introduced into the system functions as an explicit trust input.

The guest program itself represents a critical boundary for review, as it contains substantial consensus code from Core running alongside project-maintained slices for elements like the subsidy schedule and script-activation heights. The project asserts that its script-flag schedule is differentially tested to be a sound superset of Core’s rules, which allows for extra rejections in a way that is intended to preserve soundness.

A C++ portability layer is used to adapt Core for the zkVM, and a non-Core Utreexo accumulator commits changes to Bitcoin's unspent-transaction-output set. The project's disclosed assumptions also encompass RISC Zero's proof system, SHA-256, and secp256k1. Hazync has identified the portability shims and the accumulator as its highest-priority targets for remaining code review.

The repository notes that two AI-assisted external reviews were conducted in August, neither of which found a path for the guest program to accept an invalid chain. A formal, commissioned professional audit has not yet been completed. While the public code allows for external scrutiny, production-level assurance ultimately depends on adversarial examination of the exact guest program and every component within its proof boundary.

In summary, Hazync divides the process of trustless synchronization into distinct jobs handled by different operators with varied budgets. While receipt verification for a proven range can be accomplished in milliseconds, proof generation consumes immense GPU capacity. Meanwhile, archive operators maintain the underlying data, nodes compare valid tips, and auditors are responsible for assessing the guest program.

If a stable implementation can be achieved with sufficient computing power and thorough outside review, it could significantly reduce the repetitive validation work required for new nodes. At the project's current stage, the developer's reported 27-millisecond check applies only to a limited spine, while the 17 GPU-year estimate highlights the long, unfinished path to proving Bitcoin's current tip.