LightCross: A Lightweight Smart Contract Vulnerability Detection Tool

Abstract

Blockchain and smart contracts have transformed industries by automating complex processes and transactions. However, this innovation has introduced significant security concerns, potentially leading to loss of financial assets and data integrity. The focus of this research is to address these challenges by developing a tool that can enable developers and testers to detect vulnerabilities in smart contracts in an efficient and reliable way. The research contributions include an analysis of existing literature on smart contract security, along with the design and implementation of a lightweight vulnerability detection tool called LightCross. This tool runs two well-known detectors, Slither and Mythril, to analyse smart contracts. Experimental analysis was conducted using the SmartBugs curated dataset, which contains 143 vulnerable smart contracts with a total of 206 vulnerabilities. The results showed that LightCross achieves the same detection rate as SmartBugs when using the same backend detectors (Slither and Mythril) while eliminating SmartBugs’ need for a separate Docker container for each detector. Mythril detects 53% and Slither 48% of the vulnerabilities in the SmartBugs curated dataset. Furthermore, an assessment of the execution time across various vulnerability categories revealed that LightCross performs comparably to SmartBugs when using the Mythril detector, while LightCross is significantly faster when using the Slither detector. Finally, to enhance user-friendliness and relevance, LightCross presents the verification results based on OpenSCV, a state-of-the-art academic classification of smart contract vulnerabilities, aligned with the industry-standard CWE and offering improvements over the unmaintained SWC taxonomy.

1. Introduction

Blockchain technology has enabled digital transformation by fostering trust through transparency in transactions and supporting the rise of decentralised applications. Smart contracts [1], deployed on blockchain networks, are self-executing programmable agreements designed to automate processes by fulfilling predefined conditions. Widely applicable across various industry sectors, from finance to supply chain management, smart contracts have become an essential component of decentralised systems.

However, their growing adoption introduces new attack vectors due to inherent design vulnerabilities. Similarly to other established blockchain applications, including Bitcoin (e.g., [2,3,4]), smart contracts are not immune to security flaws. Exploiting these vulnerabilities can enable various types of cyber attack. For example, Denial of Service (DoS) attacks can occur through loop code manipulation [5], while timestamp dependence vulnerabilities allow malicious miners to manipulate block timestamps to interfere with critical operations [6].

The Reentrancy vulnerability led to the Decentralized Autonomous Organisation (DAO) attack [7] in 2016, where $60 million worth of Ether was stolen by recursively withdrawing funds before the contract’s balance could be updated. Access control vulnerabilities were exposed in the Parity multisig wallet attack [8] of 2017, resulting in a loss of more than $150 million due to improper initialisation of wallet ownership. Similarly, integer overflow/underflow issues allowed the BatchOverflow exploit [9] in 2018, which was used to manipulate token balances, threatening the integrity of several ERC-20 Ethereum tokens. This demonstrates the severe financial and operational risks associated with flawed smart contract implementations.

Reentrancy vulnerabilities occur when a contract makes an external call to another contract before updating its own state, allowing an attacker to repeatedly call the function and drain funds. Access control vulnerabilities arise when the permissions governing who can execute critical functions are improperly defined or misconfigured, enabling unauthorised access. Integer overflow/underflow happens when arithmetic operations exceed or drop below the range of representable numbers, leading to incorrect contract behaviour or manipulation of balances.

As traditional code audits and manual inspections are often inadequate for identifying vulnerabilities in complex smart contracts [10], there is a need for lightweight and automated solutions to effectively detect and mitigate vulnerabilities in smart contracts [11].

1.1. Research Contributions

In this paper, we present LightCross, a lightweight vulnerability detection tool that integrates Mythril and Slither tools. To achieve vulnerability detection while maintaining practical performance, LightCross integrates two complementary analysis tools: Slither for fast static analysis and broad vulnerability coverage, and Mythril for symbolic execution to catch complex logic flaws. This combination addresses the trade-off between analysis speed and detection accuracy in smart contract security tools.

LightCross does not require a container infrastructure such as Docker version 4.44.3. The only main requirement is support for Python 3. We perform an experimental and comparative analysis of LightCross in relation to SmartBugs [12]. LightCross vulnerability detection performs similarly to SmartBugs and requires fewer dependencies than SmartBugs. LightCross does not require Docker or any other container configuration and orchestration. The main contributions of our research are:

• The design and development of LightCross, a lightweight vulnerability detection tool for smart contracts that improves the security of smart contracts (Section 3).
• Composition of Mythril and Slither to provide a unified vulnerability detection tool for smart contracts without depending on a Docker container infrastructure (Section 3).
• Presentation of verification results according to OpenSCV [13], an academic state-of-the-art smart contract vulnerabilities classification aligned with the industry-standard CWE [14], which improves upon the established but unmaintained SWC [15] classification.
• An experimental evaluation of LightCross in relation to SmartBugs tool version 2.0.14 (Section 4) demonstrating the effectiveness of a lightweight approach.

1.2. Research Methodology

The four-step research methodology for the study consists of:

• Literature Review: In Section 2, we review related work on smart contract vulnerability analysis and classification. We discuss well-known vulnerabilities in smart contracts, their classification, and detection tools.
• System Design: In Section 3, we present the LightCross design as a modular system to import smart contracts, processing them in parallel with the back-end tools, and aggregating the results into a CSV file.
• Implementation: Also described in Section 3, we discuss the Python implementation of the tool, the functionalities of each program and the integration of the backend tools.
• Evaluation: We provide a performance evaluation of the proposed LightCross tool in Section 4 where we use a SmartBugs curated dataset [16] to assess the vulnerability detection rate of LightCross. We measure against the metrics of True Positive (TP), False Positive (FP), False Negative (FN), Recall, Precision, and F1 score. We then performed a comparative analysis to the independent execution of Slither, Mythril, and SmartBugs.

2. Background

Blockchain technology, originally created as a distributed ledger for cryptocurrencies, has evolved to encompass a wide range of applications beyond digital currency transactions [17]. The technology’s key features, immutability, decentralisation, and transparency, have made it an attractive choice for various sectors seeking to enhance trust and security in digital interactions.

The concept of smart contracts gained prominence with the launch of Ethereum in 2015, which fundamentally changed the landscape of digital agreements [18]. Ethereum’s smart contract platform enables the execution of self-enforcing agreements in a decentralised manner. As a result, smart contracts have become a fundamental component of blockchain ecosystems, enabling a wide range of applications, including decentralised finance (DeFi), supply chain management, digital identity verification, and gaming platforms.

2.1. Security Vulnerabilities in Smart Contracts

While smart contracts may exhibit vulnerabilities similar to those found in traditional software, such as integer overflows, they also introduce blockchain-specific risks [19]. The security of a smart contract is significantly influenced by the robustness of its programming language [20,21], and as emphasised by Sirer [22], smart contracts should be developed with the same rigour as code for critical systems.

We discuss vulnerability classification in detail in Section 2.2, but it should be noted that various definitions exist for certain blockchain-specific vulnerabilities. For instance, what Atzei et al. [7] refers to as unpredictable state is known as Transaction Order Dependency (TOD) by other authors [23]. Similarly, the vulnerability commonly termed reentrancy in some publications (e.g., [24]) is also described as Effectively Callback-Free Objects.

