sigp · mergify · May 14, 2025 · May 14, 2025 · May 14, 2025 · May 14, 2025
diff --git a/book/src/advanced_database_migrations.md b/book/src/advanced_database_migrations.md
@@ -125,7 +125,7 @@ Several conditions need to be met in order to run `lighthouse db`:
 2. The command must run as the user that owns the beacon node database. If you are using systemd then
    your beacon node might run as a user called `lighthousebeacon`.
 3. The `--datadir` flag must be set to the location of the Lighthouse data directory.
-4. The `--network` flag must be set to the correct network, e.g. `mainnet`, `holesky` or `sepolia`.
+4. The `--network` flag must be set to the correct network, e.g. `mainnet`, `hoodi` or `sepolia`.
 
 The general form for a `lighthouse db` command is:
 

diff --git a/book/src/advanced_release_candidates.md b/book/src/advanced_release_candidates.md
@@ -40,4 +40,4 @@ There can also be a scenario that a bug has been found and requires an urgent fi
 
 ## When *not* to use a release candidate
 
-Other than the above scenarios, it is generally not recommended to use release candidates for any critical tasks on mainnet (e.g., staking). To test new release candidate features, try one of the testnets (e.g., Holesky).
+Other than the above scenarios, it is generally not recommended to use release candidates for any critical tasks on mainnet (e.g., staking). To test new release candidate features, try one of the testnets (e.g., Hoodi).
diff --git a/book/src/advanced_web3signer.md b/book/src/advanced_web3signer.md
@@ -56,3 +56,11 @@ SSL client authentication with the "self-signed" certificate in `/home/paul/my-k
 > with a new timeout in milliseconds. This is the timeout before requests to Web3Signer are
 > considered to be failures. Setting a value that is too long may create contention and late duties
 > in the VC.  Setting it too short will result in failed signatures and therefore missed duties.
+
+## Slashing protection database
+
+Web3signer can be configured with its own slashing protection database. This makes the local slashing protection database by Lighthouse redundant. To disable Lighthouse slashing protection database for web3signer keys, use the flag `--disable-slashing-protection-web3signer` on the validator client.
+
+> Note: DO NOT use this flag unless you are certain that slashing protection is enabled on web3signer.
+
+The `--init-slashing-protection` flag is also required to initialize the slashing protection database locally.
diff --git a/book/src/api_vc_auth_header.md b/book/src/api_vc_auth_header.md
@@ -32,7 +32,7 @@ When starting the validator client it will output a log message containing the p
 to the file containing the api token.
 
 ```text
