The primitive set is individually named across the protocol specification and the hard-fork documentation and is fully reconstructible from them: ECDSA secp256k1 over Keccak-256 for account signing, the P256VERIFY secp256r1 precompile of EIP-7951 at address 0x100, the alt_bn128 pairing precompiles of EIP-196 and EIP-197, the BLS12-381 precompiles of EIP-2537, and KZG blob commitments under EIP-4844 for data availability. Every signature here is the pre-hash case: the chain signs a Keccak-256 digest of the encoded transaction, not the message. What is not published is a consolidated cryptographic inventory or agility register naming these primitives in one place with their replacement status, and the post-quantum roadmap names no target primitive at all, so the forward half of the inventory is empty.

The chain's own classification covers one primitive. The post-quantum roadmap identifies ECDSA EOA signing as the quantum-exposed surface and sets a deprecation date for it, and separately names Ethereum's BLS validator signatures and KZG commitments as things Ethereum should commit to moving off. No published classification covers the secp256r1 P256VERIFY precompile, the alt_bn128 pairing precompiles or the BLS12-381 precompiles added at Isthmus, each of which is Shor-breakable and each of which remained in or entered the precompile set at the most recent upgrades. The KZG blob surface is scored on the shorter shelf life its minimum retention window gives it rather than as permanent exposure.

Zero post-quantum algorithm families are deployed. No lattice scheme (ML-DSA per FIPS 204, ML-KEM per FIPS 203, Falcon per the round-3 submission), no hash-based scheme (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), no code-based KEM (Classic McEliece, BIKE, HQC) and no isogeny construction is present in the account layer, the execution client or the precompile set. The roadmap states that the scheme is not yet decided, so no family is even designated. Zero families scores zero. Because no lattice primitive is deployed either, this is not a lattice monoculture and the Cryptographic-Diversity Cap does not apply.

No NIST post-quantum security category is claimed for any primitive. The chain has a published post-quantum migration commitment, so a category target is a decision in scope for it, and the roadmap declines to make it: it states that whether the NIST-standardized lattice-based signatures are the right long-term choice is unknown, and names neither a scheme nor a parameter set, so no mapping to NIST categories 1 through 5 exists. This is a real zero rather than an architectural absence: the decision point exists and is open.

The classical side is mature, the post-quantum side is empty, and implementation diversity on the withdrawal path has narrowed rather than widened. Since Karst, op-geth and op-program are out of support (end of support 2026-05-31) and node operators run op-reth with kona-client for fault proofs, so ECDSA secp256k1 verification on this chain runs through reth, which pins the Rust secp256k1 crate with the public-key recovery feature (a binding to the bitcoin-core/secp256k1 C library) and executes through revm. The BLS12-381 and alt_bn128 precompiles are tier-1 to tier-2 cryptanalytic maturity under the per-primitive maturity scale. Karst made CANNON_KONA (8) the respected fault-proof game type and retained CANNON (0) only to resolve games opened before the upgrade, with op-program no longer supported for new fault proofs, so a single fault-proof program now secures new withdrawals rather than two independent ones. Nothing scores on the post-quantum criteria: there is no deployed ML-DSA, SLH-DSA or Falcon verifier, so there is no reproducible build or independent audit of a deployed post-quantum verifier to evidence, no library provenance question (liboqs, PQCA or otherwise), and no stateful-scheme state-management specification in scope. Constant-time behaviour of the classical implementations is not independently established here; the upstream libraries' own claims are the basis.

Under the Ethereum account model OP Mainnet uses unmodified, any address that has sent at least one transaction has its ECDSA secp256k1 public key recoverable from that transaction's (v, r, s), so it sits permanently in the exposed-after-spend bucket. On a rollup, holding a usable balance normally implies having transacted, which pushes most active value into that bucket. Total value secured is in the $1.57 billion to $1.89 billion range on L2BEAT-derived figures, and no public source partitions it into exposed-active, exposed-dormant and never-revealed shares; no analytics tool publishes that partition for this chain. The small credit here is for the one real mitigation in the architecture, that an address which has only received exposes a Keccak-256 hash and not a key. No post-quantum destination exists to spend into, so the exposure has no exit.

