# Towards enshrining Delegation in Ethereum protocol

## 0.Introduction

Delegation—the process of assigning staking power or governance authority to a third party—is fundamental in many blockchain ecosystems.
Ethereum, however, lacks native delegation support at the protocol level, relying instead on contract-based staking services.
While these services have been effective in attracting capital, they introduce centralization risks and governance challenges.

The goals of this research can be roughly outlined as:

- **Analyze** the current state of delegation across various blockchains.
- **Identify** effective models and challenges that current delegation models face.
- **Propose** improved mechanisms, that can be evaluated by the Ethereum community, proved and stress-tested by
implementation before adopted.

We propose a testable delegation framework for Ethereum, outlining its logic, structure, and implementation pathway.

---

## 1. Current State of Delegation

In Ethereum, delegation is primarily informal and off-chain. Staking services abstract validator responsibilities,offering liquid staking tokens (LSTs) to users.
This results in a natural split of staking in [two classes of participants, outside protocol level](https://notes.ethereum.org/@vbuterin/staking_2023_10#Protocol-and-staking-pool-changes-that-could-improve-decentralization-and-reduce-consensus-overhead):

- **Node Operators**: Manage the validators that execute the protocol and ensure network security.
- **Delegators**: Provide capital but have limited influence over validator selection or governance.

In contrast, other ecosystems like Cosmos, Solana, and Tezos incorporate delegation directly into the protocol, allowing delegators to stake with validators
and participate in governance, including shared slashing risks.

---

## 2. Effective Components in Existing Models

These are elements from Ethereum and other PoS ecosystems that have demonstrated measurable utility or protocol-aligned outcomes.
Their success can be attributed to tangible improvements in usability, capital efficiency, or protocol design alignment.

### ✅ Staking Abstraction

The abstraction of staking mechanics via middleware—most commonly liquid staking protocols (LSPs) such as Lido and Rocket Pool—has significantly lowered the barrier to participation.
Users delegate their stake via a single transaction and receive a derivative token, representing their claim on protocol rewards.

This model has succeeded in onboarding capital from retail users who might otherwise avoid staking due to technical complexity.
It supports a broad base of network contributors, even if it does not give them protocol-level governance.

### ✅ LST Composability

Liquid staking tokens (LSTs) such as stETH or rETH are ERC-20 representations of staked ETH that can be used as collateral or liquidity in DeFi systems while still accruing staking rewards.

This design increases capital efficiency without requiring protocol-level changes. It allows users to remain economically active in the ecosystem while contributing to Ethereum’s consensus.

### ✅ Validator Consolidation (EIP-7251 / Pectra)

Ethereum’s Pectra upgrade introduces EIP-7251, which allows validators to hold balances up to 2048 ETH—far beyond the 32 ETH maximum.
It enables validator consolidation, allowing large operators to manage capital more efficiently while reducing the number of active validators.

This reduces per-slot signature overhead and the churn caused by managing thousands of small validators, improving protocol scalability.
It is an independent improvement, not tied to any delegation model.

### ✅ Protocol-Level Accountability (in Other Chains)

Chains like Cosmos and Tezos implement in-protocol delegation and reward tracking. Delegation relationships are visible to the consensus protocol itself,
allowing for validator selection, performance tracking, and slashing to be enforced directly at the base layer.

This structure has proven effective in aligning delegator incentives and maintaining decentralization through transparent stake distribution.

---

## 3. Identified Challenges

These represent architectural and economic limitations in current Ethereum delegation practices, emerging directly from the performance of today’s delegation models and their impact on network's decentralization and validator dynamics.

### ⚠️ Centralization of Delegation

Delegated stake is highly concentrated in a few liquid staking protocols. This centralization limits protocol-level diversity and validator set autonomy.

When a few entities control a large share of delegation, they effectively control validator selection and, indirectly,consensus resilience.
This creates an oligopolistic structure that undermines Ethereum’s decentralization goals.

### ⚠️ Limited Delegator Influence

Delegators have no protocol-recognized voice in validator selection or governance. Their only recourse is to exit and move their capital elsewhere, often incurring delays and opportunity costs.

Without a mechanism to express validator preferences or governance positions, delegators become economically relevant but politically voiceless.
This reduces the effectiveness of delegation as a security-enhancing mechanism.

### ⚠️ Increased Validator Churn

Validator churn refers to the frequency of validator entries and exits. It is artificially inflated today due to the delegation model’s lack of partial stake reallocation mechanisms.

Without in-protocol support for fast re-delegation, liquid staking protocols must exit validators entirely and create new ones just to reallocate capital.
This causes redundant validator turnover, adding load to the consensus layer (activation queue, exit queue, validator sweep), and increases the total signature verification burden.

While validator consolidation introduced by Pectra's EIP-7251 independently reduces churn, it does not fully resolve churn related to delegation adjustments.
Current delegation models still cause unnecessary churn when stakes shift among validators. The consolidation feature improves scalability, but it remains orthogonal to delegation-specific churn issues.

### ⚠️ Lack of Protocol Visibility into Delegation

Ethereum’s consensus protocol does not track delegation relationships. It does not “see” whether ETH is delegated, to whom, or for how long.

Without visibility, the protocol cannot support delegation-aware validator selection, governance signaling, or censorship resistance enforcement.
This limits its ability to evolve toward more responsive consensus and validator accountability models.

---

## 4. Surrendering the model

We outline a possible delegation model, that integrates delegation in its minimal implementation, but also packs two "nice to have" perks - **protocol-level fast re-delegation** & **early exit liquidity for validators** - and has a built-in compatibility for future incorporation of dynamic validator selection or binding governance enforcement.

### eODS model design notes

eODS(enshrined Operator Delegator Separation) is a possible consensus feature that introduces the separation of Validator role between Operator and Delegator,
functionally adding delegation to Ethereum's consensus layer.

### Actors and Relationships

The following section illustrates the core roles within this delegation model:

#### EL side

- ETH holder as physical entity that provides capital and owns the withdrawal keys
- A Deposit to Delegate Contract
- A Delegation Requests Contract

#### CL side

- Delegator as protocol entity
- Delegated Validator as protocol entity, serving as a wrapper around existing Validator entity, and
- Beacon-chain-accounting, a protocol accounting gadget

It depicts a delegation construction and an internal accounting mechanism, that does not imply altering existing validator duties or current protocol incentives.

#### Capital Flow Diagram


#### Delegation Lifecycle Diagrams

##### Deposit to delegate

**ETH holder**
  └── sends ETH from execution address→ **DEPOSIT_TO_DELEGATE_CONTRACT** (ETH is burned)
       └── Contract emits → DepositToDelegate event
            └── received by → **ConsensusClient** via the execution payload
                 └── creates → DepositToDelegateRequest
                      └── creates new **Delegator** in beacon-chain's delegators registry or 
                          tops-up existing **Delegator**s balance
                            └── links → **ETH holder** ⇄ **Delegator**

##### Delegate to validator

**ETH holder's withdrawal key**
  └── calls **DelegationRequestsContract** → request operation type → delegate_to_validator(...)
       └── received by → **ConsensusClient** via the execution payload
            └── processed during → epoch_transition
                 └── triggers → **beacon-chain-accounting**
                        └── creates new **DelegatedValidator** or
                            tops-up existing **DelegatedValidator**s balance
                              └── links → **DelegatedValidator** ⇄ (existing) target **Validator**
                                   └── updates → **DelegatedValidator**s delegated amount and
                                   **Delegator**s balance

##### Withdraw from validator

**ETH holder's withdrawal key**
  └── calls **DelegationRequestsContract** → request operation type → withdraw_from_validator(...)
       └── received by → **ConsensusClient** via the execution payload
            └── processed during → epoch_transition
                 └── triggers → **beacon_chain_accounting**
                      └── decreases → **DelegatedValidator**s delegated balance by amount
                      └── reads → **Validator**s actual protocol balance
                      └── computes → adjusted withdrawal value incl. rewards, slashing, and fee
                      └── increases → **Delegator**s balance by computed value

##### Withdraw from delegator (to execution address)

**ETH holder's withdrawal key**
  └── calls **DelegationRequestsContract** → request operation type → withdraw_from_delegator(...)
       └── received by → **ConsensusClient** via the execution payload
                 └── triggers → **beacon_chain_accounting**
                      └── creates → withdrawal request
                      └── finalizes → ETH minting to delegator’s address

---

#### Summary of Relationship Roles:

- **ETH holder**: physical entity providing capital, and possessor of the withdrawal credentials.
- ETH holder deposits to **DepositToDelegateContract**
- **Delegator**, as protocol entity is created, or if existing, its balance is topped-up, via `process_deposit_to_delegate_request(...)`
- Delegator is controlled by ETH holder's withdrawal credentials key.
- Delegator is explicitly linked to a **DelegatedValidator** only upon `delegate_to_validator(...)`
- DelegatedValidator wraps around an (existing) target **Validator**
- Consensus clients act as the bridge between execution layer signals and consensus-layer state transitions
- DelegatedValidator registry formalizes the relationship between delegators and delegated validators at protocol level
- **beacon-chain-accounting**: Enshrined accounting gadget responsible for executing delegation lifecycle logic and computing all delegation-related balance updates.

---

### Internal Accounting Model

**Beacon-chain-accounting** has the role of an enshrined accounting module that intermediates delegation state transitions during consensus-layer epoch processing. It is invoked by the protocol during consensus-layer state transitions. It records deposits, withdrawals, and balance movements between delegators and delegated validators.
This architecture ensures that beacon-chain-accounting functions as a protocol gadget — enshrined at protocol level but compatible with future upgrades, including validator role separation or execution proposer dynamics.

Withdrawals can be either partial or complete, with rewards and penalties applied at the time of withdrawal. Real-time reward compounding is not implemented; instead, the state is evaluated upon exit based on the delegated validator's performance.

**beacon-chain-accounting**
  └── invoked by → beacon-chain during state transitions

  └── subroutine → delegate_to_validator(pubkey, amount)
       └── decreases → delegator's balance by amount
       └── increases → delegated validator's delegated balances by amount
       └── updates → delegator quotas for a particular validator

  └── subroutine → withdraw_from_validator(pubkey, amount)
       └── decreases → delegated validator's delegated balances by amount
       └── reads → validator’s current protocol balance
       └── computes → adjusted withdrawal (rewards, penalties, fees)
       └── increases → delegator's balances by computed value

  └── subroutine → withdraw_from_delegator(pubkey, amount)
       └── creates → withdrawal request
       └── finalizes → ETH withdrawal to delegator’s execution-layer address

---

### Delegation Mechanics

Minimal eODS introduces a structured delegation lifecycle that spans the execution layer (EL) and the consensus layer(CL).
Delegation operations are processed through EL-triggered requests that are validated and executed during CL epoch processing. This enables protocol-governed delegation flows.

#### **Execution Layer (EL) Triggers**

At the EL level, users interact with a **Delegation Operations Contract**, a dedicated smart contract inspired from the design of the Withdrawal Request Contract [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) and uses [EIP-7685](https://eips.ethereum.org/EIPS/eip-7685) format for request encoding.
Each delegation-related operation emits an operation request that is committed into the `requests_hash` field of the execution block header.

The supported EL-triggered methods are:

- `delegate_to_validator(pubkey, amount)`
- `withdraw_from_validator(pubkey, amount)`
- `fast_redelegate(src_pubkey → dst_pubkey, amount)`
- `priority_exit(pubkey, amount)`
- `withdraw_from_delegator(pubkey, amount)`

These methods are emit signed requests to be interpreted and validated by the CL during epoch processing, with invalid
requests being discarded without reverting blocks.

---

#### **Consensus Layer (CL) Processing**

On the Consensus Layer, delegation operations are executed during epoch processing using the enshrined beacon-chain-accounting gadget. These operations are triggered by EL-originated requests, committed into the requests_hash of an EL block. During the epoch transition, the CL parses these requests and invokes the corresponding subroutines in beacon-chain-accounting.
All lifecycle logic—such as delegation, reallocation, and withdrawal—is performed as modular accounting operations.
The beacon-chain-accounting module does not initiate state transitions or manage protocol registries directly; it is called by the beacon chain, which orchestrates transitions such as `process_deposit_to_delegate_request(...)`.

Each method implements a single stage in the delegation lifecycle:

| **Request Type** | **CL Handler** | **Functionality** |
|---------------------------|--------------------------------|---------------------------------------------------------------------------------------------|
| `delegate_to_validator` | `delegate_to_validator(...)` | Reduces delegator’s undelegated balance and increases delegated validator’s delegated pool. |
| `withdraw_from_validator` | `withdraw_from_validator(...)` | Computes adjusted withdrawal (incl. rewards, penalties, fees); credits back to delegator. |
| `fast_redelegate` | `fast_redelegate(...)` | Transfers stake between delegated validators without full withdrawal and redeposit. |
| `priority_exit` | `priority_exit(...)` | Allows validator to receive early liquidity via delegator-facilitated transfer. |
| `withdraw_from_delegator` | `withdraw_from_delegator(...)` | Initiates withdrawal of undelegated balance back to delegator's execution address. |

These operations:

- Do not modify validator consensus duties or state
- Operate independently of the validator exit queue
- Only affect delegation-specific balances and records inside the beacon-chain-accounting scope

This architecture preserves Ethereum’s consensus safety assumptions, while introducing native support for flexible delegation tracking and lifecycle management.

---

### Slashing

Slashing is a core security mechanism in proof-of-stake systems, penalizing validator misbehavior such as equivocation or downtime. It protects consensus integrity by imposing economic consequences on actors responsible for critical
failures.

In Ethereum today, slashing applies only to validators. Delegators—typically users of staking pools—are not slashable at the protocol level. Any losses they incur are mediated by the terms of the staking service, not by the protocol itself.

Other ecosystems like Cosmos, Tezos, and Solana implement native delegation tracking and apply slashing proportionally to delegators. This protocol-level linkage ensures that capital suppliers are directly exposed to validator risk, which strengthens alignment but increases passive stakeholder exposure.

In the eODS model, slashing is applied only to delegated validators. Delegators are not directly slashable, but their **withdrawable balance is reduced** if the validator they delegated to, was slashed. Same logic applies to rewards and penalties, that will affect delegator's withdrawable balance.
This enforces accountability without introducing slashing complexity for non-operational participants.

#### Comparison of Slashing Models

| Protocol | Slashing Target | Protocol-Level Delegation | Delegators Slashable | Delegator Impact |
|----------------------|-------------------------|---------------------------|----------------------|-------------------------------------|
| Ethereum (current) | Validators only | ❌ | ❌ | Indirect via pool policies |
| Ethereum (with eODS) | Validators only | ✅ | ❌ | Balance reflects validator slashing |
| Cosmos | Validators & Delegators | ✅ | ✅ | Direct proportional slashing |
| Tezos | Validators & Delegators | ✅ | ✅ | Shared loss on misbehavior |
| Solana | Validators & Delegators | ✅ | ✅ | Delegated stake slashed directly |

This approach allows Ethereum to maintain operational clarity—validators are slashable, delegators are not—while introducing delegation-aware accountability within the protocol.

## 5. Short-Term Implementation Steps

The short-term implementation phase for minimal eODS focuses on introducing low-risk, protocol-compatible mechanisms that track delegations, support reallocation of stake, and enable validator liquidity under constrained conditions.
These mechanisms are enshrined at the protocol's accounting level (via beacon-chain-accounting), without modifying validator consensus duties or altering validator selection, by extending the current protocol to support protocol-visible delegation.
The goal is to establish a minimal, modular base for protocol-level delegation that can be empirically validated and evolved.

---

### Initial Governance Integration

Introduce a minimal, explicit delegation mechanism where delegators can submit non-binding preferences for validators, proportional to their stake. These preferences are not enforceable but are tracked in the consensus state via the`beacon-chain-accounting` module. Delegation mechanics have been presented in the previous chapter. These delegations act as observable preference signals that the protocol can track and study over time.

The mechanism creates protocol-visible delegation data, which can serve as the foundation for more dynamic validator accountability in the future.

---

### Protocol-Level Fast Re-delegation

Protocol-level fast re-delegation allows a delegator to shift part of their delegated stake from one validator to another without performing a full withdrawal followed by a redeposit. This mechanism is implemented via the `fast_redelegate(...)` method in beacon-chain-accounting specs, and is processed during consensus-layer epoch transitions.

- Only balances already delegated to a validator and under protocol control may be re-delegated.
- The system reduces the `delegated_balance` of the source `DelegatedValidator` and increases it for the destination `DelegatedValidator`.
- The delegator’s quota entries are updated accordingly in `delegator_quotas[delegator_index]`, maintaining a proportional share record for both delegated validators.
- Validator balances are read from consensus state (`state.balances[validator_index]`) to ensure consistency with actual validators balances.
- Fast re-delegations rely on a proportional quota model, where the validator’s actual balance is used to normalize delegator shares.
- Re-delegation requests are processed during epoch transitions and may be deferred if embedded request volume exceeds protocol limits.

This design enables efficient reallocation of stake across delegated validators, without triggering validator exits or activation queues, addressing one of the core limitations of delegation via smart contract-based staking pools. It also helps reduce validator churn, preserve network stability, and gives delegators agility in responding to operator performance or governance preferences.

---

### Early Liquidity for Validators

Under constrained conditions, validators may request rapid access to liquidity by drawing from idle (undelegated) balances held by registered delegators. This is implemented via the `priority_exit(...)` method in beacon-chain-accounting specs.

- The validator initiates an early liquidity request. Participating delegators agree to temporarily transfer part of their balance to the validator, against a fee.
- The delegator performs a **partial withdrawal**, which mints ETH to the validator’s address, specified in it's withdrawal credentials.
- The validator, in turn, is expected to repay the delegator from its active balance, via a balance settlement, routed through the validator sweep queue.
- The repayment is not instant—it is handled via the existing protocol withdrawal mechanism, preserving all rate limits and slashing guarantees.

This sub-feature allows validators to access ETH in time-sensitive scenarios (e.g., wanting to exit or cover penalties / liquidations in app layer), without compromising the safety of the consensus or requiring full exits.

These three components form the foundation of the minimal eODS delegation lifecycle. Each is designed to be forward-compatible with future additions such as dynamic validator selection, or stake-weighted inclusion list enforcement.

---

## 6. Medium-Term Objectives

### Incentive Structures for Effective Delegation

In the medium term, Ethereum could begin exploring lightweight incentives tied to validator performance metrics. These incentives could manifest in dynamic reputation-based delegation signals, stake rotation preferences, or fee adjustments.
Drawing from the experience of chains like Cosmos, where validator uptime and misbehavior directly impact delegation decisions, similar mechanisms in Ethereum could encourage validators to maintain high performance and transparency, thereby earning greater delegator trust.

These metrics could be surfaced to delegators through beacon-chain-accounting extensions, allowing rational capital to flow toward reliable operators. This moves Ethereum toward a system where reputation is an economic factor, not just a social one.

### Expanded Governance Signaling from Delegators

As a next logical step after non-binding explicit delegation, the protocol could introduce optional governance signaling mechanisms.

These would enable delegators to express preferences on:

- Validator behavior e.g., related to honest-but-rational behaviour (like playing timing games)
- Participation in inclusion list enforcement (e.g., [FOCIL](https://eips.ethereum.org/EIPS/eip-7805))
- [Dynamic validator or block proposer selection schemes](https://ethresear.ch/t/exploring-sophisticated-execution-proposers-for-ethereum/21386)

These messages would be **signaling-only**—used as input to governance research or eventual protocol-level selection—but would not yet result in automated enforcement. This allows for empirical experimentation and further research, collecting data on what kind of governance expression is meaningful and feasible, before building more opinionated mechanisms.

### Validator Accountability Extensions

To enhance transparency and accountability, the protocol may introduce opt-in metadata exposure from validators. For example, validators could publicly declare:

- Geographic or jurisdictional location
- MEV policies
- Execution infrastructure used (solo, pooled, relayed)

Such self-reported metadata could allow delegators to align their stake with validators matching their values. While participation would remain voluntary, research into its social impact—especially for censorship resistance or diversity enforcement—could inform future developments in decentralized validator selection.

### Enable Delegation-Governed Rotation

With explicit delegation information and basic governance signaling established, research could begin piloting **stake-governed validator rotation mechanisms**.
The goal is to improve validator diversity and responsiveness to community sentiment by enabling low-friction stake reallocation based on validator behavior.

Instead of enforcing hard caps or fixed schedules, the protocol could introduce **soft incentives**—lightweight, non-binding mechanisms that influence delegation flows.

These include:

- Gradual decay of stake delegated to under-performing or non-compliant validators.
- Time-bound delegation signals that must be periodically refreshed.
- Public ranking or visibility metrics that affect delegator choices.

These incentives do not involve slashing or forced exits, but subtly shift economic preference toward validators that align with community goals (e.g. uptime, inclusion list compliance).
They would maintain Ethereum’s modularity and slashing minimalism while enabling governance-responsive delegation.

---

## 7. Long-Term Research Directions

### Binding Delegation-Driven Validator Selection

If empirical data supports it, Ethereum may eventually explore validator selection mechanisms that respond to explicit delegation signals. Under such a system, validator inclusion or priority could be determined (at least partially) by stake-weighted delegator votes.

This could:

- Reinforce validator competition and accountability
- Allow community signaling to shape the validator set
- Encourage protocol-aligned behaviors, like IL compliance

This stage would require rigorous testing, game-theory analysis, and simulations to evaluate resistance to collusion, cartelization, and griefing. Additionally, validator caps, rotation throttles, or economic curve modifications might be
introduced to dampen strategic manipulation. Protocol upgrades such as EIP-7251 and modular consensus roles could support finer-grained selection (e.g., for execution vs finality vs censorship resistance roles).

### Delegation-Based role unbundling

As Ethereum evolves toward validator roles modularity ([unbundling the protocol role of the validator](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683)), enhanced delegation mechanisms could provide a structured way for delegation-based validator role separation, allowing distinct validator roles to emerge under a unified delegation framework.

In such a model, **delegators** would not be limited to supporting FFG-consensus validators. They can also delegate protocol-recognized stake—or **proofs of delegation**—to **a lighter tier of consensus participants**, who participate in non-finality services, such as depicted in [Three tier staking (3TS) research post](https://ethresear.ch/t/three-tier-staking-3ts-unbundling-attesters-includers-and-execution-proposers/21648):

- Inclusion list enforcement
- Whistleblower signals
- Sync committee duties or proposer metadata voting

This bifurcation creates a formal separation between:

| Role Type | Entry Method | Risk Model | Accountability Mechanism |
|--------------------------|------------------------------------|---------------|-------------------------------|
| **Heavy tier Validator** | `delegate_to_validator(...)` | Slashable | Consensus participation (FFG) |
| **Light tier Validator** | `delegate_to_light_validator(...)` | Non-slashable | Delegator governance signals |

Light tier validators are not responsible for attestations or block finality but instead participate in auxiliary service layers essential to protocol liveness and decentralization. Delegators opt into this layer by assigning **non-slashable delegation proofs**, recorded via `beacon-chain-accounting`.

This role unbundling enables:

- Delegation-aligned incentives across diverse protocol functions
- Clear separation of capital risk profiles
- Fine-grained governance expression by delegators

It also sets the stage for future AVS integration, where delegators become **first-class participants** in emerging protocol responsibilities—without requiring external trust assumptions or LST intermediaries.

### Stake Tokenization and Fungibility Integration

As delegation matures, Ethereum might explore the safe enshrinement of tokenized delegation rights—creating **noncustodial delegation receipts** akin to LSTs, but tracked natively by the protocol.

This would enable:

- Fungibility of delegation rights
- Secondary markets for validator preference
- Efficient composability with L2s and dApps

These receipts could be embedded in the beacon state via enhanced beacon-chain-accounting and bounded by strict rate-limiting to ensure protocol stability.
The design challenge would lie in ensuring they do not reintroduce LST-style centralization vectors, while still improving usability and capital efficiency.

Unlike existing LSTs, which abstract validator relationships into ERC-20 wrappers, models that enshrine **illiquid delegation proofs**—protocol-tracked attestations of delegated stake that are visible to dApps and usable as pristine, noncustodial collateral- are not unimaginable with delegation.
This would enable external systems (e.g. DeFi applications) to rely on delegation state without replicating it or introducing custodial risks.
The design direction follows research by V.Buterin and others encouraging in-protocol representation of delegation state, without the liquidity and governance risks posed by off-chain tokenized abstractions.

## 8. Conclusion

While Ethereum's current delegation landscape functions, it obscures complexities, centralizes authority, and lacks traceable governance mechanisms at the protocol level.

This paper presents a delegation model designed to be modular, testable, and aligned with Ethereum's design principles.