DEPOSafe: Demystifying the Fake Deposit

Vulnerability in Ethereum Smart Contracts

Ru Ji1∗ , Ningyu He2∗ , Lei Wu3 , Haoyu Wang1 , Guangdong Bai4 , Yao Guo2
1
Beijing University of Posts and Telecommunications, Beijing, China
2
Peking University, Beijing, China 3 Zhejiang University, Hangzhou, China
4
The University of Queensland, Australia

Abstract—Cryptocurrency has seen an explosive growth in one of the most representative second generation blockchain
recent years, thanks to the evolvement of blockchain technol- platforms. By the end of April 2020, there are over 176,000
arXiv:2006.06419v1 [cs.CR] 11 Jun 2020

ogy and its economic ecosystem. Besides Bitcoin, thousands of ERC-20 tokens on the Ethereum platform.
cryptocurrencies have been distributed on blockchains, while
hundreds of cryptocurrency exchanges are emerging to facilitate With the rapid development of Ethereum, cryptocurrency
the trading of digital assets. At the same time, it also attracts exchange (exchange for short), as the third-party supporting
the attentions of attackers. Fake deposit, as one of the most service, has emerged to support fiat-to-crypto and crypto-to-
representative attacks (vulnerabilities) related to exchanges and crypto trades. According to their trading models, exchanges
tokens, has been frequently observed in the blockchain ecosystem,
can be categorized into two types, centralized exchange (CEX)
causing large financial losses. However, besides a few security
reports, our community lacks of the understanding of this and decentralized exchange (DEX). CEX, as the name sug-
vulnerability, for example its scale and the impacts. In this gests, requires a central entity as the intermediary to complete
paper, we take the first step to demystify the fake deposit token transfer between its users. Therefore, the trustworthiness
vulnerability. Based on the essential patterns we have summa- of the middle man plays an important role in this transaction
rized, we implement DEPOSafe, an automated tool to detect
model. Contrary to CEX, DEX removes the entity in the
and verify (exploit) the fake deposit vulnerability in ERC-20
smart contracts. DEPOSafe incorporates several key techniques middle to store data, and performs token exchange with a
including symbolic execution based static analysis and behavior matchmaking tradeoff model [3]. Theoretically, a DEX is
modeling based dynamic verification. By applying DEPOSafe to composed of smart contract(s) without the need of human in-
176,000 ERC-20 smart contracts, we have identified over 7,000 tervention. Therefore, DEX has been developed to allow peer-
vulnerable contracts that may suffer from two types of attacks.
to-peer trading of cryptocurrencies without an intermediary
Our findings demonstrate the urgency to identify and prevent
the fake deposit vulnerability. but solely depends on smart contracts. Such a trading model
can not only guarantee the privacy of users1 , but also ensure
I. I NTRODUCTION the behaviors of transaction strictly follow the logic encoded
As the first generation blockchain platform, Bitcoin demon- in smart contracts.
strated that it is possible to use the Internet to construct a Unfortunately, a number of security issues have been found
decentralized value-transfer system that can be shared across in tokens and exchanges, which attracted attacker attention
the world and virtually free to use. Due to performance and as well. First, a number of attacks targeting exchanges have
scalability issues, however, it is difficult (if not impossible) been observed in the wild [5]–[7], which caused great financial
for Bitcoin to support complex applications. To this end, losses. Besides, ERC-20 related bugs have been underesti-
Ethereum [1] was proposed to allow users to create DApps mated by developers [8]. For example, a token may be acciden-
(Decentralized Applications) by developing smart contracts, tally created as non-standard without fully understanding the
which have been regarded as the most creative blockchain ERC-20 standard. As a result, the combination of the flawed
technique after Bitcoin. verification of exchanges and non-standard implementation
Up to April 2020, there exist more than 25 million smart of tokens might cause severe damages.
contracts in Ethereum. However, only 0.36% of them have Fake deposit is one of the most representative vulnerabilities
released their source code according to our dataset, which related to both exchanges and tokens. It is publicly well known
reflects the dilemma between security and privacy. Besides, as it has appeared in recent security reports and news [9]–[12].
Ethereum uses Ether as its official cryptocurrency, which can The attacks exploiting this vulnerability have remained active
be held and transferred between accounts in the Ethereum for a long time, observed in Ethereum and other platforms
network. Besides Ether, Ethereum also allows users to create (e.g., USDT and EOSIO). Unlike other vulnerabilities, the fake
and issue cryptocurrencies (tokens). To standardize the token deposit vulnerability is conditioned by two requirements, i.e.,
behaviors, Ethereum proposes a technical standard named the non-standard implementation of a token and the flawed
ERC-20 [2] to ensure the interoperability between tokens. As verification of an exchange. To be specific, deposit means a
a result, Ethereum has attracted lots of attention and become
1 Although it is consistent with the anonymity of blockchain, abandoning
*The first two authors contributed equally to this work. the Know Your Customer (KYC) [4] policy is still a concern.
user transfers a certain type of token into the exchange. A II. BACKGROUND
malicious user, however, could take advantage of the flaws In this section, we will briefly introduce the necessary
in smart contracts of that token and deficient exchange ver- background knowledge of Ethereum [1] to facilitate the un-
ification mechanism to achieve a fake deposit, in which the derstanding of our further analyses.
amount transferred is typically too large to be affordable for
the attacker. Consequently, a malicious user can deceive the A. Ethereum Account and Transaction
exchange and gain huge profit with nearly no cost. To date, In Ethereum, account is the basic unit to identify an entity
the details and impact of this vulnerability have not been well in the network. An account is identified by a fixed-length
studied. hash-like address. Additionally, the account in Ethereum can
This Paper. We take the first step to demystify the fake be divided into two types: External Owned Account (EOA)
deposit vulnerability in Ethereum and measure the potential se- and Contract Account. An EOA is an ordinary account who
curity impacts by analyzing a large number of Ethereum ERC- can transfer tokens, invoke deployed smart contracts and
20 smart contracts. We have analyzed over 176,000 ERC-20 store received tokens. Moreover, an EOA can deploy a smart
contracts deployed between July 2015 to March 2020. Specif- contract into a Contract Account2 . Specifically, an account can
ically, we first characterized the vulnerability and identified deploy a smart contract by sending a transaction that contain
the essential patterns. We then implemented DEPOSafe, an the bytecode of smart contract to address 0x0. After that, all
automated tool to identify and verify (exploit) the fake deposit accounts in the Ethereum network are able to invoke the smart
vulnerability. DEPOSafe consists of two major components. contract residing in the Contract Account.
The first component is a static detector implemented based Accounts or smart contracts can interact with each other by
on Mythril [13], an open-source symbolic execution engine sending a transaction, which consists of a bunch of data that
towards Ethereum to efficiently perform the detection. After will be parsed and executed by the target smart contract. To
that, to eliminate the false positives introduced by the static be specific, the data consists of the signature of designated
analysis, we built a dynamic validator to emulate the behaviors function and its required arguments. Notice that, to minimize
between token and exchange when users deposit tokens into the size of the transaction transferred, Ethereum matches func-
exchange, in order to confirm the existence of the fake deposit tions by its first four bytes of the signature that is calculated
vulnerability. To facilitate our analysis, we categorized these by the Keccak256 hash function [14]. For example, the func-
attacks into two types according to the exchanges, i.e., attacks tion transfer(address,uint256) will be identified by
targeting CEX as Type-I and attacks targeting DEX as Type- 0xa9059cbb. Once the target address successfully handles
II, respectively. After applying DEPOSafe to over 176,000 the received transaction, the transaction will be recorded
ERC-20 smart contracts we collected, we have identified 56 online soon and cannot be erased or modified. However, if
and 7,716 smart contracts that could be exploited by Type-I something goes wrong within executing a transaction, all of the
and Type-II attacks, respectively. The technical details of the modifications resulted from this transaction will be reverted.
flawed implementation of token and exchange are presented B. Ethereum Virtual Machine (EVM)
in §III; the attack emulations for both types of attacks are EVM is a simple stack-based architecture, and the function
illustrated in §IV. of the EVM stack is to store the results of intermittent
Contributions In summary, this paper makes the following execution of bytecode instructions (opcodes). All the operands
main research contributions. of opcodes and the calculation result are pushed onto the
stack, a basic data structure in EVM. In a nutshell, EVM can
• We proposed DEPOSafe, the first framework aims to 1)
provide a runtime environment for smart contracts that have
identify if the smart contract is compliant with the ERC-
been compiled to bytecode to be executed, manage execution
20 standard rules and subject to fake deposit vulnera-
of the transaction and transit the blockchain to its new state.
bility; 2) automatically exploit vulnerable ERC-20 smart
Except for stack, data in EVM can also be stored in other
contracts and prove the existence of loopholes.
areas: memory, storage and calldata. To be specific, storage
• By applying DEPOSafe to over 176K ERC-20 smart
is a key-value mapping that persists between function calls
contracts, we have identified more than 7,000 ERC-20
and transactions. As the data in storage are recorded on the
smart contracts with fake deposit vulnerability, which
blockchain, it charges more to create and update entities in
can be exploited by the Type-I or Type-II attacks. Our
storage. Moreover, EVM will assign a slot ID for each variable
investigation shows that the top 10 most influential but
stored in storage to identify it. The slot ID is determined at
vulnerable ERC-20 tokens account for 984 million USD
compilation time and strictly based on the variables order in
capitalization, while the affected DEXes still have mil-
the contract code. In contrast, retrieving and inserting data
lions USD volumes per day.
from memory is much more cheaper. The memory area, how-
• We reported various findings based on the analysis of
ever, will be erased after the current transaction. Besides above
collected data and further propose mitigating mechanisms
areas, calldata is used to store external calls to functions, and
for this vulnerability. Moreover, the vulnerability dataset
it is a read-only byte-addressable space.
will be released to the community to encourage further
study. 2A smart contract can also deploy another smart contract.
 C. Smart Contract and Bytecode
