# Slither: the Solidity and Vyper static analyzer from Trail of Bits

> Slither is a Python static analysis framework for Solidity and Vyper that runs a suite of vulnerability detectors and exposes a Python API for custom analyses. It is aimed at contract developers and auditors who already have a compilation framework in place.

**crytic/slither** — Static Analyzer for Solidity and Vyper

- Repository: https://github.com/crytic/slither
- Website: https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/
- Stars: 6,374 · Forks: 1,140
- Language: Python
- License: AGPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/crytic-slither

## What Slither is for, and who actually needs it

Slither targets a narrow audience: people who write or review Solidity and Vyper smart contracts and want a second pass over the code before it holds value. The README describes it as a static analysis framework written in Python 3 that "runs a suite of vulnerability detectors, prints visual information about contract details, and provides an API to easily write custom analyses." Those three jobs map to three different users. A contract developer runs the default detector suite and reads the output. An auditor runs the printers to get a fast structural picture of an unfamiliar codebase. A tooling engineer imports the API and writes an analysis that the shipped detectors do not cover.

The project is maintained by Trail of Bits, and the repository lists it under the AGPL-3.0 license. The last push to the default branch was on 2026-09-09, and the most recent release in the release list is 0.11.6 from 2026-07-28. Those dates matter more than any claim about popularity: a static analyzer is only as useful as its parser, and Solidity changes.

What Slither is not: a compiler, a fuzzer, or a replacement for reading the contract. It reports conditions in source code; it does not execute the contract or prove that a flagged path is reachable with attacker-controlled input. Treat every finding as a question to answer, not a verdict.

## How Slither works: compilation, SlithIR, detectors and printers

The pipeline starts with compilation, not with parsing source text in isolation. The README states that Slither "relies on the underlying compilation framework to compile source code," which is why the preferred invocation is `slither .` against a Hardhat, Foundry, Dapp or Brownie application rather than against a single file. Dependency resolution, remappings and the correct solc version come from the framework you already use.

Once compilation succeeds, Slither builds an intermediate representation called SlithIR. The README credits it with enabling "simple, high-precision analyses," and the repository links to a wiki page describing it. This is the design decision that separates Slither from grep-style linters: detectors reason over a normalized IR rather than over token patterns, which is how checks like `incorrect-shift` or `encode-packed-collision` can be expressed at all.

Two output surfaces sit on top of that. Detectors are the numbered checks in the README table, each carrying an impact and confidence rating; `abiencoderv2-array`, `arbitrary-send-erc20`, `array-by-reference` and `multiple-constructors` are listed as High impact and High confidence. Printers are a separate family, split in the README into quick review and in-depth review groups, and they report contract structure rather than flagging vulnerabilities. A third surface is the detector API itself, which the README describes as a way to "write custom analyses in Python."

The compatibility claims in the README are worth reading literally. It says Slither analyzes contracts written with Solidity >= 0.4 and "correctly parses 99.9% of all public Solidity code." The remaining fraction is where you will spend your time, and the README does not enumerate what falls into it.

## Installing Slither and running a first analysis

Slither requires Python 3.10 or newer, per the README note and the `requires-python = ">=3.10"` line in pyproject.toml. The README recommends uv and calls it a fast Python package manager. Install it first, then install Slither as a tool.

```bash
curl -LsSf https://astral.sh/uv/install.sh | sh
uv tool install slither-analyzer
```

After that, `slither` is on your PATH. The README also gives `uvx --from slither-analyzer slither <target>` for running without a permanent install, and `uv tool upgrade slither-analyzer` to upgrade.

If you prefer pip, the package name is the same and the upgrade path is the usual one.

```bash
python3 -m pip install slither-analyzer
python3 -m pip install --upgrade slither-analyzer
```

Homebrew users have a formula, `brew install slither-analyzer`. For development against the source tree, the README clones the repository and installs it in editable mode so that edits take effect without reinstalling.

```bash
git clone https://github.com/crytic/slither.git && cd slither
uv tool install -e .
```

The first real run depends on your project layout. If you have a Hardhat or Foundry project, change into it and point Slither at the directory.

```bash
slither .
```

What you should see is a detector report: each finding names the check, the impact and confidence, the file and the source location. If your project imports nothing, a single file works instead.

```bash
slither tests/uninitialized.sol
```

For a report you can paste into a review thread, the README documents `slither [target] --checklist`, and `--checklist --markdown-root https://github.com/ORG/REPO/blob/COMMIT/` adds GitHub source highlighting. If you are not using one of the supported compilation frameworks, you need solc, the Solidity compiler, installed separately; the README recommends solc-select for switching between compiler versions.

## Where Slither gives you nothing: imports, coverage and false confidence

The single most common way to get a useless result from Slither is to run it on a file whose imports it cannot resolve. The README is explicit that the single-file mode is for contracts that do not import dependencies. A contract that imports OpenZeppelin or a local library will not compile in that mode, and the analysis stops there. The fix is the project mode, `slither .`, which is why the README calls it the preferred option.

