2020 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPS)

Tokens, Types, and Standards:

Identification and Utilization in Ethereum
Monika di Angelo, Gernot Salzer
TU Wien, Vienna, Austria
{monika.di.angelo,gernot.salzer}@tuwien.ac.at

Abstract—Tokens are often referred to as the killer application and thus potentially increases speed. Finally, the immutable
of blockchains and cryptocurrencies. Some even believe that traces of transfers provide evidence that the transfers of the
basically everything can be tokenized, meaning that it can be digital ownership have not been tampered with. However,
represented by a tradable digital token. With decentralized P2P
networks that hold and distribute the tokens, one can build there is still a lack of tokenization standards and in many
various decentralized applications around them. As a digital asset jurisdictions also a lack of legal infrastructure in this regard.
on top of a cryptocurrency, crypto tokens are managed by a smart Purpose of tokens. As a medium of exchange, tokens can act as
contract, most commonly on Ethereum. A widespread high-level
a currency themselves. In this respect, they can also be termed
categorization of tokens distinguishes between payment tokens,
security tokens, and utility tokens. The need for clarifying the as the local currency of a dApp. In the main, crypto tokens are
differences lies in the fact that in most jurisdictions, security used beyond mere exchange by leveraging their most salient
tokens are more heavily regulated than other tokens. feature: being programmable. In this regard, they are used to
In this work, we contribute to the detection and classification trigger certain functions in the smart contract(s) of the dApp.
of crypto tokens from bytecode. First, we examine how ideas
on regulation are currently incorporated into respective stan-
Moreover, tokens may be linked to off-chain assets. They can
dards. Then, we discuss methods for identifying deployed token serve as means of fundraising, pre-order or investment, as well
contracts from bytecode. Furthermore, we analyze deployed as building an ecosystem or a community.
contracts regarding the standards to which they comply, and Creation of tokens on top of an existing blockchain is ac-
the type of token they may represent. Moreover, we investigate
the actual usage of tokens. Our empirical analysis uses the complished via smart contracts, so-called token contracts. As
transaction data from the Ethereum main chain up to block this is a widespread application type, coding patterns and best
8 750 000, mined on Oct 16, 2019. practice examples are readily available. Furthermore, there are
Index Terms—bytecode, compliance, regulation, smart con- token contract factories, either on-chain or as a web service.
tract, standard, token
Acquisition of tokens varies. For example, they can be pur-
I. I NTRODUCTION chased during an initial coin offering (ICO) or through a crypto
Applications on a P2P network that are not controlled by exchange, traded on-chain or received freely during an airdrop
a single entity are called decentralized applications (dApps). or as a reward for a service or behavior.
Usually, their front end is a browser or app interface, while The value of a token depends mainly on supply, demand and
their backend can – at least partly – be realized on a blockchain the trust that the participating community has in it, which is
or cryptocurrency. Major categories of dApps are still de- based on credibility and service.
centralized finance, followed by gambling and games, and Our Approach
marketplaces. Often, they provide their own token in the dApp.
A crypto token is a digital asset on top of a cryptocurrency Many projects implement their tokens on Ethereum. With
or blockchain, often as a programmable asset managed by a the publicly available Ethereum transaction data, we analyze
smart contract, for use within a project or dApp. Crypto tokens token contracts to answer the following questions.
are similar to the coins of a cryptocurrency, except that they • Which types of crypto tokens can be distinguished?
do not have their own blockchain or distributed ledger. Rather, • Which standards for token contracts are in use?
they are built on top of an existing one. • How can token contracts be identified from transaction
When we regard crypto tokens as representing the right to data?
something, we enter the area of tokenization. Tokenization is a • How can the type of a token be automatically inferred?
way to convert the rights to something into a digital artifact, a For our analysis, we examine both the deployed bytecode
so-called token. With crypto tokens, the benefits of tokeniza- and the calls to token contracts that we extract from transaction
tion lie mainly in higher liquidity, general programmability, data. We discuss several methods for the (semi-)automatic
and immutable proof of ownership. More precisely, fractional identification of token contracts and their type.
digital ownership lowers the barriers of entry for investors The presented evaluation of token contracts may benefit the
while it increases the liquidity of the tokenized assets. Further- design of future decentralized asset trading systems. It paves
more, programmability facilitates automated management of the way for an accurate assessment of deployed tokens with
investor rights and compliance regarding the tokenized assets, respect to their type, based on their bytecode and usage. We

978-1-7281-6978-1/20/$31.00 ©2020 IEEE 1

DOI 10.1109/DAPPS49028.2020.00001

