BlockScan: Detecting Anomalies in Blockchain Transactions
Authors: Jiahao Yu
Xian Wu
Hao Liu
Wenbo Guo
Xinyu Xing
Venue: NeurIPS 2025 poster ()
Keywords: foundation model
blockchain transaction
Primary area: applications
TL;DR: We build a foundation model for blockchain transaction data to perform different tasks

Abstract: We propose BlockScan, a customized Transformer for anomaly detection in blockchain transactions.
Unlike existing methods that rely on rule-based systems or directly apply off-the-shelf large language models (LLMs), BlockScan introduces a series of customized designs to effectively model the unique data structure of blockchain transactions.
First, a blockchain transaction is multi-modal, containing blockchain-specific tokens, texts, and numbers.
We design a novel modularized tokenizer to handle these multi-modal inputs, balancing the information across different modalities.
Second, we design a customized masked language modeling mechanism for pretraining the Transformer architecture, incorporating RoPE embedding and FlashAttention for handling longer sequences.
Finally, we design a novel anomaly detection method based on the model outputs.
We further provide theoretical analysis for the detection method of our system. 
Extensive evaluations on Ethereum and Solana transactions demonstrate BlockScan's exceptional capability in anomaly detection while maintaining a low false positive rate.
Remarkably, BlockScan is the only method that successfully detects anomalous transactions on Solana with high accuracy, whereas all other approaches achieved very low or zero detection recall scores.
This work sets a new benchmark for applying Transformer-based approaches in blockchain data analysis.

BlockScan: Detecting Anomalies in Blockchain Transactions
Jiahao Yu
Xian Wu²- Hao Liu
Wenbo Guo'
Xinyu Xing
UC Santa Barbara
Meta AI
New York University sec3
Northwester University
Abstract
We propose BlockScan, customized Transformer for anomaly detection in blockchain transactions. Unlike existing methods that rely on rule-based sys- tems directly apply off-the-shelf large language models (LLMs), BlockScan introduces series of customized designs to effectively model the unique data structure of blockchain transactions. First, a blockchain transaction is multi-modal, containing boockchain-speciffe tokens, texts, and numbers. We design novel mod- ularized tokenizer to handle these multi-modal inputs, balancing the information across different modalitics. Second, we design a customized masked language modeling mechanism for pretraining the Transformer architecture, incorporating RoPE embedding and FlashAttention for handling longer sequences. Finally, we design novel anomaly detection method based on the model outputs. We further provide theoretical analysis for the detection method of our system. Extensive evaluations Ethereum and Solana transactions demonstrate BlockScan's 's excep- tional capability in anomaly detection while maintaining a low false positive rate. Remarkably, BlockScan the only method that successfully detects anomalous transactions on Solana with high accuracy, whereas all other approaches achieved very low or zero detection recall scores. This work sets a new benchmark for applying Transformer-bas approaches in blockchain data analysis.
Introduction
Together with the emergence of blockchain techniques comes different attacks against Decentralized Finance (DeFi) protocols, such as double-spending [1], partition [2], and front-running [3]. These attacks seriously threaten the asset security of billions of blockchain users. Mitigating these attacks requires detecting anomalous transactions that indicate potential malicious behavior or misuse of DeFi protocols. In this work, define anomalous transactions as transactions that significantly deviate from normal, benign usage patterns and often arise from exploiting smart contract vulnerabilities. These anomalies are characterized by irregular suspicious method calls, abnormal numerical parameters, and unforeseen sequences of operations inconsistent with typical user behavior. By identifying such outliers at runtime, DeFi platforms can issue early warnings and trigger interventions to prevent or at least minimize asset losses [4].
Prior works in anomalous transaction detection predominantly rely either rule-based or traditional ML methods. Rule-based approaches cannot generalize to unseen patterns. Traditional ML models [5, 6] like Gaussian Mixture Models (GMM) and Long Short-Term Memory (LSTM) cannot capture the complex, high-dimensional temporal dependencies inherent in blockchain transaction data due to limited capabilities. More recently, BlockGPT [7] harnesses GPT model for anomaly detection. However, vanilla GPT models cannot capture their unique data attributes and do not have an effective anomaly detection mechanism.
'Equal contribution, the order of authors is decided by flipping of a coin.
Work done while sec3.
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

To overcome these limitations, we propose BlockScan, a customized transformer model specifically tailored for detecting anomalous transactions in DeFi. BlockScan uses a BERT-style Transformer architecture with mask language modeling (MIM). Rather than focusing on text generation, we aim to learn robust representations of typical on-chain behaviors and identify deviations from normal usage. By masking and reconstructing transaction tokens, BlockScan assigns higher reconstruction errors to suspicious or atypical patterns, thereby facilitating accurate anomaly detection.
A significant challenge in developing a transformer-based model for blockchain data is the multi- modal and complex nature of transactions. Each transaction typically involves: 1) Blockchain- Specific Tokens / that are often unique and long hexadecimal strings, making a naive one-hot encoding impractical due to the explosion in vocabulary size. 2) Large Numerical Values: Transaction amounts (e.g., value and gas price) can be very large, easily spanning dozens of digits. Also, there are mixed types of numbers in transaction, such as decimal numbers and hexadecimal numbers. 3) Textual Fields, which are used in transaction logs. Balancing vocabulary size and preserving critical information is thus non-trivial. To address this challenge, B1 occkscan employs a novel tokenization scheme that integrates distinct strategies per modality. For addresses and hashes, we preserve only frequently occurring ones as single tokens to balance vocabulary size and information retention. For numerical values, we first convert decimals to hexadecimal format for consistency and information density, then apply subword tokenization with a fixed vocabulary utilize the subword tokenizer. This multi modli
size. For textual data like log messages, tokenization approach enables BlockScan to effectively process transaction data while maintaining manageable vocabulary and preserving essential information. Furthermore, leverage RoPE and FlashAttention to modify the base BERT model such that BlockScan can handle long inputs. We train our transformer model transactions, then feed the trained model with masked transactions and calculate how well the model can reconstruct the transaction. We use the reconstruction errors as the metric for anomaly detection. We further provide a theoretical analysis on the error bound under the natural assumption, showing that anomalous transactions will have higher error bound.
large dataset of benign transactions to learn the patterns of normal
We evaluate BlockScan on real-world transactions from Ethereum and Solana networks, comparing traditional ML-based, BlockGPT, and GPT-4. BlockScan demonstrates superior accuracy and lower false positive rates compared to existing methods. We further validate our key designs and hyper-parameter sensitivity through ablation study. The code, model, and datasets are available at an anonymous link." 3 BlockScan is the first open-source and best-performing transformer-base based anomaly detection for DeFi that provides a theoretical guarantee.
it against four baselines:
2 Background
Blockchain. Blockchain is a decentralized, distributed ledger technology that enables secure and tamper-resistant record-keeping. Originally developed for Bitcoin [8], it achieves consensus across a network through mechanisms like Proof of Work (PoW) [9] or Proof of Stake (PoS) [10]. Its immutability and transparency make it suitable for various applications beyond cryptocurrencies, including supply chain management, healthcare, and finance.
Smart Contracts and Transactions. Smart contracts are self-executing agreements encoded on blockchain platforms like Ethereum, enabling automated transactions within decentralized appli- cations (DApps). These contracts process conditions, manage assets, and update the ledger au- tonomously. While smart contracts enhance transparency and security in DeFi and other applications, their immutability after deployment makes vulnerability detection crucial. This work focuses on iden- tifying anomalous transactions that deviate from typical patterns, which could indicate vulnerabilities in contract logic or implementation. Early detection of such anomalies is essential for preventing potential losses [11, 12].
3 Related Work
Intra-Trann TriraTTranaction Anomaly Detection This category encompasses methods that modeling the inter- nal structure (e.g., function calls, parameters, logs, addresses) within a single blockchain transaction to identify deviations from normal behavior. BlockScan belongs to this category. A closely related

---

