In the article you’ll get a clear explanation of tax (fee-on-transfer) tokens, why many communities view them as problematic, the issues they cause for swaps and integrations, and STON.fi’s viewpoint. You’ll also get a quick checklist to spot them.

What tax tokens are

Tax tokens (often called fee-on-transfer, reflection, or deflationary tokens) skim a cut on every transfer and reroute it — typically to a treasury, liquidity pool, burn address, or back to holders. This cut is taken inside the token’s own transfer logic. It’s separate from network fees and separate from the DEX swap fee. As a result, the amount a receiver gets is lower than the nominal amount a router attempts to deliver.

Designs vary. Some split a fixed percentage between “liquidity,” “marketing/dev,” and “reflection” (rewards to holders). Others set different buy vs sell taxes. In many contracts the owner can modify rates after launch, toggle lists of allowed addresses, or change how the cut is routed. That flexibility is exactly where the trouble starts.

Read more on the basics of tax tokens in “Taxable tokens: basics & where they came from”

Why communities are skeptical

Builders and users don’t love mechanics that extract value from every transfer by default. Even when the narrative is “fund development,” “support liquidity,” or “reward holders,” the source of those funds is other users’ swaps. Communities also have a long memory: plenty of high-profile tax-token experiments either faded out or later dropped the taxes when they wanted broader adoption. The model is not mainstream among serious teams that aim for predictable user experience and credible market structure.

Explore the landscape and real examples of tax tokens in “The landscape: what common tax tokens are, which designs you’ll meet, and what real projects are there”

The practical problems tax tokens cause

Unpredictable delivery. A DEX can quote 10,000 units out, but the token’s transfer subtracts its own tax mid-flight. Depending on the token’s mechanics and tax rate, this can affect the final received amount, increase execution uncertainty, or make the swap technically unsupported.

Router support gaps. Some routers are designed to accommodate fee-on-transfer tokens; many aren’t. Users see “insufficient output,” stuck approvals, or confusing “expected to fail” messages. Support is inconsistent across chains and versions.

Variable parameters. If tax rates or routing can be changed by the token owner post-launch, the user cannot predict outputs reliably. At the extreme, a sudden sell-tax hike looks and feels like a trap.

Bad UX for everyone else. Even when a token isn’t malicious, fee-on-transfer breaks mental models. Quotes don’t match receipts, analytics are noisy, and integrations need custom branches that add maintenance and risk.

Where it blurs into honeypots

ℹ️ Honeypot is a smart-contract trap where you can buy the token but cannot sell or transfer it out under normal conditions. 

Once you combine transfer taxes with owner-only permissions — blacklists/whitelists, pausing transfers, editing fees on demand — the boundary between “tax token” and “you can get in but not out” becomes thin. Automated systems cannot always judge intent. That ambiguity is why STON.fi treats taxable tokens as a special-risk category and adds restrictions and warnings instead of treating them like standard assets.

Read more in “How tax tokens trade: quotes, slippage, and what really lands in your wallet”

STON.fi’s position

To protect users and keep swaps predictable, STON.fi treats tax (fee-on-transfer) tokens as a special-risk category. STON.fi provides limited support for taxable tokens when they can be handled within strict technical safeguards. Because there is no predictable, ecosystem-wide standard for these mechanics, swap outcomes can still vary from token to token in ways users should understand before confirming a transaction.

STON.fi isn’t a simple AMM front end. We aggregate liquidity and build multi-hop routes across different DEXs. Beyond swaps, users run complex flows — for example, swap → add liquidity (including arbitrary provision and other options). In these chains, a tax token’s unpredictable behavior doesn’t just affect one step; it can propagate through the whole route. This is exactly why taxable tokens cannot be used as intermediate assets on STON.fi. A taxable token may be supported only as the asset the user directly sends or receives, not as a middle step in a route.

If a token’s transfer tax is above 10%, swaps involving that token are not supported for technical reasons.

We use a combination of automatic detectors and manual reviews to identify taxable tokens, show warnings in the interface, and apply additional measures. Reasons are straightforward:

  • They can degrade swap reliability with unpredictable delivery, tax-adjusted received amounts, and higher failure risk.
  • Tax logic changes the amount delivered mid-transfer. Because there is no unified standard for how that tax is computed, routed, or updated, STON.fi applies additional safeguards rather than treating taxable tokens as ordinary assets.
  • Tax tokens inject uncertainty at each hop. To keep complex flows reliable, taxable tokens cannot be used as intermediate assets in swap routes.
  • Adjustable taxes and address controls live too close to honeypot behaviors for an automated, user-safe platform.
  • “Redistribution,” “marketing,” and “burns” are ultimately funded by skimming other users’ transfers; that’s extraction by design.
  • The long-run pattern in reputable projects is to abandon heavy transfer taxes, not embrace them.

Our goal is a predictable, composable swap experience. Tax tokens pull the other way, so STON.fi does not treat them as standard assets. Taxable tokens may be available in the STON.fi dApp‘s interface with a clear warning, but they cannot be used as intermediate assets in routes. If the token’s transfer tax is above 10%, the swap is not supported for technical reasons. At the protocol level, pools involving taxable tokens may still exist and may be reachable directly via smart contracts or through third-party interfaces.

How to spot a tax token quickly

  • The project docs mention buy/sell “tax,” “reflection,” “marketing” or “liquidity” fees taken on every transfer.
  • The team instructs users to set very high slippage for swaps.
  • Contract exposes owner functions to edit tax rates after launch.
  • Blacklist/whitelist or “onlyFrom/onlyTo” logic is present.
  • Promises of “auto-liquidity,” “automatic burns,” or “holder rewards” tied to every transfer.
  • Explorer traces show transfers consistently receiving less than they should, independent of normal fees.

If you hit two or more of these, assume fee-on-transfer mechanics and treat the token as high-risk. Check whether the interface marks it as taxable, and whether you understand how the transfer tax affects the final received amount.
Always DYOR: thoroughly explore the projects and make decisions independently.

Common counterarguments and the reality

🤔 “Taxes fund development.” If a project needs funding, there are clearer, less adversarial models: transparent treasuries, grants, or explicit protocol fees governed by a DAO. Invisible skims on every transfer are the worst way to do budgeting.

🤔 “Reflections reward holders.” Reflections pay some holders by charging all swappers. In volatile markets, that creates perverse incentives and does not replace sound token economics.

🤔 “Burns increase scarcity.” Burning taxed tokens doesn’t change that the tokens came from users. Scarcity mechanisms are unlikely to be effective without credible, sustained demand.

Bottom line

Decentralization doesn’t mean anything-goes. We strike a deliberate compromise: the interface includes guardrails for safety, while the protocol is decentralized and permissionless.

Tax tokens make swaps less predictable, add failure modes, and concentrate power in the token owner’s hands. Communities are wary for good reasons, and many projects that tried the model dropped it later.

In app.ston.fi, we act as a safety layer: taxable tokens are shown with warnings, cannot be used as intermediate assets in routes, and are not supported if their transfer tax is above 10%. Some taxe tokens that align with the interface policy, may be searchable by their names and be swapped via STON.fi dApp. Anyway, at the protocol level, pools involving taxable tokens still exist and may be reachable directly via smart contracts or through third-party interfaces.

If the TON ecosystem agrees on a tax-token standard with predictable behavior, explicit caps, and integration guarantees, we may evaluate broader support in future protocol versions.

If you understand how to spot tax tokens, you can better evaluate the warnings and execution risks before interacting with them.

Share this article: