Account Abstraction and Smart Wallets

Web3’s biggest user experience problem is not a lack of DApps. It is that raw accounts are hard to use: seed phrases are hard to protect, gas is confusing, approvals are dangerous, and every workflow takes too many signatures. Account abstraction aims to upgrade wallets from “private key signing tools” into programmable account systems.

Table of Contents

• Why Normal Wallets Feel Bad
• EOAs, Contract Accounts, and Smart Accounts
• The ERC-4337 Workflow
• What EIP-7702 Changes
• Paymasters, Bundlers, and Session Keys
• Passkeys and Social Recovery
• New Smart Account Risks
• Beginner Practice Path
• Learning Checklist
• Summary
• Further Reading

Why Normal Wallets Feel Bad

Traditional EOA wallets are very pure:

text
private key controls account
account signs transaction
transaction spends ETH as gas
confirmed transaction is irreversible

This model is secure, simple, and verifiable, but it is unfriendly for ordinary users:

Account abstraction does not lower the need for security. It turns accounts into programmable objects so wallets can implement real-world rules:

• Maximum daily transfer limits.
• An app can automate actions only during a time window.
• Login with a passkey, but require hardware wallet confirmation for large transfers.
• Applications can sponsor a new user’s first transactions.
• One signature can execute multiple actions and revert the whole batch if something fails.

EOAs, Contract Accounts, and Smart Accounts

Start with three concepts.

EOA: Externally Owned Account

An EOA is an account directly controlled by a private key. Most common wallet addresses are EOAs.

Advantages:

• Simple and natively supported by the protocol.
• Lower transaction overhead.
• Users can submit transactions directly.

Limitations:

• Account logic is not programmable.
• Lost private keys usually mean lost access.
• No native batching.
• No native ERC-20 gas payment.

Contract Account

A contract account is an address controlled by on-chain code. It has no private key; its behavior is defined by a smart contract.

Advantages:

• Custom permissions, recovery, limits, and batching.
• Multi-sig, modular permissions, and upgrade logic.
• Well suited for DAOs, treasuries, and advanced wallets.

Limitations:

• Usually requires deploying a contract.
• The wallet address may differ from the user’s existing EOA.
• Some older DApps do not handle contract wallets well.

Smart Account

“Smart account” is not one single standard. It is a design goal: let user accounts behave like programmable contracts while keeping the user experience close to a normal wallet.

Smart accounts often support:

• Batch transactions.
• Gas sponsorship.
• Multi-signature or multi-device confirmation.
• Social recovery.
• Session keys.
• Permission modules.
• Transaction simulation and risk controls.

The ERC-4337 Workflow

ERC-4337 is one of the most important account abstraction standards. It does not require Ethereum consensus-layer changes. Instead, it adds a new transaction flow at the application layer.

Traditional flow:

text
user wallet -> Ethereum mempool -> validator includes transaction -> contract executes

ERC-4337 flow:

text
User wallet
  |
  | creates UserOperation
  v
Bundler collects UserOperations
  |
  | calls EntryPoint
  v
EntryPoint validates account and Paymaster
  |
  | executes smart account logic
  v
Target DApp / contract

Core Components

What a UserOperation Contains

A UserOperation typically includes:

• sender: smart account address.
• nonce: replay protection.
• callData: the target action.
• signature: signature used by the account for validation.
• paymasterAndData: Paymaster data if gas is sponsored.
• Gas limit and fee fields.

Compared with a normal transaction, the key difference is that validation logic is defined by the smart account itself. If the account contract can prove the operation is authorized, the EntryPoint can execute it.

What ERC-4337 Enables

1. Batch transactions: one UserOperation can call multiple contracts.
2. Gas sponsorship: a Paymaster can pay gas for the user.
3. Custom signatures: accounts can support multi-sig, passkeys, MPC, or other schemes.
4. Permission modules: accounts can limit a session key to a specific contract.
5. Better recovery: accounts can include social recovery or delayed recovery flows.

What EIP-7702 Changes

ERC-4337 is powerful, but many users already have EOA addresses, assets, NFTs, transaction history, and social identity. Moving them to a new contract wallet address is expensive.

EIP-7702, activated in Pectra, brings smart account capabilities to existing EOAs. It introduces a new 0x04 transaction type that lets an EOA set a code delegation pointer. In practice, the original address can execute according to a smart account contract.

What It Solves

It Does Not Mean “Any Signature Is Safe”

EIP-7702 authorization is sensitive. The official EIP describes setting code for EOAs, not just signing an ordinary message. The delegated code can execute in the account context.

Users and wallets must ask:

• Which contract address is being delegated to?
• Has the code been audited?
• Is the delegation persistent?
• How can it be revoked or replaced?
• Is the authorization bound to a chain ID?
• Can a relayer abuse the authorization?

If a website says “upgrade your wallet to claim an airdrop” and asks for EIP-7702 authorization, treat it as high risk by default.

Paymasters, Bundlers, and Session Keys

The three most common account abstraction UX improvements map to Paymasters, Bundlers, and Session Keys.

Paymaster: Who Pays Gas

A Paymaster is a contract or service that sponsors gas in ERC-4337. Common models:

1. Application sponsorship: a project pays gas for a new user’s first interaction.
2. ERC-20 gas payment: the user pays with USDC, DAI, or a project token, while the Paymaster handles ETH behind the scenes.
3. Membership or subscription: users who meet certain conditions get sponsored actions.
4. Limited sponsorship: first N transactions per day, or only below a value threshold.

A Paymaster is not just “free gas.” It must prevent abuse:

• Limit callable contracts.
• Limit user frequency and amount.
• Check that the UserOperation matches business rules.
• Prevent users from draining Paymaster funds through failing operations.

