Filecoin FIL

Claim: Filecoin has not published a cryptographic inventory or quantum threat model for its production cryptography.

Coverage basis: Absence of evidence across all primary sources

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No public cryptographic inventory or quantum threat model exists

Assurance: Searches of the Filecoin spec, FIPs repository, and official communications yielded no quantum-specific cryptographic inventory, threat model, or risk assessment. The absence is confirmed with high confidence.

The cryptonet.org (2022 Q3) post mentions Protocol Labs funding research into lattice-based post-quantum SNARKs. This is a research acknowledgment, not a formal inventory or threat model for Filecoin's production system.

• https://spec.filecoin.io/algorithms/crypto/signatures/
• https://github.com/filecoin-project/FIPs
• https://cryptonet.org/

Claim: Protocol Labs' CryptoNet has acknowledged quantum threat to SNARKs and funded lattice-based PQ SNARK research. Filecoin's classical crypto is well-documented in specs and open-source code.

Coverage basis: Research funding acknowledgment and public code/spec documentation

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: note-only

Assurance: The cryptonet.org research funding is a substantiated public statement from Protocol Labs. However, it falls far short of a formal evidence record supporting a quantum-specific assessment of Filecoin's production cryptography.

Scored at 0.25 (public design/research plan) because a minimal research-level acknowledgment exists via the CryptoNet post, but no structured evidence record, code references for quantum risk, transaction examples, or reproducible analytics specific to quantum vulnerability have been published.

• https://cryptonet.org/
• https://spec.filecoin.io/algorithms/crypto/signatures/
• https://github.com/filecoin-project/blstrs

Claim: Filecoin uses ECDSA (secp256k1, signature type 1) and BLS (BLS12-381, signature type 2) for all transaction signatures. FEVM delegated signatures also use secp256k1.

Coverage basis: ECC/BLS-only; no PQC or hybrid support

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Active production spend authorization remains entirely ECC/BLS-only with no PQC path.

Assurance: Confirmed from official Filecoin spec, address-type documentation, and FIP-0055 (FEVM delegated signatures). All signature paths use secp256k1 or BLS12-381 exclusively.

Address types f1 (secp256k1), f3 (BLS12-381), and f410 (secp256k1 Ethereum-compatible) cover all user-facing and contract-facing accounts. No PQ or hybrid signature type exists.

• https://spec.filecoin.io/algorithms/crypto/signatures/
• https://docs.filecoin.io/smart-contracts/filecoin-evm-runtime/address-types/
• https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0055.md

Claim: All Filecoin address types expose ECC/BLS public keys. f1 addresses expose secp256k1 public keys on first spend. f3 addresses expose BLS public keys. f410 addresses expose secp256k1 keys.

Coverage basis: All address types are quantum-vulnerable; long-exposure risk exists

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All address types expose quantum-vulnerable ECC/BLS public keys with no PQ key-derivation or migration path

Assurance: Address-type documentation is unambiguous: f1 = secp256k1, f3 = BLS12-381, f410 = secp256k1. No PQ address type or hybrid key-derivation scheme exists.

Long-exposure risk: f3 (BLS) and f1 (secp256k1) public keys are visible on-chain and can be attacked offline once a CRQC exists. No address-rotation mechanism or PQ key-derivation path is available.

• https://docs.filecoin.io/smart-contracts/filecoin-evm-runtime/address-types/
• https://spec.filecoin.io/algorithms/crypto/signatures/

Claim: Filecoin uses BLS signatures over BLS12-381 for block/ticket signing, F3/GossiPBFT finality certificates, and Drand randomness beacon threshold signatures.

Coverage basis: All consensus authentication is BLS-only (BLS12-381)

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Consensus finality and randomness depend on quantum-vulnerable BLS12-381 signatures.

Assurance: FIP-0086 specifies BLS signatures for GossiPBFT messages and finality certificates. FIP-0063 details Drand quicknet using BLS12-381. The filecoin-f3-blssig crate implements BLS12-381 with BDN aggregation.