Atzei et al. [7] propose a taxonomy of smart contract vulnerabilities, providing a comprehensive framework for vulnerability analysis.

Well-known vulnerabilities specific to smart contracts are described below:

• Reentrancy: The reentrancy vulnerability occurs when a contract allows external calls to untrusted contracts before updating its internal state. This allows an attacker to repeatedly call a vulnerable function and drain funds by taking advantage of the contract’s unprotected state. For example, a malicious user could exploit contract (A) to recursively call the withdraw function of contract (B) before the contract’s state is updated. This can potentially lead to unexpected behaviour and exploitation of the smart contract’s logic [25,26].
• Access Control: Inadequate access control mechanisms can allow unauthorised users or contracts to access sensitive smart contract’s functions or data [27]. Proper management of permissions is crucial for preventing unauthorised access. For instance, the smart contract should always verify the user’s permissions before executing the withdrawal function. In the context of Ethereum, the Solidity programming language offers access modifiers. Additionally, developers can add require statements embedded inside functions, where the transaction is rolled back if the condition of the require statement is not fulfilled.
• Integer Overflow/Underflow: Integer overflow/underflow vulnerabilities occur when a computed value exceeds the maximum representable size or falls below the minimum representable size for a particular data type. In Solidity, an unsigned integer is defined as uint256 [28], which is limited to 256 bits in size. This translates to integers between 0 and $(2^{256}-1)$. These vulnerabilities can lead to unintended consequences, including loss of funds, unauthorised access, or DoS attacks [29]. However, since Solidity 0.8.0, these operations are automatically checked, and overflows/underflows cause the transaction to revert.
• Timestamp Dependency: This vulnerability affects smart contracts, particularly on the Ethereum blockchain. It is closely related to the “Unpredictable State” category and pertains to the dependence of a contract’s behaviour on the current block’s timestamp. The block timestamp is a dynamic value that can be manipulated, potentially leading to security issues [30]. Smart contracts may rely on the block timestamp for various purposes, such as time-based triggers or access control. However, malicious miners in proof-of-work or validators in proof-of-stake systems could manipulate the timestamp to gain an advantage or exploit certain time-dependent functions, leading to unpredictable behaviour or vulnerabilities [8].
• Authorisation through tx.origin: In Solidity, there exists a global variable known as tx.origin, which provides the address of the sender of a transaction. Utilising this variable for authorisation purposes can potentially introduce vulnerabilities to a contract [29]. This vulnerability arises when an authorised account interacts with a malicious contract, potentially passing the authorisation check because tx.origin reveals the original sender of the transaction [31]. To mitigate this risk, it is recommended to use “msg.sender” for authorisation purposes.
• Frozen Ether/Token: The Frozen Ether/Token vulnerability occurs when funds become inaccessible or “frozen” due to a flaw in the contract’s code. This can happen if certain conditions are not properly handled, allowing an attacker to lock up funds indefinitely. This vulnerability is frequently caused by dependency on external contract libraries. Core functionalities may be compromised if an external library is updated or terminated. This flaw resulted in the aforementioned Parity multi-signature wallet bug [19].
• Transaction Ordering Dependency (TOD): This vulnerability is a critical security concern in smart contracts, highlighting the potential risks associated with decision-making based on evolving information. In a TOD vulnerability scenario, the outcome of a smart contract function or transaction is influenced by external factors that change between the contract’s initiation and execution phases [23]. This time gap creates a window of opportunity for malicious actors to exploit discrepancies, leading to unexpected and potentially harmful results.

2.2. Smart Contract Vulnerabilities Classification

Smart contract vulnerability taxonomies are standardised classifications for identifying and categorising security flaws, enabling consistent communication among developers, auditors, and researchers. Furthermore, they facilitate the evaluation of the capabilities of detection tools and support the development of guidelines for secure development practices and programming language design [23,32].

Vidal et al. [13] present a comprehensive review of both community-driven and academic taxonomies. Ruggiero et al. [33] propose a unified data model that formalises key entities and relationships in smart contract vulnerability taxonomies. In this work, we focus on the most relevant classifications, both in general and in relation to our research contribution.

Early efforts to classify vulnerabilities in smart contracts emerged from industry and community initiatives. The Smart Contract Weakness Classification (SWC) [15] provides a structured taxonomy that categorises smart contract vulnerabilities along with descriptions and test cases. This framework has been extensively integrated into security tools (Mythril and Slither, among others) and auditing processes, ensuring consistent vulnerability identification. A notable feature is its mapping of the 37 SWC vulnerabilities to the Common Weakness Enumeration (CWE) [14], an established software security classification system.

The Decentralised Application Security Project (DASP) [34] focuses on the “Top 10” smart contract vulnerabilities, including real-world attack examples and impact assessments. However, it covers only nine vulnerabilities. Both DASP and SWC have remained outdated and unmaintained since 2018.

Academic research (e.g., [7,29]) has since advanced the field through fine-grained and more up-to-date classifications.

Rameder et al. [23] present a taxonomy derived from a Systematic Literature Review (SLR), offering comprehensive vulnerability categorisation that synthesises findings from academic papers and technical reports. Their framework groups 54 vulnerabilities into 10 categories, incorporating vulnerabilities identified by various detection tools.

OpenSCV [13], the open taxonomy for Smart Contract Vulnerabilities, adopts a hierarchical structure organised across three levels:

• High-level categories (e.g., Unsafe External Calls)
• Vulnerability groups (e.g., Reentrancy)
• Individual vulnerabilities (e.g., Unsafe Credit Transfer)

With coverage of 94 vulnerabilities, it represents one of the most comprehensive and current classifications. OpenSCV establishes mappings to the DASP, SWC, Rameder et al. taxonomy, CWE, and IBM’s Orthogonal Defect Classification (ODC) for Software Design and Code [35]. The classification has been validated through expert questionnaires and is open to community contributions.

However, as noted in [23], mapping vulnerabilities across different classifications presents challenges. For example, DASP appears too coarse with only 10 categories, while standards such as SWC lack coverage of the categories present in newer classifications (e.g., [13,23]). Specifically, Rameder et al. [23] successfully map only 22 SWC categories within their framework.

Table 1. Comparison of Main Smart Contract Vulnerability Taxonomies (L1 = Level 1 categories).

Taxonomy	Vuln	L1 Cats	Levels	Updated	Notes
SWC [15]	37	–	–	2018	Industry, CWE-aligned
DASP [34]	9	–	–	2018	Industry
Rameder et al. [23]	54	10	2	2022	Academic
OpenSCV [13]	94	8	3	2024	Academic, CWE-aligned

presents a comparison of the main smart contract vulnerability taxonomies, while

Table 2. Smart Contract Vulnerability Taxonomies Repositories.

Taxonomy	URL (Accessed on 21 August 2025)
SWC [15]	https://swcregistry.io/
DASP [34]	https://dasp.co/
Rameder et al. [23]	https://www.frontiersin.org/articles/10.3389/fbloc.2022.814977/full#supplementary-material
OpenSCV [13]	https://openscv.dei.uc.pt/

