# ERC4626 does not work with fee-on-transfer tokens

ERC4626 deposit uses pre-fee assets to compute shares, letting fee-on-transfer tokens mint more shares than intended.

- Payout: Contest reward
- Severity: medium
- Program: Astaria
- Credited: Bnke0x0
- Disclosed: 2022-11-07
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-astaria-judging/issues/3
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AM-26
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:share-inflation

**Target:** ERC4626-Cloned vault deposit/mint
**Root cause:** deposit() computes shares from the requested `assets` amount but the contract receives less after the token fee, so totalAssets and totalShares diverge from the intended ratio.
**Steps:**
1. Deploy vault with a fee-on-transfer underlying token (e.g. 20% fee).
2. Call `deposit(500)` twice instead of `deposit(1000)`.
3. Each deposit mints shares based on pre-fee 500 while totalAssets only grows by 400.
4. Observe total shares exceed those from a single deposit of 1000.
**How found:** Code reading of deposit() noting safeTransferFrom uses `assets` while previewDeposit also uses `assets`, then comparing single vs split deposits under a fee assumption.
**Exploitation:** Attacker splits deposits into smaller chunks to repeatedly mint shares priced on pre-fee amounts, diluting existing shareholders and extracting value on redeem.
**Insight:** When auditing ERC4626 or share-based vaults, check whether share math uses the requested amount or the actually-received balance; split-deposit arithmetic exposes fee-on-transfer and rebasing mismatches.