# First depositor can break minting of shares

First depositor mints 1 wei share then donates large assets, causing later depositors' shares to round to zero and their funds accrue to attacker.

- Payout: Contest reward
- Severity: high
- Program: Rubicon
- Credited: MiloTruck
- Disclosed: 2022-08-01
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-05-rubicon-findings/issues/397
- Library page: https://bugbountylibrary.com/r/c4%3A2022-05-rubicon%3AH-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:share-inflation

**Target:** BathToken share-minting deposit logic
**Root cause:** Share allocation uses (assets*totalSupply)/_pool with no minimum-liquidity burn or zero-share check, so a large donation inflates _pool and rounds victim shares to 0.
**Steps:**
1. Attacker calls `openBathTokenSpawnAndSignal()` with `initialLiquidityNew = 1`, creating bath token with totalSupply = 1
2. Attacker transfers large amount (e.g. 1000000) of underlying token directly to bath token contract
3. Victim calls `deposit(1000)`; shares = (1000*1)/1000000 = 0.001 rounds down to 0
4. Victim receives 0 shares; deposit accrues to attacker holding the only share
**How found:** Recognized the classic Yearn/ERC4626 first-depositor donation attack (TOB-YEARN-003) pattern in the share formula and reproduced it with a Hardhat test.
**Exploitation:** Attacker seeds pool with 1 wei share, donates a large balance to inflate _pool, then any victim depositing less than the donation gets zero shares while their assets are captured by the attacker's sole share.
**Insight:** Any vault using (assets*totalSupply)/pool without dead-share minting or a nonzero-share require is vulnerable to donation-based share inflation; check totalSupply==0 branch and rounding.