Aderyn reads a Solidity AST instead of pattern matching your contracts

A Solidity analyzer built around a generated AST

Aderyn is a Rust based static analyzer for Solidity smart contracts, aimed at protocol engineers and security researchers who want to find vulnerabilities in a codebase. The interesting design choice is in the middle of the pipeline. Rather than matching text against a set of regular expressions, Aderyn asks for an abstract syntax tree and reasons over the structure of the code. That tree comes from a custom backend, solidity-ast-rs, maintained by the same organisation, and the compiler layer comes from foundry-compilers. In other words, the analyzer is a consumer of a purpose built AST library rather than of a general purpose parser, and the workspace depends on it through a git tag pinned to an alpha build. The practical consequence is that detector quality depends on how much structure the AST exposes. The repository keeps the detectors in their own modules with a documented list of supported detectors, and the original detector set was based on the detectors of the 4naly3er project.

Three Rust crates in a Cargo workspace

The source layout is a Cargo workspace with resolver version 2 and edition 2024, holding the aderyn binary crate, aderyn_core and aderyn_driver, plus every crate under tools. The dependency list tells you what the tool actually does. Serialisation goes through serde with serde_json and serde_sarif, which is where the JSON and Sarif reports come from, and the Sarif format is what CI systems consume. Parallelism is handled by rayon, and tokio is present for asynchronous work. Command line parsing uses clap, with clap_complete for generating shell completions. The driver crate is the piece that orchestrates, and there is a Language Server Protocol stack through tower-lsp, which is what lets the editor integration surface diagnostics inside the IDE rather than only in a terminal report. Other entries show the shape of the tool: phf and petgraph for static maps and graph structures, the askama template engine for rendering, and an MCP server stack built on rmcp with axum and a streamable HTTP transport, matching the mcp-server topic the repository carries.

Four install routes and one stale path to remove

There are several ways to get Aderyn on a machine. The one time setup route is cyfrinup, an installation manager for the collection of Cyfrin tools, and re-running it upgrades every tool it manages. The direct script route is:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/cyfrin/aderyn/releases/latest/download/aderyn-installer.sh | bash

Homebrew and npm are the other two, and both live in the global package directories:

brew install cyfrin/tap/aderyn

npm install @cyfrin/aderyn -g

The documentation warns about one specific trap. If an older Aderyn binary is still sitting at ~/.cyfrin/bin/aderyn, it is no longer the default installation location and it can shadow the copy you just installed, so it should be removed with rm -f ~/.cyfrin/bin/aderyn. Upgrades differ per route: aderyn-update for the script install, brew upgrade cyfrin/tap/aderyn for Homebrew, and re-running npm install @cyfrin/aderyn -g for npm. On Windows the requirement is WSL, so the binary runs in a Linux environment rather than natively.

One command in the project root, one report file

Running the analyzer is deliberately short. From the root of the Solidity project:

cd path/to/solidity/project/root
aderyn

That produces a Markdown report, with the repository carrying an example report.md under reports/. There is no configuration step for Foundry or Hardhat projects, which removes the most common reason people abandon static analysis tooling: getting the tool to agree with the layout of the build system. The command line interface is where the rest of the behaviour lives, and the documentation keeps a separate page of CLI options for anything beyond the default run. Because the default invocation is configuration free, teams usually start with the plain run, look at the report, and only then decide what to exclude, so it is worth knowing that detectors and options are documented separately rather than bundled into a single required setup file. The reporter set covers Markdown for humans, JSON for scripts, and Sarif for code scanning tools.

Editor and CI integration instead of a terminal habit

Aderyn ships two integrations for people who do not want to leave their workflow. The first is an officially supported VS Code extension published on the Visual Studio Marketplace, which runs the analyzer against the code in the editor. The second is the Aderyn CI Assistant, a GitHub Action that performs static analysis on Solidity codebases in CI so potential vulnerabilities are caught before code is committed. Both matter because a static analyzer that only runs when someone remembers to run it produces findings that go stale. The LSP stack in the driver crate is what makes the editor experience possible, and the Sarif output is what makes the CI experience possible, so the two integrations are not add-ons but the reason the report formats exist in the first place. Writing your own detector is also part of the story: the documentation has a detectors quickstart for creating custom ones, and the repository is described as contributor friendly with contribution guidelines covering the development environment.

The licence in the README and the licence in the manifest

Here is something to check before you build on Aderyn. The documentation states that Aderyn is licensed under the GPL-3.0 licence and the repository carries a GPL-3.0 badge, while the Cargo workspace manifest declares license = "MIT" for the workspace package. Two different licences in the same repository is not a detail to gloss over, because the obligations differ, and this is the sort of thing to settle with the project maintainers rather than guess about. Beyond the licence question, the project is actively moving: tagged releases aderyn-v0.6.6, aderyn-v0.6.7 and aderyn-v0.6.8 all landed in January 2026, and the last push was on 2026-10-18. The repository also carries a RELEASE_CHECKLIST.md, a benchmarks directory with a benchmarks.sh script, and a justfile whose setup target checks for forge, pnpm, yarn and cargo-clippy before installing test fixtures from git submodules, which is a fair indication of how the test corpus is assembled.

Editorial conclusion

Adopt Aderyn if you review Solidity codebases, want findings you can paste into a pull request as Sarif or Markdown, and prefer a Rust binary over a Python environment. Do not adopt it as a replacement for a manual audit, and do not assume its detector list matches the tool your team already uses, because the documentation only links to a supported detectors list rather than describing coverage. Before you commit, check that the licence file in the repository matches the manifest value you were told about, that the stale binary at ~/.cyfrin/bin/aderyn is not shadowing your install, and that the detector list on the Cyfrin docs covers the patterns your contracts actually contain.

Frequently asked questions

Official sources

1. Cyfrin/aderyn on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases