Generate Deposit Data

The deposit data is used for registering new validators. ethStaking oracles are responsible for choosing the operator for the new validator based on different metrics (number of keys, performance, etc.). Once operator is selected, its deposit data is used to register the validator in beacon chain.

1. Installation

Navigate to the releases page to download and decompress the latest version of operator-cli for your operating system.

2. Generate deposit data

NB! You must use a new mnemonic for every staking setup. If you use the same mnemonic, you can accidentally run same validator in multiple places and get slashed.

New mnemonic

Run the following command to generate deposit data with the new mnemonic:

./ethStaking-cli create-deposit-data

Choose the network you would like to generate the deposit data for:

Enter the network name (mainnet, goerli, gnosis) [mainnet]: mainnet

Choose the language for your mnemonic:

// Some codeChoose your mnemonic language (chinese_simplified, chinese_traditional, czech, english, italian, korean, portuguese, spanish) [english]:

NB! You must store the generated mnemonic in secure cold storage. You won't be able to restore the keys in case it will be lost.

Existing mnemonic

Run the following command to generate deposit data using existing mnemonic:

./ethStaking-cli create-deposit-data --existing-mnemonic

Choose the network you would like to generate the deposit data for:

Enter the network name (mainnet, goerli, gnosis) [mainnet]: mainnet

Enter your existing mnemonic:

Enter your mnemonic separated by spaces (" "):

Deposit Data

Choose the number of validators you would like to run. If you're a new operator, start with a smaller amount of validator keys (e.g. 10 for the Mainnet, 100 for Gnosis Chain). Once they run smoothly, you can extend to a larger number. Also, it's better to not run too many keys in the same staking setup (e.g. up to 1000 keys in Mainnet and up to 10000 in Gnosis).

Enter the number of new validator keys you would like to generate: 10
Creating validator keys: [####################################] 10/10
Creating deposit data: [####################################] 10/10

Choose the destination address for the rewards and the percent of protocol fee shares per every validator:

Enter the wallet address that will receive rewards. If you already run ethStaking validators, please re-use the same wallet address: 0x...
Enter the % of the rewards you would like to receive from the protocol fees [50.0]:

3. Submit specification

The command from the previous step will generate the specification. For example,

## Specification

- DAO calls `addOperator` function of `PoolValidators` contract with the following parameters:
    * operator: `0x...`
    * depositDataMerkleRoot: `0x606c5a3638078206f54177ac70a71702a6e52f046a3811efa1b389f9485cbf18`
    * depositDataMerkleProofs: `/ipfs/QmSAvPukDjU2f7w1C4b5SKKuLpwaZZeC8dsG4vV6pRjTF6`


- DAO calls `setOperator` function of `Roles` contract with the following parameters:
    * account: `0x...`
    * revenueShare: `5000`


- If the proposal will be approved, the operator must perform the following steps:
    * Call `operator-cli sync-vault` or `operator-cli sync-local` with the same mnemonic as used for generating the proposal
    * Create or update validators and make sure the new keys are added
    * Call `commitOperator` from the `0x...` address

You should share that specification in a ethStaking Forum post about your operator or include it in the proposal about adding/extending validator keys.

4. Send encrypted key shares

The command from the deposit data step will generate the encrypted key shares that you must share with the committee. For example,

  • @username1: /cli/committee/username1-1867c966-1.shard

  • @username2: /cli/committee/username2-1867c966-1.shard

  • @username3: /cli/committee/username3-1867c966-1.shard

  • @username4: /cli/committee/username4-1867c966-1.shard

  • @username5: /cli/committee/username5-1867c966-1.shard

These key shares can only be decrypted by the respective committee members and will be used in case something unexpected happens with the operator, e.g. it loses access to the validators, refuses to sign validators exit on the DAO request, etc.

PreviousOnboarding ProcessNextethStaking Infra Package

Last updated