{'fraction_non_alphanumeric': 0.04223848734370235, 'fraction_numerical': 0.015706007929246722, 'mean_word_length': 4.973987854251012, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 1, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 8, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
SoK: Decentralized Finance (DeFi) Incidents

—Within just four years, the blockchain-based De- centralized Finance (DeFi) ecosystem has accumulated a peak total value locked (TVL) of more than 253 billion USD. This surge in DeFi’s popularity has, unfortunately, been accompanied by many impactful incidents. According to our data, users, liquidity providers, speculators, and protocol operators suffered a total loss of at least 3 . 24 billion USD from Apr 30 , 2018 to Apr 30 , 2022 . Given the blockchain’s transparency and increasing incident frequency, two questions arise: How can we systematically measure, evaluate, and compare DeFi incidents? How can we learn from past attacks to strengthen DeFi security? In this paper, we introduce a common reference frame to systematically evaluate and compare DeFi incidents. We investigate 77 academic papers, 30 audit reports, and 181 real-world incidents. Our open data reveals several gaps between academia and the practitioners’ community. For example, few academic papers address “price oracle attacks” and “permissonless inter- actions”, while our data suggests that they are the two most frequent incident types ( 15% and 10 . 5% correspondingly). We also investigate potential defenses, and ﬁnd that: (i) 103 ( 56% ) of the attacks are not executed atomically, granting a rescue time frame for defenders; (ii) SoTA bytecode similarity analysis can at least detect 31 vulnerable/ 23 adversarial contracts; and (iii) 33 ( 15 . 3% ) of the adversaries leak potentially identiﬁable information by interacting with centralized exchanges.


I. INTRODUCTION
Blockchain-based Decentralized Finance (DeFi) ecosystem has attracted a surge in popularity since the beginning of 2020. The peak total value locked (TVL) for DeFi surpassed 253 billion USD on Dec 2, 2021, with Ethereum (145 billion, 57% TVL) and BNB Smart Chain (19.8 billion, 8% TVL) sharing the majority of DeFi's activity [1]. While DeFi certainly provides many protocols inspired by traditional finance such as cryptocurrency exchanges [2]- [4], lending platforms [5], [6], and derivatives [7], novel constructs known as flash loans [8] and atomic composable DeFi trading [9] emerged. Unfortunately, these very intertwined DeFi systems, coupled with the already well-studied vulnerability-prone smart contracts [10]- [16], broadened the threat surface of DeFi protocols. We identify that from Apr 30, 2018 to Apr 30, 2022, so-called "DeFi incidents" have accumulated to a total loss of 3.24 billion USD. Particularly exciting to interdisciplinary scholars, these harmful incidents cover a wide variety of system layers, including the network, consensus, smart contract and DeFi protocol, as well as external auxiliary services such as off-chain oracles, cross-chain bridges, centralized exchanges etc. Understanding DeFi incidents hence requires a vertical understanding of all relevant system layers and architectures. Fig. 1: Section II presents a DeFi reference frame, with a five layer system and threat model overview, allowing to categorize real-world incidents, academic works, and audit reports (cf. Section III). Section IV studies the collected DeFi incidents with statistical analysis. Section V shows how to identify adversarial and victim contracts, how to front-run adversaries, and how to trace adversarial funds. The paper concludes with a discussion in VI, related works in VII and a closure in VIII.
For the first time in history, the information security community has access to a transparent, broad, timestamped, and nonrepudiable dataset of million-dollar security-related incidents. In this work, we leverage the blockchain as an open dataset and systematize our findings with the following contributions: • DeFi Reference Frame: We provide the first framework for reasoning about DeFi system and threat models. We outline a wide spectrum of adversarial goals, assumptions, prior knowledge, capabilities, as well as common causes for potentially harmful DeFi incidents to create a standard model for related works (cf. Section II-A and II-B). • Gap Between Attackers and Defenders: We analyze 181 DeFi incidents on Ethereum and BNB Smart Chain over a time frame of four years and structure the incidents, related academic papers, and security audit reports into a comprehensive taxonomy. We discover that academia and industry practices are underdeveloped with respect to the incident cause "unsafe DeFi protocol dependencies", when compared to the practices of in-the-wild adversaries. • Incident Defense: We investigate possible defense mechanisms against DeFi incidents. We show that SoTA similarity analysis can detect vulnerable and adversarial contracts. For instance, we identify 31/23 exactly matching vulnerable/adversarial contracts (i.e., bytecode similarity score of 100%) when compared to previously known incidents. We also discover that 103 (56%) of the attacks are not executed atomically, granting a rescue time frame for defenders. • Tracing Source of Funds: By tracking pre-incident adver- DeFi is built on smart contract enabled blockchains, where auxiliary services help to ensure the overall efficiency, stability, and usability of the ecosystem. The network layer enables data transmission between and among system layers.

II. DEFI REFERENCE FRAME
Bitcoin is the first widely adopted permissionless system to allow users to send and receive financial value without the use of a third-party intermediary [17]. While Bitcoin also introduced the concept of smart contracts, more developer-friendly smart contract primitives [18] empowered the wide adoption of DeFi. DeFi currently provides a wide range of financial services such as lending/borrowing, market-making, stablecoins, pegged tokens, price oracles [19], mixing services, flash loans, decentralized portfolio managers, insurance, etc [5], [6], [8], [20], [21]. Flash loans allow traders to instantaneously request access to cryptocurrencies worth billions of USD. This is achieved through the creative use of the blockchain's transaction atomicity property, through which a loan is not granted if the loan is not paid back with the due interests. Such convenient and programmable access to substantial capital has lowered the barrier of entrance for practical DeFi traders, as well as broaden the threat surface [8]. Because permissionless blockchains such as Bitcoin and Ethereum are known to not offer anonymity, but rather pseudonymity, alternative privacypreserving blockchains emerged. These alternative blockchains break the linkability of addresses, by shuffling assets through an anonymity set. Notable solutions include ZCash which is based on zero-knowledge proofs [22], and Monero which is based on ring signatures and confidential transactions [23], [24]. Additionally, mixers operating as applications on existing blockchains emerged, such as Tornado Cash [25], Typhoon Network and AMR [26]. An extended background on DeFi, as well as a comparison to centralized finance (CeFi), is provided by related work [27]. In the following, we present a five-layer system model which is applicable to all DeFi incidents, as well as a threat model taxonomy based on various adversarial utilities, goals, knowledge, and capabilities.

A. System Model
As Figure 2 shows, our system model consists of five layers. The network layer enables data transmission between and among system layers. The blockchain consensus and smart contract layers enable financial services such as cryptocurrency trades to be performed without the use of trusted intermediaries. The protocol layer is a collection of DeFi protocols that are deployed and built on the smart contract layer. Note that on a permissionless blockchain, any DeFi user can create or deploy financial service protocols. Furthermore, DeFi protocols may rely on auxiliary services to increase the entire financial ecosystem's efficiency, stability, and usability. We proceed to introduce the key components in each layer: (i) Network Layer (NET): • Network Communication Infrastructure: A communication protocol is a set of rules that allows two or more nodes in a system to communicate over a physical medium [28]. Users must rely on communication protocols such as TCP/IP, DNS, and BGP to interact with DeFi, whether directly through their own blockchain nodes or indirectly through third-party auxiliary services. • Blockchain and Peer-to-Peer (P2P) Network: Blockchain network protocols instruct nodes on how to join, exit, and discover other nodes in the P2P network. A blockchain node may become unresponsive at any point in time, and related works observed frequent node churn [29]. Blockchain networks typically instruct each node to connect with many peers while also configuring a timeout to disconnect from non-responsive peers to ensure the network's connectivity. • Front-running as a Service (FaaS): Independent of the public blockchain P2P network, emerging centralized transaction propagation services offer an alternative option for traders to communicate to miners (e.g., Flashbots 1 , Eden network 2 , Bloxroute 3 , and Ethermine 4 ). FaaS services allow DeFi traders to submit a bundle that consists of one or more transactions directly to FaaS miners without a broadcast on the P2P network. FaaS services may in addition provide bundle-level atomic state transition 5 , where the entire bundle is either executed successfully in the exact order that the transactions are provided, or fails collectively. Furthermore, FaaS traders are required to place a single sealed bid for the priority inclusion of the entire bundle, without observing the bid from other DeFi traders (i.e., sealed-bid auction). FaaS miners prioritize transaction bundles with the highest average bid at the top of the next mined block.
(ii) Consensus Layer (CON): • Consensus Mechanism: A consensus mechanism is a faulttolerant mechanism in blockchain systems, which assist blockchain nodes to achieve the required agreement on a single data value or network state. The blockchain consensus mechanism typically consists of the following components: -A Sybil attack-resistant leader election protocol, such as Proof-of-Work (PoW) for Ethereum or Proof-of-Stake (PoS) for BNB Smart Chain; -A consensus protocol to synchronize the latest chain state (e.g., the longest chain with most difficulty); and -A CON incentive mechanism, which aims to encourage benign consensus activity. The block reward for instance, compensates every successful block appended to the main chain. Transaction fees are paid by transaction issuers to sequencers for inclusion in specific blocks and positions, and, lastly blockchain extractable value (BEV) and miner extractable value (MEV), is potential extractable revenue left untouched [9], [30]- [34]. Transaction fees are typically enforced to be paid in the native blockchain coin.
• Nodes and Their Operation Protocol: A blockchain node may be responsible for one or several tasks: (i) transaction sequencing, specifying the order of transactions within a block; (ii) block generation; (iii) data verification; and (iv) data propagation. The two common types are: -Sequencer nodes, also known as miners in PoW blockchains, or validators in PoS blockchains, capture all four of the above responsibilities. Sequencers can insert, omit and reorder transactions in blocks they generate within the scope allowed by the protocol; -Ordinary nodes only perform blockchain data propagation and may perform data verification.
(iii) Smart Contract Layer (SC): Despite the existence of different data storage structures (e.g., directed acyclic graph [35], sharding [36]- [39], etc.), SoTA smart contract enabled blockchains order their transactions as a linear sequence in order to achieve deterministic state transition [40]. In the following, we denote non-generic SC components with the asterisk mark (*). The remaining SC components are applicable to any DeFi systems.
(iv) DeFi Protocol Design Layer (PRO): • Cryptocurrency Protocols: DeFi supports a variety of asset standards, which define a common set of rules and interfaces for the transfer and approval of cryptocurrency assets (e.g., ERC-20 [44]). DeFi protocols may, however, deviate from the common standard by proposing a newer variant with domain-specific features. The Ampleforth protocol is an example of a custom asset standard, which dynamically adjusts its total token supply to maintain a stable price (i.e., stablecoins) [45]. Newer standards may remain backward compatible, while extending the feature set (e.g., ERC-777 enables the injection of state transitions, i.e., hooks, during transfer calls [46]). Note that backward-compatible standards may however violate the security assumptions of existing protocols, thus empowering novel attack vectors. • Financial Protocols: While DeFi protocols may appear inspired by traditional financial services, the blockchains' unique features (e.g., transparency, atomicity, and discrete batch transaction execution) enable novel designs. For instance, unlike CeFi, DeFi platforms are notably intertwined through atomic composability. For instance, leveraged liquidity mining protocols such as Alpha Homora [47] and Harvest Finance [48] integrate automated market makers (i.e., Uniswap [2]) and lending platforms (i.e., Compound [6]). • Protocol Layer Incentive Mechanism: DeFi protocols may introduce PRO incentive mechanisms to encourage desired user behavior. One example is the airdrop of governance tokens in exchange for providing liquidity in decentralized exchanges [49], [50] (e.g., Sushiswap 8 and Curve 9 .).
(v) Auxiliary Service Layer (AUX): Auxiliary services refer to any entity that is required or which facilitates DeFi's efficiency, but does not belong to Capability Description Knowledge C 1 NET A may control network service providers (e.g., DNS). K3 C 2

NET
A may manipulate incoming messages to deceive a node's perception of current state (e.g., eclipse attacks [51]).

NET
A may censor or delay the transmission of messages. For example in selfish mining, A may not broadcast the blocks appended to the competing chain [52].
K1 or K3 C 4 NET A may transmit transactions to miners using FaaS. K1 C 1

CON
A may fork or append on a forked chain in an attempt to catch up and overwrite the longest chain. K2 C 2

CON
A may censor mempool transaction temporarily.
K1 or K2 A may borrow, use, and return liquidity from a decentralized cryptocurrency pool within a single atomic transaction using a flash loan [8].

PRO
A may compose the state transition from multiple DeFi protocols (composability). K1 C 4

PRO
A may compose all state transitions required in one single transaction, and execute atomically. K1 C 5

PRO
A may deploy or utilise a customised contract, which mimics the function interface (i.e., abi) of one or many DeFi protocols. K1 C 1

3RD
A may compromise the wallet passphrase of specific DeFi users, operators and etc. K3   "" has access, "" cannot access, "∆" may have access.
any of the four above-mentioned system layers (i.e., NET, CON, SC, and PRO). For example, an operationally active DeFi protocol implementation may consist of: (i) front-end code; (ii) project developers realizing the protocol designs; (iii) "operators" with administrative powers, such as the privilege to deploy the code, upgrade the protocol, freeze or cease the activity of the operative DeFi protocol; (iv) off-chain oracle services which sync price data from centralized exchanges to on-chain smart contracts, etc.

B. Threat Model Taxonomy
In the following we provide a holistic view of the adversarial utilities, goals, knowledge and capabilities, to engender a common reference frame which we subsequently apply in Section III to relatively compare all observed DeFi attacks.
(i) What is a DeFi Incident: An incident refers to a series of actions that result in an unexpected financial loss to one or more of the following entities: (i) users; (ii) liquidity providers; (iii) speculators; or (iv) operators. We classify incidents into the following two types: • Attacks: An adversary, A, may exploit vulnerabilities, in an attempt to disable, delay, or alter a DeFi protocol's expected state transition. Despite the fact that vulnerabilities exist on all five system layers, DeFi vulnerabilities are most commonly found in the following three layers (cf. 2) PRO Layer Vulnerabilities may resemble financial market manipulation instead of traditional system vulnerabilities (i.e., protocol design flaws, such as unsafe external protocol dependency or interactions). Yet, the practitioners' community as well as related works [8] classify market manipulations as attacks, which necessarily require a vulnerable system or system state; and 3) AUX Layer Vulnerabilities, which includes both operational vulnerability (e.g., off-chain oracle manipulation, compromised private key, etc.) and "information asymmetry" attacks (e.g., backdoor, honeypot, phishing, etc.). Generally speaking, we observe that users may not always (or may not be able to) inspect and understand a DeFi protocol smart contract before providing financial assets, let alone evaluating its security and risks [53], [54]. As such, a user's understanding of a contract operation may be mostly based on marketing communications, rather than the factual contract source code, leading the user to unforeseen or unexpected circumstances.
• Accidents: Any incident that does not explicitly involve proactive adversaries is classified as a DeFi accident. For example, a user's fund may become permanently locked in a contract due to unintentional coding mistakes.
(ii) Adversarial Utility and Goal: Throughout this work, we assume that A is a rational agent aiming to maximize its utility. We categorize utility into the following two categories: The most common utility we find is of monetary nature. We define the monetary utility function as the total increase in market value of A's cryptocurrency asset portfolio, which A aims to maximize. • U 2 -Non-monetary: A may instead maximize non-monetary utilities, such as sense of accomplishment, or reputation. DeFi white hat hackers (also known as ethical hackers) are an example of a non-monetary adversary, as they attack in an attempt to minimize the loss from DeFi incidents.
(iii) Adversarial Knowledge: Table II differentiates between the following three types of adversarial knowledge.
• K 1 -Public: A can access public information, including: (i) Raw on-chain data such as blocks, uncle blocks, trans-actions, accounts, balances, and deployed smart contract bytecode; (ii) Raw network data, such as P2P network transactions, pending blocks, discarded stale blocks, blockchain node IP addresses, port numbers, client version strings, etc; (iii) Public side channel, such as, open-source smart contract code, social media/chat messages; (iv) Public data analysis, such as inferred network topology, estimated sequencer location, and decompiled smart contract bytecode [55]. • K 2 -Sequencer: A obtains the following information, if A is/colludes with a sequencer: (i) Pending transactions from private communication channels; (ii) Transaction ordering logic for the corresponding sequencer, including bribery preferences; (iii) Early access to block state before broadcast if the corresponding sequencer generates the next block. • K 3 -Insider: Privileged information asymmetry may occur for example if A has early access to external market prices, oracle updates, or the wallet passphrases of an operator 10 .
(iv) Adversarial Capabilities: Table I outlines the adversarial capabilities and required knowledge. Note that A with differing levels of knowledge may be able to achieve the same capability. Sequencers, for example, can control the transaction order of their generated blocks (K 2 ), whereas A without sequencer knowledge can also perform front-/back-running by competing on the public blockchain P2P network (K 1 ).

