How we made Bitcoin post-quantum without a softfork and without the per-transaction grind

There are, as of this week, two viable families of approaches to post-quantum Bitcoin that operate inside today's consensus rules. The first family is the script-layer approach — Heilman's Lamport-in-script demonstration, BINOHASH's binomial digest construction, and most recently Levy's QSB which replaces BINOHASH's quantum-vulnerable proof-of-work puzzle with a hash-to-sig construction whose security rests on RIPEMD-160 pre-image resistance. I wrote a fair review of QSB in the previous post in this series and I will not repeat the content here. The short version: QSB is excellent script-layer work that achieves quantum-safe Bitcoin transactions inside the existing 201-opcode script budget at the cost of a substantial per-transaction off-chain grind (the QSB paper reports $75 to $200 in GPU spot pricing per transaction), a non-standard transaction format that requires a private mempool service for broadcast, and a restriction to legacy pre-SegWit script execution.

The second family is the substrate-layer approach. This post describes what we built and why it takes a fundamentally different architectural position than QSB and BINOHASH — not because the script-layer approach is wrong, but because the script layer is not the only layer that needs post-quantum protection, and the off-chain layer has different constraints and therefore a different achievable design space.

The layer cake argument

Bitcoin, viewed as a system, has at least four distinct layers where cryptographic integrity matters. From bottom to top:

Consensus layer. The rules that every Bitcoin full node enforces when validating a block. The consensus rules include the signature verification rules (which signatures are valid), the script interpreter (which opcodes mean what), the UTXO accounting rules, and the block validation rules. Changing the consensus layer requires a softfork or a hardfork — a coordinated upgrade across the majority of mining hashpower and a supermajority of economic nodes. Post-quantum safety at the consensus layer would mean, for example, adding a new opcode that verifies a Dilithium signature. The Bitcoin community has not been receptive to consensus-level changes for post-quantum, and for good reasons: the consensus layer is the most difficult surface to change, and any change there has to survive intense scrutiny across the entire economic footprint of Bitcoin. Softforks are possible but rare, and post-quantum softforks specifically are not currently on any Bitcoin Core roadmap that I have seen.

Script layer. The locking scripts that individual UTXOs carry, which the consensus layer executes as part of validating spends of those UTXOs. The script layer is what QSB and BINOHASH operate on. Every UTXO's locking script is chosen by the party that created the UTXO, and the consensus rules impose limits on what the script can do (the 201 non-push opcode limit, the 10,000-byte script size limit, the specific set of valid opcodes) but allow arbitrary compositions within those limits. A clever script can implement post-quantum signature verification, as QSB demonstrates, without requiring any consensus change. This is the domain of script-layer post-quantum Bitcoin, and it is where the recent interesting work has been happening.

Application layer. The off-chain systems that produce Bitcoin transactions, consume them, interpret them, and build services around them. This includes wallets, exchanges, custody services, lightning nodes, block explorers, and a huge ecosystem of tooling that treats Bitcoin transactions as primitives for higher-level applications. The application layer is where most of the commercial value of Bitcoin is realized, and it is where most of the operational risk lives. Cryptographic integrity at the application layer is typically handled with classical signatures — ECDSA, Ed25519, RSA — and the question of what application-layer integrity looks like in a post-quantum world has been largely unanswered until now.

Attestation layer. A specialized sub-layer of the application layer that concerns itself with proving, at any point in the future, that a specific off-chain computation produced a specific output that was subsequently referenced by a Bitcoin transaction. This is the layer that the substrate operates on. It is not, in most discussions of Bitcoin, called out as a separate layer, because until now there has not been a good primitive for it. I am calling it out here because it is the layer that the substrate specifically targets, and the distinction from the script layer is important for understanding why the substrate's design choices are what they are.

Every layer has its own threats. The threat at the consensus layer is a cryptographic failure in the signature scheme that the consensus rules accept. The threat at the script layer is signature forgery against an individual locking script — the threat that QSB addresses. The threat at the application layer is many things, but the specific threat at the attestation sub-layer is provenance forgery: the ability for an adversary to produce a plausible-looking off-chain computation that claims to have produced a given Bitcoin transaction, even though the real computation was different or never happened. Provenance forgery is the threat the substrate addresses, and it is not addressed by script-layer constructions.

Here is an example to make it concrete. Suppose a regulated financial institution runs a privacy-preserving credit-scoring model on a customer's encrypted financial history. The model produces a credit decision, and the institution wants to anchor that decision to Bitcoin so that the customer, the regulator, or any future auditor can prove that the decision was made at a specific time by the specific institution on the specific encrypted input. The institution writes a Bitcoin transaction whose OP_RETURN output carries a commitment to the credit decision, and the transaction is confirmed in a block. Five years later, the customer is in a dispute with the institution about the credit decision. The customer claims the decision was different from what the institution now says it was. Who is right?

