# Unravelling Token Ecosystem of EOSIO Blockchain

Weilin Zheng<EMAIL_ADDRESS>Bo Liu<EMAIL_ADDRESS>Hong-Ning Dai<EMAIL_ADDRESS>Zigui Jiang<EMAIL_ADDRESS>Zibin
Zheng<EMAIL_ADDRESS>Muhammad Imran<EMAIL_ADDRESS>School of
Computer Science and Engineering, Sun Yat-sen University, Guangzhou, China
Department of Computing and Decision Sciences, Lingnan University, Hong Kong,
China  School of Engineering, Information Technology and Physical Sciences,
Federation University, Australia

###### Abstract

Being the largest Initial Coin Offering project, EOSIO has attracted great
interest in cryptocurrency markets. Despite its popularity and prosperity
(e.g., 26,311,585,008 token transactions occurred from June 8, 2018 to Aug. 5,
2020), there is almost no work investigating the EOSIO token ecosystem. To
fill this gap, we are the first to conduct a systematic investigation on the
EOSIO token ecosystem by conducting a comprehensive graph analysis on the
entire on-chain EOSIO data (nearly 135 million blocks). We construct token
creator graphs, token-contract creator graphs, token holder graphs, and token
transfer graphs to characterize token creators, holders, and transfer
activities. Through graph analysis, we have obtained many insightful findings
and observed some abnormal trading patterns. Moreover, we propose a fake-token
detection algorithm to identify tokens generated by fake users or fake
transactions and analyze their corresponding manipulation behaviors.
Evaluation results also demonstrate the effectiveness of our algorithm.

###### keywords:

Blockchain, EOSIO, Token, Fake Detection, Graph Analysis

††journal: Journal of LaTeX Templates

##  1 Introduction

Cryptocurrencies such as Bitcoin [1] and Ethereum [2] have received great
interest from investors [3]. As an underlying technology, blockchain has
essentially established a distributed database with characteristics like
traceability, security, and immutability [4]. Meanwhile, smart contracts
running on top of blockchains can automate business processes, simplify
trading actions, and reduce administrative costs [5, 6, 7, 8]. However,
blockchains like Bitcoin and Ethereum suffer from a low transaction throughput
due to inefficient consensus protocols [9, 10, 11], like Proof-of-Work (PoW).
Thus, they are incapable of supporting real-time trading services.

In contrast to PoW-based blockchain systems [12], EOSIO adopts a more
efficient consensus protocol – Delegated Proof-of-Stake (DPoS) [13, 14]. It
allows EOSIO to achieve much higher transaction throughput (up to 8,000
transactions per second) and much lower confirmation latency (within one
second) than Bitcoin and Ethereum [15]. Consequently, EOSIO has become an
attractive option for many decentralized applications (DApps), especially for
applications having a stringent requirement on trading time. According to
Crowdfundinsider [16], EOSIO has become one of the largest Initial Coin
Offering (ICO) projects (over $4 billion). A recent report indicates that the
average transaction volume of EOSIO within 24 hours has reached 57 million (80
million at peak) [17]. By comparison, Ethereum has an average volume of only
717,000 transactions (1.3 million at peak) within 24 hours.

ICO has become a new approach for many startups to raise funds. Different from
traditional angel finance or venture capital, an ICO issuer raises
cryptocurrencies by selling blockchain-based digital assets to users. In this
way, cryptocurrencies can be interchanged with fiat money, consequently
boosting the cryptocurrency economy. During this process, digital assets, also
called _tokens_ , act as the programmable assets or access rights of
participants in the blockchain. Tokens are essentially managed by smart
contracts and underlying blockchains. Owing to the high liquidity brought by
the high transaction throughput and low confirmation latency, EOSIO tokens
have become one of the most ideal choices for ICOs. Meanwhile, the waiver of
trading fees in EOSIO is another attractive feature to stakeholders (e.g.,
token issuers and holders).

Figure 1: An overview of the proposed framework to analyze EOSIO token data

###  1.1 Motivation

Surprisingly, there are few studies on cryptocurrencies of EOSIO, considering
its huge token transaction volume (i.e., more than 26.3 billion). An in-depth
investigation of the EOSIO token ecosystem can help to reveal its internal
mechanism and understand economic activities in EOSIO so as to demystify the
token ecosystem. Despite a myriad of studies on EOSIO smart contracts [18,
19], EOSIO vulnerabilities [20], and the Ethereum tokens [21, 22, 23, 24, 25,
26] (a more comprehensive literature survey to be given in Section 7), there
is _no work to comprehensively investigate the EOSIO token ecosystem_ to the
best of our knowledge.

To fill this gap, we conduct a systematic study on the EOSIO token ecosystem
by performing extensive graph analysis on the entire on-chain EOSIO data. As
shown in Fig. 1, our study consists of four phases: (1) we collect the data of
EOSIO and parse the token-related datasets; (2) we investigate the token
ecosystem by constructing token creator graphs (TCGs), token contract creator
graphs (TCCGs), and token holder graphs (THGs); (3) we analyze abnormal
trading patterns by constructing token transfer graphs; (4) we propose an
algorithm to detect suspicious tokens generated by fake users or fake
transactions and analyze their corresponding manipulation behaviors.

###  1.2 Contributions

In summary, we make the following contributions.

  1. 1.

To the best of our knowledge, we are the first to conduct a holistic
measurement study on the whole EOSIO token ecosystem via graph analysis. After
synchronizing the entire EOSIO data and gathering a large-scale dataset of all
token-related transactions, we construct multiple graphs to characterize token
creators, token contract creators, and token holders. The graph analysis
offers an in-depth exploration of the entire EOSIO token ecosystem. We also
compare EOSIO with Ethereum in token ecosystems.

  2. 2.

After conducting the exploratory graph analysis, we analyze the tokens-
transfer flows and observe some anomalous behaviors done by the accounts
having large indegree or outdegree. These findings help us to identify
abnormal trading patterns in EOSIO.

  3. 3.

We propose a fake-token detection algorithm to detect “fake” tokens and
identify manipulation behaviors. We extract several abnormal tokens and reveal
their abnormal behaviors. Evaluation results further demonstrate the
effectiveness of the algorithm.

The rest of the paper is organized as follows. After reviewing EOSIO and its
internal mechanism in Section 2, we detail our study design and data
collection in Section 3. Section 4 then provides an overview of the EOSIO
token ecosystem based on graph analysis. Section 5 next investigates the token
transfer flows and identify some abnormal trading patterns. Section 6 depicts
the fake-token detection algorithm to identify the “fake” tokens. After
reviewing related work in Section 7, we conclude the paper and outline future
directions in Section 8.

##  2 EOSIO in a Nutshell

###  2.1 Blockchain and EOSIO

In general, a typical blockchain [27, 28, 29] is a globally-shared and
distributed database, which is composed of a series of blocks containing
transactions. A transaction refers to the interactive operation between users.
And a block is constructed by transactions. Each block is confirmed by the
entire network through a consensus protocol, such as PoW, PoS, and DPoS [11,
10, 9, 30]. Participants in a blockchain system can read and write
transactions in the blockchain database. There is no central authority in the
blockchain. All the transactions are determined by the consensus protocol in a
decentralized manner. As the core of blockchain technologies, the consensus
protocol plays an important role in the development of the blockchain
ecosystem.

As two main blockchain platforms, both Bitcoin and Ethereum are limited by PoW
consensus protocols [12, 31]. For example, Bitcoin only supports 7
transactions per second while Ethereum supports 15 transactions per second.
Different from Bitcoin and Ethereum, EOSIO adopts a more efficient consensus -
DPOS - to scale the throughput to millions of transactions per second. Owing
to the high scalability, EOSIO has gained huge popularity among users and
developers. Another attraction of EOSIO to investors is the waiver of trading
fees for any transactions, thereby greatly reducing the expenditure of high-
frequency trading (such as arbitrage) for investors.

The working flow of EOSIO is summarized as follows. 1) A _user_ first
registers an EOSIO account, which can uniquely determine its identity. 2) The
user interacts with the EOSIO blockchain through the invocation of smart
contracts. The interaction is called an _action_ in EOSIO [32]. 3) An EOSIO
_smart contract_ written in C++ consists of contractual clauses, which can be
invoked to be executed in EOSIO virtual machine (EOSVM) [33], consequently
generating a number of transactions to be stored in the EOSIO blockchain. 4)
An EOSIO _transaction_ contains specific information about one or multiple
users’ actions, e.g., transferring tokens from one user to another.

###  2.2 Transaction, Action, and Account

An EOSIO transaction consists of several actions, each of which represents an
_atomic_ operation [32]. Like traditional distributed database systems, the
atomicity of a transaction means an indivisible set of actions in one
transaction, i.e., either all of them are successful or none of them are
successful. For example, a user namely Alice initiates an action consisting of
(a) creating a new token named “TEST” and (b) transferring 10.0000 EOS111EOS
is the token of EOSIO, similar to ether in Ethereum and BTC in Bitcoin. to
Bob. Both actions (a) and (b) should occur either at the same time or none of
them occurs. Both of the two actions are packaged into one transaction to be
submitted to the EOSIO blockchain. As long as one of the actions fails, the
entire transaction fails.

In EOSIO, a transaction is submitted by an account represented by a string
with the length up to 12 characters. Creating a new account in EOSIO requires
an existing account to pay a certain amount of EOS for RAM resources to store
the account information. The existing account can be considered as the creator
of the new account. Different from EOSIO, a new account (address) creation in
Ethereum does not require the help of other accounts. This account-creation
mechanism implies stronger relationships of EOSIO accounts than Ethereum.
Therefore, it is worth investigating the relationships between EOSIO accounts
while previous studies on Ethereum often ignore the relationship analysis. In
Section 6, we propose an algorithm to detect “fake” tokens and analyze the
relationships of EOSIO accounts.

###  2.3 Smart Contract and Token

