Contents
  1. 1The protocol layer is quantum-safe
  2. 2Choice, not coordination
  3. 3What is deployed, and what should come next
  4. 4Bytes, cycles and propagation
  5. 5The layers above
  6. 6The P2P layer
  7. 7Keys and HD wallets
  8. 8Fiber
  9. 9Through the talk’s frameworks
  10. 10The policy question changes shape
  11. Sources

Part 1 covered a talk by Fraunhofer Singapore, Please Mind the Gap: From Migration Models to Operational Reality, and a conversation afterwards about why Bitcoin is hard to migrate. This part applies the talk’s frameworks to CKB: the five readiness dimensions, the crypto-agility components and the anti-patterns.

On Bitcoin and Ethereum the post-quantum question reaches into the consensus rules, and changing those takes a fork and a governance fight. CKB’s protocol layer is already quantum-safe: its consensus uses no cryptography a quantum computer breaks, and post-quantum signatures are locks that run on mainnet today. The quantum problems that remain are in the layers above. Look at the whole ecosystem rather than the protocol alone, and the research behind the talk points to the flip side: with nothing to fork, those problems are in front of CKB now rather than hidden behind a consensus upgrade. Facing and solving those is what staying ahead requires.

1. The protocol layer is quantum-safe

Two properties do it. Consensus is hash-based proof of work, which depends on no cryptography a quantum computer is known to break. Other designs have more to replace than validator signatures: BLS aggregates, threshold keys from MPC, VRFs for leader election, pairing-based proofs, each needing a post-quantum successor and a fork to deploy it. And transaction authorization is a lock script, so no signature algorithm is written into the consensus rules: a post-quantum scheme is deployed as a lock, not a fork (CKB docs), and runs within the existing VM and cycle limits like any other script. Both points have been made publicly since 2022 (2022, 2025). The Nervos Knowledge Base calls this the third route to quantum resistance, crypto-agility, next to “post-quantum by design” (QRL) and “post-quantum by migration” (Bitcoin, Ethereum). It also answers the talk’s warning against hard-coding one post-quantum scheme: a successor to SLH-DSA is just another lock.

The speakers were clear that hash-based cryptography can be relied on for now, and qualitatively that holds for proof of work: Grover’s algorithm gives at most a quadratic speedup on the mining search, about 1/√p quantum queries instead of 1/p for a target a random attempt hits with probability p, and breaks nothing. Quantitatively it needs further security analysis: how much of that speedup survives reversible circuits, error correction and limited parallelism, and what the resulting edge would mean for reorg and double-spend assumptions.

2. Choice, not coordination

The flip side is that the protocol decides nothing for anyone. The community adds post-quantum options at the application layer, and each holder decides whether to migrate and when. That puts three kinds of work on the ecosystem instead of on a fork: new post-quantum locks, built and audited; users who know the risk and act on it, which the survey cited in Part 1’s Bitcoin section suggests is not the default; and an upgrade path for locks that embed logic rather than one owner’s signature, those that delegate unlocking to another cell or script and those that hold assets in custody, such as multisig, escrow, time locks or contract-controlled cells. For those the questions are who can move the assets, whether the key that authorizes the move is itself classical, and what happens where the controlling logic was never designed to be replaced.

3. What is deployed, and what should come next

  • SPHINCS+ on mainnet. The quantum-resistant lock script supports all twelve FIPS 205 parameter sets and is audited; Quantum Purse is the wallet built on it, also audited. Signatures run from 7.9 KB to 49.9 KB.
  • ML-DSA and Falcon on testnet. ckb-mldsa-lock deploys ML-DSA-44, -65 and -87 and Falcon-512 and -1024, with witnesses of 1.6 KB to 7.2 KB. Unaudited, and the Falcon locks implement FN-DSA before its standard, FIPS 206, is final. The code is upgradeable: every lock’s code cell is referenced by type ID and one secp256k1 key controls all of them, which the project’s trust model calls acceptable for testnet and not for mainnet.
  • SHRINCS on testnet. shrincs-lock (Nervos Talk) uses Blockstream’s SHRINCS: 324-byte signatures in stateful mode and 2.5 KB stateless as the fallback, at the price of a counter the wallet must never reuse.

