# EIP-7002: Execution Layer Triggerable Withdrawals Source: https://www.eipsfordesigners.com/standards/EIP-7002 Agent brief: https://www.eipsfordesigners.com/standards/EIP-7002/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-7002 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-7002 | | Discussion search | https://ethereum-magicians.org/search?q=EIP-7002 | ## UX Impact 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. ## 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. ## What does not work everywhere yet 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. ## For Designers - 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 ### When to Use - 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. ### When to Avoid - 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. ## Problems It Solves ### Withdrawal-credential owners depend on the active validator key to exit Impact: critical Old way: The operator must sign an exit or provide pre-signed material to the funds' owner. New way: 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. ### Pool and custody products cannot expose a direct owner-controlled exit path Impact: high Old way: Users wait for an operator workflow with unclear authority and status. New way: A product can show the actual source and credential match, amount mode, request fee, queue, consensus result, and eventual withdrawal state. ### Execution inclusion is mistaken for staking completion Impact: high Old way: Show a transaction success toast after calling the predeploy. New way: Track execution inclusion, consensus validation, exit or withdrawal queue, and balance credit as distinct states. ## 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. ### The withdrawal request contract exposes the current required fee when queried with zero-length input. Applies to: application Source classification: normative > 2. Fee getter - if the input length is zero, return the current fee required to add a withdrawal request. Source: [Specification — Execution layer — Withdrawal Request Contract](https://eips.ethereum.org/EIPS/eip-7002#withdrawal-request-contract) Design implication (editorial): 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. ### The address that calls the withdrawal request contract must match the validator's recorded 0x01 withdrawal credential. Applies to: application Source classification: security-considerations > the address that calls the system contract must match the 0x01 withdrawal credential recorded in the beacon state. Source: [Security Considerations — Fee Overpayment](https://eips.ethereum.org/EIPS/eip-7002#fee-overpayment) Design implication (editorial): 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. ### Overpaid withdrawal-request fees are not returned to the caller. Applies to: application Source classification: security-considerations > Overpaid fees are not returned to the caller. Source: [Security Considerations — Fee Overpayment](https://eips.ethereum.org/EIPS/eip-7002#fee-overpayment) Design implication (editorial): 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. ### The withdrawal-request path must not be treated as active on a chain whose predeploy code is missing. Applies to: infrastructure Source classification: security-considerations > 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"). Source: [Security Considerations — Empty Code failure](https://eips.ethereum.org/EIPS/eip-7002#empty-code-failure) Design implication (editorial): 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. ### Withdrawal credentials ultimately own the validator funds and can naturally authorize an exit request. Applies to: application Source classification: security-considerations > The withdrawal credentials ultimately own the funds so allowing them to exit staking is natural with respect to ownership. Source: [Security Considerations — Impact on existing custody relationships](https://eips.ethereum.org/EIPS/eip-7002#impact-on-existing-custody-relationships) Design implication (editorial): 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. ### Custody flows SHOULD let the withdrawal-credential holder recover funds when active keys are lost. Applies to: application Source classification: rationale > 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. Source: [Motivation](https://eips.ethereum.org/EIPS/eip-7002#motivation) Design implication (editorial): 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. ## Anti-Patterns (editorial) ### Showing the same partial action for every validator Severity: critical 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. ### Calling execution inclusion a completed withdrawal Severity: critical Consensus processing and validator queues still determine the outcome. Instead: Separate execution, consensus, and balance-credit states. ### Quoting a fixed request fee or completion time Severity: high 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. ### Hiding the validator public key in the confirmation Severity: high 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. ## Design Decisions ### 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. ### 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. ### 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. ## States to Design ### 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. User need: Know that this account has the authority to request the action. Design response: Show the actual source address, credential prefix, validator public key, amount=0 full-exit mode, and any remaining validator-state prerequisite. ### 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. User need: Know how much excess balance can be requested without implying an immediate cash-out. Design response: Show the 32 ETH floor, pending partial-withdrawal amount, available excess, positive Gwei amount, and the separate partial-withdrawal queue. ### Credential not eligible Trigger: The credential is BLS, the actual request source does not match, or network support is missing. User need: Understand why the action is unavailable. Design response: Explain the exact prerequisite and link to a separate credential-update or operator flow when one exists. ### 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. User need: Understand why a full exit may remain available while a partial amount is not. Design response: Keep the full-exit and partial-withdrawal states separate, show the failed condition, and do not silently turn a positive amount into amount=0. ### Fee quote expired Trigger: The dynamic request fee changed before transaction inclusion. User need: Avoid overpaying or sending a request that reverts. Design response: Refresh the fee, show the user's maximum fee policy, and require a new confirmation. ### Execution request queued Trigger: The transaction is included and the request is waiting for consensus processing. User need: Know that the action has not completed yet. Design response: Show execution inclusion separately from consensus processing and provide an estimated range only when the network supplies one. ### 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. User need: Know whether a retry can work and whether fees were spent. Design response: Name the protocol result, link the execution and validator records, and avoid presenting it as a completed withdrawal. ### Exit or partial withdrawal progressing Trigger: Consensus accepted the request and assigned the relevant queue state. User need: Track when funds or validator status will change. Design response: Show the validator's exit or withdrawal queue state, then show the eventual execution-layer credit separately. ## Vocabulary - Use "Request a full exit" instead of "Withdraw now": Amount=0 signals a full exit request; the consensus-layer process and eventual withdrawal still happen later. - Use "Request a partial withdrawal" instead of "Cash out": A positive Gwei amount is available only for eligible 0x02 compounding validators and may leave the validator active. - Use "Waiting for consensus processing" instead of "Transaction pending": The execution transaction may already be included while the validator request is still queued. ## What to Prototype First ### Validator withdrawal control 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 - 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 ### Request fee and queue review 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 - Current request fee - Fee limit - Execution transaction link - Consensus status ## Mental Model ### Withdrawal authority 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. ### Execution request 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. ### Request queue The execution layer queues requests so many calls can be accepted even though only a bounded number are passed to consensus per block. ### Consensus processing The consensus layer validates each request against validator state; an invalid request can be ignored without making the whole block invalid. ### Withdrawal or exit 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. ## UI Components ### ValidatorAuthorityCard 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 ### WithdrawalRequestTimeline 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 ## Key Takeaways - 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. ## UX Patterns ### Credential-Gated Exit Control 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 User flow: - 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 ### Two-Layer Request Timeline Separate the execution transaction from queueing, consensus validation, and eventual funds movement. Components: Execution receipt, Request queue row, Consensus result, Withdrawal credit row User flow: - 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 ## Related Standards - EIP-7251: 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. - EIP-7044: Provides a separate pre-signed voluntary-exit path for active-key operations. ## Technical Notes 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.