Integer overflow and underflow happen when a calculation produces a numeric result too large or too small to be stored in the fixed slot allocated for it.

Why is Integer Overflow/Underflow a Fundamental Threat?

Smart contracts rely on fixed-width integers to track balances, shares, prices, and protocol parameters. When arithmetic exceeds those bounds, system integrity breaks. Supply can inflate, balances can vanish, and critical functions can revert.

How Common is it in Web3?

From Sherlock’s audit history, roughly one in every 160 vulnerabilities involves an integer overflow or underflow. Less frequent, but still recurring when faulty optimizations, unchecked blocks, or legacy standards are used.

Not all Overflow/Underflow Cases are Equal:

1. Arithmetic Wraparound: Addition or subtraction exceeds type limits. Common in pre-0.8 Solidity, where values were wrapped silently. In Solidity 0.8 and later, these operations revert.

2. Unchecked Arithmetic: Developers sometimes disable built-in safety checks with the “unchecked” keyword to save gas. This reintroduces the same risks Solidity 0.8 was designed to prevent.

3. Type Casting Errors: Unsafe conversions between signed and unsigned integers or narrowing widths (for example, from uint256 to uint128) can produce invalid values and break assumptions about system state.

4. Intermediate Overflow: Multiplication or division ordering produces oversized intermediate results even though the final intended result should fit within bounds.

What’s the Impact?

These vulnerabilities primarily compromise data integrity and, secondly, in some cases, availability. Overflow conditions can inflate token supply, erase balances, halt execution, or distort pricing and reward systems. Once numeric safety is broken, the protocol can no longer guarantee consistency of state, undermining both reliability and trust.

Examples from Sherlock Audits:

1. Sophon Farming: The rewards calculation system risked producing values so large they could overflow, destabilizing payout logic.

2. Symmetrical: An underflow in the liquidation process caused settlement transactions to fail, preventing liquidations from completing as intended.

3. PoolTogether: A missing index value broke the vault-portion calculation, corrupting entitlements and, in some paths, triggering underflow reverts during settlement.

Past Exploit Examples:

- BatchOverflow (2018): Multiple ERC-20s had an overflow in the batchTransfer function, letting attackers mint unlimited tokens. Exchanges suspended ERC-20 deposits until resolved.

- Yam Finance (2020): A rebase arithmetic bug minted excess tokens and broke governance, leaving about $750K in treasury assets stranded.

Preventing Integer Overflows & Underflows

✅ Build on Solidity 0.8 or later.

Since version 0.8, Solidity enforces arithmetic safety by reverting on overflow or underflow, eliminating silent wraparound bugs.

✅ Be cautious with unchecked blocks.

The unchecked keyword removes overflow checks to save gas. Only use it if boundaries are formally proven, and ensure it is well-documented and tested.

✅ Use well-audited arithmetic libraries.

SafeCast, Math.mulDiv, or Uniswap’s FullMath cover edge cases for large multiplications, divisions, or type conversions, reducing the risk of hidden overflow.

✅ Test the extremes, not just the averages.

Fuzzing and property-based testing explore extreme values such as maximum balances or zero states to confirm resilience under stress, catching failures that unit tests often miss.

Our Take

Maintaining numerical integrity is essential to protocol security. Without bounded and validated operations, protocols lose system assurance and expose themselves to silent failures that corrupt state, halt execution, or distort incentives. Robust arithmetic is not an optimization detail - it’s a core requirement for trustworthy DeFi.

Next up: Number 9…

‍