How fee rounding changes very small swap calculations

Small swaps can expose rounding that is invisible in larger trades. Calculate in the token's smallest units, then apply the actual implementation's rounding rule. The number of decimals displayed on a screen is not necessarily the precision used by the contract.

An illustrative integer calculation

Imagine a token with two decimal places and a hypothetical fee rule that rounds a 1% output deduction down to the nearest smallest unit. Gross output of 0.99 tokens equals 99 smallest units. One percent is 0.99 of a smallest unit, which this assumed rule rounds to zero. Gross output of 1.00 token equals 100 units and produces a one-unit fee, or 0.01 tokens.

A rule that rounds up would produce a different result. This example explains the importance of the convention; it is not a claim about a particular service's fee rule.

Display rounding is another layer

For a different token with at least three decimal places, suppose outputs are 1.004 and 1.003 tokens but the interface displays only two decimals. Both can display as 1.00, so a screenshot hides a real difference. Conversely, reporting too many decimals can suggest certainty that the quote or valuation does not support.

ERC-20 describes integer token balances and a decimals display field. The decimals field does not make the underlying arithmetic infinitely divisible. The Uniswap v2 reference calculations also demonstrate integer arithmetic in swap outputs.

Keep exact quantities until presentation

Preserve raw amounts for reconciliation and round only the human-readable result. Do not infer a hidden fee solely from a last-digit difference without examining the computation boundary.

When comparing tiny trades, show the smallest meaningful unit and the actual received quantity. If a quote or fee cannot be represented at that precision, the effective percentage may differ from the nominal rate. A claim of “exactly 1%” requires the implementation's rounding behavior, not just its advertised percentage.