Pith. sign in

REVIEW 6 major objections 5 minor 51 references

LLAMA: Multi-Feedback Smart Contract Fuzzing Framework with LLM-Guided Seed Generation

T0 review · 6 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read LLAMA, a smart contract fuzzer integrating LLM-generated seeds, multi-feedback optimization, and selective symbolic execution, reports 89% vulnerability detection and top coverage.

desk verdict A plausible LLM-guided fuzzing framework with a genuine adaptive mutation-scheduling tweak, but the headline results aren't trustworthy until the authors ship the artifact and address LLM contamination. read the letter →

arxiv 2507.12084 v1 pith:5P5GJAUP submitted 2025-07-16 cs.SE cs.CR

Keke Gai , Haochen Liang , Jing Yu , Liehuang Zhu , Dusit Niyato This is my paper
classification cs.SEcs.CR
keywords smartcontractfuzzingLLM-guidedseedgenerationmulti-feedbackoptimizationevolutionarymutationschedulinghybridsymbolicexecutionvulnerabilitydetectionEthereum
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

LLAMA is a smart contract fuzzing framework that closes the loop between LLM-generated initial seeds and runtime coverage, dependency, and vulnerability feedback across all three fuzzing stages: seed generation, seed selection, and mutation scheduling. The paper's central claim is that this combination beats current state-of-the-art fuzzers: 91% instruction coverage and 90% branch coverage on small contracts, 81% branch and 79% instruction coverage on large contracts, and 132 of 148 known vulnerabilities detected (89%) against ConFuzzius's 71%. A sympathetic reader would take away that treating mutation scheduling as an evolvable, feedback-driven population rather than a fixed or uniform policy is the under-explored lever that most improves smart contract fuzzing. The paper's ablation study supports this by showing that removing the multi-feedback optimization module causes the largest drop in long-term coverage.

What carries the argument

