What EIP-7702 migration actually does

The term "migration" often triggers anxiety in crypto, conjuring images of bridging assets, losing data, or navigating complex new interfaces. EIP-7702 is not a migration in that sense. It is a protocol-level upgrade that allows your existing Externally Owned Account (EOA)—the standard wallet address controlled by a private key—to borrow the logic of a smart contract.

This mechanism, known as "set code," lets an EOA delegate its execution to a smart contract wallet. Once you sign an authorization, your address behaves like a smart contract for that session. You retain your original address, but you gain access to features like transaction batching, gas sponsorship, and custom permission rules. The funds never move; the behavior simply changes.

FeatureTraditional EOAEIP-7702 Enabled EOA
AddressStandard 0x addressSame 0x address
Code ExecutionNone (simple value transfer)Delegates to smart contract logic
Session KeysNot supportedSupported
Gas PaymentMust pay in ETHCan pay in ERC-20 tokens (via paymasters)

This approach differs significantly from ERC-4337. While ERC-4337 requires users to interact with entirely new smart contract wallets and bundlers, EIP-7702 modifies the EOA directly. It is designed to be forward-compatible with account abstraction without forcing users to abandon their existing keys or addresses. The EIP-7702 authorization is a one-time setup that unlocks these capabilities, making the transition seamless for users.

This distinction matters for security and usability. Because the address remains the same, you do not need to update integrations, exchange deposits, or share new addresses with contacts. The upgrade happens at the protocol level, allowing your wallet to execute complex logic while maintaining the simplicity of a standard key-based account.

Invalid TradingView symbol: ETHUSD

EIP-7702 vs ERC-4337 comparison

The two dominant paths to account abstraction—EIP-7702 and ERC-4337—serve different architectural layers. Understanding their distinction is critical for the EIP-7702 migration, as it determines whether you upgrade the account itself or the transaction flow.

ERC-4337 (User Operations) operates as a layer above the blockchain. It introduces a new transaction type called a "User Operation" (UserOp) that is processed by a separate network of bundlers and paymasters. This approach allows for complex logic like paymasters and session keys without changing the Ethereum Virtual Machine (EVM). However, it requires users to hold an ERC-4337 smart contract account (AA) instead of a standard EOA.

EIP-7702, by contrast, modifies the EOA directly. It allows an existing externally owned account to temporarily delegate its execution to a smart contract. This is a native protocol upgrade, meaning it doesn't require a separate bundler network to process transactions. The EOA retains its address, but its behavior changes based on the delegated contract.

As the Pectra upgrade activated EIP-7702 in May 2025, the ecosystem is now distinguishing between these two models. EIP-7702 is not a replacement for ERC-4337 but a complementary path. While 7702 upgrades the account's capabilities, 4337 standardizes how that account interacts with the broader infrastructure like bundlers and paymasters.

The table below breaks down the structural differences that impact development and user experience.

FeatureEIP-7702ERC-4337
ImplementationNative EVM upgrade (Protocol)Smart contract layer (UserOp)
User AddressExisting EOA addressNew smart contract account
Transaction ProcessingStandard blockchain transactionsBundled UserOps
InfrastructureNo bundlers requiredRequires bundlers & paymasters
Gas SponsorshipNative or PaymasterPaymaster contract

Choosing the right abstraction

For many existing EOA holders, EIP-7702 offers a lower-friction migration path. Because it does not require users to change their addresses or transfer funds to a new smart contract, the adoption barrier is significantly lower. Users can retain their familiar addresses while gaining access to smart contract features like transaction batching and custom permissions.

ERC-4337 remains the standard for applications requiring deep integration with paymasters and complex session key logic that spans multiple chains or requires sophisticated off-chain validation. However, for those looking to upgrade their current wallets without disrupting their address history, the EIP-7702 migration is the primary focus.

How the authorization flow works

EIP-7702 authorizations introduce a new transaction type (Type 4) that allows Externally Owned Accounts (EOAs) to temporarily borrow logic from smart contract wallets. This mechanism enables EOAs to function as smart contract accounts without permanently altering their underlying code or storage structure.

The process begins when an EOA owner signs a specific authorization message. This signature grants permission for a designated smart contract to be attached to the EOA for a single transaction. The signed authorization is included in the transaction's authorization_list field, effectively "borrowing" the contract's code for that specific execution context.

