Blockchain Quantum Readiness Index / OP Mainnet
L2 · EVM
OP Mainnet
OP Labs has an official post-quantum roadmap: retire elliptic-curve user accounts via smart accounts over ten years and move the sequencer to post-quantum signatures, but no scheme is chosen and nothing is on mainnet. Its fault proofs are hash-based, but they read transaction data through Ethereum's elliptic-curve KZG checks, so they are not quantum-safe either. A 10-of-13 security council, together with the Foundation's multisig, can upgrade contracts without delay.
Last reviewed 2026-10-19
Is OP Mainnet quantum safe?
Not yet. OP Mainnet is at Stage 1 (Committed) in LimeChain's Blockchain Quantum Readiness Index, with a progress score of 12/100. There is an official plan for post-quantum accounts, but no code in the core software yet. Still exposed or unproven: proof system, bridges & messaging, admin & upgrade keys.
What OP Mainnet needs for Stage 2: Code merged
- Stage 2 needs PQ user accounts merged into the core code (U is: planned)
Caps and adjustments
- P: mechanism hash-based-fault-proof is vulnerable (component KZG is vulnerable: Shor's algorithm breaks discrete logarithms in pairing groups. Forged openings can make a verifier accept wrong blob data.) -> treated as exposed
- B: mechanism hash-based-fault-proof is vulnerable (component KZG is vulnerable: Shor's algorithm breaks discrete logarithms in pairing groups. Forged openings can make a verifier accept wrong blob data.) -> treated as exposed
- cap 40: users cannot hold and spend funds under a production PQ mechanism on mainnet
- cap 60: consensus PQ not even on testnet
Rosette slices
| Slice | State | Points | Weight | Reason & evidence |
|---|---|---|---|---|
| U User keys | Planned At rest: Hidden until first spend OP Mainnet is EVM-equivalent and keeps Ethereum EOAs (an L1 EOA's address is the same on L2), so the best option is a never-spent secp256k1 EOA whose address is a Keccak-256 hash of the public key. No PQ smart-account deployment on OP Mainnet was found and the OP Labs roadmap has not chosen a PQ scheme. |
2/10 | 25 | Official OP Labs roadmap commits to EOA deprecation via smart accounts; the PQ signature scheme is not yet chosen. Sources 1 |
| C Consensus | Planned | 2/10 | 20 | The sequencer/batcher signs its L1 posting transactions with a standard Ethereum (secp256k1) key. OP Labs' roadmap commits to moving the sequencer and batch submitter to post-quantum signatures, without a date. Sources 1 |
| P Proof system | Exposed vulnerable hash-based-fault-proof Hash-based (keccak256 Merkle commitments + MIPS one-step proofs) claimed “live-pq” without valid evidence |
0/10 | 10 | Fault proofs were activated on OP Mainnet on 2024-06-10 and are permissionless: disputes bisect keccak256 Merkle state commitments to a single MIPS instruction verified on-chain, with no elliptic-curve signature in proof verification. The fault proof reads blob data through the EIP-4844 KZG point-evaluation precompile (PreimageOracle.loadBlobPreimagePart), so a forged KZG opening could win a dispute. |
| B Bridges & messaging | Exposed vulnerable hash-based-fault-proof Hash-based (keccak256 Merkle commitments + MIPS one-step proofs) claimed “live-pq” without valid evidence |
0/10 | 15 | L1StandardBridge withdrawals are proven 'using a Merkle proof against the output root claimed by a fault dispute game' and finalize permissionlessly by any EOA after the 7-day challenge period; the proof machinery is hash-based. The fast path relies on the ECC-signed sequencer feed (see C). The fault proof reads blob data through the EIP-4844 KZG point-evaluation precompile (PreimageOracle.loadBlobPreimagePart), so a forged KZG opening could win a dispute. |
| A Admin & upgrade keys | Exposed | 0/10 | 15 | The Security Council is a '10-of-13 multisig' (ECC keys) that 'can be used to upgrade core OP Stack smart contracts without upgrade delays', co-managed with the Foundation's 5-of-7 multisig as a 2-of-2 nested pair; either can veto, but the upgrade path has no delay. |
| M Migration & recovery | Planned | 2/10 | 15 | The roadmap is a 10-year EOA deprecation commitment; no ratified migration spec yet. Sources 1 |
Stage gates
| Requirement | Status | Details & evidence |
|---|---|---|
| Current audit of the deployed PQ signing code (Stage 5) | Not met | not claimed |
| Exit window of at least 7 days before upgrades (Stage 5, L2s with ECC admin keys) | Not met | not claimed |
| Admin timelock of at least 30 days with a PQ override (Stage 6, alternative to PQ admin keys) | Not met | not claimed |
| Ratified migration plan with an activation date (Stage 6) | Not met | not claimed |
| New accounts PQ or hybrid by default (Stage 6) | Not met | not claimed |
| ECC sunset enforced (Stage 7) | Not met | not claimed |
PQ adoption published, not scored
There are no PQ accounts on mainnet yet. Having PQ accounts does not mean people move to them. This tracks the share of value and accounts that actually moved, over time.
Measured exposure
No on-chain probe run yet. Bitcoin, Solana, Cosmos and Substrate probes are planned.
Evidence and sources (9)
Every non-zero rating above cites at least one of these public sources.
- optimism.io/blog/a-post-quantum-roadmap-for-the-superchain
- docs.optimism.io/op-stack/protocol/differences.md
- ethereum.org/en/developers/docs/accounts/
- docs.optimism.io/op-stack/fault-proofs/explainer.md
- docs.optimism.io/op-stack/fault-proofs/cannon.md
- github.com/ethereum-optimism/optimism/blob/develop/packages/c…
- docs.optimism.io/op-stack/bridging/withdrawal-flow.md
- docs.optimism.io/op-stack/security/faq-sec-model.md
- etherscan.io/address/0xc2819DC788505Aac350142A7A707BF9D03E3Bd03
Source: chains/op-mainnet.json. Reproduce: python3 score.py chains/op-mainnet.json
Building on OP Mainnet?
LimeChain helps teams plan their post-quantum migration: what is exposed, what to change first, and the engineering to get there.
Talk to usOpen, repeatable scoring. Non-zero ratings need public evidence; missing evidence means unknown. Methodology v0.4 · mechanism registry 2026-10-13.