Security_evaluation_of_smart_contract_based_Ethereum_wallets_NSSCamera_ready_Copy_.pdf

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/347742300
Security Evaluation of Smart Contract-Based On-chain Ethereum Wallets
Chapter · December 2020
DOI: 10.1007/978-3-030-65745-1_2
CITATIONS
6
READS
760
3 authors, including:
Some of the authors of this publication are also working on these related projects:
Identifying the security issues in blockchain technology and smart contracts View project
Purathani Praitheeshan
Deakin University
6 PUBLICATIONS 16 CITATIONS
SEE PROFILE
All content following this page was uploaded by Purathani Praitheeshan on 26 March 2021.
The user has requested enhancement of the downloaded file.

Security Evaluation of Smart Contract-based
On-chain Ethereum Wallets
Purathani Praitheeshan1[0000−0003−0569−9925]
, Lei Pan1[0000−0002−4691−8330]
,
and Robin Doss1[0000−0001−6143−6850]
School of IT, Deakin University, Geelong, VIC, 3220, Australia
Email: {ppraithe, l.pan, robin.doss}@deakin.edu.au
Abstract. Ethereum is a leading blockchain platform that supports de-
centralised applications (Dapps) using smart contract programs. It exe-
cutes cryptocurrency transactions between user accounts or smart con-
tract accounts. Wallets are utilised to integrate with Dapps to manage
and hold users’ transactions and private keys securely and effectively.
Ethereum wallets are available in different forms, and we especially ex-
amine on-chain smart contract wallets to measure their safeness prop-
erty. We have conducted an exploratory study on 86 distinct bytecode
versions of Ethereum smart contract wallets and analysed them using
four popular security scanning tools. We have identified that, on aver-
age, 10.2% of on-chain wallets on the Ethereum platform are vulnerable
to different problems. We propose a novel analysis framework to classify
the security problems in smart contract wallets using the experimental
data. Most of the vulnerabilities detected from smart contract wallets are
related to security issues in programming code and interaction with ex-
ternal sources. Our experimental results and analysis data are available
at https://github.com/ppraithe/on-chain-wallet-contracts.
Keywords: On-chain Wallet · Security · Smart contract · Vulnerability
1 Introduction
Ethereum is a fast-evolving blockchain platform for cryptocurrency transactions
with the support of wallets and decentralized applications [1,25]. The current
market value of Ethereum is around 44.5 billion USD, according to the statis-
tics provided by CoinMarketCap1
in August, 2020. Ethereum’s cryptocurrency
denomination is called Ether or ETH for short. Losing an Ether is a significant
financial loss as Ether’s price varies between 150 and 350 USD during the past
a few months2
. Most Ethers are held in Ethereum wallets. These wallets are
in different forms, including on-chain contract wallets, desktop wallets, mobile
wallets, browser extensions, web-based wallets, hardware wallets, paper wallets,
and software wallets. On-chain wallets are implemented in smart contracts that
are a script type of programming code running on the Ethereum platform [1,6].
1
https://coinmarketcap.com/currencies/ethereum/
2
https://ethereumprice.org

2 P. Praitheeshan et al.
Smart contract programs are used to implement wallet functions and business
logic. Users need to deploy the smart contract wallet on Ethereum blockchain
and process their cryptocurrency transactions with other user accounts or con-
tract accounts. Contract types of wallets are more convenient and trustful since
they run on Ethereum blockchain, and they are immutable once they deployed
to the chain. However, security vulnerabilities in smart contract wallets have not
been extensively analyzed.
This paper empirically studies the existing on-chain smart contract wallets
on the Ethereum platform using popular security analysis tools. We choose the
on-chain wallet contracts in our study to compute the security measures in smart
contracts wallets running on Ethereum and identify reliable wallets to manage
crypto assets safely. The Ethereum contract wallets interact with several compo-
nents such as Dapps, contract libraries, third-party libraries, APIs, key manage-
ment applications, smart contract accounts, and real user accounts on Ethereum
[10]. Figure 3 in Appendix A, illustrates the inter-playing components with smart
contract wallets on Ethereum. The wallet contracts call external libraries, ac-
counts, and third-party web services through oracle interfaces. Decentralized
applications utilize these contract wallets to govern their token/cryptocurrency
transactions and private/public key management. These external linkages with
the smart contract wallets cause security problems. Smart contract-based wal-
lets rely on the program logic written in Solidity or Vyper languages [6,12].
Potential vulnerabilities in wallet contracts are identified related to imperfect
coding practices and issues in programming language designs.
Due to the immutable feature in smart contract wallets, they are required
to be implemented securely, and developers need to guarantee the reliability
of the wallet contract source code. The wallet users do not know how these
smart contract wallets are implemented and functioning on Ethereum. There is
a research gap of finding state of the art on Ethereum on-chain wallet functions,
existing vulnerabilities on wallet contracts, and available remedies or solutions
to prevent on-chain wallets from attackers. To bridge these missing pieces of
research, we investigated 86 distinct versions of smart contract wallets from the
Ethereum platform3
and scanned them using security analysis tools [9] to detect
any critical vulnerabilities. Our contribution to this research are:
– Analyzing the state of the art security issues and attacks on Ethereum wallet
contracts
– Proposing a new security analysis framework to classify the potential security
issues existing in on-chain wallet contracts and how each element in the
framework impacts
– Empirically evaluating the security vulnerabilities on collected data set of
smart contract wallets using popular scanning tools.
The remainder of the paper is organized as follows. Section 2 is explaining
background information about on-chain wallet contracts, major functionalities,
the literature of recent attacks on on-chain wallets, and proper analysis tools for
3
https://www.ethereum.org/

