This article was originally published on X.

In part one of this series, we explored how the adoption of EIP-7702 will play out. In part two, I’d like to zoom in on how EIP-7702 will impact DApps, and what you can do as a DApp developer to take advantage of EIP-7702.

Quick Overview of EIP-7702

EIP-7702 is slated to go live with Ethereum's next upgrade (Pectra), scheduled for approximately April 2025.

With EIP-7702, an EOA (Externally Owned Account) can "upgrade" itself into a smart account while simultaneously remaining an EOA and keeping the same address. Once upgraded, the user can experience most of the benefits of Account Abstraction (AA) such as gas sponsorship, transaction batching, and passkeys.

Two Types of DApps

For the purpose of this article, we will differentiate between two types of dApps:

• "Open DApps": DApps where users bring their own wallets.
  • Examples: Uniswap, AAVE.
• "Closed DApps": DApps that work primarily (or exclusively) through an embedded wallet. These are essentially wallets with a DApp-specific UI.
  • Examples from ZeroDev customers: Infinex, DeFi.app, and Nekodex.

EIP-7702 for Open DApps

Given MetaMask's public commitment to EIP-7702, developers of open dApps must adjust to a new reality: the wallet your user connects to your dApp MAY be a smart wallet, and increasingly more likely so.

This leads to two immediate questions: How do you know if a connected wallet is a smart wallet, and what do you do with that knowledge?

Detecting a Smart Wallet

Detecting a smart wallet is simple via the ERC-5792 standard RPC wallet_getCapabilities. This RPC returns a list of "capabilities" that the connected wallet supports.

• Example: A wallet might respond indicating it supports permissions (transaction delegation) on all networks, but supports paymasterService (gas sponsorship) only on a specific chain ID (like Base, 0x2105).

Your DApp should call wallet_getCapabilities after connection to determine which smart wallet features are supported.

Luckily, Viem and Wagmi already support wallet_getCapabilities, making implementation straightforward.

Using a Smart Wallet's Capabilities

Once you discover the capabilities, you need to decide whether to use them. This is a product decision:

• Required Capability: Your DApp cannot function without it.
  • Example: An AI trading agent might require the permissions capability to execute delegated trades. If the wallet doesn't support it, the DApp refuses to work.
• Optional Capability: Your DApp can function without it, but offers an enhanced experience with it.
  • Example: A Web3 game might optionally sponsor gas for users whose wallets support the paymasterService capability. If not supported, the user simply pays their own gas as usual.

How to Use Capabilities

While smart accounts can support infinite features, in practice, a few capabilities satisfy most use cases: Transaction Batching, Gas Sponsorship, Permissions (Session Keys), and Chain Abstraction.

For each, there is or will be a standardized wallet interface:

• Transaction Batching: Standardized with ERC-5792.
• Gas Sponsorship: ERC-7677 defines an interface for using ERC-4337 paymasters.
• Permissions: Standardization is ongoing, with competing approaches like session keys, session accounts (ERC-7710), and sub accounts (ERC-7895). The effort to unify these is ERC-7715.
• Chain Abstraction: A rapidly developing area with ERCs like ERC-7682 and ERC-7811, though standardization is easier as it requires less complicated wallet interfaces.

Do I need to know 100 different ERCs to use EIP-7702?

The bad news is that there will indeed be many ERCs specifying different capabilities. The good news is that with the right tooling (like ZeroDev), you won’t have to learn most of them—the library will abstract the complexity and maintain compatibility with the cutting edge of standardization for you.

EIP-7702 for Closed DApps

A "closed dApp" works primarily or exclusively through an embedded wallet. The story here is simpler because the DApp has full control over the single embedded wallet it uses.

The key decision for a closed dApp is: Should the embedded wallet be a regular smart account, or an EIP-7702 account (Smart EOA)?

Smart EOAs vs. Regular Smart Accounts

FeatureRegular Smart Account (SC only)Smart EOA (EIP-7702 Account)Primary Key TypeCan use non-ECDSA keys (e.g., Passkeys).Always tied to the root ECDSA private key.Key ManagementCan revoke/rotate keys securely.Impossible to revoke/rotate the root ECDSA key (it always retains root access).Infra DependencyRequires smart account infra (e.g., ERC-4337 bundlers).Not Dependent on smart account infra; can send transactions as a regular EOA.Implementation Lock-InAddress is tied to a CREATE2 factory; difficult to switch implementations across new networks.Address is derived solely from the private key; no implementation lock-in, easy to re-delegate to a different smart account implementation.InteroperabilityCannot be easily imported into existing EOA wallets.Can be imported into any existing EOA wallet by importing the private key.

General Guidelines for Choosing

• Build on Regular Smart Accounts if:
  • You want to rely exclusively on passkeys (to avoid seed phrases or MPC costs).
  • You need users to have the ability to revoke/rotate all their keys.
• Build on EIP-7702 Accounts if:
  • You do not want to be tied to any specific smart account implementation.
  • You want your DApp to work seamlessly on new networks that may lack smart account infrastructure (e.g., bundlers).
  • You expect users to frequently send regular transactions without smart features.
  • You want your users to be able to import their accounts to other wallets.

Conclusion

EIP-7702 holds incredible promise for DApp developers to build Web3 experiences that were not possible before. However, it comes with the challenge of capability fragmentation (many competing, unstandardized capabilities).

The solution is to rely on tooling to manage complexity:

• ZeroDev is partnering with embedded wallet providers (e.g., Privy/Dynamic/Turnkey) to easily turn embedded wallets into EIP-7702 smart EOAs.
• The ZeroDev SDK abstracts complexity and maintains compatibility with the latest standards, allowing developers to build on capabilities like batching, sponsorship, permissions, and chain abstraction without needing to become experts in dozens of underlying ERCs.

If you are ready to get your feet wet with EIP-7702, head to this tutorial now!