A quantum break of BLS12-381 would allow forging finality certificates (≥⅔ QAP threshold) and manipulating the Drand randomness beacon, compromising both fast finality and leader election.

• https://spec.filecoin.io/algorithms/crypto/signatures/
• https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md
• https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0063.md
• https://lib.rs/crates/filecoin-f3-blssig

Claim: Filecoin's PoRep and PoSt storage proofs use Groth16 zk-SNARKs over BLS12-381 pairings, verified millions of times daily on mainnet.

Coverage basis: PoRep/PoSt proofs depend on quantum-vulnerable BLS12-381 pairings

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Quantum attack can plausibly break supply integrity and state binding via forged storage proofs.

Assurance: Confirmed from the Filecoin spec (SDR PoRep, PoSt sections), the SnarkPack research publication, and the rust-fil-proofs codebase. The trusted setup for Groth16 parameters is documented in the phase2-attestations repository.

This is arguably Filecoin's most critical quantum vulnerability. A quantum adversary could forge proofs of replication and spacetime, claiming to store data they do not possess, collecting block rewards and undermining the entire storage-proving economic model.

• https://research.protocol.ai/publications/snarkpack-practical-snark-aggregation/
• https://spec.filecoin.io/algorithms/pos/post/
• https://spec.filecoin.io/algorithms/pos/porep/
• https://spec.filecoin.io/algorithms/sdr/
• https://github.com/filecoin-project/rust-fil-proofs

Claim: Filecoin uses Groth16 zk-SNARKs over BLS12-381 pairings for all storage proofs. The proof system is pairing-based and quantum-vulnerable. Filecoin has no shielded privacy layer.

Coverage basis: ZK proof layer is quantum-vulnerable (Groth16 over BLS12-381)

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Groth16 proof system over BLS12-381 pairings is quantum-vulnerable at the proof-assumption level

Assurance: The Groth16 proving system is well-documented in the Filecoin spec and code. It requires a BLS12-381 pairing check for verification. Quantum attacks on pairings would break soundness.

Filecoin does not have a separate privacy layer (no shielded pools, stealth addresses, or note encryption). The proof-layer vulnerability is covered under the state-integrity subfactor; this subfactor captures the pairing-based ZK assumption risk.

• https://research.protocol.ai/publications/snarkpack-practical-snark-aggregation/
• https://spec.filecoin.io/algorithms/sdr/
• https://github.com/filecoin-project/phase2-attestations

Claim: Filecoin nodes use classical cryptographic mechanisms (libp2p with standard key exchange) for P2P transport and peer identity.

Coverage basis: Classical P2P cryptography; no PQC

Implementation score: 0 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: P2P transport is not the most critical layer for Filecoin's quantum risk, as asset ownership and consensus integrity depend on higher layers. However, node identity compromise could enable eclipse or Sybil attacks that interact with consensus vulnerabilities.

While P2P is classified as quantum-critical vulnerability, its practical severity is lower than the consensus and storage-proof layers. No specific P2P-PQC documentation or implementation was found.

• https://spec.filecoin.io/

Claim: No evidence of PQ wallet, custody, HSM, or hardware-wallet support for Filecoin.

Coverage basis: No PQ wallet or custody path exists

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No PQ wallet, custody, or HSM workflow exists for FIL

Assurance: The absence of PQ wallet/custody support is confirmed with high confidence because no PQ signature types exist for Filecoin accounts. Wallets cannot support a PQ path that the protocol does not provide.

This subfactor is downstream of the protocol's lack of PQ signature support. Even if wallets wanted to implement PQ signing, the protocol has no PQ account type or signature validation path.

Claim: 0% of Filecoin's value-at-risk is protected from quantum attacks. All FIL in all account types (f1, f3, f410) and all storage-provider collateral is quantum-vulnerable.

Coverage basis: 0% protected; all value is in ECC/BLS accounts

Implementation score: 0.05 · 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.