SPHINCS+ was the right first choice: hash-based, resting on the same assumptions CKB’s consensus already relies on, and standardized. It is also the most conservative and most expensive option, in bytes, cycles and signing time. The ecosystem should treat it as the floor rather than the destination, track NIST’s standards as they finalize, and move to schemes that fit a blockchain better as soon as they are stable and audited. Falcon is the obvious candidate, at about 1.6 KB of witness and 1 M cycles to verify; ML-DSA is the interim step already on testnet. The community locks show that the path from a final standard to a deployable lock is short.

A post-quantum signature does not by itself make a post-quantum lock. A script names its code by code_hash and hash_type. With hash_type = type, the hash identifies the type script of the cell that holds the code, not the code itself, so whoever can update that cell can swap the verifier under the same reference. If that authority is a classical key, cells behind a post-quantum lock still depend on it. Quantum resistance has to cover the whole authorization path, including code upgrades and delegated dependencies. Referencing code by its data hash rules this out: the bytes cannot change, and if the original cell goes away anyone can deploy the same bytes again. The mainnet SPHINCS+ lock is published with hash_type = type; its code cell carries a type ID and sits under a secp256k1 multisig lock, whose m-of-n stays hidden until it is spent, and as of September 2026 the code has not been upgraded since it was deployed.

4. Bytes, cycles and propagation

The talk’s “the bottleneck moves to bytes” can be measured against CKB’s two block budgets, 597,000 bytes and 3.5 billion cycles, each sized for a thousand two-in-two-out secp256k1 transfers, plus the default pool limit of 70 M cycles per transaction. The table gives each lock’s witness bytes and verification cost and the transfers per block each budget allows, assuming about 530 bytes of transaction besides the lock. Witness bytes are the full lock field for ML-DSA and Falcon and the signature alone for SHRINCS and SLH-DSA. The chart shows the tighter bound.

LockWitness bytesVerificationTransfers per block, bytes-boundSame, cycles-bound
secp256k1 (reference)65 B3.5 M cycles1,0001,000
SHRINCS, stateful324 B9.5 M≈ 700≈ 370
Falcon-5121,564 B1.1 M≈ 280> 1,000
SHRINCS, stateless2,568 B19.4 M≈ 190≈ 180
ML-DSA-443,733 B3.6 M≈ 140≈ 960
ML-DSA-655,262 B5.6 M≈ 100≈ 630
SLH-DSA-128s7,856 B11.5 M≈ 70≈ 300
SLH-DSA-256f49,856 B49.7 M≈ 12≈ 70
limited by bytes limited by cycles reference, both limits 02505007501,000 secp256k1 (reference) SHRINCS, stateful Falcon-512 SHRINCS, stateless ML-DSA-44 ML-DSA-65 SLH-DSA-128s SLH-DSA-256f 1,000 ≈ 370 ≈ 280 ≈ 180 ≈ 140 ≈ 100 ≈ 70 ≈ 12
Upper bound on simple transfers per block for each lock, taking the tighter of CKB's byte and cycle limits. Colour shows which limit binds. Source: my estimate from the lock repositories' signature sizes and cycle counts and the consensus constants in the CKB source; the assumptions are stated in the text.
  • Capacity, not the fee rate, is the cost. At the minimum fee rate a 128s transfer still pays under 0.0001 CKB. The cost is block space: about 70 SLH-DSA-128s transfers per block instead of 1,000, a dozen with 256f.
  • The per-transaction cycle cap bites first. One SHA2-256f verification takes 49.7 M of the 70 M default, so a transaction with two independent 256f signers, the shape of batch payments and DEX settlements, is rejected before block limits matter.
  • Signing moves the cost to the wallet. The s sets verify cheaply because signing does the work, which is slow on a hardware wallet.
  • Smaller schemes buy most of it back, each at a price: lattice assumptions for ML-DSA and Falcon, an unfinished standard for Falcon, state that must never be reused for SHRINCS.
  • NC-Max largely removes the propagation bottleneck the talk’s blockchain paper found. Under NC-Max transactions are proposed ahead of the block that commits them and relay during the proposal window, so when they arrive in time a compact block propagates at much the same speed whatever the witness size. Nor does the load grow: the byte and cycle limits cap what each block asks nodes to relay, store and verify, so larger witnesses mean fewer transactions per block, not heavier blocks. If relay does fall behind, blocks stall while missing transactions are fetched and the orphan rate rises; the next epoch lengthens the block interval, but only after the fact and within bounds. The orphan rate is the signal to watch, and the testnet locks make the experiment cheap.

