Automated Vulnerability Injection in Smart Contracts Using Large Language Models

Luca Migliaccio; Roberto Natella; Naghmeh Ivaki; Nuno Laranjeiro; Marco Vieira

Source-linked AI summary

Automated Vulnerability Injection in Smart Contracts Using Large Language Models

Luca Migliaccio, Roberto Natella, Naghmeh Ivaki, Nuno Laranjeiro, Marco Vieira

arXiv:2609.02624v1Sep 2, 2026cs.SEcs.AIcs.CR

TL;DR

Evaluating smart-contract vulnerability detectors is difficult because labeled datasets with known ground truth are scarce. This paper uses LLMs to inject and validate vulnerabilities in Solidity contracts, finding that only 32 of 193 non-duplicate injections (16.58%) pass all validation steps and that analyzers provide incomplete, uneven coverage.

Problem
Evaluating vulnerability detectors is difficult because smart-contract datasets with known ground truth are scarce, despite their importance for assessing tool effectiveness.
Method
The approach uses LLMs to assess injectability and perform vulnerability injection, then validates contracts through compilation, execution, business-logic, and vulnerability checks.
Results
32 of 193 non-duplicate injected contracts (16.58%) passed every validation step, with success highest for structurally simpler contracts and localized vulnerability patterns.
Takeaways & Limitations
The validated contracts reveal that three static analyzers provide complementary but incomplete and uneven coverage of injected defects.
Takeaways & Limitations
The case study uses 14 SmartBugs contracts, so its results may not generalize to larger or more diverse contract sets.

Abstract

from arXiv · show

Assessing vulnerability detection tools for smart contracts requires datasets with known ground truth, yet such datasets are scarce and difficult to build by hand. We propose an approach that uses Large Language Models (LLMs) to automatically inject vulnerabilities into Solidity smart contracts, and demonstrate it in a case study targeting 49 vulnerability types from OpenSCV. Injected contracts are validated through a multi-step pipeline checking compilation, execution, business logic, and the presence of the intended vulnerability. Applied to real-world contracts from SmartBugs, LLMs generate nearly 1,000 candidate variants; after deduplication and validation, 32 confirmed vulnerable contracts spanning 25 vulnerability types survive (a 16.58% survival rate). Surviving contracts concentrate in structurally simpler targets and vulnerability types with localized syntactic patterns. We report practical challenges including LLMs' non-determinism and the difficulty of preserving contract semantics. We then use the validated contracts to assess three static analyzers, revealing complementary and incomplete coverage profiles. Results show that LLM-based vulnerability injection is feasible, while exposing key limitations in scalability and diversity.

I. INTRODUCTION

Smart-contract vulnerability detectors are difficult to evaluate because existing labeled datasets are scarce, small, manually curated, and limited in vulnerability coverage. This paper proposes LLM-based vulnerability injection with multi-step validation and evaluates its feasibility and usefulness for analyzing static analyzers.

Motivation: Existing smart-contract vulnerability datasets are scarce, difficult to extend, and typically small, manually curated, and limited in vulnerability types,.Reliable ground truth is needed to measure detection capabilities before deploying immutable code.
Approach: The paper proposes LLMs that identify injectable vulnerability types, perform constrained injections, and validate each resulting contract before dataset inclusion.Validation covers compilation, constraint compliance, business-logic integrity, and vulnerability correctness.
Case study: 49 vulnerability types were targeted across 14 SmartBugs contracts, producing nearly 1,000 candidate vulnerable variants for multi-step validation.The contracts span diverse application types and structural complexity profiles, and validation includes compilation, execution, business-logic preservation, and manual vulnerability confirmation.
Applications: The verified dataset enables static-analyzer assessment that reveals complementary and incomplete detection coverage profiles.This demonstrates the dataset’s usefulness for analyzing the detection capabilities of existing static analysis tools.
Findings and limitations: Only a small fraction of candidates survives the full pipeline, with business-logic preservation the least likely step and survivors concentrated in simpler contracts and localized vulnerability patterns.The introduction also identifies model non-determinism, validation bottlenecks, injection diversity, and legacy-tool limitations as practical lessons.

