Fee-on-transfer token risk

Fee-on-transfer tokens can deliver less than the amount sent and charge different fees on buys, sells, or wallet transfers. Learn how to check router support, permissions, simulations, and a small round-trip test.

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A fee-on-transfer token deducts value inside its transfer logic, so the recipient may receive less than the amount passed to transfer or transferFrom. The deduction may be burned, redistributed, sent to another wallet, or routed into liquidity. The rule can also depend on the sender, recipient, or transaction context.

The main risk is not merely the advertised fee. Buy, sell, and wallet-transfer rates may differ; some addresses may be exempt or blocked; and privileged accounts may be able to change the rules. A quote or successful purchase therefore does not prove that the position can later be sold at a reasonable cost.

How it works

A conventional automated-market-maker router may calculate every output from the nominal input amount. Uniswap V2 Router02 instead provides fee-on-transfer-specific swap functions that infer the actual input from the pair’s balance change and check the recipient’s balance increase against amountOutMin. This illustrates why compatibility depends on the exact router, route, and token behavior, not just the token symbol.

Token fees compound with pool fees and price impact. A multi-hop route may trigger the transfer logic more than once, while exemptions or buy/sell detection can make the effective rate direction-dependent. Estimate entry and exit separately from current on-chain state.

Example

Suppose a trader spends 1,000 USDC. Pool fees and price impact reduce value by 2%, followed by a 5% buy fee: 1,000 × 0.98 × 0.95 = 931. If the market price is unchanged, a 10% sell fee followed by another 2% of trading friction returns about US$821: 931 × 0.90 × 0.98 ≈ 821. The round-trip loss is about 18% even though the market price did not fall.

This is an illustration, not a quote. The deduction order may differ, and rates, liquidity, routing, and contract state may change between transactions. Read the current contract and pool state, then simulate the exact route and wallet before relying on an estimate.

Risks and checks

Verify the contract address and deployed code. Identify fee logic, exemptions, blocklists, maximum-fee constraints, owner roles, upgrade controls, and pause powers.
Compare the quoted output with the recipient’s simulated balance change. Confirm that every router and hop in the route explicitly handles fee-on-transfer behavior.
Simulate a sale from the same wallet, then use only a small round-trip test you can afford to lose. A successful test does not guarantee that later rules or liquidity will remain unchanged.
Keep amountOutMin at a loss limit you actually accept. Setting it to 0 or repeatedly widening slippage removes price protection but cannot override a revert, blocklist, or punitive token fee.
Base position size on the worst credible net exit value. Do not proceed when sell simulation fails, the code is unverified, privileges are opaque, or an administrator can raise fees or block transfers without a meaningful delay.

Common misconceptions

Myth 1: The transfer amount or event proves how much arrived. Check the recipient’s balance change; fee-on-transfer integrations use balance differences for a reason.
Myth 2: More gas or slippage will make any sale succeed. Gas affects transaction inclusion, and slippage relaxes the minimum price; neither bypasses contract logic.
Myth 3: Renounced ownership makes the token immutable. Proxy administrators, other privileged roles, or external configuration contracts may still control behavior, so inspect every effective access path.

Sources

Uniswap V2 Router02 - Uniswap (accessed: 2026-08-20)
FeeOnTransferDetector.sol - Uniswap (accessed: 2026-08-20)
SC01:2026 Access Control Vulnerabilities - OWASP (accessed: 2026-08-20)