Assurance: Since the protocol supports only ECC/BLS account types and has no PQC address format, all FIL value is quantum-vulnerable by construction. Coverage threshold <25% applies (implementation score 0.05).

Even if an exact percentage could be computed, it would be 0% because no quantum-safe account type exists. All FIL is held in either secp256k1 or BLS12-381 accounts.

• https://docs.filecoin.io/smart-contracts/filecoin-evm-runtime/address-types/
• https://spec.filecoin.io/algorithms/crypto/signatures/

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have migrated to PQ protection because no PQ account type exists.

Coverage basis: Zero critical wallets protected; no PQ account type available

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No critical wallets can migrate because no PQ account type or migration path exists

Assurance: This is a structural consequence of the protocol's lack of PQ support. Critical wallets cannot migrate to protection that does not exist at the protocol level.

Filecoin Foundation, Protocol Labs, exchanges (Coinbase, Binance, etc.), and storage provider operators all hold FIL in quantum-vulnerable accounts with no migration option.

Claim: No legacy vulnerable accounts have been identified, deprecated, or targeted for migration. No freeze, burn, or deprecation policy exists for quantum-vulnerable accounts.

Coverage basis: No identification or deprecation of vulnerable accounts

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No vulnerable-account identification, deprecation, freeze, or burn policy exists

Assurance: Searches of the FIPs repository and Filecoin documentation yielded no proposals addressing legacy vulnerable account identification, deprecation, freeze, or burn for quantum-migration purposes.

Since all account types are quantum-vulnerable by design, this subfactor captures the complete absence of any mechanism to partition, tag, or deprecate vulnerable accounts in preparation for a future migration.

• https://github.com/filecoin-project/FIPs

Claim: No public migration roadmap exists for Filecoin. No FIP addresses PQC migration, signature replacement, or proof-system migration.

Coverage basis: No roadmap; zero migration planning

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No public PQC migration roadmap, FIP, or design document exists

Assurance: Comprehensive search of the FIPs repository (including discussions) for 'quantum', 'post-quantum', 'PQC', 'lattice', 'hash-based', and related terms returned zero relevant results as of June 2026.

The research funding into lattice-based PQ SNARKs (cryptonet.org 2022) is a research activity, not a migration roadmap. No sequencing, activation criteria, dependencies, or timeline has been published.

• https://github.com/filecoin-project/FIPs
• https://github.com/filecoin-project/FIPs/discussions

Claim: No PQ account creation, wallet tooling, transaction paths, custody paths, user warnings, or migration prompts exist.

Coverage basis: No migration accessibility or tooling

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No PQ account creation, migration tooling, or user-facing migration path exists

Assurance: Since the protocol has no PQ account type, no downstream tooling can exist. This is a structural gap.

This subfactor covers the entire user-facing migration experience, which is entirely absent. There are no warnings about quantum vulnerability in any official Filecoin wallet or documentation.

Claim: No enforcement mechanisms, coordination with exchanges/custodians/bridges/wallets, or unsafe-path blocking exists for quantum migration.

Coverage basis: No enforcement or coordination mechanisms

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No migration enforcement or ecosystem coordination exists

Assurance: Enforcement mechanisms cannot exist without a migration target. No exchange, custody, bridge, or wallet coordination for quantum migration has been publicly documented.

The filecoin.io and fil.org websites contain no quantum-related security advisories, migration guidance, or coordination announcements.

Claim: No quantum-specific disclosure, incident-response, or governance process has been published.

Coverage basis: No quantum-specific emergency process

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Quantum blocker: No quantum-specific incident-response or governance process exists

Assurance: The fil.org/security page provides general security contact information but contains no quantum-specific disclosure process, incident-response playbook, or emergency governance procedure.

While Filecoin has general security processes, the absence of quantum-specific emergency procedures is a gap given the protocol's total dependence on quantum-vulnerable cryptography.

• https://fil.org/security