approach is BlockGPT [7], which also utilizes Transformer architectures, specifically a GPT-like causal language model, to predict subsequent tokens in a flattened transaction trace. However, this ap- proach faces several key limitations: transactions do not naturally form sequential data like language, making next-token prediction less meaningful, and the tokenization method (rounding numerical values to avoid vocabulary explosion) can obscure critical transaction details. BlockScan introduces a custom, multi-modal tokenizer to address this, whereas approaches like BlockGPT might simplity or lose information. Some approaches [13] alternatively use existing LLMs like ChatGPT without fine-tuning, feeding them raw transaction data, but these methods are limited by both input length constraints and the model's 's knowledge boundaries.
Besides wansformer-basee methods, non- moontrrasffommr--oo based methods for anomalous transaction detection comprise two main categories: traditional ML and rule-based approaches. The first category employs conventional models like Gaussian mixture models to estimate transaction density [5], flagging low-density transactions as anomalous. However, these methods heavily depend on the quality of transaction features used for representations, limiting their generalizability. Heuristic-based approaches, such as those detecting anomalies through sequence length analysis [7], make simplified assumptions about transaction patterns. While straightforward to implement, these heuristics are often too rigid and can be easily circumvented by adversaries who don't conform to expected patterns.
Anter-Transaction and Local Network Anomaly Detection Moving beyond individual transactions, a higher level anomaly detection analyzes a set of transactions or entities (e.g., smart contracts) to detect suspicious interactions. For instance, BERT4ETH [14] applies BERT-like pre-training to transaction histories for account-level fraud detection, which tackles the different scope from our focus. Graph Neural Networks (GNNs) are another prominent technique this space [15. 16, 17, 18]. They model blockchain data as graph, where transactions and addresses can be nodes, and the flow of value or calls between them form edges. GNNs are effective at learning representations of nodes based on their local neighborhood and can identify anomalies like small money laundering rings, unusual interaction sequences between a few contracts [15]. While powerful for capturing these localized relational anomalies, GNNs often abstract the fine-grained internal details of each transaction that low-level approaches like BlockScan focus on. The insights from inter- transaction analysis could potentially serve as complementary signal to BlockScan's
intra-transactionns findings.
Chain-level Temporal Anomaly Detection The higher level of anomaly detection shifts the focus on analyzing network-wide statistics and temporal sequences of blockchain activity. This involves monitoring time-series data derived from the blockchain, such as the total transaction volume per unit of time, average gas prices, the creation rate of new smart contracts or the frequency of specific global events [19, 20J. Anomalies at this level might manifest as sudden, unexpected spikes or drops in these global metrics, indicating large-scale events like network congestion, widespread exploitation of common vulnerability, or coordinated market manipulation. Various time-series analysis techniques can be employed, ranging from classical statistical models (e.g., Autoregressive Integrated Moving Average [21]) to machine learning models like LSTM [22]. While these macro-level and temporal approaches are crucial for understanding the overall health and security trends of a blockchain ecosystem, they generally do not provide insights into the maliciousness of a specific, individual transaction's 's internal logic, which is the primary objective of BlockScan.
4 Key Techniques
4.1 Technique Overview
Tokenizer. As demonstrated in Figure 1, a blockchain transaction mainly consists of three types of inputs: function and address signature in hash values, function logs in natural languages. and function arguments in numbers. This hybrid data type makes a transaction naturally to be multi-modal. As such, directly applying existing tokenizers designed for language models to blockchain transactions will be problematic. First, existing tokenizers will treat hash values as numbers and divide them into sub-tokens. However, these numbers themselves are meaningless, instead, they are just used to represent different entities. Second, the numbers in blockchain transactions have very large value range and large values frequently show up. Directly applying the existing tokenizers will divide a large number into many sub-tokens and thus result in ultra-long sequences for individual transactions. To solve the first issue, we use one-hot tokenization for hash values. We only consider the top 7,000 frequent hash values in our training dataset and treat the rest "OOV" (Out of Vocabulary). This
3

---

1. "type"; "CALL",
[START]
[CALL]
0xc1f351 ...
Bxédeca5 ... bac
Bx9fa0be94
"fron": "Bxcir3s1.
indicator
1.
2. from address
3.
"gas": 1962988,
calling call indicator
to address
function id
3. "to"; ToxddecaS....aet
"func"; "BxSTa0bc94",
8x809090 ... 39c
9x099900 ... 808
[INs]
data
8x476176 888
"args": [...],
g.g 1962908
6. value
7. imput indicatox
7. ingut type and data [OUT=]
"output"; I<"type"; "dsta",
8.
"data"; "Bx080008.... 909"),, I
address 8x809990
5d0
data
data
"ca "calls": [[
"type": "DELEGATECALL""
8. ouuup indicator unite"
"0x4dera5...
"gas": 1938278,
0x008000
[Lge]
"Progran
END
10.
"to": "0x35od16...
"func":: "0x9tadbe9e", "args": [...], "output": [...l,
output type and data [START] (DELEGATECALL)
indicator
lo
log messages
end indicator
of the calling
[00V]
Dx35dd16 ... 5e8 0x9fa0be94
"calls": [..-1,
10. subsequent call's infemation
out
"Lags": [...]
vocubulary
"logNessages":
0x008090 .., 626 [NONE] [INe] data Bx476f76 000
[OUTs]
9. "Progran PhoeNi.... invoke [2]",
"Progran rag Phoelii... cansuned
does not exist
none compute units"),
"value":
data 0X090000 009 [END] [START] [STATICCALL]
[END]
Figure 1: Tokenizer BlockScan, BlockScan tokenizes transactions by flattening nested ISON using depth-first first search, assigns unique tokens to frequent addresses while marking infrequent ones as "OOV", and uses special tokens ("[START]", "[END]", "[Ins]") mark function artifacts.
method can constrain the vocabulary size, which helps reduce model parameters and improve training efficiency. We further train own number tokenization model to handle numbers. Different from existing tokenizers, our model can better tailor to the large numbers in blockchain transactions and give shorter token sequences for large numbers. Finally, we still apply the text tokenizer to function logs to capture their semantic meanings. As demonstrated in $6, our customized tokenizer is critical for learning foundation models and final anomaly detection.
Model design. We make a different design choice from BlockGPT [7] and use a BERT structure together with MLM for our foundation model. The key rationale is to reduce training complexity and improve overall training efficiency. Specifically, we do not need to generate new transactions, and training GPT models are in general more difficult than BERT predicting the future without any context harder than filling missing parts with certain context. Besides, our main focus is to learn patterns of normal transactions. Thus, select MIM, which provides enough pattern- leateinleerning capabilities. We choose to apply RoPE embedding and FlashAttention in our model to handle long input sequences. The reason choose this technique combination rather than other ones like LongLoRA [23] is to consider computational cost and algorithmic simplicity. These techniques still keep a one-stage pretraining simpler and more efficient than two-stage training, which is required by A-bsed approaches.
Post-training detection. With trained foundation model, feed masked transactions into the model and use reconstruction error as the metric for identifying abnormal transactions. This approach is effective because the model learns patterns of normal transactions, causing anomalous ones to exhibit higher reconstruction errors due to their irregularity. While we explored alternative approaches using transaction embeddings and one-class contrastive learning [24] with both <CLS> token and full token embeddings (detailed in $D.1), none outperformed the simple reconstruction error approach. Therefore, we adopt this straightforward method, which provides both superior detection performance and minimal computational overhead.
4.2 Tokenization
To address these challenges in tokenization we discussed above, BlockScan introduces a custom tokenizer specifically designed for the unique multi-model characteristies of blockchain transaction data. We first flatten the raw JSON data into sequence of function calls and apply depth-first search to track function callings. We use "[START]" and "[END]" tokens to help the model identify the beginning and end of each function call within the sequence. Additionally, "[Ins]" and "[OUTs]" tokens are used to mark the input and output arguments of functions, which can vary number. To further distinguish between data types, we use tokens like "data" and "address" to indicate whether the argument is a data value or an address. These special tokens enable the model to clearly recognize the type and boundaries of variable-length information, improving accuracy in transaction tracing.

---

After pre- re-ppocesssin the transaction trace, we then treat unique hash addresses as individual tokens, which can significantly reduce the overall token count. Given the large number of unique addresses, we rank them by frequeney and retain the top 7,000 most frequent addresses. Addresses that fall outside the top 7,000 are treated as a single "OOV" token, as shown in Figure 1. In real-world scenarios, frequent addresses are often associated with public smart contracts or exchanges, and preserving them as single tokens improves the system's 's ability to understand transaction behavior.
For values, as illustrated in Figure 1, there are both decimal (e.g., gas) and hexadecimal numbers (e.g. output data). We first convert all decimal numbers into 40-character hexadecimal format. This approach provides a more compact representation of large numbers as the hexadecimal number is more concise than the decimal number. Small numbers typically begin with "Ox000...", which can be learned as single token. Therefore, this conversion does not lead to a significant increase in token count for small numbers. The consistent formatting of values across all transactions simplifies processing and comprehension for models.
Unlike hash addresses, log messages often convey information about the same object, such as program status, across different function calls. For example, in Figure 1, log messages like "Program PhoeNi invoke [2]" and "Program PhoeNi consumed none compute units" vary in details but relate the same event. Treating each log message as a unique token would obscure relationships between messages, which often share common topics. Subword tokenization preserves these connections. ensuring that the model can recognize similarities across different log messages.
The token dictionary size is set at 30,000 to balance the trade-off between token count and information granularity. After allocating space for special tokens and preserved hash address tokens, we apply WordPiece tokenization to learn on the remaining tokens for numbers and log messages.
4.3
Model Design
BlockScan adapts the RoBERTa model [25] to train an auto-encoder specifically for transaction tracing. BlockScan employs MLM strategy, where g% of tokens in each transaction are randomly masked. The model is then trained to reconstruct the original transaction from the masked tokens, learning robust representations in the process. However, tokenized transaction data can be significantly longer than typical natural language sequences, posing additional challenges during training. To address these challenges, we incorporate two key techniques: (1) We replace the absolute position embeddings in RoBERTa with Rotary Position Embeddings (RoPE) [26), which provide more efficient handling of long-range dependencies. (2) We leverage FlashAttention [27] to accelerate the attention mechanism, improving memory efficiency and reducing computational overhead, making feasible to train on long transaction sequences.
4.4 Post-training Detection
After training, we can deploy BlockScan for detecting anomalous transaction sequences. The motivation behind applying BlockScan for transaction anomaly detection is that since the model trained on benign transaction sequences, it can accurately predict masked tokens if the sequence is also benign. Hence, the anomalous score of a transaction can be derived based on the prediction results on the masked tokens. Specifically, for given transaction, randomly mask ratio of the tokens, similar to the training process, and input the masked sequence into the trained model. The probability distribution over the possible tokens for each MASK position represents the likelihood of each token in that position. We construct a candidate set of the top-s most likely tokens for each masked position. If the true token appears within the top-s candidate set, we consider the token as benign. Conversely, if the true token is not in the top-s candidate set, it is treated as anomalous. The reason why we do not directly predict based on the most likely token is that the addresses and values are more challenging than nature language texts to predict, and having a candidate set tolerant to the prediction error is more reasonable. After ranking the transactions by the anomalous score, we can select the top k transactions with the highest anomalous score as anomalous. & can be dynamically adjusted based on how the smart contract developers trade off between false positives and security of the transactions.
5

---

5 Theoretical Analysis
We present some theoretical insights to show that our approach is well motivated in theory. Specifi- cally, we show that transactions deviating from the learned benign distribution tend to incur higher prediction errors under our pretrained transformer model.
We begin by introducing the notation and basic definitions. Each blockchain transaction D is represented as a sequence of tokens, and D' denotes partially masked version of D. We train a transformer model h to reconstruct D from D' by minimizing the cross-entropy loss L over the benign transaction distribution Phenign- The resulting optimal model h" obtained by solving the following loss function: D'D,D')~Penn (D') D))- We then analyze the expected loss of h" when applied to malicious transactions drawn from Pmat, expressed as E (D.D')>Paull [Chh" (D',, D)]. Leveraging results from domain adaptation theory [28, 29], we derive an upper bound on this risk.
Theorem 5.1 ([28)). The expected loss of ht on the malicious distribution Pmmat satisfies:
1
Pr (C(h" (I')) S E(D.D")~<Pom (D'), D)]
Pmma)) ) + X, (I)
where the first R.H.S. term is the benign loss, dRSH is the H&A--divereecce between P Phenign and Pmut. and X is a constant representing the minimum joint error of any hypothesis in H.
In Theorem 5.1, the dHAH( (P (Phenign: Pmal) term measures the dissimilarity between the distributions of partially observed benign and malicious transactions. A larger divergence increases the upper bound on the loss for malicious data. Consequently, malicious transactions are expected yield higher prediction losses (i.e., our anomaly scores) than benign ones, justifying their detection by ranking these scores.
Experiments
6.1 Experimental Setup
Dataset. We primarily focus on Ethereum and Solana transactions in our experiments. We sample transactions from interactions with DeFi applications for Ethereum and 10 applications for Solana to ensure diverse transaction patterns. For each DeFi application, transactions are ordered by their block timestamps and split into 80% for training and 20% for evaluation as benign transactions. This per-application sequential split is crucial to prevent time travel data leakage, ensuring that the model trained exclusively on past data without access to future information. Such a methodology can maintain the integrity of performance metrics by avoiding artificially inflated results that could arise the model inadvertently learned from future transactions.
Specifically, the Ethereum dataset is collected from October 2020 to April 2023, while the Solana dataset is collected from September 2023 to December 2023. For malicious transactions, they are also sampled from these DeFi applications and occurred after the sampling periods of benign transactions. This approach guarantees that the model is trained solely on known benign transactions up to the cutoff dates, preventing any inadvertent exposure to future anomalous patterns during training. We sample these malicious transactions from verified transaction vendors, including Zengo, TRM Labs, and CertiK. Moreover, we manually verify the malicious nature of these transactions to ensure the quality of the dataset. For both benign and malicious transactions, we manually clean them to remove transactions unrelated to the target applications or failed transactions. We provide more details on the dataset in Appendix C. As far as we know, this is the open-sourced dataset for transformer-bas blockchain transaction anomaly detection.
Evaluation Metries. We adopt the evaluation methodology from BlockGPT [7], where transactions are ranked based on their detection scores produced by the models. Specifically, the top-k transactions with the highest scores are labeled as anomalous, while the remaining transactions are classified as benign. The binary classification performance is evaluated using the following metrics: False Positive Rate (FPR), Recall, and Precision. our experiments, we select values from the set 5, 10, 15 for Ethereum and 10, 15, 20 for Solana considering the number of collected to evaluate the model's performance at different detection thresholds. larger value indicates higher detection threshold, potentially leading more false positives but could detect more anomalous transactions, which can

---

k=10
k=15
k=20
Method
FPR
Recall
Precision
FPR
Recall
Precision
FPR
Recall
Precision
BlockGPT
0.47%
16.67%
30%
0.73%
22.22%%
26.67%
1%
27. 17.88%
25%
Vec2Vec
0.67%
0%
0%
1%
0%
0%
1.13%
0%
0%
GPT-4o
0.67%
0%
0%
1%
0%
0%
1.13%
0%
0%
Heuristic
0.67%
0%
0%
1%
0%
0%
1.13%
0%
0%
BlockScan
0.13%
44.44 %
80%
0.2%
66.67%
80 %
0.47%
72.22%
65%
Table I: Performance comparison with different is values for Solana.
k=5
k=10
k=15
Method
FPR
Recall
Precision
FPR
Recall
Precision
FPR
Recall
Precision
BlockGPT
0.14%
40%
80%
0.42%
70%
70%
0.99%
80%
53.33%
Vec2
0.56%
10%
20%
1.12%
20%
20%
1.83%
20%
13.33%
GPT-4o
0.28%
30%
60%
0.98%
30%
30%
1.55%
40%
26.67%
Heuristic
0.14%
40%
80%
0.42%
70%
70%
1.13%
70%
46.67%
BlockScan
0%
50%
100%
0.28%
80%
80%
0.97% %
80%
53.33%
Table 2: Performance comparison with different 1: values for Ethereum.
be varied based on how the DeFi owner wants to trade off between false positives and security. We run three independent runs for each experiment and report the average results.
Model architecture and hyper-parameter 100 million parameters, for training the Ethereum task, and the BERT-large architecture, with 300 million parameters, for training the Solana task. We the learning rate to 5e-5 and use batch size of 32 for the Ethereum task and 4 for the Solana task, respectively. For the Ethereum task, the maximum sequence length is set to 1,024 tokens, while for the Solana task. we increase the maximum sequence length to 8, 192 tokens to accommodate the longer transactions. Please refer to $D.1 for detailed setup of the training hyper-pane param-paraeetes for both datasets. the inference phase, we set the mask ratio to 15% and the number of candidate tokens is set to 3 on both datasets.
We use the BERT-base architecture, which includes
Baselines. To evaluate the effectiveness of BlockScan, compare it against several anomalous transaction detection methods: BlockGPT [7]: It pretrains a causal transformer model on the transaction corpus to learn typical benign transaction patterns. The underlying intuition is that anomalous transactions deviate from these learned patterns and are therefore difficult to predict. BlockGPT calculates the sum of the conditional likeliiis for each token in a transaction sequence. with lower likelihoods indicating potential anomaly. The top-k: transactions with the lowest Doc2 [30]: represents the transaction as a bag of words
scores are flagged as anomalous. and leverages the distributed representation of words to represent the transaction. These vectorized transactions are then analyzed using GMM to estimate the probability of each transaction being anomalous. This probabilistic approach allows for the identification of anomalous transactions based on their likelihood within the learned distribution. commercial language model to assign an anomaly score ranging from 0 to 100 to each transaction.
GPT-4o: This method utilizes a state-of-the-as art
This approach relies on the extensive pre-training of the language model, which could potentially encompass wide variety of anomalous transaction patterns, enabling it to detect suspicious activities Ereuristic-based methods: Previous study [31] has highlighted that
based on learned knowledge. machine learning models sometimes achieve decent detection rates by leveraging trivial features like input length in detection tasks. To explore this, our neuristic-based approach uses the length of transaction the sole feature, operating under the assumption that anomalous transactions typically longer than benign ones.
By comparing BlockScan with these diverse baselines, we aim to demonstrate its superior perfor- mance in accurately identifying anomalous transactions while mitigating the impact of potential confounding factors present in other detection methods.
6.2 Experimental Results
Comparison with Baselines. We show the FPR, Recall, and Precision of BlockScan and other baselines in Table I and Table 2. As the results show, BlockScan outperforms all bascline methods
7

---

Models
k=10
k=15 Recall
k=20
FPR
Recall
Precision
FPR
Precision
FPR
Recall
Precision
BlockScan
0.13%
44.44% %
80%
0.2% %
66.67% %
80%
0.47%
72.22%
65%
Tokenizer
0.67%
0%
0%
1%
0%
0%
1.33%
0%
0%
LLog message
0.67%
0%
1%
0%
0%
1.33%
0%-
RoPE
0.4%
22.22%
40%
0.53%
38.89%
46.67 46.67%
0.80%
44.44%
40%
BlockScan- 100m
0.6%
5.56%
10%
0.93%
5.56%
6.67%
1.27%
5.56%
5%
BlockScan-g-$
0.27%
33.33%
60%
0.4%
50%
60%
0.53%
66.67%
60%
BlockScan-g=ll
0,27%
33.33%
60%
0.4%
50%
60%
0.53%
66.67%
60%
BlockScan-s=l
0.13%
44.44%
80%
0.27%
61.11%
73.33%
0.4%
77.78%
70%
BlockScan-s=
0.13%
44.44%
80%
0.27%
11%
73.33%
0.47%
72.22%
6.5%
Table 3: Ablation study on BlockScan for Solana.
across various & values for both the Ethereum and Solana datasets. Notably, on the Solana dataset, most baseline methods Vec, GPT-4o, and Heuristic) consistently fail detect any anomalous transactions, achieving a recall and precision 0% for all values. This indicates that all transactions flagged as anomalous by these methods are, in fact, benign. While BlockGPT is able to detect some anomalous transactions, its recall and precision are significantly lower than those of BlockScan. For instance, k 20, BlockGPT achieves only 27.78% recall with FPR of 1%. In contrast, BlockScan detects the majority of anomalous transactions (i.e., 13 out of 18) with a lower FPR of 0.47%.
We have the following potential reasons for the failure of these baseline methods: 1) Doc2Vec's approach of representing transactions bag of words likely fails due to its inability to capture the sequential dependencies and contextual nuances crucial for distinguishing between benign and anomalous transactions. 2) Despite its extensive pre-training. GPT-4o may underperform because it is not specifically fine-tuned for blockchain-specife anomalous transaction detection, making less effective in identifying such domain-specific anomalies. 3) The heuristic method fails when the heuristics are not accurate for those anomalous transactions that have similar length as benign transactions. 4) BlockGPT, which shares the most similar idea with BlockScan, fails to detect anomalous transactions because the casual language model structure may not be suitable for detection task. For each token in the transaction, it only considers preceding information while BlockScan can analyze both previous and subsequent information for tokens to predict.
In contrast to baseline methods's failure, BlockScan demonstrates strong performance with sig- nificantly lower FPRs and much higher recall and precision scores, especially as the threshold increases. For example, at k = 10 on the Ethereum dataset, BlockScan achieves an FPR of 0.28%, recall of 80%, and precision of 80%, which means BlockScan can successfully detect 8 out of 10 anomalous transactions while only predicting false positives.
These results highlight the effectiveness of BlockScan in accurately identifying anomalous transac- tions while minimizing false positives, thereby demonstrating its superiority over existing detection methods in both Ethereum and Solana environments. The baselines' failure to detect anomalous transactions also underscores the challenge of this task and the importance of leveraging advanced methods like BlockScan for robust blockchain transaction security.
Effect of Core Components. We conduct an ablation study on BlockScan by removing each core component individually to analyze its impact on detection performance with the Solana dataset. The first component we ablate is the tokenizer, which is specifically designed to handle transaction data in BlockScan. To evaluate its significance, we replace the custom tokenizer with the default WordPiece tokenizer from BERT, allowing us to observe how much this tailored tokenization contributes to the model's 's success. Next, we examine the effect of log message, which is the printed information when executing these transactions. As mentioned in $4.2, we subword tokenization to encode the log messages in order to preserve their context information. Here, we substitute this approach by treating each log message as a unique token, similar to how treat the hash addresses, and measure the resulting change in performance. Lastly, we study the effect of the RoPE embedding, which we employ capture the relative position information between tokens. In this ablation, replace it with the default absolute positional embedding.
The results are presented in the upper half of Table 3. From these experiments. we draw the following conclusions. First, substituting our customized tokenizer with the default BERT tokenizer, while keeping all other components unchanged, caused the model to fail to detect any anomalous
8

