---
title: 'Slither: Smart Contract Analysis Framework'
url: https://www.emergentmind.com/topics/slither
type: topic
---

# Slither: Smart Contract Analysis Framework

Searching arXiv for relevant papers on Slither to ground the article.
“Slither” denotes several distinct technical objects in the research literature. Most prominently, it names an open-source static analysis framework for Ethereum smart contracts that converts Solidity source code into an intermediate representation, SlithIR, to support vulnerability detection, code optimization analysis, code understanding, and code-review assistance [1908.09878]. In other contexts, “Slither” refers to a two-player connection game whose arbitrary-position outcome problem is PSPACE-complete [1605.04715], to a snake-inspired serpentine motion imposed on a mobile robot to enrich inertial measurements for positioning [2411.17430], and to one of the mobile games used in touch-dynamics continuous-authentication experiments [2305.09482]. The dominant technical usage in recent arXiv literature is the smart-contract framework, which has become a recurring baseline, oracle, extensibility substrate, and integration component across benchmarking, abstract interpretation, mutation-based evaluation, LLM-assisted auditing, and smart-contract synthesis studies [1908.09878].

## 1. Slither as a smart-contract static analysis framework

Slither is a static analysis framework for Ethereum smart contracts that parses Solidity source through the Solidity compiler AST, reconstructs structural information such as inheritance graphs and control-flow graphs, translates the contract into SlithIR, and runs built-in analyses and detectors on that representation [1908.09878]. The framework is explicitly presented not as a single detector but as an extensible analysis platform with four main use cases: automated detection of vulnerabilities, automated detection of code optimization opportunities, improvement of the user’s understanding of contracts, and assistance with code review [1908.09878].

Its central design object is SlithIR, a hybrid intermediate representation associated with control-flow-graph nodes. SlithIR uses Static Single Assignment form and a reduced instruction set of fewer than 40 instructions, with the stated purpose of easing implementation of analyses while preserving semantic information that would be lost in transforming Solidity directly to bytecode [1908.09878]. The framework applies commonly used program-analysis techniques such as dataflow and taint tracking, and it performs alias analysis for storage references and inserts $\phi$-functions not only at function entry but also after external calls for state variables that may be read later [1908.09878]. This makes Slither unusually suited to Solidity-specific issues such as storage aliasing and re-entrancy-sensitive state reasoning.

The built-in analyses described for Slither include read/write analysis, protected-function analysis, and data-dependency analysis [1908.09878]. The open-source version includes more than twenty bug detectors, including shadowing, uninitialized variables, reentrancy, suicidal contracts, locked ether, and arbitrary ether sending [1908.09878]. It also includes “printers” that generate inheritance graphs, CFGs, call graphs, contract summaries, authorization summaries, and complexity summaries [1908.09878]. This combination of detector infrastructure and program representation is why later work repeatedly uses Slither as a foundation rather than merely as an off-the-shelf scanner.

## 2. Evaluation, benchmarking, and empirical performance

The original Slither evaluation compares it with Securify, SmartCheck, and Solhint on known vulnerable contracts and on 1000 of the most used contracts on Ethereum [1908.09878]. In that study, Slither is reported as the only tool that correctly found the actual reentrancy vulnerabilities in both DAO and SpankChain, with a false-positive rate of **10.9%**, average execution time of **0.79 ± 1**, **0%** timed-out analyses, and a failure rate of **0.1%** [1908.09878]. The same paper states that Slither was the fastest tool overall and “typically as fast as a simple linter” [1908.09878].

Subsequent benchmark work treats Slither as a strong but incomplete baseline. In SolidiFI, which evaluates six widely used smart-contract static analysis tools using **50 contracts** injected by **9369 distinct bugs**, Slither is characterized as an automated Solidity analyzer that is not based on symbolic execution and that uses SSA for analysis [2005.11613]. In that evaluation, Slither achieved **0** false negatives for **Re-entrancy** on **1343** injected cases and **0** false negatives for **tx.origin** on **1336** injected cases, but it missed **537** of **1381** Timestamp dependency bugs and **457** of **1374** Unhandled exceptions bugs [2005.11613]. The same study reports that Slither had the lowest false negatives overall, while also warning that it reported many false positives, including **71** reentrancy false positives and **1807** miscellaneous reports [2005.11613].

