Integer Overflow and Underflow Explained: Solidity Versions, SafeMath, Checked Arithmetic, and DeFi Risk

What integer boundaries mean in smart contracts

An integer type defines a set of whole numbers that a program can store. Solidity supports unsigned integers such as uint8, uint64, uint128, and uint256, as well as signed integers such as int8, int128, and int256.

The number after uint or int identifies the number of bits used to represent the value. Larger bit widths support larger ranges.

Unsigned integer ranges

An unsigned integer cannot represent negative values. A uintN type ranges from zero through 2^N - 1.

For example, uint8 uses eight bits and has 256 possible values. Its minimum is 0 and its maximum is 255. The type cannot represent 256.

A uint256 can represent values from 0 through 2^256 - 1. This range is extremely large, but it remains finite. A sufficiently large multiplication, exponentiation, accumulated total, or malicious input can still exceed it.

Signed integer ranges

A signed integer represents positive and negative values using two's-complement representation. An intN ranges from -2^(N-1) through 2^(N-1) - 1.

An int8 therefore ranges from -128 through 127. The negative side contains one additional magnitude. This creates a special edge case: negating the minimum signed value cannot produce a representable positive result of the same type.

Type boundaries are part of protocol design

Choosing an integer type is not merely a storage decision. The chosen range becomes an economic constraint. A narrow type used for token balances, timestamps, reward indices, basis points, accumulated fees, voting checkpoints, or total supply can become unsafe as the protocol grows.

Maximum values should be expressed through the type

Modern Solidity exposes type(T).min and type(T).max for integer types. These expressions make the intended boundary clearer than hard-coded decimal values or historical patterns such as converting -1 to an unsigned type.

Integer Boundary Diagram: wraparound, checked reverts, and protected arithmetic

The same out-of-range calculation can produce different outcomes depending on the compiler version and arithmetic mode.

What integer overflow is

Overflow occurs when an arithmetic result is greater than the maximum value the result type can store.

Unsigned addition overflow

In a uint8, adding 1 to 255 produces the mathematical result 256. In wrapping arithmetic, the stored value becomes 0.

Unsigned multiplication overflow

Multiplication can cross the boundary more quickly than addition. A reward calculation such as balance * rewardRate may overflow even when both inputs individually fit in the type.

This is why developers must consider intermediate values, not only the final divided result. The mathematical formula (a * b) / denominator may produce a reasonable final value while a * b exceeds uint256 first.

Signed overflow

Signed overflow occurs when a result exceeds the positive maximum or falls below the negative minimum. For example, adding 1 to type(int8).max cannot be represented as an int8.

Negating the minimum signed value

A signed type has one more negative magnitude than positive magnitude. For int8, -128 exists but positive 128 does not. Negating -128 therefore overflows.

Exponentiation risk

Exponentiation grows values rapidly. A base and exponent that appear moderate can exceed the result type. Contracts should avoid unbounded exponentiation using user-controlled values.

Accumulation risk

A total can overflow through many individually small updates. Examples include lifetime fees, reward indices, cumulative prices, total minted tokens, trading volume, checkpoint counters, or time-weighted accumulators.

What integer underflow is

Underflow occurs when an arithmetic result is less than the minimum value the type can store.

Unsigned subtraction underflow

An unsigned integer cannot represent a negative result. Subtracting 1 from zero falls below the minimum.

In wrapping arithmetic, uint8(0) - 1 becomes 255. For uint256, subtracting 1 from zero becomes type(uint256).max.

Balance underflow

A legacy token could subtract more than an account owned. Instead of producing a negative balance or reverting, the balance could wrap to an enormous value.

Allowance underflow

A transfer function could reduce an allowance below zero and wrap it to a maximum-like value, creating far more spending authority than intended.

Counter underflow

Decrementing a zero counter inside a legacy loop or unchecked block can produce the maximum unsigned value. This may cause an unexpectedly long loop, out-of-gas failure, or invalid indexing.

Signed underflow

A signed value underflows when it becomes less than the type's negative minimum. The wrapped result can move into the positive range, creating a severe sign reversal.

How Solidity before version 0.8 handled arithmetic

