DEV Community

Akim B. (mousticke.eth)
Akim B. (mousticke.eth)

Posted on

Ethereum UX: Account Abstraction (AA)

#ethereum #blockchain #web3 #cryptocurrency

Introduction

If you have been in the Web3 community for a while, you might have heard about Account Abstraction, or if you are just a Web2 user, it might have been difficult to step into a blockchain transaction with Ethereum since there are some concepts like gas fees, stipends, signatures, and so on. For all of us, Ethereum has brought an amazing EIP (4773) which improves significantly the UX for interacting with the protocol.

Account abstraction makes Ethereum more user-friendly, secure, and ready for mass adoption by institutional and regular users. I have been playing around for a while, and I’d like to share with you what Account abstraction is, my insights, and what I’ve learned so far. Whether you're a developer, investor, or just crypto-curious, understanding AA could reshape how you think about wallets and transactions.

Let's start with the basics...

If you want to see a minimal implementation, please check a sample minimal account abstraction in my github repo: https://github.com/Mousticke/eth-erc4337-minimal-account-abstraction/blob/main/src/ethereum/MinimalAccount.sol

What is Account Abstraction?

In the Ethereum blockchain, there are two main types of accounts:

  • Externally Owned Accounts (EOAs): These are your standard wallets, controlled solely by a private key. They can't contain any EVM (Ethereum Virtual Machine) code. They're simple and straightforward.
  • Smart Contract Accounts: These hold executable code and are governed by that code's logic, not a single private key.

The problem with EOAs? They're a bit hard to hand on by the common user and risky:

  • Once you sign a transaction or lose your key, there's no recovery mechanism. One mistake, and your funds could be gone forever.
  • They rely on ECDSA signatures, which aren't quantum-resistant.
  • This setup isn't ideal for mainstream users who expect seamless, forgiving experiences like in Web2 apps without caring too much about signature, gas fee, secret keys. Plus, there is no sponsors to pay fees on our behalf.

So what is the alternative ? Here comes the Account Abstraction.

It blurs the lines between EOAs and contracts, turning every account into a programmable smart contract. You define custom logic, validation rules, and flows, making accounts smarter, safer, and more flexible.

Why Do We Need AA?

Blockchain's biggest barrier to adoption is poor UX. AA solves this by enabling:

  • Customizable security: Add multi-factor auth, social recovery, or spending limits without relying on a single key.
  • Quantum-proofing: Swap out ECDSA for more secure schemes.
  • Seamless integration: Make crypto feel like everyday apps, reducing friction for non-technical users.

In short, AA paves the way for billions of users by making blockchain as intuitive as logging into your bank account.

Key Components of AA (ERC-4337 Standard)

ERC-4337 enables account abstraction without requiring changes to Ethereum's consensus layer. It introduces a parallel system using an alternative mempool, allowing smart contract wallets (programmable accounts) to replace or augment traditional Externally Owned Accounts (EOAs).

Here's the core system

1. UserOperations (UserOps)

These are ABI-encoded structures that represent user intents (send ETH or swap tokens). It's not a real Ethereum transaction but a structured data packet sent to a dedicated mempool. Which means they can't access block-level info (like timestamps) to prevent manipulation, and they only interact with the sender's data. Ops flow through a decentralized peer-to-peer alt-mempool, avoiding centralized bottlenecks.

Main fields:

  • sender : The smart contract account address.
  • nonce : Prevents replays.
  • initCode : (Optional) Code to deploy the account if it doesn't exist (using a Factory).
  • callData : The action to execute (transfer tokens).
  • callGasLimit, verificationGasLimit, preVerificationGas : Gas estimates.
  • maxFeePerGas, maxPriorityFeePerGas : Like regular txs. Fees you put on MM for example.
  • paymasterAndData : (Optional) Paymaster info for sponsorship.
  • signature : Custom signature (validated by the account).

Users/wallets create and sign UserOps, then broadcast them to the alt-mempool.

2. Alt-mempool

A peer-to-peer network separate from the main Ethereum mempool. UserOps propagate here, keeping the system decentralized (no central relayer required).

3. Bundler

Think of this as a specialized node. It monitors the UserOp mempool (alt-mempool), bundles multiple ops together, simulates them to calculate gas fees, and submits them to the EntryPoint via handleOps(). Fees can be paid by the account itself or a Paymaster. Bundlers get reimbursed for gas (plus tips) from accounts or paymasters.

4. EntryPoint

A global smart contract deployed one per chain that handles everything. The entrypoint receives bundled UserOps from bundlers and runs in two phases:

  • Verification Phase : Checks signatures, nonces, and custom rules by calling account. validateUserOp() (and paymaster if used) to check signature, nonce, and rules.
  • Execution Phase: Actually performs the ops on-chain which can handles staking, deposits, withdraw, and post ops logic.

5. Smart Account (user’s wallet)