Security Evaluation of Smart Contract-based On-chain Ethereum Wallets 3
scanning smart contract wallets. A new framework is presented in 3 to describe
how we conducted the qualitative analysis of existing wallet contracts to identify
potential security issues. Section 4 describes experiments, results, and discussion
based on our evaluation data and solutions from GitHub smart contract develop-
ers, and Ethereum stack exchange communities. Section 5 concludes the paper.
2 Related Work
Ethereum wallets carry valuable assets, access credentials of user accounts, and
transaction data. Therefore, adversaries are keen to attack, especially on-chain
wallets that operate using the execution of smart contract programs. Smart con-
tract programs are implemented using script-type languages [18], including Solid-
ity, Vyper, and Bamboo. Solidity is the first language used to develop Ethereum
smart contract wallets. Our analysis mainly focuses on the wallets implemented
using solidity programming. The business rules in on-chain wallets are imple-
mented on a smart contract program and compiled to an executable byte code
using a solidity compiler (Solc). The compiled byte code is deployed to Ethereum
Virtual Machine (EVM) by the owner of the wallet contract [6]. The EVM cre-
ates an abstraction to execute the smart contract bytecode on the Ethereum
network. The smart contract functions are invoked by a user with his private
signature or key to run the required operation. The deployed smart contract
wallets cannot be modified, and they are immutable. They are required to be
implemented using best practices and security measures on solidity program-
ming [7]. Smart contract developers have to be aware of the issues on on-chain
wallet contracts during their implementation phase.
2.1 On-chain smart contract wallets on Ethereum
We collected 20 distinct smart contract wallets and their available versions from
Etherescan explorer4
. At least one version has both solidity source code and
bytecode. Most of the deployed wallet instances have their compiled bytecode
generated during their creation time on Ethereum blockchain. We classified them
into four categories based on their behaviours and functionalities: Multisig wal-
lets, Smart wallets, Retailer wallets, and Controller wallets, as listed in Table
1.
Multisig wallets use external Parity library functions to execute critical op-
erations. Smart wallets call functions from SmartWalletLibrary contract. These
wallet contracts can call an external function from another contract or library.
This feature is facilitating to re-use the existing smart contract or library func-
tions to fulfill any specific requirements. Retailer wallets deal with tokens and
ether transactions for buying, selling, transferring, mining, trading, and with-
drawing operations. Controller wallets are managing transaction logs, time-
locked events, token balance updates, and proxy logic implementations. Further,
4
https://etherscan.io/

Table 1. Four on-chain smart contracts wallet categories
Multisig Wallets Smart Wallets Retailer Wallets Controller Wallets
MultiSigWallet SmartWallet ConsumerWallet Controller
BitgoMultisig DapperSmart SpendableWallet TimeLocked
IvtMultiSig ArgentSmart BasicWallet Intermediate
NiftyMultiSig AutoWallet Teambrella EidooUpdate
CapitalMultisig GenosisSafe BitgoForwarder LogicProxy
these wallets hold and control users’ cryptographic keys [21]. Decentralized appli-
cations (Dapp) utilize these Ethereum wallets as an external service component
to manage their users’ private/public key pairs.
2.2 Security attacks on on-chain wallet contracts
Smart contract wallets invoke external resources such as the existing library,
other smart contract functions, API calls, and third-party services, they are vul-
nerable due to programming issues, human errors, and malicious hacks [5]. Sev-
eral smart contract vulnerabilities are identified by researchers and ranked them
according to critical issues. A few of them are most relevant to the wallet con-
tracts, including unsecured fund, destroyable smart contracts, lock fund forever,
non-restricted write operation, non-restricted fund transfer, integer overflow, in-
teger underflow, re-entrance and external call problems [2,20]. These vulnerabil-
ities caused real hacks on smart contract wallets in recent years, and attackers
were benefited by stealing a massive amount of Ethers.
The first parity multi-sig wallet attack happened in July 2017, and attack-
ers had stolen approximately 30M USD worth of Ethers from multi-sig wallet
accounts [8,17]. The severe problem in the wallet contract code was allowing
non-restricted to write and transfer operations. In solidity programming, there
are pre-defined access modifiers that are public, private, external, and inter-
nal. If a function has not been specified to any access modifier, that would be
considered the public function, and any external source can access the method
without any restriction. In parity multi-sig attack, the wallet library contract
had a method called initWallet that was not assigned to any access modifier
[2,8,20]. That means the method had open access to call by any external ac-
counts. The initWallet method is used to initialize the multi-sig wallet with the
number of user addresses who need to sign and confirm a transaction. It also
set the daily limit that allowed before confirmation of the transaction. When a
multi-sig wallet contract calls the initWallet function from the library contract,
it does not check any user accessibility since it is a public method. Thus, this was
a critical attack vector in the parity multi-sig wallet problem. Hackers were able
to set their account addresses to sign/confirm the transactions through initWal-
let method and freely transferred out all the money in the wallet contract. They
have accessed the initialisation function with no restriction and easily acquired
the ownership of the wallet contract.