Before Solidity 0.8.0, ordinary integer arithmetic wrapped when a result crossed the type boundary. The EVM continued execution with the truncated value.

The compiler did not automatically insert a revert for ordinary addition, subtraction, or multiplication overflow. Developers needed to add explicit checks or use a library such as SafeMath.

Why wrapping created security failures

Smart contracts often use arithmetic to enforce authorization. A transfer is allowed only when the sender's balance remains sufficient. A mint is allowed only when total supply remains below a cap. A reward is limited by accrued value. Debt is constrained by collateral.

When arithmetic wraps, the number used to enforce the rule can become unrelated to the intended economic value.

A legacy unchecked balance example

// SPDX-License-Identifier: MIT
pragma solidity 0.7.6;

contract LegacyLedger {
    mapping(address => uint256)
        public balances;

    function reduceBalance(
        uint256 amount
    ) external {
        // In Solidity 0.7.6, this wraps
        // if amount is greater than the balance.
        balances[msg.sender] =
            balances[msg.sender] - amount;
    }
}

A require check could provide manual protection

Developers could validate amount <= balance before subtraction. Manual checks work when they are complete and correctly placed, but repeating them throughout a large contract increases the risk of omissions.

Legacy code remains economically relevant

The language changed, but older deployed bytecode did not. A contract compiled with Solidity 0.6 or 0.7 still uses its original arithmetic behavior unless the system is upgraded to new implementation code.

Proxy contracts complicate version analysis

The visible proxy may have been compiled with one version while the current implementation uses another. Users must resolve the active implementation and its source rather than relying on the proxy's metadata alone.

Why older contracts used SafeMath

SafeMath libraries wrapped arithmetic operations in explicit safety checks. Instead of writing a + b, a contract could call a.add(b). The library verified that the result remained within the type's range and reverted when it did not.

Safe addition

Safe addition calculated the result and confirmed that it was not less than the original operand. For unsigned values, a smaller wrapped result indicated overflow.

Safe subtraction

Safe subtraction checked that the amount being removed did not exceed the starting value.

Safe multiplication

Safe multiplication handled zero separately and verified that dividing the result by one operand recovered the other operand.

SafeMath improved consistency

A well-reviewed library reduced the need to recreate arithmetic checks in every token, vault, crowdsale, staking contract, or governance system.

A simplified legacy SafeMath pattern

// SPDX-License-Identifier: MIT
pragma solidity 0.7.6;

import {
    SafeMath
} from "@openzeppelin/contracts/math/SafeMath.sol";

contract LegacySafeLedger {
    using SafeMath for uint256;

    mapping(address => uint256)
        public balances;

    function credit(
        address account,
        uint256 amount
    ) external {
        balances[account] =
            balances[account].add(amount);
    }

    function debit(
        address account,
        uint256 amount
    ) external {
        balances[account] =
            balances[account].sub(amount);
    }
}

Import presence does not prove complete use

A contract may import SafeMath but still use raw operators in critical functions. Some values may use the library while other counters, fees, supplies, or indexes remain unchecked.

Custom SafeMath code requires verification

A locally copied library named SafeMath may differ from the established implementation. Review the compiled source, not only the library name.

SafeMath did not solve rounding or formula mistakes

SafeMath rejected boundary violations. It did not guarantee correct fee order, precision scaling, decimal conversion, reward formulas, oracle values, or economic assumptions.

The TokenToolHub OpenZeppelin Contracts guide explains how reusable libraries support safer development and why version pinning, inheritance review, import verification, initialization, and upgrade analysis remain necessary.

How Solidity 0.8 changed overflow behavior

Solidity 0.8.0 made checked arithmetic the default. Ordinary addition, subtraction, multiplication, increment, decrement, division edge cases, modulo, and exponentiation now revert when the result cannot fit in the result type.

Checked arithmetic raises a panic

An overflow or underflow outside an unchecked block triggers a Solidity panic with arithmetic error code 0x11. The call reverts and state changes in that call path are rolled back.

Built-in checks replace most historical SafeMath use

