Ether fi

Ether fi limits are eETH unstaking rules restricted to Ethereum Mainnet

Ether fi limits are withdrawal constraints that keep native eETH unstaking on Ethereum Mainnet, even though deposits and weETH usage extend to other networks. A holder on Arbitrum, Base, or Optimism cannot submit the mainnet withdrawal contract from that network. The asset must first reach Ethereum, or the holder must use a market swap on the source chain. On mainnet, the documented interface flow requires an ERC-20 approval and a separate withdrawal request. A queued eETH exit then needs a later claim after finalization. Standard queueing avoids the protocol exit fee, while instant redemption uses available liquidity, charges a defined fee, and remains subject to a rate limiter.

The instant route stops once liquid reserves reach its 1% low watermark.

Mainnet-only unstaking is the first point of failure

The EtherFi withdrawal interface accepts unstaking on Ethereum Mainnet, so a wallet connected elsewhere cannot create a valid native request.

Ethereum Mainnet uses chain ID 1. Arbitrum One uses 42161, Base uses 8453, and Optimism uses 10; those fixed identifiers prevent a transaction signed on one network from reaching a contract on another. Cross-chain weETH through LayerZero, and canonical weETH bridging on Arbitrum, expand where the token moves and where DeFi positions exist. They do not relocate the mainnet LiquidityPool, WithdrawRequestNFT, or EtherFiRedemptionManager. A wallet may show the same ticker while the chain state remains separate.

If the balance sits on Layer 2, choose between returning supported weETH to Ethereum and trading it locally. A bridge adds source and destination transactions plus bridge settlement; a swap replaces the protocol queue with pool liquidity, fees, and price impact. On Arbitrum One, the supported canonical asset is weETH.

Approval, request, and claim create the real transaction budget

A fresh queued eETH exit uses two mainnet transactions before queue entry and one later transaction to claim ETH.

Transaction 1 approves the LiquidityPool to transfer the chosen eETH amount under ERC-20 allowance rules. Transaction 2 calls the withdrawal request, moves the corresponding eETH into the withdrawal contract, and mints a request NFT. After finalization, transaction 3 claims ETH and burns that NFT. Each action pays Ethereum gas in ETH. Under EIP-1559, the base fee and priority fee move with block demand, so the protocol cannot publish one durable gas cost for the three-action sequence. Approval transactions carry zero ETH value; they still consume gas.

The LiquidityPool also supports an EIP-2612 permit path. A signed permit lets the withdrawal request happen in one onchain transaction, although the wallet still signs typed data and the later claim remains separate. The ordinary interface is built around the clearer two-step approval and execution flow.

Broadly, Etherscan and DeBank display the approval, request, and claim as separate records. The request event confirms a new WithdrawRequestNFT. There is a fuller treatment in Contract Risk Follows eETH.

Instant redemption exchanges waiting time for a fee and liquidity gate

Closer to the ground, EtherFi instant redemption settles from liquid reserves, but it only accepts amounts inside both a buffer gate and a refillable bucket. Instant redemption charges 0.3% and remains available only while liquid reserves stay above the 1% low watermark.

The 0.3% fee equals 30 basis points, while the standard queued route carries a 0% protocol exit fee. The EtherFiRedemptionManager calculates the redeemable amount as the lesser of liquidity above the watermark and the rate limiter’s consumable bucket. That bucket has a capacity and a per-second refill rate. Both are governance parameters, so the visible instant maximum is a live allowance rather than a permanent wallet tier. Its basis-point arithmetic uses 10,000 units for 100%.

Before signing, the interface asks the redemption manager whether the amount passes canRedeem. A false answer sends the holder toward the standard queue. Every split redemption consumes the same shared capacity, so an exhausted bucket directs all sizes toward the standard queued withdrawal.

Ether fi limits separate amount bounds from validator size

Queued withdrawals use contract-set minimum and maximum amounts, while Ethereum’s validator denomination does not define a holder’s request size.