The second attack occurred in November 2017, due to a critical vulnerabil-
ity in the parity multi-sig wallet5
. The multi-sig wallet calls library contract
functions for essential operations such as withdraw funds, deposit funds, and
assign ownership. The attacker was able to claim the ownership using the public
function initWallet to his address. Once he received the library contract’s own-
ership control, he had the right to kill the library contract instance. The parity
library contract was killed, and all the multi-sig wallet contracts were unable to
access the library functions. Since then, the multi-sig wallets were useless, and
all the funds reserved in the contracts were frozen. Around 150M USD value of
cryptocurrency was frozen, and account holders could not withdraw their funds.
2.3 Security analysis tools for smart contract wallets
Since smart contracts are computerised programs developed by humans, con-
siderable risks are caused by human errors and programming issues. The im-
mutability nature in Ethereum blockchain prevents deployed smart contracts
from malicious modification and manipulations. However, this feature restricts
the smart contract owners or actual developers to change their code after the
deployment. If they find any errors in their active smart contracts on Ethereum,
they cannot correct them while running on the blockchain. Therefore, developers
need to implement and test smart contracts carefully to make them accurate and
error-free. Researchers are eager to study and proposed several security analysis
frameworks and tools for evaluating smart contract programs. In [20], a compre-
hensive list of tools is reviewed and compared. We selected four relevant tools,
including Oyente [14], Osiris [23], Mythril [15], and Maian [16].
Table 2. Key Vulnerabilities and Analysis tools
Key Vulnerabilities Security Analysis Tools
Parity multisig bug Oyente
Call stack depth limitation Oyente, Osiris
Integer underflow Oyente, Osiris
Integer overflow Oyente, Osiris
Transaction ordering dependency Oyente, Osiris
Timestamp dependency Oyente, Osiris
Re-entrancy bug Oyente, Osiris
Arithmetic bugs Osiris
Delegate call to a user-specified address Mythril
Environment variable dependency Mythril
External call to another contract Mythril
Multiple external calls in same transaction Mythril
Contract can be killed by any account Mythril, Maian
Lock fund forever (greedy contracts) Mythril, Maian
Leak fund or allow withdrawal by arbitrary user Mythril, Maian
5
https://cointelegraph.com/news/parity-multisig-wallet-hacked-or-how-come

The four tools that we chose to scan the on-chain wallet contracts based on
their vulnerabilities detection. These tools mainly analyse the vulnerabilities in
wallet contracts such as integer related operations, external function calls, call-
stack depth limitation, miss-handled exceptions, arithmetic issues, and trans-
action ordering dependencies. Table 2 lists 15 critical vulnerabilities that exist
in on-chain smart contract wallets and suitable tools to detect them with low
false positives. We scanned all the versions of wallets’ bytecode using four tools,
including Oyente, Osiris, Mythril, and Maian. The analysis results from these
tools on our collected wallet contracts, are provided and discussed in Section 4.
Many open-sourced tools are available to analyse either smart contract solid-
ity source code or bytecode or contract address at Ethereum blockchain. Since
all the smart contract wallets do not publish their verified solidity code at Ether-
Scan, our experiments were conducted by feeding the bytecode of wallet contracts
to the selected analysis tools. The compiled bytecode can be downloaded from
the EtherScan explorer for all smart contract wallets. The wallet contracts with
verified solidity source code in EtherScan, were required to correct many compi-
lation errors before they can be scanned using any tools. Parity multi-sig wallet
bug is detected by Oyente. Osiris especially detects a range of arithmetic bugs
that is most important to check in all smart contract wallets. Mythril is one of
the powerful tools that scans for 14 different vulnerabilities that are most rele-
vant to solidity programming issues. Maian analyses the wallet contracts using
the transaction tracing method and finding issues related to the parity multi-sig
wallet attack such as leak fund, lock fund, and suicidal contract.
Smart contracts are implemented not only for on-chain wallets but also for
several reasons such as the development of decentralised applications, interme-
diaries for retailing, banking and supply chain management, trustful storage
element, and monitoring agent. Therefore, a range of security analysis tools,
frameworks, and proposals are developed by research communities in recent
years [11,13,14,15,16,22,23,24] for detecting and resolving existing vulnerabili-
ties on smart contracts. A research study on Ethereum wallet contracts, focused
on characteristics of on-chain wallets by grouping them into six types with re-
gards to their functionalities [7]. They have analysed using wallet’s transaction
data to provide the temporal perspectives of smart contract wallets on Ethereum
blockchain. The TokenScope tool [4] was implemented to detect inconsistent be-
haviors of cryptocurrency tokens in Ethereum. It inspects the transactions sent
to the deployed tokens and triggers inconsistency in token contracts with regard
to the ERC-20 token standard. However, no vulnerability analysis is conducted,
especially on Ethereum wallet contracts. In this work, we have done security
scanning and analysis using our new analysis framework to identify specific prob-
lems in smart contract wallets on Ethereum.
3 A Novel Analysis Framework
We propose our security analysis framework for qualitatively evaluate on-chain
smart contract wallets. The framework has three major components that focus

on security analysis, including solidity programming security, Ethereum Virtual
Machine security, and External sources security, as shown in Figure 1. The im-
plementation and execution of wallet contracts are mostly dependent on three
components and they are required to be controlled more securely. This section
explains how each element in this framework impacts on smart contract wallets.
Fig. 1. Security Analysis Framework for On-chain Contract Wallets
3.1 Programming Security
In programming security, we have five factors to enhance the security level of
solidity smart contract programming. Applying restrictions includes especially
to apply proper access modifiers for variables and functions. The parity multisig
attack occurred due to the use of public visibility for a critical method. The
default function visibility level in contracts is public. If a function is imple-
mented with an implicit visibility level, the compiler assumes that it has public
accessibility. It is recommended to explicitly define the access modifier for all
functions or variables in a smart contract. It would prevent unnecessary attacks
from malicious users. In the sample code in the AutoWallet.sol contract, the
transfer function is defined with implicit public visibility in line 3. The func-
tion is explicitly defined with internal access modifier in line 7.
1 // AutoWallet.sol
2 // Transfer function without access modifier
3 function transfer(address _to, uint _value) returns (bool) {
4 }
5 // Transfer function with internal access modifier