II. RELATED WORK … C. Relation to Our Earlier Work

Related work spans smart-contract vulnerability detection, fault-injection methods, and efforts to construct reliable vulnerable-contract datasets. This study extends earlier work by using structure-adaptive LLM injections across 49 OpenSCV types with four-step validation.

A. Vulnerability Detection in Smart Contracts: Static analysis dominates smart-contract vulnerability detection, while dynamic execution complements symbolic execution, taint analysis, and pattern-matching approaches.Vidal et al. survey more than 100 detection techniques and discuss tools including Mythril, Slither, and Oyente.
A. Vulnerability Detection in Smart Contracts: Recent studies apply LLMs to smart-contract vulnerability detection, combining language models with program analysis or evaluating detection directly from Solidity source code.Sun et al., Boi et al., and Sheng et al. examine LLM-based vulnerability detection and report competitive accuracy for certain patterns.
B. Vulnerability and Fault Injection: Fault injection research studies choices such as fault models, injection targets, and workload selection, with prior security methods targeting web applications and large-scale vulnerability data.Natella et al., Fonseca et al., and Nong et al. represent these dependability and security-oriented directions.
B. Vulnerability and Fault Injection: Existing smart-contract ground truth is inconsistent and limited, while SolidiFI and MuSe inject only selected vulnerability types using predefined mutation mechanisms.SolidiFI seeds seven types with fixed operators, whereas MuSe injects six types through mutation-based methods.
B. Vulnerability and Fault Injection: SuMo generates faulty contract variants with predefined operators, but targets generic programming mistakes for test-suite assessment rather than specific vulnerability types.This distinguishes generic fault seeding from vulnerability-oriented dataset construction.
B. Vulnerability and Fault Injection: FORGE extracts and classifies vulnerabilities from real-world audit reports, whereas this study generates flaws by construction and controls their type and placement.FORGE grounds labels in reported incidents, but those labels depend on source-report quality.
C. Relation to Our Earlier Work: Building on OpenSCV and prior evaluations, this work injects directly into contract code across 49 types and validates each result through four checks.The LLM adapts injections to each contract’s structure rather than fixed operators or AST templates, covering compilation, constraint compliance, business-logic integrity, and vulnerability correctness; Table I summarizes related approaches.

III. VULNERABILITY INJECTION APPROACH · A. Phase I – Preparation · B. Phase II – Injectability Assessment & Injection

The approach prepares vulnerability-free, representative smart contracts, assesses which OpenSCV vulnerability types are injectable, and generates deduplicated variants using LLMs. A subsequent validation phase filters these variants through compilation, execution, injection, business-logic, and vulnerability checks to produce the final verified dataset.

III. VULNERABILITY INJECTION APPROACH: The overall approach comprises preparation, assessment and injection, and validation, with the validated dataset serving as its final output.Preparation filters and diversifies targets; assessment and injection create candidate variants; validation progressively verifies them.
III. VULNERABILITY INJECTION APPROACH: Phase III progressively validates injected variants through compilation and execution, injection verification, business-logic verification, and vulnerability confirmation to produce the final dataset.Validation is the approach’s final output and is organized as four filtering steps.
A. Phase I – Preparation: Phase I selects representative real-world contracts with no tool-reported vulnerabilities, retaining diverse application types and code structures.A final SAT check confirms the absence of critical vulnerabilities, while minor issues may remain because they do not affect injection.
A. Phase I – Preparation: Phase I fixes the experimental configuration, including the assessment and injection LLMs, target vulnerability types, repeated runs per contract–vulnerability pair, and injectability-score threshold.Repeated runs account for LLM non-determinism.
B. Phase II – Injectability Assessment & Injection: Phase II identifies plausible contract–vulnerability pairs, generates vulnerable variants, and removes duplicates in three steps: assessment, injection, and deduplication.The assessment LLM evaluates whether each OpenSCV vulnerability type can realistically be introduced through appropriate modifications, while another LLM performs the constrained injection.
B. Phase II – Injectability Assessment & Injection: Injectability assessment is performed for every target contract and vulnerability type in the selected OpenSCV target set before injection.The assessment determines whether each vulnerability could plausibly be introduced through appropriate contract modifications.