lists their repositories.

Table 3. Examples of Mapping from SWC to OpenSCV (L2/L3 = Level 2/Level 3 categories).

SWC ID	SWC Description	OpenSCV Category (L2)	OpenSCV Category (L3)
SWC-101	Integer Overflow and Underflow	7.1 Overflow and Underflow 7.2 Division Bugs 7.3 Conversion Bugs	7.1.1 Integer Underflow 7.1.2 Integer Overflow 7.2.1 Divide by Zero 7.2.2 Integer Division 7.3.1 Truncation Bugs 7.3.2 Signedness Bugs
SWC-114	Transaction Order Dependence	6.1 Incorrect Sequencing of Behaviour	6.1.2 Incorrect Function Call Order 6.1.4 Transfer Pre-Condition Dependent on Transaction Order 6.1.5 Transfer Amount Depending on Transaction Order 6.1.6 Transfer Recipient Depending on Transaction Order
SWC-116	Block values as a proxy for time	6.1 Incorrect Sequencing of Behaviour	6.1.1 Incorrect Use of Event Blockchain Variables for Time
SWC-132	Unexpected Ether balance	6.1 Incorrect Sequencing of Behaviour	6.1.3 Improper Locking
–	–	6.1 Incorrect Sequencing of Behaviour	6.1.7 Exposed State Variables 6.1.8 Wrong Transaction Definition

presents examples illustrating how OpenSCV achieves greater granularity and precision than SWC. For example, SWC-101 aggregates a variety of arithmetic faults under a single identifier, whereas OpenSCV decomposes these into a structured hierarchy of six distinct vulnerabilities across overflow, division, and conversion categories. In the 6 Incorrect Control Flow category, OpenSCV distinguishes multiple vulnerabilities that SWC either groups together (e.g., four different transaction-order related defects all mapped to SWC-114) or omits entirely (e.g., 6.1.7 Exposed State Variables and 6.1.8 Wrong Transaction Definition have no SWC equivalent). This finer granularity reduces ambiguity, supports more precise remediation guidance, and aligns more clearly with CWE, while preserving backward compatibility via SWC mappings.

In summary, OpenSCV currently stands as the most current and fine-grained classification scheme, offering hierarchical organisation while maintaining cross-domain compatibility with CWE. However, SWC retains relevance as many tools continue to classify findings according to this established framework.

For this reason, for our LightCross tool, we adopted the OpenSCV classification and its associated vulnerability mappings while retaining SWC as a reference, since back-end tools such as Mythril can provide outputs tagged with SWC codes. For Slither, we map the detectors to SWC codes.

Finally, it is worth mentioning that the OWASP Smart Contract Security Verification Standard (SCSVS) [36] is currently under development. As of the time of writing, version 0.0.1 is the only one publicly available. This OWASP initiative outlines security requirements for smart contracts, particularly those written in Solidity for EVM-based blockchains, and aims to guide the verification of secure smart contracts and decentralised applications. Complementing SCSVS, the OWASP Smart Contract Weakness Enumeration (SCWE) [37] catalogues 84 common security and privacy weaknesses specific to smart contracts, and their corresponding CWEs.

2.3. Vulnerability Detection Tools & Related Works

Several studies have evaluated and compared existing tools for smart contract vulnerability detection, considering factors such as the types of vulnerability detected, the accuracy of detection, and the efficiency of the tools. For example, studies by Fontein [38] and Gupta et al. [39] compared several widely used tools using a benchmark dataset of vulnerable smart contracts.

Table 4. Smart contract vulnerability tool detection capabilities.

Vulnerabilities Tools	Reentrancy	Access Control	Timestamp dep.	tx.origin	Frozen Ether	Over/Underflow	TODs
Manticore	✓	×	×	✓	×	✓✓	×
Mythril	✓✓	×	✓	✓	×	✓✓	✓
MythX	✓✓	✓	✓	✓✓	×	✓✓	✓
Oyente	✓	×	✓	×	×	✓	✓
Securify	✓✓	✓✓	✓	×	✓	✓✓	✓
Slither	✓✓	✓✓	✓✓	✓✓	✓	✓✓	✓

✓✓ = Detection, ✓ = Partial detection, × = No detection.

illustrates the ability of the tools listed below to detect the vulnerabilities considered in Section 2.1. Such capabilities vary depending on tool versions, configurations, and contract complexity, and in general, reflect theoretical capacities under idealised conditions (e.g., isolated contract analysis).

• Manticore uses symbolic execution techniques. Mossberg et al. [40] described Manticore’s capabilities in analysing smart contracts through symbolic execution. This tool enables the identification of vulnerabilities that may manifest under specific input conditions. While it can be used alongside static analysis tools, Manticore’s symbolic execution approach provides a distinct method of analysis that can uncover complex, state-dependent vulnerabilities.
• Mythril uses symbolic execution to examine smart contracts. Bonomi et al. [41] assessed Mythril’s vulnerability detection capabilities by applying it to actual smart contracts sourced from Code4arena competitions and comparing the results with official security audits conducted during those events. Their study identifies potential inefficiencies in the tool, suggesting directions for the development of more scalable and effective methods for testing smart contracts.
• MythX is notable for its integration with popular smart contract development environments, providing real-time feedback to developers [42]. Seamless integration improves the overall development experience by identifying vulnerabilities in the initial stages [28].
• Oyente uses a static analysis approach for anomaly detection. Gupta et al. [39] highlighted the importance of Oyente in identifying vulnerabilities by analysing the bytecode of smart contracts, in particular in terms of the detection of potential security flaws during the contract development phase.
• Securify takes a formal verification approach to smart contract security. Tsankov et al. [43] explored the application of Securify to ensure security assurance through mathematical proofs. This tool adds an extra layer of assurance by formally verifying that smart contracts adhere to predefined security specifications [31].
• Slither is a free open source tool to inspect the Solidity code and identify potential problems. Released in 2018, it is developed in Python, using a unique intermediate representation known as SlithIR. Slither finds vulnerabilities using a combination of data flow analysis and tracking approaches. It detects a wide range of vulnerabilities, including reentrancy, frozen ether, and integer overflows, with high accuracy [44]. Its comprehensive coverage makes it one of the most robust tools for smart contract security.

A notable tool is SmartBugs [12] supporting 20 tools to analyse Solidity source code, deployment bytecode, and runtime code. SmartBugs optimises resource usage through parallel and randomised task execution. It maintains a standardised output format across tools, with scripts for parsing and normalising results. However, SmartBugs’ reliance on container infrastructure poses challenges when analysing smart contracts without container support.

Ressi et al. [45] conducted a qualitative analysis of machine learning-based vulnerability detection in Ethereum smart contracts. The study categorises existing tools, highlights limitations like restricted vulnerability coverage and dataset flaws, and introduces new metrics to compare solutions.

3. System Design and Implementation

