Smart Contract Security Vulnerabilities and Mitigation Methods: A Scoping Review

Data Charting

A structured charting form was used to extract bibliographic and technical information from each included evidence source. The chart included the year of publication, evidence type, blockchain platform, programming language or representation, type of vulnerability, detection, prevention, verification, or mitigation mechanism, validation mechanism, sample or benchmark details, and significant finding. Primary empirical tools and experiments were coded as primary evidence, whereas systematic reviews, technical reviews, taxonomies, and meta-analytic comparisons were coded as secondary evidence. This distinction prevents synthesis-level observations from being treated as independent attack observations. The categories in data-charting were merged when they used semantically similar labels to describe the same concept, e.g., transaction-ordering dependence and front-running or arithmetic overflow and underflow. The final extraction matrix is given in Table 3.

Table 3. Characteristics and evidence extracted from the 25 included evidence sources.

Evidence Source	Design / Evidence	Platform / Language	Vulnerability Focus	Detection / Prevention / Verification / Mitigation Approach	Validation Basis	Evidence Level	Principal Contribution
Luu et al. [10].	Primary tool / empirical	Ethereum; EVM / Solidity	Transaction ordering, timestamp, exceptions, reentrancy	Symbolic execution (Oyente) and protocol-level mitigation	19,366 contracts; 8,833 flagged as potentially vulnerable	Primary empirical/tool evidence	Early large-scale evidence that symbolic execution can expose multiple contract-level weaknesses.
Atzei et al. [11].	Technical survey/taxonomy	Ethereum; Solidity / EVM	External calls, gas, exceptions, type casts, reentrancy, randomness, time, fund loss	Attack taxonomy and defensive reasoning	Attack cases and platform-layer analysis	Secondary evidence/taxonomy	Shows that vulnerabilities originate across Solidity, EVM, and blockchain interaction layers.
Tikhomirov et al. [12].	Primary static-analysis tool	Ethereum; Solidity	Unchecked calls, reentrancy, tx. origin, arithmetic, timestamp, gas, visibility	Pattern-based source analysis (SmartCheck)	Real-world contracts and tool comparison	Primary empirical/tool evidence	Provides extensible source-level detection using syntax transformation and rule patterns.
Jiang et al. [13].	Primary dynamic-analysis tool	Ethereum; EVM	Gasless send, exception disorder, reentrancy, timestamp/block number, delegatecall, frozen Ether	Fuzzing with vulnerability-specific oracles (ContractFuzzer)	6,991 contracts; more than 459 vulnerabilities reported	Primary experimental evidence	Demonstrates scalable dynamic testing for vulnerability classes that depend on execution behavior.
Tsankov    et al. [14].	Primary static/security analyser	Ethereum; EVM bytecode	Reentrancy, transaction dependence, restricted writes/transfers, exceptions, locked Ether	Dependency graph plus compliance/violation patterns (Securify)	Large contract set and manual validation	Primary empirical/tool evidence	Distinguishes evidence for compliance from evidence for definite security-pattern violations.
Nikolic     et al. [15].	Primary symbolic / trace analysis	Ethereum bytecode	Greedy, prodigal, and suicidal trace vulnerabilities	Interprocedural symbolic analysis with concrete validation (MAIAN)	Nearly one million contracts; manually checked sample with high true-positive rate	Primary empirical/tool evidence	Extends analysis from local code defects to stateful multi-transaction trace properties.
Krupp & Rossow [16].	Primary exploit-generation study	Ethereum bytecode	Unsafe CALL, CALLCODE/DELEGATECALL, SELFDESTRUCT and unrestricted value flow	Symbolic exploit generation (teEther)	38,757 unique contracts; working exploits generated for 815	Primary experimental/runtime evidence	Links vulnerability discovery to concrete exploitability rather than flags alone.
Rodler     et al. [17].	Runtime protection study	Ethereum	Reentrancy	Dynamic taint tracking and runtime monitoring (Sereum)	Real-chain replay; reported low false-positive rate and low overhead	Primary experimental/runtime evidence	Provides post-deployment reentrancy protection without requiring source-code changes.
Feist et al. [18].	Static-analysis framework	Ethereum; Solidity	Multiple Solidity defects, with detailed reentrancy evaluation	SlithIR, data-flow and taint analysis (Slither)	Real contracts; manual review of high-use contracts	Primary empirical/tool evidence	Combines speed, extensibility, and low-level analyses for security auditing.
Frank      et al. [19]	Bounded model checking	Ethereum bytecode	Suicidal contracts and unrestricted value extraction	Precise EVM modelling and bounded model checking (ETHBMC)	Approximately 2.2 million accounts; 5,905 valid triggering inputs	Primary computational/experimental evidence	Shows that precise bounded reasoning can validate exploitable states at blockchain scale.
Zhuang     et al. [20]	Machine-learning study	Ethereum; Solidity graph representation	Reentrancy, timestamp dependence, infinite loop	Graph neural network with temporal message propagation	Comparative experiments on labelled smart-contract functions	Primary computational/experimental evidence	Demonstrates graph-based representation learning for structural vulnerability patterns.
Durieux    et al. [21].	Comparative empirical study	Ethereum; Solidity	Multiple vulnerability classes across nine tools	Cross-tool benchmark and agreement analysis	69 annotated vulnerable contracts plus 47,587 real contracts	Primary comparative empirical evidence	Shows substantial inconsistency in coverage, execution success, and findings among analysts.
Perez & Livshits [22].	Empirical exploitability study	Ethereum on-chain data	Vulnerabilities reported by six analysis projects	On-chain exploitation verification	23,327 vulnerable contracts; 1.98% observed as exploited	Primary empirical/on-chain evidence	Demonstrates that vulnerability detection should not be equated automatically with actual exploitation.
Huang      et al. [23].	Machine-learning study	Ethereum; Solidity	Arithmetic, reentrancy, unknown-address behavior	Multi-task vulnerability classification	Precision, recall, and F1 comparison with analysis baselines	Primary computational/experimental evidence	Uses shared representation learning to identify multiple vulnerability types jointly.
Zhang      et al. [24].	Deep-learning study	Ethereum; Solidity	Callstack, overflow/underflow, reentrancy, timestamp, ordering/loop issues	Hybrid CNN-BiGRU model (CBGRU)	SmartBugs Dataset-Wild; comparative classification metrics	Primary computational/experimental evidence	Integrates local and sequential code features for multi-class vulnerability detection.
Ashizawa et al. [25].	Machine-learning static analysis	Ethereum; Solidity / EVM	Seven types, including reentrancy, time dependency, gas, visibility, overflow/underflow	Contract-wide code embeddings (Eth2Vec)	5,000 files / 95,152 contracts; 10-fold validation; average precision 77.0%	Primary computational/experimental evidence	Improves robustness to code rewrites by learning contract-wide representations.
Kushwaha et al. [26].	Systematic review	Ethereum; Solidity	Broad vulnerability and attack coverage	Review of detection tools, attacks, and countermeasures	Systematic technical synthesis	Secondary evidence / systematic review	Maps recurrent Ethereum vulnerability classes to available detection and prevention mechanisms.
Zhou et al. [27].	Technical review	Ethereum	Broad smart-contract weaknesses	Vulnerability, countermeasure, and tool-support synthesis	Survey comparison of techniques and tools	Secondary evidence / technical review	Connects vulnerability categories to countermeasures and practical tool support.
Ma et al. [28]	Graph deep-learning study	Ethereum; Solidity	Reentrancy, timestamp, overflow, underflow	Hierarchical graph attention network (HGAT)	SmartBugs data; 7,018 contracts and comparative experiments	Primary computational/experimental evidence	Combines hierarchical structural representations for improved multi-class detection.
Tang et al. [29].	Deep-learning study	Ethereum; Solidity	Reentrancy, timestamp, unhandled exception, tx. origin	Lightning Cat using optimized CodeBERT / neural models	SolidiFI benchmark; 9,369 contracts; best reported F1 93.53%	Primary computational/experimental evidence	Shows the benefit of semantic pretrained representations for vulnerability classification.
Deng et al. [30]	Multimodal deep-learning study	Ethereum; source, opcode, control-flow	Arithmetic, reentrancy, transaction ordering, Ether locking	Multimodal feature fusion	Per-class accuracy reported around 89.5%-94.8%	Primary computational/experimental evidence	Combines complementary code modalities to reduce dependence on a single representation.
Xu et al. [31]	Heterogeneous-graph deep learning	Ethereum; Solidity	Access control, arithmetic, DoS, front-running, reentrancy, time, unchecked low-level calls	MVD-HG using AST, CFG, DFG and multi-granularity learning	Contract- and line-level experiments with repeated runs	Primary computational/experimental evidence	Broadens detection across vulnerability classes while adding line-level localization.
Vidal et al. [32].	Taxonomy/evidence synthesis	Smart-contract security ecosystem	Broad vulnerability landscape	Open hierarchical taxonomy (OpenSCV)	481 collected vulnerability entries and 77 detection tools considered	Secondary evidence / taxonomy and evidence synthesis	Provides a normalised vocabulary for heterogeneous vulnerability classifications.
Bresil      et al. [33].	Comparative review/meta-analysis	Smart contracts; mainly Ethereum	Deep-learning detection, especially reentrancy and timestamp dependence	Comparative analysis of deep-learning architectures	Cross-study performance synthesis	Secondary evidence/review and meta-analysis	Shows that representation and architecture choices materially shape reported detection performance.
Azimi       et al. [34].	Systematic review/design patterns	Smart contracts	Security-relevant design flaws and known vulnerabilities	Security design-pattern mapping	144 patterns; 36 security patterns; five patterns directly mapped to known vulnerabilities	Secondary evidence / systematic review	Reveals a gap between the breadth of known vulnerabilities and directly targeted security patterns.

