arXiv CSopen access

Knowledge Over Parameters: Evolving Smart Contract Vulnerability Detection

Knowledge Over Parameters: Evolving Smart Contract Vulnerability Detection Yuqiang Sun∗ , Han Liu† , Ying Li‡ , Yiran Zhang∗ , Zong Cao§ , Ziyun Guo¶ , Yang Liu∗ ∗ Nanyang Technological University, Singapore

arXiv:2607.01742v1 [cs.CR] 2 Jul 2026

[email protected], [email protected], [email protected] † Nankai University, China [email protected] ‡ University of California, Los Angeles, USA [email protected] § Imperial Global Singapore, Imperial College London, and Nanyang Technological University ¶ Singapore Management University, Singapore [email protected]

Abstract—Smart contract vulnerabilities are predominantly logic bugs whose detection requires structured, step-by-step procedural knowledge of attack patterns and contract semantics. Existing LLM-based methods struggle to generate this knowledge automatically: prompt-based methods rely on manually crafted detection rules, while fine-tuning requires massive labeled datasets that are inherently scarce in this domain. We present E VOV ULN, an automated framework that reformulates vulnerability detection as a procedural knowledge evolution problem, synthesizing and refining detection logic using only a minimal number of labeled samples. To achieve this, E VOV ULN introduces two key mechanisms. First, a Runtime with an Inversion of Control (IoC) architecture compiles detection rules into Executable Policies. This strictly decouples deterministic control flow from LLM semantic reasoning, ensuring faithful logical adherence and producing dense diagnostic telemetry for precise error localization. Second, a two-phase evolution pipeline refines the rule via abductive semantic debugging without any parameter updates: Cold Start bootstraps and stress-tests an initial rule using auto-synthesized corner cases; Few-Shot Evolving then grounds the policy in real-world semantics using only five vulnerable and five safe examples per vulnerability type. Evaluated across five real-world vulnerability types, E VOV ULN achieves a 71% macro-average F1-score, outperforming all baselines. The evolved procedural knowledge is portable across models: it enables a lightweight, low-cost model to surpass a much larger zero-shot model by 19 percentage points, and transfers to other LLMs without retraining, at a one-time evolution cost under $50.

I. I NTRODUCTION Smart contracts are high-stakes programs governing decentralized finance (DeFi), where logic bugs, such as price manipulation and access control flaws, frequently lead to massive financial losses [1]. Unlike syntactic errors, these logic flaws depend on semantic intent, requiring structured, multi-step procedural knowledge to verify if a contract violates application-level invariants. Current detection paradigms face a fundamental bottleneck. Prompt-based methods rely on manually authored rules [2– 4], which are labor-intensive and fail to scale to emerging threats. Conversely, fine-tuning approaches [5–7] attempt to learn detection patterns directly, yet are constrained by the severe scarcity of labeled data. Neither paradigm supports the automated generation or evolution of detection logic.

[email protected]

Inspired by the agentic “skill” paradigm, which encodes reusable, task-specific capabilities to avoid reasoning from scratch [8–10], we view vulnerability detection as the synthesis of procedural knowledge: structured rules that dictate semantic inspection steps. Existing methods like GPTScan [2] essentially instantiate this paradigm with human-authored rules, but they leave three critical gaps: First, current procedural knowledge relies entirely on human experts, making it unscalable for emerging vulnerability types. When relying on LLMs to generate this knowledge automatically, the generated procedures are often flawed or insufficient to cover real-world attack surfaces. Second, even if correct knowledge is provided, when unconstrained LLM agents attempt to autonomously execute these complex procedures, they suffer from reasoning drift, frequently falling back on their own internal priors instead of faithfully executing the prescribed multi-step logic. Conversely, bypassing procedural logic through direct fine-tuning is intractable due to the severe scarcity of labeled data. This raises the central question of this paper: Can procedural detection knowledge be automatically generated, strictly enforced, and continuously evolved using minimal labeled data, without manual engineering? We present E VOV ULN, a framework that answers this question affirmatively by reformulating vulnerability detection as an automated lifecycle of procedural knowledge generation and evolution. E VOV ULN treats procedural knowledge not as a static prompt, but as a persistent software artifact that is synthesized, executed, and empirically refined. To operationalize this framework, we address three primary dimensions: (i) Controlled Execution via Inversion of Control (IoC): Even perfectly generated procedural knowledge is useless if the agent fails to follow it faithfully. E VOV ULN compiles detection rules into Executable Policies, deterministic programmatic detection plans that strictly enforce structural control flow, utilizing LLMs solely as on-demand semantic oracles for localized judgments. (ii) Abductive Knowledge Evolution: Automatically generated procedural knowledge is prone to errors and requires feedback grounded in actual contract behavior. E VOV ULN employs abductive semantic debugging to iteratively patch and evolve detection rules. By leveraging dense execution telemetry from the executable policy, E VOV ULN pinpoints

logical missteps in failed detections and performs targeted updates using minimal labeled samples. (iii) Knowledge Transfer Across Models: E VOV ULN’s evolved procedural knowledge is portable: it enables lightweight, low-cost models (e.g., GPT5-nano) to outperform much larger models in zero-shot mode, decoupling detection accuracy from model scale. We evaluate E VOV ULN on five vulnerability types against static analysis [11], rule-based [2], deep learning-based [12], fine-tuning-based [5, 13], zero-shot LLMs [14, 15], and coding agent baselines [16, 17]. E VOV ULN achieves a macro-average F1-score of 71%, substantially outperforming all baselines. Notably, even when utilizing the lightweight GPT-5-nano as the detector, a model significantly weaker than GPT-5.2, E VOV ULN outperforms GPT-5.2 zero-shot by 19 percentage points, demonstrating that structured procedural knowledge combined with controlled execution can compensate for model capability gaps. Furthermore, the evolved rules are highly portable: transferring them to Qwen3.5-9B and MiniMaxM2.5 without any retraining yields macro F1-score of 66% and 67% respectively, both substantially above GPT-5.2 zeroshot (52%), confirming that the knowledge itself rather than the underlying model drives the performance gains. The total API cost for evolving rules across all five vulnerability types is under $50, and the evolution process is one-time: once a rule converges, it can be deployed directly without repeating the training process. In summary, this paper makes the following contributions: • We reformulate smart contract logic vulnerability detection as a procedural knowledge generation and evolution problem, and propose E VOV ULN, an automated framework that generates and refines detection procedures through a semantic lifecycle. • We introduce an IoC execution architecture, Runtime. By compiling procedural knowledge into Executable Policies, we decouple deterministic control flow from LLM semantic reasoning, ensuring faithful execution and providing dense diagnostic telemetry. • We propose a highly data-efficient, dual-phase evolution mechanism: Cold Start validates initial knowledge via synthesized corner cases, while Few-Shot Evolving performs abductive semantic debugging using minimal realworld examples. • We demonstrate that E VOV ULN outperforms nine baselines, showing that evolved procedural knowledge enables lightweight models to surpass top-tier LLMs used in zeroshot mode.

_calculateShares improperly applies a ceiling operation during deposits: if the division yields a remainder, it grants an extra share (_product / _pseudo + 1). An attacker can exploit this asymmetric rounding by inflating the pool’s assets (the denominator) via a direct donation, and then executing calculated micro-deposits to repeatedly trigger this remainder condition. This artificially inflates their share balance at negligible cost, ultimately enabling them to drain the protocol’s liquidity. However, when an LLM attempts to detect this vulnerability, the process can fail in two distinct ways, mapping directly to our identified risks: Risk 1: The generated knowledge may be flawed or insufficient. As shown in Figure 1 (red box, left), an AI-generated method can easily miss critical domainspecific patterns. While it checks generic rules (e.g., division before multiplication), it completely overlooks the specific rounding mechanism required for safe pool deposits. Consequently, when GPT-5-nano [15] applies this method, it reports the contract as safe. This results in a false negative (FN) caused entirely by the knowledge gap, despite the model’s correct reasoning over the provided rules. Risk 2: The LLM may fail to strictly adhere to the detection knowledge. Even when provided with a correct, comprehensive method (Figure 1, blue box, bottom right), LLMs frequently struggle to execute multi-step logic faithfully [2]. Given the correct method, GPT-5nano skips required intermediate checks and reverts to its internal priors, yielding another FN. Since an LLM’s internal beliefs often override its own explicitly prompted reasoning, such as chain-of-thought [18] or symbolic chain-of-thought [19], relying on the model’s autonomous execution is inherently unreliable [20]. This necessitates a more deterministic execution mechanism beyond the model’s own reasoning. Together, these two risks reveal a fundamental challenge: if the generated knowledge is flawed or insufficient, even faithful execution produces wrong results; and if the LLM does not faithfully follow the knowledge, even correct knowledge leads to wrong results. Neither problem can mask the other, and both must be solved simultaneously for reliable detection. To overcome these risks and build a robust, controllable, and accurate vulnerability detection method, there are three key challenges to be addressed. The severe scarcity of labeled data inherently dictates the first challenge (C1). Furthermore, as demonstrated by Risk 2, reliable detection demands that the LLM faithfully execute the provided logic rather than reverting to its unpredictable prior biases, driving the second challenge (C2). Finally, to circumvent the manual rule engineering bottleneck and the pitfalls of statically generated, flawed methods (Risk 1), the system must be capable of dynamically generating and evolving its detection knowledge, leading to the third challenge (C3).

