Teku can communicate with a single relay directly:
- {String.raw`--builder-endpoint="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"`}
+ {String.raw`teku --builder-endpoint="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"`}
Or you can configure it to communicate with a local MEV-boost sidecar to configure multiple relays:
- {String.raw`--builder-endpoint=http://mev-boost:18550`}
+ {String.raw`teku --builder-endpoint=http://mev-boost:18550`}
@@ -79,6 +75,7 @@ The following flags need to be configured on your chosen consensus client. A fla
+ Prysm can communicate with a single relay directly:
{String.raw`prysm beacon-chain --http-mev-relay "https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"`}
@@ -86,17 +83,21 @@ The following flags need to be configured on your chosen consensus client. A fla
+ Nimbus can communicate with a single relay directly:
- {String.raw`--payload-builder=true --payload-builder-url="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"`}
+ {String.raw`nimbus_beacon_node \
+ --payload-builder=true \
+ --payload-builder-url="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"`}
You should also consider adding --local-block-value-boost 3 as a flag, to favour locally built blocks if they are withing 3% in value of the relay block, to improve the chances of a successful proposal.
+ Lodestar can communicate with a single relay directly:
- {String.raw`--builder --builder.urls "https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"`}
+ {String.raw`node ./lodestar --builder --builder.urls "https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"`}
@@ -132,14 +133,14 @@ The following flags need to be configured on your chosen validator client
- {String.raw`--payload-builder=true`}
+ {String.raw`nimbus_validator_client --payload-builder=true`}
- {String.raw`--builder="true" --builder.selection="builderonly"`}
+ {String.raw`node ./lodestar validator --builder="true" --builder.selection="builderonly"`}
@@ -149,15 +150,16 @@ The following flags need to be configured on your chosen validator client
It can be difficult to confirm everything is configured correctly with your cluster until a proposal opportunity arrives, but here are some things you can check.
-When your cluster is running, you should see if charon is logging something like this each epoch:
-```
+When your cluster is running, you should see if Charon is logging something like this each epoch:
+
+```log
13:10:47.094 INFO bcast Successfully submitted validator registration to beacon node {"delay": "24913h10m12.094667699s", "pubkey": "84b_713", "duty": "1/builder_registration"}
```
-This indicates that your charon node is successfully registering with the relay for a blinded block when the time comes.
+This indicates that your Charon node is successfully registering with the relay for a blinded block when the time comes.
-If you are using the [ultrasound relay](https://relay.ultrasound.money), you can enter your cluster's distributed validator public key(s) into their website, to confirm they also see the validator as correctly registered.
+If you are using the [ultrasound relay](https://relay.ultrasound.money), you can enter your cluster's distributed validator public key(s) into their website, to confirm they also see the validator as correctly registered.
-You should check that your validator client's logs look healthy, and ensure that you haven't added a `fee-recipient` address that conflicts with what has been selected by your cluster in your cluster-lock file, as that may prevent your validator from producing a signature for the block when the opportunity arises. You should also confirm the same for all of the other peers in your cluster.
+You should check that your validator client's logs look healthy, and ensure that you haven't added a `fee-recipient` address that conflicts with what has been selected by your cluster in your cluster-lock file, as that may prevent your validator from producing a signature for the block when the opportunity arises. You should also confirm the same for all of the other peers in your cluster.
-Once a proposal has been made, you should look at the `Block Extra Data` field under `Execution Payload` for the block on [Beaconcha.in](https://beaconcha.in/block/18450364), and confirm there is text present, this generally suggests the block came from a builder, and was not a locally constructed block.
\ No newline at end of file
+Once a proposal has been made, you should look at the `Block Extra Data` field under `Execution Payload` for the block on [Beaconcha.in](https://beaconcha.in/block/18450364), and confirm there is text present, this generally suggests the block came from a builder, and was not a locally constructed block.
diff --git a/docs/advanced/quickstart-combine.md b/docs/advanced/quickstart-combine.md
index b4ad67a314..8f39a7b572 100644
--- a/docs/advanced/quickstart-combine.md
+++ b/docs/advanced/quickstart-combine.md
@@ -59,7 +59,7 @@ cluster/
│ ├── keystore-1.json
│ └── keystore-1.txt
...
-└── node*
+└── nodeN
├── charon-enr-private-key
├── cluster-lock.json
├── deposit-data.json
@@ -80,13 +80,13 @@ Doing so can potentially cause the combination process to fail.
Run the following command:
-```sh
+```shell
# Combine a clusters private keys
-docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.19.2 combine --cluster-dir /opt/charon/cluster --output-dir /opt/charon/combined
+docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v1.0.0 combine --cluster-dir /opt/charon/cluster --output-dir /opt/charon/combined
```
This command will store the combined keys in the `output-dir`, in this case a folder named `combined`.
-
+
```shell
$ tree combined
combined
@@ -106,7 +106,7 @@ $ jq .distributed_validators[].distributed_public_key cluster/node0/cluster-loc
:::info
-The generated private keys are in the standard [EIP-2335](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2335.md) format, and can be imported in any Ethereum validator client that supports it.
+The generated private keys are in the standard [EIP-2335](https://github.com/ethereum/ercs/blob/master/ERCS/erc-2335.md) format, and can be imported in any Ethereum validator client that supports it.
Ensure your distributed validator cluster is completely shut down before starting a replacement validator or you are likely to be slashed.
:::
diff --git a/docs/advanced/quickstart-eigenpod.md b/docs/advanced/quickstart-eigenpod.md
index db00b65155..e4ce625d2b 100644
--- a/docs/advanced/quickstart-eigenpod.md
+++ b/docs/advanced/quickstart-eigenpod.md
@@ -16,7 +16,7 @@ This is a walkthrough of creating a distributed validator cluster pointing to an
## Pre-requisites
-- The Ethereum addresses or ENS names for the node operators in the cluster. (Currently the DV Launchpad only supports Metamask or equivalent injected web3 browser wallets).
+- The Ethereum addresses or ENS names for the node operators in the cluster. (Currently the DV Launchpad only supports Metamask or equivalent injected web3 browser wallets.)
- If creating more than one validator, the ability to use the [obol-sdk](./quickstart-sdk.md) is required.
## Create a SAFE to own the EigenPod
@@ -61,7 +61,6 @@ With these contracts deployed, you can now create the DV cluster invitation to s
-
## Deposit and restake your Distributed Validator
-Once you have completed the DKG ceremony, you can continue the flow on the EigenLayer app to activate these validators and restake them. Consult the EigenLayer [documentation](https://docs.eigenlayer.xyz/eigenlayer/restaking-guides/restaking-user-guide/native-restaking/create-eigenpod-and-set-withdrawal-credentials/enable-restaking) to continue the process.
+Once you have completed the DKG ceremony, you can continue the flow on the EigenLayer app to activate these validators and restake them. Consult the EigenLayer [documentation](https://docs.eigenlayer.xyz/eigenlayer/restaking-guides/restaking-user-guide/native-restaking/create-eigenpod-and-set-withdrawal-credentials/enable-restaking) to continue the process.
diff --git a/docs/advanced/quickstart-sdk.md b/docs/advanced/quickstart-sdk.md
index af8df51d1f..040eb65ade 100644
--- a/docs/advanced/quickstart-sdk.md
+++ b/docs/advanced/quickstart-sdk.md
@@ -37,7 +37,7 @@ Install the Obol-SDK package into your development environment
## Instantiate the client
-The first thing you need to do is create a instance of the Obol SDK client. The client takes two constructor parameters:
+The first thing you need to do is create an instance of the Obol SDK client. The client takes two constructor parameters:
- The `chainID` for the chain you intend to use.
- An ethers.js [signer](https://docs.ethers.org/v6/api/providers/#Signer-signTypedData) object.
@@ -88,7 +88,7 @@ console.log(
Once the Obol-API returns a `configHash` string from the `createClusterDefinition` method, you can use this identifier to invite the operators to the [Launchpad](../dvl/intro.md) to complete the process
1. Operators navigate to `https://