Post-Quantum Protection for Any Blockchain in 74 Bytes

The Quantum Problem Blockchains Don't Want to Talk About

Every major blockchain uses elliptic curve cryptography for transaction authorization. Bitcoin uses secp256k1. Ethereum uses secp256k1. Solana uses Ed25519. These algorithms produce compact signatures—64 to 65 bytes—and that compactness is baked into every protocol rule, every fee model, every block size calculation.

Shor's algorithm, running on a sufficiently powerful quantum computer, breaks all of them. Not theoretically. Mathematically. The discrete logarithm problem that protects every wallet, every smart contract, every bridge—it becomes trivial.

The timeline for "sufficiently powerful" is debatable. NIST says organizations should begin migrating now. Some estimates say 10 years. Some say 15. The point isn't the exact date. The point is that every blockchain currently in production is protected by cryptography with a known expiration date.

And the solutions being discussed have a problem of their own.

The Size Problem

NIST has standardized three families of post-quantum signature algorithms. Each relies on a different mathematical hardness assumption. Each produces signatures dramatically larger than what blockchains are built for.

ML-DSA (Dilithium) is based on the Module Learning With Errors problem over structured lattices. It's the primary NIST recommendation. A single signature at security Level 3 is 3,309 bytes. That's 52 times larger than a Schnorr signature.

FALCON is based on the Short Integer Solution problem over NTRU lattices—a different lattice family from Dilithium. Signatures are smaller, around 657 bytes, but still 10 times larger than classical signatures. FALCON also uses floating-point arithmetic internally, which creates implementation complexity.

SPHINCS+ (SLH-DSA) is hash-based. It relies on no lattice assumptions at all—only the security of hash functions. This makes it the most conservative choice. It's also the largest: 17,088 bytes for a single signature at the fastest parameter set.

If you want defense in depth—which you should, because betting your entire chain's security on one mathematical assumption is the same mistake RSA users are about to pay for—you want at least two of these families, ideally all three. That's around 21,000 bytes of signatures per transaction.

For context:

• A Bitcoin transaction averages about 250 bytes. Adding 21KB of PQ signatures makes every transaction 85 times larger.
• Bitcoin processes roughly 600,000 transactions per day. At 21KB per transaction, that's 12.6 GB of additional chain data per day—just from signatures.
• Solana processes 65,000 transactions per second. At 21KB each, that's 1.37 TB of signature data per day.
• Even using just Dilithium alone (3,309 bytes), Bitcoin's chain would grow by 1.98 GB per day from signatures. That's 723 GB per year.

This isn't a theoretical concern. This is the math that every blockchain foundation has to deal with when someone on their team says "we should add post-quantum signatures."

The Consensus Problem

Size isn't the only issue. Verifying post-quantum signatures requires new signature verification logic in consensus.

On Bitcoin, that means a new opcode—something like OP_CHECKPQSIG—which requires a soft fork. A soft fork requires a BIP (Bitcoin Improvement Proposal), years of review, miner signaling at 95% threshold, and a community that can't agree on anything faster than geological time.

On Ethereum, it's an EIP and a hard fork. On Solana, it's a program upgrade. Each chain has its own governance process, and each process takes time measured in years, not months.

And even after the governance process completes, you still have the size problem. The signatures are in the block. Every full node stores them. Every archival node stores them forever. The chain grows at a rate that wasn't in anyone's capacity plan.

So you have two problems: getting the community to agree on a change, and living with the consequences of that change on block space.

Why Compression Isn't Enough

The natural first response is to compress the signatures. Zero-knowledge proofs can prove "I verified a valid signature" in less space than the signature itself. STARK proofs, for example, can compress a Dilithium + FALCON verification (about 3,966 bytes of raw signatures) into a proof of around 440 bytes.

That's a 9x compression, and it's real—we built it. But 440 bytes is still 7 times larger than a Schnorr signature. And if you want all three families, the proof grows further. More importantly, the compressed proof still goes on-chain. Every node still stores it. The chain still grows.

Compression reduces the problem. It doesn't eliminate it.

A Different Question

What if the signatures don't need to be on-chain at all?

Think about what a post-quantum signature actually proves. It proves that a specific private key, which is secure against quantum computers, authorized a specific action at a specific time. Once that's been verified, the verification result is what matters—not the raw signature bytes.

You don't carry a notarized document everywhere you go. You carry the notary seal. The document stays on file. The seal is small. The seal is what people check. If they need to see the full document, they know where to find it.

The question becomes: what's the smallest possible artifact that cryptographically proves post-quantum verification occurred, without carrying the raw signature weight?

The Answer: 74 Bytes

We built a system that reduces the persistent footprint of a three-family post-quantum attestation to 74 bytes total.

