Binding Proof: How 74 Bytes Chains a Document to Bitcoin

Every property the H33 substrate provides -- tamper detection, domain separation, ZK proof compatibility, receipt verification, Bitcoin anchoring -- depends on one primitive property that has to hold before any of the others can work. That property is binding. Binding means that the 74-byte substrate is cryptographically chained to the exact bytes of the computation it attests, and that chain cannot be broken or substituted without detection. If binding fails, everything built on top of it fails. If binding holds, everything built on top of it inherits the binding's strength.

This post is the first in a series of five that walks through each of the five core properties the substrate unlocks. We start with binding because binding is the load-bearing wall. The other four properties -- tamper detection, domain separation, ZK proof, and receipt chain verification -- are rooms in the house. Without the wall, none of the rooms stand.

What binding means cryptographically

Binding, in the substrate's construction, is a chain of three hash links. Each link is independently computable, independently verifiable, and connected to the next by a deterministic cryptographic function. Here is the chain, from the raw computation output all the way to Bitcoin:

Link 1: Document to substrate. The computation produces some output -- a document, a score, a ciphertext, a binary, whatever the computation type specifies. The canonical encoding of that output is hashed with SHA3-256 to produce a 32-byte digest. That digest is written into the substrate's h field. This is the content hash. It binds the substrate to the specific bytes of the computation output. If a single bit of the output changes, the SHA3-256 digest changes, and the substrate no longer matches. The notation is H(r), where r is the canonical encoding of the computation result.

Link 2: Substrate to signing message. The entire 58-byte substrate -- version byte, computation type byte, the 32-byte content hash, the 8-byte timestamp, and the 16-byte nonce -- is serialized in canonical wire format and hashed with SHA3-256 to produce a 32-byte signing message. The notation is SHA3-256(S), where S is the serialized substrate. This signing message is what the three post-quantum signature families sign. ML-DSA-65 signs it. FALCON-512 signs it. SLH-DSA-SHA2-128f signs it. The compact receipt commits to all three signatures. The signing message binds the signatures to the specific substrate, which binds to the specific computation output.

Link 3: Signing message to Bitcoin. The 32-byte signing message SHA3-256(S) is written into a Bitcoin transaction's OP_RETURN output. This is the on-chain anchor. The Bitcoin blockchain's proof-of-work consensus guarantees that once the transaction is mined, the 32-byte value is immutable -- buried under cumulative hashrate that no adversary, classical or quantum, can economically reverse. The signing message in the OP_RETURN binds the Bitcoin block to the substrate, which binds to the computation output.

Three links. Document --> H(r) --> substrate.h --> SHA3-256(S) --> OP_RETURN. Each link is a SHA3-256 hash. Each link is independently verifiable by anyone with access to the inputs. No trusted third party is required at any step. No server needs to be running. No database needs to be queried. The chain is self-contained: given the original document and the substrate bytes, anyone can recompute every link and confirm that the OP_RETURN value in the Bitcoin block is the correct terminal hash.

The persistent footprint of this entire chain is 74 bytes: 32 bytes on-chain (the signing message in the OP_RETURN) and 42 bytes off-chain (the compact receipt). The three-family signature bundle -- which is large, on the order of several kilobytes due to the FALCON and SPHINCS+ signatures -- does not need to be stored persistently. It needs to be available at verification time, but it can be reconstructed, cached, or served on demand. The 74 bytes are what persist.

The actual test: an SEC filing document