II. BACKGROUND & M OTIVATION As highlighted in § I, LLM-based contract vulnerability detection encounters three bottlenecks: the severe data scarcity that hinders fine-tuning, the unreliability of LLM-generated rules, and the reasoning drift of agents during execution. To concretely illustrate why simply prompting an LLM fails to overcome these bottlenecks, consider a real-world smart contract snippet with an exploitable precision loss vulnerability (Figure 1, top right in the black box). Specifically,

2

Is division ever performed before multiplication? Are all token decimals accounted for and normalized? Are oracle prices scaled to match token precision? Do cumulative rounding errors favor the protocol over users (or vice versa)? Are there dust amounts that accumulate and become unclaimable? Is WAD (1e18) or RAY (1e27) math used consistently (like MakerDAO's style)?

pragma solidity =0.8.23; abstract contract MainHelper is WiseLowLevelHelper { function _calculateShares( uint256 _product, uint256 _pseudo, bool _maxSharePrice) private pure returns (uint256) { return _maxSharePrice == true ? _product % _pseudo == 0 ? _product / _pseudo : _product / _pseudo + 1 : _product / _pseudo; } } Vulnerable Sample

Please use the given knowledge to find out whether there is a bug in the given code.

… If there is a rounding mechanism in a pool, the rounding for deposit and withdraw should be treated properly to avoid drain of liquidity. ... <a very long knowledge>

Knowledge: … Code: … GPT-5-nano: No. None of the item in the checklist matched.

AI Generated Method (Do not cover the bug)

Runtime (§ III-B) addresses C2 (Logical Adherence) by exploiting the core capability dichotomy of modern LLMs: while they exhibit exceptional localized semantic comprehension (e.g., parsing the intent of a specific smart contract function), they notoriously struggle with long-horizon, rigid logical adherence [2]. It introduces a strict Inversion of Control (IoC) mechanism. Instead of treating code generation as a disposable reasoning trace (as seen in Program-of-Thought), E VOV ULN compiles each detection rule into an Executable Policy (EP), a deterministic programmatic detection plan executed in a sandboxed environment. The EP serves as a deterministic controller that strictly enforces the structural control flow of the detection process. Whenever localized semantic reasoning is required, the EP issues queries to the LLM via tightly-scoped Semantic Primitives. This architectural design decouples the rigid execution path from the probabilistic reasoning, relying on the runtime for structural adherence while utilizing the LLM solely as an on-demand semantic oracle. The execution environment simultaneously logs every reasoning step as a trace, transforming a binary wrong-prediction signal into a precise diagnosis. Operating alongside the Runtime is the Result Review & Knowledge Update mechanism (§ III-C): triggered by any detection error, this independent component consumes the execution trace to identify the exact logical failure and revise the rule accordingly, essentially functioning as an automated semantic debugger. Cold Start (§ III-D) addresses C3 (Automated Extensibility) by bootstrapping a validated initial detection rule for a new vulnerability type without labeled contracts. E VOV ULN instead elicits an initial rule from the LLM’s pretraining security knowledge and stress-tests it against LLM-synthesized corner cases, all without any labeled data. This phase effectively acts as a semantic fuzzing process, producing a validated starting rule before a single real-world contract is seen. Few-Shot Evolving (§ III-E) addresses C1 (Data Efficiency) by iteratively refining the detection rule based on real-world contract feedback. E VOV ULN applies the rule to real-world contracts and revises it based on execution feedback, requiring only a few labeled samples per vulnerability type and no parameter updates. Crucially, this phase incorporates strict regression bounds, mirroring CI pipelines in software development.

Please use the given knowledge to find out whether there is a bug in the given code. Knowledge: … Code: … GPT-5-nano: No… There is a rounding mechanism, and it should be safe for deposit and withdraw …

Correct Knowledge (Cover the bug but failed to follow)

Fig. 1: A precision issue vulnerability analyzed with two detection methods. Red Box in the left: An AI-generated method with insufficient coverage leads GPT-5-nano to a FN. Blue Box in the bottom right: A correct method is provided, but GPT-5-nano fails to follow it, also producing a FN. III. E VOV ULN E VOV ULN frames vulnerability detection not merely as an inference task, but as an automated lifecycle management process for procedural detection knowledge. Rather than updating model parameters or relying on disposable reasoning traces, E VOV ULN represents detection expertise as a structured natural-language rule (a step-by-step procedure that instructs a detector how to identify a vulnerability in a smart contract) and automatically generates and refines this rule with only a few labeled samples, entirely eliminating the need for manual rule engineering. To achieve this, E VOV ULN employs two LLMs with distinct roles: a supervisor that analyzes detection errors and updates the rule, and a detector that applies the current rule to target contracts to produce verdicts. This decoupling allows the supervisor to be a capable but expensive model used only during training, while the detector can be a lightweight model deployed at inference time.

B. Runtime A. Pipeline Overview

A natural-language detection rule captures vulnerability patterns in general, contract-agnostic terms. Applying it to a specific contract requires instantiating those semantic conditions against concrete functions and variables. The Runtime handles this by compiling the rule into an EP that traverses the target contract’s structure and poses the rule’s semantic questions in the context of specific code elements. This keeps the detection knowledge portable across contracts. Furthermore, enforcing a strict IoC, where verdicts are derived deterministically from the EP’s execution logic rather than from unconstrained LLM generation, prevents the detector from reverting to its prior biases, directly addressing Risk 2 in § II.

The architecture of E VOV ULN is conceptually inspired by software engineering practices such as continuous integration (CI) and regression testing, mapped onto the semantic space of LLM reasoning. While it shares conceptual similarities with the reinforcement learning, E VOV ULN operates entirely in the semantic space: the detection rule in natural language acts as the policy, detection errors on labeled contracts serve as the reward signals, and rule revisions serve as the policy updates. Throughout this process, no model parameters are modified. This design yields three components, each targeting one of the challenges identified in § II (as shown in Figure 2):

3

Training Set (10 samples)

Vulnerable Contracts

Training Stage 1: Cold Start (§3.4)

No LLM

Vulnerability Type

Detection Method Generation

Corner Case Testing

FP & FN Check

Updated Detection Method Vulnerability Description

Safe Contracts

Weak LLM

Strong LLM

Review Module

Detect Module

Result Review & Knowledge Update (§3.3) Vulnerability Description

Knowledge Compression

Error Analysis Agent

Fixed Knowledge

Regression Testing

Root Cause Analysis

Status During Detection

Findings

Detection on Training Set

Error Collection

Executable Policy Generator

Executable Policy Executor

Training Stage 2: Few Shot Evolving (§3.5)

Detection (§3.2)

Fig. 2: An overview of E VOV ULN. 1

2 3 4 5 6 7 8

9

10 11 12 13

14

execution interface between the deterministic controller and the LLM semantic oracle: Focus (line 6). This primitive narrows the analysis context to a specific contract or function by passing its source text to the Runtime. Subsequent semantic queries are evaluated against this focused snippet, with the full contract available as background context. Seen (lines 8–9). This primitive poses a natural-language question about the currently focused code to an LLM, receiving a boolean answer. Crucially, all semantic evaluations must route exclusively through this primitive. The EP is prohibited from using string matching, regular expressions, or any syntactic pattern lookup. This constraint keeps the detection logic at the semantic level described by the rule, and makes every reasoning step attributable to a specific natural-language question rather than to syntactic heuristics. Emit (lines 12–13). When the sequence of boolean responses satisfies the rule’s vulnerability conditions, this function triggers a finding. It explicitly records the vulnerability type, the precise location, and a descriptive justification. Execution Constraints & Logging. To ensure reliability, the EP executes under strict runtime constraints. First, each semantic query is issued as a stateless, independent request, ensuring the outcome is determined solely by the rule’s logic rather than accumulated conversational context or prior attention-window hallucinations. Second, the Runtime maintains an exhaustive log of the code snippets, semantic questions, boolean answers, logical branches, and emitted findings. This transforms opaque failures into structured traces for precise diagnosis, serving as the primary artifact for the Result Review & Knowledge Update mechanism (§ III-C) when an error occurs.

# Simplified Executable Policy for price ,→ manipulation. # `runtime` is injected by the Runtime. code = """A code snippet to be detected.""" def main(): # Focus on a code region (e.g., a function). runtime.focus("{a function}") # Pose semantic queries to the LLM. has_balance_based_price = runtime.seen("Does the ,→ code calculate prices by third party ,→ balance?") has_twap = runtime.seen("Does the code calculate ,→ prices by time-weighted average price ,→ (TWAP)?") # Check conditions and emit findings. if has_balance_based_price and not has_twap: runtime.emit(runtime.Finding( type="Price Manipulation", description="The contract calculates price based on ,→ ,→ balance without TWAP, which is vulnerable to price manipulation ,→ attack.")) ,→ main()

Fig. 3: An example of an Executable Policy. EP Generation & Execution. Given a detection rule and a target contract, the LLM generates an EP (Figure 3) that iterates over the contract’s functions, instantiates the rule’s semantic checks against specific code elements, and emits findings when the conditions are met. Crucially, our EP differs from prior code-as-reasoning paradigms: unlike Program-ofThought (PoT) [21], which has the LLM author a disposable program that fully determines the computation, or symbolic chain-of-thought [19], which generates a symbolic representation and then lets the LLM simulate the reasoning over it, our EP employs a hybrid execution model. It interleaves deterministic programmatic control flow with on-demand LLM semantic queries. Rather than replacing the LLM, the EP acts as a structural manager that dictates exactly when and what to ask the LLM, keeping the semantic reasoning strictly bound to the prescribed logic. Runtime Primitives. To operationalize the semantic-toconcrete translation within the generated EP, the Runtime exposes three pre-defined primitives that serve as the strict

C. Result Review & Knowledge Update The Result Review & Knowledge Update mechanism is shared by both Cold Start and Few-Shot Evolving. In contrast to naive trial-and-error approaches where a wrong prediction yields a sparse, binary failure signal, E VOV ULN leverages the hybrid execution model to perform semantic debugging. The structured execution trace produced by the Runtime provides

4

dense, step-level feedback, allowing the supervisor to attribute the failure to a specific reasoning step and revise only the relevant part of the rule. The mechanism operates through a three-step automated lifecycle.

D. Cold Start Cold Start produces a validated, robust baseline detection rule before the system observes a single labeled contract. If the rule were initialized directly from the LLM’s intrinsic latent knowledge and passed straight to Few-Shot Evolving, the small number of labeled examples would bear the entire burden of shaping the rule. This risks severe overfitting, where the rule memorizes the idiosyncrasies of specific training contracts rather than capturing the underlying vulnerability invariants. Cold Start mitigates this vulnerability by first eliciting a broad initial heuristic (Knowledge Initialization), and subsequently subjecting it to an iterative self-testing loop using auto-generated corner cases (Corner Case-Based Evolving). This ensures the policy enters the empirical grounding phase with broad coverage and structural generality, providing a validated initial state that substantially shortens the subsequent optimization compared to starting from scratch. 1) Knowledge Initialization: Knowledge Initialization elicits an initial detection rule through a two-round dialogue. The LLM is first instructed to reason freely about the vulnerability, constrained to express detection knowledge exclusively as statically observable source-code patterns (structural properties, statement ordering, and the presence or absence of modifiers and function calls), since E VOV ULN operates as a sourcecode-level detector and cannot reference runtime behaviors, transaction sequences, or off-chain conditions. Free-form reasoning precedes structured extraction, following the insight from chain-of-thought prompting [22–25] that forcing immediate structured output suppresses the intermediate reasoning steps that improve output quality. A follow-up turn then extracts the detection rule as a self-contained description, which is persisted as the starting point for corner case refinement. 2) Corner Case-Based Evolving: With an initial rule in hand, E VOV ULN refines it through an iterative self-testing loop driven by two LLM roles: a reviewer that reads the current rule and generates synthetic Solidity corner cases to challenge its logic, and a detector that applies the rule to those contracts and reports findings. The loop exploits the reviewer’s ability to reason about the rule’s weaknesses and construct targeted contracts that expose them, entirely within the LLM’s own reasoning space. The rule must pass both an FN probe and an False Positive (FP) probe before advancing to Few-Shot Evolving; failure on either triggers another round of corner case generation and rule revision via the Result Review mechanism. FN probe. To expose potential FNs in unseen contracts, the reviewer executes four steps: (1) identify which vulnerability patterns the rule would miss and why, without generating any code; (2) synthesize a single Solidity contract containing a genuine vulnerability that exploits the identified gap; (3) produce a plain-English explanation of why the contract is vulnerable, serving as an oracle independent of the detection rule’s perspective; (4) run the detector on the synthesized contract and, if the expected FN materializes, record the gap description and invoke Result Review to revise the rule to