The LiquidityPool rejects a zero amount and reads minWithdrawAmount and maxWithdrawAmount before minting a request. An operating multisignature can update those two values, so the interface quote is the operative range at submission. eETH exposes 18 decimals, making one token divisible into 10^18 base units. The queue stores both the requested amount and its share count in 96-bit fields, and it stores request counters as 32-bit integers. EtherFi validator funding uses a 1 ETH seed and reaches 32 ETH after credential confirmation; pooled accounting does not round a user request to 32 ETH.

eETH and weETH converge only after wrapper conversion

eETH enters the queue directly, whereas weETH must become eETH shares before the same withdrawal accounting can continue.

The eETH route

eETH is a rebasing ERC-20 balance backed by shares in the LiquidityPool. The request function transfers the selected balance to WithdrawRequestNFT, records amount plus shares, and issues one ERC-721 token. Rewards keep changing the wallet balance before the request, while post-finalization rate snapshots hold the claim calculation steady.

The weETH route

weETH is the non-rebasing ERC-20 wrapper. Its token balance stays fixed while each unit represents a changing quantity of eETH.

Direct adapter path

The WeETHWithdrawAdapter pulls weETH, unwraps it, increases the resulting eETH allowance to LiquidityPool, and creates the queue request in the same execution. A permit version combines signed authorization with that call.

Manual unwrap path

The WeETH contract also unwraps weETH to eETH without starting an exit. That conversion uses the live share rate, after which the ordinary eETH approval and request steps apply. Both tokens use 18 decimals. Instant redemptions can leave 1-2 wei of residual eETH through floor rounding, an accounting trace rather than a separate user limit.

Six exit routes differ by settlement dependency and supported scope

Six withdrawal and liquidity routes differ mainly by settlement dependency, token conversion, and the asset that reaches the wallet.

The native queued rows preserve EtherFi redemption accounting and end in ETH after claim. Instant rows use EtherFiRedemptionManager and support ETH or Lido stETH output when the selected route has capacity. Unwrapping changes representation without releasing ETH. Curve performs a market trade against WETH, so its pool fee and price impact replace queue timing. Uniswap, Balancer, and CoW Swap also route market trades when a suitable pool or solver quote exists.

The withdrawal NFT carries the claim through the queue

Each standard withdrawal mints one transferable ERC-721 request whose owner receives the ETH when the finalized claim settles.

Ownership and finalization

WithdrawRequestNFT initializes its sequence at request ID 1 and advances one ID per request. The contract marks requests finalized in order through lastFinalizedRequestId; any token ID at or below that value passes the finalization test. Ownership matters more than the original requester. A valid NFT transfer moves the future claim, and the claim function always pays the address that owns the token when settlement runs.

Payout and burn

For post-upgrade requests, finalization freezes a share rate for the covered range. Later eETH rebases do not alter that finalized calculation. The claimable amount is the lesser of the original eETH amount and the frozen-rate value of its recorded shares. Claiming burns the NFT, deletes its request record, and transfers ETH. The batch claim function accepts an array of token IDs, with transaction gas imposing the practical batch size.

Ethereum timing explains the queue’s variable finish

In the same way, Ethereum’s validator exit and withdrawal clocks set the slow path when EtherFi’s liquid ETH cannot cover queued requests.

The matching explanation appears in Using Ether fi. Around that, Ethereum divides consensus time into 12-second slots, with 32 slots forming a 6.4-minute epoch. A voluntary exit receives an exit epoch at least 4 epochs after initiation, before any additional queue delay. After an Ethereum validator exits, its balance becomes withdrawable 256 epochs later, a protocol delay of about 27.3 hours. The sweep then moves eligible balances to the execution layer. Each payload includes at most 16 eligible withdrawals after checking up to 16,384 validator records, so networkwide workload also shapes settlement.

In that setup, EtherFi does not map one user’s request to one 32 ETH validator. The LiquidityPool uses unbonded ETH first and triggers validator exits when pooled liquidity falls short. EIP-7002 gives protocol contracts an execution-layer path to trigger validator exits, while WithdrawRequestNFT represents the user’s place in EtherFi’s own finalization sequence. Completion therefore combines buffer availability, EtherFi batching, Ethereum’s exit queue, and the consensus withdrawal sweep.

FAQ