Nowadays, most blockchain systems support smart contracts that run in virtual
machines. Like other blockchain systems such as Ethereum, EOSIO smart
contracts are also executed on top of EOSVM. In EOSIO, a smart contract
written in C++ is first compiled to WebAssembly machine code (aka bytecode),
which is then executed in EOSVM. Unlike Ethereum equipped with a _gas_
mechanism, EOSIO adopts a different resource-management mechanism, which
limits the _RAM_ , _CPU_ and _Bandwidth_ resources for transaction execution
to solve the halting problem [34, 32]. In EOSIO, an account can act as both a
common user and a contract at the same time. When created, an account first
acts as a common user. Authorized by its private key, it can interact with the
blockchain on behalf of the user, such as sending tokens to other accounts.
When this account is used to deploy a contract, the bytecode is stored into
the account, which also serves as a contract. When a user invokes the
contract, he/she initiates actions to the account. Consequently, the
corresponding bytecode is executed in EOSVM to change the states of the
blockchain. It is worth noting that the bytecode of an account can be updated
(as long as owning its private key) in EOSIO, which is nevertheless not
allowed in Ethereum.

In EOSIO, developers can easily use smart contracts to build their projects or
DApps. Due to the waiver of trading fees and the simple development process of
EOSIO DApps, many startups and ICOs raise funds by creating and issuing new
tokens on the EOSIO platform. Any user can buy certain tokens of ICO DApps
with EOS1, which is the native token of EOSIO. A token that acts like a
digital currency becomes a profitable asset for those shareholders of DApps.
When the EOSIO mainnet went live, a standard token protocol was introduced. As
a result, the EOSIO token ecosystem has prospered rapidly and has soon become
one of the largest token-selling platforms. Required by the EOSIO token
standard, a token contract should consist of three functions: create, issue,
and transfer. Required by the EOSIO token standard, a token contract should
consist of three functions: create, issue, and transfer. Using this condition,
we can filter all standard token contracts on the EOSIO mainnet. If we parse
the token-related transactions, we then can know how the tokens are
transferred, where they go, and by whom they are held. It is worth mentioning
that a token contract in EOSIO can create multiple tokens with different
symbols and different contracts can create tokens with the same symbol. By
contrast, this feature is also not allowed in Ethereum. Therefore, we uniquely
mark a token with “contract@symbol” in EOSIO.

##  3 Study Design & Data Collection

###  3.1 Research Questions & Study Methods

In this paper, we aim to answer the following three research questions (RQs)
when investigating the EOSIO token ecosystem:

  1. RQ1.

What are the market characteristics of the EOSIO token ecosystem? The EOSIO
token ecosystem has huge market values due to its popularity and massive
transactions. However, as far as we know, there is no study on investigating
market characteristics by exploratory analysis on the EOSIO token data. To
this end, we conduct a comprehensive graph analysis on tokens, holders,
creators by constructing token creator graphs (TCGs), token holder graphs
(THGs), and token contract creator graphs (TCCGs), respectively, accompanied
by the relationship analysis.

  2. RQ2.

Are there anomalous trading activities in the EOSIO token ecosystem? Tokens
transferred in EOSIO reveal the trading flows, which can be used to identify
trading activities, especially for those anomalous trading activities that may
be a detriment to the EOSIO ecosystem. After analyzing token transfer graphs
(TTGs) and characterizing the features, we find that some “center” accounts
have many transfer actions. We then analyze mutual trading activities and
detect abnormal trading patterns.

  3. RQ3.

Can we identify the tokens with fake users and transactions? Although millions
of token-related transactions occur in EOSIO, fake users or transactions
commonly appear in EOSIO. Due to the waiver of trading fees of EOSIO, many
token issuers intentionally increase both trading and user volumes of tokens
with nearly no extra cost, thereby boosting the token popularity and gaining
extravagant profits. To address this problem, we design an algorithm to detect
these “fake” tokens. We find that some identified cases can effectively reveal
manipulation behaviors of tokens.

###  3.2 Data Collection

The collection of all the token-related actions requires replaying all
transactions and gathering a large-scale dataset of all actions. However, the
large transaction volume of EOSIO poses challenges in replaying transactions
and efficiently obtaining the entire on-chain data. Although the EOSIO
development team offers the client Nodeos and several plugins, like
state_history_plugin and mongo_db_plugin, the official plugins severely slow
down the replay procedure due to parsing and insertion operations of raw data
to databases. These plugins collect the raw data when replaying transactions,
and then parse them into the well-formatted data for some database engines
(i.e., PostgreSQL and MongoDB). Finally, the formatted data are inserted into
the database according to certain indexes (with the purpose of fast query).
Data insertion operations take extra time during the replaying procedure.
Meanwhile, data parsing and insertion operations are conducted serially and
may affect each other, thereby further slowing down the replaying procedure.

To address these challenges, we develop a new data-replaying plugin -
history_file_plugin to collect raw data and write them into Memory Buffer
during the replaying procedure. Then, another thread asynchronously reads the
data from Memory Buffer, serializes, and finally saves them directly as JSON
files. Since the subsequent data preprocessing is conducted on these files
without affecting the replaying procedure, history_file_plugin allows data
collection and data processing to be carried out simultaneously, consequently
speeding up data collection. Our plugin greatly saves time in collecting the
entire on-chain data in contrast to official plugins of EOSIO. For example,
our plugin takes only 1/7 time to synchronize the first 20 million blocks,
compared with the official plugins of EOSIO222Our plugin is expected to obtain
even better results than the official plugins for the entire EOSIO dataset
because of no insertion operations to databases..

Table 1: EOSIO Token Data: Block #1 to #134,999,999 Category | Approximate size of Dataset | Row Count
---|---|---
token create actions | 944 KB | 5,598
token issue actions | 40.42 GB | 253,711,757
token transfer actions | 4.23 TB | 26,311,585,008
account creation actions | 244.62 MB | 1,332,669

EOSIO Token Data Summary: We have launched Nodeos and our own
history_file_plugin to run an EOSIO full node and replay all the transactions
(up to 134,999,999 blocks) to get the entire on-chain data (including blocks,
transaction receipts, action traces) from June 8, 2018 to Aug. 5, 2020.
According to the token standard defined by EOSIO, we filter out all standard
tokens and extract the token-related actions covering creation, issuance, and
transfer. Table 1 summarizes the EOSIO token data, which obviously has much
larger volumes than Ethereum [35]. More details about the dataset are shown
below.

Token Information: In EOSIO, a contract that contains three standard functions
of create, issue, and transfer can be regarded as a standard token contract.
According to this feature, we filter out 2,047 contracts to be considered as
standard token contracts, which have created and issued 5,598 tokens. For
these 5,598 tokens, we collect the data including create actions, issue
actions, and transfer actions for each token. A create action represents that
a user creates a token through a token contract. An issue action represents
that an issuer issues some tokens to a user directly (also known as Token
Airdrop), while a transfer action represents that a user sends some tokens to
another user. There are 253,711,757 token issue actions that were submitted by
2,140 issuers and 26,311,585,008 token transfer actions that occurred in
1,332,669 holding accounts. Table 2 illustrates an example of a transfer
action for helping readers further understand the format of the dataset. And
the format of the other two actions is simple and similar to that of the
transfer action.

Account Information: In EOSIO, creating a new account requires an existing
creator to pay a certain amount of EOS. There are 2,096,840 distinct accounts,
which were created by only 48,691 account creators. We filter out all account
creation actions and extract their relationship as the format shown in Table
3.

Table 2: Token Transfer Format Category | Description | Data
---|---|---
txid | transaction id | 07fc627668a471c3d...
block_time | block timestamp | 2018-06-10T14:23:39.000
contract@symbol | the token contract and token symbol | eosnowbanker@EOSNOW
from | token sender | eosnowbanker
to | token receiver | gqztamzsg4ge
quantity | the amount of token | 10000.0000 EOSNOW
memo | transfer memo | Now is now Now
Table 3: Account Creation Format Category | Description | Data
---|---|---
txid | transaction id | 245786e9d77657a5e...
block_time | block timestamp | 2018-06-12T17:05:16.500
creator | the name of the creator | hezdqmbygyge
name | the new account name | iloveuzi3344

##  4 Token Analysis

In this section, we provide an overview of the EOSIO token ecosystem. We
concentrate our study on the tokens and explore the characteristics of the
token ecosystem. Based on the analysis, we obtain the following findings.

  * •

Finding 1: Despite a huge volume of token transfer actions (exceeding 26.3
billion), most of the tokens are “silent”. Specifically, nearly 80% of the
tokens are traded less than 100 times and only 1% of the tokens cover more
than 90% of the total token volume.

  * •

Finding 2: Tokens can be created by an account through one or multiple
contracts. Some accounts create a large number of tokens through one contract
possibly because of testing or “just for fun”. On the contrary, few creators
create multiple tokens through multiple contracts.

  * •

Finding 3: A small number of accounts (might be some exchanges) hold a large
number of tokens while most accounts hold a small number of tokens. Similarly,
most tokens are held by a small number of holders while only a small number of
holders have a large number of tokens.

###  4.1 Token Activeness and Token Usage

As an important measure on the health of the token ecosystem, the degree of
the _token activeness_ reveals the network status and the availability of the
ecosystem. We first define the _token activeness_ of a token as the number of
its transfer actions. This metric has been used as an important indicator for
ranking in many DApp websites (e.g., DappReview). We then plot the
distribution of the token activeness in Fig. 2(a), from which the _Matthew
effect_ [36] can be observed. Nearly 27.9% of the tokens have never been
transferred, and 78.9% of the tokens are transferred less than 100 times.
Meanwhile, 1% of the tokens cover more than 90% of the total volume, thereby
further confirming the existed Matthew effect. This result indicates that most
tokens do not succeed from the perspective of users’ activity. In other words,
there are only a few _active_ tokens while most of them are silent. To further
analyze the token activeness, we plot the fitted line for the distribution
through $y{\sim}x^{-\beta}$ as shown in Fig. 2(a). The larger $\beta$ leads to
the smaller degree of the token activeness.