Step 1: Root cause analysis. Upon encountering an error, the mechanism analyzes the full diagnostic context: the current detection rule, the generated EP, the contract source code, and the step-by-step trace of semantic queries and boolean answers. By contrasting the ground truth against the detector’s actual execution path, it identifies the precise logical gap, either an omission of a necessary check or a misclassification of a benign pattern as vulnerable. To ensure high-precision localization, contextual anchors are dynamically injected depending on the error source. When the error originates from the Corner Case-Based Evolving stage, the known gap description produced during corner case generation is provided to prevent spurious explanations (§ III-D). When the error occurs on a real vulnerable contract during Few-Shot Evolving, the corresponding attack event report is injected, supplying the supervisor with a ground-truth description of the practical exploitation mechanics (§ III-E). Step 2: Knowledge update. Based on the root cause analysis, the detection rule is revised to address the identified flaw. To maintain the structural integrity of the procedural knowledge, E VOV ULN enforces a full-rewrite discipline rather than incremental, localized edits. The supervisor must generate a complete, coherent rule that incorporates the specific patch while perfectly preserving the unaffected logic from the previous version. This strict requirement prevents the classic failure modes of automated patching: inserting isolated clauses often breaks the logical flow of the rule, and blind semantic merging can silently corrupt previously verified checks without triggering immediate awareness. Step 3: Knowledge compression. Each update round risks introducing redundancy, as new clauses addressing edge cases accumulate alongside older, overlapping rules. To prevent this accumulation of technical debt, E VOV ULN executes a mandatory refactoring step after every update. This process distills the rule into a compact, non-redundant state, merging overlapping conditions and eliminating verbosity while strictly preserving the logical boundaries of the detection behavior. This guarantees that the resulting EPs remain structurally concise, preventing execution complexity from scaling with update rounds and maintaining inference stability. Batch update. When multiple errors occur within a single evaluation epoch, applying fixes sequentially often leads to oscillating updates where fixing one edge case introduces a regression in another. To ensure monotonic improvement, E VOV ULN aggregates the root cause analyses for all errors and computes a global, batch-resolved update. This CI-inspired conflict resolution ensures that every iteration produces a globally coherent, regression-free advancement of the detection knowledge, stabilizing the evolution process.

5

cover the newly exposed case. FP probe. The FP probe is structurally symmetric: the reviewer judges whether the rule would produce FPs on safe contracts, identifies which patterns would be incorrectly flagged or over-fitted, synthesizes one such safe contract, explains why it is benign, runs detection and triggers a rule revision if errors exist. Context compression. Each iteration accumulates generated Solidity code and multi-step reasoning in the agent’s dialogue history. To prevent context-window exhaustion and avoid redebating already-resolved gaps, E VOV ULN replaces the full message history at the end of every iteration with a concise lessons-learned summary that preserves awareness of which gaps have been identified and resolved while discarding verbatim code that is no longer needed. The Cold Start module outputs a corner case-validated rule that has passed both the FN and FP probes on LLMsynthesized contracts. This rule is subsequently handed to the Few-Shot Evolving module, which anchors it to real-world labeled contracts.

