Pith. sign in

REVIEW 4 major objections 7 minor 43 references

Automated Vulnerability Injection in Solidity Smart Contracts: A Mutation-Based Approach for Benchmark Development

T0 review · 4 major / 7 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Pattern-based mutation operators can inject six known vulnerability types into real-world Solidity contracts at scale, and the static analyzer Slither detects only 59.7% of the injected flaws.

desk verdict Useful mutation tool and large benchmark, but labels are pattern-adherent rather than exploitability-checked, so the 59.7% recall measures pattern detection more than real vulnerability detection. read the letter →

arxiv 2504.15948 v1 pith:IY7M7Y3Y submitted 2025-04-22 cs.SE

Gerardo Iuliano , Luigi Allocca , Matteo Cicalese , Dario Di Nucci This is my paper · ORCID
classification cs.SE
keywords smartcontractsecurityvulnerabilityinjectionmutationtestingSoliditystaticanalysisbenchmarkgenerationSlitherEthereum
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that mutation seeding can turn ordinary Solidity contracts into a large, labeled benchmark of vulnerable ones, and that doing so exposes measurable gaps in current static analysis. It introduces MuSe, a tool that extends an existing mutation tester with six pattern-based operators, each of which rewrites code so it matches a known vulnerability pattern. On 47,398 contracts from an Ethereum-derived dataset, MuSe generates 350,493 mutants, an increase above 840%; manual review of 384 sampled mutants found 94.79% correctly injected. Running Slither on the mutants, the paper measures an overall recall of 59.7%, ranging from 100% for unchecked low-level calls and unchecked sends down to 10% for delegatecall-to-untrusted-callee. If the label 'injected vulnerability' is taken at face value, the benchmark gives detector builders a concrete stress test with known ground truth.

What carries the argument

The load-bearing mechanism is the pattern-based mutation operator: a syntactic rewrite rule that scans an abstract syntax tree for a code shape and rewrites it into a shape associated with a known vulnerability. MuSe pairs one operator with each of the six vulnerabilities, using the parser's AST to locate target statements and the mutation engine to apply the rewrite. The operators carry the argument because benchmark validity rests on them: a mutant counts as an injected vulnerability if and only if the operator's pattern was applied, and detection is measured by comparing Slither's findings before and after that rewrite on the mutated lines.

What would settle it

Deploy a random sample of mutants that Slither flagged as true positives, roughly 50 per vulnerability type, in a local Ethereum VM; run the attack that each vulnerability class is supposed to enable, such as draining funds via an unchecked call, spoofing the owner via tx.origin, or redirecting delegatecall to a malicious contract; and count how many mutants are actually exploitable. If that fraction is far below 1, the 59.7% recall measures detection of code patterns rather than detection of exploitable vulnerabilities.

Watch

Extended reading notes

Core claim

The central discovery, on the paper's own terms, is that pattern-based mutation operators can automatically produce vulnerable smart contracts and that Slither cannot detect all of them. The six operators remove return-value checks on low-level call and send, replace msg.sender with tx.origin in authorization checks, drop unused return values, wrap external calls in loops, and replace delegatecall targets with a user-settable address. Across the real-world dataset, 41,337 of 47,398 contracts were mutated at least once; the most common injections were unused return (213,912 mutants) and tx.origin authorization (65,825), while delegatecall injection was rare (149 mutants). Slither's reported recall on the injected flaws is 59.7%, with per-type recall of 1.000 for unchecked low-level call and unchecked send, 0.810 for calls in a loop, 0.605 for unused return, 0.336 for tx.origin authorization, and 0.100 for delegatecall to untrusted callee.

Load-bearing premise

The result depends on treating a mutant that compiles and matches the intended code pattern as an actual instance of the vulnerability it is meant to inject.

Editorial extensions