Value at addresses that have never sent a transaction is mitigated-until-spend: only the Keccak-256 address hash is public, and Keccak-256 preimage resistance degrades to roughly 128 bits under Grover rather than falling to Shor. That is genuine protection and it is scored as such. Two discounts apply. No public source segments OP Mainnet's balances by whether the holding address has ever signed, so the size of this protected bucket is not established in the public record. And the protection ends at the first spend with nothing to spend into: no post-quantum address type or transaction type is accepted, so moving a protected balance converts it into an exposed one.

Long-range, at-rest forgery (13 points available) scores 2. The sequencer key and the batch-submitter key are ECDSA secp256k1, public for as long as they are in force, and sign continuously; output-root proposals and dispute-game claims on L1 are signed by long-lived keys; and historical user signatures retain validity indefinitely under the account model. Any CRQC, slow-clock or fast, suffices against all of these. Short-range, on-spend forgery (12 points available) scores 8. The window is short: block time is 2 seconds and a transaction is included by the sequencer on the next block. On exposure discipline the applicable factor is mempool privacy: OP Mainnet operates no public gossip mempool, transactions are submitted to a write-only sequencer endpoint, so a public key is not broadcast to the network before inclusion. That factor is partial rather than full, because the sequencer sees every transaction and because the chain's own documentation directs users to third-party RPC providers that relay on their behalf. Single-use addresses are not enforced and no post-quantum spend path exists.

No transport-cryptography policy is published for this chain, and the transaction-submission path does not offer post-quantum hybrid key agreement. A TLS 1.3 client offering both the hybrid X25519MLKEM768 group and classical X25519 to mainnet.optimism.io and mainnet-sequencer.optimism.io on 2026-09-21 was served X25519 in both cases, and a handshake offering X25519MLKEM768 alone was refused by both hosts with a handshake-failure alert. Both hosts return a via header naming a Google-operated front end. The credit here is for explorer.optimism.io, which is served through Cloudflare and did negotiate X25519MLKEM768 under the same test. Cloudflare documents two hybrid groups, X25519MLKEM768 (TLS identifier 0x11ec, current) and the obsolete X25519Kyber768Draft00 (0x6399), and states that since October 2022 all sites and APIs it serves over TLS 1.3 support post-quantum hybrid key agreement when the client offers it; ML-KEM itself was finalized in FIPS 203 on 2024-08-13, so the October 2022 rollout was the Kyber draft group and the ML-KEM group is the later one. That is a shipped, verified mitigation, but it covers a read-only block explorer, it depends on client initiative, and it is a CDN default rather than a control this chain specifies. No hybrid KEM combiner is specified anywhere in the chain's documentation.

Pseudonymous and fully transparent. Every transaction, state root and withdrawal is published to Ethereum L1, as blobs since the Ecotone upgrade, and L2BEAT records that all data used to construct the system state is published on chain. No shielded, confidential or hidden transaction type exists in the protocol's own feature set. A ceiling of half the available points applies across 3a to 3d because no structural-impossibility statement is published for the chain itself: nothing names what a single sequencer, an RPC provider, a bridge relayer or a TEE operator is capable of revealing, to whom, under what conditions. The chain's September 2026 privacy post comes closest, stating honestly that a deposit into the one shielded pool on the chain is visible on entry, but it describes one application rather than the architecture.

Three components. On origination concentration, the chain's own public endpoint mainnet.optimism.io is documented as strictly rate limited and not supporting websocket connections, and the documentation directs users to a third-party provider or a private endpoint; the chain's own RPC directory lists twenty-three named production providers for OP Mainnet without ranking them, and no public source publishes what share of this chain's reads and broadcasts each carries, so the inverse-scored share cannot be established above a low value. On broadcast observability the position is genuinely mixed and scores in the middle: there is no public gossip mempool to observe, which removes a metadata leak, but the reason is that a single sequencer is the sole ordering entry point under normal operation, with force-inclusion through L1 subject to a delay of up to 12 hours as the only independent path. On metadata retention the score is zero: no IP, timing or client-fingerprint retention policy is declared for the sequencer or for the chain's own RPC endpoints.

Bridge bookkeeping is fully visible on both sides. The native Standard Bridge records deposits on Ethereum L1 and credits on OP Mainnet in public transactions, and the withdrawal path publishes proofs and finalizations on L1 through a seven-day challenge period, so a passive observer links source to destination without privileged access. The chain's own documentation names no third-party bridge route and documents no measure on any route that breaks source-to-destination linkage. The same half-ceiling from the missing structural-impossibility statement applies here.

