Integer overflow, underflow and rounding bugs in disclosed reports

Solidity 0.8 removed the easy overflows. Precision loss, unchecked blocks and casting errors kept the class alive.

Reports indexed
123
Total paid
$180k
Critical
0
Largest payout
$180k

Built-in overflow checks retired the classic `balance -= amount` underflow, and the class immediately reappeared in three new forms. Explicit `unchecked` blocks added for gas savings reintroduce the original bug with none of the original excuse. Downcasts from `uint256` to `uint128` or `uint64` silently truncate. And on non-EVM chains, Rust release builds wrap on overflow unless the arithmetic is explicitly checked.

The higher-value findings in this class are rounding rather than wrapping. Integer division truncates toward zero, and a protocol that rounds in the user's favour on deposit and again on withdrawal leaks value on every cycle. Share-price vaults are the classic target: the first depositor inflates the share price so that later deposits round down to zero shares.

These bugs are quiet. They rarely revert, they rarely trip monitoring, and they are usually found by writing the invariant down and testing it at the boundaries.

What reviewers look for

  • `unchecked` blocks around arithmetic that depends on user input
  • Downcasts to smaller integer widths without a bound check
  • Division performed before multiplication in a fee or share calculation
  • Empty-vault share price paths and first-depositor inflation
  • Rust arithmetic without `checked_*` / `saturating_*` in release builds

Curated highlights

The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.

highInteger overflow/underflowMove$180k

Unchecked arithmetic in Move coin split enables balance underflow

A custom coin-splitting helper in a Move-based decentralized exchange implemented unsafe u128 downcasting that bypassed native Move checked arithmetic. Combined with a stale balance check preceding an internal callback, an attacker could request a swap amount exceeding their actual balance. The resulting u128 subtraction underflow truncated upon downcasting into a valid u64 value, crediting the attacker with an artificially inflated balance that could subsequently be drained from the exchange.

Move DEXhatsSep 27, 2023Open
mediumInteger overflow/underflowEVM-Solidity$0

Putty: Put options are free of any fees

The Putty protocol contains a logic error where put options bypass the required fee collection mechanism upon exercise. While call options correctly deduct a designated fee, the logic for put options transfers the full strike amount to the exerciser without any fee deduction. This failure results in consistent revenue leakage for the protocol, as put options are currently processed free of charge.

Puttycode4renaAug 7, 2026Open
mediumInteger overflow/underflowEVM-Solidity$0

Putty: Options with a small strike price will round down to 0 and can prevent assets to be withdrawn

The Putty protocol contains a vulnerability where certain ERC-20 tokens, which revert on zero-value transfers, can cause a Denial-of-Service during asset withdrawals. The issue occurs because the protocol's fee calculation uses integer division, which can round down to zero for small strike prices and low fee rates. When the contract attempts to transfer this zero-value fee to the protocol's treasury, the transaction reverts, permanently locking the user's assets within the vault.

Puttycode4renaAug 7, 2026Open
mediumInteger overflow/underflowEVM-Solidity$0

Rigor Protocol: Missing upper limit definition in `replaceLenderFee()` of `HomeFi.sol`

Rigor Protocol's HomeFi contract exposes `replaceLenderFee()`, an admin-only setter that stores `lenderFee` as an unbounded uint256 with only a no-change guard. Because newly created projects inherit their `lenderFee` from the HomeFi contract, a malicious or compromised admin can set it to an extreme value such as `type(uint256).max`. When a community then lends to such a project via `lendToProject()`, the fee formula `(_lendingAmount * lenderFee) / (lenderFee + 1000)` overflows in its multiplication step and reverts, permanently blocking lending to any project created afterward. The sponsor confirmed the finding, and the recommended fix is an upper-bound check on the fee inside `replaceLenderFee()`.

Rigor Protocolcode4renaAug 7, 2026Open
mediumInteger overflow/underflowEVM-Solidity$0

The Graph: After proposed 0.8.0 upgrade kicks in, L2 `finalizeInboundTransfer` might not work

The Graph's L2GraphTokenGateway restricts finalizeInboundTransfer to calls arriving from its L1 counterpart gateway, verified via applyL1ToL2Alias, which intentionally wraps the L1 address plus a fixed offset into the expected L2 sender. The protocol planned to upgrade from Solidity 0.7.6 to 0.8.0, whose built-in overflow checks would cause that deliberate uint160 wrap to revert whenever the sum exceeds UINT160_MAX. Because the L1 gateway's address can trigger such an overflow, the modifier would reject legitimate inbound transfers after the upgrade and break L2 deposit finalization. The sponsor confirmed the concern, the judge upheld it as a valid Medium, and the fix wrapped the aliasing arithmetic in an unchecked block in a future 0.8.0 branch.

The Graphcode4renaAug 7, 2026Open
mediumInteger overflow/underflowEVM-Solidity$0

PoolTogether: Silent overflow could alter computation when calculating the `vaultPortion` in the `PrizePool` contract

The PrizePool contract in the PoolTogether V5 protocol contains an unsafe type conversion flaw that can lead to silent integer overflows. During the calculation of a vault's portion of prizes, contribution metrics returned as uint256 are cast to int256 without bound checks. If these contributions are sufficiently large, the overflow results in mathematically incorrect reward distribution, negatively impacting the prize yields for specific draws.

PoolTogethercode4renaAug 7, 2026Open

All reports in this group

Chains where this class shows up

Related vulnerability category pages