Claim: Filecoin uses no PQC algorithms in production. All cryptography is classical (secp256k1 ECDSA, BLS12-381 signatures and pairings, Groth16 SNARKs).

Coverage basis: No PQC algorithms used

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No NIST-standardized or broadly reviewed PQC algorithms are used in production

Assurance: The absence of PQC algorithms is confirmed from the Filecoin spec and all primary source code repositories (blstrs, rust-fil-proofs, lotus). Only classical algorithms are used.

The cryptonet.org research into lattice-based PQ SNARKs has not resulted in any production algorithm selection, FIP, or implementation.

• https://spec.filecoin.io/algorithms/crypto/signatures/
• https://github.com/filecoin-project/blstrs
• https://github.com/filecoin-project/rust-fil-proofs

Claim: Classical crypto audits exist (NCC Group 2020, Sigma Prime 2020, Oak Security 2023) but no PQC audit exists because no PQC is implemented.

Coverage basis: Classical audits only; no PQC audit scope

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: Classical audits are stale (2020–2023) but remain relevant for confirming the classical-only design. They provide no assurance for any future PQC implementation. This is an assurance-only caveat that does not independently reduce the QRI Score.

Scored 0.00 because there is no independent audit of any quantum-safe implementation. The classical audits confirm the quantum-vulnerable design but do not advance quantum readiness.

• https://spec.filecoin.io/appendix/audit_reports/
• https://www.pentestreports.com/files/reports/nccgroup/NCC_Group_ProtocolLabs_PRLB007_Report_2020-10-20_v1.0.pdf

Claim: Filecoin's cryptographic implementations (blstrs, rust-fil-proofs, lotus) are open-source and publicly buildable, but implement only classical algorithms.

Coverage basis: Open-source classical implementation; no PQ implementation

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The classical code is well-structured, publicly available, and buildable. This provides a foundation for future PQ implementation but does not constitute PQ readiness.

Scored at 0 because there is no PQC implementation to evaluate. The open-source nature of classical code aids future migration but does not constitute PQC readiness.

• https://github.com/filecoin-project/blstrs
• https://github.com/filecoin-project/rust-fil-proofs
• https://github.com/filecoin-project/lotus

Claim: No documented parameter agility or upgrade path for replacing cryptographic primitives with PQ alternatives exists.

Coverage basis: No parameter agility or upgrade path documented

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No documented parameter agility or cryptographic upgrade path

Assurance: Filecoin's architecture deeply embeds specific cryptographic choices (BLS12-381, Groth16, SDR parameters) into the protocol, consensus rules, gas schedule, and trusted setup. No FIP or design document describes how these could be replaced or upgraded.

The NI-PoRep upgrade (FIP-0092) demonstrates that proof-system changes are possible through the FIP process, but this was within the same Groth16/BLS12-381 framework. A full PQ migration would require far more fundamental changes.

• https://github.com/filecoin-project/FIPs

Claim: Filecoin does not use stateful hash-based signatures (XMSS/LMS). No PQC implementation exists to evaluate stateful-signature safety.

Coverage basis: N/A for current production (no PQC implementation)

Implementation score: 0 · Evidence confidence: not applicable

Issue classification: none · Score treatment: not applicable

If Filecoin were to adopt XMSS/LMS in a future PQ migration, this subfactor would become applicable and state-management risks would need to be assessed.

Claim: No public performance or resource-impact analysis exists for deploying PQ signatures or PQ proof systems on Filecoin.

Coverage basis: No PQ performance analysis

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: The scale of Filecoin's proof verification (millions of SNARKs/day) would create significant performance challenges for PQ-SNARK migration. The complete absence of such analysis is a significant gap.

This is scored at 0.00 because no analysis exists. However, per the QRI spec, the absence of a formal performance benchmark is normally a note-only caveat unless resource constraints prevent safe use of PQ controls. Since no PQ controls exist at all, this subfactor is scored on its implementation status (none).

• https://research.protocol.ai/publications/snarkpack-practical-snark-aggregation/