Ethereum Pectra Upgrade: How EIP-7702 Changes Wallet Design and Payments

Ethereum's Pectra upgrade, activated on May 7, 2025, delivered the most significant protocol change since the Merge. Among its 11 EIPs, one stands out for its impact on wallet design and payment UX: EIP-7702. Co-authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett, EIP-7702 lets any externally-owned account (EOA) temporarily delegate its execution to a smart contract, gaining programmable features without abandoning its existing address.

The implications extend beyond Ethereum. Every chain competing for wallet users and payment volume now faces a raised baseline for what users expect from an on-chain account. This article explains the technical mechanism, compares it with ERC-4337, surveys early adoption, and considers what it means for blockchain payment infrastructure broadly.

What Problem Does EIP-7702 Solve?

Before Pectra, Ethereum users had two account types with no middle ground. EOAs are controlled by a single private key: they can sign transactions but cannot execute arbitrary logic. Smart contract accounts can batch calls, sponsor gas, and enforce custom validation, but they require deploying a new contract at a new address. This forced wallet developers into an uncomfortable choice: keep things simple with EOAs and accept their limitations, or migrate users to entirely new smart contract addresses with all the friction that entails.

Account abstraction via ERC-4337 offered a partial solution by introducing an overlay protocol for smart accounts. But ERC-4337 does not help the hundreds of millions of existing EOAs: those users still need to deploy new contracts and move assets to benefit from programmable accounts. EIP-7702 closes that gap by making the EOA itself programmable.

How EIP-7702 Works

EIP-7702 introduces a new transaction type: Type 4 (SET_CODE_TX_TYPE = 0x04). When an EOA submits a Type 4 transaction, it includes an authorization_list containing one or more signed authorization tuples. Each tuple specifies a target contract address, the authorizer's chain ID and nonce, and an ECDSA signature from the EOA's private key.

The Authorization Tuple

Each authorization entry in the list follows a specific structure:

• chain_id: the chain where the authorization is valid
• address: the smart contract whose code the EOA will delegate to
• nonce: must match the EOA's current nonce, preventing replay
• y_parity, r, s: the EOA owner's ECDSA signature over these fields

When the EVM processes a valid authorization, it writes a delegation indicator into the EOA's code field: 0xef0100 || address (a 3-byte prefix followed by the 20-byte implementation address). From that point on, any call to the EOA triggers the delegated contract's code via DELEGATECALL semantics: the contract logic executes in the context of the EOA, reading and writing to the EOA's own storage.

Delegation is persistent but revocable: Unlike a one-time transaction effect, the delegation remains after the transaction completes and survives even if execution reverts. To remove a delegation, the EOA submits a new Type 4 transaction delegating to the null address (address(0)). The private key always retains ultimate authority.

Gas Costs and Constraints

Each authorization costs 12,500 gas for an existing account or 25,000 gas for an account that has never been touched. A Type 4 transaction must include at least one authorization to be valid. Because the authorization increments the EOA's nonce before execution begins, replay protection is built into the mechanism without requiring additional state tracking.

What New UX Patterns Does EIP-7702 Enable?

The core value of EIP-7702 is that wallet developers can now offer smart account features without changing the user's address or requiring contract deployment upfront. Three patterns have emerged as the most immediately impactful.

Batch Transactions

Before EIP-7702, a user approving a token swap on a DEX had to send two separate transactions: one to approve the token allowance, another to execute the swap. With delegation, a wallet can batch both operations into a single atomic transaction. If either step fails, the entire batch reverts. This reduces gas costs, eliminates the window between approve and swap where allowances could be exploited, and simplifies the user experience from two confirmations to one.

Gas Sponsorship

Delegation contracts can implement paymaster logic, allowing third parties to cover gas fees on behalf of users. A new user can interact with a dApp without holding any ETH: the application or protocol treasury sponsors the gas. Alternatively, users can pay gas in ERC-20 tokens like USDC, with the delegation contract handling the conversion. This removes the most common onboarding friction point for non-crypto-native users.

Session Keys

Session keys are temporary signing keys with scoped permissions. A delegation contract can authorize a session key to execute trades up to a certain value, valid for a limited time window, without requiring the main private key for each interaction. This pattern is critical for gaming, trading bots, and any application where constant wallet pop-ups destroy the user experience.

EIP-7702 vs ERC-4337: Complementary Approaches

EIP-7702 and ERC-4337 are not competing standards. They address different parts of the account abstraction problem and are designed to work together. ERC-4337 defines the infrastructure layer: bundlers, an EntryPoint contract, and a UserOperation mempool. EIP-7702 provides the mechanism for existing EOAs to participate in that infrastructure without creating new addresses.

In practice, most wallets adopting EIP-7702 use ERC-4337-compatible contracts as their delegation targets. This means EOAs can participate in the existing bundler and paymaster ecosystem. The ethereum.org guidelines explicitly recommend aligning delegation contracts with ERC-4337 account abstraction standards to maximize interoperability.

The practical effect: ERC-4337 built the rails (bundlers, paymasters, modular accounts). EIP-7702 onboards the passengers (existing EOAs) onto those rails without forcing them to change trains.

Wallet Adoption and Early Results

Within the first week of Pectra going live, roughly 15,000 EIP-7702 delegations appeared on Ethereum mainnet, spread across more than 100 unique delegate contracts. Adoption has been led by wallets that already invested in smart account infrastructure.

Notable Adopters

An early analysis by Wintermute Research found that over 97% of mainnet delegations in the first month pointed to a small number of contract families running similar sweeper bytecode. This suggests that institutional infrastructure providers and exchanges adopted EIP-7702 for operational efficiency before retail wallets fully rolled out consumer-facing features.

