Skip to main content
This page lists common troubleshooting scenarios and solutions for node operators.

​
401 Unauthorized: Signature Invalid

If you see a log that looks like this in op-node: 
WARN [12-13|15:53:20.263] Derivation process temporary error       attempts=80 err="stage 0 failed resetting: temp: failed to find the L2 Heads to start from: failed to fetch current L2 forkchoice state: failed to find the finalized L2 block: failed to determine L2BlockRef of finalized, could not get payload: 401 Unauthorized: signature is invalid
It means that the op-node is unable to authenticate with execution client’s authenticated RPC using the JWT secret.

​
Solution

  1. Check that the JWT secret is correct in both services.
  2. Check that execution client’s authenticated RPC is enabled, and that the URL is correct.

​
Failed to Load P2P Config

If you see a log that looks like this in op-node: 
CRIT [12-13|13:46:21.386] Application failed                       message="failed to load p2p config: failed to load p2p discovery options: failed to open discovery db: mkdir /p2p: permission denied"
It means that the op-node lacks write access to the P2P discovery or peerstore directories.

​
Solution

  1. Make sure that the op-node has write access to the P2P directory. By default, this is /p2p.
  2. Set the P2P directory to somewhere the op-node can access via the --p2p.discovery.path and --p2p.peerstore.path parameters.
  3. Set the discovery path to memory to disable persistence via the --p2p.discovery.path and --p2p.peerstore.path parameters.

​
Wrong Chain

If you see a log that looks like this in op-node: 
{"attempts":183,"err":"stage 0 failed resetting: temp: failed to find the L2 Heads to start from: wrong chain L1: genesis: 0x4104895a540d87127ff11eef0d51d8f63ce00a6fc211db751a45a4b3a61a9c83:8106656, got 0x12e2c18a3ac50f74d3dd3c0ed7cb751cc924c2985de3dfed44080e683954f1dd:8106656","lvl":"warn","msg":"Derivation process temporary error","t":"2022-12-13T23:31:37.855253213Z"}
It means that the op-node is pointing to the wrong chain.

​
Solution

  1. Verify that the op-node’s L1 URL is pointing to the correct L1 for the given network.
  2. Verify that the op-node’s rollup config/--network parameter is set to the correct network.
  3. Verify that the op-node’s L2 URL is pointing to the correct instance of execution client, and that execution client is properly initialized for the given network.

​
Error: eth_sendRawTransaction Does Not Exist

If an RPC call to your execution client (op-reth, Nethermind, etc.) returns a response like: 
{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method eth_sendRawTransaction does not exist/is not available"
  }
}
This -32601 JSON-RPC error means the sequencer endpoint you configured does not expose eth_sendRawTransaction. The request path looks like: 
Client → eth_sendRawTransaction → execution client:8545
                                ↓
                  EL forwards to sequencer (--rollup.sequencer URL)
                                ↓
              eth_sendRawTransaction → op-node:8547
                                ↓
              ❌ ERROR: "method does not exist/is not available"
                 (op-node has no eth namespace!)
Because op-node only exposes rollup-specific RPC methods—there is no eth_* namespace—it cannot accept raw transaction submissions. When your execution client forwards the transaction to an op-node URL it immediately fails with -32601. This situation almost always happens when op-reth’s --rollup.sequencer (aliases --rollup.sequencer-http, --rollup.sequencer-ws) is misconfigured to point at your own op-node rather than the chain’s actual sequencer.

​
Solution

  1. Confirm op-reth exposes the eth namespace on its HTTP API (the standard set is --http.api=eth,net,web3,debug). If eth is disabled, raw transactions will be rejected before they reach the sequencer.
  2. Inspect the CLI flags and environment variables of every component that talks to the sequencer (op-node, op-reth, op-batcher, op-proposer, scripts). The --rollup.sequencer flag must point to the chain’s public sequencer endpoint (for example, https://mainnet-sequencer.optimism.io), not to your own op-node.
  3. For user-deployed L2s where you run the sequencer yourself, leave --rollup.sequencer unset so op-reth forwards locally and never falls back to an op-node endpoint.
  4. Restart the affected services after correcting the flag so they pick up the new endpoint. The error should disappear as soon as they can reach the proper sequencer RPC.

​
Unclean Shutdowns

An unclean shutdown occurs when the execution client stops without completing its normal shutdown procedure — for example, a SIGKILL, a power loss, or a container killed past its grace period. The impact depends on which database backend your EL uses. To minimize risk, always shut down gracefully: Ctrl-C for foreground processes, docker stop -t 300 <container> for Docker, or systemctl stop for systemd (override the default 90s timeout if your EL has a large in-memory write to flush).

​
For op-reth

op-reth uses MDBX, which is crash-safe by design. After an unclean shutdown the node typically restarts cleanly with no operator intervention required. If startup fails after an unclean shutdown, options include:
  • Stage unwind — roll back to the last consistent stage checkpoint: 
    op-reth stage unwind to-block <BLOCK_NUMBER> --datadir=<path>
  • Full resync — as a last resort, delete the datadir and resync from genesis or a snapshot.

​
For Nethermind

Unclean shutdowns in Nethermind can lead to database corruption. This typically happens when:
  • The node experiences hardware failures (disk failures, memory errors, overheating)
  • Power cuts cause abrupt shutdowns
  • The process is terminated without proper cleanup
Solutions
  1. Lock File Issues If Nethermind complains about lock files after an unclean shutdown, run: 
    find /path/to/nethermind_db -type f -name 'LOCK' -delete
  2. Block Checksum Mismatch If you encounter block checksum mismatch errors, you can enable direct I/O: 
    --Db.UseDirectIoForFlushAndCompactions true
    Note: This may impact performance.
  3. Complete Resync In cases of severe corruption, a full resync is recommended: 
    sudo systemctl stop nethermind
sudo rm -rf /path/to/nethermind_db/mainnet
sudo systemctl start nethermind