An evidence-gated two-stage malicious intent detection method and system for smart contracts

Abstract

The present application relates to the technical field of smart contract security audit, code semantic representation and large language model reasoning, and discloses a two-stage malicious intent detection method and system for smart contract with evidence gating. In view of the problems that the existing method lacks verifiable evidence, the pure large model audit cost is high, and illusion false positives are prone to occur, a multi-label intent detection model of the first stage is used to output a multi-label intent probability, and uncertainty routing is performed based on a category threshold, a confidence gray area and a static trigger signal; then, the contract-intent pair routed is used to extract intent focus code slices, an intent semantic prompt template is constructed, and a multi-path reasoning of a semantic reasoning model of the second stage is driven; subsequently, source code verification, evidence gating, self-consistent voting and fusion output are performed on the returned code evidence. The method can be used for on-chain contract audit, real-time risk control and token issuance monitoring.

Description

Technical Field

[0001] This invention relates to the fields of smart contract security auditing, code semantic representation, deep learning multi-label classification, large language model reasoning, and source code evidence verification, and particularly to a two-stage method and system for detecting malicious intent in smart contracts with evidence gating. Background Technology

[0002] With the development of blockchain and decentralized applications, smart contracts have become an important carrier for on-chain asset transfer and business logic execution. Besides traditional vulnerabilities such as reentrancy and integer overflow, malicious intent deliberately implanted by developers can also lead to serious asset risks. Examples include arbitrarily modifying transaction fees, centrally closing transactions, blacklisting user addresses, unlimited issuance, honeypot-style restrictions on selling, and manipulation of dividends or elastic supply. Such malicious intent is often hidden in contracts in the form of business parameters, permission modifiers, whitelists, or transfer logic, making accurate identification difficult solely through rule matching.

[0003] Existing deep learning-based smart contract intent detection methods can typically classify large-scale contracts with high throughput, but their outputs are mostly probability values ​​or labels, lacking code-level evidence for auditors to review. In scenarios where on-chain data is highly imbalanced in categories, rare malicious intents are easily missed, while some compliant business logic may be falsely reported as malicious backdoors.

[0004] Large language models possess strong capabilities in code semantic understanding and natural language interpretation, but directly performing full-scale large-scale model audits on massive amounts of smart contracts incurs significant computational costs and latency. Furthermore, single-generation large language models may produce illusions, meaning the output code evidence may not actually exist in the original source code. Therefore, a technical solution is needed that can utilize deep learning models for low-cost initial screening, leverage large language models for interpretable verification of uncertain samples, and perform source code verification and gating on the large model evidence. Summary of the Invention

[0005] The purpose of this invention is to provide a two-stage method and system for detecting malicious intent in smart contracts with evidence gating, in order to solve the problems in the prior art where deep learning detection results lack interpretable evidence, pure large language model detection is costly and has hallucinatory false positives, and rare malicious intents are difficult to recall stably.

[0006] To achieve the above objectives, this invention provides the following technical solution: The code of the smart contract to be detected is acquired, and after performing a function-level semantic representation, it is input into a first-stage multi-label intent detection model, which outputs the predicted probabilities of multiple malicious intent categories; an uncertainty-aware routing plan is constructed based on category calibration thresholds, confidence gray zones, rare intent static trigger signals, and high-confidence positive verification conditions; for the routed "contract-intent" pairs, intent-focused code slices are extracted, and an intent semantic prompt template containing intent definitions, false positive exemption boundaries, few-sample examples, and structured output constraints is constructed; a second-stage large language model is invoked for multi-path sampling and inference; the output code evidence is verified for source code verifiability, and positive conclusions without valid evidence are gated; finally, a detection report is generated through self-consistent voting, evidence aggregation, and fusion rules.

