Consensus Layer Withdrawal Protection

There is a growing community of users that are either concerned or know their Ethereum consensus layer (CL) mnemonic and private keys have been compromised through scams or accidental negligence by the validator owner. If the user has not yet set an execution layer (EL) withdrawal address for their validator, as it was not originally possible, then there will be a race to win the “change withdrawal address” operation (once implemented) if multiple parties posses the CL mnemonic and key. Validator owners who do not know they have been compromised will be quite angry and confused to find out their address has already been permanently changed by an attacker with no warning or recourse. However, if we were to start collecting the proposed change withdrawal addresses early and recommend beacon node clients to implement protective features, we can help avoid this situation for the community.

It is only possible to create conditions which favor (not a guarantee) the rightful owner of the CL mnemonic will win the race without changing core consensus. The most verifiable signal that @mcdee points out is that the rightful owner was both in control of the CL mnemonic and EL deposit address. Using proof of the EL deposit address as part of core consensus for the change withdrawal address operation will not be feasible for a number of reasons, but there are other ways it could be optionally considered in the beacon node in a way that does not change consensus:

  1. If beacon nodes supported and load an optional “Change Withdrawal Address Acceptance File” containing a list of verifiable withdrawal credential and EL deposit address, it would be possible to have the beacon nodes take this data into consideration (see #3)

  2. If beacon nodes support and load an optional “Change Withdrawal Address Broadcast File” containing verifiable lines of change withdrawal address messages, beacon nodes could help automatically broadcast out verified change withdrawal address messages at the right block height when supported, to help spread these message as fast as possible. Additionally, this list can perpetually be used to filter rebroadcasting P2P requests mismatching any requests found in the file.

  3. If beacon nodes were to allow an optional “change withdrawal address rebroadcast delay” parameter, they could delay rebroadcasting messages via P2P that do not match the original deposit address. This would not prevent an attacker from eventually winning, but would give favor to any user who requests their original deposit address or an optional line matching the broadcast file loaded by the client.

All of these ideas would not change core Ethereum consensus, but could provide significant protection to the entire Ethereum community by ensuring Change Withdrawal Address operations favor the requested address of the EL deposit address holder. Even if no data files are provided, clients enabling the “change withdrawal address rebroadcast delay” by default would give other clients who are “certain” they are correct an opportunity to gain consensus likely faster than any attacker could achieve. While attackers could use these features to load their contradictory/malicious content, they would be at no advantage unless they can convince a large amounts of nodes to agree.

No user can be certain that their CL mnemonic and key have not been compromised. It is recommended that anyone who wishes could participate in a social campaign on github to collect verifiable “CLWP Claims”, and client software operators implement these optional measures (and ideally enable them) to help the entire community. Multiple large beacon node operators have expressed interest in enabling such protections as a way to help the entire community. These measures can assist the change withdrawal address is as safe and orderly as possible for all legitimate users. I greatly appreciate any ideas or feedback.


Dear Ben, JGM, and Pietje Puk, Yorik and all other’s who have contributed to this outstanding proposal.

Having studied carefully your Github proposal and discussed this with yourselves, core devs & major staking providers as well as the countless post’s I have seen on Crypto Twitter and Reddit, it is crystal clear this proposal should be implemented to compound extra security to CL keys, in my opinion every Ethereum Staker running a validator node should use this, at a minimum vote for this proposal to protect their fellow Stakers and the integrity of the network. It is our duty to do so, it is our responsibility as node validators.

This is by far the most comprehensive and well thought out EIP for CL key security that has been discussed thus far, and may be the best chance we have to thwart bad actors who have been meticulously preying on targets all over the world with some highly sophisticated phishing and hacking attacks.

The true level of risk to consensus layer keys at this point is unknown, however we do know that many did not use air gapped computer devices to create their keys and so that in itself is a good enough reason to vote for this EIP.

Not only could this protect a node validator who knows for certain they have had a key breach, we sadly know the number of compromised keys could be in the thousands, this proposal may even help Stakehound who had a very unfortunate issue with validator keys for approximately 1193 nodes, not to mention the countless posts on Reddit and Twitter as previously mentioned. Additionally and maybe most importantly we should not underestimate an even bigger risk which is for those poor souls who are completely unaware that their keys have been breached. Without this EIP there is no way for a node validator to know for sure!

I implore the community to do the right thing and vote for this proposal, we have everything to gain from this EIP. Lets do this. WAGMI. Please let’s do our best to protect one another and not allow hackers to undermine the Ethereum protocol, it’s investors and the Ethereum reputation.

I will do everything I can to help your team and this proposal.


Tobes - Vibration Servers


It seems like this proposal really hinges on the idea that attackers can’t easily get access to the block production of a slot. If they do, they can completely bypass this protection layer. I’m curious to know your thoughts on this.

Consensus Layer Withdrawal Protection EIP-4736 has been submitted: Consensus Layer Withdrawal Protection by benjaminchodroff · Pull Request #4736 · ethereum/EIPs · GitHub

Yes, this proposal would not change any consensus itself. If an attacker does get selected as the block production, they can win – and this proposal changes nothing. We are willing to take this chance as, to the best of everyone’s knowledge, the block production selection process is random and we are simply trying to create the most favorable conditions for all legitimate validators.

I do see the value in this proposal at the moment that withdrawals are enabled. There will likely be a race between honest actors who want to rotate their keys, because they suspect they’ve been compromised, and attackers who have compromised certain them. After this initial period, I expect that future compromises will not be noticed in the period of time between the compromise and the attacker gaining access to a block production slot. This is the period of time that this proposal is protecting users against. So if validators aren’t noticing that they are compromised in that time, this proposal will not provide any protection.

1 Like

This proposal would be an excellent additional layer of security to protect one’s assets currently locked into the staking contract. It’s a simple addition to allow proof of validator ownership by referring to one’s deposit based on the Execution Layer, almost like an on-chain 2FA.

You can most definitely be certain that there are quite a lot of stakers whose keys and mnemonics have been compromised silently in the background. I know two people in fact who suspect their validator information has been compromised. The problem is that no one will know until the day withdrawals (or changing of withdrawal addresses) are implemented. I can’t imagine how so many will feel to find out all of their validators have been blind-sided, switched, or withdrawn to some hacker’s account. It wouldn’t seem like this massive attack that has been brewing for years will be a good thing for the Ethereum network as a whole given their outstanding track record thus far (minus the DAO hack of course).

For those who are taking the time running validators and supporting the Ethereum network through their stake, it feels like this would be a fair solution that would allow those who were unable to add a withdrawal address initially to help protect their assets, or at least have a shot at recovering compromised funds. For everyone’s stake, it would make a lot of sense to implement this so that everyone participating can add an extra layer of security to their validators, whether they think they have been compromised or not.

Thank you to all who have put this proposal together. Excellent work! I hope to see this implemented.

1 Like

We have launched a website which documents the Consensus Layer Withdrawal Protection mechanism outlined in EIP-4736. While still under research, we intend to use Kleros as an optional way for any validator owner to be able to request setting their Withdrawal Address in the safest and fastest way possible, once supported. This helps provide optional security and may even prevent a compromised consensus layer seed phrase from resulting in the attacker being able to withdrawal the funds once validator withdrawals are supported.

Here is a proposed outline of how Kleros curated lists on both ETH mainnet and gnosis chains will be used to collect the change withdrawal address operations (still under development):