Ether fi is a Liquid Restaking Protocol With Queued eETH-to-ETH Withdrawals

Standard queue costs before ETH arrives

The standard eETH queue charges no protocol exit fee, yet the full lifecycle still requires Ethereum gas at each state-changing step onchain.

The protocol fee on the queued route is 0%. With a fresh wallet, the ordinary allowance flow uses three state-changing transactions: approve eETH, create the request, and claim ETH after finalization. EIP-2612 compresses approval and request creation into one submission, leaving two onchain transactions for the complete lifecycle. An existing sufficient allowance also leaves two.

Approval and request gas

Each transaction costs the gas units consumed multiplied by its effective gas price. That ETH total moves with Ethereum’s base fee and the wallet’s priority fee. Approval writes an ERC-20 allowance for LiquidityPool. Request creation then calls transferFrom, calculates eETH shares, and mints the ERC-721 receipt. A permit path removes the separate approval transaction, while the request still pays its own gas.

The later claim cost

Claiming adds one Ethereum transaction after finalization. The call burns the receipt, settles share accounting, and transfers ETH; the pending request reserves no gas. batchClaimWithdraw combines eligible token IDs in one atomic call, with practical size set by the gas limit. The transaction count falls when an allowance already exists.

Start with the token on Ethereum

The queued path begins only when the wallet holds eETH on Ethereum, because LiquidityPool accepts eETH as the standard request asset for exits. An eETH holder enters the amount and receipt recipient directly. A weETH holder first calls WeETH.unwrap, which burns weETH and returns the corresponding eETH amount in one transaction. Both tokens use 18 decimals, and one whole token unit equals 10^18 base units. The standard receipt queue settles native ETH on Ethereum; bridged weETH must return to that supported context before entry.

Allowance and permit paths

The approval method decides whether request creation needs one onchain transaction or an earlier allowance transaction before LiquidityPool transfers the eETH balance (more on this in Ether fi inside limits steps ).

Separate ERC-20 approval

ERC-20 approve names LiquidityPool as spender and sets an allowance denominated in eETH base units. An exact allowance covers the selected amount; a larger allowance leaves a remainder after transferFrom moves the requested eETH. Approval is transaction one, and request creation is transaction two. An allowance granted to WeETH, EtherFiRedemptionManager, or another integration does not satisfy this call because the spender differs.

Signed EIP-2612 permit

EIP-2612 replaces the approval transaction with signed permit data. The signature authorizes a value, nonce, and deadline, and carries the three signature fields v, r, and s. LiquidityPool tries the permit before it creates the request, placing authorization and transfer in one state-changing transaction. If the permit fails, an existing sufficient allowance still supports the transfer; otherwise, the request reverts before minting a receipt.

At confirmation, the material fields are the eETH amount, the LiquidityPool spender, and the receipt recipient. That recipient owns the new token ID and receives the eventual payout while ownership remains unchanged. The available path changes when the connected wallet supports typed-data signing.

The status change after submission

A successful queue request replaces the selected eETH position with one ERC-721 WithdrawRequestNFT, whose token ID remains the position reference until claim.

The receipt changes what the wallet should monitor. The eETH balance falls by the requested amount because LiquidityPool transfers that ERC-20 value into WithdrawRequestNFT. In return, one NFT appears under the recipient address. Its sequential token ID starts from the contract’s initial ID of 1 and identifies the request in later reads. The record holds the requested eETH amount, the corresponding share amount, and a validity flag. Those first two quantities use 96-bit fields in the receipt contract, while finalization compares the ID against a separate queue boundary. A successful transaction hash confirms creation; it does not confirm ETH availability.

The output at this stage is a receipt state, not ETH. The ERC-721 Transfer event exposes the minted token ID, and ownerOf confirms its holder even when a wallet gallery omits the collectible. Etherscan also reads those contract states directly.

How do I know when the receipt is claimable?

The receipt becomes claimable only after Ether fi advances the finalized boundary to include its token ID and the request remains valid.

WithdrawRequestNFT defines finalization with one comparison: the receipt’s token ID must be less than or equal to lastFinalizedRequestId. A boundary update covers every sequential valid ID through that point. A lower ID qualifies once the boundary reaches it, while a higher ID remains pending.

