Fee-on-Transfer Token

Overview

The token contract modifies transfer logic so part of the amount is sent to a treasury, burned, distributed to holders, added to liquidity, or used for another purpose. The fee can be fixed, dynamic, address-specific, or controlled by an administrator.

A user can submit a transfer of 100 tokens while the recipient receives 95. Payment systems that credit the requested amount rather than the actual increase create accounting losses. Decentralized exchanges need router functions that support fee-on-transfer behavior, and some protocols reject these assets entirely.

Fees can also apply only to buys, sells, or selected addresses. Whitelisted accounts can avoid the fee, creating unequal market behavior. An administrator can sometimes raise the tax dramatically and prevent holders from selling, a common malicious-token pattern.

Balance-reflection mechanisms can change holdings without ordinary transfer events. Indexers and accounting systems need token-specific logic.

Applications should simulate transfers, inspect contract code and roles, verify maximum configurable fees, and record actual received amounts. Token approvals remain another risk.

Fee-on-transfer design can fund a project or reduce supply, but it reduces composability and predictability. A token that follows the ERC-20 interface can still behave very differently from a standard fungible transfer.

Deposit systems should either reject these tokens or credit only the observed balance increase after canonical confirmation. Precomputed invoice amounts are unreliable when the contract can change its fee. Refunds can incur another deduction, so customer communication and accounting need token-specific rules.

Related products such as Token-2022 should not be grouped automatically with Fee-on-Transfer Token. Their legal rights, custody model, market liquidity, and technical identifiers can differ.