A D Injection Verification

The pipeline first assesses which vulnerability types are structurally injectable, then generates constrained vulnerable variants and deduplicates repeated outputs before validation. Repeated evaluations and explicit minimal-edit rules address LLM non-determinism while limiting unrealistic candidates.

Step 1 Vulnerability Assessment: The assessment prompt returns a binary injectability decision and brief justification for every targeted vulnerability type, using explicit local-edit rules rather than chain-of-thought or few-shot examples.Few-shot prompting was impractical because all vulnerability types are assessed in one call, while explicit rules better constrain reasoning to local edits.
Step 1 Vulnerability Assessment: The assessment rules prohibit adding functions or state variables and changing pragma or inheritance, while uncertain cases default to non-injectable predictions to reduce false positives.This conservative choice accepts higher false negatives because false positives would propagate unrealistic vulnerability types into injection.
Step 1 Vulnerability Assessment: Only vulnerability types whose repeated-run injectability score exceeds a predefined threshold proceed to injection, producing a more stable estimate of compatibility with the contract’s structure and logic.The score is the percentage of repeated evaluations predicting that a vulnerability is injectable.
Step 2 Vulnerability Injection: For each eligible contract–vulnerability pair, the injection prompt directs the model to create a vulnerable variant by modifying exactly one function while preserving overall statement logic and ordering.The model must not add state variables, contracts, libraries, or functions, introduce mitigation logic, or omit the // VULN HERE marker.
Step 3 Deduplication: After multiple injection runs, whitespace-normalized textually identical outputs are removed so validation receives a compact, representative set rather than repeated copies of the same pattern.Deduplication is applied before validation to prevent repeated LLM outputs from inflating the validation workload.

C. Phase III – Validation of Injected Smart Contracts

Phase III validates injected contracts through a four-step filtering pipeline that checks structural integrity, injection correctness, preservation of business logic, and vulnerability exploitability. Contracts that pass the final confirmation step establish the ground truth used in the remainder of the paper.

Phase III – Validation of Injected Smart Contracts: The four-step validation pipeline evaluates compilation and execution, injection correctness, business-logic preservation, and final vulnerability confirmation.Results are recorded in a JSON schema capturing build status, manual validation outcomes, and static-analysis results.
Step A Compilation and Execution: Compilation and execution provide a structural integrity check by requiring successful compilation, deployment, and invocation of at least one relevant public or external function.The invocation must avoid immediate runtime errors or structural inconsistencies.
Step B Injection Verification: Manual injection verification confirms that the intended vulnerability was introduced into existing code without forbidden structural changes and remains syntactically consistent with the original.The evaluator compares the original and injected contracts’ diff against the Phase II constraints.
Step C Business Logic Verification: Business-logic verification distinguishes behavior caused directly by the targeted flaw from unintended semantic drift, requiring the original contract behavior to remain otherwise preserved.This step assesses whether the injected change alters intended behavior beyond the injected vulnerability.
Step D Vulnerability Confirmation: Final vulnerability confirmation establishes ground truth by checking that the flaw is target-consistent, semantically meaningful, reachable, and realistically exploitable.Realistic exploitability requires a technically feasible transaction sequence that triggers the flaw and benefits an attacker, with the adversarial effect derived from the vulnerability type’s OpenSCV specification.

IV. CASE STUDY: INJECTING VULNERABILITIES INTO REAL-WORLD SMART CONTRACTS · A. Phase I: Contract Selection and Experimental Setup

