Account Abstraction Explained: Your Complete Guide to ERC-4337 and EIP-7702

Part 1: The Mental Model

Introduction

Before we begin, this article assumes a brief familiarity with how Blockchains work, and having made 1 (one) transaction on-chain using a wallet. Aside from that, we’ve written this series for anyone with an open mind. (Feel free to skip the code snippets we’ve written for our fellow nerds)

The Problem with Traditional Wallets

If you’ve ever used a cryptocurrency wallet, you’ve probably experienced the friction: , paying gas fees in ETH even when you’re trying to send USDC, manually approving then confirming every single transaction, and losing your seed phrase means losing everything.

These aren’t bugs (or features) - they’re fundamental limitations of how Ethereum wallets work today.

For millions of users trying to adopt Web3, these constraints create an insurmountable barrier. But there’s a solution gaining momentum: account abstraction. This technology has exponentially increased the reach of DeFi by revolutionizing how users interact with blockchain networks .

What This Series Covers

This four-part weekly series will take you from the fundamentals of account abstraction to production-ready implementations. In this first article, we’ll build a complete mental model of ERC-4337 and EIP-7702. The following articles will dive deep into:

• Part 2: Gas sponsorship mechanisms and paymaster patterns

• Part 3: Bundler infrastructure and UserOperation lifecycle

• Part 4: EIP-7702 implementation, migration strategies, and key considerations

By the end, you’ll understand how modern wallets are removing friction from blockchain interactions- and why this matters for the future of decentralized finance.

---

Part 1: Understanding the Basics

What is an Externally Owned Account (EOA)?

An Externally Owned Account (EOA) is the standard Ethereum account controlled by a private key. When you create a wallet in MetaMask, Coinbase Wallet, or any traditional wallet, you’re creating an EOA.

EOAs have a simple structure:

• Address:Your public key (0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb)

• Balance: How much ETH the account holds

• Nonce: A counter that increments with each transaction

Transactions from EOAs must be:

1. Signed with the private key using ECDSA (Elliptic Curve Digital Signature Algorithm)

2. Paid for with ETH (for gas fees)

3. Executed sequentially according to the nonce

The Limitations of EOAs

While EOAs work, they impose severe constraints:

1. Single Point of Failure Your private key is everything. Lose it, and your funds are gone forever. Get phished, and an attacker has complete control. There’s no recovery mechanism, no multi-signature support, and no way to rotate keys.

2. Gas Payment Rigidity Every transaction requires ETH for gas, even if you’re trading ERC-20 tokens. New users must acquire ETH before they can do anything—a UX nightmare. You can’t pay gas fees in USDC, and you can’t have someone else sponsor your transactions natively.

3. Limited Transaction Logic EOAs can only do one thing at a time. Want to approve a token and swap it in a single transaction? You need two separate transactions. Want to set spending limits or implement time-locked withdrawals? Impossible with EOAs alone.

4. No Account Recovery Social recovery, guardians, and backup mechanisms? Not possible. If you lose your seed phrase, there’s no safety net.

Enter Account Abstraction: A New Paradigm

Account abstraction flips the script: instead of your account being controlled by a private key, it becomes a smart contract with programmable logic. This unlocks:

• Flexible authentication: Use multiple keys, biometrics, or passkeys

• Gas abstraction: Pay fees in any token or have fees sponsored

• Batch transactions: Execute multiple operations atomically

• Social recovery: Designate guardians who can help recover your account

• Custom security policies: Spending limits, time locks, whitelists

The challenge? Ethereum’s protocol was built around EOAs. Changing this at the protocol level would require a hard fork and massive coordination. Instead, ERC-4337 provides account abstraction without any consensus-layer changes.

---

Part 2: ERC-4337 Deep Dive

What is ERC-4337?

ERC-4337 (deployed March 2023) is a standard that achieves account abstraction using existing Ethereum infrastructure. Rather than modifying the protocol, it introduces a parallel transaction system where smart contract wallets can operate with full programmability.

Key Components Overview

ERC-4337 introduces five core components that work together:

1. UserOperations

A UserOperation is like a transaction, but for smart contract accounts. Instead of being signed by an EOA and sent directly to the network, it’s a data structure containing:

struct UserOperation {

    address sender;              // The smart account sending the operation

    uint256 nonce;               // Anti-replay protection

    bytes initCode;              // Code to deploy the account if it doesn’t exist

    bytes callData;              // The actual operation to execute

    uint256 callGasLimit;        // Gas for the main execution

    uint256 verificationGasLimit;// Gas for signature verification

    uint256 preVerificationGas;  // Gas for pre-processing

    uint256 maxFeePerGas;        // Max fee willing to pay

    uint256 maxPriorityFeePerGas;// Max priority fee (tip)

    bytes paymasterAndData;      // Paymaster address + data (if gas sponsored)

    bytes signature;             // Signature proving authorization

}

Notice what’s different: the sender is a smart contract, not an EOA. The signature field is flexible-it doesn’t have to be ECDSA. It could be a multisig proof, a WebAuthn assertion, or any validation logic the account implements.