During execution, the EVM temporarily treats the EOA as if it were a smart contract, executing the attached contract's code. This allows for advanced features like transaction batching, gas sponsorship, and custom permission checks. Once the transaction completes, the EOA reverts to its original state, with no persistent code or storage changes.

This temporary delegation is a core feature of the EIP-7702 migration, providing a flexible path for EOA users to access smart account capabilities. It complements existing standards like ERC-4337, offering a more integrated solution for account abstraction on Ethereum.

FeatureStandard EOAEIP-7702 EOA
Code ExecutionNoneTemporary
StorageNoneTemporary
RevertibilityN/AFull
CompatibilityUniversalPost-Pectra
EIP-7702 in

Migration steps for wallet developers

Integrating EIP-7702 support requires updating transaction construction logic to handle the new type 4 transactions. Wallets must manage the lifecycle of SetCode authorizations, ensuring they are properly signed, submitted, and revoked. This migration enables EOAs to temporarily delegate execution to smart contracts, unlocking account abstraction features without requiring users to migrate their keys.

EIP-7702 in
1
Implement SetCode Authorization Signing

Users must sign a specific authorization message that grants a smart contract permission to act on their behalf. Wallets need to implement the signing logic for these SetCode payloads, ensuring the target contract address and expiration are clearly displayed to the user for security verification.

EIP-7702 in
2
Handle Type 4 Transaction Construction

Modify your transaction builder to support type 4 transactions. These transactions include an authorizationList field containing the signed authorizations. The wallet must correctly encode these authorizations alongside the call data to ensure the EOA’s code is set on-chain when the transaction is executed.

EIP-7702 in
3
Manage Authorization Lifecycle and Revocation

Authorizations are temporary and must be revoked when no longer needed. Implement logic to detect when an authorization is stale or when the user wishes to revoke access. This involves constructing and sending a new transaction that clears the delegation, preventing unauthorized future access to the EOA.

EIP-7702 in
4
Ensure Backward Compatibility with Legacy EOAs

Not all users will migrate immediately. Ensure your wallet continues to support standard type 2 transactions for legacy EOAs. The UI should allow users to choose between "Simple" (legacy) and "Smart" (EIP-7702) modes, clearly explaining the trade-offs in gas costs and functionality for each path.

FeatureStandard EOAEIP-7702 Migrated
Gas SponsorshipNoYes
Transaction BatchingNoYes
Key RotationNoYes
Complex SignersNoYes

Technical implementation relies on understanding the difference between EIP-4337 and EIP-7702. While 4337 relies on external bundlers, 7702 upgrades the account itself. This distinction impacts how wallets handle state and gas payments during the migration process.

Invalid TradingView symbol: ETHUSD

Common questions about EIP-7702

The Pectra upgrade, which launched in May 2025, fully activated EIP-7702. This means the feature is live on the Ethereum network, allowing externally owned accounts (EOAs) to delegate execution to smart contract code without needing to migrate assets or change addresses.

Is EIP-7702 implemented?

Yes. The Pectra hard fork (combining Prague and Electra) enabled EIP-7702 in May 2025. Since then, the feature has been fully active on the mainnet. You can interact with it using wallets that support the new authorization standards.

How do EIP-7702 authorizations work?

Authorizations allow an EOA to sign a message that links its address to a smart contract. This effectively upgrades the EOA to behave like a smart contract account for that session. Once authorized, the EOA can execute complex logic, such as transaction bundling or gas sponsorship, directly from the original address.

What is the difference between EIP-4337 and EIP-7702?

EIP-7702 and ERC-4337 are complementary, not replacements. EIP-7702 upgrades the account itself to have code and storage, while ERC-4337 standardizes how accounts interact with external bundlers and paymasters. Many wallets use both to combine native account features with flexible transaction routing.

FeatureEIP-7702ERC-4337
Account TypeEOA with codeSmart Contract Wallet
AddressSame as EOANew contract address
BundlersOptionalRequired

What is the EIP-7702 prefix?

The authorization is typically sent as a specific transaction prefix (Type 0x04). This prefix signals to the network that the transaction includes a delegation signature. It allows the EOA to temporarily or permanently delegate its execution rights to a smart contract wallet.

Invalid TradingView symbol: ETHUSD

Do I need to migrate my wallet?

No. EIP-7702 is designed to work with existing EOAs. You do not need to transfer funds to a new address or set up a complex smart contract wallet from scratch. The upgrade happens at the protocol level, allowing your current address to gain new capabilities.