Skip to content

protocol

Optimism activates Karst on 10 Superchain mainnets, ships L2CM and kona fault proofs

Karst (Upgrade 19) activated July 8 16:00 UTC across op, ink, zora, mode, lisk, metal, unichain, soneium, ethernity, tbn. Adds L2CM, promotes kona-client, ports five Osaka EIPs. op-geth EoS.

by 6 min read

Optimism activated Karst — its 19th mainnet hard fork — across ten Superchain mainnet chains at Unix timestamp 1783526401 (July 8, 2026, 16:00:01 UTC). The activation is documented in the Upgrade 19 notice and shipped through mandatory client releases op-node v1.19.2 and op-reth v2.3.3. Karst does three things at once: it introduces a new consensus-layer mechanism for governance-approved L2 smart contract upgrades (the L2 Contract Manager), promotes the Rust-based kona-client to primary fault-proof program for withdrawals, and ports a subset of Ethereum's Osaka EIPs down to L2. Two side effects matter operationally: op-geth reached end-of-support with this activation, and the BN256 pairing precompile input size gets a preemptive Glamsterdam-defense cut.

What activated at 16:00:01 UTC

Ten chains crossed the fork block together: op, ink, zora, mode, lisk, metal, unichain, soneium, ethernity, tbn. All are OP Stack mainnets tracked in the Superchain Registry. Activation was gated on Optimism governance approval (which had passed) and on each chain's operators running the required client stack. Operators that had not updated by activation lost sync at the fork block; op-geth in particular could not follow past Karst under any configuration.

The three headline changes

L2 Contract Manager

The L2 Contract Manager (L2CM) is the biggest architectural addition. Until Karst, upgrading L2 smart contracts on OP Stack chains required either fresh deployment plus migration or bespoke privileged multisig calls. L2CM introduces a network-upgrade-transaction primitive at the consensus layer: governance-approved contract upgrades are encoded as system transactions that apply during derivation, so the change is visible to every node the same way any state transition is, without off-chain privileged action. The mechanism lands as spec PR #904 merged into the Karst overview.

Kona-client promoted to respected game type

The fault-proof system now uses CANNON_KONA — the Rust-based kona-client — as the primary fault-proof program that resolves withdrawal disputes on L1. Prior to Karst, the fault-proof program had shipped in Go (cannon); kona is a from-scratch Rust reimplementation. Making it the respected game type means withdrawals that hit a challenge fall back to kona's proof, not cannon's, when they diverge. This is a significant surface-area shift for the fraud-proof system — kona has had a shorter mainnet history than the Go client it replaces at the sharp end.

Osaka EIPs on L2

Karst ports a subset of Ethereum's Osaka hard-fork EIPs onto L2:

  • EIP-7825 — per-transaction gas limit of 2^24 = 16,777,216 gas. Transactions above the cap are invalid. Deposit transactions are exempt — deposits already carry the 20M-gas L1 aggregate cap, and rejecting a deposit on L2 that succeeded on L1 would risk permanent ETH loss.
  • EIP-7883 — MODEXP gas floor increase.
  • EIP-7823 — MODEXP input size cap.
  • EIP-7951 — P256VERIFY gas cost increase.
  • EIP-7939 — CLZ (count-leading-zeros) opcode.

These bring L2 execution semantics closer to Ethereum's, which matters for tools and contracts that assume mainnet gas costs and opcode availability.

Preemptive Glamsterdam defense

The BN256 pairing precompile maximum input size drops from 427 pairs to 300 pairs, ahead of a corresponding change expected in Ethereum's Glamsterdam upgrade. Optimism's team is landing it early rather than mid-cycle to avoid a mismatch when L1 activates. Contracts using bn256Pairing at the old ceiling need to split their inputs.

Numbers

- Activation timestamp       : 1783526401 (2026-07-08 16:00:01 UTC)
- Upgrade number             : Upgrade 19 ("Karst")
- Superchain mainnets        : 10 (op, ink, zora, mode, lisk, metal,
                                    unichain, soneium, ethernity, tbn)
- L2 per-tx gas cap (7825)   : 2^24 = 16,777,216 gas
- Deposit exemption          : yes (L1 20M-gas aggregate cap unchanged)
- BN256 pairing max input    : 300 pairs (was 427)
- Required node client       : op-node v1.19.2
- Required EL client         : op-reth v2.3.3
- op-geth status             : end-of-support at Karst
- Fault proof program        : CANNON_KONA (kona-client, Rust) — respected
- Osaka EIPs ported to L2    : 7825, 7883, 7823, 7951, 7939

Figures per the Upgrade 19 notice, op-node/op-reth release notes and the ethereum-optimism/specs Karst overview.

Operator impact

  • Sequencers and node operators on any of the ten chains must run op-node v1.19.2 (or later) with op-reth v2.3.3 (or later). op-node v1.19.2 fixes a specific consensus-layer sync bug affecting op-reth nodes that prune historical block bodies (with --minimal or --prune.bodies.distance). The interim workaround was to disable pruning or switch to EL syncing; v1.19.2 removes the need.
  • Anyone still running op-geth as their execution client fell out of sync at the fork block. op-geth end-of-support was pre-announced with the Karst timeline, but retiring a client that has served since Bedrock is a meaningful ecosystem shift — Rust is now the sole EL client for OP Stack production.
  • Withdrawals in flight through the challenge system at activation switch to kona-client's fault-proof program. Anyone monitoring open challenges should re-verify their proofs against the new respected game type.
  • Applications using bn256Pairing at inputs above 300 pairs revert post-Karst. Any zk verifier or multi-pairing that pushed the old ceiling needs to split its call.

What to watch

  1. Kona-client challenge-response performance in production. The Go cannon program spent years being adversarially tested on mainnet withdrawals. Kona has had less time under real conditions at the sharp end; the first live challenge post-Karst is the meaningful test.
  2. L2CM's first governance-approved upgrade. The mechanism is now live but has not yet been exercised against a real contract. The first time a governance-approved system transaction re-writes an L2 contract will surface any implementation gap between spec and node.
  3. Chain-level lag. Not every Superchain mainnet is expected to activate in perfect lockstep — the notice frames July 8 as the optimistic mainnet activation date; operators can trail. Watch the individual chain telemetry (Base, notably, is not in the Karst list — its own upgrade cadence is separate).
  4. Follow-on Glamsterdam EIPs. Karst ports five Osaka EIPs but not all of them. The next OP Stack upgrade window is where the remainder catch up; the BN256 downshift telegraphs that Glamsterdam alignment is a design goal, not an accident.

Context — the OP Stack hard-fork cadence

Karst is the second OP Stack activation of 2026, following Fusaka in early spring. The pace — roughly one hard fork per quarter across the whole Superchain — is what distinguishes OP Stack from a typical single-chain L2: a coordinated ten-chain activation is only sustainable because the client stack, the fault-proof program and the governance sequence are shared. That is also the ecosystem risk vector, of course. A regression in op-reth v2.3.3 or in the kona-client fault proof does not fall on one chain; it falls on all ten at once. The tight lockstep is the feature, and it is the exposure.

Base — the Superchain's largest chain by activity — is not listed in the Karst activation set. Its upgrade cadence is out of phase with the rest of the OP Stack fleet, and follows a separate coordination lane; see the June 25 mainnet stall before Beryl for the last time that mattered operationally.

Related stories