III. DATA
In this section we present our methodology to sample a dataset of "works under investigation", including research papers, security tools (i.e., intrusion detection, intrusion prevention and vulnerability detection), audit reports, and realworld incidents. We manually label which incident types each work addresses (cf . Table III and IX). Our dataset serves as the foundation for the analysis in Sections IV, V and VI.
Academic Papers: We identify relevant papers in eight of the top security, software engineering, and programming language conferences (i.e., SSP, CCS, NDSS, USENIX, ICSE, ASE, POPL, PLDI) from 2018 to 2021. Our methodology first crawls papers using Google Scholar's keyword search 11 , and then performs backward and forward reference searches to find additional relevant works. Our dataset omits: (i) papers irrelevant to DeFi, such as Bitcoin specific attacks or Monero privacy; and (ii) DeFi related papers that do not address any particular type of incidents, such as contract patching [56], model checking [57], bug bounties [58], and reverse engineering [55]. In total, our dataset captures 7 relevant surveys and SoKs, 29 security tools, and 42 attack papers. We manually label the incident types addressed in each academic paper and cross-validate our labels against the related works section. 10 See Section II-A for the definition of an operator. 11 with at least one of the following keywords: ["smart contract", "Decentralized Finance", "DeFi", "automated market maker", "AMM","decentralized exchange", "DEX", "price oracle", "miner extractable value", "MEV", "blockchain extractable value", "BEV", "Ethereum", "ETH", "BNB Smart Chain", "Binance Smart Chain", "BSC"] Audit Reports: We collect and manually inspect 30 recent public audit reports from 6 security testing companies (Beosin, PeckShild, Slowmist, Consensys, Certik, Trial of Bits). We notice that the reports collected perform manual auditing and may not explicitly disclose what the auditors examined. For example, while each of the six companies checked the common vulnerability "inconsistent access control" in at least one audit report, only 19 of the 30 (63%) audit reports explicitly state it. For reproducibility and objectiveness, we can only be certain that an audit has addressed an incident type, if it: (i) explicitly warns about the risk of a potential incident, or (ii) explicitly states that the code passed the check of an incident type. This methodology, however, leads to an underestimation of the absolute number of incident types addressed in the audit reports 12 . Note that we are only attempting to quantify whether practitioners address certain incident types less frequently than the others, and therefore this unbiased underestimation should have no significant impact on our analysis.
Incidents: Our dataset consists of 117 and 69 incidents on Ethereum and BSC respectively (in total 181 incidents) over a period of four years from Apr 30, 2018 to Apr 30, 2022. These incidents are gathered from the following three sources 13 : (i) Rekt News; (ii) Slowmist; and (iii) Cryptosec. We exclude non-DeFi incidents, such as blockchain-based gambling and gaming applications. The incidents of which we cannot identify the adversary are also excluded. We construct the following features for each of the incident: • Incident Type and Cause: We manually label the type and cause of each incident (cf . Table III for incidents taxonomy, which is further discussed in Section VI). It should be noted that we may associate one incident with multiple types or causes across multiple system layers. • Adversaries: When we can identify an incident's adversaries, we manually classify adversarial goal, knowledge, and capability based on our reference frame (cf. Section II). • Averaged Total Monetary Loss (in USD): The most perceptible impact of harm is direct monetary loss. We collect the total monetary loss reported by the aforementioned data sources, where the victim can be either users, liquidity 12 As an example, Trial of Bits does check for PRO layer incidents in other audit reports, such as sandwich in TOB-Computable-018 (https: //github.com/trailofbits/publications/blob/master/reviews/computable.pdf), replay in TOB-HERMEZ-014 (https://github.com/trailofbits/publications/blob/ master/reviews/hermez.pdf), etc., but are not included in our sampled dataset. 13 Correspondingly: (i) https://rekt.news/; (ii) https://hacked.slowmist.io/en/; and (iii) https://cryptosec.info/defi-hacks/ TABLE III: DeFi incidents taxonomy. We label the incident types that each academic paper and auditing report address. We also group the incidents that occur in the wild. Despite that this table focuses on Ethereum and BSC, we anticipate the taxonomy remains generic and thus applicable to all DeFi enabled blockchains. G -Incident type addressed; I -Incident type checked (likely with tools); J -Incident cause checked (likely with tools); H -Incident type checked (manually). Note that we can only be sure that an incident type has been addressed if an auditing report: (i) explicitly warns of the risk of a potential incident, or (ii) explicitly states that the code passed the check of an incident type. We visualize the gaps using a heat map, where a darker colour indicates a greater frequency of occurrences.   G  G  G  I I I I I I I I I I I I I I  H I I I I I I I I I I I I I I  H I I I I I I I I I I I I I I  H I I I I I I I I I I I I I I   providers, speculators, or protocol operators. When applicable, we cross-validated the loss with on-chain transaction data, and then remove sources that report incorrect loss 14 . • Cumulative Abnormal Return (CAR): CAR reflects harm by measuring how token price responds to an incident. We expect rational investors' risk aversion to information shocks will diverge the token price in the equilibrium and lead to abnormal returns (ARs) [156], [157]. We choose the capital asset pricing model (CAPM) as the benchmark for normal returns. We derive CAR with the following three steps: 1) Equation 2 fits β coefficient with the ordinary least square, where R i,t , R mkt,t , r ft denotes the token price, market price and risk-free rate 15 at tick t ∈ [T s−144 , T s ) respectively, α i is the constant, and i,t is the error term.
2) Equation 3 calculates the ARs for each tick over the is the expected return (i.e., the normal return) of token i, and t ∈ [T s , T s+144 ]. If there is no information shock, ARs would approximate zero, since they are derived with the normalβ i which is fitted within the estimation window.
3) Note that the extreme value of CAR represents the biggest anomaly of the price behavior and the change of the AR direction can be considered evidence of the (dis)appearance of an anomaly [159]- [162]. Hence, to capture the price change pattern within the appearance of anomaly, we report the adaptive CAR (i.e., minimal CAR for t ∈ [T s , T s+144 ]) in Equation 4.
• Total Value Locked (in USD): TVL is calculated as the product of the total token balance held by a protocol's smart contracts and token price in USD [163]. Greater TVL indicates greater value of assets that can be potentially compromised under DeFi incidents. We attain the pre-attack TVL for 126 incidents using DeBank 16 and DeFiLlama [1]. • Audit Status: For each incident, we manually search auditing histories from the following four sources: (i) a protocol's website; (ii) a protocol's social media and blog post (e.g., Twitter and Medium); (iii) public git repositories; (iv) a search engine (i.e., Google). We then label each incident according to the following rules: (Audited): the victim smart contract is audited prior to the incident; (Partially Audited): audits are performed before the incident, but not for the specific victim smart contract or for an older version; and (Not Audited): no audit history is found prior to the incident. • Emergency Pause, Disclosure and Reimbursement: We crawl the following three features in an attempt to measure a protocol's reactive defense: (a) Did the protocol disclose the incident within 20 days? 17 (b) Has the protocol reimbursed its users within 20 days? and (c) Did the protocol execute a circuit breaker [164] or emergency pause? We manually search for auditing histories from the following three sources: (i) public announcements on a protocol's website; (ii) a protocol's social media and blog post (e.g., Twitter and Medium); and (iii) the protocol's main discussion forum.
Limitations: Our methodology has the following limitations: • Soundness: Because our data crawling process is heavily reliant on manual labor, human errors may occur. To mitigate this limitation, we cross-validate our data with external sources whenever possible. Additionally, we conduct internal data reviews through pull requests. Each incident is reviewed by at least two paper authors before the pull request is merged. • Completeness: -Despite that Ethereum and BSC account for 77% of the total DeFi NVL (cf. Section I), incidents' features, such as adversarial behavior and deployed defense, on other DeFi enabled blockchains can differ. To ensure the paper's reproducibility, we only consider fully disclosed incidents that can be found through public sources. While incomplete, this DeFi incident dataset is the largest available collection that we are aware of. • Bias: -Our incidents dataset is gathered from three publicly sources (e.g., Rekt News, Slowmist and Peckshield). These three sources are, to our knowledge, the most extensive DeFi incident databases accessible. Unfortunately, none of these three sources explicitly document their data collection process. As a result, we are unable to evaluate whether these sources contain bias, and our dataset may therefore inherit the sampling bias from these sources 18 .

