Account abstraction: ERC-4337 vs EIP-7702 and what it changes for UX

Account abstraction means a user's account is a smart contract that decides for itself what counts as a valid transaction, instead of a single private key the protocol hard-codes. On Ethereum and EVM chains there are two routes to it. ERC-4337 gives users new smart contract accounts and has run on mainnet since March 1, 2023. EIP-7702 lets an existing wallet address (an EOA) delegate to smart account code, and went live with Pectra on May 7, 2025. For most products in 2026 the answer is both: ERC-4337 infrastructure (bundlers and paymasters) for new users, and EIP-7702 so users who already have MetaMask-style wallets get the same features without moving funds.

What it buys you as a product team: gas sponsorship, one-click batched actions, passkey login, session keys for apps that sign often, and recovery that doesn't depend on a 12-word phrase.

What a normal wallet can't do

A standard Ethereum account (an externally owned account, or EOA) is one key pair. That has direct product consequences:

• The user needs the chain's native token to pay gas before they can do anything.
• Each action is a separate transaction and a separate signature. "Approve, then swap" is two popups.
• Losing the seed phrase means losing the account. There's no recovery path in the protocol.
• Every app gets the same all-or-nothing signing power. You can't grant a game "spend up to 10 USDC for 24 hours".
• The signature scheme is fixed to secp256k1, which phones' secure hardware doesn't use.

Account abstraction moves those rules into code you choose.

How ERC-4337 works

ERC-4337 got there without changing Ethereum's consensus rules. It adds a parallel transaction flow:

1. The user's wallet builds a UserOperation: what the account should do, gas limits, and a signature in whatever scheme the account accepts.
2. A bundler collects UserOperations from a separate mempool, simulates them, and submits a batch as a normal transaction.
3. A singleton EntryPoint contract calls each account's validation function, then executes the operation.
4. An optional paymaster contract agrees to cover gas, either for free (sponsorship) or in exchange for an ERC-20 like USDC.
5. A factory deploys the account on its first operation, so the user gets an address before any deployment cost is paid.

Because the account is a contract, it can check a passkey signature, a multisig, a session key with limits, or a recovery guardian. Most smart wallet SDKs you'd evaluate today build on this flow.

The cost is a new address. A user with funds in an existing EOA has to move them to the smart account, and some dapps still assume msg.sender is a plain key. Smart accounts also pay some extra gas for validation and, the first time, deployment.

How EIP-7702 works

EIP-7702 added a new transaction type (0x04) with an authorization list. Each authorization is signed by the EOA's key and names a contract address. The protocol then writes a delegation designator (0xef0100 followed by that address) into the EOA's code. From then on, calls to the EOA run the delegate contract's code, in the EOA's own storage, at the user's existing address.

So the user keeps their address, history, balances and token approvals, and gains batching, sponsorship and custom validation. The delegation persists until the user replaces or clears it.

Two things it does not do:

• It doesn't retire the original key. The EIP notes that delegated EOAs may still originate transactions. Whoever holds the seed phrase still controls the account. Passkeys and session keys added through 7702 are extra ways in, not replacements. If your pitch is "no seed phrase to lose", a fresh 4337 account is the honest option.
• It doesn't run an initializer. The EIP warns that there's no chance to run init code during delegation, so setup calls can be front-run unless the delegate contract requires them to be signed by the EOA's key.

The two standards now fit together. EntryPoint v0.8 added native support for EIP-7702 authorizations, so a delegated EOA can use the existing bundlers and paymasters, and it shipped an audited Simple7702Account as a minimal delegate.

ERC-4337 vs EIP-7702 at a glance

Paymasters: who pays for gas

Gas sponsorship is the feature product teams ask for first, and it's widely used. BundleBear's 2024 review, as summarized by Etherspot, found that 87% of all UserOperations were paid for through a paymaster, out of more than 103 million that year.

Sponsorship is a budget line with abuse risk, so design it like one:

• Decide what you sponsor. First transaction only, specific contracts only, or everything up to a monthly cap per user.
• Rate-limit by identity. If you sponsor everything for any new address, bots will farm you. Tie sponsorship to a login, a verified email or an allowlist.
• Offer ERC-20 gas as the fallback. Users who exceed your sponsored quota can pay in USDC instead of being told to go buy ETH.
• Watch the number that matters. The same BundleBear figures show only 4.3 million accounts made more than one UserOp in 2024. Free gas brings people in; it doesn't keep them. Track retention, not account creation.

In our planning estimates, sponsoring a simple action on an L2 costs cents, so the paymaster bill is rarely the problem. Farming is. Our post on deployment and gas costs by chain has the per-chain numbers.

Session keys: fewer popups, scoped power

A session key is a temporary key, usually held by the app or the user's browser, that the account accepts for a narrow set of actions. "This key may call the game contract, spend up to 20 USDC, until Friday." The user signs once, and the app acts within those limits without a popup per move.

Where it pays off:

• Games and social apps with many small actions.
• Trading interfaces that place and cancel orders often.
• Subscriptions and recurring payments.
• Automation and AI agents that act on a user's behalf within limits, which is the model behind DeFi yield agents.

Two standards matter here. ERC-7579 defines modular smart accounts, where validators (including session key validators) and executors plug into the account through a shared interface, so a module written once works across any compliant account. ERC-7715 is a draft standard for how an app asks a wallet to grant a permission. It's still a draft and vendors' call shapes differ, so wrap it behind your own interface.

The security rule is simple: a session key is only as safe as its limits. Scope it by contract, function, amount and expiry. A session key with "call anything" permission is a hot wallet with extra steps.

Passkeys: login with a fingerprint

Passkeys use the P-256 (secp256r1) curve that phones' secure enclaves and WebAuthn support. EOAs can't verify those signatures; smart accounts can. Until recently that verification was expensive in Solidity. Ethereum's Fusaka upgrade, activated on December 3, 2025, added EIP-7951, a secp256r1 verification precompile at address 0x100 costing 3,450 gas. It replaces RIP-7212, an earlier rollup-level version with the same interface.

The UX result: a user creates an account with Face ID or a fingerprint, no extension, no seed phrase. Coinbase's smart wallet popularized this, with a passkey on the user's device as the default owner.

The caveats you need to design for:

• Passkey sync lives with Apple, Google or a password manager. If the user loses that account, they lose the passkey. Add a second signer or a recovery path.
• Passkeys are bound to a domain. If your app's domain changes, or a user wants to use the same account in another app, plan for it up front.
• Not every chain has the precompile. On chains without it, check verification gas costs before you commit.

What changes in the product

None of this matters if the rest of the flow is confusing. We wrote about the surrounding UX in Web3 products that convert.

The security traps

• 7702 phishing. One signed authorization hands an attacker's contract full control of the account. Wintermute's analysis a few weeks after Pectra found that more than 80% of EIP-7702 delegations pointed to copies of one wallet-sweeping contract, used to drain addresses whose keys had already leaked. Wallets must show delegation requests in plain language and allowlist known delegates. Apps should never ask users to sign a raw authorization.
• Chain ID 0 authorizations. EIP-7702 accepts authorizations with chain ID 0, valid on every chain. Convenient for wallets, dangerous if a user signs one for a malicious delegate.
• Storage clashes when switching delegates. A delegated EOA keeps its storage when it moves to new code. The EIP recommends namespaced layouts like ERC-7201. Same discipline as upgradeable smart contracts.
• tx.origin checks break. Contracts that used require(tx.origin == msg.sender) to block contracts can no longer rely on it.
• Account and module bugs. The account is now your user's security boundary. Use audited implementations, and audit any custom validator or module as carefully as a vault. Our audit checklist applies in full.

How to build it

1. Pick the account. Use an audited, widely deployed implementation (Safe, Kernel, Nexus, Coinbase's smart wallet, or Simple7702Account for minimal 7702). Don't write your own account contract for an MVP.
2. Pick infrastructure. You need a bundler and a paymaster on every chain you support, either from a provider or self-hosted. Check they support the EntryPoint version your account uses.
3. Decide the 4337/7702 split. New users get a smart account with passkeys. Existing EOA users get a 7702 upgrade through their wallet where supported.
4. Write the sponsorship policy before launch: what's free, limits per user, the ERC-20 fallback.
5. Scope session keys tightly and show users what they're granting in plain language.
6. Plan recovery and test it with people who aren't engineers.

If you're also deciding between embedded wallet providers and building your own, our crypto wallet development guide covers custody models and vendors.

FAQ

What is account abstraction in simple terms?

It turns a crypto account into a programmable contract. The account decides what a valid transaction is, so it can accept passkeys, let someone else pay gas, batch several actions into one, and support recovery.

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

ERC-4337 creates new smart contract accounts and runs on any EVM chain without protocol changes. EIP-7702 lets an existing EOA point to smart account code while keeping its address. EIP-7702 doesn't remove the original private key; ERC-4337 accounts can avoid having one.

Does EIP-7702 replace ERC-4337?

No. They work together. EntryPoint v0.8 supports 7702 authorizations, so delegated EOAs use the same bundlers and paymasters as smart accounts.

What is a paymaster?

A contract in ERC-4337 that pays gas on a user's behalf. Apps use it to sponsor transactions or to let users pay fees in a stablecoin instead of the chain's native token.

Are session keys safe?

They're as safe as their limits. Restrict each session key by contract, function, spend amount and expiry, and let users revoke it. An unrestricted session key is equivalent to handing the app your wallet.

Do I need account abstraction for my dapp?

If your users are crypto-native traders who already have wallets, it's a nice-to-have. If you're onboarding people who've never held crypto, or your app needs many small actions, it's the difference between a usable product and a drop-off at step one.

We build smart wallet and account abstraction flows, from passkey onboarding to paymaster policies and session key modules. If you're planning one, contact 23studio and we'll help you pick the account stack and scope what to build first.