Pith. sign in

REVIEW 3 major objections 4 minor 62 references

The paper claims that a detection pipeline combining regex screening, structure-aware code slicing, and a knowledge-constrained LLM shifts reported vulnerability rates in Ethereum NFT contracts from 73.8% to 97.1%, and that this shift itsel

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

Code slicing plus a knowledge base raises the LLM's positive-label rate from 73.8% to 97.1% on 450 NFT contracts, an effect not validated against ground truth.

T0 review reviewed 2026-08-01 challenge →

load-bearing objection Honest paper, but the headline ablation is confounded by the very labels that drive the slicing — the claimed benefit of focused context is not actually established. the 3 major comments →

arxiv 2607.21983 v1 pith:EED5PJKP submitted 2026-07-24 cs.CR

Ethereum NFT Smart Contracts: Knowledge-Guided Vulnerability Detection with LLM and Code Slicing

Deyu Yang , Rundong Wei , Xiaoqi Li This is my paper
classification cs.CR
keywords Ethereum NFT smart contractsvulnerability detectioncode slicingLLMDeepSeekreentrancyinteger overflow/underflowtimestamp dependence
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The reading

This paper claims that how you feed a large language model a smart contract matters as much as the model itself. It proposes a three-stage detector for Ethereum NFT contracts: regex-based candidate screening, structure-aware code slicing that extracts line-numbered context around each candidate, and a DeepSeek pass constrained by an ERC-721 knowledge base, a closed label set, and a fixed answer schema. On 450 contracts, the full pipeline reports a 97.1% positive-label rate; dropping the knowledge base lowers it to 87.11%, and analyzing whole contracts without the knowledge base lowers it to 73.78%. The paper is careful to say this establishes only that the constraints change the detector's output distribution, not that the detection is accurate; no independent ground truth was used. A sympathetic reader would take the contribution as an engineering recipe plus evidence that input focusing and knowledge constraints are load-bearing parts of LLM-based detection.

Core claim

Presented as a method paper, the central claim is that a vulnerability-focused code-slicing step and an ERC-721-oriented knowledge base materially change the output of an LLM-based smart-contract vulnerability detector. Across 450 NFT contract samples, the full configuration produced 437 positive labels (97.11%), slices without the external knowledge base produced 392 positive labels (87.11%), and complete contracts without the knowledge base produced 332 positive labels (73.78%). The paper states these results support only the narrower conclusion that focused code context and domain constraints affect reported output, not that the method achieves high true detection rates, because the evalu

What carries the argument

The load-bearing mechanism is vulnerability-focused code slicing: class-specific regular expressions locate candidate statements for reentrancy, integer overflow or underflow, and timestamp dependence; a structure-aware context-window algorithm then expands a five-line local window backward to a likely function start and forward up to fifty lines while balancing braces, producing line-numbered code slices. These slices are fed to DeepSeek under a constrained prompt that includes an ERC-721 knowledge base, a closed label set (the three vulnerability classes plus None), explicit decision rules, and a fixed output schema, enabling automated batch parsing.

Load-bearing premise

The vulnerability-category labels used to drive the slicing step were generated semi-automatically, so the observed higher positive-label rate may reflect the labels' guidance rather than the benefits of code slicing and the knowledge base.

What would settle it

Run the full pipeline on a benchmark with independently adjudicated ground truth for the three vulnerability classes, and compare the reported positive-label rate against actual precision and recall; also run an ablation where slicing is performed identically but the knowledge base is stripped of all vulnerability-relevant clues, to test whether the 97.1% rate depends on the model being told what to look for.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • If input focusing and knowledge constraints shift LLM output as reported, then LLM-based vulnerability detection should be designed with explicit input reduction and domain grounding rather than raw whole-contract prompting.
  • The fixed output schema and closed label set make the pipeline suitable for automated batch processing, so the method could be integrated into continuous auditing workflows for large contract collections.
  • The reported positive-label rates cannot be read as accuracy; any future application must couple the pipeline with independent ground-truth adjudication to calibrate real precision and recall.
  • The same slicing-plus-knowledge recipe could plausibly transfer to other contract standards (ERC-20, ERC-1155) and other vulnerability classes, provided the regex patterns and knowledge base are rebuilt for those domains.
  • The 13.33 percentage-point swing between whole-contract and sliced inputs suggests that code context influences how conservative the LLM is about returning None, which has implications for false-positive management.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The strongest editorial inference is that the ablation gap may be driven by the semi-automatically generated labels in vuln_labels.csv: because those labels guide the slicing stage, the pipeline could be discovering which class the slicing already knew to look for, so the 97.1% rate may partly reflect label leakage rather than a genuine benefit of slicing or knowledge.
  • A natural extension is to run the same three configurations on a benchmark with independently adjudicated ground truth and per-class confusion matrices, which would convert positive-label rates into actionable precision and recall numbers; until then, the relative ordering of the three rates is the only defensible quantitative claim.
  • A testable design improvement would be to randomize which candidate lines receive slices and to remove the knowledge-base text piecewise, isolating whether the output shift comes from reduced input size, the domain text, or the label-driven slice selection.
  • The paper's explicit admission that exact model configuration and the full knowledge base were not recorded suggests that reproducing the 97.1% figure requires freezing and publishing those details; an editor's caution would be to treat the precise percentages as environment-specific until replicated.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. The paper presents a vulnerability-detection pipeline for Ethereum NFT contracts targeting reentrancy, integer overflow/underflow, and timestamp dependence. Preprocessing uses class-specific regular-expression patterns to locate candidate lines, followed by a structure-aware context-window algorithm that extracts line-numbered code slices. DeepSeek then analyzes each slice under a constrained prompt with ERC-721 domain knowledge, a closed label set, and a fixed output schema. On 450 NFT contract samples, the full configuration yields 437 positive labels (97.11%), slices without the knowledge base yield 392 (87.11%), and complete contracts without the knowledge base yield 332 (73.78%). The paper repeatedly and correctly states that these are positive-label rates, not validated detection accuracy.

