# It is possible that receiver and treasury can receive nothing when calling withdraw function due to division being performed before multiplication

Y2K Vault.beforeWithdraw divides before multiplying, so small withdrawals round entitledAmount to zero, sending nothing to receiver or treasury.

- Payout: Contest reward
- Severity: medium
- Program: Y2k Finance
- Credited: rbserver
- Disclosed: 2023-01-09
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-09-y2k-finance-findings/issues/378
- Library page: https://bugbountylibrary.com/r/c4%3A2022-09-y2k-finance%3AM-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:accounting-error vuln:precision-loss

**Target:** Solidity Vault.withdraw / beforeWithdraw payout math
**Root cause:** entitledAmount = amount.divWadDown(idFinalTVL).mulDivDown(idClaimTVL, 1 ether) truncates the division first, so when amount < idFinalTVL the intermediate is 0 and the whole payout becomes 0.
**Steps:**
1. Deploy market, deposit 1e24 into hedge and risk vaults
2. Warp past beginEpoch, call controller.triggerDepeg
3. Call vRisk.withdraw(endEpoch, 1e5, chad, chad) with small assets
4. Observe beforeWithdraw returns 0 and chad's WETH balance is 0
5. Compare (1e5 * idClaimTVL) / idFinalTVL which is > 0
**How found:** Code reading of beforeWithdraw payout formula noticing division precedes multiplication, then writing a Foundry PoC with a small withdraw amount to confirm truncation to zero.
**Exploitation:** User calls withdraw with a small positive assets amount; entitledShares computes to 0, feeValue 0, and both treasury and receiver transfers are zero while shares are burned.
**Insight:** In share/asset payout math, check the order of divWadDown/mulDivDown: any formula of the form (amount/total)*claim truncates to zero for small amounts; test withdraw with amounts below idFinalTVL.