# EIP-8205: Towards safe delegated staking deposits

**URL:** <https://research.lido.fi/t/eip-8205-towards-safe-delegated-staking-deposits/11357>\
**Category:** General\
**Created:** [March 27, 2026, 2:39pm UTC](https://research.lido.fi/t/eip-8205-towards-safe-delegated-staking-deposits/11357 "2026-03-27T14:39:13Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![FP\_Validated](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/fp_validated/32/6725_2.png) [@FP\_Validated](https://research.lido.fi/u/FP_Validated)\
**Post date:** [March 30, 2026, 3:12am UTC](https://research.lido.fi/t/eip-8205-towards-safe-delegated-staking-deposits/11357/2 "2026-03-30T03:12:49Z")

</div>

I believe it is highly valuable direction in the long term in that it attempts to address the deposit race issue at the protocol level - it could significantly reduce existing security uncertainties and remove structural hurdles across various staking products.

That said, for implementation & consideration, it would be beneficial to address the following from my view:

* * *

### 1. Standardization Risk

EIP-8205 seems to effectively shift deposit security from being the responsibility of individual protocols to the Ethereum protocol itself. While this is a clear advantage, it also represents a transition from distributed risk to concentrated risk.

Previously, each staking protocol implemented its own deposit protection mechanisms, meaning failures were generally isolated. With EIP-8205 as a shared standard, however, even minor flaws in validation logic or ambiguities in the specification could propagate into ecosystem-wide failures.

Moreover, standardization introduces more than just code consolidation - it also brings potential risks such as **implementation divergence across clients** and **reduced flexibility in future upgrades**. For a primitive as critical as deposit—where ultimate ownership of assets is determined—this represents a fundamental shift from a system that can “fail in many places independently” to one that “ **must be correct everywhere**.”

In that sense, this is not simply a trade-off between efficiency and safety, but rather a move away from fault isolation toward systemic correctness.

* * *

### 2. EIP-4788 State Dependency

EIP-8205 relies on EIP-4788. This is a meaningful advancement, as it removes the need for off-chain trust when validating validator state. However, it also introduces a new class of potential risk stemming from temporal asynchrony between the consensus and execution layers(Correct me if I’m wrong! 🙏).

For example, issues such as slot timing mismatches, update latency between the execution and consensus layers, and potential reorg scenarios can create situations where:

- an intent is generated based on one state,

- but executed against another.

As a result, correctness becomes dependent not only on _what_ is being verified, but also on _when_ it is verified—making **state freshness and timing assumptions critical design considerations**.

* * *

But again, I strongly believe that protocol systems should remain simple - I fully support this direction and really appreciate the proposal.

---

_[View the full topic](https://research.lido.fi/t/eip-8205-towards-safe-delegated-staking-deposits/11357)._