IV. ANALYSIS
A. Incident Frequency Figure 4 shows the monthly number of incidents in relation to the total monthly loss. We find that the majority of the DeFi incidents occur after late 2020, with the peak in August 2021, when nearly 600 million dollars are lost in a single month.
Despite the fact that BSC is a relatively new blockchain, it experienced 69 DeFi incidents. We discover that 29 of the BSC incidents are exploiting PRO layer design flaws. In particular, between the 19th of May and the 3rd of June 2021, we observe 18  recurring exploits on a group of forked protocols 19 . The time frame of 15 days suggests that attackers do not yet have automated tools to scan and reproduce similar incidents. Figure 5 illustrates the incident frequency per group and the involved system layer. Overall, we find that the frequency of all incident types increase over time from 3.1 per month in 2020 to 8.5 per month in the first four months of 2022 on average (2.74×). We also observe that the most common incident cause are SC Layer (42%), PRO Layer (40%), and AUX Layer (30%) vulnerabilities.

B. DeFi Protocol Types
Table IV groups the incidents that we collect based on their protocol/application type. We find that yield farming protocols and cross-chain bridges incur 44% of the total monetary loss, although their total TVL is only 20.6 million 19 PancakeBunny suffered a performance fee minting attack on May 19, 2021, where the adversary manipulated the on-chain oracle and siphoned $45M in profit. Within two weeks, the copycats Autoshark, MerlinLab and PancakeHunny were exploited in a similar fashion: the adversary (i) exploited the vulnerability of mintFor/mintForV2 function to manipulate LP token prices and (ii) used cross-chain bridge and TC to launder money.   . In addition, we observe that the distribution of vulnerabilities varies per protocol type. For example, 86% and 59% of the incidents related to stablecoins and lending involve PRO layer vulnerabilities respectively, which is significantly higher than other protocol types.

