## 2. Proof system

Research snapshot: 2026-10-27. This is project-source corroboration, not an independent audit of deployed contracts.

- **Optimistic fault proofs are live.** The explainer expressly includes OP Mainnet, says anyone can submit state proposals and challenge them, and dates OP Mainnet activation to **June 10, 2024**. Proposals go to Ethereum through `DisputeGameFactory`; challenges can be run with `op-challenger`. This is permissionless participation, not a proposer/challenger allowlist in the ordinary fault-proof path. [Fault proofs explainer](https://docs.optimism.io/op-stack/fault-proofs/explainer).
- **Mechanism: interactive, bisecting fault disputes.** The components documentation describes a fault-proof program, fault-proof VM and dispute protocol; bisection narrows an execution disagreement to one instruction proven on L1. Its current default program is **`kona-client`**, combining Rust consensus/execution implementations; its predecessor `op-program` is end-of-support and cannot support Karst. References to future ZK or multi-proof configurations on that page do not establish that OP Mainnet has switched to validity proofs. [FP system components](https://docs.optimism.io/op-stack/fault-proofs/fp-components).
- **Current documented VM/program combination:** the Karst entry says the active upgrade promoted **`CANNON_KONA`** to respected game type. The OP Mainnet registry dates Karst activation to **July 8, 2026, 16:00:01 UTC**. The reference identifies `CANNON_KONA` as Cannon VM with Kona. This is documentation/configuration evidence, not a fresh read of the deployed respected-game-type slot. [Karst](https://docs.optimism.io/op-stack/protocol/hardforks/karst); [OP Mainnet registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml); [Fault proofs reference](https://docs.optimism.io/op-stack/fault-proofs/reference).
- **Code corroboration:** `FaultDisputeGame.step(...)` is a public single-step dispute function, whose comments describe executing a step of the fault-proof program onchain through `IBigStepper`. This corroborates the interactive execution-proof mechanism; the development branch alone does not establish a deployed implementation version. [FaultDisputeGame.sol](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol).
- **Challenge/withdrawal timing:** the explainer describes an approximately one-week challenge period. The chain-specific finality page says Standard Bridge withdrawals to Ethereum wait **7 days**, while ordinary transaction finality typically takes **15–30 minutes**. These are different clocks; seven days is not the time every L2 transaction needs to become final. [Fault proofs explainer](https://docs.optimism.io/op-stack/fault-proofs/explainer); [OP Mainnet transaction finality](https://docs.optimism.io/op-mainnet/network-information/transaction-finality).
- **Permissionless has a privileged backstop:** the Security Council, acting as Guardian, can intervene and move the system to a permissioned dispute game, with designated proposer/challenger roles. Therefore the docs do not describe an irrevocably permissionless proof system. [Security model](https://docs.optimism.io/op-stack/security/faq-sec-model).

## 3. Exit window and upgrades

- **Contract upgrade authority:** the L1 Proxy Admin upgrades most system contracts. Its owner is a nested **2-of-2** multisig requiring the Optimism Foundation and Optimism Security Council. The component thresholds are **5-of-7 Foundation** and **10-of-13 Security Council**. Both component multisigs must approve an upgrade; either can veto. The registry marks OP Mainnet `governed_by_optimism = true`. [Privileged roles](https://docs.optimism.io/op-stack/protocol/privileged-roles); [Security model](https://docs.optimism.io/op-stack/security/faq-sec-model); [OP Mainnet registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml).
- **Upgrade delay and exit opportunity, according to the security docs:** the security-model page explicitly permits core-contract upgrades **without upgrade delays**, for fast responses to security concerns. Consequently that documented upgrade path supplies **no guaranteed pre-upgrade exit window** (an implication of the documented absence of delay). The seven-day bridge-withdrawal wait is not a seven-day upgrade timelock. [Security model](https://docs.optimism.io/op-stack/security/faq-sec-model); [OP Mainnet withdrawal timing](https://docs.optimism.io/op-mainnet/network-information/transaction-finality).
- **Conflicting project statement:** the project article *Institutional DeFi for Fortune 500 Enterprises* describes a **14-day delay with Foundation veto on non-emergency upgrades** for chains participating in Optimism Governance, alongside the 2-of-2 structure and a 75% Council threshold. This differs from the security docs' no-delay description; it also does not remove an emergency bypass. Do not treat 14 days as a verified OP Mainnet exit guarantee: the current deployed distinction between these routes was **NOT FOUND** in the sources inspected. [Project article](https://optimism.io/blog/institutional-defi-fortune-500-enterprises); [Security model](https://docs.optimism.io/op-stack/security/faq-sec-model).
- **Council powers:** the Stage 1 specification places the Guardian with the Security Council and lists pausing/unpausing, changing respected game type and blacklisting dispute games among its powers. It requires Council sign-off for upgrades and describes the joint 2-of-2 Foundation/Council upgrade control. [Stage 1 roles and requirements](https://specs.optimism.io/protocol/stage-1.html).

## 4. Data availability

- **Ethereum DA, primarily EIP-4844 blobs.** Optimism's OP Mainnet explainer explicitly says transaction data is compressed, batched and submitted primarily through Ethereum blobs. The chain registry independently labels OP Mainnet `data_availability_type = "eth-da"`. No external DA layer or DA committee is identified for OP Mainnet in these sources. [What is OP Mainnet?](https://optimism.io/blog/what-is-op-mainnet); [OP Mainnet registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml).
- **Calldata remains supported, rather than blobs being exclusive.** The stack configuration specification permits switching between Ethereum blobs and calldata and excludes Alt-DA from standard configuration. Optimism's own incident report records OP Mainnet switching to calldata during high blob fees on June 20, 2024, then returning to blobs. This documents actual use of both Ethereum modes, not an outside DA service. [Configurability](https://specs.optimism.io/protocol/configurability.html); [OP Mainnet elevated-fee incident](https://status.optimism.io/clxnipyv759364bhmsk2dwifoa).

## 5. Sequencer and forced inclusion

- **Centralized block-production model:** the project's forced-transaction tutorial says the stack currently has one active sequencer at any given time. OP Mainnet's registry identifies its sequencer RPC as `https://mainnet-sequencer.optimism.io`. This establishes the documented single-active-sequencer model and endpoint, but does not establish the legal entity operating it. An explicit current OP Mainnet operator attribution to Foundation versus OP Labs was **NOT FOUND** in the inspected documentation. [Triggering transactions from Ethereum](https://docs.optimism.io/app-developers/tutorials/transactions/send-tx-from-eth); [OP Mainnet registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml).
- **Users can bypass censorship:** a user sends a deposit transaction to the Ethereum **`OptimismPortal`**, rather than relying on the sequencer to accept a native L2 transaction. The docs say forced transactions can also initiate withdrawals. The corresponding source entry point is **`depositTransaction(address,uint256,uint64,bool,bytes)`**, a public payable method carrying the L2 target and calldata. [Forced Transaction](https://docs.optimism.io/op-stack/transactions/forced-transaction); [OptimismPortal2.sol](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L1/OptimismPortal2.sol).
- **Fallback delay: a 12-hour sequencing window.** The docs say that during prolonged sequencer downtime nodes derive blocks deterministically after the window expires, incorporating forced deposits; native sequencer transactions wait for recovery. The registry sets OP Mainnet `seq_window_size = 3600`; the specification interprets 3,600 Ethereum blocks at 12 seconds as **12 hours**. This is a derivation fallback window, not a claim that every deposit waits 12 hours, nor a guarantee measured independently of Ethereum block production. [Forced Transaction](https://docs.optimism.io/op-stack/transactions/forced-transaction); [OP Mainnet registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml); [Configurability](https://specs.optimism.io/protocol/configurability.html).
- **Timing inconsistency:** the forced-transaction guide says maximum sequencer drift is **30 minutes** and normal deposits are included within that interval. The OP Mainnet registry instead records `max_sequencer_drift = 600` (10 minutes if interpreted in seconds). These are different values; neither should be silently substituted for the separate 12-hour sequencing window. Their reconciliation and the exact current operational deposit latency were **NOT FOUND** in the pages inspected. [Forced Transaction](https://docs.optimism.io/op-stack/transactions/forced-transaction); [OP Mainnet registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml).

## 1. Stage

- **Project-reported Stage 1:** Optimism's OP Mainnet explainer, updated July 31, 2026, explicitly describes the chain as rated Stage 1 by L2BEAT. This cites Optimism's own statement only; no L2BEAT page was used as evidence for this item. [What is OP Mainnet?](https://optimism.io/blog/what-is-op-mainnet).
- **Historical milestone and roadmap:** the project's June 10, 2024 announcement associates live permissionless fault proofs on OP Mainnet with reaching Stage 1, while retaining Council intervention and permissioned fallback in a system failure. Its companion announcement describes Stage 2 as a further objective. [Permissionless fault proofs and Stage 1](https://optimism.io/blog/permissionless-fault-proofs-and-stage-1-arrive-to-the-op-stack); [Fault Proof System availability](https://optimism.io/blog/the-fault-proof-system-is-available-for-the-op-stack/).
- **Project's stated Stage 1 design rationale:** permissionless fault proofs, a Security Council, Council-required upgrade sign-off and Council-held Guardian powers. The specification's core invariant says permanent withdrawal-liveness or withdrawal-safety failures require at least 75% of the Council, excluding bugs. This is the project's design explanation, not an independent certification that every live deployment meets it. [Stage 1 roles and requirements](https://specs.optimism.io/protocol/stage-1.html).
- **Direction beyond Stage 1:** the security docs describe a multi-client/multi-proof approach intended eventually to eliminate instant upgrades; they do not give a completion date. [Security model](https://docs.optimism.io/op-stack/security/faq-sec-model).

## Not found

- **Exact current sequencer operating entity:** NOT FOUND as an explicit, current OP Mainnet-specific attribution in the pages inspected. Tried [forced-transaction tutorial](https://docs.optimism.io/app-developers/tutorials/transactions/send-tx-from-eth), [sequencer outages](https://docs.optimism.io/op-stack/protocol/outages), [architecture](https://docs.optimism.io/op-stack/architecture), [OP Mainnet explainer](https://optimism.io/blog/what-is-op-mainnet), and [registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml). The operator of other OP Enterprise chains was not assumed to be OP Mainnet's operator.
- **Reconciled current OP Mainnet upgrade timelock and guaranteed user exit allowance:** NOT FOUND beyond the no-delay security model and conflicting non-emergency 14-day project article. Tried [security model](https://docs.optimism.io/op-stack/security/faq-sec-model), [privileged roles](https://docs.optimism.io/op-stack/protocol/privileged-roles), [Stage 1 specification](https://specs.optimism.io/protocol/stage-1.html), [protocol upgrades](https://docs.optimism.io/governance/protocol-upgrades), and [enterprise article](https://optimism.io/blog/institutional-defi-fortune-500-enterprises). No guaranteed 14-day exit was inferred.
- **Reconciliation of the 30-minute drift guide with the registry's 600 value:** NOT FOUND; tried [Forced Transaction](https://docs.optimism.io/op-stack/transactions/forced-transaction), [registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml), and [derivation specification](https://specs.optimism.io/protocol/derivation.html). The 12-hour fallback is separately documented.
- **A complete six-month stage-change history (April 27–October 27, 2026), or a dated Stage 2 commitment:** NOT FOUND in [OP Mainnet explainer](https://optimism.io/blog/what-is-op-mainnet), [Stage 1 launch announcement](https://optimism.io/blog/permissionless-fault-proofs-and-stage-1-arrive-to-the-op-stack), and [security model](https://docs.optimism.io/op-stack/security/faq-sec-model). A July Stage 1 statement and a 2024 milestone do not establish absence of intermediate changes.
- **Fresh onchain confirmation of the exact deployed proof implementation/respected game type:** not performed for this documentation/code item. The supported conclusion is the documented Karst promotion to Cannon/Kona; a stack catalogue of OP Succinct, ZK or alternative game types is not evidence those games secure OP Mainnet. Tried [Karst](https://docs.optimism.io/op-stack/protocol/hardforks/karst), [FP components](https://docs.optimism.io/op-stack/fault-proofs/fp-components), and [game-type reference](https://docs.optimism.io/op-stack/fault-proofs/reference).