A validator node as an inheritance is tricky because it is not one key, but two: one key that can get you slashed (signing key), and one that decides where the money goes (withdrawal address). Give both to one person, and that person can both get you slashed and take all your money. Give them to two people, and if one person cannot be reached, the assets get stuck.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
So the question is not "who gets it." The answer is that the signing key and the withdrawal address must go through two separate paths. The withdrawal path should be able to bypass the signing key and withdraw funds on its own. Otherwise, after you pass away, the node keeps running, and your heir would have to learn how to run a node just to get the money. That is not realistic.
Two Paths, Two Handover Goals
First, be clear about what you are handing over:
| Component | Purpose | What happens if leaked | What to do in inheritance |
|---|---|---|---|
| Signing Keys (Validator Keys) | Validate transactions, produce blocks, earn rewards | The other person can start a voluntary exit, or double-sign and cause you to be slashed | Stop the node; never hand these to someone you do not trust |
| Withdrawal Address / Credentials | Receives staked principal and accumulated rewards | The other person can withdraw all funds after exit, but cannot operate the node while it is running | Put it in the inheritance list as the "path to withdraw money" |
Ethereum's withdrawal mechanism is automatic: once you set a withdrawal address, after the node exits, funds are automatically "swept" to that address, and no signing key is needed to sign again. This means the heir can get all assets through the withdrawal address without ever touching the signing key.
Case A: Withdrawal address is an external wallet (EOA)
If you used an external wallet address (such as your MetaMask address) as the withdrawal address, things are much simpler. The heir only needs the seed phrase of this withdrawal wallet. After the node exits, the funds will automatically go to that address, and the heir can transfer them normally.
[What to do]: Put the withdrawal address seed phrase into the inheritance list, and keep it physically separate from the signing key.
[How to do it]:
Confirm the current withdrawal address: enter your validator public key into a block explorer such as Etherscan, and check the withdrawal_credentials field. If the first byte is 0x01, the withdrawal address is already set.
If the withdrawal address is your hardware wallet or software wallet address, treat that wallet's seed phrase as the "final withdrawal credential" in the inheritance list.
The signing key (validator seed phrase or keystore file) is for you to keep running the node while alive, or for a technical executor to stop and exit the node after your death.
[Done when]: The inheritance list clearly separates "signing key (to stop the node)" and "withdrawal wallet seed phrase (to withdraw funds)", and the two items are stored by different people or in different places.
Case B: Withdrawal address is a smart contract (Split Contract / multisig)
Many advanced users use a Split Contract to automatically distribute rewards to multiple addresses, or use a multisig wallet such as Safe as the withdrawal address, so withdrawals require multiple signatures.
If the withdrawal address is a contract, the key inheritance issue is: how to transfer control of the contract.
[What to do]: Confirm who has the admin role (Owner / Controller) of the withdrawal contract, and how to transfer control to the heir.
[How to do it]:
Check whether the withdrawal contract has an owner or controller role. If it is a Safe multisig, check the current signer list and threshold.
If you are the admin, write down the admin's seed phrase or private key in the inheritance list (for later contract changes), or transfer admin rights to the heir's multisig in advance.
If the admin is a Safe multisig, the inheritance list should list all signers and their contact details, and state that "at least X signers must cooperate to withdraw funds."
[Done when]: You clearly understand that if the withdrawal address is a contract, the final step of withdrawal is "calling a contract function", not simply "sweeping to an address."
Note: The Optimistic Withdrawal Recipient contract has a risk: it assumes any incoming amount above 16 ETH is a "principal return" rather than a "reward." If you staked multiple nodes, the heir could misjudge the type of funds if the withdrawal is done incorrectly. It is best to note in the inheritance list: "Contact a professional institution before withdrawing."
Handover Path: What to Do with the Signing Key?
The signing key itself also needs to be handed over, but not to the heir. It should go to a technical executor (the person responsible for stopping the node).
[What to do]: Prepare a "node stop manual" and give it to a technical executor, so they can safely stop the node after your death.
[How to do it]:
Export the validator keystore file and password, and store them on physical media such as an encrypted USB drive.
Write step-by-step instructions:
Stop the validator client (for example, sudo systemctl stop lighthouse-validator).
Export slashing protection data (to prevent double signing).
After confirming the node is stopped, wait about 1-2 epochs (about 15-20 minutes), and check on a block explorer that the validator status has changed to "exited."
Important: never keep the signing key and the withdrawal address seed phrase in the same place at the same time.
[Done when]: The technical executor can complete the node stop and exit without guidance, using only the manual.
Risk Warning
Double signing (slashing) is the biggest risk. If you copy the signing key and give it to the heir, and the heir does not know the old node is still running, a new machine may start and both nodes will sign at the same time. Then you get slashed. At best you lose 1 ETH; at worst you are kicked off the network and lose the entire stake. So the rule for handing over the signing key is: stop the old one first, then give out the new one. Never give the signing key to anyone until you have confirmed the old node is fully stopped.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
How to Verify the Handover Plan
After planning the handover, do a "cold test":
Test stopping the node: On a testnet, run through the full process from "stop the validator client" to "export slashing protection" to "confirm the node has exited" with a test node, and make sure the technical executor understands every step.
Test withdrawal: On a testnet, use a small amount of funds (or a very small amount on mainnet) to test whether the withdrawal address can receive funds normally. Confirm the heir can get money without relying on the signing key.
Check the inheritance list: Make sure the location of the signing key and the location of the withdrawal address seed phrase are recorded as two separate entries, and clearly labeled "signing key = for stopping the node" and "withdrawal address = for withdrawing money."
Check every 12 months that the withdrawal address is still valid (especially if it is a contract address, confirm the contract has not been abandoned), and that the validator withdrawal credentials are still type 0x01 (meaning the withdrawal address is set).
