Skip to main content
As the ecosystem matures, we are transitioning full execution client support to op-reth and moving from op-program to kona-client.

​
What this means

  • op-geth support ended May 31st, 2026. Security patches and critical bug fixes were issued through that window; support has now ended.
  • New feature development, including the Karst hardfork, happens on op-reth only.
  • op-program has also reached end-of-support. The fault proof program has transitioned from op-program to kona-client.
  • op-program does not support the now-active Karst hardfork. Chain operators must migrate to kona-client.
  • kona-node is not required for cannon-kona. You can run kona proofs with your existing op-node setup. kona-node is a separate, optional component and is not part of the fault proof program migration.
  • op-node is not being deprecated.

​
Action required

op-geth does not support the now-active Karst hardfork. Chains still running op-geth can no longer follow the canonical chain.

​
Node Operators

All node operators should migrate to op-reth as soon as possible. For more details, see op-reth configuration in the resources section below.
op-geth reached end-of-support on May 31st, 2026 and does not support the now-active Karst hardfork.
Migrate to op-reth v2.2.3 or later. v2.2.3 is required to enable the historical proof store (v2) via --proofs-history.storage-version=v2. See the historical proofs guide for the setup procedure.
Syncing op-reth takes time. Start early to allow adequate validation before the hardfork window.
Start syncing an op-reth node alongside your existing op-geth node and take a snapshot. Validate sync correctness over a meaningful window—compare block hashes, state roots, and RPC outputs. Once confident, migrate production traffic to op-reth. For OP Mainnet snapshots, you can find snapshots here.

​
Chain Operators

As soon as op-reth is fully synced, take a snapshot. Refresh it regularly as Glamsterdam approaches. Syncing an op-reth node as soon as possible helps ensure a snapshot is available for other validators on your chain so they do not need to sync from scratch. Historical L2 state on op-reth is required for permissioned chains as well, not just permissionless. Withdrawal proving calls eth_getProof on the L2 block where the withdrawal was included regardless of your dispute-game model — op-geth handled this via archive state, and op-reth needs equivalent configuration. Permissioned chains need only a few hours of lookback (covered by option 1 below, without a historical proofs database); permissionless chains need ~28 days. Two options:
  • --rpc.eth-proof-window <num_blocks> — no historical proofs database (ExEx), but performance and memory cost grow the further back you query. Size to cover your dispute-game publishing cadence with margin.
  • --proofs-history — bounded memory, but storage-heavy. The default --proofs-history.window is 1,296,000 blocks (~30 days at 2s block time); adjust if your chain’s block time differs.
See how to run historical proofs with op-reth for sizing guidance and configuration details.

​
Permissionless Chain Operators

In parallel, the fault proof program has moved from op-program to kona-client. With the Karst hardfork now active, chain operators must migrate to kona-client.

​
Resources