Every primitive on every critical path is nameable to the curve, and one curve carries almost all of them. The credit is for that: the account layer, the consensus layer, the validator key and the transport handshake all resolve to ECDSA or ECIES over secp256k1, with SHA-256 at the DAG and keccak256 at the EVM, and the account-layer pair is confirmed by direct observation of mainnet rather than inferred from EVM compatibility. The deduction is that none of it is published as an inventory. No Sonic specification states a single cryptographic primitive; the consensus documentation names none at all; the chain's own quantum post describes its own signature only as "a standard digital signature" in an elliptic-curve family; and the BLS12-381 precompiles are live at the execution layer with no published statement of what, if anything, is built on them. The naming has to be assembled from the client source, an upstream security advisory the chain patched, and probing of the live chain, which satisfies reconstruction but is not a published primitive list.

Every deployed primitive carries a per-primitive tag and none of them is PQ-safe. The chain classifies its own exposure correctly at the level it discusses it: its post of 20 April 2026 states that a quantum computer running Shor's algorithm could solve the discrete logarithm problem underlying elliptic-curve cryptography, derive a private key from a public key and forge signatures at will, and contrasts that with hash functions, which remain usable under post-quantum assumptions. That is an accurate Shor-versus-Grover split and it earns credit. Two deductions. The chain publishes no per-primitive tagging of its own, only that category-level statement. And the statement's scope is narrower than the chain's exposure: the same post argues SonicCS avoids the pairing-based aggregation problem, which holds at the consensus layer, while BLS12-381 pairing operations are live at the execution layer through the EIP-2537 precompiles and go untagged anywhere in the chain's own record.

Zero post-quantum algorithm families are deployed, so the rubric's zero-families score applies directly. The chain's own post surveys the field across two families, naming hash-based signatures as XMSS and SPHINCS+ alongside lattice schemes as Dilithium and Falcon, but it proposes neither family for Sonic: where it turns from survey to Sonic it names only the lattice pair, and the two lattice candidates would count as one family even if either were built. Nothing from either family appears in the client, in any proposal or on any testnet. No code-based KEM (Classic McEliece, BIKE, HQC) appears anywhere in the public record for this chain, and no KEM of any kind appears in the sourced material. Note also that the code-based schemes are key-encapsulation mechanisms and none of them is a candidate signature family.

No per-primitive NIST security-category mapping is published, because no post-quantum primitive is deployed to map. The chain's own post names candidate schemes without a parameter set, so it distinguishes neither ML-DSA-44 (category 2) from ML-DSA-65 (category 3) or ML-DSA-87 (category 5) under FIPS 204, nor Falcon-512 from Falcon-1024 under the round-3 submission, and it states no choice between the pure and the pre-hash variant, which under FIPS 204 are separate algorithms with separate domain separators. The primitives that are deployed, ECDSA and ECIES over secp256k1 and the BLS12-381 curve operations, carry no post-quantum category by construction.

Third-party audits are published, and none of them covers cryptography. The chain's audits page names OpenZeppelin, Quantstamp and Certora on the Sonic Gateway, OpenZeppelin on the token bridge from the predecessor chain, and Quantstamp on the staking contract; all are smart-contract engagements, the Certora work is contract-level formal verification, and none of them reaches the client's signing or verification paths. No constant-time posture, side-channel analysis or library-provenance statement is published for those paths. The remaining credit is for a dated remediation record on cryptographic input handling: client v2.1.6 of 2026-03-12 integrated the patches for two upstream advisories published 2026-02-18, one of them an improper-validation flaw on the ECIES public key in the RLPx handshake, a 22-day turnaround, accompanied by operator guidance to delete and regenerate the peer-to-peer node key; and client v2.0.3 integrated an earlier fix adding an on-curve check for unmarshalled peer-to-peer public keys. Both are cryptographic input-validation fixes in the transport, which is the closest the public record comes to evidence about implementation quality. The primitives themselves remain unassessed in public.

