Frequency-Aware Continual Learning for Smart Contract Vulnerability Detection with Large Language Models
A smart-contract vulnerability detector that keeps learning new bug types without forgetting old ones, then folds everything into one model
New categories of smart contract vulnerabilities keep emerging, but retraining a large language model from scratch every time is too costly. The researchers built a three-stage pipeline that adapts cheaply, rehearses at-risk knowledge to avoid forgetting, and merges all learned versions into a single deployable model. On the DIVE benchmark of real smart contracts, the merged model came within 2.7% of the accuracy of training separate models per task, while merging took only 156 milliseconds.
METAL MEDIA explanatory visual
A smart-contract vulnerability detector that keeps learning new bug types without forgetting old ones, then folds everything into one model
- 01Problem: deployed smart contracts can't be patched afterward, so vulnerabilities must be caught beforehand, but new attack patterns keep appearing over time; retraining the whole model each time is prohibitively expensive, and keeping separate models per vulnerability type is costly to store and run.
- 02Method 1 (FA-LoRA): keeps the large language model's core weights frozen and trains only a tiny slice of parameters (0.4% of the total), performing this lightweight adaptation in the Fourier (frequency) domain with a learnable gate that decides which frequency components matter most.
- 03Method 2 (FAR): sequential training across tasks causes 'catastrophic forgetting' of earlier knowledge, so the method tracks how much each training example's loss (prediction error) changes over time and prioritizes replaying examples that are most at risk of being forgotten.
- 04Method 3 (APPM): since separate adapters trained per task must eventually become one deployable model, this stage picks the adapter that generalizes best as a protected 'anchor,' then combines the rest through weighted averaging and lets frequency gates compete with each other during merging.
- 05Result: FA-LoRA outperformed standard LoRA and QLoRA while using only 0.4% trainable parameters; FAR reached an average Micro-F1 of 0.8022 across sequential tasks; APPM's merged model stayed within 2.7% of the independently-trained-per-task upper bound (Micro-F1 0.8085), merging in 156 milliseconds with no extra runtime memory.
What they did
- Problem: deployed smart contracts can't be patched afterward, so vulnerabilities must be caught beforehand, but new attack patterns keep appearing over time; retraining the whole model each time is prohibitively expensive, and keeping separate models per vulnerability type is costly to store and run.
- Method 1 (FA-LoRA): keeps the large language model's core weights frozen and trains only a tiny slice of parameters (0.4% of the total), performing this lightweight adaptation in the Fourier (frequency) domain with a learnable gate that decides which frequency components matter most.
- Method 2 (FAR): sequential training across tasks causes 'catastrophic forgetting' of earlier knowledge, so the method tracks how much each training example's loss (prediction error) changes over time and prioritizes replaying examples that are most at risk of being forgotten.
- Method 3 (APPM): since separate adapters trained per task must eventually become one deployable model, this stage picks the adapter that generalizes best as a protected 'anchor,' then combines the rest through weighted averaging and lets frequency gates compete with each other during merging.
- Result: FA-LoRA outperformed standard LoRA and QLoRA while using only 0.4% trainable parameters; FAR reached an average Micro-F1 of 0.8022 across sequential tasks; APPM's merged model stayed within 2.7% of the independently-trained-per-task upper bound (Micro-F1 0.8085), merging in 156 milliseconds with no extra runtime memory.


| Split | task_A | task_B | task_C | task_D |
|---|---|---|---|---|
| Train | 5,262 | 5,262 | 5,262 | 5,262 |
| Validation | 542 | 504 | 536 | 651 |
| Test | 530 | 542 | 513 | 648 |
| Total | 6,334 | 6,308 | 6,311 | 6,561 |


