MegaETH names its signature primitive exactly in its own documentation: mini-block headers are authenticated with a standard secp256k1 ECDSA signature over keccak256(rlp(header)), with the (r, s, yParity) triple verified through ecrecover against the key registered in the SequencerRegistry system contract at 0x6342000000000000000000000000000000000006. Account-layer transactions use ECDSA secp256k1 over standard Ethereum RLP and Keccak-256 encoding. The settlement path names Groth16 proofs produced under RISC Zero inside Kailua, data availability names KZG commitments on EigenDA, the specification overrides the gas cost of the KZG point-evaluation precompile at 0x0A, and the developer randomness contract names BLS12-381 with the exact drand quicknet ciphersuite bls-unchained-g1-rfc9380. That is precise naming where it is given. Two gaps hold the score: there is no consolidated cryptographic inventory in one place, and several primitives are named without their parameters, including the curve behind the Groth16 verifier and the curve behind the EigenDA operator BLS signatures. No primitive is named for key establishment at first-party transport endpoints.

Every primitive in the stack classifies cleanly from the named algorithms, and all of the asymmetric ones are Shor-break. ECDSA secp256k1 falls to discrete log. Groth16, the KZG commitments carrying EigenDA blob data, the EigenDA operator BLS signatures and the BLS12-381 drand verifier all fall to pairings; because Groth16 carries settlement, that surface is scored at equivalent-to-ECDSA exposure. No retention or expiry window is published for EigenDA blob data, so the blob surface is not discounted against a shelf life. Keccak-256 is the only primitive with a post-quantum margin, and it is a Grover weakening rather than a break. No post-quantum primitive is present: neither ML-DSA (FIPS 204), SLH-DSA (FIPS 205), nor ML-KEM (FIPS 203) appears anywhere in the stack. MegaETH publishes no classification of its own.

Zero post-quantum algorithm families are present. There is no lattice family (ML-DSA per FIPS 204, ML-KEM per FIPS 203, Falcon per the round-3 submission), no hash-based family (SLH-DSA per FIPS 205, XMSS or XMSS^MT per RFC 8391 with approval status set by NIST SP 800-208, LMS/HSS per RFC 8554, Winternitz), and no code-based family (Classic McEliece, BIKE, HQC, all of which are KEMs rather than signature schemes). Zero families scores zero. This is the absence of any post-quantum family, not a concentration in one.

No NIST security category can be mapped, because no post-quantum parameter set is selected. No MegaETH document names a target: there is no choice between ML-DSA-44, ML-DSA-65 and ML-DSA-87, no statement of whether the pure or the pre-hash variant would be used where a digest is signed, no selection among the twelve SLH-DSA parameter sets approved in FIPS 205, and no choice among ML-KEM-512, ML-KEM-768 and ML-KEM-1024. The selection is available to make and has not been made, so this is a real zero and not a structural non-applicability.

The classical implementation is inherited. The execution client is a Reth-derived Rust node published under the megaeth-labs organization as a fork of paradigmxyz/reth, carrying the standard Ethereum ECDSA secp256k1 and Keccak-256 implementations, which have long cryptanalytic maturity but are pre-quantum. Actively maintained first-party components are published alongside it, including a revm-derived execution encapsulation and a Rust stateless validator. No post-quantum library is in the tree, so none of the formally verified implementations (Libjade and the machine-checked XMSS and SPHINCS+ proofs), no constant-time validation, and no liboqs or PQCA provenance applies to anything MegaETH runs. On deployed-verifier provenance the record is negative: the RISC Zero program hash in the settlement path, 0xf0ce...22c2, is not reproducible from its published sources, and the node software needed to watch the chain independently is not published, so the compiled verifying artifact cannot be matched to audited source.

Every MegaETH account that has broadcast a transaction has revealed its secp256k1 public key, which is recoverable from any ECDSA signature through ecrecover, and the EVM account model reuses that address indefinitely afterwards. The sequencer key registered in the SequencerRegistry contract is public by construction and, since the Rex5 upgrade activated on mainnet on 2026-06-05, signs every mini-block. No public source publishes the share of MegaETH value held at addresses with revealed keys. No account-layer mitigation is deployed: no single-use addressing, no key rotation primitive for user accounts, and no post-quantum spend path.

