Pith. sign in

REVIEW 4 major objections 5 minor 53 references

SAEL: Leveraging Large Language Models with Adaptive Mixture-of-Experts for Smart Contract Vulnerability Detection

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

Pith's one-line read SAEL claims that fusing an LLM's verdict and explanation with raw code through an adaptive mixture-of-experts gate outperforms all 12 compared smart-contract vulnerability detectors.

desk verdict A genuinely new fusion architecture with plausible SOTA numbers, but the evaluation needs serious cleanup before the empirical claims can be fully trusted. read the letter →

arxiv 2507.22371 v1 pith:VNBMQQPW submitted 2025-07-30 cs.CR cs.AIcs.SE

classification cs.CRcs.AIcs.SE
keywords smartcontractvulnerabilitydetectionlargelanguagemodelsadaptivemixture-of-expertsexplanationfeaturesprompttuninggatingnetworkreentrancytimestampdependence
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

SAEL argues that the best way to detect four common smart-contract vulnerabilities is to stop choosing between specialized detection models and general-purpose large language models, and instead feed all three signals—raw code, the LLM's verdict, and the LLM's free-text explanation—through an adaptive mixture-of-experts gate that learns which signal to trust for each contract. The motivation is complementary failure modes: specialized pre-trained models miss patterns their training data did not cover, while general-purpose LLMs understand new patterns but are less precise on well-defined vulnerability classes. The paper argues that LLM explanations carry fine-grained code understanding that can even contradict and correct an LLM's own wrong verdict, making explanation text a usable detection feature. Across reentrancy, timestamp dependence, integer overflow/underflow, and delegatecall, SAEL reports F1 scores of 94.29%, 92.60%, 83.16%, and 80.31%, each ahead of 12 baselines, and reports strong zero-shot F1 on 400 held-out contracts.

What carries the argument

The load-bearing mechanism is the Adaptive Mixture-of-Experts module. It concatenates three feature embeddings: $h_{raw}$ from prompt-tuned CodeT5 on source code, $h_{expl}$ from prompt-tuned T5 on LLM explanations, and $h_{pred}$ from the LLM's vulnerability prediction. A gating network applies a linear layer, TopK filtering with $k=3$, and Softmax normalization to produce a gating vector $G(x)$, while a multi-head self-attention layer models cross-feature interactions; the gating vector weights three expert outputs (raw code, explanation, prediction) to form the final prediction. The total loss is a weighted sum of per-feature cross-entropy, overall prediction cross-entropy, and a regularization term that keeps the learned weights near the gating weights. The prompt design also matters: vulnerability-specific prompts with chain-of-thought instructions plus a five-response mimic-in-the-background consensus are used to elicit the LLM outputs.

What would settle it

Take the exact test contracts used in Tables II and III, deduplicate them by normalized bytecode against the training split, and replace any contract whose source appeared on the public internet before the chosen LLM's training cutoff with a freshly deployed contract of the same vulnerability class; if the F1 gap over PSCVFinder and ReVulDL shrinks below the reported 2–9 points, the advantage is leakage or memorization rather than fusion.

Watch

Extended reading notes

Core claim

The paper's central discovery claim is that LLM-generated explanations are not just byproducts of prediction but load-bearing features: combining raw code embeddings, explanation embeddings, and LLM prediction embeddings beats any single feature, and the gain is largest when the three are combined through the proposed Adaptive Mixture-of-Experts rather than by simple averaging. The authors further claim that this integration generalizes beyond the training distribution: with no fine-tuning on the target samples, SAEL reaches 92.00% F1 on reentrancy, 89.60% on timestamp dependence, 83.70% on overflow/underflow, and 81.00% on delegatecall. They also claim that this is the first demonstration that explanation-based features and prompt-tuned CodeT5/T5 encoders can be jointly optimized with a learnable gating loss to set new state-of-the-art results.

Load-bearing premise

The results assume the public labels and the 3:1:1 split are clean, so no test contract or function replicates one the LLM or prompt-tuned encoders saw in training, and no label noise inflates the reported F1.

Editorial extensions