Significance. If the ablation contrast were unconfounded, the paper would make a modest but useful empirical point: focused, knowledge-constrained prompts change the distribution of LLM outputs. The pipeline is clearly described, the ablation is controlled on the same 450 samples, and the authors' decision not to claim precision or recall is scientifically honest. However, the label-leakage confound means the central claim is not currently established. The paper does not provide machine-checked artifacts, independent ground truth, or statistical stability analysis; its value is therefore conditional on fixing the confound and reporting reproducibility.

major comments (3)
  1. [§4.2, Algorithm 1 and §5.4] The slicing stage takes a vulnerability class v as input (Algorithm 1: 'Require: Contract lines C, vulnerability class v, pattern library P_v'), and the class comes from vuln_labels.csv, generated semi-automatically. The LLM is then asked to output one of those same classes. Thus the comparison between 'slices without knowledge' (87.11%) and 'complete contracts without knowledge' (73.78%) may reflect the label clue embedded in slice selection rather than the removal of distracting code. Section 6 concedes this risk. To support the claim that focused context materially affects output, the authors should include a control where slices are generated without using the label (e.g., all pattern classes, random slices of matched length, or slices selected with labels held out), or add a complete-contract condition that receives the same label clue in the prompt.
  2. [§5.1, §5.4] The ablation differences are single draws from a stochastic LLM, yet no confidence intervals, standard errors, or repeated runs are reported. The manuscript also states that the exact DeepSeek model identifier, temperature, token limit, API version, retry policy, and full knowledge-base text were not recorded. Consequently, the claim that the 13.33-percentage-point difference is 'material' has no statistical support. Please report stability across runs/seeds and sufficient configuration details to make the comparison reproducible.
  3. [§5.3, Table 4] The class distribution (155 reentrancy, 141 overflow/underflow, 141 timestamp dependence) is an output of the pipeline, not an independent characterization of the contracts. The text should state this more explicitly so readers do not interpret the distribution as ground-truth prevalence. This is not a fatal issue but is needed for correct interpretation of Figure 4 and the batch results.
minor comments (4)
  1. [Table 3] It is unclear whether the selected-sample rows are hand-picked illustrative outputs or drawn systematically from the batch. Please state their provenance explicitly.
  2. [§4.3, Prompt 1] The abridged prompt omits the actual ERC-721 knowledge base. Including the full knowledge base in an appendix would aid reproducibility and let readers assess whether the domain constraints are genuinely ERC-721-specific.
  3. [Figure 4] The bar charts have no error bars because only single runs are reported. If repeated runs are added, visualizing variability would help support the claimed differences.
  4. [References] Several references are arXiv preprints with inconsistent formatting; please align with the journal style and verify identifiers and years.

Circularity Check

1 steps flagged

Central ablation confounds focused context with label-conditioned slicing: vulnerability labels leak into slice selection and the LLM's output label set.

