What is EIP-7702? Turning EOAs into Smart Wallets Explained

Hands-on with EIP-7702: Build, delegate, and upgrade your EOA just like a smart contract—all by making the tests pass.

What's the Big Idea?

Traditionally, Ethereum accounts are divided into two clear categories:

• Externally Owned Accounts (EOAs): These are typical wallets controlled by private keys—like your MetaMask account—that hold ETH and send transactions. They have balances and nonces but no logic or code execution capability.

• Smart Contract Accounts: These contain executable logic stored on-chain. They can execute complex instructions, manage state, and automate transactions.

But what if you could merge the flexibility and simplicity of EOAs with the powerful logic of smart contracts?

That's exactly what EIP-7702 achieves. It lets an EOA delegate its execution to a smart contract while still maintaining its original identity and control.

Delegation

Here's how EIP-7702 delegation changes the game:

• No Deployment Costs: You don't deploy a new contract; you simply delegate your existing wallet.

• Keep Your Identity: Your EOA address, private keys, balance, and nonce remain unchanged.

• Flexible Logic: You can update or revoke the delegated logic at any time, instantly.

The New Transaction Type: AUTHORIZATION_LIST (EIP-7702 Transaction)

EIP-7702 introduces a brand new transaction type that lets your EOA safely and flexibly delegate code execution.

What is the new transaction?

• Name: Authorization List Transaction

• Format: The transaction includes an authorization_list in its payload, containing one or more signed authorizations. Each authorization specifies which implementation contract to delegate to, and includes a nonce for replay protection.

• Key Fields:

  • sender (the EOA address)

  • authorization_list (array of signed authorizations)

  • Each authorization: {chain_id, address, nonce, y_parity, r, s}

  • to, value, data (optional, for a call in the same tx)

What does this transaction do?

• When submitted, the EOA’s code field is set to a special delegation bytecode:

0xef0100 || <Implementation Address>

• The EVM recognizes this as an instruction to delegate all code execution to the target implementation using DELEGATECALL.

How do you use it?

1. Sign a delegation authorization off-chain (e.g., using MetaMask or your own signing tool), specifying the implementation contract address, a unique nonce, and chain id.

2. Submit the Authorization List Transaction to the network. The transaction updates the EOA’s code (or reverts if invalid/nonce mismatch).

3. Immediately, your EOA begins behaving like a smart contract wallet, forwarding calls to the new implementation.

4. You can update or revoke the delegation at any time by submitting a new signed authorization with a higher nonce, or with impl_address = 0x0 to clear delegation and revert to vanilla EOA behavior.

Example Call:

Suppose your EOA is 0xA...123, and you want to delegate to a BatchExecutor contract at 0xB...456:

• You sign: { address: 0xB...456, nonce: 7, y_parity, r, s }

{
  "sender": "0xA...123",
  "authorization_list": [
    {
      "impl_address": "0xB...456",
      "nonce": 7,
      "v": 27,
      "r": "0x...",
      "s": "0x..."
    }
  ]
}

• After confirmation, all code execution for 0xA...123 is delegated to 0xB...456, using your EOA’s storage and balance.

Whenever your EOA receives a transaction, the EVM forwards the execution (via DELEGATECALL) to the specified implementation contract. All execution happens in your EOA’s context—your balance, your state, your control.

Practical Example: BatchExecutor Contract

Let's take a concrete example: the BatchExecutor contract, designed to showcase EIP-7702 delegation.

With BatchExecutor, your EOA can execute multiple transactions in a single atomic operation. Imagine you need to perform several token transfers or calls across different DeFi protocols simultaneously. Instead of manually submitting each transaction, you simply delegate your EOA to the BatchExecutor contract:

• You sign and authorize a delegation to BatchExecutor.

• Instantly, your EOA can call executeBatch, running multiple operations at once.

• Your EOA balance, nonce, and state remain intact, maintaining all the familiar EOA properties.

For concrete code examples and a hands-on workshop, check out the protocol-camp EIP-7702 repository.

You'll find the BatchExecutor implementation, upgrade scenarios, and all related test cases ready for experimentation.

⚙️ But What About Security and Access Control?

Good question. With great power comes great responsibility—and EIP-7702 makes these patterns possible, but does not mandate a specific access control model. How you implement security is entirely up to your delegated contract logic.

In the BatchExecutor example (which is just one possible use case), we show an access control pattern like:

• Owner Control: Only your EOA can trigger batch operations (if the logic is written that way).

• Guardians: You can designate trusted guardian addresses to act on your behalf—useful for shared wallets or recovery (again, if supported by the contract you delegate to).

• Revocable Delegation: At any moment, you can revoke or change the delegation to another logic contract or revert to a standard EOA behavior (this is a core property of EIP-7702 itself).

EIP-7702 delegation also makes upgrades easy and flexible. Suppose you want to enhance your batch execution logic later. You simply delegate your EOA to a new implementation (e.g., from BatchExecutor to BatchExecutorV2). Your EOA’s state persists across the upgrade.

However, developers must ensure storage compatibility between implementations. If done improperly, storage slot collisions might occur, causing unintended data corruption. This is why following storage best practices, like using namespace-based storage slots (as proposed in EIP-7201), is essential.

⚠️ Remember: EIP-7702 just enables delegation. The actual security, permissioning, and flexibility depend entirely on the implementation contract (like BatchExecutor or your own design). Always review and test the logic you delegate to!

🛠️ Getting Hands-On

Ready to see EIP-7702 in action?

The purpose of this learning module is to make all provided tests pass by modifying the smart contracts as needed. As you work through the failing tests and implement fixes, you’ll encounter and solve various issues that can arise with EIP-7702—including delegation logic, access control, storage collisions, upgrade safety, and more. This hands-on approach ensures you learn not only the mechanics of EIP-7702, but also its important design considerations.

You can find all the example code and test cases here: 👉 protocol-camp EIP-7702 repository

Through these tests, you'll:

• Verify delegation setup and execution behavior.

• Test batch operations, access control, and ether reception.

• Ensure upgrade compatibility and safe storage layouts.

Try it Yourself:

forge install
forge test

Dive into the provided tests, fix intentional issues, and learn by solving each challenge step by step!

🎯 Wrapping Up

EIP-7702 is a major step forward for Ethereum wallet and account design. It unlocks the flexibility of smart contract logic for EOAs—without losing the simplicity and direct control developers are used to.

Through this hands-on module, you’ve not only learned how delegation works, but also tackled real-world problems around code delegation, upgrade safety, and access control. As you modify the smart contracts and pass all tests, you gain direct experience with the subtleties and possibilities of EIP-7702.

Whether you’re building advanced wallets, dApps, or experimenting with new forms of user control, EIP-7702 provides a flexible foundation.

Ready to build the next generation of smart wallets?