Operationally, Upgrade 20 requires operators to match the pinned component versions named in the official notice, provision a working Super Root RPC, run an op-node that serves that Super Root RPC with a populated --safedb.path, and prepare the kona-client/v1.7.0 prestate workflow before following the cutover order exactly as specified. These are readiness prerequisites, not a signal that governance has approved or that execution has occurred; treat them as conditional steps that only proceed once the stated gates are met.
As of 12 September 2026 18:14:30 IST, the governance vote for Optimism Upgrade 20 remained open; Sepolia and mainnet execution were not established, and universal readiness was not established. The Optimism Documentation and the ethereum-optimism/optimism repository updated the Upgrade 20 notice at 11 September 2026 20:54:26 IST, pinning component versions, the cutover order, Super Root RPC requirements, a populated --safedb.path for an op-node serving Super Root RPC, and a kona-client/v1.7.0 prestate workflow. The notice said existing withdrawal proofs remain valid. No halt, exploit, or loss had been established at the cutoff.
Updated notice and still-open state
The latest notice, attributed to Optimism Documentation and mirrored in the ethereum-optimism/optimism repository, was updated on 11 September 2026 20:54:26 IST. It pins exact component versions, a defined cutover order, and specific runtime requirements for Super Root RPC and a populated --safedb.path when an op-node serves that RPC, alongside a kona-client/v1.7.0 prestate workflow. These are verified publication facts about the notice, not evidence that the network has executed an upgrade.
At the evidence cutoff (12 September 2026 18:14:30 IST), the governance proposal was open, so Upgrade 20 was proposed and documented but not approved, executed, or effective. The targets listed—vote close on 16 September, Sepolia execution on 17 September, and mainnet on 24 September—were explicitly contingent on approval and a healthy Sepolia soak. Operators should interpret the notice as readiness guidance under conditions, not as a go signal.
What Upgrade 20 changes and does not change
Per the notice, Upgrade 20 is an L1 contract upgrade with no L2 hard fork. Its stated objective is to move the fault-proof system toward Super Root Dispute Games. That means coordination touches L1 governance and contract deployment pathways, while L2 execution rules are not scheduled to change via a hard fork in this upgrade window. This framing is attributed to Optimism’s official documentation of scope.
What it does not do at this stage: it does not, by itself, alter end-user balances, invalidate existing withdrawal proofs (the notice said those remain valid), or declare new finality guarantees. Finality remains a property of the underlying chains and bridges; readers may wish to review how finality works in layered systems in our explainer at /article/blockchain-finality-when-a-transaction-becomes-durable. Also, no outage, exploit, or loss has been established at the cutoff; any such claims would require corroboration from Optimism’s official records.
Required roles and pinned components
Three operational roles are implicated by the notice: L1 governance and deployment actors for contract changes; node and infra operators responsible for provisioning Super Root RPC and op-node settings; and client maintainers/testing leads preparing the kona-client/v1.7.0 prestate workflow. Each role must align on the pinned versions named in the notice—no cherry-picking of commits, backports, or local patches—because cutover coordination depends on identical assumptions.
Operators should read the official notice as a checklist of prerequisites and ordering, not as a blanket approval to proceed. If you are unfamiliar with how to parse upgrade notices, our guide at /article/method-reading-crypto-protocol-upgrade-notices explains how to separate “published plan” from “executed change,” and how to tag each item as proposed, approved, executed, or effective.
Super Root RPC and populated SafeDB
The notice prescribes a working Super Root RPC and an op-node that serves that RPC with a populated --safedb.path. In plain terms, the RPC endpoint must be reachable and correctly wired into the node’s configuration, and the node must have the SafeDB prepared so it can answer Super Root queries deterministically. This requirement is attributed to Optimism Documentation and is presented as a prerequisite for the upgrade path.
Operational risk if this is missing: the notice indicates that absent RPC availability, an unpopulated SafeDB, or both, operations related to Super Root queries may be impaired. The cutoff record does not establish a chain halt or loss scenario, but it does warn that readiness gaps here can degrade function. Treat this as an open readiness item until tests confirm end-to-end RPC responsiveness and SafeDB integrity on your infra surface.
Kona prestate and cutover sequence
The notice calls out a kona-client/v1.7.0 prestate workflow. In practice, that means teams should prepare the stated prestate artifacts and validation steps so that kona instances can come up in the expected state at the relevant boundary. Do not assume earlier prestates are compatible; the explicit version pin is a guardrail for determinism.
Equally important is the cutover order pinned in the notice. While the exact step list belongs to the official record, the key instruction is not to reorder or parallelize steps that the notice sequences. Upgrades that involve L1 contract changes and new dispute-game plumbing are sensitive to timing. Operators should consider sequencing an internal dry run that verifies: prestate in place, op-node prepared to serve Super Root RPC with a populated SafeDB, and only then proceeding along the pinned order.
Vote, Sepolia, soak and mainnet as conditional gates
The published targets—16 September vote close, 17 September Sepolia execution, and 24 September mainnet—are conditional gates. At the cutoff, the vote was open, Sepolia execution was pending, and mainnet execution was also pending. Movement from proposed to approved requires a recorded governance outcome; movement from approved to executed requires a verifiable L1 execution on Sepolia and then mainnet; movement to effective depends on a healthy Sepolia soak without material regressions, per the notice.
Evidence that would change state includes: an official governance tally marking the proposal as approved; a confirmed Sepolia execution transaction and post-soak report from Optimism’s maintainers indicating a healthy soak; and a confirmed mainnet execution record. Until those artifacts exist, the plan remains guidance. For how we classify uncertainty and state transitions, see /article/how-cryptossinsights-labels-uncertainty.
India operator scope, withdrawal proofs and evidence to watch
For operators in India, the schedule stated in IST aligns naturally with local maintenance windows. However, nothing in the cutoff record establishes India-specific exposure or exceptions; the same prerequisites apply globally: match pinned versions, provision Super Root RPC, populate --safedb.path on an op-node serving that RPC, and complete the kona-client/v1.7.0 prestate workflow before attempting any cutover. Coordinate with upstream maintainers in advance of the targeted dates to mitigate weekend or holiday staffing gaps common in regional teams.
The notice explicitly stated that existing withdrawal proofs remain valid. That is a stability guarantee attributed to the official notice, not a general promise about unrelated bridge states. What would change the operational picture from the cutoff? Three things: (1) an on-chain governance execution record showing approval, (2) a Sepolia execution followed by a documented, healthy soak with no material regressions, and (3) a mainnet execution record aligned with the pinned order. Until then, the prudent posture is readiness without action. For background on L1/L2 interaction models that inform this upgrade’s scope, see /article/layer-1-layer-2-networks-comparison.