[0007] Compared with existing technologies, this invention has at least the following beneficial effects: First, by combining high-throughput deep learning initial screening with high-interpretability large language model verification through an uncertainty-aware routing mechanism, the cost of the second-stage call is reduced; Second, by using intent-focused code slices and intent semantic prompt templates, the large language model focuses on analyzing state variables, permission entry points, data flow destinations, control flow destinations, and security exemption boundaries; Third, by using source code verifiable evidence gating, positive judgments must be supported by locatable code fragments in the original source code, thereby reducing false positives caused by large language model illusions; Fourth, by using multi-path sampling, self-consistent voting, and consensus evidence aggregation, the verification stability of complex samples and rare intents is improved, and traceable code-level evidence is provided to auditors. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of the overall process of the smart contract malicious intent detection method provided in the embodiments of the present invention.

[0009] Figure 2 This is a schematic diagram of the structure of a two-stage evidence-gated detection system provided in an embodiment of the present invention.

[0010] Figure 3 This is a schematic diagram of the second-stage evidence gating, multi-path voting, and fusion determination mechanism provided in an embodiment of the present invention. Detailed Implementation

[0011] I. Overall Architecture

[0012] In one embodiment, the method is applied to an on-chain contract batch audit or real-time risk control system. The system receives the source code, decompiled pseudocode, or other intermediate representation of the smart contract to be detected, uses the contract as a sample, and uses each category of malicious intent as a label dimension to be judged, ultimately outputting multi-label detection results.

[0013] The system comprises a first-stage detection module, a thresholding and routing module, a code slicing and hint construction module, a second-stage review module, an evidence verification and voting module, and a fusion report module. The first-stage detection module is responsible for quickly outputting probability vectors; the thresholding and routing module is responsible for filtering "contract-intent" pairs that require review by the large language model; the code slicing and hint construction module is responsible for focusing the large model input on code fragments related to that intent; the second-stage review module is responsible for multi-path sampling and inference; the evidence verification and voting module is responsible for verification, gating, voting, and evidence aggregation; and the fusion report module is responsible for generating the final audit report.

[0014] II. First Stage: Function-Level Semantic Representation and Multi-Label Detection

[0015] In a preferred embodiment, the system extracts callable code blocks from the contract source code, such as functions, modifiers, constructors, fallback functions, or receive functions, and generates function-level semantic vectors using a pre-trained code language model in the smart contract domain. Each function-level semantic vector can be a 768-dimensional vector; multiple function-level semantic vectors of a contract are arranged in the order of the source code and formed into a fixed-length function sequence matrix by padding or truncation, for example, forming a function sequence with a maximum length of 256. The above values ​​are merely examples and do not constitute a limitation on the scope of protection of this invention.

[0016] The first-stage multi-label intent detection model can use a bidirectional long short-term memory network to encode the function sequence context and output predicted probability vectors for multiple preset malicious intent categories through a fully connected sigmoid output layer. To avoid label misalignment, assertion verification can be performed on the category order before training or evaluation. To alleviate class imbalance, binary focusing loss, category-weighted binary cross-entropy, or a combination thereof can be used. To ensure reproducibility, the model file, weight backup, training set sample labels, and evaluation set sample labels can be saved simultaneously.

[0017] Preset malicious intent categories can include Fee, DisableTrading, Blacklist, Reflect, MaxTX, Mint, Honeypot, Reward, Rebase, and MaxSell. The probability vector output in the first stage is not directly used as the final conclusion for all samples, but rather serves as the basis for subsequent uncertain routing and fusion decisions.

[0018] III. Category Calibration Threshold and Uncertainty-Aware Routing

[0019] In one embodiment, instead of using a uniform 0.5 threshold, the system plots precision-recall curves for each malicious intent category on the validation set and selects the threshold that optimizes the F1 score or satisfies business constraints as the category calibration threshold. For any intent category, the system determines the lower and upper bounds of the confidence gray area based on its category calibration threshold. Samples whose predicted probabilities fall within the confidence gray area are considered uncertain samples in the first stage and need to be sent to the second stage for verification.

[0020] Furthermore, the system can be configured with rare intent recall conditions. For rare or high-risk intents such as Honeypot, Rebase, MaxSell, and Mint, even if the probability in the first phase is below the positive threshold, as long as the source code hits a specific static trigger signal and the predicted probability reaches the recall lower bound, the "contract-intent" pair will be added to the routing plan. The static trigger signal can come from function names, variable names, modifiers, require conditions, or transfer logic keywords related to the intent.