Sonic uses the Ethereum account model, confirmed against mainnet: the signature-recovery precompile returns, for a genuine secp256k1 signature, the low twenty bytes of keccak256 over the uncompressed public key. The public key therefore becomes recoverable from the signature of an account's first outbound transaction. Every account that has ever paid a fee is exposed-after-spend and still-funded in the address-type classification, and a CRQC forges from it without racing a confirmation window. The exposure is structural and total for active accounts, which is what the low score records. No public source quantifies Sonic's exposed-public-key share, revealed-key balances or address-reuse rate, so the small residual credit reflects only that the account model hashes the public key at rest, not any measured mitigation.

An account that has never sent a transaction is mitigated-until-spend: the address commits to keccak256 of the public key, the public key itself has never appeared on chain, and a CRQC has nothing to run Shor against until the holder spends. That is a real architectural mitigation and it earns the credit here. The deduction is that it evaporates on first spend and that no public source quantifies dormant S balances, never-revealed account value or the size of the never-spent cohort, so the three-number vulnerable-supply readout cannot be reconstructed for this chain from the public record.

Long-range, at-rest exposure dominates. Signed DAG events are retained as chain history, each carrying a 64-byte secp256k1 signature over a SHA-256 digest, and validator registration keys on the same curve are registered once and held for the life of the registration, so a CRQC arriving at any point can forge against keys whose public halves have been on the record for years. At the account layer the chain's own documentation is explicit that for EIP-7702 smart accounts the ability to send regular transactions signed with the account's private key remains unaffected, so an account that upgrades without separately retiring the old key carries both authorization paths indefinitely; there is no mandated rotation, no signature-expiry rule and no published sunset for the scheme. Short-range, on-spend exposure is the ordinary EVM case: the signature and the recoverable public key enter a public mempool before inclusion. The credit is for the existence of a per-user in-place upgrade mechanism that a holder can use to add contract-enforced authorization logic; it is small because the mechanism retires nothing by default.

The harvestable surface is small but the key establishment behind it is classical and now identifiable. Validator and peer transport runs the devp2p RLPx handshake, whose key establishment is ECIES over secp256k1: the chain integrated the February 2026 upstream advisory for improper validation of the ECIES public key in that handshake, instructed operators to delete and regenerate the peer-to-peer node key, and had earlier integrated a fix adding an on-curve check for unmarshalled peer-to-peer public keys. Validator nodes carry this traffic on TCP and UDP port 5050 by default. A CRQC recovers the static node key from recorded handshakes and decrypts gossip captured years earlier, so harvest-now-decrypt-later applies to this leg. The RPC leg is served over TLS on documented https and wss endpoints, and no public source states the groups those handshakes negotiate. No hybrid KEM combiner, for example X25519 with ML-KEM-768 per FIPS 203, is documented for RPC, for validator gossip or for the bridge relay path. The credit is for a transport that is identifiable and twice patched on public-key validation; the score stays low because what is identifiable is entirely classical.

Pseudonymous and fully transparent. Sonic's own documentation describes the chain purely in terms of full EVM compatibility and standard account and transaction mechanics, and the client repository describes the software only as an EVM-compatible chain secured by the Lachesis consensus algorithm. No shielded pool, confidential-transfer facility or encrypted-state feature is described anywhere in the documentation set or the repository. Senders, recipients, amounts and contract calls are public at inclusion. Sonic publishes no structural-impossibility statement naming what the architecture can reveal, to whom and under what conditions, so this sub-score is held at or below half of maximum under the structural-impossibility evidence requirement; the score sits under that ceiling on its own merits.

Sonic's own documentation names one official default endpoint for mainnet, reachable over both https and wss, and one for testnet. No primary source publishes an origination share across independent RPC providers, so no top-three concentration figure can be reconstructed. The mempool is the ordinary public EVM gossip mempool: transactions, their signatures and the recoverable public keys are observable before inclusion. No validator metadata-retention policy covering IP address, timing or client fingerprint is published, which scores zero on that component of the rubric. The credit is for the existence of documented endpoints usable by independent operators rather than for any measured decentralization. The structural-impossibility ceiling applies here too and is not the binding constraint.