Token3 Token4
A smart contract is a collection of code and data that reside Fiat1 Fiat2
MATCH! MATCH!

in Contract Account. They are typically written in high level Token1 Token2
Token1 Token2
languages, such as Solidity [15]. They are used to implement
(a) CEX (b) DEX
arbitrary rules as well as guarantee to produce the same result
for decentralized parties. Smart contracts exist and execute in Fig. 1. The trading model of CEX and DEX respectively.
bytecode format, which is compiled from source code.
The Ethereum bytecode is made up of 144 opcodes [16].
Additionally, each opcode is encoded as one byte, and rep- E. Exchange and Deposit
resented in hexadecimal format. For example, SSTORE is
1) CEX: CEX is an intermediary between users in trading
encoded as 0x55 in EVM. Opcode takes zero or multiple
process (see Fig. 1(a)). Typically, the centralized entity is man-
arguments to achieve its functionality. As we mentioned in
aged by a trustworthy organization or company. However, once
§I, only 0.36% of contracts have opened up the source code.
the centralized server is down or compromised, it is possible
In order to cover all these contracts, we decide to implement
for data breach or even financial loss for both exchange and
DEPOSafe as a bytecode-level analyzer (see Section IV).
users. Nevertheless, CEX has its advantages: 1) it has ability
Additionally, the bytecode of smart contract is composed
to achieve quick transactions and support multiple users at
of three parts: creation code, runtime code, and swarm code.
once; 2) it supports the exchange between fiat and tokens,
Creation code includes constructor logic and constructor pa-
or even tokens from different platforms; 3) the trading model
rameters of a contract. It is generated when the bytecode
determines its scalability and quick response against attacks.
is compiled and it will be executed only once at the time
Depositing tokens into CEX is simple. The user invokes a
of deployment. Runtime code will eventually be stored on-
transaction with certain amount of tokens to a designated ad-
chain. It details the logic and behavior of each function in
dress. After that, the CEX server will verify if the transaction
contract. However, it does not contain any of the constructor
is successful and update the balance of the user in its database.
parameters. Swarm code is a little bit different. It does not
2) DEX: As depicted in Fig. 1(b), DEX, unlike CEX such
have any practical meaning and can not be executed by EVM.
as Coinbase [17] and Binance [18], has no central entity which
The swarm code is only a string of hash that is calculated by
is managed by a specific company or a person focusing on
metadata of current smart contract to index it in database.
making a profit. The DEXes put the control of funds and
1 f u n c t i o n t r a n s f e r ( address to , uint t o k e n s ) trading back to users. In other words, DEX does not store
public r e t u r n s ( bool success ) { user assets, so neither hacker attacks nor the total collapse
2 b a l a n c e s [ msg . s e n d e r ] = s a f e S u b ( b a l a n c e s [ msg .
sender ] , tokens ) ;
of the DEX can lead to a loss of funds. To compete with the
3 b a l a n c e s [ t o ] = safeAdd ( b a l a n c e s [ t o ] , t o k e n s ) ; traditional CEXes and attract users, these DEXes adopt various
4 e m i t T r a n s f e r ( msg . s e n d e r , t o , t o k e n s ) ; business logic. For example, in EtherDelta [19], maker and
5 return true ; } taker agree on trading off-chain and execute it on-chain, while
6 IDEX [20] provides real-time order book updates, which is
7 f u n c t i o n t r a n s f e r F r o m ( a d d r e s s from , a d d r e s s t o
, uint tokens ) public r e t u r n s ( bool
live on the Ethereum MainNet. Despite these diverse business
success ) { logic, DEXes share similar mechanisms, protocols and data
8 / / u p d a t e b a l a n c e s and a l l o w a n c e s models, i.e., the actual trade is executed through a smart
9 e m i t T r a n s f e r ( from , t o , t o k e n s ) ; contract on blockchain. Therefore, once the transaction is
10 return true ; } confirmed by the miners, it is impossible to withdraw or cancel
Listing 1. Standard transfer and transferFrom in ERC-20 token it due to the irreversibility. Additionally, all the behaviors
through DEX strictly follow the code of its smart contract.
D. ERC-20 Standard 1 function depositToken ( address token , uint
amount ) {
As one of the most popular and well-known techni- 2 i f ( msg . v a l u e >0 | | t o k e n ==0) throw ;
cal standards in Ethereum, ERC-20 specifies six manda- 3 i f ( ! Token ( t o k e n ) . t r a n s f e r F r o m ( msg . s e n d e r ,
tory functions (totalSupply, balanceOf, transfer, t h i s , amount ) ) throw ;
4 t o k e n s [ t o k e n ] [ msg . s e n d e r ] = s a f e A d d ( t o k e n s [
transferFrom, approve, and allowance) for the ben- t o k e n ] [ msg . s e n d e r ] , amount ) ;
efit of Ethereum developers. As shown in listing 1, the 5 D e p o s i t ( t o k e n , msg . s e n d e r , amount , t o k e n s [
transfer uses function safeAdd and safeSub to up- t o k e n ] [ msg . s e n d e r ] ) ;
date the balance table. If the invoker does not have enough 6}
token, they will throw exceptions and terminate the current Listing 2. DepositToken function
transaction. As for transferFrom, except for the update of
balance table, it also checks if the caller has enough allowance To trade tokens through DEX, users have to deposit tokens
to transfer such an amount of tokens. Any of these three into smart contract of DEX in advance. Therefore, the user
verification fails, the transfer will be terminated immediately. has to firstly grant the permission to DEX to make it eligible;
 (a) Static Detector