(a) Distribution of token activeness

(b) Word cloud of memos

Figure 2: Token activeness and usage Table 4: Top-5 Tokens according to Token Activeness Tokens | Number of transfer actions | Identities
---|---|---
eidosonecoin@EIDOS | 23,484,345,961 | Airdrop for DDoS attack
eosiopowcoin@POW | 1,793,696,754 | CPU Mining
betdicetoken@DICE | 103,865,132 | BetDice, Gambling Game
bgbgbgbgbgbg@BG | 74,043,095 | BigGame, Gambling Game
mine4charity@MICH | 67,464,460 | CPU Mining

Table 4 lists the top-5 most active tokens. We find that EIDOS is the most
active token with up to 23 billion transfer actions. According to
“Blocking.net”, EIDOS leads to a token airdrop feast aimed at exposing the
defects of EOSIO’s resource management and even “killing” EOSIO [37]. Anyone
who transfers 0.0001 EOS to contract eidosonecoin can then receive 0.0001 EOS
as well as some EIDOS tokens from eidosonecoin. To gain more EIDOS tokens,
many users submitted a large number of transfer actions to eidosonecoin,
thereby consuming substantial CPU resources. At the peak, the CPU resources
consumed by eidosonecoin occupy 60% of the entire network according to
DAppTotal [38], consequently causing users to be unable to transfer money
normally and leading to the dysfunction of other DApps. This abnormal behavior
can be regarded as a DDoS attack on the EOSIO mainnet. POW and MICH have a
similar operating model (commonly known as CPU Mining) to EIDOS. All these
projects caused some harm to EOSIO’s resource management. Acting as tokens for
gambling games, both DICE and BG have been operating gambling markets since
September 2018. From the popularity of these two tokens, we speculate the
popularity of gambling and gaming in EOSIO owing to the waiver of trading fees
of EOSIO in contrast to other blockchain platforms.

It is difficult to verify the functionality of each token since most tokens do
not have any relevant information except for some well-known ones. Thus, we go
through all the transfer actions of each token and collect the memo of each
action. These memos usually imply the purposes of the actions (e.g., betting)
and the potential identities of the _senders_. Fig. 2(b) depicts the word
cloud of the memos of EOSIO tokens. The most common word is “Airdrop”,
indicating that the token airdrop occurs the most frequently in EOSIO.
Meanwhile, the words “EIDOS”, “POW”, “Mine” indicate the prevalence of CPU
Mining. Other frequent words include “Bet”, “Game”, “Prize” (related to
gambling and game actions), further confirming the huge popularity of both
gambling apps and games in EOSIO.

###  4.2 Token Creators

Different from Ethereum, in which one token contract can create only one
token, a contract in EOSIO can create one or multiple tokens, as shown in Fig.
3. In the first case, an account is able to deploy one token contract, which
can be invoked to create multiple tokens, as shown in Fig. 3(a). Thus, a
contract in EOSIO can be reused for token creation. In the second case, an
account can create multiple tokens through multiple contracts, as shown in
Fig. 3(b). EOSIO allows different contracts to create tokens with the same
name (symbol) while Ethereum disallows this feature.

(a) One contract creates one token

(b) One contracts creates multiple tokens

Figure 3: Relationship between accounts and tokens

To investigate the relationships between tokens and accounts, we focus on the
number of tokens created by each account. We introduce $\mathsf{TCG}$ to
investigate token creators as follows:

$\mathsf{TCG}=(V_{\text{at}},E_{\text{at}},D),E_{\text{at}}=\\{(v_{i},v_{j},d)|v_{i},v_{j}\in
V_{\text{at}},d\in D\\},$

where $V_{\text{at}}$ is a set of accounts and tokens, and $E_{\text{at}}$ is
a set of edges. Each edge $(v_{i},v_{j},d)$ indicates the creation
relationship between an account $v_{i}$ and a token $v_{j}$ with a timestamp
$d$ (between June 10, 2018 and Aug. 5, 2020, the same below). To explore
whether there are tokens with the same symbol, we use “symbol” instead of
“contract@symbol” to mark a token node in $\mathsf{TCG}$.

(a) $\mathsf{TCG}$

(b) Outdegree distribution of $\mathsf{TCG}$

Figure 4: Visualization of Token Creators ($\mathsf{TCG}$)

Fig. 4(a) illustrates the $\mathsf{TCG}$ constructed from our collected
dataset, where creators are marked in blue and tokens are marked in red. We
observe from Fig. 4(a) that a small number of accounts create a large number
of tokens (i.e., one blue node is circled by many red nodes) while most of the
accounts only create one or two tokens. Meanwhile, we also find an abnormal
phenomenon, in which one red node is circled by many blue nodes. It can be
explained by the fact that the tokens with the same symbol are created by
multiple creators. For example, we find that there are 158 tokens named EOS
being created by 158 accounts through different contracts. One reason why
creators prefer the symbol EOS may lie in EOS being the native token of EOSIO
so as to attract more attention. Moreover, some attackers also create the
token named EOS to initiate the “fake EOS” attacks to some vulnerable
contracts and steal tokens [20].

To further analyze the characteristics of the $\mathsf{TCG}$, we plot the
_outdegree distribution_ of creators in Fig. 4(b). The _outdegree
distribution_ essentially indicates the number of tokens created by the
creators. Fig. 4(b) reveals a strong power-law distribution reflecting a small
number of nodes with a large outdegree. Moreover, nodes with smaller outdegree
in the token ecosystem account for the majority. For example, nearly 80.6% of
the creators only created one token and 95.7% of the creators created no more
than 5 tokens. In addition, the account who created the most number of tokens
monopolized 517 tokens, leading to a severe polarization of distribution.

Besides the relationship between tokens and creators (as analyzed in
$\mathsf{TCG}$), we next analyze the relationship between tokens and token
contracts. We define $\mathsf{TCCG}$ as follows:

$\mathsf{TCCG}=(V_{\text{tc}},E_{\text{tc}},D),E_{\text{tc}}=\\{(v_{i},v_{j},d)|v_{i},v_{j}\in
V,d\in D\\},$

where $V_{\text{tc}}$ is a set of the token contracts and tokens and
$E_{\text{tc}}$ is a set of edges. An edge $(v_{i},v_{j},d)$ represents that a
token $v_{i}$ is created by a token contract $v_{j}$ on timestamp $d$.
$\mathsf{TCCG}$ has a similar distribution to $\mathsf{TCG}$, implying that
both $\mathsf{TCG}$ and $\mathsf{TCCG}$ have homologous relationships. A token
often has the same account for its creator and its contract (as mentioned in
Section 2, an account can act as both a user and a contract). Meanwhile, we
also find that creators prefer using the same contract rather than using
multiple contracts to create multiple tokens. The reusability of token
contracts brings convenience and saves costs since creators do not need to
deploy another contract.

Who Created The Most Tokens? We then concentrate on the accounts that created
the most tokens and summarize the relevant characteristics of top-3 creators.
Account okkkkkkkkkkk is the creator with the most number of tokens (517
tokens). By carefully analyzing all actions related to account okkkkkkkkkkk,
we find that okkkkkkkkkkk usually receives eosbtextoken@BT tokens from many
accounts and then sends different tokens (e.g., USDS, DNA, LOVEYOU) to these
accounts. It implies that okkkkkkkkkkk is probably an intermediary between BT
token and other tokens, thereby providing a decentralized service for token
exchange. The second-rank creator chengyahong1 creates 284 tokens while the
third-rank creator ppiotransfer creates 270 tokens. Our further analysis shows
that both these two creators often issue or send the tokens created by
themselves to the same account, implying that they may create tokens for
testing or just for fun. To reveal the differences between these creators, we
study the distribution of token creation over time after counting the number
of tokens created by these three creators everyday. As shown in Fig. 5,
okkkkkkkkkkk has been continuously creating tokens. Account okkkkkkkkkkk has
tracked the new initiated projects as well as their tokens and created new
tokens and token pairs to meet the needs for the token exchange of ICOs. This
further confirms the identity of okkkkkkkkkkk, who is a token intermediary. On
the contrary, both accounts chengyahong1 and ppiotransfer only sporadically
create tokens.

Figure 5: Distribution of token creation over time

###  4.3 Token Holders

We further investigate the holders of the tokens and identify their
characteristics. To this end, we define and construct $\mathsf{THG}$ as
follows:

$\mathsf{THG}=(V_{\text{th}},E_{\text{th}},w),E=\\{(v_{i},v_{j},w)|v_{i},v_{j}\in
V,w\in(0,1]\\},$

where $V_{\text{th}}$ is a set of tokens and holders, and $E_{\text{th}}$ is a
set of edges, in which each edge indicates the holding relationship between a
holder $v_{i}$ and a token $v_{j}$. Note that each edge is also associated
with a weight $w$, indicating that $v_{i}$ holds $w$ shares of token $v_{j}$.

Fig. 6 presents an exploratory analysis of $\mathsf{THG}$. Fig. 6(a) first
gives the visualization of $\mathsf{THG}$, in which the purple nodes denote
the tokens and the red nodes denote the holders. Fig. 6(a) reveals that
several popular tokens are owned by many holders while most of the tokens are
still possessed by very few holders. Figs. 6(b) and 6(c) show the _indegree_
and _outdegree distribution_ of $\mathsf{THG}$, respectively. The indegree of
a token in $\mathsf{THG}$ means the number of its holders while the outdegree
of a holder is the number of tokens that he/she holds. We observe an
approximate power-law distribution, i.e., there are lots of small-degree nodes
while few large-degree nodes.

(a) $\mathsf{THG}$

(b) $\mathsf{THG}$ indegree distribution

(c) $\mathsf{THG}$ outdegree distribution

Figure 6: Visualization of Token Holders

