Skip to main content

Documentation Index

Fetch the complete documentation index at: https://optimism-373f39ad-sb-op-reth-prune-interval-doc-cleanup.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

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 is supported through May 31st, 2026. Security patches and critical bug fixes will continue to be issued during this window, after which support ends.
  • New feature development, including the next Karst hardfork, will happen on op-reth only.
  • op-program is also reaching end-of-support. The fault proof program is transitioning from op-program to kona-client.
  • Current op-program deployments are expected to remain usable until the next hardfork, Karst. Chain operators will need to migrate to kona-client at Karst.
  • 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 will not support the L1 Glamsterdam hardfork. Chains still running op-geth at activation will not be able to 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 reaches end-of-support in May 31st, 2026. Glamsterdam will break compatibility with op-geth.
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 is moving from op-program to kona client. Current op-program deployments are expected to remain usable until the next hardfork, Karst, when chain operators will need to migrate to kona-client. Optimism will handle the onchain prestate updates for managed chains.

​
Resources