Biconomy Blog
· 9 min read

A Comprehensive EIP-7702 Guide for Apps

A Comprehensive EIP-7702 Guide for Apps

What Problem Does EIP-7702 Solve?

Anyone who has built dApps knows that the blockchain user experience has significant friction. Users must sign multiple transactions for simple operations, pay gas fees in native tokens only, and manage private keys that give full access to their accounts. These limitations stem from the basic structure of Externally Owned Accounts (EOAs) - the standard user accounts on Ethereum.

EIP-7702 aims to solve these user experience issues by allowing EOAs to delegate their execution to smart contracts, effectively giving them programmable capabilities without requiring users to migrate to entirely new wallets.

Why Users Don't Want to Migrate to Smart Accounts

While smart accounts offer superior functionality, getting users to migrate from their existing EOAs to smart accounts is challenging for several important reasons:

Onboarding Friction

Smart accounts require users to:

Loss of Account History and Identity

When a user migrates to a smart account:

Limited Portability

EOAs have universal portability across wallets:

Smart accounts have limited portability:

These migration barriers explain why, despite the benefits of smart accounts, most users continue to use EOAs. EIP-7702 attempts to bridge this gap by bringing smart account capabilities to existing EOAs without requiring users to change their addresses or migrate funds.

The Current Ethereum Account Landscape

Before diving into EIP-7702, let's review the current Ethereum account types:

  1. Externally Owned Accounts (EOAs): These are the traditional user accounts controlled by private keys. When you create a MetaMask wallet, you're creating an EOA. These accounts:
    • Can initiate transactions
    • Cannot contain code
    • Are controlled entirely by a private key
    • Must pay gas in native ETH
  2. Contract Accounts: These are the smart contracts you deploy. They:
    • Contain and execute code
    • Are controlled by their code logic
    • Cannot initiate transactions (only respond to them)
    • Cannot pay gas directly (the caller pays)
  3. Smart Accounts: These are smart contracts designed to function as user accounts. They offer numerous programmable features:There are several standards in this space (ERC-4337, ERC-7579, ERC-6900) and multiple providers offering smart account solutions like Biconomy Nexus, Safe, Kernel, Alchemy, and others. While these implementations may differ in architecture, they all aim to provide enhanced capabilities beyond what EOAs can offer.
    • Multiple authorization methods: Including multi-signature requirements, social recovery, and time-locks
    • Gas abstraction: Paying fees in tokens other than ETH or having fees sponsored by third parties
    • Batched transactions: Execute multiple operations in a single transaction
    • Programmable permissions: Session keys, spending limits, and application-specific permissions
    • Recovery mechanisms: Options to recover access without seed phrases
    • Modular components: Pluggable validations, executions, hooks, and fallbacks

The problem is that most users have EOAs from wallets like MetaMask, and migrating to Smart Accounts requires additional steps and education. EIP-7702 offers a middle path by enhancing EOAs with some smart account features.

EIP-7702: A Technical Overview

EIP-7702 introduces a new transaction type that includes an "authorizations" field. This field allows EOA owners to delegate their account's execution to a smart contract. In simpler terms, your EOA can say: "When I receive transactions, run this smart contract code instead."

How It Works:

  1. A user signs a special authorization message from their EOA
  2. This authorization is included in a transaction
  3. When processed, the Ethereum network records that this EOA should delegate to a specific smart contract
  4. Future transactions to this EOA will execute the smart contract's code
  5. Importantly, the msg.sender in these transactions remains the EOA's address

This is different from a proxy contract because the delegation happens at the protocol level - there's no separate contract deployed for each user. Instead, the EOA appears to have code attached to it directly.

What Can EIP-7702 Do?

EIP-7702 enables three primary enhancements to EOAs:

1. Transaction Batching

Currently, common operations like "approve token and swap" require two separate transactions. With EIP-7702, these can be combined into a single atomic transaction. For example, a DEX could allow users to approve and swap tokens in one transaction, reducing gas costs and improving UX.

More advanced batching might include operations where the output of one step becomes the input to the next step.

2. Gas Sponsorship

