From Bitcoin OP_RETURN to Full Verification in 42 Bytes

This is the fifth post in a series describing the H33 substrate, a 74-byte post-quantum attestation primitive. The previous posts covered the primitive itself, the three-hardness-assumption argument, the batched Merkle aggregation construction, and domain separation across computation types. This post is about what happens when you take a substrate from end to end: from the moment a document enters the system to the moment a remote verifier confirms every cryptographic link in the chain. It is about Test 5 in our verification suite — receipt-to-chain verification — and about the practical consequences of being able to verify 74 bytes without calling home.

The test

We minted a LegalEvidence substrate. The input was a legal document — a PDF of a signed contract. The substrate pipeline hashed the document with SHA3-256, embedded that hash in a 58-byte canonical commitment with computation type 0x0F (LegalEvidence), generated a signing message from the canonical encoding, signed the signing message under all three post-quantum families (ML-DSA-65, FALCON-512, SLH-DSA-SHA2-128f-simple), constructed a compact receipt committing to the full signature bundle, and anchored the 32-byte signing message to Bitcoin via OP_RETURN. The total persistent footprint: 32 bytes on-chain, 42 bytes in the receipt. Seventy-four bytes.

Test 5 then ran five independent verification steps against this substrate, each designed to confirm a different link in the cryptographic chain. Every step passed. Here is what each step checked and why it matters.

Step (a): Structural receipt verification. The compact receipt is exactly 42 bytes. The first byte is the version number, which must be 0x01 for the current protocol revision. The last byte before the timestamp is the algorithm flags bitfield, which must have bits set for ML-DSA, FALCON, and SLH-DSA — the three families that signed this substrate. The test confirmed the receipt is the correct length, the version byte is valid, and the algorithm flags indicate a three-family signature. This is the cheapest possible check: it costs nothing more than reading 42 bytes and comparing three values. It catches corruption, truncation, and version mismatches before any cryptographic work begins.

Step (b): Signing message reconstruction. The signing message is a deterministic function of the substrate's canonical encoding. Given the 58-byte substrate, the verifier recomputes the signing message using the same canonical encoding rules the producer used. The test confirmed that the recomputed signing message matches the 32-byte value anchored to Bitcoin's OP_RETURN output. This step proves that the on-chain anchor is bound to this specific substrate and no other. If anyone modifies any byte of the substrate — the content hash, the computation type, the timestamp, the nonce — the recomputed signing message will differ from what is on-chain, and the verification fails.

Step (c): Verification hash reconstruction. The compact receipt's 32-byte verification_hash is SHA3-256 of a domain-tagged, length-prefixed concatenation of the signing message, all three public keys, and all three signatures. The test took the signing message from step (b), the three public keys from the signer's published key set, and the three signatures from the signature bundle store, concatenated them with the protocol-specified domain tag and length prefixes, hashed the concatenation with SHA3-256, and confirmed the result matches the verification_hash stored in the receipt. This step proves that the receipt commits to these specific signatures and these specific keys, and that no substitution has occurred since the receipt was produced.

Step (d): Content binding verification. The substrate's 32-byte content hash is SHA3-256 of the original document's bytes. The test took the original PDF, hashed it with SHA3-256, and confirmed the result matches the content hash in the substrate. This step proves that the substrate is bound to this specific document. If the document is modified — even by a single bit — the content hash changes, the substrate changes, the signing message changes, and the OP_RETURN no longer matches. Content binding is the most intuitive of the five steps: it is the link between the real-world artifact and the cryptographic chain.

Step (e): Complete two-chain verification. This is the step that ties everything together. The test verified both chains in their entirety. The content chain: document bytes → SHA3-256 → content hash in substrate → canonical encoding → signing message → Bitcoin OP_RETURN. The receipt chain: signing message + three public keys + three signatures → domain-tagged concatenation → SHA3-256 → verification_hash in receipt. Every link in both chains was independently recomputed and matched. The test confirmed that the two chains share a single binding point — the signing message — and that both chains resolve to publicly verifiable anchors: the Bitcoin blockchain on one side, the signer's published key set on the other.

All five steps passed. The substrate is verified.

What the compact receipt actually contains

Forty-two bytes. Let me be precise about what is in each of them, because the receipt's compactness is the mechanism that makes offline verification practical and the two-chain structure possible.