The case study applies the vulnerability-injection approach to real-world SmartBugs contracts, using a reproducible, resource-constrained pipeline designed to assess 49 OpenSCV vulnerability types. Phase I selects structurally diverse contracts and compatible open-source models for vulnerability assessment and injection.

IV. CASE STUDY: INJECTING VULNERABILITIES INTO REAL-WORLD SMART CONTRACTS: The case study applies the proposed approach to real-world smart contracts, covering contract selection, injection assessment, validation, and comparison of static analyzers.The study is organized into three phases and concludes by using the resulting dataset to compare SATs.
A. Phase I: Contract Selection and Experimental Setup: 2,862 contracts remained after filtering 47,398 SmartBugs sbwild contracts to those for which none of nine integrated SATs reported vulnerabilities.This filtered set formed the safe-contract pool from which the 14 study contracts were selected.
A. Phase I: Contract Selection and Experimental Setup: 14 representative contracts were selected to maximize diversity across application types, code size, control-flow complexity, functions, state variables, and external interactions.The selection metrics were normalized with min-max scaling to facilitate comparison.
A. Phase I: Contract Selection and Experimental Setup: Fig. 4 shows that the selected contracts span structural profiles ranging from minimal, low-complexity contracts to larger contracts with extensive external interactions and high control-flow complexity.The heatmap summarizes the normalized complexity metrics for all 14 contracts.
A. Phase I: Contract Selection and Experimental Setup: The experiments used a reproducible Kaggle P100 environment, excluding closed-source models because proprietary infrastructure and per-query costs limit large-scale reproducibility.The full pipeline, including code, data, and scripts, is available in the replication package.
A. Phase I: Contract Selection and Experimental Setup: Sixteen open-source models spanning 66M to 15B parameters were surveyed, with hardware-incompatible and non-code models excluded under the 16GB VRAM constraint.The surveyed models covered encoder-only, decoder-only, instruction-tuned, and code-specialized architectures and varied training data.
A. Phase I: Contract Selection and Experimental Setup: Qwen2.5-Coder was selected for assessment because it was the strongest compatible code-specialized option and the largest such model fitting the hardware constraints at 14B parameters.Its selection was based on code-analysis suitability and HumanEval and MBPP results.
A. Phase I: Contract Selection and Experimental Setup: The pipeline targeted 49 OpenSCV vulnerability types, restricting selection to types with SWC codes so injected vulnerabilities could be compared directly with recognized LLM and SAT outputs.For injection, five candidate models were evaluated on Solidity 0.8.x contracts using Integer Underflow/Overflow, whose protection must be explicitly bypassed.

B. Phase II: Assessment and Injection · 1) Step 1: Injectability Assessment:

Step 1 finds that LLM-assessed injectability is highly uneven and narrows 49 vulnerability types to 25 retained for injection. Manual validation indicates conservative, high-precision assessment, with stronger performance for localized syntactic patterns than deeper semantic or structural conditions.

1) Step 1: Injectability Assessment:: Injectability scores cluster near 0% or 100%, showing consistent predictions and distinguishing locally introducible vulnerabilities from those requiring incompatible structural changes.Figure 5 reports the resulting contract–vulnerability injectability heatmap, where only a subset of pairs is consistently judged injectable.
1) Step 1: Injectability Assessment:: 25 of the 49 initially considered vulnerability types met the 50% injectability threshold for at least one contract and were retained for injection.The retained space is constrained by target-contract structure and semantics rather than spanning the full vulnerability taxonomy.
1) Step 1: Injectability Assessment:: Injectability varies across contracts: some support many high-scoring vulnerability types, whereas structurally rigid contracts support only a limited set of plausible injections.This distribution reflects the interaction between target-contract structure and vulnerability characteristics.
1) Step 1: Injectability Assessment:: Manual validation shows that assessment errors mainly reduce coverage because the model produces relatively few false positives and more false negatives.The validation sample was stratified across vulnerability types, contracts, repeated runs, and balanced positive and negative outcomes.
B. Phase II: Assessment and Injection: Overall, the assessment phase reduces the injection search space by identifying contract–vulnerability pairs more likely to yield realistic and constraint-compliant results.The section covers injectability assessment as Step 1 before vulnerability injection and deduplication.
1) Step 1: Injectability Assessment:: 75.9% accuracy, 95.5% precision, and 73.6% recall were achieved on 108 manually validated assessment decisions, with 3 false positives and 23 false negatives.Because the sample covers 108 of 6,860 decisions (1.57%), these results are indicative rather than definitive.

