Tool selection guide
Smart contract static analysis: compare source analyzers
Start with the code and build configuration you can reproduce. A source analyzer is useful when its findings point a reviewer to a specific operation and explain why that operation may violate a rule. A tool that cannot parse the intended compiler output cannot establish coverage of that build.
Sources checked . Documentation walkthrough; tools were not run for this page.
Decide what your review needs
- Freeze the source revision, compiler version and dependency lockfiles before comparing outputs. A successful run against a different build is a different observation.
- Check whether the detector needs type information or a complete build. Pattern matching can be useful without supplying the same semantic context as a compiler-aware analysis.
- Separate the severity of a possible defect from confidence that the detector identified a real one. Confirm the affected path and authorization before escalating.
- Make suppressions reviewable. Record the detector, code location and reason. Revisit a suppression when the code or tool version changes.
Compare inputs, results and limits
| Tool & access | Input → output | When it fits | Limits & source |
|---|---|---|---|
| Slither EVM | Input: Solidity or Vyper project and a supported build configuration Output: Detector findings and structural analyses | You need compiler-aware detectors or contract structure to guide manual review. | Requires a reproducible build. Detector findings need contextual triage. Documentation reviewed. Official source |
| Aderyn EVM | Input: Solidity project source Output: Static findings for command-line or editor review | You want Solidity analysis in the development workflow and can verify the project support first. | Confirm compiler and project support before making it a CI gate. Documentation reviewed. Official source |
| Decurity Semgrep Rules EVM | Input: Source files and a chosen Semgrep rule set Output: Pattern matches with rule and location | You need targeted checks that can be inspected and extended; evaluate each rule's matching limits. | Rules cover defined patterns. Manually review matches and unsupported syntax. Documentation reviewed. Official source |
Public artifact walkthrough
Read the Slither detector table as two separate signals
The published detector table gives impact and confidence separate columns. Its reentrancy-eth entry describes a possible Ether-theft class. That label does not prove that a particular project loses funds. For a reported location, trace the external call, the state read before it and the state written afterward. Then establish whether an attacker can reach the path and repeat the sensitive operation.
Follow the detailed workflow to triage by impact and confidence.
- Capture the exact finding and the tool version. Keep the original output rather than copying only the severity label.
- Check the call path and relevant state updates in the named revision. Document an access-control or invariant argument if you reject the finding.
- Write a focused regression test or document why the suspected behavior is outside the reviewed model. Save this disposition beside the finding.