the candidate rule is discarded and the previous version is retained. This monotonicity guarantee ensures that each epoch either improves the rule or leaves it unchanged, preventing knowledge drift over successive updates. After this stage, the detection rule has been validated against real-world contracts rather than purely LLM-synthesized ones, mitigating the risk that the rule reflects the model’s internal assumptions rather than patterns actually observed in practice. Why few labeled examples suffice. A natural critique of any few-shot approach is whether such a minimal dataset can yield statistically meaningful generalizations. In traditional deep learning or parameter fine-tuning, learning from a handful of samples is intractable because the model must inductively extract underlying features from sparse, binary labels. E VOV ULN fundamentally bypasses this limitation by shifting the paradigm from inductive learning to abductive semantic debugging, leveraging two key principles: (1) Pre-trained Semantic Abstraction. LLMs enter this stage already possessing vast, pre-trained latent representations of security audits, vulnerabilities, and code semantics. Thus, the few-shot examples are not used to teach the LLM what a vulnerability is from scratch. Instead, they act as specific examples that help the model match its general knowledge to real-world cases [26–29]. (2) High Information Density via Execution Traces. More importantly, E VOV ULN extracts orders of magnitude more information from a single failed sample than traditional methods. When a prediction fails, E VOV ULN does not merely return a binary “incorrect” signal; it yields a dense, stepby-step execution telemetry trace. Just as a human software engineer does not require thousands of failed test cases to fix a logical bug, a single failing test case with a clear stack trace is sufficient for fault localization, the supervisor LLM utilizes this dense trace to pinpoint the exact logical misstep. This mechanistic transparency allows a single labeled sample to drive a deterministic, highly targeted patch to the rule, rendering massive datasets unnecessary.

E. Few-Shot Evolving Despite surviving synthetic corner-case validation, the Cold Start rule is validated purely against synthetic distributions. It may still lack awareness of complex, multi-contract interactions or emergent exploit patterns unique to real-world deployments. While traditional paradigms attempt to bridge this gap via parameter fine-tuning, such approaches are highly datahungry and impractical given the severe scarcity of labeled on-chain exploits. Few-Shot Evolving resolves this by acting as an empirical grounding pipeline. It aligns the rule with real-world architectural patterns through targeted semantic revisions, requiring only a minimal set of labeled examples without modifying any underlying neural weights. Iterative CI/CD Lifecycle. Given the labeled training set, E VOV ULN refines the rule over multiple epochs, each consisting of three phases. Phase 1: Detection & Evaluation. E VOV ULN uses the Runtime with an LLM for detection on all labeled contracts using the current rule, classifying each outcome as a true positive, true negative, false positive, or false negative. If no errors are found, E VOV ULN terminates early: the rule has converged on the current training set. Phase 2: Error Analysis and Unified Knowledge Update. Each detected error is analyzed in an independent session by the Result Review mechanism (§ III-C), using the current rule, the generated detection plan, the contract source, and the full execution trace. Once all analyses are complete, E VOV ULN consolidates the root cause analyses and applies a single batch update to the rule, preventing the common failure mode where fixing one error in isolation introduces a regression on another. Compression is applied after the update. Phase 3: Regression Check. Before accepting the updated rule, E VOV ULN re-runs the Runtime on all contracts that produced errors in Phase 1. The update is accepted only if the number of remaining errors is strictly fewer than before; otherwise

IV. E VALUATION In this section, we evaluate E VOV ULN on five prevalent vulnerability types, covering both traditional vulnerabilities and logic bugs: Price Manipulation, Access Control, Insufficient Validation, Precision Issues, and Reentrancy. We aim to answer the following research questions (RQs): RQ1: Effectiveness of E VOV ULN. How effective is E VOV ULN in detecting real-world vulnerabilities across different types, and how does it compare to state-of-the-art baselines? RQ2: Generalizability Across Models. How is the performance of E VOV ULN affected by the model, and how does the performance change with different LLMs used in detectors? RQ3: Ablation Study. How does each component of E VOV ULN contribute to its overall performance? RQ4: Cost Analysis. How is the cost of E VOV ULN in terms of token cost during training and inference?

6

TABLE I: The composition of vulnerability types versus benign samples within the dataset. Vulnerability Type

# Samples

Price Manipulation Access Control Insufficient Validation

47 33 41

Total

Vulnerability Type Precision Issues Reentrancy Non-Vulnerable

combines fine-tuning with an LLM agent to produce detections with justifications. (iii) Zero-shot LLMs: GPT-5.2 [14] (E VOV ULN’s supervising model) and GPT-5-nano [15] (its student model), without any training or evolving. (iv) Coding agents: Claude Code [16] (Claude Opus 4.8) and Codex [17] (GPT-5.5), each prompted to detect the five vulnerability types. 4) Training: For training, we split the dataset into a training set and a testing set. For training set, each vulnerability type contains only 5 vulnerable samples and 5 safe samples, which are used for the Cold Start stage and the Few-Shot Evolving stage. In the Few-Shot Evolving stage, we set the number of iterations to 5.

# Samples 11 27 50 209

A. Evaluation Setup The dataset, model selection, baselines, and training configuration used across all research questions are described below. 1) Dataset: In the evaluation, two datasets are used: (1) vulnerabilities collected from DeFiHackLab’s collection of attack events [1] , and (2) safe contracts collected from verified contracts on Etherscan. Both datasets have been used by previous works [2]. Since DeFiHackLab’s collection of attack events is updated continuously, we manually collected a snapshot from the website. We applied the following criteria to filter the collected data: (1) the vulnerability type must be clearly labeled (e.g., price manipulation), excluding ambiguous categories such as “logic flaw”; (2) each vulnerability type must have at least 10 samples, with 5 reserved for training and 5 for testing; (3) the source code of the vulnerable contract must be publicly available, as a number of attack events in the collection do not include verifiable on-chain source code; (4) vulnerability type labels follow the original classification provided by DeFiHackLabs without further merging or splitting. For the safe contract dataset, we are using the Top200 dataset from Sun et al. [2] and we randomly sample 50 of them for evaluation. Table I shows the details of the dataset. 2) Model Selection: In the evaluation, we are using GPT5.2 as the supervising model for the training process, including both the Cold Start and Few-Shot Evolving stages. For the student model used for detection, we are using a smaller and cheaper model, GPT-5-nano, to demonstrate the costeffectiveness of E VOV ULN. In RQ2, we will also evaluate the performance of E VOV ULN with different LLMs used in the detector, including Qwen3.5-9B [30] and MiniMax-M2.5 [31]. All of these models are provided by OpenRouter [32], with parameters set to default to avoid any bias in the evaluation. 3) Baselines: We compare E VOV ULN against four families of baselines. No single existing tool matches E VOV ULN’s coverage, so each baseline is evaluated only on the vulnerability types it supports. (i) Static analysis: Slither [11], which detects only reentrancy and access control. (ii) LLM/DLbased detectors: GPTScan [2], a rule-based LLM method covering price manipulation, precision issues, insufficient validation, and access control (but not reentrancy); since its manually crafted rules only partially cover each type, we run it with both the paper’s GPT-3.5-turbo and a GPT5-nano variant (GPTScan (5-nano)). MANDO-GURU [12], a graph-neural-network approach supporting access control, precision issues, and reentrancy. SAEL [13], a fine-tuningbased Mixture-of-Experts method supporting only reentrancy, used via the authors’ artifact with its full original training data (vs. five labeled samples for E VOV ULN). iAudit [5], which

B. RQ1: Effectiveness of E VOV ULN In this RQ, we evaluate the effectiveness of E VOV ULN in detecting vulnerabilities in smart contracts, and compare it with the baselines and zero-shot performance of LLMs. Table II shows the detection results across all vulnerability types and methods, reporting the precision, recall and F1-score for each method. One baseline warrants a note on scoring. Because iAudit emits a vulnerability type rather than a plain binary verdict, we score it consistently with E VOV ULN’s pertype evaluation: a detection counts as a true positive only if iAudit both flags the contract and assigns the correct type; a vulnerable contract that is missed or labeled with the wrong type is a false negative; and any safe contract flagged as vulnerable (of any type) is a false positive. This typeaware criterion is, if anything, stricter than a purely binary vulnerable-vs-safe one, under which E VOV ULN’s margin over iAudit would only widen. E VOV ULN achieves a macro-average F1-score of 71%, outperforming all baselines by a substantial margin: Slither (4%), GPTScan (16%), MANDO-GURU (24%), iAudit (33%), GPT-5-nano zero-shot (48%), GPT-5.2 zero-shot (52%), the coding agents Claude Code and Codex (57% each), and SAEL (62% on reentrancy only). A notable characteristic of E VOV ULN is its high recall (81%) at a reasonable precision (66%), indicating it successfully identifies the majority of vulnerable contracts while keeping FPs at an acceptable level. Static analysis and deep-learning detectors. Slither and MANDO-GURU both reason over structural code properties and represent opposite failure modes. Slither (macro F1score=4%) is confined to syntactic patterns: it cannot detect logic-level vulnerabilities such as price manipulation, insufficient validation, and precision issues, and even on its supported types it suffers from both FPs and FNs on realworld contracts. MANDO-GURU (macro F1-score=24% over its three supported types) instead over-detects, reaching 100% recall but only 22% precision on access control and reentrancy by flagging most contracts as vulnerable, and 0% on precision issues. It also produced tool errors on many contracts (64/83 access control, 44/77 reentrancy, 44/61 precision issues) due to unsupported newer Solidity compilers and multi-contract projects; we excluded these, which is the most favorable treatment for MANDO-GURU, since counting them as missed