Authorized licensed use limited to: IEEE Xplore. Downloaded on July 18,2020 at 04:49:28 UTC from IEEE Xplore. Restrictions apply.
contribute to the discussion about detection and classification It would be desirable to automatically identify the type of
of crypto assets. Furthermore, our work adds to a clearer in- token that a contract implements. In this work, we discuss first
sight into decentralized applications by further characterizing steps towards this goal.
the most heavily used application tokens.
III. T OKEN S TANDARDS
Roadmap. In section II, we discuss types of crypto tokens.
In section III, we summarize typical functionalities of token Standard token interfaces enable applications such as wallets
contracts and token standards. Our methods for analyzing to recognize tokens and interact with them. In this section, we
bytecode are detailed in section IV, while the methods for first clarify terms and summarize the functionalities provided
identifying token contracts are discussed in section V. We by token contracts. Then we introduce already accepted token
identify compliant tokens in section VI and non-compliant standards alongside with proposed security token standards.
ones in section VIII. In section VII, we examine the variability Finally, we reference available coding patterns.
and usage of token bytecode. We address the type distinction in A. Terms
section IX. In section X, we compare our approach to related
We assume the reader to be familiar with cryptocurrencies.
work. Section XI summarizes our findings and concludes.
For Ethereum specifics, we refer to [6]–[8].
II. T YPES OF T OKENS Ethereum distinguishes between externally owned accounts,
often called users, and contract accounts or simply contracts.
A widespread high-level categorization of tokens [1] distin-
Accounts are uniquely identified by addresses of 20 bytes.
guishes between payment tokens, security tokens, and utility
Users can issue transactions (signed data packages) that
tokens. The need for clarifying their differences lies in the fact
transfer value to users and contracts, or that call or create
that in most jurisdictions, security tokens are more heavily
contracts. These transactions are recorded on the blockchain.
regulated than other tokens. The main distinguishing feature
Contracts need to be triggered to become active, either by a
is the investment purpose of security tokens as opposed to the
transaction from a user or by a call (a message) from another
added value for the functioning of a product which is typical of
contract. Messages are not recorded on the blockchain since
utility tokens. Payment tokens fulfil a payment function with
they are deterministic consequences of the initial transaction.
little or no other function.
They only exist in the execution environment of the Ethereum
Legally, the distinction is still a grey area in many jurisdic-
Virtual Machine (EVM) and are reflected in the execution trace
tions. In [2], the authors discuss legal aspects of token sales
and potential state changes. We use ‘message’ as a collective
under US law, including a similar classification of token types,
term for any (external) transaction or (internal) message.
and the so-called ‘Howey Test’ (a list of criteria determining
whether a financial instrument qualifies as a security). They ar- Abstract Binary Interface (ABI). Most contracts in the
gue that jurisdictions should provide “regulatory certainty and Ethereum universe adhere to the ABI standard [9], which
a sensible path to compliance”. We use the Swiss FINMA [3] identifies functions by signatures that consist of the first four
definitions for security and utility tokens as a common ground bytes of the Keccak-256 hash of the function name together
for US [2], EU [4], and other jurisdictions. with the parameter types. Thus, the bytecode of a contract
contains instructions to compare the first four bytes of the
Security Tokens are “assets, such as a debt or equity claim call data to the signatures of its functions. The presence of a
on the issuer. In terms of their economic function, therefore, particular function in a contract can be checked by locating
these tokens are analogous to equities, bonds or derivatives.” the corresponding 4-bytes hash in its deployed bytecode. Thus,
Typically, it is a share in the issuing company (equity token). the compliance of a contract with interface standards can be
Regarding legal compliance, there is an ongoing discussion determined via its bytecode.
on how it could be integrated into a token standard (cf.
section III), as well as into wallets and exchanges (cf. [5]). B. Functionalities of Token Contracts
Utility Tokens are usually backed by a project, an application, The basic functionality of a token contract comprises:
or a dApp with a definable benefit (like access) and intend to bookkeeping of token holdings, transferring the ownership of
“provide access digitally to an application or service by means tokens by according changes in the book of token holdings in
of a blockchain-based infrastructure. The issue of utility tokens the respective token contract, and emitting events to record the
does not require supervisory approval if the digital access to transfers of ownership in the logs. Safe transfer is a mechanism
an application or service is fully functional at the time the where tokens are pulled (withdrawn) from an address after
tokens are issued.” The purpose of a utility token may include approval, as opposed to being pushed (transferred) to an
voting rights, some sort of reward, or staking governance. address where they may be lost in case the address is not
As these purposes and categories may overlap for a specific prepared for receiving tokens.
token, a finer-grained classification scheme may be more Additional token-related functionalities include the creation
adequate. Many tokens are hybrids concerning this coarse cat- and destruction of tokens (called minting and burning) as well
egorization [4]. Based on reviewed literature and a subsequent as their distribution and trading (e.g. via ICOs and airdrops).
empirical study, the authors of [1] distill eight archetypes of Often, token contracts also implement general functionalities
tokens. including authentication and roles, control (like pause, lock),

Authorized licensed use limited to: IEEE Xplore. Downloaded on July 18,2020 at 04:49:28 UTC from IEEE Xplore. Restrictions apply.
information provision (like view functions), and utilities (like Act Regulations CF, D and A.” Apart from its own mandatory
safe mathematical operations). functions, it makes some optional parts of ERC-20 manda-
tory. Moreover, it requires certain modifiers and constructor
C. Accepted Token Standards
arguments to be implemented.
The community continuously discusses and establishes stan-
ERC-1644 Controller Token Operation Standard [16] “allows
dard interfaces for tokens in the programming language Solid-
a token to transparently declare whether or not a controller
ity, which is prevalent on Ethereum. The following standards
can unilaterally transfer tokens between addresses.” This is
have been accepted so far.
motivated by the fact that “in some jurisdictions the issuer
ERC-20 Token Standard [10] is the most widely used and (or an entity delegated to by the issuer) may need to retain
most general token standard that “provides basic functionality the ability to force transfer tokens.” This standard requires
to transfer tokens, as well as allows tokens to be approved so compliant tokens to implement three mandatory functions and
they can be spent by another on-chain third party.” It lists six two events.
mandatory and three optional functions as well as two events ERC-1644 is part of ERC-1400 [17], a library of standards
to be implemented by a conforming API. for security tokens, which requires the contained standards
ERC-721 Non-Fungible Token Standard [11] concerns tokens to be backwards compatible with ERC-20 and via extensions
where each token is distinct (aka non-fungible) and thus also with ERC-777. Additionally, the library contains ERC-
enables the tracking of distinguishable assets. Each asset must 1410 for differentiated ownership and transparent restrictions,
have its ownership individually and atomically tracked. This ERC-1594 for on-chain and off-chain restrictions, and ERC-
standard requires compliant tokens to implement 10 mandatory 1643 for document and legend management.
functions and three events.
E. Coding Patterns for Token Contracts
ERC-777 Token Standard [12] defines advanced features to
interact with tokens while remaining backwards compatible Most tokens aim at establishing trust and credibility by
with ERC-20. It defines operators to send tokens on behalf of disclosing their source code on the leading blockchain explorer
another address, and hooks for sending and receiving in order for Ethereum, Etherscan1 . As a service, this platform checks
to offer token holders more control over their tokens. This that the deployed bytecode is the result of compiling the
standard requires compliant tokens to implement 13 mandatory provided source code with the given compiler settings, and
functions and five events. labels it as ‘verified source code’.
ERC-1155 Multi Token Standard [13] allows for the manage- Furthermore, many token related projects are developed
ment of any combination of fungible and non-fungible tokens publicly on the platform GitHub. Finally, we would like to
in a single contract, including transferring multiple token types point out the best practice coding patterns provided by Consen-
at once. This standard requires compliant tokens to implement Sys2 (including tokens), as well as the tested implementations
six mandatory functions and four events. of ERC standards by OpenZeppelin3 .

D. Proposed Security Token Standards IV. B YTECODE A NALYSIS

Apart from the accepted standards, several others are pro- We use verified source code from Etherscan if available,
posed and discussed, but not yet finalized. From the legal but relying solely on such contracts would bias the results:
perspective, the following security token standards seem in- In contrast to 18.9 M successful create operations, there is
teresting. While the first one is rather general, the other two verified source code for 73 k addresses (0.4 %) only. In this
are project-specific and company-backed. section, we describe our methods of bytecode analysis and
ERC-1462 Base Security Token [14] is a minimal extension list the tools we employ.
to ERC-20 that “provides compliance with securities regu- Unless stated otherwise, statistics refer to the Ethereum
lations and legal enforceability” and aims at general use- main chain up to block 8 750 000 (mined on Oct 16, 2019).
cases, while additional functionality and limitations related to We abbreviate factors of 1 000 and 1 000 000 by the letters k
projects or markets can be enforced separately. Furthermore, and M, respectively.
it includes “KYC (Know Your Customer) and AML (Anti
A. Code Skeletons
Money Laundering) regulations and the ability to lock tokens
for an account, and restrict them from transfer due to a legal To detect functional similarities between contracts we com-
dispute”. Moreover, it provides means to attach documents to pare their skeletons. They are obtained from the bytecodes of
tokens. This standard requires compliant tokens to implement contracts by replacing meta-data, constructor arguments, and
four further mandatory checking functions (on top of ERC-20) the arguments of PUSH operations uniformly by zeros and by
and two optional documentation functions. stripping trailing zeros. The rationale is to remove variability
that has little to no impact on the functional behavior (like
ERC-1450 LDGRToken [15] is a “security token for issuing
and trading SEC-compliant securities” that extends ERC-20. 1 https://etherscan.io/
This standard “facilitates the recording of ownership and 2 https://consensys.github.io/smart-contract-best-practices/

transfer of securities sold in compliance with the Securities 3 https://github.com/OpenZeppelin/openzeppelin-contracts

Authorized licensed use limited to: IEEE Xplore. Downloaded on July 18,2020 at 04:49:28 UTC from IEEE Xplore. Restrictions apply.
the swarm hashes added by the Solidity compiler or hard- signatures (collected from various sources), which allows us to
coded addresses of companion contracts). Skeletons allow us obtain a function header for 59 % of the 254 k distinct signa-
to transfer knowledge gained about one contract to others with tures on the main chain.5 Since signatures occur with varying
the same skeleton. frequencies and codes are deployed in different numbers, this
As an example, the 18.9 M contract deployments correspond ratio increases to 91 % (or 89 %) when picking a code (or a
to just 109 k distinct skeletons. This is still a large number, but deployed contract) at random.
more manageable then 239 k distinct bytecodes. By exploiting 3) Events: Another part of a contract’s interface are events,
creation histories and the similarity via skeletons, we are able which notify applications external to the blockchain about state
to relate 7.3 M of these deployments to some source code on changes. At the level of the EVM, events are implemented as
Etherscan, an increase from 0.4 to 39 %. LOG instructions with the unabridged Keccak-256 hash of the
event header as identifier.
B. Contract Interfaces We lack a tool that is able to extract the event signatures as
Understanding the interface of a contract renders its anal- reliably as the function signatures. But we can check whether
ysis much easier. To this end, we first extract the interface a given signature occurs in the code section of the bytecode,
from the bytecode of a contract, and then try to restore the as the 32-byte sequence is virtually unique. Even though this
corresponding function headers. heuristic may fail if the signature is stored in the data section,
1) Interface Extraction: We developed a pattern-based tool it performs well in general. E.g., when locating the event
to extract the interface in the form of 4-byte function signa- Transfer in the bytecodes corresponding to the 73 k verified
tures (cf. section III) from the bytecode. For validation, we source codes from Etherscan, we obtain just 272 mismatches.
applied it to the bytecodes of the 73 k verified contracts (71 k Many of them are due to source code declaring the event but
codes, 39 k skeletons) from Etherscan, using the ABIs given not using it, so the compiler adds it to the ABI, even though
there as ground truth. The signatures extracted by our tool it does not occur in the bytecode. Therefore, we regard this
differed from the ground truth in 42 cases. Manual inspection method as sufficiently reliable for our purpose.
revealed that our tool was correct also in these cases, whereas C. The Data and Its Use
the ABIs on Etherscan did not faithfully reflect the signatures
Section V details how we identify token contracts based on
in the bytecode (e.g. due to compiler optimization or library
both static and dynamic data of deployed contracts that we
code).
extract from transaction data and execution traces.
The validation set consists almost exclusively of bytecode
The static data consists of the deployment address, the byte-
generated by the Solidity compiler (covering most of its
code, its skeleton, the list of the extracted 4-byte signatures
releases), with just a few samples of LLL and Vyper code. We
of the implemented functions, and a flag indicating whether
therefore regard the validation as representative of the 9.6 M
the bytecode implements an event related to token transfers.
deployed contracts (220 k codes, 107 k skeletons) generated by
Moreover, we use the function headers and contract names
the Solidity compiler4 .
where available.
Another large group of deployed contracts consists of 5.2 M The dynamic data consists of all calls to and from contracts
short contracts (18 k codes, just 271 skeletons) without any (including the signature of the invoked function) as well as the
entry points. It consists mainly of contracts for storing gas signatures of the events actually emitted. The dynamic data is
(gasToken), but also of proxies (contracts redirecting calls sparse: for most contracts, only a small fraction of the offered
elsewhere) and of contracts involved in attacks. functions has ever been called, and many events have never
A third large group are 4.2 M contracts that self-destruct at been emitted. Moreover, observing a call to a contract with
the end of the deployment phase. They cannot be regularly a particular signature does not mean that the corresponding
called and thus contain no entry points either. function is indeed implemented; often a so-called fallback
What remains is a heterogeneous group of 1.4 k contracts function catches unknown signatures without raising an error.
(595 codes, 432 skeletons). For these, our tool shows an error Only if a function is frequently called, it is safe to assume
rate of 8 %, extrapolated from a random sample of 60 codes that it is part of the interface. To get a more complete picture,
that we manually checked. we accumulate the dynamic data for all contracts with the
For all groups taken together, our tool extracts the 4-byte same bytecode. If some behavior is observed with a particular
signatures of the interface with virtually no errors. contract, then we may assume that every contract with the
2) Interface Restoration: To understand the purpose of same bytecode will behave identically.
contracts we try to recover the function headers from the
signatures. As the signatures are partial hashes of the headers, D. Third Party Tools
we use a dictionary of function headers with their 4-byte We employ the Ethereum client Parity in archive mode to
obtain bytecode and execution traces. Postgres serves as our
4 Deployed code generated by solc can be identified by the first
few instructions. It starts with one of the sequences 0x6060604052, 5 An infinity of possible function headers is mapped to a finite number of
0x6080604052, 0x60806040818152, 0x60806040819052, or signatures, so there is no guarantee that we have recovered the original header.
0x60806040908152. In the case of a library, this sequence is prefixed by The probability of collisions is low, however. E.g., of the 322 k signatures in
a PUSH instruction followed by 0x50 or 0x3014. our dictionary only 19 appear with a second function header.