The base layer holds almost nothing back that a future CRQC could reveal, because it holds nothing back today: transaction content, amounts, counterparties and state are public at the moment they are written, so there is no Shor-breakable confidentiality layer over them to fail later. That is a genuine absence of retroactive exposure and it is scored positively. The deduction is for the one confidentiality layer that does exist on the chain: Privacy Boost, a shielded pool for ERC-20 tokens live on OP Mainnet since April 2026, proves with Groth16 over BN254 through gnark R1CS circuits, with a circuit-specific trusted setup for 21 circuits finalised 2026-09-02 whose published manifest records 26 participants and 490 contributions, reusing the first 80 contributions of the public Perpetual Powers of Tau ceremony as phase 1. Groth16 over BN254 is pairing-based, so the confidentiality it provides has a finite shelf life against Shor, and its privacy also rests on a trusted-execution-environment assumption whose attestation vendor is not named on any published page. The half-ceiling from the missing structural-impossibility statement applies here as well.

One structural hiding mechanism exists on the chain and it is application-layer and opt-in: Privacy Boost, an enterprise privacy SDK built and operated by Sunnyside Labs, running a shielded pool for ERC-20 tokens on OP Mainnet since April 2026, combining Groth16 zero-knowledge proofs over BN254 with a trusted execution environment. It is not a protocol property and does not change the transaction graph of the chain. It falls short of the cryptographic-shuffle band on two counts named in the rubric: deposits into the pool are visible on entry, which the chain's own privacy post states directly, and the prover infrastructure is run by a single operator rather than by three or more independent mix nodes, so the hiding is computationally secure and operator-dependent rather than information-theoretic. No commit-reveal ordering, batch ordering, encrypted mempool or cover-traffic mechanism exists at the protocol layer.

Two mechanisms are in production and one is missing. EIP-7702, set EOA account code, has been live on OP Mainnet since the Isthmus upgrade activated at 16:00:01 UTC on 2025-05-09, which lets an externally-owned account delegate its signing rules to contract code without changing address or balance and without a further fork; that is the verifiable production instance the rubric requires. The L2 Contract Manager, introduced at Karst on 2026-07-08, upgrades L2 predeploy contracts atomically through ProxyAdmin.upgradePredeploys() as part of a governed network upgrade, replacing per-contract multisig transactions, so a future post-quantum verifier predeploy has a deterministic, auditable delivery path. The chain has also demonstrated that it adds new signature-verification precompiles as ordinary work, shipping the secp256r1 P256VERIFY precompile at Fjord. What is absent is a versioned signature-type framework that switches algorithm without a consensus change: predeploy upgrades still ride a network upgrade, and no abstract-validation transaction type of the kind proposed in EIP-8141 (Frame Transaction, draft, created 2026-01-29, whose stated motivation includes a native off-ramp from elliptic-curve authentication to post-quantum schemes) is deployed here or on Ethereum L1.

Account abstraction is live in both forms. ERC-4337 bundlers and accounts operate on OP Mainnet as on any EVM-equivalent chain, and EIP-7702 delegation has been native since Isthmus on 2025-05-09, so per-user opt-in migration to arbitrary verification logic is available today without a protocol change. That is the account-model component at its full band. No credit is added above it. The rubric's client-layer band asks for a concrete signing-layer mechanism of the kind a wallet or device ships; what exists here is a roadmap stating that wallet patterns, sequencer keys and on-chain validation rules will be specified once a scheme is chosen, with no scheme chosen and no deployed or testnet signing path. The Ed25519 seed-derived floor does not apply: OP Mainnet accounts commit to secp256k1 keys, not to an RFC 8032 Ed25519 seed. No post-quantum rebind bonus is earned, because no public artifact specific to a key-rebind proof for this chain exists.

Nine consensus-layer hard forks have activated on OP Mainnet at published, on-chain-enforced timestamps recorded in the Superchain registry: Canyon 2024-01-11, Delta 2024-02-22, Ecotone 2024-03-14, Fjord 2024-07-10, Granite 2024-09-11, Holocene 2025-01-09, Isthmus 2025-05-09, Jovian 2025-12-02 and Karst 2026-07-08, an average of roughly one every three and a half months over two and a half years. Karst activated simultaneously across OP Mainnet, Soneium, Ink, Unichain, Mode, Metal and Zora, so the cadence is demonstrated at Superchain scale and not on one chain alone. L1 contract upgrades run on a separate governance track with a soak period on Sepolia, as Upgrade 20 shows. No contested or chain-splitting fork appears in the record. The single point withheld is for the concentration this cadence rests on: L2BEAT records regular and emergency upgrades alike as executable by the Security Council and the Foundation with no delay and no exit window.

