Cross-chain transfers need exact amount rules

Cross-chain transfers need an explicit rule for converting token amounts between each chain’s smallest units. Without one, an amount can arrive smaller than expected or fail because the destination cannot represent it. EIP-20, the Ethereum token standard, treats a token’s decimal count as display information; contract balances and transfers still use integer amounts. That distinction matters when a bridge moves value between chains.

For a deeper look at the bridge side, read this explanation of how an XMR bridge works for developers. The same integration question applies across assets: what amount is sent, what amount is received, and where can rounding happen?

Why do chains use different token precision?

Each token records balances in whole units of its smallest denomination, then software places the decimal point for display. A token with six decimals represents 1.23 as 1,230,000 units. With 18 decimals, the same displayed amount is 1,230,000,000,000,000,000 units.

These are different integer counts for the same user-facing amount. Decimal counts can vary by token and chain. For example, an asset represented on two networks may use one precision on the source and another on the destination. Integrators should read or configure the precision for each specific representation; they should not assume that a familiar ticker means the underlying units match.

How should an integrator convert the amount?

Convert between smallest units with integer arithmetic and an explicit decimal scale. If a source representation has 18 decimals and its destination version has six, conversion to the destination scale divides by 10¹². Conversion in the other direction multiplies by that factor.

Division can leave a remainder. If the source amount is not an exact multiple of the scale factor, the destination cannot express the full amount in its smallest unit. Choose and document one policy:

• Reject amounts that cannot be represented exactly.
• Round down and report the remainder as dust, meaning a leftover amount too small to transfer.
• Keep a remainder for a later transfer, if the system can track it safely.
• Show the user the final receive amount before they confirm.

For most integrations, rounding down with a clear minimum amount is easier to reason about than hidden rounding. Never use floating-point values for token balances or conversion; use integers or decimal-safe arithmetic.

Where can amount precision go wrong?

Check precision at every step: input parsing, source transfer, bridge accounting, destination mint or release, and final display. Keep fees separate from the bridged amount. A fee charged before conversion can produce a different result from one charged after conversion, especially when either step rounds.

Keep the original amount and the converted amount in smallest units in records. Also record the asset identity on both chains, the decimal scales used, the fee rule, and any remainder policy. EIP-20’s decimals value helps wallets display an amount, but it does not change the integer math of transfer or balanceOf. Treat it as input to a conversion rule, not as a conversion itself.

What should the transfer screen show?

Show the source amount, fee, and expected destination amount in the destination token’s display units. State when rounding changes the amount, and make zero or below-minimum results impossible to confirm. A bridge can move an asset across chains, but precision rules decide whether the user receives the amount the interface promised.