then the user will call the depositToken function which
Bytecode
Path Tree Detector
is detailed in listing 2. As we can see, the depositToken (Runtime) Stack
Input States • Enumerating Standard APIs
takes the token address token and deposit value amount as Addresses
Memory
• Locating Key Storage

…
Storage • Verifying Required throw
arguments, then calls the transferFrom in address token
to transfer money to DEX’s address. Suspect
Addresses
(b) Dynamic Validator
III. FAKE D EPOSIT V ULNERABILITY
(b.1) Obtain (b.2) Token (b.3) Verify Deposit
As aforementioned, the attack against fake deposit vulner- Creation Code Deployment Behavior
Vulnerable Type-I Type-II
Addresses txn: transfer(to2,v2) • Initialize Token
ability depends on both entities of tokens and exchanges. Output …
• Initialize DEX

Therefore, in this section, we will detail the incorrect imple- txm: transfer(to1,v1) Web3
…
mentation in ERC-20 token’s smart contracts, and also the two tx1: create(bytecode)
ganache DEX CEX

types of deficient verification of exchanges. The combination

of these two conditions leads to the fake deposit vulnerability.
Fig. 2. An overview of DEPOSafe.
A. Non-standard Implementation of Tokens
Though ERC-20 enforces the implementation of these in- token’s smart contract that is traded on its platform to ensure fi-
terfaces (see §II-D), the standard does not specify the im- nancial security. However, imagine a token’s transferFrom
plementation details, an incorrect or improper implementation is encapsulated by safeTransferFrom, where it performs
could lead to vulnerable contracts. To be specific, the official security check and then invokes the real transferFrom. If
guideline recommends developers to throw an exception if the DEX does not audit this smart contract or neglects this
there are insufficient tokens in the caller’s balance to spend, as unsafe implementation, there seems no security check when
shown at line 2-3 in listing 1. The safeAdd and safeSub DEX calls transferFrom at line 3.
would throw an exception if the overflow happens. 2) Flawed Back-end Verification of CEXs: When user de-
1 f u n c t i o n t r a n s f e r ( address to , u i n t 2 5 6 value ) posits tokens into CEXes, the depositing amount is parsed and
r e t u r n s ( bool success ) { determined by CEX’s back-end server. However, a deficient
2 i f ( b a l a n c e O f [ msg . s e n d e r ] >= v a l u e && verification strategy may result in unexpected behaviors. To
balanceOf [ to ] + value > balanceOf [ to ] ) be specific, some CEXes do only verify the status field and
{ _value in the input field of a transaction, which is reported
3 b a l a n c e O f [ msg . s e n d e r ] −= v a l u e ;
4 b a l a n c e O f [ t o ] += v a l u e ; by security analysts [21]. The status indicates whether the
5 T r a n s f e r ( msg . s e n d e r , t o , value ) ; current transaction is terminated with nothing unusual; the
6 return true ; _value is the value of arguments in the transfer function.
7 } e l s e { return f a l s e ; } Therefore, if a transaction is terminated by “return False;”
8} instead of throwing an exception, the status code will still
Listing 3. An example of a vulnerable implementation of transfer. be 1, which means current transaction is terminated normally.
Unfortunately, some CEXes rely on such an insufficient veri-
However, some developers use a conditional statement to fication to determine how many tokens are deposited.
check the caller’s balance instead of the assertion state-
ment (see listing 3). If the balance of the caller (identified
by msg.sender) is insufficient, the transfer will return IV. DEPOS AFE
false at line 7. Unfortunately, no matter which value re-
turned , the current transaction will not be terminated. This gap To evaluate if a smart contract is vulnerable to the fake
between the actual behavior and the developer’s expectation deposit attack, we implemented DEPOSafe. Fig. 2 shows
breaks the guideline and leads to the vulnerability. the overall work process of DEPOSafe. It takes the runtime
bytecode of smart contracts with their corresponding addresses
B. Flawed Verification of Exchanges as input, and generates a security report through a pipeline
Except for the vulnerabilities that reside in the ERC-20 composed of two parts: static detector and dynamic valida-
token smart contract, successfully exploiting the fake deposit tor. Specifically, the static detector is implemented based on
also relies on the implementation flaws in exchanges. There- Mythril [13], in which we screen out the addresses which may
fore, we then introduce two types of deficiencies which lead be vulnerable to the fake deposit loophole. Due to the inherent
to the security threats of exchanges. false positives of static analysis, we further implemented in
1) Flawed Token Verification of DEXs: After a thorough DEPOSafe a dynamic validator to verify the flagged smart
manual inspection towards current (and past) mainstream contracts are indeed vulnerable to fake deposit. The dynamic
DEXes, we found that most of them perform deposit logic validator takes advantage of web3 [22], which is a collection of
by calling the function depositToken, which is detailed in libraries for interacting with a local or remote Ethereum node.
listing 2. As line 3 shows, the DEX invokes the traded token’s We used it to interact with our local private chain provided
transferFrom (or sometimes transfer) to perform de- by ganache-cli [23], which is a customizable blockchain
posit. Notice that the DEX is responsible for auditing the emulator. We detail both components in the following.
function transfer(address _to, uint256 _value)
...
SLOAD x x: msg.sender opcodes of the smart contract, we extract the recorded states
returns (bool success) { ... y: _value
if (balanceOf[msg.sender] >= _value && ISZERO op(SLOAD(x),y) z: _to
...
of function transfer and traverse all of them to identify
balanceOf[_to] + _value > balanceOf[_to]) {
balanceOf[msg.sender] -= _value;
balanceOf[_to] += _value;
the addresses from which the balanceOf is SLOAD (as
Transfer(msg.sender, _to, _value); ... ...
return true;
RETURN SLOAD z
...
the balance table is stored in storage (see §II-B) and has to
} else { return false; } ISZERO op(SLOAD(z),y)
} ... be retrieved by instruction SLOAD in EVM). As we can see
from Fig. 3, the green block indicates where it retrieves the
... ...
Control Flow RETURN SSTORE x, op(SLOAD(x),y) balance of msg.sender, i.e., the caller. We mark the label
SSTORE z, op(SLOAD(z),y)
Source code of Graph of the ...
Flawed transfer transfer RETURN x as storage address. Then, we traverse the storage addresses
to examine whether any of them is treated as target address
Fig. 3. The detection logic of static detector towards a flawed transfer. by SSTORE (like SLOAD, EVM has to update variable in
storage by instruction SSTORE) in transfer. We can see
the yellow block which indicates the balance of msg.sender
A. Static Detector
is updated and stored in storage with label x. Therefore, the
To efficiently detect the fake deposit vulnerability, we balanceOf in transfer is updated, which could lead to
propose a static detector relying on symbolic execution to the actual change of balance data.
perform the detection. The Mythril, which we relied on, 3) Verify Required throw: Similarly, the success of second
implements an EVM-like virtual machine, so it is able to step is the precondition of this step. In this step, we detect if
imitate the behaviors of a given smart contract on bytecode the balanceOf is protected and properly handled. Mythril
level. Therefore, our detector firstly symbolic executes the generates all the feasible paths of the transfer function (if
bytecode to traverse all the feasible paths. Meanwhile, it it exists), so we screen out all the instructions that indicates a
records the virtual machine state (including stack, memory, normal termination of current path, i.e., STOP and RETURN,
storage, etc.) after each instruction. After that, based on the which means these paths are not terminated by assertion. Like
recorded information, the detector is capable of identifying the RETURN colored by green and red in Fig. 3, they all
vulnerabilities. represent the termination of that path. Then, we will traverse
As discussed in §III-A, to accurately detect the incorrect im- these paths backward to search for the instruction ISZERO,
plementation of transfer and transferFrom, we divide which is used at the comparison between values. For example,
the whole static analysis into three steps, including enumerat- from any of the RETURN opcode in Fig. 3, we can find a
ing standard APIs, locating key storage, and verifying required ISZERO backward. As for the two arguments compared by
throw. Specifically, in the first step, we use the signature of ISZERO, if one of them is the target address of SSTORE,
functions to find out if the smart contract implements any it means the balanceOf is protected by if-else before
of the six standard functions; in the second step, we use the updating. Hence, we treat this ISZERO as a protected node,
opcode SLOAD and SSTORE to pinpoint the storage slots of as the red block and purple block in Fig. 3. For all the paths
those key arguments, i.e., balanceOf and allowance; in forking from the protected nodes, if none of them is terminated
the last step, we check the final opcode of relevant paths to by revert instructions, i.e., REVERT and ASSERT_FAIL,
identify whether the exception is thrown as required by the we can ensure that this smart contract does not follow the
ERC-20 standard. The detection procedure against the flawed official guideline. In other words, neither of branches forked
transfer listed in listing 3 is shown in Fig. 3 and details by if-else is terminated by assertion, such that the smart
of these three steps are described in the following. contract may be subject to to fake deposit vulnerability.
1) Enumerate Standard APIs: As the existence of
transfer and transferFrom is the prerequisite of the Though we have proposed a well-designed strategy to identify
fake deposit vulnerability, so firstly we check if the smart the fake deposit vulnerability in ERC-20 smart contracts, we
contract is compliant with the standard ERC-20 token inter- have to face the introduced false positives due to the inherent
face [2]. In other words, the signatures of those six stan- limitations of static analysis methods. Taking Listing 1 as an
dard functions should be declared in the smart contract’s example, the smart contact may implement security check by
bytecode. As shown in Fig. 3, after identifying the exis- safeAdd or safeSub. This may introduce false positives
tence of transfer (including transferFrom but we use to DEPOSafe. In §V-B, we comprehensively analyze all the
transfer as an example here), we will generate the Control false positives reported by DEPOSafe. Moreover, we imple-
Flow Graph (CFG) and symbolic execute each paths. ment a dynamic validator after static detector. This benefits
2) Locate Key Storage: If the transfer is implemented, DEPOSafe in two aspects: 1) eliminating the false positives
we then verify whether it follows the official standard, i.e., introduced by static analysis and increasing the precision; 2)
throw an exception if there is insufficient tokens in the achieving automatic EXP generation towards fake deposit to
caller’s account. Similarly, we also examine the implemen- validate the existence of vulnerability.
tation of balanceOf and allowance in transferFrom
as well. Take function transfer as an example. We have to B. Dynamic Validator
pinpoint the storage slots used by balanceOf firstly. As the The strategy in our dynamic validator is to mimic the
Mythril records the virtual machine state when it executes the deposit behavior between tokens and exchanges. To this end,
 Owner DEX Owner CEX