Note: Secondary reviews and taxonomies are retained as secondary evidence and are distinguished from primary tool or empirical studies to avoid treating synthesis-level observations as independent attack incidence.

Coding, Thematic Synthesis, and Frequency Analysis

The synthesis used directed qualitative coding followed by cross-source comparison. The labels of vulnerability were coded on the evidence-source level and subsequently aggregated into seven higher-order families such as external-call / control-flow, arithmetic / state, block/transaction context, authorization / access control, resource / availability, lifecycle / fund-safety, and logic/semantic/exception handling. Security approaches were coded into distinct detection, prevention, verification, and mitigation families, including static analysis, symbolic / formal methods, fuzzing and runtime monitoring, machine / deep learning, secure coding and design patterns, multi-tool auditing and benchmarking, and taxonomy/evidence mapping. Document-level reporting frequency was then calculated for each vulnerability family. Each included publication could contribute a maximum of one count to a given vulnerability family. Source type was retained during coding to limit overlap in interpretation: the six secondary evidence sources were used to harmonise terminology, support taxonomy development, and contextualise recurring vulnerability-method relationships, but they were not treated as independent empirical replications of primary findings. Primary studies remained the principal basis for interpreting tool performance, exploitability, validation, and operational effectiveness. Consequently, a vulnerability reported in both a primary study and a secondary synthesis could contribute to document-level coverage, but this was interpreted as convergence in the literature rather than two independent empirical observations. The resulting frequencies therefore represent coverage across the 25 evidence sources rather than prevalence, effect size, or independent attack incidence.