| Hyperparameter | Value |
|---|---|
| FA-LoRA rank r [16] | 16 |
| Frequency mode [5] | High-frequency retention |
| Retain fraction γ [5] | 0.2 |
| Optimizer [30] | AdamW |
| Learning rate (CL) [16] | 5×10−5 |
| Learning rate (PEFT) [16] | 3×10−5 |
| Batch size B [16] | 8 |
| Max sequence length | 1,024 |
| Epochs per task (CL) | 3–5 |
| Epochs (PEFT) | 3 |
| Replay buffer capacity [6] | 2,000 |
| Replay batch ratio [6] | 0.25 |
| FAR temperature τ | 2.0 |
| APPM protection ρ | 1.0 |
| Component | Params (M) | Fraction |
|---|---|---|
| Total | 1,241.0 | 100.0% |
| Frozen (LLaMA base) | 1,235.8 | 99.6% |
| Trainable (FA-LoRA) | 5.2 | 0.4% |
| — LoRA (𝑼,𝑽) | 5.0 | 0.40% |
| — Gates (𝒈) | 0.2 | 0.02% |
| Per-task storage | ∼10 MB |
| Method | Quant. | Trainable (M) | Storage (MB) | Micro-F1 | Macro-F1 | Subset Acc. | |||
|---|---|---|---|---|---|---|---|---|---|
| 1B | 3B | 1B | 3B | 1B | 3B | ||||
| WaRA [15] | ✓ | 35.77 | 136.5 | 0.8398 | 0.8515 | 0.6529 | 0.7133 | 0.5544 | 0.5840 |
| QLoRA [9] | ✓ | 1.72 | 6.6 | 0.8185 | 0.8365 | 0.6133 | 0.6407 | 0.5181 | 0.5298 |
| SLoRA [17] | ✓ | 6.85 | 26.2 | 0.8138 | 0.8305 | 0.5945 | 0.6263 | 0.4966 | 0.5262 |
| LoRA [16] | bf16 | 3.42 | 13.0 | 0.8094 | 0.8370 | 0.5613 | 0.6356 | 0.4845 | 0.5428 |
| FourierFT [13] | ✓ | 0.16 | 0.6 | 0.7449 | 0.7888 | 0.4724 | 0.5585 | 0.3471 | 0.4331 |
| FouRA [5] | ✓ | 0.55 | 2.1 | 0.7635 | 0.8020 | 0.4998 | 0.5930 | 0.4004 | 0.4648 |
| FA-LoRA | ✓ | 2.62 | 10.0 | 0.8185 | 0.8424 | 0.5904 | 0.6616 | 0.5074 | 0.5544 |
| Method | Merge (ms) | CPU Δ(MB) | Speedup | ΔInd |
|---|---|---|---|---|
| Simple-Mean | 102 | 0.0 | 70× | +5.5% |
| TIES [40] | 2,123 | 0.0 | 3.4× | +5.5% |
| DARE [44] | 4,204 | 0.0 | 1.7× | +7.9% |
| HAM g=2 | 7,164 | 68.1 | 1.0× | +11.0% |
| SFA a=0.5 | 72 | 0.0 | 100× | +33.0% |
| APPM (ours) | 156 | 0.0 | 46× | +2.7% |
| After training | task_A | task_B | task_C | task_D |
|---|---|---|---|---|
| task_A | 0.7495 | 0.6121 | 0.6331 | 0.6028 |
| task_B | 0.7253 | 0.7503 | 0.7303 | 0.7065 |
| task_C | 0.7162 | 0.7226 | 0.8974 | 0.8864 |
| task_D | 0.7128 | 0.7171 | 0.8935 | 0.8854 |
| Forgetting | −0.0367 | −0.0332 | −0.0039 | — |
Why it matters
For blockchain security teams, this means a detection model can absorb newly discovered vulnerability types cheaply and still ship as a single unified model, rather than juggling separate models or paying for full retraining. It offers a practical path for keeping up with an auditing environment where threat knowledge changes constantly.
Terms in this paper
- LoRA (Low-Rank Adaptation) · a technique that adapts a large model to a new task by training only small extra matrices instead of the whole model
- Catastrophic Forgetting · when a model loses previously learned knowledge while learning something new
- Fourier Transform · a mathematical transform that breaks data down into different frequency components
- Adapter · a small add-on module trained for a specific task while the main model stays frozen
- Micro-F1 · a metric combining precision and recall across multiple labels, used here since a contract can have several vulnerability types at once
Original abstract (English)
Smart contract vulnerability detection with Large Language Models (LLMs) faces three causally linked challenges. First, new vulnerability categories demand parameter-efficient adaptation, since full retraining is prohibitive for sequentially arriving tasks. Second, training per-task adapters on a shared backbone causes catastrophic forgetting of previously learned vulnerabilities. Third, the resulting multiplicity of adapters must be consolidated into a single model, since task identity is unknown at inference time. Each challenge arises directly from the solution to its predecessor, making an integrated framework essential. We propose a three-stage pipeline in which each stage addresses one challenge and feeds into the next. The adaptation stage uses Frequency-Aware Low-Rank Adaptation (FA-LoRA), which performs adaptation in the Fourier domain with per-frequency importance gates, requiring only 0.4% trainable parameters while outperforming standard LoRA and QLoRA. The continual learning stage applies Forget-Aware Replay (FAR), which uses these frequency gates to estimate per-sample forgetting risk via loss dynamics and prioritizes vulnerable knowledge for rehearsal, achieving an average Micro-F1 of 0.8022 across sequential tasks. The deployment stage employs Anchor-Protected Progressive Merging (APPM), which exploits the asymmetric generalization produced by FAR training to identify the strongest-generalizing adapter as an anchor and consolidates all adapters into a single model via anchor-protected weighted merging with frequency-domain gate competition. APPM achieves a Micro-F1 of 0.8085, within 2.7% of the independent per-task upper bound, at a merge cost of 156 ms and no additional runtime memory. Experiments on DIVE confirm the framework effectively addresses all three challenges for evolving blockchain ecosystems.
Read on arXivLatest papers
- SWE-bench Science: Can Coding Agents Resolve Engineering Tasks in Science?AI coding agents were tested on fixing real scientific software, and even the best one failed more than half the time
- FlashPrefill V2: Block-Sparse Prefill Attention for Long-Context LLM ServingMaking sparse attention fast enough and accurate enough for real LLM serving, not just papers
- PolicyGuide: From Guarding One Action to Guiding the Whole Workflow for Policy-Compliant LLM AgentsMaking customer-service AI agents follow the whole procedure, not just avoid one bad action
- EXIMO: VLM Guided Exploration of VLA PoliciesTeaching a robot new chores without human teleoperation, by letting a chatty AI supervise it
- EnvHarness: Awakening Static Worlds for Agent LearningInstead of building new training worlds from scratch, this work adds a plug-in layer that reshapes existing ones around each agent's actual weaknesses
- Bounded Sovereignty and the Control Tax: Pricing AI Oversight When the Deployer Does Not Own the ModelCompanies that rent AI instead of owning it can only do half of AI safety oversight
- Beyond Imitation: Filtering On-Policy Distillation by Reasoning ProgressA fix for AI models that get penalized by their teacher even when they're reasoning correctly
- PersonalBench: Measuring the Authorship Gap in LLM PersonalizationAI can be prompted to write 'like someone,' but its own voice never fully disappears
Latest from METAL MEDIA
Figures: Tenghui Huang et al., arXiv:2608.19680, arxiv-nonexclusive