# Frontrun `deposit()` can cause the depositor to lose all the funds

Attacker frontruns first depositor by sending 1 wei LINK directly to Vault, making totalShares==0 but supplyBeforeTransfer>0, so newShares rounds to 0 and depositor loses funds.

- Payout: Contest reward
- Severity: medium
- Program: Mycelium
- Credited: ctf_sec
- Disclosed: 2022-10-03
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-mycelium-judging/tree/main/029-M
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-mycelium%3AM-4
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:share-inflation

**Target:** Vault.sol onTokenTransfer/deposit share calculation
**Root cause:** Share minting computes newShares from supplyBeforeTransfer without checking totalShares==0, so a pre-existing 1 wei balance makes newShares round down to 0 for the first depositor.
**Steps:**
1. Attacker transfers 1 wei LINK directly to Vault contract (no shares minted, totalShares stays 0).
2. Victim calls `deposit()` / triggers `onTokenTransfer()`; supplyBeforeTransfer = 1, totalShares == 0.
3. newShares = amount * totalShares / supplyBeforeTransfer = 0.
4. Victim receives 0 shares; their deposited LINK is absorbed into the vault.
**How found:** Manual review of share math in onTokenTransfer/deposit: noticed supplyBeforeTransfer uses raw token balance while totalShares is still 0, causing division to yield 0 shares.
**Exploitation:** Attacker frontruns the first depositor's deposit tx with a direct 1 wei LINK transfer to the Vault, forcing the victim's share calculation to round to zero so the victim's deposit is captured by the vault (and future depositors).
**Insight:** When share price derives from token balance rather than tracked accounting, a direct token transfer before first mint can zero out the first depositor's shares; check totalShares==0 explicitly for first-mint logic.