to: attacker to: attacker
amount: 1 amount: 1
 v depositToken() w  v w
amount: 100 v

v
Vulnerable w
to: exhcange
Vulnerable Attacker amount: 100 Attacker
Token Token
! Create and issue the token ! Create and issue the token
" Transfer to attacker " Transfer to attacker
# Call depositToken() to perform # Transfer to CEX with unaffordable
fake deposit value of tokens
Fig. 4. The deployment and interaction between contracts in favor of web3.
(a) Type I (b) Type II

Fig. 5. The fake deposit attack resulted from (a) the incorrect implementation
we divide the whole validation process into three steps: of ERC-20 token and lack of auditing from DEX; (b) the insufficient
obtaining creation code, preparing deployment environment, verification of back-end server of CEX. (Where the solid line is the “Call
and verifying deposit behaviors. Flow” and the dash line is the “Money Flow”)

1) Obtain Creation Code: As the static detector only passes

the addresses of those token smart contracts that may be be automatically executed by the fallback function [25], which
vulnerable to fake deposit behaviors, we have to firstly obtain will be executed if none of other functions matches to the name
the creation code, which indicates the deployed contract and indicated in the incoming function call. Consequently, some
the corresponding initial value of parameters (see §II-C). To do unexpected behaviors would happen.
this, we firstly implement a crawler to grab all the transactions Accordingly, we design our verifying procedures for Type-
invoked and received from etherscan.io [24] (a well-known I attack as shown in Fig. 5(a). Notice that, we have already
and credible browser for Ethereum) according to the addresses. deployed the smart contracts of ERC-20 and DEX before this
Then, we only keep the oldest one, which is the contract step starts. Firstly, we (the owner) issue the corresponding
deployment transaction (see §II-A), to parse. Finally, we can tokens according to the ERC-20 contract. Then, the owner
obtain the creation code and the initial values from the input transfers only 1 newly issued token to another account, i.e.,
data field. the attacker. Next, the attacker invokes depositToken by
2) Prepare Deployment Environment: After getting the calling the DEX to deposit 100 tokens which is definitely
creation code of tokens, the next step is to deploy them to unaffordable to the attacker. If the smart contract is imple-
perform test. To avoid ethical and financial issues, we conduct mented incorrectly, i.e., not following the ERC-20 guideline
the testing on our private chain. To be specific, we set up a like examples depicted in the last paragraph, the deposit
private chain and interact with the deployed contract in favor of request will be handled. Finally, we examine the balance table
ganache and web3 respectively. Moreover, as shown in Fig. 4, in the DEX to verify the final result of such a deposit request.
the sendTransactions provided by web3 enables the If the attacker has balance which is equal to the amount of
contract deployment and function invocation from us. Except tokens deposited into the DEX, the Type-I fake deposit attack
for tokens, as DEXes also perform all their functionalities in is considered successful.
smart contracts (see §II-E), we also deployed the DEXes in Type-II Attack. The Type-II attack relies on the flaws in
our testing environment for the following test. back-end source code of CEX, as discussed in §III-B2. Though
3) Verify Deposit Behaviors: As shown in Fig. 4, we use it is impossible for us to obtain the source code, we should
the sendTransaction to invoke the functions in deployed not underestimate the financial losses which may result from
smart contracts. In sendTransaction, we can indicate the this type of attack. Therefore, we just assume the CEX has
invoker, receiver, and the specific function and its parameters a deficiency in validating transactions and perform attacks
in from, to, and data respectively. following the behaviors detailed in Fig. 5(b). Specifically, like
As explained in §III-B, there are two types of flawed the verification of Type-I attack, we firstly issue the token
verification of DEX and CEX, which requires different deposit and transfer only 1 token to attacker account. Then, however,
behaviors, i.e., different testing processes. Therefore, we divide the attacker would call the transfer function in the ERC-
the verifying process into two parts (as shown in Fig. 5), which 20 with the _to as address of the CEX and _value as
aim to verify the vulnerabilities existed in DEX and CEX. 100, which is also unaffordable to him. After that, we would
Type-I Attack. Type-I attack is related to the DEXes. Under examine this transaction in our private chain to check if the
normal circumstances, the depositToken in DEXes’ smart status is 1. If it is, we can assume this kind of token has
contract would invoke the traded token’s transferFrom or possibility to be fake deposited into some defective CEXes.
transfer. However, the mis-implementation of functions in Therefore, we have measured the most worst case for the fake
ERC-20 tokens would result in Type-I attack. Except for the deposit behavior between ERC-20 and CEX in Type-II attack.
example raised in §III-B1, there exists some other cases. If the
smart contract does not implement the transferFrom or V. E VALUATION
transfer at all, the invocation from depositToken will Our evaluation is driven by the following research questions:
 2020 March 4251 10 0.24%

