Token Tax Mechanics: When 6% Is Reasonable, When It's a Trap
Every buy and sell of a tax token routes a percentage to a privileged wallet. Sometimes that wallet funds reflections to holders. Sometimes it's a marketing fund. Sometimes it's the dev's exit ramp. The contract decides which โ and most retail never reads the contract.
What a tax token is, mechanically
An ERC-20 with transfer tax overrides the standard _transfer() function. When tokens move into or out of the LP pair address, a percentage is split off and sent somewhere: another wallet, a treasury contract, the burn address, or the LP itself. Standard ERC-20 transfers between wallets typically don't trigger the tax โ only swaps do, because swaps go through the pair.
On Solana, the equivalent is the Token-2022 TransferFeeConfig extension. The fee is set at the mint level (a basis-point withhold percentage and a max absolute cap), and gets withheld from every transfer. Anyone with the WithdrawWithheldAuthority can claim accumulated fees from token accounts. $CRYPTOK explicitly does not use this extension โ its 6% buy/sell tax is handled at the routing layer, with 0% transfer-to-transfer fees, which is what makes in-app tipping work.
The four destinations of tax revenue
| Destination | Honest signal | Trap signal |
|---|---|---|
| Reflections โ distributed pro-rata to holders, often gated by minimum holding | Verifiable on-chain. Improves with volume. Aligns dev with holders. | "Reflections" wallet that simply holds tokens it never distributes. |
| Auto-LP โ tax pairs with quote currency and adds to liquidity | Pool grows over time. Verify by tracking LP token supply. | LP added then removed by team within hours. Rare but seen. |
| Treasury / marketing โ multisig or doxxed wallet | Multisig signers public. Spending breakdown posted. Funds CEX listings, audits. | EOA wallet, no breakdown, funds the dev's CEX deposit address weekly. |
| Dev / team โ direct-to-dev cut, often labeled "development" | โค 1โ2%. Dev keeps lights on. Doxxed team or known operator. | 3%+ direct to anonymous wallet. Sells routed to mixer. Slow rug. |
Reasonable taxes โ examples by purpose
Memecoin with active marketing
3โ6% buy / 3โ6% sell, split as: half to LP/burn, half to a doxxed marketing multisig with monthly reporting. Total round-trip cost to a trader: 6โ12%. That's reasonable for a token actively running campaigns and exchange listing efforts. $CRYPTOK's 6% (3% reflections to 10M+ holders, 3% to dev wallet for development costs) sits in this range with the unusual addition of zero transfer tax โ the only model that makes peer-to-peer tipping economically viable.
Reflection / dividend tokens
5โ10% per side, mostly reflections back to holders. The math only works if volume is consistent โ without volume, reflections are pennies and the tax is just a tax. Watch the reflections-paid-to-holder ratio over the first 30 days.
Anti-bot / launch protection
20โ30% sell tax in the first 1โ10 minutes of launch, decaying linearly to a normal rate. Acceptable only if the decay is hardcoded and verifiable on Etherscan. Variable taxes that "the team can adjust" are a backdoor wearing a costume.
Trap patterns to recognize
setBuyTax(uint256), setSellTax(uint256), or setFees(uint256, uint256, uint256) on a non-renounced contract mean the dev can change the rate to 99% mid-trade. This is the canonical honeypot pattern. If these functions exist and the contract isn't renounced, walk away.
_excludedFromFees, isBlacklisted, setBlacklist(address). The dev can flip an individual wallet to 100% sell tax to stop them exiting (look up "honeypot.is" โ token analyzer that simulates buys and sells and detects this). Solana equivalent: a non-renounced freeze authority.
TransferHook program that runs on every transfer. The hook can implement arbitrary logic โ including selectively rejecting transfers from certain wallets. RugCheck flags Token-2022 mints with active hooks; treat them as "fully privileged until you've read the hook program."
How to verify a tax claim in five minutes
- Buy/sell simulator. Use honeypot.is for EVM (Ethereum / BSC / Base). It simulates a buy and immediate sell in a fork and reports actual taxes paid plus any blacklist trigger.
- Read the contract. On Etherscan, the source code is published if verified. Search for
_taxFee,_buyTax,_sellTax,setFee,excludeFromFee,blacklist. Note which are gated byonlyOwnerand check whether owner is renounced. - Check tax recipients on-chain. The tax is sent somewhere. Find the contract's tax-recipient state variables, click the wallets, and look at where they have sent tokens historically. CEX deposits = team is selling tax revenue.
- Solana equivalent. RugCheck flags
TransferFeeConfigandTransferHookusage. Solscan's mint page shows the withheld-fee authority. If the authority is an EOA the team controls, tax revenue is at the team's discretion.
# Quick honeypot check via the public API
curl -s "https://api.honeypot.is/v2/IsHoneypot?\
address=0xCONTRACT&chainID=1" | jq '{
isHoneypot: .honeypotResult.isHoneypot,
buyTax: .simulationResult.buyTax,
sellTax: .simulationResult.sellTax,
flags: .summary.flags
}'
The six-percent benchmark
Why six? It's the rough breakeven where a tax token can fund development and reflections without crushing trader returns. Below 4% combined, you can't fund anything meaningful. Above 12% combined, the tax becomes the trade โ every round-trip is a guaranteed loss before the chart even moves. Six percent per side is the comfortable middle โ provided you know where the six is going.
Run the test on every tax token: read the contract, find the tax destinations, and ask "if these wallets emptied to a CEX tomorrow, would I be surprised?" If yes, the tax is reasonable. If no, the tax is the trap.