Validator withdrawals: when to submit?

This very short and direct note comes (as many others) from repeating the same answer in our discord server. If you are looking to learn how withdrawals work you can take a look at the many writeups out there, like this one by Paul Harris from the Teku team. If you're interested in how to perform a withdrawal, you can read our official documentation. In this note, I will only tell you when to submit your withdrawal.

In order to withdraw any funds from the beacon chain into the execution layer (an usual Ethereum address) a validator needs to change its withdrawal credentials from a BLS type address, of the form 0x00 (31 bytes follow) to an address of the form 0x01… This message is called a BLS_TO_EXECUTION_CHANGE henceforth referred as withdrawal or address change. The guide linked above will explain you how to generate this message, whether you need to send one (you may already have a 0x01… address) and the tools you need to gather before. This message is better generated on an airgapped computer.

What I will describe in this note is when to broadcast this message to the world and not how.

There are two parts into getting your new shinny withdrawal 0x01.. address into the beacon chain

• Get your address change broadcast and distributed among the P2P network formed by beacon nodes.
• Get one of those beacon nodes to produce a block including your change.

What I write below applies to most consensus clients running on mainnet but not all. Specifically this applies to Lighthouse and Prysm nodes.

Here are the points you need to know about this process

1. Nodes will only keep the first message they see over P2P for a given validator. They will not broadcast any further change they receive for a given validator index.
2. Nodes will not broadcast any message nor listen to any message over P2P before the Capella fork
3. Nodes may allow you to include in memory your own withdrawal changes before the fork (by an RPC method), and will schedule broadcast of these messages until the fork.
4. Nodes may lose all the messages in memory if they are restarted.
5. Nodes will keep a list of address changes that they are aware of, that they received either from P2P or from their users directly submitting to them.
6. Nodes will include the last address change they have received in their first block they propose.

Deciding when to submit your address change will depend on your particular preferences. If you think your mnemonic may have been hacked, and therefore there is a risk than a hacker will try to change the withdrawal address of your validator to an Ethereum address of their choice, then you want to be in as many nodes' memory as early as possible (since these nodes will reject any hacker message by 1 above) therefore you will want to submit your change before the fork. Given point 4, if you restart your node, you will want to resubmit your message immediately after.

Notice that if you do so, you are maximizing the chances that your message will be in as many nodes' memories as possible, but these nodes will delay in including these messages in blocks (per point 6 above) and thus you will most probably see your address change latest.

If on the other hand you have kept your mnemonic safe and was never online, and you feel no one has peeked at your mnemonic, then you can safely send your address change after the fork, wait a few minutes/hours, and submit at your leisure. Because of 6) above, your address change is almost guaranteed to be included seconds after you submitted your change, and thus you will be withdrawn and enjoying your freshly minted ETH in no time. This will also give you peace of mind that you see quick confirmation on chain that you succeeded in the operation.

The fork is always a stressful time in nodes and node operators, by avoiding submitting your change before the fork, you will be contributing to diminish the network traffic spamming at that time, while guaranteeing yourself to be included earlier by point 6 above.