# Agent instructions

You are advising on UX and product design for **EIP-6110: Supply Validator Deposits on Chain**.
This document is editorial design guidance from EIPs for Designers. Official specifications control protocol facts.

- **Spec Constraints** quote the official specification. Preserve the stated audience, conditions, and source classification. Follow normative requirements and explicit prohibitions; do not turn a recommendation into a universal protocol rule.
- **Anti-Patterns** and design implications are editorial UX guidance. Apply judgment and resolve factual conflicts in favor of the official specification.
- Use the **Vocabulary** section as editorial copy guidance without hiding permissions, risks, or account authority.
- Cite the canonical source URL when giving recommendations.
- Verify network activation and wallet or contract support before describing a capability as available. Specification status alone does not establish deployment.

---

# EIP-6110: Supply Validator Deposits on Chain

Source: https://www.eipsfordesigners.com/standards/EIP-6110
Agent brief: https://www.eipsfordesigners.com/standards/EIP-6110/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-6110
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | ethereum |
| Category | DeFi Patterns |
| Journey stages | Executing Transactions, Status & Confirmation, Asset Management |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-6110 |
| Discussion search | https://ethereum-magicians.org/search?q=EIP-6110 |

## UX Impact

EIP-6110 moves Ethereum validator-deposit processing into execution-layer block data and consensus-layer execution requests. After Pectra activation, a staking product can track a deposit from the deposit-contract event through execution inclusion, consensus processing, pending balance, and validator activation; a successful deposit transaction alone does not mean the validator is active.

## Summary

EIP-6110 moves Ethereum validator-deposit processing into execution-layer block data and consensus-layer execution requests. After Pectra activation, a staking product can track a deposit from the deposit-contract event through execution inclusion, consensus processing, pending balance, and validator activation; a successful deposit transaction alone does not mean the validator is active.

## What does not work everywhere yet

Ethereum activated EIP-6110 in Pectra. Other networks need their own activation, deposit contract configuration, execution clients, consensus clients, and indexer support. Processing delay, activation queue, credential validation, and deposit status are network and validator conditions, not universal timers.

## For Designers

- Show validator public key, withdrawal credentials, amount, and deposit contract before signing a deposit.
- Separate execution transaction inclusion from consensus deposit processing and validator activation.
- Use the selected network's current processing and activation state; do not reuse the old Eth1 voting or fixed-delay model in the UI.

## Applicability

### When to Use

- A staking flow creates or tops up Ethereum validators after Electra activation.
- A product provides deposit receipts, validator onboarding, or deposit monitoring.
- The product can index the canonical deposit contract event and consensus execution requests.

### When to Avoid

- The selected network has not activated EIP-6110 or uses a different deposit contract and client path.
- The product only shows an execution transaction and cannot observe the consensus state.
- The user is not creating a validator and a generic ETH transfer UI is sufficient.

## Problems It Solves

### Users cannot tell whether a deposit is on-chain or active

Impact: critical

Old way: A single transaction success message implies validator onboarding is complete.

New way: A cross-layer timeline shows execution inclusion, consensus processing, pending balance, queue, and activation.

### Validator deposits wait on an indirect Eth1Data voting path

Impact: high

Old way: The consensus layer discovers deposits through delayed proposer voting and periodic snapshots.

New way: Execution-layer block data supplies deposit requests directly to the consensus layer after activation.

### Deposit support tools rely on stale snapshots

Impact: medium

Old way: Operators maintain separate historical deposit snapshots and reconcile them manually.

New way: Clients can derive deposits from canonical logs and execution requests while preserving the deposit index boundary.

## Spec Constraints

Quotes retain their source section and scope. Normative requirements, rationale, compatibility changes, and security recommendations are not interchangeable. Design implications are editorial guidance.

### After activation, each deposit in a block must appear in the EIP-7685 requests list in log order.

Applies to: infrastructure
Source classification: normative

