Why Solidity uint8 Wraps Modulo 256 in 0.7 but Reverts in 0.8

A uint8 is an 8-bit unsigned integer. Its valid range is 0 through 255. When the arithmetic result of an operation falls outside that range, something has to give:

• Solidity 0.7: the result is taken modulo 2^8 = 256. So 255 + 1 becomes 0, and 0 - 1 becomes 255. No error, no revert.
• Solidity 0.8: the EVM-level math is the same — the result still wraps — but Solidity 0.8 emits an extra check after every arithmetic operation, and reverts with Panic(0x11) if the result wrapped.

The change happened because the wrap behaviour caused too many production exploits. Pre-0.8, developers had to import OpenZeppelin's SafeMath library on every contract to get the revert behaviour. Post-0.8, the safe behaviour is the default and the wrap behaviour is the opt-in. See the uint type reference for the full range table across uint8 through int256.

// Solidity 0.8+ — explicit opt-in to wrap behaviour
uint8 x = 255;
unchecked {
    x = x + 1; // x is now 0, no revert
}

The unchecked block is the documented escape hatch. Auditors expect to see it whenever wrap behaviour is intended; a bare arithmetic operation in 0.8 that depends on wrapping is a bug almost every time. See loop gas optimization for the most common production use case.

When migrating a 0.7 contract to 0.8, every arithmetic operation in the codebase becomes a candidate for the migration trap. Two patterns are the most common offenders:

• Counter loops with deliberate modulo. A loop that walks a ring buffer using i = (i + 1) % BUFFER_SIZE is fine. A loop that depends on uint8 i; i++; wrapping to 0 after 255 is silent in 0.7 and reverts in 0.8.
• Gas-tight increment loops. for (uint i; i < length; i++) is roughly 80 gas per iteration in 0.8 due to the overflow check. The idiomatic 0.8 fix is to use unchecked { ++i; } inside the loop body.

The safest migration path: compile under 0.8, run the full test suite, fix every failing revert by either accepting the safer semantics or explicitly opting into unchecked.

// Before migration (0.7) — depends on wrap
for (uint8 i = 0; i < 255; i++) {
    // i wraps at 255+1 = 0 — infinite loop risk
}

// After migration (0.8) — safe and cheap
for (uint256 i; i < length;) {
    // loop body here
    unchecked { ++i; }
}

Developers paste a snippet like solidity 0.7 uint8 overflow wraps modulo 256 into Google when they hit unexpected behaviour mid-debug. The pattern usually goes: “my counter just hit zero out of nowhere” → “what does Solidity actually do on overflow?” → paste.

The answer is the compiler version. Check the pragma solidity line at the top of the contract first. If it says ^0.8.0 or higher, the wrap is a revert. If it says ^0.7.x or lower, the wrap is silent. There is no other configuration.

The Solidity storage layout visualizer can help you see how small integer types are packed in storage, which is the other common reason developers reach for uint8 in the first place.