specific steps
  1. self definitional [Algorithm 1 (Require clause), Prompt 1, §5.4, §6]
    "Algorithm 1: 'Require: Contract lines C, vulnerability class v, pattern library P_v' ... Prompt 1: 'Allowed output label: Reentrancy | Integer overflow/underflow | Timestamp dependence | None' ... §6: 'the vulnerability-category labels used during preprocessing were generated semi-automatically, which may reveal expected classes to the slicing procedure.'"

    The slicing stage takes vulnerability class v as an input, uses class-specific patterns P_v to choose candidate lines, and then the LLM is constrained to output one of the same three classes. Consequently, in the slices-without-knowledge condition, each slice already carries a label-derived focus, so the 87.11% positive-label rate is partly forced by the input label rather than by the removal of distracting code. The comparison against complete contracts (73.78%) therefore cannot cleanly attribute the 13.33 percentage-point difference to code slicing. The paper itself concedes that the semi-automatically generated labels 'may reveal expected classes to the slicing procedure,' and no independent ground truth or confidence intervals are provided.

full rationale

The paper's strongest quantitative evidence for the value of focused code context is the ablation gap between code slices without external knowledge (87.11%) and complete contracts without external knowledge (73.78%). This gap is not a clean measure of slicing because the slicing procedure is conditioned on the vulnerability class stored in vuln_labels.csv: Algorithm 1 requires 'vulnerability class v, pattern library P_v', and Prompt 1 restricts the output to exactly the same three classes. Thus the positive-label output is partly determined by construction from the label input. The paper's own limitation statement in §6 explicitly flags that these labels 'may reveal expected classes to the slicing procedure.' This is a structural confound rather than a mere reporting gap. The knowledge-base comparison (87.11% vs 97.11%) is less circular because both conditions use the same slicing, but the claimed slicing benefit remains partially forced. Numerous self-citations appear in the related-work section, but none are load-bearing in the derivation; no uniqueness theorem or prior result is used to justify the method's correctness. The paper is also honest that the reported metric is a positive-label rate, not verified accuracy, which limits the overall circularity score to partial (6) rather than total (8-10).

Axiom & Free-Parameter Ledger

2 free parameters · 4 axioms · 0 invented entities

The paper introduces no new formal entities. Its load-bearing inputs are hand-chosen context-window sizes, a hand-crafted regex library, and a set of domain assumptions about ERC-721 contracts, LLM behavior, label quality, and pattern recall. The label-quality assumption is the most fragile and is self-flagged in §6.

free parameters (2)
  • Context window sizes = 5 lines before/after; forward scan up to 50 lines
    Algorithm 1 defines the local window as five lines on each side and a forward scan of up to fifty lines. These values are hand-chosen and directly determine the code slices fed to the LLM, but are not fitted to any outcome.
  • Regex pattern library = Representative patterns only in Table 2
    Class-specific regular expressions are hand-crafted candidate locators. They determine which lines become slices; the full library is not published and no recall measurement is given.
axioms (4)
  • domain assumption The three vulnerability classes (reentrancy, integer overflow/underflow, timestamp dependence) are the relevant security risks for ERC-721 contracts.
    Section 3.2 defines the scope and explicitly excludes other classes such as access control and denial of service.
  • domain assumption DeepSeek reliably follows the requested output schema and decision rules.
    The entire pipeline depends on the model returning parseable 'Vulnerability Type', 'Suspicious Code Location', and 'Vulnerability Cause' fields; only three selected samples are manually inspected (Table 3).
  • domain assumption The semi-automatically generated labels in vuln_labels.csv are correct enough to guide slicing.
    Section 6 explicitly warns that these labels 'may reveal expected classes to the slicing procedure', making the slicing output partly dependent on unverified labels.
  • domain assumption Regular-expression patterns achieve high recall for the three classes.
    Algorithm 1 and §4.2 treat the patterns as a high-recall filter, but no recall measurement against a labeled corpus is provided.

reviewed 2026-08-01 · how reviews work

0 comments
Cite this review

Pith. "Pith review of Ethereum NFT Smart Contracts: Knowledge-Guided Vulnerability Detection with LLM and Code Slicing." pith.science (2026). https://pith.science/paper/EED5PJKP

@misc{pith2026260721983,
  author       = {Pith},
  title        = {Pith review of: Ethereum NFT Smart Contracts: Knowledge-Guided Vulnerability Detection with LLM and Code Slicing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EED5PJKP}},
  note         = {Machine review of arXiv:2607.21983}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Ethereum non-fungible tokens (NFTs) implement ownership, transfer, authorization, and metadata operations through smart contracts, making contract vulnerabilities a direct risk to digital assets. Existing static analyzers provide efficient rule-based screening but can struggle with application-specific logic, whereas unconstrained large language model analysis may be distracted by irrelevant code or produce inconsistent outputs. We present a vulnerability-detection method that combines vulnerability-focused code slicing, an ERC-721-oriented knowledge base, and constrained DeepSeek analysis. Regular-expression patterns locate candidate statements for reentrancy, integer overflow or underflow, and timestamp dependence. A structure-aware context-window algorithm then extracts line-numbered code slices. DeepSeek analyzes each slice using explicit decision rules and a fixed output schema, and the resulting records support automated batch processing. On 450 NFT contract samples, the full configuration produced 437 positive labels, corresponding to a reported positive-label rate of 97.1%. Removing the external knowledge base reduced this rate to 87.11%, while analyzing complete contracts without the knowledge base reduced it to 73.78%. These results indicate that focused code context and domain constraints materially affect the detector's reported output.

