blockchain network
Polkadot DOT
Polkadot has produced one of the most detailed and technically credible post-quantum roadmaps among major L1 blockchains, including a 2025 Web3 Foundation roadmap by Jeff Burdges and a 2026 Draft RFC-0000 for hybrid post-quantum accounts selecting NIST-standardized Falcon (FN-DSA) and Dilithium (ML-DSA). However, as of the June 2026 evaluation date, the Polkadot Relay Chain mainnet uses entirely ECC-based cryptography (sr25519, ed25519, ECDSA) for account signatures, consensus authentication, VRF randomness, and P2P transport. Zero mainnet PQ or hybrid-PQ protection exists. All DOT that has ever been transacted has exposed public keys on-chain, creating a material long-exposure quantum-vulnerable value pool. The RFC explicitly states deployment cannot begin until NIST finalizes Falcon key-derivation standards (estimated 2028). No PQ testnet, prototype code in the official Polkadot SDK, or migration tooling has been publicly identified. The project earns credit for its thorough risk assessment, detailed mitigation design, and NIST-aligned algorithm selection, but these are roadmap artifacts that do not materially protect production users. Polkadot is squarely in Stage 2 (Mitigation/Development) with a QRI Score of 15/100.
Roadmap OnlyECC-Only ProductionPoSL1
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
3.61 / 20
Migration Mechanism, Governance & Ecosystem Coordination
3 / 15
Migration Status & Value-at-Risk
1.5 / 25
Production Cryptographic Protection
3.28 / 35
Security Assessment & Evidence Preparedness
3.75 / 5
Critical Quantum Blockers
- Active production spend authorization remains entirely ECC-based (sr25519, ed25519, ECDSA) — all DOT balances are quantum-vulnerable to key-recovery attacks (Readiness & Risk Cap: 40).
- All Polkadot accounts that have ever broadcast a transaction have exposed their public keys on-chain, creating a material long-exposure quantum-vulnerable value pool with no active migration, freeze, deprecation, or recovery path (Readiness & Risk Cap: 55).
- Consensus authentication (BABE/GRANDPA validator signatures, VRF) is entirely ECC-based — a quantum-capable adversary could forge finality signatures and compromise consensus (Readiness & Risk Cap: 70 if isolated; ECC-only spend authorization is the binding cap at 40).
Key Risks
- All DOT circulating supply is protected only by ECC signatures (sr25519, ed25519) that are broken by Shor's algorithm. A sufficiently large quantum computer could recover private keys from exposed public keys and steal any DOT balance.
- The VRF used for BABE block-production slot allocation is ECC-based. A quantum adversary with sufficient capability could predict or manipulate validator selection, undermining liveness and potentially enabling long-range attacks.
- GRANDPA finality signatures are ECC-based. Quantum forgery of finality votes could cause consensus splits or finality reversions without slashing recourse, as slashing authorization itself relies on the same vulnerable key material.
- BEEFY bridge finality proofs to other chains (e.g., Ethereum) rely on ECC validator signatures. Quantum compromise of these signatures could enable fraudulent bridge messages and theft from bridged asset pools.
- The FRI-based SNARK migration proof design (100s of KB per proof) has no known production-ready implementation and the roadmap author notes that current STARK implementations 'mostly neglect zero-knowledge' — this is a material implementation risk for the core migration mechanism.
- Deployment of Falcon-based accounts is blocked on NIST standardizing deterministic key derivation for FN-DSA, which the RFC projects may not be complete until 2028, creating an indefinite timeline for production PQ account support.
- No quantum-specific incident-response process, emergency governance procedure, or validator coordination plan exists for a quantum-emergency scenario.
- Dormant, lost, and unresponsive accounts with exposed public keys have no identified salvage, freeze, or burn policy path, creating a permanent quantum-vulnerable value pool even after migration begins.
Assurance Notes
- No independent cryptographic audit of any PQ-related Polkadot component exists because no PQ implementation has been deployed or published for Polkadot Relay Chain mainnet or official testnet.
- The 2025 Web3 Foundation PQ roadmap and the April 2026 Draft RFC-0000 for Hybrid Post-Quantum Accounts are detailed designs by core researcher Jeff Burdges but remain at the proposal/specification stage. The RFC explicitly states deployment cannot occur until NIST finalizes FN-DSA (Falcon) key-derivation standards, expected no earlier than 2028.
- The RFC has received minimal community review (one reviewer comment as of April 2026). No Kusama PQ testnet has been publicly documented.
- A third-party crate (qp-dilithium-crypto by Quantus Network, v0.3.1, April 2026) provides Dilithium signatures for Substrate but is not affiliated with Parity/Web3 Foundation and has no known Polkadot mainnet or Kusama integration.
- LayerQu independently scores Polkadot at QRI 31/100 (Migration Stage 2, 'Acknowledged with spec') under their v3.1.0 methodology, which is directionally consistent but uses different scoring weights for roadmap/spec work than QRI draft-v3.1.
- No formal quantum-specific incident-response playbook, performance benchmarks, or exchange/custody migration coordination has been published.
Non-Scoring Caveats
- The PQ roadmap proposes Falcon for accounts and Dilithium for consensus, both NIST-standardized algorithms — but deployment is contingent on NIST finalizing Falcon key-derivation standards, which the RFC estimates may not occur before 2028.
- The RFC proposes a hybrid approach (Falcon + existing sr25519/ed25519) rather than pure PQC, which is a conservative design choice but adds complexity that has not been implemented or tested.
- The FRI-based SNARK migration proof design (100s of KB per proof) is architecturally innovative but relies on STARK implementations originally built for Ethereum scaling that the roadmap author notes 'mostly neglect zero-knowledge' — ZK properties are critical for the migration proof to avoid revealing seed material.
- P2P transport layer PQ protection is acknowledged as out-of-scope for the current roadmap and deferred to future standardized PQ-TLS protocols.
- The roadmap proposes deploying PQ changes first to Kusama (canary network), but no Kusama PQ testnet has been publicly documented as of the evaluation date.
- Side-channel analysis of lattice-based PQ primitives is acknowledged in the roadmap as an open concern: the roadmap author cites IACR 2025/1577 noting limited open-source side-channel datasets for PQC schemes.
- Exchange/custody coordination for PQ migration has not been publicly addressed; the RFC focuses on Vault (Polkadot's hardware wallet) but acknowledges 'there is little reason to directly support post-quantum for accounts that do not use air-gapped hardware wallets.'
- Token assets on parachains (e.g., Moonbeam, Acala) inherit the relay chain's quantum-vulnerable security model and are not separately evaluated in this scope.
- Gavin Wood mentioned quantum resistance as part of JAM V2 planning at a December 2024 Polkadot Fellowship Call, but no JAM-specific PQ testnet or implementation has been documented as of this evaluation date.
Evidence record
Claims and Caveats
spend_authorization
Security Assessment & Evidence Preparedness — Public cryptographic inventory and quantum threat model
Claim: Polkadot Wiki documents use of sr25519 (Schnorrkel/Ristretto), ed25519, and ECDSA (secp256k1) for account keys; the 2025 PQ roadmap explicitly acknowledges these are quantum-vulnerable and proposes replacement with Falcon and Dilithium.
Coverage basis: Current production spend authorization and account exposure remain ECC-based and quantum-vulnerable.
Implementation score: 0.75 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Active production spend authorization remains entirely ECC-based (Cap: 40, Readiness & Risk)
Assurance: Primary sources are official Polkadot Wiki and Web3 Foundation forum (Jeff Burdges). The cryptographic inventory is well-documented and the quantum threat is explicitly acknowledged. No independent audit exists but the cryptography inventory is verifiable from public code and documentation.
The 2025 roadmap and 2026 RFC represent serious technical work, not marketing material. However, they are design documents only with no production implementation.
spend_authorization
Security Assessment & Evidence Preparedness — Public evidence record
Claim: Public evidence includes wiki documentation, forum roadmap, RFC documents, BMIC third-party assessment, and references to open-source Falcon implementation (Thomas Pornin's rust-fn-dsa).
Coverage basis: The evidence record supports the assessment that current production cryptography is ECC-only and quantum-vulnerable.
Implementation score: 0.75 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Multiple independent primary sources corroborate the cryptographic inventory and quantum-vulnerability assessment. The BMIC assessment provides third-party validation.
No formal quantum-specific audit exists, but the evidence record is comprehensive for the assessment stage.
spend_authorization
Production Cryptographic Protection — Spend authorization / transaction signatures
Claim: Polkadot mainnet uses sr25519, ed25519, and ECDSA (secp256k1) for all transaction signatures. No PQC or hybrid-PQC signature support exists on mainnet.
Coverage basis: 100% of current production transactions are ECC-only and quantum-vulnerable.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Active production spend authorization remains entirely ECC-based (Cap: 40, Readiness & Risk)
Assurance: Confirmed from official Polkadot Wiki documentation and verifiable from public Polkadot SDK source code.
The sr25519 scheme (Schnorrkel) is a Schnorr signature variant over Ristretto-compressed Curve25519 points. It offers no quantum resistance. Ed25519 and ECDSA secp256k1 are equally quantum-vulnerable via Shor's algorithm.
account_address_exposure
Production Cryptographic Protection — Account, address, public-key exposure, and key-derivation
Claim: All Polkadot accounts that have broadcast a transaction expose their public keys on-chain. Address reuse is common. Key derivation (BIP32-like HDKD) exposes derivation paths. No PQ key-derivation or address-hiding mechanism exists.
Coverage basis: Long-exposure quantum-vulnerable: public keys are permanently visible on-chain once an account sends a transaction.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path (Cap: 55, Readiness & Risk)
Assurance: Standard behavior for account-based networks — public keys are exposed on first transaction and remain visible permanently. BMIC assessment confirms this long-exposure risk.
The RFC acknowledges that sr25519/ed25519 accounts have exposed public keys and that the FRI-SNARK migration proof is designed to address this by proving seed knowledge without revealing the ECC private key. However, this mechanism is not yet implemented.
consensus_authentication
Production Cryptographic Protection — Consensus-critical authentication
Claim: BABE block production uses sr25519 for block signatures. GRANDPA finality uses ed25519 for vote signatures. The VRF for BABE slot allocation is ECC-based (Schnorrkel VRF over Ristretto). All are quantum-vulnerable.
Coverage basis: 100% of consensus-critical signing is ECC-only and quantum-vulnerable.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Consensus finality, validator authentication, and randomness remain quantum-vulnerable (Cap: 70 if isolated; ECC-only spend authorization is binding at 40)
Assurance: Consensus cryptography is documented in the Polkadot Wiki. The PQ roadmap explicitly addresses replacing both BABE/GRANDPA signatures (with Dilithium) and VRFs (with hash-based randomness beacon).
The roadmap proposes replacing GRANDPA and BABE signatures with Dilithium (ML-DSA), the ECC-based VRF with a hash-based randomness beacon, and Sassafras tickets with FRI-based SNARKs. None of these replacements have been deployed on mainnet or documented on a public testnet.
state_integrity
Production Cryptographic Protection — State-integrity and data-availability mechanisms
Claim: Polkadot's state is organized in a Merkle Patricia Trie using Blake2b hashing. Blake2b is a hash function considered PQ-secure. However, bridge verification (BEEFY light-client proofs) and cross-chain state proofs rely on ECC-based validator signatures.
Coverage basis: State trie commitments are hash-based and PQ-secure; bridge state proofs are ECC-dependent and quantum-vulnerable.
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The state trie's hash-based design is verifiable from the Polkadot specification and SDK source code. However, no explicit quantum-security review of the full state-binding mechanism (including parachain state proofs, XCM, and bridge protocols) has been publicly conducted.
The state trie root is bound by Blake2b hashing which is PQ-secure. However, bridge protocols (BEEFY) sign state roots with ECC validator keys, making cross-chain state verification quantum-vulnerable even though the local state binding is not.
privacy_proof_layers
Production Cryptographic Protection — Privacy and proof layers
Claim: The Polkadot Relay Chain does not have a native privacy layer (shielded pools, confidential transactions, stealth addresses). Privacy functionality exists on parachains but is out of scope for this relay-chain evaluation.
Coverage basis: No native privacy/proof layer on the relay chain to evaluate.
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The relay chain architecture is well-documented. Privacy features are delegated to parachains and are not a relay-chain concern.
Parachains with privacy features (e.g., Manta Network, Phala Network) would require separate QRI evaluations.
p2p_transport
Production Cryptographic Protection — P2P transport, node identity, and peer authentication
Claim: Polkadot nodes use libp2p with Noise/IKE for transport security and ed25519/sr25519 for peer identity. All are ECC-based and quantum-vulnerable.
Coverage basis: Node-to-node communication is ECC-only.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: P2P transport is not directly consensus-critical or spend-critical on Polkadot since all value-bearing operations are authenticated by on-chain signatures. However, node identity forgery could enable eclipse attacks or network-level disruption.
The PQ roadmap states P2P PQ security requires hybrid post-quantum key exchanges and certificates using on-chain certificates, and acknowledges this as out-of-scope for the immediate roadmap, deferred to future standardized PQ transport protocols.
wallet_custody
Production Cryptographic Protection — Critical wallet, custody, HSM, and hardware-wallet workflows
Claim: No PQ-capable wallet, custody solution, or HSM integration exists for Polkadot. The Polkadot Vault (air-gapped hardware wallet) does not support PQ signatures. Exchange and custodian workflows are entirely ECC-based.
Coverage basis: All wallet and custody paths are ECC-only.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The RFC acknowledges that Vault (Polkadot's hardware wallet) is planned to support hybrid PQ account upgrades via Falcon, but 'Vault cannot yet add support for Falcon because the secret key format was not yet agreed upon.' No timeline is provided.
The RFC states: 'There is little reason to directly support post-quantum for accounts that do not use air-gapped hardware wallets, out of which we only control Vault.' This suggests a narrow initial wallet support scope.
migration_status
Migration Status & Value-at-Risk — Percentage of economically relevant value-at-risk protected
Claim: 0% of DOT circulating supply is protected by PQC or hybrid-PQC. All DOT (fully diluted) and all staked DOT is secured only by ECC signatures. No migration has occurred on mainnet.
Coverage basis: <1% protected (negligible).
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: 0% value-at-risk coverage: all DOT is quantum-vulnerable with no migration path live (Cap: 40 via ECC-only spend authorization)
Assurance: Coverage is straightforward to assess because no PQ migration has occurred and all accounts use ECC-based keys. The BMIC assessment confirms long-exposure vulnerability for all transacted accounts.
The FRI-SNARK migration proof design (once implemented) would allow ECC account holders to prove seed knowledge and associate a new Falcon public key without losing their balance. This is a credible recovery design but has zero mainnet coverage as of the evaluation date.
critical_wallets
Migration Status & Value-at-Risk — Critical wallets migrated or protected
Claim: No critical wallets (treasury, foundation, exchanges, custodians, bridges, major protocols) have migrated to PQ or hybrid-PQ protection on Polkadot mainnet.
Coverage basis: 0 critical wallets protected.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No public attestations from exchanges, custodians, or the Web3 Foundation regarding PQ migration of critical wallets have been identified. This is expected given zero mainnet PQ support.
The Polkadot treasury, parachain auction reserves, and foundation-controlled DOT are all held in standard sr25519/ed25519 accounts with no PQ protection.
legacy_pools
Migration Status & Value-at-Risk — Legacy vulnerable pools identified and measurable
Claim: All existing DOT accounts are acknowledged as quantum-vulnerable in the PQ roadmap. No formal measurement or deprecation of vulnerable pools has been conducted, but the vulnerability is universal (all accounts are ECC-based).
Coverage basis: Universal vulnerability acknowledged but not formally measured or deprecated.
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The vulnerability is universal and easily measurable (all accounts use ECC). However, no formal on-chain measurement, labeling, or deprecation mechanism has been implemented. No policy for dormant/unmigratable accounts (lost keys, abandoned contracts) has been published.
The PQ roadmap proposes a FRI-SNARK-based migration proof that would work for accounts with known seeds. Dormant accounts with lost seeds would remain permanently vulnerable under current designs unless a freeze/burn policy is adopted.
migration_mechanism
Migration Mechanism, Governance & Ecosystem Coordination — Public migration or protection roadmap
Claim: A detailed PQ roadmap was published on the Polkadot Forum in June 2025 by Web3 Foundation researcher Jeff Burdges. A follow-up Draft RFC for hybrid post-quantum accounts was published in April 2026. Both documents specify algorithm selections, migration mechanisms, and sequencing.
Coverage basis: Detailed roadmap and RFC exist with specific algorithm selections, protocol changes, and migration design.
Implementation score: 0.75 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The roadmap and RFC are authored by a core Web3 Foundation researcher with deep cryptographic expertise. The RFC is a DRAFT and has received minimal community review as of the evaluation date. Deployment timelines are indefinite due to NIST standardization dependencies.
The roadmap covers consensus signatures, account signatures, VRFs/randomness, bridge protocols, and transport layer. The RFC focuses specifically on hybrid Falcon+sr25519/ed25519 accounts and migration via non-transfer key attachment. Both documents are technically detailed and credible but represent design work only.
migration_accessibility
Migration Mechanism, Governance & Ecosystem Coordination — Migration accessibility and defaults
Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist on Polkadot mainnet.
Coverage basis: Zero migration accessibility on production mainnet.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The absence of migration tooling is confirmed by the official Polkadot Wiki and lack of any PQ-related user documentation. No wallet (Polkadot.js, Talisman, SubWallet, Nova) supports PQ key generation or hybrid accounts.
The RFC describes a hybrid upgrade path where users 'attach a Falcon key without changing the account's existing elliptic curve key, which does not count as a transfer and does not require unstaking, unlocking, etc.' This design is user-friendly in theory but has not been implemented.
migration_enforcement
Migration Mechanism, Governance & Ecosystem Coordination — Migration enforcement and coordination
Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, mandatory migration deadlines) exist on Polkadot mainnet. No exchange, custody, bridge, wallet, or infrastructure coordination for PQ migration has been publicly documented.
Coverage basis: Zero enforcement or coordination mechanisms live.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No public announcements from exchanges, custodians, or infrastructure providers regarding PQ migration coordination for Polkadot have been identified.
Polkadot's OpenGov governance system could theoretically enact migration mandates, but no proposals for quantum-related governance actions have been submitted.
emergency_process
Migration Mechanism, Governance & Ecosystem Coordination — Emergency disclosure, incident-response, or governance process
Claim: Polkadot has a general governance system (OpenGov) and a technical fellowship for protocol upgrades. No quantum-specific incident-response playbook, emergency disclosure process, or quantum-vulnerability governance procedure has been published.
Coverage basis: General governance exists; quantum-specific process does not.
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Polkadot's governance infrastructure (OpenGov referendum system, Technical Fellowship, on-chain treasury) provides a credible mechanism for emergency upgrades. However, no quantum-specific playbook, contact procedure, or pre-authorized emergency path exists. Per QRI spec §6.5, lack of a formal quantum-specific incident-response playbook is an assurance-only caveat unless the absence leaves a current quantum-vulnerable path unresolved.
The RFC discusses rollback mechanisms for hybrid account upgrades: 'If however we make some mistake, then we could roll back all the non-transfer upgrades into hybrid post-quantum accounts, and then correct the situation.'
algorithm_selection
Algorithm & Implementation Assurance — Uses NIST-standardized or broadly reviewed PQC/hybrid-PQC algorithms
Claim: The PQ roadmap selects Falcon (FN-DSA-512) for account signatures and Dilithium (ML-DSA-44) for consensus signatures. Both are NIST-standardized post-quantum signature algorithms (FIPS 203/204).
Coverage basis: Algorithm selections are documented in the roadmap/RFC but not implemented in production.
Implementation score: 0.25 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Falcon and Dilithium are both NIST-standardized (FIPS 203 for ML-DSA, FIPS 204 for FN-DSA). The algorithm selections are appropriate for their use cases (Falcon for compact account signatures, Dilithium for constant-time consensus signing). However, NIST finalization of Falcon key-derivation standards is still pending, which blocks production deployment.
The RFC explicitly states: 'We cannot deploy anything here anyways until NIST standardises FN-DSA (Falcon), because even the key derivation remains unfinalized.' This creates an indefinite deployment dependency.
algorithm_audit
Algorithm & Implementation Assurance — Independent cryptographic and implementation audit
Claim: No independent cryptographic or implementation audit exists for any PQ-related Polkadot component because no PQ implementation has been deployed or published by Parity/Web3 Foundation.
Coverage basis: No implementation exists to audit.
Implementation score: 0 · Evidence confidence: None
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: No audit can exist before implementation. This is an expected gap at the Mitigation/Development stage. When PQ code is published, audits should cover both cryptographic correctness and side-channel resistance of the Falcon/Dilithium implementations.
The roadmap author acknowledges side-channel concerns and cites IACR 2025/1577 noting limited open-source side-channel datasets for PQC schemes.
algorithm_opensource
Algorithm & Implementation Assurance — Open-source, reproducible implementation
Claim: The RFC references open-source Falcon implementation (Thomas Pornin's rust-fn-dsa crate at github.com/pornin/rust-fn-dsa) as the intended base for Polkadot's Falcon support. No Polkadot-specific PQ code has been published.
Coverage basis: Planned open-source dependency exists; no Polkadot integration code published.
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: The referenced rust-fn-dsa crate by Thomas Pornin is open-source and well-regarded in the cryptographic community. However, the Polkadot integration layer (host calls, hybrid key derivation, AssetHub/Vault integration) has no published code and cannot be verified.
A third-party crate (qp-dilithium-crypto by Quantus Network) provides Dilithium signatures for Substrate but is not affiliated with Parity/Web3 Foundation and has no known Polkadot mainnet or Kusama integration.
algorithm_agility
Algorithm & Implementation Assurance — Parameter agility and future upgrade path
Claim: The RFC discusses multiple PQ algorithms (Falcon, Dilithium), hybrid combination approaches, key derivation flexibility, and potential future algorithm transitions. The design contemplates supporting multiple signature schemes concurrently.
Coverage basis: Design documents discuss algorithm agility; not implemented.
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: The RFC demonstrates awareness of algorithm agility needs: 'We suggest a host call for ML-DSA-44(Dilithium) too, because of its heavy adoption outside the blockchain space.' However, these are design considerations rather than implemented capabilities.
The hybrid approach (requiring both Falcon AND sr25519/ed25519 for hybrid accounts) provides classical security even if lattice assumptions are broken, which is a form of cryptographic agility at the design level.
algorithm_stateful
Algorithm & Implementation Assurance — Stateful-signature safety
Claim: Falcon (FN-DSA) and Dilithium (ML-DSA) are both stateless lattice-based signature schemes. They do not require the state management discipline needed by XMSS/LMS-style hash-based stateful signatures.
Coverage basis: Falcon and Dilithium are stateless by design.
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: NIST FIPS 203/204 standards for ML-DSA and FN-DSA confirm these are stateless signature schemes. No state-management concerns apply.
If Polkadot were to adopt SPHINCS+ (SLH-DSA) in the future for additional security diversity, stateful-signature safety would become applicable. Currently not relevant.
algorithm_performance
Algorithm & Implementation Assurance — Performance and resource-impact analysis
Claim: The RFC includes bandwidth and CPU estimates: Falcon-512 signatures are 666 bytes (21× ed25519), public keys 867 bytes (27× ed25519). Verification is ~half the time of sr25519/ed25519. Signing is ~4× slower than ML-DSA and ~20× slower than sr25519.
Coverage basis: Design-level performance analysis exists; no production benchmarks.
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Performance estimates in the RFC are based on published algorithm characteristics (Bas Westerbaan 2022 benchmarks) rather than Polkadot-specific production measurements. No formal performance benchmarks with real Polkadot block data or validator hardware exist.
The RFC notes that 'a Falcon public key and signature together with recovery should cost roughly the same bandwidth as 1.5 NOMT state reads into 1 billion accounts' — suggesting PQ bandwidth cost is manageable in the context of planned storage improvements.
Report metadata