Quality and evidence considerations

No formal risk-of-bias scoring was done since the evidence included in this study consists of incompatible designs, such as software tools, benchmark experiments, runtime defenses, empirical chain analyses, taxonomies, systematic reviews, and meta-analytic comparisons. Following the mapping objective of a scoping review, methodological heterogeneity was managed by mapping evidence type, validation method, dataset or benchmark, and evidence level, instead of statistically combining results. Special care was taken in the interpretation of accuracy or precision values since benchmark composition, vulnerability labelling, source-code availability, compiler version, and platform coverage vary across sources. Claims of comparative effectiveness are therefore interpreted within the validation conditions reported by each publication rather than as universal performance rankings.

RESULTS

Study Selection and Corpus Profile

This section presents the study-selection process and the profile of the final evidence corpus. Search interfaces found 1,200 records: 240 in Scopus, 469 in Web of Science Core Collection, 389 in IEEE Xplore and 102 in Springer Nature Link. Following the deletion of 210 duplicate records, 990 records were screened by title and abstract, with 720 being eliminated. Among the 270 reports requested to be retrieved, 15 were not retrieved, and 255 full-text reports were available to assess eligibility. An additional 230 reports were filtered out based on the reasons indicated in Fig. (1) to arrive at 25 evidence sources that were included. The final corpus spans 2016–2025 and comprises 19 primary technical or empirical studies and six secondary reviews, syntheses, or taxonomies. It is highly focused on Ethereum, Solidity, and EVM-level analysis. It encompasses primary vulnerability-detection tools, symbolic and formal analysers, fuzzing, and runtime-defense systems, machine- and deep-learning models, empirical benchmark comparisons, vulnerability taxonomies, and secondary syntheses. Table 3 presents the cross-source extraction matrix, and Fig. (2) presents the temporal distribution. The distribution indicates an early focus on static, symbolic, and exploit-oriented analysis followed by growth in learning-based approaches.