7

TABLE II: Detection results across vulnerability types and methods (all values in %). Vuln. Type Method

Our Method & Ablations Prec. Rec.

F1.

Method

Prec.

Rec.

Baselines F1. Method

Prec.

Rec.

F1.

Price Manip.

E VOV ULN E VOV ULN (Qwen3.5-9B) E VOV ULN (MiniMax-M2.5) E VOV ULN w/o Evolving E VOV ULN w/o Runtime

82 79 76 53 100

88 81 83 76 19

85 80 79 63 32

Slither GPTScan (3.5) GPTScan (5-nano) GPT-5.2 (0-shot) GPT-5-nano (0-shot)

Not Supported 94 36 52 88 36 51 100 62 76 83 57 67

MANDO-GURU iAudit SAEL Claude Code (Opus 4.8) Codex (GPT-5.5)

Not Supported 32 50 39 Not Supported 100 64 78 100 50 67

Access Control

E VOV ULN E VOV ULN (Qwen3.5-9B) E VOV ULN (MiniMax-M2.5) E VOV ULN w/o Evolving E VOV ULN w/o Runtime

57 55 61 43 73

93 93 87 82 68

70 69 72 57 70

Slither GPTScan (3.5) GPTScan (5-nano) GPT-5.2 (0-shot) GPT-5-nano (0-shot)

0 0 0 81 76

0 0 0 69 65

MANDO-GURU (-64)1 iAudit SAEL Claude Code (Opus 4.8) Codex (GPT-5.5)

22 100 36 31 71 43 Not Supported 59 79 68 84 57 68

Insuff. Validation

E VOV ULN E VOV ULN (Qwen3.5-9B) E VOV ULN (MiniMax-M2.5) E VOV ULN w/o Evolving E VOV ULN w/o Runtime

68 66 63 44 70

78 70 72 83 67

73 68 67 58 69

Slither GPTScan (3.5) GPTScan (5-nano) GPT-5.2 (0-shot) GPT-5-nano (0-shot)

Not Supported 100 6 11 100 3 5 72 64 68 53 57 50

MANDO-GURU iAudit SAEL Claude Code (Opus 4.8) Codex (GPT-5.5)

Not Supported 42 89 57 Not Supported 60 75 67 47 72 57

Precision Issues

E VOV ULN E VOV ULN (Qwen3.5-9B) E VOV ULN (MiniMax-M2.5) E VOV ULN w/o Evolving E VOV ULN w/o Runtime

40 50 60 9 0

67 33 50 33 0

50 40 55 14 0

Slither GPTScan (3.5) GPTScan (5-nano) GPT-5.2 (0-shot) GPT-5-nano (0-shot)

Not Supported 0 0 0 0 0 0 0 0

0 0 0 0

MANDO-GURU (-44) iAudit SAEL Claude Code (Opus 4.8) Codex (GPT-5.5)

0 0 0 0 0 0 Not Supported 0 0 0 20 17 18

Reentrancy

E VOV ULN E VOV ULN (Qwen3.5-9B) E VOV ULN (MiniMax-M2.5) E VOV ULN w/o Evolving E VOV ULN w/o Runtime

81 79 66 36 86

77 67 63 41 64

79 74 64 38 74

Slither GPTScan (3.5) GPTScan (5-nano) GPT-5.2 (0-shot) GPT-5-nano (0-shot)

17 5 7 Not Supported Not Supported 100 32 48 63 55 59

MANDO-GURU (-44) iAudit SAEL Claude Code (Opus 4.8) Codex (GPT-5.5)

22 17 53 87 100

100 41 73 59 59

36 24 62 70 74

Macro Avg.

E VOV ULN E VOV ULN (Qwen3.5-9B) E VOV ULN (MiniMax-M2.5) E VOV ULN w/o Evolving E VOV ULN w/o Runtime

66 66 65 37 66

81 69 71 63 44

71 66 67 46 49

Slither GPTScan (3.5) GPTScan (5-nano) GPT-5.2 (0-shot) GPT-5-nano (0-shot)

8 48 47 71 55

MANDO-GURU iAudit SAEL Claude Code (Opus 4.8) Codex (GPT-5.5)

15 24 53 61 70

67 50 73 55 51

24 33 62 57 57

0 0 0 60 57

2 10 10 44 45

4 16 14 52 48

1 (-N) after MANDO-GURU denotes the N contracts on which it encountered a tool error (timeout, or unsupported newer Solidity compiler / multi-contract

project) and produced no output; these contracts are excluded from its precision/recall computation (64 of 83 for access control, 44 of 77 for reentrancy, and 44 of 61 for precision issues).

detections would only lower its recall further. Even so, it trails E VOV ULN by a wide margin. Rule-based and fine-tuning detectors. GPTScan, SAEL, and iAudit encode detection knowledge through manually crafted rules or supervised training, yet all fall well short of E VOV ULN. GPTScan (macro F1-score=16%) exhibits a striking precision-recall imbalance (48% precision, 10% recall): its hand-crafted rules cover only a subset of each type’s patterns and miss most vulnerable contracts. Notably, where its rules are relatively complete, such as price manipulation, it attains 94% precision even with a weak GPT-3.5-turbo backend, confirming that well-crafted procedural knowledge with a structured checking procedure is highly effective, which is precisely what E VOV ULN constructs automatically. The two fine-tuning-based methods remain weaker than E VOV ULN despite far larger training data: SAEL reaches F1-score=62% on reentrancy, its only supported type, using its full original training set, whereas E VOV ULN attains 79% using only five vulnerable examples. iAudit (macro F1-score=33%) overdetects, flagging nearly every contract as vulnerable, which yields low precision (17–42%) and F1-scores of 39%, 43%, 57%, and 24% on price manipulation, access control, insufficient validation, and reentrancy, and 0% on precision issues, trailing E VOV ULN on every evaluated type under the typeaware scoring described above. Zero-shot LLMs. The zero-shot baselines achieve macroaverage F1-scores of 52% (GPT-5.2) and 48% (GPT-5-nano), performing reasonably on well-documented types such as price

manipulation and access control, but failing on precision issues (F1-score=0% for both). E VOV ULN improves macro F1-score by 19% over GPT-5.2 and 23% over GPT-5-nano, demonstrating that the knowledge evolution process adds substantial value beyond the LLM’s intrinsic capabilities. Coding agents. We further compare against two generalpurpose coding agents, Claude Code (Opus 4.8) and Codex (GPT-5.5), which can autonomously inspect contract code over multiple steps. Both reach a macro-average F1-score of 57%, clearly above the zero-shot LLMs (48–52%) owing to their agentic code-inspection ability, yet still well short of E VOV ULN’s 71%. This gap is informative: even capable agentic systems, when applied directly, plateau because they lack reusable, vulnerability-specific detection knowledge. E VOV ULN’s advantage therefore stems from its knowledgeevolution mechanism rather than from the raw capability of LLM-based agents, and cannot be obtained simply by deploying a stronger general-purpose agent. Looking at individual vulnerability types, E VOV ULN achieves the highest F1-score across all five types, including clear margins on price manipulation (85%) and reentrancy (79%). On insufficient validation (F1-score=73%), E VOV ULN improves over the best zero-shot baseline (GPT-5.2, F1score=68%) and far exceeds GPTScan (F1-score=11%). On precision issues (F1-score=50%), E VOV ULN far outperforms every other method: only Codex achieves any non-zero result (18%), while all remaining methods score F1-score=0%, indicating that this vulnerability type requires specialized

8