Who Hold the Most Tokens? Analyzing the _outdegree distribution_ of the
holders, we find that there are 1,332,669 holders and 35.63% of them hold only
one token in the token ecosystem. Moreover, 84.88% of the holders possess
fewer than 20 tokens. Table 5 lists the top-3 holders possessing the most
tokens, and Invocation in Table 5 represents the number of transfer actions
involving a holder, who is either the _sender_ or the _receiver_.

Table 5: Top-3 Accounts of $\mathsf{THG}$ Using Degree Centrality Accounts | Outdegree | Invocation | Identities
---|---|---|---
newdexiofees | 338 | 3,873,999 | decentralized exchange
5lisqkvt1n2q | 284 | 3,430 | token speculator, arbitrageur
iplayeosgame | 279 | 15,803 | token speculator, arbitrageur

Account newdexiofees that holds the most token (i.e., 338 tokens) can be
considered as the “king” of tokens. newdexiofees is essentially an exchange
initiating a large number of transfer actions (3,873,999); this is confirmed
by its banner “the first globally decentralized exchange based on
EOS”333https://newdex.io/. As for the second-rank account 5lisqkvt1n2q and
third-rank account iplayeosgame, they have 284 tokens and 279 tokens,
respectively. Interestingly, they also have similar outdegree and invocation.
Moreover, we find that both these two accounts have frequently traded with the
exchanges. Thus, we speculate that they may be token speculators who invest in
EOSIO tokens to make profits. Different from 5lisqkvt1n2q, account
iplayeosgame is also a gambler who frequently interacts with other gambling
and gaming DApps.

Which Has the Most Holders? We then analyze the _indegree distribution_ of
$\mathsf{THG}$. Among 5,598 tokens, 52.47% of them only have one holder and
even 78.62% of tokens have less than 10 holders. We consider some well-known
tokens that have many holders and analyze the distribution of daily
participants of tokens over time. According to the number of holders, MPT is
the most popular token possessed by 766,793 holders. As disclosed in
DappRadar, MPT is essentially a token for the supply chain of the metal
packaging industry [39]. The second-rank token is ZOS (604,884 holders), which
is a new token for the discount e-payment system provided by AirDropsDAC [40].
The third-rank token is DICE that has 314,278 holders for BetDice, i.e., one
of the most famous gambling DApps (aforementioned in Table 4). To explore the
popularity of these tokens, we present the daily volume of users and transfer
actions of top-3 tokens according to time, as shown in Fig. 7.

Figure 7: Daily user and transfer action volume

(a) $\mathsf{TTG}$

(b) $\mathsf{TTG}$ in sample

(c) Indegree distribution of $\mathsf{TTG}$

(d) Outdegree distribution of $\mathsf{TTG}$

Figure 8: Visualization of Token Transfer

Although MPT and ZOS are the top-2 tokens, their user volume and action volume
have only sporadically increased (sharply). This phenomenon can be explained
by the fact that these tokens (or DApps) have only received sudden attention
from the public for a short time. Meanwhile, some ICO projects inject lots of
fake users or fake transactions so as to arouse public attention. Section 6
will conduct an in-depth study for this phenomenon. By contrast, there have
been many participants continuously interacting with DICE, implying that
gambling DApps have kept prospering in EOSIO. More interestingly, the user
volume of DICE does not have the same trend as the action volume. In the early
days of DICE launch, its user volume was small despite the surged action
volume. This implies the importance of evaluating the token popularity from
multiple perspectives.

###  4.4 Comparison with Ethereum

Despite several studies [26, 22, 25, 23] on the Ethereum token ecosystem,
there are few studies on the EOSIO token system. Through the above analysis,
we summarize key similarities and differences between the EOSIO and Ethereum
token ecosystems.

Similarities: (1) _The Matthew effect has been observed in both EOSIO and
Ethereum_ in multiple aspects like token activity, token holders, token
creators. Many tokens and holders keep “silent” in the ecosystem. (2)
_Decentralized exchanges (DEX) play an important role in the token ecosystem_
[41]. Examples include newdexiofees in EOSIO, Augur and EtherDelta in Ethereum
[22]. Token exchange is the most active activity in the ecosystem, implying
that there are a lot of arbitrage opportunities for tokens.

Differences: (1) _The number of tokens in EOSIO is much smaller than that in
Ethereum_ , because the cost of deploying and maintaining a token contract in
EOSIO is high (in terms of substantial resources such as CPU, RAM being staked
for users). (2) _One smart contact can create multiple tokens in EOSIO_
although this is not allowed in Ethereum. Project parties in EOSIO are in
favor of creating multiple tokens using the same contract, possibly saving the
cost of token issuance. (3) _Gambling and gaming are the most active
activities in the EOSIO token ecosystem_. The reasons lie in the waiver of
trading fees and a lower confirmation latency than Ethereum. (4) _The
resource-management mechanism in EOSIO is inferior to the gas mechanism in
Ethereum in terms of poor security_ , thereby being exploited by attackers to
attack the ecosystem [42]. For example, the DDoS attack launched by
eidosonecoin@EIDOS almost exhausted CPU resources of the EOSIO mainnet,
resulting in the exceptions of other DApps or tokens. (5) _EOSIO has a much
larger transaction volume than Ethereum_ despite a smaller number of tokens.
The major reason lies in the waiver of trading fees, which also reduces the
cost of injecting fake transactions/users into DApps or tokens.

##  5 Token Transfer Analysis

The exploratory analysis on token creators, holders, and token usage presents
an exploration of the EOSIO token ecosystem. We next investigate the token
transferring network and identify some abnormal trading patterns.

###  5.1 Token Transfer

To study the behavior characteristics of users participating in token
transferring, we define the $\mathsf{TTG}$ as follows:

$\mathsf{TTG}=(V_{\text{tt}},E_{\text{tt}},w),E_{\text{tt}}=\\{(v_{i},v_{j},w)|v_{i},v_{j}\in
V_{\text{tt}},w\in(0,\infty)\\},$

where $V_{\text{tt}}$ is a set of the token holders and $E_{\text{tt}}$ is a
set of edges. Each edge $(v_{i},v_{j},w)$ indicates that a holder $v_{i}$
transfers some tokens to a holder $v_{j}$, where $w$ is the total number of
transfer actions. Hence, $\mathsf{TTG}$ is essentially a weighted directed
graph. Note that we ignore the type and the amount of the transferred tokens
and only count the number of transfer actions since different tokens are not
comparable. As shown in Fig. 8(a), the overall transaction network is
relatively sparse while it contains some closely-connected components (i.e.,
trading groups). After randomly sampling 10,000 edges from Fig. 8(a), we then
reconstruct a sampled $\mathsf{TTG}$ as shown in Fig. 8(b). We further observe
that many accounts are clustered together to form multiple sub-networks. To
have an in-depth understanding of $\mathsf{TTG}$, we further analyze the
distribution of _receivers_ and _senders_ , as depicted in Fig. 8(c) and Fig.
8(d), respectively. In particular, the outdegree of $\mathsf{TTG}$ denotes the
number of transfer actions initiated by a _sender_. The indegree denotes the
number of transfer actions ceased at a _receiver_. The approximate degree
distributions show that a large number of users keep “silent” in the
transferring network. In addition, we find that the accounts with a large
degree are often the center of the closely-connected groups as shown in both
Fig. 8(a) and Fig. 8(b). We will further study these accounts and find the
relationship between them.

Table 6: Top-5 Accounts of $\mathsf{TTG}$ Using Degree Centrality Accounts | Indegree | Outdegree | Identities
---|---|---|---
eidosonecoin | 34,137 | 23,480,436,814 | Token Airdrop
betdicegroup | 15,582,144 | 98,538,083 | BetDice, Gambling DApp
betdicehouse | 58,671,515 | 39,645,381 | BetDice, Gambling DApp
betdicetoken | 78 | 60,557,132 | BetDice, Gambling DApp
mykeypostman | 247,895,918 | 28 | MykeyPocket, Wallet DApp

Who Transfer The Most Tokens? Table 6 shows the top-5 accounts with the
largest degree. Account eidosonecoin is the issuer of token EIDOS (as
mentioned in Table 4), which always sends EIDOS to other accounts for airdrop.
Thus, account eidosonecoin has the largest outdegree of 23,480,436,814 but has
a smaller indegree of 34,137. All the three accounts with a prefix “betdice-”
belong to a gambling DApp called BetDice though some of them have a larger
indegree and some of them have a smaller indegree. This implies that they
provide different functions while all working together to constitute the
gambling DApp. For example, the account with a larger indegree takes stakes
from gamblers while the account with a larger outdegree runs a lottery for
gamblers and pays the bonus. Compared with eidosonecoin, mykeypostman has a
larger indegree (247,895,918) and a smaller outdegree. We find that
mykeypostman is a popular wallet DApp, which provides users with account-
creation services. Since it requires purchasing RAM resources to create
accounts in EOSIO, mykeypostman also requires payment from users.

###  5.2 Abnormal Trading Patterns

We mainly concentrate on the “center” accounts in Fig. 8(b) to find abnormal
trading patterns. The main reason for focusing on “central” accounts lies in
the _relative importance_ of “central” accounts than other “peripheral”
accounts, where the relative importance of an account can be measured by the
PageRank algorithm [43]. We first get the top-14 accounts having lots of
transfer actions and define a “center” token transfer graph ($\mathsf{CTTG}$)
as follows:

$\mathsf{CTTG}=(V_{\text{ct}},E_{\text{ct}},w),E=\\{(v_{i},v_{j},w)|v_{i},v_{j}\in
V_{\text{ct}},w\in(0,\infty)\\},$

where $V_{\text{ct}}$ is a set of the top-14 accounts and $E_{\text{ct}}$ is a
set of edges. The definition of each edge is similar to that of
$\mathsf{TTG}$. The weight $w$ of each edge represents the number of transfer
actions, being represented by the thickness of the edge. We can easily find
some thick edges in Fig. 9, which can be used to explore abnormal patterns.