100% 700
RQ1 How many ERC-20 smart contracts are vulnerable to fake Percentage of Deployed ERC-20

Percentage of Deployed ERC-20

deposit attacks, and can be successfully exploited? We Vulnerable ERC-20 Token 600

want to measure the overall landscape of fake deposit

# Vulnerable ERC-20
500
10%
vulnerability across all the ERC-20 tokens. 400
RQ2 How effective is DEPOSafe in identifying fake deposit
300
vulnerability? We want to measure the precision and 1%
200
recall of DEPOSafe.
RQ3 What is the impact of the fake deposit vulnerability? 100

To answer RQ1, we apply the DEPOSafe to all of the 176k 0

16 ry

16 l
ly

Ja er
17 ry

17 l
ly

18 ry

18 l
ly

19 ry

19 l
ly

y
20 pri

20 pri

20 pri

20 pri
be

be

be
ERC-20 smart contracts deployed by the time of this writing.

ar
Ju

Ju

Ju

Ju
20 nua

20 nua

20 nua

20 nua
b
A

nu
20 cto

20 cto

20 cto

20 cto
Ja

Ja

Ja

Ja
O

O
16

17

18

19

20
To evaluate the effectiveness of DEPOSafe (RQ2), we manu-

16

17

18

19
20

20

20

20

20
ally select samples and perform a fine-grained analysis on the Fig. 6. The distribution of ERC-20 smart contracts with fake deposit
false positives and false negatives introduced by both static vulnerability, and its percentage of deployed ones in each month.
detector and dynamic validator in DEPOSafe respectively. To
unfamiliarity to ERC-20 standard. For the following four
answer RQ3, we further analyze the transactions and volume
months, all the deployed ERC-20 contracts are not vulnerable
of these vulnerable ERC-20 tokens and corresponding DEXes,
to fake deposit vulnerability. It might be that the number of
as an indicator to measure the overall impacts.
new deployed ERC-20 contracts are small, which are between
A. RQ1: Vulnerable ERC-20 Smart Contracts 15 to 33. From then on, the percentage fluctuated between
1% to 10%, even if the absolute number changes dramatically.
1) Overall Result: After analyzing 176,559 ERC-20 smart
It suggests that although attacks related to this vulnerability
contracts deployed before April 2020, 7,735 (4.38%) smart
have been reported from time to time, there are always a
contracts are marked as vulnerable by DEPOSafe. Among
considerable number of developers who overlooked it.
them, 56 smart contracts are vulnerable to Type-I attack (see
§IV-B3 and Fig. 5), while 7,716 of them can be exploited by B. RQ2: The Effectiveness of DEPOSafe
the Type-II attack3 . It suggests that fake deposit vulnerability
is prevalent in the ERC-20 smart contract ecosystem. DEPOSafe is composed of two components: static detector
Note that, for the 56 smart contracts that are vulnerable and dynamic validator. Due to the inherent limitation of static
to Type-I attack, they can be indeed exploited by attackers analysis, the false positives will be introduced inevitably.
in the wild, due to their vulnerable implementation. For the Conversely, though dynamic validator 2can ensure the exploited
7,716 smart contracts that are vulnerable to Type-II attack, smart contracts are really vulnerable, it will introduce false
whether the attacks could be successfully performed are also negatives, as some vulnerable contracts cannot be easily trig-
relying on the verification of CEXes. As aforementioned in gered. Therefore, we seek to evaluate the effectiveness of the
§III, performing Type-II attack also requires the flawed verifi- static detector and dynamic validator, respectively.
cation of CEXes, including lacking audit to tradable token Specifically, the first phase of DEPOSafe (i.e., static detec-
and deficiency in back-end verification. As we are unable tor) has reported 9,856 suspicious smart contracts, as they have
to acquire the source code of CEXes, we can only measure shown code-level patterns of the vulnerability. As DEPOSafe
the vulnerability from the perspective of smart contracts. only reports 7,735 vulnerable contracts after the second phase
Nevertheless, these vulnerabilities are indeed existing, which (i.e., dynamic validator), there remains a gap of 2,121 contracts
pose great security issues, especially when considering the between these two phases. Note that, there are no false
fake deposit attacks are frequently reported from time to time. positives introduced by DEPOSafe, as all the 7,735 reported
2) Distribution of the Vulnerable ERC-20 Smart Contracts: smart contracts can be exploited successfully.
We further analyze the distribution of these 7,735 vulnerable 1) Manually Investigation: Next, we seek to analyze the
smart contracts based on their deployment time. As depicted 2,121 unreported ones, to see (1) how many of them are false
in Fig. 6, the number of smart contracts that are vulnerable positives introduced by static detector, but later removed by
to fake deposit vulnerability shows an increasing trend till our dynamic validator, and (2) how many of them are false
June 2018, which may be due to the growing popularity of negatives of DEPOSafe, which are indeed vulnerable ones
ERC-20 tokens. After that, the amount of vulnerable contracts but missed by the dynamic validator. Furthermore, we also
declined greatly. We speculate the decline is related to a mass sample smart contracts from the unreported ones in the 176K
of attack behaviors towards Ethereum, which in turn reminds tokens to evaluate (3) the overall coverage of DEPOSafe (as
the developers of newly deployed ERC-20 tokens. the coverage is relying on the performance of static detector).
Fig. 6 also shows the proportion of the vulnerable ERC-20 For the 2,121 smart contracts, 671 of them are open-source.
contracts within the deployed ones in each month. As we can Thus, we decide to select contracts from open-source ones for
see, for the first month (January, 2016), all of the 5 ERC- achieving accurate manual investigation. We firstly sorted them
20 tokens are affected, which may due to the developer’s by the lexicographic order based on the contracts addresses,
and then grouped them into 10 subsets (67 contracts in first
3 37 smart contracts can be exploited by both types of attacks. nine groups, and 68 contracts in the last one). Next, we chose
10 contracts randomly from each subset and analyzed them may still be implemented in a way that does not conform to
(overall 100 contracts) manually (Dataset-1). Moreover, we the ERC-20 specification. To be specific, as shown in listing 4,
randomly select 100 smart contracts (with source code) from the transfer invokes transferFrom to complete the
the unreported ones in the 176K ERC-20 tokens (Dataset-2). logic of transferring tokens. Even if such an implementation
In total, we manually investigate 200 smart contracts. could check the adequacy of balance of the invoker, this
2) Effectiveness of DEPOSafe: After two rounds of thor- would not be consistent with the specification set out in
ough and careful inspections by the first two authors, we ERC-20 guidance [2] in which it strictly limits the behaviors
have identified 90 false positive cases introduced by the of transfer, i.e., throwing an exception directly inside
static detector (but eliminated by dynamic validator) and 10 transfer if there is an insufficient balance.
false negative cases from the 100 sampled smart contracts in
1 function t r a n s f e r ( address dst , uint val )
Dataset-1. As to the Dataset-2, all of them are confirmed to be public r e t u r n s ( bool ) {
true negatives (i.e., without vulnerability). This result suggests 2 r e t u r n t r a n s f e r F r o m ( msg . s e n d e r , d s t , v a l ) ;
the effectiveness of DEPOSafe, i.e., most of the vulnerable 3}
smart contracts can be automatically exploited by DEPOSafe. 4
5 function t r a n s f e r F r o m ( address src , address dst
Overall, the precision of DEPOSafe is 100% (as all the
, uint val ) public r e t u r n s ( bool )
reported cases are vulnerable), and the recall of DEPOSafe 6{
is roughly over 99%4 . 7 r e q u i r e ( b a l a n c e O f [ s r c ] >= v a l ) ;
3) False Positives of Static Detector: The 90 false positives 8 ...
of static detector fall into three categories, including inter- 9}
contract SafeMath (72), stringent throw check (15), and non- Listing 4. An example of a mis-implementation of transfer.
standard transfer implementation (3).
Inter-Contract SafeMath. As shown in Listing 1, some 4) False Negatives of DEPOSafe: We have observed two
contracts implement safeAdd-like arithmetic operations in reasons leading to the false negatives of DEPOSafe: insuffi-
SafeMath contract, in order to perform an overflow verifi- cient initialization (9) and insufficient supply (1). Notice that,
cation by throwing an exception. However, the SafeMath is all of them are related to Type-II attack (see §III-B2).
often implemented in another contract, and the token contract Insufficient Initialization. Our dynamic validator follows
will inherit it and invoke the functions in it to perform certain attack pattern that is described in §IV-B to validate
arithmetic operations. For example, the transfer in listing 1 the vulnerability. However, some tokes implement several non-
calls two functions, i.e., safeAdd and safeSub, to prevent standard requirements such that they need additional initializa-
overflows. Nevertheless, on the bytecode level, the opcode tion. For example, BigAppleToken [26], which implements all
sequence of safeAdd (and safeSub) can be either inlined the mandatory functions in ERC-20 interface, has one special
into the transfer function, or invoked by the opcode CALL. function as shown in listing 5.
In the former case, we can easily locate the revert opcode
1 bool public t r a n s f e r E n a b l e d ;
as shown in §IV-A. However, in the latter case, because 2 function enableTransfer ( bool enable ) external
DEPOSafe does not achieve the inter-contract symbolic ex- onlyOwner {
ecution (due to the limitation of Mythril), we cannot locate 3 transferEnabled = enable ;
the revert operation and conduct the backward tracing 4 . . . / / following logic
accordingly, which will result in false positives. 5}
Stringent throw Check. As we mentioned in §IV-A2 and Listing 5. The code snippet in BigAppleToken.
§IV-A3, in the transfer (or transferFrom) function,
we would firstly locate the variables being updated, and Apart from that, in the transfer function, there is one more
then trace backwards to verify if they are protected by the line (i.e., require(transferEnabled)) before all the
throw statement. However, the semantic information of the statements, which can be regarded as a switch to enable the
bytecode is usually insufficient. As shown in the bottom function. Moreover, as the function names vary, it is impossi-
right node in Fig. 3, we are unable to distinguish the targets ble to take every situation into consideration. Therefore, such
of SSTORE between msg.sender and _to. Therefore, to kind of tokens, which require additional initialization process,
guarantee the soundness of our static detector, we would check cannot pass the validator.
the verification on balance table for both of them, which Insufficient Supply. Under most circumstances, when the
inevitably introduces false positives as only the check for variable totalSupply of a contract is initialized, all the
balanceOf[msg.sender] is necessary. balance will be transferred to the owner’s account, i.e.,
Non-Standard transfer Implementation. Even if the msg.sender. However, in some cases, the initial supply is
transfer function is implemented with the correct logic, it given to a designated address, like the code snippet shown
in Listing 6. As it is impossible to assign the addresses of
4 It is estimated based on the proportion of false negative cases in Dataset-1
new created accounts even in the testnet of Ethereum, we
and Dataset-2, as roughly 212 cases (10% * 2121) would be considered to be
false negatives, among all the 176K contracts. Precision = TP/(TP+FP) and cannot execute the following logic of dynamic validator unless
recall = TP/(TP+FN). modifying the source code.
 TABLE I the DEX, as both of the transfer and transferFrom