If this is right

  • Researchers can expand a 47,398-contract dataset into 350,493 mutants, an increase above 840%, with labels tied to six injected vulnerability types.
  • Detection-tool evaluation can expose per-type blind spots: Slither catches 100% of unchecked call and send mutants but only 10% of delegatecall mutants, so the benchmark separates easy from hard vulnerability classes.
  • Because operators are pattern-driven, adding a new vulnerability type is a matter of writing a new operator, so the benchmark can grow with the vulnerability taxonomy.
  • Consumers of the benchmark should expect side effects: mutations can add or remove unrelated warnings, so labels need line-level filtering or manual review.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A next step the paper leaves implicit is to check exploitability dynamically, for example with a test harness or symbolic execution, which would separate 'the code matches a vulnerable pattern' from 'an attacker can actually cause harm'.
  • The per-type recall spread suggests detector authors could use the mutants as regression tests for the specific missed patterns, such as tx.origin inside modifiers, unused returns from inherited functions, and settable delegatecall targets.
  • Because only contracts containing the relevant constructs can be mutated, mutation-based benchmarks inherit the base dataset's blind spots; combining mutation with audit-based or generative datasets may cover rare types like delegatecall.
  • The side effects described in the paper imply that training machine-learning detectors on this benchmark without filtering to the mutated lines could inject label noise; line-scoped logs from the mutation engine are the obvious mitigation.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 7 minor

Summary. The paper presents MuSe, a mutation-based tool that injects six vulnerability patterns into Solidity smart contracts from the SmartBugs-wild dataset, producing 350,493 mutated contracts. RQ1 measures how often each operator can inject its target pattern, yielding injection rates from 71.5% (UR) down to 0.23% (DTU). RQ2 evaluates Slither's ability to detect the injected vulnerabilities by comparing its output before and after mutation, reporting an overall recall of 0.597 (Table 3) and per-type recall from 1.000 (UC, US) to 0.100 (DTU). The authors manually validate a statistically sampled subset of 384 mutants for compilation, SuMo-log agreement, pattern adherence, and modification correctness, but not for runtime exploitability. The paper claims that MuSe expands the dataset by over 840% and that static analysis tools fail to detect all injected vulnerabilities.

Significance. If the ground-truth labels were valid, MuSe would be a useful contribution: it provides a publicly available tool, a large mutated contract dataset, a replication package, and a concrete empirical finding that even on a set of vulnerability types preselected for Slither's detectors, Slither does not detect 40.2% of the generated mutants. The per-type injection-rate analysis (Table 2) is also informative for understanding pattern prevalence in real-world contracts. However, the central measurement (Table 3 recall) is only as credible as the ground-truth labels, and the paper does not establish that the injected patterns are exploitable vulnerabilities. The paper itself concedes that DTU mutants in constructors are not exploitable, yet those mutants are counted in Table 3; side effects in 30-75% of mutations confound the before/after comparison; and the vulnerability types were chosen partly because Slither already detects them, limiting generalizability. These issues affect the load-bearing empirical claim, so the significance of the contribution will be fully realized only after the measurement is repaired or its scope is clearly delimited.

major comments (4)
  1. [Section 3.3 and Section 5.1/Table 3] The manual validation in Section 3.3 checks compilation, SuMo logs, pattern adherence, and modification correctness, but it does not check whether the injected mutation is exploitable in the contract's runtime context. This is load-bearing for RQ2 because the denominator of Table 3 includes all analyzed mutants, not only those with a potential exploit path. The paper itself states in Section 5.1 that most delegatecall sites are in constructors, where "it is impossible to inject an instance of the vulnerability into the constructor that is exploitable," yet such mutants are counted as DTU false negatives (134 of 149 in Table 3). The overall recall of 0.597 is therefore not a measurement of detection of exploitable vulnerabilities. I recommend either restricting the ground truth to reachable, potentially exploitable mutations (e.g., excluding constructor DTU and CL loops without attacker-controlled bounds and sufficient gas), or explicitly re-labeling the dependent variable as 'pattern-detection recall' and adjusting the abstract and conclusion accordingly.
  2. [Section 3, first paragraph] The vulnerability types are selected "based on their relevance in the literature and the ability of Slither to detect them with at least medium confidence." This makes the 0.597 overall recall a conditional estimate: it measures Slither on a set of types for which Slither already provides detectors, so it is not representative of the general failure rate across the space of smart contract vulnerabilities. The abstract states that "static analysis tools fail to detect all vulnerabilities injected using pattern-based mutations," which goes beyond what the design can support. I suggest either adding vulnerability types without existing Slither detectors to test generality, or explicitly framing RQ2 as an evaluation of Slither's detectors on mutation-injected instances of six targeted patterns rather than a general statement about static analysis tools.
  3. [Section 4.2 with Section 5.2] The TP/FN classification in Section 4.2 is based on comparing Slither output before and after mutation, filtered to the mutated lines. Section 5.2 reports that 30-75% of mutations introduce side effects that add or remove other Slither warnings, including removal of pre-existing vulnerabilities (e.g., reentrancy-benign -5,340, reentrancy-no-eth -3,191, reentrancy-eth -830, divide-before-multiply -3,913, incorrect-equality -3,851). Because a mutation can remove a warning at the mutated line or change the code so that a pre-existing warning disappears, the before/after diff does not cleanly isolate the injected vulnerability; Table 3's counts may conflate "Slither does not detect the injected pattern" with "Slither no longer detects a different pattern affected by the mutation." Please provide a sensitivity analysis that excludes mutants with interfering side effects, or a per-case reconciliation of the diff, before the recall values can be interpreted as detection of the injected vulnerability.
  4. [Section 3.3 vs Table 3] The manual validation found that 20 of 384 sampled mutants (5.21%) were not correctly injected, giving examples such as syntax truncation on semicolons and variable-scope conflicts in the CL operator. The paper does not state that these failed mutants are excluded from Table 3; since the table's denominator is the 335,163 successfully analyzed mutants, it likely includes a comparable fraction that are not actual instances of the target vulnerability. If Slither does not flag a failed injection, that mutant is mislabeled as a false negative, deflating the reported recall. I recommend filtering out known-failed injections where detectable from SuMo logs, applying a conservative correction based on the observed 5.21% failure rate, or adding a quantitative threat-to-validity discussion of the impact on the reported recall.
