PaperlayerView exact revision on arXiv

Source-linked AI summary

Function Name Is All You Need to Detect Blockchain Application Attacks

Rui Xi, Zehua Wang, Karthik Pattabiraman

arXiv:2609.12315v1cs.CR

TL;DR

Blockchain application attack detectors may depend on handcrafted patterns or smart-contract source code that is difficult to obtain. TxLucent learns attack semantics from function-name sequences extracted from transaction call traces. It reports a 1.56% incident-level FNR, a 0.0017% transaction-level FPR, and 24.90-millisecond mean detection time.

  • Problem

    Existing detectors rely on handcrafted patterns or contract source code that is difficult to obtain, limiting their practical applicability.

    Source: §1 · p. 1

  • Method

    TxLucent maps transaction call traces to function-name sequences and uses a Transformer to learn semantics for attack detection.

    Source: §1 · p. 2

  • Results

    TxLucent achieves a 1.56% incident-level FNR and 0.0017% transaction-level FPR, outperforming the length heuristic, CLUE, and Hunting.

    Source: §10 · p. 13

  • Takeaways & Limitations

    Function-name coverage is 98.46% versus 74.78% for source code, and TxLucent’s 24.90-millisecond mean detection time supports low-latency detection.

    Source: §10 · p. 13

    As dApp logic and attack vectors shift, TxLucent requires retraining after distribution shifts, adding maintenance overhead.

    Source: §8 · p. 13

Abstract

from arXiv · show

Blockchain application attacks, targeting business logic bugs in decentralized applications (dApps), have been an increasing concern to their developers and users, causing significant financial loss. Existing attack detectors either rely on handcrafted rules for detection, or need difficult-to-obtain smart contract source code to analyze attack transactions. This makes them brittle and inapplicable in practice. In this paper, we argue that function name sequences suffice to capture the high-level semantics of a transaction, and hence can be used to detect blockchain application attacks. Our empirical study on transactions from 424 real-world attack incidents shows that 98.46% of call traces can be resolved to function names, whereas only 74.78% invoke contracts with available source code. Based on this observation, we propose TxLucent (pronounced "translucent"), an automated framework to detect blockchain application attacks by extracting application semantics from transaction call traces. TxLucent maps call traces to function name sequences and uses a transformer to learn semantics from such sequences. Consequently, TxLucent can detect attacks without relying on hand-coded patterns or source code. Our results show that TxLucent achieves a 1.56% false negative rate on 424 known incidents with 14,611 attack transactions, and an estimated 0.0017% false positive rate for benign transactions from over 500 million transactions on the Ethereum blockchain. Finally, TxLucent takes an average of 24.90 milliseconds to analyze a transaction, thus supporting real-time attack detection on popular blockchains.

1 Introduction

Blockchain application attacks exploit dApp business-logic bugs and cause substantial financial losses, while existing detectors rely on handcrafted patterns or often-unavailable contract source code. TxLucent instead learns from function-name sequences; its evaluation reports low false-negative and false-positive rates, and function names cover more traces than source code.

1 Introduction

  • Blockchain application attacks exploit dApp business-logic bugs, have caused billions of dollars in losses, and accounted for 42% of incidents on popular blockchains since 2022.They can occur when one dApp interacts with another whose business logic deviates from the first dApp’s intended behavior.Source: §1 · p. 1
  • Prior detectors either infer expected semantics from contract source code and comments or use on-chain patterns that require manual effort and domain knowledge.The source-code approach is difficult to generalize, while evolving dApps require ongoing manual pattern analysis.Source: §1 · p. 1
  • TxLucent maps transaction call traces to function-name sequences, then uses a Transformer classifier to learn attack semantics and distinguish attacks from benign transactions.The authors emphasize the sufficiency of function-name sequences, not the choice of classifier, as the central contribution.Source: §1 · p. 2
  • TxLucent is presented as the first technique to extract transaction semantics from function-name sequences for blockchain application attack detection.The authors’ contribution is detection without handcrafted rules, contract source code, or heavyweight feature reconstruction.Source: §1 · p. 2
  • 98.46% of call traces have function-name coverage, compared with 74.78% invoking contracts with available source code.Function-name lookup is selector-level, so a name found for one contract can map calls to other contracts with unavailable source code.Source: §1 · pp. 1–2
  • 1.56% FNR for TxLucent, versus 31.31% for the length heuristic, 70.77% for CLUE, and 83.17% for Hunting; its FPR is 0.0017%.The evaluation uses incident-level fivefold cross-validation and a benign Ethereum dataset; mean detection time is 24.90 milliseconds per transaction.Source: §1 · p. 2

