Token Transfer Tax: Buy-Path Receipts Are Not Sell-Path Receipts

1. Tax rates are claims; receipt ratios are the object of study

The ERC-20 standard requires transfer and transferFrom to move balances and emit events. It does not forbid an implementation from taking a fee, rejecting a receiver, or switching rules when the counterparty is a trading pair. A website that prints “5% buy / 5% sell” is therefore a claim. What a researcher can measure are three receipt ratios: wallet to wallet, stablecoin into the token (buy path), and the token back into a stablecoin (sell path).

Front ends often collapse those three numbers into one percentage because they display a reserve-based quote as if it were the amount that will arrive in a wallet. Quote helpers typically read reserves and the pool fee tier; they do not execute the token’s own transfer hook. A common pattern follows: buys land near the advertised tax, peer transfers barely deduct, and sells take far more or revert. My working rule is to take tradability from the worst of the three paths, not from the most flattering line on a landing page.

2. A worked example: 5% advertised, 40% received on the sell path

Suppose a token advertises a 5% buy tax and a 5% sell tax. Ignore AMM price impact and the pool’s swap fee; isolate what the token contract withholds during transfer. Inputs are 1,000 display units.

Using the buy-path 95% as a holding-cost estimate treats the missing 550 units on the sell path as unrealised profit. Report the three frictions separately: 5% to enter, 1% to move between wallets, 60% to exit. They must not be averaged, and the buy column must not stand in for the rest.

A gap is not automatically malice. An implementation may raise a “sell tax” dynamically, list the pair as a high-tax address, or route fees to a marketing contract. The research job is to pin the numbers before naming a motive. Conversely, a successful peer transfer does not prove that a sale works: many implementations allow ordinary wallets to move tokens, then raise the tax or revert when the receiver is the pair.

3. Simulate at a pinned block; do not reuse another quote

Complete the checks at one block height. Read decimals, balanceOf and pair reserves, then construct an ordinary transfer, a buy-side swap and a sell-side swap. The swaps should use the pair or router the token actually trades through; calling transfer alone does not constitute a sale. eth_call does not broadcast a transaction and is suitable for reading return values or revert reasons. It also does not lock the next live trade; state can change immediately afterwards.

Uniswap V2’s swap interface notes separate “output implied by reserves” from “amount the token contract actually sends”. If a simulated buy returns 950 and a sell at the same block reverts, record executable sell size as zero rather than recycling 950. Log the revert reason as well: a cap, a cooldown, trading-disabled and a blocked receiver each imply a different follow-up. This article discusses how to read those public results. It does not provide steps for bypassing limits or for building harmful tokens.

4. Dust tests systematically understate sell friction

If the implementation withholds a fixed fraction, a 1-unit test and a 10,000-unit test can look alike. Per-transaction caps, tiered rates, allowlists and a surcharge on the first sale make the ratio jump with size and sender. A conservative research screen is: the sell-path receipt should be at least 90% of the receipt implied by the advertised sell tax, and the intended size itself must succeed. A 5% advertised sell tax implies a 95% receipt; a simulated 40% is 40/95≈0.42, well below 0.90, so the advertised rate fails the check.

0.90 is not an industry safety standard. It is only a reproducible inequality for “are the claim and the measurement in the same order of magnitude?” It ignores AMM slippage, pool fees and parameter changes in the next block. If an admin can edit the tax, the pair address or a trading switch, one passing call does not extend into the future.

5. Keep a record another researcher can replay

A minimum record includes chain ID, block number and hash, token and pair addresses, both decimal precisions, advertised buy and sell taxes, inputs and receipts on all three paths, whether the sell simulation reverted and why, whether the sender is listed, and any per-transaction cap. For a proxy, store the implementation at that block so an upgrade is not misread as a sudden tax change.

Reconcile in a fixed order: advertised implied receipt, then wallet transfer, then buy path, then sell path. Any remainder that pool fees and integer rounding cannot explain belongs in unexplained deductions. Unexplained is not an accusation; it is a ban on writing the remainder into a “verified 5% tax”.

6. Tradability is decided by the worst path

A smooth buy only shows that capital can enter. A smooth wallet transfer only shows that balances can move. Whether a holder can exit near the advertised cost is a sell-path question. A useful conclusion states buy-path receipt x%, sell-path receipt y% or not executable, wallet-transfer z%, and the gaps versus the advertised rates. Until y is measured, projecting holding cost or “net yield” from buy-side friction gives accounting uncertainty a precise-looking label.

This is a research framework with hypothetical calculations, not a safety opinion on any token and not investment advice.