In normal Solidity 0.8 arithmetic, writing a + b already includes an overflow check. Using a traditional SafeMath wrapper for the same operation is generally unnecessary.

A modern checked balance example

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

contract CheckedLedger {
    mapping(address => uint256)
        public balances;

    function credit(
        address account,
        uint256 amount
    ) external {
        // Reverts automatically on overflow.
        balances[account] += amount;
    }

    function debit(
        address account,
        uint256 amount
    ) external {
        // Reverts automatically on underflow.
        balances[account] -= amount;
    }
}

Reversion can prevent silent corruption

Checked arithmetic is safer because the contract does not continue with a wrapped value. An impossible state transition fails instead of writing a misleading balance or total.

Reversion can create denial of service

A revert is not always harmless. If an attacker can force an accumulator, timestamp calculation, reward index, loop counter, or settlement amount to cross the boundary, a critical function may become permanently unusable.

Solidity's security guidance therefore warns developers not to assume checked arithmetic removes all overflow-related risk. The contract should constrain inputs and design state so required operations remain within range.

The compiler version alone is not a proof

A pragma solidity ^0.8.0 declaration tells the compiler which versions may compile the source. It does not identify the exact compiler used unless verification metadata or build records provide it.

It also does not prove that every operation remains checked. The code may use unchecked, inline assembly, explicit conversions, bit shifts, or external libraries.

What unchecked arithmetic does

Solidity 0.8 lets developers intentionally restore wrapping arithmetic inside an unchecked block. Operations syntactically inside the block do not receive the normal overflow or underflow checks.

Why unchecked exists

Some operations are proven safe by surrounding conditions. Removing redundant checks can reduce gas usage.

A common example is incrementing a loop counter when the loop condition guarantees that the counter cannot reach the type maximum.

A bounded unchecked increment

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

contract BoundedLoop {
    function sum(
        uint256[] calldata values
    ) external pure returns (uint256 total) {
        uint256 length = values.length;

        for (uint256 i; i < length; ) {
            total += values[i];

            unchecked {
                ++i;
            }
        }
    }
}

Unchecked scope is local

An unchecked block affects operations written inside that block. Functions called from inside the block do not automatically inherit unchecked behavior.

Unchecked should include a written proof

Reviewers should be able to explain why each unchecked operation cannot cross its type boundary. A vague gas-optimization claim is insufficient.

User-controlled values increase risk

An unchecked operation involving amounts, timestamps, prices, token decimals, supply values, array lengths, fees, or indexes controlled by external input deserves close attention.

Upgrades can invalidate an earlier proof

An unchecked calculation may be safe under the original parameter limits. A later upgrade that increases the cap, changes the type, adds a new asset, or extends the operating lifetime can break the assumption.

Unchecked wrapping can be intentional protocol logic

Low-level cryptographic, hashing, ring-buffer, or sequence-number logic may intentionally use modular arithmetic. The contract should document this clearly and isolate it from economic accounting.

Why type conversions can still truncate values

Checked arithmetic does not automatically make every type conversion safe. Explicit conversions to a smaller integer type truncate high-order bits rather than reverting.

Downcasting

Downcasting converts a wider type such as uint256 into a narrower type such as uint64 or uint32.

If the original value exceeds the smaller type's maximum, the converted value loses the bits that do not fit.

A dangerous downcast

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

contract UnsafeCast {
    function narrow(
        uint256 amount
    ) external pure returns (uint64) {
        // This conversion does not use
        // ordinary arithmetic overflow checks.
        return uint64(amount);
    }
}

SafeCast restores checked downcasting

OpenZeppelin's SafeCast library provides conversion functions that revert when the value does not fit in the destination type.

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

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

contract CheckedCast {
    using SafeCast for uint256;

    function narrow(
        uint256 amount
    ) external pure returns (uint64) {
        return amount.toUint64();
    }
}

Signed and unsigned conversions need special care

Converting a negative signed value to an unsigned type or converting a large unsigned value to a signed type can produce unexpected bit-level results or require intermediate conversions.

Narrow storage types are not automatically cheaper

