{"id":"EIP-6110","name":"Supply Validator Deposits on Chain","status":"Final","chain":"ethereum","category":{"id":"defi","name":"DeFi Patterns","description":"Vaults, bonds, and financial primitives"},"journeyStages":[{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"},{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"},{"id":"management","name":"Asset Management","description":"Managing assets over time"}],"uxImpact":"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.","slug":"eip-6110","officialUrl":"https://eips.ethereum.org/EIPS/eip-6110","sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-6110","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-6110","type":"discussion"},{"label":"Pectra mainnet announcement","url":"https://blog.ethereum.org/2025/04/23/pectra-mainnet","type":"reference"},{"label":"Electra consensus specification","url":"https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md","type":"implementation"},{"label":"EIP-7685 official specification","url":"https://eips.ethereum.org/EIPS/eip-7685","type":"official-spec"},{"label":"EIP-4895 official specification","url":"https://eips.ethereum.org/EIPS/eip-4895","type":"official-spec"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","hasDetailedContent":true,"content":{"id":"EIP-6110","sources":[{"label":"EIP-6110 official specification","url":"https://eips.ethereum.org/EIPS/eip-6110","type":"official-spec"},{"label":"Pectra mainnet announcement","url":"https://blog.ethereum.org/2025/04/23/pectra-mainnet","type":"reference"},{"label":"Electra consensus specification","url":"https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md","type":"implementation"},{"label":"EIP-7685 official specification","url":"https://eips.ethereum.org/EIPS/eip-7685","type":"official-spec"},{"label":"EIP-4895 official specification","url":"https://eips.ethereum.org/EIPS/eip-4895","type":"official-spec"}],"lastReviewed":"2026-09-18","specConstraints":[{"id":"deposit-request-order","constraint":"After activation, each deposit in a block must appear in the EIP-7685 requests list in log order.","appliesTo":"infrastructure","normativity":"normative","specQuote":"Beginning with the `FORK_BLOCK`, each deposit accumulated in the block **MUST** appear in the EIP-7685 requests list\nin the order they appear in the logs.","specSection":"Specification / Execution Layer / Block validity","specUrl":"https://eips.ethereum.org/EIPS/eip-6110#block-validity","designImplication":"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."},{"id":"optimistic-sync-trust","constraint":"Optimistically syncing nodes rely on the honest-majority assumption and can temporarily apply deposits without validating them against execution state.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"An optimistically syncing node has to rely on the honest majority assumption.","specSection":"Security Considerations / Optimistic sync","specUrl":"https://eips.ethereum.org/EIPS/eip-6110#optimistic-sync","designImplication":"Label optimistic or pending validator data as provisional and distinguish it from online-node execution-validated deposit state."}],"lastUpdated":"2026-09-18","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.","partialDeployment":{"body":"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."},"designerTakeaways":["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":{"whenToUse":["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."],"whenToAvoid":["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."]},"prototypeFirst":[{"screen":"Validator deposit review","why":"The deposit binds stake to a validator public key and withdrawal credentials.","covers":["New validator","Top-up","Credential mismatch","Invalid signature"],"include":["Public key","Withdrawal credentials","Amount and fee","Canonical deposit contract","Network"]},{"screen":"Deposit-to-activation timeline","why":"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"],"include":["Execution transaction link","Deposit index or request record","Pending balance","Activation epoch","Failure and retry guidance"]}],"mentalModel":[{"label":"Deposit contract event","description":"The canonical deposit contract emits the deposit data in an execution-layer transaction receipt."},{"label":"Execution request","description":"After EIP-6110 activation, clients derive deposit requests from the block's deposit-contract logs and include them in the execution payload."},{"label":"Consensus processing","description":"The beacon chain validates and processes the request instead of relying on the old Eth1Data voting path."},{"label":"Pending deposit","description":"A processed deposit can remain pending while the consensus layer applies balance and activation rules."},{"label":"Activation","description":"The validator becomes active only after the deposit, credential, signature, balance, and activation-queue conditions are satisfied."}],"statesToDesign":[{"state":"Deposit draft","trigger":"The user has entered validator key, credentials, amount, and network.","userNeed":"Check the destination and authority before sending ETH.","designResponse":"Show public key, withdrawal credentials, amount, canonical deposit contract, network, and validator signing data."},{"state":"Execution pending","trigger":"The deposit transaction was submitted but is not yet in an execution block.","userNeed":"Know whether the stake left the wallet.","designResponse":"Show transaction submission and confirmation separately from any validator state."},{"state":"Execution included, consensus pending","trigger":"The receipt contains a valid deposit event but consensus processing has not completed.","userNeed":"Know that the deposit is recorded but not yet active.","designResponse":"Show inclusion block, deposit data, and consensus processing status with a current network-derived estimate when available."},{"state":"Pending balance","trigger":"Consensus accepted the deposit and is holding it for pending-deposit processing.","userNeed":"Understand why the amount is not yet effective balance.","designResponse":"Show pending amount, validator identity, queue position or epoch when available, and activation prerequisites."},{"state":"Activation queued","trigger":"The validator meets deposit conditions but waits for the activation queue.","userNeed":"Know when validator duties can begin.","designResponse":"Show activation epoch or a network-derived range and distinguish it from deposit processing."},{"state":"Deposit invalid or not processed","trigger":"Deposit data, signature, credentials, index, or amount fails validation.","userNeed":"Know whether the funds moved and whether a retry is safe.","designResponse":"Name the protocol result, link the execution receipt, and never mark the validator active."}],"designDecisions":[{"question":"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."},{"question":"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."},{"question":"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."}],"problemsSolved":[{"problem":"Validator deposits wait on an indirect Eth1Data voting path","oldWay":"The consensus layer discovers deposits through delayed proposer voting and periodic snapshots.","newWay":"Execution-layer block data supplies deposit requests directly to the consensus layer after activation.","impact":"high"},{"problem":"Users cannot tell whether a deposit is on-chain or active","oldWay":"A single transaction success message implies validator onboarding is complete.","newWay":"A cross-layer timeline shows execution inclusion, consensus processing, pending balance, queue, and activation.","impact":"critical"},{"problem":"Deposit support tools rely on stale snapshots","oldWay":"Operators maintain separate historical deposit snapshots and reconcile them manually.","newWay":"Clients can derive deposits from canonical logs and execution requests while preserving the deposit index boundary.","impact":"medium"}],"uxPatterns":[{"name":"Cross-Layer Deposit Receipt","description":"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"],"userFlow":["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"]},{"name":"Deposit Recovery States","description":"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"],"userFlow":["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"]}],"uiComponents":[{"name":"ValidatorDepositReview","description":"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"]},{"name":"DepositActivationTimeline","description":"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"]}],"antiPatterns":[{"pattern":"Marking a validator active after the deposit transaction confirms","why":"Execution inclusion precedes consensus processing and activation.","instead":"Track the cross-layer milestones and show the validator state from consensus data.","severity":"critical"},{"pattern":"Reusing a fixed nine-hour or thirteen-minute promise","why":"Processing and activation depend on the selected network, clients, and queues.","instead":"Show current state and label estimates with source and time.","severity":"high"},{"pattern":"Hiding withdrawal credentials until after submission","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.","severity":"critical"},{"pattern":"Treating every deposit log as an active validator","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.","severity":"high"}],"vocabulary":[{"use":"Deposit recorded on execution layer","avoid":"Validator live","why":"The deposit can still be pending or waiting for activation."},{"use":"Pending validator deposit","avoid":"Balance missing","why":"Pending is a protocol state, not necessarily a lost balance."},{"use":"Activation queued","avoid":"Staking now","why":"Validator duties begin only after consensus activation."}],"technicalNotes":"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.","relatedStandards":[{"id":"EIP-7251","relationship":"Electra pending deposit, effective balance, and activation changes."}],"keyTakeaways":["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."]},"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-6110","markdown":"https://www.eipsfordesigners.com/standards/EIP-6110/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-6110/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-6110","official":"https://eips.ethereum.org/EIPS/eip-6110","discussion":"https://ethereum-magicians.org/search?q=EIP-6110"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}