Figure 9: $\mathsf{CTTG}$

According to the connection types of the nodes, we consider several abnormal
patterns: 1) “binary” pattern, 2) “tree” pattern, and 3) “grid” pattern. As
shown in Fig. 9, eoshashagent frequently trades with eoshashlucky using many
different types of tokens, consequently forming the “binary” pattern. It is
abnormal for users (or investors) to trade with each other so many times,
especially in a traditional financial market. Meanwhile, eidosonecoin in Fig.
9 often sends EIDOS to mykeypostman and nonedunnoned, which also often trades
with pokeneotoken, thereby forming the “tree” pattern. As discussed in Section
4.1, the EIDOS airdrop action can be considered as a DDoS attack. Therefore,
both mykeypostman and nonedunnoned are likely to be accomplices in this
attack. Moreover, all the accounts with the prefix “betdice-” form the “grid”
pattern; all of them belong to a gambling DApp. It is worth mentioning that
there is a thick bidirectional link between betdicegroup and betdicehouse,
both of which may serve as the leaders of this gambling DApp. It is abnormal
that a DApp involves so many accounts which trade with each other so
frequently. So, such a trading network is likely to conduct money-laundering
activities under the guise of gambling. In addition, it is also doubtful that
all the accounts within the same DApp deliberately increase the transaction
volume of tokens to attract huge public attention (like a scam). Further
exploration of these abnormal patterns and related arguments will be carried
out in our future work.

##  6 Fake Token Detection

The exploration on abnormal activities in the token ecosystem implies that
some ICO projects and DApps may be rife with fake tokens owned by fake users
to either attract sudden popularity or make exorbitant profits. This section
aims to detect the “fake” tokens. and find out how malicious ICO projects and
DApps conduct manipulation activities to make their tokens “popular”.

###  6.1 Relationship Between Accounts

We first investigate the account-creation relationship between accounts.
Considering that an account Alice in EOSIO is created by an existing account
Bob, we then regard Bob as the parent of Alice. To describe such a
relationship, we define the account-creation graph ($\mathsf{ACG}$) as below:

$\mathsf{ACG}=(V_{\text{ac}},E_{\text{ac}},D),E_{\text{ac}}=\\{(v_{i},v_{j},d)|v_{i},v_{j}\in
V_{\text{ac}},d\in D\\},$

where $V_{\text{ac}}$ is a set of the accounts, $E_{\text{ac}}$ is a set of
edges indicating the creation relationship between these accounts, and an edge
$(v_{i},v_{j})$ represents that a parent account $v_{i}$ creates a child
account $v_{j}$ on timestamp $d$. As shown in Fig. 10, the result of
$\mathsf{ACG}$ shows that there are a few parent accounts that have
nevertheless created a large number of children accounts. When further
exploring the names of these children accounts, we find a certain similarity
and regularity among them. For example, many account names have the same
prefix (e.g., “bnr”, “gg”) followed by several digits indicating their
sequence number (i.e., created sequentially). These results imply that the ICO
projects and DApps may adopt similar methods to create and control many fake
accounts to frequently interact with their tokens, consequently flourishing
their tokens.

Figure 10: $\mathsf{ACG}$

###  6.2 Algorithm

We then propose an algorithm to identify the “fake” tokens in the ecosystem.
We model the tokens and their users mainly from two dimensions. One dimension
is Average Token Transfer Number Factor (ATTNF), which models the number of
transfer actions of users of a token. Another dimension is Max Token Transfer
Quantity Factor (MTTQF), which models the normalized transfer amount of users
of a token. Both these two factors consider the account-creation relationship
between users, which plays an important role in our algorithm. Our evaluation
results also reveal a strong relationship between the token manipulator and
its controlled children accounts.

Average Token Transfer Number Factor. Considering that a token manipulator
usually controls many accounts, we define the Account Control Factor
($\mathsf{ACF}$) for a token as below:

$\mathsf{ACF}=\frac{\big{|}\\{\text{holder}_{i}|i=1,2,...,n\\}\big{|}}{\big{|}\\{\text{parent}_{j}|j=1,2,...,m\\}\big{|}}\
\text{and}\ m\leq n,$ (1)

where $\text{holder}_{i}$ represents a unique account $i$ who transfers the
token and $\text{parent}_{j}$ represents a parent account of holders in the
set $\\{\text{holder}_{i}|i=1,2,...,n\\}$. For convenience,
$\\{\text{parent}_{j}|j=1,2,...,m\\}$ and
$\\{\text{holder}_{i}|i=1,2,...,n\\}$ are abbreviated to $\mathbb{P}$ and
$\mathbb{H}$, respectively. $\mathsf{ACF}$ is the ratio of the size of
$\mathbb{H}$ to that of $\mathbb{P}$. If a token is only transferred by the
accounts who have the same parent, it is quite possible that the parent
creates a large number of fake children accounts to manipulate transactions,
leading to a large $\mathsf{ACF}$.

However, it is not enough to only consider the relationship between the parent
and its children accounts, because token manipulators who have created lots of
children accounts often have an aim to conduct transfer actions including many
fake transactions. Hence, we define another factor, Action Number Factor
($\mathsf{ANF}$) to further model transfer actions. $\mathsf{ANF}$ is defined
as follows:

$\mathsf{ANF}^{T_{k}}_{\text{holder}_{i}}=\frac{\mathsf{NUMBER}(\text{holder}_{i},T_{k})}{\mathsf{NUMBER}(\text{holder}_{i},\\{T_{k}|k=1,2,...,z\\})},$
(2)

where ${\scriptstyle\mathsf{NUMBER}(\text{holder}_{i},T_{k})}$ represents the
number of the transfer actions on the token $T_{k}$ initiated by the account
$\text{holder}_{i}$. Set $\\{T_{k}|k=1,2,...,z\\}$ represents all tokens held
by ${\text{holder}_{i}}$ and
$\scriptstyle\mathsf{NUMBER}(\text{holder}_{i},\\{T_{k}|k=1,2,...,z\\})$
denotes the number of all the transfer actions of $\text{holder}_{i}$ on all
tokens he/she holds. In other words, if
$\mathsf{ANF}^{T_{k}}_{\text{holder}_{i}}=1$, it implies that
$\text{holder}_{i}$ is created only for interacting with token $T_{k}$. For a
token ${T_{k}}$, we get its Total Action Number Factor ($\mathsf{TANF}$)
across all its holders as follows:

$\mathsf{TANF}=\mathsf{ANF}^{T_{k}}_{\text{holder}_{1}}+\mathsf{ANF}^{T_{k}}_{\text{holder}_{2}}+...+\mathsf{ANF}^{T_{k}}_{\text{holder}_{n}}.$
(3)

To a certain extent, $\mathsf{TANF}$ reflects the “loyalty” of users to a
token. If $\mathsf{TANF}$ is very large, it means that almost all holders of a
token only hold and transfer this token forever. It is possible that these
accounts are manipulated to increase the transaction volume of the token.
$\mathsf{TANF}$ that is only evaluated from the behaviors of token holders
does not consider account-creation relationships like $\mathsf{ACF}$. Thus, we
should consider both $\mathsf{ACF}$ and $\mathsf{TANF}$ together for each
token. One naive method is dividing $\mathsf{TANF}$ by
$|\mathbb{P}|$($|\mathbb{P}|$=$|\\{\text{parent}_{j}|j=1,2,...,m\\}|$), i.e.,
${\mathsf{TANF}}/{|\mathbb{P}|}$. The smaller $|\mathbb{P}|$ leads to the
larger ${\mathsf{TANF}}/{|\mathbb{P}|}$, implying that this token may be
controlled by a few parent accounts. However, this naive method is not optimal
due to the following reason. In EOSIO, there are several wallet DApps that
help common users create a large number of accounts. When a token is really
popular, many (but not all) accounts whose parent is a wallet DApp will follow
to participate ($|\mathbb{P}|$ may be small). This may mistakenly cause a
large value of ${\mathsf{TANF}}/{|\mathbb{P}|}$, consequently leading to some
false positives.

To address this issue, we model the behaviors of each parent (using
$M_{\text{parent}_{j}}$) instead of simply counting the number. We finally
define the $\mathsf{ATTNF}$ for a token as follows:

$\mathsf{ATTNF}=\frac{\mathsf{TANF}}{\sum_{j=1}^{m}M_{\text{parent}_{j}}},$
(4)

where
$M_{\text{parent}_{j}}=\frac{|\\{\text{child}_{i}|i=1,2,...,N\\}|}{|\\{\text{holder}_{i}|i=1,2,...,n\\}|}$
for each parent account. The set $\\{\text{child}_{i}|i=1,2,...,N\\}$
(abbreviated as $\mathbb{C}$) is the total accounts created by
$\text{parent}_{j}$ and $\\{\text{holder}_{i}|i=1,2,...,n\\}$ denotes the
accounts who are created by $\text{parent}_{j}$ and hold the token. Thus, we
have the set $\mathbb{C}\subseteq\mathbb{H}$ and $n\leq N$. For a token, we
calculate all its $M_{\text{parent}_{j}}$ by dividing $|\mathbb{C}|$ by
$|\mathbb{H}|$ and add them up to get $\sum_{j=1}^{m}M_{\text{parent}_{j}}$.
To create a fake token, the manipulator generally exploits almost all of its
children accounts to initiate lots of transfer actions in a short time. So its
$M_{\text{parent}_{j}}$ is nearly equal to 1. On the contrary, the behavior of
children accounts of a wallet DApp is more scattered and only partial children
accounts interact with the token. Thus, its $M_{\text{parent}_{j}}$ is greater
than 1. The sum $\sum_{j=1}^{m}M_{\text{parent}_{j}}$ is still large when many
children accounts of a wallet DApp (whose $M_{\text{parent}_{j}}$ is
relatively large) participate in a real popular token, leading to a relatively
small $\mathsf{ATTNF}$ and alleviating the problem of false positives.
Meanwhile, if a token is “fake”, almost each $M_{\text{parent}_{j}}$ is nearly
equal to 1 and $\sum_{j=1}^{m}M_{\text{parent}_{j}}$ is relatively small,
leading to a large $\mathsf{ATTNF}$. To this end, $\mathsf{ATTNF}$ is an
important indicator to measure whether a token is “fake”. The larger the
$\mathsf{ATTNF}$ is, the more likely the token is “fake”.