Authorized licensed use limited to: IEEE Xplore. Downloaded on July 18,2020 at 04:49:28 UTC from IEEE Xplore. Restrictions apply.
primary database for storing messages between and informa- We disregard (a), as the error rate of our signature ex-
tion on contracts. For analyzing contract interactions as graphs, traction tool is low (see its evaluation in the previous sec-
we use the graph database Neo4j. We query Etherscan over its tion). Situations (b) and (c) are unlikely since deviating
API for further information on deployed contracts (like source from standard interfaces would render the token contract
code or contract name) and utilize Matplotlib for plotting. inaccessible for general use. There are cases of (d): On the
one hand there are contracts that implement e.g. a function
V. M ETHODS FOR I DENTIFYING T OKEN C ONTRACTS
balanceOf(address), but being wallets rather than to-
In this section, we discuss methods to identify contracts that kens. On the other hand, we encountered singular bogus con-
provide token functionality. We first summarize related work tracts selling tokens via a standard interface without recording
and then present our approach. ownership, but returning the same balance to all queries. The
A. Methods from Related Work second case is rare and can be ignored (or even may be
1) Behavior-oriented Approach: The central task of a token considered a token), whereas the first one can be countered
contract is bookkeeping. Each token contract maintains a data by using e.g. a combination of features or by checking the
structure that maps user ids (like addresses) to quantities of code.
fungible tokens or lists of non-fungible ones. Moreover, it 2) Non-Compliant Tokens: Above all, the detection of non-
implements functions for querying the data structure and for compliant tokens requires to define conditions for a contract to
transferring tokens between users. Some researchers try to be considered as actually implementing a token. We approach
detect such behavior by symbolic execution and taint analysis a definition over several indicators.
of the bytecode. Due to the difficulty of the problem, this Partial ERC-20 Compliance. Based on the interface method,
method is still less effective than simpler approaches [18]. We partial compliance to a standard with a threshold on imple-
therefore rely on other methods for our analysis. mented functions could serve as definition for a token contract.
2) Interface-oriented Approach: Token contracts are sup- The functions transfer or transferFrom, and balanceOf are
posed to be accessible by wallets and exchanges, hence the bare essentials of an interface that enables applications to
they offer standardized interfaces. It is therefore a reasonable work with the token contract. We therefore mark contracts as
approach to identify token contracts over the implemented potential tokens when they provide these functions. Also, the
functions headers. This is accomplished by locating the pres- presence of the signatures for the optional functions name,
ence of the corresponding function signatures in the bytecode decimals, or totalSupply are a strong indicator for a token.
(cf. section IV). Limitations: This approach has the same issues as the
Most authors concentrate on fully ERC-20 compliant con- interface method. Additionally, it heavily depends on the
tracts [19], [20], while [18] accept tokens when they imple- threshold.
ment at least five of the six mandatory ERC-20 functions. The Token Contracts as Event Issuers. Token standards usually
latter work also shows the effectiveness of this method. require compliant contracts to emit an event with every token
B. Our Approach transfer indicating the affected token as well as the sender
and receiver. Further events signal other state changes like
We apply the interface-oriented approach to identify con-
modified allowances. These events can be used to identify the
tracts that implement all functions required by the token
emitting token contract, by detecting either their signature in
standards mentioned in section III and call them fully compli-
the code or the data written to the log.
ant. For not fully compliant contracts, we discuss additional
approaches to identification. We mark addresses as potential tokens if their code contains
1) Compliant Tokens – Identification via the Interface: The the event Transfer(address,address,uint256) or
interface-oriented approach is a simple and effective means for if they actually emitted the event. All standards in section III
detecting most compliant token contracts. For obtaining the require this event, except for ERC-1155 that replaces it by
interface as a list of implemented functions, we rely on our tool TransferSingle or TransferBatch.
for extracting signatures from the bytecode (section IV). To Limitations: This approach misses contracts if they do not
determine full compliance, we consider the required functions, implement the event, or if the signature cannot be detected in
but we disregard events, return values, and further require- the code and the event is never emitted because the contract
ments of the respective standards. remains unused. In rare cases, non-token contracts use this
Limitations: This approach may misclassify token contracts event for other purposes.
in the following situations: (a) signatures are extracted inaccu- Identifying Tokens by their Contract Names. To detect tokens
rately from the bytecode, (b) the contract uses an idiosyncratic in a heuristic fashion, we scanned the 70 k source codes on
interface instead of adhering to the ABI, (c) token functions Etherscan for contracts containing the strings ‘token‘ or ‘coin’
are named in a non-standard way, (d) the contract implements in their name. Then we associated the corresponding source
non-token functionality with token-specific function headers, codes to the actual deployments and marked them as potential
and (e) the token contract is implemented as a proxy that tokens.
forwards calls to another contract and thus does not contain Limitations: Even though token contracts are more likely to
the forwarded signatures. have their source code on Etherscan (as a means of building

Authorized licensed use limited to: IEEE Xplore. Downloaded on July 18,2020 at 04:49:28 UTC from IEEE Xplore. Restrictions apply.
trust), the source and thus the name of many contracts is TABLE I
F ULL C OMPLIANCE OF D EPLOYED T OKEN C ONTRACTS
not available. Moreover, this approach misses tokens named
differently or yields false positives. standard deployments bytecodes skeletons
ERC-20 166 191 92 328 32 090
VI. C OMPLIANT T OKENS ERC-721 2 740 1 268 999
ERC-777 82 34 29
In this section, we analyze deployed token contracts regard- ERC-1155 28 22 22
ing their compliance with at least one of the standards from ERC-1462 4 4 4
section III. Since there are tokens that do not comply with any ERC-1450 0 0 0
mentioned ERC standard, we further investigate non-compliant ERC-1644 19 5 5
contracts in section VIII. For both we employ the methods
from the previous sections on all deployed bytecode.
Figure 1 shows the deployments of ERC-compliant tokens After a hype in the first half of the year 2018, ERC-20
on Ethereum’s main chain on a time line, with ERC-20 deployments seem to stabilize at about 1000 per week.
compliance in the upper plot and the other compliances in Table I shows the number of fully compliant token deploy-
the lower plot. In each of the two plots, the upper horizontal ments for the standards from section III. With over 166 k
axis indicates the date line, while the lower one shows the deployments, ERC-20 is by far the most commonly used
Ethereum block number. Each bar represents the accumulated standard. Of all compliant token contracts, over 98% comply
number of deployments within 50 k blocks (about one week). with ERC-20. The non-fungible token standard ERC-721 is
As depicted in the upper plot, ERC-20 took off in the middle the second most common one, albeit only deployed in 1.6% of
of the year 2017, while the lower plot shows that the NFT the compliant contracts. The remaining standards are deployed
standard started to rise with the beginning of the year 2018. in small numbers only. A few token contracts comply with
more than one standard and consequently are counted for
each corresponding standard. In total, we identified 169 k fully
compliant token contracts.

