Ether fi is a Liquid Restaking Protocol for Tracking eETH Wallet Balances

Choose the balance you intend to verify

The output-token decision is the first wallet choice because it determines whether the post-transaction number appears as rebasing eETH or non-rebasing weETH inside the connected Ethereum account after confirmation.

Select eETH when the verification target is the wallet’s direct liquid-restaking balance. Its displayed amount changes through the rebasing share model as the pool reports rewards. Select weETH only when the intended output is the wrapped, non-rebasing ERC-20 representation. The two choices use different wallet displays and should not be reconciled as identical token counts. An eETH-focused check therefore begins before signing: read the receive label, confirm that it says eETH, and save the quoted amount. If the interface defaults to weETH, change the output before entering the final amount.

Should you select eETH or weETH?

The eETH-versus-weETH choice is a token-format decision: eETH rebases its wallet balance, while weETH keeps its token quantity fixed as its conversion rate changes.

Both formats trace to the same pooled ETH accounting, yet wallet verification uses different evidence. For eETH, compare the quote with the contract’s balanceOf result after confirmation. For weETH, compare the minted wrapped quantity and the wrapper’s conversion rate. MetaMask and Rabby Wallet round long decimal values for display, so matching only the first visible digits is insufficient. A smaller weETH token count does not establish a shortfall; the wrapper conversion determines its eETH value.

The mechanics are laid out in detail. Stay with eETH for this workflow. Switching format after the deposit adds a separate wrap or unwrap transaction and a second receipt to reconcile.

Wallet and network prerequisites

The wallet prerequisite is an Ethereum-capable external account with ETH for the deposit, extra ETH for gas, and a connection set to mainnet chain ID 1.

Connection and account

MetaMask, Rabby Wallet, and WalletConnect expose the selected account to the Ether fi interface. A Ledger or Trezor signs through compatible wallet software while the private key remains on the device. Match the entire recipient address across the interface and wallet prompt. An Ethereum address contains 20 bytes, rendered as 40 hexadecimal characters after the 0x prefix. The connected account receives eETH, so changing accounts between quote and signature changes the balance that needs inspection.

Gas reserve

Ethereum charges gas in ETH, separately from the amount sent to the LiquidityPool. A “max” input that consumes the whole native balance leaves nothing for execution and fails at estimation or signing. An EIP-1559 type 2 transaction carries two fee caps: the maximum fee per gas and the maximum priority fee per gas. The receipt later records the effective gas price and gas used. Keep a reserve above the wallet’s estimate because the estimate responds to block demand.

Read the quote before confirmation

The pre-confirmation quote is a transaction preview that should identify the ETH input, eETH output, connected address, Ethereum network, and estimated execution cost before the wallet opens its signing prompt.

The quote needs five aligned fields. ETH is the input asset, and eETH is the output asset. The network is Ethereum mainnet, identified by chain ID 1. The recipient is the account that will hold the new balance, while execution cost is the separate gas estimate. Each label should remain unchanged when the wallet opens. A changed account, token, or network means the saved quote no longer describes the signature request.

Record the eETH estimate before opening the wallet confirmation. The LiquidityPool accepts native ETH through a payable deposit call. For a direct mint from an externally owned account, the standard sequence contains 1 payable deposit transaction and 0 ERC-20 allowance transactions. A Safe smart account wraps that call inside its own execution process, which changes the wallet screens but not the recipient check. Keep the quoted eETH output separate from the gas estimate, then confirm that the transaction value still equals the intended ETH input. This comparison keeps the signing prompt aligned with the saved quote.

Fixed values used during verification

The verification constants are Ethereum and eETH encoding rules that let a wallet, explorer, and direct contract read agree on the same transaction.

eETH uses 18 decimal places, so one whole token is represented by 1,000,000,000,000,000,000 base units before a wallet formats the value.

Before any of that matters, Ethereum schedules one slot every 12 seconds and groups 32 slots into an epoch lasting 6 minutes and 24 seconds. Those constants describe protocol time, not a promised inclusion time. The fee bid and block demand decide when a transaction lands. A complete transaction hash occupies 32 bytes, displayed as 64 hexadecimal characters after its prefix. Use that hash to keep the wallet confirmation, receipt, and token-balance query tied to one execution.

Confirm the Ethereum transaction

The wallet confirmation is an EVM signature step that authorizes a payable call carrying the chosen ETH amount to the protocol’s LiquidityPool.

Wallet summary

Read the network, selected account, transaction value, destination, and gas estimate inside the wallet itself. The EIP-1559 type 2 envelope binds the chain ID, and the sender’s sequential nonce identifies its place among that account’s transactions. Each included transaction consumes one nonce, including a reverted transaction. If another payment is pending from the same account, its nonce order can delay the deposit even when the staking quote remains open.

Receipt status

After signing, preserve the 32-byte transaction hash and wait for a receipt before repeating the action. Ethereum receipt status 1 means execution succeeded; status 0 means the call reverted. A reverted call spends gas but does not mint eETH. Etherscan exposes both the status and the recipient account, while MetaMask and Rabby Wallet link the same hash from their activity views. That receipt settles whether the protocol state changed, regardless of whether the wallet has refreshed its token list.

What changes after the transaction confirms?

The confirmed Ether fi deposit is an on-chain state transition: ETH leaves the sender, the pool mints shares, and eETH becomes readable for the recipient.

ETH debit and deposit record

A successful receipt finalizes two separate debits from the sender: the chosen ETH value and the actual gas charge. The LiquidityPool records the deposit and credits shares to the recipient path used by the call. The wallet’s native balance therefore falls by the deposit plus gas, while the quoted eETH amount appears under the token contract. Compare the transaction value with the saved input, then compare the recipient with the connected account.

Shares and rebasing balance

By contrast, Ether fi seeds a new Ethereum validator with 1 ETH and, after withdrawal-credential verification, adds 31 ETH to reach the 32 ETH activation amount. An individual user does not need 32 ETH because the LiquidityPool aggregates deposits before validator funding. At token level, the eETH contract stores shares and reports balanceOf as the holder’s claim on total pooled Ether. When pooled value rises while shares remain constant, the displayed eETH balance rises through rebasing.

The receipt proves the state transition; the next task is checking that the recipient address exposes the new ERC-20 balance at the same confirmed block.

Verify the eETH balance independently

The post-confirmation check is a three-way reconciliation between the successful receipt, the eETH contract’s balanceOf result, and the connected wallet’s formatted token display for one Ethereum mainnet address.

Start with the receipt on Etherscan and confirm status 1, the sender, the ETH value, and the LiquidityPool destination. The Ethereum LiquidityPool address is 0x308861A430be4cce5502d0A12724771Fc6DaF216. Next, inspect the recipient’s holdings under the canonical eETH contract, 0x35fA164735182de50811E8e2E824cFb9B6118ac2. A direct balanceOf query returns an integer with 18-decimal precision, which the interface divides by 1,000,000,000,000,000,000 for display.

A wallet that shows zero while the contract read is positive has a presentation problem, not a missing mint. Import eETH with the canonical contract address, switch the wallet to chain ID 1, and refresh the asset list. Because eETH rebases, a later contract read can differ in the final digits from the saved quote. Reconcile the confirmed block, account, token address, and decimal conversion before judging the amount.

Recover from the wrong-network setup error

The common setup failure is a network mismatch, where the wallet session points away from Ethereum mainnet even though the intended output is mainnet eETH.

Before signing, change the wallet network to chain ID 1, disconnect the stale session, and reconnect the same account. Re-enter the ETH amount because the interface may discard a quote after a chain change. If the wallet never produced a transaction hash, nothing was broadcast, so a fresh confirmation does not duplicate an on-chain deposit. If a hash exists, inspect its receipt on the chain where it was submitted before taking another action.

Keep eETH verification on Ethereum mainnet. Cross-chain Ether fi integrations use wrapped formats such as weETH, so a balance on another network should not be matched against the mainnet eETH quote. Once the network, receipt status, and recipient all agree, return to the 18-decimal balance check and record the confirmed amount.