Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 10 additions & 6 deletions run-on-lido/cm-v2/bond-and-key-management.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,9 +12,11 @@ This page covers how to upload and manage your validator keys, and how bond work

### Uploading keys

![Upload keys](/img/cm-guide/bond-upload-keys.png)
Before uploading keys, generate your validator keys and deposit data using a tool such as the [EthStaker Deposit CLI](https://github.com/ethstaker/ethstaker-deposit-cli) or your organization's standard key-generation process. Keys must use `0x02` (compounding) withdrawal credentials and point to the [Lido Withdrawal Vault address](/run-on-lido/cm-v2/useful-tools/key-generation#key-addresses).

See the [Key Generation & Fee Recipient](/run-on-lido/cm-v2/useful-tools/key-generation) guide for detailed steps and addresses.

Before uploading keys, generate your validator keys and deposit data using a tool such as the [EthStaker Deposit CLI](https://github.com/eth-educators/ethstaker-deposit-cli) or your organization's standard key-generation process. Please make sure the generated keys use `0x02` withdrawal credentials and point to the [Lido Execution Layer Withdrawal Vault](https://etherscan.io/address/0xb9d7934878b5fb9610b3fe8a5e441e8fad7e293f).
![Upload keys](/img/cm-guide/bond-upload-keys.png)

To upload the keys, go to the Keys tab in [cm.testnet.fi](https://cm.testnet.fi), and drag and drop the `deposit-data.json` file. The widget will tell you how much bond is required for the number of keys submitted.

Expand Down Expand Up @@ -45,7 +47,7 @@ Each key inside your Node Operator has one of the following statuses.
| **Exited** | Key has been exited | — |
| **Withdrawn** | Key has been exited and ETH has been returned to the protocol | — |
| **Unbonded** | Bond is insufficient for this key, which can be Active or otherwise | Top up bond or remove/exit the key |
| **Exit requested** | An exit has been requested by [VEBO](https://docs.lido.fi/contracts/validators-exit-bus-oracle/) but the validator has not yet exited | Exit the validator as soon as possible to avoid a Late exit penalty |
| **Exit requested** | An exit has been requested by [VEBO](/contracts/validators-exit-bus-oracle/) but the validator has not yet exited | Exit the validator as soon as possible to avoid a Late exit penalty |
| **Duplicated** | Key has been uploaded twice either to the Lido protocol or Ethereum CL | Remove duplicate key |
| **Invalid** | Uploaded key has an invalid signature | Remove key and re-upload it with the valid signature |

Expand All @@ -67,15 +69,17 @@ To remove them, go to the Keys section in the CMv2 widget and open the Remove ta

#### Voluntary exit

Voluntary exits are appropriate when the protocol has requested an exit via the [Validators Exit Bus Oracle](https://docs.lido.fi/contracts/validators-exit-bus-oracle) to fulfill stETH withdrawal requests, or when you have insufficient bond to cover this key.
Voluntary exits are appropriate when the protocol has requested an exit via the [Validators Exit Bus Oracle](/contracts/validators-exit-bus-oracle) to fulfill stETH withdrawal requests, or when you have insufficient bond to cover this key.

Please note this can't be done in the CMv2 widget, it can only be done through your validator client.

Exiting validators outside of a protocol-requested exit is discouraged. If you plan to exit validators without a prior exit request, notify the CMC and the community in advance using the [Node Operators](https://research.lido.fi/c/node-operators/12) category of the Lido Research Forum.

#### Ejection (triggerable withdrawals)

Through the CMv2 widget, you can force-exit an active validator directly from the Execution Layer using EIP-7002 triggerable withdrawals. This is an emergency measure. It is recommended to use voluntary exits broadcast via CL in normal operations.
Through the CMv2 widget, you can force-exit an active validator directly from the Execution Layer using EIP-7002 triggerable withdrawals. This is an emergency measure and incurs ejection fees.

It is recommended to use voluntary exits broadcast via CL in normal operations.

---

Expand Down Expand Up @@ -132,4 +136,4 @@ The CM interface also includes a penalty history section where you can review pa

If your bond falls below the required minimum, some of your keys become **Unbonded** and will not receive new deposits; if the key was already deposited or active, an exit will be requested.

To solve this you can either top up the bond, or exit the key.
To solve this you can either top up the bond, or exit the key.
4 changes: 2 additions & 2 deletions run-on-lido/cm-v2/consolidations-and-migration.md
Original file line number Diff line number Diff line change
Expand Up @@ -56,11 +56,11 @@ Before starting, ensure the following:
### Step 2: Consolidation

1. **Initiate via EasyTrack.** Submit a motion specifying the source CMv1 operator, the target CMv2 sub-Node Operator(s), and a consolidation manager address. Once enacted, stake transfers from the CMv1 entity to its corresponding CMv2 entity are permitted.
2. **Submit consolidation batches** using the Consolidations UI, specifying which CMv1 source validators consolidate into which CMv2 target validators.
2. **Submit consolidation batches** using the [Consolidations interface on Hoodi](https://consolidation-ui-hoodi.testnet.fi/), specifying which CMv1 source validators consolidate into which CMv2 target validators.

![Submit consolidation batches](/img/cm-guide/consolidation-submit.png)

3. **Monitor progress.** Track queued, in-progress, and completed consolidations in the Consolidations UI. Operators are expected to stay aware of their own operations.
3. **Monitor progress.** Track queued, in-progress, and completed consolidations in the [Consolidations interface on Hoodi](https://consolidation-ui-hoodi.testnet.fi/). Operators are expected to stay aware of their own operations.

![Monitor consolidation progress](/img/cm-guide/consolidation-monitor.png)

Expand Down
1 change: 1 addition & 0 deletions run-on-lido/cm-v2/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -58,6 +58,7 @@ How existing Curated Module (v1) operators transition to CMv2, the consolidation

Tools and dashboards that support CMv2 operations.

- [Key Generation & Fee Recipient](/run-on-lido/cm-v2/useful-tools/key-generation)
- [CM Prover Tool](/run-on-lido/cm-v2/useful-tools/cm-prover-tool)

---
Expand Down
4 changes: 2 additions & 2 deletions run-on-lido/cm-v2/useful-tools/cm-prover-tool.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
---
sidebar_position: 1
sidebar_position: 2
---

# 🔧 CM Prover Tool (also known as CSM Prover Tool)

The [CSM prover tool](https://github.com/lidofinance/csm-prover-tool) is a daemon application for CSM-like modules: the CSM itself and the new Curated Module v2. It listens to the Consensus Layer and Execution Layer and reports module events such as withdrawals, slashings, consolidations, and balance-related changes.
The [CSM prover tool](https://github.com/lidofinance/csm-prover-tool) is a daemon application for CSM-like modules: the CSM itself and the new Curated Module v2. It listens to the Consensus Layer and Execution Layer and reports module events such as withdrawals, slashings, and balance-related changes.

Lido contributors are running an instance of the prover-tool that serves all CMv2 Node Operators. However, Node Operators can run their own instance of the prover-tool, which will serve their Node Operator IDs exclusively, ensuring that all critical information is delivered to CMv2 contracts in a timely manner. Please refer to the README file in the repo for the configuration details.

Expand Down
3 changes: 2 additions & 1 deletion run-on-lido/cm-v2/useful-tools/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,4 +10,5 @@ Here you will find tools and dashboards that support CMv2 operations.

## Contents

[**CM Prover Tool →**](/run-on-lido/cm-v2/useful-tools/cm-prover-tool)
[**Key Generation & Fee Recipient →**](/run-on-lido/cm-v2/useful-tools/key-generation)
[**CM Prover Tool →**](/run-on-lido/cm-v2/useful-tools/cm-prover-tool)
121 changes: 121 additions & 0 deletions run-on-lido/cm-v2/useful-tools/key-generation.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,121 @@
---
sidebar_position: 1
---

# 🔑 Key Generation & Fee Recipient

The Curated Module v2 requires `0x02` (compounding) validator keys. This page walks through generating them using the [EthStaker Deposit CLI](https://github.com/ethstaker/ethstaker-deposit-cli), the most widely used tool for validator key generation.

If you're planning to use DVT or your organization uses a different key generation process, make sure the output meets the same requirements described below.

:::info
Please note that each key should be generated with a deposit amount of 32 ETH. This is the initial deposit with which the protocol will activate the validator. After activation, CMv2 may allocate additional stake to your validators, up to 2,048 ETH each.
:::

---

## Key addresses

To run your validators in the Curated Module, you will need to set the correct [Withdrawal Address](/contracts/withdrawal-vault) at key generation, and run your clients with the [Lido Execution Layer Rewards Vault](/contracts/lido-execution-layer-rewards-vault) as the Fee Recipient.

| Network | Withdrawal Address (Withdrawal Vault) | Fee Recipient (Execution Layer Rewards Vault) |
Comment thread
TheDZhon marked this conversation as resolved.
| --- | --- | --- |
| **Hoodi** | [`0x4473dCDDbf77679A643BdB654dbd86D67F8d32f2`](https://hoodi.etherscan.io/address/0x4473dCDDbf77679A643BdB654dbd86D67F8d32f2) | [`0x9b108015fe433F173696Af3Aa0CF7CDb3E104258`](https://hoodi.etherscan.io/address/0x9b108015fe433F173696Af3Aa0CF7CDb3E104258) |
| **Mainnet** | [`0xB9D7934878B5FB9610B3fE8A5e441e8fad7E293f`](https://etherscan.io/address/0xB9D7934878B5FB9610B3fE8A5e441e8fad7E293f) | [`0x388C818CA8B9251b393131C08a736A67ccB19297`](https://etherscan.io/address/0x388C818CA8B9251b393131C08a736A67ccB19297) |

You can verify these and other protocol contracts on the [Deployed Contracts](/deployed-contracts/) page.

Please note that the Withdrawal Address is set at generation. If you need to change it, you must re-generate the deposit data with the correct address before uploading. Once a validator is deposited its Withdrawal Address cannot be changed.

Similarly, blocks proposed with the incorrect Fee Recipient may result in a [**General Delayed Penalty**](/run-on-lido/cm-v2/penalties#general-delayed-penalty) being applied.

---

## Generating keys with EthStaker Deposit CLI

:::warning
- Generate your keys on a secure, ideally air-gapped machine.
- Never share your keystores or mnemonic.
- Back up your mnemonic on paper or steel. It is the only way to recover your keystore or generate additional keys. If you lose your keystores, you can still exit validators via [Triggerable Withdrawals](/run-on-lido/cm-v2/bond-and-key-management#ejection-triggerable-withdrawals).
:::

The steps below will help you create `0x02` keys **for the Hoodi testnet**.

For a broader overview of the tool and its capabilities, see the [EthStaker Deposit CLI documentation](https://deposit-cli.ethstaker.cc/landing.html).

### 1. Download and verify

1. Go to the [releases page](https://github.com/ethstaker/ethstaker-deposit-cli/releases) and download the archive for your operating system.

2. Extract the archive:

```bash
tar -xzf ethstaker_deposit-cli-*.tar.gz
cd ethstaker_deposit-cli-*/
```

3. Verify the binary attestation using the [GitHub CLI](https://cli.github.com/) (`gh`). Replace the filename with the actual file you downloaded:

```bash
gh attestation verify ethstaker_deposit-cli-*******-***.*** --repo ethstaker/ethstaker-deposit-cli
```

You should see `✓ Verification succeeded!` in the output. **Do not continue if verification fails.** For offline verification, see [GitHub's instructions](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/verifying-attestations-offline).

### 2. Generate keys

The examples below generate `0x02` compounding keys for the **Hoodi** testnet. For Mainnet adjustments, see [Common flags](#common-flags).

#### 2.1. From a new mnemonic

Use `new-mnemonic` if this is your first time generating keys:

```bash
./deposit new-mnemonic \
--chain hoodi \
--compounding \
--num_validators <NUMBER_OF_VALIDATORS> \
--amount 32 \
--withdrawal_address 0x4473dCDDbf77679A643BdB654dbd86D67F8d32f2
```

The CLI will prompt you to create a mnemonic. Write it down on paper and store it securely. It cannot be recovered if lost.

#### 2.2. From an existing mnemonic

Use `existing-mnemonic` if you already have a mnemonic and want to generate additional keys. You will need to provide the `--validator_start_index` to avoid regenerating keys you already have.

```bash
./deposit existing-mnemonic \
--chain hoodi \
--compounding \
--num_validators <NUMBER_OF_VALIDATORS> \
--amount 32 \
--validator_start_index <START_INDEX> \
--withdrawal_address 0x4473dCDDbf77679A643BdB654dbd86D67F8d32f2
```

For example, if you previously generated 4 keys (indices 0 to 3), set `--validator_start_index 4` to generate the next batch.

#### Common flags

For **Mainnet**, replace `--chain hoodi` with `--chain mainnet` and set `--withdrawal_address` to `0xB9D7934878B5FB9610B3fE8A5e441e8fad7E293f`.

- **`--compounding`**: generates keys with `0x02` withdrawal credentials, required for CMv2. These validators support a maximum effective balance of 2,048 ETH.
- **`--amount 32`**: sets the initial deposit amount to 32 ETH per validator. After activation, CMv2 may top up validators up to 2,048 ETH through its allocation algorithm.
- **`--withdrawal_address`**: must point to the Lido Withdrawal Vault for the corresponding network (see table above).

### 3. Output files

A successful run produces:

- **`keystore-*.json`** (one per validator): encrypted signing keystores, used by your validator client.
- **`deposit_data-*.json`** (one file): contains the deposit data for all generated validators. This is the file you upload to the CMv2 widget.

---

## Configuring the fee recipient

The fee recipient is configured in your validator client. Set it to the address for the corresponding network from the [key addresses table](#key-addresses) above.

How you set the fee recipient depends on your node management setup. The CSM guide on [Setting the Fee Recipient](/run-on-lido/csm/troubleshooting/setting-the-fee-recipient-for-csm-validators) covers configuration for Dappnode, Stereum, Eth Docker, Sedge, EthPillar, Systemd, and others. The same steps apply to CMv2 validators using the addresses from the table above.
Original file line number Diff line number Diff line change
Expand Up @@ -173,36 +173,41 @@ If wrong, you must exit & recreate with the correct address.

In your service file (e.g. `/etc/systemd/system/validator.service`), update the `ExecStart` line:

#### [Lighthouse](https://lighthouse-book.sigmaprime.io/)

```bash
# Lighthouse example
ExecStart=/usr/local/bin/lighthouse vc \
--suggested-fee-recipient=0x388C818CA8B9251b393131C08a736A67ccB19297 \
[other flags...]
```

#### [Prysm](https://docs.prylabs.network/)

```bash
# Prysm example
ExecStart=/usr/local/bin/validator \
--suggested-fee-recipient=0x388C818CA8B9251b393131C08a736A67ccB19297 \
[other flags...]
```

#### [Teku](https://docs.teku.consensys.io/)

```bash
# Teku example
ExecStart=/usr/local/bin/teku/bin/teku validator-client \
--validators-proposer-default-fee-recipient=0x388C818CA8B9251b393131C08a736A67ccB19297 \
[other flags...]
```

#### [Nimbus](https://nimbus.guide/)

```bash
# Nimbus example
ExecStart=/usr/local/bin/nimbus_validator_client \
--suggested-fee-recipient=0x388C818CA8B9251b393131C08a736A67ccB19297 \
[other flags...]
```

#### [Lodestar](https://chainsafe.github.io/lodestar/)

```bash
# Lodestar example
ExecStart=/usr/bin/lodestar validator \
--suggestedFeeRecipient=0x388C818CA8B9251b393131C08a736A67ccB19297 \
[other flags...]
Expand Down
11 changes: 11 additions & 0 deletions run-on-lido/csm/useful-tools/csm-prover-tool.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
---
sidebar_position: 5
---

# 🔧 CSM Prover Tool

The [CSM prover tool](https://github.com/lidofinance/csm-prover-tool) is a daemon application that listens to the Consensus Layer and Execution Layer and reports module events such as withdrawals, slashings, and balance-related changes to CSM contracts.

Lido contributors are running an instance of the prover tool that serves all CSM Node Operators. However, Node Operators can run their own instance, which will serve their Node Operator IDs exclusively, ensuring that all critical information is delivered to CSM contracts in a timely manner. Please refer to the README file in the repo for the configuration details.

A good example here is the requirement to prove the validator's withdrawal before the bond is released and becomes claimable. If the Lido-owned instance is not functioning correctly for any reason, an instance hosted by Node Operators can serve as a fallback.
4 changes: 3 additions & 1 deletion run-on-lido/csm/useful-tools/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,4 +16,6 @@ Here you will find various tools that will make your experience with CSM as easy

[**Advanced Networking →**](./advanced-networking)

[**Automated Graceful Shutdown & Remote Wake →**](./automated-graceful-shutdown-and-remote-wake)
[**Automated Graceful Shutdown & Remote Wake →**](./automated-graceful-shutdown-and-remote-wake)

[**CSM Prover Tool →**](./csm-prover-tool)
Loading