VII. C ODE U SAGE , VARIABILITY AND R EUSE

A. Usage of Token Functions
Table II lists the nine most called functions of compliant
token contracts with their respective signature, header and
number of calls. Until block 8.75 M, Ethereum produced
almost 1 370 M messages. With over 193 M calls, the function
transfer accounts for 14 % of all Ethereum messages. Sum-
ming up all calls to compliant token contracts, we arrive at
326 M or 23.8 %. This clearly suggests that tokens are the
killer application for Ethereum.

B. Variability and Reuse

Ethereum is known for its high degree of code reuse
(cf. [21]–[23]), with almost 19 M deployed contracts having
only about 239 k unique bytecodes and 109 k distinct skele-
tons. This amounts to a code reuse factor of 79 regarding
bytecode and of 174 regarding skeletons.

TABLE II
C ALLS TO F UNCTIONS IN T OKEN C ONTRACTS

signature header number of calls

A9059CBB transfer(address,uint256) 193 390 892
70A08231 balanceOf(address) 28 204 061
23B872DD transferFrom(address,address,uint256) 25 266 224
18160DDD totalSupply() 10 331 342
Fig. 1. Creation of ERC-compliant token contracts. The lower horizontal axis DD62ED3E allowance(address,address) 7 413 635
indicates the Ethereum blocks, while the upper axis shows the corresponding 095EA7B3 approve(address,uint256) 6 446 899
dates. Each bar represents a bin of 50 000 blocks (corresponding roughly 8DA5CB5B owner() 5 257 436
to 1 week). The upper plot shows ERC-20 creations, while the lower plot 40C10F19 mint(address,uint256) 3 369 344
differentiates the other compliances. 313CE567 decimals() 2 998 962

Authorized licensed use limited to: IEEE Xplore. Downloaded on July 18,2020 at 04:49:28 UTC from IEEE Xplore. Restrictions apply.
 Among the deployed token contracts, we also find code B. Number of Implemented ERC-20 Functions
reuse. However, it is far less pronounced than the average for ERC-20 is the most widespread standard for tokens with
Ethereum. In table I, we observe that 169 k deployed token the mandatory functions transfer, transferFrom, totalSupply,
contracts correspond to 94 k bytecodes and 33 k skeletons. This allowance, approve, and balanceOf. We investigated how
amounts to a code reuse factor of just 1.8 for bytecodes and many of the six mandatory functions (signatures) all deployed
5.1 for skeletons. For tokens, code reuse can be attributed to contracts actually implement. The functions transfer and bal-
off-chain services for token contract deployment as well as to anceOf are the most essential ones for a dApp to work with
readily available blueprints for token contracts in Solidity (cf. the token. At the same time, they are not specific to tokens
section III). contracts. Rather, they also appear in applications that interact
The low reuse factor indicates that token contracts are with a token where these functions may serve as proxies.
tailored to different usage scenarios. This is also supported
by the fact that the number of functions implemented by
TABLE III
any token contract varies between 6 (the bare minimum of I MPLEMENTED ERC-20 F UNCTIONS WITH AND WITHOUT TRANSFER
ERC20 compliant tokens) and 130. In total, we have 57 k
different function signatures occurring in compliant contracts, deployments bytecodes skeletons

excl. transfer

excl. transfer

excl. transfer
incl. transfer

incl. transfer

incl. transfer
which means that on average, each skeleton implements two
functions unique to it.
VIII. N ON -C OMPLIANT T OKENS signatures
While the identification of tokens via the full compliance to 6 of 6 166 191 — 92 328 — 32 090 —
a standard interface is effective, it misses non-compliant to- 5 of 6 3 496 82 2 107 64 1 578 54
4 of 6 3 347 2 795 2 637 1343 1 016 1 080
kens. Etherscan lists ERC-20 and ERC-721 tokens even when
they are not fully compliant. They report over 200 k ERC-20 3 of 6 8 802 857 4 518 535 2 586 379
2 of 6 3 473 2 603 2 061 602 887 493
tokens for the study period, while only 166.2 k contracts are 1 of 6 203 708 28 125 539 3 175 476 2 275
fully ERC-20 compliant. Even well-known tokens implement
standards only partially by leaving out one or more of the Table III lists the number of contracts regarding the num-
mandatory functions. A famous example are the CryptoKitties. ber of ERC-20 signatures they provide. We differentiate the
In this section, we discuss approaches to define tokens numbers according to the presence or absence of the function
irrespective of full ERC compliance by looking at potential transfer, and also indicate the actual deployments on-chain, the
indicators for tokens. First, we establish a ground truth for corresponding unique bytecodes, and the respective skeletons.
token contracts. As indicators, we investigate partial ERC- Table III shows that 166.2 k deployed contracts implement
20 compliance with a possible thresholds on the number of the full ERC-20 interface. Furthermore, there are 203.7 k
provided ERC-20 functions, as well as contract names and contracts that provide only the function transfer but none of
events. the other mandatory ERC-20 functions. The latter contracts
A. Ground Truth for Token Contracts also show a remarkably small set of only 539 corresponding
To compare the indicators, we construct a token ground truth bytecodes, which represents a code reuse factor of 378 re-
(TGT) consisting of bytecodes implementing a token (positive garding bytecode and of 428 regarding skeletons. This hints
instances) and bytecodes not doing so (negative instances). towards factory-produced non-token contracts (e.g. wallets)
Below, the numbers in parentheses indicate the number of implementing a function transfer.
instances obtained by the respective method. In summary, the numbers in table III do not suggest a
In the first round, we consider the names that developers threshold for a minimum of functions required to implement
gave to their verified contracts on Etherscan. We mark a a token. Furthermore, the number of contracts implementing
bytecode as a positive instance of a token contract if the name between two and five of the mandatory functions is non-
of one of its deployments ends, case insensitive, with ‘token’ negligible. Hence, it is worthwhile to look for indicators
(18532) or ‘coin’ (4535). Likewise, we mark it as a negative beyond mere ERC compliance of implemented functions.
instance if the name ends with ‘exchange’ (307), ‘market’ (95),
C. Contract Names
‘auction’ (137), or ‘wallet’ (662).
Furthermore, by manual inspection we obtain further neg- When associating bytecode with the names of its deploy-
ative instances: wallets (2170), gasToken (16080), attack or ments on Etherscan (cf. section V), we can draw the follow-
otherwise nonsensical contracts (1066), and libraries (3215); ing picture. We list the number of deployed contracts and
and positive ones: non-compliant token contracts with minimal respective bytecodes, for which we can associate a name from
interfaces (304). Etherscan in table IV. In the first line, the high number of
Finally, we manually classified 250 bytecodes that received over 3 M deployments with associated names mainly results
the most calls, resulting in 120 positive and 148 negative from wallets [24]. A high factor between bytecodes and
instances. In total, our TGT consists of 23 k positive and 23 k deployments is atypical of tokens and rather an indicator for
negative instances. wallets.

