Etherfi
Etherfi is a Liquid Restaking Protocol With an eETH Withdrawal and Claim Path
Etherfi is a liquid staking protocol whose standard eETH exit turns a token balance into a queued withdrawal request, then claimable ETH on Ethereum. The holder approves eETH, submits the chosen amount, keeps the resulting WithdrawRequestNFT and waits for finalization. After the request becomes final, one claim transaction delivers native ETH to the eligible receipt owner.
This page follows that position lifecycle only: choose the amount, read the on-chain state, preserve the receipt and close the position after the queue clears. It also separates the fee-free queued route from Ethereum gas and the distinct instant-redemption mechanism.
Choosing a Full or Partial eETH Exit
The withdrawal amount determines whether the eETH position closes completely or continues as a smaller rebasing balance.
The interface begins with one concrete choice: enter the eETH amount to unwind. A full-balance request moves the whole liquid position into the queue, while a partial request leaves the unrequested balance in the wallet. Because eETH uses 18 decimal places, the interface may round the display while the contract works in base units. Check the amount shown in the wallet confirmation, the receiving address and the remaining eETH balance before signing the request.
An ERC-20 approval authorizes the LiquidityPool to move the selected eETH. The successful request then transfers that amount to WithdrawRequestNFT and mints one ERC-721 receipt to the chosen recipient. A later adjustment uses a new request for additional eETH; the queued receipt itself does not expose an amount-editing action.
Queued Exit Costs and Wallet Transactions
The standard eETH queue removes the protocol exit fee while leaving Ethereum gas payable by the submitting wallet.
The standard queued route charges a 0% protocol exit fee and does not use the instant-redemption rate limit. A conventional wallet flow uses two transactions to start: one approval and one withdrawal request. The EIP-2612 permit route can combine authorization with the request in one transaction, and the later ETH claim remains separate. EIP-1559 gas contains two quoted components, the base fee and priority fee. Without an existing allowance, the conventional lifecycle therefore reaches three wallet transactions; the permit lifecycle reaches two. Both transaction counts exclude any preliminary weETH unwrap.
Fixed Queue Parameters and Security Layers
The eETH withdrawal queue combines Ethereum standards with fixed storage widths inside Etherfi application contracts.
Ethereum mainnet identifies itself as chain ID 1. eETH follows ERC-20 with 18 decimals, while each withdrawal receipt follows ERC-721 and carries one token ID. The request stores its amount and share allocation in two 96-bit fields. Request counters use 32 bits, and finalization-rate checkpoints use 224 bits at a 10^18 share scale. Those widths define contract accounting, not a user-facing withdrawal minimum.
| Fixed Parameter | Value | Security Tier |
|---|---|---|
| Execution network | Ethereum mainnet, chain ID 1 | Base consensus tier |
| eETH representation | ERC-20 with 18 decimals | Token-standard tier |
| Withdrawal receipt | ERC-721, one token ID per request | Ownership-standard tier |
| Request amount and shares | Two uint96 fields | Application-contract tier |
| Request counters | uint32 | Application-contract tier |
| Finalization rate | uint224 at 10^18 scale | Accounting-invariant tier |
At the unit level, 1 ETH equals 10^18 wei. The same 18-decimal convention lets wallets present readable eETH and ETH amounts while Solidity preserves integer precision.
What Does the InQueue Status Mean?
InQueue means the request transaction succeeded and the corresponding eETH exit now awaits protocol finalization.
The decisive evidence is the request transaction, not a loading animation. LiquidityPool moves the requested eETH into WithdrawRequestNFT, records both the token amount and its share allocation and emits a request event. The contract then mints one unique receipt whose token ID identifies the position in the queue. MetaMask or another wallet may omit that collectible from its default view, while Etherscan and DeBank still show the transaction and ownership record for the same token ID.
Finalization Freezes the eETH Share Rate
Finalization converts a pending request into an ETH claim whose accounting rate no longer moves afterward.
Etherfi finalizes requests in ordered batches. A request becomes final when its token ID is at or below the contract's last finalized request ID. The corresponding ETH is segregated for the standard queue, and the receipt remains the ownership record until settlement.
Two State Checks
Two contract reads separate waiting from settlement: isFinalized checks queue progress, while isValid confirms that the receipt remains active.
Pending Request
A pending token ID sits above lastFinalizedRequestId. Calling getClaimableAmount at this stage reverts because the queue has not recorded a finalization rate for that request. The receipt still identifies the queue position, but the rate snapshot and escrow allocation are absent.
Finalized Request
A finalized token ID sits at or below lastFinalizedRequestId. The claimable value then becomes readable, and any caller may submit settlement for the current NFT owner.
The Rate Snapshot
For newly finalized requests, Etherfi snapshots the eETH share rate at finalization, so later rebases do not move the claim payout. The contract compares two values: the originally requested eETH amount and the recorded shares multiplied by that frozen rate. It pays the lesser value, preserving the request cap while tying settlement to the share allocation. The fixed-point calculation uses a 10^18 share unit and ceiling-rounded rate checkpoint.
Why Does the Withdrawal Queue Length Change?
Queue length changes because Etherfi must match withdrawal requests with available ETH and Ethereum validator exits.
The LiquidityPool first relies on ETH that is not locked in active validators. When that liquidity cannot cover pending requests, the protocol initiates validator exits and waits for Ethereum to release the funds. A validator begins from a 32 ETH activation balance, yet many requests can share the proceeds from one exit. EIP-7002 provides an execution-layer path for triggering validator withdrawals, while EIP-4895 carries consensus-layer withdrawals into Ethereum execution payloads. The live backlog across these stages determines the waiting time. Fresh deposits may replenish liquid ETH while exits are still progressing.
Ethereum targets 12 seconds per slot and groups 32 slots into one epoch, equal to 384 seconds or 6 minutes 24 seconds. Those fixed intervals do not create a fixed unstaking deadline. Exit churn, pending request volume and available pool ETH remain the three operational timing inputs.
Claiming Native ETH From the Withdrawal Receipt
A finalized request closes when the WithdrawRequestNFT claim call sends native ETH to the receipt owner.
The claim function is permissionless, but it reads ownerOf(tokenId) and directs payment to that current address. It burns the ERC-721 receipt, deletes the stored request and burns the request's full eETH share allocation through LiquidityPool. One finalized token ID can use claimWithdraw; several eligible IDs can use batchClaimWithdraw in one transaction. The latter loops over every supplied ID, so each entry must pass the same finalized and valid checks before the transaction settles as native ETH.
Preparing weETH for the eETH Queue
weETH must become eETH on Ethereum mainnet before it enters the standard eETH withdrawal queue.
weETH is the non-rebasing wrapper around eETH shares. Its token count stays fixed while the amount of eETH represented by each unit changes with the pool's share rate. The unwrap action converts a chosen weETH amount into the corresponding eETH, after which the approval or EIP-2612 permit and request flow applies. This adds one unwrap transaction when the position begins entirely in weETH.
The standard queue operates on Ethereum mainnet, chain ID 1. A weETH balance held on another network must first return to mainnet through a supported route or be exchanged there; an L2 token balance cannot be inserted directly into the mainnet WithdrawRequestNFT queue.
Reconciling the Closed Position On-Chain
A complete unwind leaves an ETH credit, a burned receipt and an auditable chain of transaction records.
Use the request token ID as the common key between the queue entry and claim. Ethereum addresses contain 20 bytes, displayed as 40 hexadecimal characters after the prefix, while transaction hashes contain 32 bytes and display 64 hexadecimal characters. Matching those identifiers prevents a wallet label from being mistaken for the underlying account or transaction.
- Record the approval or permit transaction when the request required fresh authorization.
- Record the request transaction, requested eETH amount and minted WithdrawRequestNFT token ID.
- Read isFinalized and getClaimableAmount before treating the position as ready to settle.
- Match the claim transaction's recipient and native ETH transfer to the receipt owner.
Etherscan exposes contract events and internal ETH transfers, while DeBank provides a portfolio-oriented transaction view. After claim settlement, the receipt no longer exists because the contract burns it, and the wallet's native ETH balance rises by the payout minus any gas that the same wallet paid. That final ETH transfer closes the eETH queue record.
Popular questions about Etherfi
Does the eETH queue accept every positive withdrawal amount?
The eETH queue does not accept every positive amount. LiquidityPool requires a value greater than 0 and checks it against the active minWithdrawAmount and maxWithdrawAmount parameters before calculating shares or minting a receipt. A value outside that interval reverts. Because those two bounds are updateable contract settings, an amount accepted for one request does not establish a permanent minimum or maximum for a later request.
Who receives ETH when another address submits the claim?
The current WithdrawRequestNFT owner receives the ETH, even when a different address calls the permissionless claim function. The contract reads ownerOf(tokenId) at settlement and sends the payout to that address. This design separates transaction submission from economic ownership. A service may pay gas and submit the claim, but it cannot redirect the proceeds through the standard claim call.
May a valid WithdrawRequestNFT be transferred before settlement?
A valid WithdrawRequestNFT may be transferred before settlement. The receipt follows ERC-721 transfer rules, and transfer changes the address that receives ETH because the claim function pays the current NFT owner. The queued eETH claim therefore moves with the receipt. Keep the token ID and transfer transaction together in your records so later reconciliation follows the new owner.
When is batch claiming useful for several request IDs?
Batch claiming is useful when one wallet owns several finalized WithdrawRequestNFT token IDs. The batchClaimWithdraw function accepts an array and processes each eligible receipt within one Ethereum transaction, reducing the number of separate claim submissions. Every included request still must be valid and finalized. If one entry fails a required check, the combined transaction reverts, so group only receipts whose state is already claimable.
Does revoking the eETH allowance cancel an existing queue request?
Revoking an allowance does not cancel a successful queue request. The request has already moved the selected eETH into WithdrawRequestNFT and minted the receipt, so a later allowance change leaves that queued position intact. Revocation only changes whether the wallet can submit another standard request without approving again. If the allowance disappears before the request transaction executes, that transaction cannot transfer the selected eETH.