Integer Overflow in Solidity 0.8+ — Why You Still Need to Care

The Bug

An integer overflow happens when arithmetic produces a result larger than the maximum value a type can hold (or smaller than its minimum, for underflow). In a `uint8`, `255 + 1` wraps to `0`. In a `uint256`, `type(uint256).max + 1` wraps to `0`. Before Solidity 0.8.0, this was silent and catastrophic — entire token supplies could be minted by underflowing a balance check.

Solidity 0.8.0 fixed the default behavior: arithmetic on integer types now reverts on overflow or underflow. The compiler injects checks around `+`, `-`, `*`, `/`, and `**`. SafeMath, the library that defined an era of ERC-20 development, became redundant overnight.

So why are we still talking about this in 2025? Because the bug didn't die — it migrated.

Where Overflow Still Lives in Modern Solidity

There are four places SWC-101 still shows up in audits:

1. **`unchecked{}` blocks** — developers wrap arithmetic in `unchecked` to save ~30-40 gas per operation. If the bounds reasoning is wrong, you're back to pre-0.8 behavior.
2. **Inline assembly** — Yul has no overflow checks. Ever. `add(x, y)` wraps silently.
3. **Unsafe downcasting** — `uint256` to `uint128` (or smaller) is a truncation, not a check. The compiler does *not* revert. SafeCast exists for a reason.
4. **Legacy SafeMath in 0.8+ codebases** — usually harmless, but I've seen `SafeMath.sub` wrapped in `unchecked` because someone "optimized" it. That's a special kind of cursed.

A Vulnerable Modern Contract

Here's a staking contract that compiles cleanly on 0.8.24 and still has an exploitable overflow:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract RewardVault {
mapping(address => uint128) public stakedAmount;
mapping(address => uint128) public rewardDebt;
uint256 public accRewardPerShare; // scaled by 1e12

function stake(uint256 amount) external {
// bug 1: silent truncation from uint256 to uint128
stakedAmount[msg.sender] += uint128(amount);

unchecked {
// bug 2: pendingReward can exceed uint128
uint256 pending = (uint256(stakedAmount[msg.sender]) * accRewardPerShare) / 1e12;
rewardDebt[msg.sender] = uint128(pending);
}
}
}
```

Two separate failure modes:

`uint128(amount)` — if `amount > type(uint128).max`, the high bits are silently dropped. An attacker stakes `2^128`, the contract records `0`, but the token transfer (if added) moves the full amount. Funds vanish into accounting limbo.
- `unchecked { ... uint128(pending) }` — the inner multiplication can wrap in `unchecked`, and the final cast truncates regardless. Reward debt becomes wildly wrong.

The Fix

Use OpenZeppelin's `SafeCast` for any narrowing conversion, and only use `unchecked` when you can mathematically prove the operation cannot wrap:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "@openzeppelin/contracts/utils/math/SafeCast.sol";

contract RewardVault {
using SafeCast for uint256;

mapping(address => uint128) public stakedAmount;
mapping(address => uint128) public rewardDebt;
uint256 public accRewardPerShare;

function stake(uint256 amount) external {
// reverts if amount > type(uint128).max
stakedAmount[msg.sender] += amount.toUint128();

// checked arithmetic — reverts on overflow
uint256 pending = (uint256(stakedAmount[msg.sender]) * accRewardPerShare) / 1e12;
rewardDebt[msg.sender] = pending.toUint128();
}
}
```

When `unchecked` Is Actually Fine

I'm not anti-`unchecked`. Used correctly, it's free gas. The canonical safe pattern is a loop counter:

```solidity
for (uint256 i = 0; i < array.length;) {
// ... do work ...
unchecked { ++i; }
}
```

`i` is bounded by `array.length`, which is bounded by `2^256 - 1` in theory but by gas limits in practice. It cannot overflow. Same logic applies to decrementing a value you've just checked is greater than zero, or subtracting a balance from a total you know is larger.

The rule: write a one-line comment above every `unchecked` block explaining *why* it can't wrap. If you can't write that comment, remove the `unchecked`.

Real-World Damage

The pre-0.8 era was brutal:

**BeautyChain (BEC), April 2018** — an overflow in `batchTransfer` let an attacker mint `2 * (2^255)` tokens. The token's market cap collapsed in minutes; trading was suspended. Losses estimated north of $900M in notional value.
- **SMT (SmartMesh), April 2018** — same week, same bug class, different contract. Trading halted on multiple exchanges.
- **Proxy Overflow (multiple ERC-20s)** — a class of bugs where `transferFrom` allowance subtraction underflowed, granting infinite spending.

Post-0.8, the public incidents have shifted to `unchecked` misuse and downcasting bugs in DeFi protocols. They get less press because the dollar amounts per incident are smaller — but they're still six- and seven-figure losses.

Audit Checklist for SWC-101 in 0.8+

When I'm reviewing a contract, I grep for these patterns first:

Every `unchecked` block — read the math, prove the bound
- Every `uintN(x)` cast where `N < 256` — should be `SafeCast`
- Every `assembly` block touching arithmetic — Yul never checks
- Any imported `SafeMath` — flag it; the codebase is either old or confused
- Fixed-point math libraries (PRBMath, ABDKMath) — check they're using the correct mode

If you're shipping a protocol that handles real value, run it through our [free AI audit](https://www.cryptohawking.com/audit) before deployment — it catches the obvious downcasting and `unchecked` patterns automatically. For anything holding more than six figures in TVL, a [manual audit](https://www.cryptohawking.com/audit/manual) is the right call: deeper invariant analysis, three business days, paid in ETH, SOL, or USDT.

TL;DR

Solidity 0.8 didn't kill integer overflow. It moved it from "every line of arithmetic" to "every `unchecked` block, every downcast, every assembly snippet." The surface area shrunk by ~95%, but what's left is concentrated in exactly the places developers add for gas optimization — which means it correlates with code that was already trying to be clever. Be paranoid in those regions. SafeCast everywhere. Comment your `unchecked` blocks. And if you're still importing SafeMath in 2025, we need to talk.