PoW modular smart-contract blockchain network
Nervos Network CKB
Nervos CKB demonstrates strong cryptographic agility through its RISC-V based CKB-VM, enabling deployment of a NIST-standardized SPHINCS+ (FIPS 205) lock script on mainnet without a hard fork. The SPHINCS+ implementation is open-source, audited by ScaleBit, and supported by a community desktop wallet (Quantum Purse). However, quantum protection is strictly opt-in: the default lock script remains secp256k1 (ECC-only), users can still create new quantum-vulnerable accounts by default, and no migration enforcement, deprecation, or freeze mechanism exists. The vast majority of CKB value-at-risk almost certainly remains in classical secp256k1-locked cells. The P2P networking layer (Tentacle/Secio) relies on ECDH and secp256k1 ECDSA. PoW consensus with Eaglesong hash avoids validator-signature risk. Godwoken L2 and Force Bridge have been shut down, removing bridge-related quantum exposure. Overall QRI Score of 53 reflects optional mainnet PQ protection with vulnerable defaults and major quantum-critical gaps.
Category breakdown
QRI Factors
Critical Quantum Blockers
- Default spend authorization (secp256k1_blake160_sighash_all) is ECC-only and quantum-vulnerable. SPHINCS+ is strictly opt-in with no enforcement, deprecation, or freeze mechanism for classical accounts.
- Users can still create new quantum-vulnerable secp256k1 accounts by default; no warnings, prompts, or guardrails prevent this.
- P2P node identity and transport encryption (Tentacle/Secio) rely on ECDH (P-256) and secp256k1 ECDSA signatures, making node authentication and session encryption quantum-vulnerable.
- No public migration coverage data exists; the vast majority of CKB circulating supply almost certainly remains in classical secp256k1-locked cells with no measurable migration progress.
Key Risks
- Vast majority of CKB circulating supply is secured by secp256k1 (ECC) lock scripts, vulnerable to Shor's algorithm once CRQCs reach sufficient scale.
- No mechanism prevents users from creating new quantum-vulnerable secp256k1 accounts; the default wallet path remains ECC-only.
- P2P node identity and transport encryption (ECDH P-256 + secp256k1 ECDSA in Secio) is quantum-vulnerable, enabling node impersonation and traffic decryption by a quantum adversary.
- Migration coverage is unmeasurable; no public analytics, explorer support, or attestation framework exists to track SPHINCS+ adoption.
- No deprecation, freeze, burn, or enforced-migration policy exists for classical secp256k1 accounts, leaving legacy value pools permanently exposed.
- Only one community wallet supports SPHINCS+; exchange and institutional custody support is absent, severely limiting practical migration.
Assurance Notes
- ScaleBit audit of SPHINCS+ lock script is current and covers the quantum-critical spend-authorization scope.
- Least Authority core-protocol audit (2019) predates NIST PQC standards and does not cover the SPHINCS+ deployment, though the audited cryptographic design (crypto-agnostic CKB-VM, Eaglesong PoW) remains substantially unchanged.
- No public data on the percentage of CKB circulating supply migrated to SPHINCS+ lock scripts. Migration coverage cannot be measured from available explorers or analytics.
- P2P layer (Tentacle/Secio) uses ECDH (P-256) and secp256k1 ECDSA for node identity and transport encryption, making node authentication and session encryption quantum-vulnerable.
- Only one community-developed desktop wallet (Quantum Purse) supports SPHINCS+. No evidence that major exchanges or institutional custodians support SPHINCS+ lock scripts for deposits/withdrawals.
- Godwoken L2 and Force Bridge were shut down in 2025, removing bridge-related quantum risk for the current production scope.
- No formal quantum-specific incident-response playbook, governance proposal, or deprecation timeline for secp256k1 lock scripts has been published.
- SPHINCS+ performance benchmarks are published for all 12 NIST parameter sets, confirming practical viability on CKB-VM. Signature sizes up to ~49 KB are handled via the Witness data structure.
Non-Scoring Caveats
- Least Authority core-protocol audit (2019) is stale but the audited cryptographic architecture (crypto-agnostic VM, Eaglesong PoW) remains relevant. This affects confidence, not the QRI Score.
- No formal quantum-specific incident-response playbook exists. Recorded as an operational gap; does not independently create a quantum-attack path.
- Only one community wallet (Quantum Purse) supports SPHINCS+; major exchange and custody support is absent. This affects migration feasibility and confidence, not the cryptographic protection score.
- Future SPHINCS+ parameter upgrades or PQC algorithm transitions would be roadmap items; the current production SPHINCS+ lock script is already NIST FIPS 205 standardized.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: CKB has published documentation identifying critical public-key mechanisms (secp256k1 default, SPHINCS+ optional) and a quantum threat model covering Shor's algorithm impact on ECC, harvest-now-decrypt-later, and architectural mitigations.
Coverage basis: PQ/hybrid usage assessment
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Official documentation comprehensively inventories cryptographic mechanisms and discusses quantum threat model. CKB is not PQ-native; the classical inventory is complete.
Documentation is thorough and primary-source verifiable.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: Code references, specifications (RFCs), on-chain deployment transactions, audit reports, and performance benchmarks are publicly available.
Coverage basis: PQ/hybrid usage evidence
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Primary sources (GitHub, official docs, RFCs) provide strong evidence. ScaleBit audit covers QR lock script. Least Authority audit (2019) is stale for quantum scope but provides historical assurance context.
Mainnet deployment code_hash and deployment transaction are publicly verifiable.
Production Cryptographic Protection
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: Default spend authorization uses secp256k1 (ECC). Optional SPHINCS+ (NIST FIPS 205) lock script deployed on mainnet in 2025 with verifiable code_hash.
Coverage basis: PQ/hybrid usage
Implementation score: 0.75 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Default secp256k1 spend authorization is ECC-only and quantum-vulnerable. SPHINCS+ is optional, not default or mandatory.
Assurance: ScaleBit audit covers SPHINCS+ implementation. Default secp256k1 use is confirmed by official documentation.
0.75 reflects optional mainnet PQ support that is not default, mandatory, or complete by design.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths or supports PQ/hybrid controls
Claim: Default CKB address uses blake160 hash of secp256k1 public key (P2PKH-style). Public key is only revealed on spend (short-exposure). SPHINCS+ addresses use different lock script with separate code_hash. No controls prevent creation of classical addresses.
Coverage basis: PQ/hybrid usage
Implementation score: 0.75 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: cap-applying
Quantum blocker: Users can still create new quantum-vulnerable high-value accounts by default.
Assurance: Address format and key-derivation design are well-documented. blake160 hash provides partial long-exposure protection but address reuse creates long-exposure risk.
0.75 reflects partial protection: hash-based addresses prevent long-exposure for first-use addresses, but classical paths remain fully available.
Production Cryptographic Protection
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: CKB uses NC-MAX PoW consensus with Eaglesong hash function. No validator signatures, BLS threshold signatures, VRFs, or finality signatures exist in consensus.
Coverage basis: complete-by-design native coverage
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Eaglesong is a custom hash function but hash-based; quantum risk is limited to Grover's algorithm.
N/A for validator-auth subfactor as PoW chain with no validator-signature dependency.
Production Cryptographic Protection
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: CKB uses Blake2b hash for content-addressable storage (Cell model), Merkle trees, and state commitments. No KZG/pairing-based commitments, no quantum-vulnerable accumulators.
Coverage basis: complete-by-design native coverage
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Least Authority audit (2019) covered core state-integrity design.
Application-layer proof systems deployed on CKB are not evaluated here.
Production Cryptographic Protection
Privacy and proof layers are quantum-safe where applicable
Claim: CKB base protocol has no native shielded pools, ZK proof systems, or privacy-preserving transaction mechanisms.
Coverage basis: complete-by-design native coverage
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Privacy-specific subfactors are not applicable.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: CKB uses Tentacle P2P framework with Secio for encrypted communication. Secio handshake uses ECDH (P-256) for key exchange and secp256k1 ECDSA for node identity signatures.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: P2P Secio uses ECDH (P-256) and secp256k1 ECDSA, both quantum-vulnerable.
Assurance: Secio protocol is documented in Cryptape blog and verified by independent re-implementation. No evidence of PQ support in the networking stack.
P2P is applicable, not satisfied by design, because asset-spending authorization is not universally PQ-signed.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path
Claim: Quantum Purse community desktop wallet supports SPHINCS+ for Linux/Mac/Windows. No evidence of major exchange, institutional custodian, or hardware wallet support for SPHINCS+ lock scripts.
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: score-reducing
Assurance: Quantum Purse is community-developed, not officially maintained by Nervos Foundation. No evidence of exchange/custody SPHINCS+ support.
0.25 reflects existence of one community wallet with PQ support but no institutional or major wallet coverage.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: SPHINCS+ lock script is available on mainnet but adoption is strictly opt-in. No public data on migration percentage. Default remains secp256k1 for the vast majority of CKB value.
Coverage basis: migrated value
Implementation score: 0.05 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: Migration coverage is unmeasurable and almost certainly <25%.
Assurance: Confidence is Low because migration coverage cannot be measured from public data. The <25% estimate is inferred from the opt-in nature, absence of enforcement, recent deployment (2025), and lack of any public migration statistics.
Score of 0.05 corresponds to <25% coverage threshold.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No evidence that foundation treasury, exchanges, custodians, or major protocol-controlled wallets have migrated to SPHINCS+ lock scripts.
Coverage basis: migrated value
Implementation score: 0 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No evidence of any critical wallet having migrated to SPHINCS+ lock scripts.
Assurance: Absence of evidence is not evidence of absence, but no public statements, on-chain evidence, or exchange announcements confirm SPHINCS+ adoption by any critical wallet.
Exchange listings use standard CKB addresses with no indication of SPHINCS+ support.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No public identification, measurement, deprecation, freeze, or burn mechanism exists for classical secp256k1 accounts. Users can freely create and use secp256k1 lock scripts indefinitely.
Coverage basis: migrated value
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No deprecation, freeze, burn, or enforced-migration mechanism exists for classical secp256k1 accounts.
Assurance: Official documentation explicitly states that 'old addresses continue to function' and 'the upgrade is permissionless and can occur gradually.'
The crypto-agnostic design that enables permissionless PQ adoption also makes deprecation of classical accounts architecturally challenging.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: Documentation describes a three-step migration path (deploy → adopt → migrate) but no formal roadmap with sequencing, activation criteria, deadlines, or governance approvals exists.
Coverage basis: PQ/hybrid usage roadmap
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: score-reducing
Assurance: Migration approach is conceptually documented but lacks formal sequencing, activation criteria, deadlines, or governance process.
0.50 reflects a documented conceptual approach with mainnet deployment completed.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, and migration prompts are available
Claim: SPHINCS+ lock script is deployed on mainnet. Quantum Purse desktop wallet (community) supports SPHINCS+. Default account creation still uses secp256k1. No migration prompts or warnings.
Coverage basis: PQ/hybrid usage tooling
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: score-reducing
Assurance: PQ tooling exists but is not default, not integrated into standard wallets, and lacks migration prompts or warnings.
0.25 reflects existence of basic PQ tooling but no default, preferred, or prompted PQ path for users.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination: enforcement mechanisms exist and exchange, custody, bridge, wallet, and infrastructure coordination prevents unsafe fallback into vulnerable systems
Claim: No enforcement mechanisms, deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, or mandatory migration deadlines exist.
Coverage basis: PQ/hybrid usage enforcement
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Zero enforcement or coordination mechanisms exist.
Assurance: Official docs confirm that 'old addresses continue to function' and migration is 'permissionless and can occur gradually over time.'
The crypto-agnostic design philosophy makes protocol-level enforcement architecturally difficult.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No evidence of a formal quantum-specific incident-response process, vulnerability disclosure framework, or governance mechanism for quantum-related emergencies.
Coverage basis: PQ/hybrid usage governance
Implementation score: 0 · Evidence confidence: Low
Issue classification: operational/product caveat · Score treatment: score-reducing
Assurance: No quantum-specific IR process found in public documentation. This is an operational gap; it does not independently create a quantum-attack path.
Score reflects absence of quantum-specific governance/IR.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: SPHINCS+ is NIST FIPS 205 standardized (August 2024). Eaglesong for PoW is a custom hash function but hash-based.
Coverage basis: PQ/hybrid usage
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: SPHINCS+ is fully NIST-standardized (FIPS 205). Eaglesong is not NIST-standardized but is hash-based.
Full credit for NIST-standardized SPHINCS+.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit exists for the quantum-critical scope; audit freshness and scope fit are reflected in Confidence
Claim: ScaleBit audited the SPHINCS+ lock script implementation. Least Authority audited core CKB protocol (2019) including Eaglesong and secp256k1 usage.
Coverage basis: PQ/hybrid usage
Implementation score: 1 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: ScaleBit audit covers the SPHINCS+ lock script (quantum-critical scope). Least Authority audit (2019) is stale but covers core architecture. The mixed audit freshness caps confidence at Medium.
1.0 reflects that an independent audit exists for the quantum-critical scope.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: SPHINCS+ lock script is fully open-source (MIT license) with C, Rust, and hybrid implementations on GitHub. Mainnet deployment parameters are publicly verifiable.
Coverage basis: PQ/hybrid usage
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Multiple implementations with published mainnet deployment parameters enable independent verification.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path are documented
Claim: SPHINCS+ lock script supports all 12 NIST FIPS 205 parameter sets. CKB-VM crypto-agnostic design allows deployment of new PQ algorithms without hard forks.
Coverage basis: PQ/hybrid usage
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: 12 parameter sets provide strong parameter agility. CKB-VM architecture natively supports future algorithm transitions.
Full credit: SPHINCS+ parameter agility is built-in.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks are considered
Claim: SPHINCS+ is a stateless signature scheme, eliminating state-management risks. No formal side-channel analysis or fault-injection assessment has been published.
Coverage basis: PQ/hybrid usage
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: SPHINCS+ stateless design inherently avoids state-reuse vulnerabilities. No published side-channel or fault-injection analysis exists for the CKB-VM implementation.
0.50 reflects the stateless-design safety benefit but lack of formal side-channel evaluation.
Algorithm & Implementation Assurance
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment
Claim: Published cycle-consumption benchmarks for all 12 SPHINCS+ parameter sets across C, Rust, and hybrid implementations. Signature size analysis and Witness-based storage mitigation documented.
Coverage basis: PQ/hybrid usage
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Detailed benchmarks published for all parameter sets and implementations.
Full credit: comprehensive performance data enables informed parameter selection.
Report metadata