minor comments (7)
  1. [Section 3.3 / Section 4 / Table 3] The number of mutated contracts is given as 350,716 in Section 3.3 but 350,493 in Section 4 and Table 2; additionally, Section 4.2 says Slither successfully analyzed 335,234 mutants, while Table 3's TP+FN totals sum to 335,163. Please reconcile these counts.
  2. [Section 3, first paragraph] The text says six vulnerabilities are selected but then lists only five: "Unchecked call return value, Unchecked send, Authentication through tx.origin, Delegatecall to untrusted callee, and Unused return." "Multiple calls in a loop" is missing from the list.
  3. [Section 4.2, RQ2 text] The prose says the UR recall is 0.63, but Table 3 reports 0.605; update the prose to match the table.
  4. [Section 3.2, CL operator code example] The illustrative code for the CL operator contains an unbalanced parenthesis in "require (member.send(0.1 ether);" in both the before and after snippets; fix the example's syntax.
  5. [Section 5.2] The paper uses "vulnerability," "code smell," and "warning" inconsistently; for example, events-math and events-access are described as vulnerabilities while Slither labels them as informational or optimization issues. Please use consistent terminology that matches Slither's detector categories.
  6. [Table 1] The CL row describes "Multiple calls in a loop" with the hedged text "might lead to a denial-of-service attack," but RQ2 and Table 3 count all CL mutants as true vulnerabilities. The hedged description should be reflected in the interpretation of the recall numbers.
  7. [References] Reference [17] has a placeholder title (the citation reads "Ghaleb and Pattabiraman. 2020. '. In Proceedings..."). Please complete the bibliographic entry.

Circularity Check

2 steps flagged · score 4.0 of 10

Ground-truth vulnerability labels are the paper's own mutation patterns, so Table 3's recall is partly a self-consistency check of Slither on its own detectors.

  1. self definitional [Section 4.2 (RQ2), detection comparison paragraph]
    "Under the assumption that the mutation operator correctly injects the vulnerability, we compared the detection results before and after the mutation. Slither correctly detects a mutant if it is labeled as vulnerable to the type of injected vulnerability."

    The ground truth for Table 3 is the paper's own mutation label: a mutant counts as an injected vulnerability iff MuSe applied one of the six operators. Section 3.3 validates that label only by compilation, SuMo logs, pattern adherence, and modification correctness, never by independent exploitability. The reported recall of 0.597 is therefore the rate at which Slither's detectors fire on syntactic patterns that the paper itself maps to Slither detectors in Table 1. The abstract's claim that 'static analysis tools fail to detect all vulnerabilities injected using pattern-based mutations' is a statement about the paper's self-defined patterns, not about independently established vulnerabilities, so the central empirical result is partly defined by the injection procedure.

  2. self definitional [Section 5.1 (False Negative Analysis), Delegatecall to untrusted callee; Table 3]
    "we noticed that most delegatecall functions are used in the constructor, which is invoked only at deployment time. Therefore, it is impossible to inject an instance of the vulnerability into the constructor that is exploitable."

    Despite this admission, Table 3 counts all 149 DTU mutants as injected vulnerabilities and reports recall 0.100, with 134 false negatives. The paper explicitly says the constructor-based mutants are not exploitable, yet they remain in the denominator of the headline metric. This confirms that the ground-truth label is pattern adherence to the mutation operator, not a real security property, so the measured false-negative rate describes Slither's inconsistency on syntactic patterns rather than its failure to detect exploitable vulnerabilities.