2 Background

Ethereum smart contracts expose function signatures in transaction interactions, while ABIs and source code remain off-chain. ERC standards and common dApp conventions reuse function names for operations, making names informative about business activity.

2.1 Ethereum and Smart Contracts

  • Smart contracts are on-chain bytecode programs, while their source code and ABIs are off-chain; ABIs specify function signatures but not contract logic or implementation.Developers often publish ABIs for transparency and interoperability, and ERC specifications and APIs commonly provide them.Source: §2.1 · p. 2

2.2 dApps and Ethereum Request for Comments (ERCs)

  • ERCs standardize dApp interfaces, allowing applications that understand an interface to interact with conforming contracts without knowing their implementations.ERC20 tokens share names such as transfer, approve, and transferFrom; ERC721 standardizes operations such as ownerOf.Source: §2.2 · pp. 2–3
  • Common DEX and lending conventions reuse function names for operations such as swaps, liquidity management, deposits, borrowing, repayment, and liquidation.Examples include Uniswap V2 router methods, Curve’s exchange entry point, ERC4626 vault methods, and ERC3156 flash-loan methods.Source: §2.2 · p. 3
  • Formal ERCs and de facto conventions encourage consistent naming, so function names can carry semantic information about dApp business operations.Figure 1 is identified as an illustration of C.R.E.A.M. Finance in regular and attack transactions.Source: §2.2 · p. 3, Figure 1 · p. 3

3 Motivating Example

The Cream incident shows how a reentrant borrow can violate a lending dApp’s expected transaction workflow. The attack’s function-name sequence reveals the repeated borrowing that precedes liquidation and collateral seizure.

3 Motivating Example

  • The example uses function names to represent lending operations and show how the attack sequence departs from the ordinary borrow, repay, and collateral lifecycle.The named operations include supply, borrow, repay, liquidate, and seize.Source: §3 · p. 3
  • The Cream attacker borrowed twice through reentrancy, then liquidated and seized collateral; the sequence borrow → borrow → liquidate → seize contrasts with the expected workflow.The second borrow occurred without an intervening repayment, allowing total debt to exceed the collateral value while still leaving the attacker financially advantaged after liquidation losses.Source: §3 · p. 3
  • A callback from AMPToken.transferFrom reentered ETHMarket.borrow before the first borrow’s debt state updated, enabling borrowing beyond the collateral limit.The root cause was failure to account for the AMPToken.tokensReceived callback across ETHMarket and AMPMarket.Source: §3 · p. 4
  • The call traces are available on-chain, while function signatures for the involved contracts are available off-chain, including the attacker’s standardized tokensReceived signature.The attacker-controlled contract’s source code and ABI are not publicly available, but its callback signature is available through ERC777 standardization.Source: §3 · p. 4

4 Threat Model, Scope and Assumptions

TxLucent targets business-logic attacks on EVM-compatible blockchains, not infrastructure, user-targeting, language-feature, or insider attacks. It assumes transaction metadata and call traces are available, but transaction contracts’ source code is not.