---

transactions (i.e., the recall was 0 across different k values). This underscores the importance of our customized tokenizer, as the default BERT tokenizer, trained on general text data, is unable to capture the complex structure of specific transaction traces. Second, we observed that the model also struggled to differentiate between benign and anomalous transactions when we altered the log message encoding strategy. This suggests that the log messages may contain key information about the transaction status in the Solona task, and an appropriate encoding method, such as a subword tokenizer, can extract this information effectively. Lastly, replacing our relative positional embeddings with absolute positional embeddings led to a significant drop in model performance, with a decrease in recall of nearly 20% to 30% across various & values. This emphasizes the importance of relative positional embeddings for effectively handling long sequences (e.g.. a sequence length of 8192).
We also conduct an ablation study on the impact of FlashAttention on the training time and memory usage of BlockScan in Table The results show that the integration of FltehAttention reduces the training time and memory usage while maintaining the detection performance. Furthermore, we investigate the selection of the base model in Table 10 by replacing the RoBERTa model with other state-of-the-ar BERT-like models like DeBERTa [32]. The results demonstrate that BlockScan achieves consistent performance and agnostic to the choice base model.
pareerppraaettrs sensitivity analysis. We further investigate the impact of key typer-parameters and model architecture on the final model performance in the Solana task. Specifically, we introduce two additional
during detection phrase: the detection mask percentage g and the number of candidate tokens & used when calculating the mask prediction accuracy. By varying g and within [5, 10, 15) and (1, 3, 5), respectively, we assess the model's 's robustness to these parameters. Additionally, While BERT-large is the default model on Solana dataset, we replace it with BERT-base to evaluate the influence of different model architectures on the final performance.
As shown in the lower half of Table 3, our model demonstrates degree of robustness variations in g and 8. Recall that the default values for and s in BlockScan are 15% and 3, respectively. Notably, BlockScan-s=l even outperforms BlockScan when k 20, suggesting that a simpler set of hyperparameters can still achieve relatively good performance. However, when the model architecture is switched from BaRT-large to BERT-base, a noticeable performance drop occurs on the Solona dataset. This is likely due to the dataset's ' large number of training samples (i.e., almost 30,000) and longer sequence length (i.e., 8, 1,9 tokens), which smaller models like BERT-base struggle to handle effectively.
The dataset's size of malicious transactions is constrained due to the manual validation and cross-checking required to confirm their malicious nature. To address this, we perform an additional experiment using only manually verified malicious transactions on the Ethereum dataset, without cross-checking, resulting in a malicious dataset that is 10x larger. The findings, presented in Figure 2, further validate the effectiveness of BlockScan in detecting anomalous transactions within a larger dataset.
Larger Dataset.
Limitations and Discussion
Tokenizer and Model Adaptability. Our approach builds the tokenizer using a large transaction corpus. To maintain detection performance, we recommend periodically rebuilding tokenizer to align with evolving transaction patterns. Our model's training on benign data enables it to learn typical patterns and detect anomalies, providing adaptability to new malicious strategies. However, if attack strategies closely mimic benign patterns, detection becomes challenging. Regular model retraining on updated data helps ensure optimal accuracy as blockchain ecosystem evolves.
Fine-Tuning GPT-4o. As shown in $6.2, directly using GPT-4o a detector results in poor performance. We further fine-tune GPT-4o via OpenAl API on Ethereum dataset but still observe limited performance. We hypothesize that this is because the fine-tuning API is coarse-grained and does not allow next token prediction nor customization of tokenization, which is crucial for our task. Detailed results are shown in Table 7.
Robustness to Noise. In blockchain transactions, the ratio of benign to malicious transactions is typically highly imbalanced. Given this high imbalance, even if some potential malicious samples are inadvertently included in the training set, their impact minimal, as the model predominantly learns the representation of the majority class (benign transactions). To assess the model's 's robustness to

