The 74-byte post-quantum attestation primitive we built while everyone else was shipping scripts

For the last year the post-quantum Bitcoin conversation has lived inside Bitcoin script. It has been a conversation about opcodes and sighash flags and FindAndDelete quirks and whether Lamport signatures can be verified inside the 201-opcode budget of a legacy pre-SegWit locking script. The work has been technically excellent. Heilman's original Lamport-in-script demonstration opened the design space. Robin Linus's BINOHASH tightened the construction. Avihu Levy's QSB paper, published a few days ago, identified and patched a latent quantum vulnerability in BINOHASH's proof-of-work puzzle, replacing a signature-size mechanism whose security rested on ECDLP with a hash-to-sig puzzle whose security rests only on RIPEMD-160 pre-image resistance. These are real advances by serious cryptographic engineers and they deserve the attention they've been getting.

This post is about something different. We've been building in parallel. Not another script-layer construction, not another clever opcode trick, not another attempt to squeeze post-quantum signatures into the legacy Bitcoin script budget. We've been building a primitive.

The distinction matters. A protocol construction takes a specific threat in a specific context and engineers a specific defense. A primitive is a small, well-typed cryptographic object with a fixed interface and a security argument, from which many different constructions can be built. Lamport signatures are a primitive. BLS signatures are a primitive. KZG commitments are a primitive. QSB and BINOHASH are protocol constructions — brilliant ones, built on primitives like Lamport signatures and HORS aggregation. What we've been building is a primitive one layer down: an object that can be used to build substrate-attested Bitcoin scripts, or substrate-attested HTTP APIs, or substrate-attested AI inference provenance, or substrate-attested legal evidence chains, or substrate-attested anything else that needs post-quantum attestation of a computation result.

We call it the H33-74. It is 74 bytes. This post is the first of several that describes what it is, why it's 74 bytes and not 90 or 250 or 3000, why the specific cryptographic construction is what it is, and why we think this is the missing piece of infrastructure that the post-quantum Bitcoin ecosystem — and frankly the entire post-quantum transition — has been waiting for.

What the primitive is

At its most basic, the substrate is a cryptographic object that binds a computation result to a three-family post-quantum signature. The object has two parts. The first part is a 58-byte canonical commitment: a fixed-layout structure containing a version byte, a 1-byte computation type identifier, a 32-byte content hash (SHA3-256 of whatever bytes the computation produced), an 8-byte millisecond timestamp, and a 16-byte nonce. The second part is a 42-byte compact receipt: a small structure containing a version byte, an 8-bit bitfield identifying which signature families are active, a 32-byte cryptographic commitment to a three-family signature bundle, and a timestamp. The total persistent footprint is 74 bytes.

The signature bundle that the compact receipt commits to is composed of three post-quantum signatures, one from each of three NIST-standardized or NIST-Round-3-finalist families:

1. ML-DSA-65, the NIST FIPS 204 module-lattice digital signature algorithm (formerly Dilithium). Its security rests on the Module Learning With Errors problem and the Module Short Integer Solution problem over module lattices.

2. FALCON-512, the NIST PQC Round 3 alternate standardized signature. Its security rests on the Short Integer Solution problem over NTRU lattices.

3. SLH-DSA-SHA2-128f, the NIST FIPS 205 stateless hash-based signature scheme (formerly SPHINCS+). Its security rests entirely on the pre-image resistance of SHA2-256.

To forge a substrate, an adversary has to produce a valid signature under all three of these schemes simultaneously, on the specific signing message derived from the substrate's canonical encoding. That means simultaneously breaking three different mathematical hardness assumptions — module lattice problems, NTRU lattice problems, and hash pre-image resistance — assumptions that are, to the current state of cryptanalytic knowledge, as independent as the NIST PQC standardization process was able to produce. A breakthrough against one of the three families does not automatically compromise the others.

This three-family property is the heart of the security argument and we'll spend another post on it in detail. For now, the shape of the claim is: forging a substrate requires three independent mathematical catastrophes, not one.

Why 74 bytes