6 function transfer(address _to, uint _value) internal returns (bool) {
7 }
Before making a function call from a smart contract wallet, the user’s privi-
lege should be checked, whether he/she is an owner of the contract or authorized
person to call the function. The user who sends the transaction to execute a wal-
let contract is set as an owner by the smart contract’s constructor. When a smart
contract instance is created as written in line 5 of the Wallet.sol file, the owner’s
address is assigned to the caller’s address. The owner’s address is verified before
calling an external/internal functions by using the require keyword as specified
in line 8 of the Wallet.sol file.
1 // Wallet.sol
2 contract Wallet {
3 address owner;
4 constructor() {
5 owner = msg.sender; // assign message sender as owner
6 }
7 function transfer(address _to, uint _value) external returns (bool) {
8 require(owner == msg.sender); // verify the message sender is owner
9 require(_value <= this.balance);
10 _to.transfer(_value);
11 return true;
12 }
Handling errors in smart contract development is vital to prevent errors from
coding issues such as arithmetic bugs, out of bound problems in storage vari-
ables (array or list), access control problems, denial of services, and breaches
from external resources. If an error is thrown from a statement, it should be
handled properly using try and catch methods. The latest versions of solidity
support try-catch functionality to get back the error message from an invalid
code statement. In older versions of solidity, the errors are handled manually
by checking the return value using if-else blocks. In the SmartWallet.sol file, it
initiates the Wallet contract in line 2 and calls the transfer function of Wallet
contract in line 3. It uses a try block when it calls the transfer function, and it
returns the result inside the try block, if it is successfully executed. If it throws
an error with the reasoning in a string message, it passes the error in the first
catch block, as written in line 5–7. If the error is relevant to memory or cache,
it goes to the second catch block and returns false with printing error message
using a console statement (line 8–10).
1 // SmartWallet.sol
2 Wallet wallet; // initialise Wallet contract
3 try wallet.transfer(receiver_address, amount) returns (bool isTransfer) {
4 return (isTransfer, true);
5 } catch Error (string memory) { // throws a reason string of the error
6 console.error();
7 return(false, false);

8 } catch (bytes memory) { // throws low level data in the error
9 console.error();
10 return(false, false);
11 }
Using the best practices in smart contract implementation prevents compila-
tion and run-time errors because developers lack understanding and mistakes in
solidity coding. External calls to other contracts cause risks since the functions
in the un-trusted contract can behave maliciously to get benefit from the caller
contract. Smart contract developers have to bear in mind that such external
calls are undesirable and would make serious security risks. They are required
to follow coding recommendations and best practices to minimize or avoid the
threats in solidity programming. In the code snippet of SmartWallet.sol, it calls
an external function transfer from Wallet smart contract in line 3. If the Wal-
let contract is a malicious contract from an anonymous user, it can execute
malefic calls inside the transfer function. It is better to use clear naming for
the variables and methods when interacting with un-trusted external contracts.
1 LenderContract distrustLender; // initialise Wallet contract
2 distrustLender.borrow(borrwer_address, amount) returns (uint balance) {
3 }
This naming practice will give the developer a clear understanding that the spe-
cially named external call is unsafe, and it should have security measures when
it is executing after making a function call to a distrusted smart contract. The
re-entrancy problem in a smart contract occurs due to the external call to a
malicious contract’s function. The external contract from an attacker takes over
the program’s control flow and manipulates the victim contract. The malicious
contract calls again to the caller contract recursively, before its first invocation
completes. It is recommended to avoid state changes after a call to an external
contract. The state variables should be updated before the external call to min-
imize the loss from the re-entrancy attack. Several best practices and advanced
programming patterns are introduced by an upgraded solidity language. Since
smart contracts are immutable after their deployment, developers need to follow
secured coding standards6
during their development phase.
Wallet contracts use send() or tansfer() operations without any condition
or check on the return value. If the send or transfer operations fail to send the
Ethers to a given recipient, the sender is unaware of the status of the execution.
Their return value should be checked and continue the next program statement
if it is a success. Otherwise, it should break the program from that line and
notify the error message to the sender and receiver accounts.
Quality assurance testing is mandatory for wallet contracts after their de-
velopment phase. Test cases can be written using the Truffle framework and
run the test file to examine functionalities in each method in the smart con-
tract. It is better to do quality assurance tests by professional testers rather
6
https://consensys.github.io/smart-contract-best-practices/

doing by developers themselves. Several automation tools and test providers are
available, especially for testing smart contracts. A few examples are SoftEQ,
MagicBlockchainQA, LogiGeer, Populus, Corda Testing Tools, and EmbarkJS
framework.
Human errors occur during the contract development phase. The latest ver-
sions of the solidity compiler warn most of the programming errors in compila-
tion time. Coding mistakes are mostly relevant to making syntax errors, using
costly gas patterns, assigning improper access modifiers, and not following best
practices of programming standards.
3.2 Ethereum Virtual Machine (EVM) Security
Our framework qualitatively analyses the vulnerabilities of wallet contracts based
on the nature of EVM security as well. The call-stack depth limitation problem
was relevant to the maximum number of calls allowed for a smart contract on
the Ethereum Virtual Machine. This issue is already fixed by increasing the
operational cost for storage-related operations such as calling an internal function
for input/output operation, invoke a function from another smart contract, and
saving or retrieving data from storage variables. Hence, it is almost impossible to
reach the maximum number of call-stack depth frames (1024) due to not having
enough gas balance in a wallet contract.
Miners decide the order of transactions on Ethereum. Miners are the users
who are having more computational power to create blocks and validate transac-
tions on Ethereum. When a user sends a transaction to invoke a smart contract
function, the transaction request is submitted to the EVM transaction pool.
Then it is ordered according to the miners’ decision based on the consensus
protocol on Ethereum blockchain. Because of this feature, the users who send
transactions to Ethereum are unaware of the execution state of their submitted
transactions.
Ethereum Virtual Machine (EVM) does not handle many critical components
of its execution model, but it leaves several features on programming language
designers and depends on their manual implementation. The support of library
contracts, compatibility for richer data types, and direct enforcement on APIs,
external web services, and contract interfaces are given up to manage by Turing
complete languages. This leads to EVM’s execution environment to be expensive,
insecure, and slow. EVM needed to upgrade with advanced features that are
included in modern VMs such as java virtual machine. For example, EVM uses
a top-down execution model that loads the entire smart contract body to execute
a smart contract function. In contrast, the JVM loads only the particular name-
space or method and execute it directly.
Ethereum implements a mechanism to get charged from account holders or
transaction senders for executing costly EVM read/write operations [19], such
as SSTORE and SLOAD. There are inconsistencies in EVM in allocating gas prices
for different types of code instructions. It causes out of gas exceptions for simple
execution. Sometimes, it executes costly operations with the cheapest gas usage

[19]. The inconsistency in setting gas costs for EVM operations allows hackers
to launch DoS attacks on Ethereum [3].
3.3 External Source Security
Smart contract wallets utilize external sources such as library contracts, external
smart contract accounts, third-party libraries, and services. When they interact
with these external elements, there are high possibilities for breaching the secu-
rity of wallet contracts and hacks from malicious user accounts.
Wallet contracts use library contracts on Ethereum to access pre-defined
functions to execute basic operations. Hackers exploit the library contracts, and
the wallet contracts are becoming useless since they cannot invoke the library
functions as emerged in parity multisig attack. The use of libraries in smart
contract wallets reduces the deployment cost since the functions in the libraries
are not implemented in the contracts. However, when on-chain wallet contracts
make external calls to a library function, the execution cost is higher than com-
pared to internal function calls. This gas cost can be reduced by using an internal
modifier to the caller function that calls the external library function; it will pull
the external function into the wallet contract during the deployment.
On-chain wallet contracts acquire services through API calls and third-party
web services to complete advanced features. Many oracle interfaces are available
like oraclize and chainlink; they act as an intermediary or connector between
Ethereum smart contracts and third-party web services. Since the data from
web services are not deterministic, smart contracts cannot directly invoke API
calls7
that would breach the consensus state changing mechanism on Ethereum.
Because of blockchain’s deterministic design, single contract-level oracle services
are used to call API methods and external web services from wallet contracts.
Third-party libraries and interfaces that are used by smart contract wallets
have to be more secure and reliable. They can initiate malicious activities or
includes hacking codes when they return the data from their function. When
a smart contract wallet invokes a third-party library, it is required to verify
the external source’s security level. Moreover, the returning value should be
checked and handled the errors before executing the next line of code in the
smart contract wallet.
3.4 Research workflow using our framework components
We discussed the significant influences on security vulnerabilities of smart con-
tract wallets through our framework components. To investigate the current
state of safeness property in on-chain wallets, we scanned 86 bytecode versions
of wallet contracts and detected an average of 10.22% of wallets are vulnerable
on Ethereum platform. Figure 2 shows the workflow of how we analyze smart
contract wallets using scanning tools. If any vulnerabilities are detected from a
wallet contract, we classify them into one of the security issues in our analysis
7
https://bit.ly/2SNQK3T

Fig. 2. The workflow diagram of our security analysis of on-chain wallets
framework and evaluate them based on their severity. When all four tools do not
detect any vulnerabilities from a wallet contract bytecode, the wallet is regarded
as safe.
4 Evaluation and Discussion
4.1 Experiment Setups and Results
We collected 20 different smart contract wallets and multiple versions of byte-
code and verified solidity source code from the EtherScan explorer. Because the
solidity source code of wallet contracts threw several compilation errors during
their scanning process, we prioritised to bytecode analysis on smart contract
wallets. In total, we collected 54 different versions of wallets’ bytecode and 31
solidity source codes. All 20 smart contract wallets, their main contract names,
and the number of contract versions in bytecode and solidity code are listed in
Table 7 in Appendix B. Our whole set of data on wallet contracts and their scan-
ning results using security analysis tools are available at our GitHub repository8
for readers’ reference.
We set up a docker environment to execute various tools. We pulled the
latest docker images of Oyente, Osiris, Maian, and Mythril tools. Each docker
container has configured with required dependencies, including Python, Solidity
compiler Solc, Z3 theorem prover, Web3 library, Go Ethereum client Geth, and
other external libraries to run the tools with accuracy and error-free.
During the bytecode analysis using the Oyente tool, it detected the call-stack
depth issue in three wallets: AutoWallet, ConsumerWallet, and NiftyMultiSig-
Wallet. Table 3 lists the scanning result from Oyente with wallet version number,
scanned vulnerabilities, and the percentage of EVM coverage. EVM coverage
means how much opcodes are executed by Oyente out of the total number of
opcodes available in a contract. Oyente returned EVM coverage in the range
between 0% to 25% while analyzing smart contracts’ bytecode. These vulner-
abilities are classified into the EVM security issues’ component of our analysis
framework.
8
https://github.com/ppraithe/on-chain-wallet-contracts

Table 3. Scanning results from the Oyente analysis tool
On-chain-
Wallets
Version Call-
stack
TOD Time-
stamp
Re-
entrancy
EVM
coverage
AutoWallet v1 Yes No No No 9.9%
ConsumerWallet v7 Yes No No No 0.3%
NiftyMultiSig v1 Yes No No No 5%
Table 4. Scanning results from the Osiris analysis tool
On-chain-
Wallets
Version Arith-
metic
Call-
stack
Con-
currency
Time-
stamp
EVM-
coverage
AutoWallet v1 No Yes No No 10.2%
ConsumerWallet v4 No Yes No No 4.8%
NiftyMultiSig v1 No Yes No No 6.6%
TeambrellaWallet v1 No Yes No No 2.9%
ControllerWallet v1 No Yes No No 9.2%
Osiris detected the call-stack depth vulnerability in five different wallet con-
tracts, including AutoWallet, ConsumerWallet, NiftyMultiSigWallet, Teambrella-
Wallet, and ControllerWallet. Four versions of ConsumerWallet are vulnerable
to call-stack depth problem. EVM coverage from the Osiris tool is between 0%
to 25%. The vulnerable contracts detected from the Osiris tool are presented in
Table 4. In addition, the call-stack depth issue is under the category of EVM
security issue in our qualitative framework.
Four wallet contracts are detected by Maian as greedy contracts that can lock
Ether balance infinitely. The greedy contracts cannot release funds to anyone,
and the Ethers would be frozen as occurred in the parity-multisig wallet attack
[17]. AutoWallet, three versions of MultiSigWallet, three versions of BitgoMulti-
SigWallet, and TimbrellaWallet are detected as greedy contracts from the Maian
tool. Maian returns their bytecode lengths. TeambrellaWallet has a lengthy con-
tract code among these vulnerable wallets. Table 5 lists the security analysis
results of vulnerable wallet contracts scanned from the Maian tool. Using im-
proper access modifiers for functions in the library contracts causes to lock the
fund in smart contract wallets. This vulnerability belongs to the programming
security issues in our analysis model.
The Mythril tool detects 14 different types of smart contract programming
bugs, including 1) Caller can redirect execution to arbitrary bytecode locations,
2) Caller can write to arbitrary storage locations, 3) Delegate call to a user-
specified address, 4) Control flow depending on a predictable environment vari-
able, 5) Control flow depends on Origin of a transaction, 6) Any sender can
withdraw ETH from the contract account, 7) Assertion violation, 8) External
call to another contract, 9) Integer overflow or underflow, 10) Multiple external