---

noise, we conduct experiment simulating extreme case where half of the malicious transactions were intentionally included in the training for the Ethereum dataset. While this scenario caused slight drop in detection performance, the model remained effective. These results demonstrate that our approach maintains robustness to reasonable level of noise in the data (Table 8).
Conclusion
We presented BlockScan, transformer- based model designed for detecting anomalous transactions in DeFi ecosystems such as Ethereum and Solana. By leveraging MLM and carefully designed tokenization techniques, BlockScan efficiently handles the complexity and diversity of transac- tion data. Additionally, we open-sourced the code, model, and datasets, making BlockScan the first open-source solution for LLM-based anomalous transaction detection in DeFi. We hope that this contribution will serve as a valuable resource for the research community, facilitating further advancements in the development of scalable and robust anomalous transaction detection systems.
10

---

References
[1] Ghassan Karame, Elli Androulaki, and Srdjan Capkun. Double-spending fast payments in bitcoin. In Proceedings of the 2012 ACM conference Computer and communications security, 2012.
[2] Muhammad Saad, Victor Cook, Lan Nguyen, My T Thai, and Aziz Mohaisen. Partitioning attacks on bitcoin: Colliding space, time, and logic. In 2019 IEEE 39th international conference on distributed computing systems (ICDCS). IEEE, 2019.
[3] Shayan Eskandari, Seyedehmahsa Moosavi, and Jeremy Clark. Sok: front-running attacks on blockchain. In Financial Cryplography and Data Security: FC 2019 International Workshops. Springer, 2020.
Transparent dishonesty:
[4] Francesco Ravazzi. Emergency stop solidity patterns, 2024. Accessed: 2024-11-16
[5] Lingxiao Yang, Xuewen Dong, Siyu Xing, Jiawei Zheng, Xinyu Gu, and Xiongfei Song. An abnormal transaction detection mechanim on bitcoin. In Proceedings of the 2019 International Conference Networking and Network Applications (NaNA). IEEE, 2019.
[6] Thanyah Aldaham and Hedi HAMDI Enhancing digital financial security with Istm and blockchain technology. International Journal of Advanced Computer Science Applications. 2024.
[7] Yu Gai, Liyi Zhou, Kaihua Qin, Dawn Song, and Arthur Gervais, Blockchain large language models. arXiv preprint arXiv:2304. 12749, 2023.
[8] Satoshi Nakamoto. Bitcoin: A peer-to-peet electronic cash system. Satoshi Nakamoto, 2008
[9] Adam Back et al. Hashcash-a denial of service counter-measure. 2002.
[10] Fahad Saleh. Blockchain without waste: Proof-of-stake. The Review of financial studies, 2021.
[11] Mohammad Hasan, Mohammad Shahriar Rahman, Helge Janicke, and Iqbal H Sarker. Detecting anomalies in blockchain transactions using machine learning classifiers and explainability analysis. Blockchain: Research and Applications, page 100207, 2024.
[12] Muneeb Ul Hassan, Mubashir Husain Rehmani, and Jinjun Chen. Anomaly detection in blockchain networks: A comprehensive survey. IEEE Communications Surveys & Tutoriils, 25(1):289-318 2022.
[13] Chong Chen, Jianzhong Su, Jiachi Chen, Yanlin Wang, Tingting Bi, Yanli Wang, Xingwei Lin, Ting Chen, and Zibin Zheng. When chatgpt meets smart contract vulnerability detection: How far are we? arXiv preprint WrXiv:2309.05520. 2023.
[14] Sihao Hu, Zhen Zhang, Bingqiao Luo, Shengliang Lu, Bingsheng He, and Ling Liu. Bert4eth: A pre-trained transformer for ethereum fraud detection. In Proceedings of the ACM Web Conference 2023, pages 21 2189-2197, 2023.
[15] Jianian Wang. Sheng Zhang, Yanghua Xiao, and Rui Song. review on graph neural network methods in financial applications. arXiv preprint arXiv:2111.15367, 2021.
[16] Robert Appiah. MultiVul-GCN: automatic smarl contract vulnerability detection using multi- graph convolutional networks. PhD thesis, University of British Columbia, 2023.
[17] Ze Chang, Yunfei Cai, Xiao Fan Liu, Zhenping Xie, Yuan Liu, and Qianyi Zhan. Anomalous node detection in blockchain networks based on graph neural networks. Sensors, 25(1):1, 2024.
[18] Amit Sharma, Pradeep Kumar Singh, Elizaveta Podoplelova, Vadim Gavrilenko, Alexey Tselykh, and Alexander Bozhenyuk. Graph neural network-based anomaly detection in blockchain network. In International Conference on Computing, Communications, and Cyber-Security, pages 909-925 Springer, 2022.
[19] Rohan Maheshwari, Sriram Praveen VA, G Shobha, Jyoti Shetty, Arjuna Chala, and Hugo Watanuki. Illicit activity detection in bitcoin transactions using timeseries analysis. International Journal of Advanced Computer Science and Applications, 14(3), 2023.
11

---

[20] Qi Xia, Badjie Ansu, Jianbin Gao, Mupoyi Ntuala Grace, Hu Xia, and Obiri Isaac Amankona. novel time series approach to anomaly detection and correction for complex blockchain transaction networks. In 2024 IEEE 23rd International Conference on Trust, Security and Privacy Computing and Communications (TrustCom), pages 674-682. IEEE, 2024.
[21] Sebastian Schmidl, Phillip Wenig, and Thorsten Papenbrock. Anomaly detection in time series: comprehensive evaluation. Proceedings of the VLDB Endowment, (5(())1777--11)) 2022.
[22] Zahra Zamanzadeh Darban, Geoffrey I Webb, Shirui Pan, Charu Aggarwal, and Mahsa Salehi. Deep learning for time series anomaly detection: A survey, ACM Computing Surveys, 57(1):1-
42, 2024.
[23] Yukang Chen, Shengju Qian, Haotian Tang, Xin Lai, Zhijian Liu, Song Han, and Jiaya Jia. Longlora: Efficient fine-tuning of long-context large language models. arXiv preprint arXivv2309. 12307, 2023.
[24] Kihyuk Sohn, Chun-Liang Li, Jinsung Yoon, Minho Jin, and Tomas Pfister. Learning and evaluating representations for deep one-class classification, arXiv preprint arXiv:2011.02578. 2020.
[25] Yinhan Liu, Myle Ott, Naman Goyal, Xuezhe Du, Mandar Joshi, Danqi Chen, Omer Levy, Mike Lewis, Luke Zettlemoyer, and Veselin Stoyanov. Roberta: robustly optimized bert pretraining approach. arXiv preprint arXiv: /907. 1692, 2019.
[26] Jianlin Su, Murtadha Ahmed, Yu Lu, Shengfeng Pan, Wen Bo, and Yunfeng Liu. Roformer: Enhanced transformer with rotary position embedding, Neurocomputing, 2024.
[27] Tri Dao, Dan Fu, Stefano Ermon, Atri Rudra, and Christopher Ré. Flashattention: Fast and memory-efficient exact attention with io-awareness. In Proceedings of NeurlPS, 2022.
[28] Shai Ben-David, John Blitzer, Koby Crammer, Alex Kulesza, Fernando Pereira, and Jen- nifer Wortman Vaughan. A theory learning from different domains. Machine learning, 2010.
[29] Shai Ben-David, John Blitzer, Koby Crammer, and Fernando Pereira. Analysis of representations for domain adaptation. Advances in neural information processing systems, 19, 2006.
[30] Quoc Le and Tomas Mikolov. Distributed representations of sentences and documents. In Proceedings of ICML. PMLR, 2014.
[31] Niklas Risse and Marcel Böhme. Top score on the wrong exam: benchmarking in machine learning for vulnerability detection. arXiv preprint arXiv:2408. /2986, 2024.
[32] Pengcheng He, Xiaodong Liu, Jianfeng Gao, and Weizhu Chen. Deberta: Decoding-enhanen bert with disentangled attention. arXiv preprint arXiv:2006.0366 03654, 2020.
[33] Diederik P Kingma. Adam: method for stochastic optimization. arXiv preprint
1rXiv:1412.6980, 2014.
[34] Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort, Vincent Michel, Bertrand Thirion, Olivier Grisel, Mathieu Blondel, Peter Prettenhofer, Ron Weiss, Vincent Dubourg, et al. Scikit- learn: Machine learning python. Journal of machine learning research, 2011.
[35] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoe Le, Denny Zhou, et al. Chain-of-thouge prompting elicits reasoning in large language models. Advances neural information processing systems, 2022.
[36] Xinlei Chen and Kaiming He. Exploring simple siamese representation learning. In Proceedings of the IEEE/CVF conference computer vision and pattern recognition, pages 15750-1575% 2021.
12

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification: The claims made in the abstract and introduction accurately reflect the paper's contributions and scope.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.
is fine to include aspirational goals as motivation as long as is clear that these goals not attained by the paper.
2. Limitations
Question: Does the paper discuss the limitations the work performed by the authors?
Answer: [Yes]
Justification: In $7, discuss the limitations of the work.
Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create a separate "Limitations" section their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect on the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution is low images are taken in low lighting. Or speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.
While the authors might fear that complete honesty about limitations might used by reviewers as grounds for rejection, worse outcome might be that reviewers discover limitations that aren't 't acknowledged judgment and recognize that individual actions in favor of transparency play impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
the paper. The authors should use their best
3. Theory assumptions and proofs
Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [Yes]
13

---

