TrustDex › Guides › Token taxes & slippage
Token taxes, transfer fees and slippage: where your trade actually goes
Between the quote you see and the tokens you receive sit three separate leaks — the pool's price impact, your slippage setting, and the token's own tax code. Confusing them is how people get quietly clipped.
Most traders discover tax tokens the unpleasant way: a swap that should have delivered a round number delivers noticeably less, or refuses to execute until slippage tolerance is cranked to an alarming figure. Neither event is random. Both are the visible edge of mechanics written into the token itself — code that takes a cut of every transfer and, in the hostile cases, is designed to grow that cut once you're committed. Understanding who takes what, when, and under whose control turns these surprises into things you can measure before money moves.
Measure a token's real cost of exit
Paste an address to see fee configuration and risk flags before you size a trade.
Buy taxes, sell taxes, and who's on the receiving end
A taxed token skims a percentage from transfers and routes it somewhere — that's the whole mechanism. The design questions are the rate, the direction (many contracts tax sells harder than buys, since exits are where the leverage is), and the destination. Destinations vary: a burn address, a "marketing" or treasury wallet, redistribution to existing holders, or an automatic liquidity add. Each has a legitimate story attached, and each has been used as a costume. The honest implementations share three traits: the rate is fixed or capped in code, the receiving wallets are named publicly, and no address is quietly exempted. When any of those is missing, the fee stops being a funding model and starts being a spigot pointed at whoever controls it.
Fee-on-transfer under the hood: EVM hooks and Token-2022
On EVM chains, taxation is usually implemented inside an overridden transfer function: before crediting the recipient, the contract subtracts its cut and sends it elsewhere. Because this is arbitrary code, anything is expressible — different rates per direction, exemption lists, rates that read from a variable an owner can rewrite. Nothing in the ERC-20 standard constrains it, which is why the only way to know a token's true transfer behavior is to read (or have a scanner read) the actual implementation.
Solana took a more structured path. A classic SPL token cannot intercept transfers at all — no hooks, no taxes, which is a quiet safety property. The Token-2022 transfer-fee extension adds fees as a first-class, declared feature: the rate and a maximum-fee ceiling are stored on the mint where anyone can read them, and withheld amounts accrue for the fee authority to collect. Declared beats hidden — but note the same mutability catch: a live fee-config authority can raise the rate for future transfers, so the fields to check are the current rate and whether that authority has been revoked.
Slippage tolerance: the dial that lets taxes through
Slippage tolerance exists to protect you: it sets the minimum output you'll accept, and the router reverts the swap if the pool can't deliver it. Fee-on-transfer tokens collide with this protection head-on. The pool pays out the quoted amount, the token's code removes its slice in flight, and your wallet receives less than the router promised — so the safety check fails and the trade reverts. The "fix" circulating in every such token's chat is to raise your tolerance until the trade clears.
See what that actually does: your tolerance must be at least as wide as the tax, which means the setting designed to cap your losses is repurposed to authorize them. Worse, a wide-open tolerance doesn't just accept the tax — it accepts any shortfall up to that bound, inviting sandwich bots to position around your trade and take the slack the tax didn't. A token whose community tells you to set extreme slippage is disclosing its extraction rate; the number they tell you to enter is roughly the piece of your money that isn't coming back.
A working rule: price impact scales with your size and shrinks as liquidity deepens — you can manage it. A tax is invariant to both: it takes its percentage whether you trade a dollar or a fortune. If your slippage requirement doesn't fall when you cut your trade size, you're not fighting thin liquidity; you're paying a toll.
Honest fee projects versus escalating traps
The line between a fee-funded project and a slow-motion honeypot is not the existence of a tax — it's who can move it. A contract with the rate baked in at deployment can be evaluated once and trusted to stay put. A contract with setTax-style functions and no ceiling can present any rate today and a confiscatory one after you've bought; the escalation usually arrives exactly when volume peaks, because that's when the trap is worth springing. Between those poles sit hybrids worth judging case by case: capped setters, timelocked changes, fees controlled by a multisig with a published policy. The evaluation is always the same three questions — what is the rate now, who can change it, and what stops them from changing it against you?
| Trait | Fee-funded project | Extraction trap |
|---|---|---|
| Rate | Small, fixed or hard-capped | Owner-settable, no ceiling |
| Destination | Named treasury, burn, or LP — verifiable | Anonymous deployer wallets |
| Exemptions | None, or routing contracts only | Insider wallets trade tax-free |
| Disclosure | Documented before launch | Discovered by stuck sellers |
| Over time | Stable or reduced | Ratchets up as volume peaks |
Why taxed tokens break your price math
Taxes also corrupt the numbers you plan with. Charts and quotes describe the pool's exchange rate, but a taxed token's effective rate is worse in both directions: pay a buy tax and fewer tokens arrive than the pool priced; pay a sell tax and less quote asset comes back than your holdings imply. The two compound — round-tripping through a tax on each side means the token must appreciate by more than both cuts combined before you break even, before counting price impact and network fees at all. Portfolio values quietly inherit the same error, since your displayed balance is marked at a price you cannot actually realize. For meaningful taxes, the honest mark on your position is the post-tax exit value, not the chart.
Pinning down the effective tax before you commit
The real rate is an empirical question, and there are three ways to answer it. First, read the declared configuration: on Solana the Token-2022 fee fields sit on the mint in plain view, and on EVM chains verified source exposes the tax variables and — more importantly — their setters. Second, compare quote to delivery: simulate the swap, or send a genuinely small probe trade, and measure the gap between expected and received; that gap, minus normal price impact, is the tax as it exists this minute. Third, let a scanner do both, and read the mutability flags alongside the rate. Whatever the method, do it at decision time — a mutable tax measured last week describes last week. And if a token's own community coaches you to disable your slippage protection, treat the coaching itself as the finding.
Scan the fee flags, then swap with guardrails
TrustDex surfaces transfer-fee and authority data, and the swap keeps custody with you.
Frequently asked
Are token taxes the same as slippage?
No, though they get billed together. Slippage is price movement between quoting and execution, plus the price impact of your own order on the pool. A tax is a deliberate cut the token's own code takes from every transfer. Raising your slippage tolerance doesn't reduce a tax — it just tells your wallet to accept the tax without complaint.
Why does a tax token force me to raise my slippage tolerance?
Your router checks that you received at least the minimum output you agreed to. A fee-on-transfer token removes its cut mid-swap, so the amount landing in your wallet falls short of the router's math and the trade reverts unless your tolerance is at least as wide as the tax. That's why a token "requiring" high slippage is announcing the size of its cut.
Can a token's tax rate be changed after launch?
Often, yes. On EVM chains the rate usually lives in an owner-settable variable; on Solana, the Token-2022 transfer-fee extension has a fee authority that can raise the rate for future transfers if it hasn't been revoked. A modest tax with an unbounded setter is a promise, not a property — check who can move the number and how far.
Is every token with a tax a scam?
No. Some projects use small, fixed, transparently-routed fees for burns, treasury funding or reflections, and the honest ones hardcode the rate, cap it, and publish the receiving wallets. The danger pattern is different: rates that one address can raise without limit, exemptions for insider wallets, and fee proceeds flowing to an anonymous deployer.
How can I find the real tax before trading?
Compare a firm quote's expected output against what a simulated or tiny real transaction actually delivers — the gap is the effective tax. A risk scan can also read the fee configuration directly: Token-2022 fee extensions on Solana are visible on-chain, and EVM tax variables and their setters show up in verified source. Do the check at trade time, since mutable rates can change.