Table 5. Scanning results from the Maian analysis tool
On-chain-Wallets Version Suicidal
Contract
Prodegal
Contract
Greedy
Contract
Bytecode
length
AutoWallet v1 No No Yes 4542
MultiSigWallet v1 No No Yes 6922
BitgoMultiSigWallet v1 No No Yes 4106
TeambrellaWallet v1 No No Yes 10644
Table 6. Scanning results from Mythril analysis tool
On-chain-Wallets Version Vulnerabilities
(Number)
EVM-
coverage
Execution
Time (s)
AutoWallet v1 3, 10, 11 51.62% 351.34
SmartWallet v4 7 89.62% 21.13
TimeLockedWallet v2 3, 4, 10 98.69% 33.33
BitgoMultiSig v1 1 47.09% 1482.57
TeambrellaWallet v1 7 33.45% 572.32
ControllerWallet v1 7 49.01% 8.59
calls in the same transaction, 11) State change after an external call, 12) Con-
tract can be accidentally killed by anyone, 13) Return value of an external call
is not checked, and 14) A user-defined assertion has been triggered.
Mythril detected seven vulnerable on-chain wallet contracts — AutoWallet,
SmartWallet, ConsumerWallet, TimeLockedWallet, BitgoMultiSigWallet, Team-
brellaWallet, and IntermediateWallet. Six versions of BitgoMultiSig wallets are
detected as vulnerable to assertion violations and arbitrary redirection. Table
6 lists the information about detected vulnerable wallet contracts by Mythril,
contract versions, their existing vulnerabilities, and execution time. The vulner-
ability numbers are mapped to the numbering in the above list of bugs that
are detecting by Mythril. Compared to other tools, Mythril’s EVM coverage
(between 30% and 99%) is better than other analysis tools.
4.2 Discussion
The major problems identified in our dataset of smart contract wallets are call-
stack depth issue, lock fund infinitely (greedy contracts), delegate call prob-
lem, state change after an external call, assertion violation problem, and use

