Incorrect Exponent

Overview

The incorrect exponent detector identifies Solidity code where the ^ operator is used in a context where exponentiation (**) was likely intended. In Solidity, ^ is the bitwise XOR operator, not exponentiation. Developers coming from Python or mathematical notation frequently write 10^18 expecting 10**18 (1e18), but 10^18 evaluates to 24 (bitwise XOR of 10 and 18).

Why This Is an Issue

The results of XOR and exponentiation differ by orders of magnitude. 10^18 = 24, while 10**18 = 1,000,000,000,000,000,000. If this confusion occurs in token decimal calculations, price computations, or scaling factors, the resulting values are astronomically wrong — leading to incorrect transfers, broken pricing, or exploitable accounting.

How to Resolve

// Before: Vulnerable — XOR instead of exponentiation
uint256 DECIMALS = 10^18;  // Evaluates to 24, not 1e18

// After: Fixed — correct operator
uint256 DECIMALS = 10**18;  // Evaluates to 1e18
// Or use a constant
uint256 DECIMALS = 1e18;

Detection Methodology

XOR instruction detection: Identifies XOR opcodes in the bytecode.
Operand analysis: Checks if the operands are small constants (like 10, 2, 8) combined with larger constants (like 18, 8, 6) — the pattern typical of decimal/precision calculations.
Context analysis: Examines surrounding arithmetic to determine if the XOR result is used in multiplication or division that suggests a scaling factor was intended.
Constant folding check: Detects when the compiler has already folded the XOR result to a suspiciously small constant used in a scaling context.

Limitations

False positives: Legitimate XOR usage (bitwise operations, hash computations, toggle flags) may match the operand pattern. False negatives: If the compiler folds the XOR at compile time and the resulting constant is used without surrounding context, the intent is difficult to infer from bytecode alone.

Precision Errors — detects precision loss in calculations
Integer Overflow — detects arithmetic overflow