This section introduces the LightCross tool. Figure 1 provides an overview of the five main modules and the workflow of the tool. The workflow begins with smart contracts under test being processed through an import procedure, which feeds them into a subprocess orchestrator. This orchestrator distributes the smart contract code to multiple back-end detector tools, specifically Mythril and Slither, which perform a parallel vulnerability scan using different detection techniques. The detection results are then sent to the results aggregator that consolidates the findings. The consolidated results are subjected to vulnerability classification, which leverages standardised vulnerability mappings (including SWC, OpenSCV, CWE, DASP, and Rameder taxonomies) to categorise detected issues according to established security frameworks. Finally, a reporter component transforms these classified vulnerabilities into a structured CSV report, providing an overview of security issues identified in smart contracts. This architecture enables efficient multi-tool analysis while standardising vulnerability reporting across different detection engines.

3.1. Importer

In this module, we analyse the inputs from the command line to check if they are either folders that include smart contracts or a single smart contract file. LightCross supports running both Mythril and Slither or one of them. After creating a list of smart contract folders for evaluation, the importer module creates a list of files and passes the information to the next module.

3.2. Subprocess Orchestrator

This module takes as input the list of files and the selected tools. For each smart contract file, LightCross creates a subprocess for each detector specified as parameters. For instance, if both detectors are selected, then Slither will first evaluate the smart contract, and then Mythril will analyse the file as well. We chose to always start with Slither as it takes less time to finish than Mythril. Running Slither usually takes one or two seconds. We iterate over all the files and create subprocesses for the detectors. Each of the created subprocesses receives as input the path of the smart contract and configuration specific to each detector. The output of each subprocess is a report which is then fed to the analysis tools module.

3.3. Analysis Tools and Aggregator

We parse each report to extract the data for the vulnerability analysis. For Slither, we employ a regular expression to capture the summary and the issues reported. For each issue, we then extract the name of the issue, the impact, and confidence. We also mapped the issue names emitted by Slither to a corresponding SWC ID. For example, when Slither outputs in the report arbitrary-send-eth we map it to SWC-105 which means Unprotected Ether Withdrawal. Mythril directly includes the SWC ID, such as Unprotected_Ether_Withdrawal_SWC_105, in its report, which we can parse to extract the SWC ID. The report resulting from Mythril is parsed extracting the following data: title, details, SWC ID, severity contract, function name, pc address, gas usage, file path, and description. In addition, the analysis time for the smart contract is added. All extracted data from Slither and Mythril are sent to the Results Aggregator.

The Results Aggregator module collates all the data for all smart contracts for both Slither and Mythril. We integrate all results into one dataset with a standardised format, which is passed to the next module for classification.

3.4. Vulnerability Classification and Reporting

Classifying vulnerabilities starts with SWC IDs for Mythril and heuristically assigning the output detectors to SWC IDs. Initially, we import the baseline data for the SmartBugs curated dataset [16] to assess whether the detectors have accurately identified the vulnerabilities. The next step is to map the SWC ID to the DASP categories. Although the DASP classification is coarse, vulnerabilities in the baseline data are specified using DASP. We utilise the OpenScvVulnerabilityMapper component to map the vulnerability to the OpenSCV classification. We initialise the OpenSCV dataset that includes a mapping of the OpenSCV classification entries to SWC IDs. An SWC ID can be assigned to one or more OpenSCV classification entries. For example, the SWC ID 101 corresponds to multiple vulnerabilities such as integer underflow/overflow, divide by zero, integer division truncation bugs, and signedness bugs. In order to determine the accurate OpenSCV entry corresponding to the vulnerability, we use keyword-based matching analysing the vulnerability descriptions and synonyms that are included in the OpenSCV dataset. In the following, we outline the procedure for mapping the vulnerabilities (Figure 2):

• The OpenScvVulnerabilityMapper component initialises by loading vulnerability CSV files and the OpenSCV database file, validating their existence and accessibility.
• Processes these inputs by merging vulnerability files and preparing the OpenSCV data for efficient lookup.
• Establishes mapping rules based on SWC-IDs and relevant keywords extracted from vulnerability descriptions and synonyms.
• For each vulnerability entry, a two-tier analysis approach is applied: first, attempting direct matching via SWC-ID fields, if present. If it is unsuccessful, we employ keyword matching with a scoring system to determine the corresponding OpenSCV classification entry if there is more than one candidate.
• Once mapped, it retrieves the corresponding detailed entries from the OpenSCV classification.
• Exports results into CSV, JSON files and generates visualisation plots for analysis, creating a complete audit trail.

Table 5. Smart Contract Vulnerability Mapping from SWC to OpenSCV-Representative Vulnerabilities.

Tool	Contract	Vulnerability	Severity	SWC-ID	OpenSCV Index	Defect Type
Mythril	SmartBillions	Dependence on predictable environment variable	High	SWC-120	5.1 Bad Randomness	Algorithm/Method
Slither	LuckyDoubler	weak-prng	High	SWC-120	5.1 Bad Randomness	Algorithm/Method
Mythril	PredictTheBlockHashChallenge	Unprotected Ether Withdrawal	High	SWC-105	4.2 Unprotected Transfer Value	Checking
Slither	RandomNumberGenerator	weak-prng	High	SWC-120	5.1 Bad Randomness	Algorithm/Method
Slither	GuessTheRandomNumberChallenge	arbitrary-send-eth	High	SWC-105	4.2 Unprotected Transfer Value	Checking
slither	BlackJack	controlled-array-length	High	SWC-128	2.1.2 Improper Exception Handling in a Loop	Algorithm/Method

provides a representative example of the result of the mapping from SWC to OpenSCV. After classifying the vulnerabilities, the reporter module computes the metrics to assess if the detectors have accurately reported the vulnerabilities according to the baseline data. In addition, this module plots the result dataset according to the DASP category and computed metrics such as recall, precision, and F1 score.

4. Evaluation

In this section, we first discuss the baseline data set that we used to evaluate the effectiveness of LightCross. We compare the effectiveness of Slither, Mythril, LightCross and SmartBugs. In addition, the execution time for each category of smart contracts is discussed in Section 4.4.

4.1. Metrics for Vulnerability Detection

To assess the performance of vulnerability detection tools, we evaluated their effectiveness using precision, recall, and F1 score metrics. Precision measures the proportion of correctly identified vulnerabilities among all reported by the tool, while recall assesses the proportion of actual vulnerabilities that the tool successfully identifies. These metrics are widely used to assess the accuracy of tools in detecting vulnerabilities (e.g., [46]).

In this context, we define a positive outcome as the presence of a vulnerability and a negative outcome as its absence.

• True Positive (TP): the tool correctly identifies a vulnerability present in the smart contract, matching the vulnerability specified in the baseline dataset.
• False Positive (FP): the tool incorrectly reports a vulnerability in a smart contract that is not the same as the one specified in the baseline dataset.
• False Negative (FN): the tool does not identify a vulnerability in the smart contract while there is one specified in the baseline dataset.
• True Negative (TN): the tool correctly identifies that a smart contract is not vulnerable. The baseline dataset does not include a smart contract that is free of vulnerabilities.

Since true negatives are often not easily measurable in vulnerability datasets, we focus on precision, recall, and the F1 score. We define precision in the context of vulnerability detection as the proportion of positive vulnerability identifications that were actually correct. For example, high precision indicates there are minimal false positives, meaning that when the tool identifies a contract as vulnerable, it is generally accurate. We compute the precision using Equation (1):

