Detecting Cross-Function Reentrancy from EVM Traces

Blockchain technology has evolved rapidly since the introduction of Bitcoin in 2009 [25], enabling not only decentralized payments but also the execution of programmable logic through smart contracts. Smart contracts are programs deployed on a blockchain whose execution is enforced by consensus, allowing mutually distrusting parties to interact without trusted intermediaries. While this paradigm offers transparency and autonomy, it also introduces severe security challenges. Smart contracts often hold cryptocurrencies of significant value, which makes them attractive targets for malicious actors. At the same time, once deployed they are immutable and cannot be patched; therefore, vulnerabilities discovered after deployment cannot be eliminated by modifying the vulnerable code. Among smart contract vulnerabilities, reentrancy is one of the most critical. It occurs when a contract transfers control to an external entity before completing its own execution, allowing the callee to re-enter the caller within the same transaction and exploit its intermediate state. The DAO attack in 2016 [37], which resulted in the loss of more than three million Ether, represents the first and simplest instance of this vulnerability. Since then, research has shown that reentrancy can occur in more complex and compositional forms, involving subtle interactions between control flow and state updates.

In response to reentrancy threats, numerous approaches and tools have been proposed to detect and mitigate such vulnerabilities. Formal analysis techniques commonly rely on methods such as symbolic execution, taint analysis, fuzzing, and constraint solving [29]. Beyond bug-finding, smart-contract security has also been studied through information-flow properties: noninterference-based analyses aim at formally ruling out unwanted influence across security levels in contract behaviors [16, 5]. The notion of interference has been studied in other formal settings as well, including behavioral preorders explicitly sensitive to interference; we build on this general intuition and instantiate it to EVM-level smart-contract executions [8, 13]. Several well-known static analysis tools, including Oyente [22], Securify [39], and Mythril [33], analyze smart contract code to identify patterns associated with reentrancy vulnerabilities. Ethor [32] extends this line of work by abstracting the semantics of EVM bytecode using Horn clauses to verify reachability properties. These approaches are complemented by dynamic analysis frameworks such as ContractFuzzer [17] and sFuzz [26], which explore contract behavior at runtime using fuzzing techniques. More advanced analyzers, such as Clairvoyance [43] and SmartDagger [20], specifically focus on detecting vulnerabilities arising from cross-contract interactions.

Most existing tools focus on detecting single-function reentrancy, where the callee re-enters the same function while the contract is in an inconsistent intermediate state. In this work, we analyze reentrancy at the EVM bytecode level using execution traces. We extend Txspector [28], which currently detects vulnerabilities such as Reentrancy, UncheckedCall, and Suicidal contracts but is limited to single-function reentrancy. Our goal is to extend its detection capabilities to identify a more advanced and dangerous form of attack, cross-function reentrancy, where the callee re-enters a different function before the initial execution completes. This work is guided by the following research question: how does reentrancy manifest at the level of EVM execution semantics, particularly in complex and compositional scenarios?

Based on the observations above, this paper makes the following contributions:

1. 1.

   We define new patterns for cross-function reentrancy, and based on these patterns, we design a set of logic detection rules for its identification.

2. 2.

   We modernize the TxSpector framework by updating its source code to support recent libraries and EVM changes introduced by newer Ethereum hard forks.

3. 3.

   We implement the proposed rules in the TxSpector detector component using Datalog and evaluate them through experiments on real-world Ethereum transactions.

Smart contracts in Ethereum execute on the Ethereum Virtual Machine (EVM), a stack-based runtime environment. They are typically written in high-level languages such as Solidity [35] and compiled into bytecode, which is the only representation available after deployment unless source code is explicitly published [4]. The bytecode is distributed via contract creation transactions and executed by every node in the network whenever a contract function is invoked. The EVM is designed to ensure deterministic execution across all nodes and follows a stack-machine architecture, where instructions operate on a data stack or constant operands. During execution, a contract can use three memory regions. The stack is a volatile region manipulated by dedicated instructions. Memory is a volatile, byte-addressable heap that persists only during a transaction. Storage is a persistent key-value store mapping 256-bit words to 256-bit words and represents the only state preserved across transactions. Each contract invocation occurs within a transaction. Transactions can be issued by external accounts or by other contracts. To prevent abuse and ensure termination, Ethereum employs a gas mechanism, where each instruction consumes a predefined amount of gas paid by the transaction sender. This mechanism also protects the network from infinite loops.

In Ethereum, smart contracts interact with external contracts and transfer Ether through message calls using primitives such as call, transfer, and send. These instructions trigger the fallback (or receive) function of the recipient contract, which may execute additional operations depending on the gas forwarded. The send and transfer instructions forward a limited gas stipend of 2300 gas, restricting the callee’s ability to perform complex operations. In contrast, call forwards all remaining gas by default, enabling arbitrary code execution and making it the primary source of reentrancy vulnerabilities. Other call-related instructions also exist such that delegatecall executes the code of another contract in the context of the caller, meaning that the caller’s storage, address, and balance are preserved, and Staticcall performs a read-only external call and does not allow state modification during execution. In Solidity, such interactions are commonly expressed such as a.call{value: x}("fun"), where a is the callee address, the string specifies the function signature, and x is the amount of ether transferred.

