Pith. sign in

REVIEW 5 major objections 8 minor 48 references

AiRacleX: Automated Detection of Price Oracle Manipulations via LLM-Driven Knowledge Mining and Prompt Generation

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

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

Pith's one-line read The paper claims a three-LLM pipeline lifts price-oracle-manipulation recall from 0.259 to 0.667 versus GPTScan at comparable precision.

desk verdict A genuinely new three-LLM pipeline for price oracle manipulation detection with a real out-of-sample recall gain over GPTScan, but the headline 2.58x number is selected on the same set that produced it and the matching procedure is underspecified. read the letter →

arxiv 2502.06348 v2 pith:7EN5IUTY submitted 2025-02-10 cs.CR cs.AI

Bo Gao , Yuan Wang , Qingsong Wei , Yong Liu , Rick Siow Mong Goh , David Lo This is my paper · ORCID
classification cs.CRcs.AI
keywords priceoraclemanipulationsmartcontractvulnerabilitydetectionlargelanguagemodelschain-of-thoughtpromptingpromptengineeringdomainknowledgesynthesisDeFisecurityauditautomation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper claims that price oracle manipulation (POM) detection can be fully automated as a three-stage LLM pipeline: a Knowledge Synthesizer distills a definition of POM from excerpts of seven academic papers, a Prompt Generator turns that definition into a structured chain-of-thought audit prompt, and an Auditor follows the prompt to flag vulnerable functions in Solidity code. On 60 known vulnerabilities from 46 real DeFi attacks and audit contests, the best LLM combination (Claude Haiku for knowledge and prompt generation, GPT-4o-mini for auditing) reaches 0.667 recall against 0.259 for GPTScan on the attack dataset, a 2.58x improvement at comparable precision, and 0.54 recall against 0.13 on the Code4Rena set. The paper also claims the LLM-written knowledge summary slightly outperforms human-curated knowledge (F1 0.426 vs 0.424), so the framework needs no price-oracle expert to run. A sympathetic reader would care because this is a bug class that static analysis tools and plain LLM audits mostly miss, and the result suggests the bottleneck is prompt design and knowledge grounding, not model scale.

What carries the argument

The load-bearing object is the generated chain-of-thought prompt. Rather than handing the Auditor a generic 'find vulnerabilities' instruction, AiRacleX has the Prompt Generator write a structured protocol with numbered steps and per-step questions (identify the price oracle; determine whether the contract relies on it without cross-checking; evaluate financial impact; recommend mitigations), grounded only in the definition produced by the Knowledge Synthesizer. The knowledge step matters because it replaces web-scale pre-training noise with externally validated descriptions drawn from seven peer-reviewed papers on oracle manipulation. The Auditor is run with temperature 1.0 and the same prompt three times, and outputs are collected as JSON so findings can be attributed to contract and function.

What would settle it

Run the Haiku-Haiku-4o-mini configuration on the dataset and count a true positive only when the model's JSON contract and function names exactly match the ground-truth vulnerable function; if recall falls toward GPTScan's 0.259, the 2.58x improvement is an artifact of loose function matching.

Watch

Extended reading notes

Core claim