[0021] The system can also selectively review high-confidence positive predictions from the first stage to correct false alarms caused by feature similarity. Candidate routing items can be sorted by priority, which takes into account gray zone distance, prediction probability, static trigger signal, and intent rarity. The system can set a maximum number of reviews for each intent category or a total call limit for the second stage to control computational costs.

[0022] IV. Intent-Focused Code Slices

[0023] To avoid inputting excessively long contracts into the second-stage large language model, the system performs intent-focused code slicing based on the current malicious intent category to be judged. Specifically, the system pre-maintains a set of keywords corresponding to each intent category. For example, the Fee category corresponds to keywords such as fee, tax, buyFee, sellFee, setFee, and isFeeExempt; the Mint category corresponds to keywords such as mint, _mint, totalSupply, maxSupply, and minter; and the DisableTrading category corresponds to keywords such as trading, enableTrading, openTrading, and tradingEnabled. The system also maintains a set of general security keywords, such as owner, onlyOwner, admin, role, timelock, DAO, multisig, require, modifier, transfer, _transfer, mapping, and balance.

[0024] The system scans and scores contract-level code blocks, function code blocks, and modifier code blocks. A code block receives a higher score if it simultaneously contains intent keywords, permission keywords, and control flow / data flow endpoints. The system prioritizes retaining code blocks with higher scores, especially those containing state variable writes, permission entry points, whitelist or blacklist modifications, transfer restrictions, balance changes, supply changes, fee calculations, or sell restrictions. When the length of a candidate code block exceeds the input limit, the system selects code blocks based on scores and coverage relationships, forming intent-focused code slices with controllable length.

[0025] V. Intent Semantic Prompt Template

[0026] In one embodiment, each malicious intent category has a corresponding intent semantic cue template. The template includes an intent definition, a false positive exemption boundary, a few-sample semantic reasoning example, structured JSON output constraints, and placeholders for the code to be analyzed. The intent definition is used to limit the current judgment to only one type of malicious intent, avoiding feature confusion between different intents; the false positive exemption boundary is used to exclude business logic such as security caps, decentralized governance, initialization locking, time locks, multi-signature, or compliance supervision.

[0027] Structured JSON output constraints can require the second-stage large language model to output fields such as `analysis_chain`, `boundary_check`, `conclusion`, and `evidences`. `analysis_chain` includes state variable or mapping analysis, access control analysis, data flow analysis, and control flow analysis; `boundary_check` describes whether a security exemption boundary has been hit; `conclusion` is a Boolean or an intent conclusion that can be parsed as a Boolean; `evidences` is an array of evidence, each piece of evidence including `entity`, `type`, `code_snippet`, and `desc`. The `code_snippet` must be extracted verbatim from the code to be analyzed and cannot be rewritten or fabricated by the large language model.

[0028] VI. Second Stage: Multi-path Reasoning

[0029] For each routed "contract-intent" pair, the system fills the intent-focused code slice into the corresponding intent semantic prompt template and performs multiple independent sampling inferences through a local or remote large language model service. Multi-path sampling allows setting parameters such as the number of samples N, temperature, top-p, maximum output length, request timeout, and number of retries. Different sampling paths may produce different analysis chains and conclusions; the system reduces the impact of randomness in a single generation through subsequent self-consistent voting.

[0030] To improve project availability, the second-phase review module supports OpenAI-compatible interfaces, local vLLM inference services, JSON response format constraints, disk caching, and failure retries. For identical prompts and model configurations, returned results can be cached using hash keys to avoid duplicate calls.

[0031] VII. The source code allows for verification of evidence and evidence gating.

[0032] The system parses the text returned in the second stage and extracts a structured JSON object. If JSON parsing fails, it may attempt to remove code block markers, extract balanced curly braces, fix trailing commas, or minimize the recovery conclusion field. For each piece of evidence obtained through parsing, the system verifies its code_snippet in the original contract code.