Byte 0 is the version number (1 byte). Currently 0x01. This byte exists so that future protocol revisions can change the receipt format without ambiguity. A verifier that sees 0x02 knows it is looking at a format it may not understand and can reject or upgrade gracefully.

Bytes 1 through 32 are the verification_hash (32 bytes). This is the SHA3-256 digest of a domain-tagged, length-prefixed concatenation. The domain tag is a fixed ASCII string that prevents cross-protocol hash collisions. The length prefixes ensure that a concatenation of (short_message, long_key) cannot produce the same byte sequence as (long_message, short_key). The inputs to the concatenation are: the signing message (32 bytes, derived from the substrate's canonical encoding), the ML-DSA-65 public key (1,952 bytes), the FALCON-512 public key (897 bytes), the SLH-DSA-SHA2-128f public key (32 bytes), the ML-DSA-65 signature (3,309 bytes), the FALCON-512 signature (up to 690 bytes), and the SLH-DSA-SHA2-128f signature (17,088 bytes). The total input to the hash is approximately 24 kilobytes. The output is 32 bytes. This means the 32-byte verification_hash cryptographically commits to roughly 21 kilobytes of signature and key material without carrying any of it.

Bytes 33 through 40 are the timestamp (8 bytes). A millisecond-precision Unix timestamp recording when the receipt was produced. Eight bytes gives us coverage until approximately the year 292,278,994. This is not the substrate's timestamp (the substrate has its own 8-byte timestamp in its 58-byte body). This is the receipt's timestamp, which records when the signature bundle was finalized. The two timestamps will typically be within milliseconds of each other, but they are semantically distinct: the substrate timestamp records when the computation result was committed, the receipt timestamp records when the three-family signature was completed.

Byte 41 is the algorithm flags bitfield (1 byte). Eight bits, each corresponding to a signature family. Bit 0 is ML-DSA. Bit 1 is FALCON. Bit 2 is SLH-DSA. The remaining five bits are reserved for future families. For a standard three-family substrate, this byte is 0x07 (binary 00000111). This byte allows a verifier to know which families were used without parsing the signature bundle. It also allows for future substrates that use two families, or four, or five, as the post-quantum landscape evolves.

That is the entire receipt. Forty-two bytes. No signature bytes. No public key bytes. No certificate chain. No X.509 overhead. No ASN.1 encoding. Just a version, a hash, a timestamp, and a bitfield. The cryptographic weight — the 21 kilobytes of signatures and keys — lives in the signer's store, not in the receipt. The receipt is a 42-byte commitment to that weight.

Practical use: Offline verification

Consider a remote auditor. They are in a location with no network access — a classified facility, a remote field office, an airplane. They receive a 42-byte compact receipt and a 58-byte substrate, delivered on a USB drive or printed as a QR code (100 bytes fits comfortably in a QR code). What can they verify without any network connection?

They can verify structural integrity. The receipt is 42 bytes, version 0x01, algorithm flags 0x07. The substrate is 58 bytes, version 0x01, computation type 0x0F (LegalEvidence). Both are well-formed. This catches corruption in transit.

They can recompute the signing message. Given the 58-byte substrate, they apply the canonical encoding rules and produce the 32-byte signing message. This is a pure computation — no network, no external state, no oracle. They now have the value that should appear in the Bitcoin OP_RETURN output. They can record it for later on-chain verification when they regain connectivity, or compare it against a previously cached copy of the blockchain.

They can verify the content binding. If they have the original document (or a copy of it), they hash it with SHA3-256 and compare the result to the content hash in the substrate. If it matches, the substrate is bound to this document. If it does not match, either the document has been modified or the substrate was produced from a different version. This check is entirely local.

The one thing the auditor cannot do offline is verify the actual post-quantum signatures. For that, they need the approximately 21-kilobyte signature bundle from the signer's store. This is a deliberate design choice. The receipt commits to the signatures via the verification_hash, so the auditor knows that a specific set of signatures exists and that the receipt they are holding is bound to that specific set. But they cannot check the signatures themselves without the bundle. Once they obtain the bundle — from the signer, from a public archive, from a colleague — they can complete the verification: recompute the verification_hash from the signing message, keys, and signatures, and confirm it matches the receipt.

The offline verification story is therefore: three of five checks are fully local, one check (OP_RETURN confirmation) requires cached or deferred blockchain access, and one check (signature verification) requires the signature bundle. In practice, this means an auditor can make a high-confidence structural determination — "this receipt is well-formed, it binds to this document, and the signing message is consistent" — without any network access at all. The full cryptographic verification comes later, when connectivity or the signature bundle becomes available. This layered verification model is the natural consequence of separating the receipt from the signature bundle.

Practical use: Court admissibility

Consider a legal team presenting a chain-of-custody record for a set of documents. Forty-seven substrates, each attesting a custody event: initial intake, attorney review, redaction, expert analysis, filing, service, response, amendment, and so on. Each substrate is 74 bytes — 32 on-chain, 42 in the receipt. The total persistent footprint for the entire custody chain is 3,478 bytes. That is less than 3.5 kilobytes for 47 independently verifiable custody events, each anchored to the Bitcoin blockchain, each signed under three post-quantum signature families.

Opposing counsel wants to challenge the chain. They can. Every link is independently verifiable. They take substrate number 23 — the one attesting the expert analysis — and they recompute the signing message from the canonical encoding. They compare it to the OP_RETURN output in Bitcoin transaction at the recorded block height. It matches. They obtain the signature bundle for substrate 23 from the signer's published archive. They recompute the verification_hash from the signing message, the three public keys, and the three signatures. It matches the receipt. They hash the expert's report with SHA3-256 and compare it to the content hash. It matches the substrate. Every link holds.

The critical property for court admissibility is that none of this verification requires trusting H33. The verification is a pure function of publicly available data: the substrate bytes, the receipt bytes, the signature bundle, the signer's public keys, and the Bitcoin blockchain. An independent expert — retained by the opposing side — can run the same verification using the open-source verifier (Apache 2.0) on their own hardware. The math is the witness. The substrate does not require an expert to explain what it does; it requires an expert to confirm that SHA3-256 and the three NIST-standardized signature schemes behave as specified. That is a much lower bar than explaining proprietary tamper-detection technology to a jury.

The temporal ordering is also verifiable. Each substrate's timestamp is embedded in its canonical encoding, and each OP_RETURN is embedded in a Bitcoin block with a block timestamp. The Bitcoin blockchain provides an independent, globally witnessed ordering that the custody chain's timestamps are consistent with. A substrate claiming to have been produced at 2:00 PM cannot appear in a Bitcoin block timestamped 1:00 PM. This does not prove the substrate was produced at the exact claimed time, but it provides an upper bound: the substrate existed no later than the block timestamp.

Practical use: Cross-border verification

Consider a European financial regulator who needs to verify an attestation produced by an American company. Under traditional approaches, this verification typically involves one or more of the following: an API call to the American company's servers, a trust relationship between the regulator and the company (or a mutual trust anchor like a certificate authority), a jurisdiction-specific legal framework that governs how the verification is conducted, and often a bilateral agreement between the two jurisdictions' regulatory bodies.

Under the substrate model, the verification is a pure function of public data. The regulator downloads the open-source verifier from the public repository. They compile it on their own hardware. They feed it the 58-byte substrate, the 42-byte receipt, and the signature bundle. The verifier recomputes every hash, checks every signature, and returns a boolean. No API call to the American company. No trust relationship. No certificate authority. No bilateral agreement. No jurisdiction dependency.

The American company's only obligation is to have published their public key set at some point in the past. The regulator's only requirement is access to that public key set, the signature bundle, and a copy of the Bitcoin blockchain (or a Bitcoin block explorer — several are operated by European entities). The verification software is open source (Apache 2.0), auditable, and runnable in an air-gapped environment.

This property — jurisdiction-independent verification — is not an incidental feature. It is a direct consequence of the design decisions that went into the substrate: deterministic canonical encoding, no runtime dependency on the signer, open verification algorithms, and anchoring to a globally replicated ledger. When verification is a pure function of public data, jurisdictional boundaries become irrelevant to the act of verification itself. The legal interpretation of a verified attestation may still depend on jurisdiction, but the mathematical fact of verification does not.

For multinational organizations subject to multiple regulatory regimes simultaneously — a bank operating in both the EU and the US, a pharmaceutical company conducting trials across five countries, a technology company serving customers on every continent — this means producing a single attestation that every regulator can independently verify using the same open-source tool. No per-jurisdiction integration. No bilateral trust negotiation. One substrate, verifiable everywhere.

Why the two-chain structure matters

The five verification steps in Test 5 expose the substrate's two-chain architecture. The content chain runs from the original document through the content hash, through the substrate's canonical encoding, through the signing message, to the Bitcoin OP_RETURN. The receipt chain runs from the signing message through the three public keys and three signatures, through the domain-tagged concatenation, through the SHA3-256 hash, to the verification_hash in the compact receipt. The two chains share a single binding point: the signing message.

This structure is not an accident. It was designed to provide a specific failure-mode property that single-chain constructions do not have.

If the content chain breaks — the document was modified after attestation — the receipt chain is unaffected. The verification_hash in the receipt still matches the signature bundle. The signatures still verify against the public keys. The receipt still proves that a valid three-family attestation occurred at the claimed time, over the signing message that was originally derived from the original (unmodified) document. The content chain breakage tells you the document has been tampered with. The intact receipt chain tells you what the original document's hash was (it is embedded in the signing message), when the attestation occurred, and that the attestation was cryptographically valid. In a forensic context, this distinction matters: you know the document was modified, and you know what the authentic version's fingerprint was.

If the receipt chain breaks — the receipt was tampered with, or the signature bundle was corrupted — the content chain is unaffected. The content hash in the substrate still matches the document. The signing message still matches the OP_RETURN on the Bitcoin blockchain. The content chain still proves that the on-chain anchor is bound to this specific document. The receipt chain breakage tells you that the signature metadata has been compromised, but the on-chain anchor — the 32 bytes in the Bitcoin UTXO set — remains valid and independently verifiable by anyone with access to the blockchain.

For both chains to be defeated simultaneously — for an adversary to forge a substrate that passes all five verification steps — they would need to: produce a document whose SHA3-256 hash matches the content hash (pre-image attack on SHA3-256), or produce a valid canonical encoding whose signing message matches the OP_RETURN (requires either finding a collision in SHA3-256 or modifying the Bitcoin blockchain), AND produce a valid three-family signature bundle whose concatenated hash matches the verification_hash in the receipt (requires forging signatures under ML-DSA-65, FALCON-512, and SLH-DSA-SHA2-128f simultaneously, or finding a pre-image in SHA3-256). The conjunction of these requirements is what gives the two-chain structure its strength. Breaking one chain provides forensic evidence of tampering. Breaking both chains simultaneously requires multiple independent cryptographic catastrophes.

This is the engineering payoff of separating the content commitment from the signature commitment. A single-chain construction — where the signature is bundled into the on-chain data, or where the content hash is embedded in the signature rather than in a separate canonical structure — would provide an all-or-nothing verification result. Either everything checks out or nothing does. The two-chain structure provides a gradient: structural integrity, content binding, on-chain anchoring, signature commitment, and full cryptographic verification are independently checkable, and partial verification results are still meaningful.

Seventy-four bytes, two chains, five checks

Test 5 is the test we run most often, because it exercises the complete verification path. It is also the test that most clearly demonstrates what the substrate is for. The substrate is not for storing data. It is not for compressing signatures. It is not for replacing key management. It is for creating a 74-byte artifact that two independent parties — who have never met, who may be in different jurisdictions, who may not even be online at the same time — can use to agree on whether a specific computation result was authentically attested by a specific signer at a specific time, with the agreement grounded in mathematics rather than trust.

The 42-byte compact receipt is the half of that artifact that makes this practical. Without the receipt, the verifier would need the full 21-kilobyte signature bundle to confirm anything. With the receipt, the verifier can confirm structural integrity, content binding, and signing message consistency using only the 100 bytes of the substrate and receipt combined. The full signature verification — when they need it — requires the bundle, but the receipt tells them exactly which bundle to ask for, and exactly what hash that bundle must produce when they get it.

This is the primitive doing what primitives are supposed to do: providing a small, well-typed object with clear semantics that composes with everything else in the system. The content chain composes with any document management workflow. The receipt chain composes with any key archival system. The OP_RETURN anchor composes with any Bitcoin infrastructure. The five verification steps compose with any audit framework. And the whole thing fits in 74 bytes.

The next post in this series will cover batched Merkle response attestation and how a single 74-byte root substrate can commit to millions of individual computation results. Patent pending — H33 substrate Claims 124–125.