The user's programmable account. Must implement:

  • validateUserOp() : Custom logic (ECDSA, multisig, session keys).
  • execute() : Perform the action.

6. Paymaster

A contract that sponsors transactions. It can cover gas fees on behalf of users, enabling gasless experiences.

7. Aggregator

For efficiency, accounts can batch signatures using an aggregator, compressing multiple sigs into one to save on gas and data.

8. Factory

Deploys the account via CREATE2 if initCode is provided.

Transaction flow

  1. User creates/signs a UserOp.
  2. Broadcast to alt-mempool.
  3. Bundler collects, simulates, bundles, and calls EntryPoint.handleOps(bundle) .
  4. EntryPoint verifies ( account + paymaster ) → executes → refunds/reimburses.
  5. On-chain as one tx from the bundler.

Real-World Use Cases

AA isn't theoretical. It's powering innovative apps today. Here are a couple of examples

Pay Gas Fees in Any ERC-20 Token

No more scrambling for ETH! Imagine a merchant checkout: A user places a $100 order in USDC. The Paymaster covers the gas fee (say, 1 USDC from the user), converts it to ETH, and pays the network. The merchant receives the full 100 USDC. This abstracts away crypto's "gas hassle," making it feel like a regular online purchase.

Connect your wallet using Google, Apple ID, or even biometrics. No seed phrases or manual gas settings required. For beginners, this eliminates the "What’s a private key?" confusion, turning crypto into a plug-and-play experience.

Signing with Google or Apple ID (Passkeys)

But I have mentioned earlier that you can even use your google account or apple id as a wallet by signing transaction directly by your fingerprint or face ID. That’s one of the most exciting feature turning a Web3 hassle into a Web2-like logins for blockchain wallets. You can now "connect" or sign transactions using your Google account, Apple ID, or device biometrics (Face ID/Touch ID). no seed phrases, no private keys to manage, and no confusing gas settings. This is powered by passkeys (based on the WebAuthn standard), turning your smart contract wallet into something that feels like logging into any modern app.

Instead of ECDSA signatures from a private key, the wallet can validate any signature scheme, including passkeys.

Passkeys are:

  • Cryptographic credentials created and stored securely on your device (in Apple's Secure Enclave or Google's Password Manager).
  • Unlocked via biometrics (Face ID, fingerprint) or PIN.
  • Synced securely across devices via iCloud or Google.
  • Phishing-resistant and passwordless.

When you sign in with Google or Apple ID

  • It's actually creating/registering a passkey tied to your account.
  • The private key never leaves your device. It's generated and stored in hardware-secured areas.
  • The public key is registered on-chain with your smart wallet.

Account abstraction flow with Apple ID / Google

In your DApp, choose to sign in with Google or Apple. Your device uses WebAuthn API to generate a passkey (private/public key pair). Then the smart contract account is deployed (via a Factory in ERC-4337). The public key is stored in the account as the owner.

Then it’s time to create a transaction. You may want to send tokens or swap on the DApp. The wallet creates a UserOperation (your intent). Instead of signing with a private key, it prompts your device by requiring your biometric ID. WebAuthn signs the UserOp hash using the passkey (on-device, secure). The signature (P256 curve) is sent with the UserOp to a Bundler. (There is an extra step because P256 is different from the secp256k1. We will talk later about it).

Ultimately, the EntryPoint contract calls your smart wallet's validateUserOp(), verifies the signature and process to the operations like we described above.

Hold on mate ! The private key from a Google or Apple passkey never leaves the device (it's stored in the secure enclave/hardware module and can't be exported). So, Solidity code on-chain can't access or use it directly to sign anything ? And my friend your right !

Instead, the device uses WebAuthn to sign the message/hash with the passkey private key on the client side (off-chain). Then, the smart contract wallet verifies the signature using the corresponding public key which is stored on-chain. This is possible because Account Abstraction (ERC-4337) allows custom signature validation in the validateUserOp function.

Passkeys use the secp256r1 elliptic curve (also called P-256), not Ethereum's native secp256k1. But Ethereum has a built-in precompile for secp256k1 (via ecrecover), but not for P-256. So the verification requires a custom Solidity code to implement P-256 signature checking. This is expensive in gas. Check this out here : https://github.com/daimo-eth/p256-verifier/blob/master/src/P256Verifier.sol

Benefits are huge

  • No Seed Phrases: Ever. Recovery via iCloud/Google sync.
  • Gasless and Seamless: Paymasters can sponsor fees. You pay in USDC or nothing at all.
  • Secure: Keys in hardware, biometrics required, phishing-resistant.
  • Cross-Device: Lose your phone? Recover via another device signed into the same Google/Apple account.
  • Mass Adoption Ready: Feels exactly like logging into Gmail

Final thought

AA is already live on networks like Ethereum (via ERC-4337) and is being adopted. It's a cornerstone for scaling Web3 to the masses.

Top comments (0)