The carrying object is a closed-loop feedback chain. The LSG module uses a five-layer hierarchical prompt (functional abstraction, transaction-sequence inference, format verification, semantic optimization, and behavior-guided prompt injection) to produce seeds, then a lightweight pre-fuzzing pass scores each seed by Eq. (1), $Score = Coverage + \lambda \cdot Exception$, and keeps the top-$K$ by Eq. (2). The MOS module maintains a population $P$ of seeds with fitness $fit(i) = \Delta branch(i) + \Delta inst(i) + \Delta RAW(i)$, and treats the mutation operators themselves as an evolving population: each operator receives proportional credit $fit(j)^+ = (1/|J_i'|)(\Delta branch + \Delta inst)$, and selection probabilities are updated with Gaussian perturbation (Eqs. (4)-(5)). The HFE module runs a genetic engine with RAW-aware crossover and ten mutation operators, and triggers symbolic execution only when coverage growth stays below a threshold. Together they turn every fuzz iteration's feedback into the next iteration's seeds, selection probabilities, and prompts.

What would settle it

Hold out a random split of Dataset 2 that the LLM has provably never seen in training, re-run LLAMA on that split, and compare the generated seed transaction sequences against the dataset's annotated exploit sequences: if the seeds reproduce the exploit transactions nearly verbatim, or if the detection gap over ConFuzzius collapses to near zero on held-out contracts, then the reported 89% detection rate is inflated by training-data memorization rather than by LLAMA's feedback mechanisms.

Watch

Extended reading notes

Core claim

The paper claims that effective smart contract fuzzing comes from integrating three mechanisms rather than from any single one: hierarchical LLM prompting that turns contract source into semantically valid transaction-sequence seeds, a multi-feedback optimizer that scores seeds by branch gain, instruction gain, and read-after-write dependencies and adjusts mutation operator probabilities accordingly, and a hybrid engine that invokes symbolic execution only when coverage stalls. On its benchmark datasets it reports the highest instruction and branch coverage among the compared fuzzers, detecting 132 of 148 annotated vulnerabilities with zero false positives on the Dataset 2 tool comparison, including 100% detection on seven vulnerability types. The abstract states 91% instruction coverage and 90% branch coverage, while Section V-B reports the reverse pairing on small contracts; the magnitude is the same either way.

Load-bearing premise

The benchmark results depend on the language model not having memorized the test contracts during training, and the paper never names the model, publishes its prompts, or checks for contamination; if the model already knows the vulnerable contracts, the 'generated' seeds are recalled examples and the comparison with other fuzzers is not a fair test of the method.

Editorial extensions

If this is right

  • If LLAMA's numbers hold, fuzzers should stop choosing mutation operators with uniform probabilities and instead evolve those probabilities from coverage feedback, since the ablation shows the multi-feedback optimization module causes the largest coverage drop when removed.
  • LLM-generated seeds combined with a lightweight pre-fuzzing filter can compress the time to high coverage, so seed-generation quality becomes a first-class design axis for smart contract fuzzers.
  • Selective symbolic execution, triggered only at coverage stagnation, offers a resource-cheap way to keep hybrid fuzzing effective: LLAMA reports near-ConFuzzius overhead while exceeding its vulnerability detection.
  • Supporting all three mutation families (arguments, environmental properties, transaction-sequence reordering) lets one fuzzer cover more vulnerability classes than tools restricted to one or two families.
  • Because LLAMA reports 100% detection on seven of ten benchmark vulnerability types, the method is a plausible template for vulnerability-specific detectors, not just a general coverage booster.

Reading between the lines

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

  • Beyond the paper's claims: because the ablation shows the largest coverage drop when the multi-feedback optimizer is removed, the practical core of LLAMA may be the evolutionary mutation scheduler; a version with a cheap non-LLM seed generator would reveal how much of the reported gain is genuinely attributable to LLM seeds versus the feedback loop.
  • Another unstated consequence is that the multi-feedback architecture should transfer to fuzzing other stateful protocols, such as DeFi lending pools or cross-chain bridges, where valid transaction ordering and inter-call state dependencies matter as much as single-transaction coverage.
  • The paper does not evaluate on modern Solidity versions or compiler optimizations, so the reported coverage and detection rates should be treated as benchmark-specific until re-run on newer contracts.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

6 major / 5 minor

Summary. This manuscript proposes LLAMA, a hybrid fuzzing framework for Ethereum smart contracts that combines LLM-based hierarchical seed generation, a multi-feedback optimization module that adapts seed selection and mutation-operator scheduling, and a genetic fuzzing engine with selective symbolic execution. The central empirical claims are that LLAMA achieves 91% branch and 90% instruction coverage on small contracts, 81%/79% on large contracts, and detects 132 of 148 known vulnerabilities (89%) on a ConFuzzius-derived benchmark, outperforming ConFuzzius, sFuzz, ILF, and several static analyzers. Ablation studies attribute the gains to the three main modules, and resource-consumption comparisons are reported.

Significance. If the reported results are correct, LLAMA would be a meaningful advance: it explicitly targets mutation-operator scheduling, a phase rarely optimized in prior smart-contract fuzzers, and the 132/148 detection rate with zero reported false positives would place it above published baselines. The framework design is coherent and the claims are falsifiable in principle. However, the evidence as presented is not yet reproducible: the LLM is unnamed, prompt templates and decoding details are absent, no contamination check is described for a public benchmark that may appear in LLM pre-training data, and the headline numbers are point estimates without variance measures or statistical tests. The absence of a code or artifact release compounds these problems. The use of coverage feedback as both a guidance signal and an evaluation metric is standard for coverage-guided fuzzing and is not by itself a flaw; the missing experimental rigor is the load-bearing concern.

major comments (6)
  1. [V-B, Figs. 6-7] The headline coverage results are presented as single point values (Section V-B: 91% branch and 90% instruction coverage for small contracts; 81% and 79% for large contracts) with no error bars, confidence intervals, or statistical tests, and the number of independent runs is not reported. LLAMA and the baselines have stochastic components, including LLM sampling, the Gaussian perturbation in Eq. (5), genetic mutation, and dynamic symbolic solving, so the claimed margins over ConFuzzius and other tools cannot be separated from run-to-run variation. Please report the number of runs and provide median/IQR or confidence intervals together with a paired significance test for both coverage and vulnerability counts.
  2. [IV-A, V-A] The LLM used in the LSG module is never identified, the prompt templates are not given, and no contamination check is described for Dataset 2, which consists of 136 public ConFuzzius benchmark contracts with 148 annotated vulnerabilities. Public Solidity contracts of this kind are common in LLM pre-training corpora, so the LLM may have memorized the contracts or their known vulnerabilities; in that case the generated seeds are retrieved from memory rather than synthesized from understanding, and the comparison against non-LLM fuzzers would be unfair. Please name the exact model and version, provide the prompts and decoding parameters, and perform a contamination control such as evaluating on contracts published after the model cutoff or on a held-out private benchmark that was never released online.
  3. [V-A, Table II] The dataset descriptions are internally inconsistent. The text says Dataset 3 consists of 500 small and 100 large contracts randomly selected from Dataset 1, but Table II lists Dataset 3 as 155 contracts from SmartBugs and the SWC registry and separately lists a 600-contract Dataset 4 from MuFuzz, ConFuzzius, VeriSmart, and TMP. The ablation study in Section V-E uses 500 small and 100 large contracts, which matches Table II's Dataset 4 rather than Dataset 3 as described in the text. Please reconcile the text and table and state exactly which contracts were used for each experiment.
  4. [V-C, Table III] The paper does not describe how true positives and false positives were validated; the text only states that dedicated detectors were defined for each vulnerability type. Given that LLAMA is credited with zero false positives across all 132 detections, a concrete validation protocol is needed, such as manual confirmation, exploitability checking, or cross-checking against the benchmark's ground-truth annotations. In addition, the table header contains a duplicated 'Securify' column, once under Static Analyzers and once under Fuzzers, although Securify is not a fuzzer; this makes the column mapping ambiguous and should be corrected.
  5. [IV-B2, Eq. (5)] The mutation-operator probability update is not a valid probability distribution as written. Eq. (5) computes P^{t+1}(j) = fit(j)/sum_k fit(k) + N(0, sigma^2), and Algorithm 2 then clamps each value to [0.05, 0.95], but neither addition of Gaussian noise nor separate clamping preserves the constraint that the probability vector sums to 1, which is required for the subset sampling in Algorithm 2. Please specify the sampling procedure explicitly, for example by using a softmax with temperature or by renormalizing after adding noise.
  6. [V-C] The text states that for unhandled exception vulnerabilities LLAMA detected 63 vulnerabilities, 'representing a 23% increase in detection' compared to ConFuzzius, which detected 46. The relative increase is 63/46 - 1 = 37%, and the absolute increase is 17 detections, which is 23% of the total of 75. Please state which quantity is meant and correct the wording.
minor comments (5)
  1. [IV-C2] The phrase 'In order to address address issues' contains a duplicated word and should read 'In order to address issues'.
  2. [IV-E] The word 'bybrid' in Section IV-E should be 'hybrid'.
  3. [IV-B1, V-A] The stagnation threshold is described inconsistently: Algorithm 1 says 'No coverage improvement in 5 iterations', Section IV-B1 says 'less than 1% coverage growth over five consecutive generations', and Section V-A says 'When code coverage did not increase within 10 generations'. Please use a single precise definition.
  4. [Table IV] Securify is classified as a Fuzzer in Table IV even though it is a static analyzer throughout the rest of the paper; please correct the tool type.
  5. [V-A] The experiment setup does not state how many runs were performed for any tool or whether the reported curves and resource-consumption figures come from a single representative run; this belongs in the experimental configuration.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: LLAMA's coverage and detection claims are measured against external benchmarks with external baselines, and the feedback metrics used to guide fuzzing coincide with the evaluation metrics only through the standard coverage-guided paradigm, not by an equation-level reduction.

full rationale

LLAMA's central claims are empirical evaluations against external benchmarks with external baselines, and no load-bearing step reduces, by the paper's own equations or citations, to its own inputs. The headline coverage values in Section V-B (91% branch coverage, 90% instruction coverage) are measured totals of covered branches and EVM instructions, whereas the quantities that guide the search are different objects: Eq. (3) fit(i) = Δbranch + Δinst + ΔRAW, Eq. (4) operator credit, and Algorithm 2 line 31 all score incremental, per-candidate gains used to rank seeds and mutation operators, not the final reported totals. The optimization objective (new coverage) and the reported metric (total coverage) coincide in the standard coverage-guided fuzzing paradigm shared by the baselines sFuzz, ConFuzzius, and ILF, so the reported superiority is an empirical outcome and not a number forced by construction. No parameter is fitted to a subset of data and then relabeled as a prediction: λ, ρ, γ, and σ² in Eqs. (1), (2), and (5) are hand-chosen constants, and the Top-K, elite-ratio, and stagnation thresholds are stated design choices. There are no load-bearing self-citations; the paper cites external prior work (MuFuzz [13], ConFuzzius [32], ILF [31], et al.), and no uniqueness theorem or ansatz is imported from the authors' own publications. Two validity risks are worth noting but are not circular reductions: first, Section IV-A feeds target contract source through an unnamed LLM while Section V-A evaluates on the public ConFuzzius-derived Dataset 2 of 136 contracts with 148 annotated vulnerabilities, and the paper neither names the model nor reports a contamination check, so LLM memorization of the benchmark is an unverified external threat to the numbers' meaning rather than a circular step demonstrated in the text; second, the threat model in Section III-B assumes adversaries lack source code while Section IV-A's seed generation prompts over source code, an internal-consistency concern that does not constitute circularity. Verdict: no significant circularity; score 0.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

The central claim depends on a set of hand-chosen hyperparameters in the scoring functions and a set of unverified assumptions about the LLM, the ground truth, and the execution environment. The most fragile is the implicit assumption that the LLM has not memorized the benchmark contracts.

free parameters (6)
  • lambda (exception boost) = not specified
    In Eq. (1), lambda is a positive constant that boosts seeds triggering exceptions; the value is not given and no sensitivity analysis is reported.
  • rho (seed retention ratio) = not specified
    In Eq. (2), rho in (0,1) determines the fraction of LLM-generated seeds retained; its value affects which seeds initialize the pool.
  • K_max (seed pool upper bound) = not specified
    In Eq. (2), K_max caps the seed pool size; its value is not given.
  • gamma (elite retention ratio) = not specified
    In Algorithm 1, gamma selects the top fraction of the population for crossover; its value is not given.
  • sigma^2 (Gaussian noise variance) = not specified
    In Eq. (5), sigma squared is added to operator probability updates to balance exploration and exploitation; its value is not given.
  • stagnation thresholds = 5 iterations, <1% coverage growth, 10 generations
    The conditions for triggering symbolic execution and population reinitialization are hand-chosen and not ablated in the paper.
assumptions (5)
  • domain assumption EVM execution semantics in the test environment match real Ethereum behavior
    The paper assumes the isolated EVM with solc-0.4.26 faithfully reproduces contract behavior, as described in Section V-A experiment configuration.
  • domain assumption Dataset 2 vulnerability annotations are correct and complete
    The evaluation treats the 148 annotated vulnerabilities as ground truth; the paper relies on ConFuzzius's dataset without independent verification.
  • domain assumption The LLM used for seed generation has not memorized the benchmark contracts
    The LLM is never identified, and no contamination check is described in Section IV-A or V-A; the entire seed-generation advantage depends on this assumption.
  • domain assumption Bug oracles in Table I correctly identify true vulnerabilities
    True and false positive counts are reported, but the validation procedure is not described; the oracle definitions are taken as correct.
  • domain assumption Semi-honest module behavior
    Section III-B assumes the seed generation, multi-feedback, and hybrid engine modules do not interfere with contract state; this underpins the security analysis.

how reviews work

0 comments
Cite this review

Pith. "Pith review of LLAMA: Multi-Feedback Smart Contract Fuzzing Framework with LLM-Guided Seed Generation." pith.science (2026). https://pith.science/paper/5P5GJAUP

@misc{pith2026250712084,
  author       = {Pith},
  title        = {Pith review of: LLAMA: Multi-Feedback Smart Contract Fuzzing Framework with LLM-Guided Seed Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5P5GJAUP}},
  note         = {Machine review of arXiv:2507.12084}
}
read the original abstract