Under a script-layer-only post-quantum approach, the Bitcoin transaction is protected against signature forgery (QSB ensures that the UTXO was legitimately spent by the institution at the time of the spend), but nothing in the script layer tells us whether the OP_RETURN commitment actually corresponds to the credit decision the institution claims. The institution could produce any credit decision, hash it, and claim that was the one committed to the transaction. An adversary inside the institution could do the same. A competitor of the institution, holding a different guess at the decision, could claim their version was the one. The script-layer security does not distinguish between the true claim and any of the false claims.

Under a substrate-layer approach, the OP_RETURN output carries the substrate's 32-byte signing message, and the substrate itself — the 58-byte canonical commitment plus the 42-byte compact receipt — is stored off-chain by the institution. The substrate's content hash binds to the canonical encoding of the credit decision, and the substrate's three-family signature bundle proves that the institution's signing keys signed the substrate at the time of minting. A dispute five years later can be resolved by producing the substrate, the receipt, the signature bundle, and the institution's three-family public key set from the relevant epoch, and independently verifying that the substrate's content hash matches the SHA3-256 of the credit decision the institution claims. The script-layer security is necessary (to prove the Bitcoin transaction was legitimate), but insufficient (to prove what off-chain computation the transaction referenced).

This is the layered argument. Script-layer post-quantum work protects UTXO spending. Substrate-layer post-quantum work protects off-chain computation provenance. The two layers address different threats, and a deployment that cares about both needs both. QSB and the substrate are not competitors for the same threat; they are complements for different threats.

Why the substrate is less expensive per operation

The substrate's per-operation cost is, by construction, much lower than QSB's per-operation cost, for reasons that have nothing to do with implementation cleverness and everything to do with the layer each approach operates on.

QSB's cost is dominated by the hash-to-sig puzzle, which requires approximately 2^46 hash operations on commodity GPU hardware to find a valid DER-encoded ECDSA signature. That number — 2^46 — is fixed by the probability that a random 20-byte string satisfies the DER encoding constraints. It is a structural property of the DER format, and no amount of implementation optimization can reduce it. The cost of 2^46 hash operations on the current GPU spot market is the $75-$200 figure that the QSB paper reports. As GPU prices change, the dollar figure changes with them, but the underlying work does not change.

The substrate's cost is dominated by the SLH-DSA-SHA2-128f signing operation, which takes approximately 5 milliseconds on a single commodity CPU core. That number — 5 milliseconds — is fixed by the SPHINCS+ parameter set, not by any search operation. The substrate's signing cost is not a grind. It is a deterministic signing procedure that produces a valid signature on every call, in approximately constant time. There is no probability of failure, no search, no retry, no luck-of-the-draw. The CPU core runs for 5 milliseconds and produces a signature.

The quantitative difference between these two cost structures is enormous. Searching 2^46 hash outputs takes hours of GPU time per transaction. Producing a three-family signature takes milliseconds of CPU time per substrate. The ratio between the two is in the millions — I am deliberately not citing a specific multiplier here because the substrate's public pricing is not the subject of this post — but the qualitative difference is even larger than the quantitative one. QSB's cost is a grind cost; the substrate's cost is a compute cost. Grinds are bounded below by the search space size; compute costs are bounded below by the algorithm's deterministic work.

This is why the substrate can afford to offer radically different pricing from QSB. It is not that we are cutting corners or running at a loss. It is that the substrate's underlying computational work is fundamentally less expensive than QSB's underlying computational work, because we made a different architectural choice about where the post-quantum work lives. QSB's choice pushes the work into the script layer, which requires a grind that Bitcoin's script interpreter can verify cheaply. The substrate's choice pushes the work into the application layer, where a CPU can just run the signing algorithm without needing any proof-of-work.

Both choices are legitimate. They just have very different cost structures.

The on-chain footprint is different too

Beyond the per-operation cost, the on-chain footprint of the substrate is different from QSB's on-chain footprint, and in a way that matters for high-volume deployments.

A QSB transaction uses approximately 9,650 bytes of script and is non-standard, which means it cannot be relayed through the default Bitcoin mempool. Each QSB transaction also uses the full script budget, so you cannot batch multiple QSB protections into one transaction — each protected UTXO needs its own 9,650-byte locking script.

A substrate-anchoring transaction is a standard Bitcoin transaction with an OP_RETURN output containing a 32-byte signing message. The anchoring transaction's script is a standard OP_RETURN output plus whatever other inputs and outputs the transaction has. The 32 bytes of substrate data adds minimal overhead to the Bitcoin transaction — less than a single ECDSA signature's worth of on-chain footprint. The transaction is standard. It relays through every Bitcoin node. It uses standard mempool policy. And critically, a single 32-byte OP_RETURN commitment can anchor an entire batch of substrates via Merkle aggregation.

