# Transferout exclusive feeOnTransfer tokens will run out of well

Basin Well assumes fee-on-transfer fees come from recipient; sender-side fee tokens cause stored reserves to exceed real balances, draining the well.

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

**Target:** Well.sol AMM swap/skim/sync logic
**Root cause:** swapFromFeeOnTransfer only accounts for fees on the incoming token; for outgoing tokens it assumes fees are deducted from the recipient, so when a token charges the sender, stored reserves exceed actual balances.
**Steps:**
1. Deploy Well with a token that charges fee on sender during transferOut
2. Attacker swaps to raise price of the fee-on-transfer token
3. Attacker transfers token to Well and calls `skim`, cutting well funds
4. Repeat until well token balance approaches 1
5. Call `sync` then swap to drain paired token
**How found:** Code review of Well.sol transferOut paths (L610, L304, L370) noting no check of actual received/sent amounts and that swapFromFeeOnTransfer only handles incoming-token fees.
**Exploitation:** Repeated skim cycles exploit the growing discrepancy between stored reserves and actual balances caused by sender-side transfer fees, eventually draining the well's paired token via sync+swap.
**Insight:** When auditing AMMs claiming fee-on-transfer support, verify both inbound AND outbound fee handling; sender-side fee tokens break reserve accounting because reserves are set to computed amounts, not actual balances.