2) Step 2: Vulnerability Injection: · 3) Step 3: Duplicate Removal:

The injection phase generated 997 candidate contracts, but duplicate removal reduced them to 193 unique textual variants for validation. Redundancy was widespread and uneven, indicating that contract structure and vulnerability type constrain the diversity of LLM-generated injections.

2) Step 2: Vulnerability Injection:: 997 contracts were generated by Meta-Llama-3 for vulnerability–contract pairs whose injectability scores exceeded 50%, with multiple queries per selected pair.Generation followed predefined injection constraints and was restricted to cases predicted injectable during assessment.
3) Step 3: Duplicate Removal:: Duplicate removal normalizes whitespace and retains only textually distinct variants for each contract–vulnerability pair, preventing repeated patterns from inflating validation.Duplicates are defined by textual identity after whitespace normalization.
3) Step 3: Duplicate Removal:: The 193-contract count approximates semantic rather than exact diversity because formatting differences remain distinct while identical text across different execution paths is merged.This limitation follows directly from text-based comparison after whitespace normalization.
3) Step 3: Duplicate Removal:: Duplication rates were similar across vulnerability types, showing that the model frequently converged on a small set of canonical injection patterns.Figure 10 presents the ratio of duplicates across vulnerability types.
3) Step 3: Duplicate Removal:: Contract targets with rigid logic or fewer injection points induced stronger output convergence, demonstrating that diversity depends on vulnerability type–contract structure interactions.Some targets produced substantially more duplicated generations than others.
3) Step 3: Duplicate Removal:: Distinct-injection diversity was highly uneven: only a subset of contract–vulnerability pairs produced multiple variants, while many produced none.Figure 11 shows eight readable contracts although fourteen were initially selected because six yielded zero non-duplicate injections.
3) Step 3: Duplicate Removal:: 193 unique injected contracts remained after duplicate removal, an approximately 80% reduction from 997 generated contracts, forming the input to the validation pipeline.The effective output is therefore measured by distinct, semantically meaningful variants rather than raw generations.

C. Phase III: Validation · 1) Validation Pipeline (Steps A–D):

Phase III validates 193 non-duplicate generated contracts through sequential checks of compilation, execution, injection correctness, business-logic preservation, and vulnerability validity, leaving 32 confirmed contracts with a 16.58% survival rate. The filtering shows that constraint compliance and semantic preservation are major challenges, and the survivors form the ground truth for evaluating static analyzers.

1) Validation Pipeline (Steps A–D):: 32 of 193 non-duplicate contracts survive all validation steps, yielding a final survival rate of 16.58%.The pipeline progressively filters contracts through compilation and executability, injection correctness, business-logic preservation, and final vulnerability confirmation.
1) Validation Pipeline (Steps A–D):: The largest relative reduction occurs from Step B to Step C, as survivors fall from 89 to 44 when business-logic preservation is assessed.This indicates that introducing a vulnerability while preserving intended contract behavior is especially difficult.
1) Validation Pipeline (Steps A–D):: The validation results show that LLMs can generate verified vulnerable contracts, but multiple filters are needed to distinguish formal modifications from semantically valid, exploitable vulnerabilities.The pipeline was manually executed by a single evaluator experienced in Solidity smart-contract security.
1) Validation Pipeline (Steps A–D):: Step B reduces the pool from 150 to 89 by rejecting injections that violate constraints or fail to correctly implement the intended vulnerability.This remains challenging even when Phase II predicts that a vulnerability is injectable.
1) Validation Pipeline (Steps A–D):: Step C identifies syntactically correct injections that nevertheless cause unintended semantic changes, including weakened access-control checks.The passage illustrates this with transfers permitted without sufficient funds, among other recurring failure patterns.
1) Validation Pipeline (Steps A–D):: Step D applies vulnerability-specific exploitability criteria uniformly, using each vulnerability type’s expected adversarial effect from its OpenSCV specification.Access-control weakening is only an illustration; the criterion is applied across all vulnerability types.
1) Validation Pipeline (Steps A–D):: The 32 validated contracts constitute the ground truth used to compare static analyzers.They are retained only after compilation, execution, injection, business-logic, and vulnerability-validity checks.