detection knowledge that cannot be derived from general pretraining alone. On access control, E VOV ULN achieves F1score=70% with notably high recall (93%), surpassing GPT5.2 (F1-score=69%) while both Slither and GPTScan score F1-score=0% on this type. Detecting access control flaws is challenging as it requires interpreting developer intent, but E VOV ULN achieves effective results. Crucially, E VOV ULN’s detector uses the lightweight GPT5-nano rather than GPT-5.2. Despite this capacity gap, E VOV ULN achieves a 71% macro F1-score, significantly outperforming GPT-5.2’s 52% in zero-shot settings. This 19point lead shows that a structured execution framework can overcome raw model limitations, allowing a small, efficient model to outperform a much larger, unaided LLM.

of two key components that can be independently ablated: the evolving process and the Runtime-based detector. To evaluate the contribution of the evolving process, we remove both the Corner Case-Based Self-Testing stage and the FewShot Evolving stage, using only the initial detection method produced by Knowledge Initialization, denoted as E VOV ULN w/o Evolving. To evaluate the contribution of the Runtimebased detector, we note that the Runtime’s execution trace is a prerequisite for the training process, as it provides the structured feedback used by the Result Review and Knowledge Update module. Therefore, E VOV ULN w/o Runtime is trained using the full system, and the Runtime is removed only at inference time, where it is replaced with a direct prompting approach that asks the LLM to classify each contract as vulnerable or not given the detection rule. The results are shown in Table II. Removing the evolving process (E VOV ULN w/o Evolving) reduces macro-average F1-score from 71% to 46%, a drop of 25 percentage points. The degradation is primarily in precision, which falls from 66% to 37%, while recall remains relatively high at 63%. This reflects the inherent limitations of the LLM’s built-in security knowledge: without iterative refinement through corner case testing and real-world labeled contracts, the initial rule captures many vulnerable patterns but also incorrectly flags a large number of safe contracts. Continuous evolving is therefore essential for correcting the gaps and biases in the LLM’s prior knowledge and aligning the detection rule with actual contract behavior. The drop is most pronounced on reentrancy (F1-score: 79% → 38%) and precision issues (F1-score: 50% → 14%), vulnerability types whose real-world manifestations diverge most from the LLM’s intrinsic assumptions. Removing the Runtime-based detector (E VOV ULN w/o Runtime) reduces macro-average F1-score from 71% to 49%, a drop of 22 percentage points. This ablation reveals three complementary findings. First, without enforced execution, the LLM cannot reliably follow the detection rule, instead falling back on its own generation patterns. Second, the behavior resembles a zero-shot detector: recall drops from 81% to 44% while precision remains at 66%, confirming that the model effectively ignores the evolved rule and reverts to zeroshot-style logic. Third, despite the absence of the Runtime, E VOV ULN w/o Runtime achieves higher precision than GPT-5nano zero-shot (66% vs. 55%), demonstrating that the evolved knowledge retains value: it shifts the LLM’s prior toward more accurate detection patterns compared to a zero-shot prompt. Together, the two ablations confirm that both components make essential and complementary contributions: the evolving process refines the detection knowledge to match real-world patterns, while the Runtime ensures the knowledge is faithfully and systematically applied at inference time.

C. RQ2: Generalizability Across Models In this RQ, we evaluate whether the detection knowledge evolved by E VOV ULN can generalize to detector models other than the default GPT-5-nano. After training with GPT-5.2 as the supervisor and GPT-5-nano as the detector, the resulting detection knowledge is transferred without modification to two alternative open-weight models: Qwen3.5-9B and MiniMaxM2.5. The results are shown in Table II. Note that due to intermittent instability of the OpenRouter API, including request timeouts and empty responses, 4 contracts were not evaluated for Qwen3.5-9B and 6 for MiniMax-M2.5; these samples are excluded from the reported metrics. Both models achieve competitive results across all five vulnerability types. E VOV ULN (Qwen3.5-9B) achieves a macroaverage F1-score of 66%, and E VOV ULN (MiniMax-M2.5) achieves 67%, both substantially outperforming static analysis tools (Slither: 4%), deep learning baselines (MANDO-GURU: 24%), and LLM-based methods (GPTScan: 16%), without any re-training or knowledge modification. This demonstrates that the evolved detection knowledge is not overfit to a specific model’s behavior and can be applied to different LLMs with reasonable effectiveness. The performance gap between these models and E VOV ULN with GPT-5-nano (71%) is likely because the detection knowledge is evolved using GPT-5-nano as the detector, so the knowledge refinement process is implicitly guided by GPT5-nano’s behavior and response patterns; some descriptions or phrasings in the knowledge may therefore be better suited to GPT-5-nano than to other models, leading to a modest performance gap when transferred. Notably, MiniMaxM2.5 achieves F1-score=55% on precision issues, which is higher than most baselines including GPT-5.2 zero-shot (F1score=0%), further confirming that the evolved knowledge provides substantial signal even when used with a different model. Overall, the evolved knowledge generalizes across open-weight LLMs and lets them surpass the much larger GPT-5.2 in zero-shot mode (52%) without any retraining.

E. RQ4: Cost Analysis

D. RQ3: Ablation Study

In RQ4, we evaluate the economic cost of E VOV ULN. The time cost is not discussed here since it is highly dependent on throughput and latency of the underlying LLMs, which

In this RQ, we evaluate the contribution of each component of E VOV ULN to its overall performance. E VOV ULN consists

9

TABLE III: Token cost by vulnerability type and phase. Vulnerable Type

Phase

Input (K)

detect these vulnerabilities on their own. This substantial performance gap confirms that E VOV ULN’s gains stem from its synthesized procedural knowledge rather than mere memorization of leaked samples. Finally, regarding generalizability: E VOV ULN evaluates Solidity contracts across five DeFi vulnerability types. While it cannot zero-shot detect entirely novel, undocumented vulnerabilities, its extensibility lies in bootstrapping effective detection for new types using minimal samples without manual engineering. Extending evaluation to cross-contract reasoning or other languages (like Vyper or Move) is currently infeasible due to data scarcity but remains a natural future direction. We have open-sourced our artifacts to facilitate such extensions.

Output (K)

Sup.

Det.

Sup.

Det.

Price Manipulation

Train Infer

567 –∗

64,551 59,123

100 –

5,570 4,444

Access Control

Train Infer

715 –

98,897 98,244

116 –

5,950 5,459

Insuff. Validation

Train Infer

604 –

44,367 81,733

99 –

5,437 5,985

Precision Issues

Train Infer

442 –

227,416 55,518

57 –

6,234 2,738

Reentrancy

Train Infer

339 –

106,623 32,017

71 –

7,064 2,839

Train 2,667 541,854 443 30,255 Infer – 306,615 – 21,465 ∗ Supervisor is not involved during inference; its token cost is marked as –. Total

VI. R ELATED W ORKS

can vary significantly across different models and deployment settings, and may not be directly comparable. For token cost, we calculate the average number of tokens used in the prompts during training and inference, divided by vulnerability type, and calculate the average token cost per thousand line of code (KLOC) for both training and inference. Table III details the costs for the supervisor (Sup.) and detector (Det.). Overall, the economic cost of E VOV ULN is low and practical for real-world adoption. Training for five vulnerability types consumes 2.67M/443K input/output tokens for the supervisor (GPT-5.2) and 541.85M/30.25M for the detector (GPT-5-nano). At official OpenAI rates (assuming no cache hits), the total training cost is $50.06 ($10.87 for the supervisor; $39.19 for the detector). The inference phase, which utilizes only the detector to process 359 contracts (134 + 45 × 5), involves 306.62M input and 21.47M output tokens, resulting in a low maximum cost of $23.70.

