Blockchain Attack Detection

Isai Alexei

Blockchain Attack Detection Reaches 1.56% False Negatives Using Only Function Names

Blockchain, DeFi attack, TxLucent

Blockchain attack detection gains broader coverage from a signal most detectors ignore: function names. TxLucent, a detector from the University of British Columbia, converts transaction call traces into function name sequences and classifies them with a Transformer, reaching a 1.56% false negative rate on 424 real incidents and a 0.0017% false positive rate on 537 million Ethereum transactions.

Why Blockchain Attack Detection Needs New Inputs

Blockchain application attacks exploit business logic bugs in decentralized applications (dApps) and account for 42% of incidents on popular blockchains since 2022, with losses in the billions of dollars. An attacker manipulates the state of one dApp to compromise a dependent dApp, so the flaw sits in how contracts interact and not in the underlying network.

Existing detectors fall into two groups: off-chain detectors like Hunting read smart contract source code and comments to infer expected behavior, yet only 74.78% of call traces in the test data touch contracts with published source. On-chain detectors like CLUE lift low-level features into execution graphs and match handcrafted patterns, which demands manual work for every attack category and every new protocol. Both groups limit blockchain attack detection to the contracts and attack types their maintainers can curate.

Function Names as the Detection Signal

Developers of smart contracts pick descriptive function names, and Ethereum Request for Comments (ERC) standards fix the names of common operations: ERC20 tokens expose transfer, approve and transferFrom, ERC4626 vaults expose deposit and withdraw, and ERC3156 flash loans expose flashLoan. Uniswap routers use swapExactTokensForTokens and addLiquidity, and lending platforms converge on supply, borrow, repay and liquidate.

Blockchain attack detection input coverage: function names resolve 98.46% of call traces versus 74.78% for source code
Figure 1. Blockchain attack detection input coverage

Lookup granularity explains the coverage gap: source code is indexed by contract address, while a function selector, the four-byte hash prefix in every call, recurs across contracts. A selector-to-name database built from the Sourcify dataset resolves names for 98.46% of 5,632,984 call traces drawn from 149,276 transactions, against 74.78% with available source code, a gap of 23.68 percentage points.

Among the 1,420,798 call traces without source code, the database still resolves 95.22%, so blockchain attack detection based on names keeps its input where source-based methods lose it.

How the Detector Reads a Transaction

TxLucent has two components: the sequence builder rebuilds the call trace tree of a transaction, orders calls in pre-order and replaces each selector with its name from the database; unresolved selectors map to an unknown token. The classifier encodes the name sequence with an 8,192-token tokenizer and feeds it to a four-layer, eight-head Transformer encoder with a linear head outputting attack or benign.

The implementation runs 3,285 lines of Python. The scope of blockchain attack detection covers EVM-compatible chains and excludes 51% attacks, eclipse attacks, phishing, private-key theft and Solidity language flaws like integer overflow; the modeled attacker submits transactions and may deploy auxiliary contracts.

TxLucent pipeline for blockchain attack detection: call traces to function name sequences to Transformer classifier, with Cream Finance example
Figure 2. TxLucent pipeline for blockchain attack detection

The Cream Finance incident shows the signal: a routine lending flow runs borrow, repay, seize; the attacker abused a reentrancy flaw through the AMP token callback tokensReceived, which triggered a second borrow before the first updated the debt, and the attacker liquidated its position to seize collateral. The attack transaction reads as borrow, borrow, liquidate, seize, with no repay in between, and the victim-side names expose the deviation without source code.

Accuracy Against Existing Detectors

The DeFiHackLab database lists 688 incidents from July 2017 to March 2026; dropping cases without metadata and out-of-scope cases like bridge, governance and key-compromise attacks leaves 424 incidents for blockchain attack detection, with 14,611 attack transactions, 134,665 victim-history transactions and 537,069,442 benign Ethereum transactions from 2024 and 2025.

Incident-level five-fold cross-validation keeps every incident inside one fold to prevent leakage, and each fold adds 2,048 randomly sampled Ethereum transactions as benign examples, with training using cross-entropy loss and a balanced sampler.

TxLucent misses 1.56% of incidents, while a call-trace length heuristic misses 31.31%, CLUE 70.77% and Hunting 83.17%. The heuristic flags traces with more than 22 calls, the threshold giving its best false negative rate under a 1% false positive budget.

Bar chart of false negative rates: TxLucent 1.56%, length heuristic 31.31%, CLUE 70.77%, Hunting 83.17%
Figure 3. False negative rates comparison

Both baselines rely on older material: CLUE’s patterns derive from attacks through 2022, and Hunting’s pretraining covers contracts deployed before May 2023, while the test incidents run through March 2026. On the older CLUE and Hunting datasets, TxLucent records zero false negatives, so the gap reflects data drift in blockchain attack detection as much as method quality.

On the false-positive side, TxLucent flagged 9,228 of 537,069,442 benign transactions, a 0.0017% false positive rate equal to 12.6 alerts per day over 24 months, a load an operator can triage.

One flagged transaction proved a real attack found by manual search, so the rate is a conservative upper bound. Unknown selectors (48.94%) and token functions (35.76%) account for most remaining alerts. The length heuristic produces a 0.93% false positive rate, about 550 times higher.

Removing function names raises the false negative rate to 8.73%, while removing tree position raises it to 3.30%, so names supply the stronger signal. A chronological test trained on 337 older incidents missed 1 of 87 recent ones, a 1.15% rate, which shows names keep working as dApp code changes, so blockchain attack detection carries over to new protocols.

Speed, Explainability and Evasión

Detection takes 24.90 milliseconds per transaction on average, with a 95th percentile of 50.03 ms, once traces are available. Hunting averages 59.53 seconds and CLUE 275.43 seconds on the same data; CLUE builds an execution property graph per transaction, so its runtime tracks graph structure and limits blockchain attack detection at block speed.

Among the seven most vulnerable chains in September 2025, block times run from 12.07 seconds on Ethereum to 0.25 seconds on Arbitrum, with Base, Optimism and Polygon near 2 seconds, so typical latency fits inside every block interval. The maximum of 1,819 ms and the exclusion of trace acquisition leave production traffic for testing, and the design targets block builders and validators executing candidate transactions locally.

Chart comparing TxLucent detection latency of 24.90 ms with block times of seven blockchains from 0.25 s to 12.07 s
Figure 4. Detection latency sits far below every block time

Across 184 incidents with public reports, the attributed names align with the documented exploit mechanism at a median score of 74.86%, and the Cream incident scores 97.27%, with the attributed borrow, tokensReceived and seize calls matching the report. A pretrained sentence encoder ranks the true report among all 184, so higher scores mean more specific fits.

Attackers can rename functions only in contracts they control, which supply 1.30% of call traces in attack transactions; victim contracts supply the other 98.70% and keep their names. Replacing every attacker-controlled name with the unknown token raises the false negative rate from 1.56% to 2.26%. Private submission through a relay or a non-participating validator remains a gap for blockchain attack detection, because alerts arrive only after the block becomes public, a limit shared by all transaction-based detectors.