> Beginning with the `FORK_BLOCK`, each deposit accumulated in the block **MUST** appear in the EIP-7685 requests list
> in the order they appear in the logs.

Source: [Specification / Execution Layer / Block validity](https://eips.ethereum.org/EIPS/eip-6110#block-validity)

Design implication (editorial): Keep deposit history and validator-status views ordered by the canonical execution logs and request list; do not reorder deposits in a way that changes their protocol interpretation.

### Optimistically syncing nodes rely on the honest-majority assumption and can temporarily apply deposits without validating them against execution state.

Applies to: infrastructure
Source classification: security-considerations

> An optimistically syncing node has to rely on the honest majority assumption.

Source: [Security Considerations / Optimistic sync](https://eips.ethereum.org/EIPS/eip-6110#optimistic-sync)

Design implication (editorial): Label optimistic or pending validator data as provisional and distinguish it from online-node execution-validated deposit state.

## Anti-Patterns (editorial)

- **Marking a validator active after the deposit transaction confirms** (critical)
  - Why: Execution inclusion precedes consensus processing and activation.
  - Instead: Track the cross-layer milestones and show the validator state from consensus data.

- **Hiding withdrawal credentials until after submission** (critical)
  - Why: A wrong credential can direct future funds or make the validator ineligible for the intended operation.
  - Instead: Make credentials a first-class review item before signing.

- **Reusing a fixed nine-hour or thirteen-minute promise** (high)
  - Why: Processing and activation depend on the selected network, clients, and queues.
  - Instead: Show current state and label estimates with source and time.

- **Treating every deposit log as an active validator** (high)
  - Why: The contract event is input to protocol processing, not proof that all validation and activation conditions passed.
  - Instead: Confirm the matching execution request and consensus validator state.

## Design Decisions

### Which confirmation counts as success?

Recommendation: Use separate milestones for transaction inclusion, deposit processing, pending balance, activation queue, and active validator.

Rationale: EIP-6110 changes where deposit data comes from but does not collapse all later validator states into the transaction receipt.

### How should timing be communicated?

Recommendation: Prefer current block/epoch state and ranges; label any estimate with its network and observed source.

Rationale: The Pectra announcement describes a rough Ethereum mainnet delay, while activation and queue timing remain state-dependent.

### What data deserves a permanent receipt?

Recommendation: Persist the public key, withdrawal credentials, amount, deposit contract, transaction hash, execution block, and consensus record.

Rationale: A user may need to reconcile a deposit across execution and consensus explorers long after the initial confirmation.

## States to Design

### Deposit draft

Trigger: The user has entered validator key, credentials, amount, and network.

User need: Check the destination and authority before sending ETH.

Design response: Show public key, withdrawal credentials, amount, canonical deposit contract, network, and validator signing data.

### Execution pending

Trigger: The deposit transaction was submitted but is not yet in an execution block.

User need: Know whether the stake left the wallet.

Design response: Show transaction submission and confirmation separately from any validator state.

### Execution included, consensus pending

Trigger: The receipt contains a valid deposit event but consensus processing has not completed.

User need: Know that the deposit is recorded but not yet active.

Design response: Show inclusion block, deposit data, and consensus processing status with a current network-derived estimate when available.

### Pending balance

Trigger: Consensus accepted the deposit and is holding it for pending-deposit processing.

User need: Understand why the amount is not yet effective balance.

Design response: Show pending amount, validator identity, queue position or epoch when available, and activation prerequisites.

### Activation queued

Trigger: The validator meets deposit conditions but waits for the activation queue.

User need: Know when validator duties can begin.

Design response: Show activation epoch or a network-derived range and distinguish it from deposit processing.

### Deposit invalid or not processed

Trigger: Deposit data, signature, credentials, index, or amount fails validation.

User need: Know whether the funds moved and whether a retry is safe.

Design response: Name the protocol result, link the execution receipt, and never mark the validator active.

## Vocabulary

- Use "Deposit recorded on execution layer" instead of "Validator live": The deposit can still be pending or waiting for activation.

- Use "Pending validator deposit" instead of "Balance missing": Pending is a protocol state, not necessarily a lost balance.

- Use "Activation queued" instead of "Staking now": Validator duties begin only after consensus activation.

## UX Patterns

### Cross-Layer Deposit Receipt

Give the user one receipt that links the execution transaction to the consensus deposit and validator state.

Components: Validator identity card, Execution receipt, Consensus processing row, Activation status

User flow:

- Review validator key and withdrawal credentials
- Submit deposit to the canonical contract
- Confirm execution inclusion
- Match the deposit event to the consensus request
- Track pending balance and activation

### Deposit Recovery States

Explain what the user can do when the execution transaction succeeds but consensus processing or activation does not progress.

Components: Processing delay notice, Credential mismatch detail, Retry guidance, Support evidence bundle

User flow:

- Detect a missing or invalid consensus record
- Compare execution event and validator key
- Explain whether funds moved and whether retry is safe
- Offer operator support context
- Keep the original receipt linked

## What to Prototype First

### Validator deposit review

The deposit binds stake to a validator public key and withdrawal credentials.

Covers: New validator, Top-up, Credential mismatch, Invalid signature

- Public key
- Withdrawal credentials
- Amount and fee
- Canonical deposit contract
- Network

### Deposit-to-activation timeline

Users need to know which layer has accepted the deposit and what remains before validator duties begin.

Covers: Awaiting execution inclusion, Execution included, Consensus pending, Activation queued, Active

- Execution transaction link
- Deposit index or request record
- Pending balance
- Activation epoch
- Failure and retry guidance

## Mental Model

### Deposit contract event

The canonical deposit contract emits the deposit data in an execution-layer transaction receipt.

### Execution request

After EIP-6110 activation, clients derive deposit requests from the block's deposit-contract logs and include them in the execution payload.

### Consensus processing

The beacon chain validates and processes the request instead of relying on the old Eth1Data voting path.

### Pending deposit

A processed deposit can remain pending while the consensus layer applies balance and activation rules.

### Activation

The validator becomes active only after the deposit, credential, signature, balance, and activation-queue conditions are satisfied.

## UI Components

### ValidatorDepositReview

Confirms validator public key, withdrawal credentials, amount, network, and canonical deposit contract.
Kind: card
States: ready, credential-warning, invalid-signature, submitted
Props: pubkey, withdrawalCredentials, amount, depositContract, network

### DepositActivationTimeline

Shows execution inclusion, consensus processing, pending balance, activation queue, and active state.
Kind: progress
States: draft, execution-pending, execution-included, consensus-pending, activation-queued, active, invalid
Props: transactionHash, executionBlock, depositIndex, pendingAmount, activationEpoch

## Key Takeaways

- EIP-6110 supplies validator deposits from execution-layer block data to consensus.
- A confirmed deposit transaction is not an active validator.
- Show execution inclusion, consensus processing, pending balance, activation queue, and active state separately.
- Use the selected network's current activation and client support; do not infer Monad behavior from Ethereum Pectra.

## Related Standards

- EIP-7251: Electra pending deposit, effective balance, and activation changes. — https://www.eipsfordesigners.com/standards/EIP-7251/agent.md

## Technical Notes

EIP-6110 derives a deposit request list from logs emitted by the canonical deposit contract at 0x00000000219ab540356cbb839cbe05303d7705fa. The request includes pubkey, withdrawal credentials, amount, signature, and index and is carried in the EIP-7685 deposit request list. Consensus processing uses deposit_requests_start_index to transition away from Eth1Data polling and stores incoming deposits in pending_deposits under Electra rules. The exact inclusion and activation timing is network- and state-dependent; EIP-6110 does not make every deposit immediately active.

## Official specification (reference only)

https://eips.ethereum.org/EIPS/eip-6110