Signed/unsigned arithmetic confusion
A code & audits factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score#
What this measures
This factor detects signed/unsigned arithmetic confusion in the deployed bytecode: specifically, cases where a signed integer (int256) is cast to unsigned (uint256) in a context where the value may be negative, or where comparison operators are applied to signed values where unsigned was intended. The assessment uses static analysis and symbolic execution on verified source code. A flag is recorded when the detector identifies a potential underflow or semantic inversion due to signedness mismatch.
Why it matters
Signed-to-unsigned conversions with negative values wrap around to large positive integers in Solidity (two's complement). A negative int256 value cast to uint256 produces a number close to 2^256, which when used in a comparison or arithmetic context can bypass a bound check or produce a wildly incorrect amount. This pattern has appeared in approximately three documented hacks in the T-01 evidence base, primarily in protocols that use signed arithmetic for position accounting (perps, options, yield-bearing positions) and then convert to unsigned for token transfer amounts.
Green / Yellow / Red
Green: no signed-to-unsigned conversions are present in code paths that handle token amounts, collateral values, or position sizes, or all such conversions have explicit bounds checks that revert if the input is negative. Yellow: conversions exist in peripheral calculation paths where the value is always positive by construction, with curator confirmation. Red: a signed-to-unsigned conversion is present in a core fund-movement or collateral calculation path without a negative-check guard.
Common gray cases
This factor is gray for protocols written in Vyper (where the type system prevents implicit signedness conversions) or for simple token protocols with no signed arithmetic.
Notable historical examples
No hacks are currently linked in the database for this specific factor as a standalone causal driver. The factor is retained as P2 based on approximately three supporting instances in the T-01 evidence inventory.
Measurement what to look for#
Determine whether signed-integer conversions or comparisons where unsigned was intended exist in the deployed bytecode/source.