EIP-7702 Phishing Attack
Source: arXiv:2512.12174 · Published 2025-12-13 · By Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen
TL;DR
The paper analyzes EIP-7702, a delegation-based Ethereum authorization scheme that allows an externally owned account (EOA) to sign a single authorization tuple which reroutes all subsequent calls to arbitrary delegate code under the victim's address. This fundamentally shifts attack surfaces by enabling persistent, unconditional execution control given to an attacker upon one signature, rather than transaction-by-transaction phishing. Through controlled experiments, the authors identify three distinct trigger pathways (user-driven, attacker-driven, protocol-triggered) that reliably lead to full account takeover and asset drainage. They extend the attack surface by showing composability with ERC-4337's EntryPoint for remote activation without victim involvement, and cross-chain replay-like compromises when chain-agnostic authorization is enabled.
Empirically, they measure over 150k authorization and execution events across 26k unique addresses and hundreds of delegator contracts on major EVM chains. Their data reveals extreme centralization with a few contract families linked to criminal activity repeatedly reused in diverse incidents. Losses span ETH, ERC-20 tokens, and NFTs, evidencing large-scale exploitation in the wild. The paper concludes with concrete proposals for protocol-level mitigations to constrain this delegation-based phishing vector.
This work establishes that EIP-7702's delegation mechanism opens fundamentally new and practical phishing vectors with persistent, cross-context, and cross-chain implications that defy traditional signature-level security assumptions. It combines a thorough security characterization, practical exploitation demonstrations, and real-world telemetry, highlighting an urgent need for ecosystem and protocol changes.
Key findings
- A single signed EIP-7702 authorization tuple grants persistent, unconditional execution control over the victim's EOA, enabling full account takeover and asset drainage.
- Three reliable trigger pathways can activate the malicious delegation: (i) user-driven transactions, (ii) attacker-driven external calls, and (iii) ambient protocol callbacks.
- Composability with ERC-4337 EntryPoint allows remote and repeated triggering of the delegated malicious code without further victim interaction.
- Chain-agnostic authorization mode (chainId = 0) enables replay-like delegation compromise across independent EVM-compatible networks.
- Empirical analysis of 150k+ authorization/execution events involving 26k addresses across major EVM chains shows extreme centralization by a small number of delegator contract families linked to criminal activity.
- Substantial on-chain losses documented include theft of ETH, ERC-20 tokens, and NFTs linked to these malicious delegations.
- Malicious delegation contracts typically implement fallback-based sweeping logic that drains all asset types (ERC-20, NFTs, ETH) leveraging victim authority.
- Clients write delegation indicators into the victim code slot after validating the authorization tuple before transaction execution; this state change persists even if execution reverts.
Threat model
The adversary is a blockchain attacker who can induce a victim EOA user to sign a single malicious EIP-7702 authorization tuple—typically via phishing or UI deception—or alternatively has compromised the user's private keys. The attacker cannot forge signatures or break cryptography but controls attacker-deployed contracts that serve as delegate implementations. The attacker can broadcast authorization transactions embedding the tuple and subsequently trigger the malicious delegate code through user or external calls, including ambient protocol callbacks. The attacker lacks consensus-layer abilities or collusion with transaction relayers.
Methodology — deep read
The paper's methodology combines formal modeling, controlled experiments, and large-scale empirical measurement.
- Threat Model & Assumptions:
- Adversary is capable of phishing a victim's signature over an EIP-7702 authorization tuple or possibly has compromised private keys.
- The attacker deploys malicious contract implementations as delegate targets.
- The victim uses standard wallet clients that do not fully reveal delegation semantics in the signature UI.
- Auxiliary entities like relayers/bundlers act honestly and are not colluding or adversarial.
- The attacker cannot break cryptographic signature schemes or consensus rules.
- Data & Empirical Measurement:
- Authors analyze on-chain data from multiple major EVM chains.
- Dataset includes over 150,000 EIP-7702 authorization and execution events, involving 26,000+ unique addresses and hundreds of delegator contracts.
- They label contracts by suspicious/criminal linkage through heuristics and clustering.
- Transaction and event tracing used to characterize attack lifecycles and quantify losses in ETH, ERC-20, and NFT assets.
- Architecture and Attack Construction:
- EIP-7702 introduces a new Ethereum typed transaction (0x04) embedding an authorization list of signed tuples.
- Each tuple encodes chainId, target contract address, expected nonce, and ECDSA signature.
- Upon execution, clients check validity then overwrite the victim EOA's code slot with a delegation marker (0xef0100) plus the target address, redirecting all calls to the attacker contract.
- Malicious delegate contracts implement logic in fallback() to immediately drain any received call of ERC-20 tokens, NFTs, ETH, and optionally perform token swaps.
- Authorization tuples are crafted to appear innocuous in wallet UIs, hiding the malicious delegate address behind opaque numeric fields.
- Training and Execution (Experiment Setup):
- Experiments run on a locally patched Hardhat Ethereum network with chainId 1337.
- Authors extend Hardhat to support EIP-7702 typed transaction processing and delegation state transitions.
- Victim and attacker EOAs preset with 10,000 ETH each to enable reproducible exploits.
- Experiment demonstrates entire attack flow from tuple phishing signature, authTx broadcasting, delegation installation, triggering drain through diverse pathways, and asset sweeping.
- Evaluation Protocol:
- The authors experimentally verify three distinct delegation triggering methods leading to successful balances draining.
- They conduct end-to-end case studies capturing inner transaction traces and onchain states.
- Empirical chain-wide telemetry quantifies total delegations, their concentration by contract family, recurring reuse across incidents, and summed losses.
- Control baselines include standard (non-delegated) EOAs and archival wallets without delegation.
- Reproducibility:
- Implementation details of the EIP-7702 patch for Hardhat and attack contracts are described.
- Data sources are live blockchain data; however, some analysis relies on heuristics not fully detailed, and no public code repository is mentioned for extraction.
Overall, the paper offers a concrete, replicable proof-of-concept attack instantiation end-to-end and supports fundamental findings with large-scale onchain forensic analysis, grounded in the protocol semantics and empirical blockchain event traces.
Technical innovations
- Identification of a new class of persistent phishing attacks enabled by EIP-7702's delegation via a single authorization tuple modifying EOA execution semantics.
- Discovery of three distinct and practical triggering paths (user-driven, attacker-driven, ambient protocol interactions) that activate malicious delegation.
- Demonstration of dangerous composability with ERC-4337's EntryPoint facilitating remote automatic delegate execution without victim intervention.
- Revealing cross-chain replay-like risks when chain-agnostic (chainId=0) delegations are used, allowing a single delegation tuple to compromise multiple independent networks.
- First empirical quantification of EIP-7702 deployment footprints, centralized crime-linked delegation contract reuse, and associated asset losses at a large scale.
Datasets
- EVM chain 7702 authorizations — 150,000+ authorization and execution events — publicly observable on Ethereum, Polygon, BSC etc.
Baselines vs proposed
- Standard EOA (no delegation): no persistent delegation risk, asset flow strictly controlled by signed transactions vs EIP-7702 delegated EOA: single authorization tuple enables permanent execution hijack.
- User-driven tx trigger: no attack possible on normal EOA vs EIP-7702 delegated EOA: any outgoing tx routed to attacker logic enabling balance theft.
- ERC-4337 EntryPoint invocation: not applicable to EOAs vs allowed repeated remote activation of delegate code without victim signatures.
- ChainId-specific authorization: baseline normal authorization vs chain-agnostic (chainId=0) delegation enabling replay across chains.
Figures from the paper
Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2512.12174.

