Why Bridge Deposit Amounts Can Change at the Decimal Boundary

A bridge deposit uses an integer amount of a token’s smallest units, so the value shown in a wallet can differ in precision from the value submitted to a contract. A token’s decimals setting defines how many of those units make one displayed token: with 6 decimals, for example, 1 token is represented by 1,000,000 base units. The bridge transfers the integer; the interface formats it for people.

That distinction matters when an interface rounds a long balance or input to fewer decimal places. The displayed amount may look unchanged while the submitted amount has been rounded down, or an extra fractional digit may be rejected or truncated. The deposit flow for Mantle Bridge is one example of a bridge process where the amount entered is only one part of what a depositor needs to understand. The key detail is whether the number shown is the exact amount the contract will receive.

Why can a bridge deposit amount look different from my balance?

A wallet displays a human-readable decimal representation of an integer balance. If a token has 18 decimals, its balance is divided by 10¹⁸ for display; if it has 6, the divisor is 10⁶. The raw balance is exact, but a wallet may show only a limited number of digits after the decimal point.

That display limit does not necessarily change the balance. A wallet might show 1.234567 when the stored amount is 1.23456789. The omitted digits remain in the token balance unless the wallet or deposit interface uses the shortened display value to build the transaction. The same issue can occur when copying an amount, entering it manually, or using a “max” button that subtracts a reserve for transaction fees.

ERC-20 transfer calls pass an unsigned integer, not a decimal string. Wallet software converts a typed amount into base units before signing. That conversion must use the token’s decimals and an explicit rounding rule. Floating-point arithmetic is unsuitable for this step because many decimal fractions cannot be represented exactly in binary; reliable interfaces use integer or decimal arithmetic instead.

What does rounding do to the amount sent?

When an entered amount has more fractional digits than the token supports, the interface must reject it or reduce it to a representable value. Rounding down is common because it never requests more units than the user specified. For a token with 6 decimals, an input of 0.1234567 cannot be represented exactly: the nearest lower on-chain amount is 0.123456.

The difference is less than one base unit in this example, but the rule matters more when a bridge converts amounts between token representations. If the destination token has fewer decimals than the source, a conversion may require division. Integer division discards any remainder unless the contract explicitly accounts for it. The result can be a small amount left behind on the source side, a smaller destination amount, or a transaction that rejects values that do not fit the conversion rule.

These are separate from bridge fees. A fee reduces the amount delivered according to the bridge’s fee logic; decimal conversion changes how a quantity is represented. A quote that says “you receive” should be checked against both operations. A token shown with the same ticker on two networks also does not prove that the contracts use the same decimals or that their representations are interchangeable.

How can I check the exact deposit amount before signing?

Check the amount at the contract boundary: the source token, the base-unit quantity, and the bridge’s quoted destination amount. In a typical wallet flow, inspect the transaction details before signing and compare the amount there with the interface’s final review screen. For a technical integration, decode the transaction input and compare its integer amount with the intended token quantity converted using the source token’s decimals.

• Confirm the source network and token contract, not only the ticker symbol.
• Check the token’s decimals and ensure the input does not contain unsupported fractional digits.
• Compare the entered amount with the amount shown in the final transaction review.
• Read the destination estimate for fees, conversion loss, or a remainder that will not bridge.

Do not infer the received amount from a rounded balance preview alone. A “max” amount may also leave tokens behind to cover a fee, while the bridge’s own fee or conversion rule may affect the destination quantity separately. If the preview and transaction details disagree, stop and resolve the difference before signing; the transaction’s integer amount determines what the contract processes.

For most depositors, the practical choice is to use the bridge’s final review amount and avoid typing precision beyond the token’s supported decimals. For integrations and larger transfers, verify the raw integer and conversion path directly. Rounding is not a mysterious bridge deduction: it is a formatting or integer-conversion rule, and its effect is knowable before the transaction is submitted.