An Ethereum-format address is a Keccak-256 hash of the public key, so a MegaETH account that has never sent a transaction is mitigated-until-spend: its secp256k1 public key is not on chain and cannot be attacked by Shor. That is a real structural mitigation, and no other is present. No study publishes MegaETH's dormant-balance distribution, and a public mainnet history running only from 2026-02-09 means most funded accounts have transacted at least once, which moves that value into the exposed-after-spend bucket.

Long-range component, 2 of 13: the SequencerRegistry key in force is public for as long as it is registered and authenticates every mini-block produced from the Rex5 activation on 2026-06-05 onward, and the Groth16 settlement proofs anchoring state are pairing-based, so both are forgeable by any CRQC with no race against a confirmation window. Mini-blocks produced before Rex5 carry no signature at all, which removes a forgery target for that period and replaces it with an absence of authentication. Short-range component, 5 of 12: the window factor is favourable in absolute terms, because mini-blocks are produced roughly every 10ms and the interval between a public-mempool reveal and inclusion is correspondingly short, scoring 5 of 6; the exposure-discipline factor is 0 of 6, because addresses are reused by EVM default, the mempool is public across third-party RPC endpoints, and no post-quantum spend path exists.

Transport runs over HTTPS and WSS at third-party RPC providers. Alchemy serves MegaETH mainnet at an HTTPS endpoint and a matching WSS endpoint, and Chainstack serves MegaETH mainnet and testnet with HTTPS and WebSocket credentials issued per node. No first-party TLS configuration, cipher suite, or key-establishment construction is published for any MegaETH endpoint, so no hybrid combiner such as X25519 with ML-KEM-768 per the IETF hybrid TLS design is evidenced. MegaETH orders transactions through a single sequencer and publishes no validator-to-validator gossip protocol of its own, so there is no first-party encrypted peer transport for an attacker to capture and hold.

All MegaETH transaction data is public. The sequencer batches transactions to EigenDA, where they are divided into erasure-coded chunks, each accompanied by a KZG commitment, and made retrievable by anyone verifying state transitions. There is no shielded pool, no confidential transaction type, and no encrypted state. The transaction graph is pseudonymous only: addresses are not identities, and every other aspect of a transaction is visible.

Concentration component, 3 of 8: RPC entry is plural, with independent third-party providers including Alchemy and Chainstack each serving MegaETH mainnet, but no measurement of the share of transactions originating at the top providers is published, so only partial credit applies. Mempool observability component, 3 of 7: submission is a standard public eth_sendRawTransaction surface, with a realtime_sendRawTransaction variant, no encrypted mempool and no private submission path, across several independent entry points. Metadata retention component, 0 of 5: no policy covering IP address, timing or client fingerprint is declared for MegaETH endpoints, which scores zero.

MegaETH documents a wide bridge surface. Its own Rabbithole portal hosts a built-in USDm bridge and LI.FI, and the documentation names Bungee, Stargate, deBridge, Across, Portal (Wormhole), Jumper and Relay as third-party routes. Both legs of a transfer are public, the deposit on the settlement layer and the credit on MegaETH, so a passive observer links source to destination from public data alone. No correlation-resistance mechanism is documented for any of these routes, and a larger documented route set widens rather than narrows the correlation surface.

MegaETH encrypts no transaction content, so there is no note ciphertext, no ElGamal or ECIES payload and no shielded record for a CRQC to decrypt retroactively. The Groth16 proofs in the settlement path, the KZG commitments on EigenDA and the BLS12-381 drand verifier prove, commit to and attest data that is already public: breaking pairings there would let an adversary forge openings, proofs and beacon signatures, which is an integrity threat scored at 1b and 2c rather than a retroactive privacy loss. The transaction record is permanently public by design, so an observer reaches the same result today without any quantum capability.