Smaller integer types save storage primarily when several values are packed into the same storage slot. Arithmetic is commonly performed in 256-bit EVM words, so narrowing values can add conversion complexity without reducing execution cost.

ABI and off-chain decoding must match

Interfaces, indexers, frontends, and signers must agree on integer sizes. A mismatch can display a different value from the one the contract stores or validates.

Bit shifts, inline assembly, and other arithmetic exceptions

Solidity's default arithmetic checks do not cover every operation in the same way.

Bit shifts truncate

Left-shift operations can discard bits that move beyond the size of the left operand. Ordinary overflow checks are not performed for shifts.

Replacing multiplication by a power of two with a left shift can therefore change safety behavior.

Bitwise operations operate on fixed-width representations

Masks, complements, and shifts can intentionally alter bit patterns. Reviewers must reason about the exact width and sign of each operand.

Inline assembly bypasses Solidity-level protections

Yul and EVM assembly use low-level arithmetic semantics. The developer must add any required boundary checks manually.

Assembly may hide an economic calculation

Assembly is often used for memory handling, hashing, calldata decoding, and gas optimization. When it also calculates amounts, offsets, array lengths, token values, or fees, the review should trace every possible boundary.

Compiler optimizations do not prove safety

The optimizer may simplify expressions while preserving the language's defined behavior. It does not correct an unsafe unchecked assumption, flawed cast, or invalid formula.

How math bugs affect token and DeFi systems

Integer safety affects nearly every economic state transition. Overflow and underflow are only the most visible boundary failures.

Token balances

A wrapped credit can reduce a balance to a small number or zero. A wrapped debit can create a near-maximum balance. Either result can break transfer authorization.

Total supply

A mint function may add the new amount to total supply. If the result wraps in legacy arithmetic, the recorded supply can become lower while user balances increase.

A checked overflow can instead halt minting. That is safer than silent corruption, but it may still violate protocol expectations if the supply type was chosen too narrowly.

Allowances

An allowance decrement can underflow in legacy or unchecked arithmetic, turning a small approval into a very large one.

Reward calculations

Staking systems multiply a user's stake by a reward index or elapsed time. Large intermediate products, decimal scaling, and long-running accumulators can approach boundaries.

A revert may stop claims for every user if the shared reward index becomes unmanageable.

Lending debt

Interest indexes grow over time. Debt may be calculated as principal multiplied by a current index and divided by an earlier index.

Overflow, rounding, type truncation, or incorrect scaling can understate debt, overstate debt, block repayment, or create insolvency.

Collateral values

A protocol may multiply token balances by oracle prices and decimal factors. Different tokens can use different decimals, while oracle feeds may use another scale.

A formula that uses the wrong order or scale can generate a valid integer that is economically off by several orders of magnitude.

Fees and basis points

A fee calculation commonly multiplies an amount by basis points and divides by 10,000. Multiplication before division preserves precision but creates a larger intermediate value.

Division before multiplication reduces overflow risk but may round the amount down too early and return zero for small transactions.

Vault shares

Deposit and redemption formulas convert between assets and shares. Incorrect rounding direction can transfer value between entering users, existing users, and withdrawing users even when no overflow occurs.

Governance voting power

Checkpoint systems may store voting power or block numbers in narrower types. Downcasts must be verified, especially when supply limits or chain lifetimes can exceed original assumptions.

Auctions and price curves

Auctions may calculate prices from elapsed time, slopes, exponents, and minimums. Boundary mistakes can produce zero prices, excessive prices, or permanent reverts.

Bridges and cross-chain accounting

A bridge may convert amounts between representations with different decimals. Truncation can lose value, while incorrect scaling can mint too many wrapped assets.

Liquidation calculations

Liquidation bonuses, close factors, collateral discounts, and debt repayment interact. Rounding and intermediate precision can decide whether a position remains solvent.

Overflow protection does not guarantee correct mathematics

A contract can pass every overflow check and still produce a wrong financial result.

Integer division truncates

Solidity integer division rounds toward zero. A fractional result is discarded.

If a protocol calculates 3 / 10 * 100, the first operation returns zero, so the final result is zero. Calculating 3 * 100 / 10 returns 30, but the multiplication creates a larger intermediate value.