Detection, Prevention, Verification, and Mitigation Approaches

The included evidence sources demonstrate three broad methodological stages. The first stage focuses on symbolic execution, static analysis, fuzzing, and exploit generation. Oyente demonstrates symbolic execution over Ethereum contracts [10]. SmartCheck instantiates vulnerability knowledge as source-level patterns [12], and Securify as dependency graphs and security patterns [14]. ContractFuzzer introduces execution-based testing with vulnerability-specific oracles [13]. MAIAN, teEther, and ETHBMC also show that multi-transaction or exploitable states can be determined by symbolic and bounded reasoning as opposed to local syntax alone. Together, these methods form a robust basis for pre-deployment analysis, though their reach is limited by the semantics of the modeled EVM, path exploration, vulnerability specifications, and available computational resources.

A second stage deals with deployed or operational contracts. Instead of having to replace contracts, Sereum defends against reentrancy by runtime monitoring and dynamically tracking tainted contracts [17]. This shifts the mitigation goal from finding a defect before deployment to limiting damaging execution after deployment. A complementary empirical view is given by Perez and Livshits [22], who demonstrate that a small share of the contracts that were deemed vulnerable were actually exploited on-chain. Through their analysis, they justify the need to keep vulnerability detection, exploitability, and realised harm analytically separate. Even a technically correct detector can produce findings with substantially different practical risk, which supports exploitability-aware prioritisation and validation.

The third stage is defined by machine and deep learning. Graph-based learning represents contract structure and control relations, as demonstrated by Zhuang et al. [20]. Multi-task learning shares information across vulnerability classes [23], and CBGRU employs convolutional and recurrent representations [24]. Eth2Vec trains contract-wide representations that can remain useful under code rewriting [25]. Subsequent works augment the richness of representation by hierarchical graphs, semantic pretrained models, multimodal fusion, and heterogeneous AST-CFG-DFG graphs. Ma et al. [28] employed hierarchical attention, Tang et al. [29] reported high-performance results for a CodeBERT-based approach, and Deng et al. [30] used a combination of multiple code modalities. Xu et al. [31] expand graph learning to contract-level and line-level detection, indicating a shift toward finer-grained vulnerability localisation alongside classification and explainability.

Another form of security-assurance evidence is provided by secondary syntheses and taxonomies. Kushwaha et al. [26] and Zhou et al. [27] categorise vulnerabilities, tools and countermeasures within the Ethereum ecosystem. OpenSCV addresses terminology fragmentation by creating a hierarchical vulnerability taxonomy using heterogeneous classifications and detection tools [32]. Bresil et al. [33] compare deep-learning strategies based on the published evidence. In contrast, Azimi et al. [34] review the security design patterns and discover that a limited number of them directly address the known types of vulnerabilities. Together, these sources suggest that detection research has grown faster than preventive design coverage. Table 5 therefore distinguishes methodological families by control point, evidence base, and recurring limitations rather than treating detection, prevention, verification, and mitigation methods as equivalent.

Table 5. Synthesis of detection, prevention, verification, and mitigation families.