Sonic Gateway, the native bridge, moves ERC-20 assets between Ethereum and Sonic with a stated latency of up to ten minutes inbound and up to one hour outbound, and both legs settle on transparent ledgers, so a passive observer links source to destination by amount and timing without privileged access. The Gateway's own design publishes a Merkle root and both chains' block heights at regular intervals, which is exactly the linkage material. LayerZero's own published deployment metadata lists Sonic mainnet, chain id 146, as an active endpoint deployment, adding a second transparent channel with the same property. No correlation-resistance mechanism, batching window or amount-blinding scheme is documented for either channel. No public source ranks which channel carries the largest share of Sonic's cross-chain value, so the score rests on the mechanism, not on volume.

Nothing on Sonic relies on Shor-breakable privacy mathematics, because no privacy primitive exists to break: no ElGamal encryption, no discrete-log ring signature, no elliptic-curve zk-SNARK is described anywhere in the documentation set or the client repository, and every wallet integration the chain lists is a standard transparent-EVM wallet. The BLS12-381 precompiles put pairing arithmetic within reach of contracts, but no public source names a privacy construction on this chain that uses it. There is accordingly no encrypted history that a CRQC would retroactively open. The credit stops there, because the end state is the same one by a different route: the transaction graph is permanently public from the moment of inclusion and needs no quantum computer to read. The structural-impossibility ceiling of half of maximum applies and is not binding at this score.

Not scored. Structural mixing and shuffle-layer hiding are assessed under the privacy-focused-chain profile; Sonic is scored on the L1 profile, where this sub-score is out of scope. It is excluded from both the numerator and the denominator of the dimension total and is not a zero.

The rubric requires a cited specification plus a verifiable production instance of a mechanism that switches algorithm without a hard fork. Sonic has the generic half, and it is verifiable rather than merely documented: EIP-7702 and ERC-4337 are both supported under its Pectra compatibility, the Prague feature set is live on mainnet, and the canonical ERC-4337 entry-point contracts for versions 0.6, 0.7 and 0.8 all carry code on Sonic mainnet, so an account can today delegate to contract logic that enforces an arbitrary verification rule. It does not have the specific half. No versioned signature-scheme field or algorithm registry is described at the protocol level, and no ML-DSA, SLH-DSA or Falcon verifier contract or precompile is documented. The only additional signature primitive the client has added since is ECDSA over secp256r1 per EIP-7951, another classical curve, and that precompile does not answer on mainnet. The chain's own claim that replacing the per-event and transaction signatures would leave the rest of SonicCS unchanged is a design argument about migration cost, not an implemented agility mechanism, and the same post concedes the hash output size would change too; altering the consensus signature would still require a fork.

Account abstraction is live and verifiable, not merely documented: the chain supports ERC-4337 smart accounts and EIP-7702 delegation from an externally owned account under its Pectra compatibility, the Prague feature set is live on mainnet, and the canonical entry-point contracts for ERC-4337 versions 0.6, 0.7 and 0.8 all carry code on mainnet. That places the account-model component at the account-abstraction-only level of the rubric. It goes no further. The authorization options Sonic documents are WebAuthn passkey signing, which its own page marks a research project, experimental and not recommended for production, Google OAuth JWT signing, Web3Auth n-of-m, and ERC-7093 social recovery, which the same page describes as a proposal without a reference implementation; none is a post-quantum signature scheme, so there is no documented client-layer post-quantum migration path to lift the component. The Ed25519 seed-rebind floor does not apply, because standard Sonic accounts commit to an ECDSA key over secp256k1, not to an RFC 8032 seed-derived key. The post-quantum rebind bonus is zero: no public artifact specific to a Sonic rebind design exists.

