Incorrect exponentiation

Severity: High ID: incorrect-exp

Flags ^ used between integer literals where ** was almost certainly intended.

What it does

Reports a ^ b when the base a is 2 or 10 and both operands are plain decimal integer literals, looking through integer casts such as uint256(10). In Solidity ^ is bitwise xor, not exponentiation, so 10 ^ 18 evaluates to 24, not 10 ** 18.

The base is restricted to the values people write as powers (2 for bit widths, 10 for decimals). Operands written in hex (0xff), in scientific notation (1e1), or behind a non-integer cast (bytes32(...)) are left alone: the lint prefers a false negative to a false positive that would annoy developers. This mirrors GCC's and Clang's -Wxor-used-as-pow.

Why is this bad?

Developers coming from languages where ^ means exponentiation (Python, many calculators) write 10 ^ 18 expecting 10 ** 18. The contract compiles and silently uses the wrong constant, which can corrupt amounts, decimals, or limits.

Example

Bad

uint256 constant WAD = 10 ^ 18; // evaluates to 24, not 1e18

Good

uint256 constant WAD = 10 ** 18;