The central discovery, on the paper's own terms, is that the hard part of POM detection is not the detector but the instruction: giving the model a step-by-step audit protocol written from a distilled problem definition lifts recall from 0.259 to 0.667 while precision stays roughly level. The pipeline's best configuration, Haiku as both Knowledge Synthesizer and Prompt Generator with 4o-mini as Auditor, also beats GPTScan on the more complex Code4Rena benchmark (recall 0.54 vs 0.13, F1 0.157 vs 0.107) and finds 20 vulnerabilities that GPTScan misses. The paper attributes the gain to three prompt-engineering moves: role-based framing, positive and negative prompts that suppress pre-training noise (e.g., not treating an oracle owner's ability to change a feed as a POM bug), and an output schema that forces the model to name beneficiary, victim, and reason before returning a verdict. It also reports that smaller models produce less conservative output, yielding more findings and fewer false negatives, which is why the best configuration uses no flagship model.

Load-bearing premise

The whole comparison rests on the manually checked ground-truth labels and on an unpublished rule for deciding when an AiRacleX finding (contract name plus function name) counts as a hit; if that rule is lenient, the reported recall and precision are artifacts of matching rather than of detection quality.

Editorial extensions

If this is right

  • If the reported recall gain is real, an auditor using Haiku-Haiku-4o-mini would catch about two-thirds of POM vulnerabilities in the benchmarked attack dataset, versus one-quarter for GPTScan, at roughly the same false-alarm rate.
  • Because the knowledge synthesizer takes academic excerpts as input, the framework is transferable to other machine-unauditable bug classes by swapping the source papers, without writing new rules or static-analysis validators.
  • The best performance from smaller, cheaper models implies that the design bottleneck is prompt quality rather than model capability, which lowers the cost of deploying the detector.
  • The structured output (contract, function, beneficiary, victim, reason) makes each finding directly interpretable and removes the need for the static-analysis validation workflow that GPTScan relies on.
  • On Code4Rena, precision is only 0.092, so in realistic multi-file contracts the framework is a high-recall pre-filter whose many false positives still require human triage.

Reading between the lines

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

  • The reported 2.58x recall ratio should be read with caution until the paper publishes its finding-matching rule: the authors count true positives per function while GPTScan counted vulnerability types, and Section 4.1 says bugs were manually checked but does not say how a JSON finding is matched to a ground-truth bug; lenient matching would inflate the gain.
  • A direct test of the transferability claim would be to point the same three-LLM pipeline at other machine-unauditable bug categories from the same taxonomy the paper cites, such as inconsistent state updates, and measure whether recall behaves like the POM results.
  • Because the Auditor is stochastic (temperature 1.0, three repeats), deployment would need per-run stability reporting; a single averaged run could overstate or understate detection rates for a specific contract.
  • The framework's low precision on Code4Rena suggests a practical extension the authors do not build: a fourth stage that clusters or ranks the Auditor's findings to let a human review a short list, rather than hundreds of alarms.
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

5 major / 8 minor

Summary. The paper presents AiRacleX, a three-stage LLM pipeline for detecting price oracle manipulation (POM) vulnerabilities in Solidity smart contracts. A Knowledge Synthesizer distills domain knowledge from seven academic papers, a Prompt Generator converts the synthesized knowledge into structured chain-of-thought prompts, and an Auditor LLM applies the prompts to contract code and outputs JSON findings. The authors evaluate 16 model configurations on a DeFiHacks dataset (31 projects, 36 vulnerabilities) and select the best combination (Claude Haiku as synthesizer and prompt generator, GPT-4o-mini as auditor). On this same dataset, the selected configuration achieves recall 0.667 and precision 0.313, versus GPTScan's 0.259 and 0.311. On a separate Code4Rena dataset (14 projects, 24 vulnerabilities), the same configuration achieves recall 0.54 and precision 0.092, versus GPTScan's 0.13 and 0.094. The paper claims a 2.58x recall improvement over GPTScan with comparable precision.

Significance. If the results are representative, AiRacleX would be a meaningful advance in automated smart-contract auditing: it removes the need for hand-crafted rules, shows that a combination of small models can outperform a larger single model, and the Code4Rena evaluation provides a partially out-of-sample check in which the selected configuration more than quadruples GPTScan's recall. The paper is also commendable for making its prompts and curated knowledge available in the appendix, which supports reproducibility. However, the headline claim rests on in-sample model selection, the evaluation pipeline lacks an explicit finding-to-ground-truth matching rule, and the knowledge sources overlap with the test incidents, so the current evidence does not establish the claimed improvement at the stated magnitude.

major comments (5)
  1. [§4.4–§4.5, Tables 4–6] The best configuration is selected on DeFiHacks and then the same DeFiHacks set is used to report the headline '2.58-times improvement' (Finding 3; abstract). This is a selection-on-the-test-set procedure: the reported 0.667 recall / 0.313 precision is the maximum over 16 configurations evaluated on the same 36 vulnerabilities, not the performance of a pre-specified detector. The Code4Rena results (Table 7) are the only out-of-sample evidence, and they show precision of 0.092 for both tools, which does not support the 'comparable precision' claim in the abstract. Please report the selected configuration's performance on a held-out set as the primary claim, or use nested selection and report the selection bias.
  2. [§4.4.1–§4.4.2] The paper never specifies how an AiRacleX JSON finding (contract name, function name, beneficiary, victim, reason) is matched to a ground-truth vulnerability. The note in Section 4.4.1 says GPTScan counts vulnerability types while the authors count per-function true positives, but the actual matching rule—including how renamed/partial functions, multiple functions in one finding, and findings spread over the three repeated runs are handled—is absent. Without this rule, the reported precision and recall are not reproducible, and they could be artifacts of a lenient or ambiguous matching function. Please publish the matching procedure and the raw per-run outputs.
  3. [§3.2.1 and §4.1] The knowledge sources used by the Knowledge Synthesizer include refs [40] and [44], which analyze the same real-world attack incidents and Code4Rena projects that constitute the test sets. For example, Section 4.1.1 draws 20 DeFiHacks projects from the SoK [44], and Section 4.1.2 draws 6 Code4Rena projects from Zhang et al. [40]. Since the synthesized knowledge may therefore contain incident-specific details (project names, attack procedures) that are directly relevant to the test instances, the measured improvement over GPTScan may partly reflect leakage rather than generalizable detection. Please demonstrate that the distilled knowledge does not contain test-specific information, or evaluate on incidents whose analyses are excluded from the knowledge sources.
  4. [§4.2] GPTScan is evaluated after two modifications: replacing ChatGPT-3.5 with ChatGPT-4o-mini and changing the tool's code to enforce structured JSON output. The comparison is therefore against a modified version of the published SOTA tool, not the tool as originally reported, and the original GPTScan's metric (vulnerability types) differs from the per-function TP metric used here (Section 4.4.1). Please justify that the modifications are neutral or favorable to GPTScan, and report original GPTScan results under both counting conventions.
  5. [§4.3 and Tables 4–6] Each experiment is run three times and only averages are shown; no variance, confidence intervals, or significance tests are reported. Several configuration differences that drive the selection (e.g., F1 0.424 vs 0.421 in Section 4.4.2) are smaller than the typical run-to-run variability of temperature=1.0 sampling of an LLM auditor. Please report per-run values and a measure of dispersion or a statistical test, so that the model-selection decisions are distinguishable from noise.
minor comments (8)
  1. [§2.2] In the hybrid oracles bullet, 'Extra Finace2' should be 'Extra Finance' and the footnote marker is malformed.
  2. [§2.1] The phrase 'Constant Product Formula (CPF)??' contains stray question marks and should be cleaned up.
  3. [§4.1.1–§4.1.2] The exclusion criteria ('excluded two projects that were unrelated', 'excluded two misclassified projects and three incomplete ones') are post-hoc and the excluded project names are not listed; please list them for transparency.
  4. [§3.2.2] The prose refers to text highlighted in orange, brown, blue and red, but the manuscript renders these examples in plain black text; please add visible formatting or color legends.
  5. [§1, Contributions] The contribution bullet '20 bugs which can only be detected by AiRacleX but not by GPTScan' is not directly supported by a table; the TP differences in Tables 4 and 7 suggest a different number, and a detailed breakdown would help verify the claim.
  6. [Table 5] The column header layout of Table 5 is hard to read; consider a multi-level header or separate tables per auditor.
  7. [§3.2.2] Reference [41] is cited as 'Zhang et al.' but the reference entry lists Zheng et al.; please correct the citation.
  8. [Abstract] The abstract says 'demonstrate' where 'demonstrates' would agree with the singular subject; a light grammar pass would improve readability.

Circularity Check

1 steps flagged · score 4.0 of 10

Headline recall gain is the in-sample best configuration chosen on the same DeFiHacks test set; out-of-sample Code4Rena results provide partial independent support.

  1. fitted input called prediction [Section 4.4.1–4.4.3, Table 6, Finding 3; Abstract]
    "The DeFiHacks dataset was chosen because it allows for more efficient manual verification of the outputs, facilitating the identification of optimal parameter combinations. ... The combination of Haiku-Haiku-4o-mini achieved the highest F1 score (0.426), slightly outperforming the human-curated knowledge framework (0.424). ... The best performing combination of LLMs (Haiku-Haiku-4o-mini) identified by AiRacleX demonstrate a 2.58-times improvement in recall (0.667 vs 0.259) compared to the state-of-the-art tool GPTScan, while maintaining comparable precision."

    All three selection stages in Section 4.4 (Auditor in 4.4.1, Prompt Generator in 4.4.2, Knowledge Synthesizer in 4.4.3) are scored on the DeFiHacks ground truth. Finding 3 then selects Haiku-Haiku-4o-mini as having the highest F1 on that same set, and the Abstract reports this selected cell's DeFiHacks recall and precision (0.667 and 0.313) as the headline '2.58-times improvement'. These numbers are the in-sample maximum over the configurations tried on the evaluation set, not the performance of a pre-specified detector: the reported result is, by construction, the score of the configuration chosen using those same labels.

full rationale

The main circularity is evaluative rather than derivational: the best LLM combination is selected by optimizing F1 on DeFiHacks, and the same DeFiHacks numbers are then reported as the framework's headline performance. This makes the abstract's 0.667 recall figure an in-sample maximum over the tested configurations, not an independent estimate. The Code4Rena experiments partly mitigate this: the same configuration achieves recall 0.54 vs. GPTScan's 0.13 out-of-sample, so the qualitative recall improvement is externally supported. The precision claim is also roughly reproduced (0.092 vs. 0.094), though both are very low. There is also a benchmark-contamination concern: the knowledge synthesizer's input includes reference [40], which is also the source of six Code4Rena ground-truth projects, and several other knowledge papers analyzed the same real-world incidents used in the DeFiHacks set. This is a leakage risk rather than a mathematical reduction, since the synthesized knowledge is a general POM definition and the auditor must still locate the vulnerable functions in code. No load-bearing self-citation or imported uniqueness theorem is present; the authors' own prior work appears only as background evaluation context. Overall, the central claim retains independent content through the out-of-sample Code4Rena benchmark, so the score is 4 rather than higher.

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

The claim is empirical, so the ledger contains no fitted physical constants or derivations. The load-bearing numbers are experimental controls: model selection, decoding parameters, number of runs, and dataset inclusion choices. The domain assumptions are that audit reports and attack post-mortems supply correct labels, that seven academic papers supply complete POM knowledge, and that LLM JSON output can be matched to functions. No invented entities are introduced.

free parameters (3)
  • Best combination (Knowledge Synthesizer, Prompt Generator, Auditor) = Haiku, Haiku, 4o-mini
    Selected by F1 on DeFiHacks (Section 4.4), then reported as the headline result on the same dataset; this is selection on the test set.
  • Decoding settings = temp=0/0/1.0; top_p=1.0; max_tokens=1024
    Table 3, chosen by hand; they change output diversity and therefore reported precision and recall.
  • Number of repeated runs and aggregation = 3 runs, averaged
    Section 4.3, no confidence intervals; small differences such as 0.426 vs 0.424 are treated as meaningful.
assumptions (5)
  • domain assumption Code4rena audit reports and DeFiHacks post-mortems provide correct and complete ground truth for POM vulnerabilities.
    Section 4.1.2 trusts the incentive-driven audit process; no independent label verification or inter-rater agreement is reported.
  • domain assumption The seven selected papers [6,16,22,32,37,38,40] contain sufficient and accurate knowledge to define POM for detection purposes.
    Section 3.2.1 states these are the sole knowledge source; no ablation tests whether the set is complete or whether the papers' incident analyses leak answers to the test contracts.
  • domain assumption LLM JSON findings can be matched unambiguously to ground-truth vulnerable functions.
    Section 4 output format includes contract, function, beneficiary, victim, but the matching algorithm is not specified.
  • ad hoc to paper Averaging three stochastic runs gives a stable estimate of performance.
    Section 4.3; no confidence intervals, and differences as small as 0.002 in F1 are used to select the best configuration.
  • standard math Precision and recall computed over per-function counts are the right evaluation metrics for this task.
    Appendix D defines the formulas; using per-function matching instead of GPTScan's per-project vulnerability-type counting changes results (Section 4.4.1).

how reviews work

0 comments
Cite this review

Pith. "Pith review of AiRacleX: Automated Detection of Price Oracle Manipulations via LLM-Driven Knowledge Mining and Prompt Generation." pith.science (2026). https://pith.science/paper/7EN5IUTY

@misc{pith2026250206348,
  author       = {Pith},
  title        = {Pith review of: AiRacleX: Automated Detection of Price Oracle Manipulations via LLM-Driven Knowledge Mining and Prompt Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7EN5IUTY}},
  note         = {Machine review of arXiv:2502.06348}
}
read the original abstract

