diff --git a/versioned_docs/version-24.10.2/chatbot.mdx b/versioned_docs/version-24.10.2/chatbot.mdx
new file mode 100644
index 000000000..61e41b879
--- /dev/null
+++ b/versioned_docs/version-24.10.2/chatbot.mdx
@@ -0,0 +1,8 @@
+---
+title: Chatbot
+slug: chatbot
+---
+
+# Chatbot
+
+
diff --git a/versioned_docs/version-24.10.2/concepts/architecture.md b/versioned_docs/version-24.10.2/concepts/architecture.md
new file mode 100644
index 000000000..72624fff9
--- /dev/null
+++ b/versioned_docs/version-24.10.2/concepts/architecture.md
@@ -0,0 +1,19 @@
+---
+title: Architecture
+description: Learn about the Teku high-level architecture.
+sidebar_position: 1
+---
+
+# Teku architecture
+
+The following diagram outlines the Teku high-level architecture.
+
+
+
+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.com/invite/consensys).
diff --git a/versioned_docs/version-24.10.2/concepts/builder-network.md b/versioned_docs/version-24.10.2/concepts/builder-network.md
new file mode 100644
index 000000000..3ebd30f1f
--- /dev/null
+++ b/versioned_docs/version-24.10.2/concepts/builder-network.md
@@ -0,0 +1,29 @@
+---
+title: Builder network and MEV-Boost
+description: Learn about external builders and MEV-Boost.
+sidebar_position: 2
+---
+
+# 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).
diff --git a/versioned_docs/version-24.10.2/concepts/node-types.md b/versioned_docs/version-24.10.2/concepts/node-types.md
new file mode 100644
index 000000000..7476bfec3
--- /dev/null
+++ b/versioned_docs/version-24.10.2/concepts/node-types.md
@@ -0,0 +1,45 @@
+---
+title: Consensus and execution clients
+description: Learn about execution and consensus clients.
+sidebar_position: 5
+---
+
+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/development/public-networks/how-to/use-engine-api).
+
+
+
+### 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/development/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)).
+
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-24.10.2/concepts/p2p-private-key.md b/versioned_docs/version-24.10.2/concepts/p2p-private-key.md
new file mode 100644
index 000000000..689745eb9
--- /dev/null
+++ b/versioned_docs/version-24.10.2/concepts/p2p-private-key.md
@@ -0,0 +1,19 @@
+---
+title: Peer-to-peer private key
+description: Learn about the peer-to-peer private key.
+sidebar_position: 6
+---
+
+# Peer-to-peer private key
+
+The peer-to-peer (P2P) private key is used to identify the beacon node on the network and secures the information channel between nodes.
+
+When starting Teku, if the [`--p2p-private-key-file`](../reference/cli/index.md#p2p-private-key-file) option is not specified, and the `generated-node-key.dat` file does not exist in the node's data directory, Teku generates a P2P private key and writes it to the `generated-node-key.dat` file.
+
+If the `generated-node-key.dat` file exists in the data directory when starting Teku, the node starts using the private stored in the file.
+
+:::info
+
+The `generated-node-key.dat` file is stored by default in the `/kvstore` directory, where `` is specified using the [`--data-beacon-path`](../reference/cli/index.md#data-beacon-path) option.
+
+:::
diff --git a/versioned_docs/version-24.10.2/concepts/proof-of-stake.md b/versioned_docs/version-24.10.2/concepts/proof-of-stake.md
new file mode 100644
index 000000000..ae18380bb
--- /dev/null
+++ b/versioned_docs/version-24.10.2/concepts/proof-of-stake.md
@@ -0,0 +1,36 @@
+---
+title: Proof of stake
+description: Learn about Ethereum proof of stake consensus.
+sidebar_position: 3
+---
+
+# 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#execution-and-consensus-clients) 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#execution-and-consensus-clients) processes the block and sends the execution payload to the [execution client](node-types.md#execution-and-consensus-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.
diff --git a/versioned_docs/version-24.10.2/concepts/proto-danksharding.md b/versioned_docs/version-24.10.2/concepts/proto-danksharding.md
new file mode 100644
index 000000000..f4a3c8b63
--- /dev/null
+++ b/versioned_docs/version-24.10.2/concepts/proto-danksharding.md
@@ -0,0 +1,46 @@
+---
+description: Learn about the proto-danksharding upgrade and its implications for node operators.
+sidebar_position: 4
+---
+
+# 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.
diff --git a/versioned_docs/version-24.10.2/concepts/slashing-protection.md b/versioned_docs/version-24.10.2/concepts/slashing-protection.md
new file mode 100644
index 000000000..e362c8f19
--- /dev/null
+++ b/versioned_docs/version-24.10.2/concepts/slashing-protection.md
@@ -0,0 +1,96 @@
+---
+title: Slashing protection
+description: Learn about Teku's slashing protection.
+sidebar_position: 7
+---
+
+# 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 `/validator/slashprotection/` directory. One [YAML file is stored per validator] in the format `.yml` (with no `0x` prefix).
+
+:::note
+
+Set `` using the [`--data-path`](../reference/cli/index.md#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/#operation/getEthV1BeaconGenesis) 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 `/validators/slashprotection/` to `/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 either:
+
+- 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 `lastSignedBlockSlot` to the current chain head slot + 1, `lastSignedAttestationSourceEpoch` to the current justified checkpoint, and set `lastSignedAttestationTargetEpoch` to the current epoch + 1.
+
+Start the Teku node with the validator key.
+
+
+
+[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
diff --git a/versioned_docs/version-24.10.2/concepts/weak-subjectivity.md b/versioned_docs/version-24.10.2/concepts/weak-subjectivity.md
new file mode 100644
index 000000000..82c1d7b9b
--- /dev/null
+++ b/versioned_docs/version-24.10.2/concepts/weak-subjectivity.md
@@ -0,0 +1,63 @@
+---
+title: Weak subjectivity
+description: Learn about the weak subjectivity period.
+sidebar_position: 8
+---
+
+# 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/`](https://consensys.github.io/teku/#operation/getEthV2DebugBeaconStatesWithState_id)
+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/)
diff --git a/versioned_docs/version-24.10.2/concepts/withdrawals.md b/versioned_docs/version-24.10.2/concepts/withdrawals.md
new file mode 100644
index 000000000..7e8435edb
--- /dev/null
+++ b/versioned_docs/version-24.10.2/concepts/withdrawals.md
@@ -0,0 +1,98 @@
+---
+title: Withdrawals
+description: Learn about validator reward withdrawals.
+sidebar_position: 9
+---
+
+# 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.
+
+:::
diff --git a/versioned_docs/version-24.10.2/get-started/_category_.json b/versioned_docs/version-24.10.2/get-started/_category_.json
new file mode 100644
index 000000000..ca01109a1
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/_category_.json
@@ -0,0 +1,7 @@
+{
+ "label": "Get started",
+ "position": 1,
+ "link": {
+ "type": "generated-index"
+ }
+}
diff --git a/versioned_docs/version-24.10.2/get-started/checkpoint-start.md b/versioned_docs/version-24.10.2/get-started/checkpoint-start.md
new file mode 100644
index 000000000..ca9eb3c9b
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/checkpoint-start.md
@@ -0,0 +1,64 @@
+---
+title: Start Teku from a recent state
+description: Start Teku from a recent finalized state using checkpoint sync.
+sidebar_position: 4
+---
+
+# 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 --eth1-endpoint=http://localhost:8545 \
+--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 delete your existing beacon node database, for example `/beacon/db`, to enable Teku to download the new, finalized state for your node.
+
+:::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 --eth1-endpoint=http://localhost:8545 \
+--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 --eth1-endpoint=http://localhost:8545 \
+--validator-keys=/Users/me/mainnet/validator/keys:/Users/me/mainnet/validator/passwords \
+--initial-state=http://other-node:5051/eth/v2/debug/beacon/states/finalized
+```
+:::
+
+
+
+[REST API enabled]: ../reference/cli/index.md#rest-api-enabled
diff --git a/versioned_docs/version-24.10.2/get-started/connect/_category_.json b/versioned_docs/version-24.10.2/get-started/connect/_category_.json
new file mode 100644
index 000000000..ef3ebd5ae
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/connect/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Connect to a network",
+ "position": 3,
+ "link": {
+ "type": "generated-index",
+ "slug": "/get-started/connect"
+ }
+}
diff --git a/versioned_docs/version-24.10.2/get-started/connect/mainnet.md b/versioned_docs/version-24.10.2/get-started/connect/mainnet.md
new file mode 100644
index 000000000..2c0e8bf75
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/connect/mainnet.md
@@ -0,0 +1,189 @@
+---
+title: Connect to Mainnet
+description: Connect Teku to Ethereum Mainnet.
+sidebar_position: 1
+---
+
+# 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#execution-and-consensus-clients).
+
+:::
+
+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= \
+ --metrics-enabled=true \
+ --rest-api-enabled=true \
+ --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= \
+ --metrics-enabled=true \
+ --rest-api-enabled=true \
+ --checkpoint-sync-url= \
+ --validators-proposer-default-fee-recipient= \
+ --validator-keys=:[,:,...]
+```
+
+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= \
+ --validator-keys=:[,:,...]
+```
+
+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.
+
+
+
+[Besu]: https://besu.hyperledger.org/en/stable/
+[step 1]: #1-generate-the-shared-secret
diff --git a/versioned_docs/version-24.10.2/get-started/connect/testnet.md b/versioned_docs/version-24.10.2/get-started/connect/testnet.md
new file mode 100644
index 000000000..2ef8ac7c7
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/connect/testnet.md
@@ -0,0 +1,234 @@
+---
+title: Connect to a testnet
+description: Connect Teku to a testnet.
+sidebar_position: 1
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Connect to a testnet
+
+Run Teku as a consensus client with any execution client on a testnet (for example [Holesky](https://github.com/eth-clients/holesky) 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
+
+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://metamask.zendesk.com/hc/en-us/articles/360015289452-How-to-create-an-additional-account-in-your-wallet)).
+Fund this address with testnet ETH (32 ETH and gas fees for each validator) using a faucet.
+See the list of [Holesky faucets](https://github.com/eth-clients/holesky#metadata) or
+[Sepolia faucets](https://github.com/eth-clients/sepolia#meta-data-sepolia).
+
+:::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 [Holesky Staking Launchpad](https://holesky.launchpad.ethereum.org/).
+
+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):
+
+
+
+
+```bash
+teku \
+ --network=holesky \
+ --ee-endpoint=http://localhost:8551 \
+ --ee-jwt-secret-file= \
+ --metrics-enabled=true \
+ --rest-api-enabled=true \
+ --checkpoint-sync-url=
+```
+
+
+
+
+```bash
+teku \
+ --network=sepolia \
+ --ee-endpoint=http://localhost:8551 \
+ --ee-jwt-secret-file= \
+ --metrics-enabled=true \
+ --rest-api-enabled=true \
+ --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.
+
+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 [Holesky Beacon Chain explorer](https://holesky.beaconcha.in/).
+Your validator might take 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 \
+ --network=holesky \
+ --ee-endpoint=http://localhost:8551 \
+ --ee-jwt-secret-file= \
+ --metrics-enabled=true \
+ --rest-api-enabled=true \
+ --checkpoint-sync-url= \
+ --validators-proposer-default-fee-recipient= \
+ --validator-keys=:[,:,...]
+```
+
+
+
+
+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.
+
+
+
+
+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:
+
+
+
+
+```bash
+teku validator-client \
+ --network=holesky \
+ --beacon-node-api-endpoint= \
+ --validator-keys=:[,:,...]
+```
+
+
+
+
+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.
+
+
+
+
+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
+[Holesky Staking Launchpad](https://holesky.launchpad.ethereum.org/).
+
+You can check your validator status by searching your Ethereum address on the
+[Holesky Beacon Chain explorer](https://holesky.beaconcha.in/).
+It may take up to multiple days for your validator to be activated and start
+proposing blocks.
+
+
+
+[Besu]: https://besu.hyperledger.org/en/stable/
+[step 1]: #1-generate-the-shared-secret
diff --git a/versioned_docs/version-24.10.2/get-started/install/_category_.json b/versioned_docs/version-24.10.2/get-started/install/_category_.json
new file mode 100644
index 000000000..9becce822
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/install/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Install Teku",
+ "position": 1,
+ "link": {
+ "type": "generated-index",
+ "slug": "/get-started/install"
+ }
+}
diff --git a/versioned_docs/version-24.10.2/get-started/install/build-from-source.md b/versioned_docs/version-24.10.2/get-started/install/build-from-source.md
new file mode 100644
index 000000000..8ab5a7dd5
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/install/build-from-source.md
@@ -0,0 +1,77 @@
+---
+title: Build from source
+description: Build Teku from source.
+sidebar_position: 2
+---
+
+# Build from source
+
+:::caution
+
+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 21+; 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 X
+
+### 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).
+
+
+
+[binary]: install-binaries.md
+[Docker image]: run-docker-image.md
diff --git a/versioned_docs/version-24.10.2/get-started/install/install-binaries.md b/versioned_docs/version-24.10.2/get-started/install/install-binaries.md
new file mode 100644
index 000000000..d78e6a642
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/install/install-binaries.md
@@ -0,0 +1,85 @@
+---
+title: Install binary distribution
+description: Install Teku from binary distribution.
+sidebar_position: 1
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Install binary distribution
+
+## Linux / Unix / macOS / Windows
+
+### Prerequisites
+
+- [Java JDK](https://www.oracle.com/java/technologies/javase-downloads.html)
+
+:::caution
+
+Teku requires Java 21+ to compile; earlier versions are not supported.
+
+:::
+
+
+
+- If using Windows, install the [Microsoft Visual C++ 2010 security update](https://www.microsoft.com/en-us/download/details.aspx?id=26999).
+
+### Install from packaged binaries
+
+Download the [Teku packaged binaries](https://github.com/ConsenSys/teku/releases).
+
+Unpack the downloaded files and change into the `teku-` directory.
+
+Display Teku command line help to confirm installation:
+
+
+
+
+```bash
+./bin/teku --help
+```
+
+
+
+
+```bat
+bin\teku --help
+```
+
+
+
+
+## macOS with Homebrew
+
+### Prerequisites
+
+- [Homebrew](https://brew.sh/)
+- Java JDK.
+
+:::caution
+
+Teku requires Java 21+ 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
+```
diff --git a/versioned_docs/version-24.10.2/get-started/install/run-docker-image.md b/versioned_docs/version-24.10.2/get-started/install/run-docker-image.md
new file mode 100644
index 000000000..19f43a0d7
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/install/run-docker-image.md
@@ -0,0 +1,203 @@
+---
+title: Run Teku from Docker
+description: Run Teku using the official Docker image.
+sidebar_position: 3
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# 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#teku-environment-variables) 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 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=holesky --eth1-endpoint=http://102.10.10.1:8545 --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-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 --user 1001:1001 --mount type=bind,source=/Users/user1/teku/,target=/var/lib/teku consensys/teku:latest --data-base-path=/var/lib/teku --network=holesky --eth1-endpoint=http://102.10.10.1:8545 --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-advertised-port`](../../reference/cli/index.md#p2p-advertised-port)
+- [`--rest-api-port`](../../reference/cli/index.md#rest-api-port).
+
+To run Teku exposing local ports for access:
+
+```bash
+docker run -p :30303/tcp -p :30303/udp -p :5051 consensys/teku:latest --network= --data-base-path= --eth1-endpoint= --validator-keys=: --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=holesky --data-base-path=/var/lib/teku --eth1-endpoint=http://102.10.10.1:8545 --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.
+
+
+
+
+```yaml
+---
+version: "3.4"
+services:
+ besu_node:
+ image: hyperledger/besu:latest
+ command:
+ [
+ "--network=holesky",
+ "--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=holesky",
+ "--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 p2p port(9000) and REST API port(5051)
+ - "9000:9000/tcp"
+ - "9000:9000/udp"
+ - "5051:5051"
+```
+
+
+
+
+```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 p2p port(9000) and REST API port(5051)
+ - "9000:9000/tcp"
+ - "9000:9000/udp"
+ - "5051:5051"
+```
+
+
+
+
+
+
+[Besu]: https://besu.hyperledger.org/en/stable/
diff --git a/versioned_docs/version-24.10.2/get-started/manage-memory.md b/versioned_docs/version-24.10.2/get-started/manage-memory.md
new file mode 100644
index 000000000..6c923a9c2
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/manage-memory.md
@@ -0,0 +1,79 @@
+---
+title: Manage memory
+description: Manage Teku's JVM memory usage.
+sidebar_position: 5
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# 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 5GB or more.
+
+Set the heap size using the environment variable, or using the command line when starting Teku.
+
+
+
+
+```bash
+export JAVA_OPTS=-Xmx5g
+```
+
+
+
+
+```bash
+JAVA_OPTS=-Xmx5g ./teku [options]
+```
+
+
+
+
+:::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 is potentially large (1-2GB), to specify the directory to place the file, set the `-XX:HeapDumpPath` Java option to the required path.
+
+
+
+
+```bash
+export TEKU_OPTS="-XX:HeapDumpPath=/home/me/me_node/dumps"
+```
+
+
+
+
+```bash
+TEKU_OPTS="-XX:HeapDumpPath=/home/me/me_node/dumps" ./teku [options]
+```
+
+
+
+
+To disable the heap dump file generation, set the `-XX:-HeapDumpOnOutOfMemoryError` Java option.
+
+
+
+
+```bash
+export TEKU_OPTS="-XX:-HeapDumpOnOutOfMemoryError"
+```
+
+
+
+
+```bash
+TEKU_OPTS="-XX:-HeapDumpOnOutOfMemoryError" ./teku [options]
+```
+
+
+
diff --git a/versioned_docs/version-24.10.2/get-started/migrate-to-teku.md b/versioned_docs/version-24.10.2/get-started/migrate-to-teku.md
new file mode 100644
index 000000000..fdbc64744
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/migrate-to-teku.md
@@ -0,0 +1,18 @@
+---
+title: Migrate to Teku
+description: Migrate to Teku from a different Ethereum consensus client.
+sidebar_position: 6
+---
+
+# 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).
diff --git a/versioned_docs/version-24.10.2/get-started/start-teku.md b/versioned_docs/version-24.10.2/get-started/start-teku.md
new file mode 100644
index 000000000..61543c0d4
--- /dev/null
+++ b/versioned_docs/version-24.10.2/get-started/start-teku.md
@@ -0,0 +1,165 @@
+---
+title: Start Teku
+description: Run Teku as a beacon node and/or validator.
+sidebar_position: 2
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# 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#2-start-the-execution-client).
+- [Validator keystores and password files](connect/mainnet.md#3-generate-validator-keys-and-stake-eth).
+
+## 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#validator-client-vc) or [`vc`](../reference/cli/subcommands/validator-client.md#validator-client-vc) 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/#operation/getTekuV1AdminLiveness) endpoint to check whether the node is up.
+
+The endpoint returns the status `200 OK` if the node is up or syncing.
+
+
+
+
+```bash
+curl -I -X GET "http://192.10.10.101:5051/teku/v1/admin/liveness"
+```
+
+
+
+
+```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
+```
+
+
+
+
+## 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.
+
+[systemd.service](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) File Example
+```
+RestartForceExitStatus=1
+RestartPreventExitStatus=2
+```
+
+
+
+[validator clients]: #start-the-validator
+[running beacon node]: #start-the-beacon-node
+[Validator keystores]: connect/testnet.md#generate-the-validators-and-send-the-deposits
+[password files]: connect/testnet.md#create-a-password-file-for-each-validator-key
+[slashable offense]: ../concepts/slashing-protection.md
+[single process]: #start-the-clients-in-a-single-process
diff --git a/versioned_docs/version-24.10.2/how-to/configure/_category_.json b/versioned_docs/version-24.10.2/how-to/configure/_category_.json
new file mode 100644
index 000000000..55df0cf5f
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/configure/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Configure",
+ "position": 1,
+ "link": {
+ "type": "generated-index",
+ "slug": "/how-to/configure"
+ }
+}
diff --git a/versioned_docs/version-24.10.2/how-to/configure/builder-network.md b/versioned_docs/version-24.10.2/how-to/configure/builder-network.md
new file mode 100644
index 000000000..8ee93590d
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/configure/builder-network.md
@@ -0,0 +1,185 @@
+---
+title: Configure Teku to use a builder network
+description: Connect to a builder network to generate execution payloads.
+sidebar_position: 3
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# 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. Enable blinded block production
+
+Enable blinded block production using the
+[`--validators-proposer-blinded-blocks-enabled`](../../reference/cli/index.md#validators-proposer-blinded-blocks-enabled)
+command line option.
+
+:::note
+
+If [--validators-builder-registration-default-enabled](../../reference/cli/index.md#validators-builder-registration-default-enabled)
+is set to `true`, then `--validators-proposer-blinded-blocks-enabled` is automatically enabled.
+
+:::
+
+## 2. 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
+```
+
+## 3. 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.
+
+:::note
+
+If you use a proposer configuration, you must enable blinded block production using
+[`--validators-proposer-blinded-blocks-enabled`](../../reference/cli/index.md#validators-proposer-blinded-blocks-enabled).
+
+:::
+
+## 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.
+
+
+
+
+```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"
+```
+
+
+
+
+```bash
+teku validator-client \
+ --validators-proposer-blinded-blocks-enabled=true \
+ --validators-proposer-config="/etc/teku/proposerConfig.json"
+```
+
+
+
+
+```json title="proposerConfig.json"
+{
+ "proposer_config": {
+ "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": {
+ "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3"
+ }
+ },
+ "default_config": {
+ "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A",
+ "builder": {
+ "enabled": true
+ }
+ }
+}
+```
+
+
+
+
+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.
+
+
+
+
+```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"
+```
+
+
+
+
+```bash
+teku validator-client \
+ --validators-proposer-blinded-blocks-enabled=true \
+ --validators-builder-registration-default-enabled=true \
+ --validators-proposer-default-fee-recipient="0x6e35733c5af9B61374A128e6F85f553aF09ff89A"
+```
+
+
+
diff --git a/versioned_docs/version-24.10.2/how-to/configure/tls.md b/versioned_docs/version-24.10.2/how-to/configure/tls.md
new file mode 100644
index 000000000..ccf6fe2b5
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/configure/tls.md
@@ -0,0 +1,81 @@
+---
+title: Configure TLS
+description: Configure TLS communication between Teku and Web3Signer.
+sidebar_position: 4
+---
+
+# 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].
+- ETH1 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:
+
+```bash
+teku --network=holesky \
+--eth1-endpoint=http://localhost:8545 \
+--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 JSON-RPC URL of the ETH1 node using [`--eth1-endpoint`](../../reference/cli/index.md#eth1-endpoint-eth1-endpoints).
+- 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).
+
+
+
+[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/stable/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/
diff --git a/versioned_docs/version-24.10.2/how-to/configure/use-config-file.md b/versioned_docs/version-24.10.2/how-to/configure/use-config-file.md
new file mode 100644
index 000000000..a059b4db1
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/configure/use-config-file.md
@@ -0,0 +1,60 @@
+---
+title: Use a configuration file
+description: Specify options in the Teku configuration file.
+sidebar_position: 1
+---
+
+# 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#teku-environment-variables). For options specified in more than one place, the order of precedence is command line, environment variable, configuration file.
+
+## 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: "holesky"
+
+# p2p
+p2p-enabled: true
+p2p-port: 9000
+
+# validators
+validator-keys: "/Users/me/node/holesky/validator/keys:/Users/me/node/holesky/validator/passwords"
+validators-graffiti: "Teku validator"
+
+# Eth 1
+eth1-endpoint: "http://localhost:8545"
+
+# 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
+```
diff --git a/versioned_docs/version-24.10.2/how-to/configure/use-proposer-config-file.md b/versioned_docs/version-24.10.2/how-to/configure/use-proposer-config-file.md
new file mode 100644
index 000000000..d7370ff98
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/configure/use-proposer-config-file.md
@@ -0,0 +1,220 @@
+---
+title: Use a proposer configuration file
+description: Define complex fee recipients in a proposer configuration file.
+sidebar_position: 2
+---
+
+# 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 `30000000`.
+ - `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`.
diff --git a/versioned_docs/version-24.10.2/how-to/find-and-connect/_category_.json b/versioned_docs/version-24.10.2/how-to/find-and-connect/_category_.json
new file mode 100644
index 000000000..98bebf6b5
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/find-and-connect/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Find and connect to peers",
+ "position": 3,
+ "link": {
+ "type": "generated-index",
+ "slug": "how-to/find-and-connect"
+ }
+}
diff --git a/versioned_docs/version-24.10.2/how-to/find-and-connect/configure-ipv6.md b/versioned_docs/version-24.10.2/how-to/find-and-connect/configure-ipv6.md
new file mode 100644
index 000000000..210cf3ba1
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/find-and-connect/configure-ipv6.md
@@ -0,0 +1,50 @@
+---
+description: Configure Teku to listen over IPv6.
+sidebar_position: 3
+---
+
+# Configure IPv6
+
+You can configure Teku to listen over IPv4, [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) and
+[`--p2p-udp-port`](../../reference/cli/index.md#p2p-udp-port) CLI options are used for the P2P and
+discovery ports, similar to listening over IPv4 only.
+
+## Listen over both IPv4 and IPv6 (dual-stack)
+
+To configure Teku to listen over both IPv4 and IPv6, also known as dual-stack support, set the
+[`--p2p-interface`](../../reference/cli/index.md#p2p-interface-p2p-interfaces) CLI option to
+`0.0.0.0,::` for both IPv4 and IPv6 listening addresses.
+In this setup, the [`--p2p-port`](../../reference/cli/index.md#p2p-port) and
+[`--p2p-udp-port`](../../reference/cli/index.md#p2p-udp-port) options apply to the IPv4 address.
+The [`--p2p-port-ipv6`](../../reference/cli/index.md#p2p-port-ipv6) and
+[`--p2p-udp-port-ipv6`](../../reference/cli/index.md#p2p-udp-port-ipv6) options apply to the IPv6 address.
+
+After dual-stack support is enabled, Teku uses port `9000` for both TCP and UDP on IPv4, and port
+`9090` for both TCP and UDP on IPv6 by default.
+
+## 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.
+Configure the advertised port using the
+[`--p2p-advertised-port`](../../reference/cli/index.md#p2p-advertised-port) CLI option.
+It uses the value set in [`--p2p-port`](../../reference/cli/index.md#p2p-port) by default.
+
+## 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.
+Configure the advertised port for the IPv4 address using the
+[`--p2p-advertised-port`](../../reference/cli/index.md#p2p-advertised-port) option.
+Configure the advertised port for the IPv6 address using the
+[`--p2p-advertised-port-ipv6`](../../reference/cli/index.md#p2p-advertised-port-ipv6) option.
+This port is set to the value of [`--p2p-port-ipv6`](../../reference/cli/index.md#p2p-port-ipv6) by default.
diff --git a/versioned_docs/version-24.10.2/how-to/find-and-connect/improve-connectivity.md b/versioned_docs/version-24.10.2/how-to/find-and-connect/improve-connectivity.md
new file mode 100644
index 000000000..57675d3ea
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/find-and-connect/improve-connectivity.md
@@ -0,0 +1,43 @@
+---
+title: Improve peer-to-peer connectivity
+description: Update your network configuration to improve peer counts.
+sidebar_position: 1
+---
+
+# Improve peer-to-peer connectivity
+
+The consensus layer relies on peer-to-peer (P2P) networking. 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](#configuring-ports) on your router.
+
+:::tip
+
+Check the [`ip4.me`](http://ip4.me/) website to view your public IP address.
+
+:::
+
+## Configure ports
+
+By default, Teku listens for connections on port `9000` for TCP and UDP. You can configure the port number with the [`--p2p-port`](../../reference/cli/index.md#p2p-port) option.
+
+Configure port forwarding on your router and firewall to allow incoming and outgoing connections on the listening port for the TCP and UDP 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/#operation/getTekuV1AdminReadiness). 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).
+
+:::
diff --git a/versioned_docs/version-24.10.2/how-to/find-and-connect/specify-nat.md b/versioned_docs/version-24.10.2/how-to/find-and-connect/specify-nat.md
new file mode 100644
index 000000000..68f231de9
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/find-and-connect/specify-nat.md
@@ -0,0 +1,29 @@
+---
+title: Specify NAT methods
+description: Specify the method for handling NAT environments.
+sidebar_position: 2
+---
+
+# 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.
diff --git a/versioned_docs/version-24.10.2/how-to/load-validators-without-restarting.md b/versioned_docs/version-24.10.2/how-to/load-validators-without-restarting.md
new file mode 100644
index 000000000..930f5d21f
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/load-validators-without-restarting.md
@@ -0,0 +1,31 @@
+---
+title: Load validators without restarting
+description: Load validators without restarting Teku.
+sidebar_position: 6
+---
+
+# 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
+```
+
+Where `` is the process ID of the running Teku instance.
diff --git a/versioned_docs/version-24.10.2/how-to/migrate-database.md b/versioned_docs/version-24.10.2/how-to/migrate-database.md
new file mode 100644
index 000000000..1559cd8f1
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/migrate-database.md
@@ -0,0 +1,102 @@
+---
+title: Migrate the database
+description: Migrate a RocksDB database to a LevelDB2 database.
+sidebar_position: 10
+---
+
+# Migrate the database
+
+Teku version 21.5.0 and later use LevelDB2 as the default database for new installations.
+Earlier Teku versions use RocksDB. Teku continues to support RocksDB in all versions.
+
+LevelDB2 databases use less memory and proves to be more stable with Teku.
+
+:::caution
+
+We recommend Teku nodes running in [`archive` mode] use the [automatic migration](#automatic-migration) method, and Teku nodes running in [`prune` mode] use the [manual migration](#manual-migration).
+
+:::
+
+## Automatic migration
+
+Teku nodes running in [archive mode] must resynchronize from genesis to migrate from RocksDB to LevelDB2. 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 the RocksDB 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 RocksDB 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 LevelDB2 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 RocksDB database to a LevelDB2 database if the Teku node runs in [`prune` mode].
+
+:::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 RocksDB database in [`prune` mode] to a LevelDB2 database:
+
+1. [Download the latest finalized state] from a beacon node:
+
+ ```bash
+ curl -o state.ssz -H 'Accept: application/octet-stream' http://other-node:5051/eth/v2/debug/beacon/states/finalized
+ ```
+
+ :::note
+
+ This step is optional, you can also [supply the finalized checkpoint state] via URL from a beacon chain node or Infura when restarting Teku in the step below.
+
+ :::
+
+2. Stop the Teku node you intend to migrate.
+
+3. Delete the `beacon` directory in your [data path](../reference/cli/index.md#data-base-path-data-path).
+
+ :::warning
+
+ Ensure not to delete the `validator` directory if one is present as this contains your slashing protection data.
+
+ :::
+
+4. Restart Teku and specify the downloaded finalized state using the [`--initial-state`](../reference/cli/index.md#initial-state) command.
+
+Teku creates a LevelDB2 database, and starts from the specified recent state. Teku should be in sync and validating within minutes.
+
+
+
+[Download the latest finalized state]: https://consensys.github.io/teku/#operation/getEthV1DebugBeaconStatesWithState_id
+[`prune` mode]: ../reference/cli/index.md#data-storage-mode
+[`archive` mode]: ../reference/cli/index.md#data-storage-mode
+[supply the finalized checkpoint state]: ../get-started/checkpoint-start.md
+[Teku Discord channel]: https://discord.com/invite/consensys
diff --git a/versioned_docs/version-24.10.2/how-to/monitor/_category_.json b/versioned_docs/version-24.10.2/how-to/monitor/_category_.json
new file mode 100644
index 000000000..6d6009299
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/monitor/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Monitor nodes",
+ "position": 4,
+ "link": {
+ "type": "generated-index",
+ "slug": "/how-to/monitor"
+ }
+}
diff --git a/versioned_docs/version-24.10.2/how-to/monitor/configure-logging.md b/versioned_docs/version-24.10.2/how-to/monitor/configure-logging.md
new file mode 100644
index 000000000..b718e8e7e
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/monitor/configure-logging.md
@@ -0,0 +1,87 @@
+---
+title: Configure logging
+description: Configure Teku's log level settings and log formatting.
+sidebar_position: 2
+---
+
+# 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`
+- Windows: `%localappdata%\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/#operation/putTekuV1AdminLog_level) 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"
+
+
+
+ INFO
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+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]
+```
diff --git a/versioned_docs/version-24.10.2/how-to/monitor/update-metrics.md b/versioned_docs/version-24.10.2/how-to/monitor/update-metrics.md
new file mode 100644
index 000000000..eac93d716
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/monitor/update-metrics.md
@@ -0,0 +1,38 @@
+---
+title: Update metrics
+description: Manually update metrics for your custom dashboard.
+sidebar_position: 3
+---
+
+# Update metrics
+
+Manually update Teku metrics for your custom dashboard.
+
+Teku has introduced changes to metric names, adding the `_total` suffix to counter metrics that previously did not have it.
+
+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_block_blobs_trackers_pool_size` | `beacon_block_blobs_trackers_pool_size_total` |
+| `beacon_block_blobs_trackers_pool_stats` | `beacon_block_blobs_trackers_pool_stats_total` |
+| `beacon_block_import_delay_counter` | `beacon_block_import_delay_counter_total` |
+| `beacon_eth1_request_queue_size` | `beacon_eth1_request_queue_size_total` |
+| `beacon_execution_payload_source` | `beacon_execution_payload_source_total` |
+| `beacon_teku_version` | `beacon_teku_version_total` |
+| `eventbus_event_consumed_count` | `eventbus_event_consumed_count_total` |
+| `eventbus_event_failed_count` | `eventbus_event_failed_count_total` |
+| `eventbus_event_published_count` | `eventbus_event_published_count_total` |
+| `executor_signature_verifications_batch_count` | `executor_signature_verifications_batch_count_total` |
+| `executor_signature_verifications_task_count` | `executor_signature_verifications_task_count_total` |
+| `network_peer_chain_validation_attempts` | `network_peer_chain_validation_attempts_total` |
+| `network_peer_connection_attempt_count` | `network_peer_connection_attempt_count_total` |
+| `storage_finalized_state_branch_nodes` | `storage_finalized_state_branch_nodes_total` |
+| `storage_finalized_state_leaf_nodes` | `storage_finalized_state_leaf_nodes_total` |
+| `storage_finalized_states_stored` | `storage_finalized_states_stored_total` |
+| `validator_attestation_publication_delay` | `validator_attestation_publication_delay_total` |
+| `validator_block_publication_delay` | `validator_block_publication_delay_total` |
+| `validator_duties_performed` | `validator_duties_performed_total` |
+| `validator_external_signer_requests` | `validator_external_signer_requests_total` |
diff --git a/versioned_docs/version-24.10.2/how-to/monitor/use-metrics.md b/versioned_docs/version-24.10.2/how-to/monitor/use-metrics.md
new file mode 100644
index 000000000..50f055363
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/monitor/use-metrics.md
@@ -0,0 +1,98 @@
+---
+title: Use metrics
+description: Use metrics to monitor Teku's performance.
+sidebar_position: 1
+---
+
+# 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 \
+ --eth1-endpoint=http://localhost:8545 --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).
+
+
+
+[Beacon Chain metrics]: https://github.com/ethereum/beacon-metrics/blob/master/metrics.md
+[Grafana]: https://grafana.com/docs/grafana/latest/guides/getting_started/
diff --git a/versioned_docs/version-24.10.2/how-to/prevent-slashing/_category_.json b/versioned_docs/version-24.10.2/how-to/prevent-slashing/_category_.json
new file mode 100644
index 000000000..5648fda7c
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/prevent-slashing/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Prevent slashing offenses",
+ "position": 5,
+ "link": {
+ "type": "generated-index",
+ "slug": "/how-to/prevent-slashing"
+ }
+}
diff --git a/versioned_docs/version-24.10.2/how-to/prevent-slashing/detect-doppelgangers.md b/versioned_docs/version-24.10.2/how-to/prevent-slashing/detect-doppelgangers.md
new file mode 100644
index 000000000..4f9680d4f
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/prevent-slashing/detect-doppelgangers.md
@@ -0,0 +1,86 @@
+---
+description: Check if your validators' keys are already active.
+sidebar_position: 2
+---
+
+# 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#start-teku): 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
+```
diff --git a/versioned_docs/version-24.10.2/how-to/prevent-slashing/detect-slashing.md b/versioned_docs/version-24.10.2/how-to/prevent-slashing/detect-slashing.md
new file mode 100644
index 000000000..401de7525
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/prevent-slashing/detect-slashing.md
@@ -0,0 +1,73 @@
+---
+description: Shut down Teku if a validator is slashed.
+sidebar_position: 3
+---
+
+# 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...
+```
diff --git a/versioned_docs/version-24.10.2/how-to/prevent-slashing/use-a-slashing-protection-file.md b/versioned_docs/version-24.10.2/how-to/prevent-slashing/use-a-slashing-protection-file.md
new file mode 100644
index 000000000..8441a5b13
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/prevent-slashing/use-a-slashing-protection-file.md
@@ -0,0 +1,53 @@
+---
+description: Use a slashing protection file to prevent validator slashing offenses.
+sidebar_position: 1
+---
+
+# 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 `/validators/slashprotection/` directory in the format `.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) 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_1) 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.
+
+
+
+[slashing protection]: ../../concepts/slashing-protection.md
+[data path directory when starting Teku]: ../../reference/cli/index.md#data-path
+[validator client interchange format]: https://eips.ethereum.org/EIPS/eip-3076
+[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
diff --git a/versioned_docs/version-24.10.2/how-to/reconstruct-historical-states.md b/versioned_docs/version-24.10.2/how-to/reconstruct-historical-states.md
new file mode 100644
index 000000000..3c3140ead
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/reconstruct-historical-states.md
@@ -0,0 +1,24 @@
+---
+title: Reconstruct historical states
+description: Reconstruct historical states on an archive node.
+sidebar_position: 9
+---
+
+# 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).
diff --git a/versioned_docs/version-24.10.2/how-to/troubleshoot/_category_.json b/versioned_docs/version-24.10.2/how-to/troubleshoot/_category_.json
new file mode 100644
index 000000000..1f8b1489b
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/troubleshoot/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Troubleshoot",
+ "position": 13,
+ "link": {
+ "type": "generated-index",
+ "slug": "/how-to/troubleshoot"
+ }
+}
diff --git a/versioned_docs/version-24.10.2/how-to/troubleshoot/general.md b/versioned_docs/version-24.10.2/how-to/troubleshoot/general.md
new file mode 100644
index 000000000..1d84e8e73
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/troubleshoot/general.md
@@ -0,0 +1,150 @@
+---
+description: Solve common problems encountered with Teku.
+sidebar_position: 14
+---
+
+# 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 .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:
+
+```
+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: [, ]`, 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 [`--validators-keys`](../../reference/cli/index.md#validators-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
+```
+
+
+
+[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
diff --git a/versioned_docs/version-24.10.2/how-to/troubleshoot/network.md b/versioned_docs/version-24.10.2/how-to/troubleshoot/network.md
new file mode 100644
index 000000000..dec928ab3
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/troubleshoot/network.md
@@ -0,0 +1,227 @@
+---
+description: Solve common networking problems encountered with Teku.
+sidebar_position: 15
+---
+
+# 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.
+1. Delete the `beacon` directory under your [data path](../../reference/cli/index.md#data-base-path-data-path).
+1. 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.
+
+
+### Firewall connection issues
+
+To determine the number of inbound and outbound peers via the beacon node's REST API, you can send a request to the peers
+endpoint. This gathers data and organizes it based on the direction, either inbound or outbound.
+
+```bash
+curl http://127.0.0.1:5051/eth/v1/node/peers |jq '.data | group_by(.direction)[] | {direction: .[0].direction, count: length}'
+```
+
+If only outbound peers are displayed, it indicates that peers cannot connect to your infrastructure from the outside.
+Networks typically have a firewall at the entry point (router / modem / gateway) that blocks incoming data by default.
+
+To resolve this, update the firewall to include a rule that allows access to the [`--p2p-port`](../../reference/cli/index.md#p2p-port) (9000 by default)
+for both `UDP` and `TCP` traffic. Subsequently, forward this port (TCP and UDP) 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 this port.
+
+:::info
+
+View the [Prysm guide](https://docs.prylabs.network/docs/prysm-usage/p2p-host-ip/) for more information on this topic, but you need to substitute your `--p2p-port` (9000 by default) for the port numbers.
+
+:::
+
+### Advertised IP address issues
+
+A possible reason for incoming peers being unable to connect could be an incorrect address specified using the
+[`--p2p-advertised-ip`](../../reference/cli/index.md#p2p-advertised-ip-p2p-advertised-ips) option. Teku auto-detects 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 potentially be the cause.
+
+
+### Network gateway issues
+
+A potential reason for incoming peers not being able to connect could be the use of 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'll
+need to open multiple ports on your gateway. The simplest solution is to use the same port on your gateway as specified
+in your [`--p2p-port`](../../reference/cli/index.md#p2p-port) (9000 by default). However, if necessary, users can also
+update the advertised port using the [`--p2p-advertised-port`](../../reference/cli/index.md#p2p-advertised-port) command.
+
+## 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=-Xmx5g` is set, with
+ `5g` (five gigabytes of heap) as an optimal value; `4g` 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](#how-many-peers-do-i-need-or-other-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:
+
+```
+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:
+
+
+
+:::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
+auto-detection 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.
diff --git a/versioned_docs/version-24.10.2/how-to/update-withdrawal-keys.md b/versioned_docs/version-24.10.2/how-to/update-withdrawal-keys.md
new file mode 100644
index 000000000..392aa685d
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/update-withdrawal-keys.md
@@ -0,0 +1,121 @@
+---
+title: Update your withdrawal credentials
+description: Update your BLS withdrawal address to an Ethereum address.
+sidebar_position: 11
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# 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.
+
+
+
+
+```bash
+VALIDATOR= \
+curl http://localhost:5051/eth/v1/beacon/states/finalized/validators/$VALIDATOR | jq '.data | .validator.withdrawal_credentials'
+```
+
+
+
+```
+"0x00fc40352b0a186d83267fc1342ec5da49dbb78e1099a4bd8db16d2c0d223594"
+```
+
+
+
+
+In the script, specify the `` (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.
+
+:::
diff --git a/versioned_docs/version-24.10.2/how-to/use-external-signer/_category_.json b/versioned_docs/version-24.10.2/how-to/use-external-signer/_category_.json
new file mode 100644
index 000000000..2a9c96b97
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/use-external-signer/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Use an external signer",
+ "position": 2,
+ "link": {
+ "type": "generated-index",
+ "slug": "/how-to/use-external-signer"
+ }
+}
diff --git a/versioned_docs/version-24.10.2/how-to/use-external-signer/manage-keys.md b/versioned_docs/version-24.10.2/how-to/use-external-signer/manage-keys.md
new file mode 100644
index 000000000..e01b83148
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/use-external-signer/manage-keys.md
@@ -0,0 +1,147 @@
+---
+title: Manage validator signing keys
+description: Manage validator keys using the key manager API endpoints.
+sidebar_position: 2
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# 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?`.
+
+
+
+
+ ```bash
+ keytool -genkeypair -keystore -storetype PKCS12 -storepass
+ ```
+
+
+
+
+ ```bash
+ keytool -genkeypair -keystore validator_keystore.p12 -storetype PKCS12 -storepass changeit
+ ```
+
+
+
+
+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_distinguised_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:
+
+
+
+
+ ```bash
+ openssl req -x509 -nodes -days -newkey rsa:2048 -config openssl.cnf | openssl pkcs12 -export -out -passout file:
+ ```
+
+
+
+
+ ```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
+ ```
+
+
+
+
+### 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 " -X GET https://localhost:5052/eth/v1/keystores
+```
diff --git a/versioned_docs/version-24.10.2/how-to/use-external-signer/use-web3signer.md b/versioned_docs/version-24.10.2/how-to/use-external-signer/use-web3signer.md
new file mode 100644
index 000000000..71eba5fe7
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/use-external-signer/use-web3signer.md
@@ -0,0 +1,42 @@
+---
+title: Use Web3Signer
+description: Use the Web3Signer external signing client.
+sidebar_position: 1
+---
+
+# 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.
+
+```bash
+teku --network=holesky \
+--eth1-endpoint=http://localhost:8545 \
+--validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b \
+--validators-external-signer-url=http://localhost:9000
+```
+
+The command line specifies the following:
+
+- 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).
+
+:::
+
+
+
+[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/
\ No newline at end of file
diff --git a/versioned_docs/version-24.10.2/how-to/use-rewards-api.md b/versioned_docs/version-24.10.2/how-to/use-rewards-api.md
new file mode 100644
index 000000000..4bdfaa5c1
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/use-rewards-api.md
@@ -0,0 +1,149 @@
+---
+description: Use the rewards API to view validator rewards.
+sidebar_position: 12
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# 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#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 less blocks.
+
+## Examples
+
+Query all the rewards from the block currently at head.
+
+
+
+
+```bash
+curl http://localhost:5051/eth/v1/beacon/rewards/blocks/head |jq
+```
+
+
+
+
+```json
+{
+ "execution_optimistic": false,
+ "finalized": false,
+ "data": {
+ "proposer_index": "555552",
+ "total": "1217168",
+ "attestations": "0",
+ "sync_aggregate": "1217168",
+ "proposer_slashings": "0",
+ "attester_slashings": "0"
+ }
+}
+```
+
+
+
+
+Query all the sync committee rewards from the block at head for validator index 1.
+
+
+
+
+```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
+```
+
+
+
+
+```json
+{
+ "execution_optimistic": false,
+ "finalized": false,
+ "data": [
+ {
+ "validator_index": "1",
+ "reward": "16778"
+ }
+ ]
+}
+```
+
+
+
+
+Query attestation rewards from epoch 204644, just for validator index 0.
+
+
+
+
+```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
+```
+
+
+
+
+```json
+ {
+ "execution_optimistic": false,
+ "finalized": true,
+ "data": {
+ "ideal_rewards": [...],
+ "total_rewards": [
+ {
+ "validator_index": "0",
+ "head": "3125",
+ "target": "6005",
+ "source": "3236"
+ }
+ ]
+ }
+}
+```
+
+
diff --git a/versioned_docs/version-24.10.2/how-to/use-sentry-nodes.md b/versioned_docs/version-24.10.2/how-to/use-sentry-nodes.md
new file mode 100644
index 000000000..44c777f31
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/use-sentry-nodes.md
@@ -0,0 +1,74 @@
+---
+title: Use sentry beacon nodes
+description: Mitigate DoS attacks by using sentry nodes.
+sidebar_position: 7
+---
+
+# 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=` cannot be used with [`--beacon-node-api-endpoint`](../reference/cli/subcommands/validator-client.md#beacon-node-api-endpoint).
+
+:::
+
+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=` 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.
diff --git a/versioned_docs/version-24.10.2/how-to/voluntarily-exit.md b/versioned_docs/version-24.10.2/how-to/voluntarily-exit.md
new file mode 100644
index 000000000..a278ff311
--- /dev/null
+++ b/versioned_docs/version-24.10.2/how-to/voluntarily-exit.md
@@ -0,0 +1,86 @@
+---
+title: Voluntarily exit
+description: Voluntarily exit a validator from the Beacon Chain.
+sidebar_position: 8
+---
+
+# 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/#operation/getEthV1BeaconPoolVoluntary_exits) API to check the pending exit queue.
+
+## Create but don't submit an exit
+
+Use the [`voluntary-exit`](../reference/cli/subcommands/voluntary-exit.md) subcommand to create a
+signed exit for the specified validators, but not submit it to the beacon node.
+
+```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`.
+
+
+
+[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
+[REST API enabled]: ../reference/cli/index.md#rest-api-enabled
diff --git a/versioned_docs/version-24.10.2/images/architecture.png b/versioned_docs/version-24.10.2/images/architecture.png
new file mode 100644
index 000000000..6c76dc2a3
Binary files /dev/null and b/versioned_docs/version-24.10.2/images/architecture.png differ
diff --git a/versioned_docs/version-24.10.2/images/execution-consensus-clients.png b/versioned_docs/version-24.10.2/images/execution-consensus-clients.png
new file mode 100644
index 000000000..9d56ceb37
Binary files /dev/null and b/versioned_docs/version-24.10.2/images/execution-consensus-clients.png differ
diff --git a/versioned_docs/version-24.10.2/images/favicon.svg b/versioned_docs/version-24.10.2/images/favicon.svg
new file mode 100644
index 000000000..1ed75f708
--- /dev/null
+++ b/versioned_docs/version-24.10.2/images/favicon.svg
@@ -0,0 +1,14 @@
+
+
diff --git a/versioned_docs/version-24.10.2/images/logo.svg b/versioned_docs/version-24.10.2/images/logo.svg
new file mode 100644
index 000000000..79f090561
--- /dev/null
+++ b/versioned_docs/version-24.10.2/images/logo.svg
@@ -0,0 +1,7 @@
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-24.10.2/images/time_synchronized_drift_chart.png b/versioned_docs/version-24.10.2/images/time_synchronized_drift_chart.png
new file mode 100644
index 000000000..6c852a009
Binary files /dev/null and b/versioned_docs/version-24.10.2/images/time_synchronized_drift_chart.png differ
diff --git a/versioned_docs/version-24.10.2/index.md b/versioned_docs/version-24.10.2/index.md
new file mode 100644
index 000000000..7989bd247
--- /dev/null
+++ b/versioned_docs/version-24.10.2/index.md
@@ -0,0 +1,30 @@
+---
+title: Introduction
+slug: 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)
diff --git a/versioned_docs/version-24.10.2/reference/cli/index.md b/versioned_docs/version-24.10.2/reference/cli/index.md
new file mode 100644
index 000000000..e0c430cf5
--- /dev/null
+++ b/versioned_docs/version-24.10.2/reference/cli/index.md
@@ -0,0 +1,4216 @@
+---
+title: Command line options
+description: Teku command line interface reference
+sidebar_position: 1
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Teku command line options
+
+This reference describes the syntax of the Teku command line interface (CLI) options.
+
+:::caution
+
+The CLI options are currently under development and may change.
+
+:::
+
+## 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`
+
+
+
+
+```bash
+--beacon-liveness-tracking-enabled[=]
+```
+
+
+
+
+```bash
+--beacon-liveness-tracking-enabled=true
+```
+
+
+
+
+```bash
+TEKU_BEACON_LIVENESS_TRACKING_ENABLED=true
+```
+
+
+
+
+```bash
+beacon-liveness-tracking-enabled: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--builder-bid-compare-factor=
+```
+
+
+
+
+```bash
+--builder-bid-compare-factor=50
+```
+
+
+
+
+```bash
+TEKU_BUILDER_BID_COMPARE_FACTOR=50
+```
+
+
+
+
+```bash
+builder-bid-compare-factor: 50
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--builder-endpoint=
+```
+
+
+
+
+```bash
+--builder-endpoint=http://127.0.0.1:18550
+```
+
+
+
+
+```bash
+TEKU_BUILDER_ENDPOINT=http://127.0.0.1:18550
+```
+
+
+
+
+```bash
+builder-endpoint: "http://127.0.0.1:18550"
+```
+
+
+
+
+The address for an external [builder endpoint](../../how-to/configure/builder-network.md).
+
+### `builder-set-user-agent-header`
+
+
+
+
+```bash
+--builder-set-user-agent-header[=]
+```
+
+
+
+
+```bash
+--builder-set-user-agent-header=true
+```
+
+
+
+
+```bash
+TEKU_BUILDER_SET_USER_AGENT_HEADER=true
+```
+
+
+
+
+```bash
+builder-set-user-agent-header: true
+```
+
+
+
+
+Enables or disables setting the User-Agent header to `teku/v` (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`
+
+
+
+
+```bash
+--checkpoint-sync-url=
+```
+
+
+
+
+```bash
+--checkpoint-sync-url="https://beaconstate.ethstaker.cc"
+```
+
+
+
+
+```bash
+TEKU_CHECKPOINT_SYNC_URL="https://beaconstate.ethstaker.cc"
+```
+
+
+
+
+```bash
+checkpoint-sync-url: "https://beaconstate.ethstaker.cc"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--config-file=
+```
+
+
+
+
+```bash
+--config-file=/home/me/me_node/config.yaml
+```
+
+
+
+
+```bash
+TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
+```
+
+
+
+
+The path to the [YAML configuration file](../../how-to/configure/use-config-file.md).
+The default is `none`.
+
+### `data-base-path`, `data-path`
+
+
+
+
+```bash
+--data-base-path=
+```
+
+
+
+
+```bash
+--data-base-path=/home/me/me_node
+```
+
+
+
+
+```bash
+TEKU_DATA_BASE_PATH=/home/me/me_node
+```
+
+
+
+
+```bash
+data-base-path: "/home/me/me_node"
+```
+
+
+
+
+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`
+- Windows: `%localappdata%\teku`.
+
+The default Docker image location is `/root/.local/share/teku`.
+
+### `data-beacon-path`
+
+
+
+
+```bash
+--data-beacon-path=
+```
+
+
+
+
+```bash
+--data-beacon-path=/home/me/me_beacon
+```
+
+
+
+
+```bash
+TEKU_DATA_BEACON_PATH=/home/me/me_beacon
+```
+
+
+
+
+```bash
+data-beacon-path: "/home/me/me_beaon"
+```
+
+
+
+
+The path to the beacon node data.
+The default is `/beacon` where `` is specified using
+[`--data-base-path`](#data-base-path-data-path).
+
+### `data-storage-archive-frequency`
+
+
+
+
+```bash
+--data-storage-archive-frequency=
+```
+
+
+
+
+```bash
+--data-storage-archive-frequency=1028
+```
+
+
+
+
+```bash
+TEKU_DATA_STORAGE_ARCHIVE_FREQUENCY=1028
+```
+
+
+
+
+```bash
+data-storage-archive-frequency: 1028
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--data-storage-mode=
+```
+
+
+
+
+```bash
+--data-storage-mode=archive
+```
+
+
+
+
+```bash
+TEKU_DATA_STORAGE_MODE=archive
+```
+
+
+
+
+```bash
+data-storage-mode: "archive"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--data-storage-non-canonical-blocks-enabled[=]
+```
+
+
+
+
+```bash
+--data-storage-non-canonical-blocks-enabled=true
+```
+
+
+
+
+```bash
+TEKU_DATA_STORAGE_NON_CANONICAL_BLOCKS_ENABLED=true
+```
+
+
+
+
+```bash
+data-storage-non-canonical-blocks-enabled: true
+```
+
+
+
+
+Enables or disables storing non-canonical blocks and blob sidecars. The default is `false`.
+
+### `data-validator-path`
+
+
+
+
+```bash
+--data-validator-path=
+```
+
+
+
+
+```bash
+--data-validator-path=/home/me/me_validator
+```
+
+
+
+
+```bash
+TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
+```
+
+
+
+
+```bash
+data-validator-path: "/home/me/me_validator"
+```
+
+
+
+
+The path to the validator client data.
+The default is `/validator` where `` is specified using
+[`--data-base-path`](#data-base-path-data-path).
+
+### `deposit-snapshot-enabled`
+
+
+
+
+```bash
+--deposit-snapshot-enabled[=]
+```
+
+
+
+
+```bash
+--deposit-snapshot-enabled=false
+```
+
+
+
+
+```bash
+TEKU_DEPOSIT_SNAPSHOT_ENABLED=false
+```
+
+
+
+
+```bash
+deposit-snapshot-enabled: false
+```
+
+
+
+
+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, Holesky,
+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`
+
+
+
+
+```bash
+--doppelganger-detection-enabled[=]
+```
+
+
+
+
+```bash
+--doppelganger-detection-enabled=true
+```
+
+
+
+
+```bash
+TEKU_DOPPELGANGER_DETECTION_ENABLED=true
+```
+
+
+
+
+```bash
+doppelganger-detection-enabled: true
+```
+
+
+
+
+Enables or disables [doppelganger detection](../../how-to/prevent-slashing/detect-doppelgangers.md).
+The default is `false`.
+
+### `ee-endpoint`
+
+
+
+
+```bash
+--ee-endpoint=
+```
+
+
+
+
+```bash
+--ee-endpoint=http://localhost:8550
+```
+
+
+
+
+```bash
+TEKU_EE_ENDPOINT=http://localhost:8550
+```
+
+
+
+
+```bash
+ee-endpoint: "http://localhost:8550"
+```
+
+
+
+
+The URL of the [execution client's](../../concepts/node-types.md#execution-clients) Engine JSON-RPC APIs.
+This replaces [`eth1-endpoint`](#eth1-endpoint-eth1-endpoints) after
+[The Merge](../../concepts/node-types.md).
+
+### `ee-jwt-claim-id`
+
+
+
+
+```bash
+--ee-jwt-claim-id=
+```
+
+
+
+
+```bash
+--ee-jwt-claim-id=foobar
+```
+
+
+
+
+```bash
+TEKU_EE_JWT_CLAIM_ID=foobar
+```
+
+
+
+
+```bash
+ee-jwt-claim-id: "foobar"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--ee-jwt-secret-file=
+```
+
+
+
+
+```bash
+--ee-jwt-secret-file=ee-jwt-secret.hex
+```
+
+
+
+
+```bash
+TEKU_EE_JWT_SECRET_FILE=ee-jwt-secret.hex
+```
+
+
+
+
+```bash
+ee-jwt-secret-file: "ee-jwt-secret.hex"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--eth1-deposit-contract-address=
+```
+
+
+
+
+```bash
+--eth1-deposit-contract-address=0x77f7bED277449F51505a4C54550B074030d989bC
+```
+
+
+
+
+```bash
+TEKU_ETH1_DEPOSIT_CONTRACT_ADDRESS=0x77f7bED277449F51505a4C54550B074030d989bC
+```
+
+
+
+
+```bash
+eth1-deposit-contract-address: "0x77f7bED277449F51505a4C54550B074030d989bC"
+```
+
+
+
+
+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).
+
+### `eth1-deposit-contract-max-request-size`
+
+
+
+
+```bash
+--eth1-deposit-contract-max-request-size=
+```
+
+
+
+
+```bash
+--eth1-deposit-contract-max-request-size=8000
+```
+
+
+
+
+```bash
+TEKU_ETH1_DEPOSIT_CONTRACT_MAX_REQUEST_SIZE=8000
+```
+
+
+
+
+```bash
+eth1-deposit-contract-max-request-size: 8000
+```
+
+
+
+
+The maximum number of blocks to request deposit contract event logs for in a single request.
+The default is `10000`.
+
+Setting a smaller max size may help if your execution layer client is slow at loading deposit event
+logs, or when receiving warnings that the execution layer client is unavailable.
+
+### `eth1-endpoint`, `eth1-endpoints`
+
+
+
+
+```bash
+--eth1-endpoint=[,...]...
+```
+
+
+
+
+```bash
+--eth1-endpoint=http://localhost:8545,https://mainnet.infura.io/v3/d0e21ccd0b1e4eef7784422eabc51111
+```
+
+
+
+
+```bash
+TEKU_ETH1_ENDPOINT=http://localhost:8545,https://mainnet.infura.io/v3/d0e21ccd0b1e4eef7784422eabc51111
+```
+
+
+
+
+```bash
+eth1-endpoint: ["http://localhost:8545","https://mainnet.infura.io/v3/d0e21ccd0b1e4eef7784422eabc51111"]
+```
+
+
+
+
+A comma-separated list of JSON-RPC URLs of execution layer clients.
+Each time Teku makes a call, it finds the first provider in the list that is available, on the right
+chain, and in sync.
+This option must be specified if running a validator.
+
+If not specified (that is, you're running a beacon node only), then provide an initial state using
+the [`--initial-state`](#initial-state) option, or start Teku from an existing database using
+[`--data-path`](#data-base-path-data-path), which provides the initial state to work from.
+You do not need to provide an initial state if running a public network which has already started
+(for example, Mainnet or Holesky).
+
+:::caution
+
+After [The Merge](../../concepts/node-types.md), you can't use `eth1-endpoint` to specify an
+external execution layer provider.
+This option is replaced by [`ee-endpoint`](#ee-endpoint) for each beacon node.
+
+:::
+
+### `exchange-capabilities-monitoring-enabled`
+
+
+
+
+```bash
+--exchange-capabilities-monitoring-enabled[=]
+```
+
+
+
+
+```bash
+--exchange-capabilities-monitoring-enabled=true
+```
+
+
+
+
+```bash
+TEKU_EXCHANGE_CAPABILITIES_MONITORING_ENABLED=true
+```
+
+
+
+
+```bash
+exchange-capabilities-monitoring-enabled: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--exit-when-no-validator-keys-enabled[=]
+```
+
+
+
+
+```bash
+--exit-when-no-validator-keys-enabled=true
+```
+
+
+
+
+```bash
+TEKU_EXIT_WHEN_NO_VALIDATOR_KEYS_ENABLED=true
+```
+
+
+
+
+```bash
+exit-when-no-validator-keys-enabled: true
+```
+
+
+
+
+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.
+
+:::
+
+### `genesis-state`
+
+
+
+
+```bash
+--genesis-state=
+```
+
+
+
+
+```bash
+--genesis-state=/home/me/genesis.ssz
+```
+
+
+
+
+```bash
+TEKU_GENESIS_STATE=/home/me/genesis.ssz
+```
+
+
+
+
+```bash
+genesis-state: "/home/me/genesis.ssz"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--ignore-weak-subjectivity-period-enabled[=]
+```
+
+
+
+
+```bash
+--ignore-weak-subjectivity-period-enabled=true
+```
+
+
+
+
+```bash
+TEKU_IGNORE_WEAK_SUBJECTIVITY_PERIOD_ENABLED=true
+```
+
+
+
+
+```bash
+ignore-weak-subjectivity-period-enabled: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--initial-state=
+```
+
+
+
+
+```bash
+--initial-state=/home/me/genesis.ssz
+```
+
+
+
+
+```bash
+TEKU_INITIAL_STATE=/home/me/genesis.ssz
+```
+
+
+
+
+```bash
+initial-state: "/home/me/genesis.ssz"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--log-color-enabled[=]
+```
+
+
+
+
+```bash
+--log-color-enabled=false
+```
+
+
+
+
+```bash
+TEKU_LOG_COLOR_ENABLED=false
+```
+
+
+
+
+```bash
+log-color-enabled: false
+```
+
+
+
+
+Enables or disables including a console color display code in status and event log messages.
+The default is `true`.
+
+### `log-destination`
+
+
+
+
+```bash
+--log-destination=
+```
+
+
+
+
+```bash
+--log-destination=CONSOLE
+```
+
+
+
+
+```bash
+TEKU_LOG_DESTINATION=CONSOLE
+```
+
+
+
+
+```bash
+log-destination: "CONSOLE"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--log-file=
+```
+
+
+
+
+```bash
+--log-file=teku_2020-01-01.log
+```
+
+
+
+
+```bash
+TEKU_LOG_FILE=teku_2020-01-01.log
+```
+
+
+
+
+```bash
+log-file: "teku_2020-01-01.log"
+```
+
+
+
+
+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`
+- Windows: `%localappdata%\teku\logs`
+
+The default Docker image location is `/root/.local/share/teku/logs`.
+
+### `log-file-name-pattern`
+
+
+
+
+```bash
+--log-file-name-pattern=
+```
+
+
+
+
+```bash
+--log-file-name-pattern=tekuL_%d{yyyy-MM-dd}.log
+```
+
+
+
+
+```bash
+TEKU_LOG_FILE_NAME_PATTERN=tekuL_%d{yyyy-MM-dd}.log
+```
+
+
+
+
+```bash
+log-file-name-pattern: "tekuL_%d{yyyy-MM-dd}.log"
+```
+
+
+
+
+The filename pattern to apply when creating log files.
+The default pattern is `teku_%d{yyyy-MM-dd}.log`.
+
+### `log-include-events-enabled`
+
+
+
+
+```bash
+--log-include-events-enabled[=]
+```
+
+
+
+
+```bash
+--log-include-events-enabled=false
+```
+
+
+
+
+```bash
+TEKU_LOG_INCLUDE_EVENTS_ENABLED=false
+```
+
+
+
+
+```bash
+log-include-events-enabled: false
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--log-include-validator-duties-enabled[=]
+```
+
+
+
+
+```bash
+--log-include-validator-duties-enabled=false
+```
+
+
+
+
+```bash
+TEKU_LOG_INCLUDE_VALIDATOR_DUTIES_ENABLED=false
+```
+
+
+
+
+```bash
+log-include-validator-duties-enabled: false
+```
+
+
+
+
+Enables or disables logging details of validator event duties.
+The default is `true`.
+
+:::note
+
+Logs could become noisy when running many validators.
+
+:::
+
+### `logging`
+
+
+
+
+```bash
+-l, --logging=
+```
+
+
+
+
+```bash
+--logging=DEBUG
+```
+
+
+
+
+```bash
+TEKU_LOGGING=DEBUG
+```
+
+
+
+
+```bash
+logging: "DEBUG"
+```
+
+
+
+
+The logging verbosity.
+Log levels are `OFF`, `FATAL`, `ERROR`, `WARN`, `INFO`, `DEBUG`, `TRACE`, and `ALL`.
+The default is `INFO`.
+
+### `metrics-block-timing-tracking-enabled`
+
+
+
+
+```bash
+--metrics-block-timing-tracking-enabled[=]
+```
+
+
+
+
+```bash
+--metrics-block-timing-tracking-enabled=false
+```
+
+
+
+
+```bash
+TEKU_METRICS_BLOCK_TIMING_TRACKING_ENABLED=false
+```
+
+
+
+
+```bash
+metrics-block-timing-tracking-enabled: false
+```
+
+
+
+
+Enables or disables block timing metrics. The default is `true`.
+
+### `metrics-categories`
+
+
+
+
+```bash
+--metrics-categories=[,...]...
+```
+
+
+
+
+```bash
+--metrics-categories=BEACON,JVM,PROCESS
+```
+
+
+
+
+```bash
+TEKU_METRICS_CATEGORIES=BEACON,JVM,PROCESS
+```
+
+
+
+
+```bash
+metrics-categories: ["BEACON", "JVM", "PROCESS"]
+```
+
+
+
+
+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`, `REMOTE_VALIDATOR`, `VALIDATOR`,
+`VALIDATOR_PERFORMANCE`, and `VALIDATOR_DUTY`.
+All but `VALIDATOR_DUTY` categories are enabled by default.
+
+When `metrics-categories` is used, only the categories specified in this option are enabled (all
+other categories are disabled).
+
+### `metrics-enabled`
+
+
+
+
+```bash
+--metrics-enabled[=]
+```
+
+
+
+
+```bash
+--metrics-enabled=true
+```
+
+
+
+
+```bash
+TEKU_METRICS_ENABLED=true
+```
+
+
+
+
+```bash
+metrics-enabled: true
+```
+
+
+
+
+Enables or disables the metrics exporter. The default is `false`.
+
+### `metrics-host-allowlist`
+
+
+
+
+```bash
+--metrics-host-allowlist=[,...]... or "*"
+```
+
+
+
+
+```bash
+--metrics-host-allowlist=medomain.com,meotherdomain.com
+```
+
+
+
+
+```bash
+TEKU_METRICS_HOST_ALLOWLIST=medomain.com,meotherdomain.com
+```
+
+
+
+
+```bash
+metrics-host-allowlist: ["medomain.com", "meotherdomain.com"]
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--metrics-interface=
+```
+
+
+
+
+```bash
+--metrics-interface=192.168.10.101
+```
+
+
+
+
+```bash
+TEKU_METRICS_INTERFACE=192.168.10.101
+```
+
+
+
+
+```bash
+metrics-interface: "192.168.10.101"
+```
+
+
+
+
+The host on which Prometheus accesses Teku metrics. The default is `127.0.0.1`.
+
+### `metrics-port`
+
+
+
+
+```bash
+--metrics-port=
+```
+
+
+
+
+```bash
+--metrics-port=6174
+```
+
+
+
+
+```bash
+TEKU_METRICS_PORT=6174
+```
+
+
+
+
+```bash
+metrics-port: 6174
+```
+
+
+
+
+The port (TCP) on which [Prometheus](https://prometheus.io/) accesses Teku metrics.
+The default is `8008`.
+
+### `metrics-publish-endpoint`
+
+
+
+
+```bash
+--metrics-publish-endpoint=
+```
+
+
+
+
+```bash
+--metrics-publish-endpoint=https://beaconcha.in/api/v1/client/metrics?apikey={apikey}
+```
+
+
+
+
+```bash
+TEKU_METRICS_PUBLISH_ENDPOINT=https://beaconcha.in/api/v1/client/metrics?apikey={apikey}
+```
+
+
+
+
+```bash
+metrics-publish-endpoint: "https://beaconcha.in/api/v1/client/metrics?apikey={apikey}"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--metrics-publish-interval=
+```
+
+
+
+
+```bash
+--metrics-publish-interval=60
+```
+
+
+
+
+```bash
+TEKU_METRICS_PUBLISH_INTERVAL=60
+```
+
+
+
+
+```bash
+metrics-publish-interval: "60"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--network=
+```
+
+
+
+
+```bash
+--network=mainnet
+```
+
+
+
+
+```bash
+TEKU_NETWORK=mainnet
+```
+
+
+
+
+```bash
+network: "mainnet"
+```
+
+
+
+
+The predefined network configuration.
+Accepts a predefined network name, or file path or URL to a YAML configuration file.
+See the [consensus specification] for examples.
+
+The default is `mainnet`.
+
+Possible values are:
+
+| Network | Chain | Type | Description |
+|:----------|:----------------|:-----------|:------------------------------------------------------------------------|
+| `mainnet` | Consensus layer | Production | Main network |
+| `minimal` | Consensus layer | Test | Used for local testing and development networks |
+| `gnosis` | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/) |
+| `holesky` | Consensus layer | Test | Multi-client testnet |
+| `sepolia` | Consensus layer | Test | Multi-client testnet |
+| `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 can provide defaults such as the initial state of the network, bootnodes, and
+the address of the deposit contract.
+
+### `p2p-advertised-ip`, `p2p-advertised-ips`
+
+
+
+
+```bash
+--p2p-advertised-ip=
+```
+
+
+
+
+```bash
+--p2p-advertised-ip=192.168.1.132
+```
+
+
+
+
+```bash
+TEKU_P2P_ADVERTISED_IP=192.168.1.132
+```
+
+
+
+
+```bash
+p2p-advertised-ip: "192.168.1.132"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--p2p-advertised-port=
+```
+
+
+
+
+```bash
+--p2p-advertised-port=1789
+```
+
+
+
+
+```bash
+TEKU_P2P_ADVERTISED_PORT=1789
+```
+
+
+
+
+```bash
+p2p-advertised-port: 1789
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--p2p-advertised-port-ipv6=
+```
+
+
+
+
+```bash
+--p2p-advertised-port-ipv6=1790
+```
+
+
+
+
+```bash
+TEKU_P2P_ADVERTISED_PORT_IPV6=1790
+```
+
+
+
+
+```bash
+p2p-advertised-port-ipv6: 1790
+```
+
+
+
+
+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-udp-port`
+
+
+
+
+```bash
+--p2p-advertised-udp-port=
+```
+
+
+
+
+```bash
+--p2p-advertised-udp-port=1789
+```
+
+
+
+
+```bash
+TEKU_P2P_ADVERTISED_UDP_PORT=1789
+```
+
+
+
+
+```bash
+p2p-advertised-udp-port: 1789
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--p2p-advertised-udp-port-ipv6=
+```
+
+
+
+
+```bash
+--p2p-advertised-udp-port-ipv6=1790
+```
+
+
+
+
+```bash
+TEKU_P2P_ADVERTISED_UDP_PORT_IPV6=1790
+```
+
+
+
+
+```bash
+p2p-advertised-udp-port-ipv6: 1790
+```
+
+
+
+
+The [IPv6](../../how-to/find-and-connect/configure-ipv6.md) UDP port to advertise 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`
+
+
+
+
+```bash
+--p2p-direct-peers=[,...]...
+```
+
+
+
+
+```bash
+--p2p-direct-peers=/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz,/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1
+```
+
+
+
+
+```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
+```
+
+
+
+
+```bash
+p2p-direct-peers: ["/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz",
+ "/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1"]
+```
+
+
+
+
+A comma-separated list of
+[multiaddresses](https://docs.libp2p.io/concepts/appendix/glossary/#multiaddr) 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`
+
+
+
+
+```bash
+--p2p-discovery-bootnodes=[,...]...
+```
+
+
+
+
+```bash
+--p2p-discovery-bootnodes=enr:-Iu4QG...wgiMo,enr:-Iu4QL...wgiMo
+```
+
+
+
+
+```bash
+TEKU_P2P_DISCOVERY_BOOTNODES=enr:-Iu4QG...wgiMo,enr:-Iu4QL...wgiMo
+```
+
+
+
+
+```bash
+p2p-discovery-bootnodes: ["enr:-Iu4QG...wgiMo",
+ "enr:-Iu4QL...wgiMo"]
+```
+
+
+
+
+A comma-separated list of Ethereum Node Records (ENRs) for P2P discovery bootstrap.
+
+### `p2p-discovery-enabled`
+
+
+
+
+```bash
+--p2p-discovery-enabled[=]
+```
+
+
+
+
+```bash
+--p2p-discovery-enabled=false
+```
+
+
+
+
+```bash
+TEKU_P2P_DISCOVERY_ENABLED=false
+```
+
+
+
+
+```bash
+p2p-discovery-enabled: false
+```
+
+
+
+
+Enables or disables P2P peer discovery.
+If disabled, [`p2p-static-peers`](#p2p-static-peers) defines the peer connections.
+The default is `true`.
+
+### `p2p-discovery-site-local-addresses-enabled`
+
+
+
+
+```bash
+--p2p-discovery-site-local-addresses-enabled[=]
+```
+
+
+
+
+```bash
+--p2p-discovery-site-local-addresses-enabled
+```
+
+
+
+
+```bash
+TEKU_P2P_DISCOVERY_SITE_LOCAL_ADDRESSES_ENABLED=true
+```
+
+
+
+
+```bash
+p2p-discovery-site-local-addresses-enabled: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--p2p-enabled[=]
+```
+
+
+
+
+```bash
+--p2p-enabled=false
+```
+
+
+
+
+```bash
+TEKU_P2P_ENABLED=false
+```
+
+
+
+
+```bash
+p2p-enabled: false
+```
+
+
+
+
+Enables or disables all P2P communication. The default is `true`.
+
+### `p2p-interface`, `p2p-interfaces`
+
+
+
+
+```bash
+--p2p-interface=
+```
+
+
+
+
+```bash
+--p2p-interface=192.168.1.132
+```
+
+
+
+
+```bash
+TEKU_P2P_INTERFACE=192.168.1.132
+```
+
+
+
+
+```bash
+p2p-interface: "192.168.1.132"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--p2p-nat-method=
+```
+
+
+
+
+```bash
+--p2p-nat-method=UPNP
+```
+
+
+
+
+```bash
+TEKU_P2P_NAT_METHOD=UPNP
+```
+
+
+
+
+```bash
+p2p-nat-method: "UPNP"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--p2p-peer-lower-bound=
+```
+
+
+
+
+```bash
+--p2p-peer-lower-bound=25
+```
+
+
+
+
+```bash
+TEKU_P2P_PEER_LOWER_BOUND=25
+```
+
+
+
+
+```bash
+p2p-peer-lower-bound: 25
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--p2p-peer-upper-bound=
+```
+
+
+
+
+```bash
+--p2p-peer-upper-bound=40
+```
+
+
+
+
+```bash
+TEKU_P2P_PEER_UPPER_BOUND=40
+```
+
+
+
+
+```bash
+p2p-peer-upper-bound: 40
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--p2p-port=
+```
+
+
+
+
+```bash
+# to listen on port 1789
+--p2p-port=1789
+```
+
+
+
+
+```bash
+# to listen on port 1789
+TEKU_P2P_PORT=1789
+```
+
+
+
+
+```bash
+p2p-port: 1789
+```
+
+
+
+
+The P2P listening ports (UDP and TCP). The default is `9000`.
+
+### `p2p-port-ipv6`
+
+
+
+
+```bash
+--p2p-port-ipv6=
+```
+
+
+
+
+```bash
+# to listen on port 1790
+--p2p-port-ipv6=1790
+```
+
+
+
+
+```bash
+# to listen on port 1790
+TEKU_P2P_PORT_IPV6=1790
+```
+
+
+
+
+```bash
+p2p-port-ipv6: 1790
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--p2p-private-key-file=
+```
+
+
+
+
+```bash
+--p2p-private-key-file=/home/me/me_node/key
+```
+
+
+
+
+```bash
+TEKU_P2P_PRIVATE_KEY_FILE=/home/me/me_node/key
+```
+
+
+
+
+```bash
+p2p-private-key-file: "/home/me/me_node/key"
+```
+
+
+
+
+The file containing the [node's private key](../../concepts/p2p-private-key.md).
+
+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.
+
+:::
+
+### `p2p-static-peers`
+
+
+
+
+```bash
+--p2p-static-peers=[,...]...
+```
+
+
+
+
+```bash
+--p2p-static-peers=/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz,/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1
+```
+
+
+
+
+```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
+```
+
+
+
+
+```bash
+p2p-static-peers: ["/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz",
+ "/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1"]
+```
+
+
+
+
+A comma-separated list of
+[multiaddresses](https://docs.libp2p.io/concepts/appendix/glossary/#multiaddr) of static peers with
+which to establish and maintain connections.
+
+### `p2p-subscribe-all-subnets-enabled`
+
+
+
+
+```bash
+--p2p-subscribe-all-subnets-enabled=
+```
+
+
+
+
+```bash
+--p2p-subscribe-all-subnets-enabled=true
+```
+
+
+
+
+```bash
+TEKU_P2P_SUBSCRIBE_ALL_SUBNETS_ENABLED=true
+```
+
+
+
+
+```bash
+p2p-subscribe-all-subnets-enabled: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--p2p-udp-port=
+```
+
+
+
+
+```bash
+--p2p-udp-port=1789
+```
+
+
+
+
+```bash
+TEKU_P2P_UDP_PORT=1789
+```
+
+
+
+
+```bash
+p2p-udp-port: 1789
+```
+
+
+
+
+The UDP port used for discovery. The default is the port specified in [`--p2p-port`](#p2p-port).
+
+### `p2p-udp-port-ipv6`
+
+
+
+
+```bash
+--p2p-udp-port-ipv6=
+```
+
+
+
+
+```bash
+--p2p-udp-port-ipv6=1790
+```
+
+
+
+
+```bash
+TEKU_P2P_UDP_PORT_IPV6=1790
+```
+
+
+
+
+```bash
+p2p-udp-port-ipv6: 1790
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--reconstruct-historic-states=
+```
+
+
+
+
+```bash
+--reconstruct-historic-states=true
+```
+
+
+
+
+```bash
+TEKU_RECONSTRUCT_HISTORIC_STATES=true
+```
+
+
+
+
+```bash
+reconstruct-historic-states: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--rest-api-cors-origins[=[,...]...] or "*"
+```
+
+
+
+
+```bash
+--rest-api-cors-origins="http://medomain.com","https://meotherdomain.com"
+```
+
+
+
+
+```bash
+TEKU_REST_API_CORS_ORIGINS="http://medomain.com","https://meotherdomain.com"
+```
+
+
+
+
+```bash
+rest-api-cors-origins: ["http://medomain.com","https://meotherdomain.com"]
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--rest-api-docs-enabled[=]
+```
+
+
+
+
+```bash
+--rest-api-docs-enabled=true
+```
+
+
+
+
+```bash
+TEKU_REST_API_DOCS_ENABLED=true
+```
+
+
+
+
+```bash
+rest-api-docs-enabled: true
+```
+
+
+
+
+Enables or disables the REST API documentation. The default is `false`.
+
+The documentation can be accessed at `http://:/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`
+
+
+
+
+```bash
+--rest-api-enabled[=]
+```
+
+
+
+
+```bash
+--rest-api-enabled=true
+```
+
+
+
+
+```bash
+TEKU_REST_API_ENABLED=true
+```
+
+
+
+
+```bash
+rest-api-enabled: true
+```
+
+
+
+
+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-host-allowlist`
+
+
+
+
+```bash
+--rest-api-host-allowlist=[,...]... or "*"
+```
+
+
+
+
+```bash
+--rest-api-host-allowlist=medomain.com,meotherdomain.com
+```
+
+
+
+
+```bash
+TEKU_REST_API_HOST_ALLOWLIST=medomain.com,meotherdomain.com
+```
+
+
+
+
+```bash
+rest-api-host-allowlist: ["medomain.com", "meotherdomain.com"]
+```
+
+
+
+
+A comma-separated list of hostnames to allow access to the REST API.
+By default, Teku accepts access from `localhost` and `127.0.0.1`.
+
+:::warning
+
+Only trusted parties should access the REST API.
+Do not directly expose these APIs publicly on production nodes.
+
+We don't recommend allowing all hostnames (`"*"`) for production environments.
+
+:::
+
+### `rest-api-interface`
+
+
+
+
+```bash
+--rest-api-interface=
+```
+
+
+
+
+```bash
+# to listen on all interfaces
+--rest-api-interface=0.0.0.0
+```
+
+
+
+
+```bash
+TEKU_REST_API_INTERFACE=0.0.0.0
+```
+
+
+
+
+```bash
+rest-api-interface: "0.0.0.0"
+```
+
+
+
+
+The interface on which the REST API listens. The default is `127.0.0.1`.
+
+### `rest-api-port`
+
+
+
+
+```bash
+--rest-api-port=
+```
+
+
+
+
+```bash
+# to listen on port 3435
+--rest-api-port=3435
+```
+
+
+
+
+```bash
+TEKU_REST_API_PORT=3435
+```
+
+
+
+
+```bash
+rest-api-port: 3435
+```
+
+
+
+
+The REST API listening port (HTTP). The default is `5051`.
+
+### `sentry-config-file`
+
+
+
+
+```bash
+--sentry-config-file=
+```
+
+
+
+
+```bash
+--sentry-config-file=/etc/sentry-node-config.json
+```
+
+
+
+
+```bash
+TEKU_SENTRY_CONFIG_FILE=/etc/sentry-node-config.json
+```
+
+
+
+
+```bash
+sentry-config-file: "/etc/sentry-node-config.json"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--shut-down-when-validator-slashed-enabled[=]
+```
+
+
+
+
+```bash
+--shut-down-when-validator-slashed-enabled=true
+```
+
+
+
+
+```bash
+TEKU_SHUT_DOWN_WHEN_VALIDATOR_SLASHED_ENABLED=true
+```
+
+
+
+
+```bash
+shut-down-when-validator-slashed-enabled: true
+```
+
+
+
+
+Enables or disables [validators slashing detection](../../how-to/prevent-slashing/detect-slashing.md).
+The default is `false`.
+
+### `validator-api-cors-origins`
+
+
+
+
+```bash
+--validator-api-cors-origins=""[,"",...] or "*"
+```
+
+
+
+
+```bash
+--validator-api-cors-origins="http://medomain.com","https://meotherdomain.com"
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_API_CORS_ORIGINS="http://medomain.com","https://meotherdomain.com"
+```
+
+
+
+
+```bash
+validator-api-cors-origins: ["http://medomain.com","https://meotherdomain.com"]
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validator-api-docs-enabled[=]
+```
+
+
+
+
+```bash
+--validator-api-docs-enabled=true
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_API_DOCS_ENABLED=true
+```
+
+
+
+
+```bash
+validator-api-docs-enabled: true
+```
+
+
+
+
+Enables or disables the [validator REST API documentation](../rest.md#enable-the-validator-client-api).
+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`
+
+
+
+
+```bash
+--validator-api-enabled[=]
+```
+
+
+
+
+```bash
+--validator-api-enabled=true
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_API_ENABLED=true
+```
+
+
+
+
+```bash
+validator-api-enabled: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validator-api-host-allowlist=[,...]... or "*"
+```
+
+
+
+
+```bash
+--validator-api-host-allowlist=medomain.com,meotherdomain.com
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_API_HOST_ALLOWLIST=medomain.com,meotherdomain.com
+```
+
+
+
+
+```bash
+validator-api-host-allowlist: ["medomain.com", "meotherdomain.com"]
+```
+
+
+
+
+A comma-separated list of hostnames to allow access to the
+[validator REST 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`
+
+
+
+
+```bash
+--validator-api-interface=
+```
+
+
+
+
+```bash
+# to listen on all interfaces
+--validator-api-interface=0.0.0.0
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_API_INTERFACE=0.0.0.0
+```
+
+
+
+
+```bash
+validator-api-interface: "0.0.0.0"
+```
+
+
+
+
+The interface on which the [validator REST API](../rest.md#enable-the-validator-client-api) listens.
+The default is `127.0.0.1`.
+
+### `validator-api-keystore-file`
+
+
+
+
+```bash
+--validator-api-keystore-file=
+```
+
+
+
+
+```bash
+--validator-api-keystore-file=validator_keystorstore.p12
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_API_KEYSTORE_FILE=validator_keystore.p12
+```
+
+
+
+
+```bash
+validator-api-keystore-file: "validator_keystore.p12"
+```
+
+
+
+
+The keystore file for the [validator REST 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`
+
+
+
+
+```bash
+--validator-api-keystore-password-file=
+```
+
+
+
+
+```bash
+--validator-api-keystore-password-file=validator_keystore_pass.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_API_KEYSTORE_PASSWORD_FILE=validator_keystore_pass.txt
+```
+
+
+
+
+```bash
+validator-api-keystore-password-file: "validator_keystore_pass.txt"
+```
+
+
+
+
+The password used to decrypt the keystore for the [validator REST API](../rest.md#enable-the-validator-client-api).
+
+### `validator-api-port`
+
+
+
+
+```bash
+--validator-api-port=
+```
+
+
+
+
+```bash
+--validator-api-port=5052
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_API_PORT=5052
+```
+
+
+
+
+```bash
+validator-api-port: 5052
+```
+
+
+
+
+The [validator REST API](../rest.md#enable-the-validator-client-api) listening port (HTTP).
+The default is `5052`.
+
+### `validators-builder-registration-default-enabled`
+
+
+
+
+```bash
+--validators-builder-registration-default-enabled[=]
+```
+
+
+
+
+```bash
+--validators-builder-registration-default-enabled=true
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_BUILDER_REGISTRATION_DEFAULT_ENABLED=true
+```
+
+
+
+
+```bash
+validators-builder-registration-default-enabled: true
+```
+
+
+
+
+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-early-attestations-enabled`
+
+
+
+
+```bash
+--validators-early-attestations-enabled[=]
+```
+
+
+
+
+```bash
+--validators-early-attestations-enabled=false
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EARLY_ATTESTATIONS_ENABLED=false
+```
+
+
+
+
+```bash
+validators-early-attestations-enabled: false
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validators-external-signer-keystore=
+```
+
+
+
+
+```bash
+--validators-external-signer-keystore=teku_client_keystore.p12
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_KEYSTORE=teku_client_keystore.p12
+```
+
+
+
+
+```bash
+validators-external-signer-keystore: "teku_client_keystore.p12"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validators-external-signer-keystore-password-file=
+```
+
+
+
+
+```bash
+--validators-external-signer-keystore-password-file=keystore_pass.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_KEYSTORE_PASSWORD_FILE=keystore_pass.txt
+```
+
+
+
+
+```bash
+validators-external-signer-keystore-password-file: "keystore_pass.txt"
+```
+
+
+
+
+The password file used to decrypt the keystore.
+
+### `validators-external-signer-public-keys`
+
+
+
+
+```bash
+--validators-external-signer-public-keys=[,...]
+```
+
+
+
+
+```bash
+--validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_PUBLIC_KEYS=0xa99a...e44c,0xb89b...4a0b
+```
+
+
+
+
+```bash
+validators-external-signer-public-keys: ["0xa99a...e44c","0xb89b...4a0b"]
+```
+
+
+
+
+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/web3signer-eth2.html#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`
+
+
+
+
+```bash
+--validators-external-signer-slashing-protection-enabled[=]
+```
+
+
+
+
+```bash
+--validators-external-signer-slashing-protection-enabled=false
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_SLASHING_PROTECTION_ENABLED=false
+```
+
+
+
+
+```bash
+validators-external-signer-slashing-protection-enabled: false
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validators-external-signer-timeout=
+```
+
+
+
+
+```bash
+--validators-external-signer-timeout=2000
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_TIMEOUT=2000
+```
+
+
+
+
+```bash
+validators-external-signer-timeout: 2000
+```
+
+
+
+
+The timeout in milliseconds for requests to the external signer. The default is `5000`.
+
+### `validators-external-signer-truststore`
+
+
+
+
+```bash
+--validators-external-signer-truststore=
+```
+
+
+
+
+```bash
+--validators-external-signer-truststore=websigner_truststore.p12
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE=websigner_truststore.p12
+```
+
+
+
+
+```bash
+validators-external-signer-truststore: "websigner_truststore.p12"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validators-external-signer-truststore-password-file=
+```
+
+
+
+
+```bash
+--validators-external-signer-truststore-password-file=truststore_pass.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE_PASSWORD_FILE=truststore_pass.txt
+```
+
+
+
+
+```bash
+validators-external-signer-truststore-password-file: "truststore_pass.txt"
+```
+
+
+
+
+The password file used to decrypt the keystore.
+
+### `validators-external-signer-url`
+
+
+
+
+```bash
+--validators-external-signer-url=
+```
+
+
+
+
+```bash
+--validators-external-signer-url=http://localhost:9000
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_URL=http://localhost:9000
+```
+
+
+
+
+```bash
+validators-external-signer-url: "http://localhost:9000"
+```
+
+
+
+
+The URL on which the external signer (for example, Web3Signer) is running.
+
+### `validators-graffiti`
+
+
+
+
+```bash
+--validators-graffiti=
+```
+
+
+
+
+```bash
+--validators-graffiti="Teku validator"
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_GRAFFITI="Teku validator"
+```
+
+
+
+
+```bash
+validators-graffiti: "Teku validator"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validators-graffiti-file=
+```
+
+
+
+
+```bash
+--validators-graffiti-file=/Users/me/mynode/graffiti.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_GRAFFITI_FILE=/Users/me/mynode/graffiti.txt
+```
+
+
+
+
+```bash
+validators-graffiti-file: "/Users/me/mynode/graffiti.txt"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validators-graffiti-client-append-format=
+```
+
+
+
+
+```bash
+--validators-graffiti-client-append-format=CLIENT_CODES
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_GRAFFITI_CLIENT_APPEND_FORMAT=CLIENT_CODES
+```
+
+
+
+
+```bash
+validators-graffiti-client-append-format: CLIENT_CODES
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validator-is-local-slashing-protection-synchronized-enabled[=]
+```
+
+
+
+
+```bash
+--validator-is-local-slashing-protection-synchronized-enabled=true
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_IS_LOCAL_SLASHING_PROTECTION_SYNCHRONIZED_ENABLED=true
+```
+
+
+
+
+```bash
+validator-is-local-slashing-protection-synchronized-enabled: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validator-keys=: | :[,: | :...]...
+```
+
+
+
+
+```bash
+--validator-keys=/home/validator/keys:home/validator/passwords
+```
+
+
+
+
+```bash
+--validator-keys=/home/validator/keys/validator_217179e.json:/home/validator/passwords/validator_217179e.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_KEYS=/home/validator/keys:home/validator/passwords
+```
+
+
+
+
+```bash
+validator-keys: "/home/validator/keys:home/validator/passwords"
+```
+
+
+
+
+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.
+
+:::note
+
+The path separator is operating system dependent, and should be `;` in Windows rather than `:`.
+
+:::
+
+### `validators-keystore-locking-enabled`
+
+
+
+
+```bash
+--validators-keystore-locking-enabled=
+```
+
+
+
+
+```bash
+--validators-keystore-locking-enabled=true
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_KEYSTORE_LOCKING_ENABLED=true
+```
+
+
+
+
+```bash
+validators-keystore-locking-enabled: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validators-performance-tracking-mode=
+```
+
+
+
+
+```bash
+--validators-performance-tracking-mode=LOGGING
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_PERFORMANCE_TRACKING_MODE=LOGGING
+```
+
+
+
+
+```bash
+validators-performance-tracking-mode: LOGGING
+```
+
+
+
+
+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-blinded-blocks-enabled`
+
+
+
+
+```bash
+--validators-proposer-blinded-blocks-enabled[=]
+```
+
+
+
+
+```bash
+--validators-proposer-blinded-blocks-enabled=true
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_PROPOSER_BLINDED_BLOCKS_ENABLED=true
+```
+
+
+
+
+```bash
+validators-proposer-blinded-blocks-enabled: true
+```
+
+
+
+
+Enables or disables blinded blocks production, a prerequisite for the
+[builder network](../../how-to/configure/builder-network.md).
+When [`--validators-builder-registration-default-enabled`](#validators-builder-registration-default-enabled)
+is enabled, this option is enabled automatically.
+The default is `false`.
+
+### `validators-proposer-config`
+
+
+
+
+```bash
+--validators-proposer-config=
+```
+
+
+
+
+```bash
+--validators-proposer-config=/home/me/node/proposerConfig.json
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_PROPOSER_CONFIG=/home/me/node/proposerConfig.json
+```
+
+
+
+
+```bash
+validators-proposer-config: "/home/me/node/proposerConfig.json"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validators-proposer-config-refresh-enabled[=]
+```
+
+
+
+
+```bash
+--validators-proposer-config-refresh-enabled=true
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_PROPOSER_CONFIG_REFRESH_ENABLED=true
+```
+
+
+
+
+```bash
+validators-proposer-config-refresh-enabled: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--validators-proposer-default-fee-recipient=
+```
+
+
+
+
+```bash
+--validators-proposer-default-fee-recipient=0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_PROPOSER_DEFAULT_FEE_RECIPIENT=0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73
+```
+
+
+
+
+```bash
+validators-proposer-default-fee-recipient: "0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+--ws-checkpoint=:
+```
+
+
+
+
+```bash
+--ws-checkpoint=0x5a642bb8f367e98c0d11426d98d28c465f8988fc960500886cb49faf0372883a:3600
+```
+
+
+
+
+```bash
+TEKU_WS_CHECKPOINT=0x5a642bb8f367e98c0d11426d98d28c465f8988fc960500886cb49faf0372883a:3600
+```
+
+
+
+
+```bash
+ws-checkpoint: "0x5a642bb8f367e98c0d11426d98d28c465f8988fc960500886cb49faf0372883a:3600"
+```
+
+
+
+
+A recent checkpoint within the [weak subjectivity period].
+Accepts the checkpoint using `:`, where `` 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.
+
+
+
+[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
diff --git a/versioned_docs/version-24.10.2/reference/cli/subcommands/admin.md b/versioned_docs/version-24.10.2/reference/cli/subcommands/admin.md
new file mode 100644
index 000000000..dad7d3440
--- /dev/null
+++ b/versioned_docs/version-24.10.2/reference/cli/subcommands/admin.md
@@ -0,0 +1,629 @@
+---
+title: admin
+sidebar_position: 2
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# `admin`
+
+Used to perform administrative tasks.
+
+## `weak-subjectivity`
+
+Display or clear weak subjectivity configuration.
+
+### `clear-state`
+
+Clears the stored weak subjectivity configuration.
+
+#### `config-file`
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --config-file=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --config-file=/home/me/me_node/config.yaml
+```
+
+
+
+
+```bash
+TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
+```
+
+
+
+
+Path to the YAML configuration file. The default is `none`.
+
+#### `data-base-path`, `data-path`
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --data-base-path=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --data-base-path=/home/me/me_node
+```
+
+
+
+
+```bash
+TEKU_DATA_BASE_PATH=/home/me/me_node
+```
+
+
+
+
+```bash
+data-base-path: "/home/me/me_node"
+```
+
+
+
+
+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`
+- Windows: `%localappdata%\teku`.
+
+The default Docker image location is `/root/.local/share/teku`.
+
+#### `data-beacon-path`
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --data-beacon-path=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --data-beacon-path=/home/me/me_beacon
+```
+
+
+
+
+```bash
+TEKU_DATA_BEACON_PATH=/home/me/me_beacon
+```
+
+
+
+
+```bash
+data-beacon-path: "/home/me/me_beaon"
+```
+
+
+
+
+Path to the beacon node data. The default is `/beacon` where `` is specified using [`--data-base-path`](#data-base-path-data-path).
+
+#### `data-storage-archive-frequency`
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --data-storage-archive-frequency=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --data-storage-archive-frequency=1028
+```
+
+
+
+
+```bash
+TEKU_DATA_STORAGE_ARCHIVE_FREQUENCY=1028
+```
+
+
+
+
+```bash
+data-storage-archive-frequency: 1028
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --data-storage-mode=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --data-storage-mode=archive
+```
+
+
+
+
+```bash
+TEKU_DATA_STORAGE_MODE=archive
+```
+
+
+
+
+```bash
+data-storage-mode: "archive"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --data-validator-path=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --data-validator-path=/home/me/me_validator
+```
+
+
+
+
+```bash
+TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
+```
+
+
+
+
+```bash
+data-validator-path: "/home/me/me_validator"
+```
+
+
+
+
+Path to the validator client data. The default is `/validator` where `` is specified using [`--data-base-path`](#data-base-path-data-path).
+
+#### `eth1-deposit-contract-address`
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --eth1-deposit-contract-address=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --eth1-deposit-contract-address=0x77f7bED277449F51505a4C54550B074030d989bC
+```
+
+
+
+
+```bash
+TEKU_ETH1_DEPOSIT_CONTRACT_ADDRESS=0x77f7bED277449F51505a4C54550B074030d989bC
+```
+
+
+
+
+```bash
+eth1-deposit-contract-address: "0x77f7bED277449F51505a4C54550B074030d989bC"
+```
+
+
+
+
+The address of the deposit contract. Only required when creating a custom network.
+
+#### `network`
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --network=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity clear-state --network=mainnet
+```
+
+
+
+
+```bash
+TEKU_NETWORK=mainnet
+```
+
+
+
+
+```bash
+network: "mainnet"
+```
+
+
+
+
+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 |
+| `minimal` | Consensus layer | Test | Used for local testing and development networks |
+| `holesky` | Consensus layer | Test | Multi-client testnet |
+| `gnosis` | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/) |
+| `sepolia` | Consensus layer | Test | Multi-client testnet |
+| `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`
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --config-file=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --config-file=/home/me/me_node/config.yaml
+```
+
+
+
+
+```bash
+TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
+```
+
+
+
+
+Path to the YAML configuration file. The default is `none`.
+
+#### `data-base-path`, `data-path`
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --data-base-path=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --data-base-path=/home/me/me_node
+```
+
+
+
+
+```bash
+TEKU_DATA_BASE_PATH=/home/me/me_node
+```
+
+
+
+
+```bash
+data-base-path: "/home/me/me_node"
+```
+
+
+
+
+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`
+- Windows: `%localappdata%\teku`.
+
+The default Docker image location is `/root/.local/share/teku`.
+
+#### `data-beacon-path`
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --data-beacon-path=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --data-beacon-path=/home/me/me_beacon
+```
+
+
+
+
+```bash
+TEKU_DATA_BEACON_PATH=/home/me/me_beacon
+```
+
+
+
+
+```bash
+data-beacon-path: "/home/me/me_beacon"
+```
+
+
+
+
+Path to the beacon node data. The default is `/beacon` where `` is specified using [`--data-base-path`](#data-base-path-data-path).
+
+#### `data-storage-archive-frequency`
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --data-storage-archive-frequency=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --data-storage-archive-frequency=1028
+```
+
+
+
+
+```bash
+TEKU_DATA_STORAGE_ARCHIVE_FREQUENCY=1028
+```
+
+
+
+
+```bash
+data-storage-archive-frequency: 1028
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --data-storage-mode=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --data-storage-mode=archive
+```
+
+
+
+
+```bash
+TEKU_DATA_STORAGE_MODE=archive
+```
+
+
+
+
+```bash
+data-storage-mode: "archive"
+```
+
+
+
+
+Set the strategy for handling historical chain data. Valid options are `archive`, `minimal`, and `prune`. The default is `minimal`.
+
+#### `data-validator-path`
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --data-validator-path=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --data-validator-path=/home/me/me_validator
+```
+
+
+
+
+```bash
+TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
+```
+
+
+
+
+```bash
+data-validator-path: "/home/me/me_validator"
+```
+
+
+
+
+Path to the validator client data. The default is `/validator` where `` is specified using [`--data-base-path`](#data-base-path-data-path).
+
+#### `eth1-deposit-contract-address`
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --eth1-deposit-contract-address=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --eth1-deposit-contract-address=0x77f7bED277449F51505a4C54550B074030d989bC
+```
+
+
+
+
+```bash
+TEKU_ETH1_DEPOSIT_CONTRACT_ADDRESS=0x77f7bED277449F51505a4C54550B074030d989bC
+```
+
+
+
+
+```bash
+eth1-deposit-contract-address: "0x77f7bED277449F51505a4C54550B074030d989bC"
+```
+
+
+
+
+The address of the deposit contract. Only required when creating a custom network.
+
+#### `network`
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --network=
+```
+
+
+
+
+```bash
+teku admin weak-subjectivity display-state --network=mainnet
+```
+
+
+
+
+```bash
+TEKU_NETWORK=mainnet
+```
+
+
+
+
+```bash
+network: "mainnet"
+```
+
+
+
+
+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 |
+| `minimal` | Consensus layer | Test | Used for local testing and development networks |
+| `gnosis` | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/) |
+| `holesky` | Consensus layer | Test | Multi-client testnet |
+| `sepolia` | Consensus layer | Test | Multi-client testnet |
+| `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.
diff --git a/versioned_docs/version-24.10.2/reference/cli/subcommands/development.md b/versioned_docs/version-24.10.2/reference/cli/subcommands/development.md
new file mode 100644
index 000000000..e05bf85e2
--- /dev/null
+++ b/versioned_docs/version-24.10.2/reference/cli/subcommands/development.md
@@ -0,0 +1,38 @@
+---
+title: Development and testing
+description: Teku command line interface subcommands
+sidebar_position: 7
+---
+
+# 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
+```
+
+
+
+[environment variables]: ../index.md##teku-environment-variables
+[configuration file]: ../../../how-to/configure/use-config-file.md
+
+## `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
+```
\ No newline at end of file
diff --git a/versioned_docs/version-24.10.2/reference/cli/subcommands/index.md b/versioned_docs/version-24.10.2/reference/cli/subcommands/index.md
new file mode 100644
index 000000000..e05c6cc79
--- /dev/null
+++ b/versioned_docs/version-24.10.2/reference/cli/subcommands/index.md
@@ -0,0 +1,40 @@
+---
+title: Subcommands
+description: Teku subcommands overview
+sidebar_position: 1
+---
+
+# 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#specifying-options).
+
+The available subcommands are:
+
+- [`admin`](admin.md)
+- [`migrate-database`](migrate-database.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
+```
diff --git a/versioned_docs/version-24.10.2/reference/cli/subcommands/migrate-database.md b/versioned_docs/version-24.10.2/reference/cli/subcommands/migrate-database.md
new file mode 100644
index 000000000..57de17d90
--- /dev/null
+++ b/versioned_docs/version-24.10.2/reference/cli/subcommands/migrate-database.md
@@ -0,0 +1,177 @@
+---
+title: migrate-database
+description: Database migration subcommand options
+sidebar_position: 3
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# `migrate-database`
+
+[Migrate the database to a LevelDB2 database](../../../how-to/migrate-database.md).
+
+:::note
+
+As of v21.5.0, new Teku installations use a LevelDB2 database. Previous Teku versions use RocksDB which continue to be supported.
+
+:::
+
+:::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`
+
+
+
+
+```bash
+teku migrate-database --config-file=
+```
+
+
+
+
+```bash
+teku migrate-database --config-file=/home/me/me_node/config.yaml
+```
+
+
+
+
+```bash
+TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
+```
+
+
+
+
+Path to the [YAML configuration file](../../../how-to/configure/use-config-file.md). The default is `none`.
+
+## `data-base-path`, `data-path`
+
+
+
+
+```bash
+teku migrate-database --data-base-path=
+```
+
+
+
+
+```bash
+teku migrate-database --data-base-path=/home/me/me_node
+```
+
+
+
+
+```bash
+TEKU_DATA_BASE_PATH=/home/me/me_node
+```
+
+
+
+
+```bash
+data-base-path: "/home/me/me_node"
+```
+
+
+
+
+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`
+- Windows: `%localappdata%\teku`
+
+The default Docker image location is `/root/.local/share/teku`.
+
+## `data-beacon-path`
+
+
+
+
+```bash
+teku migrate-database --data-beacon-path=
+```
+
+
+
+
+```bash
+teku migrate-database --data-beacon-path=/home/me/me_node
+```
+
+
+
+
+```bash
+TEKU_DATA_BEACON_PATH=/home/me/me_node
+```
+
+
+
+
+```bash
+data-beacon-path: "/home/me/me_node"
+```
+
+
+
+
+Path to the beacon node data. The default is `/beacon` where `` is specified using [`--data-base-path`](#data-base-path-data-path).
+
+## `network`
+
+
+
+
+```bash
+teku migrate-database --network=
+```
+
+
+
+
+```bash
+teku migrate-database --network=mainnet
+```
+
+
+
+
+```bash
+TEKU_NETWORK=mainnet
+```
+
+
+
+
+```bash
+network: "mainnet"
+```
+
+
+
+
+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 |
+| `minimal` | Consensus layer | Test | Used for local testing and development networks |
+| `gnosis` | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/) |
+| `holesky` | Consensus layer | Test | Multi-client testnet |
+| `sepolia` | Consensus layer | Test | Multi-client testnet |
+| `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/) |
diff --git a/versioned_docs/version-24.10.2/reference/cli/subcommands/slashing-protection.md b/versioned_docs/version-24.10.2/reference/cli/subcommands/slashing-protection.md
new file mode 100644
index 000000000..49a7b5452
--- /dev/null
+++ b/versioned_docs/version-24.10.2/reference/cli/subcommands/slashing-protection.md
@@ -0,0 +1,452 @@
+---
+title: slashing-protection
+sidebar_position: 4
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# `slashing-protection`
+
+Manage the local [slashing protection data] used by the validator.
+
+## `export`
+
+Exports the slashing protection database in the [validator client interchange format] format.
+
+### `config-file`
+
+
+
+
+```bash
+teku slashing-protection export --config-file=
+```
+
+
+
+
+```bash
+teku slashing-protection export --config-file=/home/me/me_node/config.yaml
+```
+
+
+
+
+```bash
+TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
+```
+
+
+
+
+Path to the YAML configuration file. The default is `none`.
+
+### `data-path`
+
+
+
+
+```bash
+teku slashing-protection export --data-path=
+```
+
+
+
+
+```bash
+teku slashing-protection export --data-path=/home/me/me_node
+```
+
+
+
+
+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`
+- Windows: `%localappdata%\teku`.
+
+### `data-validator-path`
+
+
+
+
+```bash
+teku slashing-protection export --data-validator-path=
+```
+
+
+
+
+```bash
+teku slashing-protection export --data-validator-path=/home/me/me_validator
+```
+
+
+
+
+```bash
+TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
+```
+
+
+
+
+```bash
+data-validator-path: "/home/me/me_validator"
+```
+
+
+
+
+Path to the validator client data. The default is `/validator` where `` is specified using [`--data-path`](#data-path).
+
+:::info
+
+Teku exports slashing protection data from the `slashprotection` directory under the validator client data directory.
+
+:::
+
+### `to`
+
+
+
+
+```bash
+teku slashing-protection export --to=
+```
+
+
+
+
+```bash
+teku slashing-protection export --to=/home/slash/b845...23bed.json
+```
+
+
+
+
+The file to export the slashing protection database to.
+
+Exports the database in the [validator client interchange format] 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`
+
+
+
+
+```bash
+teku slashing-protection import --config-file=
+```
+
+
+
+
+```bash
+teku slashing-protection import --config-file=/home/me/me_node/config.yaml
+```
+
+
+
+
+```bash
+TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
+```
+
+
+
+
+Path to the YAML configuration file. The default is `none`.
+
+### `data-path`
+
+
+
+
+```bash
+teku slashing-protection import --data-path=
+```
+
+
+
+
+```bash
+teku slashing-protection import --data-path=/home/me/me_node
+```
+
+
+
+
+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`
+- Windows: `%localappdata%\teku`.
+
+### `data-validator-path`
+
+
+
+
+```bash
+teku slashing-protection import --data-validator-path=
+```
+
+
+
+
+```bash
+teku slashing-protection import --data-validator-path=/home/me/me_validator
+```
+
+
+
+
+```bash
+TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
+```
+
+
+
+
+```bash
+data-validator-path: "/home/me/me_validator"
+```
+
+
+
+
+Path to the validator client data. The default is `/validator` where `` is specified using [`--data-path`](#data-path).
+
+:::info
+
+Teku imports slashing protection data into a `slashprotection` directory under the validator client data directory.
+
+:::
+
+### `from`
+
+
+
+
+```bash
+teku slashing-protection import --from=
+```
+
+
+
+
+```bash
+teku slashing-protection import --from=/home/slash/b845...23bed.json
+```
+
+
+
+
+The file to import the slashing protection database from.
+
+Teku imports the file to the `/validators/slashprotection/` directory in the format `.yml` (with no 0x prefix).
+
+`` is defined using [`--data-path`](#data-path).
+
+
+## `repair`
+
+Repairs corrupted slashing protection data files used by Teku.
+
+### `check-only-enabled`
+
+
+
+
+```bash
+teku slashing-protection repair --checking-only-enabled[=]
+```
+
+
+
+
+```bash
+teku slashing-protection repair --checking-only-enabled=false
+```
+
+
+
+
+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-base-path`](#data-base-path-data-path).
+
+### `config-file`
+
+
+
+
+```bash
+teku slashing-protection repair --config-file=
+```
+
+
+
+
+```bash
+teku slashing-protection repair --config-file=/home/me/me_node/config.yaml
+```
+
+
+
+
+Path to the YAML configuration file. The default is `none`.
+
+### `data-path`
+
+
+
+
+```bash
+teku slashing-protection repair --data-path=
+```
+
+
+
+
+```bash
+teku slashing-protection repair --data-path=/home/me/me_node
+```
+
+
+
+
+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`
+- Windows: `%localappdata%\teku`
+
+The default Docker image location is `/root/.local/share/teku`.
+
+### `data-validator-path`
+
+
+
+
+```bash
+teku slashing-protection repair --data-validator-path=
+```
+
+
+
+
+```bash
+teku slashing-protection repair --data-validator-path=/home/me/me_validator
+```
+
+
+
+
+Path to validator client data. The default is `/validator` where `` 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`
+
+
+
+
+```bash
+teku slashing-protection repair --network=
+```
+
+
+
+
+```bash
+teku slashing-protection repair --network=mainnet
+```
+
+
+
+
+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 |
+| `minimal` | Consensus layer | Test | Used for local testing and development networks |
+| `gnosis` | Consensus layer | Production | Network for the [Gnosis chain](https://www.gnosis.io/) |
+| `holesky` | Consensus layer | Test | Multi-client testnet |
+| `sepolia` | Consensus layer | Test | Multi-client testnet |
+| `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.
+
+### `slot`
+
+
+
+
+```bash
+teku slashing-protection repair --slot=
+```
+
+
+
+
+```bash
+teku slashing-protection repair --slot=1028
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku slashing-protection repair --update-all-enabled[=]
+```
+
+
+
+
+```bash
+teku slashing-protection repair --update-all-enabled=false
+```
+
+
+
+
+Enables all slashing protection records to be updated. The default is `false`.
+
+
+
+[slashing protection data]: ../../../concepts/slashing-protection.md
+[validator client interchange format]: https://eips.ethereum.org/EIPS/eip-3076
+[environment variables or a configuration file]: ../index.md#specifying-options
+[recent finalized checkpoint state from which to sync]: ../../../get-started/checkpoint-start.md
diff --git a/versioned_docs/version-24.10.2/reference/cli/subcommands/validator-client.md b/versioned_docs/version-24.10.2/reference/cli/subcommands/validator-client.md
new file mode 100644
index 000000000..f3c69789f
--- /dev/null
+++ b/versioned_docs/version-24.10.2/reference/cli/subcommands/validator-client.md
@@ -0,0 +1,1211 @@
+---
+title: validator-client, vc
+sidebar_position: 5
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# `validator-client`, `vc`
+
+Run a validator client that connects to a remote beacon node.
+
+## `beacon-node-api-endpoint`, `beacon-node-api-endpoints`
+
+
+
+
+```bash
+teku vc --beacon-node-api-endpoint=[,...]...
+```
+
+
+
+
+```bash
+teku vc --beacon-node-api-endpoint=http://192.138.10.12:5051,http://192.140.11.44:5051
+```
+
+
+
+
+```bash
+TEKU_BEACON_NODE_API_ENDPOINT=http://192.138.10.12,http://192.140.11.44:5051
+```
+
+
+
+
+```bash
+beacon-node-api-endpoint: ["http://192.138.10.12","http://192.140.11.44:5051"]
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --beacon-node-ssz-blocks-enabled=
+```
+
+
+
+
+```bash
+teku vc --beacon-node-ssz-blocks-enabled=false
+```
+
+
+
+
+```bash
+TEKU_BEACON_NODE_SSZ_BLOCKS_ENABLED=false
+```
+
+
+
+
+```bash
+beacon-node-ssz-blocks-enabled: false
+```
+
+
+
+
+Enable or disable the use of SSZ encoding for API requests to the beacon node to create blocks. The default is `true`.
+
+## `config-file`
+
+
+
+
+```bash
+teku vc --config-file=
+```
+
+
+
+
+```bash
+teku vc --config-file=/home/me/me_node/config.yaml
+```
+
+
+
+
+```bash
+TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
+```
+
+
+
+
+Path to the YAML configuration file. The default is `none`.
+
+## `data-base-path`, `data-path`
+
+
+
+
+```bash
+teku vc --data-base-path=
+```
+
+
+
+
+```bash
+teku vc --data-base-path=/home/me/me_node
+```
+
+
+
+
+```bash
+TEKU_DATA_BASE_PATH=/home/me/me_node
+```
+
+
+
+
+```bash
+data-base-path: "/home/me/me_node"
+```
+
+
+
+
+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`
+- Windows: `%localappdata%\teku`.
+
+The default Docker image location is `/root/.local/share/teku`.
+
+## `data-validator-path`
+
+
+
+
+```bash
+teku vc --data-validator-path=
+```
+
+
+
+
+```bash
+teku vc --data-validator-path=/home/me/me_validator
+```
+
+
+
+
+```bash
+TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
+```
+
+
+
+
+```bash
+data-validator-path: "/home/me/me_validator"
+```
+
+
+
+
+Path to the validator client data. The default is `/validator` where `` is specified using [`--data-base-path`](#data-base-path-data-path).
+
+## `log-color-enabled`
+
+
+
+
+```bash
+teku vc --log-color-enabled[=]
+```
+
+
+
+
+```bash
+teku vc --log-color-enabled=false
+```
+
+
+
+
+```bash
+TEKU_LOG_COLOR_ENABLED=false
+```
+
+
+
+
+```bash
+log-color-enabled: false
+```
+
+
+
+
+Specify whether status and event log messages include a console color display code. The default is `true`.
+
+## `log-destination`
+
+
+
+
+```bash
+teku vc --log-destination=
+```
+
+
+
+
+```bash
+teku vc --log-destination=CONSOLE
+```
+
+
+
+
+```bash
+TEKU_LOG_DESTINATION=CONSOLE
+```
+
+
+
+
+```bash
+log-destination: "CONSOLE"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --log-file=
+```
+
+
+
+
+```bash
+teku vc --log-file=teku_2020-01-01.log
+```
+
+
+
+
+```bash
+TEKU_LOG_FILE=teku_2020-01-01.log
+```
+
+
+
+
+```bash
+log-file: "teku_2020-01-01.log"
+```
+
+
+
+
+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`
+- Windows: `%localappdata%\teku\logs`
+
+The default Docker image location is `/root/.local/share/teku/logs`.
+
+## `log-file-name-pattern`
+
+
+
+
+```bash
+teku vc --log-file-name-pattern=
+```
+
+
+
+
+```bash
+teku vc --log-file-name-pattern=tekuL_%d{yyyy-MM-dd}.log
+```
+
+
+
+
+```bash
+TEKU_LOG_FILE_NAME_PATTERN=tekuL_%d{yyyy-MM-dd}.log
+```
+
+
+
+
+```bash
+log-file-name-pattern: "tekuL_%d{yyyy-MM-dd}.log"
+```
+
+
+
+
+Filename pattern to apply when creating log files. The default pattern is `teku_%d{yyyy-MM-dd}.log`
+
+## `log-include-events-enabled`
+
+
+
+
+```bash
+teku vc --log-include-events-enabled[=]
+```
+
+
+
+
+```bash
+teku vc --log-include-events-enabled=false
+```
+
+
+
+
+```bash
+TEKU_LOG_INCLUDE_EVENTS_ENABLED=false
+```
+
+
+
+
+```bash
+log-include-events-enabled: false
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --log-include-validator-duties-enabled[=]
+```
+
+
+
+
+```bash
+teku vc --log-include-validator-duties-enabled=true
+```
+
+
+
+
+```bash
+TEKU_LOG_INCLUDE_VALIDATOR_DUTIES_ENABLED=true
+```
+
+
+
+
+```bash
+log-include-validator-duties-enabled: true
+```
+
+
+
+
+Specify whether to log details of validator event duties. The default is `true`.
+
+:::note
+
+Logs could become noisy when running many validators.
+
+:::
+
+## `metrics-categories`
+
+
+
+
+```bash
+teku vc --metrics-categories=[,...]...
+```
+
+
+
+
+```bash
+teku vc --metrics-categories=BEACON,JVM,PROCESS
+```
+
+
+
+
+```bash
+TEKU_METRICS_CATEGORIES=BEACON,JVM,PROCESS
+```
+
+
+
+
+```bash
+metrics-categories: ["BEACON", "JVM", "PROCESS"]
+```
+
+
+
+
+Categories for which to track metrics. Options are `JVM`, `PROCESS`, `BEACON`, `DISCOVERY`, `EVENTBUS`, `EXECUTOR`, `LIBP2P`, `NETWORK`, `STORAGE`, `STORAGE_HOT_DB`, `STORAGE_FINALIZED_DB`, `REMOTE_VALIDATOR`, `VALIDATOR`, `VALIDATOR_PERFORMANCE`, `VALIDATOR_DUTY`. All but `VALIDATOR_DUTY` categories are enabled by default.
+
+When `metrics-categories` is used, only the categories specified in this option are enabled (all other categories are disabled).
+
+## `metrics-enabled`
+
+
+
+
+```bash
+teku vc --metrics-enabled[=]
+```
+
+
+
+
+```bash
+teku vc --metrics-enabled=true
+```
+
+
+
+
+```bash
+TEKU_METRICS_ENABLED=true
+```
+
+
+
+
+```bash
+metrics-enabled: true
+```
+
+
+
+
+Set to `true` to enable the metrics exporter. The default is `false`.
+
+## `metrics-host-allowlist`
+
+
+
+
+```bash
+teku vc --metrics-host-allowlist=[,...]... or "*"
+```
+
+
+
+
+```bash
+teku vc --metrics-host-allowlist=medomain.com,meotherdomain.com
+```
+
+
+
+
+```bash
+TEKU_METRICS_HOST_ALLOWLIST=medomain.com,meotherdomain.com
+```
+
+
+
+
+```bash
+metrics-host-allowlist: ["medomain.com", "meotherdomain.com"]
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --metrics-interface=
+```
+
+
+
+
+```bash
+teku vc --metrics-interface=192.168.10.101
+```
+
+
+
+
+```bash
+TEKU_METRICS_INTERFACE=192.168.10.101
+```
+
+
+
+
+```bash
+metrics-interface: "192.168.10.101"
+```
+
+
+
+
+Host on which Prometheus accesses Teku metrics. The default is `127.0.0.1`.
+
+## `metrics-port`
+
+
+
+
+```bash
+teku vc --metrics-port=
+```
+
+
+
+
+```bash
+teku vc --metrics-port=6174
+```
+
+
+
+
+```bash
+TEKU_METRICS_PORT=6174
+```
+
+
+
+
+```bash
+metrics-port: 6174
+```
+
+
+
+
+Specifies the port (TCP) on which [Prometheus](https://prometheus.io/) accesses Teku metrics. The default is `8008`.
+
+## `network`
+
+
+
+
+```bash
+teku vc --network=
+```
+
+
+
+
+```bash
+teku vc --network=auto
+```
+
+
+
+
+```bash
+TEKU_NETWORK=auto
+```
+
+
+
+
+```bash
+network: "auto"
+```
+
+
+
+
+Predefined network configuration. The default is `mainnet`.
+
+Use `auto` to fetch the network configuration from the beacon node endpoint directly.
+
+## `validator-keys`
+
+
+
+
+```bash
+teku vc --validator-keys=: | :[,: | :...]...
+```
+
+
+
+
+```bash
+teku vc --validator-keys=/home/validator/keys:home/validator/passwords
+```
+
+
+
+
+```bash
+teku vc --validator-keys=/home/validator/keys/validator_217179e.json:/home/validator/passwords/validator_217179e.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_KEYS=/home/validator/keys:home/validator/passwords
+```
+
+
+
+
+```bash
+validator-keys: "/home/validator/keys:home/validator/passwords"
+```
+
+
+
+
+Directory or file to load the encrypted keystore file(s) and associated password file(s) 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.
+
+:::note
+
+The path separator is operating system dependent, and should be `;` in Windows rather than `:`.
+
+:::
+
+## `validators-early-attestations-enabled`
+
+
+
+
+```bash
+teku vc --validators-early-attestations-enabled[=]
+```
+
+
+
+
+```bash
+teku vc --validators-early-attestations-enabled=false
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EARLY_ATTESTATIONS_ENABLED=false
+```
+
+
+
+
+```bash
+validators-early-attestations-enabled: false
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --validators-external-signer-keystore=
+```
+
+
+
+
+```bash
+teku vc --validators-external-signer-keystore=teku_client_keystore.p12
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_KEYSTORE=teku_client_keystore.p12
+```
+
+
+
+
+```bash
+validators-external-signer-keystore: "teku_client_keystore.p12"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --validators-external-signer-keystore-password-file=
+```
+
+
+
+
+```bash
+teku vc --validators-external-signer-keystore-password-file=keystore_pass.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_KEYSTORE_PASSWORD_FILE=keystore_pass.txt
+```
+
+
+
+
+```bash
+validators-external-signer-keystore-password-file: "keystore_pass.txt"
+```
+
+
+
+
+Password file used to decrypt the keystore.
+
+## `validators-external-signer-public-keys`
+
+
+
+
+```bash
+teku vc --validators-external-signer-public-keys=[,...]
+```
+
+
+
+
+```bash
+teku vc --validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_PUBLIC_KEYS=0xa99a...e44c,0xb89b...4a0b
+```
+
+
+
+
+```bash
+validators-external-signer-public-keys: ["0xa99a...e44c","0xb89b...4a0b"]
+```
+
+
+
+
+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/web3signer-eth2.html#tag/Public-Key).
+
+```bash
+--validators-external-signer-public-keys=external-signer
+```
+
+## `validators-external-signer-slashing-protection-enabled`
+
+
+
+
+```bash
+teku vc --validators-external-signer-slashing-protection-enabled[=]
+```
+
+
+
+
+```bash
+teku vc --validators-external-signer-slashing-protection-enabled=false
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_SLASHING_PROTECTION_ENABLED=false
+```
+
+
+
+
+```bash
+validators-external-signer-slashing-protection-enabled: false
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --validators-external-signer-timeout=
+```
+
+
+
+
+```bash
+teku vc --validators-external-signer-timeout=2000
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_TIMEOUT=2000
+```
+
+
+
+
+```bash
+validators-external-signer-timeout: 2000
+```
+
+
+
+
+Timeout in milliseconds for requests to the external signer. The default is 5000.
+
+## `validators-external-signer-truststore`
+
+
+
+
+```bash
+teku vc --validators-external-signer-truststore=
+```
+
+
+
+
+```bash
+teku vc --validators-external-signer-truststore=websigner_truststore.p12
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE=websigner_truststore.p12
+```
+
+
+
+
+```bash
+validators-external-signer-truststore: "websigner_truststore.p12"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --validators-external-signer-truststore-password-file=
+```
+
+
+
+
+```bash
+teku vc --validators-external-signer-truststore-password-file=truststore_pass.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE_PASSWORD_FILE=truststore_pass.txt
+```
+
+
+
+
+```bash
+validators-external-signer-truststore-password-file: "truststore_pass.txt"
+```
+
+
+
+
+Password file used to decrypt the [keystore](#validators-external-signer-truststore).
+
+## `validators-external-signer-url`
+
+
+
+
+```bash
+teku vc --validators-external-signer-url=
+```
+
+
+
+
+```bash
+teku vc --validators-external-signer-url=http://localhost:9000
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_URL=http://localhost:9000
+```
+
+
+
+
+```bash
+validators-external-signer-url: "http://localhost:9000"
+```
+
+
+
+
+URL on which the external signer (for example, Web3Signer) is running.
+
+## `validators-graffiti`
+
+
+
+
+```bash
+teku vc --validators-graffiti=
+```
+
+
+
+
+```bash
+teku vc --validators-graffiti="Teku validator"
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_GRAFFITI="Teku validator"
+```
+
+
+
+
+```bash
+validators-graffiti: "Teku validator"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --validators-graffiti-file=
+```
+
+
+
+
+```bash
+teku vc --validators-graffiti-file=/Users/me/mynode/graffiti.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_GRAFFITI_FILE=/Users/me/mynode/graffiti.txt
+```
+
+
+
+
+```bash
+validators-graffiti-file: "/Users/me/mynode/graffiti.txt"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --validators-keystore-locking-enabled=
+```
+
+
+
+
+```bash
+teku vc --validators-keystore-locking-enabled=true
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_KEYSTORE_LOCKING_ENABLED=true
+```
+
+
+
+
+```bash
+validators-keystore-locking-enabled: true
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku vc --validators-performance-tracking-mode=
+```
+
+
+
+
+```bash
+teku vc --validators-performance-tracking-mode=LOGGING
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_PERFORMANCE_TRACKING_MODE=LOGGING
+```
+
+
+
+
+```bash
+validators-performance-tracking-mode: LOGGING
+```
+
+
+
+
+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.
+
+
+
+[environment variables or a configuration file]: ../index.md#specifying-options
+[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
+[slashing protection]: ../../../concepts/slashing-protection.md
+[recent finalized checkpoint state from which to sync]: ../../../get-started/checkpoint-start.md
+[metrics]: ../../../how-to/monitor/use-metrics.md
diff --git a/versioned_docs/version-24.10.2/reference/cli/subcommands/voluntary-exit.md b/versioned_docs/version-24.10.2/reference/cli/subcommands/voluntary-exit.md
new file mode 100644
index 000000000..3609e4958
--- /dev/null
+++ b/versioned_docs/version-24.10.2/reference/cli/subcommands/voluntary-exit.md
@@ -0,0 +1,587 @@
+---
+title: voluntary-exit
+sidebar_position: 6
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# `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`
+
+
+
+
+```bash
+teku voluntary-exit --beacon-node-api-endpoint=
+```
+
+
+
+
+```bash
+teku voluntary-exit --beacon-node-api-endpoint=http://192.138.10.12
+```
+
+
+
+
+```bash
+TEKU_BEACON_NODE_ENDPOINT=http://192.138.10.12
+```
+
+
+
+
+```bash
+beacon-node-api-endpoint: "http://192.138.10.12"
+```
+
+
+
+
+Endpoint of the beacon node's REST API. The default is `http://127.0.0.1:5051`.
+
+## `config-file`
+
+
+
+
+```bash
+teku voluntary-exit --config-file=
+```
+
+
+
+
+```bash
+teku voluntary-exit --config-file=/home/me/me_node/config.yaml
+```
+
+
+
+
+```bash
+TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
+```
+
+
+
+
+Path to the YAML configuration file. The default is `none`.
+
+## `confirmation-enabled`
+
+
+
+
+```bash
+teku voluntary-exit --confirmation-enabled=
+```
+
+
+
+
+```bash
+teku voluntary-exit --confirmation-enabled=false
+```
+
+
+
+
+```bash
+TEKU_CONFIRMATION_ENABLED=false
+```
+
+
+
+
+```bash
+confirmation-enabled: false
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku voluntary-exit --epoch=
+```
+
+
+
+
+```bash
+teku voluntary-exit --epoch=24500
+```
+
+
+
+
+```bash
+TEKU_EPOCH=24500
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku voluntary-exit --include-keymanager-keys=
+```
+
+
+
+
+```bash
+teku voluntary-exit --include-keymanager-keys=true
+```
+
+
+
+
+Include validator keys managed using the [key manager APIs](../../../how-to/use-external-signer/manage-keys.md). The default is `false`.
+
+## `network`
+
+
+
+
+```bash
+teku voluntary-exit --network=
+```
+
+
+
+
+```bash
+teku voluntary-exit --network=mainnet
+```
+
+
+
+
+```bash
+TEKU_NETWORK=mainnet
+```
+
+
+
+
+```bash
+network: "mainnet"
+```
+
+
+
+
+Predefined network configuration. There is no default value, because Teku reads the network specification from the Beacon API unless specified.
+
+## `save-exits-path`
+
+
+
+
+```bash
+teku voluntary-exit --save-exits-path=
+```
+
+
+
+
+```bash
+teku voluntary-exit --save-exits-path=signedExitsPath
+```
+
+
+
+
+```bash
+TEKU_SAVE_EXITS_PATH=signedExitsPath
+```
+
+
+
+
+```bash
+save-exits-path: "signedExitsPath"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku voluntary-exit --validator-keys=: | :[,: | :...]...
+```
+
+
+
+
+```bash
+teku voluntary-exit --validator-keys=/home/validator/keys:home/validator/passwords
+```
+
+
+
+
+```bash
+teku voluntary-exit --validator-keys=/home/validator/keys/validator_217179e.json:/home/validator/passwords/validator_217179e.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATOR_KEYS=/home/validator/keys:home/validator/passwords
+```
+
+
+
+
+```bash
+validator-keys: "/home/validator/keys:home/validator/passwords"
+```
+
+
+
+
+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.
+
+:::note
+
+The path separator is operating system dependent, and should be `;` in Windows rather than `:`.
+
+:::
+
+## `validator-public-keys`
+
+
+
+
+```bash
+teku voluntary-exit --validator-public-keys=[,...]...
+```
+
+
+
+
+```bash
+teku voluntary-exit --validator-public-keys=0xc7931ac6937f6c776d8dfe84918f7b26d986f2e45af5869085839b8817db2705,0x179a0e2768621eede9ce961cf8ee4f0ece5be9a1795c294269b69b85c765f3cc
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-keystore=
+```
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-keystore=teku_client_keystore.p12
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_KEYSTORE=teku_client_keystore.p12
+```
+
+
+
+
+```bash
+validators-external-signer-keystore: "teku_client_keystore.p12"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-keystore-password-file=
+```
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-keystore-password-file=keystore_pass.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_KEYSTORE_PASSWORD_FILE=keystore_pass.txt
+```
+
+
+
+
+```bash
+validators-external-signer-keystore-password-file: "keystore_pass.txt"
+```
+
+
+
+
+Password file used to decrypt the keystore.
+
+## `validators-external-signer-public-keys`
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-public-keys=[,...]
+```
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_PUBLIC_KEYS=0xa99a...e44c,0xb89b...4a0b
+```
+
+
+
+
+```bash
+validators-external-signer-public-keys: ["0xa99a...e44c","0xb89b...4a0b"]
+```
+
+
+
+
+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/web3signer-eth2.html#tag/Public-Key).
+
+```bash
+teku voluntary-exit --validators-external-signer-public-keys=external-signer
+```
+
+## `validators-external-signer-timeout`
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-timeout=
+```
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-timeout=2000
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_TIMEOUT=2000
+```
+
+
+
+
+```bash
+validators-external-signer-timeout: 2000
+```
+
+
+
+
+Timeout in milliseconds for requests to the external signer. The default is 5000.
+
+## `validators-external-signer-truststore`
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-truststore=
+```
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-truststore=websigner_truststore.p12
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE=websigner_truststore.p12
+```
+
+
+
+
+```bash
+validators-external-signer-truststore: "websigner_truststore.p12"
+```
+
+
+
+
+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`
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-truststore-password-file=
+```
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-truststore-password-file=truststore_pass.txt
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE_PASSWORD_FILE=truststore_pass.txt
+```
+
+
+
+
+```bash
+validators-external-signer-truststore-password-file: "truststore_pass.txt"
+```
+
+
+
+
+Password file used to decrypt the keystore.
+
+## `validators-external-signer-url`
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-url=
+```
+
+
+
+
+```bash
+teku voluntary-exit --validators-external-signer-url=http://localhost:9000
+```
+
+
+
+
+```bash
+TEKU_VALIDATORS_EXTERNAL_SIGNER_URL=http://localhost:9000
+```
+
+
+
+
+```bash
+validators-external-signer-url: "http://localhost:9000"
+```
+
+
+
+
+URL of the external signer (for example, [Web3Signer]).
+
+
+
+[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
+[REST API enabled]: ../index.md#rest-api-enabled
+[voluntary exit]: ../../../how-to/voluntarily-exit.md
diff --git a/versioned_docs/version-24.10.2/reference/rest.md b/versioned_docs/version-24.10.2/reference/rest.md
new file mode 100644
index 000000000..eb8458f75
--- /dev/null
+++ b/versioned_docs/version-24.10.2/reference/rest.md
@@ -0,0 +1,93 @@
+---
+description: Teku RESTful API
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# 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::/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.
+
+
+
+
+
+```bash
+curl -X GET "http://localhost:5051/eth/v1/node/identity"
+```
+
+
+
+
+```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"
+ }
+ }
+}
+```
+
+
+
+
+## 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.
+
+
+
+[REST API documentation]: https://consensys.github.io/teku/
+[Postman]: https://www.postman.com/
+[cURL]: https://curl.haxx.se/
diff --git a/versioned_docs/version-24.10.2/tutorials/configure-external-signer-tls.md b/versioned_docs/version-24.10.2/tutorials/configure-external-signer-tls.md
new file mode 100644
index 000000000..546019083
--- /dev/null
+++ b/versioned_docs/version-24.10.2/tutorials/configure-external-signer-tls.md
@@ -0,0 +1,175 @@
+---
+title: Configure TLS communication with an external signer
+description: Configure TLS communication between Teku and Web3Signer.
+sidebar_position: 1
+---
+
+# 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 Holesky testnet.
+ You can [run a Besu node on Holesky](https://besu.hyperledger.org/development/public-networks/get-started/start-node#run-a-node-on-holesky-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 Holesky testnet, and connects to the execution client's JSON-RPC URL at `http://127.0.0.1:8551`.
+:::
+
+```bash
+teku --network=holesky \
+--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
+```
+
+
+
+[Web3Signer]: https://docs.web3signer.consensys.net/en/latest/
+[Besu]: https://besu.hyperledger.org/development/public-networks/get-started/install
+[Web3Signer slashing protection]: https://docs.web3signer.consensys.net/en/latest/concepts/slashing-protection/
diff --git a/versioned_sidebars/version-24.10.2-sidebars.json b/versioned_sidebars/version-24.10.2-sidebars.json
new file mode 100644
index 000000000..3ebba2d6b
--- /dev/null
+++ b/versioned_sidebars/version-24.10.2-sidebars.json
@@ -0,0 +1,76 @@
+{
+ "docSidebar": [
+ "index",
+ {
+ "type": "category",
+ "label": "Get started",
+ "collapsed": false,
+ "link": {
+ "type": "generated-index",
+ "slug": "/get-started"
+ },
+ "items": [
+ {
+ "type": "autogenerated",
+ "dirName": "get-started"
+ }
+ ]
+ },
+ {
+ "type": "category",
+ "label": "How to",
+ "link": {
+ "type": "generated-index",
+ "slug": "/how-to"
+ },
+ "items": [
+ {
+ "type": "autogenerated",
+ "dirName": "how-to"
+ }
+ ]
+ },
+ {
+ "type": "category",
+ "label": "Concepts",
+ "link": {
+ "type": "generated-index",
+ "slug": "/concepts"
+ },
+ "items": [
+ {
+ "type": "autogenerated",
+ "dirName": "concepts"
+ }
+ ]
+ },
+ {
+ "type": "category",
+ "label": "Tutorials",
+ "link": {
+ "type": "generated-index",
+ "slug": "tutorials"
+ },
+ "items": [
+ {
+ "type": "autogenerated",
+ "dirName": "tutorials"
+ }
+ ]
+ },
+ "chatbot"
+ ],
+ "referenceSidebar": [
+ {
+ "type": "category",
+ "label": "Teku command line",
+ "items": [
+ {
+ "type": "autogenerated",
+ "dirName": "reference/cli"
+ }
+ ]
+ },
+ "reference/rest"
+ ]
+}
diff --git a/versions-preset.json b/versions-preset.json
index 75c61f0bc..2755a9b57 100644
--- a/versions-preset.json
+++ b/versions-preset.json
@@ -1,6 +1,9 @@
{
+ "24.10.2": {
+ "label": "stable (24.10.2)"
+ },
"24.10.1": {
- "label": "stable (24.10.1)"
+ "label": "24.10.1"
},
"24.10.0": {
"label": "24.10.0"
diff --git a/versions.json b/versions.json
index 06b521d93..06ca64740 100644
--- a/versions.json
+++ b/versions.json
@@ -1,4 +1,5 @@
[
+ "24.10.2",
"24.10.1",
"24.10.0",
"24.8.0",