Sigvex
EVMRemediation2 min read

Incorrect Exponent Remediation

Replace the XOR operator with exponentiation or scientific notation in scaling calculations.

evminteger-overflow

Incorrect Exponent Remediation

Overview

In Solidity, ^ is bitwise XOR, not exponentiation. Developers from Python or mathematical backgrounds often write 10^18 expecting 1e18, but it evaluates to 24 (10 XOR 18). When this slips into decimal scaling, price math, or precision factors, the result is wrong by eighteen orders of magnitude, producing broken transfers and exploitable accounting.

Related Detector: Incorrect Exponent

Before (Vulnerable)

uint256 DECIMALS = 10^18;  // Evaluates to 24, not 1e18

After (Fixed)

uint256 DECIMALS = 10**18;  // Evaluates to 1e18
// Or, clearer still:
uint256 DECIMALS = 1e18;

** is the exponentiation operator and produces the intended 1,000,000,000,000,000,000. Scientific notation (1e18) is even harder to misread and is the conventional way to express token-decimal scaling, so it is the preferred form for fixed scaling constants.

Alternative Mitigations

  • Prefer scientific notation (1e18, 1e6) over 10**n for fixed decimal constants to remove the ^/** ambiguity entirely.
  • Centralize scaling factors in named constants so they are written and reviewed once.
  • Add an assertion or test that checks a known scaled value (for example, that one whole token equals 1e18 base units).

Common Mistakes

  • Fixing 10^18 but leaving other ^ scaling expressions (such as 2^8 or 10^6) untouched.
  • Confusing intentional XOR (flag toggles, hashing) with a scaling bug and “fixing” correct bitwise code.
  • Assuming the compiler will warn; 10^18 is valid Solidity and compiles without error.

References