When arithmetic silently wraps around
Integers on the EVM are stored in fixed-width registers, commonly 256 bits, and fixed-width arithmetic has a boundary. Before Solidity version 0.8, addition, subtraction, and multiplication did not automatically check whether a result had gone past that boundary, they simply wrapped. If an unsigned integer variable held its minimum value of zero and a function subtracted one from it, the result didn't go negative, since unsigned integers can't represent negative numbers, it wrapped all the way around to the maximum representable value instead. A token balance that should have been rejected as insufficient could instead silently become an enormous number, and a contract that trusted that balance without a separate sanity check would treat the wrapped value as legitimate. Overflow is the mirror case: adding to a value already near the maximum wraps back down toward zero.
This vulnerability class shows how a plausible-looking line of arithmetic can hide a boundary condition that only shows up under extreme, specific inputs, exactly the kind of edge case that casual testing tends to miss. It's a useful vulnerability class to study conceptually even though it's largely a solved problem for new code, since Solidity 0.8 and later revert automatically on overflow or underflow unless a developer deliberately opts into unchecked arithmetic within an `unchecked { }` block for gas optimization. That history matters for auditors for two reasons: a meaningful amount of value still sits in older contracts written against pre-0.8 compilers, and any `unchecked` block in modern code is a flag that a developer has manually taken on the very risk the compiler otherwise removes, which makes it a natural place to focus extra scrutiny during a review.