Rounding direction changes who benefits

A lending protocol may round debt up to avoid undercharging borrowers. A vault may round shares down on deposit and assets down on withdrawal to protect existing holders.

The correct direction depends on the economic invariant.

Decimal mismatches

Tokens commonly use decimal metadata to display units. Oracle feeds and internal accounting may use different precision. Forgetting to normalize one input can create a result that is wrong by a factor of 10, 1,000, 1 million, or more.

Order of operations matters

Rearranging multiplication and division can change both overflow exposure and rounding loss.

Percentage confusion

A value labeled 5 percent might be encoded as 5, 500 basis points, 5e16 with 18-decimal precision, or another scale. The contract must define the representation consistently.

Zero-value edge cases

Rounding may turn a nonzero economic amount into zero. This can enable free operations, block minimum repayment progress, or create dust that can never be withdrawn.

Division by zero

Division or modulo by zero reverts. An empty pool, zero share supply, missing oracle value, or uninitialized denominator can therefore halt a function.

Full-precision multiplication and division

Established math libraries can calculate expressions such as x * y / denominator with more complete intermediate precision and explicit rounding choices.

Developers should use reviewed utilities rather than creating complicated multi-word arithmetic without a compelling reason.

Modern smart contract math safety flow

Safe arithmetic begins with a compiler default, but it continues through type selection, input limits, conversions, formula review, invariant testing, and deployment verification.

Why the compiler version is a security signal

The compiler version provides immediate context about arithmetic behavior, language semantics, ABI handling, optimizer behavior, and known compiler issues.

Versions before 0.8 need explicit arithmetic review

Analysts should look for SafeMath, manual require checks, custom arithmetic libraries, assembly, and raw operators.

Versions from 0.8 onward still require boundary review

Checked arithmetic reduces silent wrapping, but analysts must find every unchecked block, narrowing conversion, shift, assembly routine, and formula that can revert under reachable state.

A broad pragma permits several compilers

A declaration such as pragma solidity ^0.8.0 can compile under multiple compatible 0.8 releases. Verification metadata should identify the exact version used for the deployed bytecode.

An old compiler does not automatically mean vulnerable

A carefully written Solidity 0.7 contract can use complete SafeMath protection and correct formulas. The version indicates what protections were not automatic.

A new compiler does not automatically mean safe

A Solidity 0.8 contract can contain unchecked arithmetic, truncating casts, dangerous assembly, denial-of-service boundaries, precision loss, and incorrect financial formulas.

Compiler warnings and known bugs matter

Teams should review warnings, release notes, and the Solidity known-bugs list for the exact compiler version and configuration.

Proxy upgrades can change compiler assumptions

A protocol may move from a legacy implementation using SafeMath to a modern implementation using built-in checks. It may also move in the other direction by adding unchecked optimizations.

Math-safety checklist for reading a smart contract audit

What users and investors can inspect without auditing every formula

Most users will not manually prove the arithmetic of a lending market or vault. They can still identify meaningful evidence and warning signs.

Check source verification

Unverified source makes it difficult to confirm compiler version, unchecked blocks, imports, proxy behavior, and formulas.

Resolve the proxy

The user-facing address may delegate execution to another implementation. Confirm the current implementation and whether it changed after an audit.

Read the pragma and exact build metadata

The pragma provides a permitted compiler range. Verification services usually identify the exact compiler used to reproduce the bytecode.

Search for unchecked blocks

An unchecked block is not automatically unsafe. It signals that the developer accepted responsibility for proving the operation cannot cross the boundary.

Search for casts

Look for conversions such as uint128(value), uint64(value), or signed-to-unsigned transformations. Checked arithmetic does not automatically protect them.

Search for assembly

Assembly deserves specialist review, especially when it handles amounts, lengths, prices, offsets, array indexes, or storage values.

Compare audit date with upgrade history

A protocol can retain the same brand and frontend while replacing its arithmetic implementation.

Review caps and limits

Supply caps, deposit caps, market limits, bounded rates, maximum fees, and withdrawal limits can reduce the reachable arithmetic range.

Look for established utilities