4 Threat Model, Scope and Assumptions

  • The scope is EVM-compatible blockchain application attacks that exploit business-logic flaws for financial gain or disruption, excluding infrastructure, user-targeting, Solidity-feature, and insider attacks.Attackers are assumed to have standard user capabilities and may deploy auxiliary contracts to automate attacks.Source: §4 · p. 4
  • The attacker is assumed to know the dApp’s business logic and source code and to use that knowledge, documentation, and prior attack techniques to craft malicious transactions.The modeled attacker seeks to manipulate dApp state or behavior through smart-contract-defined interactions.Source: §4 · p. 4
  • TxLucent assumes access to transaction metadata and call traces but not source code for contracts in a transaction; it uses a selector-to-name database, mapping absent selectors to [UNK_SELECTOR].The database is built once from public sources, and resulting function-name coverage is measured empirically.Source: §4 · p. 4
  • The stated goal is timely, accurate detection with low false-positive and false-negative rates so attacks can be identified and mitigated before further damage.The model assumes on-chain features can be obtained locally from a full blockchain node without network latency.Source: §4 · p. 4

5 Challenges and Insights

On-chain traces are plentiful but low-level, while richer off-chain evidence is less available or harder to maintain. TxLucent uses function-name sequences as a compact semantic view for learning to distinguish attacks from benign transactions.

5.1 Challenges

  • Low-level on-chain artifacts create a vast space to organize, while graph construction and attack-pattern curation require substantial effort.Specific on-chain detectors also target only certain attack categories.Source: §5.1 · pp. 4–5
  • Function names cover 98.46% of call traces, versus source code availability for 74.78%; historical data and oracle inputs also have availability or trust limitations.New protocols may lack labeled history, and oracle values may be missing or stale.Source: §5.1 · p. 5
  • Function names mapped from call traces provide a compact semantic view derived from runtime calls without requiring source code for each transaction’s contracts.The paper presents this as an alternative to heavyweight reconstruction and manual curation.Source: §5.1 · p. 5

5.2 Insights

  • Descriptive function names encode business logic, and attackers cannot rename victim contracts’ deployed functions; 98.70% of attack call traces involve those victim-side names.Attacker-controlled function names account for 1.30% of call traces in attack transactions.Source: §5.2 · p. 5
  • Learning from function-name sequences can capture attack-related semantic patterns without handcrafted rules, including atypical victim-side call orderings.The Cream example contrasts borrow and liquidation paths interleaved with attacker-created callbacks against a routine borrow → repay → seize flow.Source: §5.2 · p. 5

6 TxLucent Design

TxLucent reconstructs transaction call traces into function-name sequences, then uses a Transformer-based classifier to predict whether transactions are attacks or benign. Its design derives semantic and ordering information from on-chain traces without relying on source code or auxiliary transaction metadata during classification.

6 TxLucent Design

  • TxLucent has a sequence builder that derives function-name sequences from raw call traces and a classifier that detects attacks.The design does not rely on contract source code or auxiliary transaction metadata during classification.Source: §6 · p. 6

6.1 Sequence Builder

  • The sequence builder reconstructs hierarchical execution flow and maps trace selectors to function names, producing an ordered representation for learning.It links traces into a tree and uses call order to preserve transaction context.Source: §6.1 · pp. 6–7
  • A one-time database maps 4-byte selectors to representative function names and parameter lists, resolving collisions by candidate prevalence and canonical-order tie-breaking.Selectors without a database match receive the special UNK_SELECTOR token.Source: §6.1 · pp. 6–7
  • Raw trace metadata links callers and callees into a call-trace tree, while the default classifier does not consume those address fields as features.The builder orders calls by canonical trace_path before constructing the sequence.Source: §6.1 · p. 6, §6.2 · p. 7

6.2 Classifier

  • The classifier encodes the function-name sequence with a Transformer encoder and linear head to predict attack or benign.It trains on labeled transactions with cross-entropy and a balanced weighted sampler, then applies a checkpoint-specific probability threshold at inference.Source: §6.2 · p. 7

7 Experiments

The experiments evaluate TxLucent’s detection accuracy, function-name coverage, explainability, latency, and feature contributions. They examine how function names support detection, the effects of obscuring attacker-controlled names or removing calls, and alignment with incident reports and compatibility with block production.