-Sep 28 19:17:52.615 INFO HTTP API started                        api_token_file: "$HOME/holesky/validators/api-token.txt", listen_address: 127.0.0.1:5062
+Sep 28 19:17:52.615 INFO HTTP API started                        api_token_file: "$HOME/hoodi/validators/api-token.txt", listen_address: 127.0.0.1:5062
 ```
 
 The _path_ to the API token may also be fetched from the HTTP API itself (this endpoint is the only
@@ -46,7 +46,7 @@ Response:
 
 ```json
 {
-    "token_path": "/home/karlm/.lighthouse/holesky/validators/api-token.txt"
+    "token_path": "/home/karlm/.lighthouse/hoodi/validators/api-token.txt"
 }
 ```
 

diff --git a/book/src/api_vc_endpoints.md b/book/src/api_vc_endpoints.md
@@ -226,36 +226,70 @@ Example Response Body
 ```json
 {
   "data": {
-    "CONFIG_NAME": "holesky",
+    "CONFIG_NAME": "hoodi",
     "PRESET_BASE": "mainnet",
-    "TERMINAL_TOTAL_DIFFICULTY": "10790000",
+    "TERMINAL_TOTAL_DIFFICULTY": "0",
     "TERMINAL_BLOCK_HASH": "0x0000000000000000000000000000000000000000000000000000000000000000",
     "TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH": "18446744073709551615",
     "MIN_GENESIS_ACTIVE_VALIDATOR_COUNT": "16384",
-    "MIN_GENESIS_TIME": "1614588812",
-    "GENESIS_FORK_VERSION": "0x00001020",
-    "GENESIS_DELAY": "1919188",
-    "ALTAIR_FORK_VERSION": "0x01001020",
-    "ALTAIR_FORK_EPOCH": "36660",
-    "BELLATRIX_FORK_VERSION": "0x02001020",
-    "BELLATRIX_FORK_EPOCH": "112260",
-    "CAPELLA_FORK_VERSION": "0x03001020",
-    "CAPELLA_FORK_EPOCH": "162304",
+    "MIN_GENESIS_TIME": "1742212800",
+    "GENESIS_FORK_VERSION": "0x10000910",
+    "GENESIS_DELAY": "600",
+    "ALTAIR_FORK_VERSION": "0x20000910",
+    "ALTAIR_FORK_EPOCH": "0",
+    "BELLATRIX_FORK_VERSION": "0x30000910",
+    "BELLATRIX_FORK_EPOCH": "0",
+    "CAPELLA_FORK_VERSION": "0x40000910",
+    "CAPELLA_FORK_EPOCH": "0",
+    "DENEB_FORK_VERSION": "0x50000910",
+    "DENEB_FORK_EPOCH": "0",
+    "ELECTRA_FORK_VERSION": "0x60000910",
+    "ELECTRA_FORK_EPOCH": "2048",
+    "FULU_FORK_VERSION": "0x70000910",
+    "FULU_FORK_EPOCH": "18446744073709551615",
     "SECONDS_PER_SLOT": "12",
-    "SECONDS_PER_ETH1_BLOCK": "14",
+    "SECONDS_PER_ETH1_BLOCK": "12",
     "MIN_VALIDATOR_WITHDRAWABILITY_DELAY": "256",
     "SHARD_COMMITTEE_PERIOD": "256",
     "ETH1_FOLLOW_DISTANCE": "2048",
+    "SUBNETS_PER_NODE": "2",
     "INACTIVITY_SCORE_BIAS": "4",
     "INACTIVITY_SCORE_RECOVERY_RATE": "16",
     "EJECTION_BALANCE": "16000000000",
     "MIN_PER_EPOCH_CHURN_LIMIT": "4",
     "MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT": "8",
     "CHURN_LIMIT_QUOTIENT": "65536",
     "PROPOSER_SCORE_BOOST": "40",
-    "DEPOSIT_CHAIN_ID": "5",
-    "DEPOSIT_NETWORK_ID": "5",
-    "DEPOSIT_CONTRACT_ADDRESS": "0xff50ed3d0ec03ac01d4c79aad74928bff48a7b2b",
+    "DEPOSIT_CHAIN_ID": "560048",
+    "DEPOSIT_NETWORK_ID": "560048",
+    "DEPOSIT_CONTRACT_ADDRESS": "0x00000000219ab540356cbb839cbe05303d7705fa",
+    "GAS_LIMIT_ADJUSTMENT_FACTOR": "1024",
+    "MAX_PAYLOAD_SIZE": "10485760",
+    "MAX_REQUEST_BLOCKS": "1024",
+    "MIN_EPOCHS_FOR_BLOCK_REQUESTS": "33024",
+    "TTFB_TIMEOUT": "5",
+    "RESP_TIMEOUT": "10",
+    "ATTESTATION_PROPAGATION_SLOT_RANGE": "32",
+    "MAXIMUM_GOSSIP_CLOCK_DISPARITY_MILLIS": "500",
+    "MESSAGE_DOMAIN_INVALID_SNAPPY": "0x00000000",
+    "MESSAGE_DOMAIN_VALID_SNAPPY": "0x01000000",
+    "ATTESTATION_SUBNET_PREFIX_BITS": "6",
+    "MAX_REQUEST_BLOCKS_DENEB": "128",
+    "MAX_REQUEST_BLOB_SIDECARS": "768",
+    "MAX_REQUEST_DATA_COLUMN_SIDECARS": "16384",
+    "MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS": "4096",
+    "BLOB_SIDECAR_SUBNET_COUNT": "6",
+    "MAX_BLOBS_PER_BLOCK": "6",
+    "MIN_PER_EPOCH_CHURN_LIMIT_ELECTRA": "128000000000",
+    "MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT": "256000000000",
+    "MAX_BLOBS_PER_BLOCK_ELECTRA": "9",
+    "BLOB_SIDECAR_SUBNET_COUNT_ELECTRA": "9",
+    "MAX_REQUEST_BLOB_SIDECARS_ELECTRA": "1152",
+    "NUMBER_OF_COLUMNS": "128",
+    "NUMBER_OF_CUSTODY_GROUPS": "128",
+    "DATA_COLUMN_SIDECAR_SUBNET_COUNT": "128",
+    "SAMPLES_PER_SLOT": "8",
+    "CUSTODY_REQUIREMENT": "4",
     "MAX_COMMITTEES_PER_SLOT": "64",
     "TARGET_COMMITTEE_SIZE": "128",
     "MAX_VALIDATORS_PER_COMMITTEE": "2048",
@@ -304,23 +338,45 @@ Example Response Body
     "MAX_BLS_TO_EXECUTION_CHANGES": "16",
     "MAX_WITHDRAWALS_PER_PAYLOAD": "16",
     "MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP": "16384",
+    "MAX_BLOB_COMMITMENTS_PER_BLOCK": "4096",
+    "FIELD_ELEMENTS_PER_BLOB": "4096",
+    "MIN_ACTIVATION_BALANCE": "32000000000",
+    "MAX_EFFECTIVE_BALANCE_ELECTRA": "2048000000000",
+    "MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA": "4096",
+    "WHISTLEBLOWER_REWARD_QUOTIENT_ELECTRA": "4096",
+    "PENDING_DEPOSITS_LIMIT": "134217728",
+    "PENDING_PARTIAL_WITHDRAWALS_LIMIT": "134217728",
+    "PENDING_CONSOLIDATIONS_LIMIT": "262144",
+    "MAX_ATTESTER_SLASHINGS_ELECTRA": "1",
+    "MAX_ATTESTATIONS_ELECTRA": "8",
+    "MAX_DEPOSIT_REQUESTS_PER_PAYLOAD": "8192",
+    "MAX_WITHDRAWAL_REQUESTS_PER_PAYLOAD": "16",
+    "MAX_CONSOLIDATION_REQUESTS_PER_PAYLOAD": "2",
+    "MAX_PENDING_PARTIALS_PER_WITHDRAWALS_SWEEP": "8",
+    "MAX_PENDING_DEPOSITS_PER_EPOCH": "16",
+    "FIELD_ELEMENTS_PER_CELL": "64",
+    "FIELD_ELEMENTS_PER_EXT_BLOB": "8192",
+    "KZG_COMMITMENTS_INCLUSION_PROOF_DEPTH": "4",
+    "DOMAIN_BEACON_PROPOSER": "0x00000000",
+    "DOMAIN_CONTRIBUTION_AND_PROOF": "0x09000000",
     "DOMAIN_DEPOSIT": "0x03000000",
-    "BLS_WITHDRAWAL_PREFIX": "0x00",
-    "RANDOM_SUBNETS_PER_VALIDATOR": "1",
-    "DOMAIN_SYNC_COMMITTEE": "0x07000000",
+    "DOMAIN_SELECTION_PROOF": "0x05000000",
+    "VERSIONED_HASH_VERSION_KZG": "1",
     "TARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEE": "16",
-    "DOMAIN_BEACON_ATTESTER": "0x01000000",
     "DOMAIN_VOLUNTARY_EXIT": "0x04000000",
+    "BLS_WITHDRAWAL_PREFIX": "0x00",
+    "DOMAIN_APPLICATION_MASK": "0x00000001",
     "DOMAIN_SYNC_COMMITTEE_SELECTION_PROOF": "0x08000000",
-    "DOMAIN_CONTRIBUTION_AND_PROOF": "0x09000000",
-    "EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION": "256",
+    "DOMAIN_SYNC_COMMITTEE": "0x07000000",
+    "COMPOUNDING_WITHDRAWAL_PREFIX": "0x02",
     "TARGET_AGGREGATORS_PER_COMMITTEE": "16",
-    "DOMAIN_APPLICATION_MASK": "0x00000001",
+    "SYNC_COMMITTEE_SUBNET_COUNT": "4",
+    "DOMAIN_BEACON_ATTESTER": "0x01000000",
+    "UNSET_DEPOSIT_REQUESTS_START_INDEX": "18446744073709551615",
+    "FULL_EXIT_REQUEST_AMOUNT": "0",
     "DOMAIN_AGGREGATE_AND_PROOF": "0x06000000",
-    "DOMAIN_RANDAO": "0x02000000",
-    "DOMAIN_SELECTION_PROOF": "0x05000000",
-    "DOMAIN_BEACON_PROPOSER": "0x00000000",
-    "SYNC_COMMITTEE_SUBNET_COUNT": "4"
+    "ETH1_ADDRESS_WITHDRAWAL_PREFIX": "0x01",
+    "DOMAIN_RANDAO": "0x02000000"
   }
 }
 ```
@@ -352,7 +408,7 @@ Example Response Body
 
 ```json
 {
-    "token_path": "/home/karlm/.lighthouse/holesky/validators/api-token.txt"
+    "token_path": "/home/karlm/.lighthouse/hoodi/validators/api-token.txt"
 }
 ```
 

diff --git a/book/src/archived_key_management.md b/book/src/archived_key_management.md
@@ -75,21 +75,21 @@ mnemonic is encrypted with a password. It is the responsibility of the user to
 define a strong password. The password is only required for interacting with
 the wallet, it is not required for recovering keys from a mnemonic.
 
-To create a wallet, use the `lighthouse account wallet` command. For example, if we wish to create a new wallet for the Holesky testnet named `wally` and saves it in `~/.lighthouse/holesky/wallets` with a randomly generated password saved
+To create a wallet, use the `lighthouse account wallet` command. For example, if we wish to create a new wallet for the Hoodi testnet named `wally` and saves it in `~/.lighthouse/hoodi/wallets` with a randomly generated password saved
 to `./wallet.pass`:
 
 ```bash