Justification: In $5, we provide the full set of assumptions and a complete (and correct) proof for the main theorem.
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated or referenced the statement of any theorems.
The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide short proof sketch provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental result reproducibility
Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that it affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?
Question:
Answer: [Yes]
Justification: In $6, we provide all the information needed to reproduce the main experimen- tal results of the paper.
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is novel architecture, describing the architecture fully might suffice, or if the contribution a specific model and empirical evaluation, it may be necessary either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of large language model), releasing of a model checkpoint, or other means that appropriate to the research performed.
While NeurlPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) the contribution is primarily a new algorithm, the paper should make clear how reproduce that algorithm. (b) If the contribution is primarily new model architecture, the paper should describe the architecture clearly and fully.
(c) the contribution is a new model (e.g., a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome deseribe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should possible for other researchers to have some path to reproducing or verifying the results.
5. Open access to data and code
14

---

Does the paper provide open access to the data and code, with sufficient instruc- tions faithfully reproduce the main experimental results, as described in supplemental material?
Question:
Answer: [Yes]
Justification:
We open-source our datasets and models.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurIPS code and data submission guidelines (https://nips cc/
for more details.
While we encourage the release of code and data, we understand that this might not be possible, "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (c.g., for new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (https: //niss httppscccpubliccccceeeeeecpcsece hwtp//giis////eee//
/tt.ddee/oooeeeumiiiieeeeeeeeeee /Ct////ooosmsssseeeeeea ssisssolicyy for more details.
The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only subset of experiments are reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information as possible in supplemental material (appended the paper) is recommended, but including URLs to data and code is permitted.
6. Experimental setting/details
Question: Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary understand the results?
Answer: [Yes]
Justification: In $D.1, we provide all the training and test details necessary to understand the results.
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core of the paper level of detail that is necessary to appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, as supplemental material.
7. Experiment statistical significance
Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Question:
Answer: [Yes]
Justification: Each result is the average of runs the experiments.
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by error bars, confi-
dence intervals, statistical significance tests, least for the experiments that support the main claims of the paper.
The factors of variability that the error bars are capturing should be clearly stated (for
example, train/test split, initialization, random drawing of some parameter, or overall with given experimental conditions).
15

---

The method for calculating the error bars should be explained (closed form formula, call a library function, bootstrap, etc.)
The assumptions made should be given (e.g.. Normally distributed errors).
It should be clear whether the error bar is the standard deviation or the standard error of the mean.
is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma enror bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are range (e.g. negative enror rates).
If error bars reported in tables plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time of execution) needed reproduce the experiments?
Question:
Answer: [Yes]
Justification: $D.1, we provide the information on the computer resources needed to reproduce the experiments.
Guidelines:
The answer NA means that the paper does not include experiments.
The paper should indicate the type of compute workers CPU GPU, internal cluster, or cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental runs as well as estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary or failed experiments that didn't make it into the paper).
9. Code of ethics
Question: Does the research conducted the paper conform, in every respect, with the NeurlPS Code of Ethics https: /tte::////uurrreee cttppps..ccppppeeeeeppp httpp////lll///cccccceeeeeeeeeee
Answer: [Yes]
Justification: This research conducted in the paper conforms, in every respect, with the NeurIPS Code of Ethics.
Guidelines:
The answer NA means that the authors have not reviewed the NeurlPS Code of Ethics.
If the authors answer No, they should explain the special circumstances that require deviation from the Code of Ethics.
The authors should make sure to preserve anonymity (e.g., there a special consid- eration due to laws or regulations in their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [Yes]
Justification:
We discuss the societal impacts of our work in Appendix A.
Guidelines:
The answer NA means that there no societal impact of the work performed.
If the authors answer NA or No, they should explain why their work has no societal impact why the paper does not address societal impact.
16

---

Examples of negative societal impacts include potential malicious unintended uses (e.g., disinformation, generating fake profiles, surveillance), faireess considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional unintentional) misuse of the technology.
If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms monitor how system learns from feedback over time, improving the efficiency and accessibility of ML).
Safeguards
Question: Does the paper deseribe safeguards that have been put in place for responsible release of data or models that have a high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Answer: [NA]
Justification: Our work does not pose any such risks.
Guidelines:
The answer NA means that the paper poses no such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere to usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make best faith effort.
12. Licenses for existing assets
Are the creators or original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
Question:
Answer: [NA]
Justification: We curate the dataset by ourselves.
Guidelines:
The answer NA means that the paper does use existing assets.
The authors should cite the original paper that produced the code package dataset.
The authors should state which version of the asset used and, possible, include URL.
The name of the license (e.g., CC-BY 4.0) should be included for each asset.
For scraped data from a particular source (e.g., website). the copyright and terms of service of that source should be provided.
If assets are released, the license, copyright information, and terms use in package should be provided. For popular datasets, paperswi wwwwwe. com datasets has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
17

---

For existing datasets that are re-packaged, both the original license and the license of the derived asset (if has changed) should be provided.
If this information is not available online, the authors are encouraged to reach out to the asset's s creators.
13. New assets
Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer:
[Yes]
Justification:
We provide the documentation for the dataset and models.
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details of the dataset/code/moddl as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent was obtained from people whose asset used.
At submission time, remember to anonymize your assets (if applicable). You can either create anonymized URL or include anonymized zip file.
14. Crowdsourcing and research with human subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well as details about compensation (if any)?
Answer: [NA]
Justification:
We do not involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included in the main paper.
According the NeurIPS Code of Bthies, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals or equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or equivalent approval/review based the requirements of your country or institution) were obtained?
Answer: [NA]
Justification:
We do involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Depending on the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurlPS Code of Ethics and the guidelines for their institution.
For initial submissions, not include any information that would break anonymity (if applicable), such the institution conducting the review.
18

---