EIP-7702 enables third-party gas payment scenarios. For instance:

3. Permission Management

Users can create sub-keys with limited permissions, such as:

Important Limitations

Despite these benefits, EIP-7702 has key limitations that distinguish it from full smart accounts:

  1. The EOA's Private Key Remains All-Powerful: The private key can always override any delegation by signing a new transaction. This means you cannot implement true multi-sig or time-lock functionality.
  2. No Deployment Permanence: Unlike a deployed smart contract account with its own address, an EIP-7702 delegation can be overwritten. This means the EOA is still fundamentally an EOA with smart features, not a true smart account.
  3. Multichain Challenges: By default, EIP-7702 authorizations are chain-specific, which means users would need to sign separate authorizations for each chain. There is a workaround where users can sign an authorization with chain_id set to 0, which will be valid across all chains. However, this approach only works if the user's EOA has the same nonce on all chains, which is rarely the case in practice. This limitation can lead to synchronization issues when working with multiple chains.

Who Controls EIP-7702? Wallets, Not Apps

This is crucial to understand: EIP-7702 is controlled by wallets, not applications.

Although technically any entity could create an EIP-7702 authorization, wallet providers have made it clear that they will reject transactions containing authorization fields from applications. Instead, wallets will manage EIP-7702 authorizations themselves, upgrading their users to the wallet's chosen smart account implementation.

This means:

The Special Case of Embedded Wallets

Embedded wallets such as Privy, Dynamic, Web3Auth, Magic, and others represent a distinct category with potentially different EIP-7702 implementation strategies. Unlike standalone wallets, embedded wallet providers might allow developers to delegate to custom smart contract account implementations.

Based on conversations with embedded wallet developers, it appears they plan to establish sensible defaults with their own implementations while enabling developers to override these defaults when needed. This could provide application developers with more flexibility in how they leverage EIP-7702 features.

The full details of these implementation strategies remain to be seen, as embedded wallet providers have not yet publicly announced their specific plans for EIP-7702 support. More information will become available as these providers release their official implementations.

How Applications Can Use EIP-7702 Features

Since applications cannot directly control EIP-7702 authorizations, how can they benefit from these features? Several approaches are emerging:

The ERC-7710/7715 Approach

This approach combines EIP-7702 with two additional standards:

The flow works like this:

  1. A wallet uses EIP-7702 to delegate the user's EOA to a smart contract that supports EIP-7710
  2. An application requests permission via EIP-7715 to spend funds from the user's account
  3. The wallet displays this request to the user
  4. If approved, the application can now execute actions through the delegation

Applications can either:

The ERC-5792 Approach

This approach utilizes the wallet_sendCalls JSON-RPC method defined in ERC-5792:

  1. Applications use wallet_sendCalls to send multiple function calls to the wallet
  2. The wallet decides how to bundle these calls into a sequence
  3. The wallet may use EIP-7702 behind the scenes to execute these as a batch
  4. Users only need to sign once for the entire sequence

This approach is particularly useful for simple batching scenarios on a single chain, such as combining token approval and swap operations. The wallet handles all the complexity of bundling the transactions, and applications don't need to know how the wallet implements this functionality.

ERC-5792 is used for batch execution only. For any actions more complex than that, you’d need to use ERC-7710/ERC-7715

The Companion Account Approach

Biconomy's solution leverages what they call "companion accounts" - application-specific smart accounts that act as intermediaries. The flow works like this:

  1. The application deploys a companion smart account for its own use
  2. The user grants permission to this companion account (via EIP-7710/7715 if the wallet supports it)
  3. The companion account then handles the complex operations like batching, gas sponsorship, etc.

This approach allows each application to implement the exact smart account features it needs. For example:

Fusion Execution (Biconomy's Fallback)

Recognizing that not all wallets will support EIP-7710/7715 initially, Biconomy has created a fallback mechanism called "Fusion Execution" that works with any wallet:

  1. The approach repurposes fields in regular EVM transactions or ERC-20 permit functions
  2. The user appears to make a regular transfer to the companion account
  3. Hidden within this transaction is additional information (compressed into a hash)
  4. The transaction is sent to both:
    • The regular Ethereum RPC (for the transfer)
    • A specialized node that processes the additional instructions

This allows for complex operations even with wallets that don't support the newer standards.

Using EIP-7702 for cheap smart account deployments

One, often overlooked, feature of EIP-7702 is that it enables developers to deploy new smart accounts for users up to 80% cheaper than before. It achieves this by leveraging the fact that an EIP-7702 proxy costs only 12,500 gas to set up. By using a few clever cryptographic tricks - such as Nick’s method and signature packing - developers can deploy fully featured smart accounts (with support for resource locks, time locks and multi sigs) - by using just EIP-7702.

The deployment cost savings of this method make using companion accounts viable on Ethereum Mainnet (with deployment costs for a companion account in the $0.2 - $0.5 range) and basically free on rollups. Beyond this, for wallets which are smart account first (no EOA) - it makes the cost of onboarding new users equally affordable.

Read more about this in our detailed guide.

What This Means for Developers

If you're an application developer, here's what you need to know:

  1. You Can't Directly Use EIP-7702: Wallets control the authorizations, not applications
  2. Watch Wallet Implementations: Major wallets will implement EIP-7702 in different ways, and you'll need to adapt to each
  3. Consider Companion Accounts: If you need specific smart account features, developing a companion account approach might be the most flexible solution
  4. Prepare for Fragmentation: Not all chains will implement EIP-7702 at once, and not all wallets will support it the same way
  5. Look Beyond Basic Use Cases: While batching and gas sponsorship are the initial focus, EIP-7702 combined with other technologies could enable more advanced features like multichain operations and intent-based transactions

Developer Tools: AbstractJS by Biconomy

Navigating the EIP-7702 ecosystem can be challenging for developers. Implementing wallet compatibility checks for ERC-7710/ERC-7715/ERC-5792, deploying companion smart accounts, and handling various encoding requirements can quickly lead to complex conditional logic and difficult-to-maintain code.

To address these challenges, Biconomy offers AbstractJS - a comprehensive TypeScript SDK built on top of viem that simplifies EIP-7702 integration. This toolkit abstracts away the complexity of wallet feature detection, companion account deployment, and transaction encoding behind a clean developer interface.

Biconomy is actively enhancing AbstractJS to support all EIP-7702 features, with plans to have a production-ready implementation by the time of the Pectra merge (expected around April 2025).

Looking Forward

EIP-7702 represents an important step in blockchain UX evolution, but it's not the final form. The standard itself is just part of a broader ecosystem of improvements including EIP-7710, EIP-7715, ERC-4337, and others.

The most interesting developments will likely come from how these standards are combined to create new user experiences. For example, combining EIP-7702's delegation with intent-based systems could allow users to express what they want to accomplish (e.g., "swap X for the best possible amount of Y across all DEXes") rather than specifying exact transaction parameters.

While there will be fragmentation and growing pains as wallets implement different approaches, the overall direction is toward more user-friendly blockchain interactions that hide complexity without sacrificing security or control.

Glossary of Terms

EOA (Externally Owned Account): The standard user account on Ethereum, controlled by a private key.

EIP-7702: An Ethereum Improvement Proposal that allows EOAs to delegate their execution to smart contracts.

ERC-7710: A standard interface for one smart contract to delegate permissions to another.

ERC-7715: A standard that introduces a new JSON-RPC method for applications to request permissions from wallets.

ERC-5792: A standard that defines a "wallet call API" allowing applications to send multiple calls to be bundled by wallets.

ERC-4337: A standard for "account abstraction" that enables smart contract wallets without changes to the Ethereum protocol.

Smart Account Standards: Various standards for smart contract accounts including ERC-7579 and ERC-6900, which provide frameworks for modular, programmable user accounts.

Companion Account: An application-specific smart account that acts as an intermediary between users and applications.

Fusion Execution: Biconomy's approach for enabling smart account features without wallet support for newer standards.

MEE (Modular Execution Environment): An advanced execution system that can handle complex transaction flows including multichain operations.

Share Share Share Share Share Email