The specific number comes from the wire-format choices. 58 bytes for the substrate itself: 1 + 1 + 32 + 8 + 16. 42 bytes for the compact receipt: 1 + 1 + 32 + 8. Together 100 bytes naively, but the persistent storage footprint when the substrate is anchored to a blockchain is 74 bytes, because the 32-byte cryptographic commitment in the receipt and the 32-byte content hash in the substrate do not need to be stored twice in the on-chain anchoring step — the Bitcoin OP_RETURN output carries a single 32-byte signing message that binds both, with the remaining 42 bytes stored by the producer alongside the canonical data.

Why these specific widths? Because they are the smallest widths that preserve the security properties we care about. 32 bytes is the SHA3-256 output width. 16 bytes is the minimum nonce width that gives us meaningful collision resistance against the birthday bound while still fitting into a single cache line alignment. 8 bytes is the natural width for a millisecond Unix timestamp, good for approximately 292 million years before rollover. 1 byte for the version and 1 byte for the computation type are the minimum useful encodings for those fields.

Could we have made the substrate smaller? Marginally. We could have dropped the version byte, at the cost of making future format revisions harder. We could have shortened the nonce to 8 bytes, at the cost of reducing collision resistance below comfortable margins. We could have used SHA3-224 instead of SHA3-256, at the cost of reducing the content hash's security margin against Grover's algorithm. None of these cost-saving measures seemed worth it. Could we have made it larger? Easily — we could have included a key identifier, a domain description string, a content-length field, and so on. We decided against each of these on the grounds that they aren't needed for the security argument and can be appended to the canonical data (which is hashed into the content field) when an application needs them.

The result is a wire format that is the shortest we could make it while preserving a security argument we could defend against a skeptical cryptographic reviewer, and not a byte shorter. 74 bytes is not a marketing number. It's a consequence of the design.

The append-only computation type registry

The 1-byte computation type field deserves a section of its own, because it's the part of the substrate that makes it a general-purpose primitive rather than a Bitcoin-specific construction.

Each value of the computation type byte identifies a specific kind of computation whose output the substrate can attest. The values are assigned from a public, append-only registry. As of this writing, the registry includes values for biometric authentication, fraud scoring, FedNow payment attestation, Solana transaction attestation, HATS governance proofs, Bitcoin UTXO attestation, zero-knowledge KYC verification, cross-institution MPC computations, document archival signing, medical PHI operations, secret management operations, HTTP API response attestation, AI model inference provenance, capture-time media authenticity, and legal evidence chain-of-custody events, along with a generic-FHE catch-all for applications that don't fit any of the specific domains. New values are added over time as new applications are identified. Values are never removed or reassigned.

The reason the registry is append-only is the same reason IANA's port number registry is append-only: once a value is assigned a meaning, substrates produced under that meaning must remain verifiable indefinitely, which requires the meaning to remain stable. A substrate minted five years ago with computation type 0x06 must verify as a BitcoinUtxo substrate regardless of what 0x06 means in next year's application set, because the software that produced the substrate expected 0x06 to mean BitcoinUtxo and the software that verifies it five years later needs to see the same meaning.

This is boring administrative machinery, but it is the administrative machinery that turns a cryptographic construction into a protocol. The substrate is a protocol because the computation type byte creates a stable global namespace for attestable computation domains, and because the registry governing that namespace is public and append-only.

What the primitive is not

Before going any further, I want to be precise about what the substrate is not, because several common misconceptions have been recurring in conversations we've had about it over the last week.

The substrate is not a zero-knowledge proof. A zero-knowledge proof is a specific cryptographic object that allows a prover to demonstrate a statement about a computation to a verifier without revealing the witness. Substrates do not do this. Substrates are signed commitments, which are a different kind of object. A signed commitment is the signer's cryptographic attestation that a specific output was produced, vouched for by the signer's key custody. A zero-knowledge proof is the prover's cryptographic demonstration that the statement is true regardless of who is making it. The security properties are different; the use cases are different; the verification procedures are different. Confusing them is a common error and it costs credibility with anyone who knows the distinction. Substrates are signed commitments. They are not ZK proofs. A future version of the primitive may incorporate ZK proofs as an optional verification layer — we have some work in this direction — but the base substrate, the thing we're shipping now, is a signed commitment, and the security argument is a signing argument, not a proving argument.

