Handle dust and rounding at the transaction boundary

Dust problems often start when a human-readable value rounds to a different base-unit amount than the transaction expects. Keep arithmetic exact and choose the rounding direction for each field deliberately.

Input and display have different jobs

For a hypothetical token with two decimals, 0.009 units cannot be represented as an integer token amount. Reject it or ask the user to choose a supported amount. Displaying 0.01 while submitting zero is not an acceptable fallback.

The decimals convention specifies how base units map to display units. It does not prescribe a swap application's rounding policy. Define that policy in your amount parser and formatter.

Bounds deserve special care

A minimum-output calculation can round downward to avoid claiming a fractional base unit. A maximum-input constraint may need a different direction to remain sufficient. However, use the provider's actual signed or encoded bound for execution; a locally displayed approximation should not overwrite it.

Fee calculations can also disappear below one base unit. Show a value as less than the display threshold when appropriate, rather than asserting that the fee is exactly zero.

Choose useful edge cases

Test the smallest unit, one value below it, a large amount with a tiny fractional part and a quote whose minimum output rounds to zero. If a zero minimum is outside the product's acceptable execution policy, block it explicitly rather than hiding it behind formatted decimals.

Round-trip checks should compare integer amounts. A format-then-parse path that uses a shortened screen label may lose precision and should not be reused to construct transactions. Keep the original integer in state throughout the form, quote, approval and execution lifecycle.