# Deep Smart Contract Intent Detection

Youwei Huang1,2, Tao Zhang1,∗, Sen Fang1, Youshuai Tan1 and Jiachun Tao2
1Macau University of Sicence and Technology, Macao SAR
2Institute of Intelligent Computing Technology, Suzhou, CAS, China
<EMAIL_ADDRESS>
*corresponding author

###### Abstract

Nowadays, security activities in smart contracts concentrate on vulnerability
detection. Despite early success, we find that developers’ intent to write
smart contracts is a more noteworthy security concern because smart contracts
with malicious intent have caused significant financial loss. Unfortunately,
current approaches to identify the aforementioned malicious smart contracts
rely on smart contract security audits, which entail huge manpower consumption
and financial expenditure. To resolve this issue, we propose a novel deep
learning-based approach, SmartIntentNN (Smart Contract Intent Neural Network),
to conduct automated smart contract intent detection.

SmartIntentNN consists of three primary parts: a pre-trained sentence encoder
to generate the contextual representations of smart contracts, a K-means
clustering method to highlight intent-related representations, and a
bidirectional LSTM-based (long-short term memory) multi-label classification
network to predict the intents in smart contracts. To evaluate the performance
of SmartIntentNN, we collect more than 40,000 smart contracts and perform a
series of comparison experiments with our selected baseline approaches. Our
experimental results demonstrate that SmartIntentNN outperforms all baselines
by up to 0.8212 in terms of the f1-score metric.

###### Index Terms:

Smart Contract, Intent Detection, Automated Software Engineering, Deep
Learning

##  I Introduction

Web3 is a technical term [1, 2, 3] that Gavin Wood111https://gavwood.com
firstly coined under the context of Ethereum[4, 5, 6], it refers to
decentralized applications (DApps) that run on the blockchain[7]. As an
infrastructure for DApp development, a smart contract is defined as a computer
program and a transaction protocol to automatically execute, control, or
document legally relevant events and actions according to the terms of a
contract or an agreement[8, 9, 10, 11, 12, 13]. Generally, users can interact
with smart contracts by sending transactions to invoke functions. From the
perspective of computer programs, current studies on the security of smart
contracts mainly focus on the detection of vulnerability or defect. However,
as transaction protocols, smart contracts can also contain malicious
intentions. Based on the above two natures of smart contracts, we divide the
risks of smart contracts into two categories: external risks and internal
risks.

What are external risks? If we analyze smart contracts from the perspective of
computer programs, their risks are mainly concentrated in vulnerability
exploitation[14]. Several vulnerable smart contracts exploited by attackers
have been extensively studied, such as the infamous DAO attack caused by
reentrancy vulnerabilities[15], inconsistencies bugs led by unchecked
exceptions[16, 17, 18], and making an invalid account balance or creating an
infinite loop by integer overflow or underflow of a variable[19]. More
vulnerabilities in smart contracts are summarized by _He et al._ ’s team[20].
In addition to vulnerability exploitation, DoERS (Denial of Ethereum RPC
service) is another attack behavior against node services in a blockchain
network, which can drop the remote procedure call (RPC) service[21]. We regard
the above types of attacks from the external of DApps by exploiting the
weaknesses of smart contract code or blockchain network service as external
risks.

Figure 1:  Some code snippets of a smart contract, where the developer embeds
several functions with intentional risks. Binance smart chain address:
0xDDa7f9273a092655a1cF077FF0155d64000ccE2A.

What are internal risks? In a real-life scene, malicious terms generally exist
in legal contracts which can cause the loss of users’ interests. Considering
that the smart contract is a transaction protocol designed by human beings, we
find that harmful terms also exist in smart contracts, in the form of computer
code. According to our investigation, in recent years, more and more risks are
intentionally designed by smart contract developers or DApp creators
themselves[22, 23]. A scam DApp purposely injects malicious code, such as
tricks and backdoors, into the smart contracts to misappropriate users’
funds[24]. As shown in Fig. 1, it gives several intentional risk samples in a
real-world smart contract. From the figure, we can observe that all functions
contain the same modifier: onlyOwner, which means that they are ownership
centralized. For instance, if adding the modifier onlyOwner to the function
changeTax, a development team can, and only they can, arbitrarily change the
tax fee for swapping the assets in a smart contract. Similar to changeTax,
teamUpdateLimits added onlyOwner can give the developer the right to modify
various limits for transactions. As for the remaining two functions, they
express an even more dangerous development intent that allows the owner
directly turn on or off the trading function in the smart contract. We define
these risks owing to developers’ malicious intents as internal or intentional
risks.

What is our research? Internal risks of smart contracts have caused more and
more economic losses, but the current detection of malicious smart contracts
relies on smart contract security audits, which entail huge manpower
consumption and financial expenditure[25]. Unfortunately, all existing work
focuses on the research of external risks of smart contracts by detecting and
exploiting the smart contract vulnerabilities or blockchain network defects.
It motivates us to propose a new approach to implement automated smart
contract intent detection, to detect whether a smart contract is injected with
malicious intents by developers as well as distinguish these intents.
Specifically, we present SmartIntentNN, a deep learning model that combines
sentence embedding, intent highlight, and bidirectional long-short term memory
(BiLSTM)[26, 27]. SmartIntentNN is a multi-label classification model
implemented with Tensorflow.js[28, 29] that can detect ten categories of
malicious intents (see details in Table I) in smart contracts, by retrieving
their contextual information.

To evaluate the performance of SmartIntentNN, we collect a dataset with more
than $40,000$ smart contracts developed in Solidity[30], each of which is
labeled with none or multiple malicious intents. Before passing smart
contracts into our model, we perform pre-processing on it, including removing
non-logic code, removing comments, and generating the code tree for each smart
contract. Then, we utilize a pre-trained sentence encoder[31] to transfer each
function in smart contracts into a context vector that can be further learned
by neural networks. To help the neural network learn the representations
better, we pre-train an intent highlight model based on K-means to predict the
strength of the intent in smart contracts. Finally, we perform the multi-label
classification for smart contracts through a deep neural network (DNN). We
compare SmartIntentNN with other baseline models, e.g., LSTM, and the
experimental results demonstrate that SmartIntentNN outperforms all compared
approaches with the highest f1-score metric of $\bm{0.8212}$ and can
effectively identify smart contracts with malicious intents as well as point
out their types.

Our contributions can be listed as the following points:

  * •

To the best of our knowledge, this is the first work to propose an approach to
implement automated smart contract intent detection, which can detect
developers’ risky intents injected in a smart contract;

  * •

We utilize a universal sentence encoder, an intent highlight model based on
K-means, and a BiLSTM-based DNN to implement the automated approach for smart
contract intent detection, namely SmartIntentNN;

  * •

We collect an extensible dataset of smart contracts with intent labels for
smart contract intent learning;

  * •

We publish our research source codes, datasets and
documents222https://gitlab.com/web3se/smartintent.

##  II Motivation

Why is it essential to identify the developers’ intent in smart contract
development? – For the love of money is the root of all evil. In conventional
web software development, developers’ intent is a rarely mentioned concept
since conventional applications are released by a trustable centralized party.
They are responsible for processing the code logic and guaranteeing the
software quality. Additionally, conventional applications make money by
providing high-quality software services to users, and they do not build their
cryptocurrency systems. By contrast, Web3 applications are decentralized and
value-driven, which means that any developer can deploy a smart contract and
promote it to users for financial purposes. More importantly, smart contracts
contain their own economic systems, which are tied to real-value
cryptocurrencies (e.g., Bitcoin), which may have a potential risk: when a
smart contract reaches a high value333A simple way to estimate the value of a
smart contract is to calculate its TVL, referring to
https://learn.bybit.com/defi/total-value-locked-tvl., greedy developers can
steal or dump users’ crypto value by executing the preset malicious code.
Therefore, in DApp development, the developers’ intent is worth our attention.

