PricingDemo
Log InGet API Key
H33-128H33-CKKSH33-256H33-FHE-IQH33-TFHEFHE OverviewH33-CompileZK LookupsBiometricsH33-3-KeyH33-MPCZKP-AIRPQC ArchitecturePQ VideoStorage EncryptionAI DetectionEncrypted Search
Blog · April 14, 2026 · Eric Beans · 9 min read

We Anchored the First H33 Substrate to Bitcoin. It's No Longer Theoretical.

On April 14, 2026, we minted an H33 substrate, signed it with three independent post-quantum signature families, and anchored it to Bitcoin mainnet. The signing message was committed to the chain two ways in a single transaction: a Taproot P2TR output and a standard OP_RETURN. Both verified. Both standard. No soft fork. No new opcodes. Anyone on earth can verify it right now.

The data attested was simple: "First H33 Substrate anchored to Bitcoin. April 14 2026. Eric Beans, CEO, H33.ai Inc."

The implications are not.

What the Transaction Proves

The transaction proves that a 74-byte post-quantum attestation primitive can be anchored to Bitcoin mainnet today, using existing transaction formats, existing relay policy, and existing full-node verification logic. No protocol changes were required. No miners were consulted. No BIP was filed. The transaction was broadcast through the standard mempool and confirmed by real miners on the real network.

Network
Bitcoin mainnet

TXID
7f8d9ef2d5625d7e3acbc269daac21087ce6b7d77f8e4ec369aabdcdb028b4a7

Taproot P2TR Output
bc1ph4s0l2d6jhjt6ntuemuvz5amar7t9h6dl2j73x898shyyyu80edqr4v5u9 (546 sats)

OP_RETURN (32-byte signing message)
1624756140f31ecd61c19d5c1427f221809a11893257b39bf601684e629d7af3

Verify it yourself
mempool.space/tx/7f8d9ef2...028b4a7

The 6a20 prefix is Bitcoin's standard OP_RETURN marker followed by a 32-byte push. The 32 bytes that follow are the SHA3-256 hash of the 58-byte substrate — the signing message m(S) defined in our whitepaper. That same signing message is also committed via a Taproot key-path tweak on the P2TR output. Two independent commitment methods. One transaction. Same 32-byte value.

What Was Signed

Before the signing message reached the chain, the substrate was signed by three independent post-quantum signature families:

FamilyStandardHardness AssumptionSignature SizeSigning Time
ML-DSA-65FIPS 204Module-LWE (lattice)3,309 bytes372 µs
FALCON-512Draft FIPS 206SIS over NTRU (lattice)666 bytes182 µs
SLH-DSA-SHA2-128fFIPS 205SHA-256 pre-image (hash)17,088 bytes24,082 µs

Total raw signature weight: 21,063 bytes. Total persistent footprint after compression: 74 bytes — 32 bytes on-chain, 42 bytes in the compact receipt held off-chain by the attester. That's a 285× compression ratio. The raw signatures are ephemeral: verified once at mint time, then discarded. Only the commitment and the receipt persist.

The security property is straightforward: forging this attestation requires simultaneously breaking all three signature schemes. Those three schemes rest on three mathematically independent hardness assumptions. A breakthrough against lattice cryptography does not help against hash-based signatures. A breakthrough against NTRU does not help against module-LWE. An adversary must break all three, independently, to forge a single substrate.

Why Both Taproot and OP_RETURN

The whitepaper describes two anchoring methods. We used both in the same transaction to prove that both work and that they compose naturally.

Taproot key-path tweak is the elegant method. The signing message is absorbed into the Taproot output key via Q = P + H(P || m(S)) · G. This adds zero marginal bytes to the transaction — the Taproot output exists regardless, and the tweak is invisible to anyone who doesn't know the internal key. The commitment is present but undetectable. This is the method we recommend for production deployments where on-chain footprint matters.

OP_RETURN is the explicit method. The signing message is written as a standard 34-byte OP_RETURN output (2-byte script prefix + 32-byte payload). It's visible to anyone examining the transaction and requires no knowledge of the internal key to verify. This is the method we recommend when transparency and independent verifiability are more important than stealth.

Neither method requires a soft fork, a new opcode, or any modification to Bitcoin's consensus rules. Both have been standard since Taproot activated in November 2021. We simply hadn't used them for this purpose until today.

The Chain of Verification

Here is the complete verification chain, from the original message to the on-chain commitment:

"First H33 Substrate anchored to Bitcoin. April 14 2026. Eric Beans, CEO, H33.ai Inc."

This message is the computation result r. The substrate construction proceeds as follows:

1. Mint. The message is hashed: h = SHA3-256(r). A 58-byte substrate S is constructed: version byte (0x01), computation type (0x06 = BitcoinUtxo), the 32-byte content hash, an 8-byte millisecond timestamp, and a 16-byte random nonce.

2. Sign. The signing message is computed: m(S) = SHA3-256(S). This 32-byte value is signed under all three PQ families. The three signatures are verified immediately. A 42-byte compact receipt is produced, committing to the signing message, all three public keys, and all three signatures under a domain-separated, length-prefixed construction.

3. Anchor. The 32-byte signing message is committed to Bitcoin mainnet via both Taproot key-path tweak and OP_RETURN in a single transaction. The transaction is broadcast through the standard mempool and confirmed by miners.

4. Verify. An independent verifier retrieves the substrate, the compact receipt, and the signature bundle. They recompute the signing message from the substrate, verify all three signatures against the signer's public keys, and check that the OP_RETURN payload matches the signing message. Every step is a pure function of public data. No interaction with H33. No network calls beyond fetching the Bitcoin transaction.

The chain is cryptographically complete. Every link is independently verifiable. Every link is post-quantum secure.

What This Means for Bitcoin

Bitcoin was designed for value transfer. It was not designed to attest the world's computation. But its architecture — immutable, globally replicated, permissionless data embedding — turns out to be exactly what a computation attestation layer needs.

What we demonstrated today is that Bitcoin's existing transaction infrastructure, unmodified, is sufficient to serve as a global post-quantum attestation anchor. The substrate does not extend Bitcoin. It does not require a single line of consensus code to change. It composes with Bitcoin's existing Taproot mechanism to surface a capability that the protocol has possessed since block 709,632 but that has not previously been exercised at the primitive level.

This is not a claim about Bitcoin's design intent. It is an observation about architectural sufficiency. The substrate supplies what Bitcoin lacks: post-quantum signature security under three independent hardness assumptions, computation-type domain separation, and batched Merkle amortization that drives the per-attestation cost toward zero. Bitcoin supplies what the substrate lacks: global immutability, permissionless timestamping, and a fifteen-year track record of adversarial resilience. Neither object alone provides both sets of properties. The composition does.

Relationship to Script-Layer Constructions

This work is complementary to the excellent recent script-layer post-quantum constructions by Levy (QSB) and Linus (BINOHASH). Their constructions protect the UTXO's spendability — they ensure that a quantum adversary cannot forge the spending transaction. Our substrate attests the computation that produced the UTXO — it ensures that the off-chain computation behind the transaction is provably bound to the on-chain commitment under three independent post-quantum hardness assumptions.

The two constructions operate at different layers and solve different problems. A production deployment that cares about both script-layer quantum safety and application-layer computation provenance should deploy both. We recommend that deployment pattern for institutions.

What Happens Next

The whitepaper is live at h33.ai/h33-74/whitepaper. It includes an interactive demo where you can mint a substrate from your browser — your input is hashed, signed by three PQ families on our Graviton4 backend, and the receipt is returned in a single round-trip. Open your Network tab and watch it happen.

The substrate verifier is a source-available Rust crate at github.com/H33ai-postquantum/h33-substrate-verifier. Any developer can verify any substrate locally, using only public keys and local cryptography, without contacting H33 or any third-party service.

We've also shipped H33 Sentinel — a runtime binary attestation watchdog that uses the same substrate primitive to attest every binary running on your infrastructure. If a binary wasn't attested at deploy time, Sentinel kills it. We're running it on our own servers. We eat our own dogfood.

The primitive supports eight computation types today: Bitcoin UTXO attestation, HTTP API response attestation, AI inference provenance, capture-time media authenticity, legal evidence chain-of-custody, federated ML mesh, authenticated relay messaging, and identity credential attestation. All eight use the same 74-byte primitive. All eight are in production.

The 74-Byte Claim

We've been making the claim for months: any computation result, regardless of data volume, can be attested under three independent post-quantum signature families at a persistent footprint of exactly 74 bytes. An 8K video. A clinical trial dataset. A legal evidence chain. A financial settlement. All 74 bytes.

As of this morning, that claim is no longer theoretical. It's a Bitcoin transaction. It's mined. It's independently verifiable. The signing message is on-chain. The receipt is in our hands. The signatures were produced by three NIST-standardized post-quantum families on a Graviton4 metal instance.

We invite the Bitcoin developer community, the post-quantum cryptography community, and anyone interested in the intersection of the two to review the whitepaper, run the live demo, inspect the verifier crate, and tell us what we got wrong. Corrections to any technical statement will be incorporated in a revised version with attribution to the contributor at their option.

Read the whitepaper. Run the demo. Verify the proof.

Read the Whitepaper

H33.ai, Inc. · Patent pending — Claims 124–125 · support@h33.ai