Family	Typical Control Point	Evidence Represented in the Corpus	Main Strength	Recurring Limitation
Static analysis/security patterns	Pre-deployment source or bytecode	Pattern rules, IR/data-flow, dependency graphs	Fast, automatable screening across large corpora	Rule coverage and false positives depend on specification quality.
Symbolic execution / formal methods	Pre-deployment and exploit validation	Path exploration, bounded model checking, trace properties	Can reason about execution states and prove/validate specific properties	Path explosion, modelling cost, and incomplete semantic coverage.
Fuzzing / dynamic testing	Pre-deployment execution	Input generation and vulnerability-specific oracles	Observes runtime behavior and can reveal execution-dependent defects	Coverage depends on generated inputs, instrumentation, and oracle design.
Runtime monitoring	Post-deployment execution	Dynamic reentrancy protection and execution monitoring	Protects already deployed contracts without source changes	May target narrow vulnerability classes and add runtime complexity.
Machine / deep learning	Primarily pre-deployment detection	Graph, sequence, embedding, pretrained-code and multimodal models	Scales multi-class detection and learns complex representations	Benchmark dependence, label quality, distribution shift, and explainability.
Secure coding/design patterns	Design and implementation	Preventive coding practices and security patterns	Reduces vulnerability introduction before analysis is needed	Direct pattern coverage remains limited relative to the vulnerability landscape.
Auditing/benchmarking/taxonomy	Cross-cutting assurance	Tool comparison, exploitation analysis, normalised taxonomies	Improves interpretation, prioritisation, and comparability	Heterogeneous tool outputs and taxonomies remain difficult to normalise.

Vulnerability-to-Security-Approach Cross-Map

According to the cross-map, smart-contract security assurance is layered. Design-time checks, effects, interactions, and reentrancy guards address external-call vulnerabilities, which can be detected using fuzzing during testing, reentrancy guards before deployment, or by static or symbolic methods before deployment. Checked arithmetic and secure coding can help eliminate arithmetic weaknesses, although it is also a goal of a static analyser and learning-based classifier. Block-context weaknesses either involve code-level limitations and the reasoning of transaction or environmental state, and lifecycle and fund-safety defects can frequently involve trace or value-flow analysis. This trend implies that the general security assurance cannot be narrowed down to the option of using the most successful detector in a single benchmark. Table 6 associates the seven vulnerability families with the most defensible detection, prevention, verification, and mitigation strategies embodied in the corpus.

Table 6. Cross-mapping of vulnerability families to detection, prevention, verification, and mitigation approaches.

Vulnerability Family	Supported Controls / Methods	Representative Evidence	Interpretation
External-call / control-flow	Checks-effects-interactions; reentrancy guards; static/symbolic analysis; fuzzing; runtime monitoring; graph/ML detection	Luu et al. [10]; Jiang et al. [13]; Rodler et al. [17]; Xu et al. [31]	Strongest multi-layer coverage, but persistent recurrence shows no single control is sufficient.
Block/transaction context	Avoid unsafe timestamp/randomness assumptions; transaction-aware analysis; fuzzing; graph/ML detection	Atzei et al. [11]; Zhuang et al. [20]; Bresil et al. [33]	Controls must model execution context and ordering, not source syntax alone.
Arithmetic / state	Checked arithmetic; static rules; formal reasoning; multi-class ML/DL	Tikhomirov et al. [12]; Huang et al. [23]; Ma et al. [28]	Well-represented in benchmark datasets, but compiler and language changes affect relevance.
Logic / semantic / exception	Return-value checks; explicit error handling; semantic/static analysis; fuzzing; learning-based classification	Jiang et al. [13]; Tsankov et al. [14]; Tang et al. [29]	Taxonomy inconsistency is a major barrier to comparing tools.
Lifecycle/fund safety	Restrict destructive/value-transfer operations; trace analysis; exploit generation; model checking.	Nikolic et al. [15]; Krupp & Rossow [16]; Frank et al. [19]	Trace-level reasoning is often required because risk emerges across transactions or value flow.
Authorisation / access control	Explicit authorisation; visibility control; role-based patterns; static/ML analysis	Huang et al. [23]; Xu et al. [31]; Azimi et al. [34]	Prevention is design-sensitive and benefits from privileged-operation analysis.
Resource/availability	Bound loops; gas-aware design; static/dynamic analysis; learning-based detection	Tikhomirov et al. [12]; Zhuang     et al. [20]; Xu et al. [31]	Availability risk depends on platform limits and runtime resource behavior.

DISCUSSION

Persistent Vulnerability Structure