7.1 Experiment Setup

  • The labeled datasets include 14,611 attacks and 134,665 victim-history transactions from 424 incidents, plus 537,069,442 benign Ethereum transactions.Five category-stratified folds keep each incident together; each checkpoint fits four folds, evaluates the fifth, and includes 2,048 randomly sampled Ethereum transactions as benign data.Source: §7.1 · p. 8

7.2 RQ1: Coverage of Function Name

  • Function names were available for 98.46% of call traces, 23.68 percentage points above source-code coverage of 74.78%.Function names were available for 95.22% of calls whose source code was unavailable; 98.70% of attack-dataset call traces invoked victim functions.Source: §7.2 · p. 8

7.3 RQ2: Detection Accuracy

  • TxLucent’s FNR was 1.56%, versus 31.31% for the length heuristic, 70.77% for CLUE, and 83.17% for Hunting.FNR is measured at the incident level across five evaluation folds, with each incident’s transactions kept together to prevent leakage.Source: §7.3 · p. 9
  • TxLucent flagged 9,228 of 537,069,442 benign transactions, an FPR of 0.0017%.The 9,228 flags correspond to 12.6 alerts per day over 24 months; this FPR is a conservative upper bound because the benign set may include undisclosed attacks.Source: §7.3 · pp. 9–10

7.4 RQ3: Explainability of Detection

  • TxLucent’s median alignment score across 184 assessable reports was 74.86%.Layer Integrated Gradients identifies positively contributing function names, which are compared with report evidence; the Cream case study aligned attributed borrow, tokenReceived→borrow, and liquidation calls with the documented exploit mechanism.Source: Figure 5 · p. 10, §7.4 · pp. 10–11

7.5 RQ4: Real-Time Detection

  • TxLucent’s warmed post-fetch mean latency was 24.90 milliseconds and P95 was 50.03 milliseconds, both below Arbitrum’s 0.25-second block time.The maximum was 1,819.032 milliseconds, and the benchmark excludes trace acquisition, full-block throughput, and production traffic; the measured trace-to-output interval excludes network latency and block confirmation.Source: Table 3 · p. 11, §7.5 · p. 11

7.6 RQ5: Ablation Study

  • The ablation study compares the full model with retrained function-names-only and tree-position-only arms at the same FPR target.The function-names-only arm masks tree and order inputs, while the tree-position-only arm replaces names with a constant call marker but retains position encoding; no ablation results are reported in this part.Source: §7.6 · p. 11, Figure 7 · p. 12
  • TxLucent’s incident FNR is 1.56%, versus 3.30% without tree position, 8.73% without function names, and 31.31% for call-trace length.Both tree position and function names contribute, with function names providing the stronger standalone signal in these ablations.Source: §7.6 · p. 12
  • The older-to-recent diagnostic misses 1 of 87 recent incidents (1.15% FNR) after fitting on 337 older incidents.The paper characterizes this as evidence that function names are not sensitive to temporal changes.Source: §7.6 · p. 12

7.7 RQ6: Evasion

  • Replacing every attacker-controlled function name with [UNK_SELECTOR] raises FNR from 1.56% to 2.26% (+0.70 percentage points).Attacker-controlled calls account for 1.30% of call traces, leaving 98.70% of retained calls to invoke non-attacker contracts under the attribution rule.Source: §7.7 · p. 12
  • In the Cream incident, removing calls safely requires exploit-specific reasoning: victim-side borrows, liquidation, seizure, and redemption preserve exploit execution and profitability.Preparatory calls such as Uniswap.swap can be performed separately, while calls transferring realized profit to the attacker’s wallet can be omitted; AMPMarket.liquidate must remain for the exploit to be profitable.Source: §7.7 · p. 12

8 Threats to Validity

The reported findings are bounded by dataset-label uncertainty, proxy-based attacker attribution, categorization choices, data drift, and private transaction submission.