Use of maintained libraries for casting and full-precision multiplication can reduce custom-code risk. It does not guarantee correct integration.

Review incident and disclosure history

Examine whether the team publishes post-mortems, responds to researchers, maintains a bug bounty, and upgrades affected contracts transparently.

Use token scans within their proper scope

The TokenToolHub Token Safety Checker can help review ownership, minting, fees, restrictions, and other token-level indicators. It cannot prove that every reward, debt, vault, bridge, or oracle formula is mathematically safe.

How arithmetic failures appear during an incident

A math-related incident may appear as a direct exploit, a stuck function, a pricing anomaly, an accounting divergence, or a slow loss accumulating through rounding.

Sudden wrapped balance

In legacy or unchecked code, an account may receive an implausibly large balance or allowance after a subtraction.

Unexpected zero

An overflowed addition, multiplication, or cast can produce zero or another small value, causing supply, reward, or limit logic to reset unexpectedly.

Repeated arithmetic panic

In checked Solidity, a function may consistently revert with panic code 0x11. This indicates an arithmetic operation crossed its range outside an unchecked block.

Downcast mismatch

An event or external system may show a large uint256 value while storage contains a truncated uint64 or uint128 value.

Precision leakage

Small rounding errors may accumulate across many deposits, trades, repayments, or claims. The protocol can lose value without one dramatic transaction.

Oracle scaling failure

A token or collateral value may suddenly appear 10 or 100 million times too large because the formula applied the wrong decimal scale.

Stuck accumulator

A reward or interest index may reach a state where every attempted update reverts. Users may become unable to claim, repay, withdraw, or liquidate.

Tracing on-chain effects

On-chain intelligence can help connect the triggering transaction, affected contracts, unusual minting, liquidations, recipient wallets, and subsequent fund movements. Nansen can support wallet and transaction research on covered networks. Labels should be verified through contract code, traces, events, and official incident records.

Reducing personal exposure to contract math failures

A user cannot repair a deployed formula, but position sizing, contract verification, upgrade monitoring, and wallet separation can reduce the consequences of one protocol failure.

Do not concentrate assets in one unverified protocol

A high yield does not compensate for arithmetic that cannot be inspected or matched to an audit.

Separate active DeFi funds from long-term holdings

Keep only the amount needed for active interactions in the wallet connected to experimental vaults, farms, bridges, and lending markets.

Use dedicated signing devices appropriately

Hardware-wallet options such as Ledger and OneKey can support separated custody and transaction review. They protect the signing key, but they cannot make a mathematically flawed protocol safe after assets are deposited.

Monitor upgrades

Arithmetic risk can change when an implementation, oracle adapter, reward module, market parameter, or supported asset changes.

Question unexplained decimal or price changes

An exchange rate, reward rate, collateral value, or share price that changes by several orders of magnitude may indicate scaling or accounting failure.

Do not follow unofficial recovery links

Exploits are frequently followed by fake compensation, migration, verification, or rescue pages. Verify announcements independently before connecting a wallet.

TokenToolHub Research Note: compiler version is a security signal

Compiler version is one of the fastest ways to establish the starting arithmetic model of a Solidity contract.

A version before 0.8 tells the reviewer that wrapping arithmetic was the language default. Every addition, subtraction, multiplication, increment, decrement, and related expression must therefore be traced to SafeMath, a manual check, or an explicit proof that wrapping is harmless.

A version from 0.8 onward tells the reviewer that ordinary arithmetic reverts by default. The review then shifts toward unchecked blocks, type conversions, shifts, assembly, denial-of-service boundaries, precision loss, rounding, scaling, and economically incorrect formulas.

Compiler version should therefore be treated as an initial classification signal, not a final security verdict.

The decisive question is whether the complete deployed system preserves its mathematical invariants under minimum values, maximum values, zero values, long time horizons, unusual token decimals, extreme prices, upgrades, and adversarial input combinations.

Integer and smart contract math risk matrix

Smart contract math checklist for builders

Practical overflow, underflow, and math-safety scenarios

Scenario one: legacy balance subtraction