One feature set is demonstrably activated and a second is staged but not. Activated: the Ethereum Prague feature set is live on Sonic mainnet, confirmed by direct observation, since the EIP-2935 history-storage contract carries code at its canonical address and the EIP-2537 BLS12-381 G1 addition precompile answers as specified. Staged only: the Brio feature set shipped in client v2.2.0 on 2026-07-02, bundling EIP-7939 for the count-leading-zeros instruction, EIP-7951 for the secp256r1 precompile, EIP-7883 and EIP-7823 for ModExp gas cost and input length, EIP-7825 for a per-transaction gas ceiling and EIP-7934 for a maximum encoded block size, plus a chain-specific transaction-bundles feature; on mainnet the EIP-7951 precompile returns empty for a signature that the same precompile accepts on another EVM mainnet, so the feature set is not active, and no activation block or date for it is published. Eight dated client releases run across the window to v2.2.2 on 2026-09-15 at a monthly to bimonthly cadence, and no contested fork appears in the record. The deduction is that the record shows a client that can build fork-gated changes and one feature set that reached mainnet, not a repeated or contested activation history, and that the chain publishes no activation schedule for the set it has already built.

The rubric asks whether the chain can ship a classical-plus-post-quantum hybrid without replacing the scheme, architecturally rather than by announcement. At the consensus layer it cannot: each DAG event carries exactly one 64-byte creator signature with no second verification slot, no OR-composition, no commit-to-hash construction and no AND-composition, and the chain's own post frames the transition as replacing the per-event and transaction signatures, which is substitution, not hybrid. The small credit is for the account layer, where EIP-7702 delegation and live ERC-4337 entry points make it architecturally possible for a smart account to require both a classical and a post-quantum verification without any consensus change. Nothing of the kind is specified, implemented or deployed, and no stateful or stateless post-quantum verifier exists on the chain to compose with.

Full credit by the rubric's stateless default. Sonic deploys no stateful hash-based signature scheme and proposes none. The chain's own post does name XMSS and SPHINCS+ when surveying post-quantum mitigations, but it names them as research the industry is doing, not as anything proposed for Sonic; where the same post turns to what a Sonic migration would involve it names only the stateless lattice pair, ML-DSA per FIPS 204 and Falcon per the round-3 submission. Neither XMSS nor XMSS^MT per RFC 8391, nor LMS or HSS per RFC 8554, nor any leanXMSS-class construction appears in the client, in any proposal or on any testnet for this chain. NIST approval status for stateful hash-based signatures is set by SP 800-208, and nothing on Sonic engages it. There is therefore no one-time-signature index space to track, no restore path that could rewind state and no multi-device state-reuse surface to enforce against. This score reflects the absence of that failure mode, not any state-management engineering.

Not scored. This sub-score applies to chains whose consensus depends on Shor-vulnerable signature aggregation or threshold primitives, for example BLS multi-signatures over BLS12-381 in a BFT voting round. SonicCS is outside that scope, and the finding is corroborated in the client rather than resting on the chain's own description: each DAG event carries exactly one creator signature, declared as a fixed 64-byte secp256k1 value, and no aggregate-certificate or threshold type exists in the consensus path. The chain's own post states the matching architecture, that no acknowledgment round is required, no global coin is formed and no aggregate certificate is produced. BLS12-381 arithmetic is live on this chain, but through the EIP-2537 precompiles at the execution layer, where it is available to contracts and plays no part in consensus. With no aggregation primitive in consensus there is no post-quantum aggregation path to declare, so the sub-score is excluded from both the numerator and the denominator and is not a zero.

0% of mainnet signing traffic runs on a post-quantum primitive. No post-quantum code, flag or feature appears in any dated client release through v2.2.2 on 2026-09-15; the changes across the window are gas subsidies, event throttling, RPC and tracing fixes, the staged Brio feature set and two integrated upstream security patches. No ML-DSA, SLH-DSA, Falcon, XMSS or LMS signature has ever been verified on Sonic mainnet, so there are no post-quantum bytes to measure.

No post-quantum cryptographic code exists in the consensus client. The single client repository ships no ML-DSA, SLH-DSA, Falcon, ML-KEM or hash-based signature implementation, no post-quantum verifier behind a feature flag, and no testnet-only post-quantum branch that would earn deducted credit. The validator signer accepts exactly one key type, secp256k1, and returns an error for anything else, so there is not even an unused slot for a second scheme. The only signature-related primitive the client has added in the window is the ECDSA secp256r1 precompile of EIP-7951, a classical curve, and it is not active on mainnet.