2. Bundlers

Bundlers are specialized nodes that collect UserOperations from an alternative mempool, bundle them together, and submit them to the blockchain in a single transaction. Think of them as transaction aggregators.

Bundlers:

• Monitor the UserOperation mempool

• Validate operations off-chain (checking gas, signatures, etc.)

• Bundle multiple UserOperations into a single on-chain transaction

• Submit the bundle to the EntryPoint contract

• Get compensated for gas costs + fees

This is where infrastructure providers like Alchemy excel- their bundlers optimize gas efficiency and provide reliable execution.

3. EntryPoint Contract

The EntryPoint is a singleton smart contract that serves as the execution coordinator for all ERC-4337 operations. Every version of it () is deployed at the same address on every EVM chain - current version is 0.7.0 and is deployed at 0x0000000071727De22E5E9d8BAf0edAc6f37da032.

The EntryPoint:

• Receives bundled UserOperations from bundlers

• Validates each operation by calling the account’s validation logic

• Handles gas payments (either from the account or via paymaster)

• Executes the callData on the smart account

• Manages reverts and ensures atomicity

Here’s a simplified flow:

solidity

function handleOps(UserOperation[] calldata ops, address payable beneficiary) external {
    for (uint i = 0; i < ops.length; i++) {
        UserOperation calldata op = ops[i];
        
        // 1. Validation phase
        uint256 validationData = _validatePrepayment(op);
        
        // 2. Execution phase
        _executeUserOp(op);
        
        // 3. Post-operation (refund excess gas)
        _postExecution(op);
    }
}

4. Smart Contract Accounts

The smart contract account is your actual wallet. It’s a contract that holds your assets and implements custom logic. Every account must implement the IAccount interface:

solidity

interface IAccount {
    function validateUserOp(
        UserOperation calldata userOp,
        bytes32 userOpHash,
        uint256 missingAccountFunds
    ) external returns (uint256 validationData);
}

The validateUserOp function is where your account’s security logic lives. It might:

• Verify an ECDSA signature from your primary key

• Check signatures from 2-of-3 multisig owners

• Validate a session key with spending limits

• Verify biometric authentication via WebAuthn

Here’s a basic example:

solidity

contract SimpleAccount is IAccount {
    address public owner;
    
    function validateUserOp(
        UserOperation calldata userOp,
        bytes32 userOpHash,
        uint256 missingAccountFunds
    ) external returns (uint256 validationData) {
        bytes32 hash = userOpHash.toEthSignedMessageHash();
        address signer = hash.recover(userOp.signature);
        
        // Verify the signer is the owner
        if (signer != owner) {
            return SIG_VALIDATION_FAILED;
        }
        
        // Pay the EntryPoint for gas
        if (missingAccountFunds > 0) {
            (bool success,) = payable(msg.sender).call{value: missingAccountFunds}(”“);
            require(success);
        }
        
        return 0; // Success
    }
    
    function execute(address dest, uint256 value, bytes calldata func) external {
        require(msg.sender == address(entryPoint), “only EntryPoint”);
        (bool success, bytes memory result) = dest.call{value: value}(func);
        require(success, string(result));
    }
}

5. Paymasters

Paymasters are optional contracts that can sponsor gas fees for UserOperations. They implement the IPaymaster interface:

solidity

interface IPaymaster {
    function validatePaymasterUserOp(
        UserOperation calldata userOp,
        bytes32 userOpHash,
        uint256 maxCost
    ) external returns (bytes memory context, uint256 validationData);
    
    function postOp(
        PostOpMode mode,
        bytes calldata context,
        uint256 actualGasCost
    ) external;
}

A paymaster might:

• Sponsor transactions for your app’s users

• Allow users to pay gas in ERC-20 tokens (USDC, DAI, etc.)

• Implement subscription models (X free transactions per month)

Axal sponsors gas for all user operations, making DeFi accessible to everyone.

How a 4337 Transaction Works

Let’s walk through a complete transaction flow:

Step 1: User Creates UserOperation Alice wants to swap 100 USDC for ETH. Her wallet creates a UserOperation:

• sender: Alice’s smart account address

• callData: Encoded call to DEX router

• paymasterAndData: Points to a paymaster that accepts USDC for gas

• signature: Proof of authorization (signed by Alice’s key)

Step 2: Submission to UserOp Mempool The UserOperation is broadcast to the alternative mempool where bundlers listen.

Step 3: Bundler Validation A bundler (like Alchemy’s) receives the UserOperation and validates it:

• Simulates the validation function to ensure it won’t revert

• Checks that gas limits are sufficient

• Verifies the signature format is valid

• Ensures the paymaster has enough funds deposited

Step 4: Bundling The bundler groups Alice’s operation with dozens of others into a single batch and submits one transaction to the EntryPoint contract.

Step 5: EntryPoint Execution The EntryPoint processes each UserOperation:

1. Calls validateUserOp on Alice’s account → verifies signature

2. Calls validatePaymasterUserOp on the paymaster → approves gas sponsorship

3. Executes the swap by calling Alice’s account’s execute function

4. Calls postOp on the paymaster to settle gas payment in USDC

Step 6: On-Chain Result Alice’s swap completes. From her perspective, she just confirmed one operation that swapped tokens and paid gas in USDC- no ETH required, no multi-step process.

---

Part 3: EIP-7702 Introduction

What is EIP-7702?

EIP-7702 (included in the Pectra upgrade, activated March 2025) introduces a new transaction type that temporarily grants EOAs the power of smart contracts for a single transaction.

The key innovation: an EOA can “delegate” its code to a smart contract temporarily, gaining programmable features without permanently converting to a smart account.

The EOA-to-Smart-Account Bridge

Here’s the mechanism:

1. An EOA creates a special transaction that includes:

   • An authorization tuple: (chain_id, address, nonce)

   • A signature authorizing the delegation

   • The address of a contract to delegate to

2. During that transaction, the EOA’s code pointer temporarily points to the delegated contract

3. After the transaction, the EOA reverts to a normal EOA

Example authorization structure:

python

authorization = {
    ‘chain_id’: 1,  # Ethereum mainnet
    ‘address’: ‘0x...’, # Address of the account implementation
    ‘nonce’: 5,
    ‘signature’: ‘0x...’ # ECDSA signature from EOA
}

This means an EOA can:

• Execute batched transactions

• Use paymasters for gas sponsorship

• Implement custom validation logic

• All without deploying a new smart contract permanently

How 7702 Complements 4337

EIP-7702 and ERC-4337 are complementary:

ERC-4337 provides:

• Full account abstraction for dedicated smart accounts

• Persistent programmable wallets

• Infrastructure (bundlers, paymasters) that works today

EIP-7702 provides:

• A migration path for existing EOAs

• Temporary smart account features without deployment costs

• Backward compatibility with existing wallets

The synergy: users can test account abstraction features with their EOA (via 7702) before committing to a full smart account (via 4337). Once they see the benefits, they can migrate permanently.

A practical flow:

1. User starts with MetaMask EOA

2. Uses 7702 to batch approve + swap in one transaction

3. Experiences the UX improvement

4. Decides to deploy a full ERC-4337 account for persistent features (social recovery, spending limits)

---

Part 4: Why This Matters

Real-World Use Cases

1. Onboarding Without ETH A DeFi protocol can sponsor gas for new users. They deposit USDC via a fiat on-ramp, and immediately start earning yield- no need to buy ETH first.

2. Batched Transactions Approve 5 tokens and execute 5 swaps in a single confirmation. What used to take 10 clicks now takes one.

3. Social Recovery Lost your device? Your social media accounts can help you log into the wallet.

4. Session Keys Authorize a gaming dapp to make transactions up to $50 for the next 24 hours- no pop-up for every action. Revoke anytime.

5. Subscription Payments Allow a smart contract to pull $10/month for a service, with built-in spending limits and cancellation logic.

The Future of Wallet UX

Account abstraction isn’t just a technical upgrade- it’s a UX revolution. Consider what becomes possible:

• Gasless transactions: Users never think about gas fees

• Biometric authentication: Face ID or fingerprint instead of seed phrases

• Automated strategies: DeFi positions that rebalance themselves

• Inherited accounts: Your crypto can be passed to heirs via time-locked mechanisms

• Compliance-friendly: Built-in transaction limits and reporting for institutional users

Platforms leveraging this infrastructure- like Alchemy’s Account Kit with optimized bundling (MAv2) - are already enabling these experiences at scale.

What’s Coming in This Series

Now that you understand the foundations, we’ll dive into the technical details that make account abstraction production-ready:

Next (Part 2): We’ll explore paymaster patterns- verifying paymasters, ERC-20 paymasters, and how to implement gas sponsorship securely. You’ll see code examples and learn how to design gas policies that balance UX and economics.

Part 3: We’ll dissect bundler infrastructure, the UserOperation lifecycle from mempool to execution, MEV considerations, and how Alchemy’s MAv2 achieves superior gas efficiency.

Part 4: We’ll implement EIP-7702, design migration paths from EOAs to smart accounts, and examine the security, cost, and regulatory considerations for production deployments.

---

Conclusion

Account abstraction represents the biggest leap forward in blockchain UX since the invention of wallets. ERC-4337 provides a production-ready framework that works today, while EIP-7702 offers a bridge for the hundreds of millions of existing EOA users.

The infrastructure is live. The standards are proven. The only question is: which builders will leverage these capabilities to create the next generation of user-friendly blockchain applications?

In our next article, we’ll explore how paymasters enable gas sponsorship—one of the most powerful UX improvements account abstraction enables.

---

Want to experience account abstraction in action? Axal leverages Alchemy’s optimized bundling infrastructure to provide seamless, gasless transactions for our users. Create an account to see the future of Web3 UX today.