Another reason to avoid relying on an ever-growing list of cryptographic precompiles is that each one embeds a cryptographic operation in the protocol’s consensus rules. Introducing a new signature scheme this way requires the network to reach social consensus around a fork. There is a consistent direction in Vitalik’s proposals, from exploring RISC-V as a replacement for the EVM to now advocating “EIP-8288 maximalism”: give Ethereum room to support new cryptography without continually expanding the protocol. EIP-8288 would open a path to supporting different signature schemes without a dedicated precompile for each. Signature verification would be proven off-chain, and those proofs aggregated for the chain to check, reducing the associated data and verification costs. The broader idea is one we've discussed extensively: blockchains are for verification, not computation. Vitalik is reframing the "world computer" along precisely these lines: "any data/computation that does not need to be in the 'main thread' of data/execution should not be put into the main thread." This is the reasoning CKB was built around from the beginning. Its accounting model (the Cell model, which is a generalized version of the UTXO model) separates off-chain state generation from on-chain verification. CKB also launched without cryptographic precompiles. Signature verification runs as ordinary software on its RISC-V VM, so developers can introduce new schemes as Lock Scripts and users can adopt them without waiting for a protocol upgrade. That's how an audited post-quantum lock, SPHINCS+, is already live on mainnet. The idea is simple: keep the base layer simple and stable while giving the cryptography and applications built on it room to evolve. It's the essence of crypto-agility, and it's becoming more appreciated amid the looming threat of cryptographically relevant quantum computers and AI.

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.