Transfer taxes: reconcile sent and received token units
For a token with transfer deductions, the amount requested, the sender’s debit and the recipient’s credit can differ. Research the actual balance movement at every relevant hop before interpreting volume or fee income. A transaction’s nominal input is not automatically the amount delivered to the final recipient.
Uniswap’s v3 integration warning identifies fee-on-transfer behavior as incompatible with its standard router contracts. That is a version-specific integration statement, not a claim that every venue handles such tokens identically. Inspect the actual token implementation and route used in the observation.
Separate deduction from destination
Identify the network, token contract, observation block and transfer path. List sender, router, pool, intermediate contract and final recipient where relevant. A deduction might be burned, retained, redirected or implemented through a balance mechanism. Do not call every difference protocol revenue without evidence of the recipient and its rights.
Record requested quantity, pre-transfer balance and post-transfer balance for each party when the evidence permits. Event logs are useful locators, but their nominal values should be reconciled with state behavior for a non-standard token. A displayed transfer amount does not settle every question about effective receipts.
Check whether deductions vary by address, direction, exemption or administrative setting. A single observed transfer cannot establish a permanent tax rate. Document the conditions of the observation and distinguish code possibilities from settings actually active at the selected block.
Hypothetical two-hop route
Assume fictional Token Flint deducts 2% from each transfer in a simplified route. A sender requests 100 units to an intermediary, which receives 98. If that intermediary then transfers its entire 98 under the same rule, the final recipient receives 96.04. The total shortfall is 3.96, rather than exactly four units.
This example assumes deductions apply to both hops and no rounding complication. A real router may be exempt, or the route may fail because the integration expects a different receipt quantity. Do not use the example as a prediction of a real token’s execution.
If one unit of the first deduction reaches a treasury while another is burned, separate those destinations. The sender’s two-unit shortfall is not two units of treasury revenue. Record any unresolved remainder explicitly instead of allocating it to the most plausible category.
Per-hop reconciliation worksheet
| Item | Research record |
|---|---|
| Requested units | Quantity in the submitted action |
| Sender debit | Change in compatible token units |
| Receiver credit | Actual amount delivered at this hop |
| Difference | Debit minus credit, with attribution evidence |
| Rule conditions | Direction, exemptions and active settings |
| Route compatibility | Supported behavior for the actual version |
For the simplified example, final receipts = input × (1 − deduction rate)^number of taxed hops. Use it only when the same proportional rule genuinely applies at every hop. More complex rules need an event-by-event ledger rather than a borrowed formula.
Interpret the research result
Separate user cost, trading venue fees and token-level deductions. Combining them into one fee percentage can conceal different recipients and different controls. A variable deduction setting is also a governance dependency, so retain its authority and change history in the evidence packet.
Common mistakes include assuming a successful transfer proves router compatibility, annualizing one observed deduction as revenue, and applying a tax only once to a multi-hop path. The final memo should report observed gross and net quantities, destination attribution and unverified conditions. It should not offer an execution route or imply that a quoted receipt is guaranteed.
FAQ
Is the token transfer event enough to measure net receipt?
For non-standard behavior, reconcile the event with actual balances and implementation semantics before relying on it.
Does a 2% rule mean every route loses exactly 2%?
No. Hops, exemptions, direction, changing settings and integration failures can produce different outcomes.