Authorized licensed use limited to: IEEE Xplore. Downloaded on July 18,2020 at 04:49:28 UTC from IEEE Xplore. Restrictions apply.
 TABLE IV First, we have the core functions mandated by token stan-
A SSOCIATED C ONTRACT NAMES dards, as well as related ones for creating, destroying, and
contract with deployments bytecodes distributing tokens. Second, there are neutral functions that
name 3 162 177 71 179
may appear in any type of contract, like getters and setters for
‘token’ in name 116 793 23 386 public variables or role management. The third group consists
‘coin’ in name 8 326 5 914 of the remaining functions, which may rely on tokens but are
‘token’ in name and non-ERC 57 831 3 495
not necessary for operating the token.
We call a token contract pure if its interface contains only
functions from the first and second group. Pure tokens do not
D. Effectiveness of Indicators
provide functions that indicate a service or product, hence
Table V compares the effectiveness of the indicators above they probably are security rather than utility tokens. Non-pure
on our token ground truth (TGT), measured by precision and tokens, on the other hand, are more likely to be utility tokens.
recall. Let tp (true-positive) denote the number of positive To partition the functions of an interface into the three
TGT instances classified correctly as a token, fp (false- groups we analyze the function names. Unsurprisingly, the
positive) be the number of negative TGT instances classified names in the first and second group are quite uniform and
wrongly as a token, and fn (false-negative) be the number stereotypical as the functions perform standardized tasks.
of positive TGT instances classified wrongly as a non-token. Therefore, this heuristic approach seems reasonable.
Precision is computed as the quotient tp/(tp +fp). A precision In the remainder of this section, we first detail our method
value close to one means that the number of negative instances for function classification and then use it to classify compliant
mistaken as positive ones is small; if the indicator classifies token contracts.
a bytecode as a token, then it most likely is one. Recall is
computed as the quotient tp/(tp + fn). A recall value close to A. Token-Related and Neutral Functions
one means that the number of positive instances not recognized To classify function headers, we use rules of the form ‘If
as tokens is small; if the indicator is applied to a token a header matches the regular expression re 1 but not re 2 , then
contract, then it is most likely classified as such. it belongs to category C.’ We devise the rules empirically
The highest precision and the second best recall is achieved in a repetitive manner, by searching yet unclassified headers
by checking the contract name for ‘token’ or ‘coin’. This for patterns, deducing new rules, checking their effect on all
seems plausible: if a developer calls a contract a token, then it headers, refining them, removing already classified headers,
probably is one. However, our ground truth is biased towards and repeating the process with the remaining ones.
this indicator, as the majority of positive instances has been As an example, one of our rules reads ‘If the header
selected by this criterion; moreover, the indicator can only be matches ^(get|is|total|balance) but not ^issue,
applied if the contract name is available. then it belongs to the category getter’. It labels headers
like getAuthor() and IsActive() as getters, whereas
TABLE V issueToken(address) is skipped. Another rule detects
E FFECTIVENESS OF I NDICATORS FOR I DENTIFYING T OKEN B YTECODES functions related to ICOs, taking into account that unicorns
indicator precision recall and icoins are not ICO-related: ‘If the header matches ico
The contract name contains either ‘token’ or ‘coin’. 99.7 98.5 but not unicorn|icoin, then it is of category ico’.
Bytecode is fully ERC compliant (section VI). 99.5 92.5 Limitations: The effectiveness of this method hinges on
Bytecode implements at least three functions of some 99.4 98.2 how carefully the rules are chosen. Moreover, the method
ERC standard.
Some deployment of bytecode has emitted the event 99.4 80.9 assumes that at least for the first and second group, the names
Transfer. of functions indicate the implemented functionality. Finally, a
Bytecode implements at least one of the functions 99.3 98.8 contract may delegate some function calls to another contract
transfer or transferFrom.
Bytecode contains the signature of event Transfer. 99.2 96.4 (like a library) such that the signatures extracted from the
Bytecode contains the event Transfer or it has been 99.1 96.6 contract represent only part of the interface.
emitted by any of its deployments.
B. Pure Compliant Token Contracts
We apply our classification scheme to the 94 k compliant
IX. D ISTINCTION OF T OKEN T YPES BY P URITY
token codes (deployed 169 k times). They contain 57 k distinct
In this section, we try to gain insights into the purpose of signatures, of which 43 k can be decoded to function headers.
token contracts at large, in particular with regard to their use Because of their uniformity, we expect signatures from the
as security or utility tokens. A precise classification of tokens first two groups to be mostly among the decoded ones. This
in large quantities would require automated code analysis to assumption can also be justified ex-post by the large number
check for semantic properties, which is a difficult problem of tokens that turn out to be pure tokens in our sense and thus
not yet adequately solved. Instead, we present a heuristic test do not contain any unknown signatures.
that starts from the observation that the functions of token We specified 22 rules that divide 35 k functions into 17
interfaces can be categorized into the following three groups. categories, with 8 k remaining unclassified. We regard headers