[0033] The source code verification can include three levels: first, a character-by-character matching is performed; if this fails, the source code is compressed and matched against whitespace characters in the evidence fragment; if this still fails, valid lines of code that meet the length requirement are selected from the evidence fragment for line-level matching. Upon successful matching, the system outputs the fragment with the actual text overlay model from the original source code, and backfills in the start line number, end line number, and matching pattern.

[0034] In a preferred embodiment, the system enables positive evidence gating: if a structured audit path concludes that "malicious intent exists," but its evidence array contains no code evidence that has passed source code verification, then this positive conclusion will not participate in positive voting, or will be marked as an invalid conclusion. This mechanism can effectively reduce false positives caused by large language models generating evidence out of thin air.

[0035] VIII. Self-consistent Voting and Evidence Aggregation

[0036] The system statistically analyzes the valid conclusions from multiple structured audit paths, obtaining the number of votes for "malicious intent exists," "malicious intent does not exist," and invalid conclusions. If the number of valid positive votes and valid negative votes are not equal, the one with the higher number of votes is used as the result of the second-stage intent review, and a confidence level is calculated. If the two are equal or there are no valid votes, the result of the second stage is uncertain.

[0037] The system also aggregates evidence. Specifically, it generates normalized evidence keys based on the entity and type of the evidence; it counts the number of times this evidence key appears in different inference paths and the number of times it passes source code verification; it selects evidence groups whose occurrence frequency reaches the consensus threshold and passes source code verification as consensus evidence, and the remaining evidence groups are considered minority suspected evidence. Consensus evidence may include code snippets, entity names, evidence types, number of supporting votes, number of source code verification votes, line numbers, and evidence descriptions.

[0038] IX. Integration Rules and Audit Report

[0039] The fusion report module combines the first-stage prediction results with the second-stage verification results. When the second-stage conclusion is positive, the confidence level reaches the preset threshold, and there is evidence of successful source code verification, the system will set the final judgment as positive; when the second-stage conclusion is negative and the confidence level reaches the preset threshold, the system can set the final judgment as negative; when the confidence level of the second-stage result is insufficient, there is a lack of source code verification evidence, parsing fails, or the source code is missing, the system retains the first-stage result.

[0040] The final output detection report may include sample identifier, contract address, intent category, first-stage probability, category threshold, routing reason, static trigger signal, second-stage voting distribution, confidence level, final judgment, fusion action, consensus evidence, suspected minority evidence, code snippets, source code line numbers, and natural language descriptions. The report can be output in JSONL, Markdown, HTML, or other formats readable by auditing systems.

[0041] 10. Examples and Variations

[0042] The first-stage multi-label intent detection model mentioned above is not limited to the combination of SmartBERT-v2 and BiLSTM, but can also be replaced by CodeBERT, GraphCodeBERT, Transformer encoder, CNN, GRU or graph neural network; the second-stage semantic reasoning model mentioned above is not limited to a specific model, and can also be deployed locally or through a cloud interface.

[0043] The aforementioned source code evidence verification is not limited to text matching; it can also be further combined with abstract syntax trees, control flow graphs, data flow graphs, call graphs, or static analysis tools for semantic-level verification. The malicious intent categories, keyword sets, gray zone parameters, recall thresholds, voting thresholds, and fusion thresholds can all be configured based on the business scenario and the performance of the verification set.

[0044] This invention can be used for offline batch auditing, as well as for on-chain real-time risk control, token issuance monitoring, decentralized exchange new pool monitoring, contract pre-launch security review, or third-party auditing platforms.

[0045] This invention can be deployed in smart contract security auditing platforms, on-chain real-time risk control systems, token issuance monitoring systems, or blockchain data analysis platforms. Through high-throughput detection in the first stage, evidence gating verification in the second stage, and fusion report output, this invention can identify malicious intent and trace the source of large-scale smart contracts with low computational cost, demonstrating good industrial applicability.

Claims