-lighthouse --network holesky account wallet create --name wally --password-file wally.pass
+lighthouse --network hoodi account wallet create --name wally --password-file wally.pass
 ```
 
-Using the above command, a wallet will be created in `~/.lighthouse/holesky/wallets` with the name
+Using the above command, a wallet will be created in `~/.lighthouse/hoodi/wallets` with the name
 `wally`. It is encrypted using the password defined in the
 `wally.pass` file.
 
 During the wallet creation process, a 24-word mnemonic will be displayed. Record the mnemonic because it allows you to recreate the files in the case of data loss.
 > Notes:
 >
-> - When navigating to the directory `~/.lighthouse/holesky/wallets`, one will not see the wallet name `wally`, but a hexadecimal folder containing the wallet file. However, when interacting with `lighthouse` in the CLI, the name `wally` will be used.
+> - When navigating to the directory `~/.lighthouse/hoodi/wallets`, one will not see the wallet name `wally`, but a hexadecimal folder containing the wallet file. However, when interacting with `lighthouse` in the CLI, the name `wally` will be used.
 > - The password is not `wally.pass`, it is the _content_ of the
 >   `wally.pass` file.
 > - If `wally.pass` already exists, the wallet password will be set to the content
@@ -100,18 +100,18 @@ During the wallet creation process, a 24-word mnemonic will be displayed. Record
 Validators are fundamentally represented by a BLS keypair. In Lighthouse, we use a wallet to generate these keypairs. Once a wallet exists, the `lighthouse account validator create` command can be used to generate the BLS keypair and all necessary information to submit a validator deposit. With the `wally` wallet created in [Step 1](#step-1-create-a-wallet-and-record-the-mnemonic), we can create a validator with the command:
 
 ```bash