The batched Merkle aggregation construction is described in a separate post in this series, but the summary is: a producer can collect an arbitrary number of substrates within a batching window, combine them into a binary Merkle tree, and commit the tree's 32-byte root to a single root substrate that gets anchored to Bitcoin. The persistent footprint of the entire batch is 74 bytes (the root substrate plus its compact receipt). Per-leaf verification requires a log-depth inclusion proof of sibling hashes. At a batch size of one million leaves, the per-leaf cost in terms of on-chain bytes is 32 bytes divided by one million, or 32 nanobytes per leaf — in other words, indistinguishable from zero. At a batch size of one trillion leaves, it is 32 picobytes per leaf.

This is the "13 quadrillion attestations per Bitcoin block" claim you may have seen elsewhere. A single Bitcoin block holds roughly 13,500 substrate root commitments (at the rate current mempool capacity allows for OP_RETURN transactions). Each root can commit to a billion-leaf Merkle tree without any additional on-chain cost. 13,500 roots × 1 billion leaves per root equals 13.5 trillion attestations per block. At a trillion-leaf batch size, which is feasible with sufficient off-chain batching infrastructure, the number is 13.5 quadrillion per block. These numbers are not marketing; they are the mechanical consequence of combining Merkle tree inclusion proofs with a single-root anchoring model.

QSB cannot do this. QSB is a per-transaction construction: one locking script, one UTXO, one quantum-safe spend. Batching is not part of the QSB design space, and cannot easily be retrofitted into it, because each QSB script has to contain its own HORS commitments and its own hash-to-sig puzzle for its specific transaction. The substrate's Merkle aggregation is a feature that only works at the substrate's layer, and it is the reason the substrate's amortized per-attestation cost can be driven to effectively zero at sufficient scale.

Standard transactions, standard mempool

One more architectural difference is worth highlighting because it has significant operational consequences.

A QSB transaction cannot be broadcast through the default Bitcoin mempool. It is non-standard, and every default-config Bitcoin Core node will refuse to relay it. To get a QSB transaction confirmed, the spender has to establish a relationship with a mining pool that accepts non-standard transactions and submit the transaction directly to that pool. Marathon's Slipstream service is the example that the QSB paper references. Other pools may have equivalent services.

This adds operational complexity for the spender. You have to know which pools accept non-standard transactions, you have to maintain a relationship with one or more of those pools, you have to handle the case where your chosen pool rejects your transaction (for business or compliance reasons), and you have to accept that your transaction's confirmation time may depend on which pools happen to be mining blocks during the relevant time window. For a commercial deployment that processes many transactions per day, this is not a trivial overhead. It is manageable — mining pool relationships are a routine part of sophisticated Bitcoin operations — but it is not free.

A substrate-anchoring transaction has none of this friction. It is a standard OP_RETURN transaction. Every Bitcoin node relays it, every mining pool will mine it, and it behaves exactly like any other Bitcoin transaction from the spender's perspective. The spender does not need to know about private mempool services, does not need to maintain relationships with specific pools, and does not have to handle rejection scenarios beyond the normal mempool dynamics that every Bitcoin user already deals with.

For customers whose compliance requirements or operational constraints preclude working with private mempool services, this difference is decisive. A substrate deployment can be done on any Bitcoin node, with no special mining pool relationships, using only the standard transaction broadcast mechanisms that every Bitcoin wallet has supported for over a decade. QSB deployments require more operational sophistication, which is acceptable for sophisticated users but rules out certain categories of customers.

The composition pattern, one more time

I want to close this post with the same point I made at the end of the QSB review post, because it is the most important takeaway.

QSB and the substrate are not alternatives. They are complementary layers.

A customer who is worried about a quantum adversary stealing their coins by forging the signature that spends a UTXO should use QSB (or BINOHASH, or whatever the best script-layer construction is at the time of deployment). The substrate does not help with this threat.

A customer who is worried about a quantum adversary forging the provenance of an off-chain computation that their Bitcoin transaction references should use the substrate. QSB does not help with this threat.

A customer who is worried about both threats simultaneously should deploy both. The composition is clean: a single Bitcoin transaction can carry a QSB-protected locking script and anchor a substrate via OP_RETURN. The two mechanisms do not interact, do not interfere, and do not degrade each other. The customer pays the cost of both (the QSB grind for the script protection, the substrate signing cost for the attestation protection) and gets the security benefits of both. For a serious commercial deployment that wants defense in depth, this is the correct pattern.

The architectural point underneath all of this is that post-quantum Bitcoin is not a single-layer problem. It is a multi-layer problem, and different layers have different threat models, different cost structures, and different achievable solutions. Trying to solve everything at the script layer means accepting the script layer's cost constraints for problems that do not need to live there. Trying to solve everything at the application layer means missing the script-layer threats that really do need script-layer defenses. The right answer is a layered defense — the same architectural principle that underlies defense-in-depth in every other security domain.

The substrate is the application-layer half of that layered defense. QSB is the script-layer half. Neither is the whole answer, and neither is trying to be.

The next post in this series is on why signed commitments are not zero-knowledge proofs and why that distinction actually makes the substrate stronger for the attestation use case, not weaker. See you there.