The substrate is not a compression scheme for the underlying data. The substrate's 32-byte content hash binds to the canonical encoding of whatever the computation produced, but the substrate does not compress or store that data. A substrate attesting a 1 gigabyte FHE ciphertext is still 74 bytes persistent — the ciphertext stays wherever it already lived. Substrates are about binding, not about storing. If you want your data to travel across a network, you still need to move it. The substrate just provides a 74-byte receipt that tells the receiver which specific canonical bytes the producer attested.

The substrate is not a Bitcoin-specific construction. Bitcoin is the blockchain we most often anchor to, because the Bitcoin UTXO set is the most durable public ledger we currently have and the OP_RETURN output is the most straightforward on-chain anchoring primitive. But the substrate itself does not depend on Bitcoin. It can be anchored to any ledger that accepts a 32-byte commitment. It can be used entirely off-chain without anchoring at all. The computation type byte has many non-Bitcoin values in the registry precisely because the substrate is a general-purpose primitive.

The substrate is not a replacement for key management systems. AWS KMS, Google Cloud KMS, HashiCorp Vault, and Fortanix DSM are excellent key management systems and the substrate does not try to replace them. A substrate-based deployment typically has a key management system in the picture for protecting the three-family signing keys. The substrate is a primitive for attestation of computation results, which is a different problem than key management.

What the primitive enables

With those negatives out of the way, here are the specific things the primitive enables that are harder to do — or impossible to do — with the existing set of cryptographic tools.

Batched Merkle aggregation under a single persistent footprint. A producer can collect arbitrarily many substrates within a time window, aggregate them into a single Merkle tree, and commit the tree's 32-byte root to a single root substrate. The root substrate is signed once under the three-family signature bundle. The persistent footprint of the entire batch is 74 bytes regardless of how many leaves are in the tree. Per-leaf inclusion proofs are O(log N) sibling hashes. At a batch size of one million leaves, the per-leaf verification cost is 20 SHA3-256 hashes plus the root substrate verification, and the persistent footprint is still 74 bytes. At a batch size of one trillion leaves, it's 40 SHA3-256 hashes, and the persistent footprint is still 74 bytes. Merkle aggregation is not new. Binding a signed root to exactly 74 bytes of persistent state at any batch size is the composition we haven't seen anywhere else in the post-quantum literature.

Computation-type-specific attestation namespaces. Because the computation type byte creates a stable global namespace, two systems that have never met each other but both use the substrate with the same computation type byte can interoperate without coordination. A regulated financial institution's fraud scoring output and an independent researcher's fraud scoring evaluation can both use computation type 0x02 and both produce substrates that third-party verifiers can check against a common interpretation. This is the same property that makes DNS, IP, and HTTP interoperable.

Independent verification with no runtime dependency on the signer. Once a substrate and its compact receipt have been produced, verification is a pure function of the substrate bytes, the receipt bytes, the three-family signature bundle, and the signer's published public key set. No runtime call to the signer is required. If the signer ceases to exist, substrates produced in the past remain verifiable indefinitely, provided the public key set has been mirrored somewhere and the signature bundle is available. This is a stronger guarantee than any managed KMS can provide, because managed KMS verification typically depends on the cloud provider's continued operation.

Composition with script-layer post-quantum Bitcoin. A substrate anchored to Bitcoin OP_RETURN is orthogonal to the Bitcoin script that locks the anchoring UTXO. A holder who wants both application-layer substrate attestation and script-layer quantum-safe spending can use QSB or BINOHASH for the locking script and the substrate for the OP_RETURN anchor. The two constructions address different threat classes (forged spending versus forged attestation) and do not interfere with each other.

Generalization to non-Bitcoin applications. A substrate attesting an HTTP API response can be transmitted in four HTTP headers. A substrate attesting a capture-time media artifact can be embedded in image metadata. A substrate attesting an AI inference can be logged alongside the inference output for later audit. The same 74-byte primitive serves all these domains because the computation type byte is the switch that selects the appropriate application semantics.

The security argument in one paragraph