Figures

Figures reproduced from arXiv: 2607.21983 by Deyu Yang, Rundong Wei, Xiaoqi Li.

Figure 1
Figure 1. Figure 1: Overall framework of the proposed vulnerability-detection method. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Contract preprocessing and knowledge-guided DeepSeek analysis. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Architecture of the code-slice extraction module. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Detection results and ablation comparison. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

62 extracted references · 14 linked inside Pith

  1. [1]

    Penetrating the hostile: Detecting DeFi protocol exploits through cross-contract analysis.IEEE Trans

    Xiaoqi Li, Wenkai Li, Zhiquan Liu, Yuqing Zhang, and Yingjie Mao. Penetrating the hostile: Detecting DeFi protocol exploits through cross-contract analysis.IEEE Trans. Inf. F orensics Secur ., 20:11759–11774, 2025

    2025

  2. [2]

    Dual-view aware smart contract vulnerability detection for Ethereum.arXiv preprint arXiv:2407.00336v1, 2024

    Jiacheng Yao, Maolin Wang, Wanqi Chen, Chengxiang Jin, Jiajun Zhou, Shanqing Yu, and Qi Xuan. Dual-view aware smart contract vulnerability detection for Ethereum.arXiv preprint arXiv:2407.00336v1, 2024

    Pith/arXiv arXiv 2024

  3. [3]

    Interaction-aware vulnerability detection in smart contract bytecodes.IEEE Trans

    Wenkai Li, Xiaoqi Li, Yingjie Mao, and Yuqing Zhang. Interaction-aware vulnerability detection in smart contract bytecodes.IEEE Trans. Dependable Secur . Comput., 23(1):298–315, 2025

    2025

  4. [4]

    SmartBugBert: BERT-enhanced vulnerability detection for smart contract bytecode.arXiv, abs/2504.05002, 2025

    Jiuyang Bu, Wenkai Li, Zongwei Li, Zeng Zhang, and Xiaoqi Li. SmartBugBert: BERT-enhanced vulnerability detection for smart contract bytecode.arXiv, abs/2504.05002, 2025

    arXiv 2025

  5. [5]

    Detection of vulnerabilities of blockchain smart contracts.IEEE Internet Things J., 10(14):12178–12185, 2023

    Daojing He, Rui Wu, Xinji Li, Sammy Chan, and Mohsen Guizani. Detection of vulnerabilities of blockchain smart contracts.IEEE Internet Things J., 10(14):12178–12185, 2023

    2023

  6. [6]

    AtomGraph: Tackling atomicity violation in smart contracts using multimodal GCNs.NIER@ICSE, pages 86–90, 2025

    Xiaoqi Li, Zongwei Li, Wenkai Li, Zeng Zhang, and Lei Xie. AtomGraph: Tackling atomicity violation in smart contracts using multimodal GCNs.NIER@ICSE, pages 86–90, 2025

    2025

  7. [7]

    Mojtaba Eshghie, Wolfgang Ahrendt, Cyrille Artho, Thomas Hildebrandt, and Gerardo Schneider. HighGuard: Cross-chain business logic monitoring of smart contracts.39th IEEE/ACM International Conference on Automated Software Engineering, October 27-November 1, 2024, Sacramento, CA, USA, 2023

    2024

  8. [8]

    Exploring vulnerabilities and concerns in Solana smart contracts.arXiv.org, abs/2504.07419, 2025

    Xiangfan Wu, Ju Xing, and Xiaoqi Li. Exploring vulnerabilities and concerns in Solana smart contracts.arXiv.org, abs/2504.07419, 2025

    Pith/arXiv arXiv 2025

  9. [9]

    OpenSCV: An open hierarchical taxonomy for smart contract vulnerabilities.Empirical Software Engineering, 2024, 2023

    Fernando Vidal, Naghmeh Ivaki, and Nuno Laranjeiro. OpenSCV: An open hierarchical taxonomy for smart contract vulnerabilities.Empirical Software Engineering, 2024, 2023

    2024

  10. [10]

    Demystifying exploitable bugs in smart contracts.ICSE, pages 615–627, 2023

    Zhuo Zhang, Brian Zhang, Wen Xu, and Zhiqiang Lin. Demystifying exploitable bugs in smart contracts.ICSE, pages 615–627, 2023

    2023

  11. [11]

    Systematic Review of Security Vulnerabilities in Ethereum Blockchain Smart Contract.IEEE Access, 2022

    Satpal Singh Kushwaha, Sandeep Joshi, Dilbag Singh, Manjit Kaur, and Heung-No Lee. Systematic Review of Security Vulnerabilities in Ethereum Blockchain Smart Contract.IEEE Access, 2022

    2022

  12. [12]

    Large language model-based smart contract auditing with LLMBugScanner.arXiv, abs/2512.02069, 2025

    Yining Yuan, Yifei Wang, Yichang Xu, Zachary Yahn, Sihao Hu, and Ling Liu. Large language model-based smart contract auditing with LLMBugScanner.arXiv, abs/2512.02069, 2025

    arXiv 2025

  13. [13]

    SmartAuditFlow: A dynamic plan-execute framework for advanced smart contract security analysis.ACM Transactions on Software Engineering and Methodology, 2025

    Zhiyuan Wei, Jing Sun, Zhe Hou, Zijian Zhang, Zixiao Zhao, Chunmiao Li, Mingchao Wan, and Jin Dong. SmartAuditFlow: A dynamic plan-execute framework for advanced smart contract security analysis.ACM Transactions on Software Engineering and Methodology, 2025

    2025

  14. [14]

    Smart contract: Attacks and protections.IEEE Access, 2020

    S Sayeed, H Marco-Gisbert, and T Caira. Smart contract: Attacks and protections.IEEE Access, 2020

    2020

  15. [15]

    Are we there yet? Unraveling the state-of-the-art smart contract fuzzers.ICSE, pages 1–13, 2024

    Shuohan Wu, Zihao Li, Luyi Yan, Weimin Chen, Muhui Jiang, Chenxu Wang, Xiapu Luo, and Hao Zhou. Are we there yet? Unraveling the state-of-the-art smart contract fuzzers.ICSE, pages 1–13, 2024

    2024

  16. [16]

    How do smart contracts benefit security protocols?arXiv.org, abs/2202.08699, 2022

    Rujia Li, Qin Wang, Qi Wang, and Galindo. How do smart contracts benefit security protocols?arXiv.org, abs/2202.08699, 2022. 9 Ethereum NFT Vulnerability Detection

    Pith/arXiv arXiv 2022

  17. [17]

    Navigating co-evolution: A multi-level analysis of socio-technical transitions in NFT ecosystems

    Yifan Cao. Navigating co-evolution: A multi-level analysis of socio-technical transitions in NFT ecosystems. arXiv preprint, 2025

    2025

  18. [18]

    PKI Ecosystem for Reliable Smart Contracts and NFT.2022 IEEE International Conference on Public Key Infrastructure and its Applications (PKIA), 2022

    Balaji Rajendran and Anoop Kumar Pandey. PKI Ecosystem for Reliable Smart Contracts and NFT.2022 IEEE International Conference on Public Key Infrastructure and its Applications (PKIA), 2022

    2022

  19. [19]

    Resolving NFT and smart contract disputes.SSRN Electronic Journal, 2022

    Amy Schmitz. Resolving NFT and smart contract disputes.SSRN Electronic Journal, 2022

    2022

  20. [20]

    The metaverse: Financial assurance procedures in smart contracts and NFTs.International Journal of Religion, 5(11):223–232, 2024

    Angela Ariza, Marleny Marín, and Mayeth Duran. The metaverse: Financial assurance procedures in smart contracts and NFTs.International Journal of Religion, 5(11):223–232, 2024

    2024

  21. [21]

    NFT application for music industry using blockchain smart contracts.2023 4th International Conference on Innovative Trends in Information Technology (ICITIIT), pages 1–6, 2023

    Tharun, Vamshi, and Eswari. NFT application for music industry using blockchain smart contracts.2023 4th International Conference on Innovative Trends in Information Technology (ICITIIT), pages 1–6, 2023

    2023

  22. [22]

    Beyond the Hype: A Large-Scale Empirical Analysis of On-Chain Transactions in NFT Scams.arXiv, abs/2512.01577, 2025

    Wenkai Li, Zongwei Li, Xiaoqi Li, Chunyi Zhang, Xiaoyan Zhang, and Yuqing Zhang. Beyond the Hype: A Large-Scale Empirical Analysis of On-Chain Transactions in NFT Scams.arXiv, abs/2512.01577, 2025

    arXiv 2025

  23. [23]

    Formal Modeling and Verification of ERC Smart Contracts: Application to NFT.ISCC, 2023

    Rim Ben Fekih, Mariam Lahami, Mohamed Jmaiel, and Salma Bradai. Formal Modeling and Verification of ERC Smart Contracts: Application to NFT.ISCC, 2023

    2023

  24. [24]

    Smart contract testing.WETSEB@ICSE, pages 21–24, 2022

    Morena Barboni, Andrea Morichetta, and Andrea Polini. Smart contract testing.WETSEB@ICSE, pages 21–24, 2022

    2022

  25. [25]

    IntelliCon: Confidence-Based Approach for Fine-Grained Vulnerability Analysis in Smart Contracts.Communications in Computer and Information Science, pages 45–59, 2023

    Yiming Shen, Kunhua Li, Lin Mao, Wenkai Li, and Xiaoqi Li. IntelliCon: Confidence-Based Approach for Fine-Grained Vulnerability Analysis in Smart Contracts.Communications in Computer and Information Science, pages 45–59, 2023

    2023

  26. [26]

    Graph neural networks enhanced smart contract vulnerability detection of educational blockchain.arXiv preprint arXiv:2303.04477v1, 2023

    Zhifeng Wang, Wanxuan Wu, Chunyan Zeng, Jialong Yao, Yang Yang, and Hongmin Xu. Graph neural networks enhanced smart contract vulnerability detection of educational blockchain.arXiv preprint arXiv:2303.04477v1, 2023

    Pith/arXiv arXiv 2023

  27. [27]

    CKG-LLM: LLM-Assisted Detection of Smart Contract Access Control Vulnerabilities Based on Knowledge Graphs.arXiv.org, abs/2512.06846, 2025

    Xiaoqi Li, Hailu Kuang, Wenkai Li, Zongwei Li, and Shipeng Ye. CKG-LLM: LLM-Assisted Detection of Smart Contract Access Control Vulnerabilities Based on Knowledge Graphs.arXiv.org, abs/2512.06846, 2025

    Pith/arXiv arXiv 2025

  28. [28]

    DoS Attacks and Defense Technologies in Blockchain Systems: A Hierarchical Analysis.arXiv.org, 2025

    Chunyi Zhang, Fengjiao Dou, and Xiaoqi Li. DoS Attacks and Defense Technologies in Blockchain Systems: A Hierarchical Analysis.arXiv.org, 2025

    2025

  29. [29]

    Have we solved access control vulnerability detection in smart contracts? A benchmark study.ASE, pages 1995–2007, 2025

    Han Liu, Daoyuan Wu, Yuqiang Sun, Shuai Wang, and Yang Liu. Have we solved access control vulnerability detection in smart contracts? A benchmark study.ASE, pages 1995–2007, 2025

    1995

  30. [30]

    PrefGen: A preference-driven methodology for secure yet gas-efficient smart contract generation.ASE, pages 317–329, 2025

    Zhiyuan Peng, Xin Yin, Zijie Zhou, Chenhao Ying, Chao Ni, and Yuan Luo. PrefGen: A preference-driven methodology for secure yet gas-efficient smart contract generation.ASE, pages 317–329, 2025

    2025

  31. [31]

    Introduction to smart contracts and DeFi

    Gurdip Kaur, Arash Lashkari, Iman Sharafaldin, and Ziba Lashkari. Introduction to smart contracts and DeFi. Financial innovation and technology, pages 29–56, 2023

    2023

  32. [32]

    What are smart contracts and how do they work?ITNOW, 64(3):50–51, 2022

    Alan Ma. What are smart contracts and how do they work?ITNOW, 64(3):50–51, 2022

    2022

  33. [33]

    Smart contracts and blockchain: An analytical approach.IC3I, pages 1139–1142, 2023

    Anu Sayal, Chetlur Vasundhara, Veethika Gupta, Ashulekha Gupta, Himani Maheshawri, and Minakshi Memoria. Smart contracts and blockchain: An analytical approach.IC3I, pages 1139–1142, 2023

    2023

  34. [34]

    Smart contracts and decentralized finance.Annual Review of Financial Economics, 15(1):523–542, 2023

    Kose John, Leonid Kogan, and Fahad Saleh. Smart contracts and decentralized finance.Annual Review of Financial Economics, 15(1):523–542, 2023

    2023

  35. [35]

    A Multi-Layered Security Analysis of Blockchain Systems: From Attack Vectors to Defense and System Hardening.arXiv, abs/2504.09181, 2025

    Yuhuan Yang, Shipeng Ye, and Xiaoqi Li. A Multi-Layered Security Analysis of Blockchain Systems: From Attack Vectors to Defense and System Hardening.arXiv, abs/2504.09181, 2025

    Pith/arXiv arXiv 2025

  36. [36]

    Smart contracts in blockchain technology: A critical review.SHILAP Revista de Lepi- dopterología, 14(2):117–117, 2023

    Hamed Taherdoost. Smart contracts in blockchain technology: A critical review.SHILAP Revista de Lepi- dopterología, 14(2):117–117, 2023

    2023

  37. [37]

    Implementation and Security Analysis of Cryptocurrencies Based on Ethereum.arXiv, 2025

    Pengfei Gao, Dechao Kong, and Xiaoqi Li. Implementation and Security Analysis of Cryptocurrencies Based on Ethereum.arXiv, 2025

    2025

  38. [38]

    A survey of application research based on blockchain smart contract.Wirel

    Shiyi Lin, Lei Zhang, Jing Li, Li-li Ji, and Yue Sun. A survey of application research based on blockchain smart contract.Wirel. Networks, 28(2):635–690, 2022

    2022

  39. [39]

    Macroeconomic implications of the introduction of smart contracts in the banking sector

    Stanislav Kostyuk. Macroeconomic implications of the introduction of smart contracts in the banking sector. Journal of Monetary Economics and Management, 2025

    2025

  40. [40]

    To what extent can smart contracts replace traditional contracts in construction projects?Engineering Construction & Architectural Management, 32(3):1393–1410, 2023

    Haizhe Yu, Xiaopeng Deng, and Na Zhang. To what extent can smart contracts replace traditional contracts in construction projects?Engineering Construction & Architectural Management, 32(3):1393–1410, 2023

    2023

  41. [41]

    Systematic literature review on smart contracts in the construction industry: Potentials, benefits, and challenges.Frontiers of Engineering Management, 9(2):196–213, 2022

    Xuling Ye, Ningshuang Zeng, and Markus König. Systematic literature review on smart contracts in the construction industry: Potentials, benefits, and challenges.Frontiers of Engineering Management, 9(2):196–213, 2022. 10 Ethereum NFT Vulnerability Detection

    2022

  42. [42]

    The value of smart contract in trade finance.Manufacturing & Service Operations Management, 2022

    Xiaoyu Wang and Fasheng Xu. The value of smart contract in trade finance.Manufacturing & Service Operations Management, 2022

    2022

  43. [43]

    Kajian penerapan smart contract syariah dalam blockchain: Peluang dan tantangan.Jurnal Jatiswara, 38(2):223–232, 2023

    Winda Fitri. Kajian penerapan smart contract syariah dalam blockchain: Peluang dan tantangan.Jurnal Jatiswara, 38(2):223–232, 2023

    2023

  44. [44]

    A non-contractual approach to smart contracts.Int

    Florian Gamper. A non-contractual approach to smart contracts.Int. J. Law Inf. Technol., 31(3):231–252, 2023

    2023

  45. [45]

    Smart contract languages: A comparative analysis.Future Gener

    Massimo Bartoletti, Lorenzo Benetollo, Michele Bugliesi, Silvia Crafa, Giacomo Dal Sasso, Roberto Pettinau, Andrea Pinna, Mattia Piras, Sabina Rossi, Stefano Salis, Alvise Spanò, Viacheslav Tkachenko, Roberto Tonelli, and Roberto Zunino. Smart contract languages: A comparative analysis.Future Gener . Comput. Syst., 164:107563– 107563, 2024

    2024

  46. [46]

    Standardizing smart contracts.IEEE Access, 10:91203–91212, 2022

    Vittorio Capocasale and Guido Perboli. Standardizing smart contracts.IEEE Access, 10:91203–91212, 2022

    2022

  47. [47]

    Declarative smart contracts

    Haoxian Chen, Gerald Whitters, Mohammad Amiri, Yuepeng Wang, and Boon Loo. Declarative smart contracts. ESEC/SIGSOFT FSE, pages 281–293, 2022

    2022

  48. [48]

    Smart contract broker: Improving smart contract reusability in a blockchain environment.Sensors (Basel, Switzerland), 23(13):6149–6149, 2023

    Joonseok Park, Sumin Jeong, and Keunhyuk Yeom. Smart contract broker: Improving smart contract reusability in a blockchain environment.Sensors (Basel, Switzerland), 23(13):6149–6149, 2023

    2023

  49. [49]

    Semantic interoperability on blockchain by generating smart contracts based on knowledge graphs.arXiv preprint arXiv:2409.12171v1, 2024

    William Van Woensel and Oshani Seneviratne. Semantic interoperability on blockchain by generating smart contracts based on knowledge graphs.arXiv preprint arXiv:2409.12171v1, 2024

    Pith/arXiv arXiv 2024

  50. [50]

    Secure-by-design smart contract based on dataflow implementations

    Simone Casale-Brunet and Marco Mattavelli. Secure-by-design smart contract based on dataflow implementations. arXiv preprint arXiv:2309.17200v2, 2023

    Pith/arXiv arXiv 2023

  51. [51]

    Trusting a smart contract means trusting its owners: Understanding centralization risk.arXiv preprint arXiv:2312.06510v1, 2023

    Metin Lamby, Valentin Zieglmeier, and Christian Ziegler. Trusting a smart contract means trusting its owners: Understanding centralization risk.arXiv preprint arXiv:2312.06510v1, 2023

    Pith/arXiv arXiv 2023

  52. [52]

    A review of smart contract blockchain based on multi-criteria analysis: Challenges and motivations.arXiv preprint arXiv:2302.08496v1, 2023

    Norah Alshahrani, Mat Kiah, Zaidan, Alamoodi, and Abdu Saif. A review of smart contract blockchain based on multi-criteria analysis: Challenges and motivations.arXiv preprint arXiv:2302.08496v1, 2023

    Pith/arXiv arXiv 2023

  53. [53]

    ExplanaSC: A framework for determining information requirements for explainable blockchain smart contracts.IEEE Trans

    Hanouf Al Ghanmi and Rami Bahsoon. ExplanaSC: A framework for determining information requirements for explainable blockchain smart contracts.IEEE Trans. Software Eng., 50(8):1984–2004, 2024

    1984

  54. [54]

    Blockchain Security Based on Cryptography: A Review.arXiv, abs/2508.01280, 2025

    Wenwen Zhou, Dongyang Lyu, and Xiaoqi Li. Blockchain Security Based on Cryptography: A Review.arXiv, abs/2508.01280, 2025

    Pith/arXiv arXiv 2025

  55. [55]

    Metamorphic Testing for Smart Contract Vulnerabilities Detection.arXiv preprint arXiv:2303.03179v1, 2023

    Jiahao Li. Metamorphic Testing for Smart Contract Vulnerabilities Detection.arXiv preprint arXiv:2303.03179v1, 2023

    Pith/arXiv arXiv 2023

  56. [56]

    ItyFuzz: Snapshot-Based Fuzzer for Smart Contract.ISSTA, pages 322–333, 2023

    Chaofan Shou, Shangyin Tan, and Koushik Sen. ItyFuzz: Snapshot-Based Fuzzer for Smart Contract.ISSTA, pages 322–333, 2023

    2023

  57. [57]

    A Comprehensive Study of Exploitable Patterns in Smart Contracts: From Vulnerability to Defense.arXiv, abs/2504.21480, 2025

    Yuchen Ding, Hongli Peng, and Xiaoqi Li. A Comprehensive Study of Exploitable Patterns in Smart Contracts: From Vulnerability to Defense.arXiv, abs/2504.21480, 2025

    Pith/arXiv arXiv 2025

  58. [58]

    Francesco Salzano, Lodovica Marchesi, Cosmo Antenucci, Simone Scalabrino, Roberto Tonelli, Rocco Oliveto, and Remo Pareschi. Bridging the gap: A comparative study of academic and developer approaches to smart contract vulnerabilities.Bridging the gap: a comparative study of academic and developer approaches to smart contract vulnerabilities. Empirical Sof...

    2026

  59. [59]

    Smart contract security beyond detection.arXiv preprint arXiv:2605.09124v2, 2026

    Tamer Abdelaziz. Smart contract security beyond detection.arXiv preprint arXiv:2605.09124v2, 2026

    Pith/arXiv arXiv 2026

  60. [60]

    No More Hidden Pitfalls? Exposing Smart Contract Bad Practices with LLM-Powered Hybrid Analysis.ACM Transactions on Software Engineering and Methodology, abs/2512.15179, 2025

    Xiaoqi Li, Zongwei Li, Wenkai Li, Yuqing Zhang, and Xin Wang. No More Hidden Pitfalls? Exposing Smart Contract Bad Practices with LLM-Powered Hybrid Analysis.ACM Transactions on Software Engineering and Methodology, abs/2512.15179, 2025

    arXiv 2025

  61. [61]

    Facial Recognition Leveraging Generative Adversarial Networks

    Zhongwen Li, Zongwei Li, and Xiaoqi Li. Facial Recognition Leveraging Generative Adversarial Networks. arXiv, abs/2505.11884, 2025

    arXiv 2025

  62. [62]

    Defensible Design for OpenClaw: Securing Autonomous Tool-Invoking Agents.arXiv, abs/2603.13151, 2026

    Zongwei Li, Wenkai Li, and Xiaoqi Li. Defensible Design for OpenClaw: Securing Autonomous Tool-Invoking Agents.arXiv, abs/2603.13151, 2026. 11

    arXiv 2026

This paper was first reviewed by deepseek-v4-flash on August 1, 2026.