EIP-7702 changes how Ethereum accounts work. An externally owned account (EOA), traditionally controlled through a private key, can now delegate its code execution to an existing smart contract while keeping its original address.

This enables features such as transaction batching, gas sponsorship, and programmable wallet logic. But it also introduces new security assumptions.

The interesting question is not simply whether the delegated contract has a vulnerability. It is what happens when delegation, signatures, initialization, storage, and external calls interact.

The real challenge is finding vulnerabilities in the interactions between these components, not just inside individual functions.

1. Understand the change before looking for bugs

Before EIP-7702, an EOA did not execute custom smart-contract code when another account called it.

With EIP-7702, the account owner signs an authorization that points to a contract whose code the EOA will use.

The important details are:

  • The delegated code comes from the target contract.
  • It executes in the EOA’s context, using the EOA’s address, storage, and balance.
  • The delegation remains until another valid authorization changes or clears it.
  • The original private key retains full control over the account, including the ability to change its delegation.

One distinction matters here: EIP-7702 provides code delegation, not automatic wallet security.

Features such as session keys, spending limits, recovery, and operation signatures must still be correctly implemented by the delegated wallet.

This means the security model depends on both the EIP’s authorization rules and the implementation of the delegated code.

2. Where can the security assumptions break?

I would approach EIP-7702 by mapping its trust boundaries.

Who authorizes delegation? Who submits the authorization? Who can initialize the account? Which signatures approve actual operations? Which external contracts can influence execution?

These questions help identify attack paths that are not obvious from reading a single function.

A. Delegation succeeds, but initialization fails

Consider this sequence:

  1. Alice signs an authorization to delegate her EOA to a wallet implementation.
  2. A relayer submits a transaction containing that authorization and an initialization call.
  3. The EIP-7702 authorization is processed before the transaction’s execution.
  4. The initialization call then reverts.
  5. The delegation remains in place, even though the transaction execution failed.

The account can now be delegated but still uninitialized.

What happens next?

If the wallet exposes an initialization function that accepts configuration from an arbitrary caller, an attacker may attempt to initialize the account with their own parameters.

The important point is the interaction between two separate operations: delegation and initialization.

A transaction that looks atomic to the application developer does not necessarily make these two effects atomic at the protocol level.

A safer implementation should authenticate the initialization parameters, for example through an initWithSig function that verifies a signature over the intended configuration.

B. Old storage can become dangerous after delegation changes

Delegation changes do not automatically clear the EOA’s storage.

Imagine:

  • Implementation A stores the account owner in one storage slot.
  • Implementation B uses that same slot for a permission or configuration value.

When the account changes its delegation from A to B, the old storage remains.

The new implementation may interpret the old value differently.

This is especially interesting when investigating wallet upgrades, module installation, migration functions, and permission systems.

The research question is:

Can state created under one implementation violate the security assumptions of another implementation?

C. A signature may approve more than the user intended

Delegated wallets often use signatures to authorize operations.

But a signature is only as strong as the data it actually covers.

For example, imagine a user signs an operation but the signature does not bind the target contract or calldata.

A relayer may be able to change the operation before execution.

The account could then execute something different from what the user intended.

Researchers should examine whether signatures cover the exact operation, including the target, calldata, value, nonce, and relevant execution parameters.

Also, the EIP-7702 authorization signature and a wallet’s operation signature are different things. The first authorizes code delegation; the wallet must separately enforce authorization for the operations it executes.

D. Cross-chain authorization may mean trusting different code

EIP-7702 supports authorizations with chain_id = 0, meaning the authorization is not restricted to one chain.

However, the same contract address does not guarantee identical code on every chain.

A user may delegate to address X on two different chains, while X contains different code on those chains.

The authorization can be valid, but the account may execute code with different security properties.

A researcher should compare the actual code and deployment assumptions across supported chains, rather than checking addresses alone.

E. Old EOA assumptions can break in other protocols

Some protocols use:

require(msg.sender == tx.origin);

This is sometimes used to prevent contract-based interactions or as a weak defence against reentrancy.

But a delegated EOA can execute code and call another contract. That external contract can then see msg.sender == tx.origin, even though the check is happening in a deeper execution frame.

This means the check is no longer a reliable way to prevent reentrancy.

The broader research question is:

Which existing protocols rely on account behaviour that EIP-7702 has changed?

These examples are known security concerns, not claims of newly discovered vulnerabilities. The research opportunity is to find implementation-specific ways in which they combine and produce a reachable exploit.

3. Look for interactions, not isolated bugs

The attack surfaces above become more interesting when combined.