Not scored. Structural mixing and shuffle layers are assessed on the privacy-focused profile; MegaETH is scored on the rollup-L2 profile, where this sub-score is out of scope. It is excluded from both the numerator and the denominator and is not a zero.

Partial. MegaETH publishes a versioned specification ladder, EQUIVALENCE through MINI_REX to REX7, in which each spec is frozen and gated so that pre-Rex5 behaviour is retained byte-for-byte for replay, and the Rex5 upgrade added a SequencerRegistry that tracks the system address and the mini-block signing key as two independently rotatable on-chain roles, queryable through currentSystemAddress() and currentSequencer(). That is a working mechanism for changing behaviour and for rotating the block-producer key, and mini-block authentication has already been changed through it once, from unsigned to ECDSA secp256k1. It is not algorithm agility: every change requires a network upgrade, no algorithm-versioned signature type exists, no support for the draft EIP-8141 generic-signature framework that would enable ML-DSA, Falcon or SLH-DSA verifier contracts is announced, and no EIP-7702 delegation support is published for MegaETH. The change mechanism itself is a 6-of-10 Safe multisig able to upgrade OptimismPortal2, DisputeGameFactory, SystemConfig and DelayedWETH with no delay, which is operationally potent but is an operator key rather than an algorithm-versioned protocol path, and carries its own standing risk of a malicious code upgrade.

Contract accounts function on MegaETH because it is EVM-compatible, so a user can in principle hold value in a smart-contract wallet that later verifies a different scheme, and MegaETH publishes its own embedded wallet SDK, MOSS, live since 2026-06-17, offering session-key smart accounts, a policy engine for delegated execution and sponsorship configuration. What is not published is the account standard behind it: no ERC-4337 EntryPoint deployment, bundler or paymaster is named as a MegaETH protocol feature, no EIP-7702 delegation is described, and MOSS's key-custody model and signature scheme are not documented, so the migration properties of these accounts cannot be established from public material. No key-rotation primitive exists for user accounts, and no client-layer migration path is published. The Ed25519 seed-rebind floor does not apply, because MegaETH accounts commit to ECDSA secp256k1 keys rather than to an RFC 8032 Ed25519 seed.

MegaETH publishes a named network-upgrade record with activation timestamps on both networks. Eleven specs are defined, MiniRex through Rex7, and ten have activated on mainnet: MiniRex at genesis, MiniRex1 and MiniRex2 and Rex on 2025-12-04, Rex1 on 2025-12-21, Rex2 on 2026-02-04, Rex3 on 2026-02-21, Rex4 on 2026-04-20, Rex5 on 2026-06-05 and Rex6 on 2026-08-25. Each was activated on testnet first, between two and fifteen days ahead of mainnet, and Rex7 is marked unstable with no activation timestamp on either network. No contested fork or chain split is documented. Three things hold the score below full credit: the record covers under ten months, activation executes through a multisig with no delay rather than through multi-party coordination, and the node software that would let external parties verify an upgrade independently is not published.

A hybrid classical plus post-quantum path is not architecturally prepared. Mini-block authentication is bound to ECDSA secp256k1 through ecrecover against the SequencerRegistry key, and beyond the standard EVM precompile set MegaETH publishes only two overrides, the KZG point-evaluation precompile at 0x0A and ModExp on the EIP-7883 schedule, neither of which verifies ML-DSA-44, ML-DSA-65 or SLH-DSA-SHA2-128s. Contract-level verification of a post-quantum signature is possible on any EVM chain, and MegaETH has demonstrated it can ship a signature verifier as a plain Solidity contract by deploying a BLS12-381 drand verifier, but no post-quantum verifier deployment, specification or benchmark is published, and no AND-composition or OR-composition combiner is described.

MegaETH deploys no stateful hash-based signature scheme. Neither XMSS nor XMSS^MT (RFC 8391, with approval status set by NIST SP 800-208), nor LMS/HSS (RFC 8554), nor any Winternitz one-time construction is present at the consensus or account layer, so there is no signing-state index to track, no restore-rewind hazard, and no multi-device state-reuse surface. A chain running no stateful scheme takes full credit here by default. The score records the absence of one specific failure mode and is not a statement of post-quantum readiness.