Did the developer’s malicious intent really cause financial damage? According
to the statistics from 2022 crypto crime report from Chainalysis[32],
cryptocurrency-oriented scammers have stolen around $\$7.8$ billion worth of
cryptocurrency from victims, over $\$2.8$ billion of which is from rug pulls.
A rug pull means that developers conduct unfair transactions by invoking the
preset malicious functions injected in smart contracts, to illegally withdraw
the funds from a smart contract address, or unpair the liquidity pool and
appropriate the valuable part[33]. Compared to the statistics released in
2020, the losses in 2021 rise $82\%$. _Torres et al._ ’s investigation has
found that $690$ smart contracts of honeypots bring an accumulated profit of
more than $\$90,000$ for the creators. In the real world, most users are not
experts, and they cannot understand any programming code. They just trust
these DApps and invest in them, but eventually become the victims of these
programs. Therefore, smart contracts with malicious intent can cause
substantial economic losses to the users.

Why do we propose an automated intent detection tool for smart contracts? For
a developer, reusing smart contract code, cloning code, and importing other
contracts are common behaviors in Web3 development. To the development
behavior with malicious intent, we think that it is necessary to develop an
automated tool for supervising these developers, preventing such intents into
real actions. Such an automated tool can also help developers to distinguish
smart contracts from malicious intents when they reuse third-party smart
contracts. Currently, the smart contract security audit is an effective way to
identify malicious smart contracts. However, the audit service is incredibly
expensive and time costly because it is manual work completed by experts. Thus
an automated audit tool has the practical sense to reduce the development cost
in terms of time, labor power, and money.

##  III Background

In this section, we introduce background knowledge, including smart contracts
with malicious intents, sentence embedding, and bidirectional LSTM.

###  III-A Malicious Smart Contract Intent

Smart contracts enable everyone to interact online via a blockchain network.
Taking Ethereum blockchain, the most popular smart contract operation
platform, as an example, we discuss how a developer grab benefits from the
users by injecting malicious intents into a smart contract. Ethereum, or
Ethereum-like blockchains are essentially transaction-based machines.
Deploying smart contracts and invoking smart contracts are both transactions.
Two types of addresses are stipulated on Ethereum: externally owned accounts
(EOA) address and contract address. To complete a transaction, an EOA address
pays a kind of native cryptocurrency, called ether (ETH) as the gas fee, which
is the valuable crypto asset.

Figure 2:  A description of developers illegally grabbing benefits from users
by developing and deploying smart contracts with malicious intents.

As indicated in Fig. 2, both a developer and a user own EOA addresses. The
developer develops a smart contract and compiles it to the bytecode, a low-
level computer language executable on Ethereum Virtual Machine (EVM)[34].
Then, the developer signs a transaction with a private key and sends it to
deploy the bytecode to the Ethereum network. A smart contract address is
generated after the transaction succeeds. There is a reward function
implemented in this smart contract to attract users. This function allows
users to stake ETH to harvest a certain amount of rewards, such as NFTs (non-
fungible tokens)[35]. A user sends a transaction to invoke the deposit
function and pays $10$ ETH to the contract address. Then, the user invokes the
reward function and receives the NFTs. However, the developer can easily steal
the user’s $10$ ETH by invoking a withdraw function. All the above
transactions are packaged into blocks and blocks are chained together through
a cryptographic hash. As a result, the victim’s money (ETH) can never be
retrieved.

###  III-B Sentence Embedding

Embedding (also known as distributed representation)[36] is a technique for
learning dense representations of entities such as words, sentences, and
images. Compared to word-level embeddings, such as word2vec[37] and GloVe[38],
Universal Sentence Encoder (USE) is a sentence-level[39] encoder that
generates sentence embeddings by aggregating the word representation in a
sentence.

USE takes a sentence as the input and outputs a contextual representation of
the sentence. It enables similar sentences to be close in its generated vector
space[36, 40]. In this paper, we regard every function snippet in the smart
contract as a sentence and pass it into USE to obtain the corresponding
contextual representation.

There are two methods to design USE. One is designed on the transformer
architecture[41] and targets high accuracy but has the greater cost of model
complexity and resource consumption. Another one targets efficient inference
with slightly reduced accuracy by making full use of a deep averaging network
(DAN)[42].

###  III-C Bidirectional LSTM

A common LSTM cell is composed of a memory cell, a forget gate[43], an input
gate, and an output gate[44]. A cell remembers values over arbitrary time
intervals and the three gates regulate the flow of information into and out of
the cell. A bidirectional LSTM (BiLSTM) wraps two LSTM layers: one obtains the
output in the forward order, and the other one obtains the output in the
backward order. The output of a BiLSTM is the concatenation of outputs in the
above two layers. Compared to LSTM which only learns the context dependency
from the left of the input sequence, BiLSTM can learn the dependency from both
sides of the input sequence. It makes BiLSTM significantly more effective in
context semantic understanding than LSTM.

##  IV Dataset

To train SmartIntentNN, we collect an unpresented dataset of more than
$40,000$ smart contracts from the explorer of Binance Smart Chain
(BSC)444https://bscscan.com and label the intents for them. BSC is an
Ethereum-like blockchain, smart contracts executing on BSC are compatible with
Ethereum. Fig. 3 shows the process of data collection and preprocessing. We
first download a large number of open-source smart contracts from the
blockchain explorer. Then the smart contracts with multiple files are merged,
and the redundant and noisy code snippets are dropped. Finally we apply the
regular expression (RegEx) to extract code snippets according to the Solidity
keywords to generate a smart contract code tree.

Figure 3:  Preprocess of dataset: (i) download the open-source smart contracts
from the BSC blockchain and label them; (ii) clean the source code and
generate the smart contract code tree.

###  IV-A Intent Labels

Ten categories of risky intents are labeled as shown in Table I. Our label
resource comes from the StaySafu555https://www.staysafu.org and the experience
of DApp developers and auditors.

TABLE I: Categories of risky intents Id | Intent | Percentage | Instance
---|---|---|---
1 | fee | $26.86\%$ | setFeeAddress(address)
2 | disableTrading | $5.34\%$ | enableTrading(bool)
3 | blacklist | $3.82\%$ | require(!isBlacklisted[sender])
4 | reflect | $37.50\%$ | tokenFromReflection(uint256)
5 | maxTX | $13.76\%$ | setMaxTxPercent(uint256)
6 | mint | $8.53\%$ | mint(uint256)
7 | honeypot | $0.23\%$ | require(allow[from])
8 | reward | $3.37\%$ | updateDividendTracker(address)
9 | rebase | $0.53\%$ | LogRebase(uint256, uint256)
10 | maxSell | $0.05\%$ | setMaxSellToken(uint256)

We explain the ten types of intents listed in Table I:

  * 1

Fee aims to modify transaction fees. Fees paid by users for each transaction
are transferred to a specified developer’s wallet.

  * 2

DisableTrading can directly turn on or off the trading action in a smart
contract.

  * 3

Blacklist restricts the behavior of its designated users on smart contracts.
It undermines the interests of these users and prejudice their right to trade
fairly and freely.

  * 4

Reflection is usually financed by a percentage tax on any transaction. Taxes
are redistributed to the holders according to the size of their holding
tokens. It can be a gimmick to attract users to buy the native tokens which
may not have any use case.

  * 5

MaxTX can limit the maximum number or volume of transactions.

  * 6

Mint allows issuing new tokens. This issue can be unlimited or artificially
controlled.

  * 7

Honeypot is a smart contract that pretends to leak its funds to a user,
provided that the user sends additional funds to it. However, the funds
provided by the user will be trapped and retrieved by the honeypot
creator[22].

  * 8

Reward is to reward users with specific crypto assets in the form of dividends
to attract users to buy or use the native tokens. Similarly, these assets may
not have value.

  * 9

Rebase, or elastic, controls the token price by algorithmically adjusting the
supply.

  * 10

MaxSell limits the specified users’ selling times or amounts, so that it can
lock their liquidity.

Each of the above intents can appear more than once in a smart contract. From
our statistical data, the most frequent intentional risk is reflect. In our
dataset, reflect appears in $33,268$ places over the $40,000$ smart contracts,
accounting for $37.5\%$ of all the types of intents, followed by fee
($26.86\%$) and maxTX ($13.76\%$) respectively. The risk maxSell accounts for
the least, only $0.05\%$, occurring in a total of $68$ places in our dataset.

###  IV-B Code Mergence & Drop

