ethereum-optimism · bradleycamacho · Jul 25, 2025 · Mar 31, 2025 · Mar 31, 2025 · Mar 31, 2025
@@ -276,4 +276,4 @@ export function ChainParametersForm(): ReactElement {
       {!isLoading && showResult && <ResultsTable data={resultsParams} />}
     </div>
   );
-}
+}
@@ -20,12 +20,12 @@ is_imported_content: 'false'
 
 # Node architecture
 
-This page reviews node architecture for  all nodes running on the Superchain network. All OP Mainnet nodes are composed of two core software services, the Rollup Node and the Execution Client.
+This page reviews node architecture for all nodes running on the Superchain network. All OP Mainnet nodes are composed of two core software services, the Rollup Node and the Execution Client.
 OP Mainnet also optionally supports a third component, Legacy Geth, that can serve stateful queries for blocks and transactions created before the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/).
 
 ## Node flow diagram
 The following diagram shows how the Rollup Node, Execution Client, and Legacy Geth components work together to form a complete node running on the Superchain network.
-This diagram uses the `op-node` and `op-geth` implementations of the Rollup Node and Execution Client respectively, but the same architecture generally applies to other implementations as well.
+This diagram uses the `op-node` implementation of the Rollup Node and shows the general architecture that applies to all execution client implementations.
 
 ![OP Mainnet node architecture diagram.](/img/guides/node-operators/node-arch.svg)
 
@@ -39,6 +39,16 @@ The Execution Client is responsible for executing the block payloads it receives
 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 OP Stack supports multiple execution client implementations:
+
+### op-geth
+
+`op-geth` is the original execution client for the OP Stack, based on the Go Ethereum (Geth) implementation. It has been modified to support the specific requirements of OP Stack chains.
+
+### Nethermind
+
+Nethermind is a high-performance execution client implementation written in C#. The `Nethermind` client has been adapted to support OP Stack chains, providing an alternative execution client option for node operators.
+
 ## Legacy Geth
 
 OP Mainnet underwent a large database migration as part of the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/) in 2023.
@@ -51,6 +61,6 @@ Legacy Geth is **not** required and is typically only necessary if you want to m
 
 ## Next steps
 
-*   To get your node up and running, start with the [run a node from docker](/operators/node-operators/tutorials/node-from-docker) or [build a node from source](/operators/node-operators/tutorials/node-from-source) tutorial.
+*   To get your node up and running, start with the [run a node from docker](/operators/node-operators/tutorials/node-from-docker) or [build a node from source](/operators/node-operators/tutorials/node-from-source) tutorial. These guides include instructions for both `op-geth` and `Nethermind` execution clients.
 *   If you've already got your node up and running, check out the [Node Metrics and Monitoring Guide](./management/metrics) to learn how to keep tabs on your node and make sure it keeps running smoothly.
 *   If you run into any problems, please visit the [Node Troubleshooting Guide](./management/troubleshooting) for help.
@@ -31,5 +31,5 @@ This section provides information on node base configuration, consensus layer co
 
   <Card title="Consensus layer configuration options (op Node)" href="/operators/node-operators/configuration/consensus-config" />
 
-  <Card title="Execution layer configuration options (op Geth)" href="/operators/node-operators/configuration/execution-config" />
+  <Card title="Execution layer configuration options" href="/operators/node-operators/configuration/execution-config" />
 </Cards>
@@ -1,7 +1,7 @@
 ---
 title: Node base configuration
 lang: en-US
-description: Learn the node base configuration and recommended flags for op-node, op-geth, and legacy geth.
+description: Learn the node base configuration and recommended flags for `op-node`, `op-geth`, and legacy geth.
 content_type: guide
 topic: node-base-configuration
 personas:
@@ -16,22 +16,26 @@ categories:
 is_imported_content: 'false'
 ---
 
-import { Callout } from 'nextra/components'
+import { Callout, Tabs } from 'nextra/components'
 
 # Node base configuration
 
 <Callout type="warning">
-  Always run `op-node` and `op-geth` in a one-to-one configuration. Don't run multiple `op-geth` instances behind one `op-node`, or vice versa.
+  Always run `op-node` and your execution client (`op-geth` or `nethermind`) in a one-to-one configuration. Don't run multiple execution client instances behind one `op-node`, or vice versa.
 </Callout>
 
 To configure your node, you will need to do the following:
 
-1.  Configure `op-node` to point to the correct L1, `op-geth`, and L2 network.
-2.  Initialize `op-geth` with the correct network parameters.
-3.  Configure `op-geth` to properly communicate with the Rollup Node.
+1.  Configure `op-node` to point to the correct L1, execution client, and L2 network.
+2.  Initialize your execution client (`op-geth` or `nethermind`) with the correct network parameters.
+3.  Configure your execution client to properly communicate with the Rollup Node.
 4.  Optionally, configure Legacy Geth.
 