Wallet confirmation and queue finalization are separate. Ethereum schedules slots every 12 seconds under normal consensus timing, and 32 slots form one 6.4-minute epoch, yet those constants do not set an Ether fi exit duration. LiquidityPool first uses unbonded ETH; if its available balance is insufficient, the protocol requests validator exits and waits for consensus-layer funds. isFinalized returns false until the boundary advances. Once true, the receipt is eligible for claim; finalization itself does not send ETH.

Ownership and receipt handling while waiting

The queue position follows the ERC-721 receipt owner, so transferring that NFT changes the future ETH recipient without creating another withdrawal request.

Transfer changes the account that receives ETH at claim, because the contract reads ownerOf(tokenId) during settlement rather than remembering the original requester. One onchain transfer therefore moves both the visible NFT and the economic right attached to it. A valid receipt remains transferable under the ERC-721 logic, subject to the contract’s transfer controls. The eETH amount does not return to the old address, and no second queue record appears. Wallets should treat the token ID as the position itself: custody of that single identifier determines who receives the eventual native ETH payment, as set out in Using Ether fi.

Batch handling leaves each token ID separate. batchClaimWithdraw accepts an array, but every included receipt must pass the same claim checks; the practical batch size changes with available gas.

Four exit paths and supported assets

The correct exit route depends on the input token, acceptable output asset, and willingness to wait for Ether fi queue finalization before settlement.

The two standard rows produce WithdrawRequestNFT receipts and carry the 0% queued-exit protocol fee. The instant rows use EtherFiRedemptionManager instead; that route checks liquid reserves and a rate limiter, then applies its configured exit fee. It produces the selected ETH or stETH output immediately when those checks pass, without creating a queue receipt.

Claim execution and position closure

A finalized receipt closes cleanly when its owner can receive native ETH and a caller submits claimWithdraw with the correct token ID.

claimWithdraw reads the receipt owner, checks validity and finalization, calculates the claimable amount, burns the NFT, deletes the request record, instructs LiquidityPool to burn the recorded eETH shares, and transfers native ETH. The call is permissionless: another address may submit the transaction, but the payout still goes to the NFT owner. One token ID closes one position. batchClaimWithdraw loops through multiple IDs in one atomic call.

For requests finalized under the share-rate-freeze mechanism, WithdrawRequestNFT values the recorded shares at the frozen rate. The claimable amount is the lesser of that value and the originally requested eETH amount. Later rebases therefore do not raise a finalized payout above the request. If the owner address rejects native ETH, the entire claim reverts, leaving the receipt and request record intact.

Mechanics beneath the queue

The queue releases ETH only after LiquidityPool secures enough liquid backing and Ether fi finalizes the receipt’s sequential position for complete settlement.

Share accounting and finalization

LiquidityPool converts the requested eETH amount into shares, moves the tokens to WithdrawRequestNFT, and records both values in 96-bit fields. Finalization advances a contiguous upper boundary and snapshots an amount-per-share rate scaled by 10^18. The claim calculation multiplies recorded shares by that frozen rate, then selects the lower value against the original requested amount. This sequence connects the user’s ERC-20 input to a fixed post-finalization ETH claim.

Validator liquidity path

Insufficient unbonded ETH moves the dependency from pool liquidity to Ethereum validator withdrawals. EIP-7002 encodes each validator withdrawal request in 56 bytes: a 48-byte public key plus an 8-byte unsigned amount. Its system contract processes no more than 16 requests per block, targets 2 per block, and sets a minimum request fee of 1 wei before congestion pricing. Those network constants govern validator-request throughput, not the receipt’s promised completion time; the user timeline stretches when settlement needs exited validator funds.

End state and post-claim checks

The position is fully closed when the claim transaction succeeds, the ERC-721 receipt disappears, and native ETH reaches the receipt owner address.

The wallet should show no remaining NFT for that token ID because claimWithdraw burns it and deletes its request data. Native ETH, rather than WETH, appears in the owner’s account. The balance increase equals the settled claim amount, while the transaction sender separately pays Ethereum gas. The claim event supplies the token ID, amount, burned shares, and recipient for a final onchain record.

A prior eETH allowance is independent of receipt closure. If approval exceeded the exited amount, its unused remainder stays until the owner changes it. That allowance cannot affect the queued claim because the eETH has already moved. It matters again only when another request uses LiquidityPool as spender and the remaining value covers that new amount.