in

Ledger Hardware Wallet and using it for ETH solo staking

At some point in the near future, I hope to run a ETH validator from home. I’m using the eth-docker project, and got my validator configured for testnet and I’m fairly comfortable with the overall process. Now I’m thinking about how best to protect and secure the validator and/or withdrawal keys using my ledger nano hardware wallet.

From my research, I believe there are 3 ways to use the ledger nano wallet while setting up ETH staking node.

1. Using the ledger nano to sign the transaction when depositing the 32 ETH to the deposit contract. This is an obvious one. No debate needed. Edit – Make sure DEBUG and SMART CONTRACT is enabled on the Ledger
2. When creating the deposit contract with the deposit cli tool, use the “–eth1_withdrawal_address” option and specify the ledger nano managed address for the withdrawal credentials. A mnemonic will still be generated for the validator key recovery.

./deposit –eth1_withdrawal_address YOURHARDWAREWALLETADDRESS

3) When creating the deposit contract with the deposit cli tool, use the “existing-mnemonic” option and provide the mnemonic used by the ledger nano wallet. This would be done using a offline/air-gapped computer booting off a Ubuntu Live USB/CD and a pre-downloaded deposit-cli tool that has been SHA256 verified.

Edit, added option 3a.
3a) This is similar to option 3, except instead of using the ledger generated mnemonic with the deposit-cli tool, we use the deposit-cli tool generated mnemonic to “recover” the ledger. The results are basically the same, one shared mnemonic between the ledger hw wallet and the validator/withdrawal keys.

​

Reference:

[https://github.com/ethereum/eth2.0-deposit-cli](https://github.com/ethereum/eth2.0-deposit-cli)

​

I’m leaning heavily to option 3, and using the “existing-mnemonic” option. I believe the biggest issue/risk with this option is exposing the ledger nano recovery mnemonic when using the deposit-cli tool. However, like I stated, I plan to use a Ubuntu Live CD on an air-gapped computer and confident I can do it securely. I already have an existing process to recover/secure my ledger mnemonic so I think the advantages out weight the risk.

​

Wanted to get the communities opinion and feedback incase I’m not understanding everything correctly.

What do you think?

10 Points
Upvote Downvote

Leave a Reply

Your email address will not be published. Required fields are marked *

GIPHY App Key not set. Please check settings

7 Comments

  1. A hardware wallet is mostly useful if you intend to use that wallet often to sign transactions, because it provides a way to interact with the private key without typing it out. In the case of staking, that wallet will almost never be used (until withdrawals are enabled) so the hardware wallet doesn’t really add any value. What is your reasoning behind integrating the hardware wallet into this workflow, if you don’t mind?

    In my opinion, it’s more secure and less error-prone the other way around: generate the mnemonic and JSON validator wallet on the air-gapped machine, and then restore the Ledger to use that mnemonic (it’s tedious, but it will auto-recommend words which is helpful). That way, you don’t have to type the mnemonic into the CLI or potentially mistype and get something wrong.

  2. Regarding the first part of your question, the validator keys need to be on a hot wallet as signatures are required every couple seconds. You can only secure the withdrawal keys with a hardware wallet.

    A fourth option would be rocket pool, it has the advantage that you can move your withdrawal address to a new wallet at will, but the downside is that you will have to put the 16 ETH + RPL onto the hot wallet temporarily for the deposits / stakes. You will get slightly more rewards but also add smart contract risk.

  3. I did number 3 myself, ledger nano X and used a live boot air gap as you described, with the same concern and assessment of risk around the seed being entered into a running system.

    Benefit to me is a shared mnemonic for both my ETH1 keys (among my other coins) and the BLS signatures for deposit, so hopefully in the future the Ledger will support EIP-2333 and EIP-2334 [natively](https://kb.beaconcha.in/ethereum-2-keys). Even if that is not done, I can still derive the withdrawal key using the mnemonic similar to how I generated it, and only have to worry about documenting the steel backup with 2 restore paths for my heirs or shareholders.

    If you’re using the ledger to sign the deposit contract transaction(s), I had to enable debug and enable contracts (big “duh” moment I had in getting it to sign)

  4. 2 and 3 are both good IMO.

    ​

    #2 is nice because you never have to type your seed phrase that is securing your other funds into anything.

    ​

    #3 is nice because you only have single seed phrase that you need to keep safe and back up.

    ​

    Slightly different risks in each case, but given what you’ve described it sounds like you’re aware of what they are and will be taking appropriate steps to reduce and mange your risk.

We Found The Original Baby Daddy πŸ₯ž It’s $DaddyCake πŸ₯ž New $Cake Reflection Gem πŸ’Ž Huge Marketing Budget πŸ”₯ 3K TG Group πŸ”₯ Anti-Rug Tokenomics πŸ‹ 250X MoonShot πŸš€ Launches Soon πŸ€‘ Airdrop: LIVE πŸ”’ 1 Year LP Lock !

Get Rich Fast(ly) – $FSLY DD