2) Factors Affecting Injection Survival: · D. Using the Dataset to Compare Detection Tools

The validated dataset exposes both the conditions limiting injection survival and distinct, incomplete detection profiles among three static analyzers. Simpler contracts and localized vulnerability patterns survive more often, while tool results remain indicative because of limited coverage and legacy-code failures.

2) Factors Affecting Injection Survival:: Simpler target contracts survive validation more often than complex contracts, and localized vulnerability classes survive more often than structural classes.The analysis assigns structural complexity using median splits on lines of code and cyclomatic complexity; Checking dominates, while Algorithm/Method and Assignment/Initialization show lower survival.
2) Factors Affecting Injection Survival:: High Phase II injectability does not guarantee Phase III survival because candidates may alter business logic or fail to produce semantically meaningful defects.Wrong Caller Identification (8.1.1) combines near-perfect Phase II assessment accuracy with high Phase III survival, while lower-accuracy types tend to survive less often.
2) Factors Affecting Injection Survival:: Only 32 of 193 non-duplicate injections, or 16.58%, survive the full pipeline; business-logic verification is the main bottleneck, reducing survivors from 89 to 44.Checking vulnerabilities account for 11 of the 25 types passing Phase II and achieve the highest Phase III survival rates, whereas more structural types perform worse.
D. Using the Dataset to Compare Detection Tools: Only 9 of 25 vulnerability types receive at least one confirmed detection, while 13 of 32 validated contracts are static analysis failures.Because only 19 contracts are analyzable, the comparison is qualitative and its precision and recall values are indicative rather than conclusive.
D. Using the Dataset to Compare Detection Tools: Legacy Solidity limitations account for many analysis failures, as all 13 static analysis failure contracts use versions from 0.3.x to 0.4.11, unlike analyzable contracts using 0.4.18 or later.The failing contracts also use deprecated constructs including sha3, legacy delegatecall, and callcode.
D. Using the Dataset to Compare Detection Tools: Slither achieves perfect precision with 57.9% recall, Solhint achieves 70.6% recall with false positives, and Remix falls between them.The tools have partially complementary coverage, with each detecting vulnerabilities the others miss.
D. Using the Dataset to Compare Detection Tools: Using a long-context proprietary model on three contracts yields 9 of 25 candidates, or 36%, passing all validation steps, concentrated in the same localized types favored by the smaller model.This experiment tests whether model size or context length changes the survival pattern under the same constraints and human evaluation.
D. Using the Dataset to Compare Detection Tools: Compared with SolidiFI, the LLM-based approach targets 49 OpenSCV types and is not tied to a specific compiler version, whereas SolidiFI supports seven fixed bug types and ran on only 3 of 14 contracts.SolidiFI failed compilation on the other 11 contracts because its toolchain was pinned to Solidity 0.5.12.

V. LESSONS LEARNED AND PRACTICAL IMPLICATIONS

LLM-based vulnerability injection is constrained less by compilation than by semantic preservation, contract complexity, limited output diversity, and manual validation effort. These limitations skew datasets and restrict how confidently static-analyzer coverage can be interpreted.