C. Structural Equation Modeling
In this section, we apply Structural Equation Modeling (SEM) [165]- [175] to test and measure causal relationships between variables (cf. Figure 6 and Table V).
• What is SEM: SEM refers to a collection of techniques to examine "latent variables" that are assumed to exist but cannot be directly observed. In more detail, SEM is a multivariate analysis technique that supports a flexible  hybrid of confirmatory factor analysis (CFA) [176]- [178] and latent structural regression [175], [179]. An SEM model encompasses two sub-models [180] (cf. Equation 5): (i) a measurement model that conducts CFA to test the hypothesized relationships between a given latent variable and its corresponding observed variables; and (ii) a structural model that performs latent structural regression to infer the causal relationships between different latent variables. where: η and y are vectors of latent and observed variables; ε and δ are independent error terms. (5) • Why SEM: The literature [181] utilized SEM to study latent variables in cyber risks. In this work, we apply similar techniques to measure the causal relationships in DeFi incidents. To this end, we do not consider approaches that are unable to support causal inference in the presence of latent variables, such as linear mixed models [182] and dimensional reduction techniques [183]. Previous literature suggests the causal Bayesian network being the best alternative to SEM. However, it requires at least 1000 samples to get a satisfactory performance. With limited samples of DeFi incidents, we consider SEM a more suitable approach. • Specification: Our model consists of four latent variables, including one endogenous/dependent variables (i.e., harm), and three exogenous/independent variables (i.e., asset, preventive defense and reactive defense). We measure one or two observed variables for each latent variable (cf.  Figure 6). • Fitness: Our model is examined using a collection of indices, including (i) the adjusted Chi-square ( χ 2 DoF ) [184]; (ii) goodness of fit index (GFI) [167]; (iii) comparative fit index (CFI) [185]; and (iv) normed fit index (NFI) [186]. The majority of indices conform to their commonly accepted value in the literature except adjusted Chi-square 23 . • Analysis: Our findings suggest that the latent variable "harm" increases with "asset exposure", which conforms with previous security research. We also find that harm decreases if the latent variable "reactive defense" increases.  [187], and ≥ 0.9 for GFI [188], CFI [189] and NFI [186]  To our surprise, the p-value for preventive defense is high (0. 21), meaning that our model does not find strong evidence to suggest preventive defense reduces harm. • Limitations: Our primary limitation is the relatively small sample size. In the event that the number of DeFi incidents increases in the future, our model should be re-evaluated and cross-validated using additional causal experiments.