Prior work has classified smart contract vulnerabilities into three layers: the blockchain layer, the virtual machine layer, and the solidity layer [31]. In this work, we argue that reentrancy detection fundamentally belongs to the virtual machine layer because reentrancy is not only a coding mistake, but a runtime behavior induced by the EVM call semantics, which temporarily transfers control to external code and can dynamically alter the transaction’s control flow before the original execution completes [34]. As a result, reentrancy depends on the concrete sequence of call frames, returns, and storage operations during transaction execution, and is therefore more naturally captured at the bytecode and execution level rather than solely at the source-code level. More generally, our choice to perform bytecode-level analysis is motivated by several additional reasons. First, the source code of deployed contracts is often unavailable, as the blockchain stores only the compiled bytecode. Second, certain properties relevant to vulnerability analysis are observable only at the bytecode level (e.g., gas consumption defined by EVM instructions). Third, compiler optimizations may alter the structure of the generated bytecode, which can affect the reliability of analyses performed at the source-code level, making post-compilation analysis more appropriate.

Smart contract vulnerabilities have been widely studied, with reentrancy recognized as one of the most severe threats. Prior work classifies vulnerabilities into the blockchain, virtual machine, and Solidity layers [31]. Recent work has also investigated reentrancy from a formal information-flow viewpoint, modeling reentrant behaviors through noninterference to capture semantic dependencies across executions [5]. Reentrancy fundamentally arises at the EVM layer, as it is caused by execution semantics and inter-contract interactions rather than source-level syntax, motivating low-level analysis approaches.

Static analysis tools have been extensively used for reentrancy detection. Vandal [7] analyzes EVM bytecode by translating semantic relations into Datalog, enabling scalable detection of multiple vulnerabilities, including reentrancy. Securify [39] follows a similar logic-based approach but applies conservative violation patterns that often flag any state update after an external call as vulnerable, leading to false positives. Source-level tools such as SmartCheck [36] and Slither [12] rely on syntactic or rule-based detection, which limits their ability to capture complex execution behaviors and cross-contract interactions.

Symbolic execution has also played a central role in smart contract analysis. Oyente [3], followed by Mythril [9], Manticore [38] and Osiris [19], explores execution paths at the EVM level to detect reentrancy and other vulnerabilities. However, symbolic execution suffers from path explosion and scalability limitations, forcing a trade-off between precision and coverage that reduces its effectiveness for large or compositional contracts.

Dynamic approaches aim to complement static analysis. ReGuard [21] applies fuzzing by translating contracts into C++ and generating randomized transactions to detect reentrancy from execution traces. While effective for certain execution-dependent bugs, fuzzing suffers from limited coverage and difficulty in triggering complex vulnerability conditions.

Runtime monitoring tools such as Sereum [30] and ECFChecker [15] detect reentrancy during execution by tracking control and data flows, achieving high precision but focusing on detection and prevention rather than abstraction and reuse.

Recent work has explored compositional and cross-contract reentrancy detection. Sailfish [6], Pluto [23], and SliSE [42] extend analysis across contract boundaries, improving coverage of complex interactions. Nevertheless, these approaches rely on ad hoc detection rules and lack a unified abstraction that explains different reentrancy behaviors in a systematic manner.

Existing approaches either rely on conservative heuristics, suffer from scalability issues, or focus solely on detection at runtime. None provides a pattern-based characterization of reentrancy grounded in EVM execution semantics, together with precise and reusable detection logic. This paper addresses this gap by defining a design-pattern–based taxonomy of reentrancy vulnerabilities and implementing logic rules for their detection.

Reentrancy is one of the most critical and widely studied vulnerabilities affecting Ethereum smart contracts. It arises when a contract transfers control to an external contract before completing its own state updates, allowing the external contract to call back into the original contract and manipulate its state while it is in an inconsistent intermediate state [2] [30] [34]. The practical severity of reentrancy has been demonstrated by several real-world incidents. The most prominent example is The DAO attack in 2016, which ultimately led to the Ethereum hard fork [2] due to its massive financial and ecosystem impact, with losses estimated at around USD 60 million. The vulnerability resided in the DAO contract’s withdrawal function [11], which transferred Ether to the user before updating the user’s internal balance. A malicious contract exploited this flaw by repeatedly re-entering the withdrawal function during fallback execution before the balance update took place. Similar reentrancy-based exploits have continued to affect major decentralized finance platforms, including Uniswap [27] and Lendf.Me [10] in April 2020, and BurgerSwap [44] in May 2021, with losses ranging from hundreds of thousands to millions of dollars.

Reentrancy vulnerabilities can arise in several forms depending on how control returns to the vulnerable contract. In single-function reentrancy [5], the attacker repeatedly re-enters the same function before its state is updated. In cross-function reentrancy [40] [30], the re-entry occurs through a different function within the same contract, affecting shared state in a less obvious way. Cross-contract reentrancy [41] involves multiple interacting contracts and more complex call chains. Reentrancy may also occur through DELEGATECALL [18], where external code executes in the caller’s storage context, creating risks especially in proxy-based designs. Finally, although less common, reentrancy can also emerge during contract creation through CREATE or CREATE2 [30], when initialization logic enables unexpected callbacks before deployment is fully completed.