A second limitation is scope. Detectors find patterns; they do not establish exploitability. A High impact, High confidence label means the pattern matched, not that the contract is exploitable in your deployment. Conversely, a clean run means no listed detector matched, which is a statement about the detector list, not about the contract. The README does not claim completeness, and the detector table is a finite enumeration.

Version pinning is a real operational constraint. pyproject.toml pins `crytic-compile>=0.4.2,<0.5.0`, and the compilation framework is what actually drives solc selection. If your build uses a solc version that crytic-compile cannot obtain, Slither fails before analysis begins. The README points to solc-select for this reason.

Finally, the README notes that Slither supports Vyper contracts, but every detector in the numbered table is described in Solidity terms, and the README does not state which detectors apply to Vyper. If Vyper is your target language, verify coverage on your own contracts before assuming parity.

## Slither versus Mythril and the fuzzing approach

The obvious alternative in the Ethereum security toolchain is symbolic execution, of which Mythril is the best-known example. The two answer different questions. Slither walks the compiled contract and its SlithIR representation looking for known-bad patterns; it terminates quickly and its findings point at a source location. The README claims "an average execution time of less than 1 second per contract," which is the property that makes it viable as a pre-commit hook or a CI gate.

A symbolic executor instead explores paths and tries to construct a concrete input that reaches a bad state. That is a stronger claim when it succeeds, and a much more expensive one to make. Path explosion, solver timeouts and unbounded loops are the usual failure modes, and the tooling is correspondingly heavier.

The practical difference for a team is where each tool sits. Slither belongs in the loop on every push because it is cheap and deterministic. A symbolic executor or a fuzzer belongs in a slower job, or in a targeted investigation after Slither has pointed at something suspicious. Neither replaces the other, and running only one of them leaves a category of defect unexamined.

## Licence, maintenance and the cost of upgrading

Slither is licensed AGPL-3.0, as stated in the README, in pyproject.toml (`license = {text = "AGPL-3.0"}`) and in the Docker image labels. That is a copyleft licence with a network-use clause, and it is a different proposition from a permissive licence. Running the CLI over your own contracts does not change their licensing, but if you import the detector API into a service you expose to users, the obligations are worth reading in full. This is a description of the licence text, not legal advice; get counsel if your use is commercial and non-trivial.

The pyproject.toml classifier says "Development Status :: 4 - Beta," which is unusual for a tool with this much deployment history but consistent with a project that keeps changing its internals. The last push was 2026-09-09 and the latest release in the release list is 0.11.6 from 2026-07-28, so the project is being worked on, but the version number is still 0.x and the API surface can move between minor releases.

Upgrade cost concentrates in three places. The crytic-compile pin means a Slither upgrade can pull a different compilation layer, which can change how your project compiles. The detector set changes between releases, so a CI job that fails on any finding can start failing on a new check without any change to your contracts. The Python floor is 3.10, and the classifiers list support through 3.14, so interpreter upgrades are not the binding constraint. For CI, pin the Slither version and review the detector list when you bump it.

## Conclusion

Adopt Slither if you write or audit Solidity and Vyper and already compile with Hardhat, Foundry, Dapp or Brownie, since the README says it relies on the underlying compilation framework to compile source code. Do not adopt it as a substitute for a compiler or a test suite, and do not expect it to resolve imports in a loose file. Before wiring it into CI, verify that your pinned crytic-compile version is inside the >=0.4.2,<0.5.0 range in pyproject.toml and that a trial run against your own contracts produces findings you can triage.

## FAQ

### How do I install Slither?

The README recommends uv: install uv, then run `uv tool install slither-analyzer`. Pip (`python3 -m pip install slither-analyzer`), Homebrew (`brew install slither-analyzer`) and a Docker image based on eth-security-toolbox are also documented.

### What is Slither used for?

Slither is a Solidity and Vyper static analysis framework that runs a suite of vulnerability detectors, prints contract information through printers, and exposes an API for writing custom analyses in Python.

### Which Python version does Slither require?

Slither requires Python 3.10 or newer, according to the README note and the `requires-python = ">=3.10"` entry in pyproject.toml.

### Does Slither need solc installed separately?

Only if you are not using one of the supported compilation frameworks. The README says that in that case you need solc, the Solidity compiler, and recommends solc-select for switching between compiler versions.

### What licence is Slither released under?

AGPL-3.0, stated in the README, in pyproject.toml and in the Docker image labels.

## Sources

- [crytic/slither on GitHub](https://github.com/crytic/slither)
- [License: AGPL-3.0](https://github.com/crytic/slither/blob/master/LICENSE)
- [Project website](https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/)
- [README](https://github.com/crytic/slither/blob/master/README.md)
- [Releases](https://github.com/crytic/slither/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crytic-slither