The wallet looked normal on the explorer. Six EIP-7702 signatures said otherwise.

Description and use

A wallet that appeared as a normal EOA automatically forwarded any received funds to a hard‑coded address due to EIP‑7702 delegation. The issue was uncovered by inspecting the code, delegate logic, and authorization tuples.

Problem

A wallet appeared as a normal EOA on the explorer, but incoming funds were automatically forwarded to another address due to EIP‑7702 delegation.

Outcome

The wallet was a delegated EOA that automatically forwarded any received funds to a hard‑coded address, effectively draining it. The issue was uncovered by inspecting the code prefix, delegate logic, and authorization tuples.

Workflow

• 1. Query the wallet’s code with eth_getCode. If the response starts with 0xef0100, the account is delegated and the next 20 bytes give the delegate address.
• 2. Retrieve the delegate contract’s code and analyze its logic. In this case, the bytecode forwards any received value to a hard‑coded address.
• 3. Pull all Authorization tuples from the delegating transactions and recover the signer with ecrecover. All tuples were signed by the same key and pointed to the same delegate.
• 4. Conclude that the wallet is a drainer and avoid sending any non‑zero amount to it.

Evidence

On the explorer it looked ordinary: an EOA, a short history, nothing flagged.

Source

EIP‑7702 lets an EOA set code for itself. The owner signs an authorization tuple and the account's code becomes a delegation designator: 0xef0100 || <delegate address>.

Source

Recovering the signer from each tuple showed all six authorizations came from the same key, and all six pointed at the same delegate.

Source

Read the code, not the history. eth_getCode on the address. Empty response = plain EOA. Code starting with 0xef0100 = delegated: the next 20 bytes are the delegate address.

Source

Read the delegate. Take that address and read its code. Ask what happens on a plain value transfer: does it forward? To whom? Is the destination hardcoded?

Source

Read the authorizations. Pull the Authorization tuples for the account (they're in the transaction data of the delegating txs). Verify the signer with ecrecover. A tuple signed by someone who isn't the account's owner is a red flag that outranks everything else.

Source