D. Emergency Pause
DeFi protocols may support an emergency pause, which is analogous to circuit breakers [164] in conventional centralized exchanges. This section examines the speed at which DeFi protocols initiate an emergency pause (cf. Table VI). According to our data, 87 of the 183 victims support the emergency pause mechanism (47.5%). However, only 51 of the 87 protocols (58.6%) pause their protocol within 48 hours, and only one protocol pauses within the first hour of the incident. Our statistics suggest that DeFi protocols may not yet have justin-time intrusion detection mechanisms to identify abnormal protocol states or malicious transactions, which limits the effectiveness of an emergency pause mechanism.

E. Effectiveness of Security Audits
Section IV-C studies the influence of security audits on harm, by performing causal inference analysis (e.g., SEM) on past incidents only. In the following section, we will attempt to estimate the effectiveness of security audits.
• Additional Data Crawling To quantify the effectiveness of security audits, we perform the following steps: (i) We crawl all DeFi protocols using DeFiLama's public API [1]. Out of the 1080 protocols listed on DeFiLama, 776 are relevant to Ethereum and BNB Smart Chain. (ii) We map the DeFiLama dataset with our incident dataset and find that 56 of the 776 protocols have been exploited before Apr 30, 2022. (iii) We construct a new audit dataset by taking snapshots and merging two public databases on June 20, 2022 [190]. • Result According to our data, 4.09% of the 56 audited protocols have been attacked at least once, whereas 15.49% of the non-audited protocols have been attacked. Hence, our data indicates that a security audit can decrease the average probability of an exploit by a factor of four. Due to the relatively small sample size of only 56 matched incidents, our result can only be considered as a rough approximation.