$$\begin{array}{cc}\hfill Precision& ={\displaystyle \frac{TP}{TP+FP}}\hfill \end{array}$$

(1)

Recall is the proportion of actual positives that were correctly identified. A high recall indicates a low false-negative rate, meaning the tool identifies most actual vulnerabilities. If we convert the result into a percentage, the result denotes the percentage of all actual vulnerabilities that the tool successfully found. We compute the recall using Equation (2):

$$\begin{array}{cc}\hfill Recall& ={\displaystyle \frac{TP}{TP+FN}}\hfill \end{array}$$

(2)

The F1 score is the harmonic mean of precision and recall. A high F1 score indicates that the vulnerability detection tool is effective in finding vulnerabilities when they exist and in avoiding false alarms in secure smart contracts. We compute the F1 score using Equation (3):

$$\begin{array}{cc}\hfill F1& ={\displaystyle \frac{2\ast TP}{2\ast TP+FP+FN}}\hfill \end{array}$$

(3)

4.2. SmartBugs Curated Dataset

We use the SmartBugs curated dataset to assess the effectiveness of LightCross in detecting vulnerabilities. The first version of the dataset included 69 vulnerable contracts [47]. Each smart contract contains a number of vulnerabilities that are labelled in comments, including the category and location of the vulnerability. The dataset is separated into nine categories according to the DASP taxonomy [34]. The updated version of the curated dataset contains 143 vulnerable smart contracts [16] and this is the version that we use to evaluate LightCross. Each smart contract file includes one or more vulnerabilities, which is annotated as a comment showing the vulnerability category. The total number of vulnerabilities is $N=206$ and the breakdown of the vulnerabilities according to the category is depicted in

Table 6. Number of vulnerabilities, number of contracts, and lines of code (LoC) per category from the SmartBugs curated dataset.

Category	Vulnerabilities	Contracts	LoC
Access Control	21	18	933
Arithmetic	23	15	304
Bad Randomness	30	8	1079
Denial of Service	7	6	177
Front Running	7	4	137
Unknown Unknowns	3	3	116
Reentrancy	32	31	2164
Short Addresses	1	1	18
Time Manipulation	7	5	100
Unchecked Return Values	75	52	4036
Total	206	143	9064

.

4.3. Experimental Results

In this subsection, the results achieved by LightCross for the different types of vulnerabilities are compared against Slither, Mythril, and SmartBugs, which are run independently. The SmartBugs computation is compared with the aforementioned tools and with LightCross. We also execute SmartBugs with all the available tools and determine the best combination of two detectors in terms of vulnerability detection and execution time.

Table 7. Performance Metrics by Vulnerability Category when using LightCross. Category abbreviations: AC = Access Control, AI = Arithmetic Issues, BR = Bad Randomness, DoS = Denial of Service, FR = Front-Running, RE = Reentrancy, SA = Short Addresses, TM = Time Manipulation, URV = Unchecked Return Values, UU = Unknown Unknowns.

	TP		FP		FN		Prec.		Rec.		F1		Samples
Category	M	S	M	S	M	S	M	S	M	S	M	S	M	S
AC	13	7	18	36	4	14	0.42	0.16	0.33	0.21	0.54	0.22	35	57
AI	11	0	7	58	3	23	0.61	0.00	0.79	0.00	0.69	0.00	21	81
BR	3	3	6	10	3	27	0.33	0.23	0.50	0.10	0.40	0.14	12	40
DoS	1	3	5	47	3	4	0.17	0.06	0.25	0.43	0.20	0.10	9	54
FR	1	0	4	0	2	7	0.20	0.00	0.33	0.00	0.25	0.00	7	7
RE	30	29	77	28	0	3	0.28	0.51	1.00	0.91	0.44	0.65	107	60
SA	0	0	0	0	0	1	0.00	0.00	0.00	0.00	0.00	0.00	0	1
TM	3	5	7	18	1	2	0.30	0.22	0.75	0.72	0.43	0.33	11	25
URV	46	50	113	36	4	25	0.29	0.58	0.92	0.67	0.44	0.62	163	111
UU	1	3	6	17	1	0	0.14	0.15	0.50	1.00	0.22	0.26	8	20
Overall	109	100	243	250	21	106	0.31	0.73	0.84	0.45	0.45	0.58	373	456

M = Mythril, S = Slither, Prec. = Precision, Rec. = Recall, F1 = F1 Score.

demonstrates that for all vulnerability categories Mythril when executed in LightCross has 31% precision, indicating that only 31% of the vulnerabilities reported by Mythril are actual vulnerabilities. The 84% recall demonstrates that Mythril is finding 84% of actual vulnerabilities. This suggests that Mythril is tuned to flag many potential issues, which results in catching most real vulnerabilities (high recall), but at the cost of many false alarms (low precision). In smart contract security, achieving high recall is often deemed more crucial than precision. This preference arises because overlooking even a single vulnerability carries significant financial risks, potentially resulting in exploits and financial losses. However, an abundance of false positives can unnecessarily consume developer efforts by prompting investigations into issues that do not exist.

In production environments, particularly CI/CD pipelines, excessive false positives can lead to alert fatigue, where developers can begin to ignore or automatically dismiss warnings, potentially overlooking genuine security vulnerabilities. Similarly, in formal security audit contexts, high false positive rates increase manual review overhead and may undermine auditor confidence in automated smart contract analysis results. In addition, the extended time to perform the security audit creates a higher cost for the audited company.

Mythril’s F1 score of 45% signifies the balance between precision and recall. Since this value is closer to the precision than the recall, it reflects the significant impact of low precision (high false-positive rate) on Mythril’s overall performance. Slither demonstrates better precision (73%) than Mythril (31%). In addition, Slither exhibits a recall of 45%, which is less than Mythril’s recall. Slither’s F1 score (58%) is better than Mythril. The results indicate that Slither produces fewer false positives while still maintaining reasonable detection, resulting in an improved overall balance between precision and recall.

Detection coverage.

Table 8. Vulnerability Detection Coverage by Category when using LightCross. Detection Coverage represents the percentage of real vulnerabilities in the SmartBugs dataset that are detected by each tool. Category abbreviations: AC = Access Control, AI = Arithmetic Issues, BR = Bad Randomness, DoS = Denial of Service, FR = Front-Running, RE = Reentrancy, SA = Short Addresses, TM = Time Manipulation, URV = Unchecked Return Values, UU = Unknown Unknowns.

	Total	Detected		Missed		Detection Coverage
Category	Vulnerabilities	M	S	M	S	M	S
AC	21	13	7	8	14	62%	33%
AI	23	11	0	12	23	48%	0%
BR	30	3	3	27	27	10%	10%
DoS	7	1	3	6	4	14%	43%
FR	7	1	0	6	7	14%	0%
UU	3	1	3	2	0	33%	100%
RE	32	30	29	2	3	94%	90%
SA	1	0	0	1	1	0%	0%
TM	7	3	5	4	2	43%	71%
URV	75	46	50	29	25	61%	66%
Overall	206	109	100	97	106	53%	48%