If this is right

  • Replacing static rules or a single fine-tuned model with a fused LLM-plus-code pipeline could raise automated audit recall on the four vulnerability classes that historically cause most financial losses.
  • LLM explanations can be treated as a first-class input signal for detection, so even when the LLM's binary verdict is wrong, its reasoning text remains useful to the classifier.
  • The zero-shot results imply the pipeline may flag new vulnerability patterns without task-specific labels, though with a drop in precision on delegatecall.
  • Because removing the MoE module hurts more than removing the LLM module, the dynamic gating itself—not just the extra features—carries part of the benefit.
  • The recipe of prompt-tuning two small encoders plus a gating network can be reproduced at a fraction of GPT-4 API cost because the chosen open-source LLM is comparatively cheap to run.

Reading between the lines

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

  • If the F1 gains survive a leakage-proof split—deduplicating by bytecode similarity and using contracts deployed after the LLM's training cutoff—the same three-channel fusion of code, verdict, and explanation could transfer to other code-analysis tasks with imbalanced labels, such as malicious-package detection.
  • The gating weights themselves are an unexploited diagnostic: inspecting when the model trusts explanation features over raw code could tell auditors which contracts most need human review, and could be turned into a confidence signal for flagging ambiguous cases.
  • A cheap variant worth testing: the paper's inference uses temperature 0, so the five mimic-in-the-background responses are deterministic and the consensus collapses to a single answer; sampling with temperature greater than 0 would test whether majority voting over diverse reasoning traces adds real robustness.
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

4 major / 5 minor

Summary. The paper proposes SAEL, a framework for smart contract vulnerability detection that combines three feature streams: raw contract code processed by prompt-tuned CodeT5, LLM-generated explanations processed by prompt-tuned T5, and LLM prediction outputs encoded as embeddings. These streams are integrated by an Adaptive Mixture-of-Experts module with a gating network, TopK filtering, and multi-head self-attention. The authors evaluate on reentrancy, timestamp dependence, integer overflow/underflow, and delegatecall, reporting state-of-the-art F1 scores over 12 baselines (e.g., 94.29% for reentrancy, 92.60% for timestamp dependence) and claiming strong zero-shot capability. Source code and data are said to be publicly available.

Significance. If the reported results hold, the paper makes a useful empirical contribution by demonstrating that LLM-generated explanations can serve as a complementary feature for vulnerability detection and by proposing an adaptive fusion mechanism. Strengths include comparison against a broad set of 12 baselines, ablation studies of the three feature types and the MoE module, a parameter-sensitivity analysis, and the public release of code and data. However, several load-bearing issues—notably the absence of a demonstrated contamination-free evaluation split, an inconsistency in the gating network's training objective, and the labeling of a trained model's cross-dataset evaluation as 'zero-shot'—mean the central SOTA claim is not yet verified.

major comments (4)
  1. [§IV.B, §IV.E, Table II] The evaluation protocol does not establish that test contracts are disjoint from training contracts at the identity level. A 3:1:1 split is described, but no hash-based deduplication, normalized-source deduplication, or overlap statistics are reported for SmartBugs Wild, ESC, or the mixed datasets [31],[32]. In addition, Qwen1.5-72B-Chat is queried on public contracts to produce hpred and hexpl, so if a test contract or near-duplicate appeared in the LLM's pretraining corpus, labels could leak into those features. Because the F1 margins over the strongest baselines in Table II are only 2.15 points (reentrancy) and 2.84 points (timestamp dependence), even modest leakage could reverse the ranking. Section VI lists internal and external validity threats but does not address this contamination risk. Please report contract/function-level deduplication, quantify remaining near-duplicates, and run a contamination check such as evaluating on contracts deployed after Qwen's knowledge cutoff or on contracts verified absent from pretraining data.
  2. [§III.C, Eqs. (5)–(13)] The gating network is not actually trained by the stated loss. Eq. (8) defines Ofinal = Σ G_i(x)·O_i, while Eq. (10) defines Ofinal = Σ w'_i·O_i, and the total loss in Eq. (13) depends only on w'_i, not on G(x) or H(x). No training objective or gradient path is given for the gating network's parameters; the TopK operation in Eq. (5) is non-differentiable, yet no straight-through estimator or alternative is described. As a result, the paper's central architectural claim that gradient optimization adaptively adjusts feature weights is not supported by the equations. Please clarify the relationship between G(x) and w', specify how G is optimized, and describe how gradients are obtained through TopK.
  3. [§IV.F, RQ4, Table III] The term 'zero-shot' is not accurate as used. The SAEL pipeline includes CodeT5/T5 prompt-tuned on the training portion and a trained MoE module; evaluating on 100 contracts per vulnerability from other datasets is out-of-distribution evaluation, not zero-shot learning. More importantly, the statement that selected contracts were 'excluded from the train and test datasets' does not rule out overlap with Qwen1.5-72B-Chat's pretraining corpus or with the source datasets [22],[31] used to build the training data. Since Table III reports F1 values between 81.0 and 92.0 while the raw Qwen model in Fig. 2 scores 67.83 F1 on reentrancy, the zero-shot numbers require a contamination check and a comparison against baselines on the same 400 samples to be interpretable. Please rename the setting (e.g., cross-dataset evaluation) and provide these controls.
  4. [§IV.C, §IV.F, Table II] It is not stated whether the 12 baseline results were produced by re-running the tools on the same train/test split used for SAEL or are quoted from prior papers. If quoted, differences in dataset versions, function-level versus contract-level granularity, class balance, and evaluation protocols make the F1 comparison non-apples-to-apples. The SOTA claim requires either re-running all baselines under the identical protocol or clearly documenting the provenance and matching conditions of each baseline number.