Max Token Transfer Quantity Factor. In addition to the number of transactions
and the number of holders, the total amount of a token being transferred has
also attracted public attention. Thus, we also consider the transfer quantity
(i.e., the amount of transfer actions in EOSIO). To measure it, we first
divide holders of a token into multiple account groups, each of which has the
same parent. We denote such an account group by
$\\{\text{holder}_{i}|i=x,x+1,...,y\\}$. We then define the Token Transfer
Quantity Factor ($\mathsf{TTQF}$) as follows:

$\small\mathsf{TTQF}=\sum^{y}_{x}\mathsf{Qua}_{i}=\sum^{y}_{x}\frac{\mathsf{Qua}(\text{holder}_{i},T_{k})}{\mathsf{Qua}(\text{holder}_{i},\\{T_{k}|k=1,2,...,z\\})}\
\text{and}\ i\in[x,y],$ (5)

where

$\mathsf{Qua}(\text{holder}_{i},T_{k})=\frac{\text{total transfer quantity of
}\text{holder}_{i}\text{ on token }T_{k}}{\text{issue quantity of token
}T_{k}}$ (6)

and

$\mathsf{Qua}(\text{holder}_{i},\\{T_{k}|k=1,2,...,z\\})=\sum_{k=1}^{z}\mathsf{Qua}(\text{holder}_{i},T_{k})$
(7)

In Eq. (6), $\mathsf{Qua}(\text{holder}_{i},T_{k})$ denotes the ratio of the
transferring quantity of an account (in an account group) to the total
issuance quantity of a token. Since the total issuance of different tokens is
not the same, it is necessary to normalize
$\mathsf{Qua}(\text{holder}_{i},T_{k})$. Similar to the definition of
$\mathsf{ANF}$ in Eq. (2), the set $\\{T_{k}|k=1,2,...,z\\}$ in Eq. (5) and
Eq. (7) represents all tokens held by $\text{holder}_{i}$. If
$\mathsf{Qua}_{i}=\frac{\mathsf{Qua}(\text{holder}_{i},T_{k})}{\mathsf{Qua}(\text{holder}_{i},\\{T_{k}|k=1,2,...,z\\})}=1$,
it means that $\text{holder}_{i}$ only holds one token and transfers this
token. We finally add up all $\mathsf{Qua}_{i}$ of each $\text{holder}_{i}$ to
get the $\mathsf{TTQF}$ for an account group. If $\mathsf{TTQF}=|x-y|+1$ for a
token, it means that this account group only holds and transfers this token.
Thus, it may be a suspicious group of the token controlled by the manipulator.
A large value of $\mathsf{TTQF}$ means that this group that has a large scale
almost only interacts with this token. Regarding a token, there are generally
multiple account groups. We define the $\mathsf{MTTQF}$ for a token as:

$\mathsf{MTTQF}=\max(\mathsf{TTQF}_{1},\mathsf{TTQF}_{2},...,\mathsf{TTQF}_{q}).$
(8)

A token that has a larger $\mathsf{MTTQF}$ also has a higher possibility of
being manipulated. As another important indicator considering both account-
creation relationship and transfer amount, $\mathsf{MTTQF}$ is helpful for
finding fake accounts and the manipulator behind them.

Algorithm 1 Search maximum $\mathsf{ATTNF}$ or $\mathsf{MTTQF}$

1:Actions[<sender,token,quantity,sender_parent>], Window Size $W$, Pieces $P$,
Flag $F$

2:maximum $\mathsf{ATTNF}$ or $\mathsf{MTTQF}$

3:$\mathsf{arr}\leftarrow[],\
\text{piece}_{\text{size}}\leftarrow\frac{W}{P},\
\text{piece}_{\text{count}}\leftarrow\frac{|\texttt{Actions}|}{\text{piece}_{\text{size}}}$

4:for $i=0\to(\text{piece}_{\text{count}}-1)$ do

5: $\text{piece}_{\text{start}}\leftarrow i\times\text{piece}_{\text{size}},\
\text{piece}_{\text{end}}\leftarrow(i+1)\times\text{piece}_{\text{size}}$

6:
$\text{res}\leftarrow\mathsf{ATTNF}\\_OR\\_\mathsf{MTTQF}(\texttt{Actions}[\text{piece}_{\text{start}}:\text{piece}_{\text{end}}],\
F)$

7: push res into $\mathsf{arr}$

8:end for

9:$\text{sum}_{\max}\leftarrow 0$

10:for $i=0\to(P-1)$ do

11: $\text{sum}_{\max}\leftarrow\text{sum}_{\max}+\mathsf{arr}[i]$

12:end for

13:$\text{temp}\leftarrow\text{sum}_{\max},\ \text{index}_{\max}\leftarrow 0$

14:for $i=P\to(|\mathsf{arr}|-1)$ do

15: $\text{temp}\leftarrow\text{temp}+\mathsf{arr}[i]-\mathsf{arr}[i-P]$

16: if $\text{temp}>\text{sum}_{\max}$ then $\triangleright$ calculate the
maximum of continuous $P$ pieces

17: $\text{sum}_{\max}\leftarrow\text{temp},\text{index}_{\max}\leftarrow
i-P+1$

18: end if

19:end for

20:$\text{window}_{\text{start}}\leftarrow\text{index}_{\max}\times\text{piece}_{\text{size}},\
\text{window}_{\text{end}}\leftarrow\text{window}_{\text{start}}+W$
$\triangleright$ $\text{index}_{\max}$ to calculate window range

21:return
$\mathsf{ATTNF}\\_OR\\_\mathsf{MTTQF}(\texttt{Actions}[\text{window}_{\text{start}}:\text{window}_{\text{end}}],\
F)$

Search For Maximum $\mathsf{ATTNF}$ And $\mathsf{MTTQF}$. For most token
manipulators, they always deluge their tokens with fake users and fake
transactions. There is often a surge of transactions within a short time. Once
enough popularity (or investments) has been received, the volume of
transactions quickly slumps. It is challenging to capture this phenomenon if
we only calculate $\mathsf{ATTNF}$ and $\mathsf{MTTQF}$ using all historical
records, thereby missing many “fake” tokens. Addressing this issue requires
selecting an appropriate window to include the maximum value of
$\mathsf{ATTNF}$ or $\mathsf{MTTQF}$. To this end, we propose Algorithm 1,
where the input includes Actions, Window Size $W$, Pieces $P$, and Flag $F$.
Actions contain all the transfer actions of a token and also the parent
information of _senders_. $W$ is the number of actions in a window and $F$
indicates whether looking for $\mathsf{ATTNF}$ or $\mathsf{MTTQF}$. We first
divide each window into $P$ pieces, each of which is a small window with size
$\text{piece}_{\text{size}}$. Actions are divided into
$\text{piece}_{\text{count}}$ pieces. We then calculate $\mathsf{ATTNF}$ or
$\mathsf{MTTQF}$ of each small window through sliding one piece and save them
into array $\mathsf{arr}$ (lines 2 to 6). We next adopt the greedy strategy to
obtain the maximum sum of the continuous $P$ pieces as well as the
corresponding index $\text{index}_{\max}$ (lines 11 to 17). Thus, we regard
$\text{index}_{\max}$ as the target to seek for a window and calculate its
$\mathsf{ATTNF}$ or $\mathsf{MTTQF}$ (lines 18 to 19). The sliding mode based
on the small window can find a larger $\mathsf{ATTNF}$ or $\mathsf{MTTQF}$,
improving the accuracy of Algorithm 1. Note that
$\mathsf{ATTNF}\\_OR\\_\mathsf{MTTQF}(\texttt{\small Actions}[x:y],F)$ is
given in both Eq. (4) and Eq. (8).

###  6.3 Evaluation Results

We implement Algorithm 1 with Python. In our experiment, we set $W=100,000$
and $P=10$. After calculating the maximum $\mathsf{ATTNF}$ and
$\mathsf{MTTQF}$ for each token, we finally visualize the distribution of
these two factors, as shown in Fig. 11, where we adopt the logarithmic form of
$\mathsf{MTTQF}$ because of its large variance.

Figure 11: Visualization of normal and suspicious tokens

We mark suspicious tokens in red as their ${\mathsf{\small ATTNF}}$ or
${\mathsf{\small MTTQF}}$ is at a high level ($\mathsf{\small ATTNF}>50\ or\
\mathsf{\small MTTQF}>10,000$). In particular, we select the top-3 tokens
(with large $\mathsf{ATTNF}\times\mathsf{MTTQF}$ products): HBGO, BABY, and
HORUS. We then focus on these three tokens and investigate the manipulation
behaviors of masterminds as well as fake transactions. To achieve this goal,
we select a normal token DICE and compare it with these three tokens. We
randomly sample the transfer actions of these four tokens and analyze the
quantity distribution of each action. As shown in Fig. 12, the distribution of
DICE presents an irregular fluctuation while the top-3 tokens periodically
have high volumes of transfer actions with a relatively-fixed quantity.
Meanwhile, these transfer actions have been submitted in a short time.
Further, it can be observed from the green box in Fig. 12 that HORUS has a
large number of transfer actions with 20.00 HORUS. We next explore evidences
on the existence of fake users or fake transactions of these three tokens.

Figure 12: Visualization of normal and suspicious tokens