M = Mythril, S = Slither, Detected = TP, Missed = Total Vulnerabilities − TP, Detection Coverage = TP/Total Vulnerabilities.

depicts the results of the detection coverage that reveal shortcomings in both vulnerability detectors used in LightCross. Overall, Mythril demonstrates moderately better detection capabilities with 53% coverage compared to Slither’s 48%, but both tools miss nearly half of all vulnerabilities in the SmartBugs curated dataset. Looking at specific categories, there are notable strengths and weaknesses for each tool. Mythril excels at identifying vulnerabilities in reentrancy with a high coverage rate of 94%. It shows moderate effectiveness in detecting access control issues and unchecked return values, achieving coverage levels of 62% and 61%, respectively. However, its performance is lacking in other categories, with only 10% coverage in bad randomness, and 14% each in denial of service and front-running vulnerabilities. Slither exhibits additional strengths, achieving flawless detection of unknown unknowns with a success rate of 100%, and demonstrating robust effectiveness in identifying vulnerabilities in reentrancy at 90% and unchecked return values at 66%. However, it lacks the ability to identify vulnerabilities in three distinct categories: arithmetic issues, front-running, and short addresses. These results highlight the importance of using multiple detection tools in combination, as neither tool alone provides comprehensive coverage across all types of vulnerabilities. The subpar performance in detecting bad randomness vulnerabilities by both tools (10% each) despite their prevalence in the dataset (30 vulnerabilities) indicates a critical area for improvement in smart contract security tooling.

The large number of execution paths overwhelms Mythril’s constraint solver, which can cause timeouts before the detection of bad randomness vulnerabilities (e.g., in smart_billions.sol). In addition, both Slither and Mythril lack understanding of the broader context of the way random values are used within the smart contract. One way to mitigate this is to create domain-specific detection modules for Mythril and Slither that complement the detection of application-specific randomness requirements. Another way is to integrate a taint analysis component to assess bad randomness vulnerabilities in smart contracts as proposed in [48].

Table 9. Performance Metrics by Vulnerability Category for SmartBugs detectors. Category abbreviations: AC = Access Control, AI = Arithmetic Issues, BR = Bad Randomness, DoS = Denial of Service, FR = Front-Running, RE = Reentrancy, SA = Short Addresses, TM = Time Manipulation, URV = Unchecked Return Values, UU = Unknown Unknowns.

Tool	AC	AI	BR	DoS	FR	RE	SA	TM	URV	UU	TP	FP	FN	Prec.	Rec.	F1	Sa.
Confuzzius	9	11	0	0	2	29	0	3	38	0	92	176	114	0.34	0.45	0.39	382
Conkas	0	9	0	0	1	30	0	5	49	0	94	234	112	0.29	0.46	0.35	440
Honeybadger	0	0	0	0	0	18	0	0	0	0	18	142	188	0.11	0.09	0.10	348
Maian	7	0	0	0	0	0	0	0	0	0	7	143	199	0.05	0.03	0.04	349
Manticore	0	0	0	0	0	0	0	0	0	0	0	142	206	0.00	0.00	0.00	348
Osiris	0	13	0	0	0	27	0	2	13	0	55	195	151	0.22	0.27	0.24	401
Oyente	0	14	0	0	0	27	0	0	38	0	79	181	127	0.30	0.38	0.34	387
Securify	1	0	0	0	2	28	0	0	50	0	81	179	125	0.31	0.39	0.35	385
Semgrep	1	0	0	0	0	0	0	0	0	0	1	145	205	0.01	0.00	0.01	351
Sfuzz	0	8	0	0	0	21	0	1	32	0	62	169	144	0.27	0.30	0.28	375
Smartcheck	2	1	0	1	0	29	0	1	51	0	85	206	121	0.29	0.41	0.34	412
Solhint	16	0	0	1	0	0	0	5	51	1	74	353	132	0.17	0.36	0.23	559
Slither	7	0	3	3	0	29	0	5	50	3	100	392	106	0.20	0.48	0.28	598
Mythril	8	11	3	1	1	18	0	2	36	1	81	204	124	0.28	0.39	0.33	409

TP = True Positives, FP = False Positives, FN = False Negatives, Prec. = Precision, Rec. = Recall, F1 = F1 Score, Sa. = No. Samples.

depicts the vulnerability detection for all detectors available in SmartBugs. Analysis of vulnerability detection results across the SmartBugs framework reveals patterns in detector capabilities and category specialisation. Slither demonstrates the highest overall detection rate with 100 true positives and recall (0.48), but suffers from precision issues (0.20) due to 392 false positives. Confuzzius achieves the best balance with the highest F1 score (0.39), maintaining strong recall (0.45) while offering substantially better precision (0.34). The specialisation of the categories is evident throughout the results: The performance of Confuzzius is notable in detecting access control vulnerabilities, achieving a score of 9. Osiris finds 13 vulnerabilities, while Oyente finds 14, and Mythril achieves a score of 11 in addressing arithmetic issues. In terms of reentrancy detection, Conkas, Confuzzius, Slither, and Smartcheck all achieve high scores of 30, 29, 29, and 29 respectively. Additionally, identifying unchecked return values vulnerabilities or in another name unchecked low-level calls vulnerabilities, Smartcheck and Solhint lead with scores of 51, closely followed by Securify and Slither with a score of 50. Subpar performers include Manticore with zero true positives due to exceptions during the execution of the detector. Semgrep exhibits only one single detection. The results highlight the complementary nature of these tools, suggesting that combining detectors with different strengths, particularly pairing Slither’s high recall with Mythril’s capability of detecting vulnerabilities from most categories, produces a more thorough vulnerability report. While Mythril in LightCross identifies 109 vulnerabilities, in SmartBugs only 81 vulnerabilities are identified. This is likely due to the timeouts, such as (DOCKER_TIMEOUT) or segmentation faults (DOCKER_SEGV) reported.

Comparison between LightCross and SmartBugs detectors. Our comparative analysis shown in

Table 10. Comparison of Vulnerability Detection: LightCross vs. SmartBugs Detectors. Category abbreviations: AC = Access Control, AI = Arithmetic Issues, BR = Bad Randomness, DoS = Denial of Service, FR = Front-Running, RE = Reentrancy, SA = Short Addresses, TM = Time Manipulation, URV = Unchecked Return Values, UU = Unknown Unknowns.

	Total	LightCross		Combined		Best SmartBugs	Difference
Category	Vulns.	Mythril	Slither	Min	Max	Tool (Detected)	Min	Max
AC	21	13	7	13	20	Solhint (16)	−3	+4
AI	23	11	0	11	11	Oyente (14)	−3	−3
BR	30	3	3	3	6	Mythril/Slither (3)	0	+3
DoS	7	1	3	3	4	Slither (3)	0	+1
FR	7	1	0	1	1	Confuzzius/Securify (2)	−1	−1
RE	32	30	29	30	32	Conkas (30)	0	+2
SA	1	0	0	0	0	None (0)	0	0
TM	7	2	3	3	5	Conkas/Slither/Solhint (5)	−2	0
URV	75	46	50	50	75	Smartcheck/Solhint (51)	−1	+24
UU	3	1	3	3	3	Slither (3)	0	0
Total	206	109	100	117	154	(127)	−10	+30