For example:

  • A delegation change leaves old storage intact.
  • The new implementation interprets that storage differently.
  • An old signed operation is still accepted.
  • The operation reaches an execution path that trusts the outdated permission state.

Each component might appear correct when reviewed independently. The problem may only become visible when we connect the state transitions.

This is how I would structure the investigation:

Research area Main question
Delegation Can authorization be submitted or applied in an unexpected sequence?
Initialization Can an attacker control the initial account configuration?
Storage Can old state become dangerous after a delegation change?
Signatures Can an approved operation be changed or replayed?
Cross-chain Does the same delegation point to different code across chains?
Integration Do other protocols rely on assumptions that are no longer valid?

The goal is not to collect suspicious code patterns. It is to construct realistic attacker sequences and identify which security property they violate.

4. Using LLMs to explore hidden attack paths

LLMs can help researchers understand large codebases, connect functions, explore different scenarios, generate hypotheses, and build test cases.

But simply asking an LLM to “find vulnerabilities” is not enough.

The approach described by Trail of Bits in How we use /goal to find bugs in Patch the Planet offers a useful direction.

One important lesson is to define the result we want without forcing the model to follow one fixed path.

I would apply that idea in three stages.

First: Understand the complete system.

Ask the LLM to map the account’s actors, permissions, execution flow, storage, signatures, external dependencies, and trust boundaries.

The result should explain how the system behaves, not simply summarize each Solidity file.

Second: Explore separate attack surfaces.

Give independent research goals to different agents.

For example, one agent investigates initialization and delegation, another investigates signature validation, and another investigates storage migration.

Keep one main security outcome per agent. Do not mix vulnerability discovery with unrelated goals such as maximizing code coverage.

Third: Connect the findings.

After understanding individual components, ask the LLM to explore multi-step scenarios involving different actors and transactions.

For example:

  • Can a delegation change affect an already signed operation?
  • Can a failed initialization leave dangerous account state?
  • Can an external call change permissions used by a later operation?
  • Can an authorization valid on multiple chains lead to different execution behaviour?

The model should be free to explore different paths rather than being told the exact function or bug to find.

5. A research goal for an LLM

Here is an example of how I would define the task:

Investigate this EIP-7702 wallet implementation for a previously unknown, reachable security vulnerability.

First understand the account’s execution model, authorization flow, initialization, storage layout, signature validation, relayer interactions, and external dependencies.

Build a threat model based on realistic attacker capabilities. Explore interactions between delegation changes, initialization, persistent storage, nonce transitions, signed operations, cross-chain behaviour, and external calls.

Look for multi-step attack paths that violate account ownership, authorization, asset control, or execution-security properties.

Do not assume access to the owner’s private key or privileged permissions unless explicitly allowed by the threat model.

Do not report a vulnerability based only on suspicious code or a theoretical state. Demonstrate that the required state is reachable and build a minimal reproducible test showing meaningful impact.

Challenge your own hypotheses. Search for checks or protocol rules that might prevent the attack. If no valid vulnerability is found, explain what was explored and why the candidates failed.

This goal defines what counts as a meaningful result without prescribing exactly how the LLM must find it.

6. A hypothesis is not a vulnerability

LLMs can generate many attack scenarios. Some will be useful; others will depend on impossible states or incorrect assumptions.

Every candidate should pass these checks:

  1. Reachability: Can an attacker reach the required state?
  2. Authority: Does the attacker actually have the required permissions?
  3. Invariant violation: What exact security property is broken?
  4. Reproduction: Can we demonstrate it with a test?
  5. Impact: Does it cause unauthorized execution, asset loss, account takeover, or another meaningful security consequence?
  6. Falsification: Is there another check or protocol rule that prevents the attack?

I would also use an independent validation pass to challenge each candidate before accepting it.

A counterexample is a reason to investigate, not proof of a vulnerability.

The researcher’s job is still to understand the protocol, question the assumptions, reproduce the behaviour, and decide whether the impact is real.

Conclusion

EIP-7702 changes more than how an account executes transactions. It changes the assumptions that wallets, relayers, and other protocols make about EOAs.

Its security risks cannot be understood by looking only at the delegation mechanism or the delegated contract.

The more interesting attack paths emerge when we connect different actors, signatures, storage states, transactions, and external contracts.

LLMs can help explore these combinations at scale. But finding useful vulnerabilities still depends on a clear threat model, well-defined research goals, and proof of exploitability.

The goal is not to ask AI to find bugs in EIP-7702. It is to use AI to explore how the entire system can fail when its security assumptions interact.

References