Decentralized finance (DeFi) applications depend on accurate price oracles to ensure secure transactions, yet these oracles are highly vulnerable to manipulation, enabling attackers to exploit smart contract vulnerabilities for unfair asset valuation and financial gain. Detecting such manipulations traditionally relies on the manual effort of experienced experts, presenting significant challenges. In this paper, we propose a novel LLM-driven framework that automates the detection of price oracle manipulations by leveraging the complementary strengths of different LLM models (LLMs). Our approach begins with domain-specific knowledge extraction, where an LLM model synthesizes precise insights about price oracle vulnerabilities from top-tier academic papers, eliminating the need for profound expertise from developers or auditors. This knowledge forms the foundation for a second LLM model to generate structured, context-aware chain of thought prompts, which guide a third LLM model in accurately identifying manipulation patterns in smart contracts. We validate the effectiveness of framework through experiments on 60 known vulnerabilities from 46 real-world DeFi attacks or projects spanning 2021 to 2023. The best performing combination of LLMs (Haiku-Haiku-4o-mini) identified by AiRacleX demonstrate a 2.58-times improvement in recall (0.667 vs 0.259) compared to the state-of-the-art tool GPTScan, while maintaining comparable precision. Furthermore, our framework demonstrates the feasibility of replacing commercial models with open-source alternatives, enhancing privacy and security for developers.

