Precision Loss and Rounding Errors in Solidity

Precision loss occurs when finite integer representation changes an economically meaningful result. Solidity integer division discards the remainder and rounds toward zero. That behavior is deterministic, but it becomes a vulnerability when the rounding direction or scale lets a caller create value, avoid debt, receive no shares, or repeat a favorable error until it exceeds transaction costs.

COMMON FAILURE MODES

Dividing before multiplying can discard information early: (amount / total) * rate may become zero even when (amount * rate) / total is nonzero. Reordering is not automatically safe, because the intermediate product can overflow or exceed the intended domain. Full-precision multiplication and division are preferable for large values.

Other failures include mixing token and oracle decimals, downscaling before fees are applied, using inconsistent rounding for inverse operations, and carrying too little precision in per-share or per-second accumulators. “Dust” is not harmless when a user can choose inputs and repeat the operation.

Standards may mandate different rounding by function. ERC-4626, for example, specifies rounding behavior for share and asset conversions and recommends opposing directions for mutable operations so calculations favor the vault rather than a caller choosing both sides of a round trip.

REVIEW AND TEST

Annotate every amount with its unit and scale: asset atoms, shares, price decimals, basis points, seconds, or fixed-point format. Follow conversions end to end and record exactly where a remainder is discarded. Review boundary casts separately from arithmetic.

Test zero, one, dust, values immediately below and above a scaling factor, highly imbalanced reserves, empty and near-empty vaults, and maximum supported amounts. Compare the implementation with a high-precision reference model. Assert that deposit-then-withdraw, mint-then-redeem, and borrow-then-repay cannot increase a user's net value except through documented yield or fees. Repeat small operations to expose accumulated bias.

MITIGATIONS AND LIMITS

• Carry a documented fixed-point scale through intermediate calculations and convert once at the boundary.
• Use full-precision helpers such as OpenZeppelin Math.mulDiv, selecting the rounding direction explicitly.
• Normalize token and oracle decimals before combining values, and reject unsupported scales.
• Round each operation against the party that chooses its input when the protocol specification permits it.
• Set minimum economically meaningful amounts where dust would otherwise create a zero-output or repeatable edge.
• Differential-fuzz formulas against an independent high-precision model.

Increasing precision reduces error but does not fix the wrong formula or rounding policy. Minimum amounts can also exclude small users, so they should follow measured economics rather than arbitrary constants.

Firepan can review submitted source for early division, scale mismatches, narrowing casts, and asymmetric round trips. It cannot determine acceptable economic error without the protocol's units, limits, and rounding specification.

FREQUENTLY ASKED QUESTIONS

Should code always multiply before dividing?

No. It often preserves precision, but the product must be representable. Use a proven full-precision helper when ranges are large.

Can a one-wei error be high severity?

Yes, if an attacker can repeat it cheaply or if it changes a threshold such as share issuance, solvency, or authorization.