Integer Overflow and Underflow in Solidity

Integer overflow occurs when a result exceeds a type's maximum; underflow falls below its minimum. In wrapping arithmetic, the result continues modulo the type's range. For example, an unchecked uint8(255) + 1 becomes zero.

Solidity 0.8 changed ordinary arithmetic to revert on overflow and underflow by default, as documented in its 0.8 breaking changes. That removes many silent-wrap bugs, but it does not make all integer handling safe.

WHERE RISK REMAINS

Legacy contracts compiled before 0.8 may wrap unless they use checked-math libraries. Modern code can deliberately restore wrapping inside unchecked blocks or assembly. Explicit conversion to a narrower integer also truncates high-order bits rather than applying the ordinary arithmetic check. A value that fits in uint256 may therefore change when stored as uint128.

Checked arithmetic can create a liveness failure too. If an attacker can force a counter or accumulator to its limit, the next otherwise-required operation may revert forever. The security impact depends on reachability and what the wrapped or reverting value controls: balances, shares, authorization epochs, fees, array indexes, or accounting totals.

REVIEW AND TEST

Record the compiler version and inspect every unchecked block, assembly arithmetic, narrowing cast, signed/unsigned conversion, exponentiation, and accumulator. Trace user-controlled values and values imported from tokens or oracles. Confirm that intended modular arithmetic is locally documented and cannot escape into economic or authorization logic.

Test zero, one, type maximum, maximum minus one, signed minimum, and values on both sides of each cast boundary. Exercise repeated operations that grow totals over time, not only single calls. For accounting code, assert conservation relationships after arbitrary sequences: aggregate user balances should match the intended supply or reserve model.

MITIGATIONS AND LIMITS

• Compile with Solidity 0.8 or later unless a pinned legacy version is unavoidable.
• Keep unchecked regions minimal and prove their preconditions in code and tests.
• Validate domain limits before arithmetic, including aggregate limits across repeated calls.
• Use checked downcasts such as OpenZeppelin's SafeCast; the OpenZeppelin utilities API also provides full-precision math helpers.
• For legacy code, use a vetted checked-arithmetic library consistently and test the deployed compiler configuration.

Do not “fix” a reverting overflow by wrapping it unless modular arithmetic is actually the intended protocol rule. A revert may reveal a capacity or accounting design flaw.

Firepan can review submitted source for compiler semantics, reachable unchecked arithmetic, unsafe casts, and boundary-sensitive state. It cannot prove arbitrary numeric safety from syntax alone or account for unsubmitted libraries and deployment configuration.

FREQUENTLY ASKED QUESTIONS

Does Solidity 0.8 eliminate overflow vulnerabilities?

No. It checks ordinary arithmetic, but unchecked code, assembly, downcasts, and denial-of-service at numeric limits still require review.

Is every unchecked loop increment unsafe?

No. It can be valid when the loop bound proves the counter cannot wrap. That proof should remain obvious after future changes.