32 bytes go on-chain. This is a cryptographic hash—a collision-resistant commitment to the specific computation, the specific time, and the specific context that was attested. It fits inside a Bitcoin OP_RETURN (well under the 80-byte standard limit), a Solana PDA, or an Ethereum storage slot. It's smaller than the Schnorr signatures Bitcoin already uses.

42 bytes go off-chain. This is a verification receipt—a compact proof that three independent post-quantum signature families (lattice/MLWE, lattice/NTRU, and hash-based) each independently signed the same message and each independently verified. The receipt binds to the on-chain hash. Tamper with either and the binding breaks.

The 42-byte receipt lives off-chain and serves lookups in under a microsecond. Anyone who wants to verify the attestation queries the receipt by the on-chain hash. The response tells them: yes, three PQ families verified this, at this time, with these algorithms.

The raw signatures—all 21,054 bytes of them—are ephemeral. They exist in memory for approximately 15 milliseconds while being verified. After verification, they are compressed into the 42-byte receipt and securely erased. They never touch disk. They never leave the process. They never go on-chain.

What Blockchains Get

No block size impact

32 bytes per transaction on-chain. At Bitcoin's 600,000 transactions per day, that's 19.2 MB of additional chain data—compared to 12.6 GB for raw three-family signatures. That's a 657x reduction in chain growth.

No validator changes

The 32-byte hash goes in a standard OP_RETURN output, a PDA account, or a contract storage slot. No new opcodes. No new precompiles. No consensus upgrade. Validators don't need post-quantum libraries. The PQ verification happens off-chain, before the transaction is broadcast.

No fee model disruption

Transaction sizes barely change. A Bitcoin transaction with a 32-byte OP_RETURN adds 69 bytes to the output (8-byte value + 1-byte script length + 60-byte script). That's 276 weight units—about 69 vbytes. At 10 sat/vB, that's 690 sats. Less than a dollar. Compare that to putting a Dilithium signature on-chain: 3,309 bytes of non-witness data would cost over 33,000 sats.

Three mathematical families, not one

This is the part most proposals get wrong. They pick one PQ algorithm and build around it. If that algorithm breaks—and mathematical breakthroughs are by definition unpredictable—every transaction ever signed with it is retroactively insecure.

Our attestation covers three independent families:

• Lattice/MLWE (Dilithium): Based on the Module Learning With Errors problem. Breaking it requires solving a hard problem on structured lattices.
• Lattice/NTRU (FALCON): Based on the Short Integer Solution problem over NTRU lattices. Different lattice construction from Dilithium. A breakthrough in MLWE doesn't automatically translate to NTRU.
• Hash-based (SPHINCS+): Based purely on hash function security. No lattice assumptions at all. If every lattice scheme ever invented breaks tomorrow, SPHINCS+ still holds.

An attacker would need to break all three families simultaneously to forge an attestation. That requires three independent mathematical breakthroughs, each targeting a different hardness assumption. The probability of all three failing at once is, for practical purposes, zero.

Works today

This is not a proposal. It's not a whitepaper. It's not a "we could build this if you fund us." It's running in production. We have 3,696 tests passing across the integrated products. The substrate crate is 1,724 lines of Rust. Every component has been compiled, tested, and deployed.

The Honest Tradeoff

We should be clear about what this is and what it isn't.

This is not consensus-level PQ protection. The 32-byte on-chain hash is not verified by Bitcoin Script, Solana BPF, or the EVM. It's an attestation that lives alongside the transaction, not a signature that gates the transaction. A quantum attacker who can break secp256k1 can still spend UTXOs and move tokens—the on-chain consensus rules haven't changed.

This is application-layer PQ protection. It gives wallets, exchanges, custodians, and block explorers a way to verify that a transaction was PQ-attested before processing it. If a UTXO was attested at block height X and then moved at block height Y without a new attestation, that's a red flag. If every legitimate transaction carries a 32-byte PQ attestation and a sudden transfer doesn't, PQ-aware infrastructure can flag it, delay it, or reject it.

This is a bridge to consensus-level changes. The soft forks and hard forks and governance processes that will eventually add PQ signature verification to consensus—those are coming, and they're the right long-term answer. Our 74-byte attestation is what works today while those changes make their way through multi-year governance pipelines. When the consensus change arrives, the 32-byte on-chain anchor can evolve to reference a consensus-verified signature instead of an application-verified one. The architecture doesn't need to change. The byte count doesn't change. The on-chain footprint is the same.

The Scale Math

To understand why this matters, run the numbers at real blockchain scale.

Bitcoin

~600,000 transactions per day. The 42-byte off-chain receipt costs 25.2 MB of storage per day. Annual: 9.2 GB. A decade of every Bitcoin transaction PQ-attested fits in 92 GB. That's one machine. The on-chain cost is 32 bytes per transaction: 19.2 MB per day, 7 GB per year. Indistinguishable from normal chain growth noise.

Solana

