Hardy Index Quantum readiness, rated and tracked

Chain profile

Sonic

S Exposed

Signs accounts and validator events with ECDSA on secp256k1, and Sonic Labs has described in a blog post how it would swap in a post-quantum scheme without naming one, proposing one or dating it.

Is Sonic quantum-safe?

No. Sonic accounts sign transactions with ECDSA on the secp256k1 curve through the go-ethereum signer, and its validators sign consensus events with secp256k1 keys too, so a sufficiently large quantum computer running Shor's algorithm would break both. Sonic Labs set out its position in a blog post of 20 April 2026, "Sonic's Road to Quantum Resistance". The post argues that Sonic's consensus design, which gives every event its own signature and avoids BLS aggregation, makes a later change simpler: Sonic would replace the per-event and transaction signatures with "a NIST-standardized scheme such as Dilithium or Falcon", update the hash output size, and change nothing else in the protocol. It does not choose a scheme, gives no dates, links no code, proposal or testnet, and says nothing about how existing accounts would move or what happens to accounts that never do. Sonic is a fresh chain, launched in December 2024 with its own genesis, and FTM holders moved to S through an upgrade portal rather than through a fork, so Fantom Opera's transaction history is not part of Sonic's.

Where we are making a judgement call Two judgement calls carry this profile. The first is the tier. Sonic Labs, the core team, has published a considered position on how it would change signature scheme, and its Chief Research Officer is quoted in it, but the Tier 4 floor asks for a formal improvement proposal or a public research programme, and a blog post that names schemes as examples is neither. The post itself points elsewhere for the research: "The Sonic tech team will keep up to date with Ethereum Foundation's approach to Post-Quantum updates, roadmap and research", which supports reading Sonic as having no research programme of its own. A reader who counts a core team's published design argument as research would put Sonic in Tier 4 and add 2.5 points. The second is exposure inheritance. Sonic launched with its own genesis and FTM moved to S through an upgrade portal, so Sonic does not share Fantom Opera's transaction history and inherits no measurement from it. Keys reused from Opera may be exposed there all the same, and a measurement of that overlap could lower the exposure score.

At a glance

On mainnet today

ECDSA on secp256k1 for account transactions and for validator event signatures

Post-quantum scheme

None selected. Sonic Labs describes swapping in a NIST-standardised scheme such as Dilithium or Falcon, without choosing one.

NIST standard

None adopted. ML-DSA (Dilithium) is FIPS 204; FN-DSA (Falcon) is in draft as FIPS 206.

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

A role not listed is not evidenced either way. Every scheme, and which other chains share it, is in the cryptography registry.

Score breakdown

Each dimension scored 0 to 10. The weight beside it is its share of the total score.
Signature scheme 0 30% Deployment stage 1 25% NIST alignment 3 15% Migration path 3 15% Exposure 2 10% Verification 2 5%
Show the weighted arithmetic and the sourced note for each dimension
No. Dimension Score Weight Contribution
1 Signature scheme 0 30% 0.0
2 Deployment stage 1 25% 2.5
3 NIST alignment 3 15% 4.5
4 Migration path 3 15% 4.5
5 Exposure 2 10% 2.0
6 Verification 2 5% 1.0
Hardy Score 14.5

1 Signature scheme 0/10, weighted 30%

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.

Sonic transactions are validated through go-ethereum's types.Sender, which recovers an ECDSA secp256k1 signer, and the node defines a single validator public key type, Secp256k1. Nothing post-quantum protects S or any asset on Sonic today. source

2 Deployment stage 1/10, weighted 25%

Band 1: Tier 5: Exposed.

Tier 5: Exposed. The signatures securing Sonic are quantum-vulnerable, and the published position is a Sonic Labs blog post describing how a swap would work, which is neither a formal improvement proposal nor a public research programme. See the caveat below on why this is a judgement call. source

3 NIST alignment 3/10, weighted 15%

Band 3 to 5: NIST schemes are referenced as candidates without a committed selection, or the work is bespoke research.

Sonic Labs names NIST schemes as examples and no more: the migration would swap in "a NIST-standardized scheme such as Dilithium or Falcon". Dilithium is standardised as ML-DSA in FIPS 204 and Falcon is on track as FN-DSA, but no scheme or parameter set has been selected. source

Placement in the band The floor of the band rather than a 4 or a 5: the schemes appear as examples in a blog post, not as candidates in a proposal or a test, and no parameter set is mentioned. Above a 2, because the schemes named are NIST's own and are named for Sonic's own transaction and event signatures.

4 Migration path 3/10, weighted 15%

Band 3 to 5: Migration is acknowledged as a problem with no agreed mechanism, or the mechanism is contested.

Sonic Labs acknowledges the problem and sketches the protocol side of a change: replace the per-event and transaction signatures and update the hash output size. Nothing is said about how existing holders would move their funds to post-quantum keys, and no mechanism, proposal or date exists. source

Placement in the band The floor of the band rather than a 4 or a 5: the acknowledgement comes from the core team and describes a protocol swap, but the hard part of migration, moving existing accounts whose keys are already public, is not addressed at all.

5 Exposure 2/10, weighted 10%

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

Sonic uses Ethereum's account model, in which an address is a hash of the public key, so a funded account that has never sent a transaction keeps its key private. Any account that has signed has published its key, which in practice covers almost all economically active supply. source

Placement in the band The top of the band rather than a 1: the hashed-address model protects never-signed accounts. Not a 3, because almost no active supply still has that protection, and keys carried over from Fantom Opera may already be public on that chain, which nobody has measured.

6 Verification 2/10, weighted 5%

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

