EIP-7702 Malicious Delegation: Check What Your Address Authorized

An EIP-7702 authorization can change the code an existing address uses without moving its funds to a new address. If the delegated implementation is malicious, the familiar address is not evidence of familiar behaviour. Check the exact network and implementation through your wallet’s supported process, stop new deposits while investigating an unexplained change, and distinguish code delegation from ordinary token allowances.

The address can stay the same while execution changes

The EIP-7702 specification describes an externally owned account pointing to code that executes in its context. The delegation is persistent rather than disappearing automatically when the initiating operation finishes. The specification also says processed delegation indicators are not rolled back merely because the transaction’s later execution fails. An error banner is therefore not a substitute for checking the account’s resulting state.

This is useful functionality when implemented intentionally through a trusted wallet. Batching and sponsored execution are possible applications; they are not evidence that any request labelled an upgrade is legitimate. The security decision concerns the actual code and authorization, not the promise of lower fees or a convenient single confirmation. A no-value request can still be significant if it changes the account’s execution authority.

A fictional user, Lena, approves a supposed reward-verification request. Her address still looks the same, and she assumes the absence of an immediate outgoing transfer means nothing changed. Later she sees an unfamiliar delegation. Her next step is to establish what was authorized and whether it is an expected wallet feature, rather than making another deposit to test whether the address still works.

Separate the permission layers before choosing a repair

The existing allowance guide explains the token-spending layer. Use it for that question without treating an allowance list as a complete account-security report. Similarly, a wallet’s disconnect feature can be useful for stopping further requests, while leaving a separate on-chain state to investigate. Record which layer each proposed action actually changes.

Do not conflate a legitimate application’s limited session with a raw EIP-7702 authorization. Their enforcement mechanisms and scope can differ. Ask the wallet to identify the request and its consequences in terms you can verify. If the explanation relies on a vague assurance that all signatures are just logins, decline the request and use the official support route.

How to investigate an unfamiliar delegate without granting more access

1. Record the account address, network, wallet version and when the unfamiliar delegation was observed.
2. Save the relevant authorization or transaction reference if available, plus the request that preceded it. Avoid publishing private customer or order details.
3. Compare the delegated implementation with the wallet provider’s official information for that exact network. An explorer label alone is not a code review.
4. Check whether smart-account functionality was intentionally enabled through the wallet. Do not assume every delegation is malicious or every familiar label is safe.
5. If the implementation or request remains unexplained, pause new deposits and ask official support for an account-specific assessment before signing a purported repair.
6. After any supported change, verify the resulting state and separately assess disclosed secrets, outstanding permissions and funds already moved.

Ethereum’s EIP-7702 guidelines discuss the importance of wallet-managed implementations and the risks of changing delegation logic. Ordinary users should not be expected to audit arbitrary delegate code themselves. Use a supported wallet flow with a documented implementation rather than authorizing a contract address supplied by a giveaway page or a private message.

The delegate implementation address and an eventual receiving address in a suspicious outgoing transfer need not be the same. Keep both roles in the evidence. Otherwise a search for the final recipient can miss the implementation that changed the account’s behaviour. Do not infer a person’s identity from either address or describe an implementation as malicious solely because you do not recognize its label.

What a wallet’s revoke control can and cannot settle

MetaMask’s current switch-back instructions describe a per-network smart-account control and a transaction to confirm the change. That is a documented path for its supported account flow, not proof that any third-party repair page is safe. Read the current instructions for your application and inspect the confirmed result rather than relying only on a toggle’s visual position.

Changing wallet apps does not by itself replace the account’s on-chain code setting. Nor should a successful removal be described as restoring stolen funds or clearing all possible consequences. Existing token allowances, application-level permissions and previously disclosed secrets need their own assessment. If a seed or private key was exposed, a code-setting change cannot make that secret unknown to the other party.

The Relay warning about malicious delegations describes cases where a correctly delivered incoming payment was followed by an unwanted movement. That is a reason to inspect recipient state and the subsequent movement, rather than assuming the latest sender caused the loss. Its incident examples are not proof that every ordinary deposit always triggers code execution or that every unfamiliar delegate means a seed was stolen.

Avoid turning the investigation into a second authorization

Do not connect to an unsolicited checker and sign because it claims revocation is urgent. Public account inspection and a state-changing transaction are different actions. A tool that reads an address should not need your recovery words. If a genuine wallet requires an on-chain change, the request should explain the network, action and cost before you approve it; no fixed repair fee or guaranteed completion time follows from the EIP itself.

Avoid repeated gas top-ups to a wallet whose behaviour is still unexplained. There may be competing or automated activity, and the right containment depends on whether the account’s keys, code or application permissions are affected. Request help through an independently verified channel. Do not follow a gas race, rescue script or raw authorization payload from a stranger as a substitute for identifying the exposure.

Uniswap’s smart-wallet explanation illustrates a legitimate EIP-7702 use with its own implementation. It does not endorse an arbitrary delegate requested by another site. Keep the distinction between a provider’s documented feature and a third party’s imitation of its wording. The same address and the same promise of convenience can appear in very different authorization contexts.

Close the case with an account-state record

A useful support packet identifies what Lena observed, what she signed, whether she entered any secret, and the relevant network and references. After the reviewed response, it records the resulting delegate state, any remaining unresolved permissions and any outgoing transactions still under investigation. ‘The website is disconnected’ is only one observation; it is not the closing evidence for every layer in the table.

Before receiving through a fresh order or making another transfer, establish a trusted destination and verify its current state. The Ethereum page provides network context, while a no-account swap is a separate service operation with its own accepted destinations. Neither an exchange quote nor a correctly copied address establishes that the receiving account’s delegated implementation is the one you intended to authorize.