Authorized licensed use limited to: IEEE Xplore. Downloaded on July 18,2020 at 04:49:28 UTC from IEEE Xplore. Restrictions apply.
of the categories token, distribution, auction, minting, ap- unrelated code (e.g., creation code and Swarm code), and
proval, kyc, ico, transfer, crowdsale, airdrop, and burning tokenizing the code to keep opcodes only”. Then they generate
as token-related (first group), whereas the categories control, fingerprints of the deduplicated contracts by a customized
math, getter, setter, trading, and roles count as neutral (second version of fuzzy hashing and compute pair-wise similarity
group). 14 k unknown signatures and 8 k unclassified functions scores. In another approach to clone detection, the authors
form the other (third) group. of [28], [29] characterize each smart contract by a set of
critical high-level semantic properties. Then they detect clones
TABLE VI by computing the statistical similarity between the respective
P URITY OF C OMPLIANT T OKEN C ONTRACTS
property sets.
# other functions bytecodes deployments received calls To detect token systems automatically, the authors of [18]
= 0 (pure) 63 496 123 021 171 343 421 compare the effectiveness of a behavior-based method com-
>0 30 120 45 936 166 586 678 bining symbolic execution and taint analysis, to a signature-
all compliant 93 616 168 957 337 930 099 based approach limited to ERC20-compliant tokens. They
demonstrated that the latter approach detects 99 % of the
Table VI groups compliant token contracts depending on tokens in their ground truth data set. For all deployed bytecode,
whether their interface contains any function of the other though, it bears a “false positive risk in case of factory
(third) group. Interestingly, 63.5 k distinct bytecodes (corre- contracts or dead code”.
sponding to 123 k deployments) implement only token-related Our method of computing code skeletons is comparable
and neutral functions. According to our definition, they are to the first step for detecting similarities by [22]. Instead of
pure tokens that do not implement a recognizable service or fuzzy hashing as a second step though, we rely on the set of
product, and therefore could be security tokens. Consequently, function signatures extracted from the bytecode and manual
30.1 k bytecodes implement other functions as well. As this analysis, as our purpose is to identify token contracts reliably.
group contains 22 k different signatures, it is not apparent how While the usage of signatures is in line with [18], we extend
to decide automatically whether they offer a genuine service it beyond ERC-20 compliance by including other standards
or product. Thus, a different approach is required to classify as well and by discussing partial compliance. Furthermore,
the further functionalities of token contracts. as we aim at distinguishing pure tokens from those with
X. C OMPARISON TO R ELATED W ORK additional functionality, we also discuss methods for automatic
type inference.
Token Aspects. Most of the distantly related work focuses
on the transfer of assets and network communication on Bit- XI. C ONCLUSIONS
coin and other cryptocurrency platforms. Regarding Ethereum,
In this work, we contributed to the detection and classifica-
[25] examines “whether an attacker can de-anonymize ad-
tion of token contracts from the publicly available transaction
dresses from graph analytics against transactions on the
data of the Ethereum main chain. More specifically, we exam-
blockchain”. The authors of [26] “leverage graph analysis
ined token types and standards, and we discussed methods
to characterize three major activities, namely money transfer,
for identifying deployed contracts as tokens. Furthermore,
contract creation, and contract calls” with the aim to address
we analyzed deployed contracts regarding the standards to
security issues. Applying network science theory, [27] “find
which they comply, and the type of token they may represent.
that several transaction features, such as transaction volume,
Moreover, we investigated the actual usage of tokens including
transaction relation, and component structure, exhibit a heavy-
code reuse.
tailed property and can be approximated by the power law
function.” Compliance. ERC-20 is the most general and most prevalent
Regarding ERC-20 tokens on Ethereum, the authors of [20] token standard. Of the deployed compliant token contracts,
study the token trading network in its entirety with graph anal- over 98 % are ERC-20 compliant. The non-fungible token
ysis and show power-law properties for the degree distribution. standard ERC-721 is the second most common one, albeit
Similarly, the authors of [19] measure token networks, which only deployed in 1.6 % of the compliant contracts. Compliance
they define as the network of addresses that have owned a with regulations is still work in progress regarding both, the
specific type of token at any point in time, connected by the standards and the deployments because regulations are either
transfers of the respective token. not yet enacted or diverge in different jurisdictions.
Instead of examining the trading of tokens, our investigation Identification. Token contracts complying with standards can
puts a focus on the compliance of tokens to standards and be readily identified by extracting characteristic signatures
investigates the types of tokens. We look at token interactions from the bytecode (interface-oriented method) and by watch-
in the form of calls to the token contracts. We combine ing out for events mandated by the standard. Recognizing non-
the analysis of interactions with the analysis of bytecode to compliant tokens is more challenging, as they often implement
identify deployed contracts more reliably as tokens. the bare minimum of a token interface and may be mixed
EVM Bytecode Analysis. To detect code clones, the authors up with non-token contracts. Here a combination of different
of [22] first deduplicate contracts by “removing function indicators seems promising. Ultimately, to reach certainty, a

