# Too few `ICHI` v2 farming reward tokens transferred to the user due to incorrect decimal precision

WIchiFarm.burn divides reward accumulator by 1e18 though ICHI v1 accumulators use 9 decimals, so users receive ~1e9x too few ICHI v2 farming rewards.

- Payout: Contest reward
- Severity: high
- Program: Blueberry
- Credited: berndartmueller
- Disclosed: 2023-02-01
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-blueberry-judging/issues/319
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-blueberry%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity vuln:accounting-error vuln:precision-loss

**Target:** WIchiFarm.sol burn() reward calculation
**Root cause:** stIchiPerShare/enIchiPerShare accumulators are in 9-decimal ICHI v1 precision, but burn() divides by 1e18 (18-decimal assumption) while amount is 18-decimal, yielding a 9-decimal result transferred as 18-decimal ICHI v2.
**Steps:**
1. Call `WIchiFarm.burn(id, amount)` with an 18-decimal amount.
2. Observe `stIchi = (stIchiPerShare * amount).divCeil(1e18)` and `enIchi = (enIchiPerShare * amount) / 1e18` produce 9-decimal precision values.
3. Compare to ICHI v2 token which uses 18 decimals; `ICHI.safeTransfer(msg.sender, enIchi - stIchi)` sends ~1e9x too few tokens.
**How found:** Code review of burn() reward math; cross-checked ICHI v1 (9 decimals) vs v2 (18 decimals) on Etherscan and inferred accumulator precision from ichiFarmV2.harvest transfer behavior.
**Insight:** When wrapping a legacy token into a new token with different decimals, verify every accumulator/denominator against the source token's actual decimals, not the destination's.