Figures

Figures reproduced from arXiv: 2502.06348 by the authors.

Figure 1
Figure 1. Overview of LLM-driven Automated Detection Framework. [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. F1 Score of Varying Prompt Generator and Auditor with Human-curated Knowledge. [PITH_FULL_IMAGE:figures/full_fig_p015_2.png] view at source ↗
Figure 3
Figure 3. Example function burnAsset with potential flash loan attack vulnerability. The burnAsset function is designed to remove tokens from circulation by burning assets and crediting Fate tokens to users. Fate tokens serve as a governance currency within the ecosystem, granting holders voting power. This function interacts with EYE-based asset tokens, but the asset pricing formula is vulnerable to flash loan manipulation. … view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 33 canonical work pages

  1. [40]

    Zhuo Zhang, Brian Zhang, Wen Xu, and Zhiqiang Lin. 2023. Demystifying exploitable bugs in smart contracts. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 615–627

    work page 2023

  2. [44]

    Liyi Zhou, Xihan Xiong, Jens Ernstberger, Stefanos Chaliasos, Zhipeng Wang, Ye Wang, Kaihua Qin, Roger Wattenhofer, Dawn Song, and Arthur Gervais. 2023. Sok: Decentralized finance (defi) attacks. In 2023 IEEE Symposium on Security and Privacy (SP) . IEEE, 2444–2461. Manuscript submitted to ACM 𝐴𝑖𝑅𝑎𝑐𝑙𝑒𝑋 : Automated Detection of Price Oracle Manipulations v...

    work page 2023

  3. [1]

    Yuanhao Ban, Ruochen Wang, Tianyi Zhou, Minhao Cheng, Boqing Gong, and Cho-Jui Hsieh. 2025. Understanding the Impact of Negative Prompts: When and How Do They Take Effect?. In European Conference on Computer Vision . Springer, 190–206. Manuscript submitted to ACM 𝐴𝑖𝑅𝑎𝑐𝑙𝑒𝑋 : Automated Detection of Price Oracle Manipulations via LLM-Driven Knowledge Mining ...

    work page 2025

  4. [2]

    Stefanos Chaliasos, Marcos Antonios Charalambous, Liyi Zhou, Rafaila Galanopoulou, Arthur Gervais, Dimitris Mitropoulos, and Benjamin Livshits

    work page

  5. [3]

    Code4rena. 2023. Code4rena Contest Platform. https://code4rena.com/ Accessed: 2023-04-16

    work page 2023

  6. [4]

    Consensys. 2024. Mythril: Security analysis tool for EVM bytecode . https://github.com/Consensys/mythril Accessed: 2024-06-06

    work page 2024

  7. [5]

    Isaac David, Liyi Zhou, Kaihua Qin, Dawn Song, Lorenzo Cavallaro, and Arthur Gervais. 2023. Do you still need a manual smart contract audit? arXiv preprint arXiv:2306.12338 (2023)

    arXiv 2023

  8. [6]

    Xun Deng, Sidi Mohamed Beillahi, Cyrus Minwalla, Han Du, Andreas Veneris, and Fan Long. 2024. Safeguarding DeFi Smart Contracts against Oracle Deviations. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering . 1–12

    work page 2024

Show all 48 references
  1. [7]

    Dominik. 2025. Smart Contract Security Field Guide . https://scsfg.io/hackers/oracle-manipulation/#off-chain-infrastructure Accessed: 2025-01-06

    2025

  2. [8]

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

    2019

  3. [9]

    Yao Fu, Hao Peng, Ashish Sabharwal, Peter Clark, and Tushar Khot. 2022. Complexity-based prompting for multi-step reasoning. arXiv preprint arXiv:2210.00720 (2022)

    2022 arXiv

  4. [10]

    Bo Gao, Ling Shi, Jiaying Li, Jialiang Chang, Jun Sun, and Zijiang Yang. 2021. sVerify: Verifying Smart Contracts Through Lazy Annotation and Learning. In Leveraging Applications of Formal Methods, Verification and Validation: 10th International Symposium on Leveraging Applica...

    2021

  5. [11]

    Bo Gao, Qingsong Wei, Yong Liu, and Rick Siow Mong Goh. 2024. Unveiling the Potential of ChatGPT in Detecting Machine Unauditable Bugs in Smart Contracts: A Preliminary Evaluation and Categorization. In 2024 IEEE Conference on Artificial Intelligence (CAI) . IEEE, 1481–1486

    2024

  6. [12]

    Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, and Haofen Wang. 2023. Retrieval-augmented generation for large language models: A survey. arXiv preprint arXiv:2312.10997 (2023)

    2023 arXiv

  7. [13]

    Sihao Hu, Tiansheng Huang, Fatih İlhan, Selim Furkan Tekin, and Ling Liu. 2023. Large language model-powered smart contract vulnerability detection: New perspectives. arXiv preprint arXiv:2310.01152 (2023)

    2023 arXiv

  8. [14]

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

    2018

  9. [15]

    Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, and Yusuke Iwasawa. 2022. Large language models are zero-shot reasoners. Advances in neural information processing systems 35 (2022), 22199–22213

    2022

  10. [16]

    Queping Kong, Jiachi Chen, Yanlin Wang, Zigui Jiang, and Zibin Zheng. 2023. Defitainter: Detecting price manipulation vulnerabilities in defi protocols. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis . 1144–1156

    2023

  11. [17]

    Mauricio Labadie. 2022. Impermanent loss and slippage in Automated Market Makers (AMMs) with constant-product formula. A vailable at SSRN 4053924 (2022)

    2022

  12. [18]

    Qingyao Li, Lingyue Fu, Weiming Zhang, Xianyu Chen, Jingwei Yu, Wei Xia, Weinan Zhang, Ruiming Tang, and Yong Yu. 2023. Adapting large language models for education: Foundational capabilities, potentials, and challenges. arXiv preprint arXiv:2401.08664 (2023)

    2023 arXiv

  13. [19]

    Zhenguang Liu, Peng Qian, Xiaoyang Wang, Yuan Zhuang, Lin Qiu, and Xun Wang. 2021. Combining graph neural networks with expert knowledge for smart contract vulnerability detection. IEEE Transactions on Knowledge and Data Engineering 35, 2 (2021), 1296–1310

    2021

  14. [20]

    Shayne Longpre, Le Hou, Tu Vu, Albert Webson, Hyung Won Chung, Yi Tay, Denny Zhou, Quoc V Le, Barret Zoph, Jason Wei, et al. 2023. The flan collection: Designing data and methods for effective instruction tuning. In International Conference on Machine Learning . PMLR, 22631–22648

    2023

  15. [21]

    Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. 2016. Making smart contracts smarter. In Proceedings of the 2016 ACM SIGSAC conference on computer and communications security . 254–269

    2016

  16. [22]

    Yifan Mo, Jiachi Chen, Yanlin Wang, and Zibin Zheng. 2023. Toward automated detecting unanticipated price feed in smart contract. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis . 1257–1268

    2023

  17. [23]

    Mark Mossberg, Felipe Manzano, Eric Hennenfent, Alex Groce, Gustavo Grieco, Josselin Feist, Trent Brunson, and Artem Dinaburg. 2019. Manticore: A user-friendly symbolic execution framework for binaries and smart contracts. In 2019 34th IEEE/ACM International Conference on Auto...

    2019

  18. [24]

    Bernhard Mueller, Nikhil Parasaram, Joran Honig, and Dominik Muhs. 2024. Mythril. https://github.com/Consensys/mythril. Accessed: 2024-05-23

    2024

  19. [25]

    Tai D Nguyen, Long H Pham, Jun Sun, Yun Lin, and Quang Tran Minh. 2020. sfuzz: An efficient adaptive fuzzer for solidity smart contracts. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering . 778–788

    2020

  20. [26]

    Openai. 2024. Openai API References. https://platform.openai.com/docs/api-reference/chat/create Accessed: 2024-05-26

    2024

  21. [27]

    Protofire. 2024. Solhint: provide a linting utility for Solidity code . https://github.com/protofire/solhint Accessed: 2024-06-06

    2024

  22. [28]

    Sunbeom So, Myungho Lee, Jisu Park, Heejo Lee, and Hakjoo Oh. 2020. VeriSmart: A highly precise safety verifier for Ethereum smart contracts. In 2020 IEEE Symposium on Security and Privacy (SP) . IEEE, 1678–1694

    2020

  23. [29]

    Yuqiang Sun, Daoyuan Wu, Yue Xue, Han Liu, Haijun Wang, Zhengzi Xu, Xiaofei Xie, and Yang Liu. 2023. When gpt meets program analysis: Towards intelligent detection of smart contract logic vulnerabilities in gptscan. arXiv preprint arXiv:2308.03314 (2023)

    2023 arXiv

  24. [30]

    Sergei Tikhomirov, Ekaterina Voskresenskaya, Ivan Ivanitskiy, Ramil Takhaviev, Evgeny Marchenko, and Yaroslav Alexandrov. 2018. Smartcheck: Static analysis of ethereum smart contracts. In Proceedings of the 1st international workshop on emerging trends in software engineering ...

    2018

  25. [31]

    Christof Ferreira Torres, Antonio Ken Iannillo, Arthur Gervais, and Radu State. 2021. Confuzzius: A data dependency-aware hybrid fuzzer for smart contracts. In 2021 IEEE European Symposium on Security and Privacy (EuroS&P) . IEEE, 103–119

    2021

  26. [32]

    Shih-Hung Wang, Chia-Chien Wu, Yu-Chuan Liang, Li-Hsun Hsieh, and Hsu-Chun Hsiao. 2021. ProMutator: Detecting vulnerable price oracles in DeFi by mutated transactions. In 2021 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW) . IEEE, 380–385

    2021

  27. [33]

    Wei Wang, Jingjing Song, Guangquan Xu, Yidong Li, Hao Wang, and Chunhua Su. 2020. Contractward: Automated vulnerability detection models for ethereum smart contracts. IEEE Transactions on Network Science and Engineering 8, 2 (2020), 1133–1144

    2020

  28. [34]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. 2022. Chain-of-thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems 35 (2022), 24824–24837

    2022

  29. [35]

    Hongbo Wen, Hanzhi Liu, Jiaxin Song, Yanju Chen, Wenbo Guo, and Yu Feng. 2024. FORAY: Towards Effective Attack Synthesis against Deep Logical Vulnerabilities in DeFi Protocols. arXiv preprint arXiv:2407.06348 (2024)

    2024 arXiv

  30. [36]

    Gavin Wood et al. 2014. Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper 151, 2014 (2014), 1–32

    2014

  31. [37]

    Siwei Wu, Dabao Wang, Jianting He, Yajin Zhou, Lei Wu, Xingliang Yuan, Qinming He, and Kui Ren. 2021. Defiranger: Detecting price manipulation attacks on defi applications. arXiv preprint arXiv:2104.15068 (2021)

    2021 arXiv

  32. [38]

    Rui Xi, Zehua Wang, and Karthik Pattabiraman. 2024. POMABuster: Detecting Price Oracle Manipulation Attacks in Decentralized Finance. In 2024 IEEE Symposium on Security and Privacy (SP) . IEEE Computer Society, 240–240

    2024

  33. [39]

    Qingren Zeng, Jiahao He, Gansen Zhao, Shuangyin Li, Jingji Yang, Hua Tang, and Haoyu Luo. 2022. EtherGIS: A Vulnerability Detection Framework for Ethereum Smart Contracts Based on Graph Learning Features. In 2022 IEEE 46th Annual Computers, Software, and Applications Conferenc...

    2022

  34. [41]

    a helpful assistant

    Mingqian Zheng, Jiaxin Pei, and David Jurgens. 2023. Is“ a helpful assistant” the best role for large language models? a systematic evaluation of social roles in system prompts. arXiv preprint arXiv:2311.10054 8 (2023)

    2023 arXiv

  35. [42]

    Denny Zhou, Nathanael Schärli, Le Hou, Jason Wei, Nathan Scales, Xuezhi Wang, Dale Schuurmans, Claire Cui, Olivier Bousquet, Quoc Le, et al

  36. [43]

    Liyi Zhou, Kaihua Qin, Antoine Cully, Benjamin Livshits, and Arthur Gervais. 2021. On the just-in-time discovery of profit-generating transactions in defi protocols. In 2021 IEEE Symposium on Security and Privacy (SP) . IEEE, 919–936

    2021

  37. [47]

    Vulnerabilities in DEXes and Liquidity Pools/reserves: a) Lack of Slippage Tolerance: Users may suffer unexpected losses due to significant price fluctuations during swaps or trades if the smart contracts do not have adequate slippage tolerance settings. b) Susceptibility to F...

  38. [48]

    LimboDAO: illegal asset

    Vulnerabilities in Price-Dependent Applications: a) Price Oracle Manipulation: Smart contracts that rely on external price oracles can be manipulated through tampering with the price feed, leading to incorrect asset valuations and financial loss. b) Unfair asset valuation: Poo...

    2000

  39. [2022]

    arXiv preprint arXiv:2205.10625 (2022)

    Least-to-most prompting enables complex reasoning in large language models. arXiv preprint arXiv:2205.10625 (2022)

    2022 arXiv

  40. [2024]

    In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering

    Smart Contract and DeFi Security Tools: Do They Meet the Needs of Practitioners?. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering . 1–13

Pith tools

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