From 3203b6eaeaf1873cc246973ef19fa7cae42da367 Mon Sep 17 00:00:00 2001 From: Paul Lange Date: Wed, 8 Apr 2026 12:12:15 +0200 Subject: [PATCH 1/3] notices: op-geth deprecation --- docs.json | 1 + .../notices/op-geth-deprecation.mdx | 35 +++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 infra-partners/notices/op-geth-deprecation.mdx diff --git a/docs.json b/docs.json index 7bfbc7d56..2f5a8da8d 100644 --- a/docs.json +++ b/docs.json @@ -407,6 +407,7 @@ { "group": "Notices", "pages": [ + "infra-partners/notices/op-geth-deprecation", "infra-partners/notices/req-resp-cl-sync-deprecation", "infra-partners/notices/jovian-upgrade", "infra-partners/notices/jello-upgrade", diff --git a/infra-partners/notices/op-geth-deprecation.mdx b/infra-partners/notices/op-geth-deprecation.mdx new file mode 100644 index 000000000..3ee74fd31 --- /dev/null +++ b/infra-partners/notices/op-geth-deprecation.mdx @@ -0,0 +1,35 @@ +--- +title: "op-geth Deprecation" +--- + +This page outlines the deprecation of `op-geth` in favor of `op-reth` as the execution client for Celo, and what node operators, RPC users, and bridge operators need to know. + + +`op-geth` will not support the L1 Glamsterdam hardfork. Node operators must migrate to `op-reth` before the Ethereum Glamsterdam hardfork to maintain compatibility with the canonical chain. We will update this notice with specific dates once the Glamsterdam timeline is confirmed. + + +## What is changing? + +Following [Optimism's deprecation of op-geth](https://docs.optimism.io/notices/op-geth-deprecation), Celo is ending support for `op-geth` as an execution client. The replacement is `op-reth`, which is built on [Reth](https://github.com/paradigmxyz/reth). + +- **`op-geth`**: Will be supported until the Ethereum Glamsterdam hardfork, after which it will no longer be compatible with the canonical chain. +- **`op-reth`**: The new supported execution client going forward. +- **`op-node`**: Not affected by this change and continues to be supported as before. + +## For Node Operators + +Node operators must migrate from `op-geth` to `op-reth` before the Ethereum Glamsterdam hardfork. + +A Celo-compatible `op-reth` release will be available as soon as possible. A detailed migration guide will be provided alongside the release. In the meantime, we recommend: + +1. Familiarize yourself with [op-reth](https://reth.rs/) and its configuration. +2. Begin planning your migration timeline. +3. Watch this page and the [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) repository for updates on Celo-specific releases and migration instructions. + +## For RPC Users and Bridge Operators + +The transition from `op-geth` to `op-reth` should be transparent for RPC consumers, as `op-reth` implements the same JSON-RPC API. However, there may be minor differences in behavior for some non-standard or debug RPC methods. We recommend testing your integration against an `op-reth` node once migration tooling is available. + +## Getting Help + +Please reach out to our team on [Discord](https://chat.celo.org) if you have any questions. From d3ad4c869e5e8aefec0e95de2711c15681e31d86 Mon Sep 17 00:00:00 2001 From: Paul Lange Date: Tue, 5 May 2026 11:35:47 +0200 Subject: [PATCH 2/3] notices: update op-geth deprecation with upstream changes --- .../notices/op-geth-deprecation.mdx | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/infra-partners/notices/op-geth-deprecation.mdx b/infra-partners/notices/op-geth-deprecation.mdx index 3ee74fd31..2afb15c52 100644 --- a/infra-partners/notices/op-geth-deprecation.mdx +++ b/infra-partners/notices/op-geth-deprecation.mdx @@ -5,31 +5,28 @@ title: "op-geth Deprecation" This page outlines the deprecation of `op-geth` in favor of `op-reth` as the execution client for Celo, and what node operators, RPC users, and bridge operators need to know. -`op-geth` will not support the L1 Glamsterdam hardfork. Node operators must migrate to `op-reth` before the Ethereum Glamsterdam hardfork to maintain compatibility with the canonical chain. We will update this notice with specific dates once the Glamsterdam timeline is confirmed. +`op-geth` will not support the L1 Glamsterdam hardfork. Celo will support `op-geth` until the Glamsterdam Ethereum hardfork, with security patches and critical bug fixes issued during that window. Node operators must migrate to `op-reth` before Glamsterdam to maintain compatibility with the canonical chain. ## What is changing? Following [Optimism's deprecation of op-geth](https://docs.optimism.io/notices/op-geth-deprecation), Celo is ending support for `op-geth` as an execution client. The replacement is `op-reth`, which is built on [Reth](https://github.com/paradigmxyz/reth). -- **`op-geth`**: Will be supported until the Ethereum Glamsterdam hardfork, after which it will no longer be compatible with the canonical chain. -- **`op-reth`**: The new supported execution client going forward. +- **`op-geth`**: Supported until the Glamsterdam Ethereum hardfork (security patches and critical bug fixes only), after which support ends. It will not support the L1 Glamsterdam hardfork. +- **`op-reth`**: The new supported execution client going forward. New feature development will happen on `op-reth` only. - **`op-node`**: Not affected by this change and continues to be supported as before. ## For Node Operators -Node operators must migrate from `op-geth` to `op-reth` before the Ethereum Glamsterdam hardfork. +Node operators must migrate from `op-geth` to `op-reth` before the Glamsterdam Ethereum hardfork. -A Celo-compatible `op-reth` release will be available as soon as possible. A detailed migration guide will be provided alongside the release. In the meantime, we recommend: +A Celo-compatible `op-reth` release for testnet will be available in June, with Mainnet release details to follow later. A detailed migration guide will be provided alongside the release. In the meantime, we recommend: 1. Familiarize yourself with [op-reth](https://reth.rs/) and its configuration. 2. Begin planning your migration timeline. -3. Watch this page and the [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) repository for updates on Celo-specific releases and migration instructions. +3. Once a Celo-compatible release is available, sync an `op-reth` node alongside your existing `op-geth` node and validate sync correctness over a meaningful window — compare block hashes, state roots, and RPC outputs before migrating production traffic. +4. Watch this page and the [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) repository for updates on Celo-specific releases and migration instructions. ## For RPC Users and Bridge Operators -The transition from `op-geth` to `op-reth` should be transparent for RPC consumers, as `op-reth` implements the same JSON-RPC API. However, there may be minor differences in behavior for some non-standard or debug RPC methods. We recommend testing your integration against an `op-reth` node once migration tooling is available. - -## Getting Help - -Please reach out to our team on [Discord](https://chat.celo.org) if you have any questions. +The transition from `op-geth` to `op-reth` should be transparent for RPC consumers, as `op-reth` implements the same JSON-RPC API. However, there may be minor differences in behavior for some non-standard or debug RPC methods. We recommend testing your integration against an `op-reth` node once migration tooling is available, and comparing RPC outputs against your current `op-geth` node before cutover. From 5a35cc480ff9ebb563c04f42d897ea27f3195dbb Mon Sep 17 00:00:00 2001 From: Paul Lange Date: Tue, 5 May 2026 14:22:13 +0200 Subject: [PATCH 3/3] review --- .../notices/op-geth-deprecation.mdx | 37 ++++++++++--------- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/infra-partners/notices/op-geth-deprecation.mdx b/infra-partners/notices/op-geth-deprecation.mdx index 2afb15c52..20aabbcc2 100644 --- a/infra-partners/notices/op-geth-deprecation.mdx +++ b/infra-partners/notices/op-geth-deprecation.mdx @@ -2,31 +2,32 @@ title: "op-geth Deprecation" --- -This page outlines the deprecation of `op-geth` in favor of `op-reth` as the execution client for Celo, and what node operators, RPC users, and bridge operators need to know. +This notice outlines the deprecation of `op-geth` and the transition to `op-reth` as the supported execution client for Celo. It includes key information for node operators, RPC providers, and bridge operators. - -`op-geth` will not support the L1 Glamsterdam hardfork. Celo will support `op-geth` until the Glamsterdam Ethereum hardfork, with security patches and critical bug fixes issued during that window. Node operators must migrate to `op-reth` before Glamsterdam to maintain compatibility with the canonical chain. - +`op-geth` will not support the upcoming Ethereum Glamsterdam hardfork. All node operators must migrate to `op-reth` before this upgrade to remain in sync with the canonical chain. -## What is changing? +We will share exact dates once the Ethereum Glamsterdam timeline is finalized. -Following [Optimism's deprecation of op-geth](https://docs.optimism.io/notices/op-geth-deprecation), Celo is ending support for `op-geth` as an execution client. The replacement is `op-reth`, which is built on [Reth](https://github.com/paradigmxyz/reth). +## Summary Of Changes -- **`op-geth`**: Supported until the Glamsterdam Ethereum hardfork (security patches and critical bug fixes only), after which support ends. It will not support the L1 Glamsterdam hardfork. -- **`op-reth`**: The new supported execution client going forward. New feature development will happen on `op-reth` only. -- **`op-node`**: Not affected by this change and continues to be supported as before. +Following [Optimism's](https://docs.optimism.io/notices/op-geth-deprecation) deprecation of op-geth, Celo will also discontinue support for `op-geth` and adopt `op-reth` as the primary execution client. -## For Node Operators +- **`op-geth`**: Supported only until the Ethereum Glamsterdam hardfork. After this, it will no longer be compatible with the network. +- **`op-reth`**: The new supported execution client built on `reth`. +- **`op-node`**: No changes. It remains fully supported. -Node operators must migrate from `op-geth` to `op-reth` before the Glamsterdam Ethereum hardfork. +## Requirements for Node Operators -A Celo-compatible `op-reth` release for testnet will be available in June, with Mainnet release details to follow later. A detailed migration guide will be provided alongside the release. In the meantime, we recommend: +Node operators must complete migration to `op-reth` before the Ethereum Glamsterdam hardfork. -1. Familiarize yourself with [op-reth](https://reth.rs/) and its configuration. -2. Begin planning your migration timeline. -3. Once a Celo-compatible release is available, sync an `op-reth` node alongside your existing `op-geth` node and validate sync correctness over a meaningful window — compare block hashes, state roots, and RPC outputs before migrating production traffic. -4. Watch this page and the [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) repository for updates on Celo-specific releases and migration instructions. +A Celo-compatible `op-reth` release and migration guide will be published shortly. In the meantime: -## For RPC Users and Bridge Operators +- Review `op-reth` and its configuration. +- Begin planning your migration timeline +- Monitor updates in the [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) repository and this page for release details and instructions. -The transition from `op-geth` to `op-reth` should be transparent for RPC consumers, as `op-reth` implements the same JSON-RPC API. However, there may be minor differences in behavior for some non-standard or debug RPC methods. We recommend testing your integration against an `op-reth` node once migration tooling is available, and comparing RPC outputs against your current `op-geth` node before cutover. +## RPC Providers and Bridge Operators + +For most RPC users, this transition should be seamless. `op-reth` supports the same JSON-RPC interface as `op-geth`. + +However, some differences may exist in non-standard or debug RPC methods. We recommend validating your integrations against `op-reth` once test environments are available.