hashbabycoin@HBGO: HBGO token that has served as a famous pornographic DApp
was created by pornhashbaby through the contract hashbabycoin. The work [20]
has reported that pornhashbaby is the controller who has created eight groups
of bot-like accounts. Each group of them has hundreds to thousands of
accounts. It is quite possible that HBGO has been controlled by pornhashbaby.
When scanning the transfer actions, we find that pornhashbaby usually sends
1.0000 HBGO to the accounts when being registered as users. Most of the names
of these accounts have a common prefix like “k”, “z”, “gi”, and “gg”.
Meanwhile, these names are sorted according to alphabet letters (a-z) or
decimal digits (1-9). In addition, the transfer amount of most actions is
fixed in a period (e.g., 11, 47). Locating the parent of the accounts, we find
that a large number of accounts involved HBGO were created by moneyloveyou,
eosbank54321, and greedysogood. These accounts may be accomplices who assist
pornhashbaby to manipulate the token HBGO. More interestingly, all of the
three accounts have been created by Meetone, another well-known DApp.

hashbabycoin@BABY: BABY The same as the HBGO, BABY is another token created
through the token contract hashbabycoin by pornhashbaby. We observe some
similar phenomena on BABY. For example, there are a large number of transfer
actions done by pornhashbaby, which sends 11.0000 BABY to other accounts.
Among them, 41,956 accounts that are prefixed with “bnr” have all been created
by walletbancor. These accounts periodically interact with BABY. It is shown
in the top two sub-figures of Fig. 12 that both HBGO and BABY have a similar
quantity distribution with a periodical trend. Surprisingly, there are
7,173,443 transfer actions involved in the accounts with the prefix “bnr*”,
accounting for 43.25% of the total transaction volume of BABY.

horustokenio@HORUS: HORUS The contract horustokenio (444https://horuspay.io/)
represents an entity called HorusPay mainly used for companies to exchange
private encrypted data. HORUS is one of the tokens created by horustokenio.
After analyzing its action records, we find some abnormal transfer actions.
For example, nearly 9,000 actions involve the accounts named “g*ge” or ”h*ge”
and chainceoneos from July 17, 2018 to Aug. 13, 2018. Meanwhile, chainceoneos
transfers HORUS to chainceout11 several times, each transfer action is
associated with a large amount of HORUS tokens (from 300,000.0000 to
15,845,927.6564). More interestingly, we observe that chainceout11 frequently
interacts with the accounts named “g*ge” or “h*ge” and transfers HORUS to
them. It seems that these accounts have formed a closed loop between
chainceoneos and chainceout11. It is reasonable to suspect that it is a
manipulation of HORUS, attempting to make HORUS be “popular”.

##  7 Related Work

###  7.1 EOSIO Analysis

There are a number of studies on blockchain data analytics on Ethereum and
Bitcoin [44, 45, 46, 47, 48, 49, 50, 51, 52]. Most of them focus on user
behaviors, cryptocurrency flows, and scams of blockchains. Despite the
popularity of EOSIO, there are a few systematic studies on the EOSIO
ecosystem. XBlock-EOS[53] provides an efficient method of data extraction and
exploration on the EOSIO blockchain data. Meanwhile, some recent studies
characterize different types of activities in EOSIO (such as money transfer
and contract invocation) and attempt to identify some bots and fraudulent
activities [20, 54]. Moreover, other studies focus on detecting vulnerable
EOSIO contracts [18, 55, 19]. Further, studies [56, 42] find design defects of
the EOSIO framework, which can be exploited by attackers. However, most of the
existing studies either focus on the visualization of EOSIO’s various
activities or identify security vulnerabilities of EOSIO. There is no work to
explore EOSIO from the cryptocurrency ecosystem perspective. It is critical
for EOSIO cryptocurrency stakeholders to fully understand the EOSIO token
ecosystem. This paper aims to bridge this gap by conducting a comprehensive
analysis on the EOSIO token ecosystem.

###  7.2 Token Analysis

In recent years, the prosperity of ICOs has brought immeasurable values to
blockchains, such as Ethereum and EOSIO. As the crucial component in value-
transferring process of blockchains, the benign development of the token
ecosystem has become an inevitable trend. Recent efforts have been conducted
to analyze the token ecosystem of Ethereum across various dimensions. For
example, [26, 22] analyze Ethereum-based ERC20 token networks from a graph
perspective. Meanwhile, studies [25, 23, 57] attempt to detect inconsistent
and abnormal behaviors in the ERC20 token ecosystem. Moreover, Fenu et al.
[21] investigate the relationship between ICO and Ethereum contracts while
[58, 59] summarizes the characteristics of successful tokens. However, none of
these studies have explored the token ecosystem in EOSIO. The comparison study
of the EOSIO token ecosystem and other blockchains (like Ethereum) can help to
characterize different blockchains in terms of ICOs. Our paper is the first
comprehensive work to study the EOSIO token ecosystem.

###  7.3 Fake Detection

The prosperity of blockchain systems and smart contracts also brings
fraudulent activities. Fraudsters often make scams to defraud investors’
assets. For example, some studies [60, 61] show that Ponzi schemes with forged
high-yield illusion were found in Ethereum to attract huge investments from
victims. Similarly, many ICO parties also counterfeit fake users and fake
transactions to make unreal prosperity of their ICO projects or DApps. Several
recent studies have attempted to detect fake users and illegal activities.
Farrugia et al. [62] identify fake and illicit accounts over the Ethereum
blockchain. Meanwhile, Huang et al. [20] find some bot-like and malicious
accounts in EOSIO while their study does not consider tokens of EOSIO. No
previous work has identified fake tokens and fake users or transactions
related to tokens. We propose an algorithm to detect fake tokens and recognize
manipulation behaviors, thereby increasing investors’ vigilance against fake
tokens and avoiding harmful investments.

##  8 Conclusion and Future Work

To our best knowledge, we are the first to conduct a holistic measurement
study on the EOSIO token ecosystem. After gathering a comprehensive dataset,
we construct multiple graphs to characterize the tokens, token holders, and
token creators, accompanied by a comparison study with Ethereum. We then
analyze token transfer flows; this analysis also helps us to identify some
abnormal trading patterns in EOSIO. Moreover, we propose an algorithm to
detect tokens with fake users and fake transactions. Our study may help
investors to be aware of abnormal behaviors of tokens to avoid harmful
investments. This study offers many insightful findings, which help people
have an in-depth understanding of the EOSIO token ecosystem and also raise
many interesting open questions in this area: 1) Why have some inactive users
created so many tokens with attempts to attack EOSIO? 2) What has occurred in
the abnormal trading patterns? 3) What roles do the accounts play in each
abnormal pattern? 4) Are there other relationships between the manipulators
and fake accounts?

## References

  * [1] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, Tech. rep., Manubot (2019).
  * [2] G. Wood, et al., Ethereum: A secure decentralised generalised transaction ledger, Ethereum project yellow paper 151 (2014) (2014) 1–32.
  * [3] M. Crosby, P. Pattanayak, S. Verma, V. Kalyanaraman, et al., Blockchain technology: Beyond bitcoin, Applied Innovation 2 (6-10) (2016) 71.
  * [4] Z. Zheng, S. Xie, H. Dai, X. Chen, H. Wang, An overview of blockchain technology: Architecture, consensus, and future trends, in: 2017 IEEE international congress on big data (BigData congress), IEEE, 2017, pp. 557–564.
  * [5] Z. Zheng, S. Xie, H.-N. Dai, W. Chen, X. Chen, J. Weng, M. Imran, An overview on smart contracts: Challenges, advances and platforms, Future Generation Computer Systems 105 (2020) 475–491.  doi:https://doi.org/10.1016/j.future.2019.12.019.
URL https://www.sciencedirect.com/science/article/pii/S0167739X19316280

  * [6] W. Viriyasitavat, L. Da Xu, Z. Bi, A. Sapsomboon, Blockchain-based business process management (bpm) framework for service composition in industry 4.0, Journal of Intelligent Manufacturing (2018) 1–12.
  * [7] E. Ganne, Can Blockchain revolutionize international trade?, World Trade Organization Geneva, 2018.
  * [8] C. G. Schmidt, S. M. Wagner, Blockchain and supply chain relations: A transaction cost theory perspective, Journal of Purchasing and Supply Management 25 (4) (2019) 100552.
  * [9] L. Bach, B. Mihaljevic, M. Zagar, Comparative analysis of blockchain consensus algorithms, in: 2018 41st International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), IEEE, 2018, pp. 1545–1550.
  * [10] C. Lepore, M. Ceria, A. Visconti, U. P. Rao, K. A. Shah, L. Zanolini, A survey on blockchain consensus with a performance comparison of pow, pos and pure pos, Mathematics 8 (10) (2020) 1782.
  * [11] B. Cao, Z. Zhang, D. Feng, S. Zhang, L. Zhang, M. Peng, Y. Li, Performance analysis and comparison of pow, pos and dag based blockchains, Digital Communications and Networks.
  * [12] A. Meneghetti, M. Sala, D. Taufer, A survey on pow-based consensus, Annals of Emerging Technologies in Computing (AETiC), Print ISSN (2020) 2516–0281.
  * [13] D. Larimer, Delegated proof-of-stake (dpos), Bitshare whitepaper.
  * [14] Block.one, EOSIO Consensus Protocol v2.0, https://developers.eos.io/welcome/v2.0/protocol/consensus_protocol.
  * [15] D. Larimer, EOSIO Dawn 3.0 Now Available, https://medium.com/eosio/eosio-dawn-3-0-now-available-49a3b99242d7.
  * [16] Crowdfundinsider, EOS Raised $4 Billion in Largest ICO Ever, Now they are Launching their Platform, https://www.crowdfundinsider.com/2018/06/134320-eos-raised-4-billion-in-largest-ico-ever-now-they-are-launching-their-platform/.
  * [17] Cryptonomist, EOS: porn blowing up transaction volumes?, https://en.cryptonomist.ch/2019/09/03/eos-porn-transaction-volumes/.
  * [18] Y. Huang, B. Jiang, W. K. Chan, Eosfuzzer: Fuzzing eosio smart contracts for vulnerability detection, in: 12th Asia-Pacific Symposium on Internetware, 2020, p. 99–109.  doi:10.1145/3457913.3457920.