No post-quantum component exists for Sonic: no code, specification or testnet implementation was found. The node is open source, but under v1.8 the openness of the classical code earns nothing here, because what this dimension verifies is the post-quantum component that protects funds. source

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 Sonic Labs does not market the chain as quantum-safe today, so its position does not rest on marketing.

The deployment dimension is not a separate judgement. It is Tier 5 expressed as a number. See the tier mapping.

How it compares

All 80 rated chains on the 0 to 100 scale. Sonic is marked. Select any point to open that profile.
Sonic 14.5

Nearest chains in the ranking

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

Rank Chain Tier Hardy vs S
32 Monero 4: Debating 17.5 +3.0
33 Neo 4: Debating 17.0 +2.5
34 Dash 5: Exposed 16.5 +2.0
35 Bitcoin 4: Debating 14.5 level
36 Sonic this chain 5: Exposed 14.5
37 Terra Classic 5: Exposed 14.5 level
38 Ethereum Classic 5: Exposed 13.0 -1.5
39 Flare 5: Exposed 13.0 -1.5
40 Internet Computer 5: Exposed 13.0 -1.5

Roadmap

  1. 20 April 2026 shipped

    Sonic Labs publishes "Sonic's Road to Quantum Resistance", arguing that its per-event signature design allows a later swap to a NIST-standardised scheme such as Dilithium or Falcon, without selecting one. source

  2. No date published proposed

    No scheme selection, improvement proposal, implementation, testnet or timeline for post-quantum signatures on Sonic was found. source

If holders never migrate

No stated policy

Sonic Labs' April 2026 post describes the protocol change it would make but does not address existing accounts, either those that migrate or those that never do.

As of 22 October 2026. source Published beside the score, not in it. Every chain's stance is compared on the commitments page.

Exposure

Exposure measures how much of the chain's value already sits behind a public key that an attacker can record today and break later. This is the part of the threat that a future upgrade cannot undo.

Sonic follows Ethereum's address model: an address is derived from a hash of the public key, so an account that has received funds but never sent a transaction has not revealed its key. The first signature reveals it permanently, and active accounts sign constantly, so almost all economically meaningful S sits behind a key that can be collected today against a future quantum computer. The exposure inheritance rule does not apply: Sonic's own documentation calls it "a fresh chain with no history", and Fantom Opera's transactions remain on Opera. Holders who kept the same keys across the move are a separate case, since a key published by a signature on Opera is just as visible there, but no measurement of that overlap exists.

What this rating means for you

If you hold Sonic

Sonic runs quantum-vulnerable signatures with no published post-quantum plan that we could find. Nothing here is urgent today, and there is also nothing scheduled to change it.

Editorial guidance from the Hardy Index.

Embed this rating

Paste this anywhere to show Sonic's current rating. It renders live from the index, so it updates when the rating does, and the review date is written into the image. There is nothing to sign up for and nothing to pay. 

<a href="https://hardyindex.com/chains/sonic"><img src="https://hardyindex.com/badge/sonic.svg" width="260" height="76" alt="Quantum readiness rated by the Hardy Index"></a>

The image is /badge/sonic.svg. It is a plain SVG with no script and no tracking, it sets no cookie, and it records nothing about whoever loads it.

Questions

Is Sonic quantum-safe?

No. Sonic accounts sign with ECDSA on secp256k1 and validators sign consensus events with secp256k1 keys, and a sufficiently large quantum computer would break both. Sonic Labs has described how it would swap in a post-quantum scheme but has not chosen one, proposed one or published a date.

What has Sonic Labs said about quantum computing?

In April 2026 Sonic Labs argued that its consensus design, which signs each event individually rather than aggregating BLS signatures, makes a future change simpler: replace the event and transaction signatures with a NIST-standardised scheme such as Dilithium or Falcon, update the hash output size, and leave the rest of the protocol alone. It is a design argument, not a plan, and it gives no timeline.

Does Sonic inherit Fantom's quantum exposure?

Not as transaction history. Sonic's documentation describes it as a fresh chain with no history, and FTM holders upgraded to S through a portal rather than through a fork, so the index's inheritance rule for shared history does not apply. A holder who kept the same key on both chains may have published that key in an Opera transaction, though, and it is no less visible for being on another chain.

What would move Sonic up the index?

A formal proposal or a public research programme on Sonic's own signatures would meet the Tier 4 floor. A published plan from Sonic Labs naming the scheme it will adopt would meet Tier 3. A testnet implementation would also lift the verification and NIST alignment scores.

Sources

  1. Sonic's Road to Quantum Resistance Sonic Labs · primary · checked 22 October 2026
  2. Sonic node client Sonic Labs (GitHub) · primary · checked 22 October 2026
  3. Sonic transaction validation (evmcore/tx_validation.go) Sonic Labs (GitHub) · primary · checked 22 October 2026
  4. Sonic validator public key types (inter/validatorpk/pubkey.go) Sonic Labs (GitHub) · primary · checked 22 October 2026
  5. Migration FAQ Sonic Labs · primary · checked 22 October 2026
  6. FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA) NIST · primary · checked 22 October 2026
Cite this rating

A rating is only true as of the day an editor last reviewed it, so both forms below carry that date and the methodology version, with the date its cited sources were last checked. If you are quoting the score, quote those too.

Plain text

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

BibTeX 
@misc{hardyindex_sonic_2026,
  author       = {{The Hardy Index}},
  title        = {Sonic: quantum readiness assessment},
  year         = {2026},
  howpublished = {\url{https://hardyindex.com/chains/sonic}},
  note         = {Hardy Score 14.5 of 100, Tier 5: Exposed. Methodology v1.8},
  urldate      = {2026-11-13}
}

The whole dataset is reusable under the terms on the about page. A machine-readable version of this page is at /chains/sonic.md.

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