Most ERC-20 tokens move the exact amount you send. If you transfer 100 tokens, the recipient gets 100 tokens. A smaller category of tokens does not work that way. These are usually called fee-on-transfer tokens, or "tax tokens," and understanding how they behave can save you from a confusing swap result, or worse, from a token that was never meant to be sold at all.
How a normal token transfer works
The ERC-20 standard defines a transfer function that moves a fixed amount from one address to another. Nothing about the standard requires that the amount received equals the amount sent. Most tokens implement it that way because it is simple and predictable, but the standard leaves room for token creators to add extra logic inside that function, and some do.
What a fee-on-transfer token adds
A fee-on-transfer token runs extra code on every transfer. Instead of moving the full amount, it might send only 95 percent to the recipient and redirect the rest: some to a burn address to reduce supply, some to a treasury or development wallet, some back into a liquidity pool. Projects that use this design usually say so up front, and it is a legitimate, if uncommon, tokenomics choice rather than a scam by itself.
The practical problem shows up when you swap. A decentralized exchange calculates how many tokens you should receive based on the pool's pricing curve, then executes the transfer. If the token takes a cut mid-transfer, you receive less than the quote promised, even though nothing went wrong technically. Many router contracts and swap interfaces are not built to account for this, and a swap that should have gone through can revert instead, because the actual amount received falls outside the slippage tolerance you set.
This is one of the more common, non-malicious reasons a swap fails with an error like "insufficient output amount." Related concept: swap fees and slippage.
Where honeypots come in
A honeypot token borrows the same mechanism for a different purpose. Instead of a modest, disclosed fee, the contract is written so that buying works normally but selling does not. A common approach is a hidden condition in the transfer logic that only blocks sales, or a fee that can be raised to 100 percent after launch by whoever controls the contract. From the buyer's side, everything looks fine right up until they try to exit: the transaction either reverts, or it succeeds while returning close to nothing.
The setup usually follows a pattern. A token launches with a website, some social presence, and a liquidity pool that looks real. Early buyers who test a small purchase and resell quickly may even succeed, which builds false confidence, since the restrictive logic is sometimes turned on later or only triggers past a certain sell size. By the time a wider group of buyers has capital in the token, exits are already blocked.
Why this is hard to catch by reading the token alone
Fee percentages and sell restrictions live in the contract's code, not in anything a token's name, symbol, or logo can tell you. Two tokens can look identical in a wallet's asset list while one transfers cleanly and the other cannot be sold at all. This is also why a swap interface's price quote is only an estimate: it reflects the pool's math, not necessarily what the token's own transfer logic will actually deliver.
Related background: spotting scam tokens on Base and what a smart contract audit covers.
Practical ways to protect yourself
A few habits reduce the risk considerably:
- Test with a small amount first. Before committing significant funds to an unfamiliar token, buy a small amount and try selling a portion of it back. This will not catch every honeypot, since some only activate later or above a threshold, but it filters out the more obvious ones.
- Use a transaction simulator when available. Some wallets and block explorers can simulate a transaction before you sign it, showing what a swap is actually expected to do. See transaction simulation explained.
- Check the contract on a block explorer. A verified contract lets anyone read the actual source code behind a token. Look for functions that can change fees, blacklist addresses, or pause transfers, and check whether ownership has been renounced. See how to use a block explorer and what a verified contract on Basescan means.
- Be skeptical of unusually high yields or aggressive marketing. Honeypots and heavy tax tokens are frequently paired with hype to attract buyers quickly, before word spreads that selling does not work.
- Revisit your token approvals. Even if you never try to sell a bad token, it is worth checking what spending allowances you have granted. See how to check and revoke token approvals.
The takeaway
Not every token that takes a fee on transfer is malicious, and disclosed transfer taxes are a known, if niche, design choice. But the same code path that implements a legitimate fee is exactly what a honeypot uses to block sales. Treat any unfamiliar token with built-in transfer logic as worth a small, cautious test before committing meaningful funds, and lean on block explorers and simulators rather than a project's marketing to judge whether it behaves the way it claims.