A broader bug-framework study evaluates nine tools on the Jiuzhou dataset of **176 smart contracts** covering **49 bug kinds** and concludes that Mythril, Slither, and Remix are the most worthwhile combination of analysis tools [2009.02066]. Within that study, Slither is reported as having the highest coverage among the evaluated tools and as detecting **27 kinds of bugs**, while still leaving numerous bug classes uncovered [2009.02066]. This suggests a recurrent empirical pattern: Slither is often favored for breadth and practicality, but not regarded as exhaustive.

A more recent systematic review of LLM-based smart-contract vulnerability detection again positions Slither as the canonical traditional static-analysis baseline. It describes Slither as fast but potentially prone to false positives, notes that it converts Solidity smart contracts into SlithIR based on SSA, and evaluates it on eight vulnerability categories from a verified-contract dataset [2504.04685]. In that review, Slither’s F1 scores are reported as **0.68** for Reentrancy, **0.78** for Timestamp Dependency, **0.75** for TxOrigin, **0.57** for Unchecked Call, **0.54** for DelegateCall, **0.50** for Frozen Ether, and **0.00** for both Integer Overflow/Underflow and Transaction Order Dependency [2504.04685]. Its mean runtime is reported as **0.57 s**, compared with **430.25 s** for Mythril [2504.04685].

## 3. Dataset generation, mutation, and robustness under transformation

Several papers use Slither not only as a benchmark target but also as an instrument for stress-testing evaluation methodology. One line of work studies semantic-preserving code transformation for expanding vulnerability datasets. Using **272 Solidity snippets** spanning **7 vulnerability types**, the paper reports that Slither performs strongly on many original patterns but becomes fragile under transformed code [2410.21685]. For example, Slither reports **0 false negatives** on the original Reentrancy cases over **1343 vulnerable locations** and **0 false negatives** on the original tx.origin cases over **1336 vulnerable locations**, yet after transformation it misses **131** of **1235** Reentrancy cases under $Op_{if}$ and **1336** of **1336** tx.origin cases under $Op_{tx}$ [2410.21685]. The same study states that the transformed dataset grows from **272 original snippets** to **674 new vulnerable code snippets**, a **248% increase**, and argues that semantic-preserving rewrites can expose detector brittleness [2410.21685].

A mutation-seeding benchmark study uses Slither as the main static-analysis oracle to assess vulnerabilities injected by MuSe into real-world contracts from the smartbugs-wild corpus [2504.15948]. The study generates **350,493** mutants from **47,398** original contracts and reports that Slither successfully analyzed **335,234** mutants after excluding execution failures [2504.15948]. Its overall recall on injected vulnerabilities is **0.597**, with perfect recall on Unchecked low-level call return value (**1.000**) and Unchecked send (**1.000**), moderate recall on Multiple calls in a loop (**0.810**) and Unused return (**0.605**), and weak recall on Authentication through `tx.origin` (**0.336**) and Delegatecall to untrusted callee (**0.100**) [2504.15948]. The paper attributes many misses to strong dependence on syntactic form, modifiers, inheritance, and complex boolean structure [2504.15948].

These results complicate any simple claim that Slither is uniformly “accurate.” A more precise formulation, supported by the literature, is that Slither is often highly effective on canonical vulnerability idioms, yet can be brittle under semantically equivalent rewrites or when vulnerability patterns are embedded in less direct syntactic contexts [2410.21685][2504.15948]. A plausible implication is that benchmark quality and code-form diversity materially affect measured performance.

## 4. Slither as infrastructure for extensibility and abstract interpretation

A recurring theme in later work is that Slither functions as a program-analysis substrate. One progress report on smart-contract interval analysis states that existing tools, including Slither, could not detect the motivating examples, and therefore implements interval analysis “on top of Slither” using Slither’s CFG, SlithIR SSA representation, and variable metadata [2309.13805]. That work uses a worklist algorithm over the CFG and interval abstractions of the form $[\ell, u]$ to detect domain mismatches, possible division by zero, integer division remainder issues, uninitialized/default-value problems, and missing input validation [2309.13805]. Slither alone, in that study, is said to detect uninitialized variables and trivial tautologies/contradictions in `assert`/`require`, but to miss the other examples [2309.13805].

A later paper extends the same direction by combining interval analysis with a constraint system and an SMT solver, again explicitly built on top of Slither [2410.23766]. In that architecture, Slither supplies parsing, AST, CFG, inheritance, and SlithIR-level program structure, while the added analysis computes a least fixed point over the CFG, tracks intervals and boolean constraints, and checks satisfiability using Z3 [2410.23766]. The analysis domain is defined as
$$
D=\{AI=(Val,Con) \mid Val:Var \rightarrow IntExt,\ C \subseteq BExp\}
$$
and is used to identify unreachable code, locked ether, possible division by zero, missing parameter validation, and array out-of-bounds conditions [2410.23766]. The paper’s explicit motivation is that Slither does not query contract state at each statement and does not itself perform interval analysis or propagate constraints strongly enough to prove certain branches unreachable [2410.23766].