Abstract descriptions of hash chains are easy to write and hard to trust. So we ran the binding test on a real document. The document was a 59-byte SEC filing fragment, minted as computation type ArchiveSign (0x09 in the substrate's computation type registry). ArchiveSign is the computation type reserved for document archival signing -- the use case where a document needs to be cryptographically bound to a point in time with a signature that will remain verifiable for decades.

Here is what we verified, link by link:

First, we took the 59-byte document and computed SHA3-256(document). This produced a 32-byte digest. We confirmed that this digest matched the h field of the minted substrate. Link 1: verified.

Second, we serialized the full 58-byte substrate in canonical wire format and computed SHA3-256(S). This produced the 32-byte signing message. We confirmed that each of the three signature families -- ML-DSA-65, FALCON-512, and SLH-DSA-SHA2-128f -- verified correctly against this signing message using the signer's published public keys. We confirmed that the compact receipt's cryptographic commitment (a SHA3-256 hash over the concatenated signature bundle) matched the actual bundle. Link 2: verified.

Third, we confirmed that the 32-byte signing message matched the value written into the Bitcoin transaction's OP_RETURN output. Link 3: verified.

Every link in the chain -- document --> H(r) --> substrate.h --> SHA3-256(S) --> OP_RETURN -- was independently verified. The persistent footprint was 74 bytes. The verification required no network call, no API key, no server. The verifier-only reference crate, published under the Apache 2.0 license at github.com/H33ai-postquantum/h33-substrate-verifier, implements this exact verification path. Patent pending #19/645,499.

The test is not interesting because it worked -- hash chains are well-understood constructions and there would be a serious problem if it didn't work. The test is interesting because of what it demonstrates about the substrate's binding property: the binding is not a theoretical claim. It is a concrete, independently reproducible chain of SHA3-256 computations that anyone can run, on a real document, with real signatures, anchored to a real Bitcoin block.

Practical use: SEC filing attestation

Consider a public company that files quarterly with the SEC. Every quarter, the company produces a 10-Q. The 10-Q is reviewed, approved by counsel, and filed. The filing is a specific document with specific bytes. Those bytes matter -- a single altered number in the financial statements can be the difference between compliance and fraud.

Today, the integrity of that filing depends on the SEC's EDGAR system, on the company's internal document management, and on the assumption that neither system has been compromised or altered after the fact. If someone asks, thirty years from now, whether the 10-Q filed in Q1 2026 is the same document that was actually filed in Q1 2026, the answer depends on the continued integrity of EDGAR's database and the company's archives. Databases get migrated. Archives get corrupted. Systems get decommissioned. The chain of custody is only as strong as the weakest administrative link.

Now consider what happens when the filing gets substrated at the moment it is finalized. The company computes SHA3-256 over the canonical encoding of the 10-Q. That hash goes into the substrate's h field. The substrate is signed under three post-quantum families -- three independent hardness assumptions, not one. The 32-byte signing message goes into a Bitcoin OP_RETURN. The persistent cost is 74 bytes and $0.001 per mint.

Thirty years later, anyone -- a regulator, a shareholder, a journalist, a forensic accountant -- can take the original 10-Q document, recompute SHA3-256 over its bytes, and check whether the result matches the OP_RETURN value that was mined into a Bitcoin block in 2026. No server needs to be running. No database needs to be queried. No company needs to still exist. The Bitcoin blockchain is the anchor, and Bitcoin's proof-of-work is the guarantee that the anchor has not been moved. The three-family signature, signed under three hardness assumptions, is the guarantee that the substrate was not forged at the time it was produced -- even by an adversary with a cryptographically relevant quantum computer.

This is not a hypothetical improvement over the status quo. The status quo for long-term document integrity is "trust the database." The substrate replaces that with "verify the hash chain." The difference is the difference between administrative assurance and cryptographic assurance.

Practical use: medical records

A hospital discharges a patient. The discharge summary is finalized by the attending physician, reviewed by nursing, and signed off. That document becomes part of the patient's permanent medical record. Under HIPAA, the hospital is required to maintain audit trails demonstrating the integrity of that record -- that it has not been altered after the fact, that the version in the system today is the version that was finalized at discharge.

Today, those audit trails are database entries. The EHR system logs who accessed the record, when, and what changes were made. The audit trail is stored in the same database as the record itself, or in a separate logging database maintained by the same vendor. The integrity of the audit trail depends on the integrity of the database, which depends on the vendor, which depends on the vendor's security practices, patching cadence, and continued solvency. If the vendor is breached, the audit trail can be altered along with the records it was supposed to protect. If the vendor is acquired, the audit trail migrates to a new system under new administration. The chain of custody has administrative links at every step.

When the discharge summary gets substrated at the moment of finalization, the binding changes the nature of the audit trail. The document's SHA3-256 hash goes into the substrate. The substrate's signing message goes into Bitcoin. The 74-byte persistent footprint is the audit trail -- not a database entry that says "this record was finalized at this time," but a cryptographic proof that this exact document, these exact bytes, existed at this exact time, signed under three post-quantum families whose combined security rests on three independent hardness assumptions.

A HIPAA auditor, five years later, can take the discharge summary from the EHR system, recompute the hash, and check it against the Bitcoin anchor. If the hashes match, the document has not been altered since the substrate was minted. If they don't match, something changed -- and the auditor knows it without relying on the EHR vendor's logging infrastructure. The audit trail becomes cryptographically verifiable, not just administratively asserted. The production pipeline that mints these substrates runs at 2,216,488 auth/sec on bare-metal Graviton4. The per-document cost is $0.01. The persistent storage is 74 bytes. The verification is offline, permanent, and independent of the minting infrastructure.

Practical use: software supply chain

A CI/CD pipeline produces a binary. The binary is tested, approved, and released to customers. Somewhere between the pipeline and the customer's machine, the binary traverses a CDN, a package registry, a mirror, a corporate proxy, and whatever else sits between the build server and the endpoint. At each hop, the binary could be altered -- by a compromised mirror, by a man-in-the-middle, by a supply-chain attack that inserts a backdoor into the binary after it has passed all the tests but before it reaches the customer.

The standard defense is code signing. The build pipeline signs the binary with a private key, and the customer verifies the signature with the corresponding public key. This works, provided the signing key has not been compromised, the signature algorithm has not been broken, and the customer has a reliable way to obtain the authentic public key. The SolarWinds attack demonstrated what happens when the signing infrastructure itself is compromised -- the attacker signed the backdoored binary with the legitimate key, and every customer's verification passed.

Substriting the binary adds a layer that code signing alone does not provide. The pipeline computes SHA3-256 over the binary's bytes. That hash goes into the substrate. The substrate is signed under three post-quantum families. The 32-byte signing message goes into Bitcoin's OP_RETURN. Now the customer has two things to check: the code signature (which proves the binary was signed by someone who held the signing key) and the substrate binding (which proves that the binary's hash matches a value that was committed to Bitcoin at a specific block height).

If an attacker compromises the signing key and re-signs a modified binary, the code signature will verify -- but the substrate binding will not, because the modified binary has different bytes, which produce a different SHA3-256 hash, which does not match the OP_RETURN value that was mined into Bitcoin before the compromise occurred. The attacker would need to also alter the Bitcoin blockchain to complete the attack, which requires reversing Bitcoin's proof-of-work -- a different and vastly harder problem than compromising a signing key.

The binding is what makes this work. The substrate does not store the binary. It does not compress the binary. It does not replace the code signing infrastructure. It adds a 74-byte cryptographic anchor that chains the binary's exact bytes to an immutable public ledger, and that anchor is what makes the difference between "we trust the signing key" and "we can verify the binary against Bitcoin."

Why binding is the primitive that makes everything else work

The substrate provides five core properties: binding, tamper detection, domain separation, ZK proof compatibility, and receipt chain verification. Each of the other four depends on binding. Here is why.

Tamper detection depends on binding. Tamper detection is the property that any alteration to the original computation output can be detected after the fact. This only works if you know what the original was. The binding is what establishes the original -- it chains the substrate to the exact bytes of the computation output via H(r). Without binding, there is no reference point against which to detect tampering. You cannot detect that a document has changed if you never cryptographically committed to what the document was.

Domain separation depends on binding. Domain separation is the property that a substrate minted for one computation type cannot be confused with a substrate minted for a different computation type. The computation type byte (0x09 for ArchiveSign, 0x01 for BiometricAuth, 0x06 for BitcoinUtxo, and so on) is part of the substrate's canonical encoding, which means it is mixed into the hash before signing. The signing message SHA3-256(S) includes the type byte. If an adversary tries to reinterpret an ArchiveSign substrate as a BiometricAuth substrate, the signing message changes, and the signatures no longer verify. But this only works because the binding chains the signing message to the specific substrate bytes, including the type byte. Without binding, the type byte is just a label with no cryptographic force.

The ZK proof depends on binding. The substrate's optional ZK layer allows a prover to demonstrate, in zero knowledge, that a substrate was correctly constructed -- that the content hash H(r) in the substrate's h field is indeed the SHA3-256 digest of the claimed computation output, without revealing the computation output itself. The ZK constraint circuit checks that H(r) matches the substrate. If the binding is not correct -- if H(r) does not actually correspond to the computation output -- the ZK proof proves nothing useful. It would be proving that a hash matches, but the hash would not be bound to the right thing. Binding is the semantic anchor that gives the ZK proof its meaning.

Receipt verification depends on binding. The compact receipt commits to the three-family signature bundle via a SHA3-256 hash over the concatenated signatures. The signatures sign the signing message SHA3-256(S). The signing message commits to the substrate. The substrate commits to the computation output. This is a four-level commitment chain: receipt --> signatures --> signing message --> substrate --> document. If any link in the binding chain breaks, the receipt no longer proves what it claims to prove. A receipt that commits to signatures over a signing message that does not correspond to the actual substrate is a receipt that proves nothing. Binding is the bottom of the stack. Without it, the receipt is an empty shell.

This is why we start the five-proof series with binding. It is not the most dramatic property -- tamper detection and ZK proofs are more immediately exciting. But it is the foundational property. Every other property is a consequence of binding holding. Every other property fails if binding fails. The 74-byte substrate is, at its core, a binding machine: it takes arbitrary computation output and chains it, through three hash links, to an immutable anchor on the most durable public ledger in existence. Everything else is built on that chain.

The distillation

The raw three-family signature bundle for a single substrate is on the order of several kilobytes -- ML-DSA-65 produces a 3,309-byte signature, FALCON-512 produces a 690-byte signature, and SLH-DSA-SHA2-128f produces a 17,088-byte signature. That is roughly 21 KB of signatures for a single attestation. The substrate distills that down to 74 bytes of persistent state by committing to the signature bundle via a single SHA3-256 hash in the compact receipt, rather than storing the signatures themselves. This is a 285x distillation ratio.

The distillation works because of binding. The compact receipt's 32-byte commitment to the signature bundle is a SHA3-256 hash. The signature bundle signs the signing message. The signing message is a SHA3-256 hash of the substrate. The substrate's content hash is a SHA3-256 hash of the computation output. Every level of the construction is a binding -- a cryptographic commitment that chains one object to another. The 285x distillation is not lossy compression; it is a chain of commitments that preserves the full security of the three-family signature bundle while requiring only 74 bytes of persistent storage.

At $0.001 per mint, running on production hardware at 2,216,488 auth/sec, the economics of substrating every important document, every critical binary, every medical record, every financial filing are already viable. The question is not whether the infrastructure can handle it. The infrastructure is running. The question is whether the binding property -- the property that chains a document to Bitcoin through three hash links, each independently verifiable, each protected by three independent hardness assumptions -- is the right primitive for the post-quantum era. We think it is. The next four posts in this series will show you why.