V. INCIDENT DEFENSE A. Rescue and Incident Time Frame
In the following, we investigate the rescue and the incident time frame (cf. Figure 7). The rescue time frame is the time  Fig. 7: An adversary A can deploy a smart contract with transaction tx deploy and then initiate an incident by calling the contract with tx first . Alternatively, the adversary may directly initiate the incident with tx first in one of two ways: (i) without using a smart contract; or (ii) by batching the contract deployment and the initiation in a single transaction.  between the adversarial contract deployment (tx deploy ) and the execution time of the first malicious state transition (tx first ). While the adversarial smart contract bytecode is already publicly available in the rescue time frame, the incident has not yet occurred. As such, defensive tools can theoretically reverse engineer the contract bytecode and determine its strategy using methods such as symbolic analysis, static analysis, and fuzzing, potentially mitigating or preventing harm. To our knowledge, no such just-in-time tool exists yet, which may explain why adversaries do not batch tx deploy and tx first into a single transaction yet (cf. Figure 8). The incident time frame, is the time that elapses between the execution of the first and last harmful state transition transactions. An A may prefer to keep the incident period as short as possible to maximize the attack's success rate, which however may not always be possible due to gas constraints, protocol design, etc. Figure 8 lays out the durations of the attack and rescue time frames. We discover that 103 (56%) attacks are not executed atomically, granting a rescue time frame for defenders. PRO layer incidents have the shortest average rescue time frame duration of 1h ± 4.1. The "Formation.Fi" incident has the longest rescue time frame, lasting approximately 25 days.

B. Bytecode Similarity Analysis
In the smart contracts ecosystem, code cloning has been utilized to measure the code similarity of deployed con-  Vulnerable  100%  38  7  31  5  2  3  80%  85  26  59  50  23  27   Adversarial  100%  29  6  23  0  0  0  80%  73  23  50  31  13  18   TABLE VII: We perform bytecode similarity analysis on our incident dataset, which includes in total 173 vulnerable and 155 adversarial contracts. We identify 7 clusters of "exact match" vulnerable contracts (in total 38 vulnerable contracts), where contracts within the same cluster have a pairwise similarity score of 100%. Therefore, we infer that 38 − 7 = 31 vulnerable contracts could be detected prior to the incident by comparing with previous known vulnerable contracts. Similarly, we infer that 23 adversarial contracts could be detected by comparing with previous known attacks.
tracts [191], identify plagiarized dApps [192], and vulnerability detection [193]. In this work, we employ code cloning to quantify bytecode similarity between all exploited DeFi protocols and adversarial contracts studied in this work. Note that we choose to perform our study at the deployed bytecode level as opposed to the source code level, because smart contract developers can close-source the contract code.
Methodology: Our code cloning detection method is inspired by the works of Kiffer et al. [191] and He et al. [192]. Specifically, to group similar smart contracts, we first identify and remove the Swarm code part from the bytecodes as it is not served for execution purposes. Then, we disassemble the bytecodes and remove the PUSH instructions' arguments.
Next, similar to [191], we compute hypervectors of n-grams (n = 5) of Ethereum opcodes for each contract. In order to compare two contracts, we compute the Jaccard similarity of their respective hypervectors. Finally, to cluster smart contracts into groups, we require a similarity score greater than 80% that the previous study suggests [191] [192].
Results: Table VII presents the results of the similarity analysis. We apply the above-mentioned methodology to cluster 173 vulnerable contracts and 155 adversarial contracts in our dataset. Using a similarity score threshold of 80%, we group vulnerable and adversarial smart contracts into 26 and 23 clusters, respectively. In addition, we note that in some clusters, all contracts are associated with a single incidence.
To address more intriguing questions, such as how many comparable adversarial contracts attack different protocols (or different vulnerabilities in the same protocol), we restrict each cluster to a single contract per incident (c.f. Table VII). We manually investigate the remaining clusters to acquire additional insights. For the vulnerable contracts, the clusters contain contracts that are part of DeFi protocols with similar functionalities (e.g., bridges and yield farming applications). Additionally, the exploitation of identical contracts is nearly equal (e.g., exploiting the same issue with equivalent transactions). In contrast, for similar vulnerable contracts, the exploits are not the same, but the incident cause is typically the same.
For example, we identify two adversaries that exploit an issue on the same function in two smart contracts used as bridges, which fork the same smart contract. Specifically, although the implementation of the function is slightly different in the two contracts, both protocols introduce a vulnerability in the exact function while forking and modifying the same contract.
The most notable outcome of our similarity analysis is the identification of clusters of adversarial smart contracts that target distinct DeFi protocols with similar vulnerabilities (e.g., oracle manipulation). An analysis of historical blockchain data could reveal more adversarial smart contracts. Furthermore, we could potentially identify adversarial smart contracts in real-time, given that the time frame is long enough, by applying a more sophisticated similarity detection technique that could work on a more fine-grained level (e.g., function-level). Combining this with other program analysis techniques could potentially mitigate or prevent exploits (c.f. Section V-A).
Limitations: Our methodology cannot cluster similar contracts that employ different compilers and optimization choices. In addition, if an adversary choose to obfuscate the bytecode by, for example, injecting unused function code into the contract, our method becomes less effective. We therefore highlight the application of more sophisticate strategies as an interesting avenue for future work [194].

C. Front-Running as a Service (FaaS) Usage
FaaS are servers to which a trader's transactions can be privately forwarded to miners that peer with the FaaS. We find that at least 18 incidents are executed through FaaS using Flashbots API on Ethereum. The first attack going through Flashbots happened on July 12, 2021.
• Arbitrageurs Accelerate Attacks: We manually examined each Flashbots bundle and discover that 6 of the 18 incidents appear to be accelerated by, e.g., arbitrage traders. We find that this is due to adversaries conducting incidents with suboptimal strategy, resulting in extractable BEV opportunities. Trading bots will then compete for these BEV opportunities by back-running incident transactions with FaaS. • Private Adversarial Transactions: Adversaries can execute an incident using FaaS services, without broadcasting any transactions on the public blockchain P2P network. As a result, only entities with sequencer knowledge (K 2 ) are able to defend against these adversaries (e.g., perform bytecode similarity analysis) prior to transaction confirmation.

