# WIchiFarm will break after second deposit of LP

WIchiFarm assumes IchiVault LP keeps max allowance, but transferFrom decrements it, so the second deposit reverts in safeApprove, bricking deposits.

- Payout: Contest reward
- Severity: medium
- Program: Blueberry
- Credited: 0x52
- Disclosed: 2023-02-01
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-blueberry-judging/issues/15
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-blueberry%3AM-17
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** WIchiFarm.sol wrapper contract / IchiVault LP token
**Root cause:** Code assumes IchiVault LP does not decrement allowance when set to type(uint256).max, but its transferFrom always subtracts amount. After first deposit allowance < max, triggering safeApprove from non-zero to non-zero which reverts.
**Steps:**
1. Deposit LP into WIchiFarm: allowance(this, ichiFarm) != max so safeApprove(max) is called, succeeds.
2. ichiFarm pulls LP via transferFrom, decrementing allowance below max.
3. Second deposit: allowance != max again, so safeApprove(max) is called.
4. safeApprove requires current allowance == 0 or value == 0; neither holds, so it reverts.
5. All subsequent deposits revert, bricking the wrapper.
**How found:** Read IchiVault's deployed transferFrom source and noticed it always subtracts allowance, contradicting the code comment claiming allowance won't decrease if set to max; traced the second-deposit path into safeApprove.
**Insight:** When code comments assert an external token's allowance behavior (e.g. 'won't decrease if max'), verify against the actual deployed token source; non-standard ERC20s that decrement max allowance break safeApprove-based re-approval logic.