Threats to Validity

  • Community-contributed DeFiHackLab labels may be inconsistent, affecting TxLucent and other supervised detectors.The authors also note that unknown attacks may remain in the benign set.Source: §8 · p. 12
  • The reported 0.0017% FPR is a conservative upper bound because undiscovered attacks in the benign set may be counted as false positives.Web searching found one unreported attack that was counted as a false positive.Source: §8 · p. 13
  • Using the root call’s callee as the attacker proxy can overstate the attacker call share when attackers also use auxiliary contracts.Source: §8 · p. 13
  • Different attack-category definitions may affect comparisons; for example, Hunting treats flash-loan attacks separately, while TxLucent treats flash loans as tools.TxLucent's categorization derives from DeFiHackLab, with some categories manually refined or merged.Source: §8 · p. 13
  • New attack vectors and changing dApp logic may require retraining after distribution shifts, adding maintenance overhead.The authors report zero FNR on the pre-2022 CLUE and Hunting datasets and 1.15% FNR in an older-to-recent ablation.Source: §8 · p. 13
  • Private transaction submission can postpone external TxLucent detection until the block becomes public; this limitation is shared by transaction-based detectors.Pre-commit detection assumes public mempool propagation or submission to a participating builder or validator.Source: §8 · p. 13

9 Related Work

Related transaction-analysis systems use network, trace, transfer, or graph representations, often for specific behaviors or with extra setup requirements. TxLucent instead uses selector-derived function-name sequences without source code or per-dApp rules.

Transaction-Level Analysis

  • Transaction-level approaches include account-transaction networks [27] [60], internal-call clustering, transfer-oriented detectors, and trace-based systems.The passage distinguishes these representations and notes that TxSpector and MoE remain specialized to particular attack categories.Source: §9 · p. 13

Sequence-Based Detection

  • Earlier host-based intrusion detectors used operating-system-call sequences [20,26] and neural system-call models, but the authors say these are inapplicable to blockchain attack detection.The passage distinguishes them by features and blockchain latency constraints.Source: §9 · p. 13

Application-Attack Detectors

  • CLUE, Hunting, and HOUSTON use richer protocol-specific features but require graph reconstruction, source artifacts, historical transactions, or per-contract setup.TxLucent instead uses selector-derived name sequences and structural position, requiring neither source code nor per-dApp rules.Source: §9 · p. 13

Adjacent Systems

  • Exploit synthesis and mitigation systems [41] [48] [72] and transaction-interpretation tools do not perform general attack detection; BlockGPT [22] ranks anomalies per contract.BlockGPT's output is not comparable with the paper's binary-prediction evaluation.Source: §9 · p. 13

10 Conclusion

TxLucent detects blockchain application attacks by learning transaction semantics from function-name sequences. Its reported results combine low error rates, broad function-name coverage, and fast analysis.

Conclusion

  • TxLucent maps call traces to function-name sequences and learns their semantics with a Transformer, without relying on hand-crafted patterns or contract source code.The authors report 24.90-millisecond mean detection time, 74.86% median alignment with available incident reports, and an FNR increase from 1.56% to 2.26% under simulated evasion.Source: §10 · p. 13
  • 1.56% incident-level FNR and 0.0017% transaction-level FPR were reported, outperforming the length heuristic (31.31% FNR), CLUE (70.77%), and Hunting (83.17%).Source: §10 · p. 13
  • Function names cover 98.46% of calls, 23.68 percentage points higher than source-code coverage.Source: §10 · p. 13

Ethical Considerations

The work analyzes attack transactions already committed to public blockchains and does not test exploits against live chains. Identified issues in three repositories or datasets were disclosed and corrected through merged pull requests.

Ethical Considerations

  • The study analyzes attacks already committed to public blockchains; it neither conducted active attacks nor tested exploits against live chains.Source: Ethical Considerations · p. 14
  • Researchers identified issues in the DeFiHackLab repository and the Hunting and CLUE datasets and implementations, then responsibly disclosed them to maintainers.Source: Ethical Considerations · p. 14
  • Corrective pull requests addressing the disclosed issues have since been merged into the corresponding repositories.Source: Ethical Considerations · p. 14

