--- title: Is Sonic quantum-safe? chain: Sonic ticker: S hardy_score: 14.5 rank: 36 of 80 tier: "5: Exposed" url: "https://hardyindex.com/chains/sonic" updated: 2026-10-22 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is Sonic quantum-safe? **Hardy Score 14.5 / 100. Rank 36 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.** 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. > This is a security-readiness assessment, not investment advice. ## Summary 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. ## 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. ## 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 | 3/10 | 15% | 4.5 | | 5 | Exposure | 2/10 | 10% | 2.0 | | 6 | Verification | 2/10 | 5% | 1.0 | | | **Hardy Score** | | | **14.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. 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: https://github.com/0xsoniclabs/sonic/blob/main/evmcore/tx_validation.go ### 2. Deployment stage: 1/10 Anchor 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: https://www.soniclabs.com/blog/sonics-road-to-quantum-resistance ### 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. 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. 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. Source: https://www.soniclabs.com/blog/sonics-road-to-quantum-resistance ### 4. Migration path: 3/10 Anchor 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. 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. Source: https://www.soniclabs.com/blog/sonics-road-to-quantum-resistance ### 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. 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. 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. Source: https://github.com/0xsoniclabs/sonic/blob/main/evmcore/tx_validation.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 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. 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. Source: https://github.com/0xsoniclabs/sonic ## Nearest chains in the ranking The 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](https://hardyindex.com/chains/monero) | 4: Debating | 17.5 | +3.0 | | 33 | [Neo](https://hardyindex.com/chains/neo) | 4: Debating | 17.0 | +2.5 | | 34 | [Dash](https://hardyindex.com/chains/dash) | 5: Exposed | 16.5 | +2.0 | | 35 | [Bitcoin](https://hardyindex.com/chains/bitcoin) | 4: Debating | 14.5 | level | | 36 | **Sonic** | 5: Exposed | 14.5 | this chain | | 37 | [Terra Classic](https://hardyindex.com/chains/terra-classic) | 5: Exposed | 14.5 | level | | 38 | [Ethereum Classic](https://hardyindex.com/chains/ethereum-classic) | 5: Exposed | 13.0 | -1.5 | | 39 | [Flare](https://hardyindex.com/chains/flare) | 5: Exposed | 13.0 | -1.5 | | 40 | [Internet Computer](https://hardyindex.com/chains/internet-computer) | 5: Exposed | 13.0 | -1.5 | ## Signature scheme - **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 - **Account signatures:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, default. Sender recovery through go-ethereum's types.Sender. Source (source code or release): https://github.com/0xsoniclabs/sonic/blob/main/evmcore/tx_validation.go - **Validator consensus:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, mandatory. Secp256k1 is the single validator public key type defined; validators sign each consensus event. Source (source code or release): https://github.com/0xsoniclabs/sonic/blob/main/inter/validatorpk/pubkey.go A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **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: https://www.soniclabs.com/blog/sonics-road-to-quantum-resistance - **No date published** (proposed): No scheme selection, improvement proposal, implementation, testnet or timeline for post-quantum signatures on Sonic was found. Source: https://github.com/0xsoniclabs/sonic ## 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: https://www.soniclabs.com/blog/sonics-road-to-quantum-resistance ## Exposure 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. ## Frequently asked questions ### 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. ### 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. ## What this rating means if you hold Sonic 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. [Sonic's Road to Quantum Resistance](https://www.soniclabs.com/blog/sonics-road-to-quantum-resistance): Sonic Labs (primary, checked 22 October 2026) 2. [Sonic node client](https://github.com/0xsoniclabs/sonic): Sonic Labs (GitHub) (primary, checked 22 October 2026) 3. [Sonic transaction validation (evmcore/tx_validation.go)](https://github.com/0xsoniclabs/sonic/blob/main/evmcore/tx_validation.go): Sonic Labs (GitHub) (primary, checked 22 October 2026) 4. [Sonic validator public key types (inter/validatorpk/pubkey.go)](https://github.com/0xsoniclabs/sonic/blob/main/inter/validatorpk/pubkey.go): Sonic Labs (GitHub) (primary, checked 22 October 2026) 5. [Migration FAQ](https://docs.soniclabs.com/migration/migration-faq.md): Sonic Labs (primary, checked 22 October 2026) 6. [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). 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} } ``` --- Methodology: https://hardyindex.com/methodology (v1.8). Cite as: The Hardy Index, "Sonic", https://hardyindex.com/chains/sonic, as of 13 November 2026.