Another line of extension concerns proxy-pattern detection. A survey of upgradeable smart-contract patterns reports that the authors analyzed approximately **100,000 verified contracts** from Etherscan, extracted about **64,000 unique files**, and used Slither as the base framework while implementing more robust proxy detection [2304.03405]. They argue that Slither’s original `is_upgradeable_proxy` logic was too permissive, partly because it checked for the word `"Proxy"` in the contract name and partly because compiler-version changes affected assembly handling [2304.03405]. Their revised approach separates `is_proxy` from `is_upgradeable_proxy`, searches fallback functions for `delegatecall` across IR nodes, assembly nodes, and expression nodes, checks that the delegated implementation address is not constant, and looks for setter/getter patterns that establish actual upgradeability [2304.03405]. The result is an elimination of approximately **70 percent** of the contracts initially flagged as upgradeable proxies as false positives [2304.03405].

Taken together, these papers show that Slither’s significance is not limited to its shipped detectors. It also serves as a reusable compiler-facing front end and IR provider for third-party analyses, particularly those that require Solidity-specific structure but seek more semantic precision than pattern-based scanning alone [2309.13805][2410.23766][2304.03405].

## 5. Slither in machine-learning and LLM-centered workflows

Slither occupies several distinct roles in machine-learning research on smart-contract analysis. In DLVA, a neural vulnerability analyzer for Ethereum smart contracts, Slither is the supervising oracle used to label source-available contracts so that a bytecode-based model can learn to predict vulnerabilities without manual feature engineering [2304.10726]. The paper states that source code was available for **120,365 contracts** out of **368,438 distinct contracts**, that Slither labeling took **13.6 days** on one core with **16 GB**, and that DLVA learns **29 vulnerabilities** for long contracts and **21** for shorter ones from Slither-generated labels [2304.10726]. DLVA predicts Slither’s labels with **92.7%** overall accuracy, **91.4%** true positive rate, and **7.2%** false positive rate, while also exposing label contradictions and estimating that Slither mislabels approximately **1.25%** of contracts [2304.10726].

In LLM-centered security evaluation, Slither is frequently used as an external non-LLM validator. SmartEval, a benchmark for LLM-generated smart contracts, uses Slither before and after refinement as an independent static-analysis check rather than as part of the main five-dimensional rubric [2605.09610]. The paper reports a compilation rate increase from **78.1%** to **82.3%**, a drop in average Slither issues per contract from **6.4** to **3.6**, a **43.8%** total issue reduction, and a category agreement rate of **79.4%** between the LLM auditor and Slither [2605.09610]. The paper explicitly cautions that Slither detects statically detectable patterns rather than execution-path bugs and does not verify semantic correctness [2605.09610].

Another LLM-integrated pipeline uses custom Slither-based preprocessing to extract structured facts and prerequisite patterns, then asks an LLM to generate Forge or Kontrol tests, which are executed to validate or refute suspected defects [2509.13023]. In that pipeline, Slither is not the final decision-maker; it serves as the front-end static analysis and contract-preprocessing stage [2509.13023]. The authors use it, for example, to locate external calls followed by state-modifying instructions in reentrancy analysis, then show via execution that a static warning may be a false positive when `transfer()` forwards only **2300 gas** [2509.13023]. This suggests a methodological division of labor in which Slither supplies cheap structural triage, while symbolic or concrete execution settles exploitability.

In a case study on compositional generalization for LLMs on reentrancy detection, Slither is used both to verify synthetic Solidity programs and to extract structural information from the control flow graph and data flow graph for the four atomic tasks of external-call identification, state-update identification, dependency identification, and ordering determination [2601.06914]. That work reports **98.2%** accuracy for its fused model and **87.10%** recall on **31** real vulnerable contracts, compared with **63.33%** recall for Slither on that benchmark [2601.06914]. Here Slither again functions less as an endpoint tool than as a structural oracle.

## 6. Other scholarly uses of “Slither”