Not scored. MegaETH orders transactions through a single active sequencer with a hot standby and has no validator-set BFT consensus of its own, so there is no BLS12-381 multi-signature or threshold aggregation inside the protocol that would need a post-quantum aggregation path. Finality runs through Kailua proofs settling to Ethereum, whose own BLS12-381 consensus aggregation sits outside MegaETH's protocol, and the EigenDA operator signatures aggregated into a DA certificate belong to EigenDA rather than to MegaETH consensus. The BLS12-381 verifier MegaETH publishes checks an external drand beacon and aggregates nothing. Chains with non-aggregating consensus signatures are excluded from this sub-score, which leaves both the numerator and the denominator and is not a zero.

Post-quantum mainnet signing traffic is 0%. Every transaction on MegaETH mainnet since 2026-02-09 is signed with ECDSA secp256k1, and every mini-block signed since the Rex5 activation on 2026-06-05 is authenticated with the same scheme. No opt-in path exists for any share of traffic, and no ML-DSA, SLH-DSA or Falcon signature type is accepted at the account layer.

No post-quantum code is present in the client. Across the megaeth-labs organization, including the Reth-derived node, the revm-derived execution encapsulation and the stateless validator, a public code search returns no result for ML-DSA or Dilithium, SLH-DSA or SPHINCS+, ML-KEM, XMSS, Falcon, or the term post-quantum, and no such package, branch or release is published. Nothing is merged at testnet level either, so there is no testnet-only code to discount.

MegaETH has a key-holding block producer: the sequencer key registered in the SequencerRegistry contract, which signs every mini-block with ECDSA secp256k1 and is verified through ecrecover. That key exists, is rotatable on chain, and has been neither migrated to nor paired with a post-quantum scheme, so this is a real zero rather than a structural absence. This sub-score covers the block-producer key only; post-quantum signing of user transactions is measured at 5a and is not re-credited here.

No dated post-quantum milestone is published. MegaETH publishes activation timestamps for its network upgrades, so the chain has a working practice of committing to dates in public, and none of those dates carries a post-quantum change. There is no protocol-enforced flag day, no phased sunset of a classical scheme, and no scheduled fork carrying a post-quantum signature type. This sub-score is also voided because mainnet post-quantum traffic is zero: milestone credit requires shipped code behind the dates.

No post-quantum claim has been published by MegaETH in the trailing twelve months. No blog post, documentation page, specification, research page or governance proposal names ML-KEM, ML-DSA, SLH-DSA, Falcon, XMSS or LMS/HSS, and nothing post-quantum has shipped. Announced count and shipped count are both zero, so there is no gap between claim and delivery and no washing deduction applies. This sub-score measures claim discipline rather than deployment; deployment is zero and is scored at 5a, 5b and 5c.

No signature-footprint multiplier is disclosed, because no post-quantum signature is deployed or specified. No projection is published for the per-block byte cost of an ML-DSA-44 signature at 2,420 bytes per FIPS 204, an SLH-DSA-SHA2-128s signature at 7,856 bytes per FIPS 205, or a Falcon-512 signature at roughly 666 bytes compressed per the round-3 submission. This matters more here than on a slower chain, because mini-blocks are produced roughly every 10ms and each one carries a signature. No aggregation or data-availability offloading design for post-quantum signatures exists, and although MegaETH operates a dual gas model with separate storage and compute dimensions and has already recalibrated precompile pricing, no recalibration of transaction-weight or fee accounting to stop post-quantum-secured transactions being fee-penalised is published. Undisclosed scores zero.

MegaETH's own connection guide names MetaMask and Rabby and otherwise directs users to any Ethereum-compatible wallet, all signing with ECDSA secp256k1, and MegaETH also publishes its own embedded wallet SDK, MOSS, live since 2026-06-17. No wallet in that set publishes a dated roadmap for ML-DSA, SLH-DSA or Falcon signing, and no hybrid-signature wallet integration is documented for this chain. MOSS's own key-custody model and signature scheme are not published in either direction. Neither the roadmap component nor the volume-concentration component earns any points.

