celo-org · palango · Jun 22, 2026 · Jun 19, 2026 · Jun 19, 2026 · Jun 19, 2026
@@ -16,22 +16,23 @@ Celo is switching its execution client from `op-geth` to `op-reth`. All node ope
 
 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.
 
-- **`op-geth`**: Supported only until the switch date for each network. After that, it will no longer be compatible with the network.
+- **`op-geth`**: Supported only until the switch date for each network. After that, it might follow the wrong chain.
 - **`op-reth`**: The new supported execution client built on `reth`.
 - **`op-node`**: No changes. It remains fully supported.
 
 ## Requirements for Node Operators
 
 Node operators must complete migration to `op-reth` by the switch date for their network (see above).
 
-A Celo-compatible `op-reth` release and migration guide will be published shortly. In the meantime:
+A Celo-compatible `op-reth` release is available, and the node-operator guides now use it:
 
-- 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.
+- Follow [Run a node with Docker](/infra-partners/operators/run-node) to run `op-reth`. A new node starts from an empty datadir — bootstrap it from a published snapshot (`OP_RETH__SNAPSHOT=true`, required on mainnet) or, on Celo Sepolia, sync from genesis; no L1 data migration is required.
+- A migrated `op-geth` datadir cannot be reused — `op-reth` uses a different on-disk format. Start `op-reth` with an empty `DATADIR_PATH`.
+- For archive nodes and pre-L2 historical state, see [Running an archive node](/infra-partners/operators/archive-node).
+- See the [Configuration reference](/infra-partners/operators/configuration) for the `OP_RETH__*` variables, and the [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) repository for the latest images.
 
 ## 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.
+However, some differences may exist in non-standard or debug RPC methods. We recommend validating your integrations against `op-reth` on Celo Sepolia, which switches first (see the dates above).
@@ -11,7 +11,7 @@ The Rollup Node is responsible for deriving L2 block payloads from L1 data and p
 
 ## Execution client
 