Fig 1: EIP-7702 Transaction Count and Growth Trend.

Fig 2: EIP-7702 phishing attack. The victim signs an authorization

Fig 3: Execution traces produced during the EIP-7702 phishing

Fig 4: In-the-wild EIP-7702 × ERC-4337 composite invocation.

Fig 5 (page 9).

Fig 6 (page 10).

Fig 5: Cross-category comparison of high-loss entities in EIP-7702–related incidents.

Fig 6: Distribution and categorization of delegator contracts in-
Limitations
- Experiments rely on a local Hardhat patch to emulate EIP-7702; native client support was unavailable, potentially limiting exact production behavior replication.
- Empirical attribution of delegator contracts to criminal clusters is heuristic-based and may have false positives/negatives.
- No detailed user behavior study on how victims are phished to sign malicious tuples; real-world UX deception pathways are assumed but not deeply explored.
- Attack evaluation focuses on Ethereum-compatible chains, limiting direct conclusions about non-EVM ecosystems or future protocol variants.
- Proposed mitigations are outlined but not implemented or quantitatively evaluated in live environments.
- Data analysis does not include metrics on how many delegations were disrupted or mitigated by ecosystem tooling.
Open questions / follow-ons
- How can wallet UIs and signature wallets evolve to transparently disclose EIP-7702 delegation semantics to prevent phishing?
- What are effective client- or protocol-level defenses that can limit or revoke malicious delegations post-installation?
- How widespread is user understanding and usage of EIP-7702 delegation, and what UX patterns lead to phishing signatures?
- Can delegation patterns observable via tooling be detected and flagged in real-time to disrupt ongoing exploitation?
Why it matters for bot defense
This research exposes a fundamentally new phishing vector enabled by account abstraction delegation at the protocol layer that allows persistent account control with a single user signature. Bot-defense and CAPTCHA practitioners should recognize that EIP-7702 phishing does not rely on continuous user interaction or transaction-level consent but rather on a one-time delegation signature that hijacks execution. Detection approaches must consider the delegation state transitions and subsequent transaction routing behaviors rather than just suspicious UI or request volumes. Moreover, the ambient and automated retriggering of malicious code through protocols like ERC-4337 EntryPoint means bot detection systems and human challenge-response mechanisms must expand beyond initial signature approval to ongoing transaction flow monitoring. The chain-agnostic cross-network replay risk further complicates defense as delegation compromises may cross service boundaries. Overall, this calls for enhanced signature transparency, delegation state tracking, and composable defense aligned to novel persistent authorization semantics, areas outside traditional CAPTCHA engagement but critical for endpoint trust.
Cite
@article{arxiv2512_12174,
title={ EIP-7702 Phishing Attack },
author={ Minfeng Qi and Qin Wang and Ruiqiang Li and Tianqing Zhu and Shiping Chen },
journal={arXiv preprint arXiv:2512.12174},
year={ 2025 },
url={https://arxiv.org/abs/2512.12174}
}