The source code of the smart contract on BSC exists in two forms. One is a
single-file smart contract, whose import contracts are merged by developers
through a flattener tool before uploading. The other is a multi-file smart
contract, whose code is separated into multiple files. For multi-file smart
contracts, we merge multiple files into a single document.

The Solidity compiler version specification pragma, import statements, and
comments in a smart contract are dropped out. The Solidity compiler version
(pragma) does not express any developer’s intent, and the code comments take
no impact on the implementation of any intent. Since the external contracts in
the import statements have been merged in the previous step (multi-file smart
contracts), removing the import statements will not lose the intent
information of a smart contract.

###  IV-C Smart Contract Code Tree

Since a smart contract is a document of computer code, we cannot directly feed
it into a neural network. To extract the model input data, we introduce the
concept of a smart contract code tree (CCTree). A CCTree is a tree graph data
structure generated by splitting and reorganizing a smart contract source
code. As shown in Fig. 4, a CCTree is expanded into three layers: (i) the
first layer is the root layer, representing the entire smart contract
document; (ii) the second layer is the contract layer, representing the
contract classes in a smart contract; (iii) the third layer is the function
layer, representing the function context under a contract class. Only one node
is placed in the root layer, denoted by $\mathbf{T}$. The second layer lists
the contract classes in $\mathbf{T}$, including the class types of contract,
interface, library, and abstract contract, denoted by $\mathbf{C}$. The third
layer contains leaf nodes, which store the code snippets with the keywords of
function, event, modifier, and constructor in the contract class, denoted by
$\mathcal{F}$. Afterward, we can easily load any data, e.g., $\mathbf{T}$,
$\mathbf{C}$ and $\mathcal{F}$, from a CCTree on demand.

Figure 4:  The smart contract code tree generated from the BSC address:
0xe4d200e40c1fc483d2aedf0e97debd7ab5760351.

##  V Approach

Figure 5:  The overview workflow of SmartIntentNN: (i) encode smart contracts
through the universal sentence encoder; (ii) highlight the developers’ intents
in smart contracts through a K-means model; (iii) feed the intent highlighted
data into a DNN to learn the representations of smart contracts. The
architecture of our DNN: an input layer, a BiLSTM layer, and a dense layer for
ouputting the multi-label binary classification results.

We introduce how we leverage the DNN-based approaches to detect the intents in
smart contracts. Fig. 5 describes an overview of our approach, named
SmartIntentNN, which could be divided into three primary parts: smart contract
embedding, intent highlighting, and DNN learning. First, we encode smart
contracts to embedding vectors through the universal sentence encoder. Then
the intents of smart contracts are highlighted through a K-means model.
Finally, we feed the highlighted data into the DNN to learn the
representations of smart contracts and perform the multi-label classification
on them. In this section, we explain our approach in details.

###  V-A Smart Contract Embedding

To generate the embedding (contextual representation) of a smart contract, we
first employ an encoder to generate the embeddings for each function in the
smart contract. Then we combine all the function embeddings to represent the
entire smart contract.

As we have introduced the CCTree in Section IV, we iterate all the leaf nodes
in the CCTree. We use the pre-trained model USE based on the DAN architecture
to encode each function $\mathcal{F}$ (i.e., leaf node) in a smart contract
into the sentence embedding. Formula 1 describes the embedding process, where
$\Phi$ represents the contextual encoder and its input data $\mathcal{F}$ can
be any context of function. It outputs a vector $\bm{f}$ which is the
embedding of the function $\mathcal{F}$.

$\Phi\left(\mathcal{F}\right):\mathcal{F}\rightarrow\bm{f}$ (1)

To generate a sentence embedding of $\mathcal{F}$, the following three steps
are processed by DAN: (i) calculate the vector average of the word embeddings
in a sentence; (2) pass the average vector through one or more feed-forward
layers; (3) perform the classification in an activation layer to generate a
universal sentence embedding.

$\mathrm{T}\left(\mathcal{F}\right):\mathcal{F}\rightarrow\mathbf{W^{\mathcal{F}}}=\left\\{w_{1},w_{2},\cdots,w_{n}\right\\}$
(2)
$\phi\left(w_{i}\right):w_{i}\in\mathbf{W^{\mathcal{F}}}\rightarrow\bm{w_{i}}$
(3) $\bm{f^{0}}=\frac{1}{n}\sum_{i=1}^{n}\bm{w_{i}}$ (4)

Formula 2-4 describe the first step in DAN. $\rm{T}$ in Formula 2 generates
the word tokens from a sentence, which is usually named as “tokenizing”. The
text of function $\mathcal{F}$ is split into an ordered set
$\mathbf{W^{\mathcal{F}}}$ of multiple word tokens
$\left\\{w_{i}\right\\}_{i=1}^{n}$. In Formula 3, $\phi$ transfers tokens into
word embeddings[36]
$\left\\{\bm{w_{1}},\bm{w_{2}},\cdots,\bm{w_{n}}\right\\}$. Eventually,
Formula 4 averages all the word embedding vectors to $\bm{f^{0}}$.

The intuition behind deep feed-forward neural networks means that each layer
learns a more abstract representation of the input data than the previous
one[45]. In the second step of DAN, the averaged output $\bm{f^{0}}$ is
further transformed by multiple feed-forward layers. We assume taking $n$
feed-forward layers, and each feed-forward layer can be illustrated by Formula
5. $\bm{W_{i}}$ is a $k\times k$ weight matrix where $k$ is the size
(dimension) of vector $\bm{f^{i}}$. The activation function $\sigma$ is
usually $\mathrm{sigmoid}$ or $\mathrm{tanh}$, and $\bm{b_{i}}$ is a bias
term.

$\bm{f^{i}}=\sigma\left(\bm{W_{i}}\cdot\bm{f^{i-1}}+\bm{b_{i}}\right),i\in\left\\{1,2,\cdots,n\right\\}$
(5)

In the third step, feeding $\bm{f^{n}}$ to a $\mathrm{softmax}$ layer can
generate the universal representation of the function $\mathcal{F}$.
$\bm{W_{s}}$ is an $m\times k$ weight matrix for the input of a $k$ size
vector and the output of a function embedding with $m$ features. Formula 6
outputs $\bm{f}$, which is the embedding of the function context.

$\bm{f}=\mathrm{softmax}\left(\bm{W_{s}}\cdot\bm{f^{n}}+\bm{b_{s}}\right)$ (6)

The above operations are performed on each function in a smart contract and we
finally push their embedding vectors $\bm{f}$ into $\bm{X}$ to represent the
entire smart contract. $\bm{X}$ is an $n\times m$ matrix where $n$ equals to
the number of functions in a smart contract and $m$ is the number of features
in $\bm{f}$.

###  V-B Intent Highlight

Although we can directly feed $\bm{X}$ into a DNN, not all functions in a
smart contract express the developer’s intent. Thus, we present intent
highlight to stress the intent-related functions in a smart contract. Intent
highlight is a pre-trained model based on K-means machine learning[46, 47],
aiming to predict the intent strength of each vector $\bm{f}$ in $\bm{X}$.
Formula 7 describes the intent highlight method, where $\rm{H}$ is an
unsupervised model and its output is the intent-highlighted data
$\bm{X^{\prime}}$.

$\mathrm{H}\left(\bm{X}\right):\bm{X}\rightarrow\bm{X^{\prime}}$ (7)

To get the $k$ value of K-means, we compute the occurrence rate of each
function $\mathcal{F}$. A function occurrence rate can be defined as the
frequency of a function occurring in a smart contract dataset, described as
$\mathrm{R}\left(\mathcal{F}\right)$ in Formula 8. We assume there is a sample
of dataset $\mathbf{S}$ and there are $m$ smart contracts in $\mathbf{S}$,
$\mathbf{S}=\left\\{\mathbf{T_{i}}\right\\}_{i=1}^{m}$. If the function
$\mathcal{F}$ exists in the tree $\mathbf{T_{i}}$, it is denoted by
$\mathrm{E}\left(\mathbf{T_{i}},\mathcal{F}\right)=1$ in Formula 9, and we
count once for $\mathrm{R}$. Eventually, we count the number of $\mathcal{F}$
whose $\mathrm{R}\left(\mathcal{F}\right)>\rho$ as the value of $k$. The
threshold of the occurrence rate $\rho$ will be fit in the experiment.