V. LESSONS LEARNED AND PRACTICAL IMPLICATIONS: 89 to 44 candidates survive Step C, making business-logic verification the pipeline’s largest relative bottleneck despite successful compilation and execution.The assessment phase identifies plausible contract–vulnerability pairs, but only 32 of 193 non-duplicate contracts survive all validation steps.
V. LESSONS LEARNED AND PRACTICAL IMPLICATIONS: 997 raw generations collapse to 193 distinct contracts, indicating convergent outputs, reduced dataset diversity, and diminishing returns from additional generation runs.Temperature variation, prompt perturbation, and multi-model ensembles were not explored as mitigation strategies.
V. LESSONS LEARNED AND PRACTICAL IMPLICATIONS: Higher contract complexity and external interaction reduce survival, while Checking vulnerabilities are more injectable than structural Algorithm/Method types.Complex control flow makes vulnerability insertion without side effects harder, and Checking accounts for 11 of the 25 types passing Phase II.
V. LESSONS LEARNED AND PRACTICAL IMPLICATIONS: Manual inspection in Steps B, C, and D grows with candidate volume, making validation a scalability bottleneck for larger datasets and repeated model evaluations.A single evaluator inspected all candidates in the case study; differential testing is identified as a candidate for automating business-logic checks.
V. LESSONS LEARNED AND PRACTICAL IMPLICATIONS: 13 of 32 validated contracts, or 40.6%, cannot be analyzed by any static analyzer because of legacy Solidity versions and deprecated constructs.The same failures occur on the original unmodified contracts, so they are not caused by the injected vulnerabilities.
V. LESSONS LEARNED AND PRACTICAL IMPLICATIONS: Injectability assessment should be treated as a filter with intermediate validation, because resulting datasets are skewed toward simple contracts and Checking defects.These datasets should not support tool-coverage conclusions beyond the represented defect classes and should account for static-analysis failures in real-world Ethereum code.

VI. THREATS TO VALIDITY · VII. CONCLUSION

LLM-based vulnerability injection is feasible but limited: only 32 of 193 non-duplicate contracts survived validation, while semantic preservation, model scope, and evaluation uncertainty constrain the conclusions. Future work should broaden datasets and models and automate validation to improve diversity and reduce semantic errors.

VI. THREATS TO VALIDITY: Manual inspection by a single evaluator in validation Steps B–D may introduce subjectivity because inter-rater agreement was not measured.Predefined criteria and deliberate reexamination of borderline cases mitigated, but did not eliminate, this limitation.
VI. THREATS TO VALIDITY: The injectability score is a proxy rather than formal structural analysis, producing false positives and false negatives that may cause the 25 retained types to underestimate injectable vulnerabilities.Textual deduplication after whitespace normalization can also miss semantically equivalent injections with different non-whitespace formatting.
VI. THREATS TO VALIDITY: Results may not generalize beyond 14 SmartBugs contracts or the two quantized open-source models used on constrained hardware.Closed-source models were excluded for reproducibility and because per-query costs would limit large-scale experimentation.
VI. THREATS TO VALIDITY: The reliability check covered 108 of 6,860 assessment decisions, yielding 75.9% accuracy with a 95% Wilson interval of approximately [67.3%, 83.2%].This leaves non-negligible uncertainty about whether observed accuracy holds uniformly across vulnerability types.
VI. THREATS TO VALIDITY: Thirteen static-analysis failures reduced the analyzable set from 32 to 19 contracts, so reported tool metrics should be treated as exploratory rather than definitive.Single-contract ground-truth classification differences could materially shift precision and recall.
VII. CONCLUSION: 32 of 193 non-duplicate injected contracts (16.58%) passed every validation step, with business-logic preservation the main bottleneck.Survival was highest for structurally simpler contracts and vulnerability types with localized syntactic patterns.
VII. CONCLUSION: Future work will evaluate larger, more diverse contract sets and alternative prompting and model strategies while automating validation through differential testing or semantic deduplication.The authors also identify model convergence as a diversity ceiling because additional generation runs produce little additional diversity.