minor comments (5)
  1. [Abstract and Table II] The abstract reports F1 improvements of 2.33, 3.16, 10.67, and 13.32 percentage points, but the differences over the best baselines in Table II are 2.15, 2.84, 8.02, and 9.44 points for reentrancy, timestamp dependence, overflow/underflow, and delegatecall, respectively. Please harmonize these numbers.
  2. [§IV.B] The statement about 'over 200,000 real-world smart contracts' is ambiguous because the evaluation is function-level; please report for each vulnerability the number of functions and contracts used, the filtering criteria, and the class balance.
  3. [§IV.F, RQ4] The phrase 'Ethernet Open Dataset' appears to be a typo for 'Ethereum Open Dataset' or for the dataset in reference [31]; please correct it.
  4. [§III.B, Eq. (2)] The verbalizer maps label words such as 'defective/bad' and 'clean/perfect', but the mapping from the cloze output [Z] to class probabilities is not specified; please clarify how hraw and hexpl are derived from the prompt-tuning outputs.
  5. [§IV.F, Figs. 6–7] The figures showing feature and module ablations do not include error bars or variance information; please state whether the F1 values are averages over multiple seeds or runs, and report standard deviations if available.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: SAEL's state-of-the-art claim is tested against external benchmarks and rests on explicit training equations, not on a self-citation chain or a fitted prediction.

full rationale

No circularity step meets the required standard of exhibiting a specific reduction to the paper's own inputs. The central claim is an empirical comparison against twelve external baselines on public datasets (SmartBugs Wild, ESC, and the mixed datasets [31], [32]), with the SAEL pipeline defined by explicit equations (Eqs. 1-14) and evaluated with a 3:1:1 train/validation/test split. The adaptive MoE, gating network, multi-head self-attention, and loss function are all trained on labeled data; none of the reported F1 scores is a fitted parameter renamed as a prediction. The ablations in Figs. 6 and 7 are internal diagnostics rather than circular evidence. The one notable self-citation, Yu et al. [25] (PSCVFinder), is used to justify prompt-tuning and CodeT5 over alternatives, but that cited work is a published, externally evaluated prior result, and PSCVFinder itself appears as a baseline that SAEL must outperform in Table II, so the SOTA claim is not forced by the self-citation. The RQ4 zero-shot claim relies on excluding selected contracts from the train and test sets; whether that exclusion is sufficient against LLM pretraining overlap or near-duplicate contracts is an evaluation-validity and contamination concern, not a definitional circularity. Overall, no equation, feature, or benchmark result reduces by construction to the paper's inputs.

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

The central evaluation rests on dataset label quality, split hygiene, and LLM output cleanliness, none of which the paper verifies. The trainable components introduce alpha, gamma, and k as hand-chosen or validation-tuned constants whose final values are not reported. No new entities are introduced.

free parameters (4)
  • alpha (loss balance coefficient) = not reported
    Eq. 13 balances L_feature + L_reg against L_pred. Fig. 8 shows F1 varies with alpha, peaking near 0.4-0.6 for some types, but the value used for Table II is not stated.
  • gamma (weight regularization coefficient) = not reported
    Eq. 12 scales the regularization term; the value used for the headline results is not reported, and Fig. 8 shows performance falls for large gamma.
  • TopK k = 3
    Eq. 5. The authors justify k=3 by the three feature types, but TopK is applied to the transformed feature vector dimensions, not to the three feature groups, so the justification is not clearly connected to the mechanism.
  • Hand-crafted prompt template per vulnerability = four templates (reentrancy shown in Fig. 5)
    The prompts embed vulnerability definitions and chain-of-thought instructions; they are designed by hand and the other three templates are not shown, so the reader cannot reproduce the exact LLM inputs.
