[False-Positive]: incorrect-shift and incorrect-exp produce 24 High-severity false positives on lib/solady

[holistis]

Description

Running Slither on any DeFi project that uses Solady (which is most of them) produces a flood of \incorrect-shift\ and \incorrect-exp\ High-severity findings — all false positives.

Reproduction

Clone 3FLabs/grunt (https://github.com/3FLabs/grunt), run Slither, observe:

• 19x \incorrect-shift\ — all in \lib/solady/src/utils/FixedPointMathLib.sol, \lib/solady/src/utils/LibString.sol, \lib/solady/src/utils/EnumerableSetLib.sol, \lib/solady/src/auth/OwnableRoles.sol\
• 5x \incorrect-exp\ — all in the same library files

Total: 24 High-severity findings, all in the Solady dependency, all false positives.

Root cause

Solady uses bitwise XOR (^) for operations that have nothing to do with exponentiation — it is an intentional assembly-level pattern for efficient bit manipulation. Slither's \incorrect-exp\ detector treats ^\ as the exponentiation operator (Python semantics), which is incorrect in this context.

Similarly, Slither's \incorrect-shift\ fires on Solady's low-level shift operations that use non-obvious operand ordering for gas optimization.

Both detectors are unable to distinguish between:

1. Code that naively misused ^\ thinking it was an exponent (the actual bug)
2. Code that uses ^\ correctly for XOR or deliberately uses shift ordering (Solady's case)

Impact

Solady is used by hundreds of production DeFi protocols. Every project that includes it as a dependency gets 20+ High-severity false positives. This significantly degrades the signal-to-noise ratio of Slither and makes it harder to spot real vulnerabilities.

Suggested fix

Add a library-exclusion mechanism or at minimum document that --filter-paths lib/\ is necessary when analyzing projects with Solady. A detector-level fix would check whether the contract file has been previously analyzed and accepted into a known-safe registry.

Environment

• Solady version: current (tested via 3FLabs/grunt, updated 2026-06-30)
• Full analysis: https://github.com/holistis/bug-bounty-intelligence-mcp/blob/main/BENCHMARK.md

[Mary-yumm]

Hi, I looked into this and can reproduce the root cause: Slither's incorrect-exp detector is matching on the ^ operator, which is exponentiation in Python (where Slither's detector logic is written) but is bitwise XOR in Solidity. Solady's use of ^ for gas-optimized bit manipulation is valid Solidity, so the detector is misclassifying correct code.

I'd like to work on a fix. Rather than the library-exclusion/known-safe-registry approach suggested above (which would need an external registry to maintain), I'd propose looking at whether the detector can correctly distinguish Solidity's ^ (XOR) from actual exponentiation at the operator-parsing level, so the fix holds for any codebase using this pattern, not just Solady specifically.

Before I start, I wanted to check: is this a direction the team would be open to a PR for, or is there a different approach you'd prefer? Happy to also look at the incorrect-shift false positives mentioned in the same report if that's useful context.