apegurus/fee-on-transfer-tokens

<!-- Source: BailSec audit reports (CC0) --> <!-- Extracted via audit-ingest pipeline from 5 independent protocol audits -->

Fee-on-Transfer Token Incompatibility

Overview

Protocols that assume transferFrom(sender, recipient, amount) delivers exactly amount tokens to the recipient will break when interacting with fee-on-transfer (deflationary) tokens. These tokens deduct a fee during transfer, so the actual received amount is less than the specified amount. This creates accounting mismatches that can lead to insolvency, stuck funds, or exploitation.

Severity: Informational to Medium (depends on whether the protocol explicitly supports or excludes these tokens)

Prevalence: Found in 5 independent BailSec audits: Gamma UniswapV4, Gamma Vaults, Meuna, Moebius Finance, Terminal Finance DEX.

---

Vulnerable Pattern

// VULNERABLE: Assumes amount received == amount transferred
function deposit(address token, uint256 amount) external {
    IERC20(token).transferFrom(msg.sender, address(this), amount);
    // If token has 2% fee, contract only received 0.98 * amount
    // but records the full amount — accounting is now wrong
    balances[msg.sender] += amount;  // Overstated!
}

Secure Pattern

// SECURE: Measures actual received amount
function deposit(address token, uint256 amount) external {
    uint256 balanceBefore = IERC20(token).balanceOf(address(this));
    IERC20(token).transferFrom(msg.sender, address(this), amount);
    uint256 received = IERC20(token).balanceOf(address(this)) - balanceBefore;
    balances[msg.sender] += received;  // Correct accounting
}

Impact

• Accounting mismatch: Protocol records more tokens than it holds, leading to insolvency over time
• Failed withdrawals: Later users cannot withdraw because the contract has fewer tokens than expected
• Vault share inflation: In vault/pool contexts, shares are minted for a larger amount than actually deposited
• Arbitrage opportunity: Attackers can exploit the mismatch to extract value from the protocol

Affected Token Examples

| Token | Fee Mechanism | Notes | |-------|--------------|-------| | SAFEMOON | 10% tax on transfer | Reflection + burn + liquidity | | STA (Statera) | 1% deflationary burn | Destroyed on each transfer | | PAXG | 0.02% transfer fee | Gold-backed, fee goes to Paxos | | USDT (potential) | Configurable fee (currently 0) | Has fee infrastructure built-in |

Detection Checklist

1. Does the contract call transferFrom() or safeTransferFrom() and then use the amount parameter directly?
2. Is there a balanceOf(address(this)) check before and after the transfer?
3. Does the protocol documentation state support for fee-on-transfer tokens?
4. Are there any allowlists/denylists for supported tokens?

Remediation

1. Measure actual received: Use before/after balanceOf to determine the actual amount received
2. Document token support: Explicitly state whether fee-on-transfer tokens are supported
3. Token allowlist: If the protocol only supports standard tokens, enforce an allowlist
4. Revert on mismatch: Add a check that reverts if received amount differs from expected

References

• Weird ERC20 Tokens — Fee on Transfer
• OpenZeppelin SafeERC20 documentation
• BailSec audit reports: Gamma, Meuna, Moebius Finance, Terminal Finance DEX