-lighthouse --network holesky account validator create --wallet-name wally --wallet-password wally.pass --count 1
+lighthouse --network hoodi account validator create --wallet-name wally --wallet-password wally.pass --count 1
 ```
 
 This command will:
 
-- Derive a single new BLS keypair from wallet `wally` in `~/.lighthouse/holesky/wallets`, updating it so that it generates a new key next time.
-- Create a new directory `~/.lighthouse/holesky/validators` containing:
+- Derive a single new BLS keypair from wallet `wally` in `~/.lighthouse/hoodi/wallets`, updating it so that it generates a new key next time.
+- Create a new directory `~/.lighthouse/hoodi/validators` containing:
   - An encrypted keystore file `voting-keystore.json` containing the validator's voting keypair.
     - An `eth1_deposit_data.rlp` assuming the default deposit amount (`32 ETH`) which can be submitted to the deposit
   contract for the Goerli testnet. Other networks can be set via the
   `--network` parameter.
-- Create a new directory `~/.lighthouse/holesky/secrets` which stores a password to the validator's voting keypair.
+- Create a new directory `~/.lighthouse/hoodi/secrets` which stores a password to the validator's voting keypair.
 
 If you want to create another validator in the future, repeat [Step 2](#step-2-create-a-validator). The wallet keeps track of how many validators it has generated and ensures that a new validator is generated each time. The important thing is to keep the 24-word mnemonic safe so that it can be used to generate new validator keys if needed.
 

diff --git a/book/src/faq.md b/book/src/faq.md
@@ -275,7 +275,7 @@ network configuration settings. Ensure that the network you wish to connect to
 is correct (the beacon node outputs the network it is connecting to in the
 initial boot-up log lines). On top of this, ensure that you are not using the
 same `datadir` as a previous network, i.e., if you have been running the
-`Holesky` testnet and are now trying to join a new network but using the same
+`Hoodi` testnet and are now trying to join a new network but using the same
 `datadir` (the `datadir` is also printed out in the beacon node's logs on
 boot-up).
 

diff --git a/book/src/installation_docker.md b/book/src/installation_docker.md
@@ -99,7 +99,7 @@ You can run a Docker beacon node with the following command:
 docker run -p 9000:9000/tcp -p 9000:9000/udp -p 9001:9001/udp -p 127.0.0.1:5052:5052 -v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse lighthouse --network mainnet beacon --http --http-address 0.0.0.0
 ```
 
