Conference PaperPDF Available

The SWC-based Security Analysis Tool for Smart Contract Vulnerability Detection



Smart contracts publicly deployed on blockchain have been shown to contain several vulnerabilities that users can maliciously exploit. To detect smart contract vulnerabilities as categorized in the Smart Contract Weakness Classification (SWC) standard, we propose the SWC-based Analysis Tool (SWAT). It operates by matching patterns in Solidity codes, making it easy to use and allowing any Solidity developers to conveniently check their smart contracts before deploying. We conducted experiments to compare the proposed solution against state-of-the-art tools in identifying 46 SWC registries. SWAT outperformed the existing tools in terms of the number of SWC vulnerabilities supported. Moreover, our solution is memory-efficient as it uses 44.58% less memory than other tools.
Pre-Printed Version
The SWC-based Security Analysis Tool for
Smart Contract Vulnerability Detection
Nattawat Songsom, Warodom Werapun, Jakapan Suaboot, Norrathep Rattanavipanon
{s6430621005, warodom.w,, norrathep.r}
College of Computing,
Prince of Songkla University, Phuket Campus
Abstract Smart contracts publicly deployed on
blockchain have been shown to contain several
vulnerabilities that users can maliciously exploit. To detect
smart contract vulnerabilities as categorized in the Smart
Contract Weakness Classification (SWC) standard, we
propose the SWC-based Analysis Tool (SWAT). It
operates by matching patterns in Solidity codes, making it
easy to use and allowing any Solidity developers to
conveniently check their smart contracts before deploying.
We conducted experiments to compare the proposed
solution against state-of-the-art tools in identifying 46
SWC registries. SWAT outperformed the existing tools in
terms of the number of SWC vulnerabilities supported.
Moreover, our solution is memory-efficient as it uses
44.58% less memory than other tools.
Keywords- SWC; vulnerability detection; smart contract;
exploit; blockchain
The frequency of crypto-related attacks has exploded
over recent years. Examples of those cases are the DAO
attack in June 2016 which allowed hackers to steal ~$50
million in Ethereum [1], and the Parity Wallet hack in
July 2017, in which hackers stole nearly $32 million
worth of Ethereum [2] tokens. Other notable attacks are
the Rubixi attack and the King of the Ether Throne
attack [3][4]. Since applications using smart contracts
are usually financial-related, deploying vulnerable
smart contracts could lead to a catastrophic result, as
demonstrated by many financial losses for a total of
billions of dollars in the past recent years. These
incidents indicate the importance of protecting smart
contracts against exploitation. While a vulnerable smart
contract can be fixed and redeployed [5], the upgrading
process must follow the delegate proxy pattern, which
is hard to implement. Moreover, this upgrading process
may take time, causing a window of vulnerability that
an attacker can exploit the vulnerable contract before
getting redeployed. In addition, smart contract
redeployment incurs an overhead of contract audits,
which can be cumbersome since they must be done
manually by software security analysts or security
experts. The existing smart contract analysis tools can
be categorized into static and dynamic based on their
detection technique. The static tools analyze a smart
contract without executing it. The dynamic tools, on the
other hand, require executing the contract to analyze it.
As a result, those dynamic tools often run slower than
tools that use a static analysis method. However, the
dynamic tools can reproduce the exploitation that
matches the exact scenario. Hence, the dynamic tools
support detection of more vulnerabilities than the static
tools. Unfortunately, many existing tools are ad-hoc
solutions; they do not comply with any security
standard. In particular, only a handful of either dynamic
or static tool targets vulnerabilities categorized by the
Smart Contract Weakness Classification (SWC)
standard. Nevertheless, none of them covers all
vulnerabilities in SWC [6].
Contributions of this work are summarized as
follows: (1) we propose the SWC-based Analysis Tool
(SWAT), a static analysis tool that currently covers the
detection of most smart contract weaknesses in the
SWC standard. Moreover, we benchmark memory
usage of SWAT and compare it to Slither [7] and
Mythril[8], and (2) we present a mapping of Slither and
Vandal [9] detection results to the SWC standard.
This paper is organized as follows. Section 2 reviews
the SWC standard, existing smart contract analysis
tools, and smart contract analysis tool development
methods. The proposed SWAT framework and its
implementation are presented in Section 3. Section 4
benchmarks the proposed SWAT against the state-of-
the-art and discusses the experimental results. Finally,
the paper is concluded in Section 5.
A. Smart contract Weakness Classification
While Common Weakness Enumeration (CWE) is
widely adopted in the software industry, it only
describes the weakness for generic software, and thus,
it is not specific to the Solidity code. Smart contract
Weakness Classification (SWC) is a weakness
classification system targetting specifically on the
Solidity code. It consists of 37 weaknesses, identifiers,
weakness titles, related CWE items, and test case codes
[10]. SWC can be a guideline for developing secure
smart contracts and tools.
B. The smart contract analysis tool
Several tools have been developed to analyze
Ethereum Virtual Machine (EVM) [11] based smart
contracts. They can be categorized as static and
dynamic based on their analysis methods.
Static analysis tools
These tools analyze smart contracts without
executing them. Slither is one in this category; it is
implemented using Python and its intermediate
representation called SlithIR. It works by translating the
code to Solidity Abstract Syntax Tree (AST) and its
intermediate representation to recover semantic facts.
Then it compares the facts with a list of pre-defined
analyses to detect vulnerabilities. Vandal [9] is another
static tool implemented using Python and Souffle [12].
It decompiles an EVM bytecode to its internal
representation language to recover semantic facts, then
feeds the facts to the Souffle analysis engine to detect
vulnerabilities. The aforementioned tools are open-
source. The latest version of Slither can detect 76
vulnerabilities, and the latest version of Vandal supports
detection of 6 vulnerabilities. However, Slither and
Vandal still lack the SWC standard support.
Other notable static tools include Securify [13]
implemented using Python and Souffle, and Solhint
[14] implemented using NodeJS; whereas, both Vandal
and Securify are implemented using Python and
Souffle. This paper chose Vandal as our benchmark
because it has analyzed 141k datasets of smart contracts
[9], more than Securify, which examined only 18k
smart contracts datasets [13]. Although Solhint supports
security and style analysis, it mainly focuses on style
analysis. Solhint is not widely discussed in security
analysis tool review researches compared to Vandal
[15][16][17], despite being developed before Vandal.
Therefore, this paper chooses Vandal as our benchmark.
Figure 1. Slither and Vandal results mapped to SWC
Dynamic analysis tools
In contrast to the static tools, the dynamic analysis
tools analyze a smart contract by actually executing the
contract. It leverages at least one of the following
techniques to discover vulnerabilities: symbolic/
concolic execution, taint tracking, and fuzzing. For
instance, Mythril uses concolic analysis [18], taint
analysis, and control flow checking to detect various
security vulnerabilities [7]. Oyente [19] is one of the
first tools that used symbolic execution to analyze smart
contracts. These tools (i.e., [8], [19] and [20]) are open-
source. In comparison, Mythril has its paid version
called MythX [20]. Mythril and MythX are developed
with Python, while Oyente is implemented using
JavaScript. The latest version of Mythril supports
detection of 14 SWC vulnerabilities [6], the latest
version of MythX supports detection of 46 SWC
vulnerabilities, and the newest version of Oyente
supports detection of 7 SWC vulnerabilities. While
Mythril and Mythx are based on the SWC standard, they
do not support all vulnerabilities in the SWC standard.
Other notable dynamic analysis tools include Edchidna
[21], which works by fuzzing the contract, and
Manticore [22], which uses symbolic execution.
We chose three state-of-the-art tools, Slither [7],
Mythril, and Vandal [9], as benchmarks. The reasons
are based on two criteria. Firstly, the tool must use a
static analysis like our proposed work. Slither and
Vandal fit this criterion. The second criterion is that the
tool must support the SWC standard. Mythril and
MythX fit this criterion, but we can only experiment
using Mythril because the latter is not open-source.
Since Slither and Vandal do not support the SWC
standard, we map their detection results to SWC
vulnerabilities such that we can compare their results
with SWAT. This mapping is depicted in Figure 1.
SWAT is a static analysis framework that aims to
detect SWC vulnerabilities in smart contract code. In this
section, we describe the architecture and implementation
examples of the proposed framework.
Figure 2. Overview of the SWAT architecture
Figure 2 illustrates the architecture overview of
SWAT. It takes the Solidity code as the input and
outputs vulnerable parts in the Solidity code. SWAT
follows a modular design. It consists of 3 main
components: (1) Core Analysis, (2) Validator, and (3)
Visualizer. The Core Analysis is where we implement
our detection system. The Validator is responsible for
filtering false-positive results, and the Visualizer is a
report generator.
A. Implementation
SWAT analyzes Solidity code using a pattern
matching technique. In this paper, we focus on detecting
the following vulnerabilities in Solidity code, namely
SWC-100, SWC-102-104, SWC-111, SWC-129, and
SWC-134, detailed as follows.
a) SWC-100 function default visibility
A function without function visibility, as shown in
Figure 3, is a public function by default. It executes
transfer() of the contract balance to the caller. Given
that the function was intended to be called by only
internal functions, this contract is vulnerable to
malicious attacks, where an external user can directly
call this function and drain all tokens or coins from the
contract wallet. This can lead to unintended or
unauthorized access by malicious users [9].
1 function _sendWinnings() {
2 msg.sender.transfer(this.balance);
3 }
Figure 3. Solidity code with default function visibility declaration
1 function _sendWinnings() internal {
2 msg.sender.transfer(this.balance);
3 }
Figure 4. Solidity code with explicit function visibility declaration
The correct implementation of this function is to
explicitly declare function visibility as internal, as
depicted in Figure 4. Our implementation uses regular
expression [23] to detect the visibility of all functions
for handling this vulnerability. In other words, the smart
contract is flagged as vulnerable if no function visibility
is declared.
b) SWC-102 Outdated Compiler Version
Solidity compiler uses semantic versioning, a
widely adopted version scheme [24]. An outdated
compiler version could be left exposed to previously
disclosed vulnerabilities such as integer overflow and
underflow. Solidity 0.8 now has a built-in overflow
checking [25], which means using a Solidity compiler
older than version 0.8.0 is vulnerable. A regular
expression is used to detect the outdated version of the
Solidity compiler to identify this issue. If the pattern
matches, the current major version is considered
outdated and SWAT marks this contract vulnerable.
c) SWC-103 Floating Pragma
Using floating pragma means the contract is
compiled with flexible compiler versions. This could
introduce nondeterministic behaviors potentially
leading to a vulnerability. Therefore, to be secure,
contracts should be compiled with a specific compiler
version [6].To detect this weakness, we use a regular
expression to search for the circumflex accent (^) in the
pragma version. If the pattern matched, we consider the
pragma version floating, and the contract is considered
d) SWC-111 Use of Deprecated Solidity Functions
Several functions and operators in Solidity are
deprecated. Continuing to use them may result in
unexpected behaviors. Solidity provides alternative
variables and functions regarding the deprecated
functions, exemplified in Table I. Replacing old
structures with their alternatives will not break current
e) SWC-129 Typological Error
Some operators in Solidity are resemblant. This can
lead to typographical errors if operators are not defined
correctly. For example, using =+ instead of += results
in a variable re-initialization, which can lead to
unintended behaviors in the contract. Similarly, we use
a regular expression to check for similar operators to
find this vulnerability. The incorrect operators are
detected, and the contract is deemed insecure if this
pattern is discovered.
f) SWC-134 Message call with the hardcoded gas
The transfer() and send() functions consume a
fixed amount of gas. Initially, they are designed to
prevent reentrancy attacks [26]. Nonetheless, hard forks
may change the gas cost of EVM instructions and break
deployed contracts. To detect this vulnerability, we use
a regular expression to detect the fixed gas amount. The
contract is considered vulnerable if the pattern is found
(i.e., the fixed gas amount is detected).
To evaluate SWAT, we select official experimental
test cases [10] from the SWC standard as our test dataset
and consider the following experimental factors: the
number of vulnerabilities detected and memory
consumption. We compared SWAT to Slither [7],
Mythril [8], and Vandal [9] to evaluate the number of
vulnerabilities supported. Table II shows that our tool
can detect SWC-103 and SWC-134, which were not
supported by other tools.
a. Percentage difference is compared with Slither.
To evaluate memory consumption, we compared
SWAT with Slither and Mythril. We did not compare
with Vandal because the SWAT detection result (SWC-
104) did not overlap with Vandal. As shown in Table III
and Figure 5, on average, SWAT used less memory than
other tools by 44.58%, 40.66%, and 35.84% for
detecting SWC-100, SWC-102, and SWC-111. For
SWC-129, Slither consumed less memory than our tool
by 9.85%. The memory usage of our tool to detect
SWC-103 and SWC-134 are 14.1 and 14.5 MB (Figure
5). Other tools cannot detect these vulnerabilities.
Figure 5. Memory usage comparison by vulnerabilities
This paper presents SWAT, a novel static analysis
tool for detecting smart contract vulnerabilities based
on the SWC standard using a pattern matching
technique. We demonstrated how Solidity code can be
vulnerable and how SWAT detects these issues through
examples. Moreover, we describe in detail the
implementation issue of each vulnerability.
Additionally, we mapped the detection results from
Slither and Vandal tools to the SWC standard to
compare with the proposed SWAT. From conducted
experiments, SWAT can detect 6 SWC vulnerabilities,
which is the best compared to Slither, Mythril, and
Vandal. Importantly, SWAT consumes the least
memory compared to other tools. In future work, we
will evaluate SWAT in terms of other metrics including
accuracy. Furthermore, we will develop SWAT to
support both static and dynamic analyses and cover a
wider range of SWC vulnerabilities, especially the more
complex vulnerabilities that cannot be detected using a
pattern matching technique.
[1] A. Averin and O. Averina, “Review of Blockchain Technology
Vulnerabilities and Blockchain-System Attacks,” in 2019
International Multi-Conference on Industrial Engineering and
Modern Technologies (FarEastCon), Vladivostok, Russia, Oct.
2019, pp. 16.
[2] “The Multi-sig Hack: A Postmortem.”
(accessed Jun. 15, 2022).
[3] N. Atzei, M. Bartoletti, and T. Cimoli, “A Survey of Attacks on
Ethereum Smart Contracts (SoK),” in Principles of Security
and Trust, vol. 10204, M. Maffei and M. Ryan, Eds. Berlin,
Heidelberg: Springer Berlin Heidelberg, 2017, pp. 164186.
[4] Pete Humiston, “Smart Contract Attacks [Part 2] - Ponzi Games
Gone Wrong.”
part-2-ponzi-games-gone-wrong-d5a8b1a98dd8 (accessed Jun.
10, 2022).
[5] Elena Gesheva, “Solidity 0.6.x Features: Fallback and Receive
features-fallback-and-receive-functions-69895e3ffe (accessed
Jun. 08, 2022).
[6] “Smart Contract Weakness Classification and Test Cases.” (accessed May 05, 2022).
[7] J. Feist, G. Grieco, and A. Groce, “Slither: A Static Analysis
Framework For Smart Contracts,” in 2019 IEEE/ACM 2nd
International Workshop on Emerging Trends in Software
Engineering for Blockchain (WETSEB), May 2019, pp. 815.
[8] “Mythril: a security analysis tool for ethereum smart contracts.” (accessed May
20, 2022).
[9] L. Brent et al., “Vandal: A Scalable Security Analysis
Framework for Smart Contracts.” arXiv, Sep. 11, 2018.
Accessed: May 18, 2022. [Online]. Available:
[10] J.-H. Lee, S. Yoon, and H. Lee, “SWC-based Smart Contract
Development Guide Research,” in 2022 24th International
Conference on Advanced Communication Technology
(ICACT), PyeongChang Kwangwoon_Do, Korea, Republic of,
Feb. 2022, pp. 138141.
[11] R. Norvill, B. B. F. Pontiveros, R. State, and A. Cullen, “Visual
emulation for Ethereum’s virtual machine,” in NOMS 2018 -
2018 IEEE/IFIP Network Operations and Management
Symposium, Taipei, Apr. 2018, pp. 14.
[12] X. Hu, J. Karp, D. Zhao, A. Zreika, X. Wu, and B. Scholz, “The
Choice Construct in the Souffle Language.” arXiv, Aug. 25,
2021. Accessed: Jun. 22, 2022. [Online]. Available:
[13] P. Tsankov, A. Dan, D. D. Cohen, A. Gervais, F. Buenzli, and
M. Vechev, “Securify: Practical Security Analysis of Smart
Contracts.” arXiv, Aug. 24, 2018. Accessed: Jun. 22, 2022.
[Online]. Available:
[14] “Solhint.” (accessed Jul. 06,
[15] M. di Angelo and G. Salzer, “A Survey of Tools for Analyzing
Ethereum Smart Contracts,” in 2019 IEEE International
Conference on Decentralized Applications and Infrastructures
(DAPPCON), Newark, CA, USA, Apr. 2019, pp. 6978
[16] M. Almakhour, L. Sliman, A. E. Samhat, and A. Mellouk,
“Verification of smart contracts: A survey,” Pervasive Mob.
Comput., vol. 67, p. 101227, Sep. 2020.
[17] H. Chen, M. Pendleton, L. Njilla, and S. Xu, “A Survey on
Ethereum Systems Security: Vulnerabilities, Attacks, and
Defenses,” ACM Comput. Surv., vol. 53, no. 3, pp. 143, May
[18] P. Godefroid, N. Klarlund, and K. Sen, “DART: directed
automated random testing,ACM SIGPLAN Not., vol. 40, no.
6, pp. 213223, Jun. 2005.
[19] S. Badruddoja, R. Dantu, Y. He, K. Upadhayay, and M.
Thompson, “Making Smart Contracts Smarter,” in 2021 IEEE
International Conference on Blockchain and Cryptocurrency
(ICBC), Sydney, Australia, May 2021, pp. 13.
[20] “MythX: Smart contract security service for Ethereum.” (accessed May 20, 2022).
[21] G. Grieco, W. Song, A. Cygan, J. Feist, and A. Groce,
“Echidna: effective, usable, and fast fuzzing for smart
contracts,” in Proceedings of the 29th ACM SIGSOFT
International Symposium on Software Testing and Analysis,
Virtual Event USA, Jul. 2020, pp. 557560.
[22] M. Mossberg et al., “Manticore: A User-Friendly Symbolic
Execution Framework for Binaries and Smart Contracts.”
arXiv, Nov. 18, 2019. Accessed: Jun. 22, 2022. [Online].
[23] “re Regular expression operations Python 3.10.4
(accessed May 10, 2022).
[24] P. Lam, J. Dietrich, and D. J. Pearce, “Putting the Semantics
into Semantic Versioning.” arXiv, Aug. 16, 2020. Accessed:
May 18, 2022. [Online]. Available:
[25] “Solidity v0.8.0 Breaking Changes.”
changes.html (accessed May 08, 2022).
[26] N. F. Samreen and M. H. Alalfi, “Reentrancy
Vulnerability Identification in Ethereum Smart Contracts,” in 2020
IEEE International Workshop on Blockchain Oriented Software
Engineering (IWBOSE), Feb. 2020, pp. 2229.
... (iii) Smart contract exploits: These attacks take advantage of vulnerabilities in the smart contracts that underlie DeFi platforms, allowing attackers to steal or redirect funds. For instance, the smart contract weakness classification (SWC) [23], reentrancy attack [24], front-running attack [25], and rug pull scam [26]. ...
... In response to various DeFi vulnerabilities, many risk assessment frameworks have been proposed. For instance, Songsom et al. [23] proposed an algorithm to efficiently detect vulnerabilities from smart contract codes. Pengcheng Xia et al. [33], on the other hand, devised a machine learning model that automatically labels the scam from Uniswap V2 transactions history. ...
Full-text available
Decentralized finance (DeFi) has exploded in popularity with a billion-dollar market cap. While uncollateralized lending, known as a flash loan, emerged from DeFi, it has become a primary tool used by attackers to drain investment tokens from DeFi networks. The existing countermeasures seem practical, but no comprehensive quantitative analysis framework was available to test them. This paper proposes the Flash loan Attack Analysis (FAA) framework, which aids security practitioners in understanding the DeFi system's effects on preventative methods when various factors change. The quantitative predictions can help security professionals in identifying hidden dangers and more efficiently adopting countermeasure strategies. The simulation predicts that the existing strategy, fair reserves, can fully protect the platform in a typical market environment; however, in a highly volatile market where the token price drops by 60% in a single hour, it will be broken, causing more than $8 million in damage.
Conference Paper
Full-text available
Blockchain is a relatively young technology. In recent years, blockchain has gained popularity, which keeps growing. Such interest is mainly due to cryptocurrencies, such as Bitcoin and Ethereum. This technology has presented promising prospects of application. With the increasing interest in blockchain from cryptocurrency to smart contracts, there are precedents of attacks on the blockchain platform. This, in turn, encourages consideration of blockchain in terms of security, identifying vulnerabilities and predicting the emergence of new vulnerabilities. That further would allow to find new methods and solutions for blockchain security. In this paper, the known vulnerabilities were considered, as well as the known attacks on blockchain and their successful implementations in recent times.
Conference Paper
Full-text available
Smart contracts are at the heart of many decentralized applications, encapsulating core parts of the business logic. They handle the exchange of valuable assets like crypto-currencies or tokens in a transparent, decentralized manner. Being computer programs, they are also prone to programming errors, which have already lead to spectacular losses. Therefore, methods and tools have emerged to support the development of secure smart contracts and to aid the analysis of deployed ones. Assessing the quality of such tools turns out to be difficult. There are academic tools, tools developed by companies, and community tools in open repositories, but no comprehensive survey that may serve as a guide. Most discussions of related work in research papers are not helpful either, as they concentrate on methods rather than tools, base their review on publications about the tools rather than the tools themselves, or disregard tools outside of academia. Our survey aims at filling this gap by considering tools regardless of their provenance and by installing and testing them. It is meant as a guide for those who intend to analyze already deployed code, want to develop secure smart contracts, or plan to teach a related subject. We investigate 27 tools for analyzing Ethereum smart contracts regarding availability, maturity level, methods employed, and detection of security issues.
Datalog has become a popular implementation language for solving large-scale, real world problems, including bug finders, network analysis tools, and disassemblers. These applications express complex behaviour with hundreds of relations and rules that often require a non-deterministic choice for tuples in relations to express worklist algorithms. This work is an experience report that describes the implementation of a choice construct in the Datalog engine Soufflé. With the choice construct we can express worklist algorithms such as spanning trees in a few lines of code. We highlight the differences between rule-based choice as described in prior work, and relation-based choice introduced by this work. We show that a choice construct enables certain worklist algorithms to be computed up to 10k× faster than having no choice construct.
To achieve trust and continuity in the smart contracts-based business process execution, the verification of such smart contracts is mandatory. A blockchain-based smart contract should work as intended before using it. Due to the immutable nature of blockchain, any bugs or errors will become permanent once published and could lead to huge economic losses. To avoid such problems, verification is required to check the correctness and the security of the smart contract. In this survey, we consider the smart contracts and we investigate smart contacts formal verification methods. We also investigate the security assurance for smart contracts using vulnerabilities detection methods. In this context, we provide a detailed overview of the different approaches to verify the smart contracts and we present the used methods and tools. We show a description of each method as well as its advantages and limitations and we draw several conclusions.
Blockchain technology is believed by many to be a game changer in many application domains. While the first generation of blockchain technology (i.e., Blockchain 1.0) is almost exclusively used for cryptocurrency, the second generation (i.e., Blockchain 2.0), as represented by Ethereum, is an open and decentralized platform enabling a new paradigm of computing—Decentralized Applications (DApps) running on top of blockchains. The rich applications and semantics of DApps inevitably introduce many security vulnerabilities, which have no counterparts in pure cryptocurrency systems like Bitcoin. Since Ethereum is a new, yet complex, system, it is imperative to have a systematic and comprehensive understanding on its security from a holistic perspective, which was previously unavailable in the literature. To the best of our knowledge, the present survey, which can also be used as a tutorial, fills this void. We systematize three aspects of Ethereum systems security: vulnerabilities, attacks, and defenses. We draw insights into vulnerability root causes, attack consequences, and defense capabilities, which shed light on future research directions.