Fee-on-Transfer Tokens: Why a Deposit Arrives Short

A fee-on-transfer token can reduce what the recipient receives even when the transfer succeeds. Compare three quantities separately: the amount instructed, the tokens actually delivered and the amount credited by the receiving service. A smaller deposit does not, by itself, identify the cause; token deductions, a source platform’s withdrawal charge and a recipient’s accounting rules need different evidence.

Start with the asset’s transfer rules

A token can impose its own fee when it is bought, sold or transferred. Uniswap Labs describes these token fees as issuer-set charges, separate from Uniswap Labs receiving a share. The relevant question is what the particular token does on the operation you used. A fee displayed for a swap is not enough to establish the treatment of every later wallet transfer.

Identify the network and contract address before reading a token’s documentation. A familiar ticker, a wallet icon or an old token list can point to the wrong asset. This article does not provide a permanent list of taxed tokens: a list would still leave you needing to verify the exact contract and current route. Nor does the existence of a transfer fee establish that the project is legitimate or fraudulent.

Use a three-amount reconciliation

The ERC-20 interface distinguishes token balances and transfer operations. A token transfer amount is not the native ETH value field of the enclosing transaction. For a nonstandard token, interpreting the result still requires that token’s actual implementation and the movement relevant to the recipient. One conveniently named event is not a substitute for understanding the operation.

A whole-block balance comparison can also mislead if the address had other activity. A recipient might receive another payment or move assets during the same block. Ask for evidence tied to the particular transaction rather than attributing every difference between two snapshots to your deposit. If the available records do not resolve the discrepancy, leave the cause unresolved instead of assigning it to a fee by subtraction.

A worked example that does not invent a live tariff

Suppose a fictional token instruction is for 100 units. Assume its documented rules for this exact transfer retain 3 units, with no other token deduction, and the recipient receives 97. In that deliberately simplified model, delivered amount equals 100 minus 3. The 3-unit retention is a token-side deduction; it is not an ETH gas charge. These numbers describe an example, not any listed token or exchange’s current fee.

Now suppose instead that a sending platform retained 3 units before sending 97, and the token itself charged nothing. The recipient could again receive 97, yet the cause is different. You cannot distinguish these cases from the final number alone. Compare the source withdrawal detail with the actual on-chain leg before asking the token issuer or recipient to explain the wrong deduction.

A third boundary is account credit. If a receiving address obtained 97, that fact does not promise that a service will credit the original instruction for 100. Ask what it recognizes and whether this token mechanism is supported. Do not assume that paying an extra amount will repair the situation: another transfer can create another deduction and another unsupported deposit.

Gas and transfer taxes solve different accounting problems

For Ethereum execution, gas fees are paid in ETH. A token’s retention changes token accounting. Increasing the native gas budget does not instruct that token to stop deducting its fee. A failed transaction and a successful transfer with a smaller delivered amount are also different results; establish which one occurred before choosing a next step.

Slippage tolerance is not a general repair for an exchange deposit. It belongs to the conditions of the particular swap interface or route. The 1inch explanation discusses adjusting tolerance for unusual token mechanics and warns of increased front-running risk. Do not turn that into advice to raise tolerance blindly, or into a promise that an unrelated recipient will accept the token.

Protocol support has to be checked by version and route

Two primary examples show why a generic “ERC-20 supported” label is insufficient. The Uniswap v3 integration documentation says fee-on-transfer tokens do not work with its router contracts. The OP Standard Bridge guide excludes fee-on-transfer tokens because they can cause bridge accounting errors. These are scoped restrictions, not statements that every swap or bridge behaves identically.

There is a different, equally specific example in the UniswapX repository: its fee-on-transfer disclaimer distinguishes the specified transfer from the recipient’s after-fee receipt. That is not a guarantee that any particular frontend or exchange accepts your asset. Read the documentation for the actual component handling your transfer, rather than combining descriptions of different products under one brand.

What to establish before sending more

1. Verify the exact token contract and network against the receiving service’s supported deposit route.
2. Find the token’s documented treatment of the specific transfer, rather than assuming its buy, sell and ordinary-transfer fees are identical.
3. Separate the source instruction, on-chain recipient receipt and internal credited amount.
4. Keep native gas costs in their own currency and record source-platform or route charges separately.
5. If the deposit is short or uncredited, ask the recipient which quantity it detected and whether this token behavior is supported before making another payment.

A concise support request can state the network, token contract, transaction hash, instructed amount and observed recipient amount. Ask for the credited quantity and the reason for any difference; do not send signing secrets or approve a contract merely to obtain an accounting explanation. A legitimate discrepancy needs evidence, not an unexplained extra payment.

For a later simple swap, check the supported assets and the current funding instructions. The exchange fee information concerns the service’s disclosed costs, not a promise that an arbitrary token’s mechanics are supported. An unsupported contract cannot be made compatible just by using its ticker or increasing the amount.