A Solidity 0.7 token subtracts an amount from the sender without SafeMath or a sufficient-balance check.

Subtracting more than the balance wraps the value to a very large number. The token's authorization model collapses because an account can appear to own far more than the intended supply.

Scenario two: modern checked mint ceiling

A Solidity 0.8 token adds a mint amount to total supply. The sum exceeds uint256.

The transaction reverts instead of wrapping. Silent corruption is prevented, but the protocol may have failed to define a realistic supply cap or input bound.

Scenario three: unchecked fee accumulator

A protocol places fee accumulation inside a broad unchecked block to save gas. The accumulator eventually wraps after sustained use.

Future fee claims become inaccurate. The optimization relied on an operating-lifetime assumption that was never enforced.

Scenario four: truncated reward index

A reward system computes an index as uint256 but stores it as uint64. The value eventually exceeds the smaller type.

The explicit conversion truncates it, causing rewards to reset or become dramatically smaller even though the contract uses Solidity 0.8.

Scenario five: multiplication before division

A lending market calculates collateral value using balance * price / scale. Both balance and price are large.

The final divided value would fit, but the intermediate multiplication overflows. In checked mode, borrowing or liquidation reverts. In unsafe wrapping mode, the collateral value becomes incorrect.

Scenario six: division before multiplication

A staking contract calculates elapsed / year * annualReward. For any elapsed period shorter than one year, the first division returns zero.

Users receive no reward until the elapsed period reaches the denominator. The contract has no overflow, but its integer operation order is wrong.

Scenario seven: oracle decimal mismatch

A collateral token uses 18 decimals while its price feed uses 8. The protocol treats both as 18-decimal values.

The resulting collateral valuation is wrong by a factor of 10 billion. All arithmetic fits within uint256, so checked arithmetic does not detect the economic error.

Scenario eight: signed minimum negation

A protocol stores a signed adjustment and calculates its absolute value by negating negative numbers.

Negating type(int256).min cannot fit in int256. The operation reverts in checked mode and can block processing of a maliciously created edge position.

Scenario nine: countdown underflow

A legacy loop decrements an unsigned index while checking a condition that fails to stop at zero.

The counter wraps to the maximum value, causing an out-of-gas failure or invalid access pattern.

Scenario ten: share rounding extraction

A vault repeatedly rounds deposits or withdrawals in a direction that benefits the caller. The loss from each action is small.

An automated strategy repeats the action and extracts value over time. No overflow occurs, but the mathematical invariant is unsafe.

Scenario eleven: upgrade changes a type width

A proxy implementation originally stores a cumulative value as uint256. An upgrade reinterprets the storage position through an incompatible packed structure.

Existing values become corrupted. The incident is a storage-layout and type problem rather than ordinary arithmetic overflow.

Scenario twelve: checked overflow blocks liquidation

A lending market's interest index grows beyond an assumed boundary. Debt calculation begins reverting.

Unsafe positions cannot be liquidated, and borrowers cannot repay through the normal path. Checked arithmetic prevented a wrong number but did not preserve protocol availability.

Scenario thirteen: bit-shift truncation

A contract packs configuration values and uses a left shift to scale an input. High bits are discarded.

The stored parameter differs from the validated value. Ordinary overflow checking does not apply to the shift.

Scenario fourteen: allowance underflow in custom token logic

A legacy token reduces allowance without checking that the spender has enough remaining approval.

The allowance wraps to a maximum-like value, allowing continued transfers far beyond the owner's intended limit.

Scenario fifteen: reward dust becomes permanently trapped

Reward-per-share calculations round small allocations down to zero. The undistributed remainder is never carried forward.

The contract remains operational, but users lose a growing amount of value through repeated truncation.

Related TokenToolHub research

Smart contract arithmetic risk overlaps with source verification, security libraries, token behavior, reentrancy, precision design, upgradeability, and protocol-wide accounting.

Common misconceptions about integer overflow and underflow

uint256 is too large to overflow

False. Its range is enormous but finite. Multiplication, exponentiation, cumulative indexes, adversarial inputs, and long-running state can reach the boundary.

Solidity 0.8 removed overflow risk