Authorized licensed use limited to: IEEE Xplore. Downloaded on July 18,2020 at 04:49:28 UTC from IEEE Xplore. Restrictions apply.
thorough analysis of the bytecode and its semantics is neces- [8] G. Wood, “Ethereum: A secure decentralised generalised transaction
ledger,” Ethereum Project Yellow Paper, Tech. Rep., 2019, https://
sary, which cannot be fully automatized yet. Our indicators, ethereum.github.io/yellowpaper/paper.pdf.
however, help to focus on relevant contracts. Moreover, they [9] “Contract ABI Specification,” 2019, accessed 2019-09-09. [Online].
may be sufficient for a statistical analysis of contracts where Available: https://solidity.readthedocs.io/en/latest/abi-spec.html
[10] F. Vogelsteller and V. Buterin, “ERC-20 token standard,” 2015, accessed
the misclassification of single contracts does no harm. 2019-10-12. [Online]. Available: https://eips.ethereum.org/EIPS/eip-20
Token Type. Distinguishing token types automatically in a [11] W. Entriken, D. Shirley, E. Evans, and N. Sachs, “ERC-721
non-fungible token standard,” 2018, accessed 2019-10-12. [Online].
heuristic fashion is feasible in a first step for pure tokens Available: https://eips.ethereum.org/EIPS/eip-721
that do not provide other functionalities than token-related and [12] J. Dafflon, J. Baylina, and T. Shababi, “ERC-777 token standard,”
neutral ones, and thus do not indicate a genuine product or 2015, accessed 2019-10-12. [Online]. Available: https://eips.ethereum.
org/EIPS/eip-777
service on-chain. Pure tokens amount to 70 % of the deployed [13] W. Radomski, A. Cooke, P. Castonguay, J. Therien, E. Binet, and
compliant token contracts (66 % regarding unique bytecodes). R. Sandford, “ERC-1155 multi token standard,” 2015, accessed 2019-
10-12. [Online]. Available: https://eips.ethereum.org/EIPS/eip-1155
Code Reuse is far less pronounced for compliant token con- [14] M. Kupriianov and J. Svirsky, “Base security token standard draft,”
tracts than the average for Ethereum, with a factor between 2019, accessed 2019-10-12. [Online]. Available: https://eips.ethereum.
deployed bytecode and unique bytecode of less than 2 as org/EIPS/eip-1462
[15] J. Shiple, H. Marks, and D. Zhang, “Ldgrtoken standard draft,”
opposed to a factor of nearly 80 on average. The unusually 2019, accessed 2019-10-12. [Online]. Available: https://eips.ethereum.
high code variability refers to the bytecode level. However, org/EIPS/eip-1450
on the level of functionality we are presented with the more [16] A. Dossa, P. Ruiz, F. Vogelsteller, and S. Gosselin, “Controlled token
standard proposal,” 2019, accessed 2019-10-12. [Online]. Available:
uniform picture of a high number of pure tokens. https://github.com/ethereum/EIPs/issues/1644
Code Usage. The fully compliant token contracts are respon- [17] ——, “Security token standard proposal,” 2019, accessed 2019-10-12.
[Online]. Available: https://github.com/ethereum/EIPs/issues/1411
sible for almost a quarter of all messages of Ethereum, which [18] M. Fröwis, A. Fuchs, and R. Böhme, “Detecting token systems on
makes them the dominant application. ethereum,” in International Conference on Financial Cryptography and
Data Security. Springer, 2019.
Limitations of Scope [19] F. Victor and B. K. Lüders, “Measuring ethereum-based erc20 token
networks,” in International Conference on Financial Cryptography and
We did not discuss regulations in depth as they are still in Data Security. Springer, 2019.
flux. The safety of the managed asset was out of scope as well [20] S. Somin, G. Gordon, and Y. Altshuler, “Network analysis of erc20
tokens trading on ethereum blockchain,” in International Conference on
as an analysis of security issues in token contracts. Moreover, Complex Systems. Springer, 2018, pp. 439–450.
we were not interested in the trading or market value of tokens. [21] L. Kiffer, D. Levin, and A. Mislove, “Analyzing ethereum’s contract
topology,” in Proceedings of the Internet Measurement Conference, ser.
Ideas for Further Work IMC ’18. New York, NY, USA: ACM, 2018, pp. 494–499. [Online].
Available: http://doi.acm.org/10.1145/3278532.3278575
Functionality that is split between several contracts is chal- [22] N. He, L. Wu, H. Wang, Y. Guo, and X. Jiang, “Characterizing
lenging to analyze. Heuristics for analyzing and understanding code clones in the ethereum smart contract ecosystem,” arXiv preprint
arXiv:1905.00272, 2019.
contracts are a promising field, as they may provide effective, [23] M. Di Angelo and G. Salzer, “Mayflies, Breeders, and Busy Bees in
yet simple means. Ethereum: Smart Contracts Over Time,” in Third ACM Workshop on
A semantic analysis of bytecode is indispensable for reliably Blockchains, Cryptocurrencies and Contracts (BCC’19). ACM Press,
2019.
determining what a smart contract actually implements. For a [24] ——, “Wallet Contracts on Ethereum,” arXiv preprint: 2001.06909,
massive automated semantic code analysis, better tool support 2020.
is desirable. [25] W. Chan and A. Olmsted, “Ethereum transaction graph analysis,” in
12th International Conference for Internet Technology and Secured
Transactions (ICITST). IEEE, 2017, pp. 498–500.
R EFERENCES [26] T. Chen, Y. Zhu, Z. Li, J. Chen, X. Li, X. Luo, X. Lin, and X. Zhange,
[1] L. Oliveira, L. Zavolokina, I. Bauer, and G. Schwabe, “To token or not “Understanding ethereum via graph analysis,” in IEEE INFOCOM:
to token: Tools for understanding blockchain tokens,” in International Conference on Computer Communications. IEEE, 2018, pp. 1484–
Conference on Information Systems (ICIS). AIS eLibrary, 2018. 1492.
[2] J. Rohr and A. Wright, “Blockchain-Based Token Sales, Initial Coin [27] D. Guo, J. Dong, and K. Wang, “Graph structure and statistical prop-
Offerings, and the Democratization of Public Capital Markets,” Hastings erties of ethereum transaction relationships,” Information Sciences, vol.
LJ, vol. 70, p. 463, 2019. 492, pp. 58–71, 2019.
[3] FINMA, accessed 2019-10-12. [Online]. Avail- [28] H. Liu, Z. Yang, C. Liu, Y. Jiang, W. Zhao, and J. Sun,
able: https://www.finma.ch/en/documentation/dossier/dossier-fintech/ “Eclone: Detect semantic clones in ethereum via symbolic transaction
entwicklungen-im-bereich-fintech/ sketch,” in Proceedings of the 2018 26th ACM Joint Meeting on
European Software Engineering Conference and Symposium on the
[4] P. Hacker and C. Thomale, “Crypto-securities regulation: Icos, token
Foundations of Software Engineering, ser. ESEC/FSE 2018. New
sales and cryptocurrencies under eu financial law,” European Company
York, NY, USA: ACM, 2018, pp. 900–903. [Online]. Available:
and Financial Law Review, vol. 15, no. 4, pp. 645–696, 2018.
http://doi.acm.org/10.1145/3236024.3264596
[5] Bittrex, “Controlled wallet,” 2017, accessed 2019-
[29] H. Liu, Z. Yang, Y. Jiang, W. Zhao, and J. Sun, “Enabling clone
10-12. [Online]. Available: https://etherscan.io/address/
detection for ethereum via smart contract birthmarks,” in IEEE/ACM
0xA3C1E324CA1CE40DB73ED6026C4A177F099B5770#code
27th International Conference on Program Comprehension (ICPC).
[6] Ethereum Wiki, “A next-generation smart contract and decentralized
IEEE Press, 2019, pp. 105–115.
application platform,” accessed 2019-02-02. [Online]. Available:
https://github.com/ethereum/wiki/wiki/White-Paper
[7] B. Vitalik, “Blockchain and smart contract mechanism design
challenges (slides),” 2017, accessed 2018-08-09. [Online]. Available:
http://fc17.ifca.ai/wtsc/Vitalik%20Malta.pdf

10

Authorized licensed use limited to: IEEE Xplore. Downloaded on July 18,2020 at 04:49:28 UTC from IEEE Xplore. Restrictions apply.