-The Execution Client is responsible for executing the block payloads it receives from the Rollup Node over JSON-RPC via the standard [Ethereum Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md#engine-api----common-definitions). The Execution Client exposes the standard JSON-RPC API that Ethereum developers are familiar with, and can be used to query blockchain data and submit transactions to the network. The Execution Client is largely analogous to an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) in Ethereum.
+The Execution Client is responsible for executing the block payloads it receives from the Rollup Node over JSON-RPC via the standard [Ethereum Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md#engine-api----common-definitions). The Execution Client exposes the standard JSON-RPC API that Ethereum developers are familiar with, and can be used to query blockchain data and submit transactions to the network. The Execution Client is largely analogous to an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) in Ethereum. On Celo this is `op-reth`; `op-geth` is supported until your network's [switch date](/infra-partners/notices/op-geth-deprecation).
 
 ## Next steps
 

@@ -9,11 +9,11 @@ sidebarTitle: "Run an Archive Node"
 This guide covers running a **full archive node**, which serves every historical-state RPC call (such as `eth_getBalance` or `eth_call`) at any block and requires terabytes of storage. Celo also supports a narrower **historical proofs** feature for serving historical data without keeping full archive state; a dedicated guide for it is forthcoming.
 </Info>
 
-<Warning>
-**op-geth is being deprecated**
+<Info>
+**Execution client: op-reth**
 
-These instructions use `op-geth`, which is supported only until your network's switch to `op-reth`. Celo is transitioning to `op-reth` as the primary execution client. See [End of Support for op-geth](/infra-partners/notices/op-geth-deprecation) for the switch dates; archive-node guidance for `op-reth` will follow once a Celo-compatible release is published.
-</Warning>
+These instructions use `op-reth`, Celo's primary execution client. `op-geth` is supported until your network's switch date — see the **Still running op-geth?** notes at the end of this guide and [End of Support for op-geth](/infra-partners/notices/op-geth-deprecation).
+</Info>
 
 ## Overview
 
@@ -24,12 +24,12 @@ To run an L2 archive node, you need to start the L2 execution client in archive
 <Info>
 **Prerequisites**
 
-These instructions assume you already have
+An L2 archive node starts from an empty datadir, like a full node — no migrated L1 data is required. To serve pre-L2 historical state, you additionally need one of:
 
-1. A migrated full node datadir that has been synced to the migration block. See [Migrating an L1 Node](/infra-partners/operators/migrate-node) if you do not have this.
-2. A non-migrated Celo L1 archive node datadir. Do not attempt to migrate an archive datadir.
+1. A non-migrated Celo L1 archive node datadir (the compose setup runs a legacy archive node from it). Do not attempt to migrate an archive datadir.
+2. The RPC endpoint of a running legacy Celo L1 archive node.
 
-Please ensure neither datadir is being used by a running node before proceeding.
+Ensure any datadir you supply is not in use by a running node before proceeding.
 </Info>
 
 1. Pull the latest version of [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) and `cd` into the root of the project.
@@ -50,25 +50,24 @@ Please ensure neither datadir is being used by a running node before proceeding.
     cp $NETWORK.env .env
     ```
 
-    #### Configure sync mode
-
-    By default, [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) will start your node with `snap` sync. While `archive` nodes can technically run with `snap` sync, they will only store archive data from the point that `snap` sync completes. This will leave a gap in the archive data after the hardfork, so we recommend running archive nodes with `full` sync and a migrated pre-hardfork datadir.
+    #### Configure node type
 
-    To use `full` sync, configure `.env` as follows:
+    To enable `archive` mode, configure `.env` as follows:
 
     ```text
-    OP_GETH__SYNCMODE=full
-    DATADIR_PATH=<path to a migrated L1 full node datadir>
+    NODE_TYPE=archive
     ```
 
-    #### Configure node type
+    #### Bootstrap your datadir
 
-    To enable `archive` mode, configure `.env` as follows:
+    An archive node starts from an **empty** datadir and keeps the full historical state. Bootstrap it from a published snapshot:
 
     ```text
-    NODE_TYPE=archive
+    OP_RETH__SNAPSHOT=true
     ```
 
+    On first start this downloads the snapshot matching your `NODE_TYPE` (here, the archive snapshot) and continues from there. **On mainnet a snapshot is required** — it provides the pre-L2 (Celo L1) history. On **Celo Sepolia**, which has no pre-L2 history, you can instead leave `OP_RETH__SNAPSHOT=false` and execute every block from genesis. Either way, `NODE_TYPE=archive` is what keeps the full historical state available, and `DATADIR_PATH` must be empty on first start — a datadir written by `op-geth` cannot be reused.
+
     #### Configure Historical RPC Service
 
     To handle RPC requests for pre-hardfork state and execution, an L2 archive node proxies to a legacy archive node or "Historical RPC Service".
@@ -85,7 +84,7 @@ Please ensure neither datadir is being used by a running node before proceeding.
     2. Start the legacy archive node yourself and configure `.env` as follows:
 
         ```text
-        OP_GETH__HISTORICAL_RPC=<RPC endpoint of a running legacy archive node>
+        OP_RETH__HISTORICAL_RPC=<RPC endpoint of a running legacy archive node>
         ```
 
         This will cause any value you set for `HISTORICAL_RPC_DATADIR_PATH` to be ignored. The tool will not start a legacy archive node when it starts your L2 archive node.
@@ -100,37 +99,52 @@ Please ensure neither datadir is being used by a running node before proceeding.
         If the following options are not configured correctly, your node will not be discoverable or reachable to other nodes on the network. This is likely to impair your node's ability to stay reliably connected to and synced with the network.
     </Warning>
 
-    - `OP_NODE__P2P_ADVERTISE_IP` - Specifies the public IP to be shared via  discovery so that other nodes can connect to your node. If unset op-node other nodes on the network will not be able to discover and connect to your node.
+    - `OP_NODE__P2P_ADVERTISE_IP` - Specifies the public IP to be shared via discovery so that other nodes can connect to your node. If unset, other nodes on the network will not be able to discover and connect to your op-node.
     - `PORT__OP_NODE_P2P` - Specifies the port to be shared via discovery so that other nodes can connect to your node. Defaults to 9222.
-    - `OP_GETH__NAT` - Controls how op-geth determines its public IP that is shared via the discovery mechanism. If the public IP is not correctly configured then other nodes on the network will not be able to discover and connect to your node. The default value of `any` will try to automatically determine the public IP, but the most reliable approach is to explicitly set the public IP using `extip:<your-public-ip>`. Other acceptable values are `(any|none|upnp|pmp|pmp:<IP>|extip:<IP>|stun:<IP:PORT>)`.
-    - `PORT__OP_GETH_P2P` - Specifies the port to be shared via discovery so that other nodes can connect to your node. Defaults to 30303.
+    - `OP_RETH__NAT` - Controls how op-reth determines its public IP that is shared via the discovery mechanism. If the public IP is not correctly configured then other nodes on the network will not be able to discover and connect to your node. The default value of `any` will try to automatically determine the public IP, but the most reliable approach is to explicitly set the public IP using `extip:<your-public-ip>`. Other acceptable values are `(any|none|upnp|publicip|extip:<IP>|stun:<IP:PORT>)`.
+    - `PORT__OP_RETH_P2P` - Specifies the port to be shared via discovery so that other nodes can connect to your node. Defaults to 30303.
 
 3. Start the node(s).
 
     ```bash
-    docker-compose up -d --build
+    docker compose up -d --build
     ```
 
 4. Check the progress of your L2 archive node as it syncs.
 
     ```bash
-    docker-compose logs -n 50 -f op-geth
+    docker compose logs -n 50 -f op-reth
     ```
 
-    This will display and follow the last 50 lines of logs. In a syncing node, you would expect to see `Syncing beacon headers  downloaded=...` where the downloaded number is increasing and later lines such as `"Syncing: chain download in progress","synced":"21.07%"` where the percentage is increasing. Once the percentage reaches 100%, the node should be synced.
+    This will display and follow the last 50 lines of logs. As the node syncs you will see `op-reth` executing blocks and its head advancing toward the network's latest block.
 
 5. Check that node is fully synced.
 
-   Once the node is fully synced, you can validate that it's following the network by fetching the current block number via the RPC API and seeing that it's increasing as expected.
+   You can validate that your node is following the network by fetching the current block number via the RPC API and seeing that it climbs as the node syncs and then tracks the network's latest block.
 
    ```bash
    cast block-number --rpc-url http://localhost:9993
    ```
 
-   Note that until fully synced, the RPC API will return 0 for the head block number.
-
 6. Try querying historical state to test archive functionality.
 
    ```bash
    cast balance --block <pre-migration-block-number> <address> --rpc-url http://localhost:9993
    ```
+
+<Accordion title="Still running op-geth? (until your switch date)">
+
+Until your network's [switch date](/infra-partners/notices/op-geth-deprecation), you can keep running an `op-geth` archive node from an existing checkout of [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose). The flow above is the same, with these differences:
+
+- **Sync mode instead of a snapshot.** `op-geth` archive nodes should run `full` sync against a migrated pre-hardfork datadir — `snap` sync only stores archive data from the point it completes, leaving a gap after the hardfork:
+
+    ```text
+    OP_GETH__SYNCMODE=full
+    DATADIR_PATH=<path to a migrated L1 full node datadir>
+    ```
+
+- **Historical RPC variable.** Use `OP_GETH__HISTORICAL_RPC` in place of `OP_RETH__HISTORICAL_RPC`.
+- **P2P variables.** Use `OP_GETH__NAT` (values `any|none|upnp|pmp|pmp:<IP>|extip:<IP>|stun:<IP:PORT>`) and `PORT__OP_GETH_P2P` (default `30303`).
+- **Logs.** Follow `docker compose logs -n 50 -f op-geth`; a syncing node shows `Syncing beacon headers downloaded=...` and later `"Syncing: chain download in progress","synced":"21.07%"`.
+
+</Accordion>