--- title: Is Flare quantum-safe? chain: Flare ticker: FLR hardy_score: 13 rank: 39 of 80 tier: "5: Exposed" url: "https://hardyindex.com/chains/flare" updated: 2026-10-22 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is Flare quantum-safe? **Hardy Score 13.0 / 100. Rank 39 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.** No. Flare runs go-flare, a modified version of avalanchego, and its C-chain and P-chain transactions are signed with ECDSA on the secp256k1 curve. Validators sign the blocks they propose with their staking certificate key, ECDSA on P-256 by default, and the Flare Systems Protocol, which finalises FTSO prices and Flare Data Connector attestations, accepts a result once data providers holding more than half the weight, or more than 60% when finalisation is delayed, have signed it with ECDSA. A sufficiently large quantum computer running Shor's algorithm would break all of these. Flare Research did publish a paper in July 2022, A hybrid post-quantum digital signature scheme for the Ethereum virtual machine, by Jernej Tonejc and Naïri Usher, proposing a new EVM transaction type carrying deterministic CRYSTALS-Dilithium Level 2 alongside ECDSA. The paper is written for the EVM in general, not for Flare, and we found no Flare improvement proposal, code, testnet or later publication taking it forward, which is why Flare sits in Tier 5 rather than Tier 4. See the caveat on that call. > This is a security-readiness assessment, not investment advice. ## Summary Signs C-chain and P-chain transactions with ECDSA on secp256k1, and its one post-quantum item is a 2022 Flare Research paper proposing Dilithium for EVM transactions that was never brought to Flare governance or built. ## Where we are making a judgement call The tier is a judgement call. Tier 4 asks for post-quantum work on the chain's own signatures, documented by people with authority over it in a formal improvement proposal or a public research programme. Flare Research's 2022 paper is more than a blog post: it selects a scheme, specifies a transaction type and address derivation, and sits in Flare's own series of white papers. We read it as falling short for three reasons. It is written for the EVM in general and never mentions Flare's chains; it was never brought into Flare's FIP or STP process; and in four years no code, testnet or further publication has followed, so we found one paper rather than a programme. A reader who counts a chain's own research team publishing a concrete design as a research programme would place Flare in Tier 4, raising the deployment score from 1 to 2 and the Hardy Score by 2.5 points. The NIST alignment score of 3 and the migration score of 2 credit the paper only as a design by Flare's own researchers: it is written for the EVM in general rather than for Flare's signatures, and it names pre-standard round-three Dilithium, so neither score would change. A second, smaller call: the Flare Systems Protocol's data-provider signatures are recorded as ledger attestation, because they finalise prices and cross-chain attestations that FAssets collateral depends on, rather than as account or validator signatures. ## 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 | 3/10 | 15% | 4.5 | | 4 | Migration path | 2/10 | 15% | 3.0 | | 5 | Exposure | 2/10 | 10% | 2.0 | | 6 | Verification | 2/10 | 5% | 1.0 | | | **Hardy Score** | | | **13.0** | ### 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. go-flare's secp256k1 package signs and recovers keys with the decred secp256k1 ECDSA implementation, used for P-chain transactions, and the C-chain recovers EVM senders with ECDSA on secp256k1. Nothing post-quantum protects FLR or any asset on Flare today. Source: https://github.com/flare-foundation/go-flare/blob/main/avalanchego/utils/crypto/secp256k1/secp256k1.go ### 2. Deployment stage: 1/10 Anchor band 1: Tier 5: Exposed. Tier 5: Exposed. The signatures securing Flare are quantum-vulnerable. The one post-quantum item, a 2022 Flare Research paper proposing a hybrid Dilithium transaction type for the EVM, was not taken into Flare's FIP or STP governance process, and no implementation or later work followed. See the caveat below on why this is a judgement call. Source: https://dev.flare.network/pdf/whitepapers/20220722-HybridPostQuantumDigitalSignatureSchemeForTheEthereumVirtualMachine.pdf ### 3. NIST alignment: 3/10 Anchor band 3 to 5: NIST schemes are referenced as candidates without a committed selection, or the work is bespoke research. The Flare Research paper selects one scheme for EVM transaction signatures in general, not for Flare's own: deterministic CRYSTALS-Dilithium Level 2, the pre-standard round-three form of the scheme NIST later standardised as ML-DSA in FIPS 204. Flare has not adopted it or any other scheme for its own accounts or validators. Placement in the band: The floor of the band rather than a 4 or a 5: the paper names round-three Dilithium for the EVM in general rather than for Flare's own signatures, and Flare never proposed or adopted it. Above a 2, because Flare's own research team published it and it selects a single scheme and security level. Source: https://dev.flare.network/pdf/whitepapers/20220722-HybridPostQuantumDigitalSignatureSchemeForTheEthereumVirtualMachine.pdf ### 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. The paper sketches a mechanism: new hybrid addresses derived from both an ECDSA and a Dilithium key, with a possible cutoff after which addresses created later may only send hybrid transactions. Existing addresses would keep signing with ECDSA alone, so holders would have to move funds to gain protection. Placement in the band: The top of the band rather than a 0 or a 1: Flare's own research team has published a concrete hybrid-address design for EVM accounts. Not a 3, because the paper is written for the EVM in general rather than for Flare, it was never proposed to Flare governance, it leaves the P-chain and validator keys unaddressed, and no one with authority over Flare has acknowledged migration as Flare's problem. Source: https://dev.flare.network/pdf/whitepapers/20220722-HybridPostQuantumDigitalSignatureSchemeForTheEthereumVirtualMachine.pdf ### 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. Both Flare address formats are key hashes: a C-chain address is the Ethereum-style Keccak hash of the public key, and a P-chain address is RIPEMD-160 of SHA-256 of the key, so an account that has never signed keeps its key private. Accounts in active use have signed and published their keys. Placement in the band: The top of the band rather than a 0 or a 1: the hashed-address model protects never-signed accounts on both chains. Not a 3, because the accounts that hold economically meaningful FLR have signed, staking and delegation included, and no measured share of exposed supply has been published. Source: https://github.com/flare-foundation/go-flare/blob/main/avalanchego/utils/crypto/secp256k1/secp256k1.go ### 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 Flare: the 2022 paper specifies a design, and no code, governance proposal or testnet implementation was found in Flare's public repositories. Under v1.8 a design paper is not a component, and the openness of the classical node earns nothing here. Placement in the band: The top of the band rather than a 0 or a 1: there is nothing to verify, but Flare does not market the chain as quantum-safe, and the paper presents its scheme as a proposal for the EVM rather than as something Flare runs. Source: https://github.com/flare-foundation/go-flare ## Nearest chains in the ranking The chains Flare sits among, out of 80 rated. The last column is the gap in Hardy points from Flare. | Rank | Chain | Tier | Hardy | vs FLR | |---:|---|---|---:|---:| | 35 | [Bitcoin](https://hardyindex.com/chains/bitcoin) | 4: Debating | 14.5 | +1.5 | | 36 | [Sonic](https://hardyindex.com/chains/sonic) | 5: Exposed | 14.5 | +1.5 | | 37 | [Terra Classic](https://hardyindex.com/chains/terra-classic) | 5: Exposed | 14.5 | +1.5 | | 38 | [Ethereum Classic](https://hardyindex.com/chains/ethereum-classic) | 5: Exposed | 13.0 | level | | 39 | **Flare** | 5: Exposed | 13.0 | this chain | | 40 | [Internet Computer](https://hardyindex.com/chains/internet-computer) | 5: Exposed | 13.0 | level | | 41 | [TON](https://hardyindex.com/chains/toncoin) | 5: Exposed | 11.0 | -2.0 | | 42 | [Decred](https://hardyindex.com/chains/decred) | 5: Exposed | 10.5 | -2.5 | | 43 | [IOTA](https://hardyindex.com/chains/iota) | 5: Exposed | 10.5 | -2.5 | ## Signature scheme - **On mainnet today:** ECDSA on secp256k1 for C-chain and P-chain transactions; validator block signatures with the staking certificate key (ECDSA on P-256 by default); ECDSA signatures from data providers to finalise Flare Systems Protocol results - **Post-quantum scheme:** None selected for Flare. A 2022 Flare Research paper proposes deterministic CRYSTALS-Dilithium Level 2 in a hybrid EVM transaction type; it was not adopted or implemented. - **NIST standard:** None adopted. The paper's Dilithium is the round-three predecessor of ML-DSA, standardised in FIPS 204. - **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, mandatory. P-chain keys and addresses; the C-chain recovers EVM senders with ECDSA on the same curve. Source (source code or release): https://github.com/flare-foundation/go-flare/blob/main/avalanchego/utils/crypto/secp256k1/secp256k1.go - **Validator consensus:** [ECDSA on secp256r1](https://hardyindex.com/algorithms/ecdsa-secp256r1.md). Mainnet, default. New staking certificates are generated with ECDSA on P-256, and proposervm signs each proposed block with the staking key. The signature identifies the proposer the stake-weighted windower picked for that slot; Snowman finalises blocks by repeated sub-sampled voting among validators, not by collecting signatures. Signature checks also accept RSA certificates, which the registry does not yet list. Source (source code or release): https://github.com/flare-foundation/go-flare/blob/main/avalanchego/staking/tls.go - **Ledger attestation:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, mandatory. The Relay contract checks data providers' signatures with ecrecover and finalises an FTSO or Flare Data Connector Merkle root once signers exceed the signing policy's weight threshold, which the Flare Systems Protocol documentation gives as more than 50% of the weight normally and more than 60% in case of delays. Source (source code or release): https://github.com/flare-foundation/flare-smart-contracts-v2/blob/main/contracts/protocol/implementation/Relay.sol - **Account signatures:** [ML-DSA](https://hardyindex.com/algorithms/ml-dsa.md) (Deterministic CRYSTALS-Dilithium Level 2 (round three)). Proposed. Proposed in a 2022 Flare Research paper for a hybrid EVM transaction type in general, not proposed for Flare's chains; never taken into Flare governance or implemented. Source (specification or proposal): https://dev.flare.network/pdf/whitepapers/20220722-HybridPostQuantumDigitalSignatureSchemeForTheEthereumVirtualMachine.pdf A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **5 July 2022** (shipped): Flare Research publishes A hybrid post-quantum digital signature scheme for the Ethereum virtual machine, proposing a transaction type that carries deterministic CRYSTALS-Dilithium Level 2 alongside ECDSA, with new hybrid addresses. Source: https://dev.flare.network/pdf/whitepapers/20220722-HybridPostQuantumDigitalSignatureSchemeForTheEthereumVirtualMachine.pdf - **No date published** (proposed): No FIP or STP, implementation, testnet or timeline for post-quantum signatures on Flare was found, and no later Flare publication takes the 2022 paper forward. Source: https://proposals.flare.network ## If holders never migrate **No stated policy.** Flare has published no post-quantum migration plan. The 2022 Flare Research paper notes that existing addresses could only ever sign with ECDSA and that nodes would decide how long to accept classical transactions, but that is a research observation, not a Flare policy. As of 22 October 2026. Source: https://dev.flare.network/pdf/whitepapers/20220722-HybridPostQuantumDigitalSignatureSchemeForTheEthereumVirtualMachine.pdf ## Exposure Flare has two address formats, both hashes of the public key: the C-chain uses Ethereum's Keccak-derived address, and the P-chain uses RIPEMD-160 of SHA-256, as in avalanchego. An account that has received FLR but never signed has not revealed its key on either chain. The protection ends at the first signature, and staking and delegation on the P-chain require signing, so economically meaningful FLR sits behind keys that can be collected today against a future quantum computer. The C-chain uses Ethereum's key and address format, so a key that has already signed on another EVM chain is exposed on Flare too. Flare has its own genesis and shares no transaction history with Avalanche, so no inherited measurement applies, and none specific to Flare has been published. ## Frequently asked questions ### Is Flare quantum-safe? No. Flare runs go-flare, a modified version of avalanchego, and its C-chain and P-chain transactions are signed with ECDSA on the secp256k1 curve. Validators sign the blocks they propose with their staking certificate key, ECDSA on P-256 by default, and the Flare Systems Protocol, which finalises FTSO prices and Flare Data Connector attestations, accepts a result once data providers holding more than half the weight, or more than 60% when finalisation is delayed, have signed it with ECDSA. A sufficiently large quantum computer running Shor's algorithm would break all of these. Flare Research did publish a paper in July 2022, A hybrid post-quantum digital signature scheme for the Ethereum virtual machine, by Jernej Tonejc and Naïri Usher, proposing a new EVM transaction type carrying deterministic CRYSTALS-Dilithium Level 2 alongside ECDSA. The paper is written for the EVM in general, not for Flare, and we found no Flare improvement proposal, code, testnet or later publication taking it forward, which is why Flare sits in Tier 5 rather than Tier 4. See the caveat on that call. ### Is Flare quantum-safe? No. Flare's C-chain and P-chain transactions are signed with ECDSA on secp256k1, validators sign proposed blocks with an elliptic-curve staking key, and Flare Systems Protocol results are finalised with ECDSA signatures from data providers. A sufficiently large quantum computer would break all of them, and nothing post-quantum runs on any Flare network. ### Has Flare done any post-quantum work? One paper. In July 2022 Flare Research published a design for a hybrid EVM transaction type that adds a deterministic CRYSTALS-Dilithium Level 2 signature to the usual ECDSA one, with new addresses derived from both keys. It is a proposal for the EVM in general, and we found no Flare governance proposal, implementation or later publication taking it forward. ### Does Flare inherit Avalanche's quantum position? It inherits the code, not the history. go-flare is a modified version of avalanchego, so Flare shares Avalanche's secp256k1 keys, hashed addresses and staking certificates, and any post-quantum change to avalanchego would be available to Flare to adopt. Flare has its own genesis, though, so none of Avalanche's transaction history or exposure carries over. ### What would move Flare up the index? A FIP, or a continuing public research programme from Flare on post-quantum signatures for its own chains, would meet the Tier 4 floor. A published plan from the Flare Foundation naming the scheme it will adopt would meet Tier 3. Code on Coston2, Flare's test network, would also lift the signature and verification scores. ## What this rating means if you hold Flare 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. [A hybrid post-quantum digital signature scheme for the Ethereum virtual machine](https://dev.flare.network/pdf/whitepapers/20220722-HybridPostQuantumDigitalSignatureSchemeForTheEthereumVirtualMachine.pdf): Flare Research (primary, checked 22 October 2026) 2. [Whitepapers](https://flare.network/whitepapers): Flare (primary, checked 22 October 2026) 3. [go-flare node client](https://github.com/flare-foundation/go-flare): Flare Foundation (GitHub) (primary, checked 22 October 2026) 4. [secp256k1 keys and signatures (avalanchego/utils/crypto/secp256k1/secp256k1.go)](https://github.com/flare-foundation/go-flare/blob/main/avalanchego/utils/crypto/secp256k1/secp256k1.go): Flare Foundation (GitHub) (primary, checked 22 October 2026) 5. [Staking certificate generation (avalanchego/staking/tls.go)](https://github.com/flare-foundation/go-flare/blob/main/avalanchego/staking/tls.go): Flare Foundation (GitHub) (primary, checked 22 October 2026) 6. [Proposed block signing (avalanchego/vms/proposervm/block/build.go)](https://github.com/flare-foundation/go-flare/blob/main/avalanchego/vms/proposervm/block/build.go): Flare Foundation (GitHub) (primary, checked 22 October 2026) 7. [Proposer selection (avalanchego/vms/proposervm/proposer/windower.go)](https://github.com/flare-foundation/go-flare/blob/main/avalanchego/vms/proposervm/proposer/windower.go): Flare Foundation (GitHub) (primary, checked 22 October 2026) 8. [Avalanche Consensus](https://build.avax.network/docs/primary-network/avalanche-consensus): Avalanche Builder Hub (primary, checked 22 October 2026) 9. [Relay contract (flare-smart-contracts-v2)](https://github.com/flare-foundation/flare-smart-contracts-v2/blob/main/contracts/protocol/implementation/Relay.sol): Flare Foundation (GitHub) (primary, checked 22 October 2026) 10. [Weights and Signing, Flare Systems Protocol](https://dev.flare.network/network/fsp/weights-and-signing): Flare Developer Hub (primary, checked 22 October 2026) 11. [Flare governance proposals (FIPs, STPs and SIPs)](https://proposals.flare.network): Flare Foundation (primary, checked 22 October 2026) 12. [FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): NIST (primary, 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). Flare: quantum readiness assessment. Hardy Score 13.0 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/flare ```bibtex @misc{hardyindex_flare_2026, author = {{The Hardy Index}}, title = {Flare: quantum readiness assessment}, year = {2026}, howpublished = {\url{https://hardyindex.com/chains/flare}}, note = {Hardy Score 13.0 of 100, Tier 5: Exposed. Methodology v1.8}, urldate = {2026-11-13} } ``` --- Methodology: https://hardyindex.com/methodology (v1.8). Cite as: The Hardy Index, "Flare", https://hardyindex.com/chains/flare, as of 13 November 2026.