Smart contracts play a pivotal role in blockchain ecosystems, and fuzzing remains an important approach to securing smart contracts. Even though mutation scheduling is a key factor influencing fuzzing effectiveness, existing fuzzers have primarily explored seed scheduling and generation, while mutation scheduling has been rarely addressed by prior work. In this work, we propose a Large Language Models (LLMs)-based Multi-feedback Smart Contract Fuzzing framework (LLAMA) that integrates LLMs, evolutionary mutation strategies, and hybrid testing techniques. Key components of the proposed LLAMA include: (i) a hierarchical prompting strategy that guides LLMs to generate semantically valid initial seeds, coupled with a lightweight pre-fuzzing phase to select high-potential inputs; (ii) a multi-feedback optimization mechanism that simultaneously improves seed generation, seed selection, and mutation scheduling by leveraging runtime coverage and dependency feedback; and (iii) an evolutionary fuzzing engine that dynamically adjusts mutation operator probabilities based on effectiveness, while incorporating symbolic execution to escape stagnation and uncover deeper vulnerabilities. Our experiments demonstrate that LLAMA outperforms state-of-the-art fuzzers in both coverage and vulnerability detection. Specifically, it achieves 91% instruction coverage and 90% branch coverage, while detecting 132 out of 148 known vulnerabilities across diverse categories. These results highlight LLAMA's effectiveness, adaptability, and practicality in real-world smart contract security testing scenarios.

