---
title: Is Filecoin quantum-safe?
chain: Filecoin
ticker: FIL
hardy_score: 8.5
rank: 61 of 80
tier: "5: Exposed"
url: "https://hardyindex.com/chains/filecoin"
updated: 2026-10-22
reviewed: 2026-11-13
methodology_version: 1.8
---

# Is Filecoin quantum-safe?

**Hardy Score 8.5 / 100. Rank 61 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.**

No. Filecoin has two native account types, and a sufficiently large quantum computer running Shor's algorithm would break both: f1 accounts sign with ECDSA on secp256k1, which is the Lotus wallet's default, and f3 accounts sign with BLS signatures on the BLS12-381 curve. Ethereum-compatible f410 accounts also sign with secp256k1. Storage providers sign blocks with a worker key that the specification requires to be BLS, and the same key signs the BLS-aggregated votes of F3, the fast-finality protocol of FIP-0086. No Filecoin Improvement Proposal, specification section or statement from the core developers addresses post-quantum signatures; the post-quantum items found in the project's GitHub organisation are all grant applications from outside teams. Filecoin's storage proofs use Groth16 SNARKs over BLS12-381, which a quantum computer would also break, but they prove storage rather than authorise spends, so they sit outside what this rating scores.

> This is a security-readiness assessment, not investment advice.

## Summary

Signs accounts with ECDSA on secp256k1 or BLS on BLS12-381, signs blocks and finality votes with BLS, and has no post-quantum improvement proposal, plan or research programme for any of them.

## Where we are making a judgement call

Three judgement calls carry this profile. The first is scope. Filecoin's proofs of replication and spacetime are Groth16 SNARKs over BLS12-381, and its randomness comes from drand's BLS threshold signatures; a quantum computer would break both, and forged storage proofs could earn block rewards. Neither authorises a spend, so under v1.8 neither is a fund-protecting signature, and they are recorded but not scored. Counting them would change no score, because nothing post-quantum exists for them either. The second is the tier. The devgrants repository holds several grant applications with post-quantum themes, such as a December 2025 proposal for a post-quantum FIL bridge, but they come from outside teams with no authority over the chain and concern their own products; a reader who counted them as a public research programme would place Filecoin in Tier 4, with a deployment score of 2 and a Hardy Score of 11.0 rather than 8.5. The third is exposure. f3 addresses publish their BLS keys by construction and every block producer's worker key is public, which argues for a 1, and a reader who scores it so would give a Hardy Score of 7.5. We hold it at 2 because f1 and f410 addresses do hide unused keys and no measured share of exposed FIL has been published.

## Score breakdown

| # | Dimension | Score | Weight | Contribution |
|---:|---|---:|---:|---:|
| 1 | Signature scheme | 0/10 | 30% | 0.0 |
| 2 | Deployment stage | 1/10 | 25% | 2.5 |
| 3 | NIST alignment | 0/10 | 15% | 0.0 |
| 4 | Migration path | 2/10 | 15% | 3.0 |
| 5 | Exposure | 2/10 | 10% | 2.0 |
| 6 | Verification | 2/10 | 5% | 1.0 |
| | **Hardy Score** | | | **8.5** |

### 1. Signature scheme: 0/10

Anchor band 0: Classical signatures only on mainnet, with nothing post-quantum protecting live funds. Short-lived devnets and one-off benchmarks sit here: they demonstrate research rather than something a user can hold keys on.

The Filecoin specification lists two signature types, ECDSA over secp256k1 to authenticate user messages and BLS over BLS12-381, and Ethereum-compatible accounts sign with secp256k1 under FIP-0055. All are broken by Shor's algorithm, and nothing post-quantum protects FIL on mainnet.

Source: https://spec.filecoin.io/algorithms/crypto/signatures/

### 2. Deployment stage: 1/10

Anchor band 1: Tier 5: Exposed.

Tier 5: Exposed. The signatures securing FIL are quantum-vulnerable, and no Filecoin Improvement Proposal, specification section or core-developer statement on post-quantum signatures exists: the FIPs repository does not mention quantum computing at all. The post-quantum grant applications filed in the devgrants repository come from outside teams with no authority over the chain.

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

