# Teku documentation

> Official Teku documentation: Ethereum consensus client, installation, configuration, staking and operations.

This file contains all documentation content in a single document following the llmstxt.org standard.

## Start Teku from a recent state


To get Teku up and running in only a few minutes, start Teku from a recent finalized checkpoint
state rather than syncing from genesis.
Using a checkpoint state enables Teku to sync within the
[weak subjectivity](../concepts/weak-subjectivity.md) period.

When starting from a recent checkpoint, Teku downloads historic chain data in the background.

:::tip
You need access to a beacon node with [REST API enabled] (for example, Teku) to download the
finalized checkpoint state file.

Alternatively, you can use a checkpoint state endpoint from
[this community-maintained list of checkpoint state endpoints](https://eth-clients.github.io/checkpoint-sync-endpoints/).
:::

The following command downloads a recent finalized checkpoint state from a beacon node, and starts Teku:

```bash
teku --ee-endpoint=http://localhost:8551 \
--validator-keys=/Users/me/mainnet/validator/keys:/Users/me/mainnet/validator/passwords \
--checkpoint-sync-url=https://beaconstate.ethstaker.cc
```

The command uses the [`--checkpoint-sync-url`](../reference/cli/index.md#checkpoint-sync-url) option
to download the finalized checkpoint state.
When using this option, you must clear your existing beacon node database so Teku can download the
new, finalized state. Either start Teku with
[`--force-clear-db`](../reference/cli/index.md#force-clear-db) to clear the database on startup, or
manually delete the beacon database (for example `<data-path>/beacon/db`).

:::note

You can also download a finalized checkpoint state file, and specify the location using the
[`--initial-state`](../reference/cli/index.md#initial-state) option.
To download the file and name it `state.ssz` run:

```bash
curl -o state.ssz -H 'Accept: application/octet-stream' http://other-node:5051/eth/v2/debug/beacon/states/finalized
```

And to start Teku, run:

```bash
teku --ee-endpoint=http://localhost:8551 \
--validator-keys=/Users/me/mainnet/validator/keys:/Users/me/mainnet/validator/passwords \
--initial-state=state.ssz
```

Another option is to use [`--initial-state`](../reference/cli/index.md#initial-state) with the URL
of the state you want to use:

```bash
teku --ee-endpoint=http://localhost:8551 \
--validator-keys=/Users/me/mainnet/validator/keys:/Users/me/mainnet/validator/passwords \
--initial-state=http://other-node:5051/eth/v2/debug/beacon/states/finalized
```

:::

<!--links-->

[REST API enabled]: ../reference/cli/index.md#rest-api-enabled

---

## Connect to Mainnet


:::info

Ethereum is a [proof-of-stake](../../concepts/proof-of-stake.md) network, and a full Ethereum node requires
both [an execution client and a consensus client](../../concepts/node-types.md).

:::

Run Teku as a consensus client with any execution client on Ethereum Mainnet.

If you're using [Besu](https://besu.hyperledger.org/en/stable/) as an execution client, you can
follow the [Besu and Teku Mainnet tutorial](https://besu.hyperledger.org/en/latest/public-networks/tutorials/besu-teku-mainnet/).

## Prerequisites

- [Teku installed](../install/install-binaries.md).
- An execution client installed. For example, [Besu].

## 1. Generate the shared secret

Run the following command:

```bash
openssl rand -hex 32 | tr -d "\n" > jwtsecret.hex
```

You will specify `jwtsecret.hex` when starting Teku and the execution client. This is a shared JWT secret the clients use to authenticate each other when using the [Engine API](https://github.com/ethereum/execution-apis/blob/v1.0.0-beta.1/src/engine/specification.md).

## 2. Generate validator keys

If you're running a beacon node only, skip to the
[next step](#3-start-the-execution-client).

If you're also running a validator client, have a funded Ethereum address ready
(32 ETH and gas fees for each validator).

Generate validator keys for one or more validators using the
[Staking Launchpad](https://launchpad.ethereum.org/en/).
Remember the passwords that you use to create the validator keys, because you
need them to [create the validator password files](#create-a-password-file-for-each-validator-key).

### Create a password file for each validator key

For each validator key, create a text file containing the password to decrypt the key.

Teku allows you to specify individual keys and passwords in the command line, or you can specify directories from which to load keys and passwords.
If specifying directories, password files must have the same name as the keys, but use the `.txt` extension.

:::info

- If the Launchpad creates a key named `keystore-m_12381_3600_0_0_0-1596485378.json`,
  then the password file must be named `keystore-m_12381_3600_0_0_0-1596485378.txt`.

- The password file format follows
  [`EIP-2335`](https://eips.ethereum.org/EIPS/eip-2335#password-requirements)
  requirements (UTF-8 encoded file, unicode normalization, and control code removal).

:::

## 3. Start the execution client

Refer to your execution client documentation to configure and start the execution client. Make sure you specify the shared secret generated in [step 1].

If you're using [Besu], you can follow the [Besu and Teku Mainnet tutorial](https://besu.hyperledger.org/en/stable/public-networks/tutorials/besu-teku-mainnet/).

## 4. Start Teku

Open a new terminal window.

### Beacon node only

To run Teku as a beacon node only (without validator duties), run the following command or [specify the options in a configuration file](../../how-to/configure/use-config-file.md):

```bash
teku \
    --ee-endpoint=http://localhost:8551          \
    --ee-jwt-secret-file=<path to jwtsecret.hex> \
    --metrics-enabled=true                       \
    --rest-api-enabled=true                      \
    --checkpoint-sync-url=<checkpoint sync URL>
```

Specify:

- The path to the `jwtsecret.hex` file generated in [step 1] using the
  [`--ee-jwt-secret-file`](../../reference/cli/index.md#ee-jwt-secret-file) option.
- The URL of a checkpoint sync endpoint using the
  [`--checkpoint-sync-url`](../../reference/cli/index.md#checkpoint-sync-url) option.

Also, in the command:

- [`--ee-endpoint`](../../reference/cli/index.md#ee-endpoint) is set to the default URL of the execution client's Engine API.
- [`--metrics-enabled`](../../reference/cli/index.md#metrics-enabled) enables the metrics exporter.
- [`--rest-api-enabled`](../../reference/cli/index.md#rest-api-enabled) enables the REST API service.

You can modify the option values and add other [command line options](../../reference/cli/index.md) as needed.

### Beacon node and validator client

You can run the Teku beacon node and validator client as a [single process](#single-process) or as [separate processes](#separate-processes).

You can check your validator status by searching your Ethereum address on the [Beacon Chain explorer](https://beaconcha.in/).
Your validator might take up to multiple days to activate and start proposing blocks.

You can also use [Prometheus and Grafana](../../how-to/monitor/use-metrics.md) to monitor your nodes.

#### Single process

To run the Teku beacon node and validator client in a single process, run the following command or [specify the options in the configuration file](../../how-to/configure/use-config-file.md):

```bash
teku \
  --ee-endpoint=http://localhost:8551                       \
  --ee-jwt-secret-file=<path to jwtsecret.hex>              \
  --metrics-enabled=true                                    \
  --rest-api-enabled=true                                   \
  --checkpoint-sync-url=<checkpoint sync URL>              \
  --validators-proposer-default-fee-recipient=<ETH address> \
  --validator-keys=<path to key file>:<path to password file>[,<path to key file>:<path to password file>,...]
```

Specify:

- The path to the `jwtsecret.hex` file generated in [step 1] using the [`--ee-jwt-secret-file`](../../reference/cli/index.md#ee-jwt-secret-file) option.
- The URL of a checkpoint sync endpoint using the
  [`--checkpoint-sync-url`](../../reference/cli/index.md#checkpoint-sync-url) option.
- An Ethereum address you own as the default fee recipient using the [`--validators-proposer-default-fee-recipient`](../../reference/cli/index.md#validators-proposer-default-fee-recipient) option.
- The paths to the keystore `.json` file and password `.txt` file created in [step 2](#create-a-password-file-for-each-validator-key)
  for each validator using the [`--validator-keys`](../../reference/cli/index.md#validator-keys) option.
  Separate the `.json` and `.txt` files with a colon, and separate entries for multiple validators with commas.
  Alternatively, specify paths to directories to load multiple keys and passwords from.

Also, in the command:

- [`--ee-endpoint`](../../reference/cli/index.md#ee-endpoint) is set to the default URL of the execution client's Engine API.
- [`--metrics-enabled`](../../reference/cli/index.md#metrics-enabled) enables the metrics exporter.
- [`--rest-api-enabled`](../../reference/cli/index.md#rest-api-enabled) enables the REST API service.

You can modify the option values and add other [command line options](../../reference/cli/index.md) as needed.

#### Separate processes

To run the Teku beacon node and validator client as separate processes, first [start Teku as a beacon node only](#beacon-node-only).

On a separate machine, run Teku using the [`validator-client`](../../reference/cli/subcommands/validator-client.md) subcommand:

```bash
teku validator-client \
    --beacon-node-api-endpoint=<endpoint> \
    --validator-keys=<path to key file>:<path to password file>[,<path to key file>:<path to password file>,...]
```

Specify:

- The location of one or more beacon node API endpoints using the
  [`--beacon-node-api-endpoint`](../../reference/cli/subcommands/validator-client.md#beacon-node-api-endpoint-beacon-node-api-endpoints) option.
- The paths to the keystore `.json` file and password `.txt` file created in [step 2](#create-a-password-file-for-each-validator-key)
  for each validator using the [`--validator-keys`](../../reference/cli/index.md#validator-keys) option.
  Separate the `.json` and `.txt` files with a colon, and separate entries for multiple validators with commas.
  Alternatively, specify paths to directories to load multiple keys and passwords from.

## 5. Wait for the clients to sync

After starting the execution client and Teku, your node starts syncing and
connecting to peers.

If you're running Teku as a beacon node only, you're all set.
If you're also running Teku as a validator client, ensure your clients are fully
synced before submitting your staking deposit in the next step.
Syncing the execution client can take several days.

## 6. Stake ETH

Stake your ETH for one or more validators using the
[Staking Launchpad](https://launchpad.ethereum.org/en/).

You can check your validator status by searching your Ethereum address on the
[Beacon Chain explorer](https://beaconcha.in/).
It may take up to multiple days for your validator to be activated and start
proposing blocks.

<!-- links -->

[Besu]: https://besu.hyperledger.org/en/stable/
[step 1]: #1-generate-the-shared-secret

---

## Connect to a testnet


Run Teku as a consensus client with any execution client on a testnet (for example [Hoodi](https://github.com/eth-clients/hoodi), [Ephemery](https://ephemery.dev/), or [Sepolia](https://github.com/eth-clients/sepolia)).

If you're using [Besu](https://besu.hyperledger.org/en/stable/) as an execution client, you can follow the
[Besu and Teku testnet tutorial](https://besu.hyperledger.org/en/latest/public-networks/tutorials/besu-teku-testnet/).

:::note Notes

- Ephemery is a single network that rolls back to the genesis after a set period of time.
  Ephemery is focused on short-term and heavy testing use cases.
  It avoids problems like insufficient testnet funds, inactive validators, state bloat, and similar
  issues faced by long-running testnets.
- Sepolia is a permissioned network and you can't run a validator client on it without [requesting to become a validator](https://notes.ethereum.org/zvkfSmYnT0-uxwwEegbCqg) first.
You can connect your consensus client using the beacon node only, without any validator duties.

:::

## Prerequisites

- [Teku installed](../install/install-binaries.md).
- An execution client installed. For example, [Besu].

## 1. Generate the shared secret

Run the following command:

```bash
openssl rand -hex 32 | tr -d "\n" > jwtsecret.hex
```

You will specify `jwtsecret.hex` when starting Teku and the execution client. This is a shared JWT secret the clients use to authenticate each other when using the [Engine API](https://github.com/ethereum/execution-apis/blob/v1.0.0-beta.1/src/engine/specification.md).

## 2. Generate validator keys

If you're running a beacon node only, skip to the [next step](#3-start-the-execution-client).

If you're also running a validator client, create a test Ethereum address
(you can do this in [MetaMask](https://support.metamask.io/configure/accounts/how-to-add-accounts-in-your-wallet/)).
Fund this address with testnet ETH (32 ETH and gas fees for each validator) using a faucet.
See the faucets for the relevant testnet:

- [Hoodi](https://github.com/eth-clients/hoodi)
- [Sepolia](https://github.com/eth-clients/sepolia)
- [Ephemery](https://ephemery-faucet.pk910.de/)

:::note

If you're unable to get ETH using the faucet, you can ask for help on the [EthStaker Discord](https://discord.gg/ethstaker).

:::

Generate validator keys for one or more validators using the [Hoodi Staking Launchpad](https://hoodi.launchpad.ethereum.org/) or [Ephemery Staking Launchpad](https://launchpad.ephemery.dev/).

Remember the passwords that you use to create the validator keys, because you
need them to [create the validator password files](#create-a-password-file-for-each-validator-key).

### Create a password file for each validator key

For each validator key, create a text file containing the password to decrypt the key.

Teku allows you to specify individual keys and passwords in the command line, or you can specify directories from which to load keys and passwords.
If specifying directories, password files must have the same name as the keys, but use the `.txt` extension.

:::info

- If the Launchpad creates a key named `keystore-m_12381_3600_0_0_0-1596485378.json`,
  then the password file must be named `keystore-m_12381_3600_0_0_0-1596485378.txt`.
- The password file format follows
  [`EIP-2335`](https://eips.ethereum.org/EIPS/eip-2335#password-requirements)
  requirements (UTF-8 encoded file, unicode normalization, and control code removal).

:::

## 3. Start the execution client

Refer to your execution client documentation to configure and start the execution client. Make sure you specify the shared secret generated in [step 1].

If you're using [Besu], you can follow the [Besu and Teku testnet tutorial](https://besu.hyperledger.org/en/latest/public-networks/tutorials/besu-teku-testnet/).

## 4. Start Teku

Open a new terminal window.

### Beacon node only

To run Teku as a beacon node only (without validator duties), run the following command or [specify the options in a configuration file](../../how-to/configure/use-config-file.md):

<Tabs>
<TabItem value="Hoodi" label="Hoodi" default>

```bash
teku \
  --network=hoodi                              \
  --ee-endpoint=http://localhost:8551          \
  --ee-jwt-secret-file=<path to jwtsecret.hex> \
  --metrics-enabled=true                       \
  --rest-api-enabled=true                      \
  --checkpoint-sync-url=<checkpoint sync URL>
```

</TabItem>

<TabItem value="Ephemery" label="Ephemery">

```bash
teku \
  --network=ephemery                           \
  --ee-endpoint=http://localhost:8551          \
  --ee-jwt-secret-file=<path to jwtsecret.hex> \
  --metrics-enabled=true                       \
  --rest-api-enabled=true                      \
  --checkpoint-sync-url=<checkpoint sync URL optional>
```

</TabItem>
<TabItem value="Sepolia" label="Sepolia">

```bash
teku \
  --network=sepolia                            \
  --ee-endpoint=http://localhost:8551          \
  --ee-jwt-secret-file=<path to jwtsecret.hex> \
  --metrics-enabled=true                       \
  --rest-api-enabled=true                      \
  --checkpoint-sync-url=<checkpoint sync URL>
```

</TabItem>
</Tabs>

Specify:

- The path to the `jwtsecret.hex` file generated in [step 1] using the
  [`--ee-jwt-secret-file`](../../reference/cli/index.md#ee-jwt-secret-file) option.
- The URL of a checkpoint sync endpoint using the
  [`--checkpoint-sync-url`](../../reference/cli/index.md#checkpoint-sync-url) option.

You can modify the option values and add other [command line options](../../reference/cli/index.md) as needed.

### Beacon node and validator client

You can run the Teku beacon node and validator client as a [single process](#single-process) or as [separate processes](#separate-processes).

You can check your validator status by searching your Ethereum address on the [Hoodi explorer](https://hoodi.etherscan.io/) or [Ephemery explorer](https://explorer.ephemery.dev/).
It may take up to multiple days for your validator to be activated and start proposing blocks.

You can also use [Prometheus and Grafana](../../how-to/monitor/use-metrics.md) to monitor your nodes.

#### Single process

To run the Teku beacon node and validator client in a single process, run the following command or
[specify the options in the configuration file](../../how-to/configure/use-config-file.md):

<Tabs>
<TabItem value="Hoodi" label="Hoodi" default>

```bash
teku \
  --network=hoodi                                           \
  --ee-endpoint=http://localhost:8551                       \
  --ee-jwt-secret-file=<path to jwtsecret.hex>              \
  --metrics-enabled=true                                    \
  --rest-api-enabled=true                                   \
  --checkpoint-sync-url=<checkpoint sync URL>               \
  --validators-proposer-default-fee-recipient=<ETH address> \
  --validator-keys=<path to key file>:<path to password file>[,<path to key file>:<path to password file>,...]
```

</TabItem>

<TabItem value="Ephemery" label="Ephemery">

```bash
teku \
  --network=ephemery                                        \
  --ee-endpoint=http://localhost:8551                       \
  --ee-jwt-secret-file=<path to jwtsecret.hex>              \
  --metrics-enabled=true                                    \
  --rest-api-enabled=true                                   \
  --checkpoint-sync-url=<checkpoint sync URL optional>      \
  --validators-proposer-default-fee-recipient=<ETH address> \
  --validator-keys=<path to key file>:<path to password file>[,<path to key file>:<path to password file>,...]
```

</TabItem>
<TabItem value="Sepolia" label="Sepolia" >

:::note
Sepolia is a permissioned network and you can't run a validator client on it without [requesting to become a validator](https://notes.ethereum.org/zvkfSmYnT0-uxwwEegbCqg) first.
:::

</TabItem>
</Tabs>

Specify:

- The path to the `jwtsecret.hex` file generated in [step 1] using the
    [`--ee-jwt-secret-file`](../../reference/cli/index.md#ee-jwt-secret-file) option.
- The URL of a checkpoint sync endpoint using the
    [`--checkpoint-sync-url`](../../reference/cli/index.md#checkpoint-sync-url) option.
- An Ethereum address you own as the default fee recipient using the
    [`--validators-proposer-default-fee-recipient`](../../reference/cli/index.md#validators-proposer-default-fee-recipient) option.
- The paths to the keystore `.json` file and password `.txt` file created in [step 2](#create-a-password-file-for-each-validator-key)
    for each validator using the [`--validator-keys`](../../reference/cli/index.md#validator-keys) option.
    Separate the `.json` and `.txt` files with a colon, and separate entries for multiple validators with commas.
    Alternatively, specify paths to directories to load multiple keys and passwords from.

You can modify the option values and add other [command line options](../../reference/cli/index.md) as needed.

#### Separate processes

To run the Teku beacon node and validator client as separate processes, first [start Teku as a beacon node only](#beacon-node-only).

On a separate machine, run Teku using the [`validator-client`](../../reference/cli/subcommands/validator-client.md) subcommand:

<Tabs>
<TabItem value="Hoodi" label="Hoodi" default>

```bash
teku validator-client \
  --network=hoodi                       \
  --beacon-node-api-endpoint=<endpoint> \
  --validator-keys=<path to key file>:<path to password file>[,<path to key file>:<path to password file>,...]
```

</TabItem>

<TabItem value="Ephemery">

:::note Coming soon
Support for starting Teku as a separate validator client on the Ephemery testnet is coming soon.
:::

</TabItem>
<TabItem value="Sepolia" label="Sepolia">

:::note
Sepolia is a permissioned network and you can't run a validator client on it without [requesting to become a validator](https://notes.ethereum.org/zvkfSmYnT0-uxwwEegbCqg) first.
:::

</TabItem>
</Tabs>

Specify:

- The location of one or more beacon node API endpoints using the
[`--beacon-node-api-endpoint`](../../reference/cli/subcommands/validator-client.md#beacon-node-api-endpoint-beacon-node-api-endpoints) option.
- The paths to the keystore `.json` file and password `.txt` file created in [step 2](#create-a-password-file-for-each-validator-key)
for each validator using the [`--validator-keys`](../../reference/cli/index.md#validator-keys) option.
Separate the `.json` and `.txt` files with a colon, and separate entries for multiple validators with commas
Alternatively, specify paths to directories to load multiple keys and passwords from.

## 5. Wait for the clients to sync

After starting the execution client and Teku, your node starts syncing and
connecting to peers.

If you're running Teku as a beacon node only, you're all set.
If you're also running Teku as a validator client, ensure your clients are fully
synced before submitting your staking deposit in the next step.
Syncing the execution client can take several days.

## 6. Stake ETH

Stake your testnet ETH for one or more validators using the [Hoodi Staking Launchpad](https://hoodi.launchpad.ethereum.org/) or [Ephemery Staking Launchpad](https://launchpad.ephemery.dev).

You can check your validator status by searching your Ethereum address on the [Hoodi explorer](https://hoodi.etherscan.io/) or [Ephemery explorer](https://explorer.ephemery.dev/).
It may take up to multiple days for your validator to be activated and start proposing blocks.

<!-- links -->

[Besu]: https://besu.hyperledger.org/en/stable/
[step 1]: #1-generate-the-shared-secret

---

## Build from source


If you want to use the latest development version of Teku or a specific commit, build from source.
Otherwise, use the [binary] or [Docker image] for more stable versions.

## Prerequisites

- [Java JDK](https://www.oracle.com/java/technologies/javase-downloads.html)

  :::caution

  Teku requires Java 25+; earlier versions are not supported.

  :::

- [Git](https://git-scm.com/downloads) or [GitHub Desktop](https://desktop.github.com/)
- [Gradle build tool](https://gradle.org/)

## Installation on Linux / Unix / macOS

### Clone the Teku repository

Clone the `Consensys/teku` repository:

```bash
git clone https://github.com/Consensys/teku.git
```

### Build Teku

After cloning, go to the `teku` directory.

Build Teku with the Gradle wrapper `gradlew`, as follows:

```bash
./gradlew distTar installDist
```

:::note

The command produces an expanded distribution, ready to run in `build/install/teku`, and a `.tar` distribution in `build/distribution`.

:::

Go to the `teku` directory:

```bash
cd build/install/teku
```

Display the Teku help to confirm installation:

```bash
bin/teku --help
```

:::tip

To view the list of available Gradle tasks, run `./gradlew tasks`

:::

Continue with [Starting Teku](../start-teku.md).

<!-- links -->

[binary]: install-binaries.md
[Docker image]: run-docker-image.md

---

## Install binary distribution


## Linux / Unix / macOS

### Prerequisites

- [Java JDK](https://www.oracle.com/java/technologies/javase-downloads.html)

:::caution

Teku requires Java 25+ to run; earlier versions are not supported.

:::

### Install from packaged binaries

Download the [Teku packaged binaries](https://github.com/ConsenSys/teku/releases).

Unpack the downloaded files and change into the `teku-<release>` directory.

Display Teku command line help to confirm installation:

```bash
./bin/teku --help
```

## macOS with Homebrew

### Prerequisites

- [Homebrew](https://brew.sh/)
- Java JDK.

:::caution

Teku requires Java 25+ to run. Earlier versions are not supported. You can install Java using `brew install temurin`. Alternatively, you can manually install the [Java JDK](https://www.oracle.com/java/technologies/javase-downloads.html).

:::

### Install (or upgrade) using Homebrew

To install Teku using Homebrew:

```bash
brew tap ConsenSys/teku
brew install ConsenSys/teku/teku
```

To upgrade Teku using Homebrew:

```bash
brew upgrade ConsenSys/teku/teku
```

To display the Teku version and confirm installation:

```bash
teku --version
```

---

## Run Teku from Docker

# Run Teku from a Docker image

Use the Teku Docker image to run a node without installing Teku.

**Prerequisites**:

- [Docker](https://docs.docker.com/install/)

## Run Teku Docker image

Display the Teku command line help using the Docker image

```bash
docker run consensys/teku:latest --help
```

You can specify [Teku environment variables](../../reference/cli/index.md#specify-options) with the docker image instead of the command line options.

```bash title="Example using Environment variables and CLI options"
docker run -d                             \
  -p 9000:9000/tcp                        \
  -p 9000:9000/udp                        \
  -p 9001:9001/udp                        \
  -p 5051:5051                            \
  -e TEKU_REST_API_ENABLED=true           \
  -e TEKU_P2P_PORT=9000                   \
  --mount type=bind,source=/Users/user1/teku/,target=/var/lib/teku consensys/teku:latest \
  --network=hoodi                         \
  --ee-endpoint=http://102.10.10.1:8551   \
  --validator-keys=/var/lib/teku/validator/keys:/var/lib/teku/validator/passwords \
  --data-path=/var/lib/teku               \
  --log-destination=CONSOLE
```

:::tip

- If running Docker in the background, set [`--log-destination`](../../reference/cli/index.md#log-destination) to `console` to send all logs to the console and appear in Docker's log output.
- Set [`--data-path`](../../reference/cli/index.md#data-base-path-data-path) to a mount point to ensure Teku data is not lost in the Docker filesystem.
- [Set the Docker user to the UID of the normal user](#allow-multiple-users-to-run-the-docker-image) to ensure read/write access to the required files.

:::

## Allow multiple users to run the Docker image

If using a local volume to mount data, ensure the permissions on the directory allow other users and groups to read/write.

Use the Docker [`--user`](https://docs.docker.com/engine/reference/commandline/run/) option to run the container for the specified user.
Use the UID because the username may not exist inside the docker container.

```bash title="Example"
docker run                                \
  -p 9000:9000/tcp                        \
  -p 9000:9000/udp                        \
  -p 9001:9001/udp                        \
  --user 1001:1001                        \
  --mount type=bind,source=/Users/user1/teku/,target=/var/lib/teku consensys/teku:latest \
  --data-base-path=/var/lib/teku          \
  --network=hoodi                         \
  --ee-endpoint=http://102.10.10.1:8551   \
  --validator-keys=/var/lib/teku/validator/keys:/var/lib/teku/validator/passwords
```

## Exposing ports

Expose ports for P2P peer discovery, metrics, and REST APIs. Expose the default ports or the ports specified using:

- [`--metrics-port`](../../reference/cli/index.md#metrics-port)
- [`--p2p-port`](../../reference/cli/index.md#p2p-port)
- [`--p2p-quic-port`](../../reference/cli/index.md#p2p-quic-port)
- [`--p2p-advertised-port`](../../reference/cli/index.md#p2p-advertised-port)
- [`--p2p-advertised-quic-port`](../../reference/cli/index.md#p2p-advertised-quic-port)
- [`--rest-api-port`](../../reference/cli/index.md#rest-api-port).

Teku uses the [QUIC transport](../../concepts/p2p-networking.md) on `9001/udp` by default, so expose this port in addition to the TCP transport and discovery ports.

To run Teku exposing local ports for access:

```bash
docker run                                      \
  -p <localportP2P>:30303/tcp                   \
  -p <localportP2P>:30303/udp                   \
  -p <localportREST>:5051 consensys/teku:latest \
  --network=<NETWORK>                           \
  --data-base-path=<DATA_DIR>                   \
  --ee-endpoint=<URL>                           \
  --validator-keys=<KEY_DIR>:<PASS_DIR>         \
  --rest-api-enabled=true
```

```bash title="Example"
docker run                                \
  -p 30303:30303/tcp                      \
  -p 30303:30303/udp                      \
  -p 5051:5051                            \
  --mount type=bind,source=/Users/user1/teku/,target=/var/lib/teku consensys/teku:latest \
  --network=hoodi                         \
  --data-base-path=/var/lib/teku          \
  --ee-endpoint=http://102.10.10.1:8551   \
  --validator-keys=/var/lib/teku/validator/keys:/var/lib/teku/validator/passwords \
  --rest-api-enabled=true
```

## Run Teku using Docker Compose

**Prerequisites**:

- [Docker Compose](https://docs.docker.com/compose/)

The following `docker-compose.yml` file starts a [Besu] and Teku node.

:::note

The example assumes the validators specified in [`--validator-keys`](../../reference/cli/index.md#validator-keys) have already been registered in the deposit contract.

:::

Run `docker-compose up` in the directory containing the `docker-compose.yml` file to start the container.

<Tabs>
  <TabItem value="Hoodi" label="Hoodi" default>

```yaml
---
version: "3.4"
services:
  besu_node:
    image: hyperledger/besu:latest
    command:
      [
        "--network=hoodi",
        "--data-path=/var/lib/besu/data",
        "--host-allowlist=*",
        "--sync-mode=FAST",
        "--rpc-http-enabled",
        "--rpc-http-cors-origins=*",
        "--rpc-http-api=ETH,NET,CLIQUE,DEBUG,MINER,NET,PERM,ADMIN,EEA,TXPOOL,PRIV,WEB3",
        "--engine-jwt-secret=/var/lib/besu/data/token.txt",
        "--engine-host-allowlist=*",
        "--engine-rpc-enabled=true",
      ]
    volumes:
      - ./besu:/var/lib/besu/data
    ports:
      # Map the p2p port(30303), RPC HTTP port(8545), and engine port (8551)
      - "8545:8545"
      - "8551:8551"
      - "30303:30303/tcp"
      - "30303:30303/udp"

  teku_node:
    environment:
      - "JAVA_OPTS=-Xmx4g"
    image: consensys/teku:latest
    command:
      [
        "--network=hoodi",
        "--data-base-path=/var/lib/teku/data",
        "--validators-proposer-default-fee-recipient=YOUR_WALLET",
        "--ee-endpoint=http://besu_node:8551",
        "--ee-jwt-secret-file=/var/lib/teku/data/token.txt",
        "--validator-keys=/var/lib/teku/data/validator/keys:/var/lib/teku/data/validator/passwords",
        "--p2p-port=9000",
        "--rest-api-enabled=true",
        "--rest-api-docs-enabled=true",
      ]
    depends_on:
      - besu_node
    volumes:
      - ./teku:/var/lib/teku/data
    ports:
      # Map the TCP transport and discovery port(9000), QUIC transport port(9001), and REST API port(5051)
      - "9000:9000/tcp"
      - "9000:9000/udp"
      - "9001:9001/udp"
      - "5051:5051"
```

  </TabItem>

  <TabItem value="Ephemery" label="Ephemery">

```yaml
---
version: "3.4"
services:
  besu_node:
    image: hyperledger/besu:latest
    command:
      [
        "--network=ephemery",
        "--data-path=/var/lib/besu/data",
        "--host-allowlist=*",
        "--sync-mode=FAST",
        "--rpc-http-enabled",
        "--rpc-http-cors-origins=*",
        "--rpc-http-api=ETH,NET,CLIQUE,DEBUG,MINER,NET,PERM,ADMIN,EEA,TXPOOL,PRIV,WEB3",
        "--engine-jwt-secret=/var/lib/besu/data/token.txt",
        "--engine-host-allowlist=*",
        "--engine-rpc-enabled=true",
      ]
    volumes:
      - ./besu:/var/lib/besu/data
    ports:
      # Map the p2p port(30303), RPC HTTP port(8545), and engine port (8551)
      - "8545:8545"
      - "8551:8551"
      - "30303:30303/tcp"
      - "30303:30303/udp"

  teku_node:
    environment:
      - "JAVA_OPTS=-Xmx4g"
    image: consensys/teku:latest
    command:
      [
        "--network=ephemery",
        "--data-base-path=/var/lib/teku/data",
        "--validators-proposer-default-fee-recipient=YOUR_WALLET",
        "--ee-endpoint=http://besu_node:8551",
        "--ee-jwt-secret-file=/var/lib/teku/data/token.txt",
        "--validator-keys=/var/lib/teku/data/validator/keys:/var/lib/teku/data/validator/passwords",
        "--p2p-port=9000",
        "--rest-api-enabled=true",
        "--rest-api-docs-enabled=true",
      ]
    depends_on:
      - besu_node
    volumes:
      - ./teku:/var/lib/teku/data
    ports:
      # Map the TCP transport and discovery port(9000), QUIC transport port(9001), and REST API port(5051)
      - "9000:9000/tcp"
      - "9000:9000/udp"
      - "9001:9001/udp"
      - "5051:5051"
```

  </TabItem>

  <TabItem value="Mainnet" label="Mainnet" >

```yaml
---
version: "3.4"
services:
  besu_node:
    image: hyperledger/besu:latest
    command:
      [
        "--data-path=/var/lib/besu/data",
        "--host-allowlist=*",
        "--rpc-http-enabled",
        "--rpc-http-cors-origins=*",
        "--rpc-http-api=ETH,NET,CLIQUE,DEBUG,MINER,NET,PERM,ADMIN,EEA,TXPOOL,PRIV,WEB3",
        "--engine-jwt-secret=/var/lib/besu/data/token.txt",
        "--engine-host-allowlist=*",
        "--engine-rpc-enabled=true",
      ]
    volumes:
      - ./besu:/var/lib/besu/data
    ports:
      # Map the p2p port(30303), RPC HTTP port(8545), and engine port (8551)
      - "8545:8545"
      - "8551:8551"
      - "30303:30303/tcp"
      - "30303:30303/udp"

  teku_node:
    environment:
      - "JAVA_OPTS=-Xmx4g"
    image: consensys/teku:latest
    command:
      [
        "--data-base-path=/var/lib/teku/data",
        "--validators-proposer-default-fee-recipient=YOUR_WALLET",
        "--ee-endpoint=http://besu_node:8551",
        "--ee-jwt-secret-file=/var/lib/teku/data/token.txt",
        "--validator-keys=/var/lib/teku/data/validator/keys:/var/lib/teku/data/validator/passwords",
        "--p2p-port=9000",
        "--rest-api-enabled=true",
        "--rest-api-docs-enabled=true",
      ]
    depends_on:
      - besu_node
    volumes:
      - ./teku:/var/lib/teku/data
    ports:
      # Map the TCP transport and discovery port(9000), QUIC transport port(9001), and REST API port(5051)
      - "9000:9000/tcp"
      - "9000:9000/udp"
      - "9001:9001/udp"
      - "5051:5051"
```

  </TabItem>
</Tabs>

<!-- Links -->

[Besu]: https://besu.hyperledger.org/en/stable/

---

## Manage memory


Manage Teku's Java Virtual Machine (JVM) memory usage by setting a maximum heap size using the `JAVA_OPTS` environment variable.

We recommend setting the maximum heap size to 8GB or more.

Set the heap size using the environment variable, or using the command line when starting Teku.

<Tabs>
  <TabItem value="Environment variable" label="Environment variable" default>

```bash
export JAVA_OPTS=-Xmx8g
```

  </TabItem>
  <TabItem value="Command line" label="Command line" >

```bash
JAVA_OPTS=-Xmx8g ./teku [options]
```

  </TabItem>
</Tabs>

:::note

The node uses more RAM to perform better if it’s available, especially during periods of non-finalization.

:::

## Manage the heap dump

If an out of memory error occurs, the heap dump file is placed in the directory that Teku runs from.
The heap dump file can be 1-2 GB in size.
To specify the directory to place the file, set the `-XX:HeapDumpPath` Java option to the required path.

<Tabs>
  <TabItem value="Environment variable" label="Environment variable" default>

```bash
export TEKU_OPTS="-XX:HeapDumpPath=/home/me/me_node/dumps"
```

  </TabItem>
  <TabItem value="Command line" label="Command line" >

```bash
TEKU_OPTS="-XX:HeapDumpPath=/home/me/me_node/dumps" ./teku [options]
```

  </TabItem>
</Tabs>

To disable the heap dump file generation, set the `-XX:-HeapDumpOnOutOfMemoryError` Java option.

<Tabs>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
export TEKU_OPTS="-XX:-HeapDumpOnOutOfMemoryError"
```

  </TabItem>
  <TabItem value="Command line" label="Command line" >

```bash
TEKU_OPTS="-XX:-HeapDumpOnOutOfMemoryError" ./teku [options]
```

  </TabItem>
</Tabs>

---

## Migrate to Teku


Migrate from a different Ethereum consensus client to Teku to contribute to [client diversity](https://clientdiversity.org/).

When migrating from a different client, consider the following:

- You can [import a slashing protection database](../reference/cli/subcommands/slashing-protection.md#import).
- You might need to update your [network ports](../how-to/find-and-connect/improve-connectivity.md).
- The way Teku handles [validator keys](../reference/cli/index.md#validator-keys) might differ from your previous client. Teku also supports [using Web3Signer](../how-to/use-external-signer/use-web3signer.md).
- You can skip the long initial sync period by using Teku's [checkpoint start](checkpoint-start.md) capability.

Find guides to switch from specific clients on the [client diversity website](https://clientdiversity.org/#switch).

---

## Start Teku


You can run Teku as a beacon node and validator in a single process, or as separate processes.

We recommend you run the beacon node and validator as a [single process] if they are to run on the same machine.

:::note

By default, Teku connects to `mainnet`. Use the [`--network`](../reference/cli/index.md#network) command line option to specify an alternate network.

:::

## Prerequisites

- [Teku installed](install/install-binaries.md).
- [An execution client synced](connect/mainnet.md#3-start-the-execution-client).
- [Validator keystores and password files](connect/mainnet.md#2-generate-validator-keys).

## Start the clients in a single process

Start the beacon node and validator as a single process by specifying the validator options using the [`teku`](../reference/cli/index.md#options) command.

```bash title="Example"
teku \
  --ee-endpoint=http://localhost:8551                       \
  --ee-jwt-secret-file=jwtsecret.hex                        \
  --metrics-enabled=true                                    \
  --rest-api-enabled=true                                   \
  --checkpoint-sync-url=https://beaconstate.ethstaker.cc    \
  --validators-proposer-default-fee-recipient=0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73 \
  --validator-keys=validator/keys/validator_888eef.json:validator/passwords/validator_888eef.txt
```

Use the [`--validator-keys`](../reference/cli/index.md#validator-keys) option to specify the directories or files to load the encrypted keystore file(s) and associated password file(s) from.

## Run the clients separately

Validators must connect to a beacon node to publish attestations or propose blocks. The beacon node requires internet access, but the connected validators can run on machines without internet access.

### Start the beacon node

Run Teku as a beacon node.

```bash title="Example"
teku \
    --ee-endpoint=http://localhost:8551                    \
    --ee-jwt-secret-file=jwtsecret.hex                     \
    --metrics-enabled=true                                 \
    --rest-api-enabled=true                                \
    --checkpoint-sync-url=https://beaconstate.ethstaker.cc \
```

Specify [`--rest-api-enabled`](../reference/cli/index.md#rest-api-enabled) to allow validators to connect to the beacon node.

:::caution

Don't pass the validator keys as a command line option to both the beacon node and validator client. This can cause a [slashable offense].

:::

By default, [validator clients] can connect to the beacon node at `http://127.0.0.1:5051`.
Use the [`--rest-api-interface`](../reference/cli/index.md#rest-api-interface) and [`--rest-api-port`](../reference/cli/index.md#rest-api-port) options to update the address.

You can specify [`--rest-api-host-allowlist`](../reference/cli/index.md#rest-api-host-allowlist) to allow access to the REST API from specific hostnames.

### Start the validator

To run a validator, connect to a [running beacon node].

Use the [`validator-client`](../reference/cli/subcommands/validator-client.md) or
[`vc`](../reference/cli/subcommands/validator-client.md) subcommand to run a Teku as a validator.

```title="Example"
teku validator-client \
    --beacon-node-api-endpoint=http://192.10.10.101:5051,http://192.140.110.44:5051 \
    --validator-keys=validator/keys:validator/passwords
```

:::warning

Ensure that the validator keys are only provided to the validator. Don't pass the validator keys as command line options to both the beacon node and validator client. This can cause a [slashable offense].

:::

Specify one or more beacon nodes using the [`--beacon-node-api-endpoint`](../reference/cli/subcommands/validator-client.md#beacon-node-api-endpoint-beacon-node-api-endpoints) option.

:::info

You can supply multiple beacon node endpoints to the validator. The first one is used as the primary node, and others as failovers.

:::

## Confirm Teku is running

Use the [`/liveness`](https://consensys.github.io/teku/#tag/Teku/operation/GetLiveness) endpoint to check whether the node is up.

The endpoint returns the status `200 OK` if the node is up or syncing.

<Tabs>
  <TabItem value="curl HTTP request" label="curl HTTP request" default>

```bash
curl -I -X GET "http://192.10.10.101:5051/teku/v1/admin/liveness"
```

  </TabItem>
  <TabItem value="Result" label="Result" >

```bash
HTTP/1.1 200 OK
Date: Fri, 05 Feb 2021 03:58:30 GMT
Server: Javalin
Content-Type: application/json
Cache-Control: max-age=0
Content-Length: 0
```

  </TabItem>
</Tabs>

## Exit codes

### Exit code 1

This code indicates a scenario where Teku has exited with a fatal error; however, restarting Teku without changes is a logical step in correcting it.
This code represents the error is related to something external to Teku.

Example: If the beacon chain controller has issues starting P2P services on a particular port, the system will exit with a fatal error code of 1. This could correct itself with a restart.

Example 2: If the migrate database command does not successfully migrate the database, Teku will exit with a code 1 fatal error. Restarting the system could correct this.

### Exit code 2

This code indicates a scenario where Teku has exited with a fatal error. Restarting Teku will not correct this.

Note that most user configuration errors fall into this category.

Example: If you specify an invalid database version in the migrate database command, Teku will exit with a code 2 fatal error.
To correct this, make the appropriate changes to the setup and then restart Teku.

### Usages

The exit codes for Teku are important to understand so that you know how to approach a restart and mitigate the issue.

The **service unit configuration** file is an example of how status codes can be used.
`RestartPreventExitStatus=` and `RestartForceExitStatus=` can be used to automatically restart Teku or stop it in case of failure.

The following is an example of a [`systemd.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) file:

```text
RestartForceExitStatus=1
RestartPreventExitStatus=2
```

<!-- links -->

[validator clients]: #start-the-validator
[running beacon node]: #start-the-beacon-node
[slashable offense]: ../concepts/slashing-protection.md
[single process]: #start-the-clients-in-a-single-process

---

## System requirements


The following are the minimum system requirements for running a full node, with Teku as a beacon node and validator client:

- CPU: 4 cores at 2.8 GHz
- Memory: 16 GB RAM
- Storage: SSD with 2 TB free space
- Operating system: 64-bit Linux or macOS
- Internet: Broadband internet connection (10 Mbps)

:::caution Windows is not supported

Teku does not support Windows. Windows users may switch to using Docker, Windows Subsystem for
Linux, or other supported operating systems.

:::

:::note
We also recommend that you have an uninterrupted power supply (UPS) to ensure your node is always available.
However, this is not required.
:::

You can use [Prometheus](../how-to/monitor/use-metrics.md) to check CPU and disk space requirements for Teku.
Grafana provides a [sample Teku dashboard](https://grafana.com/grafana/dashboards/13457).

---

## Architecture

# Teku architecture

The following diagram outlines the Teku high-level architecture.

![Architecture](/img/architecture.png)

Teku contains both a beacon node and validator client implementation.
The beacon node is the primary link to the Beacon Chain.
The validator client performs [validator duties](proof-of-stake.md).

You can [run the beacon node only](../get-started/start-teku.md#start-the-beacon-node), or [run the beacon node and validator client](../get-started/start-teku.md#start-the-clients-in-a-single-process).

Read more about the [Ethereum consensus client architecture](https://ethereum.org/en/developers/docs/nodes-and-clients/). For more information about the Teku architecture, contact us on [Teku Discord channel](https://discord.gg/teku).

---

## Builder network and MEV-Boost


[Consensus clients](./node-types.md#consensus-clients) are responsible for proposing
blocks containing an execution payload obtained from their local
[execution clients](./node-types.md#execution-clients) via the Engine API.

A consensus client can optionally configure an external builder and delegate the
execution payload construction to it, instead of using the execution client.

## MEV-Boost

The most common builder deployment is to run a specialized external software
such as [MEV-Boost](https://github.com/flashbots/mev-boost).
MEV-Boost works by requesting a payload proposal from several entities (called 
relays), and selecting the best bid in order to improve validator rewards and
increase the maximal extractable value (MEV).

Teku allows you to
[configure the beacon node to use a builder network](../how-to/configure/builder-network.md)
to generate execution payloads.
In case of failures or non-timely responses, Teku falls back to the payload
produced by the local execution client specified using
[`--ee-endpoint`](../reference/cli/index.md#ee-endpoint).

---

## Consensus and execution clients

An Ethereum node is an instance of an Ethereum client, which consists of:

- A consensus client (for example, Teku)
- An execution client (for example, Besu)

:::info

Before The Merge, execution clients were known as
[Eth1 clients](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/), and consensus clients
were called [Eth2 clients](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/).

The Merge, completed on **September 15, 2022**, transitioned Ethereum from
proof of work to [proof of stake consensus](proof-of-stake.md).

:::

Execution and consensus clients communicate with each other using the [Engine API](https://besu.hyperledger.org/public-networks/how-to/use-engine-api).

![Ethereum node](/img/execution-consensus-clients.png)

### Execution clients

Execution clients, such as [Besu](https://besu.hyperledger.org/), manage the execution layer, including
executing transactions and updating the world state. Execution clients serve
[JSON-RPC API](https://besu.hyperledger.org/public-networks/reference/api) requests and
communicate with each other in a peer-to-peer network.

### Consensus clients

Consensus clients, such as Teku, contain beacon node and validator client implementations. The beacon node
is the primary link to the [Beacon Chain](https://ethereum.org/en/upgrades/beacon-chain/) (consensus layer).
The validator client performs [validator duties](proof-of-stake.md) on the consensus layer. Consensus
clients serve [REST API](../reference/rest.md) requests and communicate with each other in a peer-to-peer network.

:::info

To become a validator, you must also run a validator client (either [in the same process as the beacon node](../get-started/start-teku.md#start-the-clients-in-a-single-process) or [separately](../get-started/start-teku.md#run-the-clients-separately)).

:::

---

## Peer-to-peer networking


Teku connects to the consensus-layer peer-to-peer (P2P) network using two transports to exchange data
and a discovery protocol to find peers.
This page explains how the transports, discovery, ports, and address configuration fit together.

:::note
If you encounter peering issues, see the [network troubleshooting guide](../how-to/troubleshoot/network.md#resolve-peering-issues).
:::

## Transports

Teku supports two P2P transports, both enabled by default:

- **TCP** - The original libp2p transport.
- **QUIC** - A transport that runs over UDP.

When QUIC is enabled, Teku advertises both its TCP and QUIC addresses to the network, and remote
peers can connect over either transport.
When Teku dials a peer, it uses QUIC if both the local node and the peer support it, and otherwise
falls back to TCP.

## Peer discovery and ENR

Teku uses [discovery v5](https://github.com/ethereum/devp2p/tree/master/discv5) over UDP to find
peers on the network.
Discovery starts from a set of [bootnodes](../how-to/find-and-connect/run-a-bootnode.md) and lets nodes
locate each other dynamically.

Teku identifies itself on the discovery network using an
[Ethereum Node Record (ENR)](https://eips.ethereum.org/EIPS/eip-778), which advertises the node's IP
address and ports.
The UDP discovery address is used only to find peers; it is not a connectable transport address.

:::note
Instead of relying on automatic discovery, you can also
[connect Teku to specific peers](../how-to/find-and-connect/connect-to-specific-peers.md), such as nodes
you operate, using static or direct peers.
:::

## Node identity and private key

The P2P private key identifies the beacon node on the network and secures the communication channel
between nodes.
Teku generates a key automatically on first startup, or you can supply your own using the
[`--p2p-private-key-file`](../reference/cli/index.md#p2p-private-key-file) option.

Using a persistent private key file gives the node a stable ENR, which is useful for
[bootnodes](../how-to/find-and-connect/run-a-bootnode.md) and other nodes that you want peers to
reconnect to reliably.

## P2P port options

Teku exposes a listening port and an advertised port for each transport and for peer discovery:

| Purpose | Protocol | Default port | Listening option | Advertised option |
| --- | --- | --- | --- | --- |
| TCP transport | TCP | `9000` | [`--p2p-port`](../reference/cli/index.md#p2p-port) | [`--p2p-advertised-port`](../reference/cli/index.md#p2p-advertised-port) |
| Peer discovery | UDP | `9000` | [`--p2p-udp-port`](../reference/cli/index.md#p2p-udp-port) | [`--p2p-advertised-udp-port`](../reference/cli/index.md#p2p-advertised-udp-port) |
| QUIC transport | UDP | `9001` | [`--p2p-quic-port`](../reference/cli/index.md#p2p-quic-port) | [`--p2p-advertised-quic-port`](../reference/cli/index.md#p2p-advertised-quic-port) |

The default port applies to the whole row: Teku listens on it and advertises it until you override
one or both options.
Set an advertised option only when peers must dial a different port than the node listens on, such
as when the node is behind a port forward.

Peer discovery has no default port of its own.
Its default follows the TCP transport port, so changing
[`--p2p-port`](../reference/cli/index.md#p2p-port) moves discovery with it unless you also set
[`--p2p-udp-port`](../reference/cli/index.md#p2p-udp-port).

Each option has an `-ipv6` counterpart (for example,
[`--p2p-quic-port-ipv6`](../reference/cli/index.md#p2p-quic-port-ipv6) and
[`--p2p-advertised-quic-port-ipv6`](../reference/cli/index.md#p2p-advertised-quic-port-ipv6)) that
adds a second address family for dual-stack operation.
The IPv6 defaults are `9090` for the TCP transport and peer discovery, and `9091` for QUIC.
The listening mode (IPv4, IPv6, or dual-stack) depends on how you combine these options with the
[`--p2p-interface`](../reference/cli/index.md#p2p-interface-p2p-interfaces) option.
By default, Teku listens over IPv4.
For IPv6 or dual-stack, see [Configure IPv6](../how-to/find-and-connect/configure-ipv6.md).

The address Teku advertises to peers can differ from the address it listens on, which matters when
the node is behind a NAT or router.
Teku autodetects the advertised address by default; you can configure it with
[`--p2p-advertised-ip`](../reference/cli/index.md#p2p-advertised-ip-p2p-advertised-ips).
You can also [specify NAT methods](../how-to/find-and-connect/specify-nat.md).

## Multiaddresses

Teku identifies peers using [multiaddresses](https://libp2p.io/concepts/fundamentals/addressing/).
A multiaddress includes the transport and port, so the TCP and QUIC addresses for the same node
differ:

- TCP - `/ip4/<ip>/tcp/9000/p2p/<peer_id>`
- QUIC - `/ip4/<ip>/udp/9001/quic-v1/p2p/<peer_id>`

The `p2p_addresses` field returned by the
[`/eth/v1/node/identity`](https://consensys.github.io/teku/#tag/Node/operation/getNetworkIdentity)
API endpoint lists the TCP and QUIC transport addresses.
The `discovery_addresses` field lists the UDP discovery address.

---

## PeerDAS


Peer Data Availability Sampling (PeerDAS), specified by [EIP-7594](https://eips.ethereum.org/EIPS/eip-7594), is the main
feature of the next Ethereum upgrade, Fusaka.

PeerDAS introduces enhanced capacity extension over [proto-danksharding](proto-danksharding.md).
The goal of this enhancement is to significantly increase the average number of blobs in every slot while keeping moderate
network and storage requirements for most node operators.

This is achieved using multiple techniques:

- **1D blob extension** - PeerDAS applies one-dimensional erasure coding extension to each blob, so its size doubles.
  The extended blob can be split into 128 parts such that you can reconstruct the original blob from any 64 parts.

- **Column splitting** - In danksharding, the base data unit is the blob.
  Each node is required to download all blobs referenced in the block to verify its availability.
  In PeerDAS, extended blobs are rows which stack one below another and are split into columns, creating DataColumnSidecars.
  This is the base data unit in PeerDAS and consists of 1/128th of each extended blob from the block, with additional
  data like proofs and block header.

- **Data availability sampling** - The last major change is easing node operator requirements for data availability checks.
  By splitting blobs data into columns, so that every single node operator is required to get pieces of each blob, it's
  impossible to lose any whole blob; either all blobs are available or none are.
  Security research has proven that it's enough to download 1/8 of the data (1/16 of the extended data) to prove data
  availability or confirm its non-availability.

Decreasing the size of required download, store, and share data by 8 for most nodes compared to danksharding
makes it possible to schedule a target number of blobs increase of almost 5x compared to the danksharding launch,
with potential room to increase it by another 4x in the future.
This change significantly increases the blob capacity of the Ethereum network and TPS of Layer 2.
Moreover, [EIP-7892: Blob Parameters Only Hardforks](https://eips.ethereum.org/EIPS/eip-7892) allows for changing maximum
number of blobs and blob target without a hard fork,
making future blob capacity changes easier.

## Expected implications for node operators

Proto-danksharding was launched with increased network requirements over the previous fork and additional storage required
for the data layer of about 50 GB for 3 blobs,
which was later increased to about 100 GB for 6 blobs in the Pectra fork.

With PeerDAS, consensus layer clients will use network and storage space for sidecar data according to their roles:

- **Full nodes** - These are nodes without any validators.
  Their requirements are to store 4 data columns in custody (which is permanent storage for a moving window of about 18
  recent days) and sample another 4. This means the data is downloaded, data availability is checked, but nothing is stored.
  4 columns with a scheduled 14-blob target (which could be increased in the future) will occupy about 16 GB of space, which
  means significantly less storage consumption by non-validator nodes.

- **Validator nodes** - Requirements for validator nodes are to custody at least 8 columns, with the number calculated based
  on the effective balance of active validators, adding a requirement of 1 extra column per every 32 ETH.
  Therefore, 1 validator requires 8 columns, 8 validators require 8 columns, 20 validators require 20 columns, with a maximum of
  128 columns for 128 validators or 4096 ETH in consolidated validators. For 1-8 validators and 14 blobs, a node will
  take 32 GB of space, which is still less than current requirements. But nodes with a lot of validators will basically
  become supernodes.

- **Supernodes** - These are either nodes running in altruistic mode or those operated by big validator operators with
  4096 or more ETH staked.
  This type of node stores and shares all columns data.
  An operator can enable this mode using the [`--p2p-subscribe-all-custody-subnets-enabled`](../reference/cli/index.md#p2p-subscribe-all-custody-subnets-enabled) command line option;
  big operators run in this mode as a protocol requirement.
  Storage consumption is increased, taking about 500 GB with 14 blobs of data layer space compared to 100 GB in Pectra.

  :::warning important

  If a node operator needs complete blob data through the REST API (for example, the `getBlobs` endpoint),
  they must either run in supernode mode or enable
  [`--rest-api-getblobs-sidecars-download-enabled`](../reference/cli/index.md#rest-api-getblobs-sidecars-download-enabled),
  which allows Teku to retrieve required sidecars on demand from the P2P network.
  Other types of nodes store only partial blob data.

  :::

All node space requirements are subject to change proportionally to the target number of blobs, which is currently scheduled
to be 14 starting from January 7, 2026 (about 1 month after the Fusaka fork).
Further target changes may be applied later and do not require a hard fork, but require node operators to upgrade their
clients in a timely manner.

---

## Proof of stake


In Ethereum's [proof of stake (PoS)](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/), you
must run a [full node](node-types.md) and
[stake 32 ETH](https://ethereum.org/en/staking/) to become a validator.

:::note

You must run a beacon node and an execution client to operate a node on Mainnet. To become a validator, you
must also run a validator client either [in the same process as the beacon node](../get-started/start-teku.md#start-the-clients-in-a-single-process) or [separately](../get-started/start-teku.md#run-the-clients-separately).

:::

The PoS mechanism randomly chooses validators to propose or validate blocks on the [Beacon Chain](https://ethereum.org/en/upgrades/beacon-chain/) in defined time frames.

Proposers are responsible for proposing new consensus blocks, and non-proposing validators are responsible for validating (attesting to) proposed blocks.
Validators are rewarded for proposing and attesting to consensus blocks eventually included in the Beacon Chain, and penalized for malicious behavior.
Validators also receive transaction fees for included blocks.

Each consensus block contains an execution payload, which contains a list of transactions and other data required to execute and validate the payload.

When a node validates a consensus block, its [consensus client](node-types.md#consensus-clients) processes the block
and sends the execution payload to the [execution client](node-types.md#execution-clients), which:

1. Assembles a block on the execution layer.
1. Verifies pre-conditions.
1. Executes transactions.
1. Verifies post-conditions.
1. Sends the validity result back to the consensus client.

If the block is valid, the execution client includes it in the execution chain and stores the new state in execution state storage.

If a consensus block receives attestations backed by enough staked ETH, the block is included in the Beacon Chain.

---

## Proto-danksharding


Proto-danksharding, specified by [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), is part of
the next Ethereum upgrade, the Dencun upgrade.

Proto-danksharding introduces a new "blob-carrying" transaction type, which allows data to be posted
to Ethereum Mainnet more cheaply than currently possible, thus improving scalability while
preserving decentralization.

## What are blobs?

Blobs are "sidecars" of data that ride alongside blocks, and are primarily used by the sequencers of
Ethereum Layer 2 rollups to contain batched transactions executed on those rollups.

Blobs are made up of 4096 32-byte field elements.
Blobs are designed to remain available for exactly 4096 epochs, or roughly 18 days.
After a blob expires, a majority of consensus layer clients can no longer retrieve the specific
data within the blob, but evidence of the blob's prior existence remains on the network.

The blobs' fee market structure is designed to target an average of three blobs attached to each
beacon block, with a maximum of six blobs.
Each blob holds 128 KB of temporary data.
This means that proto-danksharding might increase the data associated with a block by 384 KB on
average (128 KB per blob times three blobs) with a maximum of 768 KB (six blobs per block).

## What changes in consensus layer clients?

With proto-danksharding, consensus layer clients will:

- Use more network bandwidth in the peer-to-peer layer to receive and distribute the blobs.

- Require roughly 48 GiB more storage space for blobs, with a maximum of 96 GiB.
  This estimate comes from the following calculation:

  - 3 blobs per block x 128 KB each = 384 KB per block
  - 32 blocks per epoch x 4096 epochs for blob expiry = 131,072 blocks with blobs
  - 384KB x 131,072 blocks = 48 GiB increase in storage

See this article,
[Ethereum Evolved: Dencun Upgrade Part 5, EIP-4844](https://consensys.io/blog/ethereum-evolved-dencun-upgrade-part-5-eip-4844),
for more information about Dencun and proto-danksharding.

---

## Slashing protection


Teku implements slashing protection to prevent validators from signing blocks or attestations based on what it has already signed.

By default, Teku also locks keystore files listed in the [`--validator-keys`](../reference/cli/index.md#validator-keys) option to prevent other processes from using it.
You can enable and disable this functionality using the [`--validators-keystore-locking-enabled`](../reference/cli/index.md#validators-keystore-locking-enabled) option.

:::warning

Teku's slashing protection does not provide protection if the same validator key is being used by multiple nodes.

:::

To protect validators from slashable offenses, Teku stores a record of the most recently signed blocks for each validator in the `<data-path>/validator/slashprotection/` directory.
One [YAML file is stored per validator] in the format `<validator-pubkey>.yml` (with no `0x` prefix).

:::note

Set `<data-path>` using the [`--data-path`](../reference/cli/index.md#data-base-path-data-path) command line option.

:::

Teku provides command line options to [import] or [export] the slashing protection file.

:::tip

Teku also supports [doppelganger detection](../how-to/prevent-slashing/detect-doppelgangers.md)
and [validator slashing detection](../how-to/prevent-slashing/detect-slashing.md) to help
prevent slashing.
These are early access features.

:::

## Validator slashing protection file

The slashing protection file records multiple values that protects the validator from incorrectly signing blocks or attestations.

```yaml title="Example"
---
genesisValidatorsRoot: "0x9436e8a630e3162b7ed4f449b12b8a5a368a4b95bc46b941ae65c11613bfa4c1"
lastSignedBlockSlot: 71090
lastSignedAttestationSourceEpoch: 2290
lastSignedAttestationTargetEpoch: 3247
```

The following rules apply to the file:

- A validator signs a block only if the slot number is greater than `lastSignedBlockSlot`.
- A validator signs an attestation when the source epoch of the attestation is equal to or exceeds `lastSignedAttestationSourceEpoch`, and the target epoch of the attestation is greater than `lastSignedAttestationTargetEpoch`.
- `genesisValidatorsRoot` is a hash of the validators active at genesis, and is used to differentiate between different chains.
  Teku does not require this field to be present, but if it is present and differs from the required value, then Teku returns an error.

:::info

You can obtain the `genesisValidatorsRoot` value by using the [`/eth/v1/beacon/genesis`](https://consensys.github.io/teku/#tag/Beacon/operation/getGenesis) API.

:::

These rules guarantee the validator does not sign anything that is slashable.

## Migrate the slashing protection file

Use the Teku command line options to [import] or [export] the slashing protection file. Alternatively, you can manually migrate or create the database.

### Between Teku nodes

If moving a validator from one Teku node to another, you can manually migrate the slashing protection file.

For example, to manually move the file from node A to node B:

1. Stop Teku node A and confirm the process has fully exited and won't be restarted.
1. Remove the validator key from node A, for example from the [`--validator-keys`](../reference/cli/index.md#validator-keys) option.
1. Copy the file from `<nodeA-data-path>/validators/slashprotection/` to `<nodeB-data-path>/validators/slashprotection/`.
1. Start node B with the migrated validator key.
1. Restart node A if required.

### From a non-Teku node

If moving a validator from a different client to Teku, you can do either of the following:

- Manually [create a new slashing protection file] by setting the values based on the validator's last signing details.
- [Import] the slashing protection file.

To manually create the file, stop the other client to ensure it isn't signing, then set the following:

- Set `lastSignedBlockSlot` to the current chain head slot + 1.
- Set `lastSignedAttestationSourceEpoch` to the current justified checkpoint.
- Set `lastSignedAttestationTargetEpoch` to the current epoch + 1.

Start the Teku node with the validator key.

<!-- links -->

[YAML file is stored per validator]: #validator-slashing-protection-file
[create a new slashing protection file]: #validator-slashing-protection-file
[import]: ../how-to/prevent-slashing/use-a-slashing-protection-file.md#import-a-slashing-protection-file
[export]: ../how-to/prevent-slashing/use-a-slashing-protection-file.md#export-a-slashing-protection-file

---

## Weak subjectivity


The weak subjectivity period refers to how far behind the chain head a node can be before 1/3 of
validators may have exited since the node was last in sync.

For example, if 1/3 of validators withdraw their stake and continue signing blocks and attestations,
they can form a chain which conflicts with the finalized state.
If your node is far enough behind the chain head not to be aware that they've withdrawn their funds,
these validators can act dishonestly and continue feeding you blocks to lead you down the wrong chain.

:::note
If a node is aware that a validator has withdrawn its funds, the node will reject the validator's attestations.
:::

At a high-level, the weak subjectivity period is the period of time that a node can be behind the
chain and trust that it is following the correct chain.
In practice, the weak subjectivity mechanism tells Teku if the latest checkpoint is too old to
continue syncing from it (either when starting a new node or after your node has been offline for a while).

## Safely sync your node

Teku provides three methods to safely sync a node that is new to the network or has been offline for an extended period.

1. Use [`--checkpoint-sync-url`](../reference/cli/index.md#checkpoint-sync-url) to supply a URL of a
    checkpoint state endpoint from which to sync.
2. Use [`--initial-state`](../reference/cli/index.md#initial-state) to supply an SSZ encoded state
    file from which to sync.

We recommend using `--checkpoint-sync-url` on Mainnet.

:::tip
Use the [`/eth/v2/debug/beacon/states/<state_id>`](https://consensys.github.io/teku/#tag/Debug/operation/getStateV2)
API on an updated node to download a recent finalized state as an SSZ encoded state file.
:::

Another option is to [reconstruct historical states](../how-to/reconstruct-historical-states.md).
This allows the creation of a full archive node, ensuring that once the node is
up-to-date, the concerns associated with weak subjectivity are cleared.

## Sync outside the weak subjectivity period

Originally, Teku's default behavior was to sync from any point in the chain without the weak
subjectivity check, including syncing all the way from the genesis of the chain.
However, this is considered unsafe.

If you want to allow Teku to sync outside the weak subjectivity period, you can use the
[`--ignore-weak-subjectivity-period-enabled`](../reference/cli/index.md#ignore-weak-subjectivity-period-enabled)
CLI option.

## Learn more

See the following resources to learn more about weak subjectivity:

- [Ethereum weak subjectivity documentation](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/)
- [Proof of Stake: How I Learned to Love Weak Subjectivity](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity)
- [Exploring Ethereum 2: Weak Subjectivity Period](https://www.symphonious.net/2019/11/27/exploring-ethereum-2-weak-subjectivity-period/)

---

## Withdrawals


Validators staking ether on Mainnet, accrue two forms of rewards:

- Execution layer rewards paid directly to a withdrawal address (Ethereum address).
- Consensus layer rewards for performing actions each epoch.

The
[Capella network upgrade](https://notes.ethereum.org/@launchpad/withdrawals-faq#Q-What-is-ShanghaiCapella)
implements an automated process that allows a validator's rewards to be
transferred from the consensus layer to an Ethereum address on the execution layer.
Before the Capella upgrade, consensus layer rewards were locked, and couldn't be
transferred to an Ethereum address.

:::caution

When you create a validator, you can set its withdrawal address to a
[BLS address](https://en.wikipedia.org/wiki/BLS_digital_signature), or an
Ethereum address.
Withdrawal keys configured as BLS keys can't have automated withdrawals executed
for them.

You can
[update your BLS withdrawal address to an Ethereum address](../how-to/update-withdrawal-keys.md)
after the Capella upgrade.

:::

You don't pay gas fees for receiving reward payments.

## Types of withdrawals

Two types of automated withdrawals occur once the withdrawal key is set up as an
Ethereum address: [partial withdrawals](#partial-withdrawals) and
[full withdrawals](#full-withdrawals).

### Partial withdrawals

Partial withdrawals are for active validators that have a balance exceeding 32 ETH.
The network periodically makes transfers to the associated Ethereum address for
validators with a balance exceeding 32 ETH.
This means that a validator's balance periodically reduces to 32 ETH once
Capella becomes the active fork on the network.

### Full withdrawals

Full withdrawals are for validators that have exited the network, and have
waited the necessary time to withdraw their funds.
For these validators, their entire balance is returned to the Ethereum address
associated with the validator key.
The balance can't be transferred until the validator key is associated with an
Ethereum address.

An exited validator can't become active on the network again, and currently (as
of Capella), there's no mechanism for recycling the validator ID that has been exited.

## How it works

From the first Capella slot, block proposers provide up to 16 withdrawals per
proposed block.

Proposers start with validator 1, and find validators that have an Ethereum address as a withdrawal address, and meet one of these criteria:

- They have an excess balance.
- They have exited.

Block proposers select the withdrawals that go into the block.
In each block, up to 16 changes to withdrawal credentials are also allowed,
where an owner of a validator key can
[update their withdrawal key's Ethereum address](../how-to/update-withdrawal-keys.md).
This update is retrieved from a pool, and the order isn't guaranteed.

## Withdrawal keys

Withdrawal keys configured as
[BLS keys](https://en.wikipedia.org/wiki/BLS_digital_signature) can't have
automated withdrawals executed for them.
Users must alter their credentials to specify an Ethereum address for their
withdrawal key.

BLS withdrawal keys are prefixed with `0x00`, whereas Ethereum withdrawal keys
are prefixed with `0x01`.

To determine the type of withdrawal key your validator uses, you can
[query your validator configuration onchain](../how-to/update-withdrawal-keys.md#determine-the-withdrawal-address-type).

:::caution

Don't store your [validator keys](../how-to/use-external-signer/manage-keys.md) and
withdrawal keys in the same location.

:::

---

## Configure Teku to use a builder network


You can connect to a [builder network](../../concepts/builder-network.md) to generate execution
payloads for the [consensus client](../../concepts/node-types.md#consensus-clients).

The builder recommends new blocks that are validated by the consensus client.
If the builder goes down, the local execution client proposes a block instead.

Use the following steps to configure Teku to use a builder network.

## 1. Specify the builder endpoint

Specify the builder endpoint using the [`--builder-endpoint`](../../reference/cli/index.md#builder-endpoint)
command line option.
For example:

```bash
--builder-endpoint="https://builder-relay-sepolia.flashbots.net/"
```

View the [list of relay endpoints](https://github.com/flashbots/mev-boost#usage) for available endpoints.

You can also use external software such as [MEV-Boost](https://github.com/flashbots/mev-boost) to
connect to multiple relays.
For example:

```bash
--builder-endpoint=http://127.0.0.1:18550
```

## 2. Register the validator

You must register your validator with the builder before proposing a block.
On the validator client, enable registration for all validators using the
[`--validators-builder-registration-default-enabled`](../../reference/cli/index.md#validators-builder-registration-default-enabled)
command line option.

To enable registration for specific validators only, use the
[`--validators-proposal-config`](../../reference/cli/index.md#validators-proposer-config) option and
specify the enabled validators in the `proposer_config` field of the
[proposer configuration file](use-proposer-config-file.md).

```json title="proposerConfig.json"
{
  "proposer_config": {
    "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": {
      "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3",
      "builder": {
        "enabled": true,
        "gas_limit": "12345654321"
      }
    }
  },
  "default_config": {
    "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A",
    "builder": {
      "enabled": false
    }
  }
}
```

In this example, validator `0xa057816...` is registered with the builder, but any validator using
the default configuration isn't.

## Example builder configurations

In the following example, Teku is running with the beacon node and validator client in a single process.

```bash
teku \
    --ee-endpoint="http://127.0.0.1:8551"                  \
    --ee-jwt-secret-file="/etc/jwt-secret.hex"             \
    --validators-builder-registration-default-enabled=true \
    --builder-endpoint="http://127.0.0.1:18550"            \
    --validators-proposer-default-fee-recipient="0x6e35733c5af9B61374A128e6F85f553aF09ff89A"
```

In the following example, Teku is running with the beacon node and validator client in separate processes.
The beacon node runs with no validators in a single process, and the validator client maintains keys
in a separate process.
The proposer configuration is managed using a [proposer configuration file](use-proposer-config-file.md),
and the validator client communicates with the beacon node using REST API.

<Tabs>
<TabItem value="Beacon node">

```bash
teku \
    --rest-api-enabled=true                     \
    --ee-endpoint="http://127.0.0.1:8551"       \
    --ee-jwt-secret-file="/etc/jwt-secret.hex"  \
    --builder-endpoint="http://127.0.0.1:18550" \
    --validators-proposer-default-fee-recipient="0x6e35733c5af9B61374A128e6F85f553aF09ff89A"
```

</TabItem>
<TabItem value="Validator client">

```bash
teku validator-client \
    --validators-proposer-config="/etc/teku/proposerConfig.json"
```

</TabItem>
<TabItem value="Proposer configuration">

```json title="proposerConfig.json"
{
  "proposer_config": {
    "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": {
      "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3"
    }
  },
  "default_config": {
    "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A",
    "builder": {
      "enabled": true
    }
  }
}
```

</TabItem>
</Tabs>

In the following example, a validator client is connected to a beacon node that is using the builder
flow, and all keys use a specified fee recipient from the validator client by default.
Each epoch, the validator client will register all of its keys to the specified fee recipient with
the beacon node.

<Tabs>
<TabItem value="Beacon node">

```bash
teku \
    --rest-api-enabled=true                     \
    --ee-endpoint="http://127.0.0.1:8551"       \
    --ee-jwt-secret-file="/etc/jwt-secret.hex"  \
    --builder-endpoint="http://127.0.0.1:18550" \
    --validators-proposer-default-fee-recipient="0x6e35733c5af9B61374A128e6F85f553aF09ff89A"
```

</TabItem>
<TabItem value="Validator client">

```bash
teku validator-client \
    --validators-builder-registration-default-enabled=true \
    --validators-proposer-default-fee-recipient="0x6e35733c5af9B61374A128e6F85f553aF09ff89A"
```

</TabItem>
</Tabs>

---

## Configure TLS


You can configure TLS for communication between Teku and an external signer, for example [Web3Signer].

:::info

The [Teku and Web3Signer TLS configuration tutorial] provides instructions to create the required keystores and configuration.

:::

## Prerequisites

**Web3Signer prerequisites**:

- [Password-protected PKCS12 keystore and password file].
- [Known clients file].

**Teku prerequisites**:

- [Teku's password-protected PKCS12 or JKS keystore and password file].
- [Web3Signer's password-protected PKCS12 or JKS truststore and password file].
- Execution client (for example [Besu]) synced to the required network.

## Start Web3Signer

Start Web3Signer with the TLS configuration options and specify the keystore and known clients file.

```bash
web3signer \
  --key-store-path=/Users/me/keyFiles/                                          \
  --tls-keystore-file=/Users/me/certs/web3signer_keystore.p12                   \
  --tls-keystore-password-file=/Users/me/certs/web3signer_keystore_password.txt \
  --tls-known-clients-file=/Users/me/certs/knownClients.txt                     \
  eth2
```

:::note

[Slashing protection] is enabled by default when using the `eth2` Web3Signer subcommand. If using Web3Signer slashing protection, ensure you [configure your slashing protection database].

:::

## Start Teku

Start Teku with the external signer, keystore, and truststore details.
For example:

```bash
teku \
  --network=hoodi                                                                           \
  --ee-endpoint=http://localhost:8551                                                       \
  --validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b                      \
  --validators-external-signer-url=https://localhost:9000                                   \
  --validators-external-signer-truststore=/Users/me/certs/web3signer_truststore.p12         \
  --validators-external-signer-truststore-password-file=/Users/me/certs/truststore_pass.txt \
  --validators-external-signer-keystore=/Users/me/certs/teku_client_keystore.p12            \
  --validators-external-signer-keystore-password-file=/Users/me/certs/teku_keystore_password.txt
```

In the command:

- Specify the network using [`--network`](../../reference/cli/index.md#network).
- Specify the URL of the execution client's Engine API using [`--ee-endpoint`](../../reference/cli/index.md#ee-endpoint).
- Specify the validator's public keys using [`--validators-external-signer-public-keys`](../../reference/cli/index.md#validators-external-signer-public-keys).
- Specify the URL of the running external signer using [`--validators-external-signer-url`](../../reference/cli/index.md#validators-external-signer-url).
- Specify the truststore and password file using [`validators-external-signer-truststore`](../../reference/cli/index.md#validators-external-signer-truststore) and [`validators-external-signer-truststore-password-file`](../../reference/cli/index.md#validators-external-signer-truststore-password-file).
- Specify the keystore and password file using [`validators-external-signer-keystore`](../../reference/cli/index.md#validators-external-signer-keystore) and [`validators-external-signer-keystore-password-file`](../../reference/cli/index.md#validators-external-signer-keystore-password-file).

<!-- links -->

[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
[Teku and Web3Signer TLS configuration tutorial]: ../../tutorials/configure-external-signer-tls.md
[Password-protected PKCS12 keystore and password file]: ../../tutorials/configure-external-signer-tls.md#web3signer-keystore-and-password-file
[Known clients file]: ../../tutorials/configure-external-signer-tls.md#3-create-the-known-clients-file
[Teku's password-protected PKCS12 or JKS keystore and password file]: ../../tutorials/configure-external-signer-tls.md#teku-keystore-and-password-file
[Web3Signer's password-protected PKCS12 or JKS truststore and password file]: ../../tutorials/configure-external-signer-tls.md#2-create-the-truststore-and-password-file
[Besu]: https://besu.hyperledger.org/public-networks/get-started/install
[Slashing protection]: https://docs.web3signer.consensys.net/en/latest/concepts/slashing-protection/
[configure your slashing protection database]: https://docs.web3signer.consensys.net/en/latest/HowTo/Configure-Slashing-Protection/

---

## Use a configuration file

# Use the Teku configuration file

To specify command line options in a file, use a YAML configuration file.

To specify the configuration file, use the [`--config-file`](../../reference/cli/index.md#config-file) option.

To override an option specified in the configuration file, either specify the same option on the command line or as an [environment variable](../../reference/cli/index.md#specify-options).
For options specified in more than one place, the order of precedence is command line, environment variable, configuration file.

:::note

The configuration file is used for node-level settings.
It is separate from the consensus-specification network configuration that you can supply with
[`--network`](../../reference/cli/index.md#network).

:::

## YAML specification

The configuration file must be a valid YAML file composed of key/value pairs. Each key is the corresponding command line option name without the leading dashes (`--`).

Values must conform to YAML specifications for strings, numbers, arrays, and booleans. Specific differences between the command line and the YAML file format are:

- Comma-separated lists on the command line are string arrays in the YAML file.
- Enclose all string values (including but not limited to file paths, hexadecimal numbers, URLs) in quotes.

:::tip

The [command line reference](../../reference/cli/index.md) includes configuration file examples for each option.

:::

```yaml title="Sample YAML configuration file"
# network
network: "hoodi"

# p2p
p2p-enabled: true
p2p-port: 9000

# validators
validator-keys: "/Users/me/node/hoodi/validator/keys:/Users/me/node/hoodi/validator/passwords"
validators-graffiti: "Teku validator"

# execution client
ee-endpoint: "http://localhost:8551"

# metrics
metrics-enabled: true
metrics-categories: ["BEACON", "LIBP2P", "NETWORK"]

# database
data-path: "/Users/me/tekudata"
data-storage-mode: "archive"

# rest api
rest-api-port: 5051
rest-api-docs-enabled: true
rest-api-enabled: true

# logging
log-include-validator-duties-enabled: true
```

---

## Use a proposer configuration file


You can define complex fee recipient and [builder network](builder-network.md) configurations for multiple validators using a proposer configuration file.
Specify the proposer configuration file using the [`--validators-proposer-config`](../../reference/cli/index.md#validators-proposer-config) command line option.

:::note

To define a single default fee recipient for all validator keys, use the [`--validators-proposer-default-fee-recipient`](../../reference/cli/index.md#validators-proposer-default-fee-recipient) option instead.

:::

## Proposer configuration file attributes

The proposer configuration file is a JSON file that specifies:

- `default_config` - (required) A default proposer configuration containing all default values to be applied to every validator. These values can be overridden for specific validators in `proposer_config`.
- `proposer_config` - (optional) A proposer configuration for multiple validator public keys.

Attributes for each proposer configuration are:

- `fee_recipient` - (optional in `proposer_config` but required in `default_config`) The fee recipient to use when proposing blocks.
- `builder` - (optional) The [builder network configuration](builder-network.md), which includes the following attributes:
  - `enabled` - (optional in `proposer_config` but required in `default_config`) Indicates whether to use the [builder endpoint](../../reference/cli/index.md#builder-endpoint) when proposing blocks.
     The default is `false`.
  - `gas_limit` - (optional) Gas limit for the builder. The default is `36000000`.
  - `registration_overrides` - (optional) Dedicated overrides to use during the registration process.
     Useful for distributed validator technology (DVT) and secret shared validator (SSV) technology.
     The override is specified using the following attributes:
    - `timestamp` - (optional) Timestamp to be used (instead of the current time) in the validator registration message.
    - `public_key` - (optional in `proposer_config` but forbidden in `default_config`) Public key to be used (instead of the validator's public key) in the validator registration message.

Each attribute value, for a given validator key, is determined using the following priority:

1. Specific configuration in `proposer_config`
2. Default configuration in `default_config`
3. Default CLI argument (applicable only to `builder.enabled`)
4. Default value (applicable only to `builder.enabled`)

```json title="Example configuration file"
{
  "proposer_config": {
    "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": {
      "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3",
      "builder": {
        "enabled": true,
        "gas_limit": "35000000"
      }
    },
    "0xa99a76ed7796f7be22d5b7e85deeb7c5677e88e511e0b337618f8c4eb61349b4bf2d153f649f7b53359fe8b94a38e44c": {
      "builder": {
        "enabled": true
      }
    }
  },
  "default_config": {
    "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A",
    "builder": {
      "enabled": false,
      "gas_limit": "25000000"
    }
  }
}
```

In this example, validator `0xa0578...` is configured as:

```json
"fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3",
"builder": {
  "enabled": true,
  "gas_limit": "35000000"
}
```

Validator `0xa99a7...` is configured as:

```json
"fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A",
"builder": {
  "enabled": true,
  "gas_limit": "25000000"
}
```

All other validators are configured as:

```json
"fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A",
"builder": {
  "enabled": false,
  "gas_limit": "25000000"
}
```

## Example configuration file and CLI argument

The following is an example proposer configuration in conjunction with a CLI argument.

```json
{
  "proposer_config": {
    "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": {
      "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3",
      "builder": {
        "gas_limit": "35000000"
      }
    },
    "0xa99a76ed7796f7be22d5b7e85deeb7c5677e88e511e0b337618f8c4eb61349b4bf2d153f649f7b53359fe8b94a38e44c": {
      "builder": {
        "enabled": false
      }
    }
  },
  "default_config": {
    "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A"
  }
}
```

If [`--validators-builder-registration-default-enabled`](../../reference/cli/index.md#validators-builder-registration-default-enabled) is set to `true`:

- Validator `0xa0578...` is configured as:

  ```json
  "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3",
  "builder": {
    "enabled": true,
    "gas_limit": "35000000"
  }
  ```

- Validator `0xa99a7...` is configured as:

  ```json
  "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A"
  "builder": {
    "enabled": false,
    "gas_limit": "30000000"
  }
  ```

- All other validators are configured as:

  ```json
  "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A",
  "builder": {
    "enabled": true,
    "gas_limit": "30000000"
  }
  ```

If [`--validators-builder-registration-default-enabled`](../../reference/cli/index.md#validators-builder-registration-default-enabled) isn't specified (or set to `false`):

- Validator `0xa0578...` is configured as:

  ```json
  "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3",
  "builder": {
    "enabled": false,
    "gas_limit": "35000000"
  }
  ```

- Validator `0xa99a7...` is configured as:

  ```json
  "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A",
  "builder": {
    "enabled": false,
    "gas_limit": "30000000"
  }
  ```

- All other validators are configured as:

  ```json
  "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A",
  "builder": {
    "enabled": false,
    "gas_limit": "30000000"
  }
  ```

## Example configuration file using DVT and SSV

The following is a proposer configuration example using distributed validator technology (DVT) and secret shared validator (SSV) technology.

```json
{
  "proposer_config": {
    "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": {
      "builder": {
        "registration_overrides": {
          "public_key": "0xaef9162ee6f29ee82fbfe387756d84f9ac472eb8709217aaf28f5ef0ea273f6210e531496470b30d2b7747216e3672d5"
        }
      }
    },
    "0xa99a76ed7796f7be22d5b7e85deeb7c5677e88e511e0b337618f8c4eb61349b4bf2d153f649f7b53359fe8b94a38e44c": {
      "builder": {
        "registration_overrides": {
          "public_key": "0xb53d21a4cfd562c469cc81514d4ce5a6b577d8403d32a394dc265dd190b47fa9f829fdd7963afdf972e5e77854051f6f"
        }
      }
    }
  },
  "default_config": {
    "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A",
    "builder": {
      "enabled": true,
      "registration_overrides": {
        "timestamp": "1669285248"
      }
    }
  }
}
```

In this example, the builder is enabled by default, with `timestamp` registration override.
Each validator has its own `public_key` override.
All validators use the same `0x6e35733c5af9B61374A128e6F85f553aF09ff89A` as `fee_recipient`.

---

## Configure IPv6


In [peer-to-peer (P2P) networking](../../concepts/p2p-networking.md), Teku listens over IPv4 by default.
You can configure it to listen over [IPv6](#listen-over-only-ipv6) or
[both (dual-stack)](#listen-over-both-ipv4-and-ipv6-dual-stack).

## Listen over only IPv6

To configure Teku to listen only on IPv6, set the
[`--p2p-interface`](../../reference/cli/index.md#p2p-interface-p2p-interfaces) CLI option to `::`.
The [`--p2p-port`](../../reference/cli/index.md#p2p-port), [`--p2p-udp-port`](../../reference/cli/index.md#p2p-udp-port),
and [`--p2p-quic-port`](../../reference/cli/index.md#p2p-quic-port) CLI options are used for the TCP
transport, discovery, and QUIC transport ports.

In single-stack mode, Teku uses port `9000` for TCP and UDP, and `9001` for QUIC (UDP) by default.

## Listen over both IPv4 and IPv6 (dual-stack)

To configure Teku to listen over both IPv4 and IPv6 (dual-stack), set the
[`--p2p-interface`](../../reference/cli/index.md#p2p-interface-p2p-interfaces) CLI option to
one IPv4 address and one IPv6 address, separated by a comma.
For example, set it to `0.0.0.0,::` to listen on all IPv4 and IPv6 interfaces.

In this setup, the [`--p2p-port`](../../reference/cli/index.md#p2p-port),
[`--p2p-udp-port`](../../reference/cli/index.md#p2p-udp-port), and
[`--p2p-quic-port`](../../reference/cli/index.md#p2p-quic-port) options apply to the IPv4 address.
The [`--p2p-port-ipv6`](../../reference/cli/index.md#p2p-port-ipv6),
[`--p2p-udp-port-ipv6`](../../reference/cli/index.md#p2p-udp-port-ipv6), and
[`--p2p-quic-port-ipv6`](../../reference/cli/index.md#p2p-quic-port-ipv6) options apply to the IPv6 address.

In dual-stack mode, Teku uses the following ports by default:

- On IPv4: `9000` for TCP and UDP, and `9001` for QUIC (UDP)
- On IPv6: `9090` for TCP and UDP, and `9091` for QUIC (UDP)

:::note Listen on the same port

In dual-stack mode, you can set an IPv6 listening port to the same value as its corresponding IPv4 port.
If the ports match and [`--p2p-interface`](../../reference/cli/index.md#p2p-interface-p2p-interfaces)
includes the IPv6 wildcard address (`::`), Teku binds a single IPv6 wildcard listener for that
port, accepting both IPv4 and IPv6 connections on all interfaces.
This applies independently to the TCP, UDP discovery, and QUIC ports.

:::

## Advertise only the IPv6 address

To advertise only the IPv6 public address to the network, use the
[`--p2p-advertised-ip`](../../reference/cli/index.md#p2p-advertised-ip-p2p-advertised-ips) CLI option.
This is similar to advertising an IPv4 address.

You can configure the advertised ports using the
[`--p2p-advertised-port`](../../reference/cli/index.md#p2p-advertised-port) and
[`--p2p-advertised-quic-port`](../../reference/cli/index.md#p2p-advertised-quic-port) options.

## Advertise both IPv4 and IPv6 addresses (dual-stack)

To advertise both the IPv4 and IPv6 public addresses to the network, use the
[`--p2p-advertised-ips`](../../reference/cli/index.md#p2p-advertised-ip-p2p-advertised-ips) CLI
option and provide the two addresses, separated by a comma.

You can configure the advertised ports for the IPv4 address using the
[`--p2p-advertised-port`](../../reference/cli/index.md#p2p-advertised-port) and
[`--p2p-advertised-quic-port`](../../reference/cli/index.md#p2p-advertised-quic-port) options.

You can configure the advertised port for the IPv6 address using the
[`--p2p-advertised-port-ipv6`](../../reference/cli/index.md#p2p-advertised-port-ipv6) and
[`--p2p-advertised-quic-port-ipv6`](../../reference/cli/index.md#p2p-advertised-quic-port-ipv6) options.

---

## Connect to specific peers


By default, Teku uses [discovery](../../concepts/p2p-networking.md#peer-discovery-and-enr) to find and connect to peers automatically.
In some cases, you might want Teku to connect to specific peers, such as nodes you operate across different
regions.

Teku provides multiple mechanisms to connect to specific peers:

- [Static peers](#static-peers) - Peers that Teku maintains a connection to, configured at startup.
- [Direct peers](#direct-peers) - Static peers that always exchange full messages, configured reciprocally.
- [The `add_peer` API](#add-a-static-peer-at-runtime) - Add a static peer at runtime without restarting Teku.

:::info

When you specify a peer, use one of its transport
[multiaddresses](https://libp2p.io/concepts/fundamentals/addressing/) from the `p2p_addresses` field
of the [`/eth/v1/node/identity`](https://consensys.github.io/teku/#tag/Node/operation/getNetworkIdentity)
API endpoint.

:::

## Static peers

Use the [`--p2p-static-peers`](../../reference/cli/index.md#p2p-static-peers) option to specify a
comma-separated list of peer multiaddresses to maintain connections with.
Teku connects to each static peer at startup and keeps trying to reconnect if the connection drops.

```bash title="Example"
--p2p-static-peers=/ip4/192.0.2.10/tcp/9000/p2p/16Uiu2HA...aXRz,/ip4/192.0.2.11/tcp/9000/p2p/16Uiu2HA...q6f1
```

Static peers take precedence over dynamically discovered peers, so Teku connects to them even when its peer
table is full.

To load the static peer list from a URL instead of listing addresses directly, use
[`--p2p-static-peers-url`](../../reference/cli/index.md#p2p-static-peers-url).

:::note

A static peer is a one-sided declaration.
If the remote node's peer table is full, it can still reject the incoming connection.
For a reliable, persistent connection between two known nodes, use [direct peers](#direct-peers) and
configure both nodes to point to each other.

:::

## Direct peers

Use the [`--p2p-direct-peers`](../../reference/cli/index.md#p2p-direct-peers) option to specify a
comma-separated list of direct peer multiaddresses.
Direct peers are static peers that always exchange full messages, regardless of peer scoring mechanisms.

```bash title="Example"
--p2p-direct-peers=/ip4/192.0.2.10/tcp/9000/p2p/16Uiu2HA...aXRz,/ip4/192.0.2.11/tcp/9000/p2p/16Uiu2HA...q6f1
```

Direct peers must be configured reciprocally.
Each node must list the other node as a direct peer for the connection to work.
This is the recommended way to maintain a persistent connection between two nodes that you operate.

## Add a static peer at runtime

Use the [`/teku/v1/admin/add_peer`](https://consensys.github.io/teku/#tag/Teku/operation/AddPeer) API endpoint to add a
static peer at runtime, without restarting Teku.
Send a `POST` request to the endpoint with the peer's multiaddress as a JSON string in the request body.

```bash title="Example"
curl -X POST "http://127.0.0.1:5051/teku/v1/admin/add_peer" \
  -H "Content-Type: application/json" \
  -d '"/ip4/192.0.2.10/tcp/9000/p2p/16Uiu2HA...aXRz"'
```

The endpoint returns the following responses:

- `200` - The peer address is valid and Teku added it to the static peer list.
- `400` - The peer address is invalid.
- `500` - An internal error occurred, for example, the discovery network is unavailable.

The request is idempotent, so adding the same peer multiple times returns `200` each time.

:::note

A `200` response means Teku accepted the request and stored the peer as a static peer.
It does not mean the peer is connected.
Teku attempts the connection asynchronously and retries with an increasing delay if it fails.

:::

To establish a connection between two nodes dynamically, call `add_peer` on both nodes, with each node
pointing to the other node's address.
Because this is a runtime configuration, the static peer list added through the API is not persisted across
restarts.
To make the connection persistent, use [`--p2p-direct-peers`](#direct-peers) on both nodes.

## Verify a peer is connected

Use the [`/eth/v1/node/peers/{peer_id}`](https://consensys.github.io/teku/#tag/Node/operation/getPeer) API
endpoint to look up a single peer by its ID:

```bash title="Example"
curl "http://127.0.0.1:5051/eth/v1/node/peers/16Uiu2HA...aXRz"
```

If the peer is in the node's peer set, Teku returns its record, including the connection state and
direction.
If the peer is not present, Teku returns a `404` response.

To see connection attempts and retries, enable [debug logging](../../reference/cli/index.md#logging).
When Teku connects to a static peer, it logs messages such as:

```bash
Connecting to peer <PEER_ADDRESS>
Connection to peer <PEER_ID> was successful
```

If the connection fails or the peer disconnects, Teku logs the retry attempt:

```bash
Connection to <PEER_ADDRESS> failed: <ERROR>. Will retry in <N> sec
Peer <PEER_ADDRESS> disconnected. Will try to reconnect in <N> sec
```

---

## Improve peer-to-peer connectivity


The consensus layer relies on [peer-to-peer (P2P) networking](../../concepts/p2p-networking.md).
By having a good peer count you increase the performance and health of your node.
When a Teku node starts up, it looks for participants on the P2P network by listening for incoming connections, and finds and connects to peers.

While Teku is good at finding peers, changes to your network configuration can help improve your peer count.

## Advertise your public IP address

If you are using a NAT, it's easier to get peers by advertising your public address to the network.
Use the [`--p2p-advertised-ip`](../../reference/cli/index.md#p2p-advertised-ip-p2p-advertised-ips) option to advertise the address publicly.

Additionally, if on a home network, [configure port forwarding](#configure-ports) on your router.

:::tip

Check the [`ip4.me`](http://ip4.me/) website to view your public IP address.

:::

## Configure ports

By default, Teku uses two [P2P ports](../../concepts/p2p-networking.md#p2p-port-options) across three
protocols:

- `9000/tcp` and `9000/udp` for the TCP transport and peer discovery (configured with
  [`--p2p-port`](../../reference/cli/index.md#p2p-port)).
- `9001/udp` for the QUIC transport (configured with
  [`--p2p-quic-port`](../../reference/cli/index.md#p2p-quic-port)).

Configure port forwarding on your router and firewall to allow incoming and outgoing connections on
these ports and protocols.

View your router or firewall documentation to configure port-forwarding.

## Check readiness with a peer count

Check the readiness of your node by using the [`get node readiness` API](https://consensys.github.io/teku/#tag/Teku/operation/readiness).
This check helps to prevent a beacon from receiving traffic from validators while the node is not being connected to enough peers.

You can specify a number in the `target_peer_count` parameter to require a minimum number of peers before the node is considered ready.

:::note

Make sure to [enable the REST API service](../../reference/rest.md#enable-the-rest-api-service).

:::

---

## Run Teku as a bootnode


## What is a bootnode?

When a new node joins the Ethereum network, it must connect to other nodes in the same network. This
process is referred to as peering.

Ethereum uses the Discovery protocol to find new peers. The process starts with a small set of nodes, known
as bootnodes, that are hard coded into Ethereum clients. The Discovery protocol allows nodes to locate and
exchange information about active peers, enabling them to dynamically join the network without needing a
full list of known nodes.

You can specify additional bootnodes using the [`--p2p-discovery-bootnodes`](../../reference/cli/index.md#p2p-discovery-bootnodes) option.

:::note
Any Teku instance running as a beacon node already participates in the Discovery protocol and can serve
as a bootnode.
:::

Most users don’t need to run a bootnode. This mode is primarily useful for client teams, infrastructure
providers, or others who want to contribute to the health and connectivity of the Ethereum network.
Running a bootnode helps new nodes discover peers more reliably, but doesn't provide direct benefits to the operator.

## Run Teku in bootnode-only mode

You can run Teku in bootnode-only mode when you don't want to operate a full beacon node.
When running in bootnode-only mode, Teku will only enable its Discovery service.

In this mode, Teku only runs its Discovery service and doesn't:

- Synchronize with the chain
- Validate or produce blocks
- Respond to Beacon API queries.

To run Teku in bootnode-only mode, start Teku with the [`bootnode`](../../reference/cli/subcommands/bootnode.md) subcommand:

```bash
teku bootnode <extra_options>
```

Here is an example of common options used for a mainnet bootnode:

```bash
teku bootnode \
  --network="mainnet" \
  --p2p-port=9000 \
  --p2p-advertised-ip=116.250.191.71 \
  --p2p-private-key-file=/opt/data/node-key.txt
```

This example configures a bootnode for Ethereum mainnet. It sets:

- The network to `mainnet`
- The external communication port using [`--p2p-port`](../../reference/cli/index.md#p2p-port)
- The public IP address using [`--p2p-advertised-ip`](../../reference/cli/index.md#p2p-advertised-ip-p2p-advertised-ips)
- A persistent private key file using [`--p2p-private-key-file`](../../reference/cli/index.md#p2p-private-key-file)

Using a persistent private key ensures the bootnode has a stable Ethereum Node Record (ENR), which others
can use to connect reliably.

---

## Specify NAT methods


Use the [`--p2p-nat-method`](../../reference/cli/index.md#p2p-nat-method) option to specify the NAT method. Options are [`NONE`](#none) and [`UPNP`](#upnp).

You cannot change the NAT method while Teku is running. To change the NAT method restart the node with the [`--p2p-nat-method`](../../reference/cli/index.md#p2p-nat-method) option.

## UPnP

Specify `UPNP` to quickly allow inbound peer connections without manual router configuration. Use UPnP in home or small office environments where a wireless router or modem provides NAT isolation.

UPnP automatically detects if a node is running in a UPnP environment and provides port forwarding. UPnP might introduce delays during node startup, especially on networks without a UPnP gateway device.

:::tip

UPnP support is often disabled by default in networking firmware. If disabled by default, you must explicitly enable UPnP support.

:::

## None

Specify `NONE` to explicitly configure the external IP address and ports advertised using [`--p2p-advertised-ip`](../../reference/cli/index.md#p2p-advertised-ip-p2p-advertised-ips) and [`--p2p-advertised-port`](../../reference/cli/index.md#p2p-advertised-port) for the P2P service.

Manually configure your firewall to allow external hosts to create inbound connections to Teku.

---

## Load validators without restarting

# Load validators without restarting Teku

You can load validators into a running Teku process, only if you started Teku by:

- Specifying a directory using [`--validator-keys`](../reference/cli/index.md#validator-keys), or
- Specifying a URL using [`--validators-external-signer-public-keys`](../reference/cli/index.md#validators-external-signer-public-keys).

:::caution

- If you started Teku by specifying individual validator key files or external signer public keys, then you must restart Teku.
- You must restart Teku to remove validators.

:::

**Prerequisites:**

- Add the new validators to the directory specified in [`--validator-keys`](../reference/cli/index.md#validator-keys), or ensure the URL supplied in [`--validators-external-signer-public-keys`](../reference/cli/index.md#validators-external-signer-public-keys) contains the new public keys.

To load the validators in a running Teku instance, send a `SIGHUP` signal to the Teku process.

```bash
kill -HUP <PID>
```

Where `<PID>` is the process ID of the running Teku instance.

---

## Migrate the database


Teku version 26.2.0 and later use RocksDB as the default database for new installations.
Earlier Teku versions use LevelDB. LevelDB support has been deprecated and may be removed in a future release.

RocksDB databases use less memory and proves to be more stable with Teku.

:::caution

We recommend Teku nodes running in [`prune` mode] or [`minimal` mode] (default) use the [manual migration](#manual-migration),
 and Teku nodes running in [`archive` mode] use the [automatic migration](#automatic-migration) method.

:::

## Automatic migration

Teku nodes running in [archive mode] must resynchronize from genesis to migrate from LevelDB to RocksDB.
Use the [`migrate-database`](../reference/cli/subcommands/migrate-database.md) subcommand to migrate the database.
Once migration completes there will be two databases in Teku's data folder.
Manually verify that Teku starts and has the expected data before you remove old LevelDB database.

:::note

You need double the disk space of the existing Teku storage folder for the migration process. Once you are satisfied with the migration then you can delete the LevelDB to free up space.

:::

Ensure that Teku isn't running when using the [`migrate-database`](../reference/cli/subcommands/migrate-database.md) subcommand.
The duration of the migration depends on various factors, but principally on the disk speed.
Status updates display during the migration process.
To migrate the database:

1. Shut down the local Teku instance.

2. Run [`migrate-database`](../reference/cli/subcommands/migrate-database.md) to create a RocksDB database.
    Pass your [configuration file](configure/use-config-file.md) or CLI options so that Teku has the correct paths and context.

    ```bash title="Example"
    teku migrate-database --data-path /etc/teku/data/
    ```

    At a minimum, provide the [`--network`](../reference/cli/subcommands/migrate-database.md#network) and [`--data-path`](../reference/cli/subcommands/migrate-database.md#network) options.

    :::note

    If not supplied [`--network`](../reference/cli/subcommands/migrate-database.md#network) defaults to `mainnet`.

    :::

3. The migration process informs you if it succeeded, or provides context to errors. If successful, then confirm Teku functions correctly.

    ```bash title="Example"
    teku --data-path /etc/teku/data/
    ```

4. If Teku is running correctly, remove the `beacon.old` directory from the [`--data-path`](../reference/cli/subcommands/migrate-database.md#network) directory.

If migration fails, resolve any issues and retry. Contact support on the [Teku Discord channel] if you need help resolving issues.

## Manual migration

Users can manually migrate Teku nodes running a LevelDB database to a RocksDB database if the Teku node runs in [`prune` mode] or [`minimal` mode] (default).

:::caution

Teku nodes running in [archive mode] must resynchronize from genesis to migrate. Use the [automatic migration](#automatic-migration) to migrate Teku nodes running in [archive mode].

:::

To migrate a LevelDB database in [`minimal` mode] or [`prune` mode] to a RocksDB database:

1. Stop the Teku node you intend to migrate.

2. Clear the beacon database, either:
    - Restart Teku with
   [`--force-clear-db`](../reference/cli/index.md#force-clear-db)
    - Manually delete the `beacon/db` directory in your [data path](../reference/cli/index.md#data-base-path-data-path) and `beacon/db.version` file.

    :::warning

    If you manually delete, ensure not to delete the `validator` directory if one is present as this contains your slashing protection data.

    :::

3. Add the [`--checkpoint-sync-url`](../reference/cli/index.md#checkpoint-sync-url) option with link to any community state provider to Teku command line and start Teku.
 Check [Start Teku from a recent state] for more information.

Teku creates a RocksDB database, and starts from the specified recent state. Teku should be in sync and validating within minutes.

<!-- links -->

[`minimal` mode]: ../reference/cli/index.md#data-storage-mode
[`prune` mode]: ../reference/cli/index.md#data-storage-mode
[`archive` mode]: ../reference/cli/index.md#data-storage-mode
[Start Teku from a recent state]: ../get-started/checkpoint-start.md
[Teku Discord channel]: https://discord.gg/teku

---

## Configure logging


Teku uses Log4J2 for logging, and provides multiple methods to configure logging behavior:

- [Basic](#basic-log-level-settings) - changes the log level.
- [Destination logging](#configure-log-destination) - configures the destination for log output.
- [Custom logging](#advanced-custom-logging) - custom logging to configure the output and format of the logs.

The default log directory is OS dependent:

- macOS: `~/Library/teku/logs`
- Unix/Linux: `$XDG_DATA_HOME/teku/logs` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku/logs`

The default Docker image location is `/root/.local/share/teku/logs`.

## Basic log level settings

Use the [`--logging`](../../reference/cli/index.md#logging) command line option to specify logging verbosity.
The [`--logging`](../../reference/cli/index.md#logging) option changes the volume of events displayed in the log.
Valid log levels are `OFF`, `FATAL`, `ERROR`, `WARN`, `INFO`, `DEBUG`, `TRACE`, `ALL`. The default level is `INFO`.

By default most logging output is sent to the log file, and limited content shown on the console.

:::tip

Use the [`log_level`](https://consensys.github.io/teku/#tag/Teku/operation/putLogLevel) API method to change the log level while Teku is running.

:::

Additional logging options include:

- [`--log-color-enabled`](../../reference/cli/index.md#log-color-enabled) displays status and event log messages in different colors on the console
- [`--log-include-events-enabled`](../../reference/cli/index.md#log-include-events-enabled) logs frequent update events. For example, every slot event with validators and attestations.
- [`--log-include-validator-duties-enabled`](../../reference/cli/index.md#log-include-validator-duties-enabled) logs details of validator event duties.

## Configure log destination

Use the [`--log-destination`](../../reference/cli/index.md#log-destination) command line option to specify where to output log information.
Valid options are `BOTH`, `CONSOLE`, `DEFAULT_BOTH`, `FILE`. Defaults to `DEFAULT_BOTH`.

When using `BOTH` or `DEFAULT_BOTH`, system updates such as blockchain events are displayed on the console, and errors and other information are logged to a file.
Specify the log file with the [`--log-file`](../../reference/cli/index.md#log-file) command-line option.

Use `DEFAULT_BOTH` when using a [custom Log4J2 configuration file](#advanced-custom-logging). Any other option applies the custom logging changes on top of its default settings.

:::note

For production systems we recommend using the `CONSOLE` or `FILE` options to ensure all log information is available in one place.

:::

## Advanced custom logging

You can provide your own logging configuration using the standard Log4J2 configuration mechanisms.

```xml title="debug.xml"
<?xml version="1.0" encoding="UTF-8"?>
<Configuration level="INFO">
  <Properties>
    <Property name="root.log.level">INFO</Property>
  </Properties>

  <Appenders>
    <Console name="Console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSSZZZ} | %t | %-5level | %c{1} | %msg %throwable%n" />
    </Console>
  </Appenders>
  <Loggers>
    <Root level="${sys:root.log.level}">
      <AppenderRef ref="Console" />
    </Root>
  </Loggers>
</Configuration>
```

To use your custom configuration, set the environment variable `LOG4J_CONFIGURATION_FILE` to the location of your configuration file, and ensure
[`--log-destination`](../../reference/cli/index.md#log-destination) is not set to `DEFAULT_BOTH`.

If you have more specific requirements, you can create your own [log4j2 configuration](https://logging.apache.org/log4j/2.x/manual/configuration.html).

For Bash-based executions, you can set the variable for only the scope of the program execution by setting it before starting Teku.

```bash title="Example"
LOG4J_CONFIGURATION_FILE=./debug.xml teku [OPTIONS]
```

---

## Update metrics


Manually update Teku metrics for your custom dashboard.

With the upgrade of the Prometheus library, Teku introduces the following changes to metric names:

- Gauge names are not allowed to end with `total`, so metrics such as `beacon_proposers_data_total` and `beacon_eth1_current_period_votes_total` are dropping the `_total` suffix.
- The `_created` timestamps are not returned by default.
- Some JVM metric names are changing to adhere to the OTEL standard.

If you are using a custom dashboard, you must update the metric names to reflect these changes.  

The following table lists the name changes for Teku metrics:

| Previous Teku metric name                | New Teku metric name               |
|------------------------------------------|------------------------------------|
| `beacon_proposers_data_total`            | `beacon_proposers_data`            |
| `beacon_eth1_current_period_votes_total` | `beacon_eth1_current_period_votes` |
| `jvm_memory_bytes_committed`             | `jvm_memory_committed_bytes`       |
| `jvm_memory_bytes_init`                  | `jvm_memory_init_bytes`            |
| `jvm_memory_bytes_max`                   | `jvm_memory_max_bytes`             |
| `jvm_memory_bytes_used`                  | `jvm_memory_used_bytes`            |
| `jvm_memory_pool_bytes_committed`        | `jvm_memory_pool_committed_bytes`  |
| `jvm_memory_pool_bytes_init`             | `jvm_memory_pool_init_bytes`       |
| `jvm_memory_pool_bytes_max`              | `jvm_memory_pool_max_bytes`        |
| `jvm_memory_pool_bytes_used`             | `jvm_memory_pool_used_bytes`       |

---

## Use metrics

# Use metrics to monitor performance

Enable the [Prometheus](https://prometheus.io/) monitoring and alerting service for Teku metrics using the [`--metrics-enabled`](../../reference/cli/index.md#metrics-enabled) option.

## Install Prometheus

To use Prometheus with Teku, install the [Prometheus main component](https://prometheus.io/download/). On macOS, install with [Homebrew](https://formulae.brew.sh/formula/prometheus):

```bash
brew install prometheus
```

## Setting up and running Prometheus with Teku

To configure Prometheus and run with Teku:

1. Configure Prometheus to poll Teku. For example, add the following YAML fragment to the `scrape_configs` block of the `prometheus.yml` file:

    ```yaml title="Example configuration"
    global:
      scrape_interval: 15s
    scrape_configs:
      - job_name: "prometheus"
        static_configs:
          - targets: ["localhost:9090"]
      - job_name: "teku-dev"
        scrape_timeout: 10s
        metrics_path: /metrics
        scheme: http
        static_configs:
          - targets: ["localhost:8008"]
    ```

2. Start Teku with the [`--metrics-enabled`](../../reference/cli/index.md#metrics-enabled) option. To start a node for testing with metrics enabled:

    ```bash
    teku --eth1-deposit-contract-address=dddddddddddddddddddddddddddddddddddddddd \
    --ee-endpoint=http://localhost:8551 --validators-key-file=validator_keys \
    --p2p-port=9000 --rest-api-enabled=true --rest-api-docs-enabled=true \
    --metrics-enabled=true --metrics-categories=BEACON,PROCESS,LIBP2P,JVM,NETWORK,PROCESS
    ```

    :::warning

    To avoid DNS rebinding attacks, if running Prometheus on a different host to your Teku node
    (any host other than `localhost`), ensure you add the hostname that Prometheus uses to connect
    to Teku to [`--metrics-host-allowlist`](../../reference/cli/index.md#metrics-host-allowlist).

    For example, if Prometheus is configured to get metrics from `http://teku.local:8008/metrics` then `teku.local` has to be in `--metrics-host-allowlist`.

    :::

    To specify the host and port on which Prometheus accesses Teku, use the
    [`--metrics-interface`](../../reference/cli/index.md#metrics-interface) and
    [`--metrics-port`](../../reference/cli/index.md#metrics-port) options.
    The default host and port are 127.0.0.1 and 8008.

3. In another terminal, run Prometheus specifying the `prometheus.yml` file:

    ```bash
    prometheus --config.file=prometheus.yml
    ```

4. View the [Prometheus graphical interface](#view-prometheus-graphical-interface).

:::tip

Use a log ingestion tool, such as Logstash, to parse the logs and alert you to configured anomalies.

:::

## View Prometheus graphical interface

1. Open a web browser to `http://localhost:9090` to view the Prometheus graphical interface.

2. Choose **Graph** from the menu bar and click the **Console** tab below.

3. From the **Insert metric at cursor** drop-down, select a metric such as `libp2p_peers` or `beacon_finalized_epoch` and click **Execute**. The values display.

    :::note

    The available metrics are prefixed with the category type specified using [`--metrics-categories`](../../reference/cli/index.md#metrics-categories).

    The [Beacon Chain metrics] lists the minimum set of metrics implemented by beacon nodes.

    :::

Click the **Graph** tab to view the data as a time-based graph. The query string displays below the graph.

## Visualize collected data

Use [Grafana] to visualize the collected data. See the sample [Teku Grafana dashboard](https://grafana.com/grafana/dashboards/13457).

<!-- Links -->

[Beacon Chain metrics]: https://github.com/ethereum/beacon-metrics/blob/master/metrics.md
[Grafana]: https://grafana.com/docs/grafana/latest/guides/getting_started/

---

## Detect doppelgangers


Doppelganger detection checks if the validators' keys are already active before scheduling any of their duties (the validators stay inactive for at most two epochs). This can help prevent slashing offenses.

When enabled, doppelganger detection is triggered from two entry points:

1. At [validator client startup](../../get-started/start-teku.md): If at least one
    doppelganger is detected, the Teku validator client shuts down after it finishes the check with
    exit code `2`.
    When this happens, you should not restart Teku by default because validators will likely be slashed.
2. When importing keys via the [key manager API](https://ethereum.github.io/keymanager-APIs/): Any detected
    doppelganger's keys are ignored (not imported).
    The other keys are imported and the validators start performing their duties after it finishes the check.

:::warning

Doppelganger detection is imperfect and might fail to detect doppelgangers.
Use this as a last resort option that might prevent validators from being slashed.

:::

## Enable doppelganger detection

Enable doppelganger detection by setting the
[`--doppelganger-detection-enabled`](../../reference/cli/index.md#doppelganger-detection-enabled)
option to `true`.

Your validator client must be connected to a beacon node with validator liveness tracking enabled.
Enable validator liveness tracking by setting the [`--beacon-liveness-tracking-enabled`](../../reference/cli/index.md#beacon-liveness-tracking-enabled) option to `true`.

## Side effects

Doppelganger detection runs until one of the following occurs:

- All the loaded keys are detected as active.
- The check runs for two epochs.

This means that the validators being checked are inactive for at most two epochs.

:::warning

Keeping the validators inactive might cause:

- Missed attestations.
- Missed sync committee contributions.
- Missed block proposals.

These side effects result in penalties and missed rewards.

:::

You might still consider these side effects a worthwhile trade-off of doppelganger detection, since it can prevent slashing.

## Logs

When running, doppelganger detection prints various logs.

```bash title="Example startup logs"
Starting doppelganger detection for public keys: b28ab22, c2bab15, cd26f5e
```

```bash title="Example logs when a check is performed (every 12 seconds)"
Performing doppelganger check. Epoch 148220, Public keys b28ab22, c2bab15, cd26f5e
```

```bash title="Example logs when a doppelganger is detected"
Detected 2 validators doppelganger:
Index: xxxxxx, Public key: 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
Index: xxxxxx, Public key: 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002
```

```bash title="Example logs: list of detected doppelgangers"
Detected 5 validators doppelganger:
  Index: xxxxxx, Public key: 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
  Index: xxxxxx, Public key: 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002
  Index: xxxxxx, Public key: 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003
  Index: xxxxxx, Public key: 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004
  Index: xxxxxx, Public key: 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005
```

```bash title="Example logs when doppelganger detection ends"
Doppelganger detection check finished. Stopping doppelganger detection for public keys b28ab22, c2bab15, cd26f5e
```

---

## Stop Teku when a validator is slashed


Validator slashing detection monitors slashing events and shuts down Teku when any owned validator
is slashed.
This can help prevent further slashing offenses.

When a validator is slashed, the Teku validator client shuts down with exit code `2`.
When this happens, you should not restart Teku by default because validators will likely continue to
be slashed.
We recommend restarting Teku with [doppelganger detection](detect-doppelgangers.md) enabled.

If you are using `systemd` to manage the Teku service, you might need to add `Restart=on-success` to
your service config in order to prevent the auto restart.  
Please check [the systemd config documentation](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#Restart=) for more details.

:::warning

This feature is imperfect and might fail to detect slashing events rapidly.
Use it as a last resort option that might prevent validators from being slashed.

:::

## Enable validator slashing detection

Enable validator slashing detection by setting the `--shut-down-when-validator-slashed-enabled`
option to `true`.

When a validator is slashed, you must remove it from the owned validators before restarting Teku with validator slashing detection enabled.
Otherwise, the validator will still be detected as slashed and Teku will shut down again.
The duties performed by a slashed validator are ignored, and it's queued for exit after being slashed.
If you wish to keep it running, you should disable validator slashing detection before restarting Teku.

:::warning

When running a separate validator client, it must be connected to a beacon node that supports the
`proposer_slashing` and `attester_slashing` SSE event streams (both supported by the Teku beacon node).

:::

## Side effects

The purpose of shutting down Teku when a validator is slashed is to prevent a massive slashing.  
When triggered, the Teku validator client terminates and all its running validators stop performing
their duties.

:::warning

Stopping the validators might cause:

- Missed attestations.
- Missed sync committee contributions.
- Missed block proposals.

These side effects result in penalties and missed rewards.

:::

You might still consider these side effects a worthwhile trade-off of validator slashing detection,
since it can prevent a massive slashing.

## Logs

When validator slashing detection is enabled, Teku will print logs when any owned validator is slashed.
For example:

```bash
Validator(s) with public key(s) 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001, 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002 got slashed.  Shutting down...
```

---

## Use a slashing protection file


Teku implements [slashing protection] to prevent validators from signing incorrect blocks or attestations.

You can import and export the slashing protection file when migrating validator keys between validator clients.
Teku supports the [validator client interchange format] when importing or exporting the slashing protection file.

:::note

If using an external signer that implements its own slashing protection (for example [Web3Signer]), then you can disable Teku's built-in slashing protection using the
[`--validators-external-signer-slashing-protection-enabled`](../../reference/cli/index.md#validators-external-signer-slashing-protection-enabled) command line option.

:::

## Import a slashing protection file

When importing the slashing protection file, Teku imports the file to the `<data-path>/validators/slashprotection/` directory in the format `<validator-pubkey>.yml` (with no 0x prefix).

```bash title="Example"
teku slashing-protection import --data-path=/home/me/me_node --from=/home/slash/slashing-interchange-format.json
```

In the command line:

- [`--data-path`](../../reference/cli/subcommands/slashing-protection.md#data-path-1) specifies the location of the Teku `data` directory.
- [`--from`](../../reference/cli/subcommands/slashing-protection.md#from) specifies the location of the slashing protection file.

In this example, Teku imports the file to the `/home/me/me_node/data/validators/slashprotection/` directory.

## Export a slashing protection file

Export the slashing protection file when migrating a validator to a different Teku, or non-Teku node.

```bash title="Example"
teku slashing-protection export --data-path=/home/me/me_node --to=/home/slash/slashing-interchange-format-minimal.json
```

In the command line:

- [`--data-path`](../../reference/cli/subcommands/slashing-protection.md#data-path) specifies the location of the Teku `data` directory.
- [`--to`](../../reference/cli/subcommands/slashing-protection.md#to) specifies the file to export the slashing protection data to.

You can now import the slashing protection file in a Teku, or non-Teku node.

<!--links -->

[slashing protection]: ../../concepts/slashing-protection.md
[validator client interchange format]: https://eips.ethereum.org/EIPS/eip-3076
[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/

---

## Reconstruct historical states


An archive node can reconstruct historical states from genesis up to the current
checkpoint, running during startup.
This allows you to create a full archive node while also using checkpoint sync.
Generating states this way is faster as many validations can be safely skipped.
It also avoids [weak subjectivity concerns](../concepts/weak-subjectivity.md).

## Configuration

To configure Teku to reconstruct historical states, set
[`--reconstruct-historic-states`](../reference/cli/index.md#reconstruct-historic-states)
to `true` and
[`--data-storage-mode`](../reference/cli/index.md#data-storage-mode) to
`"archive"`.

You can also set [`--genesis-state`](../reference/cli/index.md#genesis-state).
Otherwise, network defaults are used (such as Mainnet defaults).

---

## General issues


## Out of memory error

If Teku exits with a `java.lang.OutOfMemoryError: Java heap space` error, it could mean that Teku's Java Virtual Machine (JVM) ran out of memory.

To fix this, you can try [setting a maximum heap size].

## P2P port conflicts

If Teku fails to start with a `P2P Port 9000 (TCP/UDP) is already in use. Check for other processes using this port.` error, it means that Teku is trying to use a network port that is already in use.

For example, Teku and Lighthouse both use port 9000 by default for P2P traffic. You can change Teku's default port number with the [`--p2p-port`](../../reference/cli/index.md#p2p-port) option.

## Unable to lock a keystore file

If Teku fails to start with an `Unexpected error when trying to lock a keystore file` error, this could be because the directory containing the keystores is not writable by Teku.

Teku uses a file locking mechanism for the keystores to prevent two validator clients using the same keystores at the same time.

To resolve this issue, try one of the following:

- Set the permissions of the directory holding the keystores so that it is writable by Teku.
- Set [`--validators-keystore-locking-enabled`](../../reference/cli/index.md#validators-keystore-locking-enabled) to `false` to disable the locking functionality.

:::warning

Ensure no other process or clients are using your keys. If they are, you could get [slashed].

:::

## Keystore file already in use

If Teku fails to start with a `Keystore file <keystore_file>.lock already in use.` error,
this could mean the keystore file is already being used by a validator client, or Teku has exited unexpectedly and did not remove the lock.

Teku uses a file locking mechanism for the keystores to prevent two validator clients using the same keystores at the same time.

To resolve this issue, try one of the following:

- Manually remove the lock files that are created alongside your keystore files, with `.lock` appended to the filename. Take care not to delete your keystores.
- Set [`--validators-keystore-locking-enabled`](../../reference/cli/index.md#validators-keystore-locking-enabled) to `false` to disable the locking functionality.

:::warning

Ensure no other process or clients are using your keys. If they are, you could get [slashed].

:::

## Keystore files are loading slowly

Teku supports `scrypt` or `pbkdf2` formatted keystores. Both keystore formats are supported by [EIP-2335].

The `scrypt` formatted keystores load slower and require more memory to load, whereas `pbkdf2` formatted keystores load instantly.

The `scrypt` formatted keystores are more secure because they require more resources to crack. To improve the loading times of your keystores, you can convert them to the `pbkdf2` format.

## Unable to read YAML configuration

If Teku fails to start with the following:

```bash
Unable to read yaml configuration. Invalid yaml file [config.yaml]:
java.io.CharConversionException: Invalid UTF-8 start byte 0x93 (at char #11, byte #-1) at [Source: (File); line: 1, column: 1]
```

This could mean that the word processor has inserted smart quotes instead of straight quotes. Use straight quotes only.

## Validators not making attestations

Check whether your validator's attestations are being included in blocks at [`BeaconCha.in`](https://beaconcha.in/).

:::note

Occasional missed attestations are normal on a P2P network, but they should be a few percent.

:::

If all recent attestations are marked as missed, check the following:

- **Did the validators load correctly?**

  Check the logs when Teku started for the line, `teku-status-log | Loaded N Validators: <validator_pubkey>[, <validator_pubkey>]`, where `N` is the number of expected validators.
  Each validator's truncated public key is also listed.

  If the validator did not load, check for any errors loading the validator, and that the [`--validator-keys`](../../reference/cli/index.md#validator-keys) option is correct.

- **Is the beacon node still syncing?**

  Validators can only attest when the beacon node is in sync. If you see lines similar to,

  `teku-event-log | Syncing *** Target slot: 2017218, Head slot: 123456, Remaining slots: 2015500, Connecting peers: 12`, then the node is still syncing.

  Syncing is complete when the head slot reaches the current slot. If the node is synced, the messages are similar to, `teku-event-log | Slot Event *** Slot: 716614, Block: acef76..c61b, Epoch: 22394...`.

- **Is the beacon node reporting attestations?**

  Each validator that you run prints the message, `teku-validator-log | Validator *** Published attestation Count: 1, Slot: 48539, Root: 5e1bf5..cee8` once each epoch.
  If you do not see this for your validator then check that it loaded correctly.

  To see this message, ensure [`log-include-validator-duties-enabled`](../../reference/cli/index.md#log-include-validator-duties-enabled) is `true`.

- **Do you have peers?**

  The nodes's peer count is printed at the end of each slot event in the log. [Ensure your local network is configured correctly] to allow the node to listen for incoming P2P connections and discover peers.

## UnsatisfiedLinkError when starting Teku

If Teku fails to start with the following error:

```bash
Teku failed to start.
java.util.concurrent.CompletionException: java.lang.UnsatisfiedLinkError: /tmp/librocksdbjni8697586722914603821.so...
```

This could be due to your `/tmp` directory being marked non-executable (`noexec`).

To resolve this, try one of the following:

- Remove `noexec` on the `/tmp` mount. This can be done permanently in the file systems table (`fstab`), or temporarily using the command `sudo mount /tmp -o remount,exec`

- Create a new temporary folder for applications to use within the shell.

  ```bash
  mkdir tmp
  export TMPDIR=`pwd`/tmp
  ```

## Command line options

On Linux, shell processing of paths do not work when specified like this:

```bash
./teku --config-file=~/config.yaml
```

The shell does not see the tilde (~) in the command. To fix this, omit the equals sign (=).

```bash
./teku --config-file ~/config.yaml
```

<!-- links -->

[Ensure your local network is configured correctly]: ../find-and-connect/improve-connectivity.md
[EIP-2335]: https://eips.ethereum.org/EIPS/eip-2335
[slashed]: ../../concepts/slashing-protection.md
[setting a maximum heap size]: ../../get-started/manage-memory.md

---

## Network issues


## Speed up sync time

Use [checkpoint sync](../../get-started/checkpoint-start.md) to sync Teku from a recent finalized checkpoint, bypassing
the need to sync from genesis and enabling a quick synchronization process within minutes. To do this, use the
[`--initial-state`](../../reference/cli/index.md#initial-state) CLI option which accepts a URL or file that provides a
recent
finalized `BeaconState`. Any synchronized beacon node can provide this from the standard API, and you can view
[the list of public sources](https://eth-clients.github.io/checkpoint-sync-endpoints/).

The [`--initial-state`](../../reference/cli/index.md#initial-state) option is only used when you first create a database.
To restart an existing sync process with checkpoint sync, do the following:

1. Stop the current Teku sync process.
2. Clear the beacon database: either start Teku once with
   [`--force-clear-db`](../../reference/cli/index.md#force-clear-db), or manually delete the
   `beacon/db` directory under your [data path](../../reference/cli/index.md#data-base-path-data-path).
3. Start Teku with the [`--initial-state`](../../reference/cli/index.md#initial-state) option.

Teku will sync within a few minutes, and downloads historic blocks in the background, so it can
help any peers that are syncing from genesis. Teku can run validators and attest while historic blocks are being
downloaded.

## Locate the multiaddress and/or ENR of a Teku beacon node

Teku outputs its Ethereum Name Record (ENR) to the logs at startup. You can also access the info via the API:

```bash
curl "http://127.0.0.1:5051/eth/v1/node/identity" | jq
```

You can decode the ENR by using the [ENR Viewer website](https://enr-viewer.com/).

## Resolve peering issues

### Peer connection issues

By default, Teku attempts to get 100 peers. You can increase the number of peers to improve performance, but this does
lead to increased network traffic and a higher number of messages requiring validation.

Teku's attempt to connect with peers is influenced by two CLI options: [`--p2p-peer-lower-bound`](../../reference/cli/index.md#p2p-peer-lower-bound) (default is 64)
and [`--p2p-peer-upper-bound`](../../reference/cli/index.md#p2p-peer-upper-bound) (default is 100).  If you notice a
decline in your beacon node's participation after reducing these parameters, consider increasing them to enhance
performance.

### Check ports

To confirm the ports your node uses, send a request to
the [`/eth/v1/node/identity`](https://consensys.github.io/teku/#tag/Node/operation/getNetworkIdentity) endpoint.

```bash
curl -s http://127.0.0.1:5051/eth/v1/node/identity | jq '.data | {p2p_addresses, discovery_addresses}'
```

Teku returns the addresses it advertises to peers as
[multiaddresses](../../concepts/p2p-networking.md#multiaddresses), each containing a transport and a port.
For example:

```json
{
  "p2p_addresses": [
    "/ip4/192.0.2.10/tcp/9000/p2p/16Uiu2HAm...",
    "/ip4/192.0.2.10/udp/9001/quic-v1/p2p/16Uiu2HAm..."
  ],
  "discovery_addresses": [
    "/ip4/192.0.2.10/udp/9000"
  ]
}
```

Peers dial these ports, so your firewall and port forwarding rules must allow them:

- `/tcp/<port>/` in `p2p_addresses` is the TCP transport port, set by
  [`--p2p-port`](../../reference/cli/index.md#p2p-port).
- `/udp/<port>/quic-v1/` in `p2p_addresses` is the QUIC transport port, set by
  [`--p2p-quic-port`](../../reference/cli/index.md#p2p-quic-port).
- `/udp/<port>` in `discovery_addresses` is the discovery port, set by
  [`--p2p-udp-port`](../../reference/cli/index.md#p2p-udp-port).

Teku advertises only the transports it has enabled, so a missing TCP or QUIC address means that transport is
disabled on the node.
Addresses that start with `/ip6/` appear when the node also listens over
[IPv6](../find-and-connect/configure-ipv6.md).
For the default ports and the full set of port options, see
[P2P port options](../../concepts/p2p-networking.md#p2p-port-options).

:::note

If you set an advertised port using an option such as
[`--p2p-advertised-port`](../../reference/cli/index.md#p2p-advertised-port), the response shows the
advertised port instead of the port the node listens on.
Open the advertised port on your gateway and forward it to the listening port.
See [Network gateway issues](#network-gateway-issues).

:::

### Check inbound and outbound peers

To count your node's inbound and outbound peers, send a request to
the [`/eth/v1/node/peers`](https://consensys.github.io/teku/#tag/Node/operation/getPeers) endpoint.
This command groups peers by direction and counts peer addresses that include `/tcp/` or `/quic`:

```bash
curl -s http://127.0.0.1:5051/eth/v1/node/peers | jq '
  .data
  | group_by(.direction)[]
  | {
      direction: .[0].direction,
      tcp: (
        map(select((.last_seen_p2p_address // "") | contains("/tcp/")))
        | length
      ),
      quic: (
        map(select((.last_seen_p2p_address // "") | contains("/quic")))
        | length
      )
    }
'
```

Interpret the output by transport:

- If the output shows outbound TCP peers, but no inbound TCP peers, inbound TCP traffic might be blocked.
  Allow and forward TCP traffic on the port specified in
  [`--p2p-port`](../../reference/cli/index.md#p2p-port) (`9000` by default).
- If the output shows outbound QUIC peers, but no inbound QUIC peers, inbound QUIC traffic might be blocked.
  Allow and forward UDP traffic on the port specified in
  [`--p2p-quic-port`](../../reference/cli/index.md#p2p-quic-port) (`9001` by default).

### Firewall connection issues

Networks typically have a firewall at the entry point (router, modem, or gateway) that blocks incoming
data by default.
To resolve this, update the firewall to include rules that allow access to the [P2P ports](../../concepts/p2p-networking.md#p2p-port-options):

- `9000/tcp` and `9000/udp` for the TCP transport and peer discovery (configurable with [`--p2p-port`](../../reference/cli/index.md#p2p-port)).
- `9001/udp` for the QUIC transport (configurable with [`--p2p-quic-port`](../../reference/cli/index.md#p2p-quic-port)).

Forward these ports to the internal IP address of the machine running the beacon node.
Some operating systems also have local firewalls that should be updated to permit communication through these ports.

:::info

View the [Prysm guide](https://docs.prylabs.network/docs/prysm-usage/p2p-host-ip/) for more information on this topic.
Use your Teku ports for the firewall rules: `--p2p-port` for TCP (transport) and UDP (discovery)
traffic, and `--p2p-quic-port` for QUIC over UDP traffic.

:::

### Advertised IP address issues

If incoming peers can't connect, you might have specified an incorrect address using the
[`--p2p-advertised-ip`](../../reference/cli/index.md#p2p-advertised-ip-p2p-advertised-ips) option. Teku autodetects the
address to use by default, so most users won't need to use this option. If you're experiencing issues with incoming peers
despite having
correct firewall and forwarding settings, this could be the cause.

### Network gateway issues

If incoming peers can't connect, you might be using a different port on your network gateway (router or modem).
This usually happens because only one service can listen on a port.
Therefore, if you're running multiple beacon nodes, you need to open multiple ports on your gateway.

We recommend using the same port on your gateway as specified in
[`--p2p-port`](../../reference/cli/index.md#p2p-port) (`9000` by default).
However, you can also set the advertised port using
[`--p2p-advertised-port`](../../reference/cli/index.md#p2p-advertised-port).

Similarly, for [`--p2p-quic-port`](../../reference/cli/index.md#p2p-quic-port) (`9001` by default),
you can set the advertised port for QUIC using
[`--p2p-advertised-quic-port`](../../reference/cli/index.md#p2p-advertised-quic-port).

## Resolve poor attestation performance

Troubleshooting poor attestation performance is complicated, and the solution requires you to identify the root cause.

[This video](https://www.symphonious.net/2020/09/08/exploring-eth2-attestation-inclusion/), while slightly dated, still
provides valuable and applicable insights.

Common issues include:

- **The CPU is overloaded and Teku is lagging**.
  Monitor CPU stats, and watch the terminal for frequent `regenerating state` messages, common during Teku's struggle.
  In this context, enabling [`--p2p-subscribe-all-subnets`](../../reference/cli/index.md#p2p-subscribe-all-subnets-enabled)
  can worsen the situation by raising CPU usage.
  A typical problem arises when JVM lacks adequate heap allocation, causing aggressive garbage collection.
  Ensure an environment variable like `JAVA_OPTS=-Xmx8g` is set, with `8g` (five gigabytes of heap) as an optimal value;
  `7g` is acceptable, while anything much lower may lead to problems.

- **Time sync on your server is poor**.
  Ensure `ntpd` or `chrony` is configured correctly.

- **Low numbers of peers, or poor quality peers**.
  Refer to the [peering troubleshooting topic](#resolve-peering-issues) for more information to resolve this.

- **Poor internet speed**.
  An example is someone was on an ADSL link with only about 2.5 Mbps upstream which led to misses, typically anything over
  10 Mbps upstream is acceptable.

## Excessive late block import warnings due to time skew

In Ethereum, every proposed block is expected to propagate through the network and reach every beacon node within
four seconds into the current slot. Whenever Teku receives a block after the expected period, it prints a warning to
the logs that looks like:

```bash
2024-03-18 17:32:27.363 WARN  - Late Block Import ***
Block: a0ad54151e1e629ac4a3c23d768e100a9f017b229c927c23ea90111f6399cbdf (8659360)
proposer 858815 arrival 4083ms, gossip_validation +4ms, pre-state_retrieved +3ms,
processed +259ms, execution_payload_result_received +0ms, begin_importing +1ms,
transaction_prepared +0ms, transaction_committed +0ms, completed +13ms
```

The `arrival` value in the message indicates the time the block was received by the node. In this particular
case, the block arrived 4083ms after the start of the slot (more than four seconds). Therefore, Teku printed
the warning message.

Even on a healthy network, some late blocks are expected. It's impossible to completely eliminate them, as most of
the time, a block being late has nothing to do with your node specifically. However, if you're seeing multiple late
block warnings in the logs, it's possible that your server's timing configuration is incorrect, causing your node
to perceive blocks as late when, in reality, the server's clock is misaligned with the rest of the network. This
is why it's important to use a service like NTPD or Chrony to keep your server's clock synchronized.

If you suspect your server clock is out-of-sync, use a dashboard like the
[Grafana Node Exporter Dashboard](https://grafana.com/grafana/dashboards/1860-node-exporter-full/) to check.
Look for the **System Timesync** panel and examine the **Time Synchronized Drift** chart, which shows how much
your server clock is drifting from other nodes in the network. A higher drift indicates a greater deviation between
your system clock and other nodes, potentially causing issues for Teku.

Here is an image that shows the **Time Synchronized Drift** chart before and after the server clock being
adjusted using Chrony:

![Time Synchronized Drift](/img/time_synchronized_drift_chart.png)

:::note

Having zero time drift is impossible in practice. The Ethereum protocol has been designed to withstand up to
500ms of variance between nodes.

:::

References:

- [Monitoring a Linux host with Prometheus and `node_exporter`](https://grafana.com/docs/grafana-cloud/send-data/metrics/metrics-prometheus/prometheus-config-examples/noagent_linuxnode/)
- [Node Exporter Grafana Dashboard](https://grafana.com/grafana/dashboards/1860-node-exporter-full/)
- [Using `chrony` to configure NTP](https://ubuntu.com/blog/ubuntu-bionic-using-chrony-to-configure-ntp)
- [Why clock sync matters in Ethereum 2.0](https://hackmd.io/@ericsson49/BJfLjEX-8)

## Address missing attestations or non-inclusion issues

- No peers might have been present on the attestation subnet.
  Check for a log message when attempting to publish without subscribed peers: `Failed to publish ... for slot ... due
  to missing peers on the required gossip topic`.
- Several factors could contribute, such as delayed blocks past your inclusion slot causing ripple effects.
  Thus, examining epochs where your attestation was scheduled and checking for late block import warnings would be beneficial.
- Also, consider specific times of day and concurrent network activities.
  It's possible that message transmission could be hindered by factors like bandwidth limitations.

## Invalid signer public key configuration

You may see log error messages similar to:

```bash
Caused by: java.lang.IllegalArgumentException: Expected 48 bytes but received 58.
```

This arises if `validators-external-signer-public-keys` is in the config file without proper quotation for public keys.
In YAML, `0x` prefixed values are treated as numbers, leading the parser to convert them to an unexpected binary format
in Teku. Previous Teku versions had a YAML parser that didn't perform this conversion, making both quoted and unquoted
forms functional.

**Incorrect:**

```yaml
validators-external-signer-public-keys:
  - 0x8f9335f7d6b19469d5c8880df50bf41c01f476411d5b69a8b121255347f1c0b8400ba31a63010b229080240589ad2423
  - 0xb3f3faa8dfa1030714559b95cb0107e53c9ee9c6f2b4b11f29e60417dbc4462052ff2d2dbbe98d808e3093858a3acdcc
  - 0xb2f1e6c00c6716d4cd5cb02b42678ff481e3ae1525cdfc33e4a1711eeb2878da10ebeacdcdc2ef2049410fc60fe5cfe5
  - 0xb7d6cb9ce7397c33b89ec57de0de383c7c294687b8963f92cc60f59bb1de46c56623cd24c9cc1e407db92d1a79920887
  - 0xaf3eab6962987321bdf81e7a10239b91316c643cca64babe81d68e9f9030a6a7b91681168df5a02a9ac3433b8332a712
```

**Correct:**

```yaml
validators-external-signer-public-keys:
  - "0x8f9335f7d6b19469d5c8880df50bf41c01f476411d5b69a8b121255347f1c0b8400ba31a63010b229080240589ad2423"
  - "0xb3f3faa8dfa1030714559b95cb0107e53c9ee9c6f2b4b11f29e60417dbc4462052ff2d2dbbe98d808e3093858a3acdcc"
  - "0xb2f1e6c00c6716d4cd5cb02b42678ff481e3ae1525cdfc33e4a1711eeb2878da10ebeacdcdc2ef2049410fc60fe5cfe5"
  - "0xb7d6cb9ce7397c33b89ec57de0de383c7c294687b8963f92cc60f59bb1de46c56623cd24c9cc1e407db92d1a79920887"
  - "0xaf3eab6962987321bdf81e7a10239b91316c643cca64babe81d68e9f9030a6a7b91681168df5a02a9ac3433b8332a712"
```

## Teku crashes with SIGILL

The BLST library might erroneously use the optimized library version instead of the portable one. This could stem from CPU
autodetection errors, in which case, obtaining the CPU details from `/proc/cpuinfo` on Linux or `/usr/sbin/sysctl -a` on
macOS will help us to improve it. Alternatively, users might have intentionally set BLST to optimal.

You can specifically request the portable version of BLST (overriding CPU detection) with the following:

```bash
JAVA_OPTS="-Dteku.portableBlst=true"
```

If the user has already set `-Dteku.portableBlst=false` it should be changed to `true`.

## Force Teku to use the optimized BLST library

Check the Teku logs at startup for `Using optimized BLST library` if it was able to detect a compatible CPU, or
`Using portable BLST library` if it could not.

You can force Teku to use the optimized version by setting the environment variable `TEKU_OPTS="-Dteku.portableBlst=false"`.
If you're already setting `TEKU_OPTS` or `JAVA_OPTS`, append `-Dteku.portableBlst=false` to the existing variable. If
you use the optimized library on a CPU that doesn't support it, Teku will crash with a `SIGILL`, in which case you should
switch back to the portable version (`TEKU_OPTS="-Dteku.portableBlst=true"`).

## Configure an archive node

Set [`--data-storage-mode`](../../reference/cli/index.md#data-storage-mode) to `archive`, and provide an
[`--initial-state`](../../reference/cli/index.md#initial-state), you can also use
[`--reconstruct-historic-states`](../../reference/cli/index.md#reconstruct-historic-states) to rebuild
all the old states once blocks have been downloaded.

It will take a while to build up the node, but you'll be able to access all state and block information back to genesis
after it is completed.

---

## Update your withdrawal credentials


When you create a validator, it’s possible to set its
[withdrawal](../concepts/withdrawals.md) address to a BLS address, or an
Ethereum address.

You can update your BLS withdrawal address to an Ethereum address after the
Capella upgrade.

## Determine the withdrawal address type

**Prerequisites**:

- Access to the beacon node API endpoint.
  The default is `localhost:5051`.
- [`curl`](https://curl.se/) and [`jq`](https://stedolan.github.io/jq/) installed.

The following shell script allows you to determine the withdrawal address of a
given validator ID.

<Tabs>
  <TabItem value="Script" label="Script" default>

```bash
VALIDATOR=<VALIDATOR_INDEX> \
curl http://localhost:5051/eth/v1/beacon/states/finalized/validators/$VALIDATOR | jq '.data | .validator.withdrawal_credentials'
```

  </TabItem>
  <TabItem value="Example output" label="Example output" >
```
"0x00fc40352b0a186d83267fc1342ec5da49dbb78e1099a4bd8db16d2c0d223594"
```

  </TabItem>
</Tabs>

In the script, specify the `<VALIDATOR_INDEX>` (for example, `1`) that was
provided when you joined the network.
Alternatively, you can specify the validator's public key.

In the output, the first four characters of the string, in this case `0x00`,
indicates the key is a BLS withdrawal key.

## Update your withdrawal address

:::caution

Don't store your [validator keys](use-external-signer/manage-keys.md) and withdrawal
keys in the same location.

:::

### From a BLS withdrawal address to an Ethereum address

:::caution

Teku doesn't offer functionality to create a signed withdrawal credential change.
Tools such as
[`staking-deposit-cli`](https://github.com/ethereum/staking-deposit-cli#generate-bls-to-execution-change-arguments)
allow you to generate this signed message, which can be submitted directly to
your beacon node if your REST API is active.

:::

If your withdrawal address is a BLS key (starts with `0x00`), the Capella fork
provides a process to update your withdrawal address to a `0x01` withdrawal key
(Ethereum address).
You must have the BLS withdrawal address private key, or the seed phrase
(mnemonic) to sign the request to prove that you have access to the BLS
withdrawal key.

Tools such as
[`staking-deposit-cli`](https://github.com/ethereum/staking-deposit-cli#generate-bls-to-execution-change-arguments) or [`ethdo`](https://github.com/wealdtech/ethdo/blob/master/docs/changingwithdrawalcredentials.md) can sign the request correctly. You can then submit the signed withdrawal credential change to your own beacon node using the [`bls_to_execution_changes`](https://consensys.github.io/teku/#tag/Beacon/operation/postBlsToExecutionChange) API, or broadcast it using [`beaconcha.in`](https://beaconcha.in/tools/broadcast).

:::caution Important information about changing withdrawal credentials

- Once you update a validator to use a `0x01` withdrawal key (Ethereum address),
  you can't change it again.
- Updating your withdrawal credentials isn't available until the Capella fork is
  active.
- Ensure you update to the expected Ethereum address because the change is permanent.

:::

A maximum of 16 validator keys can update their withdrawal credentials per
block, so the process may be congested initially.
If you submit a request to update your key, and it hasn't been done in a period
of time, you might consider re-submitting the request.
It might take several epochs for the change to be included in a block, depending
on the number of requests in the queue.

Query the
[`bls_to_execution_changes`](https://consensys.github.io/teku/#tag/Beacon/operation/getBlsToExecutionChanges)
API see if your request is still in the pool.

### Update your Ethereum address

If your withdrawal credentials are set to an Ethereum address, and you wish to
update it to a different address, you must create a new validator key.
You can exit your current validator key as a voluntary exit, and use the funds
from the full withdrawal of that to create the new validator key.

The voluntary exit process takes while to complete, and the exiting validator
must remain active during that time to avoid inactivity penalties.

:::caution

Ensure that you own the current Ethereum address before exiting, otherwise you
can't access your funds.

:::

---

## Manage validator signing keys


You can manage the signing keys of validators using the
[key manager API endpoints](https://ethereum.github.io/keymanager-APIs/).
You can list keys, import keystores, and delete keys with the API.

## Enable validator client API

To use the key manager API endpoints,
[enable the validator client API](../../reference/rest.md#enable-the-validator-client-api)
using the [`--validator-api-enabled`](../../reference/cli/index.md#validator-api-enabled)
option.
You must also [create a keystore](#create-a-keystore) to enable access.

### Create a keystore

When enabling the validator client API, you must create a keystore.

1. Use a tool such as
    [keytool](https://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html)
    or [openSSL](https://www.openssl.org/) to generate a keystore.
    Note that the `CN` value must be set to the domain name or IP used to access
    the validator API.
    Keytool sets this based on the answer to `What is your first and last name?`.

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

    ```bash
    keytool -genkeypair -keystore <keystore> -storetype PKCS12 -storepass <password>
    ```

  </TabItem>
  <TabItem value="Example" label="Example" default>

    ```bash
    keytool -genkeypair -keystore validator_keystore.p12 -storetype PKCS12 -storepass changeit
    ```

  </TabItem>
</Tabs>

2. Create a plain text file (for example, `validator_keystore_pass.txt`) that
    stores the password you defined in the keystore.

3. Start Teku using
    [`--validator-api-keystore-file`](../../reference/cli/index.md#validator-api-keystore-file)
    to define the keystore file and
    [`--validator-api-keystore-password-file`](../../reference/cli/index.md#validator-api-keystore-password-file)
    to define the password file.

    ```bash title="Example"
    teku --validator-api-enabled --validator-api-keystore-file=validator_keystore.p12 --validator-api-keystore-password-file=validator_keystore_pass.txt
    ```

:::caution

Don't store your validator keys and
[withdrawal keys](../../concepts/withdrawals.md#withdrawal-keys) in the same
location.

:::

#### Support multiple domains and IPs

When the key manager API is accessible using different domain names or IP
addresses, each domain or IP must be listed in the SSL certificate to be
accepted as valid.
Multiple addresses can be specified when using openSSL to generate the certificate.

1. Create a file named `openssl.cnf` containing the configuration required for
    the certificate.

    ```ini title="openssl.cnf"
    [req]
    distinguished_name = req_distinguished_name
    x509_extensions = v3_req
    prompt = no

    [req_distinguished_name]
    countryName = US
    stateOrProvinceName = CA
    localityName = San Francisco
    organizationName = My Organization Name
    organizationalUnitName = My Department Name

    [v3_req]
    subjectKeyIdentifier = hash
    authorityKeyIdentifier = keyid,issuer
    basicConstraints = CA:TRUE
    subjectAltName = @alt_names

    [alt_names]
    DNS.1 = mydomain.com
    DNS.2 = localhost
    IP.1 = 127.0.0.1
    IP.2 = 10.0.0.6
    ```

    You should adjust the `req_distinguished_name` and `alt_names` sections to
    match your needs.

2. Create a plain text file (for example, `validator_keystore_pass.txt`) that
    stores the password you defined in the keystore.

3. Generate an x509 certificate from the configuration and convert it to PKCS12
    format:

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

    ```bash
    openssl req -x509 -nodes -days <expiry> -newkey rsa:2048 -config openssl.cnf | openssl pkcs12 -export -out <keystore> -passout file:<password-file>
    ```

  </TabItem>
  <TabItem value="Example" label="Example">

    ```bash
    openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -config openssl.cnf | openssl pkcs12 -export -out validator_keystore.p12 -passout file:validator_keystore_pass.txt
    ```

  </TabItem>
</Tabs>

### Authentication

Authentication verifies user access to requested validator client methods.

Upon startup of the validator client, Teku creates an API token at the path
`/opt/teku/data/validator/key-manager`.
When calling an endpoint that requires authorization, you must send the
generated token in the `Authorization` request header field with the `Bearer`
authentication scheme.

```bash title="Example"
curl -H "Authorization: Bearer <TOKEN>" -X GET https://localhost:5052/eth/v1/keystores
```

---

## Use Web3Signer


Teku supports the [Web3Signer] external signing client.

**Prerequisites**:

- Web3Signer installed and running
- [Signing key configuration files]

## Start Teku

Start Teku and specify the external signer options.
For example:

```bash
teku \
  --network=hoodi                                                      \
  --ee-endpoint=http://localhost:8551                                  \
  --validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b \
  --validators-external-signer-url=http://localhost:9000
```

The command line specifies the following:

- The network using [`--network`](../../reference/cli/index.md#network).
- The URL of the execution client's Engine API using [`--ee-endpoint`](../../reference/cli/index.md#ee-endpoint).
- The validator public keys for which Web3Signer signs attestations and blocks using
  [`--validators-external-signer-public-keys`](../../reference/cli/index.md#validators-external-signer-public-keys).
- The URL of the Web3Signer client using [`--validators-external-signer-url`](../../reference/cli/index.md#validators-external-signer-url).

:::note

You need a [signing key configuration file] for each public key specified using [`--validators-external-signer-public-keys`](../../reference/cli/index.md#validators-external-signer-public-keys).

:::

<!--links-->

[Web3Signer]: https://docs.web3signer.consensys.net/
[Signing key configuration files]: https://docs.web3signer.consensys.net/HowTo/Use-Signing-Keys/
[signing key configuration file]: https://docs.web3signer.consensys.net/en/latest/HowTo/Use-Signing-Keys/

---

## View block rewards


Use the [rewards API](https://consensys.github.io/teku/#tag/Rewards) to view the validator rewards.

:::note

You cannot query attestation rewards for the latest epoch.

:::

Enable the rewards API with the [`--rest-api-enabled`](../reference/cli/index.md#rest-api-enabled) command line option.

:::tip

A [Swagger interface is also available](../reference/rest.md#enable-the-rest-api-service).
Use the [`--rest-api-docs-enabled`](../reference/cli/index.md#rest-api-docs-enabled) command line option to enable the web interface.

:::

## Limitations

The following limitations apply:

- The rewards API currently supports the `altair` fork upgrade and later.

- The rewards API relies on state and block data to retrieve the reward information, meaning you'll receive limited data if the beacon node being queried is not an archive node.

- You can only query blocks from finalized to head if you are not using `archive` storage mode.

## Impact of data storage modes

:::tip

You can change the [`data-storage-mode`](../reference/cli/index.md#data-storage-mode) without re-initializing your database.

You can change the frequency that states are stored by specifying [`data-storage-archive-frequency`](../reference/cli/index.md#data-storage-archive-frequency),
but it will only affect the state storage from the time that the change has been made.
It will also directly impact the amount of disk space required by Teku.

:::

Consider using a beacon node with `archive` mode storage if you frequently call the rewards API on finalized data.
However, this may produce slow results due to having to replay blocks due to the infrequent storage of states on disk (every 2048 slots by default).

You can consider tuning your data storage to access data quicker, by storing more states (at the cost of disk space), for example,
[setting the archive frequency](../reference/cli/index.md#data-storage-archive-frequency) to `256` or even `64`, and replaying fewer blocks.

## Examples

Query all the rewards from the block currently at head.

<Tabs>
  <TabItem value="Example" label="Example" default>

```bash
curl http://localhost:5051/eth/v1/beacon/rewards/blocks/head |jq
```

  </TabItem>
  <TabItem value="Result" label="Result" >

```json
{
  "execution_optimistic": false,
  "finalized": false,
  "data": {
    "proposer_index": "555552",
    "total": "1217168",
    "attestations": "0",
    "sync_aggregate": "1217168",
    "proposer_slashings": "0",
    "attester_slashings": "0"
  }
}
```

  </TabItem>
</Tabs>

Query all the sync committee rewards from the block at head for validator index 1.

<Tabs>
  <TabItem value="Example" label="Example" default>

```bash
curl -X POST \
     -H 'accept: application/json' \
     -H 'Content-Type: application/json' \
     http://localhost:5051/eth/v1/beacon/rewards/sync_committee/head \
     -d '["1"]' |jq
```

  </TabItem>
  <TabItem value="Result" label="Result" >

```json
{
  "execution_optimistic": false,
  "finalized": false,
  "data": [
    {
      "validator_index": "1",
      "reward": "16778"
    }
  ]
}
```

  </TabItem>
</Tabs>

Query attestation rewards from epoch 204644, just for validator index 0.

<Tabs>
  <TabItem value="Example" label="Example" default>

```bash
curl -X POST \
     -H 'accept: application/json' \
     -H 'Content-Type: application/json' \
     http://localhost:5051/eth/v1/beacon/rewards/attestations/204648 \
     -d '["0"]' |jq
```

  </TabItem>
  <TabItem value="Result" label="Result" >

```json
 {
  "execution_optimistic": false,
  "finalized": true,
  "data": {
    "ideal_rewards": [...],
    "total_rewards": [
      {
        "validator_index": "0",
        "head": "3125",
        "target": "6005",
        "source": "3236"
      }
    ]
  }
}
```

  </TabItem>
</Tabs>

---

## Use sentry beacon nodes


You can calculate future block proposers ahead of time, which opens up an attack vector.
A DoS attack on a validator's beacon node can cause the validator to miss its block proposal, thereby losing the block proposal reward.
You can mitigate this issue by using sentry nodes.

:::info

Only [validators executed separately](../get-started/start-teku.md#run-the-clients-separately) from beacon nodes (remote validators) can use sentry nodes

:::

When you configure your remote validator to use sentry beacon nodes, each beacon node (or cluster of beacon nodes) can be assigned a role.
Each role determines which beacon node the remote validator sends request to when performing a task.

Sentry nodes support three roles:

- `duties_provider` - Beacon node used for requesting attestations and block duties.
- `block_handler` - Beacon node used for block creation and publishing.
- `attestation_publisher` - Beacon node used for publishing attestations.

Only the `duties_provider` role is mandatory. You can assign multiple beacon node endpoints for each role.

## Configure sentry nodes

:::info

The CLI option `--sentry-config-file=<file_path>` cannot be used with [`--beacon-node-api-endpoint`](../reference/cli/subcommands/validator-client.md#beacon-node-api-endpoint-beacon-node-api-endpoints).

:::

Configure your sentry nodes in a JSON configuration file. To configure your remote validator to use the sentry node configuration, use the `--sentry-config-file=<file_path>` CLI option.

The configuration file (in this example, `/etc/sentry-node-config.json`) uses the following format:

```json
{
  "beacon_nodes": {
    "duties_provider": {
      "endpoints": ["http://duties:9051"]
    },
    "block_handler": {
      "endpoints": ["http://block:9051"]
    },
    "attestation_publisher": {
      "endpoints": ["http://attestation:9051"]
    }
  }
}
```

Start your remote validator with the `--sentry-config-file` option, for example:

```bash
teku validator --sentry-config-file=/etc/sentry-node-config.json
```

During startup the logs display output similar to:

```bash
...
DEBUG | SentryNodesConfigLoader | 2022-10-03 01:31:48.260 INFO  - Loading sentry nodes configuration from /etc/sentry-node-config.json
DEBUG | SentryNodesConfigLoader | 2022-10-03 01:31:48.277 INFO  - Duty provider beacon nodes: http://duties:9051
DEBUG | SentryNodesConfigLoader | 2022-10-03 01:31:48.277 INFO  - Block handler beacon nodes: http://block:9051
DEBUG | SentryNodesConfigLoader | 2022-10-03 01:31:48.278 INFO  - Attestation publisher beacon nodes: http://attestation:9051
...
```

At this point, the remote validator knows what beacon nodes should be used for its tasks and no further configuration is required.

---

## Voluntarily exit

# Voluntarily exit a validator

A voluntary exit is when a validator chooses to stop performing its duties, and exits the Beacon Chain permanently.

To voluntarily exit, the validator must continue performing its validator duties until successfully exited to avoid penalties.

:::caution important

To voluntarily exit, you must have a running beacon node with the [REST API enabled].

:::

:::warning

A validator **cannot** rejoin the network once it voluntarily exits. You can set up a new validator with the withdrawn funds.

:::

## Initiate a voluntary exit

Use the [`voluntary-exit`](../reference/cli/subcommands/voluntary-exit.md) subcommand to initiate a voluntary exit for specified validators.

```bash title="Example"
teku voluntary-exit                                \
  --beacon-node-api-endpoint=http://127.0.0.1:5051 \
  --validator-keys=validator/keys/validator_1e9f2a.json:validator/passwords/validator_1e9f2a.txt
```

In the command:

- Specify the location of the beacon node using the
  [`--beacon-node-api-endpoint`](../reference/cli/subcommands/voluntary-exit.md#beacon-node-api-endpoint) option.
- Specify the validators to exit using the
  [`--validator-keys`](../reference/cli/subcommands/voluntary-exit.md#validator-keys) option.
- Specify the earliest epoch at which to exit using the
  [`--epoch`](../reference/cli/subcommands/voluntary-exit.md#epoch) option.
  If not specified, the default value is the current epoch.
  You cannot specify a future epoch.

If using an external signer such as [Web3Signer], then specify the external signer URL and public key of the exiting validator:

```bash title="Example"
teku voluntary-exit                                      \
  --beacon-node-api-endpoint=http://127.0.0.1:5051       \
  --validators-external-signer-url=http://localhost:9000 \
  --validators-external-signer-public-keys=1e9f2afcc0737f4502e8d4238e4fe82d45077b2a549902b61d65367acecbccba
```

Use the [`/eth/v1/beacon/pool/voluntary_exits`](https://consensys.github.io/teku/#tag/Beacon/operation/getPoolVoluntaryExits) API to check the pending exit queue.

## Create but don't submit an exit

The [`voluntary-exit`](../reference/cli/subcommands/voluntary-exit.md) subcommand accepts an option [`--save-exits-path`](../reference/cli/subcommands/voluntary-exit.md#save-exits-path),
which creates a signed exit without submitting it to the beacon node.

[`--save-exits-path`](../reference/cli/subcommands/voluntary-exit.md#save-exits-path) allows an operator to create the voluntary exits for validators, and save them for future use.
These exit messages (from the Deneb fork) will be valid for the current or any future hard fork—they do not become invalid at any point in time.

```bash title="Example"
teku voluntary-exit                                \
  --beacon-node-api-endpoint=http://127.0.0.1:5051 \
  --save-exits-path=.                              \
  --validator-keys=validator/keys/validator_1e9f2a.json:validator/passwords/validator_1e9f2a.txt
```

In the command:

- Specify the location of the beacon node using the
  [`--beacon-node-api-endpoint`](../reference/cli/subcommands/voluntary-exit.md#beacon-node-api-endpoint) option.
- Specify the validators to exit using the
  [`--validator-keys`](../reference/cli/subcommands/voluntary-exit.md#validator-keys) option.
- Specify the path at which to save the generated exit messages using the
  [`--save-exits-path`](../reference/cli/subcommands/voluntary-exit.md#save-exits-path) option.

In this example, a JSON file is written to the current folder (`.`) containing a signed exit message
for validator `1e9f2a`.
At a future time when this exit needs to be processed, you can use the beacon API to submit
this message using a POST request to `/eth/v1/beacon/voluntary_exits`.

The `--beacon-node-api-endpoint` option is required even though the voluntary exit is not being submitted, as it verifies the status of the validator, and needs network parameters to generate a valid message.

<!-- links -->

[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
[REST API enabled]: ../reference/cli/index.md#rest-api-enabled

---

## Configure TLS communication with an external signer

# Configure TLS communication

Configure TLS communication with an external signer such as [Web3Signer] which accepts connections from clients that use trusted CA certificates or self-signed certificates.

This tutorial configures TLS between Teku and Web3Signer, and uses the [`keytool`](https://docs.oracle.com/en/java/javase/12/tools/keytool.html)
utility to generate keystores and a truststore that contain self-signed certificates.

:::info

`keytool` is available with the JDK or JRE installation, you can also use OpenSSL.

:::

**Prerequisites**:

- [Web3Signer installed](https://docs.web3signer.consensys.net/en/latest/HowTo/Get-Started/Install-Binaries/).
- [Web3Signer signing key files](https://docs.web3signer.consensys.net/en/latest/HowTo/Use-Signing-Keys/) for validators on the testnet.
- [Teku Installed](../get-started/install/install-binaries.md).
- [Java `keytool`](https://docs.oracle.com/en/java/javase/12/tools/keytool.html).
- A running execution client such as [Besu].

 This tutorial connects to the Hoodi testnet.
 You can [run a Besu node on Hoodi](https://besu.hyperledger.org/public-networks/get-started/start-node#run-a-node-on-an-ethereum-testnet).

## 1. Create keystores

A keystore contains the certificate and private key used to authenticate yourself during TLS mutual authentication.

Teku can use either the PKCS12 or JKS keystore type, whereas Web3Signer only uses a PKCS12 keystore.

For each keystore you must create a plain text file containing the password to decrypt the keystore.

### Web3Signer keystore and password file

1. Generate the Web3Signer keystore.

    ```bash
    keytool \
      -genkeypair                       \
      -keystore web3signer_keystore.p12 \
      -storetype PKCS12                 \
      -storepass changeit               \
      -alias web3signer                 \
      -keyalg RSA                       \
      -keysize 2048                     \
      -validity 109500                  \
      -dname "CN=localhost, OU=PegaSys, O=ConsenSys, L=Brisbane, ST=QLD, C=AU" \
      -ext san=dns:localhost,ip:127.0.0.1
    ```

    :::info

    Common name (`CN`) is generally the fully qualified name of Web3Server, you can use `-ext san` to add additional hostnames or IP addresses.
    This allows the same certificate to be used for more than one hostname or IP address if Web3Signer is running on a different machine to Teku with multiple hostnames.

    :::

2. Create a plain text file (for example `web3signer_keystore_password.txt`) that stores the password used to create the keystore.

    ```bash title="web3signer_keystore_password.txt"
    changeit
    ```

You now have the `web3signer_keystore.p12` and `web3signer_keystore_password.txt` files that must be supplied when [starting Web3Signer](#4-start-web3signer).

### Teku keystore and password file

Teku presents the keystore to Web3Signer for TLS mutual authentication. We recommend using PKCS12.

1. Generate the Teku keystore.

    ```bash
    keytool \
      -genkeypair                        \
      -keystore teku_client_keystore.p12 \
      -storetype PKCS12                  \
      -storepass changeit                \
      -alias teku_client                 \
      -keyalg RSA                        \
      -keysize 2048                      \
      -validity 109500                   \
      -dname "CN=teku, OU=PegaSys, O=ConsenSys, L=Brisbane, ST=QLD, C=AU"
    ```

    :::info

    For Teku as a client, `CN` doesn't need to have a hostname, however it must be a lowercase value, such as `CN=teku`.

    :::

2. Create a plain text file (for example `teku_keystore_password.txt`) that stores the password used to create the keystore.

    ```bash title="teku_keystore_password.txt"
    changeit
    ```

You now have the `teku_client_keystore.p12` and `teku_keystore_password.txt` files that must be supplied when [starting Teku](#5-start-teku).

## 2. Create the truststore and password file

The truststore contains certificates that you are willing to trust. Create the truststore to trust the Web3Signer certificate during TLS mutual authentication.

To create the truststore:

1. Export the Web3Signer public certificate from the Web3Signer keystore to `PEM` format.

    ```bash
    keytool -exportcert -keystore ./web3signer_keystore.p12 -alias web3signer -rfc -file web3signer.pem
    ```

2. Import the public certificate into a truststore to be used by Teku, and type `yes` if asked to trust the certificate.

    ```bash
    keytool -importcert -storetype PKCS12 -keystore web3signer_truststore.p12 -alias web3signer -trustcacerts -storepass changeit -file ./web3signer.pem
    ```

3. Create a plain text file (for example `truststore_pass.txt`) that stores the password used to create the keystore.

    ```bash title="truststore_pass.txt"
    changeit
    ```

You now have the `web3signer_truststore.p12` and `truststore_pass.txt` files that must be supplied when [starting Teku](#5-start-teku).

## 3. Create the known clients file

Web3Signer uses a known clients file to trust client certificates.

1. Retrieve the `CN` and `SHA256` details from the Teku keystore.

   ```bash
   keytool -list -v -keystore teku_client_keystore.p12
   ```

2. Create a plain text file (in this case `knownClients.txt`) and add the `CN` and `SHA256` details in one line (separated by a single space).

   ```bash
   teku 67:89:C8:95:70:E0:38:10:2F:AB:7E:A3:75:4A:8C:29:C1:64:52:37:E5:E9:CD:EF:CD:27:C2:88:BF:84:3A:A1
   ```

:::info

You can add multiple known clients to the file by adding the `CN` and `SHA256` details on a new line.

:::

You now have the `knownClients.txt` file that must be supplied when [starting Web3Signer](#4-start-web3signer).

## 4. Start Web3Signer

:::warning

This example disables [Web3Signer slashing protection], this is not recommended on Mainnet.

:::

Start Web3Signer using the [keystore and password](#web3signer-keystore-and-password-file), and [known clients file](#3-create-the-known-clients-file) created earlier.

```bash
web3signer \
  --key-store-path=/Users/me/keyFiles/                                          \
  --tls-keystore-file=/Users/me/certs/web3signer_keystore.p12                   \
  --tls-keystore-password-file=/Users/me/certs/web3signer_keystore_password.txt \
  --tls-known-clients-file=/Users/me/certs/knownClients.txt                     \
  eth2 --slashing-protection-enabled=false
```

## 5. Start Teku

Start Teku and specify the [keystore](#teku-keystore-and-password-file) and [truststore](#2-create-the-truststore-and-password-file) created earlier, with the accompanying password files.

:::note
This example connects to the Hoodi testnet, and connects to the execution client's JSON-RPC URL at `http://127.0.0.1:8551`.
:::

```bash
teku \
  --network=hoodi                                                                           \
  --ee-endpoint=http://127.0.0.1:8551                                                       \
  --validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b                      \
  --validators-external-signer-url=https://localhost:9000                                   \
  --validators-external-signer-truststore=/Users/me/certs/web3signer_truststore.p12         \
  --validators-external-signer-truststore-password-file=/Users/me/certs/truststore_pass.txt \
  --validators-external-signer-keystore=/Users/me/certs/teku_client_keystore.p12            \
  --validators-external-signer-keystore-password-file=/Users/me/certs/teku_keystore_password.txt
```

<!-- links -->

[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
[Besu]: https://besu.hyperledger.org/public-networks/get-started/install
[Web3Signer slashing protection]: https://docs.web3signer.consensys.net/en/latest/concepts/slashing-protection/

---

## Command line options

# Teku command line options

This reference describes the syntax of the Teku command line interface (CLI) options.

## Specify options

You can specify Teku options:

- On the command line.

  ```bash
  teku [OPTIONS] [COMMAND]
  ```

- As an environment variable. For each command line option, the equivalent environment variable is:

  - Uppercase.
  - `-` is replaced by `_`.
  - Has a `TEKU_` prefix.

- In a [YAML configuration file](../../how-to/configure/use-config-file.md).

If you specify an option in multiple places, the order of priority is command line, environment
variable, configuration file.

## Using autocomplete

If using Bash or Z shell, you can enable autocomplete support by navigating to the `build` folder
and running:

```bash
source teku.autocomplete.sh
```

Autocomplete allows you to view option suggestions by entering `--` and pressing the Tab key twice.

```bash
teku --Tab+Tab
```

## Options

### `beacon-liveness-tracking-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--beacon-liveness-tracking-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--beacon-liveness-tracking-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_BEACON_LIVENESS_TRACKING_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
beacon-liveness-tracking-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables validator liveness tracking.
Used by [doppelganger detection](../../how-to/prevent-slashing/detect-doppelgangers.md).
The default is `false`.

### `builder-bid-compare-factor`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--builder-bid-compare-factor=<STRING>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--builder-bid-compare-factor=50
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_BUILDER_BID_COMPARE_FACTOR=50
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
builder-bid-compare-factor: 50
```

  </TabItem>
</Tabs>

The builder bid compare factor. The default is 90 (90%).

Execution layer clients in
[Capella-enabled networks](https://notes.ethereum.org/@launchpad/withdrawals-faq#Q-What-is-ShanghaiCapella)
provide the execution payload and the payload value.
The beacon node compares this value against the builder bid to maximize the validator's profit or
decrease network censorship at a low or no cost.

Use this option to set the comparison factor applied to the builder bid value when comparing it to
the locally produced payload.
The factor is expressed as a percentage.
For example, a builder bid comparison factor of 90 means the builder's payload is chosen when its
value is at least 10% greater than what can be built locally.

Set this option to `BUILDER_ALWAYS` to always use the builder bid, unless the bid is invalid.

### `builder-endpoint`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--builder-endpoint=<URL>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--builder-endpoint=http://127.0.0.1:18550
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_BUILDER_ENDPOINT=http://127.0.0.1:18550
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
builder-endpoint: "http://127.0.0.1:18550"
```

  </TabItem>
</Tabs>

The address for an external [builder endpoint](../../how-to/configure/builder-network.md).

### `builder-set-user-agent-header`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--builder-set-user-agent-header[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--builder-set-user-agent-header=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_BUILDER_SET_USER_AGENT_HEADER=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
builder-set-user-agent-header: true
```

  </TabItem>
</Tabs>

Enables or disables setting the User-Agent header to `teku/v<version>` (for example, `teku/v23.4.0`)
when making a builder bid request, to help builders identify clients and versions.
The default is `true`.

### `checkpoint-sync-url`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--checkpoint-sync-url=<URL>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--checkpoint-sync-url="https://beaconstate.ethstaker.cc"
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CHECKPOINT_SYNC_URL="https://beaconstate.ethstaker.cc"
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
checkpoint-sync-url: "https://beaconstate.ethstaker.cc"
```

  </TabItem>
</Tabs>

The URL of a [Checkpointz](https://github.com/ethpandaops/checkpointz) endpoint used to
[start Teku from a recent state](../../get-started/checkpoint-start.md).

By default, Teku tries to download the finalized state from the endpoint.
If it can't download the finalized state, it tries to download the genesis state.

:::tip
See
[this community-maintained list of checkpoint state endpoints](https://eth-clients.github.io/checkpoint-sync-endpoints/).
:::

When this option is set, and `--deposit-snapshot-enabled` is also not set or disabled,
the `--checkpoint-sync-url` value will be used to determine the deposit snapshot.

### `config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--config-file=/home/me/me_node/config.yaml
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
```

  </TabItem>
</Tabs>

The path to the [YAML configuration file](../../how-to/configure/use-config-file.md).
The default is `none`.

### `data-base-path`, `data-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--data-base-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--data-base-path=/home/me/me_node
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_BASE_PATH=/home/me/me_node
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-base-path: "/home/me/me_node"
```

  </TabItem>
</Tabs>

The path to the Teku data directory. The default directory is OS-dependent:

- macOS: `~/Library/teku`
- Unix/Linux: `$XDG_DATA_HOME/teku` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku`

The default Docker image location is `/root/.local/share/teku`.

### `data-beacon-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--data-beacon-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--data-beacon-path=/home/me/me_beacon
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_BEACON_PATH=/home/me/me_beacon
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-beacon-path: "/home/me/me_beacon"
```

  </TabItem>
</Tabs>

The path to the beacon node data.
The default is `<data-base-path>/beacon` where `<data-base-path>` is specified using
[`--data-base-path`](#data-base-path-data-path).

### `data-storage-archive-frequency`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--data-storage-archive-frequency=<NUMBER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--data-storage-archive-frequency=1028
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_STORAGE_ARCHIVE_FREQUENCY=1028
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-storage-archive-frequency: 1028
```

  </TabItem>
</Tabs>

The frequency (in slots) at which to store finalized states to disk.
The default is `2048`.

This option is ignored if [`--data-storage-mode`](#data-storage-mode) is not set to `archive`.

:::note

Specifying a higher number of slots has a potentially higher overhead for retrieving finalized
states, since Teku might need to regenerate more states to get to the requested state.
Specifying a lower number of slots increases the disk space usage.

:::

For example, with `--data-storage-archive-frequency=1`, Teku uses maximum disk space but has the
lowest response time for retrieving a finalized state since it saves every slot state.
With `--data-storage-archive-frequency=2048`, Teku uses less disk space but might need to
regenerate the state since it only saves every 2048th slot state.

### `data-storage-mode`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--data-storage-mode=<STORAGE_MODE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--data-storage-mode=archive
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_STORAGE_MODE=archive
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-storage-mode: "archive"
```

  </TabItem>
</Tabs>

The strategy for handling historical chain data. Valid options are:

- `archive` - Stores all blocks and states.

- `minimal` - Stores the minimal required data to follow the chain and run validators.
  Finalized states and historic blocks are pruned.

- `prune` - Stores all blocks, but finalized states are pruned.

The default is `minimal`.

### `data-storage-non-canonical-blocks-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--data-storage-non-canonical-blocks-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--data-storage-non-canonical-blocks-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_STORAGE_NON_CANONICAL_BLOCKS_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-storage-non-canonical-blocks-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables storing non-canonical blocks and blob sidecars. The default is `false`.

### `data-validator-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--data-validator-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--data-validator-path=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-validator-path: "/home/me/me_validator"
```

  </TabItem>
</Tabs>

The path to the validator client data.
The default is `<data-base-path>/validator` where `<data-base-path>` is specified using
[`--data-base-path`](#data-base-path-data-path).

### `deposit-snapshot-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--deposit-snapshot-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--deposit-snapshot-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DEPOSIT_SNAPSHOT_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
deposit-snapshot-enabled: false
```

  </TabItem>
</Tabs>

Enables or disables using a deposit tree snapshot from checkpoint sync or distributed as part of
Teku's binary and persisting the tree after finalization.
The default is `true`.

Normally, at sync, Teku requests all deposit logs from the execution layer up to the head.
At each startup, Teku loads all deposits from the disk and replays them to recreate the Merkle tree.
Both operations consume peer resources and delay node availability on restart.
The feature enabled by this option dramatically decreases the time of both operations by bundling
deposit tree snapshots in the Teku distribution for all major networks (Mainnet, Gnosis, Hoodi,
and Sepolia) and persisting the current tree after finalization.
Instead of replaying thousands of deposits on startup, Teku loads the bundled tree or a saved one.

:::info Security considerations
If a malicious peer changes the bundled tree, Teku throws `InvalidDepositEventsException` on the
next deposit received from the execution layer.
The malicious peer can't follow up the chain, and so can't propose with an incorrect deposit tree snapshot.
:::

When this option is not set or is disabled, the `--checkpoint-sync-url` value will be used if
provided to find the deposit snapshot URL.

### `doppelganger-detection-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--doppelganger-detection-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--doppelganger-detection-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DOPPELGANGER_DETECTION_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
doppelganger-detection-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables [doppelganger detection](../../how-to/prevent-slashing/detect-doppelgangers.md).
The default is `false`.

### `ee-endpoint`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--ee-endpoint=<URL>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--ee-endpoint=http://localhost:8550
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_EE_ENDPOINT=http://localhost:8550
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
ee-endpoint: "http://localhost:8550"
```

  </TabItem>
</Tabs>

The URL of the [execution client's](../../concepts/node-types.md#execution-clients) Engine JSON-RPC APIs.

### `ee-jwt-claim-id`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--ee-jwt-claim-id=<STRING>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--ee-jwt-claim-id=foobar
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_EE_JWT_CLAIM_ID=foobar
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
ee-jwt-claim-id: "foobar"
```

  </TabItem>
</Tabs>

A unique identifier for the consensus layer client.
When using the JSON-RPC API engine, this identifier is added to JWT claims as an `id` claim.

### `ee-jwt-secret-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--ee-jwt-secret-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--ee-jwt-secret-file=ee-jwt-secret.hex
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_EE_JWT_SECRET_FILE=ee-jwt-secret.hex
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
ee-jwt-secret-file: "ee-jwt-secret.hex"
```

  </TabItem>
</Tabs>

The shared secret used to authenticate
[execution clients](../../concepts/node-types.md#execution-clients) when using the Engine JSON-RPC API.
Contents of file must be 32 hex-encoded bytes.
This can be a relative or absolute path.
See an [example of how to generate this](../../get-started/connect/mainnet.md#1-generate-the-shared-secret).

### `eth1-deposit-contract-address`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--eth1-deposit-contract-address=<ADDRESS>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--eth1-deposit-contract-address=0x77f7bED277449F51505a4C54550B074030d989bC
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_ETH1_DEPOSIT_CONTRACT_ADDRESS=0x77f7bED277449F51505a4C54550B074030d989bC
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
eth1-deposit-contract-address: "0x77f7bED277449F51505a4C54550B074030d989bC"
```

  </TabItem>
</Tabs>

The address of the deposit contract. Only required when creating a custom network.

The deposit contract address can also be defined in:

- The genesis file specified using [`--initial-state`](#initial-state)
- The predefined network supplied using [`--network`](#network).

### `exchange-capabilities-monitoring-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--exchange-capabilities-monitoring-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--exchange-capabilities-monitoring-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_EXCHANGE_CAPABILITIES_MONITORING_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
exchange-capabilities-monitoring-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables querying the [execution client](../../concepts/node-types.md#execution-clients)
periodically for the Engine API methods it supports.
If enabled and incompatibility is detected, a warning is raised in the logs.
The default is `true`.

### `exit-when-no-validator-keys-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--exit-when-no-validator-keys-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--exit-when-no-validator-keys-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_EXIT_WHEN_NO_VALIDATOR_KEYS_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
exit-when-no-validator-keys-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables automatically exiting when no validator keys are loaded.

If set to `false`, Teku continues running even when no validator keys are loaded.
If set to `true`, Teku automatically exits if no validator keys are loaded, or there are no active validators.

The default is `false`.

:::important

If running the validator client and beacon node separately, set this option only on the validator
client side.
This setting is meant for the client that loads and handles the validator keys.

:::

### `force-clear-db`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--force-clear-db[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--force-clear-db=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_FORCE_CLEAR_DB=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
force-clear-db: true
```

  </TabItem>
</Tabs>

When enabled, Teku deletes the beacon node's on-disk chain database on startup before loading. Use this  
when you want to start from a clean chain state (for example, before using  
[checkpoint sync](../../get-started/checkpoint-start.md) or after a failed migration).
The default is `false`.

:::caution

This option is destructive. The beacon chain database will be permanently deleted. Only use it when you
intend to clear the database and resync or load a new state. Avoid setting it in config files or environment
variables else the database will be deleted on every startup.

:::

### `genesis-state`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--genesis-state=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--genesis-state=/home/me/genesis.ssz
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_GENESIS_STATE=/home/me/genesis.ssz
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
genesis-state: "/home/me/genesis.ssz"
```

  </TabItem>
</Tabs>

The path or URL to an SSZ-encoded state file.
The state file can be used to specify the genesis state, or a
[recent finalized checkpoint state from which to sync].

This option does not need to be specified if the genesis state is provided by the network specified
using the [`--network`](#network) option.
It also is not required if the [`--reconstruct-historic-states`](#reconstruct-historic-states) is
not used.

:::note

If overriding the genesis state in a custom network, you must supply the genesis state file at each restart.

:::

:::tip

You can use [Infura](https://infura.io/) as the source of initial states using
`--genesis-state https://{projectid}:{secret}@eth2-beacon-mainnet.infura.io/eth/v2/debug/beacon/states/genesis`.

:::

### `help`

```bash title="Syntax"
-h, --help
```

Show the help message and exit.

### `ignore-weak-subjectivity-period-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--ignore-weak-subjectivity-period-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--ignore-weak-subjectivity-period-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_IGNORE_WEAK_SUBJECTIVITY_PERIOD_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
ignore-weak-subjectivity-period-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables ignoring the [weak subjectivity](../../concepts/weak-subjectivity.md) period
verification that Teku performs at startup.
The default is `false`.

:::caution
Syncing from outside the weak subjectivity period is considered unsafe.
:::

### `initial-state`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--initial-state=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--initial-state=/home/me/genesis.ssz
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_INITIAL_STATE=/home/me/genesis.ssz
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
initial-state: "/home/me/genesis.ssz"
```

  </TabItem>
</Tabs>

The path or URL to an SSZ-encoded state file.
The state file can be used to specify the genesis state, or a
[recent finalized checkpoint state from which to sync].

This option does not need to be specified if the genesis state is provided by the network specified
using the [`--network`](#network) option.

:::note

If overriding the initial state in a custom network, you must supply the initial state file at each restart.

:::

:::tip

See
[this community-maintained list of checkpoint state endpoints](https://eth-clients.github.io/checkpoint-sync-endpoints/).

:::

### `log-color-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--log-color-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--log-color-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_COLOR_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-color-enabled: false
```

  </TabItem>
</Tabs>

Enables or disables including a console color display code in status and event log messages.
The default is `true`.

### `log-destination`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--log-destination=<LOG_DESTINATION>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--log-destination=CONSOLE
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_DESTINATION=CONSOLE
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-destination: "CONSOLE"
```

  </TabItem>
</Tabs>

The location to output log information. Valid options are:

- `BOTH`
- `CONSOLE`
- `DEFAULT_BOTH`
- `FILE`

The default is `DEFAULT_BOTH`.
When using `BOTH` or `DEFAULT_BOTH`, system updates such as blockchain events are displayed on the
console, and errors and other information are logged to a file.
Specify the log file with the [`--log-file`](#log-file) command-line option.

In production environments, we recommend using the `CONSOLE` or `FILE` options to ensure all log
information is available in one place.

:::note

Use `DEFAULT_BOTH` when using a
[custom Log4J2 configuration file](../../how-to/monitor/configure-logging.md#advanced-custom-logging).
Any other option applies the custom logging changes on top of its default settings.

:::

### `log-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--log-file=<FILENAME>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--log-file=teku_2020-01-01.log
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_FILE=teku_2020-01-01.log
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-file: "teku_2020-01-01.log"
```

  </TabItem>
</Tabs>

The relative or absolute location and filename of the log file.

The default directory is OS-dependent:

- macOS: `~/Library/teku/logs`
- Unix/Linux: `$XDG_DATA_HOME/teku/logs` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku/logs`

The default Docker image location is `/root/.local/share/teku/logs`.

### `log-file-name-pattern`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--log-file-name-pattern=<REGEX>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--log-file-name-pattern=tekuL_%d{yyyy-MM-dd}.log
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_FILE_NAME_PATTERN=tekuL_%d{yyyy-MM-dd}.log
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-file-name-pattern: "tekuL_%d{yyyy-MM-dd}.log"
```

  </TabItem>
</Tabs>

The filename pattern to apply when creating log files.
The default pattern is `teku_%d{yyyy-MM-dd}.log`.

### `log-include-events-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--log-include-events-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--log-include-events-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_INCLUDE_EVENTS_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-include-events-enabled: false
```

  </TabItem>
</Tabs>

Enables or disables logging frequent update events.
For example, every slot event with validators and attestations.
The default is `true`.

### `log-include-validator-duties-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--log-include-validator-duties-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--log-include-validator-duties-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_INCLUDE_VALIDATOR_DUTIES_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-include-validator-duties-enabled: false
```

  </TabItem>
</Tabs>

Enables or disables logging details of validator event duties.
The default is `true`.

:::note

Logs could become noisy when running many validators.

:::

### `logging`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
-l, --logging=<LEVEL>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--logging=DEBUG
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOGGING=DEBUG
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
logging: "DEBUG"
```

  </TabItem>
</Tabs>

The logging verbosity.
Log levels are `OFF`, `FATAL`, `ERROR`, `WARN`, `INFO`, `DEBUG`, `TRACE`, and `ALL`.
The default is `INFO`.

### `metrics-block-production-performance-tracking-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--metrics-block-production-performance-tracking-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--metrics-block-production-performance-tracking-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_BLOCK_PRODUCTION_PERFORMANCE_TRACKING_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-block-production-performance-tracking-enabled: false
```

  </TabItem>
</Tabs>

Enables or disables block production performance metrics. The default is `false`.

### `metrics-block-timing-tracking-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--metrics-block-timing-tracking-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--metrics-block-timing-tracking-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_BLOCK_TIMING_TRACKING_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-block-timing-tracking-enabled: false
```

  </TabItem>
</Tabs>

Enables or disables block timing metrics. The default is `true`.

### `metrics-categories`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--metrics-categories=<CATEGORY>[,<CATEGORY>...]...
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--metrics-categories=BEACON,JVM,PROCESS
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_CATEGORIES=BEACON,JVM,PROCESS
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-categories: ["BEACON", "JVM", "PROCESS"]
```

  </TabItem>
</Tabs>

A comma-separated list of categories for which to track metrics.
Options are `JVM`, `PROCESS`, `BEACON`, `DISCOVERY`, `EVENTBUS`, `EXECUTOR`, `LIBP2P`, `NETWORK`,
`STORAGE`, `STORAGE_HOT_DB`, `STORAGE_FINALIZED_DB`, `VALIDATOR`,
`VALIDATOR_PERFORMANCE`, and `VALIDATOR_DUTY`.

When `metrics-categories` is used, only the categories specified in this option are enabled (all
other categories are disabled).

### `metrics-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--metrics-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--metrics-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables the metrics exporter. The default is `false`.

### `metrics-host-allowlist`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--metrics-host-allowlist=<hostname>[,<hostname>...]... or "*"
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--metrics-host-allowlist=medomain.com,meotherdomain.com
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_HOST_ALLOWLIST=medomain.com,meotherdomain.com
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-host-allowlist: ["medomain.com", "meotherdomain.com"]
```

  </TabItem>
</Tabs>

A comma-separated list of hostnames to allow access to the [Teku metrics].
By default, Teku accepts access from `localhost` and `127.0.0.1`.

:::tip

To allow all hostnames, use `"*"`.
We don't recommend allowing all hostnames for production environments.

:::

### `metrics-interface`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--metrics-interface=<HOST>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--metrics-interface=192.168.10.101
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_INTERFACE=192.168.10.101
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-interface: "192.168.10.101"
```

  </TabItem>
</Tabs>

The host on which Prometheus accesses Teku metrics. The default is `127.0.0.1`.

### `metrics-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--metrics-port=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--metrics-port=6174
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_PORT=6174
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-port: 6174
```

  </TabItem>
</Tabs>

The port (TCP) on which [Prometheus](https://prometheus.io/) accesses Teku metrics.
The default is `8008`.

### `metrics-publish-endpoint`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--metrics-publish-endpoint=<URL>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--metrics-publish-endpoint=https://beaconcha.in/api/v1/client/metrics?apikey={apikey}
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_PUBLISH_ENDPOINT=https://beaconcha.in/api/v1/client/metrics?apikey={apikey}
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-publish-endpoint: "https://beaconcha.in/api/v1/client/metrics?apikey={apikey}"
```

  </TabItem>
</Tabs>

The endpoint URL of an external service such as [beaconcha.in](https://beaconcha.in/) to which Teku
publishes metrics for node monitoring.

### `metrics-publish-interval`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--metrics-publish-interval=<INTEGER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--metrics-publish-interval=60
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_PUBLISH_INTERVAL=60
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-publish-interval: "60"
```

  </TabItem>
</Tabs>

The interval between metric publications to the external service defined in
[metrics-publish-endpoint](#metrics-publish-endpoint), measured in seconds.
The default is `60`.

### `network`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--network=<NETWORK>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--network=mainnet
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_NETWORK=mainnet
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
network: "mainnet"
```

  </TabItem>
</Tabs>

The network to use.
Accepts a predefined network name, or a file path or URL to a YAML network-specific configuration file
from the [consensus specification].
This network configuration is separate from the Teku
[configuration file](../../how-to/configure/use-config-file.md), which configures node-level settings.

The default is `mainnet`.

Possible values are:

| Network    | Chain           | Type       | Description                                                             |
|:-----------|:----------------|:-----------|:------------------------------------------------------------------------|
| `mainnet`  | Consensus layer | Production | Main network                                                            |
| `hoodi`    | Consensus layer | Test       | Multi-client testnet                                                    |
| `ephemery` | Consensus layer | Test       | Multi-client testnet                                                    |
| `sepolia`  | Consensus layer | Test       | Multi-client testnet                                                    |
| `minimal`  | Consensus layer | Test       | Used for local testing and development networks                         |
| `gnosis`   | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/)                  |
| `chiado`   | Consensus layer | Test       | Gnosis [testnet](https://docs.gnosischain.com/concepts/networks/chiado) |
| `lukso`    | Consensus layer | Production | Network for the [Lukso chain](https://lukso.network/)                   |

Predefined networks configure base network settings such as the initial state of the network, bootnodes, and
the address of the deposit contract.

### `p2p-advertised-ip`, `p2p-advertised-ips`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-advertised-ip=<IP_ADDRESS>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-advertised-ip=192.168.1.132
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_ADVERTISED_IP=192.168.1.132
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-advertised-ip: "192.168.1.132"
```

  </TabItem>
</Tabs>

The peer-to-peer IP address(es) to advertise.
You can define up to two addresses: one IPv4 and one
[IPv6](../../how-to/find-and-connect/configure-ipv6.md).
The default address is `127.0.0.1`.

### `p2p-advertised-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-advertised-port=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-advertised-port=1789
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_ADVERTISED_PORT=1789
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-advertised-port: 1789
```

  </TabItem>
</Tabs>

The P2P port to advertise.
The default is the port specified in [`--p2p-port`](#p2p-port).

The advertised port can differ from the [`--p2p-port`](#p2p-port).
For example, you can set the advertised port to `9010`, and the `--p2p-port` value to `9009`, then
manually configure the firewall to forward external incoming requests on port `9010` to port `9009`
on the Teku node.

### `p2p-advertised-port-ipv6`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-advertised-port-ipv6=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-advertised-port-ipv6=1790
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_ADVERTISED_PORT_IPV6=1790
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-advertised-port-ipv6: 1790
```

  </TabItem>
</Tabs>

The P2P [IPv6](../../how-to/find-and-connect/configure-ipv6.md) port to advertise.
Use this port only when advertising both IPv4 and IPv6 addresses.
The default is the port specified in [`--p2p-port-ipv6`](#p2p-port-ipv6).

### `p2p-advertised-quic-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-advertised-quic-port=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-advertised-quic-port=1789
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_ADVERTISED_QUIC_PORT=1789
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-advertised-quic-port: 1789
```

  </TabItem>
</Tabs>

The P2P QUIC port to advertise.
The default is the port specified in [`--p2p-quic-port`](#p2p-quic-port).

The advertised port can differ from the [`--p2p-quic-port`](#p2p-quic-port).
For example, you can set the advertised QUIC port to `9010`, and the `--p2p-quic-port` value to `9009`, then
manually configure the firewall to forward external incoming requests on port `9010` to port `9009`
on the Teku node.

### `p2p-advertised-quic-port-ipv6`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-advertised-quic-port-ipv6=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-advertised-quic-port-ipv6=1790
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_ADVERTISED_QUIC_PORT_IPV6=1790
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-advertised-quic-port-ipv6: 1790
```

  </TabItem>
</Tabs>

The P2P [IPv6](../../how-to/find-and-connect/configure-ipv6.md) QUIC port to advertise.
Use this port only when advertising both IPv4 and IPv6 addresses.
The default is the port specified in [`--p2p-quic-port-ipv6`](#p2p-quic-port-ipv6).

### `p2p-advertised-udp-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-advertised-udp-port=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-advertised-udp-port=1789
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_ADVERTISED_UDP_PORT=1789
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-advertised-udp-port: 1789
```

  </TabItem>
</Tabs>

The UDP port to advertise to external peers.
The default is the port specified in [`--p2p-advertised-port`](#p2p-advertised-port) if it is set.
Otherwise, the default is the port specified in [`--p2p-port`](#p2p-port).

### `p2p-advertised-udp-port-ipv6`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-advertised-udp-port-ipv6=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-advertised-udp-port-ipv6=1790
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_ADVERTISED_UDP_PORT_IPV6=1790
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-advertised-udp-port-ipv6: 1790
```

  </TabItem>
</Tabs>

The [IPv6](../../how-to/find-and-connect/configure-ipv6.md) UDP port to advertise to external peers.
This port is only used when advertising both IPv4 and IPv6 addresses.
The default is the port specified in [`--p2p-advertised-port-ipv6`](#p2p-advertised-port-ipv6) if it is set.
Otherwise, the default is the port specified in [`--p2p-port-ipv6`](#p2p-port-ipv6).

### `p2p-direct-peers`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-direct-peers=<ADDRESS>[,<ADDRESS>...]...
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-direct-peers=/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz,/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_DIRECT_PEERS=/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz,/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-direct-peers: ["/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz",
                    "/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1"]
```

  </TabItem>
</Tabs>

A comma-separated list of
[multiaddresses](https://libp2p.io/guides/addressing/) of direct peers with
which to establish and maintain connections.
Direct peers are static peers with which this node will always exchange full messages, regardless of
peer scoring mechanisms.
Your direct peers also need to enable your node as direct peer in order to work.

### `p2p-discovery-bootnodes`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-discovery-bootnodes=<ENR_ADDRESS>[,<ENR_ADDRESS>...]...
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-discovery-bootnodes=enr:-Iu4QG...wgiMo,enr:-Iu4QL...wgiMo
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_DISCOVERY_BOOTNODES=enr:-Iu4QG...wgiMo,enr:-Iu4QL...wgiMo
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-discovery-bootnodes: ["enr:-Iu4QG...wgiMo",
                          "enr:-Iu4QL...wgiMo"]
```

  </TabItem>
</Tabs>

A comma-separated list of Ethereum Node Records (ENRs) for P2P discovery bootstrap.

### `p2p-discovery-bootnodes-url`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-discovery-bootnodes-url=<URL>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-discovery-bootnodes-url=/etc/bootnodes.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_DISCOVERY_BOOTNODES_URL=/etc/bootnodes.txt
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-discovery-bootnodes-url: "/etc/bootnodes.txt"
```

  </TabItem>
</Tabs>

A URL or file that contains a list of [Ethereum Node Records (ENRs)](https://ethereum.org/en/developers/docs/networking-layer/network-addresses/) for P2P discovery bootstrap.
The file should have one ENR per line.

:::note
If the URL or file is unable to load, Teku will fail to start up.
:::

### `p2p-discovery-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-discovery-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-discovery-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_DISCOVERY_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-discovery-enabled: false
```

  </TabItem>
</Tabs>

Enables or disables P2P peer discovery.
If disabled, [`p2p-static-peers`](#p2p-static-peers) or [`p2p-static-peers-url`](#p2p-static-peers-url) defines the peer connections.
The default is `true`.

### `p2p-discovery-site-local-addresses-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-discovery-site-local-addresses-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-discovery-site-local-addresses-enabled
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_DISCOVERY_SITE_LOCAL_ADDRESSES_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-discovery-site-local-addresses-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables discovery of the following local network (RFC1918) addresses.
The default is `false`.

```text
10.0.0.0      -   10.255.255.255  (10/8 prefix)
172.16.0.0    -   172.31.255.255  (172.16/12 prefix)
192.168.0.0   -   192.168.255.255 (192.168/16 prefix)
```

Normal Teku operation shouldn't send traffic to these local network addresses.

In test or private networks, operators might need to enable discovery of local addresses.
For example, when you run multiple consensus layer nodes in one local network, these nodes are not
discovered on the public internet and are advertised with local (RFC1918) addresses.

### `p2p-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-enabled: false
```

  </TabItem>
</Tabs>

Enables or disables all P2P communication. The default is `true`.

### `p2p-interface`, `p2p-interfaces`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-interface=<HOST>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-interface=192.168.1.132
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_INTERFACE=192.168.1.132
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-interface: "192.168.1.132"
```

  </TabItem>
</Tabs>

The network interfaces on which the node listens for P2P communication.
The default is `0.0.0.0` (all interfaces).
You can define up to two interfaces, with one being IPv4 and the other IPv6.

### `p2p-nat-method`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-nat-method=<STRING>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-nat-method=UPNP
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_NAT_METHOD=UPNP
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-nat-method: "UPNP"
```

  </TabItem>
</Tabs>

The method for handling [NAT environments](../../how-to/find-and-connect/specify-nat.md).
Valid options are `NONE` and `UPNP`.

The default is `NONE`, which disables NAT functionality.

:::tip

UPnP support is often disabled by default in networking firmware.
If disabled by default, explicitly enable UPnP support.

:::

### `p2p-peer-lower-bound`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-peer-lower-bound=<INTEGER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-peer-lower-bound=25
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_PEER_LOWER_BOUND=25
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-peer-lower-bound: 25
```

  </TabItem>
</Tabs>

The lower bound on the target number of peers.
Teku actively seeks new peers if the number of peers falls below this value.
The default is `64`.

### `p2p-peer-upper-bound`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-peer-upper-bound=<INTEGER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-peer-upper-bound=40
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_PEER_UPPER_BOUND=40
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-peer-upper-bound: 40
```

  </TabItem>
</Tabs>

The upper bound on the target number of peers.
Teku refuses new peer requests that would cause the number of peers to exceed this value.
The default is `100`.

### `p2p-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-port=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-port=1789
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_PORT=1789
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-port: 1789
```

  </TabItem>
</Tabs>

The P2P listening ports (UDP and TCP). The default is `9000`.

### `p2p-port-ipv6`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-port-ipv6=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-port-ipv6=1790
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_PORT_IPV6=1790
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-port-ipv6: 1790
```

  </TabItem>
</Tabs>

The P2P listening ports (UDP and TCP) for [IPv6](../../how-to/find-and-connect/configure-ipv6.md)
when listening over both IPv4 and IPv6.
The default is `9090`.

### `p2p-private-key-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-private-key-file=<PATH_TO_FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-private-key-file=/home/me/me_node/key
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_PRIVATE_KEY_FILE=/home/me/me_node/key
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-private-key-file: "/home/me/me_node/key"
```

  </TabItem>
</Tabs>

The file containing the [node's private key](../../concepts/p2p-networking.md#node-identity-and-private-key).

If a file doesn't exist at the specified path, Teku creates a new file and P2P private key to store inside.

If you don't specify this option, Teku looks for a `generated-node-key.dat` file in the
`<data-beacon-path>/kvstore` directory, where `<data-beacon-path>` is set using the
[`--data-beacon-path`](#data-beacon-path) option.
If the file doesn't exist, Teku generates a P2P private key and writes it to that file.
If the file already exists, Teku uses the stored key.

:::important

Ensure you specify the complete file path, including the file name, and not only the directory location.

:::

### `p2p-quic-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-quic-port=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-quic-port=1801
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_QUIC_PORT=1801
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-quic-port: 1801
```

  </TabItem>
</Tabs>

The P2P QUIC listening port (UDP).
The default is `9001`.

### `p2p-quic-port-ipv6`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-quic-port-ipv6=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-quic-port-ipv6=1802
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_QUIC_PORT_IPV6=1802
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-quic-port-ipv6: 1802
```

  </TabItem>
</Tabs>

The P2P QUIC listening port (UDP) for [IPv6](../../how-to/find-and-connect/configure-ipv6.md) when
listening over both IPv4 and IPv6.
The default is `9091`.

### `p2p-static-peers`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-static-peers=<ADDRESS>[,<ADDRESS>...]...
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-static-peers=/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz,/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_STATIC_PEERS=/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz,/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-static-peers: ["/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz",
                    "/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1"]
```

  </TabItem>
</Tabs>

A comma-separated list of
[multiaddresses](https://libp2p.io/guides/addressing/) of static peers with
which to establish and maintain connections.

### `p2p-static-peers-url`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-static-peers-url=<URL>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-static-peers-url=https://my-peers-url
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_STATIC_PEERS_URL=https://my-peers-url
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-static-peers-url: "https://my-peers-url"
```

  </TabItem>
</Tabs>

A URL or file that contains a list of
[multiaddresses](https://libp2p.io/guides/addressing/) of static peers with
which to establish and maintain connections. The file should have one peer per line.

:::note
If the URL or file is unable to load, Teku will fail to start up.
:::

### `p2p-subscribe-all-custody-subnets-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-subscribe-all-custody-subnets-enabled=<BOOLEAN>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-subscribe-all-custody-subnets-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_SUBSCRIBE_ALL_CUSTODY_SUBNETS_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-subscribe-all-custody-subnets-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables forcing the beacon node to stay subscribed to all custody
subnets, storing and providing all custody sidecars regardless of the
number of validators.
The default is `false`.

When set to `false`, Teku subscribes to the number of persistent subnets
required by the protocol, which is calculated by the number of validators and
the balance of consolidated validators: 1 subnet per each 32 ETH of balance,
but no less than 8 subnets.

This option is a mostly altruistic feature for a node with an excess of resources
that could be dedicated to serving network stability. When enabled, the option turns the node
into a [supernode](https://github.com/ethereum/consensus-specs/blob/master/specs/fulu/p2p-interface.md#supernodes).
If the node is required to provide blob data via the Beacon API, it's required
to be a supernode; otherwise, the node doesn't have all data for blob
reconstruction.

:::caution

When this option is set to `true`, Teku uses significantly more storage, bandwidth and CPU.
Most users don't need to use this option.

:::

### `p2p-subscribe-all-subnets-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-subscribe-all-subnets-enabled=<BOOLEAN>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-subscribe-all-subnets-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_SUBSCRIBE_ALL_SUBNETS_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-subscribe-all-subnets-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables forcing the beacon node to stay subscribed to all subnets regardless of the
number of validators.
The default is `false`.

When set to `false`, Teku subscribes to two persistent subnets regardless of the number of validators.
Teku also subscribes and unsubscribes from subnets as needed for the running validators.

This option is primarily for users running an external validator client and load balancing it across
multiple beacon nodes.
Without this flag, depending on how requests are load balanced, the beacon nodes may not have
subscribed to the required subnets and be unable to produce aggregates.

:::caution

When set to `true`, Teku uses more CPU and bandwidth, and for most users there's no need to use this option.

:::

### `p2p-udp-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-udp-port=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-udp-port=1789
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_UDP_PORT=1789
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-udp-port: 1789
```

  </TabItem>
</Tabs>

The UDP port used for discovery. The default is the port specified in [`--p2p-port`](#p2p-port).

### `p2p-udp-port-ipv6`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--p2p-udp-port-ipv6=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--p2p-udp-port-ipv6=1790
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_UDP_PORT_IPV6=1790
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-udp-port-ipv6: 1790
```

  </TabItem>
</Tabs>

The [IPv6](../../how-to/find-and-connect/configure-ipv6.md) UDP port used for discovery.
Use this port only when listening over both IPv4 and IPv6.
The default is the port specified in [`--p2p-port-ipv6`](#p2p-port-ipv6).

### `reconstruct-historic-states`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--reconstruct-historic-states=<BOOLEAN>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--reconstruct-historic-states=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_RECONSTRUCT_HISTORIC_STATES=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
reconstruct-historic-states: true
```

  </TabItem>
</Tabs>

Enables or disables [reconstructing historical states](../../how-to/reconstruct-historical-states.md).

When set to `true`, an archive node can reconstruct historical states from genesis up to the current
checkpoint, running during start up.
When set to `false`, this function is disabled.

### `rest-api-cors-origins`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--rest-api-cors-origins[=<url>[,<url>...]...] or "*"
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--rest-api-cors-origins="http://medomain.com","https://meotherdomain.com"
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_REST_API_CORS_ORIGINS="http://medomain.com","https://meotherdomain.com"
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
rest-api-cors-origins: ["http://medomain.com","https://meotherdomain.com"]
```

  </TabItem>
</Tabs>

A list of domain URLs for CORS validation.
You must enclose the URLs in double quotes and separate them with commas.

Listed domains can access the node using HTTP REST API calls.
If your client interacts with Teku using a browser app (such as a block explorer), add the client
domain to the list.

The default is `none`.
If you don't list any domains, browser apps can't interact with your Teku node.

:::tip

For testing and development purposes, use `*` to accept requests from any domain.
We don't recommend accepting requests from any domain for production environments.

:::

### `rest-api-docs-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--rest-api-docs-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--rest-api-docs-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_REST_API_DOCS_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
rest-api-docs-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables the REST API documentation. The default is `false`.

The documentation can be accessed at `http://<interface>:<port>/swagger-ui` where:

- `interface` is specified using [`--rest-api-interface`](#rest-api-interface)
- `port` is specified using [`--rest-api-port`](#rest-api-port)

### `rest-api-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--rest-api-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--rest-api-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_REST_API_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
rest-api-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables the [REST API service](../rest.md).
The default is `false`.

If set to `true`, use [`--rest-api-host-allowlist`](#rest-api-host-allowlist) to limit access to
trusted parties.

### `rest-api-getblobs-sidecars-download-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--rest-api-getblobs-sidecars-download-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--rest-api-getblobs-sidecars-download-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
REST_API_GETBLOBS_SIDECARS_DOWNLOAD_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
rest-api-getblobs-sidecars-download-enabled: true
```

  </TabItem>
</Tabs>

Enables the `getBlobs` REST API to retrieve missing blob sidecars from the P2P network via RPC.

When set to `true`, if required sidecars are not available locally, the node attempts to fetch them from peers.
Successfully retrieved sidecars are persisted to the local database to satisfy subsequent requests.
This allows nodes to serve blob data without being configured for full custody, while custody backfill is in progress,
or for requests outside the local retention period (if peers still hold the data).

:::note

Retrieved sidecars are treated as standard custody data and are subject to the network pruning [retention limits](https://github.com/ethereum/consensus-specs/blob/master/specs/fulu/validator.md#sidecar-retention).

:::

### `rest-api-getblobs-sidecars-download-timeout`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--rest-api-getblobs-sidecars-download-timeout=<INTEGER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--rest-api-getblobs-sidecars-download-timeout=10
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
REST_API_GETBLOBS_SIDECARS_DOWNLOAD_TIMEOUT=10
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
rest-api-getblobs-sidecars-download-timeout: 10
```

  </TabItem>
</Tabs>

Specifies the maximum time in seconds to wait for blob sidecars to be retrieved from the P2P network when serving `getBlobs` requests.

If the timeout is reached before the required sidecars are retrieved, the reconstruction attempt is aborted.
This option is only effective when [`--rest-api-getblobs-sidecars-download-enabled`](#rest-api-getblobs-sidecars-download-enabled) is set to `true`. The default is `5`.

### `rest-api-host-allowlist`

<Tabs>
 <TabItem value="Syntax" label="Syntax" default>

```bash
--rest-api-host-allowlist=<hostname>[,<hostname>...]... or "*"
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--rest-api-host-allowlist=localhost,127.0.0.1,10.0.0.1
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_REST_API_HOST_ALLOWLIST=localhost,127.0.0.1,10.0.0.1
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
rest-api-host-allowlist: ["localhost", "127.0.0.1", "10.0.0.1"]
```

  </TabItem>
</Tabs>

A comma-separated list of hostnames or IP addresses from which the REST API server will respond.
This flag restricts the server's responding addresses, but not the client access.

By default, Teku's REST API server responds only to requests where the `Host` header matches `localhost` or `127.0.0.1`.
If you specify values, the server will only respond to requests where the `Host` header matches one of the specified hosts or IP addresses.

You can configure the API to listen on all network interfaces using [`rest-api-interface="0.0.0.0"`](#rest-api-interface)
and allow connections from specific addresses by setting `rest-api-host-allowlist`.
See [configure the API for network interfaces and host allowlist](../rest.md#configure-the-api-for-network-interfaces-and-host-allowlist)
for more information.

:::tip

To allow all hostnames, use "*". We don't recommend allowing all hostnames for production environments.

:::

:::warning

Only trusted parties should access the REST API.
Do not directly expose these APIs publicly on production nodes.

:::

### `rest-api-interface`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--rest-api-interface=<HOST>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
# to listen on all interfaces
--rest-api-interface=0.0.0.0
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_REST_API_INTERFACE=0.0.0.0
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
rest-api-interface: "0.0.0.0"
```

  </TabItem>
</Tabs>

The interface on which the REST API listens. The default is `127.0.0.1`.

### `rest-api-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--rest-api-port=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
# to listen on port 3435
--rest-api-port=3435
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_REST_API_PORT=3435
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
rest-api-port: 3435
```

  </TabItem>
</Tabs>

The REST API listening port (HTTP). The default is `5051`.

### `sentry-config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--sentry-config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--sentry-config-file=/etc/sentry-node-config.json
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_SENTRY_CONFIG_FILE=/etc/sentry-node-config.json
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
sentry-config-file: "/etc/sentry-node-config.json"
```

  </TabItem>
</Tabs>

The path to the [sentry node](../../how-to/use-sentry-nodes.md) configuration file.
The default is `none`.

:::caution

You can't use this option with
[`--beacon-node-api-endpoint`](subcommands/validator-client.md#beacon-node-api-endpoint-beacon-node-api-endpoints).

:::

### `shut-down-when-validator-slashed-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--shut-down-when-validator-slashed-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--shut-down-when-validator-slashed-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_SHUT_DOWN_WHEN_VALIDATOR_SLASHED_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
shut-down-when-validator-slashed-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables [validators slashing detection](../../how-to/prevent-slashing/detect-slashing.md).
The default is `false`.

### `validator-api-bearer-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-api-bearer-file=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validator-api-bearer-file=/etc/teku/validator-api-bearer-file
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_API_BEARER_FILE=/etc/teku/validator-api-bearer-file
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-api-bearer-file: "/etc/teku/validator-api-bearer-file"
```

  </TabItem>
</Tabs>

The path to the file containing the [validator client API](../rest.md#enable-the-validator-client-api) bearer token.
If the file exists, the password is loaded from this file.
If the file does not exist and the path is writeable, a bearer token is automatically generated.

By default, the bearer file is generated as `validator-api-bearer` in the `validator/key-manager` path.

### `validator-api-cors-origins`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-api-cors-origins="<URL>"[,"<URL>",...] or "*"
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validator-api-cors-origins="http://medomain.com","https://meotherdomain.com"
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_API_CORS_ORIGINS="http://medomain.com","https://meotherdomain.com"
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-api-cors-origins: ["http://medomain.com","https://meotherdomain.com"]
```

  </TabItem>
</Tabs>

A comma-separated list of domain URLs for CORS validation.

Listed domains can access the node using validator API calls.
If your client interacts with Teku using a browser app (such as a block explorer), add the client
domain to the list.

The default is `none`.
If you don't list any domains, browser apps can't interact with your Teku node.

:::tip

For testing and development purposes, use `*` to accept requests from any domain.
We don't recommend accepting requests from any domain for production environments.

:::

### `validator-api-docs-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-api-docs-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validator-api-docs-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_API_DOCS_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-api-docs-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables the [validator client API](../rest.md#enable-the-validator-client-api) documentation.
The default is `false`.

When enabling the API documentation endpoint, you must also specify:

- `interface` by using [`--validator-api-interface`](#validator-api-interface).
- `port` by using [`--validator-api-port`](#validator-api-port).

### `validator-api-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-api-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validator-api-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_API_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-api-enabled: true
```

  </TabItem>
</Tabs>

Set to `true` to enable the [validator client API](../rest.md#enable-the-validator-client-api).
The default is `false`.

If set to `true`, then use [`--validator-api-host-allowlist`](#validator-api-host-allowlist) to
limit access to trusted parties.

### `validator-api-host-allowlist`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-api-host-allowlist=<hostname>[,<hostname>...]... or "*"
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validator-api-host-allowlist=medomain.com,meotherdomain.com
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_API_HOST_ALLOWLIST=medomain.com,meotherdomain.com
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-api-host-allowlist: ["medomain.com", "meotherdomain.com"]
```

  </TabItem>
</Tabs>

A comma-separated list of hostnames to allow access to the
[validator client API](../rest.md#enable-the-validator-client-api).
By default, Teku accepts access from `localhost` and `127.0.0.1`.

:::warning

Only trusted parties should access the API.
Do not directly expose these APIs publicly on production nodes.

We don't recommend allowing all hostnames (`"*"`) for production environments.

:::

### `validator-api-interface`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-api-interface=<HOST>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
# to listen on all interfaces
--validator-api-interface=0.0.0.0
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_API_INTERFACE=0.0.0.0
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-api-interface: "0.0.0.0"
```

  </TabItem>
</Tabs>

The interface on which the [validator client API](../rest.md#enable-the-validator-client-api) listens.
The default is `127.0.0.1`.

### `validator-api-keystore-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-api-keystore-file=<keystoreFile>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validator-api-keystore-file=validator_keystorstore.p12
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_API_KEYSTORE_FILE=validator_keystore.p12
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-api-keystore-file: "validator_keystore.p12"
```

  </TabItem>
</Tabs>

The keystore file for the [validator client API](../rest.md#enable-the-validator-client-api).
Teku can use PKCS12 or JKS keystore types.
You must [create a keystore](../../how-to/use-external-signer/manage-keys.md#create-a-keystore) to
enable access.

### `validator-api-keystore-password-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-api-keystore-password-file=<keystorePasswordFile>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validator-api-keystore-password-file=validator_keystore_pass.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_API_KEYSTORE_PASSWORD_FILE=validator_keystore_pass.txt
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-api-keystore-password-file: "validator_keystore_pass.txt"
```

  </TabItem>
</Tabs>

The password used to decrypt the keystore for the [validator REST API](../rest.md#enable-the-validator-client-api).

### `validator-api-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-api-port=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validator-api-port=5052
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_API_PORT=5052
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-api-port: 5052
```

  </TabItem>
</Tabs>

The [validator client API](../rest.md#enable-the-validator-client-api) listening port (HTTP).
The default is `5052`.

### `validators-builder-registration-default-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-builder-registration-default-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-builder-registration-default-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_BUILDER_REGISTRATION_DEFAULT_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-builder-registration-default-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables registering all validators managed by the validator client to the
[builder endpoint](../../how-to/configure/builder-network.md) when proposing a block.

### `validators-builder-registration-default-gas-limit`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-builder-registration-default-gas-limit=<NUMBER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-builder-registration-default-gas-limit=40000000
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_BUILDER_REGISTRATION_DEFAULT_GAS_LIMIT=40000000
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-builder-registration-default-gas-limit: 40000000
```

  </TabItem>
</Tabs>

The gas limit used for [registering validators to the builder endpoint](../../how-to/configure/builder-network.md#2-register-the-validator).
The default is `60000000`.

### `validators-early-attestations-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-early-attestations-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-early-attestations-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EARLY_ATTESTATIONS_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-early-attestations-enabled: false
```

  </TabItem>
</Tabs>

Enables or disables using Teku's built-in early attestation production, which creates an attestation
as soon as a block is received.
The default is `true`.

Set this option to `false` if running a validator client connected to a load balanced beacon node
(including most hosted beacon nodes such as [Infura]), and validator effectiveness is poor.

:::note

Delaying attestation production increases the chances of generating a correct attestation when using
a load balanced beacon node, but it increases the risk of inclusion delays.

:::

### `validators-external-signer-keystore`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-external-signer-keystore=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-external-signer-keystore=teku_client_keystore.p12
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_KEYSTORE=teku_client_keystore.p12
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-keystore: "teku_client_keystore.p12"
```

  </TabItem>
</Tabs>

The keystore that Teku presents to the external signer for TLS authentication.
Teku can use PKCS12 or JKS keystore types.

Use the PKCS12 keystore type if connecting to Web3Signer.

### `validators-external-signer-keystore-password-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-external-signer-keystore-password-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-external-signer-keystore-password-file=keystore_pass.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_KEYSTORE_PASSWORD_FILE=keystore_pass.txt
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-keystore-password-file: "keystore_pass.txt"
```

  </TabItem>
</Tabs>

The password file used to decrypt the keystore.

### `validators-external-signer-public-keys`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-external-signer-public-keys=<KEY>[,<KEY>...]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_PUBLIC_KEYS=0xa99a...e44c,0xb89b...4a0b
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-public-keys: ["0xa99a...e44c","0xb89b...4a0b"]
```

  </TabItem>
</Tabs>

A list or URL of validator public keys used by an external signer (for example, Web3Signer).

Use the URL to load the public keys from a remote service. For example:

```bash
--validators-external-signer-public-keys=http://localhost:9900/api/v1/eth2/publicKeys
```

Use the value `external-signer` to load all public keys managed by the external signer.
Teku automatically queries the external signer's
[public keys endpoint](https://consensys.github.io/web3signer/#tag/Public-Key).

```bash
--validators-external-signer-public-keys=external-signer
```

:::tip

You can [load new validators without restarting Teku] if you specify a URL from which to load the
public keys.

:::

Ensure the external signer is running before starting Teku.

### `validators-external-signer-slashing-protection-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-external-signer-slashing-protection-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-external-signer-slashing-protection-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_SLASHING_PROTECTION_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-slashing-protection-enabled: false
```

  </TabItem>
</Tabs>

Enables or disables using Teku's built-in [slashing protection] when using an external signer such
as [Web3Signer].
The default is `true`.

Set this option to `false` if using the slashing protection implemented by an external signer.

:::warning

Ensure the external signer has slashing protection enabled before disabling Teku slashing
protection, otherwise a validator may get slashed.

:::

Built-in slashing protection can only be disabled for validators using external signers.
Validators using Teku to sign blocks and attestations always uses its built-in slashing protection.

### `validators-external-signer-timeout`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-external-signer-timeout=<INTEGER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-external-signer-timeout=2000
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_TIMEOUT=2000
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-timeout: 2000
```

  </TabItem>
</Tabs>

The timeout in milliseconds for requests to the external signer. The default is `5000`.

### `validators-external-signer-truststore`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-external-signer-truststore=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-external-signer-truststore=websigner_truststore.p12
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE=websigner_truststore.p12
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-truststore: "websigner_truststore.p12"
```

  </TabItem>
</Tabs>

The PKCS12 or JKS keystore used to trust external signer's self-signed certificate or CA certificate
which signs the external signer's certificate.

### `validators-external-signer-truststore-password-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-external-signer-truststore-password-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-external-signer-truststore-password-file=truststore_pass.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE_PASSWORD_FILE=truststore_pass.txt
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-truststore-password-file: "truststore_pass.txt"
```

  </TabItem>
</Tabs>

The password file used to decrypt the keystore.

### `validators-external-signer-url`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-external-signer-url=<URL>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-external-signer-url=http://localhost:9000
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_URL=http://localhost:9000
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-url: "http://localhost:9000"
```

  </TabItem>
</Tabs>

The URL on which the external signer (for example, Web3Signer) is running.

### `validators-graffiti`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-graffiti=<STRING>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-graffiti="Teku validator"
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_GRAFFITI="Teku validator"
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-graffiti: "Teku validator"
```

  </TabItem>
</Tabs>

The graffiti to add when creating a block.
This is converted to bytes and padded to `Bytes32`.

The same graffiti is used for all validators started with this beacon node.

[`--validators-graffiti-file`](#validators-graffiti-file) takes precedence if both options are set.

### `validators-graffiti-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-graffiti-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-graffiti-file=/Users/me/mynode/graffiti.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_GRAFFITI_FILE=/Users/me/mynode/graffiti.txt
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-graffiti-file: "/Users/me/mynode/graffiti.txt"
```

  </TabItem>
</Tabs>

The file containing the validator graffiti to add when creating a block.
The file contents are converted to bytes and padded to `Bytes32`.
The same graffiti is used for all validators started with this beacon node.

You can overwrite the file while Teku is running to update the graffiti.

This option takes precedence over [`--validators-graffiti`](#validators-graffiti).

### `validators-graffiti-client-append-format`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-graffiti-client-append-format=<STRING>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-graffiti-client-append-format=CLIENT_CODES
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_GRAFFITI_CLIENT_APPEND_FORMAT=CLIENT_CODES
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-graffiti-client-append-format: CLIENT_CODES
```

  </TabItem>
</Tabs>

Appends consensus layer (CL) and execution layer (EL) clients' information to the validator graffiti.
When running a beacon node and validator client separately, set this option on the beacon node.
This feature helps developers and community members analyze client diversity and block anomalies.

The default is `AUTO`.

Possible values are:

- `AUTO`: If validator graffiti is empty, it automatically updates to include information about the
  CL/EL clients, including their codes and build commits.
  For example, `TK508459f2BUbb9ba13c`:

  - `TK` represents the Teku consensus layer client.
  - `508459f2` is the Teku build commit.
  - `BU` represents the Besu execution layer client.
  - `bb9ba13c` is the Besu build commit.

  If the graffiti is set, this option calculates the space left (graffiti size is 32 bytes).
  If there are more than four characters left, it appends either the full CL/EL version information
  or one of its compact forms up to four characters (client codes only).
  For example, if the graffiti is `It's my first block`, it's updated to something similar to
  `It's my first block TK50BUbb`.

- `CLIENT_CODES`: Appends only CL/EL client codes such as `TKBU`.
  This option is useful if you're not sure if version information can be used to exploit
  vulnerabilities, or if you just don't want to share any extra information.

- `DISABLED`: Client information is not appended.
  If the graffiti is set, it goes as-is in a block, otherwise empty graffiti is used.

### `validator-is-local-slashing-protection-synchronized-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-is-local-slashing-protection-synchronized-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validator-is-local-slashing-protection-synchronized-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_IS_LOCAL_SLASHING_PROTECTION_SYNCHRONIZED_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-is-local-slashing-protection-synchronized-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables performing slashing protection checks in a sequential manner.

When set to `true`, Teku performs slashing protection checks sequentially.
Sequential checks restrict the throughput of duties, and under some scenarios, can improve
performance to allow more granular in-process locking of slashing protection data.

When set to `false`, Teku performs slashing protection checks concurrently.
The local slashing protection process can check if signing is safe for multiple
keys concurrently, reducing latencies experienced while performing these checks.

The default is `true`.

### `validator-keys`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validator-keys=<KEY_DIR>:<PASS_DIR> | <KEY_FILE>:<PASS_FILE>[,<KEY_DIR>:<PASS_DIR> | <KEY_FILE>:<PASS_FILE>...]...
```

  </TabItem>
  <TabItem value="Example for directory" label="Example for directory" >

```bash
--validator-keys=/home/validator/keys:home/validator/passwords
```

  </TabItem>
  <TabItem value="Example for file" label="Example for file" >

```bash
--validator-keys=/home/validator/keys/validator_217179e.json:/home/validator/passwords/validator_217179e.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_KEYS=/home/validator/keys:home/validator/passwords
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-keys: "/home/validator/keys:home/validator/passwords"
```

  </TabItem>
</Tabs>

The directory or file to load the encrypted keystore files and associated password files from.
Keystore files must use the `.json` file extension, and password files must use the `.txt` file extension.

When specifying directories, Teku expects to find identically named keystore and password files.
For example `validator_217179e.json` and `validator_217179e.txt`.

:::tip

You can [load new validators without restarting Teku] if you specify a directory from which to load
the keystore files.

:::

When specifying file names, Teku expects that the files exist.

### `validators-keystore-locking-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-keystore-locking-enabled=<BOOLEAN>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-keystore-locking-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_KEYSTORE_LOCKING_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-keystore-locking-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables locking the keystore files listed in [`--validator-keys`](#validator-keys).
The default is `true`.

Attempts to lock all keystores in a directory if a directory is specified in [`--validator-keys`](#validator-keys).

### `validators-performance-tracking-mode`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-performance-tracking-mode=<STRING>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-performance-tracking-mode=LOGGING
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_PERFORMANCE_TRACKING_MODE=LOGGING
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-performance-tracking-mode: LOGGING
```

  </TabItem>
</Tabs>

The validator performance tracking strategy.
Valid options are `LOGGING`, `METRICS`, `ALL`, and `NONE`.
The default is `ALL`.

When set to `LOGGING`, attestation and block performance are reported as log messages.
When set to `METRICS`, attestation and block performance are reported using [metrics] in the
[`VALIDATOR_PERFORMANCE`](#metrics-categories) metrics category.

### `validators-proposer-config`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-proposer-config=<STRING>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-proposer-config=/home/me/node/proposerConfig.json
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_PROPOSER_CONFIG=/home/me/node/proposerConfig.json
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-proposer-config: "/home/me/node/proposerConfig.json"
```

  </TabItem>
</Tabs>

The remote URL or local file path to the
[proposer configuration file](../../how-to/configure/use-proposer-config-file.md).

### `validators-proposer-config-refresh-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-proposer-config-refresh-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-proposer-config-refresh-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_PROPOSER_CONFIG_REFRESH_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-proposer-config-refresh-enabled: true
```

  </TabItem>
</Tabs>

Enables or disables reloading the
[proposer configuration](../../how-to/configure/use-proposer-config-file.md) on every proposer
preparation (once per epoch).
The default is `false`.

### `validators-proposer-default-fee-recipient`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--validators-proposer-default-fee-recipient=<ADDRESS>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--validators-proposer-default-fee-recipient=0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_PROPOSER_DEFAULT_FEE_RECIPIENT=0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-proposer-default-fee-recipient: "0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73"
```

  </TabItem>
</Tabs>

The default recipient of transaction fees for all validator keys.
When running a validator, this is an alternative to the `fee_recipient` in the
[default proposer configuration](../../how-to/configure/use-proposer-config-file.md).

:::tip

We recommend using this option when running a beacon node serving APIs to other validator clients.

The specified fee recipient is used in rare cases when a validator requests a block production but
its fee recipient is still unknown for the beacon node.

:::

### `version`

```bash title="Syntax"
-V, --version
```

Displays the version and exits.

### `ws-checkpoint`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
--ws-checkpoint=<BLOCK_ROOT>:<EPOCH_NUMBER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
--ws-checkpoint=0x5a642bb8f367e98c0d11426d98d28c465f8988fc960500886cb49faf0372883a:3600
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_WS_CHECKPOINT=0x5a642bb8f367e98c0d11426d98d28c465f8988fc960500886cb49faf0372883a:3600
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
ws-checkpoint: "0x5a642bb8f367e98c0d11426d98d28c465f8988fc960500886cb49faf0372883a:3600"
```

  </TabItem>
</Tabs>

A recent checkpoint within the [weak subjectivity period].
Accepts the checkpoint using `<blockRoot>:<epochNumber>`, where `<blockRoot>` must start with `0x`.

The weak subjectivity checkpoint is a recent, finalized checkpoint on the correct chain.
By supplying a weak subjectivity checkpoint, you ensure that nodes that have been offline for a long
period follow the correct chain.
It protects the node from long-range attacks by malicious actors.

Use the [`admin weak-subjectivity`](subcommands/admin.md#weak-subjectivity) subcommand to display or
clear your weak subjectivity settings.

<!-- links -->

[Infura]: https://infura.io/
[Teku metrics]: ../../how-to/monitor/use-metrics.md
[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
[slashing protection]: ../../concepts/slashing-protection.md
[weak subjectivity period]: ../../concepts/weak-subjectivity.md
[load new validators without restarting Teku]: ../../how-to/load-validators-without-restarting.md
[recent finalized checkpoint state from which to sync]: ../../get-started/checkpoint-start.md
[consensus specification]: https://github.com/ethereum/consensus-specs/tree/master/configs
[metrics]: ../../how-to/monitor/use-metrics.md

---

## admin

# `admin`

Used to perform administrative tasks.

## `weak-subjectivity`

Display or clear weak subjectivity configuration.

### `clear-state`

Clears the stored weak subjectivity configuration.

#### `config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity clear-state --config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity clear-state --config-file=/home/me/me_node/config.yaml
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
```

  </TabItem>
</Tabs>

Path to the YAML configuration file. The default is `none`.

#### `data-base-path`, `data-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity clear-state --data-base-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity clear-state --data-base-path=/home/me/me_node
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_BASE_PATH=/home/me/me_node
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-base-path: "/home/me/me_node"
```

  </TabItem>
</Tabs>

Path to the Teku data directory. The default directory is OS-dependent:

- macOS: `~/Library/teku`
- Unix/Linux: `$XDG_DATA_HOME/teku` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku`

The default Docker image location is `/root/.local/share/teku`.

#### `data-beacon-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity clear-state --data-beacon-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity clear-state --data-beacon-path=/home/me/me_beacon
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_BEACON_PATH=/home/me/me_beacon
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-beacon-path: "/home/me/me_beaon"
```

  </TabItem>
</Tabs>

Path to the beacon node data. The default is `<data-base-path>/beacon` where `<data-base-path>` is specified using [`--data-base-path`](#data-base-path-data-path).

#### `data-storage-archive-frequency`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity clear-state --data-storage-archive-frequency=<NUMBER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity clear-state --data-storage-archive-frequency=1028
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_STORAGE_ARCHIVE_FREQUENCY=1028
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-storage-archive-frequency: 1028
```

  </TabItem>
</Tabs>

Set the frequency (in slots) at which to store finalized states to disk. The default is 2048.

This option is ignored if [`--data-storage-mode`](#data-storage-mode) is set to `minimal`.

:::note

Specifying a larger number of slots as the archive frequency has a potentially higher overhead for retrieving
finalized states since more states may need to be regenerated to get to the requested state. Specifying a lower
number of slots as the frequency increases the disk space usage.

:::

For example, `--data-storage-archive-frequency=1` uses maximum disk space but has the lowest response time for
retrieving a finalized state since each slot state is saved, whereas `--data-storage-archive-frequency=2048` uses
less disk space, but may need to regenerate the state because every 2048th slot state is saved.

#### `data-storage-mode`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity clear-state --data-storage-mode=<STORAGE_MODE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity clear-state --data-storage-mode=archive
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_STORAGE_MODE=archive
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-storage-mode: "archive"
```

  </TabItem>
</Tabs>

Set the strategy for handling historical chain data. Valid options are `archive`, `minimal` and `prune`. The default is [`minimal`](#data-storage-mode).

#### `data-validator-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity clear-state --data-validator-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity clear-state --data-validator-path=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-validator-path: "/home/me/me_validator"
```

  </TabItem>
</Tabs>

Path to the validator client data. The default is `<data-base-path>/validator` where `<data-base-path>` is specified using [`--data-base-path`](#data-base-path-data-path).

#### `eth1-deposit-contract-address`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity clear-state --eth1-deposit-contract-address=<ADDRESS>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity clear-state --eth1-deposit-contract-address=0x77f7bED277449F51505a4C54550B074030d989bC
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_ETH1_DEPOSIT_CONTRACT_ADDRESS=0x77f7bED277449F51505a4C54550B074030d989bC
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
eth1-deposit-contract-address: "0x77f7bED277449F51505a4C54550B074030d989bC"
```

  </TabItem>
</Tabs>

The address of the deposit contract. Only required when creating a custom network.

#### `network`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity clear-state --network=<NETWORK>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity clear-state --network=mainnet
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_NETWORK=mainnet
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
network: "mainnet"
```

  </TabItem>
</Tabs>

Predefined network configuration. Accepts a predefined network name, or file path or URL to a YAML configuration file. The default is `mainnet`.

Possible values are:

| Network    | Chain           | Type       | Description                                                           |
|------------|-----------------|------------|-----------------------------------------------------------------------|
| `mainnet`  | Consensus layer | Production | Main network                                                          |
| `hoodi`    | Consensus layer | Test       | Multi-client testnet                                                  |
| `ephemery` | Consensus layer | Test       | Multi-client testnet                                                  |
| `sepolia`  | Consensus layer | Test       | Multi-client testnet                                                  |
| `minimal`  | Consensus layer | Test       | Used for local testing and development networks                       |
| `gnosis`   | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/)                |
| `chiado`   | Consensus layer | Test       | Gnosis [testnet](https://docs.gnosischain.com/about/networks/chiado/) |
| `lukso`    | Consensus layer | Production | Network for the [Lukso chain](https://lukso.network/)                 |

Predefined networks can provide defaults such the initial state of the network, bootnodes, and the address of the deposit contract.

### `display-state`

Displays the stored weak subjectivity configuration.

#### `config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity display-state --config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity display-state --config-file=/home/me/me_node/config.yaml
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
```

  </TabItem>
</Tabs>

Path to the YAML configuration file. The default is `none`.

#### `data-base-path`, `data-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity display-state --data-base-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity display-state --data-base-path=/home/me/me_node
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_BASE_PATH=/home/me/me_node
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-base-path: "/home/me/me_node"
```

  </TabItem>
</Tabs>

Path to the Teku data directory. The default directory is OS-dependent:

- macOS: `~/Library/teku`
- Unix/Linux: `$XDG_DATA_HOME/teku` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku`

The default Docker image location is `/root/.local/share/teku`.

#### `data-beacon-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity display-state --data-beacon-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity display-state --data-beacon-path=/home/me/me_beacon
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_BEACON_PATH=/home/me/me_beacon
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-beacon-path: "/home/me/me_beacon"
```

  </TabItem>
</Tabs>

Path to the beacon node data. The default is `<data-base-path>/beacon` where `<data-base-path>` is specified using [`--data-base-path`](#data-base-path-data-path).

#### `data-storage-archive-frequency`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity display-state --data-storage-archive-frequency=<NUMBER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity display-state --data-storage-archive-frequency=1028
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_STORAGE_ARCHIVE_FREQUENCY=1028
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-storage-archive-frequency: 1028
```

  </TabItem>
</Tabs>

Set the frequency (in slots) at which to store finalized states to disk. The default is 2048.

This option is ignored if [`--data-storage-mode`](#data-storage-mode) is not set to `archive`.

:::note

Specifying a larger number of slots as the archive frequency has a potentially higher overhead for retrieving
finalized states since more states may need to be regenerated to get to the requested state. Specifying a lower
number of slots as the frequency increases the disk space usage.

:::

For example, `--data-storage-archive-frequency=1` uses maximum disk space but has the lowest response time for
retrieving a finalized state since each slot state is saved, whereas `--data-storage-archive-frequency=2048` uses
less disk space, but may need to regenerate the state because every 2048th slot state is saved.

#### `data-storage-mode`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity display-state --data-storage-mode=<STORAGE_MODE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity display-state --data-storage-mode=archive
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_STORAGE_MODE=archive
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-storage-mode: "archive"
```

  </TabItem>
</Tabs>

Set the strategy for handling historical chain data. Valid options are `archive`, `minimal`, and `prune`. The default is `minimal`.

#### `data-validator-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity display-state --data-validator-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity display-state --data-validator-path=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-validator-path: "/home/me/me_validator"
```

  </TabItem>
</Tabs>

Path to the validator client data. The default is `<data-base-path>/validator` where `<data-base-path>` is specified using [`--data-base-path`](#data-base-path-data-path).

#### `eth1-deposit-contract-address`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity display-state --eth1-deposit-contract-address=<ADDRESS>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity display-state --eth1-deposit-contract-address=0x77f7bED277449F51505a4C54550B074030d989bC
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_ETH1_DEPOSIT_CONTRACT_ADDRESS=0x77f7bED277449F51505a4C54550B074030d989bC
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
eth1-deposit-contract-address: "0x77f7bED277449F51505a4C54550B074030d989bC"
```

  </TabItem>
</Tabs>

The address of the deposit contract. Only required when creating a custom network.

#### `network`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku admin weak-subjectivity display-state --network=<NETWORK>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku admin weak-subjectivity display-state --network=mainnet
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_NETWORK=mainnet
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
network: "mainnet"
```

  </TabItem>
</Tabs>

Predefined network configuration. Accepts a predefined network name, or file path or URL to a YAML configuration file. The default is `mainnet`.

Possible values are:

| Network    | Chain           | Type       | Description                                                           |
|------------|-----------------|------------|-----------------------------------------------------------------------|
| `mainnet`  | Consensus layer | Production | Main network                                                          |
| `hoodi`    | Consensus layer | Test       | Multi-client testnet                                                  |
| `ephemery` | Consensus layer | Test       | Multi-client testnet                                                  |
| `sepolia`  | Consensus layer | Test       | Multi-client testnet                                                  |
| `minimal`  | Consensus layer | Test       | Used for local testing and development networks                       |
| `gnosis`   | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/)                |
| `chiado`   | Consensus layer | Test       | Gnosis [testnet](https://docs.gnosischain.com/about/networks/chiado/) |
| `lukso`    | Consensus layer | Production | Network for the [Lukso chain](https://lukso.network/)                 |

Predefined networks can provide defaults such the initial state of the network, bootnodes, and the address of the deposit contract.

---

## bootnode

# `bootnode`

Run Teku in [bootnode-only](../../../how-to/find-and-connect/run-a-bootnode.md) mode.

## `network`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku bootnode --network=<NETWORK>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku bootnode --network=mainnet
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_NETWORK=mainnet
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
network: "mainnet"
```

  </TabItem>
</Tabs>

Predefined network configuration. The default is `mainnet`.

Possible values are:

| Network    | Chain           | Type       | Description                                                           |
|------------|-----------------|------------|-----------------------------------------------------------------------|
| `mainnet`  | Consensus layer | Production | Main network                                                          |
| `hoodi`    | Consensus layer | Test       | Multi-client testnet                                                  |
| `ephemery` | Consensus layer | Test       | Multi-client testnet                                                  |
| `sepolia`  | Consensus layer | Test       | Multi-client testnet                                                  |
| `minimal`  | Consensus layer | Test       | Used for local testing and development networks                       |
| `gnosis`   | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/)                |
| `chiado`   | Consensus layer | Test       | Gnosis [testnet](https://docs.gnosischain.com/about/networks/chiado/) |
| `lukso`    | Consensus layer | Production | Network for the [Lukso chain](https://lukso.network/)                 |

## `p2p-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku bootnode --p2p-port=<PORT>[,<PORT>...]...
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku bootnode --p2p-port=9000
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_PORT=9000
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-port: 9000
```

  </TabItem>
</Tabs>

The P2P listening ports (UDP and TCP). The default is 9000.

## `p2p-advertised-ip`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku bootnode --p2p-advertised-ip=<IP_ADDRESS>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku bootnode --p2p-advertised-ip=192.168.1.132
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_ADVERTISED_IP=192.168.1.132
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-advertised-ip: "192.168.1.132"
```

  </TabItem>
</Tabs>

The peer-to-peer IP address(es) to advertise. The default address is `127.0.0.1`.

## `p2p-private-key-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku bootnode --p2p-private-key-file=<PATH_TO_FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku bootnode --p2p-private-key-file=/home/me/me_node/key
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_P2P_PRIVATE_KEY_FILE=/home/me/me_node/key
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
p2p-private-key-file: "/home/me/me_node/key"
```

  </TabItem>
</Tabs>

The file containing the [node's private key](../../../concepts/p2p-networking.md#node-identity-and-private-key).

If a file doesn't exist at the specified path, Teku creates a new file and P2P private key to store inside.

:::important

Ensure you specify the complete file path, including the file name, and not only the directory location.

:::

## `config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku bootnode --config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku bootnode --config-file=/home/me/me_node/config.yaml
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
```

  </TabItem>
</Tabs>

Path to the YAML configuration file. The default is `none`.

## `data-base-path`, `data-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku bootnode --data-base-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku bootnode --data-base-path=/home/me/me_node
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_BASE_PATH=/home/me/me_node
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-base-path: "/home/me/me_node"
```

  </TabItem>
</Tabs>

Path to the Teku base directory for storage. The default directory is OS-dependent:

- macOS: `~/Library/teku`
- Unix/Linux: `$XDG_DATA_HOME/teku` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku`

The default Docker image location is `/root/.local/share/teku`.

## `log-color-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku bootnode --log-color-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku bootnode --log-color-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_COLOR_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-color-enabled: false
```

  </TabItem>
</Tabs>

Specify whether status and event log messages include a console color display code. The default is `true`.

## `log-destination`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku bootnode --log-destination=<LOG_DESTINATION>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku bootnode --log-destination=CONSOLE
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_DESTINATION=CONSOLE
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-destination: "CONSOLE"
```

  </TabItem>
</Tabs>

Specify where to output log information. Valid options are:

- `BOTH`
- `CONSOLE`
- `DEFAULT_BOTH`
- `FILE`

The default is `DEFAULT_BOTH`. When using `BOTH` or `DEFAULT_BOTH`, system updates such as blockchain events are displayed on the console, and errors and other information are logged to a file.
Specify the log file with the `--log-file` command line option.

For production systems we recommend using the `CONSOLE` or `FILE` options to ensure all log information is available in one place.

:::note

Use `DEFAULT_BOTH` when using a [custom Log4J2 configuration file](../../../how-to/monitor/configure-logging.md#advanced-custom-logging).
Any other option applies the custom logging changes on top of its default settings.

:::

---

## Development and testing

# Development and testing subcommands

The following subcommands are used for development and testing purposes.

## `genesis`

Generate a genesis state for a network.

```bash
teku genesis
```

## `peer`

Generate a list of peer IDs, including the private key, public key, and peer ID.

```bash
teku peer
```

## `transition`

Manually run state transitions for blocks or slots for debugging.

```bash
teku transition
```

---

## Subcommands

# Teku subcommands

This reference describes the syntax of the Teku subcommands.

To start a Teku node using subcommands, run:

```bash
teku [OPTIONS] [SUBCOMMANDS] [SUBCOMMAND OPTIONS]
```

You can also supply the subcommand options using [environment variables or a configuration file](../index.md#specify-options).

The available subcommands are:

- [`admin`](admin.md)
- [`migrate-database`](migrate-database.md)
- [`bootnode`](bootnode.md)
- [`slashing-protection`](slashing-protection.md)
- [`validator-client`](validator-client.md)
- [`voluntary-exit`](voluntary-exit.md)
- [Development and testing subcommands](development.md)

## Using autocomplete

If using Bash or Z shell, you can enable autocomplete support by navigating to the `build` folder and running:

```bash
source teku.autocomplete.sh
```

Autocomplete allows you to view subcommand suggestions by pressing the Tab key twice.

```bash
teku Tab+Tab
```

---

## migrate-database

# `migrate-database`

[Migrate the database to a RocksDB database](../../../how-to/migrate-database.md).

:::note

As of v26.2.0, new Teku installations use a RocksDB database. Previous Teku versions use LevelDB which has been deprecated and may be removed in a future release.

:::

:::caution

Before running the database migration, you must shut down the local Teku instance and confirm the process has fully exited and won't be restarted.

:::

## `config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku migrate-database --config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku migrate-database --config-file=/home/me/me_node/config.yaml
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
```

  </TabItem>
</Tabs>

Path to the [YAML configuration file](../../../how-to/configure/use-config-file.md). The default is `none`.

## `data-base-path`, `data-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku migrate-database --data-base-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku migrate-database --data-base-path=/home/me/me_node
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_BASE_PATH=/home/me/me_node
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-base-path: "/home/me/me_node"
```

  </TabItem>
</Tabs>

Path to the Teku data directory. The default directory is OS-dependent:

- macOS: `~/Library/teku`
- Unix/Linux: `$XDG_DATA_HOME/teku` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku`

The default Docker image location is `/root/.local/share/teku`.

## `data-beacon-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku migrate-database --data-beacon-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku migrate-database --data-beacon-path=/home/me/me_node
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_BEACON_PATH=/home/me/me_node
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-beacon-path: "/home/me/me_node"
```

  </TabItem>
</Tabs>

Path to the beacon node data. The default is `<data-base-path>/beacon` where `<data-base-path>` is specified using [`--data-base-path`](#data-base-path-data-path).

## `network`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku migrate-database --network=<NETWORK>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku migrate-database --network=mainnet
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_NETWORK=mainnet
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
network: "mainnet"
```

  </TabItem>
</Tabs>

Predefined network configuration. Accepts a predefined network name, or file path or URL to a YAML configuration
file. See the [consensus specification](https://github.com/ethereum/consensus-specs/tree/master/configs) for examples.

The default is `mainnet`.

Possible values are:

| Network    | Chain           | Type       | Description                                                           |
|------------|-----------------|------------|-----------------------------------------------------------------------|
| `mainnet`  | Consensus layer | Production | Main network                                                          |
| `hoodi`    | Consensus layer | Test       | Multi-client testnet                                                  |
| `ephemery` | Consensus layer | Test       | Multi-client testnet                                                  |
| `sepolia`  | Consensus layer | Test       | Multi-client testnet                                                  |
| `minimal`  | Consensus layer | Test       | Used for local testing and development networks                       |
| `gnosis`   | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/)                |
| `chiado`   | Consensus layer | Test       | Gnosis [testnet](https://docs.gnosischain.com/about/networks/chiado/) |
| `lukso`    | Consensus layer | Production | Network for the [Lukso chain](https://lukso.network/)                 |

---

## slashing-protection

# `slashing-protection`

Manage the local [slashing protection data] used by the validator.

## `export`

Exports the slashing protection database in the [validator client interchange format].

### `config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection export --config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection export --config-file=/home/me/me_node/config.yaml
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
```

  </TabItem>
</Tabs>

Path to the YAML configuration file. The default is `none`.

### `data-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection export --data-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection export --data-path=/home/me/me_node
```

  </TabItem>
</Tabs>

Path to the Teku data directory. The default directory is OS-dependent:

- macOS: `~/Library/teku`
- Unix/Linux: `$XDG_DATA_HOME/teku` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku`

### `data-validator-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection export --data-validator-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection export --data-validator-path=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-validator-path: "/home/me/me_validator"
```

  </TabItem>
</Tabs>

Path to the validator client data. The default is `<data-path>/validator` where `<data-path>` is specified using [`--data-path`](#data-path).

:::info

Teku exports slashing protection data from the `slashprotection` directory under the validator client data directory.

:::

### `to`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection export --to=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection export --to=/home/slash/b845...23bed.json
```

  </TabItem>
</Tabs>

The file to export the slashing protection database to.

Exports the database in the [validator client interchange format].

## `import`

Imports the slashing protection database using the [validator client interchange format].

:::caution

Before running the import, you must stop the validator and confirm the process has fully exited and won't be restarted.

:::

### `config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection import --config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection import --config-file=/home/me/me_node/config.yaml
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
```

  </TabItem>
</Tabs>

Path to the YAML configuration file. The default is `none`.

### `data-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection import --data-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection import --data-path=/home/me/me_node
```

  </TabItem>
</Tabs>

Path to the Teku data directory. The default directory is OS-dependent:

- macOS: `~/Library/teku`
- Unix/Linux: `$XDG_DATA_HOME/teku` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku`

### `data-validator-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection import --data-validator-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection import --data-validator-path=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-validator-path: "/home/me/me_validator"
```

  </TabItem>
</Tabs>

Path to the validator client data. The default is `<data-path>/validator` where `<data-path>` is specified using [`--data-path`](#data-path).

:::info

Teku imports slashing protection data into a `slashprotection` directory under the validator client data directory.

:::

### `from`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection import --from=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection import --from=/home/slash/b845...23bed.json
```

  </TabItem>
</Tabs>

The file to import the slashing protection database from.

Teku imports the file to the `<data-path>/validators/slashprotection/` directory in the format `<validator-pubkey>.yml` (with no 0x prefix).

`<data-path>` is defined using [`--data-path`](#data-path).

## `repair`

Repairs corrupted slashing protection data files used by Teku.

### `check-only-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection repair --checking-only-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection repair --checking-only-enabled=false
```

  </TabItem>
</Tabs>

Reads and reports potential slashing protection file problems, but doesn't update any files. You can specify which files are checked using [`--config-file`](#config-file-2), [`--data-path`](#data-path-2).

### `config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection repair --config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection repair --config-file=/home/me/me_node/config.yaml
```

  </TabItem>
</Tabs>

Path to the YAML configuration file. The default is `none`.

### `data-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection repair --data-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection repair --data-path=/home/me/me_node
```

  </TabItem>
</Tabs>

Path to the Teku data directory. The default directory is OS-dependent:

- macOS: `~/Library/teku`
- Unix/Linux: `$XDG_DATA_HOME/teku` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku`

The default Docker image location is `/root/.local/share/teku`.

### `data-validator-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection repair --data-validator-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection repair --data-validator-path=/home/me/me_validator
```

  </TabItem>
</Tabs>

Path to validator client data. The default is `<data-path>/validator` where `<data-path>` is specified using [`--data-path`](#data-path).

:::info

The slashing protection data is stored in a `slashprotection` directory under the validator client data directory.

:::

### `network`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection repair --network=<NETWORK>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection repair --network=mainnet
```

  </TabItem>
</Tabs>

Predefined network configuration. Accepts a predefined network name, or file path or URL to a YAML configuration file. The default is `mainnet`.

Possible values are:

| Network    | Chain           | Type       | Description                                                           |
|------------|-----------------|------------|-----------------------------------------------------------------------|
| `mainnet`  | Consensus layer | Production | Main network                                                          |
| `hoodi`    | Consensus layer | Test       | Multi-client testnet                                                  |
| `ephemery` | Consensus layer | Test       | Multi-client testnet                                                  |
| `sepolia`  | Consensus layer | Test       | Multi-client testnet                                                  |
| `minimal`  | Consensus layer | Test       | Used for local testing and development networks                       |
| `gnosis`   | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/)                |
| `chiado`   | Consensus layer | Test       | Gnosis [testnet](https://docs.gnosischain.com/about/networks/chiado/) |
| `lukso`    | Consensus layer | Production | Network for the [Lukso chain](https://lukso.network/)                 |

Predefined networks can provide defaults such as the initial state of the network, bootnodes, and the address of the deposit contract.

### `slot`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection repair --slot=<INTEGER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection repair --slot=1028
```

  </TabItem>
</Tabs>

Updates slashing protection files to contain the specified slot as a minimum. The value should be a future slot, or after when the validators stopped performing duties.

:::note

This can be automatically calculated for most networks, and is generally not required.

:::

### `update-all-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku slashing-protection repair --update-all-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku slashing-protection repair --update-all-enabled=false
```

  </TabItem>
</Tabs>

Enables all slashing protection records to be updated. The default is `false`.

<!-- links -->

[slashing protection data]: ../../../concepts/slashing-protection.md
[validator client interchange format]: https://eips.ethereum.org/EIPS/eip-3076

---

## validator-client, vc

# `validator-client`, `vc`

Run a validator client that connects to a remote beacon node.

## `beacon-node-api-endpoint`, `beacon-node-api-endpoints`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --beacon-node-api-endpoint=<ENDPOINT>[,<ENDPOINT>...]...
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --beacon-node-api-endpoint=http://192.138.10.12:5051,http://192.140.11.44:5051
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_BEACON_NODE_API_ENDPOINT=http://192.138.10.12,http://192.140.11.44:5051
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
beacon-node-api-endpoint: ["http://192.138.10.12","http://192.140.11.44:5051"]
```

  </TabItem>
</Tabs>

Endpoint of the beacon node's REST API. You can configure multiple beacon nodes by providing a comma-separated list of beacon node API endpoints.

If multiple beacon node endpoints are configured, the first one is used as primary and others as failovers.

:::note

This option cannot be used with the [sentry beacon nodes early access feature](../../../how-to/use-sentry-nodes.md).

:::

The default is `http://127.0.0.1:5051`.

## `beacon-node-ssz-blocks-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --beacon-node-ssz-blocks-enabled=<BOOLEAN>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --beacon-node-ssz-blocks-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_BEACON_NODE_SSZ_BLOCKS_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
beacon-node-ssz-blocks-enabled: false
```

  </TabItem>
</Tabs>

Enable or disable the use of SSZ encoding for API requests to the beacon node to create blocks. The default is `true`.

## `config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --config-file=/home/me/me_node/config.yaml
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
```

  </TabItem>
</Tabs>

Path to the YAML configuration file. The default is `none`.

## `data-base-path`, `data-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --data-base-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --data-base-path=/home/me/me_node
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_BASE_PATH=/home/me/me_node
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-base-path: "/home/me/me_node"
```

  </TabItem>
</Tabs>

Path to the Teku base directory for storage. The default directory is OS-dependent:

- macOS: `~/Library/teku`
- Unix/Linux: `$XDG_DATA_HOME/teku` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku`

The default Docker image location is `/root/.local/share/teku`.

## `data-validator-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --data-validator-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --data-validator-path=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
data-validator-path: "/home/me/me_validator"
```

  </TabItem>
</Tabs>

Path to the validator client data. The default is `<data-base-path>/validator` where `<data-base-path>` is specified using [`--data-base-path`](#data-base-path-data-path).

## `log-color-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --log-color-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --log-color-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_COLOR_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-color-enabled: false
```

  </TabItem>
</Tabs>

Specify whether status and event log messages include a console color display code. The default is `true`.

## `log-destination`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --log-destination=<LOG_DESTINATION>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --log-destination=CONSOLE
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_DESTINATION=CONSOLE
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-destination: "CONSOLE"
```

  </TabItem>
</Tabs>

Specify where to output log information. Valid options are:

- `BOTH`
- `CONSOLE`
- `DEFAULT_BOTH`
- `FILE`

The default is `DEFAULT_BOTH`. When using `BOTH` or `DEFAULT_BOTH`, system updates such as blockchain events
are displayed on the console, and errors and other information are logged to a file. Specify the log file
with the [`--log-file`](#log-file) command-line option.

For production systems we recommend using the `CONSOLE` or `FILE` options to ensure all log information is available in one place.

:::note

Use `DEFAULT_BOTH` when using a
[custom Log4J2 configuration file](../../../how-to/monitor/configure-logging.md#advanced-custom-logging). Any
other option applies the custom logging changes on top of its default settings.

:::

## `log-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --log-file=<FILENAME>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --log-file=teku_2020-01-01.log
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_FILE=teku_2020-01-01.log
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-file: "teku_2020-01-01.log"
```

  </TabItem>
</Tabs>

Relative or absolute location, and filename of the log file.

The default directory is OS-dependent:

- macOS: `~/Library/teku/logs`
- Unix/Linux: `$XDG_DATA_HOME/teku/logs` if `$XDG_DATA_HOME` is set; otherwise `~/.local/share/teku/logs`

The default Docker image location is `/root/.local/share/teku/logs`.

## `log-file-name-pattern`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --log-file-name-pattern=<REGEX>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --log-file-name-pattern=tekuL_%d{yyyy-MM-dd}.log
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_FILE_NAME_PATTERN=tekuL_%d{yyyy-MM-dd}.log
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-file-name-pattern: "tekuL_%d{yyyy-MM-dd}.log"
```

  </TabItem>
</Tabs>

Filename pattern to apply when creating log files. The default pattern is `teku_%d{yyyy-MM-dd}.log`

## `log-include-events-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --log-include-events-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --log-include-events-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_INCLUDE_EVENTS_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-include-events-enabled: false
```

  </TabItem>
</Tabs>

Specify whether to log frequent update events. For example every slot event with validators and attestations. The default is `true`.

## `log-include-validator-duties-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --log-include-validator-duties-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --log-include-validator-duties-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_LOG_INCLUDE_VALIDATOR_DUTIES_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
log-include-validator-duties-enabled: true
```

  </TabItem>
</Tabs>

Specify whether to log details of validator event duties. The default is `true`.

:::note

Logs could become noisy when running many validators.

:::

## `metrics-categories`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --metrics-categories=<CATEGORY>[,<CATEGORY>...]...
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --metrics-categories=BEACON,JVM,PROCESS
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_CATEGORIES=BEACON,JVM,PROCESS
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-categories: ["BEACON", "JVM", "PROCESS"]
```

  </TabItem>
</Tabs>

Categories for which to track metrics. Options are `JVM`, `PROCESS`, `BEACON`, `DISCOVERY`, `EVENTBUS`, `EXECUTOR`,
`LIBP2P`, `NETWORK`, `STORAGE`, `STORAGE_HOT_DB`, `STORAGE_FINALIZED_DB`, `VALIDATOR`,
`VALIDATOR_PERFORMANCE`, `VALIDATOR_DUTY`.

When `metrics-categories` is used, only the categories specified in this option are enabled (all other categories are disabled).

## `metrics-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --metrics-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --metrics-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-enabled: true
```

  </TabItem>
</Tabs>

Set to `true` to enable the metrics exporter. The default is `false`.

## `metrics-host-allowlist`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --metrics-host-allowlist=<hostname>[,<hostname>...]... or "*"
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --metrics-host-allowlist=medomain.com,meotherdomain.com
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_HOST_ALLOWLIST=medomain.com,meotherdomain.com
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-host-allowlist: ["medomain.com", "meotherdomain.com"]
```

  </TabItem>
</Tabs>

A comma-separated list of hostnames to allow access to the [Teku metrics]. By default, Teku accepts access from `localhost` and `127.0.0.1`.

:::tip

To allow all hostnames, use `"*"`. We don't recommend allowing all hostnames for production environments.

:::

## `metrics-interface`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --metrics-interface=<HOST>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --metrics-interface=192.168.10.101
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_INTERFACE=192.168.10.101
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-interface: "192.168.10.101"
```

  </TabItem>
</Tabs>

Host on which Prometheus accesses Teku metrics. The default is `127.0.0.1`.

## `metrics-port`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --metrics-port=<PORT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --metrics-port=6174
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_METRICS_PORT=6174
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
metrics-port: 6174
```

  </TabItem>
</Tabs>

Specifies the port (TCP) on which [Prometheus](https://prometheus.io/) accesses Teku metrics. The default is `8008`.

## `network`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --network=<NETWORK>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --network=auto
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_NETWORK=auto
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
network: "auto"
```

  </TabItem>
</Tabs>

Predefined network configuration. The default is `mainnet`.

Use `auto` to fetch the network configuration from the beacon node endpoint directly.

## `validator-keys`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validator-keys=<KEY_DIR>:<PASS_DIR> | <KEY_FILE>:<PASS_FILE>[,<KEY_DIR>:<PASS_DIR> | <KEY_FILE>:<PASS_FILE>...]...
```

  </TabItem>
  <TabItem value="Example for directory" label="Example for directory" >

```bash
teku vc --validator-keys=/home/validator/keys:home/validator/passwords
```

  </TabItem>
  <TabItem value="Example for file" label="Example for file" >

```bash
teku vc --validator-keys=/home/validator/keys/validator_217179e.json:/home/validator/passwords/validator_217179e.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_KEYS=/home/validator/keys:home/validator/passwords
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-keys: "/home/validator/keys:home/validator/passwords"
```

  </TabItem>
</Tabs>

Directory or file to load the encrypted keystore files and associated password files from. Keystore files
must use the `.json` file extension, and password files must use the `.txt` file extension.

When specifying directories, Teku expects to find identically named keystore and password files. For
example `validator_217179e.json` and `validator_217179e.txt`.

When specifying file names, Teku expects that the files exist.

## `validators-early-attestations-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-early-attestations-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-early-attestations-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EARLY_ATTESTATIONS_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-early-attestations-enabled: false
```

  </TabItem>
</Tabs>

Specify whether to use Teku's built-in early attestation production, which creates an attestation once a block is
received. The default is `true`.

Set this option to `false` if running a validator client connected to a load balanced beacon node
(including most hosted beacon nodes such as [Infura]), and validator effectiveness is poor.

:::note

Delaying attestation production increases the chances of generating a correct attestation when using a load
balanced beacon node, but it increases the risk of inclusion delays.

:::

## `validators-external-signer-keystore`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-external-signer-keystore=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-external-signer-keystore=teku_client_keystore.p12
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_KEYSTORE=teku_client_keystore.p12
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-keystore: "teku_client_keystore.p12"
```

  </TabItem>
</Tabs>

The keystore that Teku presents to the external signer for TLS authentication. Teku can use PKCS12 or JKS keystore types.

Use the PKCS12 keystore type if connecting to Web3Signer.

## `validators-external-signer-keystore-password-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-external-signer-keystore-password-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-external-signer-keystore-password-file=keystore_pass.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_KEYSTORE_PASSWORD_FILE=keystore_pass.txt
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-keystore-password-file: "keystore_pass.txt"
```

  </TabItem>
</Tabs>

Password file used to decrypt the keystore.

## `validators-external-signer-public-keys`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-external-signer-public-keys=<KEY>[,<KEY>...]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_PUBLIC_KEYS=0xa99a...e44c,0xb89b...4a0b
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-public-keys: ["0xa99a...e44c","0xb89b...4a0b"]
```

  </TabItem>
</Tabs>

List or URL of validator public keys used by an external signer (for example, [Web3Signer]).

Use the URL to load the public keys from a remote service. For example:

```bash
--validators-external-signer-public-keys=http://localhost:9900/api/v1/eth2/publicKeys
```

Use the value `external-signer` to load all public keys managed by the external signer. Teku automatically
queries the external signer's [public keys endpoint](https://consensys.github.io/web3signer/#tag/Public-Key).

```bash
--validators-external-signer-public-keys=external-signer
```

## `validators-external-signer-slashing-protection-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-external-signer-slashing-protection-enabled[=<BOOLEAN>]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-external-signer-slashing-protection-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_SLASHING_PROTECTION_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-slashing-protection-enabled: false
```

  </TabItem>
</Tabs>

Specify whether to use Teku's built-in [slashing protection] when using an external signer such as [Web3Signer]. The default is `true`.

Set this option to `false` if using the slashing protection implemented by an external signer.

:::warning

Ensure the external signer has slashing protection enabled before disabling Teku slashing protection, otherwise
a validator may get slashed.

:::

Built-in slashing protection can only be disabled for validators using external signers. Validators using
Teku to sign blocks and attestations always uses its built-in slashing protection.

## `validators-external-signer-timeout`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-external-signer-timeout=<INTEGER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-external-signer-timeout=2000
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_TIMEOUT=2000
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-timeout: 2000
```

  </TabItem>
</Tabs>

Timeout in milliseconds for requests to the external signer. The default is 5000.

## `validators-external-signer-truststore`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-external-signer-truststore=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-external-signer-truststore=websigner_truststore.p12
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE=websigner_truststore.p12
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-truststore: "websigner_truststore.p12"
```

  </TabItem>
</Tabs>

PKCS12 or JKS keystore used to trust external signer's self-signed certificate or CA certificate which
signs the external signer's certificate.

## `validators-external-signer-truststore-password-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-external-signer-truststore-password-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-external-signer-truststore-password-file=truststore_pass.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE_PASSWORD_FILE=truststore_pass.txt
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-truststore-password-file: "truststore_pass.txt"
```

  </TabItem>
</Tabs>

Password file used to decrypt the [keystore](#validators-external-signer-truststore).

## `validators-external-signer-url`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-external-signer-url=<URL>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-external-signer-url=http://localhost:9000
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_URL=http://localhost:9000
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-url: "http://localhost:9000"
```

  </TabItem>
</Tabs>

URL on which the external signer (for example, Web3Signer) is running.

## `validators-graffiti`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-graffiti=<STRING>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-graffiti="Teku validator"
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_GRAFFITI="Teku validator"
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-graffiti: "Teku validator"
```

  </TabItem>
</Tabs>

Graffiti to add when creating a block. Gets converted to bytes and padded to Bytes32.

The same graffiti is used for all validators started with this beacon node.

## `validators-graffiti-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-graffiti-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-graffiti-file=/Users/me/mynode/graffiti.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_GRAFFITI_FILE=/Users/me/mynode/graffiti.txt
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-graffiti-file: "/Users/me/mynode/graffiti.txt"
```

  </TabItem>
</Tabs>

File containing the validator graffiti to add when creating a block. The file content is converted to `bytes`
and padded to `Bytes32`. The same graffiti is used for all validators started with this beacon node.

You can overwrite the file while Teku is running to update the graffiti.

This option takes precedence over [`--validators-graffiti`](#validators-graffiti).

## `validators-keystore-locking-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-keystore-locking-enabled=<BOOLEAN>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-keystore-locking-enabled=true
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_KEYSTORE_LOCKING_ENABLED=true
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-keystore-locking-enabled: true
```

  </TabItem>
</Tabs>

Locks the keystore files listed in [`--validator-keys`](#validator-keys). The default is `true`.

Attempts to lock all keystores in a directory if a directory is specified in [`--validator-keys`](#validator-keys).

## `validators-performance-tracking-mode`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku vc --validators-performance-tracking-mode=<STRING>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku vc --validators-performance-tracking-mode=LOGGING
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_PERFORMANCE_TRACKING_MODE=LOGGING
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-performance-tracking-mode: LOGGING
```

  </TabItem>
</Tabs>

Set the validator performance tracking strategy. Valid options are `LOGGING`, `METRICS`, `ALL`, and `NONE`. The default is `ALL`.

When `LOGGING` is enabled, attestation and block performance is reported as log messages. When `METRICS` is
enabled, attestation and block performance is reported using [metrics] in the [`VALIDATOR_PERFORMANCE`](#metrics-categories) metrics category.

<!-- links -->

[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
[slashing protection]: ../../../concepts/slashing-protection.md
[metrics]: ../../../how-to/monitor/use-metrics.md

---

## voluntary-exit

# `voluntary-exit`

Create and sign a [voluntary exit] for the specified validator or set of validators.
This subcommand can be run as a separate Teku process.

:::caution

To submit a voluntary exit, you must have a running beacon node with the [REST API enabled].

:::

## `beacon-node-api-endpoint`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --beacon-node-api-endpoint=<ENDPOINT>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --beacon-node-api-endpoint=http://192.138.10.12
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_BEACON_NODE_ENDPOINT=http://192.138.10.12
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
beacon-node-api-endpoint: "http://192.138.10.12"
```

  </TabItem>
</Tabs>

Endpoint of the beacon node's REST API. The default is `http://127.0.0.1:5051`.

## `config-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --config-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --config-file=/home/me/me_node/config.yaml
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
```

  </TabItem>
</Tabs>

Path to the YAML configuration file. The default is `none`.

## `confirmation-enabled`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --confirmation-enabled=<BOOLEAN>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --confirmation-enabled=false
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_CONFIRMATION_ENABLED=false
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
confirmation-enabled: false
```

  </TabItem>
</Tabs>

Specify whether to request confirmation when exiting a validator. The default is `true`.

:::warning

If you set `--confirmation-enabled` to `false`, exits are generated immediately without any prompt.

:::

## `epoch`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --epoch=<EPOCH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --epoch=24500
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_EPOCH=24500
```

  </TabItem>
</Tabs>

Earliest epoch that the voluntary exit can be processed. The specified epoch can be a past epoch, or current epoch. You cannot specify a future epoch. The default is the current epoch.

:::note

If there is a high number of validators that are queued to exit, then the validator exit may be processed at a later epoch.

:::

## `include-keymanager-keys`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --include-keymanager-keys=<BOOLEAN>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --include-keymanager-keys=true
```

  </TabItem>
</Tabs>

Include validator keys managed using the [key manager APIs](../../../how-to/use-external-signer/manage-keys.md). The default is `false`.

## `network`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --network=<NETWORK>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --network=mainnet
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_NETWORK=mainnet
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
network: "mainnet"
```

  </TabItem>
</Tabs>

Predefined network configuration. There is no default value, because Teku reads the network specification from the Beacon API unless specified.

## `save-exits-path`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --save-exits-path=<PATH>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --save-exits-path=signedExitsPath
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_SAVE_EXITS_PATH=signedExitsPath
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
save-exits-path: "signedExitsPath"
```

  </TabItem>
</Tabs>

Path at which to save the generated exit messages.
This option [creates but doesn't submit an exit](../../../how-to/voluntarily-exit.md#create-but-dont-submit-an-exit).
It doesn't validate the exit epoch, and doesn't publish the exit messages.

## `validator-keys`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --validator-keys=<KEY_DIR>:<PASS_DIR> | <KEY_FILE>:<PASS_FILE>[,<KEY_DIR>:<PASS_DIR> | <KEY_FILE>:<PASS_FILE>...]...
```

  </TabItem>
  <TabItem value="Example for directory" label="Example for directory" >

```bash
teku voluntary-exit --validator-keys=/home/validator/keys:home/validator/passwords
```

  </TabItem>
  <TabItem value="Example for file" label="Example for file" >

```bash
teku voluntary-exit --validator-keys=/home/validator/keys/validator_217179e.json:/home/validator/passwords/validator_217179e.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATOR_KEYS=/home/validator/keys:home/validator/passwords
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validator-keys: "/home/validator/keys:home/validator/passwords"
```

  </TabItem>
</Tabs>

Directory or file to load the encrypted keystores and passwords of the validators that you wish to exit.
Keystore files must use the `.json` file extension, and password files must use the `.txt` file extension.

When specifying directories, Teku expects to find identically named keystore and password files. For example `validator_217179e.json` and `validator_217179e.txt`.

When specifying file names, Teku expects that the files exist.

## `validator-public-keys`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --validator-public-keys=<PUBKEY>[,<PUBKEY>...]...
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --validator-public-keys=0xc7931ac6937f6c776d8dfe84918f7b26d986f2e45af5869085839b8817db2705,0x179a0e2768621eede9ce961cf8ee4f0ece5be9a1795c294269b69b85c765f3cc
```

  </TabItem>
</Tabs>

Restrict the exit command to a specified list of public keys. When the parameter is not used, all keys will be exited.

## `validators-external-signer-keystore`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --validators-external-signer-keystore=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --validators-external-signer-keystore=teku_client_keystore.p12
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_KEYSTORE=teku_client_keystore.p12
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-keystore: "teku_client_keystore.p12"
```

  </TabItem>
</Tabs>

The keystore that Teku presents to the external signer for TLS authentication. Teku can use PKCS12 or JKS keystore types.

Use the PKCS12 keystore type if connecting to Web3Signer.

## `validators-external-signer-keystore-password-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --validators-external-signer-keystore-password-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --validators-external-signer-keystore-password-file=keystore_pass.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_KEYSTORE_PASSWORD_FILE=keystore_pass.txt
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-keystore-password-file: "keystore_pass.txt"
```

  </TabItem>
</Tabs>

Password file used to decrypt the keystore.

## `validators-external-signer-public-keys`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --validators-external-signer-public-keys=<KEY>[,<KEY>...]
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_PUBLIC_KEYS=0xa99a...e44c,0xb89b...4a0b
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-public-keys: ["0xa99a...e44c","0xb89b...4a0b"]
```

  </TabItem>
</Tabs>

List of public keys of validators that you wish to voluntarily exit when using an external signer (for example, [Web3Signer]).

Use the URL to load the public keys from a remote service. For example:

```bash
teku voluntary-exit --validators-external-signer-public-keys=http://localhost:9900/api/v1/eth2/publicKeys
```

Use the value `external-signer` to load all public keys managed by the external signer. Teku automatically queries the external signer's [public keys endpoint](https://consensys.github.io/web3signer/#tag/Public-Key).

```bash
teku voluntary-exit --validators-external-signer-public-keys=external-signer
```

## `validators-external-signer-timeout`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --validators-external-signer-timeout=<INTEGER>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --validators-external-signer-timeout=2000
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_TIMEOUT=2000
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-timeout: 2000
```

  </TabItem>
</Tabs>

Timeout in milliseconds for requests to the external signer. The default is 5000.

## `validators-external-signer-truststore`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --validators-external-signer-truststore=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --validators-external-signer-truststore=websigner_truststore.p12
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE=websigner_truststore.p12
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-truststore: "websigner_truststore.p12"
```

  </TabItem>
</Tabs>

PKCS12 or JKS keystore used to trust external signer's self-signed certificate or CA certificate which signs the external signer's certificate.

## `validators-external-signer-truststore-password-file`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --validators-external-signer-truststore-password-file=<FILE>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --validators-external-signer-truststore-password-file=truststore_pass.txt
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE_PASSWORD_FILE=truststore_pass.txt
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-truststore-password-file: "truststore_pass.txt"
```

  </TabItem>
</Tabs>

Password file used to decrypt the keystore.

## `validators-external-signer-url`

<Tabs>
  <TabItem value="Syntax" label="Syntax" default>

```bash
teku voluntary-exit --validators-external-signer-url=<URL>
```

  </TabItem>
  <TabItem value="Example" label="Example" >

```bash
teku voluntary-exit --validators-external-signer-url=http://localhost:9000
```

  </TabItem>
  <TabItem value="Environment variable" label="Environment variable" >

```bash
TEKU_VALIDATORS_EXTERNAL_SIGNER_URL=http://localhost:9000
```

  </TabItem>
  <TabItem value="Configuration file" label="Configuration file" >

```bash
validators-external-signer-url: "http://localhost:9000"
```

  </TabItem>
</Tabs>

URL of the external signer (for example, [Web3Signer]).

<!-- links -->

[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
[REST API enabled]: ../index.md#rest-api-enabled
[voluntary exit]: ../../../how-to/voluntarily-exit.md

---

## Use the REST API


:::tip View the REST API
View the [REST API documentation] for information about the available API methods.
:::

## Enable the REST API service

Enable the REST API service from the command line by setting the [`--rest-api-enabled`](cli/index.md#rest-api-enabled) command line option to `true`.

You can also interact with APIs using Swagger UI by enabling the API documentation endpoint.

:::warning

Only trusted parties should access the REST API. Do not directly expose these APIs publicly on production nodes.

:::

Interact with Teku APIs using the web browser by setting the [`--rest-api-docs-enabled`](cli/index.md#rest-api-docs-enabled) command line option to `true`.

Access the APIs at `http:<interface>:<port>/swagger-ui` where:

- `interface` is specified using [`--rest-api-interface`](cli/index.md#rest-api-interface)
- `port` is specified using [`--rest-api-port`](cli/index.md#rest-api-port)

The default location is `http://localhost:5051/swagger-ui`.

You can also use tools such as [Postman] or [cURL] to interact with Teku APIs.

<Tabs>
  <TabItem value="cURL request" label="cURL request" default>

```bash
curl -X GET "http://localhost:5051/eth/v1/node/identity"
```

  </TabItem>
  <TabItem value="JSON Result" label="JSON Result" >

```json
{
  "data": {
    "peer_id": "16Uiu2HAkuWPWqF4W3aw9oo5Yw79v5muzBaaGTGKumuXR8qkSVq6y",
    "enr": "enr:-KG4QJ3PlL-XIRZCBq3L-uZ4wovEVEvxUMmvv75YDk9imb21clm0x3V2J5Vf9Zz3tLDpTplhG68_kzZPOxcU0ttwNDAEhGV0aDKQtTA_KgAAAAD__________4JpZIJ2NIJpcIS5a1YhiXNlY3AyNTZrMaECATVJhRqBrqyo8l6JKz6HidWL82kQcDmtKWuQZLDmZmqDdGNwgiMog3VkcILZIg",
    "p2p_addresses": [
      "/ip4/10.0.0.42/tcp/9000/p2p/16Uiu2HAkuWPWqF4W3aw9oo5Yw79v5muzBaaGTGKumuXR8qkSVq6y"
    ],
    "discovery_addresses": [
      "/ip4/10.0.0.42/udp/55586/p2p/16Uiu2HAkuWPWqF4W3aw9oo5Yw79v5muzBaaGTGKumuXR8qkSVq6y"
    ],
    "metadata": {
      "seq_number": "0",
      "attnets": "0x0000000000000000"
    }
  }
}
```

  </TabItem>
</Tabs>

### Configure the API for network interfaces and host allowlist

You can use the [`rest-api-host-allowlist`](cli/index.md#rest-api-host-allowlist) and [`rest-api-interface`](cli/index.md#rest-api-interface)
options to control which hosts and network interfaces Teku's REST API responds to.
Configure the API to listen on specific IP addresses or all interfaces with `rest-api-interface` and control
which hosts can connect using `rest-api-host-allowlist`:

| Configuration | Interface | Allowlist | Result |
|---------------|-----------|-----------|--------|
| Listen on all IP addresses and allow all hosts | `rest-api-interface="0.0.0.0"` | `rest-api-host-allowlist=["*"]` | Enables connections from any address, such as `localhost` (`127.0.0.1`) or `10.0.0.1`. |
| Listen on a specific IP address (`10.0.0.1`) and allow all hosts | `rest-api-interface="10.0.0.1"` | `rest-api-host-allowlist=["*"]` | Only the specified IP (`10.0.0.1`) can connect, and attempts from `localhost` (`127.0.0.1`) will fail. |
| Listen on all IP addresses but allow only `localhost` | `rest-api-interface="0.0.0.0"` | `rest-api-host-allowlist=["127.0.0.1"]` | Only `localhost` (`127.0.0.1`) can connect; other IP addresses (for example `10.0.0.1`) will receive a 403 error. |
| Listen on a specific IP address (`10.0.0.1`) but allow only `localhost` (`127.0.0.1`) | `rest-api-interface="10.0.0.1"` | `rest-api-host-allowlist=["127.0.0.1"]` | Neither can connect. `localhost` can't reach the server, and `10.0.0.1` is blocked. |

## Enable the validator client API

The [validator client API](../how-to/use-external-signer/manage-keys.md) allows you to call the
[key manager API endpoints](https://ethereum.github.io/keymanager-APIs/) and is enabled separately from the REST API methods.

Enable the validator client API service from the command line by including the
[`--validator-api-enabled`](cli/index.md#validator-api-enabled) command line option.

When enabling the validator client API, you must [create a keystore](../how-to/use-external-signer/manage-keys.md#create-a-keystore).
Set the keystore using [`--validator-api-keystore-file`](cli/index.md#validator-api-keystore-file) and the password file for the
keystore using [`--validator-api-keystore-password-file`](cli/index.md#validator-api-keystore-password-file).

```bash title="Example"
teku --validator-api-enabled --validator-api-keystore-file=validator_keystore.p12 --validator-api-keystore-password-file=validator_keystore_pass.txt
```

The [OpenAPI specifications](https://swagger.io/specification/) for the validator client API are available at `/swagger-docs` when
the [`--validator-api-docs-enabled`](cli/index.md#validator-api-docs-enabled) option is set to `true`.
The `/swagger-docs` endpoint defines the API if code generators are in use.

When enabling the API documentation endpoint, specify:

- `interface` using the [`--validator-api-interface`](cli/index.md#validator-api-interface) option.
- `port` using the [`--validator-api-port`](cli/index.md#validator-api-port) option.

<!-- Links -->

[REST API documentation]: https://consensys.github.io/teku/
[Postman]: https://www.postman.com/
[cURL]: https://curl.haxx.se/

---

## Introduction

# Teku

Teku is an open source Ethereum consensus client (previously called an
[Ethereum 2.0](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/)
client) written in Java.
Teku contains a full beacon node implementation and a validator client for
participating in [proof of stake consensus](concepts/proof-of-stake.md).

## What can you do with Teku?

Teku supports the following features:

- Running the beacon node synchronization and consensus.
- Proposing and attesting to blocks.
- Enterprise-focused metrics using Prometheus.
- A REST API for managing consensus layer node operations.
- External key management for managing validator signing keys.

## New to Teku?

Get started by running Teku with Docker or installing Teku. You can:

- [Run Teku from a Docker image.](get-started/install/run-docker-image.md)
- [Install the binary distribution.](get-started/install/install-binaries.md)
- [Build from source.](get-started/install/build-from-source.md)