5. The layers above

Every layer has its protocols, but when people say a blockchain’s protocol they usually mean the consensus rules, the semantics only a fork can change. That is where the post-quantum question sends Bitcoin and Ethereum into a fork, and where CKB has nothing left to fork: its consensus uses no quantum-breakable cryptography and its signatures are locks, for the reasons above. What remains are the architecture, systems and infrastructure layers of the talk’s diagram, where, as the talk warned, information gets thinner.

  • Architecture: every place a classical lock is coupled to something else. sUDT and xUDT owner mode fixes the issuer’s classical lock hash in the type args, so issuance authority stays exposed unless that lock was upgradeable. Contracts that accept only specific lock code hashes reject a post-quantum lock by construction, the talk’s “Ghost in the Basement”. Omnilock’s exec and dynamic-linking modes are the natural integration point; multisig carries n full signatures because no post-quantum scheme aggregates. RGB++ waits on Bitcoin, and passkey locks on FIDO. A Nervos DAO deposit can switch to a post-quantum lock at phase 1, but redepositing costs up to a cycle of compensation and about a month of idle capital.
  • Systems: the software people touch. Wallets, hardware wallets, exchanges, custodians, indexers, SDKs and HSMs each need the new locks. An exchange that cannot credit a SPHINCS+ deposit is a hard stop, whatever the chain allows. This is the layer where the talk’s “best of 6” scores showed every real system falling short.
  • Infrastructure: nodes, keys and inventory. The chain itself is the inventory: capacity by lock code_hash, exposed keys and contracts that hard-code a classical lock hash can all be computed from chain data, a CBOM that reconciles itself against runtime by construction. It shows where exposure sits and which contracts need attention. It is not a readiness score: whether to move is each owner’s decision, and readiness is whether the options and tools are there when they decide.

With the protocol layer quantum-safe, this is the list in front of CKB now.

6. The P2P layer

Tentacle’s secio uses secp256k1 peer identities and X25519 key agreement, none of it post-quantum, and the two halves fail differently. Recorded traffic decrypted later exposes transaction origin and links nodes to addresses: a privacy loss. Forged identities are worse. Impersonating reserved peers, bootnodes or the nodes a light client trusts enables eclipse attacks, and an eclipsed exchange or merchant node can be fed a private chain whose later rollback turns a confirmed deposit into a double spend. The fixes are TLS’s: a hybrid X25519 plus ML-KEM-768 key agreement now, post-quantum or hybrid identity keys before a quantum computer exists. Both are networking upgrades with no consensus impact.

7. Keys and HD wallets

