#07 SC07:2026 High NEW for 2026

Arithmetic Errors (Rounding & Precision)

Arithmetic errors (rounding and precision loss) describe any situation where a smart contract performs integer-based calculations that produce incorrect or exploitable results due to truncation, scaling, or unit conversion.

Official OWASP description, from scs.owasp.org (CC BY-NC-SA 4.0).

$138M

2025 losses attributed

15.3%

Of all 2025 SC losses

Why this rank in 2026

New for 2026. OWASP carved out a separate category for rounding and precision because 2025 produced several nine-figure incidents (Balancer V2 $128M, zkLend $9.5M, Bunni $8.4M) where the bug was distinct from classic integer overflow. SC07 is about subtle math, not impossible math.

Why this is a new 2026 category

OWASP carved out rounding and precision as a distinct category in 2026 because 2025's biggest math-related losses were not classic integer overflows - they were subtle arithmetic flaws where the math compiled, the tests passed, and a 1-wei rounding bias became a 7-figure exploit after enough iterations.

2025 incidents

Balancer V2 (Nov 2025) lost ~$128M when _upscaleArray rounding in manageUserBalance was combined with access-control issues. (OWASP cross-references this under SC01 because the access-control failure is the entry point, but the amplification is pure SC07.)
zkLend (Feb 2025) lost $9.5M when integer-division rounding in mint() inflated internal accumulators across many small mints.
Bunni (Sep 2025) lost $8.4M when a withdrawal rounded down assumption broke under specific liquidity-burn sequences.

The ERC-4626 inflation attack family

A specific sub-pattern worth calling out: ERC-4626 vaults are vulnerable to first-depositor "inflation" attacks where rounding asymmetries on the first deposit let an attacker mint shares against minimal collateral. Modern vault implementations (OpenZeppelin 5.x) include _decimalsOffset to neutralize this, but custom vaults still ship the bug regularly.

How AI auditors handle this category

AI is moderately strong here. It detects divide-before-multiply and zero-supply edge cases. It is weakest on adversarial-sequence arithmetic - bugs that only appear after a specific multi-step sequence of operations. Fuzzers (Echidna, Medusa, Foundry) close most of that gap, but only when the right invariants are written first.

2025 incidents tied to this category

Pulled live from the SCH hack database, ordered by amount lost. Click any incident for the full post-mortem.

Balancer V2

$128.0M Nov 2025

arbitrum base ethereum optimism polygon sonic

View the full SCH hack dashboard →

Vulnerable vs secure code

✗ Vulnerable solidity

// Vulnerable: divide before multiply causes 0 result on small inputs
function calcReward(uint256 stake, uint256 totalStake, uint256 pool) public pure returns (uint256) {
    return stake / totalStake * pool;   // tiny stakes yield zero
}

✓ Secure solidity

// Secure: multiply before divide + explicit rounding direction
function calcReward(uint256 stake, uint256 totalStake, uint256 pool) public pure returns (uint256) {
    require(totalStake > 0, "zero total");
    return (stake * pool) / totalStake;     // mulDiv-style; rounds down by default
}

AI vs human auditor on this category

Each bar is a detection rate: out of 100 known arithmetic errors bugs, how many that auditor type finds. Higher means more reliable. The gap below is the percentage-point difference - the work senior humans still do that AI does not.

AI auditor (frontier LLM)

64%

Human auditor (senior)

86%

% of SC07 bugs caught - higher is better.

Human advantage on SC07

+22 percentage points

Senior auditors catch 22 more arithmetic errors bugs per 100 than frontier AI today. That gap is the skill the SCH course teaches.

AI catches obvious "divide before multiply" patterns and zero-supply edge cases. The gap is in *asymmetric* rounding under adversarial sequences, where a 1-wei rounding in the protocol's disfavor becomes a 7-figure drain after enough flash-loan-amplified iterations.

Methodology: EVMbench, Cecuro purpose-built agent benchmarks, and senior-auditor self-reported catch rates. SCH editorial, not OWASP-authored.

Prevention checklist

Use safe math (Solidity 0.8+ default checks).
Document and test rounding direction explicitly; round in the protocol's favor.
Prove repeated interactions cannot generate free value.
Use reviewed fixed-point, exp, and log libraries - do not roll your own.
Add invariant checks: totalAssets vs user balances, share/value consistency.
Fuzz and differentially test edge cases (zero supply, first depositor, extreme ratios).

