There is a specific moment I remember when the decision became obvious.
I was reading through the archived transaction records of an early Ethereum wallet — hundreds of signed transactions, every one of them sitting permanently in the public chain. The signatures were ECDSA on the secp256k1 curve. Sixty-four bytes each. Mathematically sound, by every standard in use today.
And I thought: every single one of these is a liability.
Not today. Not this year. But the signatures do not expire. The blockchain does not forget them. And the mathematics that protects them — the discrete logarithm problem on elliptic curves — has a known, published, peer-reviewed attack that a sufficiently capable quantum processor will execute in polynomial time.
Peter Shor published that attack in 1994. It is not a theory. It is an algorithm. The reason it has not been executed against Bitcoin or Ethereum is purely a hardware constraint — current quantum machines are orders of magnitude below the qubit count required. Not orders of magnitude away in difficulty. Orders of magnitude away in scale.
That gap is closing.
And the transactions will still be there when it does.
The Attack That Is Already Happening
The cryptographic community has a name for what is occurring right now, before a single production quantum computer capable of breaking elliptic curve cryptography exists.
They call it harvest-now, decrypt-later.
The attack is simple. An adversary with sufficient storage archives ciphertexts, signed transactions, and public keys today. They pay almost nothing to do this — blockchain data is public, and storage is cheap. Then they wait. When quantum hardware of sufficient scale becomes available — whether that is 2030, 2035, or 2040 — they apply quantum decryption to everything they collected.
The historical record of every classical blockchain is, under this model, a cryptographic liability that grows by every block produced.
Mohamed Mosca, one of the most cited researchers on this threat, has written that organisations should assume post-quantum-capable adversaries will exist within ten to fifteen years and build their security posture accordingly. He wrote that in 2018. We are now eight years into that window.
Most blockchain protocols are still producing classical signatures at millions of transactions per day and adding to the archive.
Why Migration Is Not the Answer
The standard industry response to this threat is: we will upgrade when we need to. Plan a post-quantum migration. Execute it before the hardware arrives.
I spent a long time examining this response. The more carefully I looked, the less I believed it.
Coordinated cryptographic migrations of deployed distributed systems are among the hardest engineering and coordination problems in existence. They require every participant in the ecosystem to upgrade simultaneously: validators, wallet software, browser extensions, hardware wallets, exchanges, custodians, indexers, bridges, relayers, block explorers, developer tooling, and the users who rely on all of them.
Consider the HTTPS ecosystem. The deprecation of SHA-1 certificates began formally in 2014, after years of academic warnings. Browser vendors gave the industry advance notice measured in years. The economic incentive to upgrade was clear. The technical lift was manageable compared to a full cryptographic primitive replacement.
The migration still dragged for five years and required browser vendors to impose hard cutoffs — refusing to load pages with SHA-1 certificates — to reach completion.
A blockchain migration is categorically harder. Validators running staking infrastructure cannot simply receive an update notification. Wallets holding private keys in legacy formats cannot be automatically upgraded. Bridge contracts on external chains require separate governance processes on those chains. A user who has not touched their wallet in three years is still holding funds that need to migrate.
And unlike the HTTPS migration, the historical record of a blockchain — the archive that the quantum adversary is already collecting — does not become safe after the migration. The pre-migration transactions remain permanently on-chain, permanently signed with classical keys, permanently vulnerable to retroactive decryption.
Migration secures the future. It does not protect the past.
A protocol that launches classical and migrates later will always have a permanent classical-era history. A protocol that launches post-quantum has no such liability.
That is the decision we made with BLEEP.
What We Actually Built
BLEEP is a Layer 1 blockchain. Blocks every three seconds. Ten shards. Ethereum-compatible and WebAssembly-compatible smart contracts. Cross-chain bridges to Ethereum, Solana, Cosmos, Binance Smart Chain, and Polkadot. On-chain governance with zero-knowledge voting. Self-healing shard recovery. A full economic model with an EIP-1559-style fee market.
None of that is the interesting part.
The interesting part is that every single cryptographically sensitive operation in the protocol uses a NIST-finalised post-quantum primitive at Security Level 5. No exceptions. No fallbacks. No "we'll replace this later."
Transaction signing and block signing: SPHINCS+-SHAKE-256f-simple (FIPS 205)
SPHINCS+ is a stateless hash-based signature scheme. Its security reduces to the one-wayness of the SHAKE-256 hash function. There is no algebraic structure — no group law, no discrete logarithm — for Shor's algorithm to exploit. A quantum computer of any scale gains nothing against it. The security assumption is among the most conservative in post-quantum cryptography: if SHA-3 and SHAKE-256 remain one-way functions, SPHINCS+ signatures are secure.
The tradeoff is size. A SPHINCS+ signature at Security Level 5 is 7,856 bytes. An ECDSA signature is 64 bytes. On a block with 4,096 transactions, the aggregate signature data is approximately 32 megabytes. This is a real cost. We accepted it as the explicit price of the most conservative post-quantum security assumption available.
Key encapsulation: Kyber-1024 / ML-KEM-1024 (FIPS 203)
Every secure channel between validators uses Kyber-1024 for key encapsulation. Every peer-to-peer session, every onion-routed message hop, every validator binding. The security of ML-KEM reduces to the hardness of the Module Learning With Errors problem — a lattice problem for which no quantum algorithm is known to provide significant advantage.
Zero-knowledge proofs: Winterfell STARK
For block validity proofs and cross-chain bridge verification, we chose Winterfell STARKs over SNARKs. The reasoning comes down to two properties.
First, transparency. STARKs require no trusted setup ceremony. There is no structured reference string to generate, no multi-party computation to coordinate, no ceremony participant whose key material must be trusted to have been properly destroyed. Any party can generate or verify a proof using only the public inputs and the verifier library. There is nothing to trust.
Second, post-quantum security. SNARK constructions like Groth16 and PLONK are built on pairing-based cryptography — elliptic curve constructions that Shor's algorithm breaks. A STARK's security reduces to collision resistance of hash functions. The same conservative assumption as SPHINCS+.
The block validity proof circuit takes five public inputs — block index, epoch ID, transaction count, Merkle root hash, and validator public key hash — and proves structural consistency and proposer key possession. Verification requires only the Winterfell verifier library. No pre-existing key material. No trusted third party.
The post-quantum boundary
This is the complete list of operations secured by post-quantum primitives in BLEEP:
Transaction signing (SPHINCS+), block signing (SPHINCS+), peer-to-peer message authentication (SPHINCS+), key encapsulation (Kyber-1024), block validity proofs (Winterfell STARK), cross-chain bridge proofs (SPHINCS+-bound STARK transcripts), identity proofs (SHA3-256 Sparse Merkle Trie paths), and audit log chaining (SHA3-256 Merkle chain).
No classical public-key primitive — no secp256k1, no Ed25519, no BLS, no x25519 — appears on any of these paths.
The Decision We Made That Cannot Be Undone
Early in the design process, we had a debate about constitutional parameters — the values that define the protocol's economic properties. Maximum token supply. Maximum inflation rate. Fee burn percentage. Finality threshold.
The conventional approach is to protect these values with governance: a proposal requires a supermajority to change them, making them practically immutable.
We rejected this approach. A governance-protected value can still be changed by a sufficiently motivated stakeholder coalition. It requires coordination, but it is possible. More importantly, it requires an honest assessment by validators and token holders in the moment — under economic pressure, under adversarial conditions — that the change is wrong.
We wanted something stronger.
BLEEP's constitutional parameters are enforced by Rust compile-time assertions. The 200 million BLEEP maximum supply. The 500 basis point maximum per-epoch inflation. The 25% fee burn floor. The 66.67% finality threshold.
const_assert!(MAX_SUPPLY == 200_000_000 * 10u64.pow(8));
const_assert!(MAX_INFLATION_RATE_BPS <= 500);
A code change that violates any of these assertions does not compile. A codebase that does not compile cannot be deployed. A governance proposal that would raise the supply cap above 200 million BLEEP produces a codebase that the build system refuses to accept.
These are not promises. They are machine-verified invariants.
An independent security audit reviewed 16,127 lines of Rust across six crates and identified 14 findings — 2 critical, 3 high, 4 medium, 3 low, 2 informational. All critical and high findings are resolved. The audit report is published in the repository. We included the two acknowledged findings with full explanations because a published audit that acknowledges imperfections is more credible than one that does not.
What Running It Actually Looks Like
When a BLEEP node boots, this is what happens:
✅ SPHINCS+-SHAKE-256f-simple keypair generated (PK=64 bytes, SK=128 bytes)
✅ Kyber-1024 keypair generated (PK=1568 bytes)
✅ STARK prover/verifier — no trusted setup required
✅ STARK block circuit ready
✅ STARK batch tx circuit ready
✅ Chain adapters: ETH, BSC, SOL, COSMOS, DOT
✅ BlockProducer online (3s slots, PoS, VM execution, P2P gossip)
✅ 46 RPC endpoints active
The SPHINCS+ keypair is generated first, before anything else initialises. The STARK prover announces, explicitly, that no trusted setup was required. These are not log messages added for appearance — they reflect the actual initialisation sequence in the code.
When a transaction enters the mempool, the first thing the protocol does — before checking the nonce, before checking the balance — is verify the SPHINCS+ signature. A transaction without a valid post-quantum signature is dropped at the gate.
When we ran the interchain demo — transferring one BLEEP to an Ethereum Sepolia address — the intent entered an executor auction with a 15-second window, appeared in the pending intent pool within a second of submission, and was logged at the bleep_connect_layer4_instant crate level with its full cross-chain parameters. The destination amount, the slippage tolerance, the executor reward cap, the expiry timestamp — all on-chain, all verifiable.
In the mempool debug logs, the actual SPHINCS+ signature bytes are visible:
[DEBUG TxPool] Total signature length: 49920 bytes
[DEBUG TxPool] Sig bytes length: 49856 bytes
49,856 bytes divided by 7,856 bytes per SPHINCS+ signature equals exactly 6.34 signatures. Real post-quantum cryptography running in a real node. Not simulated.
Why We Did It Before Anyone Else
The honest answer is that we looked at the harvest-now decrypt-later threat model and concluded that the correct time to establish post-quantum foundations is before a protocol accumulates economic value and ecosystem dependencies — not after.
Every transaction BLEEP produces from its genesis block is post-quantum secured. There is no classical-era history. There is no archive of ECDSA signatures waiting to be retroactively decrypted. The liability that is accumulating on every classical blockchain with every block produced does not accumulate here.
NIST finalised FIPS 203 and FIPS 205 in 2024. The algorithms are standardised. The security assumptions are well-studied. The Rust libraries are production-quality. The technical prerequisites existed. What was missing was a protocol willing to accept the bandwidth and computation overhead of post-quantum primitives from day one rather than waiting until the pressure to migrate became unavoidable.
We accepted that overhead. The 7,856-byte SPHINCS+ signature. The larger Kyber public keys. The STARK proof generation time. These are quantified, documented costs — not hidden, not minimised.
The alternative — launching with classical cryptography and planning a future migration — means inheriting the coordination problem, accepting permanent classical-era liability, and depending on the assumption that quantum hardware will not reach the required scale before the migration completes.
We do not think that is a bet worth making on infrastructure intended to last decades.
BLEEP is our answer to that conclusion.
The codebase is open source. The audit is published. The testnet is running.
The quantum threat to classical blockchains is real, growing, and already in motion. We built the answer before the industry was ready to hear the question.
BLEEP is a post-quantum Layer 1 blockchain built in Rust. Protocol Version 4 is live on testnet with 10 shards, Ethereum cross-chain integration on Sepolia, and a completed independent security audit. The codebase is open source at github.com/BleepEcosystem/BLEEP-v1. An independent security audit has been completed with all critical and high findings resolved and the full report published in the repository.
Whitepaper · GitHub · Discord · Telegram
Top comments (0)