Quantum-safe L0 blockchain protocol
Cellframe CELL
Cellframe positions as a PQ-native L0 blockchain with post-quantum algorithms (CRYSTALS-Dilithium, Falcon, SPHINCS+, Kyber) as standard from design, claiming no user migration needed due to absence of a classical native ownership namespace. Official sources (whitepaper, wiki, SDK, FAQ, Qverify 2025 audit announcement, mainnet explorer) support algorithm choices, open-source implementation, and production mainnet activity. The 2025 Qverify independent audit confirms NIST standards compliance for PQC algorithm implementation. However, evidence is insufficient to verify mandatory PQ/hybrid enforcement across all mainnet spend authorization and consensus signatures, bridge dependency quantum safety, or complete-by-design coverage metrics. The PQ-native claim is plausible given design documentation but lacks on-chain signature format proofs. Conservative scoring applies a Readiness & Risk Cap due to quantum-critical enforcement uncertainty. Stale audit, missing formal benchmarks, and absent incident-response playbook are noted as assurance-only caveats.
PQ-NativePQ-Resistant
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
10.5 / 20
Migration Mechanism, Governance & Ecosystem Coordination
10 / 15
Migration Status & Value-at-Risk
18 / 25
Production Cryptographic Protection
24.5 / 35
Security Assessment & Evidence Preparedness
5 / 5
Critical Quantum Blockers
- Unverified mandatory PQ/hybrid enforcement across all mainnet spend authorization and consensus signatures
- Unresolved bridge/wrapped asset dependencies potentially introducing classical cryptographic risks
- Lack of public mainnet transaction signature proofs or coverage metrics confirming no classical ownership space
Key Risks
- Potential classical fallback or hybrid paths in production spend authorization or consensus signatures not evidenced as absent
- Bridge dependencies (e.g., cBTC, wrapped tokens) may expose value to non-PQ-secure systems
- No public proof of 99%+ coverage or verified complete-by-design native asset protection
- ERC-20 and BEP-20 CELL tokens inherit host-chain quantum risk independent of native protocol design
- Consensus authentication (validator signatures in ESBOCS/PoS) quantum protection unverified
Assurance Notes
- Qverify audit dated 2025-08-13 covers NIST-standardized PQC algorithms (Kyber, Dilithium, Falcon, SPHINCS+, Picnic) and confirms implementation meets NIST standards. Audit is stale but relevant as quantum-critical design is supported by public code (SDK), wiki documentation, official whitepaper, and mainnet explorer evidence.
- No public mainnet transaction signature format proofs or explorer examples confirming mandatory PQ-only enforcement for all spend authorization.
- Bridge and wrapped asset dependencies (cBTC, ERC20/BEP20 CELL) may introduce classical cryptographic risks not fully evidenced.
- Consensus authentication (ESBOCS PoS validator signatures) is claimed PQ-protected but specific enforcement details lack independent verification.
- No public evidence of circulating supply protection percentage or legacy vulnerable pools for native asset, though PQ-native claim is design-based.
- Full Qverify audit report content and any noted limitations are not fully public in dossier; manual review recommended.
Non-Scoring Caveats
- Audit dated 2025; stale but relevant. No recent independent audit for current implementation.
- No formal quantum-specific incident-response playbook documented.
- No formal performance or resource-impact analysis for PQ signature/verification costs.
- Future protocol upgrades from one PQ-secure design to another are roadmap notes, not current deductions.
- Exchange and custody migration attestations absent, but protocol design claims classical ownership impossible for native asset.
- ERC-20 and BEP-20 wrapped CELL tokens exist on Ethereum and BNB Smart Chain; these inherit host-chain quantum risk and are outside evaluated native scope.
Evidence record
Claims and Caveats
Spend authorization
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: Post-quantum encryption is standard; PQ-native spend authorization without user migration or third-party code
Coverage basis: PQ-native by design per whitepaper and FAQ
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: confidence-only
Quantum blocker: PQ-native claim is strong from design docs but no mainnet tx signature format proofs or explorer examples confirm mandatory PQ-only enforcement for all spend authorization
Assurance: Official whitepaper, wiki, FAQ, and explorer all support PQ-native design. SDK confirms PQ algorithms. However, no transaction-level signature inspection evidence or coverage metric is available in dossier.
Score reflects optional mainnet support level (0.75) due to inability to verify mandatory enforcement from public evidence; design claims suggest satisfied-by-design but unverified
Account/address/public-key exposure
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths or supports PQ/hybrid controls
Claim: PQ-native design with no classical address namespace for native asset; prevents long-exposure vulnerable ownership paths
Coverage basis: PQ-native by design
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Design claim supported by multiple official sources. No contradictory evidence found. Confidence limited to Medium due to lack of independent on-chain verification.
Consensus authentication
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: ESBOCS PoS consensus with PQ-protected validator signatures
Coverage basis: PQ-native by design per FAQ
Implementation score: 0.5 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: confidence-only
Quantum blocker: FAQ mentions PoS consensus but no specific evidence of PQ enforcement on validator signatures
Assurance: Only FAQ reference available. No code, spec, or audit evidence for consensus authentication PQ status. Confidence Low.
ESBOCS consensus details not fully evidenced in dossier
State/proof/privacy layers
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: PQ-native design with quantum-safe state integrity by construction
Coverage basis: PQ-native by design
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Design-level claim supported by official docs. No contradictory evidence. Confidence Medium.
Privacy/proof layers
Privacy and proof layers are quantum-safe where applicable
Claim: No privacy or ZK proof layer identified in dossier
Coverage basis: N/A
Implementation score: 0 · Evidence confidence: None
Issue classification: none · Score treatment: not applicable
P2P identity
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: PQ encryption standard for P2P; node identity uses PQ controls
Coverage basis: PQ-native by design
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Design-level claim. Confidence Medium as no P2P-specific code evidence in dossier.
Wallet/custody paths
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path
Claim: PQ-native wallet design; third-party custody depends on native protocol controls
Coverage basis: PQ-native by design for native on-chain control
Implementation score: 0.75 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Whitepaper claims no third-party code needed. However, no public evidence of hardware wallet or HSM PQ support. Confidence Low.
Wallet/custody PQ support not independently evidenced beyond design claims
Migration coverage
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: PQ-native with no classical native ownership space; migration complete by design
Coverage basis: PQ-native by design
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Design claim supported by multiple sources. No contradictory evidence. Confidence Medium. ERC-20/BEP-20 wrapped CELL inherit host-chain risk separately.
Score reflects 99%+ coverage by design per spec Section 9.3.1
Critical wallets
Critical wallets migrated, protected, or inherently PQ-native
Claim: All native on-chain control paths are PQ-native by design
Coverage basis: PQ-native by design
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Design-level claim. No exchange or custody migration attestation evidence, but per spec 7.1 this is not required for PQ-native assets.
Legacy vulnerable pools
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No classical native ownership space exists by design; legacy vulnerable pools proven not to exist
Coverage basis: PQ-native by design
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Design-level claim. Confidence Medium.
Migration roadmap
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: No migration needed by design; PQ-native from genesis. Parachain quantum resistance blog post indicates ongoing ecosystem development.
Coverage basis: PQ-native by design; no ECC-to-PQC migration required
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: No migration roadmap needed per design. Blog posts indicate continued ecosystem PQ development.
Migration accessibility
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths default or complete by design
Claim: PQ-native; all paths are PQ by default from genesis. No user action required.
Coverage basis: PQ-native by design
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Design claim well-supported by official docs. No migration prompts needed as no unsafe classical path exists.
Migration enforcement
Migration enforcement and coordination
Claim: No enforcement mechanism needed as no classical ownership space exists; design prevents unsafe fallback
Coverage basis: PQ-native by design
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Bridge/wrapped asset coordination is a caveat but outside native scope enforcement.
Emergency governance
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No formal quantum-specific incident-response playbook documented
Coverage basis: N/A or assurance caveat
Implementation score: 0 · Evidence confidence: None
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: No formal quantum-specific incident-response process found. Note-only per spec 7.4 as PQ-native design reduces quantum-vulnerable attack surface.
Not scored; assurance caveat only
Algorithm choices
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: CRYSTALS-Dilithium, Falcon, SPHINCS+, Kyber - all NIST-standardized or standards-track
Coverage basis: PQ-native by design
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Strong evidence from SDK source code, wiki, audit, and FAQ. NIST-standardized algorithms confirmed.
Independent audit
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: Qverify audit (2025-08-13) confirms NIST standards compliance for PQC implementation
Coverage basis: Independent audit of quantum-critical implementation
Implementation score: 1 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: Audit dated 2025-08-13, approximately 10 months old. Stale but relevant per spec as quantum-critical design remains verifiable from public code, wiki, and SDK. Full audit report content not fully public; link referenced in blog. Confidence capped at Medium due to audit age.
Audit announcement references GitHub report link at https://github.com/qvfoundation/certifications/blob/main/2025/Cellframe/Cell_frame_report_v1.pdf
Open-source implementation
Open-source, reproducible implementation
Claim: Cellframe SDK and node are open-source on GitHub
Coverage basis: Open-source code
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Multiple public repositories confirm open-source implementation. High confidence.
Parameter agility
Parameter agility and future upgrade path are documented
Claim: Variable PQ encryption supporting multiple signatures and on-the-fly algorithm upgrades
Coverage basis: Design documentation
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Multiple official sources confirm variable encryption and on-the-fly upgrade capability. Design-level evidence; Confidence Medium.
Stateful-signature safety
Stateful-signature safety, side-channel, fault-injection, state-management, HSM, or custody implementation risks are considered
Claim: No stateful signatures (XMSS/LMS) used; lattice-based and hash-based stateless schemes employed
Coverage basis: Algorithm choice
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Algorithms used (Dilithium, Falcon, SPHINCS+) are stateless. No XMSS/LMS stateful scheme identified. Side-channel and HSM analysis not evidenced but this subfactor is satisfied by algorithm choice. Confidence Medium.
Performance analysis
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment
Claim: No formal performance or resource-impact analysis documented
Coverage basis: N/A or assurance caveat
Implementation score: 0 · Evidence confidence: None
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: No formal performance analysis found. Per spec, this is note-only unless resource constraints prevent safe use of PQ path. Active mainnet with 1M+ transactions suggests practical viability but no formal benchmark exists.
Not scored as deduction; assurance caveat only per spec 7.4
Report metadata