Slither: Smart Contract Analysis Framework

• Slither is a static analysis framework for Ethereum smart contracts that converts Solidity code into an intermediate representation (SlithIR) to support vulnerability detection, code optimization, and review assistance.
• Benchmark studies reveal Slither’s fast performance with low false positive rates on canonical issues like reentrancy, though it may miss vulnerabilities under complex syntactic transformations.
• Beyond scanning, Slither serves as a versatile infrastructure for extensions such as interval analysis, proxy detection, and integration in machine-learning and LLM-based auditing workflows.

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 (Feist et al., 2019). In other contexts, “Slither” refers to a two-player connection game whose arbitrary-position outcome problem is PSPACE-complete (Bonnet et al., 2016), to a snake-inspired serpentine motion imposed on a mobile robot to enrich inertial measurements for positioning (Etzion et al., 2024), and to one of the mobile games used in touch-dynamics continuous-authentication experiments (Pelto et al., 2023). 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 (Feist et al., 2019).

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 (Feist et al., 2019). 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 (Feist et al., 2019).

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 (Feist et al., 2019). 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 (Feist et al., 2019). 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 (Feist et al., 2019). The open-source version includes more than twenty bug detectors, including shadowing, uninitialized variables, reentrancy, suicidal contracts, locked ether, and arbitrary ether sending (Feist et al., 2019). It also includes “printers” that generate inheritance graphs, CFGs, call graphs, contract summaries, authorization summaries, and complexity summaries (Feist et al., 2019). 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 (Feist et al., 2019). 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% (Feist et al., 2019). The same paper states that Slither was the fastest tool overall and “typically as fast as a simple linter” (Feist et al., 2019).

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 (Ghaleb et al., 2020). 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 (Ghaleb et al., 2020). 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 (Ghaleb et al., 2020).

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 (Zhang et al., 2020). 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 (Zhang et al., 2020). 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 (Ince et al., 7 Apr 2025). 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 (Ince et al., 7 Apr 2025). Its mean runtime is reported as 0.57 s, compared with 430.25 s for Mythril (Ince et al., 7 Apr 2025).

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 (Manh et al., 2024). 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}$ (Manh et al., 2024). 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 (Manh et al., 2024).

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 (Iuliano et al., 22 Apr 2025). The study generates 350,493 mutants from 47,398 original contracts and reports that Slither successfully analyzed 335,234 mutants after excluding execution failures (Iuliano et al., 22 Apr 2025). 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) (Iuliano et al., 22 Apr 2025). The paper attributes many misses to strong dependence on syntactic form, modifiers, inheritance, and complex boolean structure (Iuliano et al., 22 Apr 2025).

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 (Manh et al., 2024, Iuliano et al., 22 Apr 2025). 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 (Susan et al., 2023). 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 (Susan et al., 2023). Slither alone, in that study, is said to detect uninitialized variables and trivial tautologies/contradictions in assert/require, but to miss the other examples (Susan et al., 2023).

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 (Susan, 2024). 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 (Susan, 2024). 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 (Susan, 2024). 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 (Susan, 2024).

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 (Meisami et al., 2023). 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 (Meisami et al., 2023). 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 (Meisami et al., 2023). The result is an elimination of approximately 70 percent of the contracts initially flagged as upgradeable proxies as false positives (Meisami et al., 2023).

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 (Susan et al., 2023, Susan, 2024, Meisami et al., 2023).

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 (Abdelaziz et al., 2023). 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 (Abdelaziz et al., 2023). 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 (Abdelaziz et al., 2023).

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 (Goel et al., 10 May 2026). 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 (Goel et al., 10 May 2026). The paper explicitly cautions that Slither detects statically detectable patterns rather than execution-path bugs and does not verify semantic correctness (Goel et al., 10 May 2026).

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 (Susan et al., 16 Sep 2025). In that pipeline, Slither is not the final decision-maker; it serves as the front-end static analysis and contract-preprocessing stage (Susan et al., 16 Sep 2025). 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 (Susan et al., 16 Sep 2025). 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 (Zhou et al., 11 Jan 2026). 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 (Zhou et al., 11 Jan 2026). 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 (Bonnet et al., 2016). 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 (Bonnet et al., 2016). The principal complexity result is that deciding which player has a winning strategy from an arbitrary Slither position is PSPACE-complete (Bonnet et al., 2016). The proof proceeds by showing membership in PSPACE and a reduction from Hex via cell gadgets that simulate empty, black, and white Hex cells (Bonnet et al., 2016). The paper also notes that Slither differs from many connection games because movement of existing stones introduces zugzwang phenomena (Bonnet et al., 2016).

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 (Etzion et al., 2024). In the MoRPINet framework, this motion enriches accelerometer and gyroscope signals, increasing their informativeness for a neural distance regressor called D-Net (Etzion et al., 2024). 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 (Etzion et al., 2024). 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 (Etzion et al., 2024).

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 (Pelto et al., 2023). 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 (Pelto et al., 2023). 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 (Pelto et al., 2023). 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 (Pelto et al., 2023).

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 (Feist et al., 2019).

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 (Feist et al., 2019, Ince et al., 7 Apr 2025). 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 (Susan et al., 2023, Susan, 2024, Meisami et al., 2023, Zhou et al., 11 Jan 2026). 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 (Abdelaziz et al., 2023, Goel et al., 10 May 2026, Susan et al., 16 Sep 2025).

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 (Ye et al., 2019, Ghaleb et al., 2020). It can miss vulnerabilities expressed through indirect syntax, transformations, modifiers, inheritance, or semantically equivalent control-flow rewrites (Manh et al., 2024, Iuliano et al., 22 Apr 2025). 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 (Susan et al., 16 Sep 2025, Goel et al., 10 May 2026). 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 (Feist et al., 2019). 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 (Susan et al., 2023, Susan, 2024, Meisami et al., 2023, Zhou et al., 11 Jan 2026, Susan et al., 16 Sep 2025). 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.