# EIP-7684: motivation Frontrunning the deposit had been possible from the start; it's enabling a subtle but dangerous bugs that had been found in both Lido and Rocketpool. It opens up staking to unsavory MEV opporunities of significant size. Mitigations for it are expensive and inconvinient, possible mitigations include: - pre-depositing at least 1 ETH and checking it's been deposited before sending the deposit body -- examples: rocketpool, etherfi; I don't know if it happens ouside of LSTs -- downsides: if there's not enough stake coming in the system, validator is stuck with unproductive 1 eth; capital ineffciency. Before BEACON_ROOT, also required a trusted oracle and still runs with oracles in some places. - just-in-time deposit check -- examples: Lido, maybe custodial operators? not open -- downsides: trust model (who does the check?) or extreme costs for ZK-proofs - just winging it -- basically all the rest of the delegated stake (35%+ of stake) -- downsides: being open to the attack Trust-minimized protocols need to develop complex and/or capital inefficient mitigations around this, and with withdrawals introduced there's a way to make a simple-ish mitigation. I don't see any downside or tradeoff to this change, except the impementation effort.