D. Money Tracing
Adversaries require a source of funds to issue transactions to execute incidents. A may attempt to break the linkability of their source of funds to evade potential legal ramifications. This section proposes a money tracing methodology to analyze the pre-incident flow of funds (cf. Figure 9). An incident's source of funds is usually originating from a native coin transfer, e.g., from an address X to an address Y , i.e., X → Y . We apply Algorithm 1 in the appendix to identify the funding transaction X → Y for address Y . We abbreviate our

... Incident
Money transfer happens before the first tx of B

Pre-incident tracing
A B Fig. 9: Overview of the money tracing methodology. We start with the adversarial address (A), then iteratively determine the addresses that provide the initial source of funds (i.e., X 2 and X 1 , analogous to depth-first search).
Pre-incident ( To our knowledge, the current literature has not proposed any methodology to trace an incident's source of funds on an account-based ledger. • Centralized Exchange: We observe that 12(7.3%) (on Ethereum) and 21(8.0%) (on BSC) adversaries directly withdraw from exchange wallets (h = 1). The identities of these attackers can be revealed if the corresponding exchanges comply with Know Your Customer (KYC) requirements. For indirect exchange withdrawals (h > 1), we can only determine that A is linked to the withdrawer, but not whether the withdrawer is the attacker. • Mixer: 55(21%) (on ETH) and 12(4.6%) (on BSC) adversaries receive their initial funds directly from a mixer (h = 1). Note that we classify a mixer as the source of funds only if a so-called relayer executes the withdrawal transaction (i.e., a third-party paying the transaction fees in the native blockchain coin); otherwise, we assume that the withdrawal fee payer is linked to the withdrawer and continue tracing the money flow. Relayers help to break address linkability, by paying the transaction fees (gas fee) of mixer withdrawal transactions in exchange for a commission on the withdrawal value. • Cross-chain Bridge: Four attackers directly withdraw their source of funds from a blockchain bridge (h = 1). Linked Incidents We discover that the adversarial address in 13 incidents can be linked to another incident's adversary within three hops (cf.   II-A). ! -the number and percentage of research items related to a system layer; " -the average ratio of incident types each research item covers. For example, 15 of the 29 tools (52%) relate to PRO layer incidents, but each tool on average only covers 6% of the common PRO layer incident causes we identify.
Our dataset therefore inherits potential data completeness issues from Ether-and Bscscan.
VI. DISCUSSION DeFi Incidents -Another Cat and Mouse Game: Analog to traditional information security, DeFi incidents can be perceived as a cat-and-mouse game, in which defenders attempt to minimize the security risk surface while attackers breach defenses. In the following, we extract insights on the current state of this contest, highlight key findings, discuss their implications and make recommendations for future research. 1) Insight -Understudied NET and CON incidents: We observe that NET and CON-related incidents are studied in 29% and 26% of academic papers (excluding tools, SoKs and surveys). However, only two tools (SquirRL [71], DeFiPoser [9]) as well as 2% and 0% of the in-the-wildincidents relate to the NET and CON layers, respectively. While related works have surprisingly identified evidence of miner misbehavior in block header timestamps for financial gain [125], we note that: (a) it is not trivial to identify NET and CON incidents with absolute certainty (e.g., transaction censoring, selfish mining attack and block reorganization attack); and (b) to our knowledge, no publicly available tool can comprehensively detect potential NET and CON incidents in DeFi. As such, we suspect that more incidents have yet to be discovered. Furthermore, we notice that none of the industrial DeFi audit reports explicitly address potential NET and CON incidents, while some companies have previously performed NET and CON auditing for layer 1 and 2 blockchains 25 . 2) Challenge -Low coverage for PRO incidents: SC and PRO layer incidents are the most common incident type (42% and 40%, respectively). Security tools, however, only cover 52% of the PRO layer incident types on average, which is less than SC layer (90%). As such, our dataset indicates that most defense tools still focus on SC vulnerabilities. The literature, however, suggests that the development of effective and generic PRO incident defense tools remains an open security challenge [9]. This is mainly due to DeFi's composability feature, which leads to action path explosion in detecting PRO layer vulnerabilities. 3) Insight -Repeated on-chain oracle manipulation: We discover 28 (15%) on-chain oracle manipulation incidents on Ethereum and BSC, which is the most common PRO layer incident type. On-chain oracle manipulation is one type of composability attack, which implies the adversary has C 3 PRO capability. Repeated on-chain oracle manipulation indicates the need for tools to automatically identify such attack. To our knowledge, only DeFiRanger [85] and DeFiPoser [9] can detect oracle manipulation vulnerabilities. DeFiRanger can only identify observed attack transactions, whereas DeFiPoser can identify new vulnerabilities in real-time, but necessitates manual and costly modeling of the captured DeFi protocols. 4) Insight -Permissionless interactions are dangerous: The permissionless interactions between various DeFi protocols can further broaden the attack surface. According to our dataset, in 19 (10.5%) incidents, adversaries utilize or deploy a contract (C 5 PRO ), which complies with the accepted ABI interface, but contains incompatible implementation logic that causes harm 26 . The underlying cause of these incidents is that the victims only constrain the contract function interface, not how the contract is implemented. We are, however, unaware of any viable way to efficiently verify code implementation on-chain due to the limitations of the current SC layer design. An alternative solution for constraining the contract with which a protocol or its user interacts is to implement a whitelist, where a DeFi protocol can only interact with other protocols in the whitelist. 5) Insight -The identities of the attackers may still be revealed: Although mixers are available on both Ethereum and BSC, our empirical result shows that only 38% of attackers obtain their source of funds from mixers (i.e., C 1 PRO ). The majority of attackers interact with AUX services, such as centralized exchanges, and mining pools, which may provide stored personally identifiable information upon regulatory requests. Note that we naively assume mixers leaking the least side-channel information compared to other methodologies. Wang et al. [25] develop heuristics to reduce the anonymity set of Tornado.cash and Typhoon mixers on Ethereum and BSC. Quesnelle et al. [195] and Kappos et al. [196] investigate Zcash and show that the anonymity set size can be significantly reduced using simple heuristics to link transactions. Tran et al. [197] and Pakki et al. [198] show that existing mixer services are vulnerable to various threats such as permutation leak. 6) Insight -Adversaries can be front-run during the rescue time frame: Su et al. [87] discover that blockchain adversaries test their code by sending several transactions to the victim protocol before the actual attack. We initially questioned this finding because anyone can inspect the adversarial smart contract bytecode and transactions on the P2P layer, and therefore can front-run the adversaries to rescue the victim protocol. The optimal strategy for A is to emulate the state transitions off-chain, then deploy and exploit in one single transaction (i.e., the capability C 4 PRO ). Surprisingly, our empirical results support Su et al. [87] (cf. Section V-A). We encourage the development of tools to front-run adversaries during this rescue time frame. 7) Challenge -Absence of intrusion detection tools: Only one incident in our dataset has triggered the emergency pause within the first hour of the incident. This indicates the absence of intrusion detection tools to automatically trigger emergency pauses. We anticipate that just-in-time detection of abnormal protocol states or malicious transactions will receive increased attention in future studies. 8) Insight -Adversarial and vulnerable contracts are detectable: We show that SoTA similarity analysis can detect vulnerable and adversarial contracts. For instance, we identify 31/23 exactly matching vulnerable/adversarial contracts (i.e., bytecode similarity score of 100%) when compared to previously known incidents.

