> Feedback: If these docs are stale, missing, or confusing, post sanitized feedback to `https://docs.tempo.xyz/api/feedback` with `source: "mcp"`, a short `message`, and any relevant `toolName`, `relatedResource`, or `client`.
# Validator failover

This runbook covers a warm failover where a follower is promoted into a validator. A follower running in certified mode stores the same consensus finalization data used to bootstrap the validator.

:::danger\[Prevent double-signing]
Only one node may run with a validator signing key at a time. Before promoting the follower, fence the old validator. Do not start the replacement while the old validator can still sign.
:::

## Prepare a follower

:::::steps

### Run the follower

Use a dedicated data directory for the follower. The upstream must be a validator or RPC node that exposes the `consensus` RPCs.

Trustless RPC-to-RPC following is currently only supported on Moderato testnet. If following on Mainnet, follow against the existing validator. See more about [trustless rpc nodes](/docs/guide/node/rpc#trustless-rpc-nodes).

::::code-group

```bash [Testnet]
tempo node --datadir <datadir> \
  --chain testnet \
  --follow <WS_URL> \
  --follow.experimental.certify \
  --http --http.port 8545 \
  --http.api eth,net,web3,txpool,trace,consensus
```

```bash [Mainnet]
tempo node --datadir <datadir> \
  --chain mainnet \
  --follow <WS_URL> \
  --follow.experimental.certify \
  --http --http.port 8545 \
  --http.api eth,net,web3,txpool,trace,consensus
```

::::

Do not pass `--consensus.signing-key` while the standby is running as a follower. The standby is syncing certified consensus state, not participating in consensus.

### Verify the follower is current

Check that execution height is advancing and the certified consensus feed is available:

```bash
cast block-number --rpc-url http://localhost:8545
cast rpc consensus_getLatest --rpc-url http://localhost:8545
```

If `consensus_getLatest` is unavailable, the follower is not syncing consensus state. Confirm that the upstream endpoint is certified and exposes the `consensus` namespace.

### Keep validator networking ready

The promoted node must be reachable at the ingress and egress addresses registered onchain. A setup that allows a floating IP or load balancer address that can move from the old validator to the standby will require no onchain updates.

If failover uses a different address, update the validator's onchain IP configuration after fencing the old validator. Follow the [update IP addresses](/docs/guide/node/validator-lifecycle#update-ip-addresses) procedure.

:::::

## Promote the follower

:::::steps

### Fence the old validator

Stop the old validator or isolate it from the network before starting the replacement. If you use a floating IP, move it to the standby before validator startup.

```bash
sudo systemctl stop tempo
```

### Stop the follower process

Stop the standby follower cleanly so the same data directory can be reopened in validator mode.

```bash
sudo systemctl stop tempo-follower
```

If the follower is not managed by systemd, send `SIGINT` or `SIGTERM` and wait for the process to exit.

### Restart the standby in validator mode

Restart the same data directory without `--follow` or `--follow.experimental.certify`, and add the validator signing key.

Use the same consensus signing key as the validator you are failing over from. This procedure moves an existing validator identity to the standby; it does not rotate the identity. To use a different signing key,
the validator's onchain configuration must be rotated. Follow the [rotate the validator identity](/docs/guide/node/validator-lifecycle#rotate-validator-identity) procedure.

::::code-group

```bash [Mainnet]
tempo node --datadir <datadir> \
  --chain mainnet \
  --consensus.signing-key <PRIVATE_KEY_PATH> \
  --consensus.listen-address 0.0.0.0:<REGISTERED_INGRESS_PORT> \
  --http --http.port 8545 \
  --http.api eth,net,web3,txpool,trace,consensus \
  --telemetry-url <TELEMETRY_URL>
```

```bash [Testnet]
tempo node --datadir <datadir> \
  --chain testnet \
  --consensus.signing-key <PRIVATE_KEY_PATH> \
  --consensus.listen-address 0.0.0.0:<REGISTERED_INGRESS_PORT> \
  --http --http.port 8545 \
  --http.api eth,net,web3,txpool,trace,consensus \
  --telemetry-url <TELEMETRY_URL>
```

::::

Do not delete or resync the data directory during failover. The follower's datadir contains the necessary consensus and execution state that allows the node to restart as a validator without a fresh bootstrap.

### Verify validator participation

Check that the node's consensus RPC is live and progressing, then verify the validator status from a public RPC endpoint:

```bash
cast rpc consensus_getLatest --rpc-url http://localhost:8545
```

::::code-group

```bash [Mainnet]
tempo consensus validator <pubkey> --rpc-url https://rpc.tempo.xyz
```

```bash [Testnet]
tempo consensus validator <pubkey> --rpc-url https://rpc.testnet.tempo.xyz
```

::::

The validator should remain `in_committee: true` if it was already active. If you changed IP addresses during failover, wait for the IP update to finalize and for peer discovery to pick up the new address.

:::::

## After failover

Treat the promoted node as the active validator until you intentionally move the role again.

Use the [validator status metrics](/docs/guide/node/validator-status#checking-state-via-metrics) to confirm the promoted node is connected to peers and participating in consensus.