Bundler: Sending UserOperations On-Chain

A Bundler listens for UserOperations, bundles them into normal Ethereum transactions, and calls EntryPoint.

It needs to:

• Simulate whether UserOperations succeed.
• Estimate gas.
• Filter malicious or unpaid operations.
• Support multiple chains and EntryPoint versions.

For developers, a Bundler is part of account abstraction infrastructure. You can use third-party Bundlers, or run your own in advanced cases.

Session Key: A Temporary Key, Not the Master Key

A Session Key is a temporary permission key. It is not the main private key. It is authorized by a smart account with limited permissions.

Good use cases:

• Auto-sign low-value game actions.
• Let a DApp act for 24 hours.
• Allow spending only one token and only below a daily limit.
• Automate rebalancing, recurring buys, or subscriptions.

A good Session Key should include:

Without these limits, a Session Key is just another way to leak full account control.

Passkeys and Social Recovery

Account abstraction lets wallets support more practical authentication methods.

Passkeys

Passkeys use WebAuthn and device secure modules. Users can confirm actions with Face ID, Touch ID, Windows Hello, or hardware security keys.

Advantages:

• Users do not directly handle seed phrases.
• Key material can be protected by the device secure module.
• The experience is closer to normal internet products.

But passkeys are not magic:

• Device loss still requires recovery.
• Browser and platform compatibility must be tested.
• Large assets should still use hardware wallets or multi-sig strategies.

Social Recovery

Social recovery lets users set guardians or recovery devices. If the main device is lost, a threshold of guardians can confirm recovery.

Common design:

text
user sets 5 guardians
any 3 guardians approve
48-hour delay period starts
account recovers to a new key

The delay period matters. It gives the user time to detect and cancel malicious recovery.

New Smart Account Risks

Account abstraction improves UX, but it also expands the attack surface.

1. Authorization Is Harder to Read

Old risks were mostly:

• Are you transferring an asset?
• Are you approving a contract to spend your tokens?

Smart accounts add questions:

• Are you letting code control account logic?
• Are you authorizing a Paymaster or Bundler to relay operations?
• Did you give a Session Key too much permission?
• Did you allow a module upgrade?

2. “Free Gas” Can Encourage Bad Signatures

Attackers can use “free gas,” “airdrop,” or “one-click upgrade” to reduce caution. A transaction that costs no ETH is not automatically safe. The most dangerous signatures may change future permissions rather than immediately transfer assets.

3. Wallet Implementations Become Security Critical

Smart accounts rely on wallets to display complex permissions. If a wallet only shows “sign,” without explaining delegated code, modules, Paymasters, or Session Keys, the user cannot make an informed decision.

4. Compatibility Issues Create Hidden Risk

Some DApps still assume users are ordinary EOAs. Smart accounts may encounter:

• Signature format incompatibility.
• Contract wallets excluded from airdrops.
• Anti-contract checks that block real users.
• tx.origin logic causing security or usability problems.

Developers must test smart accounts instead of treating them as an edge case.

Beginner Practice Path

If you are new to account abstraction, do not start by writing a complete wallet. Use this path:

Stage 1: Understand Concepts

• Learn the difference between EOAs and contract accounts.
• Understand that UserOperation is not a normal transaction.
• Understand the roles of EntryPoint, Bundler, and Paymaster.
• Understand that EIP-7702 lets EOAs set code delegation.

Stage 2: Use Existing Smart Wallets

Try a smart-account-enabled wallet or test tool:

• Create a test account.
• Try gas sponsorship on a testnet.
• Check whether the transaction goes through EntryPoint.
• Observe how the wallet displays batching and permissions.

Stage 3: Build a Minimal Example

Try a small experiment:

1. Write a minimal smart account contract that only lets the owner execute.
2. Send a UserOperation through EntryPoint.
3. Connect to a testnet Bundler.
4. Add a simple Paymaster that only sponsors allowlisted functions.
5. Write tests for invalid signature, wrong nonce, insufficient funds, and illegal call.

Stage 4: Study the Security Model

Learn:

• EIP-712 structured signatures.
• Permit and Permit2 risks.
• Multi-sig and delayed recovery.
• Session Key permission design.
• Paymaster griefing attacks.
• Transaction simulation and malicious calldata detection.

Learning Checklist

After this lesson, you should be able to answer:

• What is the core difference between an EOA and a contract account?
• How can account abstraction improve gas, recovery, and batching UX?
• What do UserOperation, EntryPoint, Bundler, and Paymaster do in ERC-4337?
• Why can EIP-7702 give existing EOAs smart account capabilities?
• Why is EIP-7702 authorization more sensitive than an ordinary signature?
• What limits should a Session Key include?
• What can passkeys solve, and what can they not solve?
• Why should DApp developers avoid tx.origin and simplistic account-type checks?

Summary

The long-term goal of account abstraction is to stop exposing raw account complexity to users. Users want:

• Safe login.
• Account recovery.
• Understandable permissions.
• The ability to use USDC without buying ETH first.
• Limited application permissions instead of full account control.

ERC-4337 provides smart account infrastructure without consensus-layer changes. EIP-7702 brings similar capabilities closer to existing EOAs. They are not mutually exclusive; together they move wallets from “private key managers” toward “account operating systems.”

But more powerful accounts require stricter security boundaries. Wallet competition will not only be about interface design. It will also be about whether users can understand and control their permissions.

Further Reading

• ERC-4337 Documentation
• EIP-7702: Set Code for EOAs
• Ethereum.org: Account abstraction
• EntryPoint Explainer
• Paymasters
• Session Keys and Delegation