$\mathrm{R}\left(\mathcal{F}\right)=\frac{1}{m}\sum_{i=1}^{m}\mathrm{E}\left(\mathbf{T_{i}},\mathcal{F}\right)$
(8)
$\mathrm{E}\left(\mathbf{T},\mathcal{F}\right)=\left\\{\begin{array}[]{lc}1&\mathcal{F}\in\mathbf{T}\\\
0&\mathcal{F}\not\in\mathbf{T}\end{array}\right.$ (9)

When comparing the similarity of two documents, we prefer to compute the
cosine distance between their embedding vectors[48]. For example, there are
two functions ($\mathcal{F}_{A}$ and $\mathcal{F}_{B}$) whose embedding
vectors are $\bm{f^{A}}=[f_{1}^{A},f_{2}^{A},\cdots,f_{n}^{A}]$ and
$\bm{f^{B}}=[f_{1}^{B},f_{2}^{B},\cdots,f_{n}^{B}]$. Formula 10 provides a
method for calculating the text similarity between $\mathcal{F}_{A}$ and
$\mathcal{F}_{B}$, that is, the cosine value of $\bm{f^{A}}$ and $\bm{f^{B}}$.
Therefore, we transform cosine similarity to cosine distance by Formula 11.

$\displaystyle\cos\left\langle\bm{f^{A}},\bm{f^{B}}\right\rangle$
$\displaystyle=\frac{\bm{f^{A}}\cdot\bm{f^{B}}}{\left\|\bm{f^{A}}\right\|\left\|\bm{f^{B}}\right\|}$
(10) $\displaystyle=\frac{\sum_{i=1}^{n}f_{i}^{A}\times
f_{i}^{B}}{\sqrt{\sum_{i=1}^{n}\left(f_{i}^{A}\right)^{2}}\times\sqrt{\sum_{i=1}^{n}\left(f_{i}^{B}\right)^{2}}}$
$\mathrm{D}\left(\bm{f^{A}},\bm{f^{B}}\right)=1-\cos\left\langle\bm{f^{A}},\bm{f^{B}}\right\rangle$
(11)

To find the centroid of each cluster for K-means, we assume a training dataset
$\left\\{\bm{f^{\prime}_{i}}\right\\}_{i=1}^{n}$ with $n$ samples of contract
functions and $k$ random means (centroids)
$\left\\{\bm{c_{j}^{t}}\right\\}_{j=1}^{k},t=0,1,\cdots,z$, where $z$
represents the maximum number of iterations in K-means. K-means repeatedly
performs the calculation of the minimum square Euclidean distance between the
current centroids and each within-cluster observation value from the initial
centroids $\left\\{\bm{c_{j}^{0}}\right\\}_{j=1}^{k}$. We replace the squared
Euclidean distance with the cosine distance mentioned above. Let us assign
$\bm{f^{\prime}_{i}}$ to its closest mean $\bm{c_{j}^{t}}$ and denote as a set
$\mathbf{M_{j}^{t}}$, where $\bm{f^{\prime}_{i}}$ is a within-cluster
observation value to $\bm{c_{j}^{t}}$. In Formula 12, if $\bm{f^{\prime}_{i}}$
is the within-cluster observation to $\bm{c_{j}^{t}}$, the cosine distance
between them is calculated, otherwise the distance is $0$.

$\mathrm{M}(\bm{f^{\prime}_{i}},\bm{c_{j}^{t}})=\left\\{\begin{array}[]{lc}\mathrm{D}\left(\bm{f^{\prime}_{i}},\bm{c_{j}^{t}}\right)&\bm{f_{j}}\in\mathbf{M_{j}^{t}}\\\
0&\bm{f^{\prime}_{i}}\notin\mathbf{M_{j}^{t}}\end{array}\right.$ (12)
$\bm{c_{j}^{t+1}}=\frac{\displaystyle\sum_{i=1}^{n}\frac{\mathrm{M}\left(\bm{f^{\prime}_{i}},\bm{c_{j}^{t}}\right)\bm{f^{\prime}_{i}}}{\mathrm{D}\left(\bm{f^{\prime}_{i}},\bm{c_{j}^{t}}\right)}}{\displaystyle\sum_{i=1}^{n}\frac{\mathrm{M}\left(\bm{f^{\prime}_{i}},\bm{c_{j}^{t}}\right)}{\mathrm{D}\left(\bm{f^{\prime}_{i}},\bm{c_{j}^{t}}\right)}}$
(13)
$\min\left\\{\displaystyle\sum_{j=1}^{k}\displaystyle\sum_{i=1}^{n}\mathrm{M}\left(\bm{f^{\prime}_{i}},\bm{c_{j}^{t}}\right)\right\\}_{t=0}^{z}$
(14)

According to Formula 13, after each round, the centroid $\bm{c_{j}^{t}}$ is
updated to $\bm{c_{j}^{t+1}}$ where $0\leq t\leq z$. The training target is to
minimize the total within-cluster variation (TWCV) as Formula 14. The training
is terminated when $t$ reaches the maximum iteration limit, $z$ rounds, or the
minimum TWCV is no longer significantly reduced. Eventually, we find the most
appropriate centroids $\left\\{\bm{c_{j}}\right\\}_{j=1}^{k}$ for K-means.

Figure 6:  Use a 3D coordinate system to describe the principle of intent
highlight. The larger the vector angle deviates from the centroid in space,
the stronger its intent is.

As the K-means model is ready, we can pass any vector $\bm{f_{i}}$ to predict
its within-cluster distance. Around the centroids $\bm{c_{j}}$ in Fig. 6, we
find some frequently occurring and similar function code snippets. Their
vectors densely keep a short distance from the centroids. These code snippets
are usually from public libraries, written with mainstream algorithms, or the
codes in high-frequency reuse. We consider that these functions are as weak as
to offer the developer’s intent while the centroid-outlying functions are
distinctive, expressing the strong intent. Therefore, we regard a within-
cluster distance as the strength of intent.

$\bm{X^{\prime}}=\mathrm{rank}\left(\bm{X}\right)\;\mathsf{by}\;\mathrm{D}\left(\bm{f_{i}},\bm{c_{j}}\right)$
(15)
$\bm{X^{\prime}}=\mathrm{scale}\left(\bm{X}\right)\;\mathsf{by}\;\mu\bm{f_{i}}\;\mathsf{if}\;\mathrm{D}\left(\bm{f_{i}},\bm{c_{j}}\right)\geq\lambda$
(16)

We rank or scale $\bm{f_{i}}$ in $\bm{X}$ by the predicted within-cluster
distance and generate a new matrix $\bm{X^{\prime}}$. In Formula 15 and 16,
$i\in\left\\{1,2,\cdots,n\right\\}$, $j\in\left\\{1,2,\cdots,k\right\\}$,
$\lambda$ is a threshold of the distance, beyond which, $\bm{f_{i}}$ can be
scaled by $\mu$ times. The above steps can be found in the middle part of Fig.
5, nearby intent highlight.

###  V-C Multi-label Classification

In this section, we introduce the last part of Fig. 5, using a DNN for multi-
label classification. The architecture of the DNN can be divided into three
layers: an input layer (masking layer), a bidirectional LSTM layer, and an
output layer. To learn the classification, we feed the intent highlighted
data, that is, the matrix (sequence) $\bm{X^{\prime}}$ output from the
previous intent highlight model, to DNN.

The data first flows into the input layer, and we assume that the input layer
accepts a sequence of $a\times b$ size. The number of functions $\mathcal{F}$
input for each time should be equal to $a$. The vector size of each function
embedding $\bm{f_{i}}$ is required to be equal to $b$. The size of the
function embedding vector is fixed, for instance, USE outputs a vector of
$512$ units. Therefore, we do not need to make any change to the columns of
$\bm{X^{\prime}}$. We just need to ensure that $b$ of the input layer is the
same as the vector size of $\bm{f_{i}}$. However, the row size of
$\bm{X^{\prime}}$ is determined by the number of functions in each smart
contract. There is a situation for $\bm{X^{\prime}}$, where the number of its
rows may be less than $a$. Such smart contracts are very simple as they
usually contain very few functions. We pad the absent rows of
$\bm{X^{\prime}}$ with zero vectors. Our input layer is also a masking layer.
Tensorflow’s official explanation of the masking
layer666https://js.tensorflow.org/api/latest/#layers.masking is that it can
skip timesteps by giving a masking (skipping) value. Therefore, we set the
masking value equal to the above padded value, which is $0$.

The data flows into the second layer, a bidirectional LSTM layer. This layer
also accepts an $a\times b$ matrix, denoted by
$\bm{X^{\prime\prime}}=[\bm{f_{i}}]_{i=1}^{a}$, which is the output of the
input layer. Each LSTM layer contains $a$ memory cells, thus there are a total
of $2a$ cells in the forward layer and the backward layer. Each row vector
$\bm{f_{i}}$ of $\bm{X^{\prime\prime}}$ is input to one of the LSTM cells both
in the forward layer and the backward layer.

$\mathrm{G}^{\mathsf{f}}_{i}=\alpha\left(\bm{W^{\mathsf{f}}_{i}}\bm{f_{i}}+\bm{U^{\mathsf{f}}_{i}}\bm{h_{i-1}}+\bm{b^{\mathsf{f}}_{i}}\right)$
(17)
$\mathrm{G}^{\mathsf{u}}_{i}=\alpha\left(\bm{W^{\mathsf{u}}_{i}}\bm{f_{i}}+\bm{U^{\mathsf{u}}_{i}}\bm{h_{i-1}}+\bm{b^{\mathsf{u}}_{i}}\right)$
(18)
$\mathrm{G}^{\mathsf{o}}_{i}=\alpha\left(\bm{W^{\mathsf{o}}_{i}}\bm{f_{i}}+\bm{U^{\mathsf{o}}_{i}}\bm{h_{i-1}}+\bm{b^{\mathsf{o}}_{i}}\right)$
(19)
$\widetilde{\Theta}_{i}=\beta\left(\bm{W^{\theta}_{i}}\bm{f_{i}}+\bm{U^{\theta}_{i}}\bm{h_{i-1}}+\bm{b^{\theta}_{i}}\right)$
(20)
$\Theta_{i}=\mathrm{G}^{\mathsf{f}}_{i}\odot\Theta_{i-1}+\mathrm{G}^{\mathsf{u}}_{i}\odot\widetilde{\Theta}_{i}$
(21)
$\bm{h_{i}}=\mathrm{G}^{\mathsf{o}}_{i}\odot\gamma\left(\Theta_{i}\right)$
(22)

Formula 17-22 describe the computing process after a row vector $\bm{f_{i}}$
is fed to an LSTM cell, where $i\in\mathbb{N}^{+},i\leq a$. $\Theta$ is the
cell state vector and $\widetilde{\Theta}$ is the cell input activation
vector. The initial $\Theta_{0}$ is a zero vector of size $h$ (hidden units of
each LSTM cell). $\mathrm{G}$ represents “gate” in a cell.
$\mathrm{G}^{\mathsf{f}}_{i}$ is the forget gate.
$\mathrm{G}^{\mathsf{u}}_{i}$ is the update gate, which is also called the
input gate. $\mathrm{G}^{\mathsf{o}}_{i}$ is the output gate.
$\bm{W}\in\mathbb{R}^{h\times b}$, $\bm{U}\in\mathbb{R}^{h\times h}$ are
weight matrices and $\bm{b}\in\mathbb{R}^{h}$ is a bias vector parameter. All
of $\bm{W}$, $\bm{U}$ and $\bm{b}$ need to be learned during training. The
elements in $\bm{W}$, $\bm{U}$ and $\bm{b}$ can be treated as any real number
$\mathbb{R}$. The superscript represents their shape. The activation
functions, $\alpha$, $\beta$ and $\gamma$, can be treated as $\mathrm{tanh}$,
$\mathrm{sigmoid}$ or others. The hidden state vector $\bm{h}$, is also known
as the output vector of an LSTM cell, whose size is $h$ and the initial
$\bm{h_{0}}$ is a zero vector. The operator $\odot$ denotes the Hadamard
product (element-wise product)[49].

For a bidirectional LSTM, the forward layer finally outputs an
$\bm{h_{a}^{f}}$, and the backward layer also outputs an $\bm{h_{a}^{b}}$. The
final output of BiLSTM is the direct sum of the two outputs through
$\bm{h_{a}^{f}}\oplus\bm{h_{a}^{b}}$[50], denoted by $\bm{h^{\prime}}$.

The output of the BiLSTM layer is eventually passed to the output layer, which
is a multi-label classification dense layer. It accepts a vector of $2h$ size,
which is $\bm{h^{\prime}}$.

$\bm{y}=\mathrm{sigmoid}\left(\bm{W_{c}}\bm{h^{\prime}}+\bm{b}\right)$ (23)

In Formula 23, we perform binary classification on each category (label)
through a $\mathrm{sigmoid}$ function. $\bm{W_{c}}$ is an $l\times 2h$ weight
matrix, where $2h$ is the size of input vector $\bm{h^{\prime}}$ and $l$ is
the number of target labels. Therefore, the final output is a vector
$\bm{y}=[y_{1},y_{2},\cdots,y_{l}]$ and the value of each element in it
indicates the probability of the existence of each intent category. For each
element $y_{i}$ in $\bm{y}$, we let $y_{i}\geq 0.5$ be equal to $1$ while
$y_{i}<0.5$ be equal to $0$. A multi-hot vector is then generated, where $1$
indicates the existence of one intent and $0$ indicates the absence of such
intent. So far, the intent detection of a smart contract is completed.

##  VI Evaluation

In this section, evaluation metrics and baselines are firstly described. Then
we state the details of our experiment, including the configurations and
results. Finally, we propose three research questions (RQs) and answer them
according to the results of our experiment.

###  VI-A Evaluation Metrics

To evaluate our model, we present the confusion matrix:

  * •

True Positive (TP): the number of correctly predicted intent categories
existing in smart contracts.

  * •

True Negative (TN): the number of correctly predicted non-existing intent
categories in smart contracts.

  * •

False Positive (FP): the number of incorrectly predicted intent categories
existing in smart contracts.

  * •

False Negative (FN): the number of incorrectly predicted non-existing intent
categories in smart contracts.

With TP, TN, FP and FN, we can compute the metrics like accuracy, precision,
recall and f1-score (F1) as Formula 24-27.

$\mathbf{accuracy}=\frac{\mathbf{TP}+\mathbf{TN}}{\mathbf{TP}+\mathbf{FP}+\mathbf{FN}+\mathbf{TN}}$
(24) $\mathbf{precision}=\frac{\mathbf{TP}}{\mathbf{TP}+\mathbf{FP}}$ (25)
$\mathbf{recall}=\frac{\mathbf{TP}}{\mathbf{TP}+\mathbf{FN}}$ (26)
$\mathbf{F1}=\frac{2\times\mathbf{precision}\times\mathbf{recall}}{\mathbf{precision}+\mathbf{recall}}$
(27)

Accuracy is a basic metric for model evaluation, describing the proportion of
correct predictions in total predictions. Precision is a measure of how many
of the positive predictions made are correct. Recall is a measure of how many
of the positive cases the classifier correctly predicted, over all the
positive cases in the data. F1 is a measure combining both precision and
recall.

###  VI-B Baselines

TABLE II: Baselines Comparison Model | Accuracy | Precision | Recall | F1-score
---|---|---|---|---
SmartIntentNN
Rank ASC | $0.9437$ | $0.8079$ | $0.7960$ | $0.8019$
Scale$\times 2$ | $\bm{0.9474}$ | $\bm{0.8173}$ | $\bm{0.8142}$ | $\bm{0.8158}$
Scale$\times 4$ | $0.9455$ | $0.8380$ | $0.7677$ | $0.8013$
Scale$\times 10$ | $0.9435$ | $0.8250$ | $0.7682$ | $0.7956$
Scale$\times 2$ dropout | $\bm{0.9482}$ | $\bm{0.8118}$ | $\bm{0.8308}$ | $\bm{0.8212}$
Other Models
LSTM | $0.9405$ | $0.8126$ | $0.7588$ | $0.7848$
BiLSTM | $0.9402$ | $0.8033$ | $0.7706$ | $0.7866$
CNN | $0.9309$ | $0.8395$ | $0.6392$ | $0.7258$

As this is the first work on smart contract intent detection, we have no
previous related work to compare. We perform a self-comparison with three
baselines, respectively, using a basic LSTM model, a BiLSTM model, a CNN
(Convolutional Neural Network) model[51] to detect the intents in smart
contracts. There are two variants of the intent highlight model: rank and
scale. Of the two variants, a scale can be further multiplied by different
constants. We add a dropout layer[52] to the best variant (i.e.,
$2\times$scale intent highlight). Therefore, we finally list eight different
control groups in Table II.

###  VI-C Experiment Details

We first state the experimental configurations in our model training. All the
models are built and trained on Tensorflow.js. We prepare the first $10,000$
rows of data in our database to train the model and employ the data after
$20,000$ to evaluate the model. The middle $10,000$ rows of data are standby,
which can be used for extended training or evaluation. Each training batch
size is $20$ smart contracts, and they are shuffled during training. The
number of training epochs is $30$, which means that we train the neural
network with all the training data for $30$ cycles. We take
“binaryCrossentropy” and “Adam” as the loss function and optimizer
respectively. The number of hidden units in LSTM is set to $32$ as $32$ is the
best parameter achieved by repeated tuning. We have also tried $16$, $64$,
$128$, $256$ and $512$ hidden units for an LSTM cell while their performance
is not as good as $32$. The dimension of output multi-hot vectors $\bm{y}$ in
Section V.C is $10$ as we label ten categories of intents.

(a) CNN

(b) LSTM

(c) SmartIntentNN rank

(d) SmartIntentNN scale

Figure 7: Metrics trend of the models evaluated by $10,000$ smart contracts.

Fig. 7 lays out the trend charts of the metrics as each model is evaluated
with $10,000$ smart contracts. We find that after about $7,000$ evaluations,
the metrics tend to be steady. Therefore, we consider that the metrics
evaluated on $10,000$ smart contracts are reasonable and reliable. In Fig. 7,
AC, PR and RE are abbreviations of accuracy, precision, and recall,
respectively.

(a) Total visualization

(b) One cluster

(c) Partially enlarged observation

Figure 8:  Visualization of intent highlight.

We also conduct a specific experiment on the intent highlight model. Referring
to Fig. 8, we visualize the outputs of the intent highlight model. In Fig. 8,
(a) shows an entire visualization of the intent highlight performed on a smart
contract. After myraid experiments, we find that the most appropriate $k$ for
K-means is $16$ when the threshold $\rho$ of function occurrence rate is
$0.75$, tested on $2,500$ smart contracts, thus we get $16$ clusters as (a). A
single cluster and its within-cluster functions can be viewed in (b). Fig. 8
(c) enlarges the details in (a), and the nodes with red labels are intent
highlighted functions, whose distances are far from their centroids. We find
that those functions such as IBEP20/name and getOwner are common interfaces or
public libraries while the highlighted functions like setFees,
setDistributorSettings are the logic code snippets that express the specific
development intents.

###  VI-D Research Questions

We put forward three questions for our research and answer them according to
the results of our experiment.

RQ1 How well does SmartIntentNN and its variants detect intents in smart
contracts in pratical?

The results of evaluation in Table II shows that, of all the baselines and our
approach, SmartIntentNN with intent highlight scale$\times 2$ (dropout)
acquires the highest f1-score of $\bm{0.8212}$, the accuracy of $\bm{0.9482}$,
the precision of $\bm{0.8118}$, and the recall of $\bm{0.8308}$. Compared with
the other models, without considering dropout, F1 is nearly $3\%$ higher than
that of LSTM and BiLSTM, and $9\%$ higher than that of CNN. SmartIntentNN
performs better than other typical models (baselines) as we use a BiLSTM layer
to understand the context of smart contracts both from forward and backward,
and further use the intent highlight model to strengthen those code
representations with strong intents.

All the variants of SmartIntentNN can achieve an F1 of more than $0.8$ except
the model using intent highlight of $10\times$scale. Another variant using
intent highlight of ascending order for function embeddings also performs well
as its accuracy reaches $0.9437$, precision reaches $0.8079$, recall reaches
$0.7960$ and f1-score is $0.8019$. It is slightly lower than the best variant
of SmartIntentNN but still higher than the other models.

RQ2 How does intent highlight contribute to the performance of SmartIntentNN?

The intent highlight model is divided into two variants, scale, and rank. Rank
sorts the embeddings of the functions in a smart contract according to the
strength of intent (within-cluster distance). Scale amplifies the embedding
vectors by $\mu$ times, whose within-cluster distances are greater than a
threshold $\lambda$. In our experiment, $\lambda$ and $\mu$ are $0.2$ and
$\left\\{2,4,10\right\\}$ respectively.

The re-rank of the input sequence teaches the neural network to learn the
representations in order. Before being fed to the neural network, functions in
a smart contract are sorted from weak to strong by the strength of intent.
Table II shows that, compared to a typical and unique BiLSTM, SmartIntentNN
with intent highlight of ascending rank improves F1 by $1.53\%$. This result
demonstrates that a sequence ordered by ascending intent strength helps LSTM
better remember and understand the features in the sequence.

Scaling the vectors in a sequence helps a neural network pay more attention to
these unusual data. Over-scale vectors cannot improve the performance of our
model, on the contrary, they can produce worse results, e.g., scale$\times 10$
in Table II. This is because excessive enlargement of the vector can deviate
from its original representation. By comparing the different scaling sizes, we
conclude that $2\times$scale ($\mu=2$) is the best choice for intent
highlight. Similarly, compared with a normal BiLSTM, its F1 can be improved by
up to $3.46\%$.

RQ3 How is the capability of SmartIntentNN in detecting different categories
of intents?

Figure 9:  Evaluation metrics of SmartIntentNN for different intents.

The performance of SmartIntentNN in detecting different types of intents is
different. As shown in Fig. 9, we separately evaluate our model on each
category of intent and reach the different metrics. Among all the intents,
SmartIntentNN performs outstandingly in detecting fee, reflect and maxTX three
intents while the F1 of maxSell detection is poor. According to the statistics
in Section IV, it is not difficult to analyze that the reason for this gap is
that, in our dataset, there are too few samples (only $0.05\%$) of maxSell
while the proportion of fee, reflect and maxTX are very high (see the
explanation of threats to validity in Section VI.E). Despite the relatively
weak efficiency in detecting a few types of intents, the accuracy metric of
each one is still high, over $90\%$, which demonstrates most of the risky
intents detected by our model are correct.

###  VI-E Threats to Validity

There is a threat from the imbalance of dataset, e.g., maxSell, according to
the statistics in Section IV, only accounting for $0.05\%$, far less than the
other labels of intents. The data scarcity issue can result in our model being
unable to learn their representations well. We find these intents rare in
nature as we collect smart contracts wildly and randomly on the real
blockchain. Nevertheless, SmartIntentNN is a trainable model, as long as the
case number of these intents increases in smart contracts, we can perform
model retraining to improve the detection capability of these intents.

Another threat is the universality of our model, as all our data is from BSC.
BSC is an Ethereum-like blockchain, as well as it supports EVM and Solidity.
Therefore, the model trained on BSC can detect smart contracts not only on BSC
but also on Ethereum and other Ethereum-like blockchains. Although our model
currently does not sustain detecting the smart contracts not in Solidity, we
can still perform the additional training on other smart contract programming
languages, e.g., JavaScript, and Vyper[53], to drive our model to sustain
them. As we know, Solidity is the most popular and universal programming
language for smart contracts[54], thus we consider that our current model is
already universal for detecting most of the smart contracts on various
blockchains.

##  VII Related Work

In this section, we introduce the related work from the perspective of
external risks and internal risks, as well as discuss the distinctions between
their work and ours.

###  VII-A External Risks

A survey of smart contract vulnerabilities[20] well summarizes various
vulnerabilities on Ethereum, as well as the applied attacks and defense
methods. The earlier vulnerability detection research typically performs
static[16, 17, 55, 56, 57, 58] or dynamic analysis[59] on smart contracts. A
kind of datalog-based formulation is used in[19] to perform the static
analysis over EVM execution traces. teTether[60] finds vulnerable execution
traces in smart contracts, as well as employs symbolic execution to create
exploits for them. Besides, Oyente[18], Securify[58] and Maian[61] also adopt
symbolic executions to find vulnerability traces. SMARTSHIELD[62] detects
security-related bugs by analyzing the abstract syntax tree (AST) and EVM
bytecode. The latest research[63, 64] also applies deep learning to detect
vulnerabilities in smart contracts. The above work aims to detect the external
risks, mainly the exploitation of vulnerabilities, while our research aims to
detect the internal risks from the developers’ intent.

###  VII-B Internal Risks

The first empirical analysis of Bitcoin-based scams is presented by[65].
HoneyBadger[22] is built to expose honeypots through symbolic execution with
the well-defined heuristics. “Trade or Trick”[24] proposes an approach for
flagging scam tokens on Uniswap based on a guilt-by-association heuristic and
a machine-learning-powered technique. Its ground truth is labeled by official
tokens and scam tokens, which is different from our intent labels.
SCSGuard[66] is the most relevant to our work, which uses deep learning to
detect scams in smart contracts. The difference is that: (i) the target of its
detection is Ponzi and honeypots; (ii) it learns from the bytecode rather than
the smart contract source code. Despite being the same in detecting internal
risks, our approach is the first work to implement the detection by
identifying the developers’ intents in smart contracts.

##  VIII Conclusion

We propose a new automated approach, to detect the developers’ intent in smart
contracts. To implement the approach, we build an automated smart contract
intent detection model, namely SmartIntentNN, consisting of a universal
sentence encoder, an intent highlight model based on K-means, and a DNN
integrated with a BiLSTM layer. For training this model, we collect more than
$40,000$ smart contracts, clean the data, and label them with ten typical
categories of intents. According to the experimental results, we find that the
performance of our model performs better than all baselines, up to the
accuracy of $0.9482$, the precision of $0.8118$, the recall of $0.8308$, and
the f1-score of $0.8212$.

In the future, our work will focus on two aspects to improve this model: (i)
train the model for smart contracts in other programming languages; (ii) build
an programming language encoder specifically for generating smart contract
embeddings.

##  IX Data Availability

SmartIntentNN is available online. To use our source code and dataset, please
refer to the documentation on the following website.

https://gitlab.com/web3se/smartintent

## References

  * [1] “Introduction to web3.” [Online]. Available: https://ethereum.org/en/web3
  * [2] U. W. Chohan, “Web 3.0: The future architecture of the internet?” _Available at SSRN_ , 2022.
  * [3] S. Richards, “Web2 vs web3.” [Online]. Available: https://ethereum.org/en/developers/docs/web2-vs-web3
  * [4] V. Buterin _et al._ , “A next-generation smart contract and decentralized application platform,” _white paper_ , vol. 3, no. 37, pp. 2–1, 2014.
  * [5] G. Wood _et al._ , “Ethereum: A secure decentralised generalised transaction ledger,” _Ethereum project yellow paper_ , vol. 151, no. 2014, pp. 1–32, 2014.
  * [6] “Ethereum.” [Online]. Available: https://ethereum.org
  * [7] M. Nofer, P. Gomber, O. Hinz, and D. Schiereck, “Blockchain,” _Business & Information Systems Engineering_, vol. 59, no. 3, pp. 183–187, 2017.
  * [8] M. Röscheisen, M. Baldonado, K. Chang, L. Gravano, S. Ketchpel, and A. Paepcke, “The stanford infobus and its service layers: Augmenting the internet with higher-level information management protocols,” _Digital Libraries in Computer Science: The MeDoc Approach_ , pp. 213–230, 1998.
  * [9] B. P. P. Martin Fries, _Smart Contracts_. Mohr Siebeck GmbH and Co. KG, 2019. [Online]. Available: http://www.jstor.org/stable/j.ctvn96h9r
  * [10] A. Savelyev, “Contract law 2.0:‘smart’contracts as the beginning of the end of classic contract law,” _Information & communications technology law_, vol. 26, no. 2, pp. 116–134, 2017.
  * [11] D. Tapscott and A. Tapscott, _Blockchain revolution: how the technology behind bitcoin is changing money, business, and the world_. Penguin, 2016.
  * [12] N. Szabo, “Smart contracts: building blocks for digital markets,” _EXTROPY: The Journal of Transhumanist Thought,(16)_ , vol. 18, no. 2, p. 28, 1996.
  * [13] “Introduction to smart contracts.” [Online]. Available: https://ethereum.org/en/developers/docs/smart-contracts
  * [14] I.-A. BUCULEI _et al._ , “Information systems vulnerabilities,” in _International Conference on Cybersecurity and Cybercrime_ , vol. 4, 2017, pp. 39–48.
  * [15] D. Siegel, “Understanding the dao attack.” [Online]. Available: http://www.coindesk.com/understanding-dao-hack-journalists
  * [16] L. Brent, A. Jurisevic, M. Kong, E. Liu, F. Gauthier, V. Gramoli, R. Holz, and B. Scholz, “Vandal: A scalable security analysis framework for smart contracts,” _arXiv preprint arXiv:1809.03981_ , 2018.
  * [17] S. Kalra, S. Goel, M. Dhawan, and S. Sharma, “Zeus: analyzing safety of smart contracts.” in _Ndss_ , 2018, pp. 1–12.
  * [18] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contracts smarter,” in _Proceedings of the 2016 ACM SIGSAC conference on computer and communications security_ , 2016, pp. 254–269.
  * [19] D. Perez and B. Livshits, “Smart contract vulnerabilities: Does anyone care?” _arXiv preprint arXiv:1902.06710_ , pp. 1–15, 2019.
  * [20] D. He, Z. Deng, Y. Zhang, S. Chan, Y. Cheng, and N. Guizani, “Smart contract vulnerability analysis and security audit,” _IEEE Network_ , vol. 34, no. 5, pp. 276–282, 2020.
  * [21] K. Li, J. Chen, X. Liu, Y. R. Tang, X. Wang, and X. Luo, “As strong as its weakest link: How to break blockchain dapps at rpc service.” in _NDSS_ , 2021\.
  * [22] C. F. Torres, M. Steichen _et al._ , “The art of the scam: Demystifying honeypots in ethereum smart contracts,” in _28th USENIX Security Symposium (USENIX Security 19)_ , 2019, pp. 1591–1607.
  * [23] J. Wu, Q. Yuan, D. Lin, W. You, W. Chen, C. Chen, and Z. Zheng, “Who are the phishers? phishing scam detection on ethereum via network embedding,” _IEEE Transactions on Systems, Man, and Cybernetics: Systems_ , 2020.
  * [24] P. Xia, H. Wang, B. Gao, W. Su, Z. Yu, X. Luo, C. Zhang, X. Xiao, and G. Xu, “Trade or trick? detecting and characterizing scam tokens on uniswap decentralized exchange,” _Proceedings of the ACM on Measurement and Analysis of Computing Systems_ , vol. 5, no. 3, pp. 1–26, 2021.
  * [25] “What is a smart contract security audit? a beginner’s guide.” [Online]. Available: https://cointelegraph.com/blockchain-for-beginners/what-is-a-smart-contract-security-audit-a-beginners-guide
  * [26] S. Hochreiter and J. Schmidhuber, “Long short-term memory,” _Neural computation_ , vol. 9, no. 8, pp. 1735–1780, 1997.
  * [27] I. Sutskever, O. Vinyals, and Q. V. Le, “Sequence to sequence learning with neural networks,” _Advances in neural information processing systems_ , vol. 27, 2014.
  * [28] M. Abadi, P. Barham, J. Chen, Z. Chen, A. Davis, J. Dean, M. Devin, S. Ghemawat, G. Irving, M. Isard _et al._ , “Tensorflow: a system for large-scale machine learning,” in _12th USENIX symposium on operating systems design and implementation (OSDI 16)_ , 2016, pp. 265–283.
  * [29] D. Smilkov, N. Thorat, Y. Assogba, C. Nicholson, N. Kreeger, P. Yu, S. Cai, E. Nielsen, D. Soegel, S. Bileschi _et al._ , “Tensorflow. js: Machine learning for the web and beyond,” _Proceedings of Machine Learning and Systems_ , vol. 1, pp. 309–321, 2019.
  * [30] “Solidity.” [Online]. Available: https://soliditylang.org/
  * [31] D. Cer, Y. Yang, S.-y. Kong, N. Hua, N. Limtiaco, R. S. John, N. Constant, M. Guajardo-Cespedes, S. Yuan, C. Tar _et al._ , “Universal sentence encoder,” _arXiv preprint arXiv:1803.11175_ , 2018.
  * [32] Chainalysis, “The 2022 crypto crime report,” Chainalysis Inc., Tech. Rep., 2022\. [Online]. Available: https://go.chainalysis.com/2022-Crypto-Crime-Report.html
  * [33] “Rug pull.” [Online]. Available: https://academy.binance.com/en/glossary/rug-pull
  * [34] “Ethereum virtual machine (evm).” [Online]. Available: https://ethereum.org/en/developers/docs/evm
  * [35] Q. Wang, R. Li, Q. Wang, and S. Chen, “Non-fungible token (nft): Overview, evaluation, opportunities and challenges,” _arXiv preprint arXiv:2105.07447_ , 2021.
  * [36] T. Mikolov, I. Sutskever, K. Chen, G. S. Corrado, and J. Dean, “Distributed representations of words and phrases and their compositionality,” _Advances in neural information processing systems_ , vol. 26, 2013.
  * [37] K. W. Church, “Word2vec,” _Natural Language Engineering_ , vol. 23, no. 1, pp. 155–162, 2017.
  * [38] J. Pennington, R. Socher, and C. D. Manning, “Glove: Global vectors for word representation,” in _Proceedings of the 2014 conference on empirical methods in natural language processing (EMNLP)_ , 2014, pp. 1532–1543.
  * [39] H. Palangi, L. Deng, Y. Shen, J. Gao, X. He, J. Chen, X. Song, and R. Ward, “Deep sentence embedding using long short-term memory networks: Analysis and application to information retrieval,” _IEEE/ACM Transactions on Audio, Speech, and Language Processing_ , vol. 24, no. 4, pp. 694–707, 2016.
  * [40] T. Mikolov, K. Chen, G. Corrado, and J. Dean, “Efficient estimation of word representations in vector space,” _arXiv preprint arXiv:1301.3781_ , 2013\.
  * [41] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, Ł. Kaiser, and I. Polosukhin, “Attention is all you need,” _Advances in neural information processing systems_ , vol. 30, 2017.
  * [42] M. Iyyer, V. Manjunatha, J. Boyd-Graber, and H. Daumé III, “Deep unordered composition rivals syntactic methods for text classification,” in _Proceedings of the 53rd annual meeting of the association for computational linguistics and the 7th international joint conference on natural language processing (volume 1: Long papers)_ , 2015, pp. 1681–1691.
  * [43] F. A. Gers, J. Schmidhuber, and F. Cummins, “Learning to forget: Continual prediction with lstm,” _Neural computation_ , vol. 12, no. 10, pp. 2451–2471, 2000.
  * [44] S. Hochreiter and J. Schmidhuber, “Lstm can solve hard long time lag problems,” _Advances in neural information processing systems_ , vol. 9, 1996\.
  * [45] Y. Bengio, A. Courville, and P. Vincent, “Representation learning: A review and new perspectives,” _IEEE transactions on pattern analysis and machine intelligence_ , vol. 35, no. 8, pp. 1798–1828, 2013.
  * [46] J. MacQueen, “Classification and analysis of multivariate observations,” in _5th Berkeley Symp. Math. Statist. Probability_ , 1967, pp. 281–297.
  * [47] K. Krishna and M. N. Murty, “Genetic k-means algorithm,” _IEEE Transactions on Systems, Man, and Cybernetics, Part B (Cybernetics)_ , vol. 29, no. 3, pp. 433–439, 1999.
  * [48] F. Rahutomo, T. Kitasuka, and M. Aritsugi, “Semantic cosine similarity,” in _The 7th international student conference on advanced science and technology ICAST_ , vol. 4, no. 1, 2012, p. 1.
  * [49] R. A. Horn and C. R. Johnson, _Matrix analysis_. Cambridge university press, 2012.
  * [50] C. Faith and E. A. Walker, “Direct sum representations of injective modules,” _J. Algebra_ , vol. 5, no. 2, pp. 203–221, 1967.
  * [51] Y. LeCun, Y. Bengio _et al._ , “Convolutional networks for images, speech, and time series,” _The handbook of brain theory and neural networks_ , vol. 3361, no. 10, p. 1995, 1995.
  * [52] N. Srivastava, G. Hinton, A. Krizhevsky, I. Sutskever, and R. Salakhutdinov, “Dropout: a simple way to prevent neural networks from overfitting,” _The journal of machine learning research_ , vol. 15, no. 1, pp. 1929–1958, 2014.
  * [53] “Vyper.” [Online]. Available: https://vyper.readthedocs.io
  * [54] “These are the top 10 programming languages in blockchain.” [Online]. Available: https://thenextweb.com/news/javascript-programming-java-cryptocurrency
  * [55] T. Chen, X. Li, X. Luo, and X. Zhang, “Under-optimized smart contracts devour your money,” in _2017 IEEE 24th international conference on software analysis, evolution and reengineering (SANER)_. IEEE, 2017, pp. 442–446.
  * [56] N. Grech, M. Kong, A. Jurisevic, L. Brent, B. Scholz, and Y. Smaragdakis, “Madmax: Surviving out-of-gas conditions in ethereum smart contracts,” _Proceedings of the ACM on Programming Languages_ , vol. 2, no. OOPSLA, pp. 1–27, 2018.
  * [57] S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy, R. Takhaviev, E. Marchenko, and Y. Alexandrov, “Smartcheck: Static analysis of ethereum smart contracts,” in _Proceedings of the 1st International Workshop on Emerging Trends in Software Engineering for Blockchain_ , 2018, pp. 9–16.
  * [58] P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Buenzli, and M. Vechev, “Securify: Practical security analysis of smart contracts,” in _Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security_ , 2018, pp. 67–82.
  * [59] B. Jiang, Y. Liu, and W. K. Chan, “Contractfuzzer: Fuzzing smart contracts for vulnerability detection,” in _2018 33rd IEEE/ACM International Conference on Automated Software Engineering (ASE)_. IEEE, 2018, pp. 259–269.
  * [60] J. Krupp and C. Rossow, “teether: Gnawing at ethereum to automatically exploit smart contracts,” in _27th USENIX Security Symposium (USENIX Security 18)_ , 2018, pp. 1317–1333.
  * [61] I. Nikolić, A. Kolluri, I. Sergey, P. Saxena, and A. Hobor, “Finding the greedy, prodigal, and suicidal contracts at scale,” in _Proceedings of the 34th annual computer security applications conference_ , 2018, pp. 653–663.
  * [62] Y. Zhang, S. Ma, J. Li, K. Li, S. Nepal, and D. Gu, “Smartshield: Automatic smart contract protection made easy,” in _2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER)_. IEEE, 2020, pp. 23–34.
  * [63] Y. Zhuang, Z. Liu, P. Qian, Q. Liu, X. Wang, and Q. He, “Smart contract vulnerability detection using graph neural network,” in _IJCAI_ , 2020, pp. 3283–3290.
  * [64] Z. Liu, P. Qian, X. Wang, Y. Zhuang, L. Qiu, and X. Wang, “Combining graph neural networks with expert knowledge for smart contract vulnerability detection,” _IEEE Transactions on Knowledge and Data Engineering_ , 2021\.
  * [65] M. Vasek and T. Moore, “There’s no free lunch, even using bitcoin: Tracking the popularity and profits of virtual currency scams,” in _International conference on financial cryptography and data security_. Springer, 2015, pp. 44–61.
  * [66] H. Hu, Q. Bai, and Y. Xu, “Scsguard: Deep scam detection for ethereum smart contracts,” in _IEEE INFOCOM 2022-IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS)_. IEEE, 2022, pp. 1–6.