Hybrid signing is architecturally possible today and has not been built. Because EIP-7702 lets any account delegate to contract code, a 2-of-2 account requiring both an ECDSA secp256k1 signature and a post-quantum signature can be deployed on OP Mainnet with no protocol change, and the roadmap commits in words to running overlapping ECDSA and post-quantum acceptance during the migration window. Two things hold the score down. There is no post-quantum verification precompile on the chain: no ML-DSA (FIPS 204), SLH-DSA (FIPS 205) or Falcon verifier exists at a precompile address, so any hybrid account must verify the post-quantum half in EVM bytecode, and no gas-cost or feasibility figure for doing so is published for this chain. And no hybrid account, combiner construction or domain-separation scheme is specified or deployed, so the capability is latent rather than demonstrated.

OP Mainnet 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 appears at the consensus, sequencing 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 for this chain. OP Mainnet has no BFT validator set of its own: blocks are produced by a single sequencer, and withdrawal finality is established by the fault-proof system, whose respected game type moved from CANNON (0) to CANNON_KONA (8) at Karst, anchored to Ethereum L1 consensus. There is no chain-native signature-aggregating committee and no threshold primitive inside the protocol that would need a post-quantum aggregation path. The BLS12-381 aggregation that secures the anchor belongs to Ethereum L1 validators, which this chain does not control, and the EIP-2537 BLS12-381 precompiles adopted at Isthmus are a verification facility for contracts, aggregating nothing at consensus. Chains with non-aggregating consensus signatures are excluded from this sub-score; it is not a zero.

Post-quantum mainnet signing traffic is 0%. Every transaction accepted on OP Mainnet is signed with ECDSA secp256k1 over a Keccak-256 digest. No transaction type accepts an ML-DSA (FIPS 204), SLH-DSA (FIPS 205), Falcon, XMSS or LMS/HSS signature, and no opt-in path exists for any share of traffic. The execution-layer changes in the most recent hard fork, Karst, are EIP-7642, EIP-7823, EIP-7825, EIP-7883, EIP-7910, EIP-7939 and EIP-7951, all gas-accounting, opcode or classical-precompile changes.

No post-quantum signature implementation is present in the software OP Mainnet runs. Since Karst, op-geth and op-program are out of support and nodes run op-reth with kona-client for fault proofs. A code search across the indexed default branches of the reth repository, the kona repository, the chain's protocol specification repository and the OP Stack monorepo returns no occurrence of ML-DSA, Dilithium or SLH-DSA. The index does not cover every branch or fork, so this establishes absence in the indexed default branches rather than across every repository in those organizations. The Rust fault-proof client promoted to the respected game type at Karst introduces no post-quantum primitive either; it reimplements the same classical verification. No testnet-only post-quantum code exists to deduct.

OP Mainnet has key-holding block producers: the sequencer key that orders and produces blocks and the batch-submitter key that posts batches to L1, both ECDSA secp256k1. Those keys exist and could have been migrated or paired with a post-quantum scheme, and the chain's own roadmap states they will transition off ECDSA at some future point, so this is a real zero rather than a structural absence. Nothing has been migrated. This sub-score measures the block-producing key set and does not re-credit user-transaction signing, which is measured at 5a.

One dated post-quantum milestone is published: January 2036, the flag day after which ECDSA-signed EOA transactions are to be deprecated and every ECDSA EOA is to have delegated key management to a post-quantum smart contract account. It is explicitly subject to governance approval, names no signature scheme, and has no interim dated milestone in front of it, so the three named, dated, publicly verifiable next milestones the rubric asks for are not there. Milestone credit is also conditioned on shipped mainnet post-quantum traffic, which is zero. No delivery record can be read against the chain's own published post-quantum dates either: January 2036 is the only one, and it has not come due.