Zero. Sonic has key-holding block producers, so this is a real gap rather than a structural absence: validators register a locally generated signing key through the validator public-key flag and use it continuously, that key is ECDSA over secp256k1, and no validator holds or uses a post-quantum key because the client implements no post-quantum scheme to hold one under and its signer rejects any key type other than secp256k1. The percentage of active validators or stake signing with a post-quantum key is zero, and no registration path for such a key exists. Post-quantum user-transaction signing is measured in 5a and is not re-credited here.

Zero, on two independent grounds. First, the rubric voids this sub-score whenever mainnet post-quantum traffic is zero, which it is. Second, the underlying condition is not met either: no named, dated, publicly verifiable post-quantum milestone exists. The single post-quantum artifact in the public record is an explainer piece carrying no proposal number, no governance item and no protocol-enforced activation, and no Sonic improvement proposal, forum thread or DAO vote concerning post-quantum cryptography is published anywhere. The one published DAO vote in the window, on 2025-08-31, authorized a capital-markets issuance unrelated to cryptography.

No washing delta. The metric compares press-release claims about a named primitive in the trailing twelve months against mainnet bytes verifiably signed under that exact primitive. Sonic's post of 20 April 2026 makes no claim that any post-quantum primitive is running: it states a property of the protocol, that SonicCS uses one signature per event and one hash so a future replacement would be cheap, and names candidate schemes without choosing one. With no claimed primitive there is no shipped-primitive claim to fail, the ratio is zero, and neither the 1.5 deduction threshold nor the 2.0 cap nor the 5.0 narrative-only tag is reached. Full credit here measures the absence of overclaiming and nothing else; the absence of deployment is scored in 5a, 5b and 5c.

Undisclosed, which the rubric scores zero. No per-block post-quantum signature-data multiplier can exist, because no post-quantum deployment exists. Sonic publishes no bytes-per-block projection under any candidate scheme, no aggregation or SNARK-batching design, no data-availability offloading plan and no recalibration of transaction-weight accounting so that post-quantum-secured transactions are not fee-penalized against classical ones. The classical baseline is fixed in the client at 64 bytes per consensus event signature, which sizes the problem without addressing it: an ML-DSA-44 signature is 2,420 bytes per FIPS 204 and an SLH-DSA-SHA2-128s signature is 7,856 bytes per FIPS 205, so a like-for-like substitution at the consensus layer multiplies per-event signature data by roughly 38 or 123 times respectively.

Sonic's own documentation lists Rabby Wallet, MetaMask, OKX Wallet, Trust Wallet, Bitget Wallet and 1inch Wallet for users, and Safe, Safe Backup, Fordefi and Fireblocks for institutions. The tile scores named vendor post-quantum roadmaps with dates and the share of key volume concentrated among vendors holding one. No post-quantum signing roadmap tied to Sonic is published for any wallet in this set, and the chain's own wallet documentation states no post-quantum capability or date for any of them, so there is no roadmap-covered volume to credit.

Two channels are documented. Sonic Gateway is the native bridge, secured by the validator network rather than a custodial multisig, with a 14-consecutive-day immutable fail-safe that lets users reclaim bridged funds on Ethereum if the Gateway stops sending heartbeats, and it carries published audits from OpenZeppelin, Quantstamp and Certora. LayerZero's own published deployment metadata lists Sonic mainnet, chain id 146, as an active endpoint deployment, a second channel. Neither publishes a post-quantum roadmap with dates for Sonic, and the signatures that authorize both paths are the same Shor-breakable secp256k1 schemes scored in Dimension 1; the Gateway's authorization rests on the same validator key material. The audits are contract-level and address no cryptographic-primitive risk. The Gateway fail-safe is a real mechanism but it is a liveness circuit-breaker, not post-quantum readiness, and it is credited once, in 7e.

BitGo is named as the institutional custodian for the proposed regulated S-token vehicle approved in the DAO vote of 2025-08-31, and Fireblocks and Fordefi appear in the institutional wallet list. No post-quantum roadmap with dates is published for Sonic custody by any of them, and no exchange in the chain's public record publishes one either. With no roadmap-covered custodian, there is no concentration credit to award.