Informally: for any probabilistic polynomial-time adversary, classical or quantum, with full access to the signer's public keys and oracle access to the signer's signing function on arbitrary messages, the probability that the adversary produces a fresh substrate-receipt-signature triple that passes verification against the signer's public keys is negligible, under the combined assumption that the ML-DSA-65 parameter set is EUF-CMA secure under MLWE, that the FALCON-512 parameter set is EUF-CMA secure under SIS over NTRU lattices, that the SLH-DSA-SHA2-128f parameter set is EUF-CMA secure under the pre-image resistance of SHA2-256, and that SHA3-256 is collision-resistant. The reduction is straightforward from the individual signature-scheme securities: a successful substrate forgery implies a successful forgery in at least one of the three signature families, because the compact receipt's cryptographic commitment (SHA3-256 over the concatenated signature bundle) can only be satisfied by a triple of signatures that each verify against the corresponding public key. A full proof is in our whitepaper.

The three-family structure is what distinguishes this from a single-family signed commitment. A single-family signed commitment is EUF-CMA secure against a classical adversary to the extent its signature scheme is. The substrate is EUF-CMA secure against a classical or quantum adversary that cannot simultaneously break ML-DSA, FALCON, and SLH-DSA. The difference is what you give up in exchange for a cryptanalytic surprise. Under a single-family scheme, a cryptanalytic breakthrough against the chosen family is a total break — every substrate produced under that scheme becomes forgeable. Under the three-family scheme, the same breakthrough degrades the security to approximately two-family security, which is still stronger than any single-family alternative. The breaker has to work again, twice more, to complete the forgery. This is insurance against the specific failure mode that makes post-quantum signature choices hardest: the uncertainty about which cryptographic assumption survives future cryptanalysis.

What we're shipping

The reference commercial implementation of the substrate is live on production hardware today. A verifier-only reference Rust crate is published under a proprietary source-available license at github.com/H33ai-postquantum/h33-substrate-verifier; it implements the parse-and-verify path of the substrate protocol and depends only on SHA3-256 and the NIST reference implementations of the three signature families. The verifier source is available for audit, independent compilation, and reference-implementation purposes; commercial use requires a license from H33.ai, Inc. A commercial runtime that produces substrates under a customer's own three-family keypair is available under a separate commercial license; the commercial runtime runs inside a Trusted Execution Environment on the customer's own hardware, with no runtime dependency on our infrastructure. Patent pending — H33 substrate Claims 124–125.

A formal whitepaper describing the primitive, the security argument, the construction details, the batched Merkle aggregation, the efficiency measurements, and the application catalog, has been drafted and is being finalized for release to the Bitcoin developer community and the post-quantum cryptography research community. A module breakout specification describing the concrete software boundaries of the commercial implementation is also drafted. A binary release and attestation protocol specification describing how the commercial binaries are distributed to customers and how customers verify that the binaries they are running are authentic has also been drafted.

Each of these artifacts will be published over the coming days and weeks. This post is the first of a series describing different aspects of the work. Posts in the series include a deep dive on the three-hardness-assumption argument, an account of three contended-lock bugs we found in our cache layer under production load, a fair review of QSB and where it differs from a substrate-layer approach, an explanation of why signed commitments are not zero-knowledge proofs and why that actually makes them stronger for our use case, a walkthrough of the batched Merkle aggregation construction, and several other pieces. We will link each post from the series index when it's ready.

An invitation

If you are working on post-quantum cryptography, post-quantum Bitcoin, cryptographic attestation, audit infrastructure, AI provenance, compliance-grade signing, or any adjacent field, we would like your eyes on the whitepaper and the primitive spec. We would particularly like critical eyes. The construction is simple enough that any competent cryptographic reviewer can read the whitepaper in an afternoon and form an opinion, and we expect to be told about things we got wrong.

The kind of feedback that is most useful to us: wire-format choices we could have made better, security reduction steps that are informal where they should be rigorous, cryptanalytic caveats we didn't consider, applications we should have included or left out, implementation details that could be clearer. The kind of feedback that is less useful: marketing adjectives.

The substrate is a primitive. Primitives survive and spread because they solve a real problem, compose with existing cryptographic tools, and can be audited by anyone willing to put in the time. We think we have built one. Over the next several posts, we'll give you the material to verify that claim — or to tell us precisely where it falls apart. Either outcome is a useful one for us.

The next post in this series is about the three-hardness-assumption argument and why we chose it over the alternatives. The post after that is about the three contended-lock bugs we found in our cache layer when we ran the substrate at 96 concurrent workers on a bare-metal Graviton4 instance. The post after that is about QSB, what it does right, and where a substrate-layer approach does something different.

Thanks for reading. See you in the next one.