T OP 5 VULNERABLE TOKENS WITH MOST HOLDERS (T YPE -I) AND will return a boolean value to indicate if the transferring
LARGEST MARKET CAP (T YPE -II).
Type-I Type-II
succeeds, the DEX should never assume the return value
Token #Holders #Txs Token Cap($) #Holders #Txs from tokens. Additionally, it should handle the exception
CLB 53 62 BRC 391K 87K 1,382K properly if the token raises it. For the CEX, it should perform
BB 50 32 BAT 388K 305K 2,054K
LOVE 49 85 HPT 63K 1K 7K a comprehensive verification on each transaction of deposit
eDOGE 21 21 RPL 39K 3K 30K request in back-end servers.
EMVC 13 15 POWR 28K 50K 378K
Limitation. We characterize the fake deposit vulnerability
Total(56) 258 1,178 Total(7,716) 1.1B 695K 4.6M
mainly from the perspective of the ERC-20 smart contracts. As
we mentioned, performing the Type-II attack also requires the
1 a d d r e s s p u b l i c f o u n d e r = 0xCB7E . . . ; // a fixed flawed verification of CEXes. However, we are unable to get
address the source code of CEXes. Thus, we only measure the scale
2 balances [ founder ] = totalSupply ; of the vulnerable ERC-20 tokens, which is an upper bound for
the Type-II attack. Besides, we did not analyze the transactions
Listing 6. An example of the insufficient supply problem.
on Ethereum, which may reveal the existence of real-world
Moreover, in some cases, there might not exist initial supply at fake deposit attacks. Furthermore, it was reported that the fake
all. Thus we cannot perform the validation shown in Fig. 5(b). deposit attacks have been observed in other blockchains (e.g.,
USDT [28], EOSIO [29]), while this paper only focused on
C. RQ3: The Impact of the Fake Deposit Vulnerability Ethereum. We leave them for the future work.
We further measured the impact of the 7,735 influenced
tokens. As described in RQ1, 56 ERC-20 tokens are affected VII. R ELATED W ORK
by Type-I attack. The top-5 tokens (Type-I) with the highest Characterizing the Blockchain Ecosystem. A number of
number of holders and transactions are shown in Table I studies have measured the blockchain ecosystem [30]–[35].
(Column 1-3). They have 258 holders and 1,178 transactions Chen et al. [35] characterized money transfer, contract creation
in total. Although the overall volume of them is not large, ac- and invocation of Ethereum through graph analysis. Huang et
cording to the validation methods we described in §IV-B, these al. [30] characterized EOSIO blockchain, and [34] proposed
56 contracts can be attacked in the wild as long as the DEXes an approach to identify entities in Bitcoin blockchain.
allow these tokens to be traded and the depositToken is Program Analysis of Smart Contract. Based on program
used. Consequently, we have identified three such kinds of analysis techniques, e.g., symbolic execution and formal verifi-
DEXes, i.e., IDEX [20], DDEX [27], and Ether Delta [19]. cation, a variety of frameworks have been proposed to improve
IDEX and DDEX are still active with a relatively high trading the security of smart contracts [36]–[43]. Specifically, M.
volume, around 1 million USD per day according to the Mossberg et al. [41] proposed Manticore, a dynamic symbolic
statistics from etherscan.io. execution framework for analyzing Ethereum smart contract.
For the 7,716 tokens that are vulnerable to Type-II attack, He et al. [43] implemented a symbolic execution framework
they are potentially at risk of being attacked in the scenario for analyzing smart contracts at WebAssembly level, which is
of insufficient validation of CEXes. Table I shows the top-5 used by EOSIO blockchain.
tokens with the highest market capitalization. Note that, here ERC-20 Tokens. Several work [44]–[50] have focused on
we consider fully diluted market cap, which is calculated by the ERC-20 smart contracts in Ethereum. A number of stud-
multiplying the token total supply with the current market ies [45], [46], [49] analyzed the network structures of tokens
price per token. The data is acquired on 10th June from and transactions in Ethereum. Chen et al. proposed Token-
etherscan.io. If we take all the tokens suffered from Type- Scope [50], which is able to detect transactions that triggers
II attack into consideration, the market cap would be over inconsistent behaviors. Somin et al. [48] presents the analysis
1 billion USD, and the number of holders and transactions of the dynamical properties of the ERC-20 protocol, which in
would be 695K and 4.6 million respectively. Therefore, if a turn allows the prediction of some network parameters.
CEX allows these tokens to be traded without comprehensive
verification, the financial loss will be tremendous. VIII. C ONCLUSION
In this work, we have systematically characterized the fake
VI. D ISCUSSION deposit vulnerability in Ethereum. DEPOSafe, an automated
Mitigation of Fake Deposit Vulnerability. For developers, tool is proposed to perform the detection and verification of
strictly following the official guideline [2] is always a good the vulnerability. We demonstrate the efficiency of DEPOSafe
choice. To be specific, developers should implement all the six with experiments on a large number of smart contracts. Our
mandatory functions carefully, especially the transfer and observations reveal the prevalence of fake deposit vulnerability
transferFrom that are closely related to the transferring in the ERC-20 smart contracts. Our efforts can positively
behaviors. The developer should throw an exception if any contribute to bring developer awareness, attract the focus of
mis-behavior happens (like insufficient balance or allowance) the research community and regulators, and promote best
in both of them instead of returning a boolean value. For operational practices across blockchains.
 R EFERENCES [31] N. He, L. Wu, H. Wang, Y. Guo, and X. Jiang, “Characterizing
