{"id":"EIP-7002","name":"Execution Layer Triggerable Withdrawals","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-7002 supplies the execution-layer request path for validator exits and withdrawals. Under Electra's integrated processing, a request whose source address matches a validator's 0x01 or 0x02 execution withdrawal credential can request a full exit with amount=0; a positive amount requests a partial withdrawal only for a 0x02 compounding credential when effective balance is at least 32 ETH and balance exceeds 32 ETH plus pending partial withdrawals. Ethereum activated the path in Pectra; requests enter an execution-layer queue, pay a dynamic request fee, and are then processed by the consensus layer.","slug":"eip-7002","officialUrl":"https://eips.ethereum.org/EIPS/eip-7002","sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-7002","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-7002","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-7002","specConstraints":[{"id":"eip-7002-current-fee-query","constraint":"The withdrawal request contract exposes the current required fee when queried with zero-length input.","appliesTo":"application","normativity":"normative","specQuote":"2. Fee getter - if the input length is zero, return the current fee required to add a withdrawal request.","specSection":"Specification — Execution layer — Withdrawal Request Contract","specUrl":"https://eips.ethereum.org/EIPS/eip-7002#withdrawal-request-contract","designImplication":"Refresh the fee immediately before the request review and show the amount used for the transaction. Treat a cached estimate as provisional, not as a guaranteed charge."},{"id":"eip-7002-withdrawal-credential-authority","constraint":"The address that calls the withdrawal request contract must match the validator's recorded 0x01 withdrawal credential.","appliesTo":"application","normativity":"security-considerations","specQuote":"the address that calls the system contract must match the 0x01 withdrawal credential recorded in the beacon state.","specSection":"Security Considerations — Fee Overpayment","specUrl":"https://eips.ethereum.org/EIPS/eip-7002#fee-overpayment","designImplication":"Show the actual request source, credential prefix, validator public key, and eligibility result before submission. Do not present an execution address as sufficient authority without the credential match."},{"id":"eip-7002-fee-not-refunded","constraint":"Overpaid withdrawal-request fees are not returned to the caller.","appliesTo":"application","normativity":"security-considerations","specQuote":"Overpaid fees are not returned to the caller.","specSection":"Security Considerations — Fee Overpayment","specUrl":"https://eips.ethereum.org/EIPS/eip-7002#fee-overpayment","designImplication":"Refresh the dynamic request fee before confirmation, show a user-selected maximum, and make any estimate-versus-inclusion risk explicit. A successful transaction does not mean excess fee was recoverable."},{"id":"eip-7002-predeploy-readiness","constraint":"The withdrawal-request path must not be treated as active on a chain whose predeploy code is missing.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"This EIP should not have been activated if there is no code present at `WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS` (i.e., if the chain is not \"ready\").","specSection":"Security Considerations — Empty Code failure","specUrl":"https://eips.ethereum.org/EIPS/eip-7002#empty-code-failure","designImplication":"Gate controls on verified network activation and predeploy readiness. If the chain is not ready, explain that the protocol path is unavailable instead of letting a user sign a request that can invalidate blocks or fail."},{"id":"eip-7002-custody-exit-authority","constraint":"Withdrawal credentials ultimately own the validator funds and can naturally authorize an exit request.","appliesTo":"application","normativity":"security-considerations","specQuote":"The withdrawal credentials ultimately own the funds so allowing them to exit staking is natural with respect to ownership.","specSection":"Security Considerations — Impact on existing custody relationships","specUrl":"https://eips.ethereum.org/EIPS/eip-7002#impact-on-existing-custody-relationships","designImplication":"Make the withdrawal credential and its authority visible in custody or staking products. Do not assume an existing custody arrangement is safe merely because the validator operator, rather than the credential owner, controls day-to-day activity."},{"id":"eip-7002-cold-credential-recovery","constraint":"Custody flows SHOULD let the withdrawal-credential holder recover funds when active keys are lost.","appliesTo":"application","normativity":"rationale","specQuote":"Additionally, in the event that active keys are lost, a user should still be able to recover their funds by using their cold withdrawal credentials.","specSection":"Motivation","specUrl":"https://eips.ethereum.org/EIPS/eip-7002#motivation","designImplication":"Make cold-credential recovery an explicit custody path, showing which credential can initiate the exit and separating recovery availability from the validator operator's hot-key status."}],"sources":[{"label":"EIP-7002 official specification","url":"https://eips.ethereum.org/EIPS/eip-7002","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","lastUpdated":"2026-09-18","summary":"EIP-7002 supplies the execution-layer request path for validator exits and withdrawals. Under Electra's integrated processing, a request whose source address matches a validator's 0x01 or 0x02 execution withdrawal credential can request a full exit with amount=0; a positive amount requests a partial withdrawal only for a 0x02 compounding credential when effective balance is at least 32 ETH and balance exceeds 32 ETH plus pending partial withdrawals. Ethereum activated the path in Pectra; requests enter an execution-layer queue, pay a dynamic request fee, and are then processed by the consensus layer.","partialDeployment":{"body":"Pectra mainnet activation supports the feature on Ethereum, while other networks need their own fork activation and predeploy configuration. A staking product must verify the selected network, the actual request source (msg.sender may be an EOA or contract), credential type, amount mode, validator state, request fee, queue state, and client/indexer data before showing an actionable control."},"designerTakeaways":["Offer a full exit only when the request source matches a validator's 0x01 or 0x02 execution credential; offer a positive partial amount only for a 0x02 credential with the required balance conditions.","Show whether amount=0 means full exit or a positive Gwei amount means partial withdrawal, along with the request fee, validator public key, queue status, and consensus processing.","Treat a submitted request as pending until the consensus layer accepts it; an execution transaction alone does not prove an exit or withdrawal occurred."],"applicability":{"whenToUse":["A staking product manages Ethereum validators with 0x01 or 0x02 execution withdrawal credentials and can submit the request through the actual source address.","A pool, DAO, or custodian lets the withdrawal-credential owner initiate full exits or eligible 0x02 partial withdrawals.","The product can read execution requests and validator state from both layers."],"whenToAvoid":["The validator still has a BLS withdrawal credential and no supported credential-update path, or the request source cannot be matched to the credential.","The selected network has not activated EIP-7002 or the withdrawal-request predeploy is not configured.","The product cannot distinguish amount=0 full exits from positive 0x02 partial requests, or cannot distinguish an execution transaction, queued request, consensus acceptance, and eventual balance change."]},"prototypeFirst":[{"screen":"Validator withdrawal control","why":"The user must choose amount=0 for a full exit or a positive Gwei amount for an eligible 0x02 partial withdrawal while understanding authority and timing.","covers":["Eligible 0x01 or 0x02 full-exit validator","Eligible 0x02 partial-withdrawal validator","Insufficient excess or pending partials","BLS credential or already exiting"],"include":["Validator public key and index","Withdrawal credential type","Amount mode: 0 for full exit or positive Gwei for partial","Actual request source address (EOA or contract)","32 ETH floor and pending partial-withdrawal balance"]},{"screen":"Request fee and queue review","why":"The execution request is rate-limited and can wait before consensus processing; a positive partial request can also be unavailable when the partial queue or balance conditions do not allow it.","covers":["Fee quote","Queue pending","Request processed","Invalid request"],"include":["Current request fee","Fee limit","Execution transaction link","Consensus status"]}],"mentalModel":[{"label":"Withdrawal authority","description":"Electra compares the request source address recorded from msg.sender (which may be an EOA or contract) with the validator credential. 0x01 or 0x02 credentials can request a full exit; positive partial requests require 0x02."},{"label":"Execution request","description":"A transaction calls the withdrawal-request predeploy with a validator public key and uint64 amount in Gwei, paying the current request fee. Amount 0 signals a full exit; a positive amount asks for a partial withdrawal subject to consensus rules."},{"label":"Request queue","description":"The execution layer queues requests so many calls can be accepted even though only a bounded number are passed to consensus per block."},{"label":"Consensus processing","description":"The consensus layer validates each request against validator state; an invalid request can be ignored without making the whole block invalid."},{"label":"Withdrawal or exit","description":"A valid amount=0 request starts an exit, while a valid positive request queues a bounded partial withdrawal; the eventual balance credit and exit completion are later states."}],"statesToDesign":[{"state":"Full exit eligible","trigger":"The validator is active, has a 0x01 or 0x02 execution credential, the actual request source matches its credential, and amount=0 is allowed with no pending withdrawal balance blocking the exit.","userNeed":"Know that this account has the authority to request the action.","designResponse":"Show the actual source address, credential prefix, validator public key, amount=0 full-exit mode, and any remaining validator-state prerequisite."},{"state":"Partial withdrawal eligible","trigger":"The validator is active, has a 0x02 compounding credential, effective balance is at least 32 ETH, balance exceeds 32 ETH plus pending partial withdrawals, and the request source matches.","userNeed":"Know how much excess balance can be requested without implying an immediate cash-out.","designResponse":"Show the 32 ETH floor, pending partial-withdrawal amount, available excess, positive Gwei amount, and the separate partial-withdrawal queue."},{"state":"Credential not eligible","trigger":"The credential is BLS, the actual request source does not match, or network support is missing.","userNeed":"Understand why the action is unavailable.","designResponse":"Explain the exact prerequisite and link to a separate credential-update or operator flow when one exists."},{"state":"Partial amount unavailable","trigger":"A positive amount was selected but the validator lacks a 0x02 compounding credential, has less than 32 ETH effective balance, has no excess above 32 ETH plus pending partial withdrawals, or the partial queue is full.","userNeed":"Understand why a full exit may remain available while a partial amount is not.","designResponse":"Keep the full-exit and partial-withdrawal states separate, show the failed condition, and do not silently turn a positive amount into amount=0."},{"state":"Fee quote expired","trigger":"The dynamic request fee changed before transaction inclusion.","userNeed":"Avoid overpaying or sending a request that reverts.","designResponse":"Refresh the fee, show the user's maximum fee policy, and require a new confirmation."},{"state":"Execution request queued","trigger":"The transaction is included and the request is waiting for consensus processing.","userNeed":"Know that the action has not completed yet.","designResponse":"Show execution inclusion separately from consensus processing and provide an estimated range only when the network supplies one."},{"state":"Consensus request rejected","trigger":"The validator is unknown, inactive, already exiting, has pending balance that blocks a full exit, or a positive request fails the 0x02 compounding or excess-balance checks.","userNeed":"Know whether a retry can work and whether fees were spent.","designResponse":"Name the protocol result, link the execution and validator records, and avoid presenting it as a completed withdrawal."},{"state":"Exit or partial withdrawal progressing","trigger":"Consensus accepted the request and assigned the relevant queue state.","userNeed":"Track when funds or validator status will change.","designResponse":"Show the validator's exit or withdrawal queue state, then show the eventual execution-layer credit separately."}],"designDecisions":[{"question":"Who may request the action?","recommendation":"Gate the control on the actual request source and credential match, allowing a direct EOA or a contract call; use 0x01 or 0x02 for full exit and 0x02 for positive partial requests.","rationale":"The predeploy stores msg.sender as source_address, and consensus compares that address with the credential before applying the amount-specific rules."},{"question":"How should full exit and partial withdrawal differ?","recommendation":"Use amount=0 for full exit and a separate positive Gwei amount control for 0x02 partial withdrawal; explain whether the validator remains active and show the 32 ETH floor.","rationale":"Electra treats amount=0 as a full-exit signal, while positive amounts are capped by available excess above 32 ETH and pending partial withdrawals and require a compounding credential."},{"question":"How much timing should the UI promise?","recommendation":"Show live queue and consensus state; use ranges only when derived from the selected network and validator state.","rationale":"Request fees and churn queues are network conditions, not a fixed user-facing SLA."}],"problemsSolved":[{"problem":"Withdrawal-credential owners depend on the active validator key to exit","oldWay":"The operator must sign an exit or provide pre-signed material to the funds' owner.","newWay":"A matching 0x01 or 0x02 request source can request a full exit; only a matching 0x02 compounding credential can request an eligible positive partial amount.","impact":"critical"},{"problem":"Pool and custody products cannot expose a direct owner-controlled exit path","oldWay":"Users wait for an operator workflow with unclear authority and status.","newWay":"A product can show the actual source and credential match, amount mode, request fee, queue, consensus result, and eventual withdrawal state.","impact":"high"},{"problem":"Execution inclusion is mistaken for staking completion","oldWay":"Show a transaction success toast after calling the predeploy.","newWay":"Track execution inclusion, consensus validation, exit or withdrawal queue, and balance credit as distinct states.","impact":"high"}],"uxPatterns":[{"name":"Credential-Gated Exit Control","description":"Reveal amount=0 full-exit and positive 0x02 partial-withdrawal actions only after verifying the actual request source, credential, validator state, and balance conditions.","components":["Validator identity card","Credential match badge","Amount selector","Exit/withdrawal choice"],"userFlow":["Select a validator","Read withdrawal credential and actual request source (EOA or contract)","Check validator state and available amount","Choose amount=0 full exit or a positive Gwei partial withdrawal when eligible","Review validator key, amount, fee, and destination","Submit the execution request"]},{"name":"Two-Layer Request Timeline","description":"Separate the execution transaction from queueing, consensus validation, and eventual funds movement.","components":["Execution receipt","Request queue row","Consensus result","Withdrawal credit row"],"userFlow":["Read the current request fee","Submit and confirm the execution transaction","Wait for request inclusion in the execution payload","Track consensus processing and validator queue","Show the eventual withdrawal or exit result"]}],"uiComponents":[{"name":"ValidatorAuthorityCard","description":"Shows validator identity, withdrawal credential type, actual request source (EOA or contract), and authority match.","kind":"card","states":["eligible","address-mismatch","bls-credential","unsupported-network","already-exiting"],"props":["validatorPubkey","validatorIndex","withdrawalCredential","requestSource","network"]},{"name":"WithdrawalRequestTimeline","description":"Tracks request fee, execution inclusion, consensus processing, queue state, and final credit.","kind":"progress","states":["fee-loading","submitted","queued","processed","rejected","completed"],"props":["requestId","executionTxHash","consensusStatus","validatorState","destination"]}],"antiPatterns":[{"pattern":"Showing the same partial action for every validator","why":"Full exits accept amount=0 for matching 0x01 or 0x02 execution credentials, but positive partial amounts require 0x02, at least 32 ETH effective balance, and excess above the floor plus pending partials.","instead":"Feature-detect network activation, match the actual request source to the credential, and calculate full versus partial eligibility separately.","severity":"critical"},{"pattern":"Calling execution inclusion a completed withdrawal","why":"Consensus processing and validator queues still determine the outcome.","instead":"Separate execution, consensus, and balance-credit states.","severity":"critical"},{"pattern":"Quoting a fixed request fee or completion time","why":"The request fee changes with queue usage and the exit/withdrawal path is rate-limited.","instead":"Fetch the current fee and show network-derived queue status.","severity":"high"},{"pattern":"Hiding the validator public key in the confirmation","why":"One execution address can control more than one validator, so the key disambiguates the target.","instead":"Show the validator public key and index alongside the execution address.","severity":"high"}],"vocabulary":[{"use":"Request a full exit","avoid":"Withdraw now","why":"Amount=0 signals a full exit request; the consensus-layer process and eventual withdrawal still happen later."},{"use":"Request a partial withdrawal","avoid":"Cash out","why":"A positive Gwei amount is available only for eligible 0x02 compounding validators and may leave the validator active."},{"use":"Waiting for consensus processing","avoid":"Transaction pending","why":"The execution transaction may already be included while the validator request is still queued."}],"technicalNotes":"EIP-7002 adds a withdrawal-request predeploy at 0x00000961Ef480Eb55e80D19ad83579A64c007002. A call with a 48-byte validator public key and uint64 amount in Gwei pays the current request fee and stores source_address from msg.sender; msg.sender may be an EOA or contract. Amount=0 is the FULL_EXIT_REQUEST_AMOUNT signal. Under Electra processing, a full-exit request must match a 0x01 or 0x02 execution withdrawal credential and have no pending withdrawal balance blocking exit. A positive amount is a partial request only for a 0x02 compounding credential with effective balance >=32 ETH and balance >32 ETH plus pending partial withdrawals; the processed amount is the minimum of available excess and requested amount. The request is emitted as an EIP-7685 execution request and is dequeued into consensus with a maximum of 16 withdrawal requests per block. The consensus layer validates the request; an invalid request can fail without invalidating the whole block. The fee uses a dynamic excess-based formula, overpayment is not generally returned, and the exact request/exit/withdrawal timing depends on the activated network and validator state.","relatedStandards":[{"id":"EIP-7251","relationship":"Adds 0x02 compounding credentials, the 32 ETH floor and excess-balance conditions for positive partial requests, and the consensus-side processing used by Electra withdrawal and consolidation flows."},{"id":"EIP-7044","relationship":"Provides a separate pre-signed voluntary-exit path for active-key operations."}],"keyTakeaways":["EIP-7002 gives a matching execution withdrawal credential an execution-layer request path; Electra accepts 0x01 or 0x02 for amount=0 full exits.","Positive partial requests require a 0x02 compounding credential, at least 32 ETH effective balance, and excess above 32 ETH plus pending partial withdrawals.","Show the actual request source, amount mode and unit, dynamic request fee, and validator public key before submission.","Do not claim Ethereum's Pectra behavior on another network without activation evidence."]},"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-7002","markdown":"https://www.eipsfordesigners.com/standards/EIP-7002/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-7002/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-7002","official":"https://eips.ethereum.org/EIPS/eip-7002","discussion":"https://ethereum-magicians.org/search?q=EIP-7002"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}