There is no gap between claim and delivery, because no primitive has been claimed. The publisher's own blog index carries exactly one post touching quantum cryptography in the trailing twelve months, the post-quantum roadmap of 2026-01-14, and it names no post-quantum primitive at all: it states that the specific post-quantum signature scheme is not yet decided and that whether the NIST-standardized lattice-based signatures are the best long-term choice is unknown. The chain's entire documentation index, 417 published pages, contains no occurrence of the word quantum. No press release, keynote, documentation page or governance proposal claims that ML-KEM, ML-DSA, SLH-DSA, Falcon, XMSS or LMS/HSS is running on this chain. Announced primitive claims and shipped bytes are both zero, the ratio does not exceed 1.5, and no narrative-only tag applies. A roadmap that declines to name a scheme cannot overstate what it ships.

No signature-footprint multiplier is disclosed, because no post-quantum signature is deployed or specified. Nothing is published projecting the per-block byte cost on this chain 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, and no aggregation or data-availability-offload design is published that would bring an effective multiplier down. The chain has in fact moved its transaction-weight accounting in the opposite direction at the most recent upgrade: Karst imposed a per-transaction gas limit of 2^24 = 16,777,216 gas under EIP-7825 and raised the P256VERIFY precompile from 3,450 to 6,900 gas, and no fee or weight recalibration favouring larger post-quantum-secured transactions is published. An undisclosed multiplier scores zero.

One named wallet vendor serving this chain has published dated post-quantum work, and it is an SDK capability rather than transaction signing. Ledger's embedded-software post of June 2026 documents two post-quantum APIs in the Ledger Embedded OS SDK: ML-KEM with parameter sets ML-KEM-512, ML-KEM-768 and ML-KEM-1024 per FIPS 203, and ML-DSA with parameter sets ML-DSA-44, ML-DSA-65 and ML-DSA-87 per FIPS 204, stating the output is bit-for-bit identical to the NIST standard. The same document sets two limits on the credit: the version described provides algorithmic security only, with constant-time comparison paths and zeroization of intermediates but no hardware countermeasures against fault injection or side-channel attack, which masking and shuffling are named as future work; and ML-DSA-87 is not enabled by default, because without the low-RAM optimization it exceeds the stack budget on Nano X devices. The page makes no claim that device firmware signs blockchain transactions with these schemes. No software wallet serving this chain publishes a post-quantum roadmap: the chain's own network-information page names MetaMask only as a wallet that requires a currency symbol, and MetaMask's own documentation contains no post-quantum statement. No public source publishes the share of this chain's wallet connections each vendor carries, so the tile is scored on the published programmes themselves and not on a concentration figure.

No bridge serving OP Mainnet publishes a post-quantum roadmap. Optimism's own native Standard Bridge has no post-quantum statement in its documentation, and the chain's full documentation index carries no occurrence of the word quantum across 417 pages. Third-party bridge routes into the chain are not named in the chain's own documentation at all, and the independently documented routes checked publish no post-quantum statement either. The messaging layers that carry value to and from this chain authorize transfers with classical elliptic-curve signatures, and none of their public materials names a post-quantum signature scheme, a migration date or a hybrid path. The tile scores zero on vendor roadmaps and zero on concentration among vendors with roadmaps, because there are none.

One named custodian has demonstrated post-quantum signing engineering. BitGo, with Silence Laboratories, completed a post-quantum MPC transaction simulation reported on 2026-05-27 and run the preceding Friday, integrating Silence Laboratories' post-quantum MPC protocol, built on ML-DSA per FIPS 204, with BitGo's institutional custody platform; no published source names the ML-DSA parameter set used. Silence Laboratories publishes the protocol as a threshold implementation of MPC over ML-DSA with BitGo among its named partners; that page also carries a market-position claim for the implementation which no independent source corroborates and which is not carried into this score. The demonstration was a simulation inside a custody workflow rather than production custody of OP Mainnet assets, and it is credited at that level. Utila, the MPC custody provider Optimism's own enterprise material names as its access-layer partner, publishes no post-quantum statement, and neither do the other large custodians whose platforms list this chain among supported networks. The rubric's note that ML-DSA is amenable to efficient MPC while SLH-DSA is not is what makes the BitGo demonstration relevant here; no scheme is mandated by this chain, so the SLH-DSA MPC ceiling does not apply.