code clones in the ethereum smart contract ecosystem,” arXiv preprint
[1] (2020, Apr.) Ethereum official site. [Online]. Available: https: arXiv:1905.00272, 2019.
//ethereum.org/ [32] M. Saad, J. Choi, D. Nyang, J. Kim, and A. Mohaisen, “Toward
characterizing blockchain-based cryptocurrencies for highly accurate
[2] (2019, Mar.) Official guide to ERC-20 standard. [Online]. Available:
predictions,” IEEE Systems Journal, 2019.
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md
[33] P. Xia, B. Zhang, R. Ji, B. Gao, L. Wu, X. Luo, H. Wang, and
[3] Julia Magas. (2019, June) Explanation of DEX. [Online]. Available:
G. Xu, “Characterizing cryptocurrency exchange scams,” arXiv preprint
https://cointelegraph.com/explained/dex-explained
arXiv:2003.07314, 2020.
[4] Comply Advantage. (2020, Apr.) Defination of DEX. [Online]. [34] M. Jourdan, S. Blandin, L. Wynter, and P. Deshpande, “Characterizing
Available: https://complyadvantage.com/knowledgebase/kyc/ entities in the bitcoin blockchain,” in 2018 IEEE International Confer-
[5] Mix. (2018, Nov.) Attacks towards Ethereum exchange. [Online]. ence on Data Mining Workshops (ICDMW). IEEE, 2018, pp. 55–62.
Available: https://thenextweb.com/hardfork/2018/11/22/vulnerability-eth [35] T. Chen, Y. Zhu, Z. Li, J. Chen, X. Li, X. Luo, X. Lin, and X. Zhange,
ereum-gastoken-exchange/ “Understanding ethereum via graph analysis,” in IEEE INFOCOM 2018-
[6] Adrian Zmudzinski. (2019, Sep.) Attacks towards Ethereum exchange. IEEE Conference on Computer Communications. IEEE, 2018, pp.
[Online]. Available: https://cointelegraph.com/news/developers-of-ether 1484–1492.
eum-dex-protocol-airswap-disclose-critical-exploit [36] N. Grech, M. Kong, A. Jurisevic, L. Brent, B. Scholz, and Y. Smarag-
[7] ——. (2019, July) Attacks towards Ethereum exchange. [Online]. dakis, “Madmax: Surviving out-of-gas conditions in ethereum smart
Available: https://cointelegraph.com/news/0x-dex-protocol-suspended-b contracts,” Proceedings of the ACM on Programming Languages, vol. 2,
ecause-of-vulnerability-funds-safe no. OOPSLA, pp. 1–27, 2018.
[8] J. Chen, X. Xia, D. Lo, J. Grundy, X. Luo, and T. Chen, “Defining smart [37] S. Kalra, S. Goel, M. Dhawan, and S. Sharma, “Zeus: Analyzing safety
contract defects on ethereum.” of smart contracts.” in NDSS, 2018, pp. 1–12.
[9] CHINABTCNEWS. (2018, July) Attacks agianst fake deposit [38] L. Brent, A. Jurisevic, M. Kong, E. Liu, F. Gauthier, V. Gramoli, R. Holz,
vulnerability. [Online]. Available: https://news.8btc.com/slowmis and B. Scholz, “Vandal: A scalable security analysis framework for smart
t-3619-eth-based-tokens-are-affected-by-fake-deposit-vulnerability contracts,” arXiv preprint arXiv:1809.03981, 2018.
[10] SyncFab. (2018, Aug.) Attacks agianst fake deposit vulnerability. [39] S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy, R. Takhaviev,
[Online]. Available: https://medium.com/syncfabmfg/erc20-fake-depos E. Marchenko, and Y. Alexandrov, “Smartcheck: Static analysis of
it-vulnerability-countered-by-bitforex-maintenance-and-mfg-smart-con ethereum smart contracts,” in Proceedings of the 1st International
tract-upgrade-6699bf086e28 Workshop on Emerging Trends in Software Engineering for Blockchain,
[11] Stephen O’Neal. (2019, Mar.) Attacks agianst 2018, pp. 9–16.
fake deposit vulnerability. [Online]. Available: [40] J. Feist, G. Grieco, and A. Groce, “Slither: a static analysis framework
https://cointelegraph.com/news/ledger-client-address-issue-and-fak for smart contracts,” in 2019 IEEE/ACM 2nd International Workshop on
e-deposits-community-spots-two-vulnerabilities-related-to-monero Emerging Trends in Software Engineering for Blockchain (WETSEB).
[12] (2020, May) Attacks agianst fake deposit vulnerability. [Online]. IEEE, 2019, pp. 8–15.
Available: https://www.chainnews.com/news/524364903562.htm [41] M. Mossberg, F. Manzano, E. Hennenfent, A. Groce, G. Grieco, J. Feist,
[13] (2020, Apr.) Ofiicial site of mythril. [Online]. Available: https: T. Brunson, and A. Dinaburg, “Manticore: A user-friendly symbolic
//github.com/ConsenSys/mythril execution framework for binaries and smart contracts,” in 2019 34th
[14] J. R. Cruz. (2013, May) Keccak256 hash function. [Online]. IEEE/ACM International Conference on Automated Software Engineer-
Available: https://www.drdobbs.com/security/keccak-the-new-sha-3-enc ing (ASE). IEEE, 2019, pp. 1186–1189.
ryption-standard/240154037 [42] P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Buenzli, and
[15] (2020, Apr.) Documentation of Solidity. [Online]. Available: https: M. Vechev, “Securify: Practical security analysis of smart contracts,” in
//solidity.readthedocs.io/en/v0.6.6/ Proceedings of the 2018 ACM SIGSAC Conference on Computer and
[16] ethervm. (2019, Sep.) Opcodes supported by EVM. [Online]. Available: Communications Security, 2018, pp. 67–82.
https://ethervm.io/ [43] N. He, R. Zhang, L. Wu, H. Wang, X. Luo, Y. Guo, T. Yu, and
X. Jiang, “Security analysis of eosio smart contracts,” arXiv preprint
[17] (2020, Apr.) Coinbase official site. [Online]. Available: https:
arXiv:2003.06568, 2020.
//www.coinbase.com/
[44] G. Fenu, L. Marchesi, M. Marchesi, and R. Tonelli, “The ico phe-
[18] (2020, Apr.) Binance official site. [Online]. Available: https://www.bina
nomenon and its relationships with ethereum smart contract environ-
nce.com/en
ment,” in 2018 International Workshop on Blockchain Oriented Software
[19] (2020, Apr.) EtherDelta official site. [Online]. Available: https: Engineering (IWBOSE). IEEE, 2018, pp. 26–32.
//etherdelta.com/ [45] F. Victor and B. K. Lüders, “Measuring ethereum-based erc20 token
[20] (2020, Apr.) IDEX official site. [Online]. Available: https://idex.market/ networks,” in International Conference on Financial Cryptography and
[21] (2018, July) Fake deposit attack. [Online]. Available: https://www.chai Data Security. Springer, 2019, pp. 113–129.
nnews.com/articles/168840801152.htm [46] S. Somin, G. Gordon, and Y. Altshuler, “Network analysis of erc20
[22] (2020, June) web3.js, the Ethereum JavaScript API. [Online]. Available: tokens trading on ethereum blockchain,” in International Conference on
https://github.com/ethereum/web3.js/ Complex Systems. Springer, 2018, pp. 439–450.
[23] (2020, June) Ganache CLI provides private chain for Ethereum. [47] M. Fröwis, A. Fuchs, and R. Böhme, “Detecting token systems on
[Online]. Available: https://github.com/trufflesuite/ganache-cli ethereum,” in International Conference on Financial Cryptography and
[24] (2020, Apr.) Data explorer for Ethereum. [Online]. Available: Data Security. Springer, 2019, pp. 93–112.
https://etherscan.io/ [48] S. Somin, G. Gordon, A. Pentland, E. Shmueli, and Y. Altshuler,
[25] D. Crescenzi. (2018, June) Defination of fallback function. [Online]. “Erc20 transactions over ethereum blockchain: Network analysis and
Available: https://medium.com/upstate-interactive/the-truth-about-fallb predictions,” arXiv preprint arXiv:2004.08201, 2020.
ack-functions-in-solidity-a2c604f8e66b [49] W. Chen, T. Zhang, Z. Chen, Z. Zheng, and Y. Lu, “Traveling the
[26] (2020, June) BigAppleToken. [Online]. Available: https://etherscan.io/a token world: A graph analysis of ethereum erc20 token ecosystem,”
ddress/0xDfbfCe00fc2fDBd5951f0a1bc4D49b6d87BF516D#code in Proceedings of The Web Conference 2020, 2020, pp. 1411–1421.
[27] (2020, Apr.) DDEX official site. [Online]. Available: https://ddex.io/ [50] T. Chen, Y. Zhang, Z. Li, X. Luo, T. Wang, R. Cao, X. Xiao, and
[28] (2020, Mar.) Fake deposit attack towards USDT. [Online]. Available: X. Zhang, “Tokenscope: Automatically detecting inconsistent behaviors
https://www.coinness.com/news/582082 of cryptocurrency tokens in ethereum,” in Proceedings of the 2019 ACM
[29] SlowMist. (2019, Mar.) Fake deposit attack towards EOSIO. [Online]. SIGSAC Conference on Computer and Communications Security, 2019,
Available: https://medium.com/@slowmist/hard-fail-status-attack-for-e pp. 1503–1520.
os-7cfa73ae7d4b
[30] Y. Huang, H. Wang, L. Wu, G. Tyson, X. Luo, R. Zhang, X. Liu,
G. Huang, and X. Jiang, “Characterizing eosio blockchain,” arXiv
preprint arXiv:2002.05369, 2020.