Notes: Column LightCross Combined Min represents the conservative estimate (maximum of either tool) assuming complete overlap. The LightCross Combined Max column represents the optimistic estimate (sum of both tools, capped at total vulnerabilities) assuming minimal overlap. The Difference column depicts the potential gain/loss when using LightCross instead of the best SmartBugs tool, with negative values indicating vulnerabilities missed by LightCross. The Min Difference column uses the optimistic LightCross estimate, while the Max Difference column uses the conservative estimate.

reveals that using LightCross Mythril and Slither only instead of all detectors in SmartBugs results in minimal vulnerability detection losses in most categories. The table shows the conservative estimate, which is the maximum detected vulnerabilities of each tool as the Min column, and the optimistic estimate, which is the sum of both tools capped by the number of total vulnerabilities as the Max column. In the following, we focus on the conservative estimate. When Mythril and Slither are included in the SmartBugs framework, a user switching to LightCross would primarily experience detection losses in five specific vulnerability types. Access Control (losing at least 3 vulnerabilities with Solhint detecting 16 versus LightCross detecting minimum to 13), Arithmetic Issues (losing 3 vulnerabilities with Oyente detecting 14 versus LightCross detecting 11), Front-Running (losing 1 vulnerability with Confuzzius/Securify detecting 2 versus LightCross detecting 1), Time Manipulation losing 2 vulnerabilities with Conkas, Slither, Solhint detecting 5 versus LightCross detecting 3 and Unchecked Return Values losing 1 vulnerability with Smartcheck, Solhint detecting 51 versus LightCross detecting 50. In particular, LightCross maintains the optimal detection capability in the Bad Randomness, Denial of Service, Reentrancy, and Unknown Unknowns categories, where Mythril or Slither already represents the best performing tool in SmartBugs. For Reentrancy and Unchecked Return Values, two critical vulnerability categories, LightCross demonstrate equivalent detection capability to the best performing individual SmartBugs tools, with potential for complete coverage depending on tool detection overlap. These findings suggest that adopting LightCross offers an efficient vulnerability detection approach with minimal compromise (a potential loss of 10 vulnerabilities across all categories) while significantly reducing the operational complexity associated with maintaining and integrating 14 separate analysis tools deployed as different Docker containers. This efficiency gain is particularly valuable in resource-constrained development environments or continuous integration pipelines where execution speed and reliability are paramount.

Comparable vulnerability detection results have also been reported in [47]. In particular, the conclusion that Slither and Mythril provide the best combination in terms of vulnerability detection (Table 7). Taking also into account the results of the vulnerability detection results using the LightCross and SmartBugs tools and their execution time, we determine that the best combination when using two detectors is Slither and Mythril and these are the detectors for the LightCross  tool.

4.4. Performance Evaluation

For the performance evaluation of LightCross we used Python 3.12.4, Mythril version 0.24.7, Slither version 0.10.1, and SmartBugs 2.0.10. The experiments were carried out using an Intel(R) Core(TM) i5-6260U CPU with 16GB of RAM and Ubuntu 22.04.5 operating system. LightCross can be executed from the command line or executed from other Python applications. There are two main arguments for the tool. First, we can add the single file we want to analyse and the second option is to add the path of the folder where we can analyse all the smart contracts that reside in the folder. We developed a bash script (exec-lightcross.sh) to automate the process of running LightCross with multiple folders that contain smart contracts.

LightCross leverages the subprocess Application Programming Interface (API), and consists of two files: run_smartvulscap.py and smartvulscan.py. The first file is the entry point for the tool which checks if the input is a smart contract file or folder and outputs an error message to the user. The second file is the main component of the tool. In the second file, both Mythril and Slither create a subprocess where the input is either a specific solidity smart contract or a folder that contains solidity smart contracts. Each tool persists its output on a file which is then parsed to construct the CSV file with the output of each tool in a structured way. Slither is configured with the following options: (a) -exclude-optimisation, (b) -exclude-informational, (c) -exclude-low. The first option excludes detector with optimisation findings, the second excludes detectors with informational findings, and the last option removes detectors designed to identify low-risk vulnerabilities. We believe that this configuration offers the best approach for optimising the tool’s output quality by reducing noise and unnecessary information. When running Mythril within LightCross, the only configuration option we use is the execution timeout, which is set to 900 s.

Figure 3 illustrates the execution time for analysing smart contracts in the SB-curated dataset using all the tools supported by SmartBugs. Solhint completes its tasks in an average duration of 18.9 s, Slither in 21.9 s, and Oyente in 25.6 s, positioning them as the fastest tools, generally finishing analyses in less than 30 s. Detectors that are moderate in speed, such as SmartCheck at 33 s, Semgrep at 36.8 s, and Conkas at 99.5 s, provide a balance of quick execution and high accuracy in identifying issues. In contrast, detectors at the lower end of the speed, including Manticore with an average of 1186 s, SFuzz with 1262 s, and Confuzzius with 1775 s per analysis, exhibit significantly longer durations, often spanning between 20 and 30 min. Confuzzius takes around 100 times longer than the other detectors. This difference emphasises the influence of vulnerability complexity on tool efficiency, as demonstrated by categories such as reentrancy, averaging 487.1 s, and unchecked low-level calls, averaging 473.4 s, which require higher processing times due to their complex nature.

Comparing the execution times between the SmartBugs and LightCross tools unveils significant performance variances for the Mythril and Slither detectors. Using SmartBugs, Mythril displays considerable computation time, with execution durations spanning from 190.896 s for front-running vulnerabilities to 1174 s for reentrancy vulnerabilities. In contrast, Slither achieves more favourable performance results, ranging from 10.48 s for other vulnerabilities to 47.97 s for addressing short-address vulnerabilities. However, upon transitioning to the LightCross tool, both detectors realise significant efficiency improvements: Mythril execution times are reduced, with a range from 12.26 s for short addresses to 600.8 s for reentrancy, reflecting up to a 15-fold increase in speed for particular vulnerability categories. Slither’s improvement is even more noticeable, achieving execution times from 0.64 s for access control to 1.13 s for unchecked return values, which is faster than when using SmartBugs. These observations highlight the important influence of the implementation framework on detector efficiency, with LightCross providing performance improvements that could greatly improve the practical usage and effectiveness of these detectors in conducting large-scale security evaluations for smart contracts, especially in a CI/CD environment.

Figure 4 shows the time it takes for LightCross and SmartBugs to analyse smart contracts that reside in a specific category of the SB-curated dataset. LightCross outperforms SmartBugs in terms of execution time across most vulnerability categories, particularly when using the Slither detector. The most significant difference is observed with the Slither tool, where LightCross can achieve average execution times below one second in most vulnerability categories, with times varying from $0.6$ to $0.9$ s. In contrast, the SmartBugs tool requires substantially longer execution durations, with times ranging from $8.4$ to $26.3$ s. In the case of the Mythril detector, LightCross once again exhibits better performance, particularly evident through its faster execution times in various categories. For example, in the access control category, the execution time is shorter, being $47.2$ s compared to $211.3$ s, while in the arithmetic category, the time required is $35.6$ s as opposed to $270.5$ s. However, both tools experience execution times similar to those of Mythril for vulnerability categories such as reentrancy and unchecked low-level calls. This outcome is attributed to the fact that the Mythril tool takes more time to analyse the smart contracts in the dataset since it uses Satisfiability Modulo Theories (SMT) solvers such as Z3 and checks whether a path exists for the contract to execute in a particular path.