### 3. NIST alignment: 0/10

Anchor band 0 to 2: No post-quantum scheme named for the chain’s fund-protecting signatures, or a proprietary scheme with no public cryptanalysis.

No post-quantum scheme has been named for Filecoin's account, block or finality signatures in any FIP, in the specification or by the core developers, so there is nothing to align with a NIST standard.

Placement in the band: The floor of the band rather than a 1 or a 2: no scheme has been named for Filecoin's own signatures at all, as distinct from a scheme named without commitment. Outside grant applicants naming Dilithium or SPHINCS+ for their own products do not count, because they are not naming it for the chain.

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

### 4. Migration path: 2/10

Anchor band 0 to 2: No agreed migration path, or the proposals on the table would strand or freeze holder funds.

No migration plan exists. Filecoin does have real machinery a migration could use: its address format versions signature schemes by a protocol byte, so a new scheme would take a new address protocol, and FIP-0048 added the f4 address class so that new addressing schemes can be added through address manager actors. Nobody with authority has proposed using either for post-quantum keys.

Placement in the band: The top of the band rather than a 0 or a 1: versioned address protocols and the extensible f4 class are working mechanisms for introducing a new account type, and network upgrades through the FIP process routinely change the protocol. Not a 3, because no one with authority over Filecoin has acknowledged migration as a problem to solve.

Source: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md

### 5. Exposure: 2/10

Anchor band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses.

f1 addresses are a Blake2b-160 hash of the secp256k1 public key and f410 addresses follow Ethereum's key hash, so those keys stay hidden until the account signs. f3 addresses carry the 48-byte BLS public key itself, so every f3 key is public from the address alone, and every storage provider's worker key is a BLS key used to sign blocks.

Placement in the band: The top of the band rather than a 1: the f1 and f410 address types do hide the key of an account that has never sent a message. Not a 3, because f3 addresses publish their keys by construction, every storage provider's worker key is public, and any account that has sent a message has revealed its key; nobody has published a measured share.

Source: https://spec.filecoin.io/appendix/address/

### 6. Verification: 2/10

Anchor band 0 to 2: No post-quantum component exists, or the claims rest on marketing.

No post-quantum component exists for Filecoin: no code, specification or testnet implementation for its signatures was found. Lotus and the proof libraries are open source, but under v1.8 the openness of the classical code earns nothing here.

Placement in the band: The top of the band rather than a 0 or a 1: there is no post-quantum component to verify, but nothing about Filecoin is marketed as quantum-safe by the project, so its position does not rest on marketing.

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

## Nearest chains in the ranking

The chains Filecoin sits among, out of 80 rated. The last column is the gap in Hardy points from Filecoin.