Open Science

The appendices explain how Solidity calls become traceable function identifiers, define the attack taxonomy, and examine function-name frequency coverage. They also describe the planned research-artifact release.

Open Science

  • The planned artifact includes incident metadata, attack and victim transactions, a selector-to-name database, training code, and analysis scripts.The full 537,069,442-transaction benign dataset is too large to distribute, so the release will include a 171,584-transaction subset; runtime results may not reproduce on different hardware.Source: Open Science · p. 14

A How Solidity and EVM Handle Functions

  • Solidity signatures are hashed into 4-byte selectors, and Geth represents nested call frames as a tree.Call traces record transaction-specific information; contract creation, SELFDESTRUCT, and ETH-transfer frames are hard-coded as names because they also contribute to transaction semantics and attack detection.Source: A How Solidity and EVM Handle Functions · p. 18

B Taxonomy of Blockchain Application Attacks

  • The taxonomy covers unauthorized or unintended outcomes from exploiting dApp state or business logic, including price-oracle, access-control, and arbitrary-call vulnerabilities [73].The authors derive it from community incident categories and manually refine or merge some categories.Source: B Taxonomy of Blockchain Application… · p. 19, Table 4 · p. 19

C Long-Tail Distribution of Function Names

  • 51.09%, 82.83%, and 97.26% of all selector-bearing call traces are covered by the top 10, 100, and 1,000 names, respectively.Coverage uses all 5,632,984 selector-bearing call traces as the denominator, including traces unresolved by the database; Figure 10 depicts the long-tail distribution.Source: C Long-Tail Distribution of Function… · p. 19, Figure 10 · p. 20

D Experiments on Comparison Datasets

The comparison experiments test TxLucent and prior detectors on datasets collected by other studies and on HOUSTON’s interaction model. They also examine apparent benign-set positives, including one identified attack.

D Experiments on Comparison Datasets

  • Only 29 of 139 CLUE transactions and 24 of 116 Hunting transactions overlap with TxLucent’s attack dataset; the comparison datasets are older and narrower in chain or category coverage.The comparison datasets were collected before August 2022, while DeFiHackLab includes incidents through March 2026.Source: D Experiments on Comparison Datasets · p. 20
  • 62.93% FNR for Hunting on its dataset and 17.86% for CLUE on its dataset suggest both baselines may have limited generalizability to other datasets.The table marks each baseline evaluated on its own dataset and identifies the lowest FNR in each row.Source: D Experiments on Comparison Datasets · p. 20
  • 0% FNR on both the Hunting and CLUE datasets without retraining supports TxLucent’s generalization across the evaluated datasets, attack categories, and time periods.The authors note that differences in training-data scale and recency may also contribute to this cross-dataset behavior.Source: D Experiments on Comparison Datasets · p. 20

E HOUSTON Interaction-Model Comparison

  • On HOUSTON’s attack-only dataset, TxLucent had 2.61% FNR and 0.130-second runtime versus the interaction model’s 25.45% FNR and 324.85 seconds.This evaluates only HOUSTON’s runnable, source-code-independent interaction model, not its complete detector; TxLucent’s runtime was longer on this attack-only dataset because its transactions were more complex to analyze.Source: Table 6 · p. 21, E HOUSTON Interaction-Model Comparison · p. 21

F False Positives Analysis

  • For remaining apparent positives, the analysis ranks function names by positive attribution and categorizes transactions by their dominant function type.The analysis uses LIG after removing transactions identified as reported attacks.Source: F False Positives Analysis · p. 21
  • Exact-hash searches identified one of 9,228 apparent positives as a reported attack, leaving 9,227 for further analysis.The identified ReferralFeeReceiver exploit involved improper access checks and an approximately $4.3K loss; the authors could not manually verify the remaining positives or rule out other unreported attacks.Source: F False Positives Analysis · p. 21
Loading 2609.12315v1…