URL https://doi.org/10.1145/3457913.3457920

  * [19] N. He, R. Zhang, H. Wang, L. Wu, X. Luo, Y. Guo, T. Yu, X. Jiang, EOSAFE: Security analysis of EOSIO smart contracts, in: 30th USENIX Security Symposium (USENIX) Security 21), 2021.
  * [20] Y. Huang, H. Wang, L. Wu, G. Tyson, X. Luo, R. Zhang, X. Liu, G. Huang, X. Jiang, Understanding (mis)behavior on the EOSIO blockchain, Proceedings of the ACM on Measurement and Analysis of Computing Systems 4 (2) (2020) 1–28.
  * [21] G. Fenu, L. Marchesi, M. Marchesi, R. Tonelli, The ico phenomenon and its relationships with ethereum smart contract environment, in: 2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE), IEEE, 2018, pp. 26–32.
  * [22] W. Chen, T. Zhang, Z. Chen, Z. Zheng, Y. Lu, Traveling the token world: A graph analysis of Ethereum ERC20 token ecosystem, in: Proceedings of The Web Conference 2020, 2020, pp. 1411–1421.
  * [23] T. Chen, Y. Zhang, Z. Li, X. Luo, T. Wang, R. Cao, X. Xiao, X. Zhang, Tokenscope: Automatically detecting inconsistent behaviors of cryptocurrency tokens in ethereum, in: Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 2019, pp. 1503–1520.
  * [24] S. Somin, G. Gordon, Y. Altshuler, Network analysis of ERC20 tokens trading on ethereum blockchain, in: International Conference on Complex Systems, Springer, 2018, pp. 439–450.
  * [25] M. Fröwis, A. Fuchs, R. Böhme, Detecting token systems on ethereum, in: International conference on financial cryptography and data security, Springer, 2019, pp. 93–112.
  * [26] F. Victor, B. K. Lüders, Measuring Ethereum-based ERC20 token networks, in: International Conference on Financial Cryptography and Data Security, Springer, 2019, pp. 113–129.
  * [27] E. B. Hamida, K. L. Brousmiche, H. Levard, E. Thea, Blockchain for enterprise: overview, opportunities and challenges, 2017.
  * [28] M. Risius, K. Spohrer, A blockchain research framework, Business & Information Systems Engineering 59 (6) (2017) 385–409.
  * [29] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, H. Wang, Blockchain challenges and opportunities: A survey, International Journal of Web and Grid Services 14 (4) (2018) 352–375.
  * [30] D. Mingxiao, M. Xiaofeng, Z. Zhe, W. Xiangwei, C. Qijun, A review on consensus algorithm of blockchain, in: 2017 IEEE International Conference on Systems, Man, and Cybernetics (SMC), IEEE, 2017, pp. 2567–2572.
  * [31] M. H. Nasir, J. Arshad, M. M. Khan, M. Fatima, K. Salah, R. Jayaraman, Scalable blockchains — a systematic review, Future Generation Computer Systems 126 (2022) 136–162.  doi:https://doi.org/10.1016/j.future.2021.07.035.
URL https://www.sciencedirect.com/science/article/pii/S0167739X21002971

  * [32] B. Xu, D. Luthra, Z. Cole, N. Blakely, EOS: An architectural, performance, and economic analysis, Retrieved June 11 (2018) 2019.
  * [33] D. Larimer, EOS VM - A Low-Latency, High Performance and Extensible WebAssembly Engine, https://github.com/EOSIO/eos-vm.
  * [34] L. Burkholder, The halting problem, ACM SIGACT News 18 (3) (1987) 48–60.
  * [35] L. Zhao, S. Sen Gupta, A. Khan, R. Luo, Temporal analysis of the entire ethereum blockchain network, in: Proceedings of the Web Conference 2021, WWW ’21, Association for Computing Machinery, New York, NY, USA, 2021, p. 2258–2269.  doi:10.1145/3442381.3449916.
URL https://doi.org/10.1145/3442381.3449916

  * [36] R. K. Merton, The matthew effect in science: The reward and communication systems of science are considered, Science 159 (3810) (1968) 56–63.
  * [37] Blocking.net, EOS is dead: Does EIDOS really kill EOS?, https://blocking.net/22349/eos-is-dead-does-eidos-really-kill-eos/ (2019).
  * [38] DAppTotal, World leading DApp data service platform, https://dapptotal.com/.
  * [39] DappRadar, Metal Packaging Token, https://dappradar.com/eos/other/metpacktoken-mpt (2019).
  * [40] AirDropsDAC, ZOS Token, https://www.airdropsdac.com/zos (2019).
  * [41] F. Victor, A. M. Weintraud, Detecting and quantifying wash trading on decentralized cryptocurrency exchanges, in: WWW ’21: The Web Conference 2021, 2021, pp. 23–32.  doi:10.1145/3442381.3449824.
URL https://doi.org/10.1145/3442381.3449824

  * [42] S. Lee, D. Kim, D. Kim, S. Son, Y. Kim, Who spent my EOS on the (in) security of resource management of eos.io, in: 13th USENIX Workshop on Offensive Technologies (WOOT 19), 2019.
  * [43] M. Pasquinelli, Google’s pagerank algorithm: A diagram of cognitive capitalism and the rentier of the common intellect, Deep search: The politics of search beyond Google (2009) 152–162.
  * [44] D. Ron, A. Shamir, Quantitative analysis of the full bitcoin transaction graph, in: International Conference on Financial Cryptography and Data Security, Springer, 2013, pp. 6–24.
  * [45] F. Reid, M. Harrigan, An analysis of anonymity in the bitcoin system, in: Security and privacy in social networks, Springer, 2013, pp. 197–223.
  * [46] D. Kondor, M. Pósfai, I. Csabai, G. Vattay, Do the rich get richer? an empirical analysis of the bitcoin transaction network, PloS one 9 (2) (2014) e86197.
  * [47] T. Chen, Y. Zhu, Z. Li, J. Chen, X. Li, X. Luo, X. Lin, X. Zhange, Understanding ethereum via graph analysis, in: IEEE INFOCOM 2018-IEEE conference on computer communications, IEEE, 2018, pp. 1484–1492.
  * [48] J. Wu, Q. Yuan, D. Lin, W. You, W. Chen, C. Chen, Z. Zheng, Who are the phishers? phishing scam detection on ethereum via network embedding, IEEE Transactions on Systems, Man, and Cybernetics: Systems.
  * [49] 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.
  * [50] T. Hu, X. Liu, T. Chen, X. Zhang, X. Huang, W. Niu, J. Lu, K. Zhou, Y. Liu, Transaction-based classification and detection approach for ethereum smart contract, Information Processing & Management 58 (2) (2021) 102462.
  * [51] L. Liu, W.-T. Tsai, M. Z. A. Bhuiyan, H. Peng, M. Liu, Blockchain-enabled fraud discovery through abnormal smart contract detection on ethereum, Future Generation Computer Systems 128 (2022) 158–166.  doi:https://doi.org/10.1016/j.future.2021.08.023.
URL https://www.sciencedirect.com/science/article/pii/S0167739X21003319

  * [52] B. Tao, H.-N. Dai, J. Wu, I. W.-H. Ho, Z. Zheng, C. F. Cheang, Complex network analysis of the bitcoin transaction network, IEEE Transactions on Circuits and Systems II: Express Briefs (2021) 1–1doi:10.1109/TCSII.2021.3127952.
  * [53] W. Zheng, Z. Zheng, H.-N. Dai, X. Chen, P. Zheng, Xblock-eos: Extracting and exploring blockchain data from eosio, Information Processing & Management 58 (3) (2021) 102477.
  * [54] Y. Zhao, J. Liu, Q. Han, W. Zheng, J. Wu, Exploring EOSIO via graph characterization, in: International Conference on Blockchain and Trustworthy Systems, Springer, 2020, pp. 475–488.
  * [55] L. Quan, L. Wu, H. Wang, Evulhunter: Detecting fake transfer vulnerabilities for eosio’s smart contracts at webassembly-level, arXiv preprint arXiv:1906.10362.
  * [56] D. Lee, D. H. Lee, Push and pull: Manipulating a production schedule and maximizing rewards on the eosio blockchain, in: Proceedings of the Third ACM Workshop on Blockchains, Cryptocurrencies and Contracts, 2019, pp. 11–21.
  * [57] M. Di Angelo, G. Salzer, Identification of token contracts on ethereum: standard compliance and beyond, International Journal of Data Science and Analytics (2021) 1–20.
  * [58] J. P. Conley, et al., Blockchain and the economics of crypto-tokens and initial coin offerings, Vanderbilt University Department of economics working papers (17-00008).
  * [59] S. T. Howell, M. Niessner, D. Yermack, Initial coin offerings: Financing growth with cryptocurrency token sales, The Review of Financial Studies 33 (9) (2020) 3925–3974.
  * [60] W. Chen, Z. Zheng, J. Cui, E. Ngai, P. Zheng, Y. Zhou, Detecting ponzi schemes on ethereum: Towards healthier blockchain technology, in: Proceedings of the 2018 World Wide Web Conference, 2018, pp. 1409–1418.
  * [61] M. Bartoletti, S. Carta, T. Cimoli, R. Saia, Dissecting ponzi schemes on ethereum: Identification, analysis, and impact, Future Generation Computer Systems 102 (2020) 259–277.  doi:https://doi.org/10.1016/j.future.2019.08.014.
URL https://www.sciencedirect.com/science/article/pii/S0167739X18301407

  * [62] S. Farrugia, J. Ellul, G. Azzopardi, Detection of illicit accounts over the ethereum blockchain, Expert Systems with Applications 150 (2020) 113318.