Source-linked AI summary
Solidity Meets LLMs: A Transformer-Based Approach to Smart Contract Vulnerability Detection
Djamel Eddine Hakim Ghorab, Farid Mokhati, Mostafa Anouar Ghorab
TL;DR
Smart contracts are difficult to secure because vulnerabilities can remain after deployment, when contracts are immutable. The paper labels Solidity fragments and fine-tunes BERT to classify them as vulnerable or safe; its reported metrics rise across training epochs.
Problem
Smart contracts are immutable after implementation, making vulnerability prevention throughout development challenging.
Source: §1 · p. 2Method
The approach collects and labels Solidity contract fragments, then fine-tunes BERT to classify snippets as vulnerable or safe.
Source: §1 · p. 2, §5 · p. 12Results
Across five training epochs, accuracy, precision, recall, F1-score, MCC, and ROC-AUC increased while training and validation losses decreased.
Source: §4.3 · p. 11Takeaways & Limitations
The authors report that the model shows promise for detecting vulnerable Solidity code and may be useful to developers and security analysts.
Source: §4.3 · pp. 11–12The dataset may need enrichment with misleading code and edge cases to reduce false positives.
Source: §5 · p. 12
Abstract
from arXiv · showhide
The growing adoption of blockchain technologies, particularly the Ethereum platform, has amplified the critical role of smart contracts in decentralized applications. However, the increasing complexity and financial value of these contracts make them prime targets for cyber attacks. In this work, we present a transformer-based approach for the detection of vulnerabilities in smart contract fragments written in Solidity. Leveraging the representational power of pre-trained Large Language Models (LLMs), we construct a robust pipeline that includes the definition of a ground truth dataset, labeling code fragments as vulnerable or safe. We then fine-tune a BERT-based architecture on this dataset, enabling the model to capture the syntactic and semantic patterns specific to Solidity code. Our fine-tuned model demonstrates strong performance, achieving an F1 score of 92%, and highlighting the effectiveness of LLM adaptation in enhancing smart contract security through deep contextual understanding.
1 Introduction
Smart contracts are difficult to secure because vulnerabilities can persist after deployment, when contracts are immutable. The paper proposes labeling Solidity contracts and fine-tuning BERT to detect vulnerabilities in contract fragments.
1 Introduction
- The paper positions Solidity vulnerability detection within blockchain applications spanning finance, healthcare, logistics, and notary services.Blockchain is described as a decentralized, secure, transparent, and immutable mechanism for managing information.Source: §1 · p. 1
- Smart contracts cannot be modified after implementation, making security across development phases challenging; the DAO reentrancy attack siphoned about $70 million.The paper uses this incident to illustrate the stakes of vulnerability detection.Source: §1 · p. 2
- The proposed pipeline collects raw Solidity contracts, labels them, and fine-tunes BERT to detect potential vulnerabilities in contract fragments.The paper describes labeling code fragments as vulnerable or safe.Source: §1 · p. 2
2 Background
The background introduces Solidity smart contracts and presents a five-category taxonomy of their vulnerabilities. It illustrates reentrancy as an external-call risk that can permit repeated withdrawals.
2.1 Solidity Smart Contract
- Solidity contracts run on Ethereum, with execution enforced through consensus, and support object-oriented features alongside EVM-related language features.The passage names inheritance, overloading, overriding, modifiers, specifiers, and global variables.Source: §2.1 · p. 2
2.2 Vulnerabilities and Taxonomy
- The taxonomy organizes Solidity vulnerabilities into five categories reflecting their impact and behavior, addressing risks in sensitive applications and new smart-contract attack vectors.The taxonomy is presented for developers, auditors, and researchers.Source: §2.2 · p. 3
- Reentrancy occurs when an external call transfers control to a recipient that can call the vulnerable withdrawal function again before funds are exhausted.The paper describes the DAO exploit as a prominent example and notes transfer or a lock as possible remediations.Source: §2.2 · p. 4
3 Related works
Related work covers formal, dynamic, symbolic, static, and machine-learning approaches to Solidity vulnerability detection. The paper contrasts these methods with BERT, which it presents as suited to code snippets, including early or incomplete code.
3 Related works
- Prior work includes formal modeling and model checking, dynamic fuzzing, symbolic execution, static analysis, and learned classifiers using source code, bytecode, graphs, or images.Examples include ABI- and bytecode-driven fuzzing, symbolic path exploration, and graph-neural-network classification.Source: §3 · p. 4, §3.1 · pp. 5–6
3.1 Detection approaches
- Fuzzing uses concrete inputs, whereas symbolic execution explores paths with symbolic values and checks whether security properties are violated.Static-analysis approaches include abstract interpretation, pattern matching, and taint analysis.Source: §3.1 · pp. 5–6
- Some learned detectors combine source-code and bytecode features, while others classify graph slices or bytecode converted into RGB images.The cited examples include SmartMixModel, a graph-neural-network approach, and a CNN-based approach.Source: §3.1 · p. 6
3.2 Comparison of Solidity Smart Contract Vulnerability Detection Tools
- Many tools depend on binary code, ABI, or an AST; parser-dependent tools may require a complete contract and therefore cannot scan partial code for IDE integration.The paper contrasts these requirements with regex-based SolScan, which can detect patterns in partial code but may miss newer vulnerability patterns.Source: §3.2 · p. 6
- The proposed BERT approach uses bidirectional context without explicit formal modeling or manual rule definitions, and is presented as applicable to early-stage or incomplete snippets.The paper contrasts this with conventional tools that often rely on ASTs, compiled code, or well-specified inputs.Source: §3.2 · pp. 6, 8
4 The proposed approach
The proposed approach fine-tunes BERT to classify Solidity fragments as vulnerable or safe, using scanner-labeled data and evaluating model performance across training epochs.
4 The proposed approach
- The approach collects Solidity contracts, automates fragment labeling, and fine-tunes BERT for binary vulnerability classification.The classifier is intended to identify whether Solidity source code contains vulnerabilities.Source: §4 · p. 8
4.1 Data collection and Labeling process
- Slither and SolScan label fragments using a conservative rule: either tool flagging a contract marks it vulnerable, while both must deem it safe for a safe label.Slither uses symbolic execution and SolScan pattern recognition; vulnerability lines and types are extracted, and the resulting code snippets are cleaned of comments and excess whitespace.Source: §4.1 · pp. 8–10
4.2 Training
- The data are split into 70% training, 15% validation, and 15% testing, then tokenized with Hugging Face's Bert-Tokenizer for BERT input.The test set is reserved to assess the final model on unseen data.Source: §4.2 · pp. 10–11
4.3 Results
- Across five epochs, training and validation losses decreased while accuracy, precision, recall, F1, MCC, and ROC-AUC increased.The authors interpret high precision and recall as indicating low false-positive and false-negative rates, and say further tuning may improve performance.Source: §4.3 · pp. 11–12, Table 5 · p. 12
5 Conclusion and perspectives
Because smart-contract vulnerabilities can compromise systems that use them, the conclusion frames their detection and mitigation as critical. It presents a BERT-based approach to classifying Solidity fragments and outlines directions for improving the approach’s performance and applicability.
5 Conclusion and perspectives
- The study proposes classifying Solidity smart-contract fragments as vulnerable or safe with a BERT-based model, and reports that its findings validate LLM effectiveness for this task.The approach collects and labels fragments, trains a transformer-based model, and evaluates its ability to detect security flaws.Source: §5 · p. 12
- Dataset quality could be improved by adding corrected vulnerable examples, misleading code, and edge cases to reduce false positives.Source: §5 · p. 12
- More precise and trustworthy ground-truth labels could be pursued by combining static and dynamic analysis tools with expert manual review.Source: §5 · p. 12
- Moving from binary classification to taxonomy-based multiclass classification could help developers understand specific flaws.Source: §5 · p. 12
- Using advanced LLMs to generate secure fixes is proposed as a path toward automated vulnerability mitigation.The paper describes this direction as extending LLM use from detection to remediation.Source: §5 · p. 13