full rationale

The paper's main derivation is empirical rather than mathematical: MuSe applies six pattern-based operators, and Table 3 reports Slither's recall on the resulting mutants. No parameter is fitted and no uniqueness theorem is imported from the authors' prior work, so this is not a case of a prediction being forced by a fit or by a self-citation chain. The circularity that does exist is in the definition of the ground-truth label. Section 4.2 states that a mutant is correctly detected if Slither labels it with the type of the injected vulnerability, and the injection is assumed correct by construction. Section 3.3 validates injection only by compilation, SuMo logs, pattern adherence, and modification correctness; it never checks exploitability. Thus Table 3's 0.597 recall measures how often Slither's detectors fire on syntactic patterns that the authors generated from, and mapped to, Slither's own detector descriptions. The DTU discussion makes the self-definition explicit: mutants in constructors are counted even though the paper says they cannot be exploitable. This makes the headline claim about 'vulnerabilities' partly self-referential, although the underlying measurement of Slither's inconsistency across syntactic contexts is still an empirical, reproducible result. The vulnerability selection also used Slither's detectability as a criterion (Section 3), further aligning the benchmark with the tool under test. These issues warrant a moderate circularity score of 4, not a higher score, because the dataset, operators, and robustness observations have independent content and the main limitation is openly disclosed in the paper.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claims rest on several domain assumptions about the correctness of the underlying parser (SuMo), the generalizability of the manual validation, the ability to compare Slither outputs before and after mutation, and the representativeness of the smartbugs-wild dataset. No free parameters are fitted to data, and no new entities are postulated.

assumptions (4)
  • domain assumption SuMo correctly parses Solidity and applies its existing mutation operators without introducing systematic errors.
    MuSe is built directly on SuMo and inherits its behavior; the paper acknowledges this as a threat to validity in Section 6.
  • domain assumption Manual validation of a 384-contract sample generalizes to all 350,493 generated mutants.
    The 5.21% failure rate from the sample is treated as the overall failure rate without applying it to the full dataset.
  • domain assumption Slither's detection before and after mutation, filtered by line numbers, correctly distinguishes the injected vulnerability from pre-existing issues.
    Used to compute TP/FN in Table 3; the method of mapping lines is described in Section 4.2 but not validated.
  • domain assumption The smartbugs-wild dataset is a representative sample of real-world smart contracts.
    Dataset chosen for its size and prior use; Section 6 acknowledges external validity threats.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Automated Vulnerability Injection in Solidity Smart Contracts: A Mutation-Based Approach for Benchmark Development." pith.science (2026). https://pith.science/paper/IY7M7Y3Y

@misc{pith2026250415948,
  author       = {Pith},
  title        = {Pith review of: Automated Vulnerability Injection in Solidity Smart Contracts: A Mutation-Based Approach for Benchmark Development},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IY7M7Y3Y}},
  note         = {Machine review of arXiv:2504.15948}
}
read the original abstract

The security of smart contracts is critical in blockchain systems, where even minor vulnerabilities can lead to substantial financial losses. Researchers proposed several vulnerability detection tools evaluated using existing benchmarks. However, most benchmarks are outdated and focus on a narrow set of vulnerabilities. This work evaluates whether mutation seeding can effectively inject vulnerabilities into Solidity-based smart contracts and whether state-of-the-art static analysis tools can detect the injected flaws. We aim to automatically inject vulnerabilities into smart contracts to generate large and wide benchmarks. We propose MuSe, a tool to generate vulnerable smart contracts by leveraging pattern-based mutation operators to inject six vulnerability types into real-world smart contracts. We analyzed these vulnerable smart contracts using Slither, a static analysis tool, to determine its capacity to identify them and assess their validity. The results show that each vulnerability has a different injection rate. Not all smart contracts can exhibit some vulnerabilities because they lack the prerequisites for injection. Furthermore, static analysis tools fail to detect all vulnerabilities injected using pattern-based mutations, underscoring the need for enhancements in static analyzers and demonstrating that benchmarks generated by mutation seeding tools can improve the evaluation of detection tools.

