Teku command line options
This reference describes the syntax of the Teku command line interface (CLI) options.
The CLI options are currently under development and may change.
Specify options
You can specify Teku options:
-
On the command line.
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.
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:
source teku.autocomplete.sh
Autocomplete allows you to view option suggestions by entering --
and pressing the Tab key twice.
teku --Tab+Tab
Options
beacon-liveness-tracking-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--beacon-liveness-tracking-enabled[=<BOOLEAN>]
--beacon-liveness-tracking-enabled=true
TEKU_BEACON_LIVENESS_TRACKING_ENABLED=true
beacon-liveness-tracking-enabled: true
Enables or disables validator liveness tracking.
Used by doppelganger detection.
The default is false
.
builder-bid-compare-factor
- Syntax
- Example
- Environment variable
- Configuration file
--builder-bid-compare-factor=<STRING>
--builder-bid-compare-factor=50
TEKU_BUILDER_BID_COMPARE_FACTOR=50
builder-bid-compare-factor: 50
The builder bid compare factor. The default is 90 (90%).
Execution layer clients in Capella-enabled networks 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
- Syntax
- Example
- Environment variable
- Configuration file
--builder-endpoint=<URL>
--builder-endpoint=http://127.0.0.1:18550
TEKU_BUILDER_ENDPOINT=http://127.0.0.1:18550
builder-endpoint: "http://127.0.0.1:18550"
The address for an external builder endpoint.
builder-set-user-agent-header
- Syntax
- Example
- Environment variable
- Configuration file
--builder-set-user-agent-header[=<BOOLEAN>]
--builder-set-user-agent-header=true
TEKU_BUILDER_SET_USER_AGENT_HEADER=true
builder-set-user-agent-header: true
Enables or disables setting the User-Agent header to teku/v<version>
(for example, teku/v23.4.0
)
when making a builder bid request, to help builders identify clients and versions.
The default is true
.
checkpoint-sync-url
- Syntax
- Example
- Environment variable
- Configuration file
--checkpoint-sync-url=<URL>
--checkpoint-sync-url="https://beaconstate.ethstaker.cc"
TEKU_CHECKPOINT_SYNC_URL="https://beaconstate.ethstaker.cc"
checkpoint-sync-url: "https://beaconstate.ethstaker.cc"
The URL of a Checkpointz endpoint used to start Teku from a recent state.
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.
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
- Syntax
- Example
- Environment variable
--config-file=<FILE>
--config-file=/home/me/me_node/config.yaml
TEKU_CONFIG_FILE=/home/me/me_node/config.yaml
The path to the YAML configuration file.
The default is none
.
data-base-path
, data-path
- Syntax
- Example
- Environment variable
- Configuration file
--data-base-path=<PATH>
--data-base-path=/home/me/me_node
TEKU_DATA_BASE_PATH=/home/me/me_node
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
- Syntax
- Example
- Environment variable
- Configuration file
--data-beacon-path=<PATH>
--data-beacon-path=/home/me/me_beacon
TEKU_DATA_BEACON_PATH=/home/me/me_beacon
data-beacon-path: "/home/me/me_beaon"
The path to the beacon node data.
The default is <data-base-path>/beacon
where <data-base-path>
is specified using
--data-base-path
.
data-storage-archive-frequency
- Syntax
- Example
- Environment variable
- Configuration file
--data-storage-archive-frequency=<NUMBER>
--data-storage-archive-frequency=1028
TEKU_DATA_STORAGE_ARCHIVE_FREQUENCY=1028
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
is not set to archive
.
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
- Syntax
- Example
- Environment variable
- Configuration file
--data-storage-mode=<STORAGE_MODE>
--data-storage-mode=archive
TEKU_DATA_STORAGE_MODE=archive
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
- Syntax
- Example
- Environment variable
- Configuration file
--data-storage-non-canonical-blocks-enabled[=<BOOLEAN>]
--data-storage-non-canonical-blocks-enabled=true
TEKU_DATA_STORAGE_NON_CANONICAL_BLOCKS_ENABLED=true
data-storage-non-canonical-blocks-enabled: true
Enables or disables storing non-canonical blocks and blob sidecars. The default is false
.
data-validator-path
- Syntax
- Example
- Environment variable
- Configuration file
--data-validator-path=<PATH>
--data-validator-path=/home/me/me_validator
TEKU_DATA_VALIDATOR_PATH=/home/me/me_validator
data-validator-path: "/home/me/me_validator"
The path to the validator client data.
The default is <data-base-path>/validator
where <data-base-path>
is specified using
--data-base-path
.
deposit-snapshot-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--deposit-snapshot-enabled[=<BOOLEAN>]
--deposit-snapshot-enabled=false
TEKU_DEPOSIT_SNAPSHOT_ENABLED=false
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.
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
- Syntax
- Example
- Environment variable
- Configuration file
--doppelganger-detection-enabled[=<BOOLEAN>]
--doppelganger-detection-enabled=true
TEKU_DOPPELGANGER_DETECTION_ENABLED=true
doppelganger-detection-enabled: true
Enables or disables doppelganger detection.
The default is false
.
ee-endpoint
- Syntax
- Example
- Environment variable
- Configuration file
--ee-endpoint=<URL>
--ee-endpoint=http://localhost:8550
TEKU_EE_ENDPOINT=http://localhost:8550
ee-endpoint: "http://localhost:8550"
The URL of the execution client's Engine JSON-RPC APIs.
This replaces eth1-endpoint
after
The Merge.
ee-jwt-claim-id
- Syntax
- Example
- Environment variable
- Configuration file
--ee-jwt-claim-id=<STRING>
--ee-jwt-claim-id=foobar
TEKU_EE_JWT_CLAIM_ID=foobar
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
- Syntax
- Example
- Environment variable
- Configuration file
--ee-jwt-secret-file=<FILE>
--ee-jwt-secret-file=ee-jwt-secret.hex
TEKU_EE_JWT_SECRET_FILE=ee-jwt-secret.hex
ee-jwt-secret-file: "ee-jwt-secret.hex"
The shared secret used to authenticate 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.
eth1-deposit-contract-address
- Syntax
- Example
- Environment variable
- Configuration file
--eth1-deposit-contract-address=<ADDRESS>
--eth1-deposit-contract-address=0x77f7bED277449F51505a4C54550B074030d989bC
TEKU_ETH1_DEPOSIT_CONTRACT_ADDRESS=0x77f7bED277449F51505a4C54550B074030d989bC
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
- The predefined network supplied using
--network
.
eth1-deposit-contract-max-request-size
- Syntax
- Example
- Environment variable
- Configuration file
--eth1-deposit-contract-max-request-size=<INTEGER>
--eth1-deposit-contract-max-request-size=8000
TEKU_ETH1_DEPOSIT_CONTRACT_MAX_REQUEST_SIZE=8000
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
- Syntax
- Example
- Environment variable
- Configuration file
--eth1-endpoint=<URL>[,<URL>...]...
--eth1-endpoint=http://localhost:8545,https://mainnet.infura.io/v3/d0e21ccd0b1e4eef7784422eabc51111
TEKU_ETH1_ENDPOINT=http://localhost:8545,https://mainnet.infura.io/v3/d0e21ccd0b1e4eef7784422eabc51111
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
option, or start Teku from an existing database using
--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).
After The Merge, you can't use eth1-endpoint
to specify an
external execution layer provider.
This option is replaced by ee-endpoint
for each beacon node.
exchange-capabilities-monitoring-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--exchange-capabilities-monitoring-enabled[=<BOOLEAN>]
--exchange-capabilities-monitoring-enabled=true
TEKU_EXCHANGE_CAPABILITIES_MONITORING_ENABLED=true
exchange-capabilities-monitoring-enabled: true
Enables or disables querying the execution client
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
- Syntax
- Example
- Environment variable
- Configuration file
--exit-when-no-validator-keys-enabled[=<BOOLEAN>]
--exit-when-no-validator-keys-enabled=true
TEKU_EXIT_WHEN_NO_VALIDATOR_KEYS_ENABLED=true
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
.
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
- Syntax
- Example
- Environment variable
- Configuration file
--genesis-state=<FILE>
--genesis-state=/home/me/genesis.ssz
TEKU_GENESIS_STATE=/home/me/genesis.ssz
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
option.
It also is not required if the --reconstruct-historic-states
is
not used.
If overriding the genesis state in a custom network, you must supply the genesis state file at each restart.
You can use Infura as the source of initial states using
--genesis-state https://{projectid}:{secret}@eth2-beacon-mainnet.infura.io/eth/v2/debug/beacon/states/genesis
.
help
-h, --help
Show the help message and exit.
ignore-weak-subjectivity-period-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--ignore-weak-subjectivity-period-enabled[=<BOOLEAN>]
--ignore-weak-subjectivity-period-enabled=true
TEKU_IGNORE_WEAK_SUBJECTIVITY_PERIOD_ENABLED=true
ignore-weak-subjectivity-period-enabled: true
Enables or disables ignoring the weak subjectivity period
verification that Teku performs at startup.
The default is false
.
Syncing from outside the weak subjectivity period is considered unsafe.
initial-state
- Syntax
- Example
- Environment variable
- Configuration file
--initial-state=<FILE>
--initial-state=/home/me/genesis.ssz
TEKU_INITIAL_STATE=/home/me/genesis.ssz
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
option.
If overriding the initial state in a custom network, you must supply the initial state file at each restart.
log-color-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--log-color-enabled[=<BOOLEAN>]
--log-color-enabled=false
TEKU_LOG_COLOR_ENABLED=false
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
- Syntax
- Example
- Environment variable
- Configuration file
--log-destination=<LOG_DESTINATION>
--log-destination=CONSOLE
TEKU_LOG_DESTINATION=CONSOLE
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
command-line option.
In production environments, we recommend using the CONSOLE
or FILE
options to ensure all log
information is available in one place.
Use DEFAULT_BOTH
when using a
custom Log4J2 configuration file.
Any other option applies the custom logging changes on top of its default settings.
log-file
- Syntax
- Example
- Environment variable
- Configuration file
--log-file=<FILENAME>
--log-file=teku_2020-01-01.log
TEKU_LOG_FILE=teku_2020-01-01.log
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
- Syntax
- Example
- Environment variable
- Configuration file
--log-file-name-pattern=<REGEX>
--log-file-name-pattern=tekuL_%d{yyyy-MM-dd}.log
TEKU_LOG_FILE_NAME_PATTERN=tekuL_%d{yyyy-MM-dd}.log
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
- Syntax
- Example
- Environment variable
- Configuration file
--log-include-events-enabled[=<BOOLEAN>]
--log-include-events-enabled=false
TEKU_LOG_INCLUDE_EVENTS_ENABLED=false
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
- Syntax
- Example
- Environment variable
- Configuration file
--log-include-validator-duties-enabled[=<BOOLEAN>]
--log-include-validator-duties-enabled=false
TEKU_LOG_INCLUDE_VALIDATOR_DUTIES_ENABLED=false
log-include-validator-duties-enabled: false
Enables or disables logging details of validator event duties.
The default is true
.
Logs could become noisy when running many validators.
logging
- Syntax
- Example
- Environment variable
- Configuration file
-l, --logging=<LEVEL>
--logging=DEBUG
TEKU_LOGGING=DEBUG
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
- Syntax
- Example
- Environment variable
- Configuration file
--metrics-block-timing-tracking-enabled[=<BOOLEAN>]
--metrics-block-timing-tracking-enabled=false
TEKU_METRICS_BLOCK_TIMING_TRACKING_ENABLED=false
metrics-block-timing-tracking-enabled: false
Enables or disables block timing metrics. The default is true
.
metrics-categories
- Syntax
- Example
- Environment variable
- Configuration file
--metrics-categories=<CATEGORY>[,<CATEGORY>...]...
--metrics-categories=BEACON,JVM,PROCESS
TEKU_METRICS_CATEGORIES=BEACON,JVM,PROCESS
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
- Syntax
- Example
- Environment variable
- Configuration file
--metrics-enabled[=<BOOLEAN>]
--metrics-enabled=true
TEKU_METRICS_ENABLED=true
metrics-enabled: true
Enables or disables the metrics exporter. The default is false
.
metrics-host-allowlist
- Syntax
- Example
- Environment variable
- Configuration file
--metrics-host-allowlist=<hostname>[,<hostname>...]... or "*"
--metrics-host-allowlist=medomain.com,meotherdomain.com
TEKU_METRICS_HOST_ALLOWLIST=medomain.com,meotherdomain.com
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
.
To allow all hostnames, use "*"
.
We don't recommend allowing all hostnames for production environments.
metrics-interface
- Syntax
- Example
- Environment variable
- Configuration file
--metrics-interface=<HOST>
--metrics-interface=192.168.10.101
TEKU_METRICS_INTERFACE=192.168.10.101
metrics-interface: "192.168.10.101"
The host on which Prometheus accesses Teku metrics. The default is 127.0.0.1
.
metrics-port
- Syntax
- Example
- Environment variable
- Configuration file
--metrics-port=<PORT>
--metrics-port=6174
TEKU_METRICS_PORT=6174
metrics-port: 6174
The port (TCP) on which Prometheus accesses Teku metrics.
The default is 8008
.
metrics-publish-endpoint
- Syntax
- Example
- Environment variable
- Configuration file
--metrics-publish-endpoint=<URL>
--metrics-publish-endpoint=https://beaconcha.in/api/v1/client/metrics?apikey={apikey}
TEKU_METRICS_PUBLISH_ENDPOINT=https://beaconcha.in/api/v1/client/metrics?apikey={apikey}
metrics-publish-endpoint: "https://beaconcha.in/api/v1/client/metrics?apikey={apikey}"
The endpoint URL of an external service such as beaconcha.in to which Teku publishes metrics for node monitoring.
metrics-publish-interval
- Syntax
- Example
- Environment variable
- Configuration file
--metrics-publish-interval=<INTEGER>
--metrics-publish-interval=60
TEKU_METRICS_PUBLISH_INTERVAL=60
metrics-publish-interval: "60"
The interval between metric publications to the external service defined in
metrics-publish-endpoint, measured in seconds.
The default is 60
.
network
- Syntax
- Example
- Environment variable
- Configuration file
--network=<NETWORK>
--network=mainnet
TEKU_NETWORK=mainnet
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 |
holesky | Consensus layer | Test | Multi-client testnet |
sepolia | Consensus layer | Test | Multi-client testnet |
chiado | Consensus layer | Test | Gnosis testnet |
lukso | Consensus layer | Production | Network for the Lukso chain |
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
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-advertised-ip=<IP_ADDRESS>
--p2p-advertised-ip=192.168.1.132
TEKU_P2P_ADVERTISED_IP=192.168.1.132
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.
The default address is 127.0.0.1
.
p2p-advertised-port
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-advertised-port=<PORT>
--p2p-advertised-port=1789
TEKU_P2P_ADVERTISED_PORT=1789
p2p-advertised-port: 1789
The P2P port to advertise.
The default is the port specified in --p2p-port
.
The advertised port can differ from the --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
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-advertised-port-ipv6=<PORT>
--p2p-advertised-port-ipv6=1790
TEKU_P2P_ADVERTISED_PORT_IPV6=1790
p2p-advertised-port-ipv6: 1790
The P2P IPv6 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-advertised-udp-port
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-advertised-udp-port=<PORT>
--p2p-advertised-udp-port=1789
TEKU_P2P_ADVERTISED_UDP_PORT=1789
p2p-advertised-udp-port: 1789
The UDP port to advertise to external peers.
The default is the port specified in --p2p-advertised-port
if it is set.
Otherwise, the default is the port specified in --p2p-port
.
p2p-advertised-udp-port-ipv6
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-advertised-udp-port-ipv6=<PORT>
--p2p-advertised-udp-port-ipv6=1790
TEKU_P2P_ADVERTISED_UDP_PORT_IPV6=1790
p2p-advertised-udp-port-ipv6: 1790
The IPv6 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
if it is set.
Otherwise, the default is the port specified in --p2p-port-ipv6
.
p2p-direct-peers
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-direct-peers=<ADDRESS>[,<ADDRESS>...]...
--p2p-direct-peers=/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz,/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1
TEKU_P2P_DIRECT_PEERS=/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz,/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1
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 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
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-discovery-bootnodes=<ENR_ADDRESS>[,<ENR_ADDRESS>...]...
--p2p-discovery-bootnodes=enr:-Iu4QG...wgiMo,enr:-Iu4QL...wgiMo
TEKU_P2P_DISCOVERY_BOOTNODES=enr:-Iu4QG...wgiMo,enr:-Iu4QL...wgiMo
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
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-discovery-enabled[=<BOOLEAN>]
--p2p-discovery-enabled=false
TEKU_P2P_DISCOVERY_ENABLED=false
p2p-discovery-enabled: false
Enables or disables P2P peer discovery.
If disabled, p2p-static-peers
defines the peer connections.
The default is true
.
p2p-discovery-site-local-addresses-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-discovery-site-local-addresses-enabled[=<BOOLEAN>]
--p2p-discovery-site-local-addresses-enabled
TEKU_P2P_DISCOVERY_SITE_LOCAL_ADDRESSES_ENABLED=true
p2p-discovery-site-local-addresses-enabled: true
Enables or disables discovery of the following local network (RFC1918) addresses.
The default is false
.
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
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-enabled[=<BOOLEAN>]
--p2p-enabled=false
TEKU_P2P_ENABLED=false
p2p-enabled: false
Enables or disables all P2P communication. The default is true
.
p2p-interface
, p2p-interfaces
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-interface=<HOST>
--p2p-interface=192.168.1.132
TEKU_P2P_INTERFACE=192.168.1.132
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
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-nat-method=<STRING>
--p2p-nat-method=UPNP
TEKU_P2P_NAT_METHOD=UPNP
p2p-nat-method: "UPNP"
The method for handling NAT environments.
Valid options are NONE
and UPNP
.
The default is NONE
, which disables NAT functionality.
UPnP support is often disabled by default in networking firmware. If disabled by default, explicitly enable UPnP support.
p2p-peer-lower-bound
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-peer-lower-bound=<INTEGER>
--p2p-peer-lower-bound=25
TEKU_P2P_PEER_LOWER_BOUND=25
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
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-peer-upper-bound=<INTEGER>
--p2p-peer-upper-bound=40
TEKU_P2P_PEER_UPPER_BOUND=40
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
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-port=<PORT>
# to listen on port 1789
--p2p-port=1789
# to listen on port 1789
TEKU_P2P_PORT=1789
p2p-port: 1789
The P2P listening ports (UDP and TCP). The default is 9000
.
p2p-port-ipv6
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-port-ipv6=<PORT>
# to listen on port 1790
--p2p-port-ipv6=1790
# to listen on port 1790
TEKU_P2P_PORT_IPV6=1790
p2p-port-ipv6: 1790
The P2P listening ports (UDP and TCP) for IPv6
when listening over both IPv4 and IPv6.
The default is 9090
.
p2p-private-key-file
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-private-key-file=<PATH_TO_FILE>
--p2p-private-key-file=/home/me/me_node/key
TEKU_P2P_PRIVATE_KEY_FILE=/home/me/me_node/key
p2p-private-key-file: "/home/me/me_node/key"
The file containing the node's private key.
If a file doesn't exist at the specified path, Teku creates a new file and P2P private key to store inside.
Ensure you specify the complete file path, including the file name, and not only the directory location.
p2p-static-peers
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-static-peers=<ADDRESS>[,<ADDRESS>...]...
--p2p-static-peers=/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz,/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1
TEKU_P2P_STATIC_PEERS=/ip4/151.150.191.80/tcp/9000/p2p/16Ui...aXRz,/ip4/151.150.191.80/tcp/9000/p2p/16Ui...q6f1
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 of static peers with which to establish and maintain connections.
p2p-subscribe-all-subnets-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-subscribe-all-subnets-enabled=<BOOLEAN>
--p2p-subscribe-all-subnets-enabled=true
TEKU_P2P_SUBSCRIBE_ALL_SUBNETS_ENABLED=true
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.
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
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-udp-port=<PORT>
--p2p-udp-port=1789
TEKU_P2P_UDP_PORT=1789
p2p-udp-port: 1789
The UDP port used for discovery. The default is the port specified in --p2p-port
.
p2p-udp-port-ipv6
- Syntax
- Example
- Environment variable
- Configuration file
--p2p-udp-port-ipv6=<PORT>
--p2p-udp-port-ipv6=1790
TEKU_P2P_UDP_PORT_IPV6=1790
p2p-udp-port-ipv6: 1790
The IPv6 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
.
reconstruct-historic-states
- Syntax
- Example
- Environment variable
- Configuration file
--reconstruct-historic-states=<BOOLEAN>
--reconstruct-historic-states=true
TEKU_RECONSTRUCT_HISTORIC_STATES=true
reconstruct-historic-states: true
Enables or disables reconstructing historical states.
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
- Syntax
- Example
- Environment variable
- Configuration file
--rest-api-cors-origins[=<url>[,<url>...]...] or "*"
--rest-api-cors-origins="http://medomain.com","https://meotherdomain.com"
TEKU_REST_API_CORS_ORIGINS="http://medomain.com","https://meotherdomain.com"
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.
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
- Syntax
- Example
- Environment variable
- Configuration file
--rest-api-docs-enabled[=<BOOLEAN>]
--rest-api-docs-enabled=true
TEKU_REST_API_DOCS_ENABLED=true
rest-api-docs-enabled: true
Enables or disables the REST API documentation. The default is false
.
The documentation can be accessed at http://<interface>:<port>/swagger-ui
where:
interface
is specified using--rest-api-interface
port
is specified using--rest-api-port
rest-api-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--rest-api-enabled[=<BOOLEAN>]
--rest-api-enabled=true
TEKU_REST_API_ENABLED=true
rest-api-enabled: true
Enables or disables the REST API service.
The default is false
.
If set to true
, use --rest-api-host-allowlist
to limit access to
trusted parties.
rest-api-host-allowlist
- Syntax
- Example
- Environment variable
- Configuration file
--rest-api-host-allowlist=<hostname>[,<hostname>...]... or "*"
--rest-api-host-allowlist=localhost,127.0.0.1,10.0.0.1
TEKU_REST_API_HOST_ALLOWLIST=localhost,127.0.0.1,10.0.0.1
rest-api-host-allowlist: ["localhost", "127.0.0.1", "10.0.0.1"]
A comma-separated list of hostnames or IP addresses from which the REST API server will respond. This flag restricts the server's responding addresses, but not the client access.
By default, Teku's REST API server responds only to requests where the Host
header matches localhost
or 127.0.0.1
.
If you specify values, the server will only respond to requests where the Host
header matches one of the specified hosts or IP addresses.
You can configure the API to listen on all network interfaces using rest-api-interface="0.0.0.0"
and allow connections from specific addresses by setting rest-api-host-allowlist
.
See configure the API for network interfaces and host allowlist
for more information.
To allow all hostnames, use "*". We don't recommend allowing all hostnames for production environments.
Only trusted parties should access the REST API. Do not directly expose these APIs publicly on production nodes.
rest-api-interface
- Syntax
- Example
- Environment variable
- Configuration file
--rest-api-interface=<HOST>
# to listen on all interfaces
--rest-api-interface=0.0.0.0
TEKU_REST_API_INTERFACE=0.0.0.0
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
- Syntax
- Example
- Environment variable
- Configuration file
--rest-api-port=<PORT>
# to listen on port 3435
--rest-api-port=3435
TEKU_REST_API_PORT=3435
rest-api-port: 3435
The REST API listening port (HTTP). The default is 5051
.
sentry-config-file
- Syntax
- Example
- Environment variable
- Configuration file
--sentry-config-file=<FILE>
--sentry-config-file=/etc/sentry-node-config.json
TEKU_SENTRY_CONFIG_FILE=/etc/sentry-node-config.json
sentry-config-file: "/etc/sentry-node-config.json"
The path to the sentry node configuration file.
The default is none
.
You can't use this option with
--beacon-node-api-endpoint
.
shut-down-when-validator-slashed-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--shut-down-when-validator-slashed-enabled[=<BOOLEAN>]
--shut-down-when-validator-slashed-enabled=true
TEKU_SHUT_DOWN_WHEN_VALIDATOR_SLASHED_ENABLED=true
shut-down-when-validator-slashed-enabled: true
Enables or disables validators slashing detection.
The default is false
.
validator-api-cors-origins
- Syntax
- Example
- Environment variable
- Configuration file
--validator-api-cors-origins="<URL>"[,"<URL>",...] or "*"
--validator-api-cors-origins="http://medomain.com","https://meotherdomain.com"
TEKU_VALIDATOR_API_CORS_ORIGINS="http://medomain.com","https://meotherdomain.com"
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.
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
- Syntax
- Example
- Environment variable
- Configuration file
--validator-api-docs-enabled[=<BOOLEAN>]
--validator-api-docs-enabled=true
TEKU_VALIDATOR_API_DOCS_ENABLED=true
validator-api-docs-enabled: true
Enables or disables the validator REST API documentation.
The default is false
.
When enabling the API documentation endpoint, you must also specify:
interface
by using--validator-api-interface
.port
by using--validator-api-port
.
validator-api-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--validator-api-enabled[=<BOOLEAN>]
--validator-api-enabled=true
TEKU_VALIDATOR_API_ENABLED=true
validator-api-enabled: true
Set to true
to enable the validator client API.
The default is false
.
If set to true
, then use --validator-api-host-allowlist
to
limit access to trusted parties.
validator-api-host-allowlist
- Syntax
- Example
- Environment variable
- Configuration file
--validator-api-host-allowlist=<hostname>[,<hostname>...]... or "*"
--validator-api-host-allowlist=medomain.com,meotherdomain.com
TEKU_VALIDATOR_API_HOST_ALLOWLIST=medomain.com,meotherdomain.com
validator-api-host-allowlist: ["medomain.com", "meotherdomain.com"]
A comma-separated list of hostnames to allow access to the
validator REST API.
By default, Teku accepts access from localhost
and 127.0.0.1
.
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
- Syntax
- Example
- Environment variable
- Configuration file
--validator-api-interface=<HOST>
# to listen on all interfaces
--validator-api-interface=0.0.0.0
TEKU_VALIDATOR_API_INTERFACE=0.0.0.0
validator-api-interface: "0.0.0.0"
The interface on which the validator REST API listens.
The default is 127.0.0.1
.
validator-api-keystore-file
- Syntax
- Example
- Environment variable
- Configuration file
--validator-api-keystore-file=<keystoreFile>
--validator-api-keystore-file=validator_keystorstore.p12
TEKU_VALIDATOR_API_KEYSTORE_FILE=validator_keystore.p12
validator-api-keystore-file: "validator_keystore.p12"
The keystore file for the validator REST API. Teku can use PKCS12 or JKS keystore types. You must create a keystore to enable access.
validator-api-keystore-password-file
- Syntax
- Example
- Environment variable
- Configuration file
--validator-api-keystore-password-file=<keystorePasswordFile>
--validator-api-keystore-password-file=validator_keystore_pass.txt
TEKU_VALIDATOR_API_KEYSTORE_PASSWORD_FILE=validator_keystore_pass.txt
validator-api-keystore-password-file: "validator_keystore_pass.txt"
The password used to decrypt the keystore for the validator REST API.
validator-api-port
- Syntax
- Example
- Environment variable
- Configuration file
--validator-api-port=<PORT>
--validator-api-port=5052
TEKU_VALIDATOR_API_PORT=5052
validator-api-port: 5052
The validator REST API listening port (HTTP).
The default is 5052
.
validators-builder-registration-default-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--validators-builder-registration-default-enabled[=<BOOLEAN>]
--validators-builder-registration-default-enabled=true
TEKU_VALIDATORS_BUILDER_REGISTRATION_DEFAULT_ENABLED=true
validators-builder-registration-default-enabled: true
Enables or disables registering all validators managed by the validator client to the builder endpoint when proposing a block.
validators-early-attestations-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--validators-early-attestations-enabled[=<BOOLEAN>]
--validators-early-attestations-enabled=false
TEKU_VALIDATORS_EARLY_ATTESTATIONS_ENABLED=false
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.
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
- Syntax
- Example
- Environment variable
- Configuration file
--validators-external-signer-keystore=<FILE>
--validators-external-signer-keystore=teku_client_keystore.p12
TEKU_VALIDATORS_EXTERNAL_KEYSTORE=teku_client_keystore.p12
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
- Syntax
- Example
- Environment variable
- Configuration file
--validators-external-signer-keystore-password-file=<FILE>
--validators-external-signer-keystore-password-file=keystore_pass.txt
TEKU_VALIDATORS_EXTERNAL_KEYSTORE_PASSWORD_FILE=keystore_pass.txt
validators-external-signer-keystore-password-file: "keystore_pass.txt"
The password file used to decrypt the keystore.
validators-external-signer-public-keys
- Syntax
- Example
- Environment variable
- Configuration file
--validators-external-signer-public-keys=<KEY>[,<KEY>...]
--validators-external-signer-public-keys=0xa99a...e44c,0xb89b...4a0b
TEKU_VALIDATORS_EXTERNAL_SIGNER_PUBLIC_KEYS=0xa99a...e44c,0xb89b...4a0b
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:
--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.
--validators-external-signer-public-keys=external-signer
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
- Syntax
- Example
- Environment variable
- Configuration file
--validators-external-signer-slashing-protection-enabled[=<BOOLEAN>]
--validators-external-signer-slashing-protection-enabled=false
TEKU_VALIDATORS_EXTERNAL_SIGNER_SLASHING_PROTECTION_ENABLED=false
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.
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
- Syntax
- Example
- Environment variable
- Configuration file
--validators-external-signer-timeout=<INTEGER>
--validators-external-signer-timeout=2000
TEKU_VALIDATORS_EXTERNAL_SIGNER_TIMEOUT=2000
validators-external-signer-timeout: 2000
The timeout in milliseconds for requests to the external signer. The default is 5000
.
validators-external-signer-truststore
- Syntax
- Example
- Environment variable
- Configuration file
--validators-external-signer-truststore=<FILE>
--validators-external-signer-truststore=websigner_truststore.p12
TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE=websigner_truststore.p12
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
- Syntax
- Example
- Environment variable
- Configuration file
--validators-external-signer-truststore-password-file=<FILE>
--validators-external-signer-truststore-password-file=truststore_pass.txt
TEKU_VALIDATORS_EXTERNAL_TRUSTSTORE_PASSWORD_FILE=truststore_pass.txt
validators-external-signer-truststore-password-file: "truststore_pass.txt"
The password file used to decrypt the keystore.
validators-external-signer-url
- Syntax
- Example
- Environment variable
- Configuration file
--validators-external-signer-url=<URL>
--validators-external-signer-url=http://localhost:9000
TEKU_VALIDATORS_EXTERNAL_SIGNER_URL=http://localhost:9000
validators-external-signer-url: "http://localhost:9000"
The URL on which the external signer (for example, Web3Signer) is running.
validators-graffiti
- Syntax
- Example
- Environment variable
- Configuration file
--validators-graffiti=<STRING>
--validators-graffiti="Teku validator"
TEKU_VALIDATORS_GRAFFITI="Teku validator"
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
takes precedence if both options are set.
validators-graffiti-file
- Syntax
- Example
- Environment variable
- Configuration file
--validators-graffiti-file=<FILE>
--validators-graffiti-file=/Users/me/mynode/graffiti.txt
TEKU_VALIDATORS_GRAFFITI_FILE=/Users/me/mynode/graffiti.txt
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-client-append-format
- Syntax
- Example
- Environment variable
- Configuration file
--validators-graffiti-client-append-format=<STRING>
--validators-graffiti-client-append-format=CLIENT_CODES
TEKU_VALIDATORS_GRAFFITI_CLIENT_APPEND_FORMAT=CLIENT_CODES
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 toIt's my first block TK50BUbb
. -
CLIENT_CODES
: Appends only CL/EL client codes such asTKBU
. 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
- Syntax
- Example
- Environment variable
- Configuration file
--validator-is-local-slashing-protection-synchronized-enabled[=<BOOLEAN>]
--validator-is-local-slashing-protection-synchronized-enabled=true
TEKU_VALIDATOR_IS_LOCAL_SLASHING_PROTECTION_SYNCHRONIZED_ENABLED=true
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
- Syntax
- Example for directory
- Example for file
- Environment variable
- Configuration file
--validator-keys=<KEY_DIR>:<PASS_DIR> | <KEY_FILE>:<PASS_FILE>[,<KEY_DIR>:<PASS_DIR> | <KEY_FILE>:<PASS_FILE>...]...
--validator-keys=/home/validator/keys:home/validator/passwords
--validator-keys=/home/validator/keys/validator_217179e.json:/home/validator/passwords/validator_217179e.txt
TEKU_VALIDATOR_KEYS=/home/validator/keys:home/validator/passwords
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
.
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.
The path separator is operating system dependent, and should be ;
in Windows rather than :
.
validators-keystore-locking-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--validators-keystore-locking-enabled=<BOOLEAN>
--validators-keystore-locking-enabled=true
TEKU_VALIDATORS_KEYSTORE_LOCKING_ENABLED=true
validators-keystore-locking-enabled: true
Enables or disables locking the keystore files listed in --validator-keys
.
The default is true
.
Attempts to lock all keystores in a directory if a directory is specified in --validator-keys
.
validators-performance-tracking-mode
- Syntax
- Example
- Environment variable
- Configuration file
--validators-performance-tracking-mode=<STRING>
--validators-performance-tracking-mode=LOGGING
TEKU_VALIDATORS_PERFORMANCE_TRACKING_MODE=LOGGING
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 category.
validators-proposer-blinded-blocks-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--validators-proposer-blinded-blocks-enabled[=<BOOLEAN>]
--validators-proposer-blinded-blocks-enabled=true
TEKU_VALIDATORS_PROPOSER_BLINDED_BLOCKS_ENABLED=true
validators-proposer-blinded-blocks-enabled: true
Enables or disables blinded blocks production, a prerequisite for the
builder network.
When --validators-builder-registration-default-enabled
is enabled, this option is enabled automatically.
The default is false
.
validators-proposer-config
- Syntax
- Example
- Environment variable
- Configuration file
--validators-proposer-config=<STRING>
--validators-proposer-config=/home/me/node/proposerConfig.json
TEKU_VALIDATORS_PROPOSER_CONFIG=/home/me/node/proposerConfig.json
validators-proposer-config: "/home/me/node/proposerConfig.json"
The remote URL or local file path to the proposer configuration file.
validators-proposer-config-refresh-enabled
- Syntax
- Example
- Environment variable
- Configuration file
--validators-proposer-config-refresh-enabled[=<BOOLEAN>]
--validators-proposer-config-refresh-enabled=true
TEKU_VALIDATORS_PROPOSER_CONFIG_REFRESH_ENABLED=true
validators-proposer-config-refresh-enabled: true
Enables or disables reloading the
proposer configuration on every proposer
preparation (once per epoch).
The default is false
.
validators-proposer-default-fee-recipient
- Syntax
- Example
- Environment variable
- Configuration file
--validators-proposer-default-fee-recipient=<ADDRESS>
--validators-proposer-default-fee-recipient=0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73
TEKU_VALIDATORS_PROPOSER_DEFAULT_FEE_RECIPIENT=0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73
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.
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
-V, --version
Displays the version and exits.
ws-checkpoint
- Syntax
- Example
- Environment variable
- Configuration file
--ws-checkpoint=<BLOCK_ROOT>:<EPOCH_NUMBER>
--ws-checkpoint=0x5a642bb8f367e98c0d11426d98d28c465f8988fc960500886cb49faf0372883a:3600
TEKU_WS_CHECKPOINT=0x5a642bb8f367e98c0d11426d98d28c465f8988fc960500886cb49faf0372883a:3600
ws-checkpoint: "0x5a642bb8f367e98c0d11426d98d28c465f8988fc960500886cb49faf0372883a:3600"
A recent checkpoint within the weak subjectivity period.
Accepts the checkpoint using <blockRoot>:<epochNumber>
, where <blockRoot>
must start with 0x
.
The weak subjectivity checkpoint is a recent, finalized checkpoint on the correct chain. By supplying a weak subjectivity checkpoint, you ensure that nodes that have been offline for a long period follow the correct chain. It protects the node from long-range attacks by malicious actors.
Use the admin weak-subjectivity
subcommand to display or
clear your weak subjectivity settings.