Security Considerations for Developers

EIP-7702 introduces several breaking assumptions that developers must account for. The most significant: an address that was previously guaranteed to be a simple EOA can now execute arbitrary code through its delegation.

Broken Invariants

• tx.origin can no longer be assumed to reference a codeless account: delegated EOAs may have contract logic attached
• The pattern msg.sender == tx.origin is no longer a reliable reentrancy guard: a delegated EOA can initiate calls with both values matching while still executing contract logic
• Delegation signatures can be frontrun: an attacker who intercepts an authorization tuple before it is included on-chain could submit it with modified initialization parameters

Best Practices

• Delegation contracts should not hard-code a single trusted relayer: if that relayer goes offline, the account becomes permanently inaccessible
• Storage layout collisions are a real risk when switching between delegation contracts, since delegated code reads and writes directly to the EOA's storage
• dApps should request operations via standardized wallet interfaces (ERC-5792 wallet_sendCalls) rather than asking users to sign raw EIP-7702 authorizations
• Delegation contracts should align with ERC-4337 and ERC-6900 standards for maximum composability across the smart wallet ecosystem

The Broader Pectra Upgrade

EIP-7702 is one of 11 EIPs included in Pectra. Several others have direct relevance to payment infrastructure and wallet developers.

The combination of cheaper L2 data availability (EIP-7691), native ZK precompiles (EIP-2537), and programmable EOAs (EIP-7702) positions Pectra as a coordinated improvement in both scalability and user experience across Ethereum's execution and consensus layers.

Migration Strategies for Wallet Developers

Wallet teams considering EIP-7702 integration face a spectrum of approaches depending on their existing architecture and user base.

Opt-In Upgrade

The simplest path: offer a one-click "upgrade to smart account" button that submits a Type 4 transaction delegating to an audited implementation contract. This is the approach MetaMask took with its Account Update flow. Users who do not upgrade continue using plain EOA functionality. The advantage is zero disruption; the risk is fragmented UX where some users have smart features and others do not.

Default-On for New Users

New wallet installations automatically delegate the EOA to a smart account implementation during onboarding. Existing users receive a prompt to upgrade. This approach maximizes adoption of batch transactions, gas sponsorship, and session keys but requires thorough testing of the delegation contract across all supported dApps.

Hybrid with ERC-4337

Wallets already supporting ERC-4337 smart accounts can use EIP-7702 as an onramp: users with existing EOAs delegate to a 4337-compatible implementation, gaining access to the same bundler and paymaster infrastructure that dedicated smart accounts use. This avoids maintaining two separate account models while preserving backwards compatibility with the 4337 ecosystem.

What This Means for Blockchain Payments

EIP-7702 raises the baseline for what a blockchain account can do. Batch operations, gas abstraction, and session keys are no longer experimental features limited to dedicated smart contract wallets. They are now available to every Ethereum address.

For payment applications, the implications are concrete. A checkout flow can approve and transfer tokens in one transaction. A subscription service can use session keys to pull recurring payments without requiring the user to sign each charge. A paymaster can sponsor onboarding transactions so new users never need to acquire ETH before making their first payment.

These patterns are not unique to Ethereum. The lessons from Ethereum L2 scaling have consistently shown that UX improvements on one chain create expectations across all chains. Users who experience gasless onboarding on Ethereum will expect the same on Bitcoin L2s, Solana, and every other network they use. For Bitcoin Layer 2 protocols like Spark, which already offers instant, feeless transfers with self-custody, the competitive dynamic is less about matching specific EIP-7702 features and more about ensuring the end-to-end payment experience meets the elevated bar that programmable accounts set.

Risks and Open Questions

Delegation Contract Quality

Users trust their entire account to the delegation contract's code. A bug in that contract could drain the EOA. Unlike a standalone smart contract wallet, there is no separation between the user's primary address and the execution environment. This makes delegation contract auditing critical: Ambire, for example, reported over 10 security audits on approximately 200 lines of contract code before launch.

Storage Collisions

Because delegated code executes in the EOA's storage space, switching from one delegation contract to another can cause storage slot collisions if the two contracts use different storage layouts. This is an inherent limitation of the DELEGATECALL model, and no protocol-level solution exists yet. Wallet developers must either standardize storage layouts across implementations or warn users about the risks of switching delegation targets.

Phishing Surface

EIP-7702 authorization signatures grant significant power: they allow arbitrary code to execute in the context of the user's account. If a user is tricked into signing a malicious authorization tuple, an attacker could delegate the account to a drainer contract. Wallets need to implement clear, unambiguous authorization UIs and warn users about the consequences of delegation.

Looking Ahead

Pectra's next chapter is already taking shape. The Ethereum roadmap points toward further account abstraction improvements, with proposals like ERC-6900 for modular smart account standards and continued work on native account abstraction at the protocol level. The long-term direction is clear: the distinction between EOAs and smart contracts will continue to blur until every Ethereum account has programmable capabilities by default.

For developers building payment and wallet infrastructure across any chain, the takeaway is practical: batch operations, gas abstraction, and scoped session keys are becoming table stakes. Whether you are building on EVM-compatible chains, Bitcoin L2s, or Solana, users will increasingly expect these capabilities as defaults rather than premium features. Explore the Spark developer documentation to see how Bitcoin L2 payment infrastructure approaches similar UX goals through different architectural choices, or read our analysis of ERC-4337 account abstraction for the full picture of Ethereum's smart wallet evolution.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.