# recoverEther not updating currentWithheldETH breaks calculation of withheld amount for further deposits

recoverEther in frxETHMinter fails to reset currentWithheldETH, so post-recovery deposits skew the withhold ratio, letting owner move excess ETH.

- Payout: Contest reward
- Severity: medium
- Program: Frax Finance
- Credited: joestakey
- Disclosed: 2022-11-29
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-09-frax-findings/issues/346
- Library page: https://bugbountylibrary.com/r/c4%3A2022-09-frax%3AM-09
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error

**Target:** frxETHMinter.sol recoverEther / currentWithheldETH accounting
**Root cause:** recoverEther transfers ETH out but never decrements currentWithheldETH, so the withheld counter no longer reflects actual balance relative to withholdRatio.
**Steps:**
1. Set withholdRatio to 200000 (20%) via comptroller.
2. Alice submits 100 ETH; currentWithheldETH becomes 20 ETH.
3. Owner calls `recoverEther(100 ether)`; balance goes to 0 but currentWithheldETH stays 20 ETH.
4. Alice submits another 100 ETH; currentWithheldETH becomes 40 ETH (40% of balance).
5. Owner calls `moveWithheldETH(Alice, 40 ether)`, moving 40% instead of intended 20%.
**How found:** Code review of recoverEther noticing it lacks the currentWithheldETH decrement present in other ETH-outflow paths, then tracing deposit/moveWithheldETH math.
**Exploitation:** Owner (privileged) after emergency recovery can moveWithheldETH more than the intended withholdRatio, or depositEther stakes less than expected, because currentWithheldETH is inflated relative to actual balance.
**Insight:** When a contract tracks a derived counter (withheld amount) separate from balance, audit every outflow path—especially emergency/admin functions—for missing counter updates; stale counters silently skew ratio-based logic.