of predictable environment variables. As discussed in our analysis framework,
they can mitigate by taking proper security measures on smart contract wal-
let development. We have surveyed the questions and answers from Ethereum
StackExchange9
posts related to smart contracts’ vulnerabilities. Possible fixes
and solutions are proposed by experienced smart contract developers and by
Ethereum GitHub developers.
The call-stack depth problem is related to Ethereum Virtual Machine im-
plementation. EVM has configured the call stack depth limit to 1,024 frames
[1,14]. If a smart contract calls another contract using send() method or call()
method, the call-stack depth is increasing by one. Applying child gas restriction
for external calls prevents them from reaching the maximal call-stack depth to
1,024.
Smart contract wallets are exploited by claiming ownership of the contract
to lock the fund infinitely due to improper coding. The frozen contracts are
identified by the Maian tool as greedy contracts. Since the smart contract wallets
are backward-incompatible, they need to be developed cautiously and tested
before their deployment on the Ethereum platform. This vulnerability can be
prevented using restricted access modifiers for key functions, including state
variable initialization and multiple ownerships assigned to users.
Mythril [15] detected the problem regarding deligatecall to a user-specified
address in TimeLockedWallet contracts. The specified address can be an un-
trusted callee who may execute malicious functions to harm the caller contract.
It is recommended to check whether the target address used in delegatecall
is in the allow-list of trusted contracts [15].
External calls in smart contract wallets stimulate recursive calls from the
fallback function of a callee contract. It is dangerous to update a state variable
value immediately after an external call statement. If the external call re-entered
the same function call and checked the value of a state variable, it will succeed
in continuing the execution since the state variable has not been updated yet.
Therefore, it is best practice to commit any value updates of state variables
before invoking an external call.
Smart contract wallets use the assert function to evaluate if a statement
is always true for given in-variants. If an assertion is reachable, then there is a
bug in a wallet contract for allowing to enter an improper state. BitgoMultisig-
Wallet, SmartWallet, TimbrellaWallet, and ControllerWallet are vulnerable to
the assertion violation problem, as shown in Table 6 listing Mythril’s detection
results.
In our experiments, we discovered that the vulnerabilities detected in the
older versions had been fixed in most latest versions of wallet contracts. For
example, versions 1, 2, and 3 of MultisigWallet have detected as greedy contracts.
But the latest versions of MultisigWallet have been resolved the greedy issue so
that it was not reported by the Maian tool. The call-stack depth vulnerability
no longer exists on Ethereum smart contracts since it has been resolved using
9
https://ethereum.stackexchange.com/