The synthesis provides the answer to RQ1 by demonstrating that the research on smart-contract security is highly focused on external calls, control flow, and transaction context. At the document level, external-call/control-flow weaknesses were reported in 92% of the included evidence sources, and block/transaction-context weaknesses were reported in 76%. The prominence of these families is technically consistent since smart contracts are a mixture of program logic and externally triggered calls, publicly ordered transactions, economic transfer of value, and deterministic execution on a shared state. Atzei     et al. [11] already conceptualised many attacks as language, EVM, and blockchain layer interactions, and subsequent evidence does not refute that framework. Rather, more modern approaches recode the same underlying flaws in various forms again and again. This continuity suggests that improvements have been made in analysis capability, scale, and representation, as opposed to the removal of the underlying classes of smart-contract risk.

The frequency analysis also explains why arithmetic or access-control bugs cannot be considered obsolete merely because more recent languages or compiler checkers address some instances. At the document level, arithmetic/state weaknesses were reported in 56% of the included evidence sources, and authorisation/access-control weaknesses were reported in 44%. This continuity is partially due to benchmark continuity, but also demonstrates that security failures are not entirely compiler problems. Huang et al. [23] utilise arithmetic and reentrancy as targets of multi-task detection, and MVD-HG consists of arithmetic and access-control targets in a more general heterogeneous-graph framework [31]. The field thus still considers these classes of vulnerabilities as useful analytical categories regardless of the change in the implementation environment.

These frequencies require careful interpretation because six included sources are secondary reviews, syntheses, or taxonomies that may discuss primary studies also represented directly in the corpus. Secondary sources were retained to stabilise terminology, corroborate vulnerability categories, and map broader methodological coverage, but they were not treated as additional independent empirical confirmations. Repeated reporting of a vulnerability family in a primary study and in a secondary synthesis therefore indicates convergence in the literature rather than empirical replication. The cross-map should consequently be interpreted as a descriptive synthesis of recurring vulnerability-method relationships, with primary studies providing the principal empirical basis and secondary sources providing contextual corroboration and taxonomy harmonisation.

Evolution from Rule-Based Analysis to Learned Representations

The obvious methodological shift over the decade provides an answer to RQ3. Initial studies focus on symbolic execution, pattern-based static analysis, fuzzing, dependency-graph analysis, and exploit generation. These techniques expose their assumptions and tend to leave traceable results or rule violations. An example of symbolic execution is provided by Luu et al. [10], and formalization of source-level patterns is implemented in SmartCheck [12]. teEther generates concrete exploits, whereas ETHBMC identifies bounded counterexamples or triggering inputs [16, 19]. Interpretability is the key advantage of this generation, and scalability and semantic completeness are recurring limitations.

Representation learning has gained more and more prominence since 2020. Graph neural networks are able to capture structural relationships, multi-task models are able to share information across vulnerability classes, and code-language models learn semantic representations. Tang et al. [29] and Deng et al. [30] indicate that an optimized CodeBERT-based model has good F1 performance, and that integrating source, opcode, and control-flow information can enhance multi-class detection, respectively. MVD-HG continues this orientation with heterogeneous graph relations as well as line-level localisation [31]. Nevertheless, improved benchmark performance does not always result in stronger operational security. Results based on learning are sensitive to labels, datasets, injection strategies, compiler versions, and train-test distributions; the values of performance must be viewed as evidence conditioned on the benchmark but not as evidence of universal superiority.

Effectiveness, Validation, and Exploitability

RQ2 requires distinguishing detection, prevention, verification, and mitigation from demonstrated risk reduction. Durieux et al. [21] demonstrate that even within the same population of contracts, automated analysers can diverge significantly, which implies that the output of tools is sensitive to implementation, supported compiler versions, as well as vulnerability definitions. Perez and Livshits [22] introduce another critical risk factor: only a small proportion of the contracts identified as vulnerable in their large sample were observed to be exploited (1.98%). This does not diminish the importance of vulnerability detection; rather, it shows that exposure, exploitability, attacker incentives, and contract value mediate realised harm. A stronger assurance process should therefore integrate vulnerability identification with exploit validation, contextual severity assessment, and mitigation verification.

Design- and runtime-oriented evidence also demonstrates the necessity of layered controls. Sereum is able to defend against reentrancy in existing contracts during execution time [17], but design patterns aim to defend against unsafe structures prior to deployment. But Azimi et al. [34] conclude that only a small number of established security patterns can be directly related to recognised vulnerability categories, which suggests a prevention-coverage gap. OpenSCV also illustrates the scope and terminological disaggregation of the vulnerability domain [32]. These results suggest that security engineering cannot be based on one lifecycle stage. Prevention, detection, formal reasoning, exploit validation, and runtime safeguards deal with various failure modes and should be integrated based on the criticality of the contract.