False. It changed ordinary arithmetic from silent wrapping to automatic reversion. Unchecked blocks, casts, shifts, assembly, precision errors, and denial-of-service boundaries remain.

SafeMath makes every formula correct

False. SafeMath protects against certain boundary violations. It does not correct decimals, rounding, operation order, oracle scaling, or economic logic.

Importing SafeMath proves the contract uses it everywhere

False. Critical expressions may still use raw operators, custom assembly, or another library.

A revert means no vulnerability exists

False. Reversion prevents a wrapped state value, but a reachable revert can block withdrawals, liquidations, claims, settlement, voting, or upgrades.

Explicit conversions revert when a value is too large

False. Integer downcasts can truncate. Use checked casting or explicit bounds.

Bit shifts receive the same overflow checks as multiplication

False. Shift results are truncated to the left operand's type without ordinary arithmetic overflow checks.

Smaller integer types always save gas

False. Storage packing can save slots, but arithmetic commonly uses 256-bit words, and conversions add complexity.

Overflow and underflow are only token bugs

False. They can affect lending, vaults, staking, rewards, auctions, governance, bridges, derivatives, oracles, and fee systems.

A mathematically equivalent expression always behaves the same

False. Integer division, rounding, and intermediate bounds make operation order important.

A verified contract has safe math

False. Verification lets readers inspect the source associated with deployed bytecode. It does not prove mathematical correctness.

An audit guarantees every boundary was tested

False. Audits have defined scopes and may not cover later upgrades, new markets, long-term growth, or every adversarial combination.

A hardware wallet protects assets deposited into a flawed contract

False. The wallet protects signing keys. Deployed contract logic controls assets after deposit.

Conclusion: checked arithmetic is the foundation, not the finish line

Integer overflow occurs when a result exceeds an integer type's maximum. Underflow occurs when a result falls below its minimum. In wrapping arithmetic, the value continues from the opposite boundary, turning a small change into an unrelated number.

Solidity versions before 0.8 used wrapping arithmetic by default. SafeMath and manual checks were therefore essential for balances, supplies, allowances, rewards, debt, fees, and other economic state.

Solidity 0.8 and later made ordinary arithmetic checked by default. Out-of-range results revert instead of silently wrapping. This was a major improvement, but it did not eliminate mathematical risk.

Unchecked blocks restore wrapping. Explicit downcasts can truncate. Bit shifts do not use ordinary overflow checks. Assembly requires manual validation. Integer division loses fractions. Decimal mismatches can create results that are wrong by several orders of magnitude. A checked overflow can also block a critical function.

Developers must choose types based on reachable protocol bounds, constrain inputs, document unchecked proofs, use checked casting, control precision, select rounding directions deliberately, test extreme states, and verify the deployed implementation.

Users should treat compiler version as a useful security signal. They should then confirm source verification, proxy implementation, audit scope, unchecked arithmetic, casts, assembly, formula design, upgrade history, and operational limits.

Your next action is to use the TokenToolHub smart contract verification guide to identify the exact compiler and implementation behind the contract you are evaluating. Then continue with the Safe Math and Overflow guide to inspect casts, rounding, precision, and reachable arithmetic boundaries.

FAQs

References and further learning

Use maintained compiler documentation and established library references when evaluating integer behavior, unchecked arithmetic, casting, precision, and verification.

• Solidity Documentation: Checked and Unchecked Arithmetic
• Solidity 0.8.0 Breaking Changes
• Solidity Documentation: Integer Types
• Solidity Security Considerations: Underflows and Overflows
• Solidity Type Information: Minimum and Maximum Values
• OpenZeppelin Contracts: SafeCast
• OpenZeppelin Contracts: Math Utilities
• Solidity SMTChecker and Formal Verification

This TokenToolHub guide is educational research only. It is not investment advice, trading advice, legal advice, tax advice, cybersecurity advice, accounting advice, or a smart contract audit. Always verify the compiler version, deployed implementation, arithmetic mode, unchecked blocks, type conversions, assembly, decimal scales, rounding rules, formula bounds, audit scope, upgrade history, and protocol-wide invariants before depositing assets.