CKB has been crypto-agile by design since its mainnet launch in 2019. On many blockchains, a new signature scheme needs a protocol upgrade, and getting a whole network to agree is slow and contentious. On CKB, signature checks run as lock scripts rather than as part of the protocol, so a post-quantum scheme can be deployed as a new lock with no network-wide vote. One is already live on mainnet and three are on testnet. Each scheme below is measured against secp256k1, the signature scheme used today by Bitcoin and Ethereum, as well as by CKB's “default” lock. On CKB it takes up 65 bytes and about 3.5 million computing cycles to check. 1. SPHINCS+ (live on CKB mainnet, audited) Instead of relying on the arcane mathematical problems behind today's signatures, SPHINCS+ uses layers of cryptographic hashes to show that a transaction was authorized by the rightful owner. Its security depends on the hash function and nothing else. Jan Xie, our Chief Architect, calls it the most conservative option. It is also stateless: the wallet does not have to keep count of how many times it has signed, so a seed phrase restores everything. ⦿ Size: about 120 to 770 times larger than a secp256k1 signature ⦿ Checking: about 3 to 14 times longer ⦿ Space: about 12 to 70 transactions per block, against about 1,000 with secp256k1 ⦿ Standard and audit: NIST's SLH-DSA (FIPS 205); ScaleBit audited the lock in 2025 In plain terms: the most conservative choice on the list. It is standardized, audited and built on hash functions alone, at the price of taking up the most space on the chain. 2. SHRINCS (testnet, unaudited) SHRINCS also relies only on hash functions. It is a design from @Blockstream, and the CKB lock on testnet was written by Jiandong Xu. It is built to be small. In normal use the signatures are very short, but the wallet has to keep count of them, because signing twice with the same count would expose the key. If the count is lost, or the wallet would rather not rely on it, it can use a larger signature that works from the seed phrase alone. ⦿ Size: about 5 times larger (324 bytes at the start, growing slightly with each signature), or about 40 times larger on the fallback ⦿ Checking: about 3 times longer at the start, or about 5.5 times on the fallback ⦿ Space: about 370 transactions per block with a fresh counter, against about 1,000 with secp256k1 ⦿ Maturity: a young design, with no independent audit or security proof so far In plain terms: SHRINCS signatures have the smallest footprint of the four at first, but the wallet has to keep careful count, and the design is young and unproven. 3. ML-DSA (testnet, unaudited) ML-DSA is NIST's main general-purpose standard (FIPS 204). It rests on a different kind of mathematical problem, called a lattice problem, which is newer than hash functions. Like SPHINCS+, it needs no counter. The CKB locks were written by community developer toastmanAu. ⦿ Size: about 57 to 81 times larger at its two smaller settings ⦿ Checking: about 1 to 2 times longer ⦿ Space: about 100 to 140 transactions per block, against about 1,000 with secp256k1 ⦿ Standard: final (NIST, 2024) In plain terms: the standard all-rounder. It is reasonably quick to check, but bigger than today's signatures and built on a newer mathematical assumption than the hash-based options. 4. Falcon (testnet, unaudited) Falcon is also lattice-based, and NIST is standardizing it. It produces the smallest signatures of the lattice schemes. Its weak spot is signing, which is complex to implement. Checking a signature, the part the chain does, is simple. The CKB locks are also by toastmanAu. ⦿ Size: about 24 times larger for Falcon-512 ⦿ Checking: about a third of secp256k1's cost, the cheapest of the four ⦿ Space: about 280 transactions per block, against about 1,000 with secp256k1 ⦿ Standard: still a draft (NIST's FN-DSA, FIPS 206) In plain terms: the quickest to check, and small for a lattice scheme, but harder to implement on the signing side. So is there a best one? No. Each wins on one measure and pays for it on another: ⦿ SHRINCS: the smallest signatures at first, provided the wallet keeps its count ⦿ Falcon: the cheapest to check, though signing is hard to implement ⦿ ML-DSA: the most established standard and the simplest to build, but bigger than today's signatures ⦿ SPHINCS+: the most conservative foundation, paid for in space Which matters most depends on what a chain is protecting and what it can afford: block space, checking cost, how much it trusts newer mathematics, and how much it can ask wallets to look after. On October 7, @VitalikButerin said hash-based signatures beat lattice-based ones wherever hash-based is possible at all. Ethereum's roadmap already excludes ML-DSA and Falcon. SPHINCS+ and SHRINCS are hash-based; ML-DSA and Falcon are lattice-based. No break of any of the four has been shown. CKB does not have to choose. Each scheme is a lock script, so anyone can deploy one without a network-wide vote, and each user decides which to trust. If research or a standard points somewhere new, a new lock can join them the same way.