Tax tokens on TON: what they are and why they aren’t on STON.fi

Tax tokens on TON: what they are and why they aren’t on STON.fi

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.

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.

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. Unless you crank slippage way up, the swap fails. If you do crank slippage up, you invite worse execution.

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 alone is enough to avoid listing them on a swap interface that targets reliability.

STON.fi’s position

To protect users and keep swaps predictable, STON.fi disables tax (fee-on-transfer) tokens in the interface. It’s a consequence of how our pool contracts work and the lack of a common standard for these mechanics. Without a predictable, ecosystem-wide spec, swap outcomes vary from token to token in ways our contracts cannot safely model. 

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 hurt one step; it propagates. Tokens can get stuck mid-route in an intermediate contract or side pool, where recovering them is difficult or impossible. This is exactly the scenario we’re designing against — hence the UI filter for tax tokens, while the permissionless protocol remains unchanged.

We use a combination of automatic detectors and manual reviews to identify tax tokens and hide them in the interface. Reasons are straightforward:

• They degrade swap reliability with unpredictable delivery, forced high slippage, and higher failure rates.
• Tax logic changes the amount delivered mid-transfer. Because there is no unified standard for how that tax is computed, routed, or updated, our pools cannot deterministically account for it across all cases. 
• Tax tokens inject uncertainty at each hop. To keep complex flows reliable, we exclude these tokens in the interface.
• 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. Pools involving tax tokens can be created and may be accessible via third-party interfaces that use STON.fi protocol/pools. However, in app.ston.fi these assets are filtered by the UI and not available for swapping. In short: a pool may exist on the protocol, but the STON.fi interface won’t surface it or route through it.

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 consider walking away.
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 and hide tax (fee-on-transfer) tokens in the UI to keep swaps predictable. At the protocol level, there are no restrictions: pools involving such tokens can be created and may be reachable directly via smart contracts or through third-party interfaces that choose to allow them. 

If the TON ecosystem agrees on a tax-token standard with predictable behavior, explicit caps, and integration guarantees — we’ll evaluate support in a future protocol version. 

If you understand how to spot tax tokens, you can avoid costly surprises and stick to assets that behave as expected.