How tax tokens trade: quotes, slippage, and what really lands in your wallet

Fee‑on‑transfer (FoT, “tax”) tokens change delivery, not just price: a slice of the tokens is withheld during the transfer itself and routed elsewhere. That internal skim sits in addition to normal DEX/pool fees and network gas. Because the token reduces what the recipient actually receives, swaps can fail unless your route and minimum‑received/slippage settings allow enough room for that deduction. Some routers handle this, others don’t.

What a normal swap is doing (and why that matters here)

When you trade any token, three layers show up:

1. Network gas — paid in the chain’s native coin, it never reduces the token amount delivered.
   
2. DEX/pool fee — part of the AMM’s economics. On STON.fi, the default trading fee is 0.3% per pool (typically 0.2% to LPs, 0.1% to the protocol, pools can be configured in a 0–1% range). This fee is already reflected in quotes you see in the UI.
   
3. Price impact — if your order is big relative to the pool, the rate worsens as you trade. UIs surface this and cap or warn on high impact. On STON.fi, the guide warns when price impact exceeds ~5% and explains “minimum received” as the safeguard.

None of the above reduces tokens mid‑transfer by design. They affect price, not the transfer logic itself. FoT tokens add a fourth layer: the token‑level deduction that fires when the token moves. That’s the piece that trips people up.

What changes with a fee‑on‑transfer token and common variants

Imagine the app quotes you 10,000 tokens out. With a standard token, if the market doesn’t move beyond your tolerance, you receive ~10,000 (less only to the extent price moves within your slippage limit). With a FoT token, the token contract itself may skim, say, 5%, and route it to holders/liquidity/burn/treasury. So even if the quote and pool fee were fine, the recipient ends up with about 9,500 tokens because the token withheld the rest on delivery. That’s why UIs and aggregators often tell you to allow more slippage for FoT assets: your minimum received must be high‑enough to survive both AMM math and the token’s own fee.

Buy tax vs. sell tax vs. both. Some tokens charge only on buys, only on sells, or both. Tooling like 0x v2 now reports buy and sell tax separately (buyTaxBps, sellTaxBps) so UIs can warn you which side bites. User impact: you may need a higher slippage on the taxed leg, e.g., sell‑only taxes especially affect exit pricing.

Fixed vs. changeable fees. In some designs the team can modify the tax rate after launch. GoPlus’s security docs flag “modifiable tax” as a risk because owners can raise fees, sometimes to levels that render a token untradeable. User impact: centralization risk, so you rely on a switch you don’t control.

Why some routers fail and others succeed

Routers that assume “whatever goes out of the pool arrives 1:1 at the recipient” can break on FoT tokens. Historically, e.g., Uniswap v2 added special swap methods ending in “SupportingFeeOnTransferTokens”. These check what lands with the recipient rather than what leaves the pool, so the transaction doesn’t revert just because the token trims the amount en route.

By contrast, Uniswap v3 says it plainly in its docs: fee‑on‑transfer tokens do not function with the v3 router. Projects would need wrappers or custom routers, and the core team doesn’t plan to support FoT tokens there. That is a strong signal that FoT behavior is non‑standard and not universally supported.

Quotes vs. “minimum received”: reading the screen correctly

User interfaces usually show two different ideas:

• Estimate/quote — the best guess given pool price and fee tiers right now.

• Minimum received — the protective floor your transaction enforces (what many wallets label as “slippage tolerance” in percent).

For standard tokens, setting a tight tolerance (e.g., 0.5–1%) often works in liquid pools. For FoT tokens, your tolerance has to cover the token’s own fee plus normal price wiggles. Otherwise you’ll see “insufficient output” or “expected to fail” type errors because the transfer lands below your floor (we will discuss them in more detail below). Interfaces explicitly warn about this behavior. Matcha’s help center, for example, calls out the problem and why higher settings are sometimes required for taxed tokens.

If you’re trading on STON.fi, the app emphasizes “minimum received” and price impact rather than a raw “slippage slider.” Functionally, it’s the same safety valve: the contract protects you from receiving less than a chosen floor and the UI warns of high price impact.

“Looks liquid, hard to exit” — the honeypot trap

Some tokens appear tradable (liquidity exists, buys go through) but selling is blocked or punitive. Support docs on DEXes flag unsellable tokens (“honeypots”) and list typical causes: very high sell fees and whitelist/blacklist checks in the token contract. Security researchers echo this pattern and show blacklist‑based honeypots where non‑privileged wallets simply cannot sell. Treat any token that demands extreme sell slippage or constantly shows “expected to fail” as a major red flag. 

Common failure messages and what they’re really telling you

• “Insufficient output amount” / “Transaction expected to fail.” Either your floor is too tight for a FoT deduction, or the token’s sellability/permissions are problematic.

• “Increase slippage.” The UI is hinting that the token, not just the market, is eating into delivery. That’s typical for FoT tokens, so bump carefully and re‑check the math.

A simple mental model

1. Router finds a route and prices your swap — the AMM fee (e.g., STON.fi’s default 0.3%) is already in there.
   
2. You set a floor — “minimum received” (implicitly a slippage tolerance).
   
3. Transfer happens — if the token is FoT, it skims its fee (tax) during delivery.
   
4. Settlement checks — if the skimming + price movement push received tokens below your floor, the swap reverts. Routers designed for FoT avoid checking the wrong amount (they look at recipient balance, not just pool exit).

How to set slippage without handing the market a blank check

Your goal is to cover the token’s fee with a small buffer, not to invite bad fills.

• Know the fee (or assume conservatively). If docs say 5% buy tax, start a touch above that, say 6–7%, and only increase if the UI still projects a revert. If the fee is unknown or variable, consider a tiny test swap first. (Matcha cautions that some taxed tokens may need 10 or even 20% tolerances; that’s a yellow flag, not a challenge.)
  
• Mind the venue. If you rely on protocols, such as Uniswap v3, remember the router won’t support FoT tokens. In that case, use a DEX or aggregator that handles them (such as SushiSwap, PancakeSwap, Uniswap V2, or Matcha by 0x, 1inch) or you’ll fight the tooling.
  
• Watch “minimum received,” not just the quote. That’s your real protection on STON.fi, Uniswap V2 and elsewhere. If your floor ends up way under the quote, ask yourself whether the trade still makes sense.
  

Sources & further reading

• 1inch Help — What is a fee on a transfer token? (clear definition and behavior).

• Matcha Help — Buy/Sell tax tokens (why naive settlement fails; slippage ranges sometimes needed).

• 0x docs & case study — Buy/Sell tax detection & execution in 0x v2 and Matcha v2.

• STON.fi docs & guide — per‑pool fee model and UI concepts (“minimum received,” price impact).

Read next: The landscape: how common tax tokens are, which designs you’ll meet, and what real projects are there