Outside smart-contract analysis, “Slither” is also the name of a connection game studied in combinatorial game theory. On an $n \times n$ rectangular grid, Black attempts to connect the first and last columns, while White attempts to connect the first and last rows [1605.04715]. Stones are never captured or removed, but a move may include relocating an existing stone of the moving player before placing a new stone, and positions must respect a diagonal rule forbidding certain diagonal configurations of same-colored stones [1605.04715]. The principal complexity result is that deciding which player has a winning strategy from an arbitrary Slither position is PSPACE-complete [1605.04715]. The proof proceeds by showing membership in PSPACE and a reduction from Hex via cell gadgets that simulate empty, black, and white Hex cells [1605.04715]. The paper also notes that Slither differs from many connection games because movement of existing stones introduces zugzwang phenomena [1605.04715].

In robotics, “slithering” denotes a periodic, snake-inspired motion with variable frequency and amplitude and slowly changing heading direction, imposed deliberately on a mobile robot to improve pure inertial positioning [2411.17430]. In the MoRPINet framework, this motion enriches accelerometer and gyroscope signals, increasing their informativeness for a neural distance regressor called D-Net [2411.17430]. The system combines D-Net, a Madgwick filter for heading estimation, and dead reckoning, updating position via
$$
x_{k+1} = x_k + s_{Dnet,k}\cos \overline{\psi}_k
$$
and
$$
y_{k+1} = y_k + s_{Dnet,k}\sin \overline{\psi}_k
$$
where $s_{Dnet,k}$ is the distance predicted by D-Net and $\overline{\psi}_k$ is the average heading [2411.17430]. On **290 minutes** of inertial recordings, the authors report **30% improvement** in PRMSE and **33% improvement** in PMAE over MoRPI, with MoRPINet updating at **5 Hz**, about **20× faster** than MoRPI [2411.17430].

In mobile security, Slither is one of four games—alongside PUBG, Diep.io, and Minecraft—used to collect touch-dynamics data from **40 unique participants** on an **LG V30+** in landscape orientation [2305.09482]. Each participant played each game for **10 minutes**, with the games selected because they require simultaneous use of two fingers, generate substantial finger movement, and support multi-finger touch dynamics [2305.09482]. Raw touch streams contained **8 fields**, were grouped into sets of **10 touch/sliding events**, and yielded **44 total features** derived from **11** kinematic and touch features such as speed, acceleration, jerk, path tangent, angular velocity, Touch Major, and Touch Minor [2305.09482]. The study does not report Slither-only performance, but Slither contributes to the unified dataset used to train Neural Network, XGBoost, and SVC classifiers for continuous authentication [2305.09482].

These alternate usages are terminologically important because they show that “Slither” is not a domain-unique label. In contemporary arXiv literature, however, the smart-contract framework remains the most extensive and methodologically consequential referent [1908.09878].

## 7. Significance, limitations, and research trajectory

Across the surveyed literature, Slither’s significance lies in three properties that recur with unusual consistency. First, it is fast and robust enough to serve as a practical baseline in large-scale comparative studies [1908.09878][2504.04685]. Second, its SlithIR-plus-SSA design exposes enough semantic structure to make it a convenient substrate for interval analysis, proxy detection, mutation-based validation, and graph-informed learning pipelines [2309.13805][2410.23766][2304.03405][2601.06914]. Third, it is sufficiently standardized and widely used that papers treat its outputs as reference labels, external validators, or first-pass alarms even when the principal contribution lies elsewhere [2304.10726][2605.09610][2509.13023].

The main limitations identified in the literature are also consistent. Slither is vulnerable to false positives when rules are too coarse or context is not modeled adequately, as emphasized in Vulpedia and SolidiFI [1912.04466][2005.11613]. It can miss vulnerabilities expressed through indirect syntax, transformations, modifiers, inheritance, or semantically equivalent control-flow rewrites [2410.21685][2504.15948]. It detects statically visible patterns rather than full execution-path semantics, so later work often combines it with symbolic execution, concrete execution, SMT solving, or human review [2509.13023][2605.09610]. This suggests that Slither is best understood not as a complete verifier but as a high-leverage static-analysis core around which richer auditing workflows can be organized.

A broader historical pattern is that Slither has shifted from being evaluated chiefly as a detector to being reused as infrastructure. Early work centers on its speed, robustness, and detector balance [1908.09878]. Later work increasingly treats it as an analyzable, extensible framework whose IR, CFGs, def-use relations, and detector ecosystem can seed datasets, guide LLMs, support abstract interpretation, or anchor hybrid pipelines [2309.13805][2410.23766][2304.03405][2601.06914][2509.13023]. A plausible implication is that Slither’s long-term importance may derive as much from its role as a research platform as from the individual detectors bundled with it.

Source: https://www.emergentmind.com/topics/slither