# `EtherFiLib::_initiateWithdrawImpl` will revert because rebase tokens transfer 1-2 less wei

EtherFiLib._initiateWithdrawImpl approves and requests withdraw of the pre-transfer eETH amount, but rebase share rounding delivers 1-2 wei less, reverting every withdrawal.

- Payout: Contest reward
- Severity: high
- Program: Leveraged Vaults
- Credited: ZeroTrust
- Disclosed: 2024-06-18
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-06-leveraged-vaults-judging/issues/43
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-leveraged-vaults%3AH-4
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:precision-loss

**Target:** EtherFi staking integration (EtherFiLib / weETH unwrap + LiquidityPool.requestWithdraw)
**Root cause:** weETH.unwrap returns the nominal eETH amount, but eETH.transfer converts to shares and delivers 1-2 wei less due to rounding; the code then approves/requests the full nominal amount, exceeding actual balance.
**Steps:**
1. Call _initiateWithdrawImpl(weETHToUnwrap).
2. `uint256 eETHReceived = weETH.unwrap(weETHToUnwrap)` transfers eETH to the contract; actual received = eETHReceived - 1~2 wei due to share rounding.
3. `eETH.approve(LiquidityPool, eETHReceived)` approves the nominal amount.
4. `LiquidityPool.requestWithdraw(address(this), eETHReceived)` attempts to pull eETHReceived, but balance is short by 1-2 wei, so the transfer reverts.
**How found:** Researcher reasoned that rebase tokens like eETH/stETH transfer shares internally, so received amount can be lower than requested by a couple wei; traced unwrap's eETH.transfer and the subsequent requestWithdraw pull to spot the mismatch between nominal eETHReceived and actual balance.
**Insight:** For rebase/share-based tokens (eETH, stETH), never trust a function's returned nominal amount as the balance delta; measure balanceBefore/balanceAfter around any transfer and use the delta for approvals and downstream pulls.