65,000 transactions per second at peak. The off-chain receipts cost 235 GB per day at max throughput. That's one high-memory server for hot storage, with warm and cold tiers for older receipts. The on-chain cost is 32 bytes per transaction: 178 GB per day. Solana already handles this kind of data volume.

Ethereum

~1.2 million transactions per day. Off-chain receipts: 50 MB per day. On-chain: 38 MB per day. Trivial.

At no scale does the 74-byte approach create a storage problem that doesn't already exist from the blockchain's normal operation.

Domain Separation

One architectural property that matters for multi-purpose blockchains: not all PQ attestations are the same, and the protocol enforces this.

The substrate carries a computation type identifier that distinguishes between different categories of attested computation. A biometric authentication attestation carries a different type value than a payment attestation, which carries a different type value than a KYC verification.

These type values are assigned from an append-only registry. Once a value is assigned to a computation category, it's permanent. No value is reused, reassigned, or retired. Because the type value is inside the substrate, and the substrate is inside the signing message, and all three PQ algorithms sign the same message—the type value is covered by the post-quantum signatures. You cannot take an attestation meant for one context and replay it in another.

This is protocol-level replay prevention. It's not application metadata that sits outside the signature boundary. It's inside the signed payload. Stripping it or changing it invalidates every signature.

Chain-Agnostic by Construction

The same 74 bytes work on every blockchain. The 32-byte on-chain hash is a SHA3-256 digest—it's just bytes. Any chain that can store 32 bytes in an output, an account, or a storage slot can carry it.

We've validated this on:

• Bitcoin: OP_RETURN output (34-byte script: 0x6a 0x20 + 32 bytes). 172 weight units.
• Solana: PDA (Program Derived Address) seeded by the 32-byte hash.
• Ethereum: Contract storage or calldata. 32 bytes fits in a single storage slot.

The off-chain receipt is also chain-agnostic. It's 42 bytes of opaque data, keyed by the on-chain hash. Any infrastructure that can store and retrieve 42 bytes by a 32-byte key can serve as the verification layer. The receipt format is the same regardless of which chain anchored it.

This means a single integration gives a blockchain ecosystem post-quantum protection across every use case: payments, DeFi, NFTs, identity, governance, bridges—all using the same 74-byte attestation format.

What Happens If a Family Breaks

This is the scenario everyone worries about but few design for.

Suppose a breakthrough in lattice cryptography breaks Dilithium. (This is not expected, but cryptography is a field where "not expected" has been wrong before.)

In a single-algorithm system, every transaction ever signed with Dilithium is now insecure. Retroactively. There's nothing to fall back to.

In our three-family system, the other two families still hold. FALCON is also lattice-based (NTRU), so depending on the nature of the breakthrough, it might also be affected—but SPHINCS+ is hash-based with zero lattice assumptions. Even if both lattice families fall, the hash-based attestation survives.

And because the 42-byte receipt records which families verified (via a bitmask), a verifier can assess the current trustworthiness of an attestation given the current state of cryptographic knowledge. An attestation where all three families are intact is stronger than one where only hash-based is intact—but both are verifiable, and neither requires re-signing.

The protocol degrades gracefully instead of failing catastrophically. That's the difference between defense in depth and a single point of failure.

The Upgrade Path

When a blockchain eventually adds native PQ signature verification through its governance process, the 74-byte attestation doesn't become obsolete. It becomes more powerful.

Today, the 32-byte on-chain hash is an application-layer attestation. PQ-aware wallets check it. PQ-aware exchanges verify it. But consensus doesn't enforce it.

After a consensus upgrade, the 32-byte hash can serve as the anchor for a consensus-verified proof. The attestation format doesn't change. The on-chain footprint doesn't change. The off-chain receipt format doesn't change. What changes is the trust model: the PQ verification moves from "the application layer verified this" to "consensus verified this."

The 74-byte format was designed with this evolution in mind. It's not a temporary hack that gets thrown away when the "real" solution arrives. It's the persistent layer that survives the upgrade.

The Question for Every Blockchain

Every chain has to answer the same question: how do we protect our users against quantum computers without destroying our block space economics?

The options are:

1. Do nothing and hope quantum computers are further away than they seem. NIST disagrees with this approach. So do the national security agencies of every major government that has issued PQ migration guidance.
2. Add a PQ signature scheme to consensus. This is the right long-term answer, but it takes years of governance and permanently adds thousands of bytes per transaction to your chain.
3. Add a 32-byte PQ attestation today, with three algorithm families, no consensus changes, and an upgrade path to consensus verification when you're ready. 74 bytes. Works now.

These aren't mutually exclusive. Option 3 works while you're doing option 2. And option 3 costs so little in block space that you'd never need to remove it even after option 2 is live.

32 bytes on-chain. The 42-byte verification receipt lives off-chain and serves lookups in under a microsecond. Three independent mathematical families. 69 tests. Running in production.

We built it. It works. Reach out if you want to see it run against your chain.