assumptions (4)
  • domain assumption Ground-truth labels in the four datasets are correct.
    Section IV.B treats SmartBugs Wild, ESC, and the mixed [31],[32] labels as ground truth; known label noise in such datasets would inflate measured F1 for every method, SAEL included.
  • domain assumption The 3:1:1 random split does not place the same contract or function in both training and test sets.
    Section IV.E specifies only the split ratio; no deduplication is described, and duplicate contracts are common across public Solidity collections.
  • domain assumption Qwen1.5-72B-Chat's outputs on test contracts are not contaminated by the contracts appearing in its pre-training data.
    The LLM is used as a feature source; the test datasets are public GitHub-sourced contracts, and the paper does not assess memorization.
  • standard math Gradient-based optimization of the stated loss converges to a useful gating behavior.
    Eq. 14 assumes standard gradient descent on a differentiable loss; this is routine, though the connection between the gating vector and the loss is not fully specified (see red flags).

how reviews work

0 comments
Cite this review

Pith. "Pith review of SAEL: Leveraging Large Language Models with Adaptive Mixture-of-Experts for Smart Contract Vulnerability Detection." pith.science (2026). https://pith.science/paper/VNBMQQPW

@misc{pith2026250722371,
  author       = {Pith},
  title        = {Pith review of: SAEL: Leveraging Large Language Models with Adaptive Mixture-of-Experts for Smart Contract Vulnerability Detection},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VNBMQQPW}},
  note         = {Machine review of arXiv:2507.22371}
}
read the original abstract

With the increasing security issues in blockchain, smart contract vulnerability detection has become a research focus. Existing vulnerability detection methods have their limitations: 1) Static analysis methods struggle with complex scenarios. 2) Methods based on specialized pre-trained models perform well on specific datasets but have limited generalization capabilities. In contrast, general-purpose Large Language Models (LLMs) demonstrate impressive ability in adapting to new vulnerability patterns. However, they often underperform on specific vulnerability types compared to methods based on specialized pre-trained models. We also observe that explanations generated by general-purpose LLMs can provide fine-grained code understanding information, contributing to improved detection performance. Inspired by these observations, we propose SAEL, an LLM-based framework for smart contract vulnerability detection. We first design targeted prompts to guide LLMs in identifying vulnerabilities and generating explanations, which serve as prediction features. Next, we apply prompt-tuning on CodeT5 and T5 to process contract code and explanations, enhancing task-specific performance. To combine the strengths of each approach, we introduce an Adaptive Mixture-of-Experts architecture. This dynamically adjusts feature weights via a Gating Network, which selects relevant features using TopK filtering and Softmax normalization, and incorporates a Multi-Head Self-Attention mechanism to enhance cross-feature relationships. This design enables effective integration of LLM predictions, explanation features, and code features through gradient optimization. The loss function jointly considers both independent feature performance and overall weighted predictions. Experiments show that SAEL outperforms existing methods across various vulnerabilities.

Figures

Figures reproduced from arXiv: 2507.22371 by the authors.