-## Configuring `op-geth`
+## Configuring Your execution client
+
+You can choose between two execution clients for your OP Stack rollup node: `op-geth` or `nethermind`. Each has its own configuration requirements and recommended settings.
+
+### Configuring `op-geth`
 
 <Callout type="info">
   Although the Docker image for the Execution Engine is called `op-geth`, the actual binary is still called `geth` in order to minimize differences between `op-geth` and `go-ethereum`. You can see the difference [here](https://op-geth.optimism.io/?utm_source=op-docs&utm_medium=docs).
@@ -146,6 +150,22 @@ geth \
 
 Consult [Geth's documentation](https://geth.ethereum.org/docs/) for more information on customizing `op-geth`'s behavior.
 
+### Configuring `nethermind`
+
+Nethermind is an alternative execution client for OP Stack rollup nodes. It provides high performance and reliability while maintaining compatibility with the OP Stack protocol.
+
+#### Working base configuration for Nethermind
+
+To run `Nethermind` on the OP Mainnet, use the following command:
+
+```bash
+nethermind \
+  -c op-mainnet \
+  --data-dir path/to/data/dir \
+  --jsonrpc-jwtsecretfile path/to/jwt.hex
+```
+Consult [`Nethermind`'s documentation](https://docs.nethermind.io/fundamentals/configuration) for more detailed configuration options.
+
 ## Configuring `op-node`
 
 `op-node` is a standalone, statically linked binary. It stores no state, and requires no initialization. It consumes configuration parameters either via the command line or environment variables. For some networks, the Rollup Node also requires a configuration file (called `rollup.json` or the "rollup config") that configures network-specific genesis parameters. For official networks like OP Sepolia and OP Mainnet, the genesis config is hardcoded in the `op-node` software and can be specified via a `--network` flag.
@@ -163,6 +183,8 @@ from a Beacon node.
 
 A minimal valid configuration that runs `op-node` looks like:
 
+<Tabs items={['op-geth', 'Nethermind']}>
+  <Tabs.Tab>
 ```bash
 op-node --l1=<ethereum mainnet RPC url> \
         --l2=<op-geth authenticated RPC url> \
@@ -174,6 +196,21 @@ op-node --l1=<ethereum mainnet RPC url> \
         --syncmode=execution-layer \
         --l2.enginekind=geth
 ```
+  </Tabs.Tab>
+  <Tabs.Tab>
+```bash
+op-node --l1=<ethereum mainnet RPC url> \
+        --l2=<nethermind authenticated RPC url> \
+        --network=op-mainnet \
+        --rpc.addr=127.0.0.1 \
+        --rpc.port=9545 \
+        --l2.jwt-secret=<path to JWT secret> \
+        --l1.beacon=<http endpoint address of L1 Beacon-node> \
+        --syncmode=execution-layer \
+        --l2.enginekind=nethermind
+```
+  </Tabs.Tab>
+</Tabs>
 
 You can manually specify a path to a rollup config with the `--rollup.config` flag. This is used for testnets or internal deployments that are not migrated from a legacy network.
 
@@ -229,6 +266,6 @@ The term *historical execution* refers to RPC methods that need to execute trans
 If you do not need these RPC methods for historical data, then you do not need to run Legacy Geth at all.
 
 ## Next steps
-*   See the [op-node configuration](/operators/node-operators/configuration/consensus-config) guide for additional configuration options for `op-node` and the Consensus-Layer.
-*   Similarly, visit the [op-geth configuration](/operators/node-operators/configuration/execution-config) guide for additional configuration options for `op-geth` and Execution-Layer.
+*   See the [`op-node` configuration](/operators/node-operators/configuration/consensus-config) guide for additional configuration options for `op-node` and the Consensus-Layer.
+*   For execution client configuration, visit [execution client configuration](/operators/node-operators/configuration/execution-config) for additional options when using `op-geth` or `nethermind`
 *   If you run into any problems, please reach out to our [developer support forum](https://github.com/ethereum-optimism/developers/discussions) for help.
@@ -1,7 +1,7 @@
 ---
 title: Consensus layer configuration options (op-node)
 lang: en-US
-description: Learn additional configuration and command line options for op-node and the Consensus-Layer.
+description: Learn additional configuration and command line options for `op-node` and the Consensus-Layer.
 content_type: reference
 topic: consensus-layer-configuration
 personas:
@@ -20,7 +20,7 @@ is_imported_content: 'false'
 import { Callout } from 'nextra/components'
 import { Tabs } from 'nextra/components'
 
-# Consensus layer configuration options (op-node)
+# Consensus layer configuration options (`op-node`)
 
 <Callout type="info">
   You can configure your node using the command line options below (also called flags).
@@ -94,7 +94,7 @@ If true, all sidecars are fetched and filtered locally. Workaround for buggy Bea
 
 ### l1.beacon.ignore
 
-When false, halts op-node startup if the healthcheck to the Beacon-node endpoint fails. The default value is `false`.
+When false, halts `op-node` startup if the healthcheck to the Beacon-node endpoint fails. The default value is `false`.
 
 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>
   <Tabs.Tab>`--l1.beacon.ignore=<boolean>`</Tabs.Tab>
@@ -154,7 +154,7 @@ Optional self-imposed global rate-limit on L1 RPC requests, specified in request
 
 ### l1.rpckind
 
-The kind of RPC provider, used to inform optimal transactions receipts fetching, and thus reduce costs. Valid options: alchemy, quicknode, infura, parity, nethermind, debug\_geth, erigon, basic, any, standard. The default value is `standard`.
+The kind of RPC provider, used to inform optimal transactions receipts fetching, and thus reduce costs. Valid options: alchemy, quicknode, infura, parity, `nethermind`, debug\_geth, erigon, basic, any, standard. The default value is `standard`.
 
 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>
   <Tabs.Tab>`--l1.rpckind=<value>`</Tabs.Tab>
@@ -277,7 +277,7 @@ are as follows:
     low-level system operations. This level generates a large amount of log data and is
     typically used only for in-depth troubleshooting.
 
-To set the log level, use the `--log.level` flag when running the op-node command. For
+To set the log level, use the `--log.level` flag when running the `op-node` command. For
 example, to set the log level to debug:
 
 ```bash

@@ -1004,10 +1004,24 @@ Sample success output:
 todo: add Sample success output
 ```
 
-## op-geth
+## Execution clients
 
+The OP Stack supports multiple execution client implementations. Each client implements the execution layer with minimal changes for a secure Ethereum-equivalent application environment.
 
-`op-geth` implements the Execution-Layer, with minimal changes for a secure Ethereum-equivalent application environment.
+<Tabs items={['op-geth', 'Nethermind']}>
+  <Tabs.Tab>
+    ### op-geth
+
+    `op-geth` is the original execution client for the OP Stack, based on the Go Ethereum (Geth) implementation.
+
+    The execution engine's RPC interface is identical to [the upstream Geth RPC interface](https://geth.ethereum.org/docs/interacting-with-geth/rpc). The responses are nearly identical too, except we also include the L1 gas usage and price information.
+  </Tabs.Tab>
+  <Tabs.Tab>
+    ### Nethermind
 
-The execution engine's RPC interface is identical to [the upstream Geth RPC interface](https://geth.ethereum.org/docs/interacting-with-geth/rpc). The responses are nearly identical too, except we also include the L1 gas usage and price information.
+    `Nethermind` is a high-performance execution client implementation written in C#. The `Nethermind` client has been adapted to support OP Stack chains, providing an alternative execution client option for node operators.
+
+    The execution engine's RPC interface is identical to [the upstream `Nethermind` RPC interface](https://docs.nethermind.io/interacting/json-rpc-server/). The responses are nearly identical too, except we also include the L1 gas usage and price information.
+  </Tabs.Tab>
+</Tabs>
 
@@ -41,16 +41,31 @@ See the [Software Releases](/operators/node-operators/releases) page for the min
 ### Configure the Ecotone activation date
 
 *   If you are operating a node for an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), 
-the Ecotone activation date is part of the `op-node` and `op-geth` nodes. So, 
-no action is needed for the sequencer after upgrading to the latest release.
-*   For node operators of custom chains not included in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), 
-the activation dates can be set in the `rollup.json` (set `ecotone_time`) or 
-set the activation time via overrides (CLI) in both `op-node` and `op-geth`. 
-These will need to be set on `op-node` and `op-geth` for the sequencer and all other nodes.
+the Ecotone activation date is handled automatically by both execution clients:
+
+<Tabs items={['op-geth', 'Nethermind']}>
+  <Tabs.Tab>
+    The activation date is part of the node configuration. No action needed after upgrading to the latest release.
+  </Tabs.Tab>
+  <Tabs.Tab>
+    The activation date is included in the built-in chain configuration. No action needed after upgrading to the latest release.
+  </Tabs.Tab>
+</Tabs>
+
+*   For node operators of custom chains not included in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json):
+
+<Tabs items={['op-geth', 'Nethermind']}>
+  <Tabs.Tab>
+    Set the activation time in `rollup.json` (`ecotone_time`) and via CLI overrides
+  </Tabs.Tab>
+  <Tabs.Tab>
+    Use the chain configuration examples in `src/Nethermind/Chains` as templates for your custom chain configuration
+  </Tabs.Tab>
+</Tabs>
 
 <Callout type="warning">
-  Even if the ecotone activation is configured via the `rollup.json`, it still 
-  needs to be configured separately on `op-geth` via command line flag.
+  When using `op-geth`, even if the ecotone activation is configured via the `rollup.json`, it still 
+  needs to be configured separately via command line flag.
 </Callout>
 
 <Tabs items={['op-node', 'op-geth']}>
-Original file line number
+Diff line change
@@ Expand Up / @@ -276,4 +276,4 @@ export function ChainParametersForm(): ReactElement { @@
           {!isLoading && showResult && <ResultsTable data={resultsParams} />}
         </div>
       );
-    }
+    }