Research Gaps and Implications

There are four significant evidence gaps that are identified in RQ4. First, the corpus is largely Ethereum- and Solidity-focused, which means that the generalizability across platforms is low. Second, the comparability of benchmarking is limited due to the fact that the evidence sources contain various vulnerability labels, injected defects, real-world contracts, compiler versions, and metrics. Third, numerous learning-based primary studies maximize classification performance but do not have similar evidence on exploitability, remediation efficacy, or post-deployment behavior. Fourth, the coverage of preventive design is still significantly less than the list of known vulnerabilities. Future reports should give standardised definitions of vulnerabilities, provenance of data sets, compiler and platform versions, class distribution, false-positive and false-negative analysis, and reproducible code or benchmark artifacts where feasible.

The results also carry practical implications for auditors and developers. Coverage can be fast with static analysis, but it should be complemented with analyses of vulnerabilities that are sensitive to multi-transaction state or runtime circumstances. Symbolic and formal methods provide more powerful execution reasoning, but can have more limited specifications and demand more computation. Fuzzing provides tangible evidence of execution, and runtime protection can decrease the risk of already deployed contracts. Learning-based models are also scale- and multi-class-sensitive, though when the contract value is high, they should be used in combination with rule-based or semantic checks. The cross-map in Table 6 therefore supports a defense-in-depth strategy in which techniques should be selected according to the vulnerability family, lifecycle phase, and required assurance level.

LIMITATIONS AND FUTURE DIRECTIONS

This review has several limitations. Only four information sources and English-language literature were searched, which means that potentially eligible work that is indexed elsewhere or published in other languages might not have been found. The title-based search query limited the amount of general blockchain-security literature, but this method can suppress sensitivity to articles whose titles focus on a tool name or platform-specific terms instead of security or vulnerability terms. Titles and abstracts were screened and full texts evaluated by two reviewers who discussed and agreed on disagreements, though no formal inter-rater reliability coefficient was computed. The numerical study-selection pathway and full-text exclusion categories applied in this review are reported in Fig. (1).

The final corpus contained 25 evidence sources from 1,200 identified records, comprising 19 primary technical or empirical studies and six secondary reviews, syntheses, or taxonomies. This substantial reduction reflects the strict eligibility criteria requiring direct smart-contract security relevance, peer review, readable full text, sufficient extractable technical detail, English language, and publication within 2016–2025. These restrictions increased topical specificity but reduced empirical breadth and may have omitted relevant work with tool-specific titles, incomplete reporting, non-English publication, or indexing outside the four searched sources. Accordingly, the vulnerability-to-security-method cross-map should be interpreted as a structured synthesis of the eligible evidence captured by this protocol rather than a comprehensive or universally generalisable representation of all smart-contract security research. The limited primary-study base also reduces confidence in sparsely represented vulnerability-method associations and cross-platform conclusions.

The evidence included is heterogeneous, and primary software tools, benchmark studies, empirical on-chain analyses, taxonomies, systematic reviews, and meta-analytic comparisons do not offer directly equivalent types of evidence. No formal risk-of-bias score was used since no single appraisal tool is suitable for all these designs; evidence type and validation basis were charted directly. Document-level frequencies indicate how often a family of vulnerabilities is reported in the sources of evidence included in the analysis and cannot be understood as actual prevalence of vulnerabilities or attack rates. Performance measures should also not be compared across incomparable datasets as though they had been measured in equal conditions. Lastly, the research on Ethereum, Solidity, and EVM is predominant, which restricts the inferences to other smart-contract ecosystems. These restrictions do not obstruct evidence mapping, but limit conclusions regarding universal security efficacy. Although secondary sources were not given independent empirical weight, overlap remains possible because some of their underlying primary studies may also appear separately in the corpus. This further support interpreting the frequencies and cross-map as descriptive evidence mapping rather than quantitative estimates of independent evidence strength. Future reviews could broaden database coverage, relax title-field constraints, or conduct primary-study-only synthesis where sufficiently comparable data permit.