VII. RELATED WORKS
Cyber Risks: Sheyner et al. [199] outline an algorithm that can automatically generate attack graphs and analyze network security. Wang et al. [200] present a framework for measuring various aspects of network security metrics based on attack graphs. Khan et al. [201] propose a generalized mathematical model for cybersecurity that quantifies a set of parameters including risk, vulnerability, threat, attack, consequence, and reliability. Amin et al. [202] adopt the structural Bayesian Network to capture the relationship between financial loss, cyber risk and resilience, as well as developed a scorecard based approach to qualitatively assess the level of cyber risk. We refer interested readers to an SoK that thoroughly categorizes previous cyber risk studies [181]. While the research literature of cyber risks span over 30 years, DeFi is a relatively recent area with fewer works (cf . Table III). DeFi Security: This paper proposes a five-layer system model as well as a comprehensive taxonomy of threat models that are used to measure and compare DeFi incidents. In the following, we present an overview of the most recent DeFi related survey and SoK papers, while highlighting the differences to contrast our work. Praitheeshan et al. [10] identify 19 software security issues and 16 Ethereum smart contract vulnerabilities, with 14 of them on smart contract layer. Homoliak et al. [11] present a stacked security model with four layers and systemized the vulnerabilities, threats, and countermeasures for each layer. Unfortunately, this research is not able to cover any smart contract layer vulnerabilities. Saad et al. [12] categorize 22 attack vectors in terms of its vulnerability origins (i.e., blockchain structure, P2P system and blockchain applications) and analyze the entities (e.g., miners, mining pools, users, exchanges, etc.) involved in each types of attacks. However, their examinations on protocol layer vulnerabilities and third-party vulnerabilities are conspicuously inadequate. Chen et al. [13] provide a comprehensive systematization of vulnerabilities, attacks, and defenses on four blockchain layers with detailed discussion on the relationships between them. Despite being able to cover in total of 40 vulnerabilities, this study does not state any vulnerabilities that are related to DeFi composability. Werner et al. [14] present a systematization of DeFi protocols and dissected DeFi related vulnerabilities with respect to technical and economic security. Nonetheless, this study lacks in-depth analysis of consensus and network layer vulnerabilities and does not provide generic measures to quantify the harm of DeFi incidents. Atzei et al. [15] investigate the security vulnerability on Ethereum and provided a taxonomy of the common programming pitfalls. Nevertheless, the vulnerability coverage of this work is unsatisfactory as it exclusively focuses on smart contract layer. Samree et al. [16] identify 8 application level security vulnerabilities on the smart contract layer, analyze past attack incidents and categorize detection tools. However, this study also focuses on addressing smart contract vulnerabilities. Wan et al. [109] conduct 13 interviews and 156 surveys to investigate the practitioners' perceptions and practices on smart contract security. They, however, do not reveal how much effort was allocated into the security of each system layer. For studies and tools related to specific incidents, we refer interested readers to Table III. Code Cloning: Code clone detection has been extensively explored in the literature for both source code [203] and binary programs [204]. Token based [205], tree based [206], graph based [207], text based [208], and deep learning based [209] techniques are the most prevalent techniques explored for code cloning. Applications of code cloning include bug detection, malware detection, patch analysis, plagiarism detection, and code similarity [203], [204], [210], [211]. Smart contract code cloning has been utilized primarily for computing duplication [191]- [193], [212]- [215] and vulnerability search [193], [212]. In this work, we apply a code cloning detection for comparing vulnerable and adversarial smart contracts. Blockchain money tracing and account linking: Androulaki et al. [216] evaluate the privacy provisions in Bitcoin and show that nearly 40% of user profiles can be recovered. Meiklejohn et al. [217] apply heuristic clustering to group Bitcoin wallets. Yousaf et al. [218] develop heuristics allowing to trace transactions across blockchains. Victor [219] proposes heuristics to cluster Ethereum addresses by analyzing the phenomena surrounding deposit addresses, multiple participation in airdrops and token transfer authorization on Ethereum. The most relevant paper to this study is Su et al. [87], which analyze adversarial footprints and operational intents on Ethereum. In this work, we examine adversarial money flow before the attack to determine the source of funds.

VIII. CONCLUSION
This paper constructs a DeFi reference frame that categorizes 77 academic papers, 30 audit reports, and 181 incidents, which reveals the differences in how academia and the practitioners' community defend and inspect incidents. We investigate potential defense mechanisms, such as comparing victim/adversarial smart contract bytecodes, quantifying attack time frames, and tracing each attacker's source of funds. Our results suggest that DeFi security is still in its nascent stage, with many potential defense mechanisms requiring further research and implementation.

IX. ACKNOWLEDGEMENT
This work is partially supported by Chainlink labs, Swiss-Borg SA, Nimiq Foundation, and Lucerne University of Applied Sciences and Arts, Switzerland.