| Rank | Chain | Tier | Hardy | vs FIL |
|---:|---|---|---:|---:|
| 57 | [Chiliz Chain](https://hardyindex.com/chains/chiliz) | 5: Exposed | 8.5 | level |
| 58 | [Conflux](https://hardyindex.com/chains/conflux) | 5: Exposed | 8.5 | level |
| 59 | [dYdX Chain](https://hardyindex.com/chains/dydx) | 5: Exposed | 8.5 | level |
| 60 | [eCash](https://hardyindex.com/chains/ecash) | 5: Exposed | 8.5 | level |
| 61 | **Filecoin** | 5: Exposed | 8.5 | this chain |
| 62 | [GateChain](https://hardyindex.com/chains/gatechain) | 5: Exposed | 8.5 | level |
| 63 | [Gnosis Chain](https://hardyindex.com/chains/gnosis) | 5: Exposed | 8.5 | level |
| 64 | [Injective](https://hardyindex.com/chains/injective) | 5: Exposed | 8.5 | level |
| 65 | [KCC (KuCoin Community Chain)](https://hardyindex.com/chains/kcc) | 5: Exposed | 8.5 | level |

## Signature scheme

- **On mainnet today:** ECDSA on secp256k1 for f1 and Ethereum-compatible f410 accounts; BLS on BLS12-381 for f3 accounts, block signatures by storage providers' worker keys and F3 finality votes
- **Post-quantum scheme:** None selected or proposed
- **NIST standard:** None adopted
- **Readiness tier:** Tier 5: Exposed. The signatures securing funds on mainnet today are quantum-vulnerable, and no public post-quantum plan, proposal or research programme addressing them could be found.

## Cryptography in use

- **Account signatures:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, default. The Lotus wallet creates secp256k1 (f1) keys unless told otherwise. Ethereum-compatible f410 accounts also sign with secp256k1, under FIP-0055.
  Source (source code or release): https://github.com/filecoin-project/lotus/blob/master/cli/wallet.go
- **Account signatures:** [BLS signatures on BLS12-381](https://hardyindex.com/algorithms/bls12-381.md). Mainnet, opt-in. f3 accounts. The address embeds the BLS public key itself.
  Source (specification or proposal): https://spec.filecoin.io/algorithms/crypto/signatures/
- **Validator consensus:** [BLS signatures on BLS12-381](https://hardyindex.com/algorithms/bls12-381.md). Mainnet, mandatory. A storage provider's worker key, which must be BLS, signs its blocks and election tickets, and signs F3 finality votes, which are aggregated with BLS. A mainnet node returned a current F3 finality certificate on 22 October 2026.
  Source (specification or proposal): https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md
- **Randomness:** [BLS signatures on BLS12-381](https://hardyindex.com/algorithms/bls12-381.md). Mainnet, mandatory. The drand quicknet beacon, a BLS12-381 threshold signature with signatures on G1, supplies Filecoin's randomness.
  Source (specification or proposal): https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0063.md

A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md.

## Roadmap

- **2 October 2022** (shipped): FIP-0048 is created, adding the extensible f4 address class through which new addressing schemes can be introduced. It is now Final, and Ethereum-compatible f410 accounts use it. It does not mention post-quantum keys.
  Source: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md
- **18 December 2023** (shipped): FIP-0086, Fast Finality in Filecoin (F3), is created. Now Final and running on mainnet, it adds finality votes signed with storage providers' BLS worker keys and aggregated with BLS on BLS12-381.
  Source: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md
- **No date published** (proposed): No FIP, specification change, implementation or timeline for post-quantum signatures on Filecoin was found.
  Source: https://github.com/filecoin-project/FIPs

## If holders never migrate

**No stated policy.** No FIP, specification section or core-developer statement addresses FIL in accounts that never move to post-quantum keys, since no post-quantum account type has been proposed. As of 22 October 2026. Source: https://github.com/filecoin-project/FIPs

## Exposure

Filecoin mixes the two address models. An f1 address is a Blake2b-160 hash of a secp256k1 public key and an f410 address is an Ethereum address derived from a key hash, so both hide the key until the account first signs. An f3 address is the 48-byte BLS public key itself plus a checksum, so an f3 key is public from the moment the address is shared, whether or not it has ever signed. Every storage provider's worker key is a BLS key that signs its blocks, so the keys that produce Filecoin's blocks and F3 finality votes are all public. FIL held in storage providers' miner actors, including pledge collateral, is administered and withdrawn by owner keys. No measurement of the share of FIL behind revealed keys has been published.

## Frequently asked questions

### Is Filecoin quantum-safe?

No. Filecoin has two native account types, and a sufficiently large quantum computer running Shor's algorithm would break both: f1 accounts sign with ECDSA on secp256k1, which is the Lotus wallet's default, and f3 accounts sign with BLS signatures on the BLS12-381 curve. Ethereum-compatible f410 accounts also sign with secp256k1. Storage providers sign blocks with a worker key that the specification requires to be BLS, and the same key signs the BLS-aggregated votes of F3, the fast-finality protocol of FIP-0086. No Filecoin Improvement Proposal, specification section or statement from the core developers addresses post-quantum signatures; the post-quantum items found in the project's GitHub organisation are all grant applications from outside teams. Filecoin's storage proofs use Groth16 SNARKs over BLS12-381, which a quantum computer would also break, but they prove storage rather than authorise spends, so they sit outside what this rating scores.

### Is Filecoin quantum-safe?

No. Filecoin accounts sign with ECDSA on secp256k1 or with BLS on BLS12-381, and storage providers sign blocks and finality votes with BLS. A sufficiently large quantum computer would break all of them, and there is no post-quantum improvement proposal or plan for Filecoin.

### Are Filecoin f3 addresses more exposed than f1 addresses?

Yes. An f1 address is a hash of a secp256k1 key, so the key stays hidden until the account signs a message. An f3 address contains the BLS public key itself, so the key is visible to anyone who sees the address, even if the account has never signed.

### Do Filecoin's storage proofs need to become post-quantum too?

Eventually, yes. Proofs of replication and spacetime are Groth16 SNARKs over BLS12-381, which a quantum computer could forge. They prove that storage exists rather than authorising spends, so this rating does not score them, but a post-quantum Filecoin would need replacements for them as well as for its signatures.

### What would move Filecoin up the index?

A FIP or a public research programme from Filecoin's core developers on post-quantum account or block signatures would meet the Tier 4 floor. A published plan naming the scheme would meet Tier 3. Filecoin's versioned address protocols and the f4 address class already give it a way to add a new account type.

## What this rating means if you hold Filecoin

Plain-language guidance from the same publication, with no product recommendation attached.

- [Is my crypto safe from quantum computers?](https://hardyindex.com/guides/is-my-crypto-safe-from-quantum-computers.md)
- [How to protect your crypto from quantum computers](https://hardyindex.com/guides/how-to-protect-crypto-from-quantum-computers.md)
- [All guides](https://hardyindex.com/guides.md)


## Sources

1. [Signatures](https://spec.filecoin.io/algorithms/crypto/signatures/): Filecoin Spec (primary, checked 22 October 2026)
2. [Address](https://spec.filecoin.io/appendix/address/): Filecoin Spec (primary, checked 22 October 2026)
3. [Key Store](https://spec.filecoin.io/systems/filecoin_nodes/repository/key_store/): Filecoin Spec (primary, checked 22 October 2026)
4. [Address types](https://docs.filecoin.io/core-concepts/filecoin-evm-runtime/address-types): Filecoin documentation (primary, checked 22 October 2026)
5. [Lotus wallet commands (cli/wallet.go)](https://github.com/filecoin-project/lotus/blob/master/cli/wallet.go): Lotus (GitHub) (primary, checked 22 October 2026)
6. [Filecoin Improvement Proposals](https://github.com/filecoin-project/FIPs): Filecoin (GitHub) (primary, checked 22 October 2026)
7. [FIP-0048: f4 Address Class](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md): Filecoin (GitHub) (primary, checked 22 October 2026)
8. [FIP-0055: Supporting Ethereum Accounts, Addresses, and Transactions](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0055.md): Filecoin (GitHub) (primary, checked 22 October 2026)
9. [FIP-0063: Switching to new Drand mainnet network](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0063.md): Filecoin (GitHub) (primary, checked 22 October 2026)
10. [FIP-0086: Fast Finality in Filecoin (F3)](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md): Filecoin (GitHub) (primary, checked 22 October 2026)
11. [bellperson: zk-SNARK library (Groth16 over BLS12-381)](https://github.com/filecoin-project/bellperson): Filecoin (GitHub) (primary, checked 22 October 2026)
12. [Open Grant Proposal: QSN Post-Quantum Bridge for Filecoin](https://github.com/filecoin-project/devgrants/issues/2010): Filecoin devgrants (GitHub) (secondary, checked 22 October 2026)

## How to cite this rating

A rating is only true as of the day it was reviewed, so both forms carry the review date and the methodology version. If you are quoting the score, quote those too.

The Hardy Index (2026). Filecoin: quantum readiness assessment. Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/filecoin

```bibtex
@misc{hardyindex_filecoin_2026,
  author       = {{The Hardy Index}},
  title        = {Filecoin: quantum readiness assessment},
  year         = {2026},
  howpublished = {\url{https://hardyindex.com/chains/filecoin}},
  note         = {Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8},
  urldate      = {2026-11-13}
}
```

---

Methodology: https://hardyindex.com/methodology (v1.8).
Cite as: The Hardy Index, "Filecoin", https://hardyindex.com/chains/filecoin, as of 13 November 2026.
