{
  "id": "ethereum",
  "name": "Ethereum",
  "type": "L1 + rollup settlement layer",
  "reviewed": "2026-06-24",
  "summary": "Ethereum's state tree (Keccak Merkle-Patricia) and the EVM are post-quantum-safe, but almost everything that signs or commits is breakable: secp256k1 accounts, BLS12-381 consensus, finality, sync committee, MEV-Boost and restaking, plus KZG (BLS12-381) blob data-availability with its trusted setup and the EVM's pairing precompiles. Even RANDAO inherits BLS's weakness. The PQ roadmap (EIP-8141 signature agility, Lean Ethereum's hash-based signatures, a binary state tree) is real but not yet live. Deep-research-verified against the consensus-specs, EIPs and ethereum.org (June 2026).",
  "links": {
    "Website": "https://ethereum.org",
    "PQ roadmap": "https://ethereum.org/roadmap/future-proofing/quantum-resistance/",
    "Consensus specs": "https://github.com/ethereum/consensus-specs"
  },
  "assessment": {
    "1.1": { "verdict": "fail", "scheme": "secp256k1 ECDSA (EOAs)", "why": "Externally-owned accounts sign transactions with secp256k1 ECDSA, which Shor breaks; no post-quantum scheme is the default.", "sources": ["https://ethereum.org/roadmap/future-proofing/quantum-resistance/"] },
    "1.2": { "verdict": "fail", "scheme": "secp256k1 keys", "why": "Stored keys are the same breakable secp256k1 keys; PQ custody only follows once accounts adopt a PQ scheme, which none do by default." },
    "1.3": { "verdict": "fail", "scheme": "Classical threshold / MPC", "why": "Multi-party and MPC signing still split classical keys; PQ threshold signing is research-stage." },
    "1.4": { "verdict": "fail", "scheme": "ERC-4337 / EIP-7702 (classical)", "why": "Account abstraction (ERC-4337, EIP-7702) is opt-in and still verifies ECDSA; no PQ-signature verifier ships by default. Falcon-in-AA is only a research proposal.", "sources": ["https://ethresear.ch/t/migration-strategies-and-falcon-account-abstraction/"] },
    "1.5": { "verdict": "fail", "scheme": "secp256r1 passkeys / session keys", "why": "Passkeys (secp256r1) and session keys exposed via account abstraction rely on Shor-breakable curves." },
    "1.6": { "verdict": "fail", "scheme": "ENS", "why": "ENS names inherit the controlling account's signature, which is breakable until accounts move to PQ." },
    "1.7": { "verdict": "fail", "scheme": "Account-signed votes (Snapshot)", "why": "On-chain and off-chain (Snapshot) governance is authorized by breakable ECDSA account signatures." },
    "2.1": { "verdict": "fail", "scheme": "ecrecover / EIP-712 (ECDSA)", "why": "Contracts verify signatures with secp256k1 ECDSA (ecrecover, EIP-712 permits, Safe multisig); there is no post-quantum signature precompile.", "sources": ["https://www.cyfrin.io/blog/understanding-ethereum-signature-standards-eip-191-eip-712"] },
    "2.2": { "verdict": "fail", "scheme": "EVM pairing precompiles (EIP-2537, EIP-4844 KZG)", "why": "The EVM exposes live pairing/KZG verification — the EIP-2537 BLS12-381 pairing-check precompile (0x0f) and the EIP-4844 point-evaluation precompile (0x0A) — plus pairing-SNARK verifier contracts; all are pairing-based and Shor-breakable.", "sources": ["https://eips.ethereum.org/EIPS/eip-2537", "https://eips.ethereum.org/EIPS/eip-4844"] },
    "2.3": { "verdict": "fail", "scheme": "Operator-signed feeds (Chainlink)", "why": "Oracle feeds (e.g. Chainlink) authenticate data with classical operator signatures.", "sources": ["https://blog.chain.link/chainlink-vrf-on-chain-verifiable-randomness/"] },
    "2.4": { "verdict": "fail", "scheme": "RANDAO (BLS reveals)", "why": "Beacon-chain RANDAO mixes in each proposer's BLS signature over the epoch, so its unpredictability rests on BLS — which Shor breaks, making reveals forgeable/predictable. A post-quantum VRF replacement is only in research, and app-level VRFs (Chainlink) are elliptic-curve based too.", "sources": ["https://ethresear.ch/t/randao-breaks-at-l-a-post-quantum-vrf-for-ethereum/24906"] },
    "2.5": { "verdict": "na", "scheme": "", "why": "Ethereum has no live verifiable delay function; the proposed RANDAO+VDF was never deployed." },
    "3.1": { "verdict": "fail", "scheme": "BLS12-381 proposer signature", "why": "The PoS block proposer orders the block and signs it with a BLS12-381 key (get_block_signature), which Shor breaks.", "sources": ["https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md"] },
    "3.2": { "verdict": "na", "scheme": "", "why": "Ethereum L1 validates blocks by full re-execution, not validity/fraud proofs; zkEVM-based L1 verification is research, not live on mainnet.", "sources": ["https://ethereum.org/roadmap/zkevm/"] },
    "3.3": { "verdict": "fail", "scheme": "EIP-4844 KZG powers-of-tau", "why": "Blob commitments use a live KZG trusted setup (powers-of-tau over BLS12-381). Shor recovers the secret from the public SRS regardless of honest deletion, enabling forged blob commitments — honest-deletion security does not hold against quantum.", "sources": ["https://github.com/ethereum/kzg-ceremony/blob/main/FAQ.md", "https://vitalik.ca/general/2022/03/14/trustedsetup.html"] },
    "3.4": { "verdict": "fail", "scheme": "EIP-4844 KZG blobs", "why": "Data availability uses EIP-4844 blob KZG commitments over BLS12-381 — pairing-based and Shor-breakable (EIP-4844 is Final / live).", "sources": ["https://eips.ethereum.org/EIPS/eip-4844"] },
    "3.5": { "verdict": "pass", "scheme": "Keccak Merkle-Patricia trie", "why": "State is committed with a Keccak Merkle-Patricia trie — hash-based and post-quantum-safe (only Grover-weakened). Verkle (elliptic-curve) was dropped; the proposed binary tree (EIP-7864, still draft) is also hash-based.", "sources": ["https://ethereum.org/roadmap/statelessness/", "https://eips.ethereum.org/EIPS/eip-7864"] },
    "3.6": { "verdict": "pass", "scheme": "EVM", "why": "The EVM carries no cryptography of its own; signature and pairing checks live in other components." },
    "4.1": { "verdict": "fail", "scheme": "BLS12-381 attestations + FFG", "why": "Validator attestations and Casper FFG finality are signed with BLS12-381 (get_attestation_signature) — pairing-based and Shor-breakable.", "sources": ["https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md"] },
    "4.2": { "verdict": "fail", "scheme": "Altair sync committee (BLS)", "why": "The light-client sync committee signs headers with BLS12-381, so light-client header trust is Shor-breakable.", "sources": ["https://eth2book.info/latest/part2/building_blocks/signatures/"] },
    "4.3": { "verdict": "na", "scheme": "", "why": "Ethereum is the base settlement layer; it does not anchor its state to another chain." },
    "4.4": { "verdict": "na", "scheme": "", "why": "As the base layer, Ethereum has no canonical bridge of its own — L2 deposit bridges are the L2s' canonical bridges and everything else is third-party, which this framework does not score against the chain." },
    "4.5": { "verdict": "fail", "scheme": "EigenLayer (BLS)", "why": "Restaking / AVS operators (EigenLayer) sign attestations with BLS, which Shor breaks.", "sources": ["https://docs.eigencloud.xyz/products/eigenlayer/concepts/keys-and-signatures"] },
    "4.6": { "verdict": "na", "scheme": "", "why": "Payment channels / HTLCs are app-layer, not part of the core protocol." },
    "4.7": { "verdict": "fail", "scheme": "MEV-Boost (BLS)", "why": "MEV-Boost relays, builders and the proposer's blinded-block commitment all sign with BLS — a breakable proposer-builder-separation trust surface.", "sources": ["https://github.com/flashbots/mev-boost-relay/blob/main/common/types_spec.go", "https://docs.flashbots.net/flashbots-mev-boost/architecture-overview/block-proposal"] },
    "5.1": { "verdict": "fail", "scheme": "RLPx / libp2p Noise (ECDH)", "why": "Execution-layer RLPx (ECIES over secp256k1) and consensus-layer libp2p Noise use classical elliptic-curve key exchange.", "sources": ["https://github.com/ethereum/devp2p/blob/master/rlpx.md"] },
    "5.2": { "verdict": "fail", "scheme": "secp256k1 node IDs", "why": "devp2p and libp2p node identities are secp256k1 keypairs (classical).", "sources": ["https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md"] },
    "5.3": { "verdict": "fail", "scheme": "Classical TLS", "why": "RPC / API connections to nodes and providers use classical TLS key exchange." },
    "5.4": { "verdict": "fail", "scheme": "ERC-5564 stealth (ECDH)", "why": "The finalized ERC-5564 stealth-address standard derives shared secrets via elliptic-curve Diffie-Hellman, which Shor breaks; harvested data is retroactively de-anonymizable.", "sources": ["https://eips.ethereum.org/EIPS/eip-5564"] },
    "5.5": { "verdict": "na", "scheme": "", "why": "There is no default protocol-level encrypted mempool or privacy layer; Shutter and similar are opt-in / L2." }
  }
}