Several protection mechanisms have been adopted to mitigate reentrancy vulnerabilities in smart contracts. The most widely recommended practice is the Checks-Effects-Interactions (CEI) pattern, which requires contracts to first validate conditions, then update their internal state, and only afterward perform external calls. By ensuring that critical state changes are completed before control is transferred outside the contract, CEI reduces the risk of reentrant execution. Another common defense is the use of a mutex-based guard, usually implemented through a shared lock variable or a nonReentrant modifier, which prevents a function from being invoked again before the current execution has finished. Historically, Solidity’s send and transfer primitives were also considered safer because they forward only a limited amount of gas to the callee, thereby restricting reentrant behavior, although this protection is no longer considered fully reliable under evolving gas semantics. Other mechanisms, such as onlyOwner access control and isHuman checks, may reduce exposure by limiting who can invoke sensitive functions, but they do not provide complete protection against reentrancy, especially in more complex cross-function or cross-contract scenarios.

In this work, we adopt the definition of a pattern proposed by Destefanis et al. [24], who describe a design pattern as “a typical solution to a recurring design problem.” The notion of pattern originates from architecture then later transferred to software engineering and became formally established in object-oriented design [14]. A design pattern is generally characterized by three main elements: a name, which provides a clear and memorable reference; a problem, which defines the recurring issue and the conditions under which the pattern applies; and a solution, which presents an abstract but reusable approach for resolving the problem without prescribing a single concrete implementation.

We evaluate our rules by implementing and testing them within TxSpector, which consists of four main components: the Trace Extractor, the Execution Flow Graph Generator, the Logic Relation Builder, and the Attack Detector. Our contribution mainly concerns the Trace Extractor and the Detector.

For the Trace Extractor, which replays Ethereum on-chain transactions using a Geth node and records execution traces, we found that the Geth version originally used by TxSpector was outdated and did not support several newer EVM opcodes. In addition, some of the libraries required for extraction were no longer available. To address this limitation, we migrated the extractor to a newer version of Geth and applied the necessary modifications to restore compatibility with TxSpector while supporting recent EVM changes. These updates required modifications to several source files responsible for MongoDB initialization and transaction storage, transaction execution, state prefetching, EVM interpretation, opcode execution, and trace persistence.

We also updated the Detector component so that it recognizes newer call-related opcodes during the analysis, and we extended it with new user-defined Datalog rules for detecting cross-function reentrancy. We then evaluated the extended tool on real Ethereum on-chain transactions. The following example was successfully detected by our approach. Figure 1 illustrates the process flow of the detector component. The complete implementation of these modifications along the examples used to validate the proposed detection rules, is publicly available on GitHub.

This work shows that reentrancy vulnerabilities cannot be fully captured by traditional single-function or source-level analyses. By operating directly on EVM transaction traces, our approach characterizes reentrancy as an execution-level phenomenon arising from concrete control-flow and data-dependency relations. This perspective enables precise reasoning about behaviors that depend on call context, temporal ordering, and shared persistent state.

A key contribution is the formalization and detection of cross-function reentrancy, where re-entry occurs through a different function of the same contract. Such vulnerabilities are missed by existing tools that assume reentrancy to be confined to a single function. By explicitly modeling call depth, call number, and storage access ordering, our logic rules accurately identify these behaviors without relying on conservative heuristics, thereby reducing false positives.

The pattern-based abstraction adopted in this work provides a structured and extensible framework for reentrancy detection. New variants can be incorporated by defining additional patterns and logic rules, without modifying the underlying trace extraction pipeline. While the approach is inherently limited by trace coverage, it complements static and symbolic techniques and is well suited for analyzing real-world transaction executions.

This paper presented a pattern-based approach for detecting reentrancy vulnerabilities at the level of EVM execution traces. We extended an existing execution-trace analysis framework with new logic rules designed to capture cross-function reentrancy, a more subtle and dangerous variant of the classical reentrancy vulnerability. Unlike traditional analyses that focus primarily on single-function patterns or source-level code, our approach operates directly on execution traces and models reentrancy as a runtime phenomenon involving control-flow dependencies, storage access ordering, and call-context relations.

To enable this analysis, we modernized the underlying infrastructure by updating its trace extraction component to support recent versions of the Ethereum client and newer EVM instructions. We then implemented the proposed detection rules in Datalog within the detector module and evaluated the extended system on real Ethereum transaction traces. The experimental results demonstrate that our approach successfully identifies cross-function reentrancy patterns that are not captured by the baseline rules.

Beyond the specific case of reentrancy, the pattern-based methodology proposed in this work provides a flexible framework for describing and detecting execution-level vulnerabilities in smart contracts. Future work includes extending the pattern taxonomy to cover additional classes of vulnerabilities, improving trace coverage, and integrating the approach with complementary static and symbolic analysis techniques to further enhance detection accuracy.