What Is Slither? A Practical Guide to the Solidity Static Analyzer

Updated 2026-06-18 · VRF7 Security Guides

Slither is an open-source static analysis framework for Solidity smart contracts, developed and maintained by Trail of Bits. It parses your contract source code, builds an internal representation of the program's control flow and data flow, and then runs a library of detectors that flag known vulnerability patterns, code-quality issues, and optimization opportunities — all without executing the contract. If you are evaluating security tooling for a Solidity project, understanding what Slither does and where it fits in a broader security workflow is essential.

How Static Analysis Works

Static analysis examines source code or compiled artifacts at rest, without running the program. For smart contracts this means Slither reads your .sol files, compiles them internally using the same version of solc specified in your pragma, and constructs several intermediate representations:

• SlithIR — a simplified, SSA-form (Static Single Assignment) intermediate representation that makes data-flow reasoning tractable.
• Call graph — a directed graph of which functions call which, including cross-contract calls.
• Control-flow graph (CFG) — the possible execution paths through each function.

Detectors then query these representations using a Python API. Because the analysis is purely syntactic and semantic rather than execution-based, it is fast — a moderately sized codebase typically finishes in seconds — and it produces no false negatives for patterns it was specifically written to catch. The trade-off is that it cannot reason about runtime state or probabilistic execution paths the way symbolic execution tools can. For a comparison of these approaches, see What Is Mythril? Symbolic Execution for Smart Contract Security.

Slither's Detector Categories

Slither ships with over 100 detectors organized by impact and confidence. Impact levels are High, Medium, Low, and Informational. Confidence levels are High, Medium, and Low, indicating how certain the tool is that a flagged pattern is actually a problem rather than a false positive.

High-Impact Detectors

• reentrancy-eth — identifies functions that send Ether before updating state, the classic pattern behind reentrancy exploits. See Reentrancy Attacks in Solidity: How They Work and How to Prevent Them for a deep dive.
• arbitrary-send-eth — flags functions where an attacker-controlled address receives Ether.
• controlled-delegatecall — detects delegatecall targets derived from user input, which can lead to complete storage corruption.
• suicidal — finds selfdestruct calls reachable by any caller, not just the owner.
• uninitialized-local / uninitialized-storage — catches variables that default to zero or to an unexpected storage slot.

Medium-Impact Detectors

• tx-origin — warns against using tx.origin for authorization.
• incorrect-equality — flags strict equality checks on balances or block numbers that can be manipulated.
• locked-ether — identifies contracts that accept Ether but have no withdrawal path.
• weak-prng — detects pseudo-random number generation derived from block variables.

Informational and Optimization Detectors

Beyond security bugs, Slither also surfaces maintainability concerns: missing zero-address checks, unused state variables, public functions that could be declared external, costly storage reads inside loops, and shadowed state variables. These findings do not represent immediate vulnerabilities but they reduce auditability and increase attack surface over time.

Running Slither

Installation requires Python 3.8 or later and a compatible solc binary. The recommended approach is via pip:

pip install slither-analyzer

For projects that use Hardhat or Foundry, install the relevant compiler wrapper so Slither can locate the correct solc version automatically:

# Hardhat project
slither .

# Foundry project
slither . --foundry-compile-all

# Single file with explicit compiler
slither contracts/Token.sol --solc-version 0.8.20

By default Slither prints findings to stdout grouped by detector. You can export machine-readable output for CI integration:

slither . --json slither-report.json --checklist

A Concrete Example: Reentrancy

Consider this vulnerable withdrawal function:

// Vulnerable
function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount);
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok);
    balances[msg.sender] -= amount; // state update AFTER external call
}

Slither's reentrancy-eth detector identifies that balances[msg.sender] is written after an external call to msg.sender, and reports the finding with the precise source location. The fix is to update state before the external call:

// Fixed
function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount; // state update BEFORE external call
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok);
}

Filtering False Positives

Slither will occasionally flag code that is intentionally written in a non-standard way. You can suppress individual findings inline with a structured comment:

//slither-disable-next-line reentrancy-eth
(bool ok, ) = trustedContract.call{value: amount}("");

Use suppressions sparingly. Every suppressed line should be accompanied by a comment explaining why the pattern is safe in context, so future auditors understand the reasoning.

Integrating Slither into a CI Pipeline

Because Slither exits with a non-zero code when it finds issues above a configurable threshold, it integrates cleanly into GitHub Actions, GitLab CI, or any shell-based pipeline. A minimal GitHub Actions step looks like this:

- name: Run Slither
  uses: crytic/slither-action@v0.3.0
  with:
    node-version: 18
    fail-on: high

Setting fail-on: high blocks merges when new high-impact findings appear without blocking on informational noise. Tightening the threshold over time as the codebase matures is a practical way to incrementally raise the security baseline.

What Slither Cannot Do

Understanding the limits of any tool is as important as understanding its capabilities.

• It does not execute code. Slither cannot discover vulnerabilities that only manifest under specific runtime conditions, such as integer overflows that depend on particular input values combined with specific contract state.
• It cannot reason across off-chain components. Oracle manipulation, MEV-related issues, and governance attacks typically involve multiple transactions and external actors that static analysis cannot model.
• It misses business-logic flaws. If a fee calculation formula is mathematically correct but economically wrong for the protocol, Slither will not flag it.
• Proxy storage collisions require configuration. Slither has a --proxy-* flag family for upgradeability analysis, but it requires explicit setup and still misses subtle slot-collision scenarios.

These gaps are precisely why automated scanning and manual auditing serve different functions. For a detailed breakdown, see Automated Scanners vs Manual Audits: What Is the Difference?.

Slither Inside a Multi-Tool Workflow

No single static analyzer covers every vulnerability class with equal depth. Slither excels at fast, broad pattern matching across a large detector library. Mythril adds symbolic execution for constraint-based vulnerability discovery. Aderyn focuses on Foundry-native projects with a Rust-based AST traversal. Echidna applies fuzzing to discover invariant violations through random inputs.

Running these tools together and correlating their output gives a more complete picture than any single tool alone. VRF7 runs Slither alongside Aderyn, Mythril, Semgrep, Solhint, SMTChecker, and Echidna in parallel, labels every finding with the tool that produced it, and explains each result in plain language. If you want to see how your contracts fare across all these tools at once, you can run an automated scan without setting up any local tooling.

Summary

Slither is a mature, actively maintained static analysis framework that should be part of every Solidity developer's baseline security workflow. It is fast, integrates easily into CI, and its detector library covers a broad range of high-severity vulnerability classes. Its limitations — no runtime reasoning, no business-logic coverage — are not weaknesses unique to Slither; they are inherent to the static analysis approach. Use it early, use it often, and pair it with other analysis methods and eventual manual review before deploying contracts that hold real value.