Figure 1
Figure 1. Motivation examples of different methods on smart contract vulnerability detection task. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Performance comparison of specialized pre-trained models and [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. The case related to timestamp where LLMs made incorrect predictions. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: The overall architecture of the proposed model SAEL. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: The Prompt Design for Reentrancy Vulnerability. [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Analysis of Different Features Base w/o LLM w/o MOE 70 75 80 85 90 95 100 F1-Score (%) Reentrancy Base w/o LLM w/o MOE Base w/o LLM w/o MOE 70 75 80 85 90 95 100 Timestamp Base w/o LLM w/o MOE 70 75 80 85 90 95 100 Integer Overflow/Underflow [PITH_FULL_IMAGE:figures/f…
Figure 7
Figure 7. Figure 7: Analysis of Different Modules 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.70 0.75 0.80 0.85 0.90 0.95 1.00 F1-Score F1-Score vs Reentrancy Timestamp Overflow/Underflow Delegatecall 10 2 10 1 10 0 10 1 0.70 0.75 0.80 0.85 0.90 0.95 1.00 F1-Score F1-Score vs Reentrancy Timesta…
Figure 8
Figure 8. Figure 8: Performance of SAEL with different parameters. [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: A simplified real-world smart contract with a complex reentrancy [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

53 extracted references · 42 canonical work pages

  1. [31]

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

    Z. Liu, P. Qian, J. Yang, L. Liu, X. Xu, Q. He, and X. Zhang, “Rethinking smart contract fuzzing: Fuzzing with invocation ordering and important branch revisiting,” IEEE Transactions on Information F orensics and Security, vol. 18, pp. 1237–1251, 2023

  2. [32]

    Cross-modality mutual learning for enhancing smart contract vulnerability detection on bytecode,

    P. Qian, Z. Liu, Y . Yin, and Q. He, “Cross-modality mutual learning for enhancing smart contract vulnerability detection on bytecode,” in Proceedings of the ACM Web Conference 2023 , 2023, pp. 2220–2229

  3. [22]

    Smart contract vulnerability detection using graph neural network

    Y . Zhuang, Z. Liu, P. Qian, Q. Liu, X. Wang, and Q. He, “Smart contract vulnerability detection using graph neural network.” in IJCAI, 2020, pp. 3283–3290

  4. [1]

    Swan, Blockchain: Blueprint for a new economy

    M. Swan, Blockchain: Blueprint for a new economy . ” O’Reilly Media, Inc.”, 2015

  5. [2]

    Survey on blockchain based smart contracts: Applications, opportunities and challenges,

    T. Hewa, M. Ylianttila, and M. Liyanage, “Survey on blockchain based smart contracts: Applications, opportunities and challenges,” Journal of Network and Computer Applications , vol. 177, p. 102857, 2021

  6. [3]

    Ethereum: A secure decentralised generalised trans- action ledger,

    G. Wood et al. , “Ethereum: A secure decentralised generalised trans- action ledger,” Ethereum project yellow paper , vol. 151, no. 2014, pp. 1–32, 2014

  7. [4]

    Who are the money launderers? money laundering detection on blockchain via mutual learning-based graph neural network,

    L. Yu, F. Zhang, J. Ma, L. Yang, Y . Yang, and W. Jia, “Who are the money launderers? money laundering detection on blockchain via mutual learning-based graph neural network,” in2023 International Joint Conference on Neural Networks (IJCNN) . IEEE, 2023, pp. 1–8

  8. [5]

    Dccgraph: Detecting criminal communities with augmented criminal network construction and graph neural network,

    Y . Yang, L. Yang, L. Li, X. Ma, L. Yu, and C. Zuo, “Dccgraph: Detecting criminal communities with augmented criminal network construction and graph neural network,” in 2023 International Joint Conference on Neural Networks (IJCNN) . IEEE, 2023, pp. 1–8

Show all 53 references
  1. [6]

    Topology augmented multi-band and multi-scale filtering for graph anomaly detection,

    J. Zhang, L. Yu, Z. Huang, L. Yang, and F. Zhang, “Topology augmented multi-band and multi-scale filtering for graph anomaly detection,” ACM Transactions on Knowledge Discovery from Data , 2025

  2. [7]

    Smart contract development: Challenges and opportunities,

    W. Zou, D. Lo, P. S. Kochhar, X.-B. D. Le, X. Xia, Y . Feng, Z. Chen, and B. Xu, “Smart contract development: Challenges and opportunities,” IEEE Transactions on Software Engineering , vol. 47, no. 10, pp. 2084– 2106, 2019

  3. [8]

    The dao hacked,

    V . Dhillon, D. Metcalf, M. Hooper, V . Dhillon, D. Metcalf, and M. Hooper, “The dao hacked,” blockchain enabled applications: Un- derstand the blockchain Ecosystem and How to Make it work for you , pp. 67–78, 2017

  4. [9]

    Understanding a revo- lutionary and flawed grand experiment in blockchain: the dao attack,

    M. I. Mehar, C. L. Shier, A. Giambattista, E. Gong, G. Fletcher, R. Sanayhie, H. M. Kim, and M. Laskowski, “Understanding a revo- lutionary and flawed grand experiment in blockchain: the dao attack,” Journal of Cases on Information Technology (JCIT) , vol. 21, no. 1, pp. 19–32, 2019

  5. [10]

    Smart-llama: two-stage post-training of large language models for smart contract vulnerability detection and explanation,

    L. Yu, S. Chen, H. Yuan, P. Wang, Z. Huang, J. Zhang, C. Shen, F. Zhang, L. Yang, and J. Ma, “Smart-llama: two-stage post-training of large language models for smart contract vulnerability detection and explanation,” arXiv preprint arXiv:2411.06221 , 2024

  6. [11]

    Smart-llama-dpo: Reinforced large language model for explainable smart contract vulnerability detection,

    L. Yu, Z. Huang, H. Yuan, S. Cheng, L. Yang, F. Zhang, C. Shen, J. Ma, J. Zhang, J. Lu et al. , “Smart-llama-dpo: Reinforced large language model for explainable smart contract vulnerability detection,” Proceedings of the ACM on Software Engineering , vol. 2, no. ISSTA, pp. 18...

  7. [12]

    Mos: Towards effective smart contract vulnerability detection through mixture-of-experts tuning of large language models,

    H. Yuan, L. Yu, Z. Huang, J. Zhang, J. Lu, S. Cheng, L. Yang, F. Zhang, J. Ma, and C. Zuo, “Mos: Towards effective smart contract vulnerability detection through mixture-of-experts tuning of large language models,” arXiv preprint arXiv:2504.12234 , 2025

  8. [13]

    Blockchain-based smart contracts: A systematic mapping study,

    M. Alharby and A. Van Moorsel, “Blockchain-based smart contracts: A systematic mapping study,” arXiv preprint arXiv:1710.06372 , 2017

  9. [14]

    Towards analyzing the complexity landscape of solidity based ethereum smart contracts,

    P. Heged ˝us, “Towards analyzing the complexity landscape of solidity based ethereum smart contracts,” in Proceedings of the 1st International Workshop on Emerging Trends in Software Engineering for Blockchain , 2018, pp. 35–39

  10. [15]

    Making smart contracts smarter,

    L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contracts smarter,” in Proceedings of the 2016 ACM SIGSAC conference on computer and communications security , 2016, pp. 254–269

  11. [16]

    Mythril-reversing and bug hunting framework for the ethereum blockchain,

    B. Mueller, “Mythril-reversing and bug hunting framework for the ethereum blockchain,” 2017

  12. [17]

    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,” in Proceedings of the 34th Annual Computer Security Applications Conference , 2018, pp. 664–676

  13. [18]

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

    M. Mossberg, F. Manzano, E. Hennenfent, A. Groce, G. Grieco, J. Feist, T. Brunson, and A. Dinaburg, “Manticore: A user-friendly symbolic execution framework for binaries and smart contracts,” in 2019 34th IEEE/ACM International Conference on Automated Software Engineer- ing (A...

  14. [19]

    Slither: a static analysis framework for smart contracts,

    J. Feist, G. Grieco, and A. Groce, “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, 2019, pp. 8–15

  15. [20]

    Smartcheck: Static analysis of ethereum smart contracts,

    S. Tikhomirov, E. V oskresenskaya, I. Ivanitskiy, R. Takhaviev, E. Marchenko, and Y . Alexandrov, “Smartcheck: Static analysis of ethereum smart contracts,” in Proceedings of the 1st international workshop on emerging trends in software engineering for blockchain , 2018, pp. 9–16

  16. [21]

    Improving smart contract security with contrastive learning-based vulnerability detection,

    Y . Chen, Z. Sun, Z. Gong, and D. Hao, “Improving smart contract security with contrastive learning-based vulnerability detection,” in 2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE). IEEE Computer Society, 2024, pp. 940–940

  17. [23]

    Scvhunter: Smart contract vulnerability detection based on heteroge- neous graph attention network,

    F. Luo, R. Luo, T. Chen, A. Qiao, Z. He, S. Song, Y . Jiang, and S. Li, “Scvhunter: Smart contract vulnerability detection based on heteroge- neous graph attention network,” in 2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE) . IEEE Computer Society, ...

  18. [24]

    Peculiar: Smart contract vulnerability detection based on crucial data flow graph and pre-training techniques,

    H. Wu, Z. Zhang, S. Wang, Y . Lei, B. Lin, Y . Qin, H. Zhang, and X. Mao, “Peculiar: Smart contract vulnerability detection based on crucial data flow graph and pre-training techniques,” in 2021 IEEE 32nd International Symposium on Software Reliability Engineering (ISSRE) . IE...

  19. [25]

    Pscvfinder: A prompt-tuning based framework for smart contract vulnerability detection,

    L. Yu, J. Lu, X. Liu, L. Yang, F. Zhang, and J. Ma, “Pscvfinder: A prompt-tuning based framework for smart contract vulnerability detection,” in 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE) . IEEE, 2023, pp. 556–567

  20. [26]

    Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation,

    Y . Wang, W. Wang, S. Joty, and S. C. Hoi, “Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation,” in Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing , 2021, pp. 8696–8708

  21. [27]

    Graphcodebert: Pre-training code representations with data flow,

    D. Guo, S. Ren, S. Lu, Z. Feng, D. Tang, L. Shujie, L. Zhou, N. Duan, A. Svyatkovskiy, S. Fu et al. , “Graphcodebert: Pre-training code representations with data flow,” in International Conference on Learning Representations, 2020

  22. [28]

    Exploring the limits of transfer learning with a unified text-to-text transformer,

    C. Raffel, N. Shazeer, A. Roberts, K. Lee, S. Narang, M. Matena, Y . Zhou, W. Li, and P. J. Liu, “Exploring the limits of transfer learning with a unified text-to-text transformer,” The Journal of Machine Learning Research, vol. 21, no. 1, pp. 5485–5551, 2020

  23. [29]

    Smartbugs: A framework to analyze solidity smart contracts,

    J. F. Ferreira, P. Cruz, T. Durieux, and R. Abreu, “Smartbugs: A framework to analyze solidity smart contracts,” in Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering, 2020, pp. 1349–1352

  24. [30]

    Smart contract vulnerability detection: from pure neural network to interpretable graph feature and expert pattern fusion,

    Z. Liu, P. Qian, X. Wang, L. Zhu, Q. He, and S. Ji, “Smart contract vulnerability detection: from pure neural network to interpretable graph feature and expert pattern fusion,” arXiv preprint arXiv:2106.09282 , 2021

  25. [33]

    Sael: Leveraging large language models with adaptive mixture-of-experts for smart contract vulnerability detection,

    L. Yu, S. Cheng, Z. Huang, J. Zhang, C. Shen, J. Lu, L. Yang, F. Zhang, and J. Ma, “Sael: Leveraging large language models with adaptive mixture-of-experts for smart contract vulnerability detection,”

  26. [34]

    A survey on ethereum sys- tems security: Vulnerabilities, attacks, and defenses,

    H. Chen, M. Pendleton, L. Njilla, and S. Xu, “A survey on ethereum sys- tems security: Vulnerabilities, attacks, and defenses,” ACM Computing Surveys (CSUR), vol. 53, no. 3, pp. 1–43, 2020

  27. [35]

    Easyflow: Keep ethereum away from overflow,

    J. Gao, H. Liu, C. Liu, Q. Li, Z. Guan, and Z. Chen, “Easyflow: Keep ethereum away from overflow,” in 2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE- Companion). IEEE, 2019, pp. 23–26

  28. [36]

    Security analysis methods on ethereum smart contract vulnerabilities: a survey,

    P. Praitheeshan, L. Pan, J. Yu, J. Liu, and R. Doss, “Security analysis methods on ethereum smart contract vulnerabilities: a survey,” arXiv preprint arXiv:1908.08605, 2019

  29. [37]

    Large language model-powered smart contract vulnerability detection: New perspec- tives,

    S. Hu, T. Huang, F. ˙Ilhan, S. F. Tekin, and L. Liu, “Large language model-powered smart contract vulnerability detection: New perspec- tives,” arXiv preprint arXiv:2310.01152 , 2023

  30. [38]

    When chatgpt meets smart contract vulnerability detection: How far are we?

    C. Chen, J. Su, J. Chen, Y . Wang, T. Bi, Y . Wang, X. Lin, T. Chen, and Z. Zheng, “When chatgpt meets smart contract vulnerability detection: How far are we?” arXiv preprint arXiv:2309.05520 , 2023

  31. [39]

    Do you still need a manual smart contract audit?

    I. David, L. Zhou, K. Qin, D. Song, L. Cavallaro, and A. Gervais, “Do you still need a manual smart contract audit?” arXiv preprint arXiv:2306.12338, 2023

  32. [40]

    Gptscan: Detecting logic vulnerabilities in smart contracts by combining gpt with program analysis,

    Y . Sun, D. Wu, Y . Xue, H. Liu, H. Wang, Z. Xu, X. Xie, and Y . Liu, “Gptscan: Detecting logic vulnerabilities in smart contracts by combining gpt with program analysis,” Proc. IEEE/ACM ICSE , 2024

  33. [41]

    Securify: Practical security analysis of smart contracts,

    P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Buenzli, and M. Vechev, “Securify: Practical security analysis of smart contracts,” in Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security , 2018, pp. 67–82

  34. [42]

    Codebert: A pre-trained model for programming and natural languages,

    Z. Feng, D. Guo, D. Tang, N. Duan, X. Feng, M. Gong, L. Shou, B. Qin, T. Liu, D. Jiang et al., “Codebert: A pre-trained model for programming and natural languages,” in Findings of the Association for Computational Linguistics: EMNLP 2020 , 2020, pp. 1536–1547

  35. [43]

    Reentrancy vulnerability detection and localization: A deep learning based two-phase approach,

    Z. Zhang, Y . Lei, M. Yan, Y . Yu, J. Chen, S. Wang, and X. Mao, “Reentrancy vulnerability detection and localization: A deep learning based two-phase approach,” in37th IEEE/ACM International Conference on Automated Software Engineering , 2022, pp. 1–13

  36. [44]

    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

  37. [45]

    Towards safer smart contracts: A sequence learning approach to detecting security threats,

    W. J.-W. Tann, X. J. Han, S. S. Gupta, and Y .-S. Ong, “Towards safer smart contracts: A sequence learning approach to detecting security threats,” arXiv preprint arXiv:1811.06632 , 2018

  38. [46]

    Deepcrceval: Revisiting the evaluation of code review comment generation,

    J. Lu, X. Li, Z. Hua, L. Yu, S. Cheng, L. Yang, F. Zhang, and C. Zuo, “Deepcrceval: Revisiting the evaluation of code review comment generation,” in International Conference on Fundamental Approaches to Software Engineering . Springer Nature Switzerland Cham, 2025, pp. 43–64

  39. [47]

    Llama-reviewer: Advancing code review automation with large language models through parameter- efficient fine-tuning,

    J. Lu, L. Yu, X. Li, L. Yang, and C. Zuo, “Llama-reviewer: Advancing code review automation with large language models through parameter- efficient fine-tuning,” in 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE) . IEEE, 2023, pp. 647–658

  40. [48]

    Dependency-aware method naming framework with generative adversarial sampling,

    C. Shen, J. Zhu, L. Yu, L. Yang, and C. Zuo, “Dependency-aware method naming framework with generative adversarial sampling,” in 2024 International Joint Conference on Neural Networks (IJCNN) . IEEE, 2024, pp. 1–8

  41. [49]

    Swe-bench-java: A github issue resolving benchmark for java,

    D. Zan, Z. Huang, A. Yu, S. Lin, Y . Shi, W. Liu, D. Chen, Z. Qi, H. Yu, L. Yu et al. , “Swe-bench-java: A github issue resolving benchmark for java,” arXiv preprint arXiv:2408.14354 , 2024

  42. [50]

    Optuna: A next- generation hyperparameter optimization framework,

    T. Akiba, S. Sano, T. Yanase, T. Ohta, and M. Koyama, “Optuna: A next- generation hyperparameter optimization framework,” in Proceedings of the 25th ACM SIGKDD international conference on knowledge discovery & data mining , 2019, pp. 2623–2631

  43. [51]

    Exploring the potential of chatgpt in automated code refinement: An empirical study,

    Q. Guo, J. Cao, X. Xie, S. Liu, X. Li, B. Chen, and X. Peng, “Exploring the potential of chatgpt in automated code refinement: An empirical study,” in Proceedings of the 46th IEEE/ACM International Conference on Software Engineering , 2024, pp. 1–13

  44. [52]

    Algorithms for hyper- parameter optimization,

    J. Bergstra, R. Bardenet, Y . Bengio, and B. K ´egl, “Algorithms for hyper- parameter optimization,” Advances in neural information processing systems, vol. 24, 2011

  45. [2025]

    Available: https://zenodo.org/records/16421321

    [Online]. Available: https://zenodo.org/records/16421321

Pith tools

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