16. Declaration of LLM usage
Question: Does the paper describe the usage of LLMs if it is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, or formatting purposes and does not impact the core methodology. scientific rigorousness, originality of the research, declaration is not required.
Answer: [NA]
Justification:
We do not use LLMs in the core methods of this research.
Guidelines:
The answer NA means that the core method development in this research does not involve LLMs as any important, original, non-standard components.
Please refer to L.LM policy (https: : / tteurrpps.ccCComfeeeeeeett for what should or should not be described.
19

---

A Broader Impact
This work focuses on anomaly detection in blockchain transactions, with the goal of mitigating risks in DeFi applications. By identifying transactions that exhibit abnormal behaviors, such as those arising from smart contract vulnerabilities, our work contributes to enhancing the security and reliability of blockchain-basee systems, which play an increasingly important role in financial and other industries.
We emphasize that all transactions used in this study are publicly available and sourced from blockchain networks. No private permissioned transaction data has been used, ensuring compliance with privacy standards. Furthermore, we have open-sourced our dataset and model to facilitate further research in this and promote transparency and reproducibility.
We do not foresee any significant negative societal impacts arising from this work. However, we recognize that with any security-related technology, there is potential for misuse, such as the development of adversarial techniques to bypass detection mechanisms. We encourage further research to strengthen anomaly detection models and ensure they robust against such challenges.
Overall, our work is a step toward improving the security and trustworthiness of blockchain ecosys- tems, with broad potential societal benefits in safeguarding users and systems in decentralized finance.
B Pseudo Algorithm of BlockScan
We present the pseudo algorithm of BlockScan in Algorithm to help readers understand the workflow of BlockScan.
Algorithm 1:
Workflow of BlockScan
Require: Benign transactions D [Di.... Dv), ) transactions to be predicted P= [Ti, T2,
TM), mask percentage g. detection mask percentage g. top-s candidates, threshold k:
Ensure: Top-k transactions P ranked by anomaly score
1: Tokenization:
2: Initialize tokenizer T with preserved address tokens and special tokens
3: Train subword tokenization remaining data generate the final token dictionary
4: Save tokenizer T
5: Training Phase:
6: for each transaction D; E D do
7: Tokenize D; using T
8: Randomly select tokens from D, and mask them: Dj = MMsk Di, m)
9: Train the model h to minimize the loss function:
ED. [log P(D,)D(,)))
10: end for
Save the trained model h*
12: Detection Phase:
13: for each transaction T3 P do
14: Tokenize T, using T
15:
Randomly select 9% of tokens and mask them: Tý = Mask(T,,9)
16:
Use the trained model he" to predict the top-s tokens for each masked token position:
f
(f.,1 ....... f4 for 1,....
17: Calculate the failed prediction ratio (abnormality score) for Tj:
Score (T,)
T(4 & (4.1,,... (..1)
1=1
18:
end for
20

---

C Additional Details on Dataset
Here provide additional details on the dataset used in our experiments.
Dataset Statistics. Specifically, our Ethereum dataset consists of 3,383 benign transactions for training. 709 benign transactions for testing, and 10 malicious transactions. The data was collected from October 2020 to April 2023. For Solana, our training dataset comprises 35, 15,115 transactions, while the testing dataset includes 1,500 benign transactions and 18 malicious transactions. The Solana data is sampled in September 2023 and December 2023, spanning a two-month period due to the availability of transaction data. To mitigate the risk of data leakage, transactions occurred after the sampling periods benign transactions. This approach guarantees that the model is trained solely known benign transactions up to the cutoff dates, preventing any inadvertent exposure to future anomalous patterns during training.
ensured that the malicious
Address Frequency. To balance training efficiency and information retention, we rank all unique addresses the dataset by frequency and retain only the top 7,000 addresses for training. For Ethereum, this covers the majority of unique addresses, with the remaining addresses appearing just once in the training set. For Solana, the dataset contains 56,203 unique addresses, and retaining all of them would significantly increase the embedding size, making training computationally infeasible due to the high resource demands. Notably, the addresses excluded from the top 7,000 in Solana appear fewer than 10 times in the training set, contributing minimally to the overall information.
there only 7,335 addresses in total,
High-frequency addresses typically correspond to smart contracts, token addresses, other entities that are frequently accessed and more significant for classification tasks. Conversely, low-frequency addresses, such as individual user wallets, often carry less relevance for anomaly detection. Including these low-frequency addresses would increase model complexity and training time without yiclding significant performance gains. By focusing the most frequent 7,000 addresses, we ensure practical trade-off between training efficiency and the retention critical information for effective anomaly detection.
Potential Duplication in Transaction Data. Contract templates are wildly used in real-world smart contract development, leading to different smart contracts may offering similar or even identical APIs to the users. This could cause potential duplication the transaction data. To assess the extent of this issue, we conduct 5-gram BLEU similarity analysis on our dataset, choosing 5-gram to avoid false positives caused by indicator tokens such as "[START]" and "[CALL]." Our analysis reveal that only 0.05% of transaction pairs in the Ethereum dataset exhibit BLEU similarity exceeding 0.7, with 0.023% surpassing 0.8. These highly similar transactions may indeed result from the use of contract templates. Given the low similarity ratio in our data, we do not consider potential duplication a significant issue.
D Detailed Experimental Results
D.1 Implementation Details
Our method We detail the hyper-parameters and training process of our customized language models, each trained from seratch for either the Solana Ethereum tasks. Recall that for the Solana dataset, the model is based on a BERT-large architecture, with a hidden dimension of 1024, 24 hidden layers, and 16 attention heads. For the Ethereum dataset, the model uses BERT-base architecture, with a hidden dimension of 768, 12 hidden layers, and 12 attention heads. The complete set of training hyper-parameters is detailed in Table 4 and Table 5, The Solana model was trained over two days using eight A 100 GPUs, while the Ethereum model required around 2 hours of training on the same hardware.
Baselines We employ four baseline methods: BlockGPT, Doc2 GPT-4o, and Heuristic. For BlockGPT, as the source code was unavailable, we contact the author and implement BlockGPT based on their guidance. For the Doc2Vec approach, as described by [7], we first apply Doc2Vec [30] to extract features from the pre-processed and flattened traces of training transactions, as is shown in Figure 1. After obtaining the feature representations, we build GMM to model the training
21

---

config
value
config
value
optimizer
Adam [33]
optimizer
Adam
base learning
5c-5
buse learning rale
5e-5
weight decay
0.0
weight decay
0.0
gradient accunulation step
gradient accumulation step
optimizer momentum
0.9,
optimizer momentum
9.
92 0.9, 0.999
batch size
butch size
20
learning rate schedule
cosine decay
learning schedule
decay
wamnup epochs
warmup epochs
10
total epochs max sequence length
10
total epochs sequence length
8192
1024
Table 4: Configuration of training setup on Solana.
Table 5: Configuration of training setup on Ethereum.
transactions' distribution using the Sklearn library [34] with default apper-parameters.. During evaluation, for each transaction, extract its feature using Doc2 Vec and computed its anomaly score as the negative log-likelihood under the GMM. For the heuristic method, the anomalous score of given transaction is determined by the sequence length of the corresponding flattened traces, with longer traces indicating a higher probability of anomaly behavior. For GPT-4o,, we use the above prompts to instruct the LLM give score between 0 and 100. We use chain-of-thor of-th-of-thought (COT) [35] prompting to further improve the performance of GPT-4o. Additionally, we integrate human prior knowledge into the LLM by providing it with the list of known anomalous patterns help it make more accurate predictions.
Prompt for GPT-40 method
You are blockchain security expert tasked with determining whether given blockchain transaction is anomalous. Please evaluate the transaction step by step and consider the following aspects:
Analyze the sender and recipient addresses to check if they have been involved known anomalous activity.
Assess the transaction value and fee to identify any unusual patterns that might indicate suspicious behavior.
3. Examine the transaction's 's input data, including any smart contract interactions, to see they match known attack vectors.
Consider the timing and frequency of the transaction relative to previous transactions from the same address.
Assign a score between O and 100, where 0 means completely benign and 100 means highly anomalous. Provide clear explanation of the reasoning behind your score. Finally, return the result in the following JSON format:
#json
"reasso":: "Detailed explanation why the transaction is considered anomalous or benign.", "score": "A number between and 100 representing the likelihood of the transaction being anomalous."
Transaction details: [Insert transaction data here]
D.2 Additional Experiments
Post- Detectiecn Methods. As mentioned in $4.1, also explore post-detection methods using a one-class contrastive learning approach. Specifically, we apply SimSiam style [36] contrastive learning algorithm on top of the pre-trained BERT backbone to obtain more robust representation of the transactions. We then apply kernel density estimation (KDE) on the resulting representations to determine which transactions are anomalous. We provide detailed explanation of this method below.
Feature Extraction. We first take each transaction T; (from the Ethereum dataset in this experiment) and tokenize using the trained tokenizer T. We then feed the token sequence into our pre-trained BERT model, denoted as M to obtain feature vector e, In practice, consider two ways to
22

---

k=5
k=10
k=15
Method
FPR
Recall
Precision
FPR
Recall
Precision
FPR
Recall
Precision
<CLS>-CLL
0.28%
30%
60%
0.28%
80%
80%
0.85%
90%
60%
Average-CI.
0.14%
40%
80%
0.28%
80%
80%
0.97%
80%
53.33%
BlockScan
0%
50%
100%
0.28%
80%
80%
0.97%
80%
53.33%
Table 6: Performance comparison of different post-detection methods for Ethereum.
k=5
k=10
k=15
Model
FPR
Recall
Precision
FPR
Recall
Precision
FPR
Recall
Precision
GPT-4o 0.28%
30%
37.5% 37.5%
0.98%
30%
23%
1.55%
40% 40%
21%
GPT-44-FT
0.28%
30%
0.98%
30%
23%
1.55%
21%
Table 7: Performance comparison of fine-tuned GPT-4o and GPT-4 Ethereum for various k: values.
derive e;:
(CLS) M- (Ti)
(avg)
Σ EET:
BERT M- (t),
(CLS)-token
where e; (CLS), embedding at the <CLS> token position, and e; (avg) is the average of all token embeddings in T; We refer to these two modes <CLS>-CL and Average-CL, respectively.
SimSiam Contrastive Learning. To further refine these representations, trastive learning approach to e; Specifically, we consider all samples from the training set positive examples, they represent benign transactions, and our goal is to learn a unified representation of these transactions. Consequently, since no negative samples are involved, we adopt the SimSiam contrastive learning framework. The overall SimSiam objective for positive pair (i, )) is then:
apply one-class con-
Cstam (M)((((e))) + (((
Here, f is projection head (a one-layer MLP) and h is prediction head (another one-layer MLP). D is the negative cosine similarity.
KDE-Based Anomaly Scoring, After the one-class contrastive learning, we obtain a refined feature vector f(e,) for each transaction. We then fit Kernel Density Estimation model with RBF kernel parameter y on the training set (f(e:) to estimate the density of a given transaction T). Formally, have
KDE, (T,) = log
Σ exp (->llf(e;) - f(e)))l f(e.)
lower density score for transaction indicates a higher probability of Tf being anomalous. Comparison with Our Masked Prediction Approach. We evaluate two variants this alternative pipeline:
(CLS)-CIL, which uses the (CTSS)-token embedding as
Average-CL. which uses the average of token embeddings for e,,
As shown in Table 6, neither of these one-class contrastive learning methods yields stronger detection performance than our main masked prediction-bar approach, BlockScan. Given the extra complex- ity and computational overhead of contrastive training plus KDE, simpler masked reconstruction strategy remains preferable in practical settings. Therefore, BlockScan defaults to the masked prediction post-detection procedure, which is straightforward, lightweight, and empirically more effective.
Additional details on hyper-parameter settings (e.g., MLP dimensions, RBF kernel parameter 7) are provided in our anonymous repository htttps://gtthbb com/nuwuxian/te /ttx fm for repro- ducibility.
23

---

1=5
k=10
k=15
Model
Precision
Recall
Precision
Recall
Precision
No Noise
0%
50% 40%
100%
0.28% 0.56%
80% 60%.
0.97%
80% 60%
53.33%
With Noise
0.14%
80%
60%
1 1.26%
40%
Table 8: Performance comparison of models with and without noise for Ethereum for various values.
Dataset
Training Time
GPU Memory Usage (GB)
With FlashAttention
Without FlashAttention
With FlashAttention
Without FlushAttention
Ethereum
7,042
9,415
41.5
78.4
Solana
170,210
79.4
Table 9: Impact of FlashAttention training time and GPU memory usage for Ethereum and Solana datasets.
k=S
k=10
k=1S
Model
FPR
Recall
Precision
FPR
Recall
Precision
FPR
Recall
Precision
DeBERTa RoBERTa
0%
50% 50%
100%
0.28% 0.28%
80% 80%
80% 80%
0.97%
80% 80%
53.33%
0%
100%
0.97%
53.33%
Table 10: Performance comparison of different base models Ethereum for various values.
Fine- Fine-Tuning GPT-4o. We fine-tune GPT-4 (version 2024-08-06) using the Ethereum dataset to evaluate its performance domain-specific tasks following BlockGPT's approach. However, method deviated from traditional loken-by-token iteration approaches due to the limitations of OpenAl's fine-tuning API, which supports only instruction-response style fine-tuning. Instead, divide each benign transaction into two halves: the first half' served as the input, and the second half the target response. This method aimed enable the model predict transaction details. The егrоr between the predicted and actual transaction is used as the anomaly score. We summarize the results in Table 7.
The results indicate no significant improvement over the default GPT-4o model. Several factors may contribute this outcome:
Training Budget Constraints: Our fine-tuning costs approximately $950, limiting the number training iterations.
Coarse-Grained Approach:
The half-half prediction strategy may not have captured the intricate details of transaction patterns.
Tokenization Challenges: GPT-4o's default tokenization struggles with specific data types, such blockchain addresses and numerical patterns, reducing its ability to learn precise representations.
To overcome these limitations, future efforts could include:
Developing more fine-grained fine-tuning strategies.
Exploring additional tools to preprocess blockchain-specifi inputs, such as addresses and numbers. Leveraging models with customizable tokenization and greater control over training objectives.
Robustness to Noise. We intentionally modified the training data to include 50% of the malicious transactions while keeping the rest of the data unchanged for the Ethereum dataset. As shown in Table the detection performance of BlockScan is still relatively good, achieving recall 60% for detection threshold k 10. These results demonstrate that our approach maintains robustness to reasonable level of noise and inaccurate information in the data.
D.3 Ablation Study
Impact of FlashAttention. To evaluate the impact of Flash Attentoto on the training efficiency and resource utilization of BlockScan, we conduct an ablation study on Ethereum and Solana datasets. The results are shown in Table 9.
24

---

The integration of FlashAttention significantly improves training efficiency by optimizing attention computation. For Ethereum, FlashAttention reduces the running time from 9,415 seconds to approxi- mately 7,000 seconds, as shown in the table. Additionally, it nearly halves the GPU memory usage, enabling more efficient use of hardware resources.
For Solana, the impact of FlashAttention is even more pronounced. Without FlashAttention, the model cannot handle even a batch size of I on an 80GB A100 GPU due memory constraints. With FlashAttention, the training process becomes feasible, allowing a batch size of while maintaining memory efficiency.
These results highlight the critical role of FlashAttention handling long sequences and enabling scalable training for large datasets without sacrificing detection performance. Also, enabling FlashAt- tention has no noticeable impact on the accuracy of the model for Ethereum, as it achieves the same detection performance optimizing computational efficiency rather than altering model representations or outputs. This study demonstrates that FlashAttention essential for enabling efficient training on long sequences and large datasets while maintaining detection performance.
the model without PlashAttention This aligns with its design goal of
Impact of Base Model. To ensure that the choice of the base model does not significantly influence the performance of our framework, we conducted additional experiments with alternative state-of-the- art BERT-like models, such as DeBERTa [32], on the Ethereum dataset. These models are selected for their outstanding ability in NLP tasks. As shown in Table 10, the results achieved with DeBERTa consistent with those of RoBERTa. This validation confirms that our framework is agnostic the architectures.
specific choice of base model, offering flexibility in adapting to other transformer- Future work may explore additional models to further generalize the framework's 's applicability.
Larger Dataset. We conduct another experiment by only using manually verified malicious trans- actions without cross-checking on Ethereum dataset conduct the experiment. The larger dataset is formed by 100 attack transactions belonging to 69 vulnerable contracts. We follow BlockGPT to categorize them based on the number of transactions interacting with the contract. We set the threshold (k) as < 0.01, < 0.1, < 0.5, < 1, I 10 of the total number of transactions interacting with each contract, and Top-1, Top-2. Top-3. The results are shown in Figure From the results, we can see that BlockScan achieves consistent better performance than BlockGPT, which validates the effectiveness of BlockScan detecting anomalous transactions within a larger dataset.
25

---

(a) BIockGPT Performance
Dutaset Size (Tecal Attacks
Percentage Runking Alarm Threshold (5)
Absolute Ranking Alarm Threshold
interacting vulnerable contracts)
Top-1
Top-2
Top-3
attacks)
Detected (Peroentage)
8 (57.1%)
(42.8%
(50.0%)
9 (64.2%)
Average false positive
8.1%
0.0%
1.0%
1,7%
Avengee
positives
100 999 bas (11 attacks)
Detected (Pereentage)
(36,495)
4 (36.49))
7
(27 3%)
(27.3%)
4 (36.4%)
Average falso positive rate
0,38%
1.00%
9.00%
0.0%
0.0%
0.0%
Average oom. of false positives
1,48
3.59
39.8
0.7
1.7
2.6
Detected (Pereentage)
(30.0%)
(40.0%)
8 (10.09)
14 (70.0%)
(25.0%)
(25.0%)
(30.0%)
Avenge false positive
0.02%
0.50%
1.00%
9.50%
0.0%
0.0%
0.0%
Avenge num, false positives
3.80
380.4
0.8
1:75
10000 Exs (24 attacks)
Detected (Pereentage)
(8.3%)
10 (41.7%)
(58.39))
(4.2%)
(12.5%)
Average false posilive rate
0.01%
0.12%
0.52%
0.98%
9.08%
0.0%
0.0%
0.0%
Average oum. of false positives
2.25
19.47
96.58
194.46
1942.79
1.0
2.0
3,0
Overall (69 attacks)
Detected (Percentage)
(8.3%)
(14.5%))
(31.9%)
Average false positive rate
0.02%
0.08%
0.50%
0.95%
9,50%
0.0%
0.0%
0.0%
Average of false positives
2.25
19.49
96.58
193.45
1942.79
0.8
1.7
2.7
(b) BlockScan Performance
Datoser Size (Tota) Attacks interacting vulnerable contract)
Peroentage Ranking Alarm Threshold (9)
Absolute Ranking Alamm Threshold
$0.1 0.1
S
S
Top-1
Top-2
Top-3
atlacks)
Detected (Percentage)
(85.719))
(64.2%)
12 (1%)
(85.719))
Average false positive miee
7.42%
0.0%
0.8%
1.4%
Average num. of false positives
3.35
0.3
1.1
2.1
100 999 txs attackss
(Percentage)
5%
(45.5%)
(72.739)
(36.4%%
(36.4%)
(45.5%)
Average false posilive rale
0.35%
1.00%
8.87%
0.0%
0.0%
0.0%
Aserage num. of false positives
1445
3.54
39.0
0.6
1.6
2.5
1000 9999 Ixs (20 altacha) (Percentage)
(40.0%)
(50.0%)
(80.0%)
(35.0%%
(35.0%)
Average false posilive rale
0.01%
0.18%
0.96%
9.05%
0.0%
0.0%
0.0%
Astrage num. of false positives
3.75
18.5
37,3
380.2
0.7
1.7
2.7
10000+ (24 allacks)
Detected
(20.99)
(50.0%)
(8.
(20.83))
Average positive
0.10%
0.985%
9.08%
0.0%%
10.0%
0.0%%
Average num. of false positives
2.20
19:41
96.54
193.45
1942.79
1.0
1.9
2.8
Overall attacks)
Detected (Percenings)
3 (4, (44%)
13 (18.845)
(36 235))
27 (39. 1398)
52 (75, 36%)
21 (30.439))
23 (33 33%)
29 (42 (42.025)
Average false positive rale
0.01%
0.08%
0.42%
0.9775
9.07%
0.0%
0.0%
0.0%
Average false
2.20
13.54
64.53
102.64
1063.36
0.7
2.7
Figure 2: Performance comparison of BlockGPT and BlockScan on the larger dataset.
26


Reviews:
[{"review_id": "6d6BIhCQnU", "reviewer": "Reviewer_4Xf4", "summary": "The paper introduces BlockScan, a customized Transformer model for detecting anomalous blockchain transactions in DeFi ecosystems. It proposes a novel multi-modal tokenizer to handle blockchain-specific data, leverages BERT with MLM, RoPE, and FlashAttention for efficient training, and achieves superior performance.", "questions": "Please see weakness part", "limitations": "Yes", "rating": 3, "confidence": 2, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 2, "clarity": 2, "significance": 2, "originality": 2, "strengths_and_weaknesses": "# Strengths\n1. Using models for testing under blockchain has certain practical significance\n\n2. The multi-modal tokenizer effectively addresses the complexity of blockchain data, balancing vocabulary size and information retention.\n\n3. Outperforms baselines significantly, especially on Solana, where other methods fail (0% recall).\n\n# Weakness\n1. The methodological design and underlying ideas presented in this paper are relatively straightforward, with only incremental innovation in terms of techniques and conceptual contributions. Specifically, the proposed approach does not introduce any architectural novelties; instead, it merely utilizes traditional architectures (e.g., BERT) in a concatenation-based manner. Despite this, a considerable portion of the paper is dedicated to methodological description. In my opinion, the manuscript would benefit from reallocating this space toward a more thorough and convincing evaluation of the proposed detector. This could include a broader range of comparative baselines as well as more diverse test sets.\n\n2. The comparison methods appear to be evaluated on different datasets than the one used by the proposed approach. It raises the concern that the superior performance of BlockScan might be largely attributed to the quality or construction of its dataset. Moreover, the paper does not clearly distinguish between the training and testing sets. If the proposed model is trained on a dataset that closely matches the distribution of the test set, while the baselines are evaluated on a distribution-shifted test set, the reported improvements could be due to this discrepancy rather than the efficacy of the method itself. The authors should provide a more detailed explanation and analysis to rule out this possibility and convincingly demonstrate that the performance gains are not merely artifacts of dataset alignment.\n\n3. The paper lacks a fundamental introduction to blockchain technology, which is a core component of the proposed approach. This omission significantly affects the readability and accessibility of the work, particularly for readers who may not be deeply familiar with blockchain concepts. A concise but sufficient background section is necessary to contextualize how blockchain is utilized and why it is integral to the proposed method.", "was_revised": false, "final_justification": "", "rebuttal": "We thank Reviewer 4Xf4 for the constructive and insightful comments. Please see our response to each of your questions below.\n\n> The methodological design is straightforward, and the approach does not have new model structure architectural novelties (Weakness 1).\n\n**Response:** \nThanks for pointing this out. \n\nOur core contribution is a novel, end-to-end system that addresses the blockchain data representation challenge, which includes:\n\n1.  **A Multi-Modal Tokenizer:** We designed a custom tokenizer to handle the distinct data types in a transaction (hashes, numbers, text logs). As shown in Table 3, simply applying a default tokenizer fails completely (0% recall), demonstrating that our domain-specific data handling is essential for the blockchain transaction data.\n    \n2.  **A Theoretically-Grounded Detection Method:** Our choice of using reconstruction error is not ad-hoc. As we analyze in Section 4, our formulation provides a theoretical analysis that anomalous transactions can yield a higher reconstruction loss, providing a formal justification to our approach.\n\nAs transformers have been widely used in different application domains, as well as its advantages over other neural architecture, we still use transformers in our system. We would like to kindly note that it does not dilute our contribution as we integrate non-trivial domain-specific technical designs as well as theoretical guarantees. \n\n> The comparison seems unfair as BlockScan might be trained on a dataset that matches the test set distribution, while baselines are evaluated on a distribution-shifted dataset. (Weakness 2)\n\n**Response:** We thank the reviewer for this insightful comment, and we appreciate the opportunity to clarify our evaluation methodology.\n\n**1. On the Necessity of a New Dataset:**\n\nWe created a new dataset for this study precisely because, to the best of our knowledge, there are no existing open-source datasets specifically for **chain-level temporal anomaly detection in DeFi applications on Ethereum and Solana** when we worked on this project. While datasets for other tasks like phishing account detection exist, they are not suitable for our problem. We did contact the authors of BlockGPT to inquire about their dataset as this work shares the same goal with us; however, they were unable to share it due to privacy concerns, which necessitated the creation of our own benchmark. We use different tools like Zengo, TRM Labs and CertiK to cross-check the transaction to ensure the quality of the dataset and we believe that open-sourcing this dataset could inspire further research for anomalous transaction detection on blockchain.\n\n**2. On Ensuring a Fair Comparison with Baselines:**\n\nTo directly address the reviewer's primary concern: **we did not report performance numbers or directly use trained models from other papers.** To ensure a rigorous and direct comparison, we re-implemented all baseline methods and trained and evaluated them on the **exact same training and testing data** as our BlockScan model. This is also because prior work like BlockGPT does not release their trained model and we are unable to directly use it. This approach guarantees that the reported performance is directly comparable across all methods and that the observed advantages of BlockScan stem from its methodological merits, not from a dataset artifact. \n\n**3. On Distinguishing Between Training and Testing Sets:**\n\nFor the dataset distribution, as we claimed in Section 5.1 and Appendix C, we ensured that the malicious transactions occurred after the sampling periods of benign transactions. It not only avoids the data leakage between training and testing sets, but also mimics the real-world setting (i.e., distribution shift through time).\n\n\n> The paper lacks a fundamental introduction to blockchain technology (Weakness 3)\n\n**Response:** Thanks for this feedback, and we will add it in our next version to make it easier to follow for the audience not familiar with blockchain."}, {"review_id": "flLsKXH9vN", "reviewer": "Reviewer_muq7", "summary": "BlockScan presents a comprehensive and effective approach to blockchain anomaly detection by integrating behavioral signals across different structural levels. It addresses challenges in scalability, label scarcity, and diversity of malicious behaviors. The framework is modular, empirically validated, and applicable to real-world blockchain monitoring scenarios.", "questions": "1.The group-level module uses Infomap community detection, which may have high computational overhead on large-scale blockchain graphs. How scalable is this component on blockchains with millions of accounts and transactions?\n2.The method is evaluated only on Ethereum and Tron. Can BlockScan generalize to other blockchains (e.g., BNB Chain, Solana), especially those with different transaction semantics or graph topologies?", "limitations": "As discussed above.", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths\n1.The paper introduces a well-structured framework that models anomalies at the account, transaction, and group levels.\nThis design reflects the hierarchical nature of blockchain ecosystems and captures diverse anomaly patterns.\n2.BlockScan outperforms strong baselines (e.g., GCN, MetaDetect, GAT, TransDetect) across multiple datasets (Ethereum, Tron) and evaluation metrics (AUC, AP). The method demonstrates consistent improvements in both supervised and semi-supervised settings.\n3.The use of self-supervised objectives (e.g., masked modeling, contrastive learning) effectively alleviates the scarcity of labeled anomaly data.\n\n Weaknesses\n1.The overall framework is novel, many core components (e.g., transformer encoder, contrastive loss, Infomap clustering) are reused from prior work without major innovation.\n2.Group-level modeling via community detection may not scale efficiently to large transaction graphs with millions of accounts — this is not analyzed in depth.\n3.The model is evaluated only on Ethereum and Tron. There is no discussion of how it generalizes to other blockchain networks (e.g., BNB, Solana) or unseen anomaly types.\n4.The paper focuses on performance metrics (AUC, AP) but lacks detailed analysis of failure modes, especially false positives, which are critical in real-world applications.", "was_revised": false, "final_justification": "", "rebuttal": "We thank Reviewer muq7 for the constructive and insightful comments. We would like to offer some clarifications on the specific points raised.\n\n> On Novelty and Core Components (Weakness 1/2 & Question 1)\n\n**Response:** We appreciate the reviewer's comments on novelty. Sorry for the confusion.  Our approach does not utilize contrastive loss, Infomap clustering, or any form of group-level community detection. Consequently, concerns about the scalability of Infomap on large graphs do not apply to our work.\n\nOur primary novelty lies in **the end-to-end system for representing and analyzing individual transactions.** The core technical contribution is our **multi-modal tokenizer**, which is specifically designed to decompose complex blockchain transactions into components (hashes, numerical values, and text logs). As our ablation study in Table 3 shows, this domain-specific representation is critical—without it, the model fails to learn effectively(the recall is 0%). \n\n> On Evaluation and Generalizability (Weakness 3& Question 2)\n\n**Response:** Regarding the evaluation, we would like to clarify that our experiments were conducted on **Ethereum and Solana**, not Tron. We believe the inclusion of Solana is a key strength of our evaluation, as it is a non-EVM chain with a fundamentally different transaction architecture and data semantics from Ethereum. The strong performance of BlockScan on both platforms demonstrates its ability to generalize across heterogeneous blockchain ecosystems.\n\nWe agree that evaluation on additional platforms like BNB Chain would be valuable. However, the effort needed for data collection and potential model retraining is non-trivial. As such, we believe it is reasonable to treat this as future work.\n\n> On analysis of Failure Modes (Weakness 4)\n\n**Response:** Thanks for this valuable feedback. In our revision, we will add a dedicated subsection to analyze these cases.\n\nTo provide a concrete example, one type of failure mode we observed involves **rare but benign transaction structures**, which can lead to false positives. Our model defines an anomaly as a significant deviation from the patterns learned in the training corpus of benign transactions. Consequently, a benign transaction that is structurally unique can be incorrectly flagged.\n\nFor instance, we analyzed a case where a benign transaction was assigned a high anomaly score. This transaction's purpose was to perform a one-time, protocol-wide parameter update, and it had two key characteristics:\n\n1.  **Unusually Long Input Data:** The function call contained a very long list of arguments, far exceeding the typical number seen in common user transactions like swaps or deposits.\n    \n2.  **Novel Event Logs:** The transaction emitted a series of unique event logs specific to this upgrade process.\n    \n\nBecause our model was trained on standard transactions, it had learned that \"normal\" behavior involves shorter argument lists and familiar log patterns. When tokens within this rare transaction were masked during detection, the model struggled to reconstruct them accurately. The unfamiliar context (the long sequence of parameters and novel logs) resulted in a high reconstruction error, causing the system to flag this perfectly valid transaction as anomalous.\n\nThis analysis highlights a key trade-off: the model's sensitivity to novel malicious patterns also makes it sensitive to novel benign ones. In our revised manuscript, we will discuss this limitation and suggest potential mitigation strategies, such as periodically fine-tuning the model on a curated set of a protocol's own recent transactions, especially after deploying new smart contracts or performing rare administrative actions. This would help the model adapt to a protocol's evolving patterns and reduce such false positives."}, {"review_id": "aV4McSUWBc", "reviewer": "Reviewer_HVd1", "summary": "BlockScan integrates BERT-like pre-training techniques for detecting anomalies in blockchain transactions. The main specialized efforts lie in a multimodal tokenizer to handle high-frequency addresses, numeric values, and log text separately, and leverages mask language modeling for computing reconstruction errors. Some techniques like RoPE, FlashAttention are also adopted to enhance efficiency.", "questions": "Please address the main weakness outlined in the “Strengths and Weaknesses”. The final score will be adjusted based on the rebuttal.", "limitations": "Yes.", "rating": 5, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 2, "originality": 2, "strengths_and_weaknesses": "Missing key reference: I found that there is a similar paper named BERT4ETH[1] that has already applied BERT-like pre-training technique for blockchain transactions two years ago, yet it is neither cited nor discussed in the related work. Based on my reading, there appear to be some similarities between BERT4ETH and BlockScan: both randomly mask tokens in transactions and compute reconstruction errors; both include mechanisms to handle high-frequency addresses. Given this, I strongly recommend that the authors explicitly discuss BERT4ETH in the related work section and clearly articulate the unique contributions of the proposed BlockScan.\n\n[1] Bert4eth: A pre-trained transformer for ethereum fraud detection. Proceedings of the ACM Web Conference 2023. 2023.", "was_revised": true, "final_justification": "I changed my rating to accept based on the authors' efforts and commitments in the rebuttal.", "rebuttal": "We sincerely thank the reviewer HVd1 for bringing this prior work to our attention. We will add a thorough discussion of it to our related work section in the revision.\n\nTo address the reviewer’s concern, we present a detailed comparison below. While both works apply BERT-like models to blockchain data, they target fundamentally different tasks, and as a result, employ distinct methodologies.\n\nThe most fundamental difference lies in the **task definition and input granularity**:\n\n-   **BERT4ETH** focuses on **account-level fraud detection** (an inter-transaction task). Its goal is to classify an account (EOA) as fraudulent or legitimate by analyzing its entire transaction history. The input is a sequence of transactions aggregated at the account level.\n    \n-   **BlockScan** focuses on **single-transaction anomaly detection** (an intra-transaction task). Its goal is to assess if a single, specific transaction is anomalous based on its internal logic and structure, without needing the account's full history. The input is the fine-grained sequence of operations within one transaction.\n    \nThis core difference in objective informs all subsequent design choices, leading to two distinct systems:\n\n**1. Transaction Representation:**\n\nBER4ETH constructs input sequences by aggregating all transactions involving a given EOA, either as sender or receiver, and sorting them by descending timestamps. Each transaction is represented as a single token by extracting only several features (e.g., address, timestamp and amount, account type, and in/out type) and summing their embeddings, which limits the model’s capacity to capture internal transaction details and may result in the loss of critical information. In contrast, BlockScan explicitly models the internal structure of each transaction by decomposing it into fine-grained components—such as function and address signatures, logs, and numerical arguments—represented as a sequence of tokens. This design enables richer and more expressive feature representations, allowing our model to detect subtle anomalies that BER4ETH’s coarse-grained approach may overlook.\n\n**2. Detection Method and Supervision:**\n\nBER4ETH employs a two-stage pipeline, where the model is first trained via self-supervised masked prediction and then fine-tuned using labeled data to classify transactions (see Section 5.11 in BER4ETH). In contrast, our method directly detects anomalies using reconstruction accuracy, without requiring labeled data. Furthermore, we provide theoretical justification in Section 4, showing that malicious transactions have a provably higher upper bound on reconstruction loss than benign ones—offering principled support for our design.\n\n**3. Masking Strategy:**\n\nWhile both methods employ token masking during pretraining, BER4ETH restricts masking to address information and increases the masking ratio to elevate task difficulty and encourage stronger representations. In contrast, we use the default 15% BERT masking ratio and apply it randomly across various token types (e.g., large numbers, logs, or addresses) to learn the general patterns of a transaction's structure. This approach proves effective in our setting due to the higher token density resulting from fine-grained decomposition, making our masking strategy more efficient and semantically meaningful.\n  \n**4. Handling High-Frequency Addresses:**\n\nThe two methods differ in their treatment of high-frequency addresses due to differing goals. BlockScan retains the 7,000 most frequent addresses in its vocabulary, mapping less frequent ones to a single “OOV” token to control vocabulary size and reserve capacity for other informative tokens such as large numbers or logs. In contrast, BER4ETH tackles the skewed, power-law address distribution by applying frequency-aware negative sampling—treating high-frequency addresses as negatives in the contrastive loss to mitigate their overrepresentation. This reduces unintended similarity between unrelated accounts and enhances sensitivity to rare addresses, which are often more indicative of fraud. These design choices reflect different priorities: BlockScan emphasizes semantic richness at the token level, while BER4ETH focuses on representation learning under skewed distributions.\n\nIn summary, our work significantly differs from BERT4ETH in various aspects. Moreover, our work has a theoretical analysis for our method while the BERT4ETH does not. We are confident that this could address the reviewer’s concern, and we appreciate the reviewer for this insightful feedback."}, {"review_id": "eBx856b8fq", "reviewer": "Reviewer_kEQo", "summary": "This paper proposes BlockScan, a new transformer-based anomaly detection framework for blockchain transactions. The authors develop various customization methods to improve the representation learning of the multi-model, complex data blockchain transactions. To detect anomalies in one chain, BlockScan uses the reconstruction error of the transaction as the metric. Empirical results and comparison with other detection methods show that BlockScan achieves better detection accuracy and lower false positives.", "questions": "Please consider addressing the weaknesses discussed above.", "limitations": "Please consider addressing the weaknesses discussed above.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "This paper has the following strengths:\n+ The authors develop customized pre-processing methods to handle hash values, numbers, and logs in the transaction data. \n+ The authors improve the capability of long sequence processing with RoPE embedding and FlashAttention. \n+ The authors provide theoretical proof for the anomaly detection hypothesis that the reconstruction error of anomalous transactions is higher than the error of benign transactions.  \n\nThis paper has the following weaknesses:\n- The experiments section mentions that the collected transactions are processed by a per-application sequential split. This implies that BlockScan obtains one customized anomaly detection model for each application. However, there are diverse applications running on Ethereum or Solana. It's not clear whether BlockScan is scalable considering the volume and diversity of applications.  \n- While the authors explain that the trade-off can be explored by selecting different values for the hyperparameter k, there is no clear guidance about how to choose the k value (nor the mask ratio g) in a practical setting.", "was_revised": false, "final_justification": "", "rebuttal": "We thank Reviewer kEQo for the constructive and insightful comments. Please see our response to each of your questions below.\n\n> BlockScan obtains one customized anomaly detection model for each application. (Weakness 1)\n\n**Response:** We thank the reviewer for this important question regarding scalability. Sorry for the confusion.. **We train a single, unified model for each blockchain (one for all Ethereum applications and one for all Solana applications), not a separate model per application.**\n\nThe \"per-application sequential split\" mentioned in Section 5.1 refers to a rigorous data preprocessing step we took to ensure the integrity of our evaluation. Before pooling benign transactions from all applications into a single training set, we first split the benign transaction data based on timestamps (80% for training, 20% for testing) to avoid the data leakage. After this time-aware split, all the training data from the different applications are combined to train the single, unified model.\n\nWe recognize that our wording may have led to this confusion, and we will revise Section 5.1 to make this training process more explicit for our readers.\n\n> No guidance about how to choose the k value and g value (Weakness 2)\n\n**Response:** Thanks for this valuable question, and we are happy to clarify.\n\n**For the mask ratio g:**  \nOur ablation study in Table 3 demonstrates that the model's performance is robust to variations in this parameter within a reasonable range [5%, 15%]. We found that a value of g = 15% consistently provides a good detection accuracy, and we recommend it as a reliable default setting.\n\n**For the detection threshold k:**  \nThe parameter k directly controls the trade-off between detection sensitivity (Recall) and the false alarm rate (FPR). The optimal value is application-specific and depends on the risk tolerance of the protocol. We recommend the following practical procedure for setting k in a real-world scenario:\n\n1.  **Prepare a Labeled Validation Set:** The developer should first curate a held-out validation set that contains both a large number of benign transactions and a representative set of known malicious or anomalous transactions.\n    \n2.  **Score and Rank Transactions:** Run the trained BlockScan model on this entire validation set to obtain an anomaly score for every transaction. Then, rank all transactions from the highest score (most anomalous) to the lowest.\n    \n3.  **Establish Initial k for Full Recall:** Identify the rank of the lowest-scoring malicious transaction in a validation set that mimics the real-world setting. The initial value for k should be set to this rank. This establishes a baseline threshold that ensures 100% recall on the set of known threats.\n    \n4.  **Adjust k Based on Risk Tolerance:** With this initial k, calculate the corresponding FPR. If this FPR is high, the developer can make a risk-based decision. They can analyze the anomalies that received lower scores (i.e., those near the detection threshold) and determine if some can be tolerated. By accepting that some less critical anomalies might be missed, they can select a smaller k to achieve a more manageable FPR, thus making an explicit trade-off between security and operational cost.\n\n    \nWe believe this guidance makes the deployment of BlockScan more practical. We will add a dedicated subsection to the Appendix to formalize this procedure for future practitioners. Thank you for this valuable suggestion, which helps improve the practical utility of our paper."}]

Author rebuttal:

Meta-review: This paper proposes a Transformer-based model for anomaly detection in blockchain transactions. It introduces a multi-modal tokenizer, a customized masked language modeling strategy, and a theoretically grounded detection method. The paper demonstrates strong empirical performance, especially on Solana, and claims to outperform existing baselines.
Strengths
1.	The multi modal tokenizer addresses the unique statistical and semantic properties of transactions; ablation studies indicate default tokenization collapses (e.g., 0% recall). 
2.	Using MLM reconstruction error with associated theoretical justification provides a clean, label efficient route to anomaly scoring. 
3.	Evaluation spans Ethereum (EVM) and Solana (non EVM) with differing semantics and data layouts. 
4.	Authors reimplemented baselines and trained/evaluated them on identical splits, which provides a fair/rigor comparison. 
5.	Clarifications include training one unified model per chain (not per application) and a concrete procedure for setting mask ratio and detection threshold in practice.
Weaknesses
1.	The detector builds on standard BERT style pretraining, and its novelty is mainly incremental which centers on data representation and deployment framing.
2.	An important related work (BERT4ETH - BERT like pretraining for blockchain) was initially missing. This paper needs a thorough comparative discussion in the camera ready. 
3.	Prior to rebuttal, there was limited failure mode analysis (e.g., false positives on rare but benign administrative transactions). Authors promised an expanded section; it should appear in the final version.
4.	A succinct blockchain primer is missing, which hinders readability for non specialists. The authors agreed to add one.
Most important reasons for my decision
•	The proposed model is practical, and it is useful for Web3 security monitoring. 
•	The authors convincingly addressed most concerns of Reviewers.
Decision: Accept (poster)