Figures

Figures reproduced from arXiv: 2507.12084 by the authors.

Figure 1
Figure 1. LLM-based seed generation. fuzzer’s costs in CPU and memory usage. The rest of this paper is organized in the following order. Section II reviews related work. Section III provides design goals, threat model, and key concepts. Sections IV and V details the proposed approach and exhibits experiments eval￾uations, respectively. Finally, Section VI concludes this work. II. RELATED WORK A. LLM-Based Smart Contract Fuzzi… view at source ↗
Figure 2
Figure 2. Traditional smart contract fuzzing workflow. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Architecture of the proposed LLAMA. B. Threat Model Adversary’s objective: Attackers aim to exploit potential vulnerability logic within the contract by making specific in￾puts or interaction flows to carry out illegal activities, including unauthorized access, asset theft, or state manipulation. Adversary’s Knowledge: Attackers have a complete knowl￾edge of the contract interfaces, including bytecode, ABI speci￾fic… view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: LLM-based seed generation in LLAMA. environment to quickly collect basic execution metrics, e.g., instruction-level coverage, call depth, and exception states. This process is efficient for ranking large amounts of seeds, as it excludes deep symbolic reasoning or heavy…
Figure 5
Figure 5. Figure 5: Illustration of the evolutionary scheduling process for [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Branch and instruction coverage comparison on small and large contracts. [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Overall coverage comparison The results depicted that LLAMA achieved the highest coverage on both large and small contracts, demonstrating its superior capability in detecting vulnerabilities. Specifically, for small contracts, the branch coverage reached 91%, and the …
Figure 9
Figure 9. Figure 9: Branch and instruction coverage comparison on small and large contracts. [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]
Figure 10
Figure 10. Figure 10: Overall ablation study. the slight overhead was due to the integration of LSG and MOS modules. Our evaluations showed that LLAMA’s cost was negligible and within an acceptable limit, significantly lower than other approaches, demonstrating a great balance between perf…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

51 extracted references · 50 canonical work pages

  1. [1]

    An overview on smart contracts: Challenges, advances and platforms,

    Z. Zheng, S. Xie, H.-N. Dai, W. Chen, X. Chenet al., “An overview on smart contracts: Challenges, advances and platforms,”Future Generation Computer Systems, vol. 105, pp. 475–491, 2020

    work page 2020

  2. [2]

    Blockchain smart contracts: Applications, challenges, and future trends,

    S. N. Khan, F. Loukil, C. Ghedira-Guegan, E. Benkhelifa, and A. Bani- Hani, “Blockchain smart contracts: Applications, challenges, and future trends,”Peer-to-peer Netw. and App., vol. 14, pp. 2901–2925, 2021. 13

    work page 2021

  3. [3]

    Challenges and common solutions in smart contract development,

    N. Kannengiesser, S. Lins, C. Sander, K. Winteret al., “Challenges and common solutions in smart contract development,”IEEE Trans. on Software Eng., vol. 48, no. 11, pp. 4291–4318, 2021

    work page 2021

  4. [4]

    A survey on smart contract vulnerabilities: Data sources, detection and repair,

    H. Chu, P. Zhang, H. Dong, Y . Xiaoet al., “A survey on smart contract vulnerabilities: Data sources, detection and repair,”Info. & Software Tech., vol. 159, p. 107221, 2023

    work page 2023

  5. [5]

    Understanding a revolutionary and flawed grand experiment in blockchain: the dao attack,

    M. I. Mehar, C. L. Shier, A. Giambattista, E. Gong, G. Fletcher et al., “Understanding a revolutionary and flawed grand experiment in blockchain: the dao attack,”J. of Cases on Infor. Tech., vol. 21, no. 1, pp. 19–32, 2019

    work page 2019

  6. [6]

    Vulnerability detection techniques for smart contracts: A systematic literature review,

    F. R. Vidal, N. Ivaki, and N. Laranjeiro, “Vulnerability detection techniques for smart contracts: A systematic literature review,”Journal of Systems and Software, p. 112160, 2024

    work page 2024

  7. [7]

    Fuzzing: a survey,

    J. Li, B. Zhao, and C. Zhang, “Fuzzing: a survey,”Cybersecurity, vol. 1, pp. 1–13, 2018

    work page 2018

  8. [8]

    Adversarial generation method for smart contract fuzz testing seeds guided by chain- based llm,

    J. Sun, Z. Yin, H. Zhang, X. Chen, and W. Zheng, “Adversarial generation method for smart contract fuzz testing seeds guided by chain- based llm,”Auto. Software Eng., vol. 32, no. 1, pp. 1–28, 2025

    work page 2025

Show all 51 references
  1. [9]

    Codamosa: Escaping coverage plateaus in test generation with pre-trained large language models,

    C. Lemieux, J. P. Inala, S. K. Lahiri, and S. Sen, “Codamosa: Escaping coverage plateaus in test generation with pre-trained large language models,” inIEEE/ACM 45th Int’l Conf. Software Eng.IEEE, 2023, pp. 919–931

    2023

  2. [10]

    Combining fine-tuning and llm-based agents for intuitive smart contract auditing with justifications,

    W. Ma, D. Wu, Y . Sun, T. Wang, S. Liu, J. Zhang, Y . Xue, and Y . Liu, “Combining fine-tuning and llm-based agents for intuitive smart contract auditing with justifications,”arXiv preprint arXiv:2403.16073, 2024

    2024 arXiv

  3. [11]

    Large language model guided protocol fuzzing,

    R. Meng, M. Mirchev, M. B ¨ohme, and A. Roychoudhury, “Large language model guided protocol fuzzing,” inProceedings of the 31st Ann’l Netw. and Distr. Sys. Security Symp., vol. 2024, 2024

    2024

  4. [12]

    Fuzz4all: Universal fuzzing with large language models,

    C. S. Xia, M. Paltenghi, J. Le Tian, M. Pradel, and L. Zhang, “Fuzz4all: Universal fuzzing with large language models,” inIEEE/ACM 46th Int’l Conf. on Software Eng., 2024, pp. 1–13

    2024

  5. [13]

    MuFuzz: sequence- aware mutation and seed mask guidance for blockchain smart contract fuzzing,

    P. Qian, H. Wu, Z. Du, T. Vural, D. Ronget al., “MuFuzz: sequence- aware mutation and seed mask guidance for blockchain smart contract fuzzing,” in40th Int’l Conf. on Data Eng.IEEE, 2024, pp. 1972–1985

    2024

  6. [14]

    Fuzzing: a survey for roadmap,

    X. Zhu, S. Wen, S. Camtepe, and Y . Xiang, “Fuzzing: a survey for roadmap,”ACM Computing Surveys, vol. 54, no. 11s, pp. 1–36, 2022

    2022

  7. [15]

    Are we there yet? unraveling the state-of-the-art smart contract fuzzers,

    S. Wu, Z. Li, L. Yan, W. Chen, M. Jianget al., “Are we there yet? unraveling the state-of-the-art smart contract fuzzers,” inProceedings of the IEEE/ACM 46th Int’l Conf. on Software Eng., 2024, pp. 1–13

    2024

  8. [16]

    Seed selection for successful fuzzing,

    A. Herrera, H. Gunadi, S. Magrath, M. Norrishet al., “Seed selection for successful fuzzing,” in30th ACM SIGSOFT Int’l Symp. Software Testing & Analysis, 2021, pp. 230–243

    2021

  9. [17]

    Testing smart contracts gets smarter,

    E. Andesta, F. Faghih, and M. Fooladgar, “Testing smart contracts gets smarter,” in10th Int’l Conf. Comp. Know. Eng.IEEE, 2020, pp. 405– 412

    2020

  10. [18]

    sfuzz: An efficient adaptive fuzzer for solidity smart contracts,

    T. D. Nguyen, L. H. Pham, J. Sun, Y . Lin, and Q. T. Minh, “sfuzz: An efficient adaptive fuzzer for solidity smart contracts,” inACM/IEEE 42nd Int’l Conf. on Software Eng., 2020, pp. 778–788

    2020

  11. [19]

    Smartian: Enhancing smart contract fuzzing with static and dynamic data-flow analyses,

    J. Choi, D. Kim, S. Kim, G. Griecoet al., “Smartian: Enhancing smart contract fuzzing with static and dynamic data-flow analyses,” in36th IEEE/ACM Int’l Conf. Auto. Software Eng.IEEE, 2021, pp. 227–239

    2021

  12. [20]

    Increasing fuzz testing coverage for smart contracts with dynamic taint analysis,

    S. Ji, J. Dong, J. Qiu, B. Guet al., “Increasing fuzz testing coverage for smart contracts with dynamic taint analysis,” in21st Int’l Conf. Software Quality, Reliability and Security. IEEE, 2021, pp. 243–247

    2021

  13. [21]

    Securify: Practical security analysis of smart contracts,

    P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervaiset al., “Securify: Practical security analysis of smart contracts,” inACM SIGSAC Conf. Comp. & Comm. Sec., 2018, pp. 67–82

    2018

  14. [22]

    Smartcheck: Static analysis of ethereum smart contracts,

    S. Tikhomirov, E. V oskresenskaya, I. Ivanitskiy, R. Takhavievet al., “Smartcheck: Static analysis of ethereum smart contracts,” in1st Int’l WKSP Emerging Trends Software Eng. for Blockchain, 2018, pp. 9–16

    2018

  15. [23]

    Contractward: Automated vulnerability detection models for ethereum smart contracts,

    W. Wang, J. Song, G. Xu, Y . Liet al., “Contractward: Automated vulnerability detection models for ethereum smart contracts,”IEEE Trans. Netw. Sci. & Eng., vol. 8, no. 2, pp. 1133–1144, 2020

    2020

  16. [24]

    Manticore: A user-friendly symbolic execution framework for binaries and smart contracts,

    M. Mossberg, F. Manzano, E. Hennenfent, A. Groceet al., “Manticore: A user-friendly symbolic execution framework for binaries and smart contracts,” in34th IEEE/ACM Int’l Conf. Auto. Software Eng.IEEE, 2019, pp. 1186–1189

    2019

  17. [25]

    Zeus: analyzing safety of smart contracts

    S. Kalra, S. Goel, M. Dhawan, and S. Sharma, “Zeus: analyzing safety of smart contracts.” inNDSS, 2018, pp. 1–12

    2018

  18. [26]

    Slither: a static analysis framework for smart contracts,

    J. Feist, G. Grieco, and A. Groce, “Slither: a static analysis framework for smart contracts,” inIEEE/ACM 2nd Int’l WKSP Emerging Trends in Software Eng. for Blockchain. IEEE, 2019, pp. 8–15

    2019

  19. [27]

    Ityfuzz: Snapshot-based fuzzer for smart contract,

    C. Shou, S. Tan, and K. Sen, “Ityfuzz: Snapshot-based fuzzer for smart contract,” in32nd ACM SIGSOFT Int’l Symp. Software Testing & Analysis, 2023, pp. 322–333

    2023

  20. [28]

    Reguard: finding reentrancy bugs in smart contracts,

    C. Liu, H. Liu, Z. Cao, Z. Chenet al., “Reguard: finding reentrancy bugs in smart contracts,” in40th Int’l Conf. Software Eng.: Companion Proceeedings, 2018, pp. 65–68

    2018

  21. [29]

    xfuzz: Machine learning guided cross-contract fuzzing,

    Y . Xue, J. Ye, W. Zhang, J. Sunet al., “xfuzz: Machine learning guided cross-contract fuzzing,”IEEE Trans. Dependable & Sec. Comp., vol. 21, no. 2, pp. 515–529, 2022

    2022

  22. [30]

    A systematic literature review of blockchain and smart contract development: Tech- niques, tools, and open challenges,

    A. Vacca, A. Di Sorbo, C. A. Visaggio, and G. Canfora, “A systematic literature review of blockchain and smart contract development: Tech- niques, tools, and open challenges,”J. Sys. & Software, vol. 174, p. 110891, 2021

    2021

  23. [31]

    Learning to fuzz from symbolic execution with application to smart contracts,

    J. He, M. Balunovi ´c, N. Ambroladze, P. Tsankov, and M. Vechev, “Learning to fuzz from symbolic execution with application to smart contracts,” inACM SIGSAC Conf. Comp. Comm. Sec., 2019, pp. 531– 548

    2019

  24. [32]

    Confuzzius: A data dependency-aware hybrid fuzzer for smart contracts,

    C. F. Torres, A. K. Iannillo, A. Gervais, and R. State, “Confuzzius: A data dependency-aware hybrid fuzzer for smart contracts,” inIEEE Euro. Symp. Sec. & Privacy. IEEE, 2021, pp. 103–119

    2021

  25. [33]

    Effectively generating vulnerable transaction sequences in smart contracts with reinforcement learning-guided fuzzing,

    J. Su, H.-N. Dai, L. Zhao, Z. Zheng, and X. Luo, “Effectively generating vulnerable transaction sequences in smart contracts with reinforcement learning-guided fuzzing,” in37th IEEE/ACM Int’l Conf. Auto. Software Eng., 2022, pp. 1–12

    2022

  26. [34]

    Verismart: A highly precise safety verifier for ethereum smart contracts,

    S. So, M. Lee, J. Park, H. Lee, and H. Oh, “Verismart: A highly precise safety verifier for ethereum smart contracts,” inIEEE Symp. Sec. & Privacy. IEEE, 2020, pp. 1678–1694

    2020

  27. [35]

    Smart contract vulnerability detection using graph neural networks,

    Y . Zhuang, Z. Liu, P. Qian, Q. Liu, and ohters, “Smart contract vulnerability detection using graph neural networks,” in29th Int’l Joint Conf. Artificial Intell., 2021, pp. 3283–3290

    2021

  28. [36]

    Empirical review of automated analysis tools on 47,587 ethereum smart contracts,

    T. Durieux, J. F. Ferreira, R. Abreu, and P. Cruz, “Empirical review of automated analysis tools on 47,587 ethereum smart contracts,” in ACM/IEEE 42nd Int’l Conf. Software Eng., 2020, pp. 530–541

    2020

  29. [37]

    Swc registry,

    SmartContractSecurity, “Swc registry,” Available at https://swcregistry. io, 2020, accessed: 2024-03-17

    2020

  30. [38]

    Finding the greedy, prodigal, and suicidal contracts at scale,

    I. Nikoli ´c, A. Kolluri, I. Sergey, P. Saxena, and A. Hobor, “Finding the greedy, prodigal, and suicidal contracts at scale,” in34th Ann. Comp. Sec. App. Conf., 2018, pp. 653–663

    2018

  31. [39]

    Defectchecker: Automated smart contract defect detection by analyzing evm bytecode,

    J. Chen, X. Xia, D. Lo, J. Grundy, X. Luo, and T. Chen, “Defectchecker: Automated smart contract defect detection by analyzing evm bytecode,” IEEE Trans. Software Eng., vol. 48, no. 7, pp. 2189–2207, 2021

    2021

  32. [40]

    Mythril: A security analysis tool for evm bytecode,

    B. Mueller, “Mythril: A security analysis tool for evm bytecode,” https: //github.com/ConsenSys/mythril, 2017, accessed: 2024-10-26

    2017

  33. [41]

    Osiris: Hunting for integer bugs in ethereum smart contracts,

    C. F. Torres, J. Sch ¨utte, and R. State, “Osiris: Hunting for integer bugs in ethereum smart contracts,” in34th Ann. Comp. Sec. App. Conf., 2018, pp. 664–676

    2018

  34. [42]

    Making smart contracts smarter,

    L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contracts smarter,” inACM SIGSAC Conf. Comp. & Comm. Security, 2016, pp. 254–269

    2016

  35. [43]

    teEther: Gnawing at ethereum to automatically exploit smart contracts,

    J. Krupp and C. Rossow, “teEther: Gnawing at ethereum to automatically exploit smart contracts,” in27th USENIX Sec. Symp., 2018, pp. 1317– 1333

    2018

  36. [44]

    Contractfuzzer: Fuzzing smart contracts for vulnerability detection,

    B. Jiang, Y . Liu, and W. K. Chan, “Contractfuzzer: Fuzzing smart contracts for vulnerability detection,” in33rd ACM/IEEE Int’l Conf. Auto. Software Eng., 2018, pp. 259–269

    2018

  37. [45]

    Oracle-supported dynamic exploit generation for smart contracts,

    H. Wang, Y . Liu, Y . Li, S.-W. Linet al., “Oracle-supported dynamic exploit generation for smart contracts,”IEEE Trans. Dependable & Sec. Comp., vol. 19, no. 3, pp. 1795–1809, 2020

    2020

  38. [46]

    Echidna: effective, usable, and fast fuzzing for smart contracts,

    G. Grieco, W. Song, A. Cygan, J. Feist, and A. Groce, “Echidna: effective, usable, and fast fuzzing for smart contracts,” in29th ACM SIGSOFT Int’l Symp. Software Testing & analysis, 2020, pp. 557–560

    2020

  39. [47]

    Harvey: A greybox fuzzer for smart contracts,

    V . W ¨ustholz and M. Christakis, “Harvey: A greybox fuzzer for smart contracts,” in28th ACM Joint Meeting on Euro. Software Eng. Conf. & Symp. Foundations of Software Eng., 2020, pp. 1398–1409

    2020

  40. [48]

    Rethinking smart contract fuzzing: Fuzzing with invocation ordering and important branch revisiting,

    Z. Liu, P. Qian, J. Yang, L. Liuet al., “Rethinking smart contract fuzzing: Fuzzing with invocation ordering and important branch revisiting,”IEEE Trans. Info. Fore. & Sec., vol. 18, pp. 1237–1251, 2023

    2023

  41. [49]

    Smartgift: Learning to generate practical inputs for testing smart contracts,

    T. Zhou, K. Liu, L. Li, Z. Liuet al., “Smartgift: Learning to generate practical inputs for testing smart contracts,” inIEEE Int’l Conf. Software Maintenance and Evolution. IEEE, 2021, pp. 23–34

    2021

  42. [50]

    Soliaudit: Smart contract vulnerability assessment based on machine learning and fuzz testing,

    J.-W. Liao, T.-T. Tsai, C.-K. He, and C.-W. Tien, “Soliaudit: Smart contract vulnerability assessment based on machine learning and fuzz testing,” in6th Int’l Conf. IoT: Sys., Mngt. & Sec.IEEE, 2019, pp. 458–465

    2019

  43. [51]

    Syntest-solidity: Automated test case generation and fuzzing for smart contracts,

    M. Olsthoorn, D. Stallenberg, A. Van Deursen, and A. Panichella, “Syntest-solidity: Automated test case generation and fuzzing for smart contracts,” inACM/IEEE 44th Int’l Conf. Software Eng.: Companion Proc., 2022, pp. 202–206

    2022

Pith tools

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