# ReaperVaultERC4626 is not EIP-4626 compliant and integrations can result in loss of funds

ReaperVaultERC4626.withdraw/redeem silently return fewer assets than requested when a strategy reports a loss, violating EIP-4626 and breaking integrator assumptions.

- Payout: Contest reward
- Severity: medium
- Program: Ethos Reserve
- Credited: DadeKuma
- Disclosed: 2023-05-02
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-02-ethos-findings/issues/247
- Library page: https://bugbountylibrary.com/r/c4%3A2023-02-ethos%3AM-12
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error

**Target:** ReaperVaultERC4626 / ReaperVaultV2 ERC-4626 vault
**Root cause:** In _withdraw, strategy-reported losses are subtracted from `value` before transfer, so the receiver gets less than the requested `assets` instead of the call reverting as EIP-4626 mandates.
**Steps:**
1. Call `withdraw(assets, receiver, owner)` on ReaperVaultERC4626 where assets exceed idle vault balance.
2. Vault iterates withdrawalQueue, calling `IStrategy.withdraw` on each strategy.
3. A strategy returns a nonzero `loss`; code does `value -= loss` and `_reportLoss`.
4. `token.safeTransfer(_receiver, value)` sends less than `assets`; no revert occurs.
5. Same flaw applies to `redeem`.
**How found:** Code-reading against the EIP-4626 spec: compared the spec's MUST-revert-on-slippage requirement to the withdraw implementation and traced into _withdraw's loss-handling branch.
**Exploitation:** Not directly weaponized; an integrator trusting EIP-4626 semantics (exact assets out or revert) could misaccount, e.g. downstream protocols crediting full `assets` while receiving less, causing fund shortfalls.
**Insight:** When auditing ERC-4626 vaults, diff each function's actual transfer amount against the spec's exact-assets guarantee; loss-reporting and fee-deduction branches inside _withdraw/_redeem are where silent under-delivery hides.