CPU and memory. To evaluate CPU and memory usage for LightCross, we selected a smart contract from each category with the most lines of code. We developed a process profiler using psutil version 7.0 [49] to measure CPU usage and memory consumption when running Slither and Mythril in LightCross. We evaluated the same contracts using SmartBugs and captured the output of the docker stats [50] command to retrieve each container’s CPU utilisation and memory consumption for Slither and Mythril. For both cases, we recorded the peak CPU utilisation and memory usage. Figure 5 depicts the results of the peak CPU usage for the selected smart contracts. The comparative assessment between LightCross and SmartBugs demonstrates significant differences in CPU utilisation patterns, with LightCross consistently showing higher CPU consumption across both the Slither and Mythril analysis engines. Specifically, LightCross Slither operations averaged 95.52% CPU usage (ranging from 79% to 99.80%), while SmartBugs Slither maintained a more moderate 74.04% average (52.58% to 82.24%). The difference becomes more evident with the Mythril analysis, where LightCross averaged 107.50% CPU usage with peaks reaching 120.20%, compared to SmartBugs’s 100.45% average. In particular, the LightCross Mythril analysis exceeded the usage of 100% CPU for all contracts tested, indicating multi-core resource consumption. The most CPU-intensive analysis occurred with the smart_billions.sol contract under the LightCross Mythril configuration, which consumed 120.20% CPU resources. LightCross exhibits higher CPU utilisation in most of the smart contracts evaluated in relation to SmartBugs.

Figure 6 illustrates the results of measuring memory consumption when running LightCross and SmartBugs. There are distinct performance characteristics between the LightCross and SmartBugs platforms when Slither and Mythril are executed on smart contracts. For Slither, LightCross demonstrates improved memory efficiency with an average consumption of 42.68 MB that ranges from 36.89 to 63.61 MB, outperforming SmartBugs, which averaged 92.10 MB with a range of 73.39 to 166.40 MB. This represents a $2\times$ memory advantage for LightCross, indicating that LightCross manages memory more efficiently. In contrast, the Mythril-based symbolic execution analysis presents a different performance dynamic where LightCross averaged 1010.29 MB which ranges from 235.19 to 2781.03 MB compared to SmartBugs’ higher average of 1360.49 MB, with range from 388.70 to 4294.00 MB. Although SmartBugs consumed 34.7% more memory on average during Mythril execution, it exhibited greater variability with peak consumption reaching 4294 MB for the open_address_lottery.sol smart contract, compared to LightCross’ maximum of 2781.03 MB. The memory efficiency ratio of 0.74 (LightCross/SmartBugs) for the Mythril analysis indicates that LightCross maintains more consistent memory usage patterns, although both platforms require on average substantial memory resources. In particular, using Mythril in SmartBugs requires considerable memory consumption, which is on average approximately $15\times$ higher than Slither in SmartBugs. Similarly, Mythril in LightCross requires on average approximately $24\times$ more memory consumption than Slither in LightCross. In conclusion, the results show that LightCross has a higher CPU utilisation and enhanced memory management than SmartBugs due to LightCross having direct access to these resources without the overhead exhibited by Docker containers [51].

4.5. Limitations

Despite its contributions, LightCross is affected by some limitations, mostly inherited from the backend tool detection and performance limits:

• Limited Detection Coverage: The tool relies solely on Slither and Mythril, which together detect only 53% and 48% of vulnerabilities in the SmartBugs dataset, respectively. Critical gaps exist for categories like bad randomness (10% coverage) and front-running (14%).
• High False Positives/Negatives: Mythril’s low precision (31%) introduces noise, while Slither misses 52% of vulnerabilities, risking undetected exploits.
• Performance Bottlenecks: Symbolic execution (e.g., Mythril’s 600 s analysis for reentrancy) limits scalability. Subprocess orchestration lacks advanced parallelism compared to containerised approaches like SmartBugs.
• Isolated Contract Analysis: LightCross scans contracts in isolation, ignoring vulnerabilities arising from inter-contract interactions (e.g., cross-contract reentrancy).

5. Conclusions and Future Work

In this paper, we presented a lightweight vulnerability detection tool for smart contracts called LightCross. The tool works by creating subprocesses for Slither and Mythril detectors for analysing smart contracts. We conducted an experimental analysis measuring the vulnerability detection rate using the SB-curated dataset, which contains 143 vulnerable smart contracts with 206 total vulnerabilities. We found that LightCross exhibits the same detection rate compared to SmartBugs when using the same backend detectors (Slither, Mythril), while not depending on Docker containers. We also measured the time it takes to analyse the smart contracts according to the specified categories. The results showed that when using the Mythril detector, LightCross achieves execution times comparable to those of SmartBugs. With Slither in LightCross, the analyses are completed in a timeframe of 0.64–5.0 s between categories, while the use of SmartBugs extends these times to a range of 5.66–26.35 s. In general, LightCross enables developers to efficiently examine smart contracts for vulnerabilities in their smart contract using a lightweight tool that does not depend on software containers.

Additionally, to improve user-friendliness and currency, LightCross presents the verification results based on OpenSCV, a state-of-the-art academic classification of smart contract vulnerabilities, aligned with the industry-standard CWE and offering improvements over the unmaintained SWC taxonomy. More generally, we advise tool developers to adopt maintained and up-to-date classifications such as OpenSCV and OWASP SCWE.

Future work could expand on LightCross in several directions. First, integrating additional vulnerability detection tools beyond Slither and Mythril could enhance the tool’s coverage and detection. Second, developing an improved orchestration mechanism for the subprocesses could potentially improve performance, especially for complex contracts or large-scale analyses. For example, we could use the PyCOMPSs framework [52] to improve the parallel processing of a large number of smart contracts. Third, implementing a user-friendly interface, possibly as a web application or IDE plugin, could make LightCross more accessible to a wider range of smart contract developers and security engineers. Additionally, exploring ways to reduce the execution time for the reentrancy category, perhaps through optimisation of the Mythril subprocess, would be valuable. Finally, conducting a more extensive benchmarking against a wider range of smart contract vulnerability detection tools and on larger, more diverse datasets such as the SmartBugs wild dataset [53] would provide a more thorough evaluation of the capabilities and limitations of LightCross. Alternatively, an extensive live dataset can be created using Etherscan to download the smart contracts’ source code from Ethereum Mainnet and testnet as demonstrated in [54].

Furthermore, we could also bridge this research to professional practice by implementing a GUI or IDE extension for LightCross, making the tool more accessible to developers by providing a familiar interface and removing some of the more technical barriers to industrial adoption, as studied by Davis et al. [55].