E VO P O C: Automated Exploit Synthesis for DeFi Smart Contracts via Hierarchical Knowledge Graphs Ruichao Liang∗ , Jing Chen† , Xianglong Li† , Huangpeng Gu† , Yebo Feng∗ , Yue Xue‡ , Cong Wu† , Yang Liu∗ ∗ School of Computer Science and Engineering, Nanyang Technological University, Singapore † School of Cyber Science and Engineering, Wuhan University, Wuhan, China
arXiv:2605.02868v1 [cs.CR] 4 May 2026
‡ MetaTrust Labs, Singapore
Abstract—Smart contract vulnerabilities in Decentralized Finance (DeFi) caused over billions of dollars losses every year, yet the security community faces a critical bottleneck: identifying a vulnerability is not the same as proving it is exploitable. Without an executable proof-of-concept (PoC) exploit, reported findings remain theoretical, leaving auditors unable to prioritize remediation. Manual PoC construction is prohibitively laborintensive, leaving most disclosed vulnerabilities unverified and protocols exposed long before mitigation is applied. While recent LLM-based approaches show promise, naive prompting falls short of producing reliable PoCs. In this paper, we propose E VO P O C, a knowledge-driven agentic system for end-to-end contract vulnerability detection and exploit synthesis. Our core insight is that exploit synthesis is not a code generation task but a structured reasoning problem that requires grounded knowledge of protocol semantics, failure root cause, and exploit primitives. E VO P O C organizes this knowledge into a Hierarchical Knowledge Graph (HKG) that serves as structured memory for LLM-guided multi-hop reasoning, enabling the model to compose exploit strategies from reusable, semantically grounded primitives rather than unconstrained token generation. To validate exploit feasibility beyond code synthesis, E VO P O C employs a two-stage validation framework that checks exploitpath reachability via SMT solving and profit realizability via asset-level state simulation, ensuring generated PoCs satisfy both logical and economic viability constraints. Evaluated on 88 realworld DeFi attacks and 72 audited projects (2,573 contracts), E VO P O C achieves 98% recall and 0.9 F1-score in detection, and a 96.6% exploit success rate (ESR), reproducing 85 historical exploits and recovering over $116.2M revenue. E VO P O C outperforms SOTA fuzzers (V ERITE, I TY F UZZ) by up to 5× in ESR and 300× in recoverable value, and the LLM-based exploit generator A1 by 2× and 8.5× respectively. In bug bounty evaluation, E VO P O C identified 16 confirmed 0-day vulnerabilities, helping secure over $70.6M and earning $2,900 in bounties.
I. I NTRODUCTION DeFi protocols have become one of the most lucrative targets for adversarial exploitation in the history of software security, with an estimated $3.6 billion lost to smart contract flaws in 2025 alone [1]. Numerous automated techniques, including static analysis [2], [3], [4], [5], fuzzing [6], [7], and formal verification [8], [9], [10], [11], have been proposed to
Network and Distributed System Security (NDSS) Symposium 2026 23 - 27 February 2026 , San Diego, CA, USA ISBN 979-8-9919276-8-0 https://dx.doi.org/10.14722/ndss.2026.[23|24]xxxx www.ndss-symposium.org
identify potential vulnerabilities. However, in practice, these tools produce large volumes of unverified alerts, and security teams must manually assess each finding to determine whether it represents an actual vulnerability. This manual triage process is slow, expensive, and error-prone. Large language models (LLMs) offer a promising path toward automating this confirmation step. However, existing LLM-based approaches [12], [13], [14], [15], [16] focus narrowly on vulnerability detection and lack the capability for end-to-end exploit synthesis. Gervais et al. [17] take a step toward exploit generation via tool-calling, but their system relies predominantly on the LLM’s intrinsic capability, making it prone to hallucination, unstable reasoning, and limited robustness and reproducibility in complex scenarios. The fundamental problem is that exploit generation in DeFi is not a code completion task: it is a multi-step reasoning problem that requires precise knowledge of protocol semantics, economic models, and end-to-end executability. To fill the gap, we propose E VO P O C, a knowledge-driven agentic system for automated end-to-end smart contract exploit synthesis. Rather than viewing exploit generation as a direct extension of vulnerability detection or a one-shot code generation, we formulates it as a structured reasoning problem that retrieves semantic context from grounded domain knowledge, synthesizes exploit primitives through multi-hop reasoning, and verifies their logical and economic feasibility. Specifically, we make several innovations to address three core challenges: i) The semantic gap between vulnerability detection and exploit synthesis. Since LLM training knowledge is implicitly distributed across model parameters, its reasoning capability largely manifests as probabilistic navigation in high-dimensional semantic spaces [18]. In complex DeFi protocols, however, vulnerability detection and exploitation are separated by a substantial semantic distance: the former focuses on localized anomalies within contract implementations [19], [20], [12], whereas the latter requires synthesizing multi-contract interactions, protocol states, and economic constraints to construct executable attack strategies [21]. This mismatch significantly amplifies reasoning errors as the model attempts to navigate sparse semantic connections, which is a phenomenon known as probability diffusion [22]. To bridge this gap, we define an ontology schema that organizes DeFi domain knowledge into a structured, explicit representation called Hierarchical Knowledge Graph (HKG). By structuring
in DeFi: ① the semantic distance between localized flaw identification and complex PoC composition; ② LLM susceptibility to hallucination and knowledge staleness during long-horizon security reasoning; and ③ the absence of executable validity guarantees for LLM-generated PoCs in realistic execution environments. • We make three innovations to address these gaps, including ① a hierarchical knowledge graph that encoding DeFi security knowledge as structured reasoning anchors to bridge vulnerability detection and exploit synthesis; ② an evolving agentic memory mechanism to ground LLM reasoning and reduce hallucinations with up-to-date knowledge distilled from real-world audits and exploits; and ③ a two-stage feasibility validation framework combining SMT-based reachability checking with profit realizability simulation. • We build and evaluate E VO P O C, an agentic system for end-to-end vulnerability identification and exploit synthesis. Experiments show that it outperforms SOTA vulnerability scanner in detection accuracy, surpasses leading fuzzers and PoC generators in exploit effectiveness, reproduces 85 realworld exploits extracting over $116.2M, and discovers 16 0-day vulnerabilities yielding $2,900 in bug bounties.
knowledge along three dimensions: contract semantics, failure modes, and exploit primitives, the HKG provides reusable symbolic anchors that enable multi-hop reasoning and guide LLMs from vulnerability detection through root cause analysis to composition of exploit primitives. ii) Hallucination amplification in long-horizon reasoning chains. The effectiveness of LLM-based approaches [17], [12], [13], [14], [15] is often limited by hallucinations when reasoning over multi-step chains: a single fabricated primitive or misinterpreted protocol behavior compounds across subsequent steps, collapsing the entire exploit logic. The challenge intensifies as novel DeFi attack patterns continually outpace model training data. To address this, we develop an evolving agentic memory mechanism built upon the HKG, consisting of long-term memory (LTM) and working memory (WM). The system continuously updates LTM by extracting structured and reusable knowledge from the latest audit reports and exploits under the predefined HKG ontology, and dynamically instantiates task-specific working memory during contract analysis. This mechanism assists in establishing a coherent and grounded reasoning chain, significantly reducing hallucinations with up-to-date domain expertise. iii) Lack of practical exploit validity guarantees. LLMgenerated PoCs are frequently syntactically plausible but semantically invalid: they reference non-existent execution paths, fail to satisfy state prerequisites, or produce no net profit under realistic execution conditions. To address this, E VO P O C incorporates a two-stage validation framework that verifies exploit-path reachability via SMT constraint checking and profit realizability via asset-level state simulation, filtering infeasible candidates before Foundry execution and providing informative feedback for iterative refinement. E VO P O C ’s long-term memory is bootstrapped from audit reports and real-world exploit analyses across multiple sources [23], [24], [25], [26], [27] through automated knowledge extraction, and can be continuously updated. We evaluated E VO P O C on 88 real-world DeFi attack incidents and 72 audited projects comprising 2,573 contracts1 , comparing it with state-of-the-art (SOTA) tools, including LLMbased scanner GPTS CAN [12], the fuzzers I TY F UZZ [6] and V ERITE [28], and the LLM-based exploit generation tool A1 [17]. E VO P O C outperforms GPTS CAN by achieving a recall of 98% and an F1-score of 90% in vulnerability detection. Its generated PoCs successfully reproduce 85 historical real-world exploits, yielding a total profit of $116.2 million. E VO P O C attains about 5× higher exploit success than I TYF UZZ, and 2× higher than V ERITE and A1, while achieving over 300×, 2×, and 8.5× higher revenue, respectively. In addition, E VO P O C discovered 21 0-day vulnerabilities, 16 of which have been acknowledged or patched, helping secure $70.6 million and earning $2,900 in bug bounties. Contributions. This paper makes following contributions. • We demystify three root causes that make automated exploit synthesis fundamentally harder than vulnerability detection
II. BACKGROUND A. Smart Contract and Decentralized Finance Smart contracts manage digital assets on the blockchain via predefined logic [29], underpinning the DeFi ecosystem of lending, trading, and asset management [30], [31]. Logic vulnerabilities are frequently exploited, causing substantial losses [32]. Validating such vulnerabilities requires a proofof-concept (PoC) exploit, yet PoC construction demands deep DeFi expertise and compositional reasoning, making it costly and hard to scale. B. LLM-based Vulnerability Detection LLMs have been applied to vulnerability detection via fine-tuning, chain-of-thought reasoning, and integration with static analysis or symbolic execution [33], [34], [12], [13], [14]. However, these methods identify potential vulnerabilities but struggle to assess exploitability or generate valid PoCs, limiting their practical utility. III. T HREAT M ODEL Adversary model. We consider an adversary seeking financial gain by exploiting vulnerabilities in publicly deployed DeFi smart contracts. The adversary has read access to onchain bytecode, contract ABIs, historical transactions, and public disclosures, and aims to construct transaction sequences that triggers a target vulnerability and extracts unauthorized profit. This model captures the real-world attacker profile observed in historical DeFi incidents. Defender model. E VO P O C is designed as a proactive defensive security tool that enables authorized security practitioners to stay ahead of adversaries through an end-toend pipeline covering both vulnerability identification and
1 Evaluation datasets were not used in constructing the LTM of E VO P O C.
2
1 function buyTokenAndFees(address from, address to,
Structured Knowledge-guided Prompt Template
uint256 amount) internal {
2 uint256 burnAmount = amount.mul(3).div(100); 3 uint256 otherAmount = amount.mul(1).div(100); 4 uint256 feeAmount = amount.mul(10).div(100); 5 amount = amount.sub(feeAmount); 6 swapFeeTotal = swapFeeTotal.add(otherAmount); 7 super._burn(from, burnAmount); 8 super._transfer(from, to, amount);} 9 10 function distributeFee() public { 11 uint256 mokeyFeeTotal = swapFeeTotal.mul(2); 12 super._transfer(uniswapV2Pair, monkeyWallet, 13 14 15 16 17
System: You are a professional smart contract auditor ... Step 1: Review the protocol context nodes [%PROTOCOL%] and contract code [%CODE%], select only the nodes that are semantically consistent with the contract’s logic and interaction patterns. Step 2: Based on the selected protocol nodes and contract code, determine whether it exhibits vulnerabilities described in the failure mode nodes [%FAIL%]. Retain those that genuinely match and link them explicitly with the corresponding protocol nodes. Step 3: Based on the result, select exploit primitives from [%EXP%] that can trigger the vulnerability. Retain those that genuinely match and link them with the corresponding root cause nodes. Compose these primitives into a coherent high-level attack strategy. Step 4: Based on the strategy, generate a concise proof-of-concept in Solidity that demonstrates the sequence of interactions an attacker would use. Use the environment assumptions [%ENV%] during PoC generation.
mokeyFeeTotal); super._transfer(uniswapV2Pair, birdWallet, swapFeeTotal); super._transfer(uniswapV2Pair, foundationWallet, swapFeeTotal); super._transfer(uniswapV2Pair, technologyWallet, swapFeeTotal); super._transfer(uniswapV2Pair, marketingWallet, swapFeeTotal); swapFeeTotal = 0;}
Fig. 2: Structured knowledge as reasoning primitives for vulnerability detection and exploitation.
Listing 1: Fee-on-transfer token with delayed distribution causing reserve imbalance and price manipulation.
Token
FeeOn Transfer
DelayedFee Distribution
SkimSync Manipulation
AMM DEX Liquidity Pool
CoT-based-only Prompt Template
Reserves Mismatch
Manipulable AMMPrice
FlashLoan Borrow
Price Arbitrage
Fig. 3: Reasoning chains from structured knowledge nodes to guide exploit synthesis. Green, red, and blue nodes represent [%PROTOCOL%], [%FAIL%], and [%EXP%] types.
System: You are a professional smart contract auditor ... Step 1: Review the contract code [%CODE%] and and identify any logic flaws or security issues that could lead to unexpected or exploitable behavior. Report only the most confident and impactful finding. Step 2: Based on the identified issue, analyze its root cause and evaluate whether it can be exploited for financial gain or manipulation in a DEX or liquidity pool setting. If so, outline a high-level attack strategy. Step 3: Based on the strategy, generate a concise proof-of-concept in Solidity that demonstrates the sequence of interactions an attacker would use. Use the environment assumptions [%ENV%] during PoC generation.
An attacker must first locate an AMM pair, obtain capital via a flash loan, and repeatedly transfer tokens into the pair to accumulate the retained 7% fees inside, and then invoke skim to reclaim the transferred amount. Finally, the attacker triggers distributeFee to induce a sharp reserve imbalance, and distort the AMM price to arbitrage profits. Notably, although the vulnerability originates from the token’s fee-handling logic, the exploitation does not manifest locally. Instead, it unfolds within an external AMM pair through a sequence of coordinated interactions across contracts. The attack requires reasoning over fee-on-transfer semantics, AMM pricing, flash loan, and adversarial state manipulation. This separation between localized vulnerability detection and crosscontract, stateful exploitation illustrates a substantial semantic gap that is difficult to bridge through LLM reasoning alone. We further use a CoT-based prompt (Figure 1) and GPT-5 to conduct an evaluation on this example. Table I summarizes the model’s performance across successive reasoning stages. While the model consistently recognizes the presence of the price manipulation vulnerability (5/5), its performance degrades sharply when deeper causal reasoning (3/5) and exploit construction (0/5) are required, and no executable PoC is produced (0/5). This result provides concrete evidence of a substantial reasoning gap between vulnerability detection and practical exploitation.
Fig. 1: Step-wise prompt for guiding LLMs to identify and exploit the vulnerability in the motivating example.
exploit confirmation. Intended users include security auditors, bug bounty hunters, and protocol teams conducting internal reviews. In all cases, practitioners operate on contracts they are authorized to test, and exploits execute only in controlled local fork environments. IV. M OTIVATING E XAMPLE Despite the capabilities of LLMs in understanding smart contract code, a substantial gap remains between identifying potential vulnerabilities and generating practical PoCs. Here, we show how structured and reusable knowledge enables compositional reasoning in LLMs and bridge this gap. A. Detection-to-Exploitation Gap Listing 1 shows a token contract snippet from a real-world price manipulation incident. The token implements a fee-ontransfer mechanism that deducts 10% per transfer, burning 3% and redistributing the remaining 7% to designated wallets. In practice, the 7% is temporarily held in sender’s account and only released via distributeFee, creating a mismatch between the sender’s actual balance and deserved balance. While detecting this anomaly in buyTokenAndFees is straightforward for LLMs, exploiting it is more complex.
B. Structured Knowledge as Semantic Link We augment the LLM with structured domain knowledge relevant to this example. Specifically, we abstract DeFi protocol context, token–AMM interactions, typical fee-on-transfer
3
TABLE I: Evaluation of LLM reasoning progression on the motivating example. C-B (CoT-based-only) and K-G (Knowledgeguided) were each tested in 5 runs with up to 5 iterations. Result
Reasoning Stage
Iteration
Notes
C-B
K-G
C-B
Vulnerability Identification
5/5
5/5
1.8
1
Correctly recognizes the presence and category of the vulnerability.
Root Cause Analysis
3/5
5/5
4
1.4
Correctly analyze the root cause of the vulnerability.
Exploit Strategy Synthesis
0/5
5/5
5
2
Synthesizes the attack strategy spanning flash loans, token transfers, and AMM interactions.
Executable PoC Generation
0/5
4/5
5
2
Produces an executable PoC that succeeds under realistic environment.
1. Hierarchical Knowledge Graph (HKG) Construction
K-G
2. Knowledge Enhanced Reasoning Long Term Memory
Local Retrieval
Contract Semantics
Human Experts Ontology Specification
Vulnerability Intelligence (audits and exploits) Knowledge Abstraction
Knowledge Fusion
Failure Mode
Exploit Primitive
filtering
Smart Contract
3. PoC Generation & Validation Generation Stage 1 PoC Plan Generation
Working Memory Hierarchical Retrieval
Sparse-Dense Hybrid Indexing
Multi-hop Reasoning
Stage 1 Exploit-Path Reachability
Stage 2 PoC Script Generation
Stage 2 Profit Realizability
Validation
Blockchain Environment Output: Validated PoC Script
Foundry testing framework
SMT solver
Fig. 4: Overview of E VO P O C.
nodes and edges from real-world vulnerability intelligence such as audit reports and exploits, transforming unstructured text into reusable abstract knowledge. iii) Finally, knowledge from multiple sources is merged by aligning nodes, removing redundancies, and resolving conflicts, producing a unified and consistent HKG that serves as long-term memory. The second phase illustrates the knowledge-enhanced reasoning process of E VO P O C. Given a contract project, E VO P O C first filters candidate functions to exclude nonSolidity files, test code, and trusted libraries. It then builds a task-specific working memory by incrementally retrieving relevant HKG nodes to improve LLM reasoning. The process starts with local retrieval of a candidate node in the first HKG layer. Based on this node, the LLM performs multi-hop reasoning to identify additional relevant nodes, which are incorporated into the working memory to incrementally build the layer-specific subgraph. After completing reasoning within a layer, hierarchical retrieval selects candidate nodes for the next layer, and the interleaved, memory-guided retrieval–reasoning process repeats, gradually constructing a coherent reasoning subgraph that serves as the working memory for subsequent PoC generation. In the third phase, E VO P O C interleaves PoC generation and validation. Leveraging the reasoning subgraph and contract code in the working memory, the LLM first produces a high-level exploit plan, which is validated through path-level analysis to ensure reachability. Based on the validated plan, a concrete exploit script is generated and further verified through state-based analysis by tracking account-level fund flows and state transitions to confirm the intended exploit effects. Only PoCs that pass both validation stages are retained for execution
flaw root causes, and common state manipulation and arbitrage strategies into structured knowledge entries. As shown in Figure 2, these entries are exposed to the LLM as candidate reasoning primitives during inference, allowing the model to select and compose them rather than being directly guided toward the ground-truth exploit. As illustrated in Figure 3, the LLM selectively extracts relevant knowledge nodes and composes them into explicit reasoning chains. These chains operationalize structured knowledge as intermediate reasoning steps rather than implicit heuristics. As shown in Table 1, this knowledge-guided setting (K-G) consistently outperforms the baseline (C-B), achieving higher success rates across all reasoning stages while requiring fewer iterations. The result demonstrates that structured and reusable knowledge can provide semantic link that enable LLMs to perform compositional inference and supply the necessary reasoning primitives, effectively bridging the gap between vulnerability detection and exploit construction. V. M ETHODOLOGY A. Overall Workflow As shown in Figure 4, E VO P O C consists of three phases: hierarchical knowledge graph (HKG) construction, knowledgeenhanced multi-hop reasoning, as well as two-stage PoC generation and validation. In the first phase, E VO P O C constructs HKG in three steps. i) For ontology specification, ontology schema is defined to specify a three-layer structure, including node and edge types and their connection constraints, establishing an inductive schema for knowledge construction. ii) In knowledge abstraction, guided by this ontology, the LLM extracts structured
4
in an on-chain environment.
contract semantics node is linked to a failure pattern only if it contributes to the pattern’s root cause, and a failure pattern is linked to an exploit skeleton only if the pattern is necessary for the exploit. This design supports structured reasoning from high-level semantics to concrete exploit realizations. HKG construction and evolution. Based on the ontology schema, we leverage LLMs to instantiate concrete nodes and edges in the HKG. Input knowledge is collected from realworld vulnerability intelligence, including audit reports [23], [24], attack incident disclosures [25], [27], and technical analysis blogs [26]. A case is selected if it satisfies at least two of the following criteria: i) availability of the vulnerable contract source code, ii) detailed analysis of the vulnerability or attack event, and iii) explicit descriptions of exploitation steps or exploit script. The construction process consists of knowledge abstraction and knowledge fusion. In the abstraction stage, given unstructured textual intelligence for a case, we prompt LLMs with chain-of-thought instructions to extract ontology-conformant nodes and relations. The model is explicitly required to assign each extracted element a node type in S, F, or X , a relation type in E, and a concise semantic description. For contract semantics, node descriptions include the intended functionality and potential defect-prone aspects. For failure mode nodes, descriptions encode the failure pattern together with its semantic context and triggering conditions. For exploit primitive nodes, descriptions summarize the exploit behavior, the exploited failure mode, and the resulting impact. When certain ontology elements are missing from the input intelligence, the model may infer and complete them through contextual reasoning. Each case is instantiated as an individual, case-level subgraph of O. In the fusion stage, case-level subgraphs are incrementally integrated into the global HKG. For each newly generated node v ∈ V, the LLM determines whether it corresponds to an existing node by jointly considering its node type, semantic descriptions, and neighboring relations. Candidate matching proceeds in two stages: a type-filtered sparse lookup first restricts the search to nodes within the same ontology sublayer, and a Faiss ANN search [35] over node-description embeddings then retrieves the top-k semantic neighbors. This design avoids pairwise comparison across the full graph, allowing fusion cost to scale sub-linearly with graph size. Nodes judged semantically equivalent are merged with their incident edges. Nodes sharing high-level intent but differing in scope or granularity are preserved as parallel variants. Edges are merged only when both endpoints are aligned. The same abstraction and fusion procedures incorporate newly collected vulnerability intelligence, allowing the graph to evolve continuously as new cases emerge. The complete ontology schema, node type definitions, and HKG statistics are provided in Appendix B.
B. Hierarchical Knowledge Graph Hierarchical knowledge graph serves as the core representation in E VO P O C ’s memory. It abstracts concrete DeFi semantics and vulnerability intelligence into structured, reusable knowledge, which can be continuously refined through automated knowledge construction and fusion. Ontology schema. As shown in Figure 5, we model the HKG ontology as a typed directed graph O = ⟨V, E, T ⟩, where V denotes a set of nodes, E denotes a set of directed edges, and T defines node types, edge types, and their admissible connections. Nodes are organized into three semantic layers: contract semantics, failure mode, and exploit primitive, corresponding to progressively deeper stages of vulnerability understanding. i) For the contract semantics layer, we define S = {Prot, Acc, Eco, Dep} as the set of node types, corresponding to protocol, access control, economic model, and dependency, respectively. Protocol node p ∈ Prot serves as a semantic anchor, connected to other semantic nodes via typed relations: enforces : Prot → Acc, adopts : Prot → Eco, depends on : Prot → Dep.
(1)
To support fine-grained abstraction, each semantic node c ∈ C is internally structured as c = ⟨cp , cs , l⟩, where cp ∈ PrimaryCategory, cs ∈ SubCategory, and l ∈ ImplementLogic. The hierarchical relations explicitly encode this decomposition: subsume : PrimaryCategory → SubCategory, implements : SubCategory → ImplementLogic
(2)
ii) For the failure mode layer, we define F = {FP , Cond , Imp, RC , Inv } as the set of node types, corresponding to failure pattern, condition, impact, root cause, and invariant violation, respectively. Each failure pattern f p ∈ FP is connected by typed relations: caused by : FP → RC , needs : FP → Cond , can cause : FP → Imp.
(3)
Root cause rc ∈ RC is connected to an invariant violation by: leads to : RC → Inv .
(4)
iii) For the exploit primitive layer, let X = {Skel , Prim, Ex } denote the set of node types in the exploit primitive layer. Each exploit skeleton sk ∈ Skel is connected to a sequence of exploit primitives: ⟨p0 , p1 , . . . , pn ⟩, where pi ∈ Prim, via typed relations: start at : Skel → Prim,
next : Prim → Prim.
(5)
Exploit primitive p ∈ Prim is assigned a semantic role from: { Setup, EnvironmentManipulation, ExploitationAndAmplification, ArbitrageAndExit }.
(6)
Each skeleton is further linked to few-shot examples by: illustrated by : Skel → Ex .
C. Memory-Enhanced Multi-hop Reasoning (7)
The HKG constitutes the long-term memory (LTM) of E VO P O C. It is maintained as a graph that encodes ontologyconformant nodes and their relations, with node descriptions
Cross-layer edges are introduced selectively to encode causal relevance rather than exhaustive linkage. Specifically, a
5
Contract Semantics
Failure Mode
prone_to
Protocol enforces
depends_on
Dependency
needs
Failure Pattern adopts
Access Control
subsume
Subcategory
Environment Manipulation
can_cause
Root Cause
Implement Logic
Setup next
caused_by
Economic Model
implements
start_at
Skeleton
Condition
next
Impact
Few-shot Examples
leads_to
Primary Category
Exploit Primitive
exploited_by
Exploitation and Amplification next
Invariant Violation
Aarbitrage and Exit
Fig. 5: Overview of the hierarchical knowledge graph (HKG) ontology schema. Local Contract Retrieval Summary
hop-2 reasoning
hop-n reasoning
Hierarchical Retrieval
hop-2 reasoning
hop-n reasoning
hop-1 reasoning
hop-1 reasoning Dense Indexing
Vector Database
hop-2 reasoning Dense Indexing
hop-n reasoning
hop-1 reasoning
Or
Or
HKG Layer 1
Sparse Indexing
Sparse Indexing
- Which ones describe the protocol adopted by the contract? Multi-hop - Which candidates match the contract’s economic model? Reasoning - Which candidates best match ....
HKG Layer 2
- Which ones explain the root cause of this failure? - Which invariants are violated by these root causes? - Which candidates best match ....
HKG Layer 3
- Which ones are applicable in the contract’s execution context? - Which candidates can manipulate this vulnerable state? - Which candidates best match ....
Fig. 6: Multi-hop reasoning workflow based on agentic memory, where retrieved knowledge from the HKG (LTM) is organized into a task-specific subgraph as E VO P O C’s working memory (WM).
indexed by vector embeddings. Given a target contract, relevant knowledge is selectively retrieved from the LTM and instantiated into the working memory (WM), enabling the LLM to perform agentic multi-hop reasoning. This process produces a case-specific, holistic understanding of the contract, including its semantics, relevant failure modes, and corresponding exploit strategies.
when transitioning from the failure mode layer to the exploit primitive layer. Within each layer, reasoning follows a breadth-first strategy. At each step, candidate nodes are evaluated against layerspecific criteria. In the contract semantics layer, the LLM assesses whether the contract adopts the protocol type, economic model, or access control pattern represented by a candidate node. In the failure mode layer, it evaluates whether the contract behavior aligns with the vulnerability pattern captured by the candidate. In the exploit primitive layer, it selects exploitation strategies that are consistent with the identified failure modes. Reasoning within a layer terminates when no candidate nodes remain consistent with the contract context or when further expansion is deemed uninformative.
As shown in Figure 6, reasoning is initiated by generating a semantic summary of the target contract. In the contract semantics layer, similarity-based retrieval identifies the most relevant protocol-level primary category nodes, which serve as initial reasoning seeds. Starting from these seeds, the LLM incrementally expands a protocol-level subgraph via multi-hop traversal of graph relations, guided by the contract context. At each hop, one-hop neighboring nodes are retrieved as candidates and evaluated under CoT reasoning to determine their relevance. This iterative expansion completes local retrieval within the layer. Cross-layer transitions are realized through hierarchical retrieval using a sparse-dense hybrid strategy. To move from the contract semantics layer to the failure mode layer, sparse retrieval first checks whether multiple selected semantic nodes converge on the same failure pattern through existing cross-layer links. If a candidate exceeds a predefined confidence threshold, it is selected as the next reasoning seed. When sparse retrieval yields no candidate, dense retrieval is applied by performing similarity search over failure pattern nodes using semantic embeddings, from which the LLM selects the most plausible node conditioned on the contract context. The same retrieval-and-selection procedure is applied
D. Exploit Synthesis with Feasibility Checking As shown in Algorithm 1, this process is formalized as an iterative search for a valid exploit sequence P satisfying reachability and profitability constraints, instantiated into a feasible exploit script. Two-stage generation. The two stages refer to: (1) PoC plan generation, which produces a high-level, human-readable attack strategy specifying the sequence of protocol interactions, asset flows, and exploitation steps; and (2) PoC script generation, which instantiates the validated plan into a concrete, executable Solidity test script instrumented for Foundry. Rather than relying on rigid templates, synthesis utilizes exploit primitives grounded in E VO P O C’s working memory and the LLM’s generative capabilities. It begins with an exploit plan P = {t1 , t2 , . . . , tn }, organizing the attack
6
σ and confirms reachability; UNSAT certifies that the path cannot be executed under any input and the candidate is pruned. The check focuses on logic within the target protocol’s own contracts, where exploit-relevant predicates concentrate; behaviors of unrelated external contracts encountered along π are assigned conservative defaults that may admit additional candidates but never spuriously reject feasible ones. Within these bounds, an UNSAT verdict from Z3 reliably eliminates infeasible paths once (π, Φ) is extracted. The profitability stage filters candidates that are reachable but cannot yield positive net wealth. We maintain an abstract asset state S = ⟨B, Ω⟩, where B tracks token balances of the attacker and relevant contracts, and Ω captures price-relevant state from AMM reserves or external oracles. The LLM simulates script execution at the asset layer only: recording balance and price transitions while abstracting control flow under idealized conditions such as zero slippage and successful branch completion. A candidate proceeds to Foundry if
Algorithm 1: Executable exploit synthesis with feasibility Input: Working memory WM, execution environment E Output: Exploit script: script or Failure 1 Procedure E XPLOIT S YNTHESIS (WM, E ): 2 P ← G ENERATE E XPLOIT P LAN (WM); 3 reachable ← C HECK PATH R EACHABILITY (P, E ); 4 if reachable = true then 5 script ← G ENERATE E XPLOIT S CRIPT (P, E ); 6 if VALIDATE P ROFITABILITY (script, E ) = true then 7 D EPLOY T O F OUNDRY (script); /* Forward for execution */ 8 9
else return Failure else return Failure
/* Not profitable */; /* Path infeasible */ ;
Procedure C HECK PATH R EACHABILITY (P, E ): foreach t = ⟨C, f, σ, K⟩ ∈ P do 12 π ← S EMANTIC T RAVERSAL (C, f, K); 13 Φ ← C OLLECT P REDICATES V (π); 14 if not SMTS ATISFIABLE ( Φ) then 15 return false /* Unreachable sink */
10
11
16
return true
Procedure VALIDATE P ROFITABILITY (script, E ): 18 Initialize S = ⟨Binit , Ωinit ⟩; 19 S IMULATE E XECUTION (script, S); /* Over-approximate asset transitions */ 20 ∆W ← Val(Bf inal , Ωf inal ) − Val(Binit , Ωinit ); 21 if ∆W > 0 then 22 return true
17
23
∆W = Val(Bf inal , Ωf inal ) − Val(Binit , Ωinit ) > 0.
(8)
The filter is optimistic: idealized assumptions favor the exploitation, so the gate admits any candidate profitable under at least one plausible execution and rejects only those with no path to a positive ∆W . A walk-through of both validation stages on a flash-loan governance exploit candidate is provided in Appendix ??.
else return false ;
into three phases: preparation (environment setup and asset acquisition), exploitation (triggering the vulnerability), and extraction (profit realization). Each transaction ti is represented as ⟨C, f, σ, K⟩, where C is the target contract, f the entrance function, σ the parameters (concrete or symbolic), and K the primary target operation (state modification, external call, or fund transfer). Once validated, the LLM integrates the plan with the execution environment E (ABIs, contract addresses, block heights) to synthesize a Foundry-based [36] PoC script instrumented with diagnostic oracles for verifiable proof of exploit success. Reachability and profitability validation. This stage combines LLM-guided semantic reasoning with formal constraint solving to prune infeasible PoC candidates before Foundry execution. We avoid heavyweight symbolic verification: the goal is cheap pruning that produces actionable failure signals for iterative refinement, since pure Foundry failures offer little insight into why a candidate fails. The two stages target the two dimensions exploits must satisfy: logical reachability and economic viability. In the reachability validation, for each transaction t = ⟨C, f, σ, K⟩ ∈ P, we evaluate whether K is logically reachable from f at the inter-procedural constraint level. S EMANTIC T RAVERSAL performs LLM-guided traversal of C, expanding callees, tracking how symbolic parameters σ propagate across scopes and contract boundaries, and emitting an ordered call sequence π = ⟨f0 , . . . , fk ⟩ with associated data-flow edges. C OLLECT P REDICATES then walks π and encodes each require/assert/branch condition as a Z3 formula ϕi , treating attacker-controlled inputs and relevant V protocol state as symbolic. A satisfying assignment for Φ concretizes
VI. I MPLEMENTATION The system is implemented in Python with approximately 12K lines of code, using LangChain [37] to orchestrate multistep LLM interactions and state management. Contract preprocessing is implemented using ANTLR [38] to extract structural metadata (functions, visibility, and state variables) and generate abstract syntax trees (ASTs). For multi-file projects, we use a lightweight call-graph–based pruning to identify core logic contracts, reducing token overhead and improving analysis stability. Knowledge storage and indexing. The hierarchical knowledge graph is implemented through a dual-storage architecture. We use Neo4j [39] as the graph database to store the graph topology for efficient traversal and reasoning across connected nodes. Complementary to the graph, node descriptions are indexed in Faiss [35], which serves as the RAG vector store to enable similarity-based retrieval for both initial reasoning seeds and cross-layer node discovery. Verification engine. The reachability check requires translating Solidity-level predicates into a form consumable by Z3. We implement a normalization layer that flattens mapping accesses, resolves type casts, rewrites Solidity-specific arithmetic into Z3-compatible expressions, and applies conservative defaults for undeclared external returns. Predicate extraction uses a structured prompt that asks the LLM to emit each branch condition in a fixed form, which the layer then parses and assembles into the SMT query. The profitability check is realized as an LLM-driven simulator that maintains
7
TABLE II: Performance of E VO P O C in detecting vulnerabilities within dataset D1. Dataset
D1
We evaluate E VO P O C on datasets D1 and D2 under different LLMs as the base model. D1 consists of audited projects and is used to evaluate E VO P O C’s effectiveness in vulnerability identification. D2 contains historical Defi attack incidents with confirmed profits as ground truth and is used to assess whether the PoCs generated by E VO P O C can reproduce the exploits and yield profits. Vulnerability detection performance (D1). Table II summarizes the vulnerability detection performance of E VO P O C on D1. TP and FN denote the numbers of detected and missed vulnerabilities among the 48 kinds of vulnerabilities in D1. FP denotes the false alarms during E VO P O C’s analysis, and TN denotes benign projects correctly identified as non-vulnerable. Overall, E VO P O C demonstrates strong detection capability across all base models, achieving high recall (up to 0.98) and F1-scores between 0.83 and 0.90. Notably, with GPT-5 as the base model, E VO P O C detects 47 out of 48 vulnerability types while maintaining a moderate false positive rate. This high recall stems from the HKG’s contract semantics layer, which encodes protocol-level behavioral patterns that pure static analysis typically misses. Rather than relying on predefined syntactic rules, E VO P O C retrieves semantically relevant protocol and dependency nodes and performs multi-hop reasoning to connect localized code anomalies to broader vulnerability contexts, enabling detection of complex logic flaws that manifest only through cross-contract or cross-function interactions. The moderate false positive rate reflects two failure modes. First, E VO P O C occasionally misinterprets intentionally permissive access-control designs as vulnerabilities, as the underlying developer intent is not always recoverable from code alone. Second, some potential vulnerabilities are not practically exploitable, such as reentrancy where existing guards or rollback mechanisms prevent actual exploit. Real-world exploitation performance (D2). Table III presents the exploitation results and revenue achieved by E VO P O C on dataset D2, which consists of real-world attack incidents spanning from 2022 to December 2025. Overall, the PoCs generated by E VO P O C successfully reproduced 85 out of 88 historical exploits, yielding an exploit success rate (ESR) of 96.6% and a total reproduced revenue of $116,225.3K. The largest reproduced profit is observed on uwerx, reaching $63,797.5K, which exceeds the profit obtained by the realworld attacker in the original incident. The iteration refers to the repetitive generation process triggered when the initial PoC fails our two-step verification, and a task is marked as a failure if it exceeds a maximum of 5 iterations. The strong ESR reflects several complementary design choices. HKG provides semantic context, links vulnerable logic to root causes, and offers high-level exploit guidance, enabling E VO P O C to compose structured PoCs grounded in real-world precedents rather than generating exploit code from scratch. The two-stage validation further filters structurally infeasible and economically non-viable candidates before Foundry execution, focusing refinement on plausible PoCs and providing
Result
Model GPT-5 GPT-4o GPT-o3 GPT-3.5
B. RQ1: Effectiveness in Real-world Scenarios
TP
FN
FP
TN
Precision
Accuracy
Recall
F1-score
47 44 47 45
1 4 1 3
10 13 12 15
29 25 25 27
0.82 0.77 0.80 0.75
0.87 0.80 0.85 0.80
0.98 0.92 0.98 0.94
0.90 0.84 0.88 0.83
the abstract state S across simulated calls, with placeholderaware handling of unresolved external values and standardized asset-accounting templates to keep ∆W comparable across heterogeneous protocols. VII. E VALUATION A. Evaluation Setups Datasets. D1 is built from 72 Code4rena-audited projects in the Web3Bugs dataset collected by Sun et al. [12], comprising 2,573 smart contracts. It includes 41 projects with 48 verified vulnerability types and 31 vulnerability-free projects. Dataset D2 contains 88 real-world attack cases collected from DeFiHackLabs [40], covering those used in V ERITE and A1. Dataset D3 consists of contract bounty projects from the Secure3 [41] platform. Research questions. Based on the above datasets, we aim to answer these research questions: RQ1: How effective is E VO P O C in identifying and exploiting real-world vulnerabilities, and how efficient is it in terms of runtime performance and token consumption? • RQ2: How does E VO P O C perform compared to state-ofthe-art approaches including fuzzers as well as the LLMbased scanner and exploit generator? • RQ3: How does hierarchical knowledge and the validation module affect E VO P O C’s performance? • RQ4: Can E VO P O C detect previously unknown (0-day) vulnerabilities in real-world projects? •
Baselines. To ensure a comprehensive evaluation, we compare E VO P O C with four representative tools across different technical paradigms. For vulnerability identification, we use GPTS CAN [12], which represents the current SOTA LLMbased vulnerability scanner as our baseline. For vulnerability exploitation, we select I TY F UZZ [6], V ERITE [28], and A1 [17]. I TY F UZZ and V ERITE are SOTA fuzzers capable of triggering profitable vulnerabilities, while A1 is an LLMbased PoC generator. LLM selection. We employ five widely used LLMs as the backbone models of E VO P O C, namely GPT-5.2, GPT-5, GPT-4o, GPT-o3, and GPT-3.5-turbo. These models cover a broad parameter range from tens of billions to several trillion parameters and include both general-purpose and inferenceoptimized variants, enabling a comprehensive evaluation of E VO P O C across different model capacities. For all models, we use their publicly available API endpoints with a temperature of 0.2 to ensure deterministic behavior across runs.
8
TABLE III: Exploitation performance and revenue of E VO P O C on Dataset D2. ESR denotes the Exploit Success Rate. Asterisks (*) denote projects where PoC failed to achieve exploitation. ID
Name
Max Revenue
Avg Iter
Avg Token
ID
Name
Max Revenue
Avg Iter
Avg Token
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
aes apemaga axioma bamboo bego bevo bunn cellframe dfs fapen fil314 game gss health hpay mbc melo olife pledge pltd rfb seama shadowfi sut swapos uerii upswing uranium uwerx wifcoin
$61.6K $57.4K $18.9K $205.2K $10.9K $130.7K $47.2K $222.8K $1.5K $10.9K $12.8K $99.0K $24.9K $15.1K $103.9K $5.9K $250.4K $29.3K $15.0K $244.5K $5.6K $7.8K $978.9K $29.6K $9.5K $5.9K $1.0K $8,772.6K $63,797.5K $10.8K
1.3 2.3 2.0 1.5 1.5 1.8 3.5 3.8 3.5 1.5 4.0 2.0 3.8 2.3 3.3 4.0 1.0 3.5 1.5 1.0 2.0 2.0 1.0 1.5 1.8 1.0 3.8 3.0 1.5 2.3
148.9K 61.0K 69.5K 148.5K 156.2K 158.7K 130.7K 49.8K 115.1K 45.9K 74.2K 58.1K 248.9K 131.5K 52.0K 144.1K 58.5K 116.4K 198.0K 102.5K 102.1K 149.5K 150.6K 56.4K 68.3K 80.1K 59.2K 69.9K 102.1K 141.0K
31 32 33 34 35 36 34 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
zeed bno curve01 cover newfi utopia wgpt myai ddcoin cfc babydoge bzx mamo hypr compound ffist laeeb juice smartmesh spankchain yearn ydai spartan bearn hunny popsicle nimbus ploutoz* yeth drlvaultv3 bancor
$124.5K $0.0K $2,504.5K $1,274.4K $30.5K $446.6K $76.9K $9.8K $126.4K $19.1K $401.1K $9,486.7K $5.3K $1.4K $45.1K $207.2K $43.2K $98.3K $0.5K $506.0K $185.1K $1,529.4K $123.1K $5.2K $2.2K $4.6K $0.0K $1,077.0K $13,980.8K $0.2K
4.0 3.3 1.8 1.0 3.0 2.3 4.5 2.5 3.8 3.8 4.3 2.8 3.5 3.5 4.5 1.3 1.5 2.3 2.5 2.8 4.8 1.8 4.0 4.0 4.8 3.5 5.0 4.5 3.5 2.0
106.0K 132.0K 136.4K 81.3K 143.1K 105.7K 95.0K 65.4K 80.3K 116.8K 170.7K 94.5K 99.7K 65.0K 330.7K 107.5K 176.2K 59.6K 66.8K 146.1K 58.8K 57.9K 78.7K 546.8K 404.0K 92.1K 57.5K 183.9K 127.2K 187.2K
Total
Exploted: 85/88
ESR:96.6%
ID
Name
Max Revenue
Avg Iter
Avg Token
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88
opyn allbridge annex apedao bigfi cs depusdt discover* dpc gds gym 1 hackdao inuko lusd lw neverfall omniestate res roi safemoon* sdao selltoken sheep sheepfarm starlink tinu ufdao valuedefi
$9.9K $5.5K $6.6K $7.5K $30.3K $684.2K $106.1K $0.0K $10.8K $207.2K $1,246.6K $148.5K $5,019.5K $9.5K $83.5K $74.3K $0.1K $184.4K $152.5K $0.0K $13.7K $10.9K $20.0K $0.1K $34.8K $70.0K $227.1K $359.6K
2.3 1.8 3.5 1.3 2.5 2.0 1.8 5.0 3.0 4.0 2.0 2.3 2.3 1.8 4.0 3.0 1.0 2.5 2.0 5.0 1.3 2.8 2.3 3.0 1.3 2.3 3.3 1.3
293.6K 380.6K 182.8K 132.3K 164.1K 168.3K 72.1K 122.1K 223.0K 154.9K 61.9K 112.0K 135.6K 69.1K 137.0K 177.1K 131.3K 152.6K 198.5K 112.1K 106.9K 74.1K 162.3K 101.4K 169.0K 243.8K 67.1K 100.6K
Revenue: $116,225.3K
TABLE IV: Exploitation performance of E VO P O C on Dataset D2 across different underlying LLMs. Dataset
D2
Result
Model
GPT-5.2 GPT-5 GPT-o3 GPT-4o
Det.
Rec.
Exp.
ESR
Avg. Iteration
Avg. Time
Avg. Token
Total Revenue
82 82 85 77
93.2% 93.2% 96.6% 87.5%
76 69 79 70
86.4% 78.4% 89.8% 79.5%
2.84 2.32 2.49 2.86
296.50 119.48 178.94 100.69
151,278 114,889 142,827 119,502
$110,960,607.9 $107,626,754.2 $86,384,234.5 $94,936,898.2
Det., Exp., and Rec. denote the number of detected vulnerabilities, exploited vulnerabilities, and recall rate, respectively.
informative feedback for iterative repair. We also analyze the three failed exploit cases. In the project discover, E VO P O C triggers the unfair exchange rate but fails to construct a profit-realizing multi-contract exploit due to ambiguity between price-manipulation logic and arithmetic errors. In project ploutoz, the vulnerability lies in low-level mint/burn arithmetic corner cases unrelated to function semantics, causing E VO P O C to miss the relevant execution path. In project safemoon, publicly exposed mint and burn interfaces in a proxy contract are vulnerable, but E VO P O C focuses on proxy risks, leading to an incorrect contract-type abstraction and missed trigger. Cross-LLM effectiveness and efficiency analysis. We break down E VO P O C’s performance on D2 across LLMs and summarize it in Table IV and visualized in Figures 7 and 8. i) For exploitation effectiveness, the results show that E VO P O C is effective and robust across all evaluated LLMs. All models achieve an ESR above 78% and identify more than $86M in total revenue, indicating that the framework
consistently bridges the gap between raw LLM reasoning and practical exploit generation. Among the models, GPTo3 achieves the highest ESR (89.8%), benefiting from its reasoning-oriented architecture which exhibits stronger capability in HKG knowledge retrieval. GPT-5.2 performs best in high-impact cases, reaching the highest total Revenue of $110M, which can be attributed to its stronger state modeling and strategy optimization ability. ii) For efficiency and resource overhead, GPT-4o is the most time-efficient among all models, requiring only 100.69s per task on average. GPT-5 is the most resource-economical, utilizing the lowest iterations (2.32) and tokens (114,889). In contrast, GPT-5.2 incurs the heaviest overhead, with the longest time cost (296.50s) and highest token consumption (151,278). This trade-off indicates that stronger models improve the ability to exploit more vulnerabilities with more profits but require more extensive reasoning, leading to higher runtime and token consumption. iii) For distributional characteristics, in Figure 8 (a) and (b),
9
3 0 0
1 5
2 0 0
1 0
2 5 0
4 0
T o k e n
T im e (s )
E x p lo ite d
6 0
1 5 0 1 0 0
2 0
5 0
0
0
M o d e l
M o d e l
1 2 0
G P T - 5 .2
× 1 0 6
5
1 0 0
5 0
(b ) A v e ra g e T im e C o s t
(a ) E x p lo ite d P ro je c t
G P T -o 3
3
6 0 2 0
1
2
4 0 0
M o d e l
4
8 0
Ite ra tio n
8 0
G P T -4 o
× 1 0 4
R e v e n u e ($ U S D )
G P T -5
3 5 0
(c ) A v e ra g e T o k e n C o s t
0
M o d e l
M o d e l
(e ) A v e ra g e Ite ra tio n
(d ) T o ta l R e v e n u e
Fig. 7: Performance metrics of E VO P O C across various LLM backends. 6 0
5 0 0
6 0
R e v e n u e ($ U S D )
T im e (s )
T o k e n -5 -4 o P T -o 3 P T -5 . G P T G P T G G (a ) T im e D is trib u tio n
2
4 3
3 0
2 0 1 0 0
5
4 0
3 0
2 0 0
× 1 0 6
5 0
4 0
3 0 0 0
7 0
5 0
4 0 0 1 0 0
× 1 0 4
Ite ra tio n
6 0 0
2
2 0
-5 -4 o P T -o 3 P T -5 . G P T G P T G G
2
(b ) T o k e n D is trib u tio n
1 0 0
-5 -4 o P T -o 3 P T -5 . G P T G P T G G
2
1
(c ) R e v e n u e D is trib u tio n
-5 -4 o P T -o 3 P T -5 . G P T G P T G G
2
(d ) Ite ra tio n D is trib u tio n
Fig. 8: Distribution analysis of performance indicators for each model. TABLE V: Comparison of vulnerability detection performance between E VO P O C and GPTS CAN on D1. Dataset
Tool
TABLE VI: Exploitation performance comparison between E VO P O C and SOTA fuzzers and PoC generator on D2.
Result
Model
Dataset
Tool
Precision Accuracy Recall F1-score D1
GPTS CAN GPT-3.5 E VO P O C (Ours) GPT-3.5
57.1% 75.0%
62.4% 80.0%
83.3% 93.8%
Result
Model
Exploited ESR Total Revenue Average Revenue I TY F UZZ D2 (s1) V ERITE E VO P O C
67.8% 83.3%
D2 (s2)
models exhibit a long-tail distribution, reflecting its extensive reasoning process when handling highly complex projects. In Figure 8 (c), all models follow a power-law distribution where a small number of incidents account for the majority of total revenue, reflecting the reality of DeFi security incidents. GPT-5 and GPT-o3 show tighter distributions in Figure 8 (d), with most PoCs generated within 1–2 iterations, demonstrating higher determinism compared to the wider distributions of GPT-4o and GPT-5.2.
N\A
10 25 50
19.2% 48.1% 96.2%
$106,473.8 $18,225,320.8 $35,308,169.5
$10,647.4 $729,012.8 $706,163.4
A1 GPT-o3 E VO P O C GPT-o3
15 29
48.4% 93.5%
$8,839,461.0 $75,018,779.7
$589,297.4 $2,586,854.5
substantially mitigate LLM hallucinations, resulting in fewer false positives and more dependable detection. Comparison with exploitation generator. Our dataset D2 encapsulates the benchmarks used by compared tools. Specifically, we derived D2 (s1) by incorporating all incidents from I TY F UZZ and V ERITE, retaining 52 cases after excluding those where source code is no longer available. Similarly, D2 (s2) includes the incidents from the A1 benchmark, with 31 cases remaining. As shown in Table VI, E VO P O C achieves an ESR of 96.2% and 93.5% on D2 (s1) and D2 (s2), nearly 2× of V ERITE’s 48.1% and A1’s 48.4%, and 5× of I TY F UZZ. E VO P O C also demonstrates a massive lead in profitability. Compared to its LLM-based counterpart A1, it achieves 8.5× the total revenue and 4.4× the average revenue. V ERITE achieves a slightly higher average revenue by employing a profit maximizer. In contrast, E VO P O C generates PoCs through knowledge-driven logic reasoning without specific optimization for profit maximization.
Answer to RQ1: E VO P O C is highly effective, achieving a 0.98 recall and 0.90 F1-score in detection, and a 96.6% exploit success rate with $116.2M revenue. It also maintains consistent performance across various LLM backends with moderate overhead in terms of runtime and token consumption.
C. RQ2: Comparison with SOTA Approaches Comparison with vulnerabiliy scanner. Table V reports the performance of E VO P O C and GPTS CAN on the D1 dataset. GPTS CAN achieves a high recall of 0.83 but suffers from relatively low precision (0.57), indicating a considerable number of false positives. Specifically, it detects 40 out of 48 vulnerability types while missing 8 cases and producing 30 false positives. In contrast, E VO P O C consistently outperforms GPTS CAN across all evaluation metrics, achieving higher precision (0.75), accuracy (0.80), recall (0.94), and F1-score (0.83). These results demonstrate that E VO P O C leverages its memory mechanism and knowledge-based reasoning chains to
Answer to RQ2: E VO P O C significantly outperforms SOTA baselines, surpassing GPTS CAN with an 0.83 F1-score, 2× the exploit success rate of V ERITE and A1, and 8.5× the total revenue of A1, proving its superior effectiveness in both vulnerability detection and high-profit exploit generation.
10
TABLE VII: Ablation study results. CS, FM, and EP denote Contract Semantics, Failure Mode, and Exploit Primitive. Num denotes the successful exploits, and Degr denotes the degradation over baseline. Tool
E VO P O C-SF E VO P O C-EP E VO P O C-NO E VO P O C
Knowledge
Model
GPT-5 GPT-5 GPT-5 GPT-5
Detected
Exploited
Result Total Revenue
Average Revenue
CS
FM
EP
Num
Degr
Num
Degr
Num
Degr
Num
Degr
× ✓ × ✓
× ✓ × ✓
✓ × × ✓
17 80 16 82
-79% -2% -80% N/A
11 1 0 69
-84% -99% -100% N/A
$2,465,360 $931,177 0 $107,626,754
-98% -99% -100% N/A
$224,123 $931,177 0 $1,559,808
-86% -40% -100% N/A
TABLE VIII: Ablation of the reachability-profitability validation module on D2 with GPT-5.
D. RQ3: Ablation Study We conduct ablation studies to assess the contribution of E VO P O C’s knowledge layers and validation module to vulnerability detection, exploit generation, and refinement efficiency. HKG ablation. We construct three variants by selectively removing HKG layers: E VO P O C-SF removes the contract semantics and failure mode layers, E VO P O C-EP removes the exploit primitive layer, and E VO P O C-NO removes all layers. As shown in Table VII, all layers are necessary for endto-end exploit synthesis. Removing the semantic and failure mode layers (E VO P O C-SF) reduces detection by 79% and total revenue by 98%. This suggests that exploit primitives alone are insufficient: without semantic context and failure-mode guidance, the model struggles to identify protocol-specific vulnerable logic and thus misses most exploitable cases. In contrast, removing the exploit primitive layer (E VO P O CEP) retains 80 detected vulnerabilities but reduces successful exploits by 99%. This indicates that semantic and failure-mode knowledge mainly support vulnerability discovery, whereas exploit primitives are critical for transforming detected flaws into executable PoCs. Removing all layers (E VO P O C-NO) leads to zero successful exploits, further confirming that the three layers jointly bridge code understanding, vulnerability reasoning, and exploit construction. Validation ablation. Table VIII evaluates the reachabilityprofitability validation module from two aspects. Panel (a) shows that two-stage validation reduces average Foundry iterations from 13.8 to 2.3 and runtime from 309s to 117s, despite introducing 4.3 lightweight internal iterations. This suggests that the dominant cost in refinement comes from coarse execution-level feedback. In direct-to-Foundry refinement, a failed PoC only reveals that the complete script does not work, but does not isolate whether the failure comes from an infeasible path, wrong parameters, incorrect transaction ordering, or non-profitable asset movement. The model therefore tends to revise the script by trial and error, often remaining in the same invalid search region. Two-stage validation changes this process by moving part of the refinement to the plan level. Reachability and profitability checks expose failures before script execution and provide more localized correction signals. Thus, the additional internal iterations are cheaper and more informative, replacing many expensive trial-error attempts. Panel (b) shows that validation removes all 8 false positives while preserving all 22 true positives. This is because LLMgenerated false positives are often not arbitrary mistakes, but
(a) Efficiency vs. direct Foundry Setting Direct-to-Foundry Two-stage
Int.Iter
Fdry.Iter
Time
0 4.3
13.8 2.3
309s 117s
(b) Filtering quality Setting No validation Two-stage
Passed
TP
FP
FN
Prec.
30 22
22 22
8 0
– 0
73% 100%
partial exploits that are semantically plausible yet violate necessary exploit conditions. For example, a candidate may match a known vulnerability pattern but fail to reach the target operation, or it may reach relevant logic without yielding positive net wealth. By enforcing path feasibility and economic gain before Foundry execution, the validation module filters these structurally invalid candidates early. Therefore, it improves precision by reducing the number of plausible-butinvalid PoCs entering the execution loop, rather than by simply duplicating Foundry’s role. Answer to RQ3: Each HKG layer is indispensable: semantic layers drive vulnerability detection while exploit primitives enable successful PoC generation. The two-stage validation module further improves synthesis by moving refinement from expensive Foundry-level trial-and-error to more diagnostic reachability-profitability checks.
E. RQ4: Discovery of 0-day Vulnerabilities We apply E VO P O C to the open bug bounty program of Secure3 [41], aiming to evaluate whether E VO P O C, equipped with specialized domain knowledge, can identify previously undiscovered 0-day vulnerabilities and validate them through proofs of concept like experienced human experts. Overall results. E VO P O C identified a total of 21 0-day vulnerabilities across five projects. To date, 16 of these vulnerabilities were either confirmed or fixed by the developers, resulting in a total bounty reward of $2,900. As shown in Table IX, these 16 vulnerabilities include 2 high-severity, 11 mediumseverity, and 3 low-severity issues. The detected vulnerabilities span various categories, such as accounting errors, unprotected initialization, and reentrancy. Notably, all high-severity and the majority of medium-severity vulnerabilities have been remediated by the developers, securing approximately $70.6M in on-chain assets.
11
TABLE IX: 0-day vulnerabilities found by E VO P O C ID
Location
Description
Risk
Status
Project
TVL
1 2
calculateReward() emergencyWithdraw()
Precision loss from integer truncation causing zero rewards. Missing blacklist check allows sanction bypass.
M M
Fixed Fixed
cudis bsc
$839K
3 4 5
removeSourceToken() deposit() withdraw()
Reflexive token check causes DoS. Ignored transfer fees cause over-minting. Transfer-tax tokens break accounting, causing inflated balance.
M M M
Fixed Fixed Fixed
zklink MergeToken
$37.6M
6 7 8 9 10 11
openEnvelope() openEnvlope() addEnvelope() moneyThisOpen() openEnvlope() addEnvelope()
Missing signature verification enables replay and fund theft. Reentrancy with ERC777 tokens allows repeated withdrawals. Missing ID existence check allows overwrite and fund theft. Bad randomness enables MEV manipulation. Reentrancy allows repeated unauthorized withdrawals. Front-running ID registration causes user DoS.
H H M M M L
Fixed Fixed Fixed Fixed Fixed ACK
Aki Protocol
$128K
12 13
unwhitelistTarget() getTarget()
Incorrect mapping update prevents proper whitelist removal. Calldata decoding flaw bypasses whitelist checks.
M L
ACK ACK
Klydo
Unk.
14 15 16
init insurance() transfer() init config()
Missing init guard allows state overwrite and manipulation. Fee precision loss enables fee evasion via dust attacks. Unprotected initialization allows admin takeover.
M M L
ACK ACK ACK
Cooking City
$32M
TABLE X: Key nodes retrieved from HKG during E VO P O C’s analysis of the fee-on-transfer token incompatibility vulnerability. Contract Semantics | | +– Protocol | +– TokenWrapping | +– Portal | +– DepositMint | | +– Economic Model | +– AssetBacking | +– DeterministicMinting | +– BalanceDeltaBased | | +– Dependency | +– ERC20Token | +– NonStandardERC20 | +– FeeOnTransfer
Failure Mode | | +– Failure Pattern | +– ERC20Incompatibility | +– AccountingMismatch | | +– Root Cause | +– FullTransferAssumption | | +– Invariant Violation | +– CollateralConsistency | +– Redeemability | | +– Impact | +– OverMinting | +– DoS
Case study: over-minting vulnerability causing portal insolvency. We analyze a 0-day vulnerability in the MergeTokenPortal.sol contract from the zkLink MergeToken project. As shown in Listing 2, the contract functions as a portal, enabling asset conversion through a deposit–withdraw mechanism. Users deposit a source token to receive a synthetic token, and can later burn the synthetic token to redeem the underlying asset. However, this design is incompatible with fee-on-transfer tokens, which deduct a fee on each transfer. Because the deposit function mints synthetic tokens according to the _amount rather than the actual amount received (Line 5), each deposit increases the synthetic token supply beyond the underlying collateral. This discrepancy accumulates over time, ultimately resulting in insufficient reserves, failed withdrawals, and permanent losses for merge token holders. Identifying this vulnerability is non-trivial for LLM-based analysis because it results from a compound semantic mismatch among external token behavior, fee-on-transfer mechanics, and internal collateral accounting, rather than from a naive local implementation flaw. When reasoning is confined to the local MergeTokenPortal, the model lacks the necessary context to infer that an external token’s economic behavior can invalidate the portal’s internal accounting assumptions. Table X illustrates the key nodes retrieved by E VO P O C
Exploit Primitive | | +– Setup | +– TokenDeployment | +– TokenRegistration | | +– Exploitation | +– RepeatedDeposits | | +– Arbitrage and Exit | +– RepeatedWithdrawals
1 function deposit(address _sourceToken, ...) external { 2 // ... 3 IERC20Upgradeable(_sourceToken).safeTransferFrom( 4 5 6 7 8 9 10 11 12 13 14
msg.sender, address(this), _amount); address mergeToken = tokenInfo.mergeToken; IERC20MergeToken(mergeToken).mint(_receiver, _amount); // ...} function withdraw(address _sourceToken, ...) external { // ... require(tokenInfo.balance >= _amount, "Source Token balance is not enough"); unchecked {tokenInfo.balance -= _amount;} address mergeToken = tokenInfo.mergeToken; IERC20MergeToken(mergeToken).burn(msg.sender, _amount); IERC20Upgradeable(_sourceToken).safeTransfer( _receiver, _amount); // ...}
Listing 2: Simplified code snippet of the over-minting vulnerability in MergeTokenPortal.sol. from the hierarchical knowledge graph during its analysis of the MergeTokenPortal contract, highlighting how structured knowledge supports multi-hop, cross-domain reasoning. E VO P O C first classifies the contract under the TokenWrapping protocol category and further identifies it as a Portal implementing a DepositMint pattern. By analyzing the deposit and withdraw functions, E VO P O C infers that the contract adopts a balance-delta-based deterministic
12
TABLE XI: Cases post-dating GPT-5 knowledge cutoff (May 2024). ✓/✗ denotes exploit success with/without HKG. Case
Disclosure
Lag (mo.)
w/ HKG
w/o HKG
wifcoin pledge drlvaultv3 yeth
Jun 2024 Dec 2024 Nov 2025 Dec 2025
+1 +7 +18 +19
✓ ✓ ✓ ✓
✗ ✗ ✗ ✗
to validity. To mitigate this issue, we adopt a selection mechanism in Section V-B, which requires candidate intelligence to satisfy at least two of three predefined criteria, thereby filtering out noisy or incomplete inputs. Naturally, the system exhibits its strongest performance when provided with ”gold-standard” intelligence that meets all three criteria. IX. R ELATED W ORK
minting model with a strict 1:1 collateral backing assumption. Through dependency-level retrieval, E VO P O C identifies the involvement of a FeeOnTransfer token, whose economic model imposes a fee on each transfer. This behavior violates the portal’s implicit full-transfer assumption, revealing a semantic inconsistency between the contract’s internal accounting model and its external token dependency. Guided by this semantic conflict, E VO P O C reasons across the contract semantics layers to identify the contract’s failure pattern, characterized by an AccountingMismatch that leads to systematic OverMinting and violation of CollateralConsistency, ultimately breaking Redeemability. Building on this identified failure mode, E VO P O C links it to the corresponding exploit primitives in the HKG to generate a plausible PoC. The PoC was validated through local execution, confirming the correctness of the inferred vulnerability, which was later acknowledged by the developers and fixed in a subsequent revision.
LLM-based smart contract auditing leverages models’ understanding of code to detect vulnerabilities [12], [42], [43], [44], [45]. GPTS CAN [12] is the first to detect logical vulnerabilities in contracts using LLMs. I AUDIT [15] combines fine-tuning and LLM-based agents for intuitive auditing with explanations, while S MART-LL A MA-DPO [46] introduces preference-based optimization to improve vulnerability detection. However, these approaches still face a semantic gap to bridge vulnerability identification and exploitable PoC generation. E VO P O C address this via a structured hierarchical knowledge graph and agentic memory, enabling reliable vulnerability detection and PoC synthesis. Smart contract fuzzing constructs transaction sequences to detect vulnerabilities during execution [47]. Early approaches [48], [49], [50], [51], [52] use control and data flow patterns as oracles, but are limited by predefined templates. Recent methods [53], [28] adopt profit-driven oracles to detect profitable vulnerabilities, serving partially as PoC generators. However, these fuzzers rely on hard-coded heuristics, limiting coverage and scalability, and struggle with complex contextual reasoning. E VO P O C leverages domain knowledge-guided LLMs with verification process and an evolving memory to generate reliable PoCs and handle a broader range of contracts and vulnerabilities. Automated exploit generation has been extensively studied in binary and web security, with systems such as AEG [54] and Q [55] combining symbolic execution with vulnerability signatures to automatically produce working exploits from detected flaws. These works share the core challenge that motivates E VO P O C: bridging the gap between a detected vulnerability and an executable attack artifact. However, DeFi exploits differ fundamentally: they involve inter-contract economic state manipulation, profitability requirements, and protocolspecific interaction semantics that have no direct analogue in traditional binary or web exploitation.
Answer to RQ4: E VO P O C demonstrates its real-world impact by detecting 16 previously unknown vulnerabilities, resulting in $2,900 USD awards and securing protocols managing over $70.6M USD.
VIII. D ISCUSSION A. Data Leakage and Generalization Capability The risk of data leakage is a threat to validity of experimental results in LLM-based systems. We address this from three complementary angles. HKG construction data isolation. The long-term memory of E VO P O C is constructed from data entirely disjoint from the evaluation datasets and stores only abstracted, reusable knowledge rather than instance-level code. Post-training cutoff cases. Table XI lists four cases of D2 whose public disclosure post-dates GPT-5’s knowledge cutoff (May 2024), meaning the model cannot have seen their exploit details during pretraining. E VO P O C successfully generates valid PoCs for all four cases with HKG guidance, while the noHKG baseline produces none, directly ruling out memorization as the driver for these results. Memorization test. To further distinguish memorization from generalization, our ablation VII-D already provides this test: the no-HKG baseline, which reduces E VO P O C to direct LLM reasoning over raw contract code, produces zero successful exploits across all 88 cases (Table VII).
X. C ONCLUSION We present E VO P O C, a knowledge-driven agentic system for end-to-end smart contract vulnerability detection and PoC generation. By organizing vulnerability intelligence into a hierarchical knowledge graph and leveraging self-evolving agentic memory with two-step verification, E VO P O C achieves robust reasoning and exploit synthesis. Experiments show that E VO P O C outperforms SOTA vulnerability scanners, fuzzers, and PoC generators in both vulnerability identification and exploit success rate. E VO P O C also discovered 16 0-day vulnerabilities across five real-world projects.
B. Reliability of Memory Evolution The effectiveness of E VO P O C ’s evolving memory is influenced by the quality of the underlying domain knowledge and vulnerability intelligence, which constitutes a potential threat
13
E THICS C ONSIDERATIONS
[7] R. Liang, J. Chen, R. Cao, K. He, R. Du, S. Li, Z. Lin, and C. Wu, “Smartshot: Hunt hidden vulnerabilities in smart contracts using mutable snapshots,” in Proceedings of the ACM International Conference on the Foundations of Software Engineering (FSE), 2025. [8] J. Stephens, K. Ferles, B. Mariano, S. Lahiri, and I. Dillig, “Smartpulse: automated checking of temporal properties in smart contracts,” in Proceedings of the IEEE Symposium on Security and Privacy (SP), 2021. [9] P. Bose, D. Das, Y. Chen, Y. Feng, C. Kruegel, and G. Vigna, “Sailfish: Vetting smart contract state-inconsistency bugs in seconds,” in Proceedings of the IEEE Symposium on Security and Privacy (SP), 2022. [10] Y. Liu, Y. Xue, D. Wu, Y. Sun, Y. Li, M. Shi, and Y. Liu, “Propertygpt: Llm-driven formal verification of smart contracts through retrievalaugmented property generation,” in Proceedings of the Annual Network and Distributed System Security Symposium (NDSS), 2025. [11] B. Zhang, “Towards finding accounting errors in smart contracts,” in Proceedings of the IEEE/ACM International Conference on Software Engineering (ICSE), 2024. [12] 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,” in Proceedings of the IEEE/ACM International Conference on Software Engineering (ICSE), 2024. [13] J. Kevin and P. Yugopuspito, “Smartllm: Smart contract auditing using custom generative ai,” in Proceedings of the International Conference on Computer Sciences, Engineering, and Technology Innovation (ICoCSETI), 2025. [14] Y. Jin, C. Li, P. Fan, P. Liu, X. Li, C. Liu, and W. Qiu, “Llm-bscvm: An llm-based blockchain smart contract vulnerability management framework,” arXiv preprint arXiv:2505.17416, 2025. [15] 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,” in Proceedings of the IEEE/ACM International Conference on Software Engineering (ICSE), 2025. [16] 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. [17] A. Gervais and L. Zhou, “Ai agent smart contract exploit generation,” arXiv preprint arXiv:2507.05558, 2025. [18] N. Dziri, X. Lu, M. Sclar, X. L. Li, L. Jiang, B. Y. Lin, P. West, C. Bhagavatula, R. Le Bras, J. D. Hwang, S. Sanyal, S. Welleck, X. Ren, A. Ettinger, Z. Harchaoui, and Y. Choi, “Faith and fate: limits of transformers on compositionality,” in Proceedings of the International Conference on Neural Information Processing Systems (NIPS), 2023. [19] L. Yu, Z. Huang, H. Yuan, S. Cheng, L. Yang, F. Zhang, C. Shen, J. Ma, J. Zhang, J. Lu, and C. Zuo, “Smart-llama-dpo: Reinforced large language model for explainable smart contract vulnerability detection,” in Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2025. [20] K. Qin, Z. Ye, Z. Wang, W. Li, L. Zhou, C. Zhang, D. Song, and A. Gervais, “Enhancing smart contract security analysis with execution property graphs,” in Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2025. [21] H. Wen, H. Liu, J. Song, Y. Chen, W. Guo, and Y. Feng, “Foray: Towards effective attack synthesis against deep logical vulnerabilities in defi protocols,” in Proceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2024. [22] J. Ho, A. Jain, and P. Abbeel, “Denoising diffusion probabilistic models,” in Proceedings of the International Conference on Neural Information Processing Systems (NIPS), 2020. [23] Z. Group, “Openzeppelin research,” 2025. [Online]. Available: https://www.openzeppelin.com/research [24] Chainalysis, “Chainalysis blog crime,” 2025. [Online]. Available: https://www.chainalysis.com/blog/category/crime/ [25] CertiK, “Web3 resources,” 2025. [Online]. Available: https://www. certik.com/resources [26] Medium, “Medium,” 2025. [Online]. Available: https://medium.com/ [27] X, “X,” 2025. [Online]. Available: https://x.com/ [28] Z. Kong, C. Zhang, M. Xie, M. Hu, Y. Xue, Y. Liu, H. Wang, and Y. Liu, “Smart contract fuzzing towards profitable vulnerabilities,” in Proceedings of the ACM International Conference on the Foundations of Software Engineering (FSE), 2025. [29] S. Werner, D. Perez, L. Gudgeon, A. Klages-Mundt, D. Harz, and W. Knottenbelt, “Sok: Decentralized finance (defi),” in Proceedings of the ACM Conference on Advances in Financial Technologies (AFT), 2023.
Research Scope and Ethical Boundaries. This research strictly adheres to ethical standards for security and AI system evaluation. E VO P O C is designed and presented solely for the purpose of analyzing and improving the robustness of DeFi protocol security. Our work aims to reveal the inherent limitations of current smart contract auditing practices and demonstrate the feasibility of automated exploit synthesis as a means to accelerate vulnerability validation. All experiments were conducted in controlled, locally hosted environments built upon Foundry’s fork simulation framework. No live, online, or third-party blockchain systems were accessed, attacked, tested, or influenced at any stage of this research. All exploit scripts execute against a locally forked blockchain state and do not submit any transactions to mainnet or any testnet. Zero-day Disclosure and Responsible Use. The 0-day vulnerabilities discovered by E VO P O C during our evaluation were responsibly disclosed to the respective project developers prior to public reporting. We reported all findings through official channels, including direct developer contact and the Secure3 bug bounty platform, and withheld technical details until developers had sufficient time to acknowledge and remediate the issues. To date, 16 vulnerabilities have been confirmed or patched by the respective teams. Only the highlevel descriptions of vulnerability categories are included in the paper; no functional exploit code targeting any real-world deployed contract is distributed. Dual-use Considerations. We acknowledge that automated exploit generation tools carry inherent dual-use risks. To mitigate potential misuse, the full system is intended for release to vetted security researchers and auditors only, with usage restricted to contracts for which the user holds authorization. We encourage the community to adopt E VO P O C as a standard component in pre-deployment security audits, thereby strengthening the defensive posture of DeFi protocols before adversarial exploitation occurs. R EFERENCES [1] C. Intelligence, “Gpt-4 technical report,” 2025. [Online]. Available: https://crystalintelligence.com/thought-leadership/ 22-7b-in-stolen-digital-assets-since-2011 [2] J. Feist, G. Grieco, and A. Groce, “Slither: A static analysis framework for smart contracts,” in Proceedings of the IEEE/ACM International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), 2019. [3] A. Ghaleb, J. Rubin, and K. Pattabiraman, “Achecker: Statically detecting smart contract access control vulnerabilities,” in Proceedings of the IEEE/ACM International Conference on Software Engineering (ICSE), 2023. [4] K. Qin, Z. Ye, Z. Wang, W. Li, L. Zhou, C. Zhang, D. Song, and A. Gervais, “Enhancing smart contract security analysis with execution property graphs,” in Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2025. [5] M. Xie, M. Hu, Z. Kong, C. Zhang, Y. Feng, H. Wang, Y. Xue, H. Zhang, Y. Liu, and Y. Liu, “Defort: Automatic detection and analysis of price manipulation attacks in defi applications,” in Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2024. [6] C. Shou, S. Tan, and K. Sen, “Ityfuzz: Snapshot-based fuzzer for smart contract,” in Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2023.
14
[52] Y. Xue, J. Ye, W. Zhang, J. Sun, L. Ma, H. Wang, and J. Zhao, “xfuzz: Machine learning guided cross-contract fuzzing,” IEEE Trans. Dependable Secur. Comput., vol. 21, 2024. [53] M. Ye, X. Lin, Y. Nan, J. Wu, and Z. Zheng, “Midas: Mining profitable exploits in on-chain smart contracts via feedback-driven fuzzing and differential analysis,” in ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2024. [54] T. Avgerinos, S. K. Cha, A. Rebert, E. J. Schwartz, M. Woo, and D. Brumley, “Automatic exploit generation,” Communications of the ACM, vol. 57, 2014. [55] E. J. Schwartz, T. Avgerinos, and D. Brumley, “Q: Exploit hardening made easy,” in Proceedings of the USENIX Security Symposium (USENIX Security), 2011.
[30] K. John, L. Kogan, and F. Saleh, “Smart contracts and decentralized finance,” Annual Review of Financial Economics, vol. 15, 2023. [31] J. C. León and A. Lehar, “What data have told us about decentralized finance,” Journal of Corporate Finance, 2025. [32] L. Zhou, X. Xiong, J. Ernstberger, S. Chaliasos, Z. Wang, Y. Wang, K. Qin, R. Wattenhofer, D. Song, and A. Gervais, “ SoK: Decentralized Finance (DeFi) Attacks ,” in Proceedings of the IEEE Symposium on Security and Privacy (SP), 2023. [33] A. Khare, S. Dutta, Z. Li, A. Solko-Breslin, R. Alur, and M. Naik, “Understanding the effectiveness of large language models in detecting security vulnerabilities,” in Proceedings of the IEEE Conference on Software Testing, Verification and Validation (ICST), 2025. [34] J. Lin and D. Mohaisen, “From large to mammoth: A comparative evaluation of large language models in vulnerability detection,” in Proceedings of the Network and Distributed System Security Symposium (NDSS), 2025. [35] Meta, “Faiss: A library for efficient similarity search and clustering of dense vectors.” 2025. [Online]. Available: https://github.com/ facebookresearch/faiss [36] Foundry, “Foundry: Ethereum development framework,” 2025. [Online]. Available: https://getfoundry.sh/ [37] I. LangChain, “Langchain,” 2025. [Online]. Available: https://www. langchain.com [38] ANTLR, “Another tool for language recognition,” 2025. [Online]. Available: https://github.com/antlr/antlr4 [39] Neo4j, “Neo4j graph database & analytics,” 2025. [Online]. Available: https://neo4j.com [40] SunSec, “Defihacklabs,” 2025. [Online]. Available: https://github.com/ SunWeb3Sec/DeFiHackLabs [41] Secure3, “Comprehensive security audits for the web3 ecosystems,” 2025. [Online]. Available: https://app.secure3.io [42] Y. Wu, X. Xie, C. Peng, D. Liu, H. Wu, M. Fan, T. Liu, and H. Wang, “Advscanner: Generating adversarial smart contracts to exploit reentrancy vulnerabilities using llm and static analysis,” in Proceedings of the IEEE/ACM International Conference on Automated Software Engineering (ASE), 2024. [43] 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,” in Proceedings of the IEEE International Conference on Software Maintenance and Evolution (ICSME), 2025. [44] L. Zhang, K. Li, K. Sun, D. Wu, Y. Liu, H. Tian, and Y. Liu, “Acf ix: Guiding llms with mined common rbac practices for contextaware repair of access control vulnerabilities in smart contracts,” IEEE Transactions on Software Engineering, 2025. [45] Z. Wei, J. Sun, Y. Sun, Y. Liu, D. Wu, Z. Zhang, X. Zhang, M. Li, Y. Liu, C. Li et al., “Advanced smart contract vulnerability detection via llm-powered multi-agent systems,” IEEE Transactions on Software Engineering, 2025. [46] 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,” in Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2025. [47] S. Wu, Z. Li, L. Yan, W. Chen, M. Jiang, C. Wang, X. Luo, and H. Zhou, “Are we there yet? unraveling the state-of-the-art smart contract fuzzers,” in IEEE/ACM International Conference on Software Engineering (ICSE), 2024. [48] 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 Forensics and Security (TIFS), 2023. [49] J. Lin, Q. Zhang, J. Li, C. Sun, H. Zhou, C. Luo, and C. Qian, “Automatic library fuzzing through api relation evolvement,” in Network and Distributed System Security Symposium (NDSS), 2025. [50] X. Lin, Q. Xie, B. Zhao, Y. Tian, S. Zonouz, N. Ruan, J. Li, R. Beyah, and S. Ji, “Promfuzz: Leveraging llm-driven and bug-oriented composite analysis for detecting functional bugs in smart contracts,” in Proceedings of the IEEE/ACM International Conference on Automated Software Engineering (ASE), 2025. [51] M. Rodler, D. Paaßen, W. Li, L. Bernhard, T. Holz, G. Karame, and L. Davi, “Ef/cf: High performance smart contract fuzzing for exploit generation,” in Proceedings of the IEEE European Symposium on Security and Privacy (EuroS&P), 2023.
A PPENDIX A WALK - THROUGH OF T WO - STAGE VALIDATION This appendix illustrates how E VO P O C validates an exploit candidate using a real-world signature-bypass minting vulnerability. The vulnerable token contract exposes a privileged mint function that is intended to be protected by a multisignature authorization check. The exploit candidate bypasses this check using empty signature arrays, mints 1012 BEGO tokens to the attacker, and then liquidates the minted tokens through the BEGO/WBNB AMM pair to realize profit. A. Victim Contract Semantics Listing 3 shows the simplified vulnerable logic. The contract provides a mint function that takes a mint amount, a replayprotection identifier, a receiver address, and three arrays representing ECDSA signature components. The intended design is that mint should only proceed when the submitted signatures are produced by authorized signers. To prevent replay, the function records used identifiers in txHashes. However, the authorization logic is flawed. The modifier isSigned first checks only whether the three signature arrays have equal lengths. It then allocates an array of recovered signers with length _r.length, fills this array by iterating over the submitted signatures, and finally calls isSigners to verify whether all recovered addresses are authorized signers. When the attacker submits empty arrays, the length check succeeds because all three arrays have length zero. The recovery loop is skipped, and isSigners receives an empty signer array. Since isSigners only rejects explicitly invalid signers inside the loop, the loop is also skipped and the function returns true. As a result, the signature check is bypassed and the privileged minting sink becomes reachable without any valid signature. B. Candidate Exploit Plan For readability, we use swapBEGOToWBNB to denote the PancakeSwap V2 router call that liquidates the minted BEGO tokens into WBNB. Given the above semantics, E VO P O C constructs the following high-level exploit plan: P = ⟨t1 , t2 , t3 ⟩, t1 = ⟨CBEGO , mint, σmint , Kmint ⟩, t2 = ⟨CBEGO , approve, σapprove , Kallowance ⟩, t3 = ⟨CRouter , swapBEGOToWBNB, σswap , Kprofit ⟩.
15
1 function mint( 2 uint256 _amount, 3 string memory _txHash, 4 address _receiver, 5 bytes32[] memory _r, 6 bytes32[] memory _s, 7 uint8[] memory _v 8 ) isSigned(_txHash, _amount, _r, _s, _v) 9 external returns (bool) 10 { 11 require(!txHashes[_txHash], "tx-hash-used"); 12 txHashes[_txHash] = true; 13 14 _mint(_receiver, _amount); 15 return true; 16 } 17 18 modifier isSigned( 19 string memory _txHash, 20 uint256 _amount, 21 bytes32[] memory _r, 22 bytes32[] memory _s, 23 uint8[] memory _v 24 ) { 25 require(checkSignParams(_r, _s, _v), "bad-sign-
We use M for the human-readable token amount and Mraw for the 18-decimal ERC-20 base-unit amount. After minting, the attacker approves the PancakeSwap V2 router to spend the minted BEGO tokens and swaps all received BEGO for WBNB. The resulting exploit path is: BEGO.mint(Mraw , h, attacker , [], [], []) → isSigned → checkSignParams → skip-ecrecover-loop → isSigners([]) → mint(attacker , Mraw ) → BEGO.approve(Router, ∞) → Router.swapBEGOToWBNB.
C. Stage 1: Exploit-path Reachability The first validation stage checks whether the privileged minting sink is logically reachable from the public entry function mint. For the candidate above, E VO P O C performs semantic traversal from mint through the isSigned modifier and collects the branch predicates that guard mint. The extracted path is:
params");
26 27 28 29 30 31 32 33
bytes32 _hash = keccak256(abi.encodePacked(bsc, msg.sender, _txHash, _amount));
π = ⟨mint, isSigned, checkSignParams, skip-ecrecover-loop, isSigners, mint⟩.
address[] memory _signers = new address[](_r.length );
The path predicates collected from the contract are: ϕ1 : |R| = |S|, ϕ2 : |S| = |V |, ϕ3 : ¬txHashes[h].
for (uint8 i = 0; i < _r.length; i++) { _signers[i] = ecrecover(_hash, _v[i], _r[i], _s [i]); }
34 35 36 require(isSigners(_signers), "bad-signers"); 37 _; 38 } 39 40 function checkSignParams( 41 bytes32[] memory _r, 42 bytes32[] memory _s, 43 uint8[] memory _v 44 ) internal pure returns (bool) { 45 return _r.length == _s.length && _s.length == _v.
The candidate-controlled assignments are: |R| = |S| = |V | = 0, receiver = attacker , Mraw = 1012 × 1018 .
The signature recovery loop is guarded by 0 ≤ i < |R|. Since |R| = 0, the loop has no feasible iteration:
length;
46 } 47 48 function isSigners(address[] memory _signers) 49 public view returns (bool) 50 { 51 for (uint8 i = 0; i < _signers.length; i++) { 52 if (!_containsSigner(_signers[i])) { 53 return false; 54 } 55 } 56 return true; 57 }
∀i, ¬(0 ≤ i < 0).
Therefore, no call to ecrecover is required, and the recovered signer array remains empty. Since the rejection condition in isSigners is only evaluated inside the loop, the empty signer array is accepted: signers = [] =⇒ isSigners(signers) = true.
Listing 3: Simplified signature-bypass minting vulnerability.
The SMT query used for this path consists of the collected predicates instantiated with the empty-array assignment:
The first interaction targets the vulnerable token contract and attempts to reach the privileged minting operation. The mint sink and its symbolic input are:
Φ = ϕ1 ∧ ϕ2 ∧ ϕ3 ∧ (|R| = 0) ∧ (|S| = 0) ∧ (|V | = 0).
A satisfying assignment is:
Kmint = mint(attacker , Mraw ), σmint = (Mraw , h, attacker , R, S, V ).
Here, h is an attacker-chosen replay-protection identifier that has not been used before, and R, S, V are attacker-controlled signature arrays. The candidate assigns:
|R| = |S| = |V | = 0,
Mraw = 1012 × 1018 ,
receiver = attacker ,
txHashes[h] = false.
Thus, the result is SAT(Φ) = true, which confirms that the exploit-critical sink in t1 is reachable: mint(attacker , Mraw ). The remaining approval and swap interactions are then handled in the asset-level profitability simulation.
M = 1012 BEGO, Mraw = 1012 × 1018 , |R| = |S| = |V | = 0.
16
TABLE XII: Step-wise asset-state simulation for the BEGO signature-bypass minting exploit. Step
Operation
Attacker BEGO
Attacker WBNB
AMM state Ω
S0 S1 S2 S3 S4 S5 S6 Sf
Initial state Prepare empty signatures Pass isSigned Execute mint sink Approve router Transfer BEGO to pair Pair outputs WBNB Final state
0 0 0 1012 1012 ≈0 ≈0 ≈0
0 0 0 0 0 0
(RBEGO , RWBNB ) (RBEGO , RWBNB ) (RBEGO , RWBNB ) (RBEGO , RWBNB ) (RBEGO , RWBNB ) (RBEGO + x, RWBNB ) (RBEGO + x, RWBNB − outWBNB ) Ωf
outWBNB outWBNB
TABLE XIII: Bootstrapped HKG node statistics and crosslayer edge statistics.
D. Stage 2: Profit Realizability The second validation stage checks whether the reachable minting sink can be converted into positive asset-level profit. E VO P O C tracks the attacker’s BEGO and WBNB balances, as well as the BEGO/WBNB AMM state, throughout the candidate exploit. Unlike flash-loan-based candidates, this exploit does not require upfront capital in the abstract asset model; the input BEGO is created by the vulnerable mint operation. We model the asset state as S = ⟨B, Ω⟩, where B records account-level token balances and Ω records the BEGO/WBNB AMM state. The initial state is:
After Stage 1 proves that empty signature arrays satisfy the authorization modifier, the attacker calls mint(Mraw , h, attacker , [], [], []). This increases the attacker’s BEGO balance by M : B3 (attacker , BEGO) = 10 ,
Contract Semantics Failure Mode Exploit Primitive
144 107 523
CS→FM: 165 FM→EP: 132 –
Total
774
297
Table XIV provides the complete ontology schema of the Hierarchical Knowledge Graph, including all node types, their semantic roles, intra-layer edge types, and cross-layer linking constraints. The schema is fixed prior to HKG construction and is not modified during knowledge abstraction or fusion; see Section V-B for the formal definition. Node type assignment. During knowledge abstraction, the LLM assigns each extracted element a node type from the predefined schema via chain-of-thought prompting. A node receives type T only if its semantic description matches the role definition of T and its incident edges are admissible under the schema constraints. Cases where two candidate types score within a confidence margin of 0.1 are flagged as ambiguous and resolved during fusion by adopting the most consistent typing across similar cases. HKG statistics. As shown in Table XIII, the bootstrapped HKG contains 774 nodes across three layers: 144 contract semantics nodes, 107 failure mode nodes, and 523 exploit primitive nodes. It also includes 297 cross-layer edges, with 165 CS→FM edges and 132 FM→EP edges. This moderate graph density reflects the design principle of encoding causal relevance rather than exhaustive linkage.
B3 (attacker , WBNB) = 0.
γxRWBNB , RBEGO + γx
where γ is the fee-adjusted input ratio. After the swap: Bf (attacker , BEGO) ≈ 0,
Cross-layer Edges
A PPENDIX B HKG O NTOLOGY S CHEMA D ETAILS
The subsequent approval only updates allowance and does not change token balances, so B4 = B3 . During liquidation, the router transfers the minted BEGO from the attacker to the BEGO/WBNB pair. Let x denote the actual amount of BEGO credited to the pair. For a standard ERC-20 transfer, x = 1012 BEGO; if the token applies transfer-side deductions, x denotes the post-transfer amount received by the pair. The AMM output is: outWBNB =
Nodes
This walk-through demonstrates how the two-stage validation framework separates exploit feasibility into two complementary checks. The first stage verifies that the security-critical sink is reachable under attacker-controlled inputs, while the second stage verifies that reaching this sink yields a positive asset-level outcome.
Ω0 = (RBEGO , RWBNB ), B0 (attacker , BEGO) = 0, B0 (attacker , WBNB) = 0.
12
Layer
Bf (attacker , WBNB) = outWBNB .
Using WBNB as the numeraire and ignoring gas in the abstract simulation, the asset-level wealth change is: ∆W = Val(Bf , Ωf ) − Val(B0 , Ω0 ) = outWBNB .
When outWBNB > 0, the candidate is economically viable and passes the second validation stage. Table XII summarizes the step-wise asset-state simulation. The simulation includes the authorization steps for continuity; they do not change asset balances. The concrete asset transition is: (0 BEGO, 0 WBNB) → (≈ 0 BEGO, outWBNB WBNB).
Since outWBNB > 0, the exploit realizes positive profit and is forwarded for concrete Foundry execution.
17
TABLE XIV: HKG ontology schema: node types, semantic roles, and cross-layer edge types. Layer Contract Semantics (CS)
Node Type
Semantic Role
Protocol
Top-level protocol category; serves as semantic anchor linked to all other CS nodes via enforces, adopts, depends_on. Permission structure and role enforcement logic of the contract (e.g., owner-only guards, proxy admin). Fee structures, tokenomics, reserve accounting, and incentive mechanisms (e.g., feeon-transfer, rebase). External contract and non-standard token dependencies that affect protocol behavior.
Access Control Economic Model Dependency Failure Pattern
Failure Mode (FM)
Condition Root Cause Impact Invariant Violation
Exploit Primitive (EP)
Exploit Behavior Specific Plan PoC Framework Few-shot Example
Named vulnerability pattern (e.g., price manipulation, accounting mismatch); causally linked to root cause via caused_by. Preconditions in the execution environment required to trigger the failure (e.g., flash loan availability). Underlying implementation or design flaw that enables the vulnerability (e.g., fulltransfer assumption). Observable consequence of a successful exploit: fund drainage, over-minting, DoS, unauthorized withdrawal. Protocol-level invariant broken when the failure manifests (e.g., collateral consistency, reserve balance). Generic, reusable exploit action template covering preparation, exploitation, and arbitrage phases. Case-specific exploit step sequence grounded in a concrete DeFi incident; composed from exploit behaviors. High-level Foundry test scaffold that assembles specific plans into a complete executable PoC. Concrete Solidity snippet grounding abstract exploit behaviors in real attack code for LLM reasoning.
Cross-layer Edge Types related_exploit: CS → FM caused_by: FP → RC leads_to: RC → Inv related_exploit: FM → EP start_at: PocFrame → SpecificPlan
Links a CS node to failure patterns it is implicated in. Failure pattern is caused by a specific root cause. Root cause leads to a protocol invariant violation. Root cause pattern linked to corresponding exploit primitives. PoC framework references specific plans as composable phases.
18