Post-quantum schemes have no equivalent of BIP32 non-hardened derivation: a child public key cannot be derived from a parent public key. Every xpub workflow breaks, from exchange deposit addresses derived online to hardware wallets paired with watch-only desktops, and has to be rebuilt around pre-generated keys or seeds kept online. Hardened derivation through a KDF still works, as SLIP-0010 does for ed25519 and Quantum Purse does with HKDF. Stateful schemes like SHRINCS turn backups and multi-device use into a key-safety problem. Derivation paths and witness layouts need shared conventions, or funds become recoverable only by the wallet that made them, lock-in in the talk’s sense. A hybrid classical-plus-post-quantum lock is the hedge against young implementations. Key rotation itself is cheap on CKB: moving cells to a new lock is a normal transaction, the talk’s E1 enabler without a TransformKey.

8. Fiber

Fiber follows Lightning’s cryptographic design in its own implementation: MuSig2 funding, secp256k1 node identities, ECDH-based Sphinx onions, signed invoices, HTLCs with PTLCs planned, carried over Tentacle’s secio transport with its own P2P messages and invoice format. The closest Lightning work, PQLN (September 2026), hybridizes gossip, transport, invoices, onions and offers with ML-DSA and ML-KEM on top of Lightning’s BOLT encodings and Noise_XK handshake, and leaves the on-chain funding and commitment transactions out of scope because on Bitcoin they wait for new output types. Its security argument also assumes that post-quantum identity keys were pinned before a quantum adversary existed, or arrived over an authenticated channel.

  • The on-chain half is where CKB is ahead. A post-quantum funding lock can ship now. The cost is aggregation: two full signatures instead of one 64-byte MuSig2 signature, about 7.5 KB with ML-DSA-44, paid only at open and close.
  • Signing speed caps channel updates. ML-DSA and Falcon fit; SLH-DSA-128s allows only a few updates per second on a laptop. Stateful SHRINCS suits the state machine but adds a counter that must survive crashes.
  • Revocation, watchtowers and PTLCs need redesign. Per-commitment keys derived from EC basepoints need a hash-based replacement, watchtower storage grows with signature size, and PTLCs rest on adaptor signatures that have no standardized post-quantum form.
  • The off-chain surfaces are Lightning’s problems, not Lightning’s code. PQLN is a useful design reference, but its BOLT-specific encodings and Noise handshake cannot be applied unchanged to Fiber’s Tentacle transport, invoice format and channel messages; each of those integrations needs its own design and validation.

The shape is the same as for the chain: CKB removes the protocol-layer blocker that Lightning cannot remove on its own, and leaves a systems-layer list like Lightning’s, to be worked through in Fiber’s own formats.

9. Through the talk’s frameworks

Readiness dimensions. Against the five dimensions, and looking at the ecosystem rather than the chain alone, CKB’s position is the mirror image of Bitcoin’s: the protocol layer is already quantum-safe, so the weight sits on the other four.