Sonic's own documentation names one official default RPC endpoint for mainnet and one for testnet, and its validator guidance recommends running on dedicated hardware or a major cloud provider without naming a key-management arrangement. No primary source names an HSM vendor, a key-management service or a TEE attestation chain for Sonic RPC or validator infrastructure. The validator signing key is generated locally by the chain's own tooling and stored in a password-protected keystore on the node, which is the opposite of an attested hardware custody path. No post-quantum roadmap with dates is published for any infrastructure provider serving this chain.

Two mechanical bounds are published: a minimum self-stake of 500,000 S and a maximum validator size of sixteen times self-stake, which caps how much delegated stake a single validator identity can command and is a genuine structural limit on concentration. Beyond that the picture is thin. No Nakamoto coefficient, stake-distribution table or active-validator count is published, and client diversity is nil by construction, since the chain runs a single implementation, so a consensus-level defect has no second client to fall back on. The reward structure is documented, fifteen percent of delegator rewards and fees to the validator against a target of roughly 3.5% APR at fifty percent network staking, which shapes but does not measure distribution.

The cadence is real and the activation record is thinner than the release record. Eight dated client releases run across the window to v2.2.2 on 2026-09-15 at a monthly to bimonthly cadence, and one multi-EIP feature set, Ethereum Prague, is live on mainnet by direct observation. A second multi-EIP feature set, Brio, shipped in v2.2.0 on 2026-07-02 and is not active on mainnet, with no activation date published, so the window contains coordinated engineering without a second coordinated activation. Security pressure has been handled once in the window: v2.1.6 on 2026-03-12 integrated patches for two upstream advisories published 2026-02-18, a 22-day turnaround, with operator guidance to regenerate the peer-to-peer node key. The deduction is that none of this was performed against a deadline set by an adversary or a live exploit, and that a cryptographic-primitive migration is a larger coordination problem than any upgrade in this record.

There is governance structure but no cryptographic-migration mandate. The leadership change announced in June 2026 moved three board members to advisory roles, appointed a new chief executive and chief operating officer, committed to a dedicated risk and compliance committee and named a public disclosure channel, and a statement by a departing director and a separate news report corroborate the same date and the same changes. The credit is for that published structure and a working disclosure address. No source names an individual, team or working group with a published mandate for quantum readiness or post-quantum migration. The only voice on quantum matters anywhere in the record is the chief research officer, quoted once in one blog post, and the quotation is a personal view that powerful quantum computers are unlikely in the near future paired with a statement that the industry must prepare. That is commentary, not a mandate.

Two dated precedents, both partial. Client v2.1.6 on 2026-03-12 integrated the patches for two upstream advisories published 2026-02-18, one a denial-of-service flaw reachable by a malicious peer-to-peer message and the other an improper-validation flaw on the ECIES public key in the RLPx handshake, and the upgrade required operators to delete and regenerate their peer-to-peer node key, which breaks static peering setups and so demanded coordination rather than a silent bump. Client v2.0.3 integrated an earlier fix adding an on-curve check for unmarshalled peer-to-peer public keys. Both are the correct shape of the exercise this sub-score measures, and both are cryptographic input-validation work. They fall short of the full condition: no source describes an attacker actively threatening the chain at the time, both patches originated upstream rather than from the chain's own disclosure process, and the chain has never coordinated a signature-scheme change of any kind, which is the maneuver a post-quantum migration actually requires.

No canary for legacy-key exposure exists. No honeypot address with a revealed public key is monitored, no rate-limited spending rule governs exposed keys, and no mechanism anywhere is designed to detect the arrival of a cryptographically relevant quantum computer. The credit is for the one mechanical, non-discretionary tripwire the chain does operate: Sonic Gateway's 14-consecutive-day fail-safe, described in the chain's own post as immutable and alterable by no party once deployed, which returns bridged funds to users on Ethereum if the Gateway stops sending heartbeats. It would fire on a bridge halt, including one caused by a validator-key compromise, which is why it is not zero. It observes liveness, not cryptographic compromise, it covers only assets routed through the Gateway, and the chain's own documentation notes that bridged tokens already spent onward may not be recoverable.