Lean Staking is an L1-native, two-phase staking protocol that breaks the public link between Ethereum deposit addresses and consensus layer validator keys. Depositors submit ETH alongside a cryptographic commitment to the staking contract, without revealing any validator keypair. A separate party later claims the deposit by submitting a zero-knowledge proof of commitment ownership, at which point the deposit enters the validator entry queue. The protocol is implemented through changes to the staking contract coupled with a zkSNARK only, requiring no consensus layer modifications.
We benchmark our zkSNARK on a Macbook M1 Pro using LeanVM, a post-quantum, expected to be formally verified, proving system currently developed by the Ethereum Foundation.
We also introduce an optional two-phase withdrawal extension using a new 0x03 withdrawal credential type. It allows validators to break the link between their validator key and their withdrawal address. This enables a direct pending-deposit-to-pending-withdrawal path, preventing privacy-only seeking users to ever activate as a validator. This extension offers two-sided plausible deniability: both sender and recipient perform actions indistinguishable from routine staking operations.
To our knowledge, this is the first construction providing two-sided plausible deniability for private ETH transfers on Ethereum.
I think that idea of making staking a powerful shielding pool for Ethereum has legs. I don’t know if there’s a way to make non-custodial protocols possible here which I think is a must for adoption, though. As proposed, there’s two points in validator lifecycle where there should be a custodial secret holder. maybe there’s a way to make MPC around that and upgrade it to multisig model which is a bit but not the whole way better?
I agree that accommodating non-custodial validation is very important. For a non-custodial arrangement between a staker and a validator to work we need to guarantee two things:
a. Staker or a smart contract can trigger/force withdrawals
b. Staker or a smart contract controls the withdrawal address
The current version of the EIP supports both:
(a) is possible with a pre-signed exit message
(b) is possible trivially by setting the type 0x3 withdrawal credential appropriately (likely to a smart contract).
We could go one step further to support smart contract triggered withdrawals (EIP-7002), either by revealing the withdrawal address or making a ZK proof that the withdrawal request contract has indeed requested withdrawal. Both have non-ideal privacy implication and it requires more exploration.
We will add a discussion about non-custodial validation to the next version of the EIP.
In my mental model, validator shares pub key and withdrawal credential with staker before the initial deposit, so either of them can enqueue a pending deposit and there is no room for validator griefing the full deposit. I am probably missing your point, if so could you please expand?
similar to the deposit flow, withdrawal with type 3 credentials has two phases. The first is exiting the active validator pool (which could happen with a pre-signed exit message shared with staker before making the initial deposit; it doesn’t need a proof), and the second phase is claiming the released funds with a proof. Again assuming the staker knows the withdrawal credential and pub key, they can do the claim.
Nice proposal. I want to raise something on this that is very new.
After Justin Drake’s X post on pivoting away from Poseidon, as drafted it would be the only consensus-critical Poseidon dependency on L1, sitting in an append-only tree with a permanently growing nullifier set.
Not claiming Poseidon is broken. What changed is the proving side: Flock (eprint 2026/1329) does 82,100 BLAKE3 and 42,100 SHA-256 compressions/sec on one M4 Max core. The claim circuit is small enough that this matters. Byte-oriented, it is 68 SHA-256 or 35 BLAKE3 compressions per claim, mostly the depth-32 path, so ~1.6 ms and ~0.4 ms on one core. Against your 0.035 s at N=500, BLAKE3 under Flock on ten cores is around 0.027 s.
The stack underneath this EIP also looks like it is already moving: leanVM-b is a 192-bit binary field variant with a BLAKE2S instruction, benchmarked at 434k compressions/s. So there is a third candidate hash in play, and none of SHA-256, BLAKE2s or BLAKE3 has been named in a spec yet.
Which is why I would suggest versioning the hash rather than swapping it. Briefly: a one-byte suite id in every deposit, claim and 0x03 credential, binding hash, proving system and verifier together; SHA-256 as the mandatory baseline, since SSZ Merkleises with it today and the lean spec’s plan to replace that with Poseidon2 is presumably what the pivot reverses, which would also let the claim circuit constrain deposit_data_root natively rather than taking it as an argument; whatever leanVM lands on as the recommended default; byte-oriented preimages that remove the five field-packing constants; a shielded migrate so deprecating a suite never forces a linkable exit; and domain separation between commitment and nullifier.
If useful, I can share the notes and spec and do this as a PR against 8222 rather than a competing EIP. Would you prefer that?