1. A two-stage method and system for detecting malicious intent in smart contracts using evidence gating, characterized in that, include: The system acquires the source code, bytecode decompilation code, or intermediate representation of the smart contract to be detected. It performs semantic representation on callable code blocks such as functions, modifiers, constructors, fallback functions, and receive functions, and inputs these representations into the first-stage multi-label intent detection model. The model outputs the predicted probability vectors of the smart contract across multiple preset malicious intent categories. It loads calibration thresholds corresponding to each malicious intent category and, based on these calibration thresholds, category confidence gray zones, rare intent recall conditions, and static trigger signals, constructs an uncertainty-aware routing plan for "contract-intent" pairs. For "contract-intent" pairs selected by the uncertainty-aware routing plan, it extracts intent-focused code slices from the original contract code based on the keyword set and general security keyword set for that intent category, and fills these intent-focused code slices into the corresponding intent semantic prompt template. The second-stage semantic reasoning model is used to perform multiple independent sampling reasoning on the same "contract-intent" pair to obtain multiple structured audit paths. Each structured audit path includes at least an analysis chain, exemption boundary check results, intent conclusion, and evidence array. The code evidence in each structured audit path is verified for source code verifiability in the original contract code. If the positive intent conclusion lacks verified code evidence, evidence gating is performed on the positive intent conclusion. Based on evidence gating, multiple structured audit paths are used for self-consistent voting and evidence aggregation to obtain the second-stage intent review results. According to the preset fusion rules, the prediction results of the first-stage multi-label intent detection model are fused with the second-stage intent review results to output a smart contract malicious intent detection report that includes intent category, final judgment, confidence level, source code location, and consensus evidence.

2. The method according to claim 1, characterized in that, The first-stage multi-label intent detection model includes a code semantic encoding module for generating semantic representations of smart contracts and a sequence feature learning module for learning the contextual relationships of multiple code blocks. The first-stage multi-label intent detection model is used to output the predicted probabilities corresponding to multiple malicious intent categories.

3. The method according to claim 1, characterized in that, The category threshold information is obtained through a validation dataset; the uncertainty information is determined based on the relationship between the prediction result and the category threshold; the static feature information includes at least one of the following: function name, variable name, modifier name, control condition, permission control structure, or transfer logic.

4. The method according to claim 1, characterized in that, The verified routing plan is constructed based on at least one or more of the following conditions: the prediction result is in an uncertain range; the prediction result meets the preset verification conditions; the source code hits a specific static feature; The target intent belongs to the high-risk intent category; And determine the "contract-intention" pairs to be reviewed based on preset priorities.

5. The method according to claim 1, characterized in that, The code snippet extraction process includes: analyzing contract-level code blocks, function-level code blocks, and modifier code blocks based on the keyword set corresponding to the target intent and the security-related keyword set; selecting code blocks that meet the relevance conditions to the target intent to form intent-focused code slices; and prioritizing the retention of code blocks related to access control, state variable modification, data flow paths, or control flow paths when the code slice length exceeds a preset limit.

6. The method according to claim 1, characterized in that, The intent analysis input includes at least: malicious intent definition information; security boundary constraint information; example reasoning information; structured output constraint information; and smart contract code information to be analyzed.

7. The method according to claim 1, characterized in that, The review results include analysis process information, boundary check results, intent determination results, and evidence set; each piece of evidence in the evidence set includes at least an evidence identifier, evidence type, code content, and evidence description.

8. The method according to claim 1, characterized in that, The source code can be verified using at least one of the following methods: text matching verification; normalized text matching verification; code structure matching verification; abstract syntax tree matching verification; control flow matching verification. Data stream matching and verification; when the verification is successful, the corresponding source code location is determined and source code location information is generated.

9. The method according to claim 1, characterized in that, The evidence gating process includes: when the verification result is positive and there is no valid evidence that can be verified through the source code, the positive result is marked as an invalid result, downgraded to an uncertain result, or prohibited from participating in positive voting; when the verification result contains at least one valid piece of evidence that can be verified through the source code, the verification result is allowed to participate in subsequent consistency analysis and final determination.

Images