gas cost changes for weighted input/output operations10
. However, Oyente and
Osiris detected the call-stack vulnerability in a few wallet contracts, as listed in
Tables 3 and 4.
Moreover, the solidity compiler (Solc) can notify many possible errors during
the contracts’ compilation. Wallet contract developers can resolve the compil-
ing errors using the compiler’s auto recommendations or remedies advised by
experienced GitHub developers or solutions from the stack overflow and the
Ethereum stack exchange community. Through the wallet security analysis from
four scanning tools, we investigated a considerable number of on-chain wallet
contracts vulnerable to the Ethereum platform. Mythril discovered that 20.37%
of wallet contracts bytecode are having different types of programming issues.
Maian identified that 14.8% of wallet contracts are vulnerable to the greedy issue.
Oyente detected that 5.5% of smart contract wallets are vulnerable to call-stack
depth problem. Osiris detected that 14.8% of wallets contracts are erroneous to
call stack depth limitation. Furthermore, our experiment results are manually
verified to eliminate possible false positives.
5 Conclusion
As Ethereum on-chain wallets hold the crypto-asset, transaction data, and users’
private keys, they are required to ensure well strong security to enhance the trust-
worthiness of the participants. These wallets are entirely based on immutable
smart contract programs on the Ethereum platform. This paper empirically ana-
lyzed the security issues on existing smart contract wallets using detection tools
such as Oyente, Osiris, Maian, and Mythril. We scanned 86 wallets with multi-
ple versions, and 10.2% of them are identified as vulnerable for different issues.
With the detection result, we have classified them into the components in our
proposed framework. According to our analysis framework, we concluded that
wallet contracts on Ethereum exist with several programming issues and im-
proper interaction between external sources that breach the security of on-chain
wallets. Further, we investigated the proposed solutions for the smart contract
vulnerabilities from the discussions in stack overflow and Ethereum exchange
communities. Our findings raise awareness of wallets’ security among contract
developers and users to ensure wallets’ security level before the deployment.
References
1. Antonopoulos, A.M., Wood, G.: Mastering ethereum: building smart contracts and
dapps. O’Reilly Media (2018)
2. Atzei, N., Bartoletti, M., Cimoli, T.: A survey of attacks on ethereum smart con-
tracts (sok). In: Proceedings of the International Conference on Principles of Se-
curity and Trust. pp. 164–186. Springer (2017)
10
https://bit.ly/33PQeZo

3. Chen, T., Li, X., Wang, Y., Chen, J., Li, Z., Luo, X., Au, M.H., Zhang, X.: An adap-
tive gas cost mechanism for ethereum to defend against under-priced dos attacks.
In: International Conference on Information Security Practice and Experience. pp.
3–24. Springer (2017)
4. Chen, T., Zhang, Y., Li, Z., Luo, X., Wang, T., Cao, R., Xiao, X., Zhang, X.: To-
kenscope: Automatically detecting inconsistent behaviors of cryptocurrency tokens
in ethereum. In: Proceedings of the 2019 ACM SIGSAC Conference on Computer
and Communications Security. pp. 1503–1520 (2019)
5. Cheng, Z., Hou, X., Li, R., Zhou, Y., Luo, X., Li, J., Ren, K.: Towards a first step
to understand the cryptocurrency stealing attack on ethereum. In: Proceedings of
the 22nd international Symposium on research in Attacks, Intrusions and Defenses
(RAID 2019). pp. 47–60 (2019)
6. Dannen, C.: Introducing Ethereum and solidity. Springer (2017)
7. Delmolino, K., Arnett, M., Kosba, A., Miller, A., Shi, E.: Step by step towards
creating a safe smart contract: Lessons and insights from a cryptocurrency lab. In:
Proceedings of the International Conference on Financial Cryptography and Data
Security. pp. 79–94. Springer (2016)
8. Destefanis, G., Marchesi, M., Ortu, M., Tonelli, R., Bracciali, A., Hierons, R.:
Smart contracts vulnerabilities: a call for blockchain software engineering? In:
Proceedings of the 2018 International Workshop on Blockchain Oriented Software
Engineering (IWBOSE). pp. 19–25 (2018)
9. Di Angelo, M., Salzer, G.: A survey of tools for analyzing ethereum smart contracts.
In: Proceedings of the 2019 IEEE International Conference on Decentralized Ap-
plications and Infrastructures (DAPPCON). pp. 69–78. IEEE (2019)
10. Di Angelo, M., Salzer, G.: Characteristics of wallet contracts on ethereum. In:
Proceedings of the 2020 IEEE International Conference on Blockchain and Cryp-
tocurrency (ICBC ’20). pp. 1–2. IEEE (2020)
11. Feist, J., Grieco, G., Groce, A.: Slither: a static analysis framework for smart
contracts. In: Proceedings of the 2019 IEEE/ACM 2nd International Workshop on
Emerging Trends in Software Engineering for Blockchain (WETSEB). pp. 8–15.
IEEE (2019)
12. Harz, D., Knottenbelt, W.: Towards safer smart contracts: A survey of languages
and verification methods. arXiv preprint arXiv:1809.09805 (2018)
13. Hildenbrandt, E., Saxena, M., Rodrigues, N., Zhu, X., Daian, P., Guth, D., Moore,
B., Park, D., Zhang, Y., Stefanescu, A., et al.: Kevm: A complete formal semantics
of the ethereum virtual machine. In: Proceedings of the 2018 IEEE 31st Computer
Security Foundations Symposium (CSF). pp. 204–217. IEEE (2018)
14. Luu, L., Chu, D.H., Olickel, H., Saxena, P., Hobor, A.: Making smart contracts
smarter. In: Proceedings of the 2016 ACM SIGSAC conference on computer and
communications security. pp. 254–269 (2016)
15. Mueller, B.: Smashing ethereum smart contracts for fun and real profit. HITB
SECCONF Amsterdam (2018)
16. Nikolić, I., Kolluri, A., Sergey, I., Saxena, P., Hobor, A.: Finding the greedy, prodi-
gal, and suicidal contracts at scale. In: Proceedings of the 34th Annual Computer
Security Applications Conference. pp. 653–663 (2018)
17. Palladino, S.: The parity wallet hack explained. July-2017.[Online]. Available:
https://blog. zeppelin. solutions/on-the-parity-wallet-multisig-hack-405a8c12e8f7
(2017)
18. Parizi, R.M., Dehghantanha, A., et al.: Smart contract programming languages on
blockchains: an empirical evaluation of usability and security. In: Proceedings of
the International Conference on Blockchain. pp. 75–91. Springer (2018)