Figures

Figures reproduced from arXiv: 2504.15948 by the authors.

Figure 1
Figure 1. Summary of the Research Method. To achieve this goal, we developed MuSe, a tool to generate vulnerable smart contracts that are challenging to detect automati￾cally. Inspired by mutation testing [21, 29], we extended the SuMo mutation testing tool [2] to mutate Solidity smart contracts into vulnerable mutants. To this end, we implemented mutation oper￾ators designed to inject known vulnerabilities by modifying the s… view at source ↗
Figure 4
Figure 4. Two examples of unused return. (a) Unused return detected at line 10. 1 library SafeMath { 2 function add ( uint256 a , uint256 b ) internal pure returns ( uint256 ) { 3 uint256 c = a + b ; 4 require ( c >= a , " addition overflow ") ; 5 return c ; 6 } 7 } 8 contract SafeMathExample { 9 function addNumbers ( uint256 a , uint256 b ) public { 10 SafeMath . add (a , b ) ; 11 } 12 } (b) Unused return not detected at lin… view at source ↗
Figure 3
Figure 3. Clause with two conditions combined using OR. [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (1 more)
Figure 5
Figure 5. Figure 5: On the other hand, we noticed that most delegatecall functions are used in the constructor, which is invoked only at deployment time. Therefore, it is impossible to inject an instance of the vulnerability into the constructor that is exploitable. In addition, the deleg…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

43 extracted references · 25 canonical work pages

  1. [1]

    Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli. 2017. A survey of attacks on ethereum smart contracts (sok). In Principles of Security and Trust: 6th Interna- tional Conference, POST 2017, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2017, Uppsala, Sweden, April 22-29, 2017, Proceedings 6. Springer, 164–186

    work page 2017

  2. [2]

    Morena Barboni, Andrea Morichetta, and Andrea Polini. 2021. SuMo: A Mutation Testing Strategy for Solidity Smart Contracts. In 2021 IEEE/ACM International Conference on Automation of Software Test (AST) . 50–59. doi:10.1109/AST52587. 2021.00014

    work page arXiv 2021

  3. [3]

    Morena Barboni, Andrea Morichetta, and Andrea Polini. 2022. SuMo: A mutation testing approach and tool for the Ethereum blockchain. Journal of Systems and Software 193 (2022), 111445. doi:10.1016/j.jss.2022.111445

    arXiv 2022

  4. [4]

    Morena Barboni, Andrea Morichetta, Andrea Polini, and Francesco Casoni. 2024. ReSuMo: a regression strategy and tool for mutation testing of solidity smart contracts. Software Quality Journal 32, 1 (2024), 225–253

    work page 2024

  5. [5]

    Kent Beck. 2022. Test driven development: By example. Addison-Wesley Profes- sional

    work page 2022

  6. [6]

    Sofia Bobadilla, Monica Jin, and Martin Monperrus. 2025. Do Automated Fixes Truly Mitigate Smart Contract Exploits? arXiv preprint arXiv:2501.04600 (2025)

    work page arXiv 2025

  7. [7]

    Vitalik Buterin et al . 2014. Ethereum white paper: a next generation smart contract & decentralized application platform. First version 53 (2014)

    work page 2014

  8. [8]

    Patrick Chapman, Dianxiang Xu, Lin Deng, and Yin Xiong. 2019. Deviant: A Mutation Testing Tool for Solidity Smart Contracts. In2019 IEEE International Conference on Blockchain (Blockchain) . 319–324. doi:10.1109/Blockchain.2019. 00050

    work page doi:10.1109/blockchain.2019 2019

Show all 43 references
  1. [9]

    Ting Chen, Yuxiao Zhu, Zihao Li, Jiachi Chen, Xiaoqi Li, Xiapu Luo, Xiaodong Lin, and Xiaosong Zhange. 2018. Understanding Ethereum via Graph Analysis. In IEEE INFOCOM 2018 - IEEE Conference on Computer Communications . 1484–1492. doi:10.1109/INFOCOM.2018.8486401

    2018

  2. [10]

    Hanting Chu, Pengcheng Zhang, Hai Dong, Yan Xiao, and Shunhui Ji. 2024. SGDL: Smart contract vulnerability generation via deep learning. Journal of Software: Evolution and Process 36, 12 (2024), e2712

    2024

  3. [11]

    Etienne Daspe, Mathis Durand, Julien Hatin, and Salma Bradai. 2024. Bench- marking Large Language Models for Ethereum Smart Contract Development. 1–4. doi:10.1109/BRAINS63024.2024.10732686

    2024

  4. [12]

    Ferreira, and Gernot Salzer

    Monika di Angelo, Thomas Durieux, João F. Ferreira, and Gernot Salzer. 2023. SmartBugs 2.0: An Execution Framework for Weakness Detection in Ethereum Smart Contracts. In 38th IEEE/ACM International Conference on Automated Software Engineering (ASE) . IEEE Computer Society, 210...

    2023

  5. [13]

    Monika Di Angelo and Gernot Salzer. 2019. A survey of tools for analyzing ethereum smart contracts. In 2019 IEEE international conference on decentralized applications and infrastructures (DAPPCON). IEEE, 69–78

    2019

  6. [14]

    Ardit Dika and Mariusz Nowostawski. 2018. Security Vulnerabilities in Ethereum Smart Contracts. In 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) a...

    2018

  7. [15]

    Thomas Durieux, João F Ferreira, Rui Abreu, and Pedro Cruz. 2020. Empirical review of automated analysis tools on 47,587 ethereum smart contracts. In Pro- ceedings of the ACM/IEEE 42nd International conference on software engineering . 530–541

    2020

  8. [16]

    Josselin Feist, Gustavo Grieco, and Alex Groce. 2019. Slither: a static analysis framework for smart contracts. In 2019 IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB) . IEEE, 8–15

    2019

  9. [17]

    Asem Ghaleb and Karthik Pattabiraman. 2020. ‘. In Proceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis (Virtual Event, USA) (ISSTA 2020). Association for Computing Machinery, New York, NY, USA, 415–427. doi:10.1145/3395363.3397385

    2020

  10. [18]

    Ákos Hajdu, Naghmeh Ivaki, Imre Kocsis, Attila Klenik, László Gönczy, Nuno Laranjeiro, Henrique Madeira, and András Pataricza. 2020. Using Fault Injection to Assess Blockchain Systems in Presence of Faulty Smart Contracts. IEEE Access 8 (2020), 190760–190783. doi:10.1109/ACCES...

    2020

  11. [19]

    Gerardo Iuliano and Dario Di Nucci. 2024. Smart Contract Vulnerabil- ities, Tools, and Benchmarks: An Updated Systematic Literature Review. arXiv:2412.01719 [cs.SE] https://arxiv.org/abs/2412.01719

    2024

  12. [20]

    Ivanova and A

    Y. Ivanova and A. Khritankov. 2020. RegularMutator: A Mutation Testing Tool for Solidity Smart Contracts. Procedia Computer Science 178 (2020), 75–83. doi:10.1016/j.procs.2020.11.009 9th International Young Scientists Conference in Computational Science, YSC2020, 05-12 September 2020

    2020 doi

  13. [21]

    Yue Jia and Mark Harman. 2011. An Analysis and Survey of the Development of Mutation Testing. IEEE Trans. Softw. Eng. 37, 5 (Sept. 2011), 649–678. doi:10. 1109/TSE.2010.62

    2011

  14. [22]

    Bo Jiang, Ye Liu, and Wing Kwong Chan. 2018. Contractfuzzer: Fuzzing smart contracts for vulnerability detection. In Proceedings of the 33rd ACM/IEEE inter- national conference on automated software engineering . 259–269

    2018

  15. [23]

    Satpal Singh Kushwaha, Sandeep Joshi, Dilbag Singh, Manjit Kaur, and Heung-No Lee. 2022. Systematic Review of Security Vulnerabilities in Ethereum Blockchain Smart Contract. IEEE Access 10 (2022), 6605–6621. doi:10.1109/ACCESS.2021. 3140091

    2022 doi

  16. [24]

    Satpal Singh Kushwaha, Sandeep Joshi, Dilbag Singh, Manjit Kaur, and Heung-No Lee. 2022. Systematic review of security vulnerabilities in ethereum blockchain smart contract. IEEE Access 10 (2022), 6605–6621

    2022

  17. [25]

    Chao Liu, Han Liu, Zhao Cao, Zhong Chen, Bangdao Chen, and Bill Roscoe

  18. [26]

    Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor

  19. [27]

    Muhammad Izhar Mehar, Charles Louis Shier, Alana Giambattista, Elgar Gong, Gabrielle Fletcher, Ryan Sanayhie, Henry M Kim, and Marek Laskowski. 2019. Understanding a revolutionary and flawed grand experiment in blockchain: the DAO attack. Journal of Cases on Information Techno...

    2019

  20. [28]

    Alexander Mense and Markus Flatscher. 2018. Security vulnerabilities in ethereum smart contracts. In Proceedings of the 20th international conference on information integration and web-based applications & services . 375–380

    2018

  21. [29]

    Mike Papadakis, Marinos Kintis, Jie Zhang, Yue Jia, Yves Le Traon, and Mark Harman. 2019. Chapter Six - Mutation Testing Advances: An Analysis and Survey. Advances in Computers, Vol. 112. Elsevier, 275–378. doi:10.1016/bs.adcom.2018. 03.015

    2019 doi

  22. [30]

    Reza M Parizi, Ali Dehghantanha, Kim-Kwang Raymond Choo, and Amritraj Singh. 2018. Empirical vulnerability analysis of automated smart contracts security testing on blockchains. arXiv preprint arXiv:1809.02702 (2018)

    2018 arXiv

  23. [31]

    Heidelinde Rameder, Monika Di Angelo, and Gernot Salzer. 2022. Review of automated vulnerability analysis of smart contracts on Ethereum. Frontiers in Blockchain 5 (2022), 814977

    2022

  24. [32]

    Meng Ren, Zijing Yin, Fuchen Ma, Zhenyang Xu, Yu Jiang, Chengnian Sun, Huizhong Li, and Yan Cai. 2021. Empirical evaluation of smart contract testing: What is the best choice?. In Proceedings of the 30th ACM SIGSOFT international symposium on software testing and analysis . 566–579

    2021

  25. [33]

    Noama Fatima Samreen and Manar H Alalfi. 2021. Smartscan: an approach to detect denial of service vulnerability in ethereum smart contracts. In 2021 IEEE/ACM 4th International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB). IEEE, 17–26

    2021

  26. [34]

    Sarwar Sayeed, Hector Marco-Gisbert, and Tom Caira. 2020. Smart contract: Attacks and protections. Ieee Access 8 (2020), 24416–24427

    2020

  27. [35]

    Fabian Schär. 2021. Decentralized finance: On blockchain-and smart contract- based financial markets. FRB of St. Louis Review (2021)

    2021

  28. [36]

    Fernando Richter Vidal, Naghmeh Ivaki, and Nuno Laranjeiro. 2024. OpenSCV: an open hierarchical taxonomy for smart contract vulnerabilities. Empirical Software Engineering 29, 4 (2024), 101

    2024

  29. [37]

    Xiaoyin Wang, Jiaze Sun, Chunyang Hu, Panpan Yu, Bin Zhang, and Donghai Hou. 2022. EtherFuzz: mutation fuzzing smart contracts for TOD vulnerabil- ity detection. Wireless Communications and Mobile Computing 2022, 1 (2022), 1565007

    2022

  30. [38]

    Oualid Zaazaa and Hanan El Bakkali. 2023. A systematic literature review of undiscovered vulnerabilities and tools in smart contract technology. Journal of Intelligent Systems 32 (09 2023). doi:10.1515/jisys-2023-0038

    2023 doi

  31. [39]

    Zibin Zheng, Jianzhong Su, Jiachi Chen, David Lo, Zhijie Zhong, and Mingxi Ye

  32. [40]

    Weiqin Zou, David Lo, Pavneet Singh Kochhar, Xuan-Bach Dinh Le, Xin Xia, Yang Feng, Zhenyu Chen, and Baowen Xu. 2021. Smart Contract Development: Challenges and Opportunities. IEEE Transactions on Software Engineering 47, 10 (2021), 2084–2106. doi:10.1109/TSE.2019.2942301

    2021

  33. [2016]

    In Proceedings of the 2016 ACM SIGSAC conference on computer and communications security

    Making smart contracts smarter. In Proceedings of the 2016 ACM SIGSAC conference on computer and communications security . 254–269

    2016

  34. [2018]

    In Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings

    Reguard: finding reentrancy bugs in smart contracts. In Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings . 65–68

  35. [2024]

    IEEE Trans

    DAppSCAN: Building Large-Scale Datasets for Smart Contract Weaknesses in DApp Projects. IEEE Trans. Softw. Eng. 50, 6 (June 2024), 1360–1373. doi:10. 1109/TSE.2024.3383422

    2024

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.