DimensionCKB ecosystem
I InformationSufficient, because the assets are on chain. Every cell names its lock by code_hash, so the whole ledger can be classified by lock type and the cells that need migration identified. Whether a public key is already exposed depends on the lock: the default lock reveals it only when its arguments are spent from, other locks put keys in their arguments or use other schemes, but since most locks in use are open source, the exposure rule of each lock type can be worked out and applied across the chain. Contracts that hard-code a classical lock hash can be found by parsing their scripts
C ControllabilityThree tiers. The part that a community and a core team can solve by concentrating effort, the protocol layer, is solved: consensus uses no quantum-breakable cryptography, and post-quantum locks run on mainnet. Above it, controllability follows the code: what lives under github.com/nervosnetwork, the node, the reference locks, the SDKs, the light client, Fiber, can be fixed and shipped directly, and that covers a good share of the architecture and infrastructure layers. Everything else, third-party wallets, exchanges, pools, dApps, and above all which lock each owner uses and when they move, is by design outside anyone’s control. A decentralized system can offer choices and only choices; it cannot force a migration or steer its users, and CKB should not try. There the ecosystem can advocate and make the option easy, and owners decide. Cells whose owners are gone, and assets bound to another chain such as RGB++, are outside anyone’s reach for the same reason
V VerificationFollows from the same principle. Each owner can verify their own state trivially, because the lock on every cell is public. What the ecosystem verifies is the quality and availability of the options: audited post-quantum locks on mainnet, wallet and exchange support tested end to end, acceptance criteria met before deployment. How many cells and how much capacity sit behind post-quantum locks is worth publishing, as a measure of the risk that remains, but it is not the ecosystem’s score: whether and when to migrate is each owner’s decision, and the ecosystem’s job is to make sure the option works whenever an owner takes it
E EcosystemThe main work, and voluntary. Wallets, hardware wallets, exchanges, custodians, SDKs, indexers and explorers need the new locks and witness layouts; dApps that check lock hashes need to accept them; Fiber nodes and bridges have lists of their own. Mining itself is untouched, since Eaglesong is a hash, but the money around it is not: pools collect block rewards into coinbase outputs and pay miners from hot wallets, both under classical locks today, so pool software has to move its own reward wallets and accept post-quantum payout addresses, and mining software and ASIC vendors’ firmware and management tools have to let miners configure them. No fork means no forcing function, and that is the point: each party moves when its own users and economics call for it. With central coordination gone, the order of migration is set by demand rather than by a roadmap, which is the participants’ freedom and the market’s efficiency at once
R ResourcesSmall, and to be used the decentralized way. The CKB ecosystem has few teams and few people who can write and review lock scripts, wallet code and pool software. The answer is not to centralize the work but to raise the return on every contributor, with the tools a decentralized community has: open specifications, reference implementations and test vectors that every team can reuse instead of rebuilding; testnet deployments anyone can exercise, so review is open rather than waiting on a few people; community funds, grants and bounties aimed at audits and the shared pieces; independent implementations that check each other, as the two ML-DSA backends on testnet already do. The scarce people build once, and the whole ecosystem benefits

Agility and anti-patterns. At chain level CKB scores well on C1 and C4: the operation is “unlock this cell” and the algorithm is chosen per cell by its owner. The question is whether that reaches applications; a wallet or SDK that hard-codes the secp256k1 lock is at C1.0 whatever the chain allows. Two anti-patterns apply. The Algorithm Nobody Used is not about adoption numbers, since migrating is each owner’s decision; it is about shipping an option without acceptance evidence. A post-quantum lock is ready when it is audited, has test vectors and has been exercised end to end by real wallets and exchanges. The Vendor Will Surely Fix It: for any product on CKB, readiness is the integrations that have shipped, not the chain’s capability.

10. The policy question changes shape

Cells under classical locks with exposed keys stay exposed until their owners move them, and the chain cannot force that without a fork. Some will never move: their owners are gone or have lost their keys, and a post-quantum lock does nothing for a cell nobody can sign for. So the Bitcoin question does not go away. Whether CKB keeps accepting valid classical signatures from those cells indefinitely, or ever restricts them, is still a protocol rule and a social choice, and the externality is the same: if someone with a quantum computer drains them, every holder pays. What CKB removes is the protocol-layer prerequisite. On Bitcoin the policy debate is tangled with the fork that would make migration possible at all; on CKB the path exists, every owner who can move can do so today, and the remainder can be measured as it shrinks.

My own position is to leave classical locks alone and make migration easy: no freeze and no deadline. It accepts the residual risk of unmigrated cells; it is a choice, not the absence of one, and it follows from what CKB is for. The positioning paper makes layer 1 a decentralized custodian of value, where users “enjoy absolute property ownership” of their assets and are “fully responsible” for them. A freeze would override that ownership for every owner who has not moved yet. Imagine Bitcoin eventually intervening in unmigrated coins in some form, while CKB leaves the choice with their owners: which project would people then see as holding closer to Bitcoin’s original ideals? Decisions like this are how a community establishes its identity, answering who we are, where we come from and where we are going. Whatever a community chooses, it should choose knowing that.

Sources

The opinions here are all my own. Claude helped with the calculations and with revising the text.