Smart Contract Vulnerability Detection. Traditional static analysis [11, 33–37] and specialized vulnerability detectors [38–54] struggle with complex logic bugs due to their reliance on rigid predefined rules. To capture complex semantics, deep learning (DL) approaches [12, 55, 56] utilize neural representations but require massive labeled datasets that are inherently scarce in this domain. E VOV ULN bypasses both bottlenecks by evolving procedural knowledge from minimal samples, achieving generalized detection of logic bugs independent of rigid rules or data-hungry training. LLM for Code and Security Analysis. Recent works have applied LLMs to smart contract security via prompt engineering [57, 58], advanced fine-tuning architectures (e.g., SmartLLaMA-DPO [59], SAEL [13]), or hybrid integrations with static tools (e.g., GPTScan [2], NumScout [60], Ma et al. [5]). However, fine-tuned models remain static post-training, and hybrid methods inherit the rigidity of their underlying static analyzers. Unlike these approaches, E VOV ULN operates independently of legacy static tools and treats detection logic as an evolvable policy, continuously adapting to intricate logic vulnerabilities over time. Agentic Reasoning and Self-Refinement. Within the LLM agent community, self-refinement paradigms [61, 62] iteratively improve per-instance outputs based on LLM selfevaluation. Similarly, Program-of-Thoughts (PoT) [21] has the LLM author a disposable program that produces the answer, while symbolic chain-of-thought [19] generates a symbolic representation the LLM then simulates. In both, the LLM determines the entire computation in one shot, and the resulting reasoning is neither recorded as an auditable trace nor reused. E VOV ULN departs from these one-shot paradigms in two dimensions. First, rather than handing the whole task to the LLM, E VOV ULN executes each rule in a controlled, fully-logged environment that invokes the LLM only for localized semantic judgments (strict IoC), so every reasoning step is auditable. Second, this trace is not discarded but serves as dense, ground-truth feedback for a persistent loop that refines reusable procedural knowledge, rather than relying on hallucination-prone self-assessment.

V. T HREATS TO VALIDITY Internal validity. The supervisor’s root-cause analysis may occasionally misattribute trace errors, risking rule updates that fix one issue but introduce another. We mitigate this through strict epoch-level regression checks, which reject updates that cause net performance degradation. Construct validity. The Few-Shot Evolving stage uses exactly five vulnerable and five safe samples per vulnerability type. To prevent selection bias, these are randomly drawn rather than hand-picked. A systematic analysis of how sample quantity and quality impact the evolved rules remains future work. External validity. First, regarding dataset scale: our evaluation totals 209 samples across five vulnerability types. While “Precision Issues” contains only 11 samples (leaving a statistically limited 6-sample test set), the other four categories feature substantially larger test sets that demonstrate consistent efficacy. This overall scale aligns with field norms for logicbug evaluation (e.g., GPTScan [2], PropertyGPT [3]), which are fundamentally constrained by the intrinsic scarcity of verifiable exploits with public source code. Second, regarding potential data leakage: historical exploits may exist in the LLMs’ pre-training data. However, highly capable zero-shot baselines (e.g., GPT-5.2) fail to reliably

10

VII. C ONCLUSION

[16] Anthropic, “Claude code,” https://www.anthropic.com/claude-code, 2025. [17] OpenAI, “Codex,” https://openai.com/codex/, 2025. [18] J. Wei, X. Wang, D. Schuurmans, M. Bosma, F. Xia, E. Chi, Q. V. Le, D. Zhou et al., “Chain-of-thought prompting elicits reasoning in large language models,” Advances in neural information processing systems, vol. 35, pp. 24 824–24 837, 2022. [19] J. Xu, H. Fei, L. Pan, Q. Liu, M.-L. Lee, and W. Hsu, “Faithful logical reasoning via symbolic chain-of-thought,” in Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (ACL), 2024. [20] S. Boppana, A. Ma, M. Loeffler, R. Sarfati, E. Bigelow, A. Geiger, O. Lewis, and J. Merullo, “Reasoning theater: Disentangling model beliefs from chain-of-thought,” 2026. [Online]. Available: https: //arxiv.org/abs/2603.05488 [21] W. Chen, X. Ma, X. Wang, and W. W. Cohen, “Program of thoughts prompting: Disentangling computation from reasoning for numerical reasoning tasks,” Transactions on Machine Learning Research, 2023. [22] Y. Nong, M. Aldeen, L. Cheng, H. Hu, F. Chen, and H. Cai, “Chain-ofthought prompting of large language models for discovering and fixing software vulnerabilities,” arXiv preprint arXiv:2402.17230, 2024. [23] R. Xu, Z. Qi, and W. Xu, “Preemptive answer “attacks” on chain-ofthought reasoning,” in Findings of the Association for Computational Linguistics: ACL 2024, 2024, pp. 14 708–14 726. [24] Y. Huang, Y. Chen, J. Cai, J. Wu, X. Chen, P. Shen, and L. Yun, “Towards combining chain-of-thought and code static analysis for buffer overflow vulnerability detection,” Software Quality Journal, vol. 34, no. 1, p. 2, 2026. [25] Q. Mao, Z. Li, X. Hu, K. Liu, X. Xia, and J. Sun, “Towards explainable vulnerability detection with large language models,” IEEE Transactions on Software Engineering, 2025. [26] X. Zhou, T. Zhang, and D. Lo, “Large language model for vulnerability detection: Emerging results and future directions,” in Proceedings of the 2024 ACM/IEEE 44th International Conference on Software Engineering: New Ideas and Emerging Results, 2024, pp. 47–51. [27] A. Shahriar, S. J. Hisham, K. A. Rahman, M. R. Islam, M. S. Hossain, R.-H. Hwang, and Y.-D. Lin, “5gpt: 5g vulnerability detection by combining zero-shot capabilities of gpt-4 with domain aware strategies through prompt engineering,” IEEE Transactions on Information Forensics and Security, 2025. [28] H. Pearce, B. Tan, B. Ahmad, R. Karri, and B. Dolan-Gavitt, “Examining zero-shot vulnerability repair with large language models,” in 2023 IEEE symposium on security and privacy (SP). IEEE, 2023, pp. 2339–2356. [29] Y. Yang, S. Yao, J. Chen, and W. Lee, “Hybrid language processor fuzzing via llm-based constraint solving,” in 34th USENIX Security Symposium (USENIX Security 25), 2025, pp. 6299–6318. [30] Qwen Team, “Qwen3.5: Towards native multimodal agents,” February 2026. [Online]. Available: https://qwen.ai/blog?id=qwen3.5 [31] M. AI, “Minimax m2.5 sota in coding and agent, designed for agent universe,” https://www.minimax.io/models/text, 2026. [32] “The unified interface for llms,” https://openrouter.ai/, 2026. [33] “Mythril,” https://github.com/Consensys/mythril, 2026. [34] P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Buenzli, and M. Vechev, “Securify: Practical security analysis of smart contracts,” in Proceedings of the 2018 ACM SIGSAC conference on computer and communications security (CCS). New York, NY, USA: ACM, 2018, pp. 67–82. [35] C. F. Torres, J. Schütte, and R. State, “Osiris: Hunting for integer bugs in ethereum smart contracts,” in Proceedings of the 2018 34th annual computer security applications conference (ACSAC). New York, NY, USA: ACM, 2018, pp. 664–676. [36] M. Mossberg, F. Manzano, E. Hennenfent, A. Groce, G. Grieco, J. Feist, T. Brunson, and A. Dinaburg, “Manticore: A user-friendly symbolic execution framework for binaries and smart contracts,” in Proceedings of the 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). New York, NY, USA: IEEE, 2019, pp. 1186–1189. [37] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contracts smarter,” in Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, 2016, pp. 254–269. [38] Z. Wang, J. Chen, Y. Wang, Y. Zhang, W. Zhang, and Z. Zheng, “Efficiently detecting reentrancy vulnerabilities in complex smart contracts,” vol. 1. [Online]. Available: https://doi.org/10.1145/3643734