-> To join the Holesky testnet, use `--network holesky` instead.
+> To join the Hoodi testnet, use `--network hoodi` instead.
 
 > The `-v` (Volumes) and `-p` (Ports) and values are described below.
 

diff --git a/book/src/mainnet_validator.md b/book/src/mainnet_validator.md
@@ -12,7 +12,7 @@ managing servers. You'll also need at least 32 ETH!
 
 Being educated is critical to a validator's success. Before submitting your mainnet deposit, we recommend:
 
-- Thoroughly exploring the [Staking Launchpad][launchpad] website, try running through the deposit process using a testnet launchpad such as the [Holesky staking launchpad](https://holesky.launchpad.ethereum.org/en/).
+- Thoroughly exploring the [Staking Launchpad][launchpad] website, try running through the deposit process using a testnet launchpad such as the [Hoodi staking launchpad](https://hoodi.launchpad.ethereum.org/en/).
 - Running a testnet validator.
 - Reading through this documentation, especially the [Slashing Protection][slashing] section.
 - Performing a web search and doing your own research.
@@ -38,7 +38,7 @@ There are five primary steps to become a validator:
 > **Important note**: The guide below contains both mainnet and testnet instructions. We highly recommend *all* users to **run a testnet validator** prior to staking mainnet ETH.  By far, the best technical learning experience is to run a testnet validator. You can get hands-on experience with all the tools and it's a great way to test your staking
 hardware. 32 ETH is a significant outlay and joining a testnet is a great way to "try before you buy".
 
-> **Never use real ETH to join a testnet!** Testnet such as the Holesky testnet uses Holesky ETH which is worthless. This allows experimentation without real-world costs.
+> **Never use real ETH to join a testnet!** Testnet such as the Hoodi testnet uses Hoodi ETH which is worthless. This allows experimentation without real-world costs.
 
 ### Step 1. Create validator keys
 
@@ -48,7 +48,7 @@ The Ethereum Foundation provides the [staking-deposit-cli](https://github.com/et
 ./deposit new-mnemonic
 ```
 
-and follow the instructions to generate the keys. When prompted for a network, select `mainnet` if you want to run a mainnet validator, or select `holesky` if you want to run a Holesky testnet validator. A new mnemonic will be generated in the process.
+and follow the instructions to generate the keys. When prompted for a network, select `mainnet` if you want to run a mainnet validator, or select `hoodi` if you want to run a Hoodi testnet validator. A new mnemonic will be generated in the process.
 
 > **Important note:** A mnemonic (or seed phrase) is a 24-word string randomly generated in the process. It is highly recommended to write down the mnemonic and keep it safe offline. It is important to ensure that the mnemonic is never stored in any digital form (computers, mobile phones, etc) connected to the internet. Please also make one or more backups of the mnemonic to ensure your ETH is not lost in the case of data loss. It is very important to keep your mnemonic private as it represents the ultimate control of your ETH.
 
@@ -71,10 +71,10 @@ Mainnet:
 lighthouse --network mainnet account validator import --directory $HOME/staking-deposit-cli/validator_keys
 ```
 
-Holesky testnet:
+Hoodi testnet:
 
 ```bash
-lighthouse --network holesky account validator import --directory $HOME/staking-deposit-cli/validator_keys
+lighthouse --network hoodi account validator import --directory $HOME/staking-deposit-cli/validator_keys
 ```
 
 > Note: The user must specify the consensus client network that they are importing the keys by using the `--network` flag.
@@ -132,10 +132,10 @@ Mainnet:
 lighthouse vc --network mainnet --suggested-fee-recipient YourFeeRecipientAddress
 ```
 
-Holesky testnet:
+Hoodi testnet:
 
 ```bash
-lighthouse vc --network holesky --suggested-fee-recipient YourFeeRecipientAddress
+lighthouse vc --network hoodi --suggested-fee-recipient YourFeeRecipientAddress
 ```
 
 The `validator client` manages validators using data obtained from the beacon node via a HTTP API. You are highly recommended to enter a fee-recipient by changing `YourFeeRecipientAddress` to an Ethereum address under your control.
@@ -153,7 +153,7 @@ by the protocol.
 
 ### Step 5: Submit deposit (a minimum of 32ETH to activate one validator)
 
-After you have successfully run and synced the execution client, beacon node and validator client, you can now proceed to submit the deposit. Go to the mainnet [Staking launchpad](https://launchpad.ethereum.org/en/) (or [Holesky staking launchpad](https://holesky.launchpad.ethereum.org/en/) for testnet validator) and carefully go through the steps to becoming a validator. Once you are ready, you can submit the deposit by sending ETH to the deposit contract. Upload the `deposit_data-*.json` file generated in [Step 1](#step-1-create-validator-keys) to the Staking launchpad.
+After you have successfully run and synced the execution client, beacon node and validator client, you can now proceed to submit the deposit. Go to the mainnet [Staking launchpad](https://launchpad.ethereum.org/en/) (or [Hoodi staking launchpad](https://hoodi.launchpad.ethereum.org/en/) for testnet validator) and carefully go through the steps to becoming a validator. Once you are ready, you can submit the deposit by sending ETH to the deposit contract. Upload the `deposit_data-*.json` file generated in [Step 1](#step-1-create-validator-keys) to the Staking launchpad.
 
 > **Important note:** Double check that the deposit contract for mainnet is `0x00000000219ab540356cBB839Cbe05303d7705Fa` before you confirm the transaction.
 

diff --git a/book/src/run_a_node.md b/book/src/run_a_node.md
@@ -54,7 +54,7 @@ Notable flags:
 - `--network` flag, which selects a network:
   - `lighthouse` (no flag): Mainnet.
   - `lighthouse --network mainnet`: Mainnet.
-  - `lighthouse --network holesky`: Holesky (testnet).
+  - `lighthouse --network hoodi`: Hoodi (testnet).
   - `lighthouse --network sepolia`: Sepolia (testnet).
   - `lighthouse --network chiado`: Chiado (testnet).
   - `lighthouse --network gnosis`: Gnosis chain.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -40,4 +40,4 @@ There can also be a scenario that a bug has been found and requires an urgent fi

		## When not to use a release candidate

		Other than the above scenarios, it is generally not recommended to use release candidates for any critical tasks on mainnet (e.g., staking). To test new release candidate features, try one of the testnets (e.g., Holesky).
		Other than the above scenarios, it is generally not recommended to use release candidates for any critical tasks on mainnet (e.g., staking). To test new release candidate features, try one of the testnets (e.g., Hoodi).