Bridging is documented through MegaETH's Rabbithole portal, which hosts a built-in USDm bridge and LI.FI, plus third-party routes named in the documentation: Bungee, Stargate, deBridge, Across, Portal (Wormhole), Jumper and Relay. None publishes a post-quantum roadmap or describes quantum-resistant verification of bridge messages. Bridge authorization rests on ECDSA secp256k1 signatures and on the Groth16-based settlement path, both Shor-break.

No custodian or exchange integration for MegaETH is named in any public source, so none is documented as publishing a post-quantum roadmap or as having assessed threshold-MPC compatibility for ML-DSA. The MEGA token generation event took place on 2026-04-30, so a custody surface exists for this chain; nothing about its post-quantum posture is published in either direction.

RPC component, 0 of 8: independent providers including Alchemy and Chainstack serve MegaETH over JSON-RPC on HTTPS and WSS, and neither documents a post-quantum roadmap or a hybrid key-establishment construction such as X25519 with ML-KEM-768 for these endpoints. HSM component, 0 of 8: no hardware-security-module-backed key management is documented for the sequencer key or any other MegaETH infrastructure, so no HSM algorithm-support roadmap applies. TEE component, 0 of 9: no trusted execution environment is documented in block building or proving, since settlement uses a RISC Zero zkVM rather than an enclave, so no RSA-to-post-quantum attestation transition is documented for this chain.

MegaETH runs a single active sequencer operated by MegaETH Labs, with a standby that takes over within tens of milliseconds, so the effective Nakamoto coefficient for transaction ordering is one. A Sequencer Safe of 1-of-5 lets a single signer execute sequencer transactions, core contracts are upgradeable by a 6-of-10 Safe with no delay, an EigenDA operations multisig is 2-of-4, a treasury multisig is 4-of-6, fewer than five external actors can submit challenges to a state-root proposal, and one entity holds an extended proposal-advantage window. There is a single Reth-derived client and no client diversity, and the node software required to watch the chain independently is not published, which is why the chain does not meet the requirements of the lowest rollup decentralization stage. A validator count of 16 circulates in third-party educational material; no MegaETH-operated source publishes a validator count, so the public record does not support the figure.

MegaETH ships protocol upgrades on a published cadence, ten mainnet activations between 2025-12-04 and 2026-08-25, each staged on testnet first. The closest thing to a fork under time pressure is Rex1, a patch release fixing a cross-transaction gas-detention state leak, which activated on testnet on 2025-12-19 and on mainnet on 2025-12-21, a two-day turnaround. That demonstrates the chain can move fast when a defect is found. What the record does not contain is a fork coordinated against an adversary or an external deadline, and upgrades execute through multisigs with no delay rather than through a set that has to be persuaded. The one tracked governance change, on 2026-08-27, removed a member from the EigenDA operations multisig and narrowed its threshold from 3-of-5 to 2-of-4, narrowing rather than broadening the set that would have to agree on a cryptographic change.

MegaETH Labs is the named coordinating entity, with publicly identified leadership, a published technical direction toward dual-client stateless validation in which a block is valid only when MegaETH's stateless validators and an external network reach the same state root, and a named external technical-integration partner, Pi Squared, for that work. What is missing is a mandate: no working group, no named owner for cryptographic decisions, no published process for deciding or executing a migration of the ECDSA secp256k1 signature path, and no date for any step toward decentralized sequencing.

No precedent exists. MegaETH has not coordinated a change of cryptographic primitive while an attacker was actively threatening, and its public history, running from Frontier mainnet beta in December 2025 through public mainnet on 2026-02-09 and ten network upgrades since, contains no such event.

No canary or tripwire exists. There is no monitored honeypot at a quantum-vulnerable ECDSA secp256k1 address, no rate-limited spending rule for legacy-exposed value, no cryptographic tripwire embedded in consensus with a published threshold, and no automated response that would pause signing or switch to a hybrid path on detection.