We presented E VOV ULN, an automated framework that reformulates smart contract vulnerability detection from a static inference task into a procedural knowledge evolution problem. Evaluations across five real-world vulnerability types show that E VOV ULN achieves a 71% macro F1-score, substantially outperforming static analysis, deep learning-based, LLM-based methods, zero-shot LLM, and code agent baselines. Most notably, the evolved rules are portable: they enable lightweight, low-cost models to surpass much larger models. With ablations confirming the contribution of each component and a one-time evolution cost under $50, E VOV ULN offers a practical, model-agnostic approach to smart contract vulnerability detection. R EFERENCES [1] “Defi hacks analysis - root cause analysis,” https://web3sec.notion.site/ c582b99cd7a84be48d972ca2126a2a1f, 2026. [2] 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 46th international conference on software engineering, 2024, pp. 1–13. [3] 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 Network and Distributed System Security Symposium (NDSS), 2025. [4] H. Ding, Y. Liu, X. Piao, H. Song, and Z. Ji, “Smartguard: An llmenhanced framework for smart contract vulnerability detection,” Expert Systems with Applications, vol. 269, p. 126479, 2025. [5] 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 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE, 2025, pp. 1742– 1754. [6] W. Jie, W. Qiu, H. Yang, M. Guo, X. Huang, T. Lei, Q. Zhang, H. Zheng, and Z. Zheng, “Agent4vul: multimodal llm agents for smart contract vulnerability detection,” Science China Information Sciences, vol. 68, no. 6, p. 160101, 2025. [7] S. J. Wang, K. Pei, and J. Yang, “Smartinv: Multimodal learning for smart contract invariant inference,” in 2024 IEEE Symposium on Security and Privacy (SP). IEEE, 2024, pp. 2217–2235. [8] Z. Wang, S. Zhao, Y. Wang, H. Huang, S. Xie, Y. Zhang, J. Shi, Z. Wang, H. Li, and J. Yan, “Re-task: Revisiting llm tasks from capability, skill, and knowledge perspectives,” in Findings of the Association for Computational Linguistics: ACL 2025, 2025, pp. 4925–4936. [9] Y. Jiang, D. Li, H. Deng, B. Ma, X. Wang, Q. Wang, and G. Yu, “Sok: Agentic skills–beyond tool use in llm agents,” arXiv preprint arXiv:2602.20867, 2026. [10] T. Schick, J. Dwivedi-Yu, R. Dessı̀, R. Raileanu, M. Lomeli, E. Hambro, L. Zettlemoyer, N. Cancedda, and T. Scialom, “Toolformer: Language models can teach themselves to use tools,” Advances in neural information processing systems, vol. 36, pp. 68 539–68 551, 2023. [11] J. Feist, G. Grieco, and A. Groce, “Slither: a static analysis framework for smart contracts,” in Proceedings of the 2019 2nd IEEE/ACM international workshop on emerging trends in software engineering for blockchain (WETSEB). New York, NY, USA: IEEE, 2019, pp. 8–15. [12] H. H. Nguyen, N.-M. Nguyen, H.-P. Doan, Z. Ahmadi, T.-N. Doan, and L. Jiang, “Mando-guru: vulnerability detection for smart contract source code by heterogeneous graph embeddings,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2022, pp. 1736–1740. [13] 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 2025 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2025, pp. 61–72. [14] “Gpt-5.2,” https://developers.openai.com/api/docs/models/gpt-5.2, 2026. [15] “Gpt-5 nano,” https://developers.openai.com/api/docs/models/ gpt-5-nano, 2026.

11

[39] Y. Xue, M. Ma, Y. Lin, Y. Sui, J. Ye, and T. Peng, “Cross-contract static analysis for detecting practical reentrancy vulnerabilities in smart contracts,” in Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering, ser. Ase ’20. Association for Computing Machinery, pp. 1029–1040. [Online]. Available: https://doi-org.remotexs.ntu.edu.sg/10.1145/3324884.3416553 [40] Z. Zheng, N. Zhang, J. Su, Z. Zhong, M. Ye, and J. Chen, “Turn the rudder: A beacon of reentrancy detection for smart contracts on ethereum,” in Proceedings of the 45th International Conference on Software Engineering, ser. Icse ’23. IEEE Press, pp. 295–306. [Online]. Available: https://doi.org/10.1109/ICSE48619.2023.00036 [41] J. Ye, M. Ma, Y. Lin, Y. Sui, and Y. Xue, “Clairvoyance: Crosscontract static analysis for detecting practical reentrancy vulnerabilities in smart contracts,” in Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Companion Proceedings, 2020, pp. 274–275. [42] Z. Zhang, Y. Lei, M. Yan, Y. Yu, J. Chen, S. Wang, and X. Mao, “Reentrancy vulnerability detection and localization: A deep learning based two-phase approach,” in Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, 2022, pp. 1–13. [43] C. Liu, H. Liu, Z. Cao, Z. Chen, B. Chen, and B. Roscoe, “Reguard: finding reentrancy bugs in smart contracts,” in Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings, ser. ICSE ’18. New York, NY, USA: Association for Computing Machinery, 2018, p. 65–68. [Online]. Available: https://doi.org/10.1145/3183440.3183495 [44] Q. Song, H. Huang, X. Jia, Y. Xie, and J. Cao, “Silence false alarms: Identifying anti-reentrancy patterns on ethereum to refine smart contract reentrancy detection,” in NDSS, 2025. [45] P. Bose, D. Das, Y. Chen, Y. Feng, C. Kruegel, and G. Vigna, “SAILFISH: Vetting smart contract state-inconsistency bugs in seconds,” in 2022 IEEE Symposium on Security and Privacy (SP), pp. 161–178. [46] A. Ghaleb, J. Rubin, and K. Pattabiraman, “Achecker: Statically detecting smart contract access control vulnerabilities,” in Proceedings of the 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), Melbourne, Australia, May 2023, p. 945–956. [47] Y. Fang, D. Wu, X. Yi, S. Wang, Y. Chen, M. Chen, Y. Liu, and L. Jiang, “Beyond “protected” and “private”: An empirical security analysis of custom function modifiers in smart contracts,” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, New York, NY, USA, 2023, p. 1157–1168. [48] Y. Liu, Y. Li, S.-W. Lin, and C. Artho, “Finding permission bugs in smart contracts with role mining,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2022. New York, NY, USA: Association for Computing Machinery, 2022, p. 716–727. [49] Z. Zhong, Z. Zheng, H.-N. Dai, Q. Xue, J. Chen, and Y. Nan, “Prettysmart: Detecting permission re-delegation vulnerability for token behaviors in smart contracts,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, ser. ICSE ’24. New York, NY, USA: Association for Computing Machinery, 2024. [50] H. Lin, Z. Gao, J. Chen, X. Chen, X. Yang, and L. Bao, “Actaint: Agentbased taint analysis for access control vulnerabilities in smart contracts,” in Proceedings of the 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). New York, NY, USA: IEEE, 2025, pp. 2555–2567. [51] H. Liu, D. Wu, Y. Sun, S. Wang, Y. Liu, and Y. Chen, “Have We Solved Access Control Vulnerability Detection in Smart Contracts? A Benchmark Study,” in Proceedings of the 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). New York, NY, USA: IEEE, 2025, pp. 1995–2007. [52] Q. Kong, J. Chen, Y. Wang, Z. Jiang, and Z. Zheng, “Defitainter: Detecting price manipulation vulnerabilities in defi protocols,” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2023, pp. 1144–1156. [53] S. Wu, Z. Yu, D. Wang, Y. Zhou, L. Wu, H. Wang, and X. Yuan, “Defiranger: Detecting defi price manipulation attacks,” IEEE Transactions on Dependable and Secure Computing, vol. 21, no. 4, pp. 4147–4161, 2023. [54] Y. Mo, J. Chen, Y. Wang, and Z. Zheng, “Toward automated detecting unanticipated price feed in smart contract,” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2023, pp. 1257–1268.

[55] W. Li, X. Li, Z. Li, and Y. Zhang, “Cobra: interaction-aware bytecodelevel vulnerability detector for smart contracts,” in Proceedings of the 39th IEEE/ACM international conference on automated software engineering, 2024, pp. 1358–1369. [56] X. Li, A. Bhattacharjya, Q. Li, M. Zhou, R. Wisniewski, and G. Bazydło, “A novel method for vulnerability detection based on fusion and hyperbolic neural network graphs,” IEEE Transactions on Software Engineering, 2026. [57] C. Chen, J. Su, J. Chen, Y. Wang, T. Bi, J. Yu, Y. Wang, X. Lin, T. Chen, and Z. Zheng, “When chatgpt meets smart contract vulnerability detection: How far are we?” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 4, pp. 1–30, 2025. [58] 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. [59] L. Yu, Z. Huang, H. Yuan, S. Cheng, L. Yang, F. Zhang, C. Shen, J. Ma, J. Zhang, J. Lu et al., “Smart-llama-dpo: Reinforced large language model for explainable smart contract vulnerability detection,” Proceedings of the ACM on Software Engineering, vol. 2, no. ISSTA, pp. 182–205, 2025. [60] J. Chen, Z. Shao, S. Yang, Y. Shen, Y. Wang, T. Chen, Z. Shan, and Z. Zheng, “Numscout: Unveiling numerical defects in smart contracts using llm-pruning symbolic execution,” IEEE Transactions on Software Engineering, 2025. [61] A. Madaan, N. Tandon, P. Gupta, S. Hallinan, L. Gao, S. Wiegreffe, U. Alon, N. Dziri, S. Prabhumoye, Y. Yang et al., “Self-refine: Iterative refinement with self-feedback,” Advances in neural information processing systems, vol. 36, pp. 46 534–46 594, 2023. [62] N. Shinn, F. Cassano, A. Gopinath, K. Narasimhan, and S. Yao, “Reflexion: Language agents with verbal reinforcement learning,” Advances in neural information processing systems, vol. 36, pp. 8634–8652, 2023.

12