Three components. On RPC providers the score is near zero: the chain's own RPC directory lists twenty-three named production providers for OP Mainnet and names no post-quantum capability for any of them, and the four checked directly publish no post-quantum roadmap for this integration; the small credit is for explorer.optimism.io, served through Cloudflare, which negotiated the hybrid X25519MLKEM768 group under direct TLS test on 2026-09-21, a shipped rather than announced control, though it covers a read-only explorer and not the RPC or sequencer path, both of which refused that group under the same test. On HSM and key-management vendors the score is the strongest part of the tile: AWS KMS has shipped ML-DSA signing in general availability since 2025-06-13, with key specs ML_DSA_44, ML_DSA_65 and ML_DSA_87 and signing algorithm ML_DSA_SHAKE_256, creating and using those keys inside FIPS 140-3 Security Level 3 validated hardware security modules, and offering both raw signing and an externally computed 64-byte message representation per FIPS 204 section 6.2, which the vendor's documentation states explicitly is not the HashML-DSA pre-hash variant of FIPS 204 section 5.4. The chain's own key-management guidance points chain operators at an HSM or a cloud key-management service for the batcher and proposer hot keys but states nothing about what secures OP Mainnet's own sequencer or batch-submitter keys, so this is vendor availability, not chain adoption. On TEE attestation the score is zero: no chain-operated trusted execution environment is documented in block building, sequencing or oracles, and the one TEE-backed application on the chain names no attestation vendor and no post-quantum attestation path.

There is no validator set to distribute. Ordering runs through a single sequencer under normal operation, with force-inclusion through Ethereum L1 subject to a delay of up to 12 hours as the independent path, and L2BEAT assesses the chain at Stage 1, passing the walkaway test while carrying two open Stage 2 issues. Upgrade authority is concentrated: a Security Council of 13 voting members and one non-voting lead operates a Gnosis Safe multisig at a 75% signing threshold, members elected by Token House vote to staggered twelve-month terms, and L2BEAT records that both regular and emergency upgrades are executable by the Council and the Foundation with no delay and no exit window. Two things earn the small credit and bound it. Proposing is permissionless, so anyone can propose new roots to the L1 bridge. But client diversity on the part of the stack that adjudicates withdrawals has narrowed rather than widened: Karst made CANNON_KONA (8) the respected game type, retained CANNON (0) only for games opened before the upgrade, and ended support for op-program, so new withdrawals are secured by a single fault-proof program.

The cadence is demonstrated and fast. Nine consensus upgrades activated at published, on-chain-enforced timestamps between 2024-01-11 and 2026-07-08, Karst landing simultaneously across seven Superchain chains, and L1 contract upgrades run on a separate governance track with a documented soak period, as Upgrade 20 shows: published as a proposal 2026-09-09 after an external contracts audit that closed 2026-08-21, targeting Sepolia execution 2026-09-17 and OP Mainnet execution 2026-09-24, subject to governance approval and a seven-day Sepolia soak. Karst also changed the respected fault-proof game type and promoted a different client implementation to primary, which is a live change to the mechanism securing withdrawals, executed on the published timestamp. The points withheld are for the absence of a time-pressured instance: none of the nine upgrades was executed against a running clock set by an adversary or a disclosed vulnerability in the public record.

The governance structure is named and published: a two-house model of the Token House, token-weighted and permissionless to vote or delegate, and the Citizens' House, one member one vote, with a Security Council operating under a published charter and implementing upgrades that Token House governance approves. The post-quantum work has an author rather than a lead. The Superchain post-quantum roadmap is authored by Karl Floersch, an OP Labs co-founder, and states that OP Labs is in communication with people at the Ethereum Foundation. No person, team or working group holds a published mandate specific to the post-quantum transition, and no mandate document for it exists in the governance forum or the documentation. A named author of one blog post is not a coordination lead.

No cryptographic change coordinated under active adversarial pressure appears in the public record for this chain. The credit is for the machinery that would carry one: the Security Council can execute emergency upgrades at a 75% threshold with instant effect and no delay, the nine-fork record shows that a consensus change can be scheduled and landed across the Superchain on a fixed timestamp, and the L2 Contract Manager added at Karst makes a predeploy replacement a single governed transaction rather than a sequence of multisig signings. That machinery is exercised routinely and has never been exercised against an attacker.

No canary or tripwire exists. Nothing in the protocol specification, the governance forum or the post-quantum roadmap documents a honeypot address monitored for legacy-key compromise, a rate-limited spending rule on exposed value, a cryptographic tripwire embedded in consensus with a published threshold, or an automated response that would pause signing, switch to a hybrid path or alert wallets on detection. The chain has no mechanism that would tell it a CRQC had arrived other than the loss itself.