Detection tools

Industry-standard tools that detect this category. Tool mappings are SCH editorial - OWASP's per-category pages do not list specific tools.

Echidna

fuzz

primary tool for rounding bugs

Medusa

fuzz

parallel coverage-guided arithmetic fuzzing

Foundry

fuzz

invariant tests on share/asset conversion

Slither

static

divide-before-multiply detector

Aderyn

static

division-before-multiplication

Deep dive: related SCH attack pages

FAQ

What is OWASP SC07 Arithmetic Errors?

SC07 covers situations where a smart contract performs integer-based calculations that produce incorrect or exploitable results due to truncation, scaling, or unit conversion. It is a new category for OWASP 2026, carved out specifically because 2025 produced several nine-figure incidents (Balancer V2 $128M, zkLend $9.5M, Bunni $8.4M) where the bug was distinct from classic integer overflow.

How is SC07 Arithmetic Errors different from SC09 Integer Overflow?

SC09 is about values exceeding the representable range of the type (overflow / underflow). SC07 is about subtle math that compiles cleanly but is wrong - rounding direction, divide-before-multiply, precision loss, and adversarial-sequence arithmetic where a 1-wei rounding bias becomes a 7-figure exploit after enough iterations. SC07 is about subtle math, not impossible math.

What is the ERC-4626 inflation attack?

A first-depositor attack on share-based ERC-4626 vaults where rounding asymmetries on the first deposit let an attacker mint shares against minimal collateral. Modern vault implementations (OpenZeppelin 5.x) include _decimalsOffset to neutralize this, but custom vaults still ship the bug regularly. Bunni $8.4M (Sep 2025) is a 2025 example of a related rounding pattern amplified by flash loans.

What is the divide-before-multiply bug in Solidity?

Computing a/b*c instead of a*c/b. On integer arithmetic, dividing first truncates small values to zero, so tiny stakes or small reward amounts disappear entirely. Slither and Aderyn flag this pattern. Always multiply before divide unless overflow risk requires reordering - and then use a mulDiv helper.

How do you prevent arithmetic and rounding bugs in Solidity?

Use Solidity 0.8+ for built-in overflow checks. Document and test rounding direction explicitly - round in the protocol favor. Prove repeated interactions cannot generate free value. Use reviewed fixed-point, exp, and log libraries (do not roll your own). Add invariant checks on totalAssets versus user balances. Fuzz and differentially test edge cases (zero supply, first depositor, extreme ratios) with Echidna, Medusa, or Foundry invariants.

How well do AI auditors detect arithmetic bugs?

AI is moderately strong - around 64% catch rate versus 86% for senior humans. It detects divide-before-multiply and zero-supply edge cases reliably. The gap is in adversarial-sequence arithmetic: bugs that only appear after a specific multi-step sequence of operations. Fuzzers close most of that gap, but only when the right invariants are written first.

Sources & methodology

Every claim on this page traces back to a primary, citable source. Open the originals if you want to verify the numbers or read the underlying methodology.

Official

OWASP Foundation

SC07 category page

Canonical description, root causes, and references for Arithmetic Errors in the 2026 list.

Project

OWASP Foundation

Smart Contract Top 10 2026

Project landing page covering scope, governance, and the full 10-category ranking.

Methodology

OWASP Foundation

Data sources & ranking method

How OWASP scored each category from 2024-2025 incident data, audit reports, and contributor surveys.

Dataset

CredShields

Web3HackHub incident database

Continuously updated public dataset of on-chain exploits used to cross-check loss figures.

Quoted OWASP descriptions are used under CC BY-NC-SA 4.0. SCH editorial content (analysis, code, prevention prose, FAQ, AI-vs-human rates) is © Smart Contract Hacking.

Continue through OWASP 2026

← Back to the OWASP 2026 hub

Master the techniques that make this category exploitable

The SCH Smart Contract Hacking Course teaches the exploit primitives, audit techniques, and tool workflows for arithmetic errors (rounding & precision) and every other OWASP 2026 category.

Explore the course Estimate an audit