/integer-issues

name: integer-issues
description: Detect integer over/underflow in `unchecked` blocks, downcasting losses, fixed-point precision errors, division-before-multiplication, signed/unsigned mixing. Activate on any arithmetic in `unchecked { }`, `SafeCast`, `uintN(uintM(x))` casts, division and modulo, percentage/basis-points math, AMM share/asset math.

Integer issues detection

When this applies

• `unchecked { … }` blocks (Solidity ≥0.8)
• Downcasts: `uint128(x)`, `int256(uint256(x))`, `uint8(...)`
• Division and modulo
• Fixed-point math with custom decimal scales
• Share/asset math in vaults, lending, AMMs
• Pre-0.8 Solidity code (no built-in overflow checks)
• Vyper code with unbounded loops
• Inline assembly arithmetic

Detection patterns

Unchecked overflow on user input (HIGH)

unchecked {
    balance[to] += amount;        // ← if amount controlled, can overflow back to 0
}

`unchecked` is fine for proven-safe accumulators (e.g. `++i` in bounded loops), not for value math.

Division before multiplication (HIGH)

uint256 fee = (amount / 100) * feeBps;   // ← truncation; do (amount * feeBps) / 100

Decimal mismatch (HIGH)

USDC = 6 decimals, WETH = 18, WBTC = 8. Mixing without scaling produces silent 1e10–1e12 errors.

uint256 wethValue = amountUsdc * price;   // ← USDC 6dp × price 8dp = 14dp, need 18dp

Downcast loss (HIGH)

uint128 sharesU128 = uint128(shares);   // ← silently truncates if shares > 2^128

Use OZ `SafeCast`.

Fixed-point precision loss (HIGH)

Compounding interest done as `principal * (1 + rate)^t` with too-few-decimal `rate`. Use ray (1e27) or wad (1e18) math via PRBMath / Solady.

Round-direction asymmetry (HIGH for vaults)

ERC-4626 must round shares *down* on deposit (favor vault) and *up* on withdraw (favor vault). Reversed direction = donations-style drain. Use OZ `Math.mulDiv(_, _, _, Rounding.Down/Up)`.

Signed/unsigned mixing (HIGH)

int256 delta = int256(a) - int256(b);   // a or b might be > 2^255, becomes negative silently

Modulo zero (revert, but…) (MEDIUM-HIGH if attacker can set divisor=0)

Block-time math on L2 (MEDIUM)

`block.timestamp` granularity differs (2s on Optimism, 250ms on Arbitrum). Slot-based deadlines can be off.

Sqrt / log integer approximations (MEDIUM)

Custom `sqrt` implementations are notorious. Use Solady/PRBMath.

Percentage in basis points without bounds (LOW)

`fee_bps` should be capped (`fee_bps <= 10_000`).

Severity rubric

| Pattern | Severity | |---|---| | Unchecked overflow on user input | **High** | | ERC-4626 round-direction wrong | **High** | | Decimal-mismatch in price/balance math | **High** | | Downcast losing high bits silently | **High** | | Division before multiplication on financial-critical path | **High** | | Custom sqrt/log without overflow proof | **Medium** | | Bps fee with no cap | **Low** | | Loop index underflow in pre-0.8 code | **High** | | Modulo-zero on attacker-controlled divisor | **High** |

Remediation patterns

• Solidity 0.8.x default checks; only `unchecked` proven-safe (e.g. `++i` in `for` loops bounded by array length).
• OZ `SafeCast` for downcasts.
• `Math.mulDiv` (OZ) for multiply-then-divide without intermediate overflow.
• PRBMath or Solady for fixed-point exp/log/pow.
• Always scale to a common decimal base before doing math; document the scale.
• ERC-4626: always use `Math.mulDiv(..., Rounding.Down)` on deposits, `Rounding.Up` on withdrawals; or use OZ's `ERC4626Upgradeable` which handles this.

False-positive notes

• `unchecked { ++i; }` in `for` loops with `i < arr.length` is the canonical safe use — not a finding.
• Pre-0.8 SafeMath is fine; the issue is mixed-version dependencies.

Related

• [[token-compatibility]] — decimals confusion
• [[oracle-manipulation]] — price scaling
• [[yield-aggregator-specialist]] — ERC-4626 round direction