DeFi smart contract security auditing faces a structural bottleneck: billions of dollars are lost annually to contract vulnerabilities, yet identifying a vulnerability and proving it is exploitable are two fundamentally different tasks. Manually constructing proofs-of-concept (PoCs) is so labor-intensive that most disclosed vulnerabilities are never actually verified—leaving protocols exposed to unknown risk until mitigations ship.
On May 4, 2026, Liang et al. published the EvoPoC system (arXiv:2605.02868), which uses a knowledge-driven multi-agent architecture to solve this problem systematically. This article provides a structural analysis of its technical mechanisms, verification framework, and experimental results.
Why Traditional Methods Fall Short
The traditional audit pipeline—code review → vulnerability identification → PoC construction → verification—has systemic weaknesses at every stage:
- Code review: human auditors read only a few thousand lines per day against codebases of hundreds of thousands; static analysis tools have high false-positive rates.
- Vulnerability identification: "suspicious code" is not "exploitable code." Fuzzers (e.g., Echidna, ItyFuzz) trigger anomalies, but an anomaly is not necessarily an exploitable vulnerability.
- PoC construction: the biggest bottleneck—turning suspicious patterns into working attacks requires deep understanding of protocol semantics, failure root causes, and how attack primitives compose.
- Verification: most methods ignore whether a running PoC is actually *profitable* at the economic level.
- L3 — Protocol Semantics layer: DeFi primitives (AMMs, flash loans, governance tokens, yield farming), interaction patterns (deposit→borrow→repay→withdraw), economic constraints (collateral thresholds, liquidation bonuses, slippage tolerance).
- L2 — Exploit Primitives layer: reentrancy, oracle manipulation, access control bypass, front-running/sandwich attacks, governance flash loan attacks.
- L1 — Concrete Patterns layer: code snippets, historical attacks (Poly Network cross-chain validation bypass, $611M; Beanstalk governance flash loan attack, $182M), audit findings.
- Title: EvoPoC: Automated Exploit Synthesis for DeFi Smart Contracts via Hierarchical Knowledge Graphs
- Authors: Ruichao Liang, Jing Chen, Xianglong Li, Huangpeng Gu, Yebo Feng, Yue Xue, Cong Wu, Yang Liu
- arXiv ID: 2605.02868
- Published: May 4, 2026
- Categories: cs.CR, cs.SE
Core Insight: Exploit Synthesis ≠ Code Generation
EvoPoC's methodology rests on the counterintuitive insight that exploit synthesis is a structured reasoning problem, not a code generation task. A valid exploit requires three types of grounded knowledge:
| Knowledge | Meaning | Examples | |:--|:--|:--| | Protocol semantics | business-level function of contracts | AMM pricing formulas, flash loan repayment constraints | | Failure root causes | underlying cause of the vulnerability | missing check-effects-interaction, stale oracle updates | | Exploit primitives | reusable attack techniques | reentrancy, price manipulation, governance attacks |
Naive approaches (including simple LLM prompting) treat synthesis as code generation, ignoring the structured relationships among these knowledge types. EvoPoC builds the knowledge structure first, then reasons over it.
HKG: Hierarchical Knowledge Graph
EvoPoC organizes the three knowledge types into a Hierarchical Knowledge Graph (HKG) that serves as structured memory for LLM-guided multi-hop reasoning:
LLM reasoning follows a multi-hop path: an L1 anomaly pattern is abstracted to an L2 primitive, semantically bound to an L3 protocol constraint, and used to synthesize a constraint-satisfying exploit. This layered design addresses two pure-LLM failure modes:
1. Hallucination — HKG anchors reasoning in real, grounded patterns. 2. Combinatorial explosion — hierarchical abstraction narrows the search space from "all possible code" to "primitives relevant to the current protocol's semantics."
Two-Stage Verification Framework
Generating an exploit is only step one. EvoPoC's key innovation is verification: ensuring a PoC is not just runnable code but a profitable attack in a realistic environment.
Stage 1: Logical Reachability via SMT Solving
The attack path is encoded as a constraint system: variables represent contract state (balances, permission flags), constraints represent code logic. The solver answers whether there exists a transaction sequence π such that the attack success condition φ holds in the final state. If UNSAT, the attack path is logically blocked.
> SMT (Satisfiability Modulo Theories): an automated logical reasoning tool that decides whether a set of mathematical/logical constraints is satisfiable.
Stage 2: Economic Feasibility via Asset-Level Simulation
Stage 2 simulates full transaction execution in a virtual blockchain environment, tracking per-address token balance changes, liquidity pool state transitions, oracle price updates, gas costs, and flash loan repayment constraints:
Profit = final assets − initial assets − gas cost − flash loan interest
A PoC is deemed "economically feasible" only when Profit > 0. The two-stage design provides layered filtering: the cheap SMT stage quickly discards logically infeasible candidates before the expensive simulation runs.
Experimental Results
Evaluation covers three dimensions: historical attack replay, audited project detection, and 0-day discovery.
Historical Attack Replay (88 real DeFi attacks)
| Metric | Value | |:--|:--| | Successful replays | 85 / 88 (96.6% ESR) | | Recoverable asset value | $116.2M |
The 3 failures likely involve complex attacks requiring off-chain coordination or social engineering.
Audited Project Detection (72 projects, 2,573 contracts)
| Metric | Value | |:--|:--| | Recall | 98% | | F1-Score | 0.90 |
Comparison with SOTA
| Dimension | EvoPoC | SOTA fuzzers (Verite, ItyFuzz) | LLM generator (A1) | |:--|:--:|:--:|:--:| | ESR | 96.6% | ~19% | ~48% | | ESR multiple | baseline | 1/5× | 1/2× | | Recoverable value multiple | baseline | 1/300× | 1/8.5× |
The pattern: fuzzers are adequate at finding anomalies but very weak at turning them into exploitable attacks (19% ESR). The 300× gap in recoverable value is especially notable—fuzzer PoCs typically extract small amounts, while EvoPoC constructs profit-maximizing attack paths by understanding protocol semantics.
0-Day Discovery (Bug Bounty Evaluation)
| Metric | Value | |:--|:--| | Confirmed 0-day vulnerabilities | 16 | | Assets protected | $70.6M | | Bounties earned | $2,900 |
All 16 zero-days were found in projects that had already undergone manual audits—suggesting EvoPoC exceeds the coverage of current industry-standard human auditing. The $2,900 bounty versus $70.6M protected value (~0.004%) also exposes a structural issue in bug bounty economics: defenders pay far less than attackers could steal.
Attack–Defense Asymmetry and Limitations
Asymmetry
EvoPoC's techniques are public—available to defenders *and* attackers. The systemic impact depends on asymmetric adoption speed: attackers can directly scan the ecosystem, while protocol teams must integrate into development workflows. Before defenders fully adopt AI-assisted auditing, attackers may have already built systematic scanning capability—a classic technology-diffusion timing problem.
Limitations
1. Historical attack bias: the 96.6% ESR was measured on known attack patterns; effectiveness on novel attack vectors is unknown. 2. Protocol complexity boundary: HKG construction depends on enumerable attack primitives; coverage may be insufficient for attacks spanning multiple protocols (e.g., cross-chain attacks). 3. Economic model simplification: asset-level simulation assumes a rational, solitary attacker in a static market. In real MEV competition, multiple bots racing for the same opportunity change actual profitability.
Conclusion: From Tool to Infrastructure
EvoPoC's deeper value is a methodological shift: code generation → structured reasoning → verified exploit. This moves DeFi security auditing from experience-driven manual labor toward knowledge-driven systematic methods.
But the technology itself is neutral. A 96.6% ESR can protect $70.6M in assets—or steal more. What ultimately determines the direction of the security ecosystem is not technical capability, but adoption speed and governance frameworks.