# Tempo validator troubleshooting and FAQ

## My node is not proposing blocks

Once your node is proposing blocks, it will start emitting logs like these:

```
INFO handle_propose{epoch=18 view=387213 parent.view=387212 parent.digest=0x43885416b4a7ae7550c615ad4dc702045cd26540b78fa2bd75abdcbfbef02d9d}: tempo_commonware_node::consensus::application::actor: constructed proposal proposal.digest=0x6baa8fa813beea491cf598024d8b31cb2927e7ba1b92a29899a795dbafd682c6 proposal.height=5733680
```

If you do not see logs like these:

* Check that your validator is part of the active set, and is both [a player and a dealer](https://tempo.xyz/developers/docs/guide/node/validator-status).
* Check that your node is synced up to the [latest block height](https://explorer.tempo.xyz/).
* Check that your outgoing IP address matches the one whitelisted on the validator smart contract:

:::code-group
```bash [Mainnet]
tempo consensus validators-info --rpc-url https://rpc.tempo.xyz
```

```bash [Testnet]
tempo consensus validators-info --rpc-url https://rpc.testnet.tempo.xyz
```
:::

## My node is not connecting to peers

If `consensus_engine_peer_manager_peers` remains at `0` for more than 3 hours after your validator was added on-chain:

* Verify your firewall allows inbound connections on the ingress port you registered.
* Verify your egress IP matches the one registered on-chain — check with `tempo consensus validator <pubkey> --rpc-url https://rpc.tempo.xyz`.
* If you have reset your validator's data without rotating to a new identity, your node may have been blocked due to double-signing. In that case, [reach out to the Tempo team](https://tempo.xyz/contact) to coordinate a new validator identity.

## My node's DKG metrics are not increasing

If `how_often_dealer` and `how_often_player` are not increasing after 6 hours:

* Confirm your node is connected to peers (see above).
* Check that your validator has progressed past the [Syncer state](https://tempo.xyz/developers/docs/guide/node/validator-status#state-transitions) — it takes at least one full epoch (~3 hours) after on-chain addition before your node participates in DKG.
* Check DKG failure count: if `consensus_engine_dkg_manager_ceremony_failures_total` is increasing, your node may be failing to complete ceremonies. Enable debug logging for more detail:
  ```bash
  RUST_LOG=info,tempo_commonware_node::dkg=debug
  ```

## My node is rejecting blocks or missing proposals

If your node logs block validation errors (e.g. "block timestamp is in the future") or you notice missed proposals, a potential root cause is **clock drift**. Check whether `parent_ahead_of_local_time` is increasing in your metrics — if so, your system clock is behind the network.

To fix:

1. **Check your current sync status:**
   ```bash
   timedatectl status
   ```
   Confirm `System clock synchronized: yes` and `NTP service: active`.

2. **Install chrony** (if not already installed):
   ```bash
   sudo apt install chrony
   sudo systemctl enable --now chronyd
   ```

3. **Verify the offset is acceptable:**
   ```bash
   chronyc tracking
   ```
   The **System time** offset should be under a few milliseconds.

4. **Restart your node** after fixing the clock to clear any cached invalid block state.

See [Time Synchronization](https://tempo.xyz/developers/docs/guide/node/system-requirements#time-synchronization) for full setup details.

## My node fails to start: finalized tip certificate failed verification against the trusted network identity

Starting with [v1.15.0](https://github.com/tempoxyz/tempo/releases/tag/v1.15.0), a validator verifies the finalization certificate of its latest finalized block before its consensus engine starts. If verification fails, the node exits with an error chain that includes `failed initializing dkg manager` and ends with:

```text
finalized tip certificate at height `<HEIGHT>` in epoch `<EPOCH>` failed verification against the trusted network identity from epoch `<FROM_EPOCH>`; configure an updated network identity if a full DKG rotation occurred while the node was offline
```

The node checks the certificate against the newest [network identity](https://tempo.xyz/developers/docs/guide/node/consensus-and-dkg) it trusts: the identity built into the binary or passed on the command line, or a newer identity from its own persisted DKG state. Verification fails when the certificate was signed under a network identity the node does not know yet, for example:

* A full DKG rotation happened while your node was offline, and your release predates the rotation.
* You started from a snapshot taken after a rotation with a release that predates the rotation.

Follow/RPC nodes do not run this startup check. Instead, they log one of these warnings when their network identity is outdated:

```text
Network identity differs from the onchain DKG outcome!!! Update the binary with the latest network identity
Network identity derived from the trusted start block differs from the configured network identity!!! Update the binary with the latest network identity
```

To fix either case, upgrade to a release that includes the current identity. [Network Upgrades and Releases](https://tempo.xyz/developers/docs/guide/node/network-upgrades#network-identities) lists the current identities and the releases that include them.

If you cannot upgrade immediately, override the built-in identity by adding both of these arguments to your existing `tempo node` command:

| Argument | Meaning |
| --- | --- |
| `--consensus.network-identity <KEY>` | The full, hex-encoded 96-byte BLS threshold public key to use instead of the built-in network identity. |
| `--consensus.network-identity-from-epoch <EPOCH>` | The first epoch for which the supplied identity is valid. |

Use the identity and epoch listed in [Network identities](https://tempo.xyz/developers/docs/guide/node/network-upgrades#network-identities). Keep your other node arguments, including `--chain testnet` for testnet nodes.

:::code-group
```bash [Mainnet]
tempo node \
  --consensus.network-identity 0xa217bb85001d4dcf8e5c50136f77af88cb2cab1857279b91c6240f41cca95c4f43f6dcab3e0dfb87dafb3ecbeb6251e90a5df2e6c47432482821cd8b84665ee4642589d2d9628a92b03e2bbfb00e006d038cd98def76d2a41b7c228c05f5a193 \
  --consensus.network-identity-from-epoch 0
```

```bash [Testnet]
tempo node --chain testnet \
  --consensus.network-identity 0x967ae1a6d3ddbe5cb0fe5e6fc58e74249787b4a277619b549fed6609d04660540dd2449cd7174def35e40f544e5ad72d15d064191a205ed6e0c49619c68f975108b614d0d51def9a8416a10a07c4193bea0cbbc4252ec1b33f21095a5d7aa590 \
  --consensus.network-identity-from-epoch 1747
```
:::

If the supplied identity does not match the network's DKG outcome for that epoch, the node stops with `network identity mismatch in epoch` or `persisted DKG network identity differs from the configured identity`. Check the identity and epoch values against [Network identities](https://tempo.xyz/developers/docs/guide/node/network-upgrades#network-identities).

## I accidentally deleted my consensus data directory

Current validators require consensus finalization certificates to start. Contact the Tempo team to coordinate restoring a consistent snapshot; do not assume restarting with an empty consensus directory is sufficient. Once startup data is restored, [signing-share recovery](https://tempo.xyz/developers/docs/guide/node/validator-keys#signing-share-recovery) can reconstruct a missing share, or the node can obtain one in a future successful DKG ceremony.

:::danger
Do **not** delete the entire data directory and attempt to re-sync with the same signing key. This risks double-signing and will require [rotating to a new identity](https://tempo.xyz/developers/docs/guide/node/validator-lifecycle#resetting-your-validators-data).
:::

## How long does it take for my validator to become active?

After on-chain registration, your validator follows the [state transition timeline](https://tempo.xyz/developers/docs/guide/node/validator-status#state-transitions):

1. **Epoch E** (immediate) — registered on the p2p network, starts syncing.
2. **Epoch E+1** (~3 hours) — becomes a player, receives signing shares.
3. **Epoch E+2** (~6 hours) — becomes a dealer/validator, can propose and vote once synced.

In most cases, your validator will be fully active within 6 hours.

## How long does it take for my validator to exit?

After deactivation, your validator is phased out over two epochs:

1. **Epoch E** — deactivation transaction submitted. Validator remains fully active.
2. **Epoch E+1** (~3 hours) — still a dealer but no longer a player. In the process of being removed.
3. **Epoch E+2** (~6 hours) — fully out of the committee (assuming no DKG failures).

Keep your node running until `in_committee: false` — check with [validator lookup](https://tempo.xyz/developers/docs/guide/node/validator-status#look-up-your-validator).

## Can I register my validator without the Tempo team?

No — the active validator set is currently permissioned. Only the contract owner can add validators on-chain. To get started, [contact the Tempo team](https://tempo.xyz/contact).

The onboarding process:

1. **You** generate your signing key and registration signature ([Steps 1–2](https://tempo.xyz/developers/docs/guide/node/validator-setup#initial-registration)).
2. **You** provide the required values to the Tempo team ([Step 3](https://tempo.xyz/developers/docs/guide/node/validator-setup#step-3-submit-registration-details)).
3. **The Tempo team** adds your validator on-chain.
4. **You** download a snapshot and start your node ([Running the validator](https://tempo.xyz/developers/docs/guide/node/validator-setup#running-the-validator)).

## What can I do without the Tempo team?

Once your validator is registered, most operations are self-service:

* [Rotate your signing key](https://tempo.xyz/developers/docs/guide/node/validator-lifecycle#rotate-validator-identity)
* [Update IP addresses](https://tempo.xyz/developers/docs/guide/node/validator-lifecycle#update-ip-addresses)
* [Update your fee recipient](https://tempo.xyz/developers/docs/guide/node/validator-lifecycle#update-the-fee-recipient)
* [Transfer validator ownership](https://tempo.xyz/developers/docs/guide/node/validator-lifecycle#transfer-validator-ownership)
* [Deactivate your validator](https://tempo.xyz/developers/docs/guide/node/validator-lifecycle#deactivate-your-validator)

Only **initial registration** and **reactivation** require the Tempo team.

## How do I check which version I'm running?

```bash
tempo --version
```

Compare with the latest release on the [network upgrades](https://tempo.xyz/developers/docs/guide/node/network-upgrades) page to ensure you're on a supported version.