19. Perez, D., Livshits, B.: Broken metre: Attacking resource metering in evm. arXiv
preprint arXiv:1909.07220 (2019)
20. Praitheeshan, P., Pan, L., Yu, J., Liu, J., Doss, R.: Security analysis methods on
ethereum smart contract vulnerabilities: a survey. arXiv preprint arXiv:1908.08605
(2019)
21. Praitheeshan, P., Xin, Y.W., Pan, L., Doss, R.: Attainable hacks on keystore files
in ethereum wallets—a systematic analysis. In: Proceedings of the International
Conference on Future Network Systems and Security. pp. 99–117. Springer (2019)
22. Tikhomirov, S., Voskresenskaya, E., Ivanitskiy, I., Takhaviev, R., Marchenko, E.,
Alexandrov, Y.: Smartcheck: Static analysis of ethereum smart contracts. In: Pro-
ceedings of the 1st International Workshop on Emerging Trends in Software Engi-
neering for Blockchain. pp. 9–16 (2018)
23. Torres, C.F., Schütte, J., State, R.: Osiris: Hunting for integer bugs in ethereum
smart contracts. In: Proceedings of the 34th Annual Computer Security Applica-
tions Conference. pp. 664–676 (2018)
24. Tsankov, P., Dan, A., Drachsler-Cohen, D., Gervais, A., Buenzli, F., Vechev, M.:
Securify: Practical security analysis of smart contracts. In: Proceedings of the 2018
ACM SIGSAC Conference on Computer and Communications Security. pp. 67–82
(2018)
25. Wood, G.: Ethereum: A secure decentralised generalised transaction ledger.
Ethereum project yellow paper 151, 1–32 (2014)
Appendix A Interactions of smart contract wallets
Fig. 3. Inter-playing components with Ethereum Smart Contract Wallets

Appendix B Smart contract wallets data
Table 7. On-chain wallets and source code versions
On-chain Con-
tract Wallets
Main and Sub Contract
Names
ByteCode
versions
SolidityCode
versions
MultiSigWallet MultiSigWallet 7 (v1-7) 4 (v4-7)
BitgoMultisig WalletSimple 6 (v1-6) 1 (v1)
IvtMultiSig IvtMultiSigWallet,
ERC20Interface
1 (v1) 1 (v1)
NiftyMultiSig NiftyWallet, MasterContract 1 (v1) 1 (v1)
CapitalMultisig SmartWallet 1 (v1) 1 (v1)
SmartWallet SmartWallet 6 (v1-6) 3 (v2,5,6)
DapperSmart FullWallet, CoreWallet 1 (v1) 1 (v1)
ArgentSmart Proxy 1 (v1) 1 (v1)
AutoWallet AutoWallet, Owned, ERC20,
ERC721
1 (v1) 1 (v1)
GenosisSafe GnosisSafe 1 (v1) 1 (v1)
ConsumerWallet Wallet, Ownable, ResolverBase,
Controller
7 (v1-7) 6 (v2-7)
SpendableWallet SpendableWallet, Factory, ERC20,
Ownable
6 (v1-6) 1 (v1)
BasicWallet Wallet, ERC20Basic, BasicToken 2 (v1-2) 1 (v1)
Teambrella TeambrellaWallet 1 (v1) 1 (v1)
BitgoForwarder Forwarder, FixedSupplyToken,
ForwarderTarget
1 (v1) 1 (v1)
Controller Controller, AbstractSweeper,
UserWallet, Token
1 (v1) 1 (v1)
TimeLocked TimeLockedWallet, TimeLocked-
WalletFactory, ERC20
7 (v1-7) 3 (v5-7))
Intermediate IntermediateWallet, Ownable,
ERC20Basic
1 (v1) 1 (v1)
EidooUpdate Wallet, Connector, LoggingErrors,
Token, Exchange
1 (v1) 1 (v1)
LogicProxy UserWallet, AddressRecord, User-
Auth, UserNote
1 (v1) 1 (v1)
Total 54 32
View publication stats
View publication stats

Security_evaluation_of_smart_contract_based_Ethereum_wallets_NSSCamera_ready_Copy_.pdf

More Related Content

Similar to Security_evaluation_of_smart_contract_based_Ethereum_wallets_NSSCamera_ready_Copy_.pdf (20)

Recently uploaded (20)