OKX Ventures: A Systematic Analysis of the Past, Present, and Future of the Account Abstraction Sector

2023.09.22

OKX Ventures: A Systematic Analysis of the Past, Present, and Future of the Account Abstraction Sector

OKX Ventures systematically reviews the past, present, and future opportunities of account abstraction by tracing back to its conceptual origins.

2023.09.22 - 10:43:53

Navigating Web3 tides with focused insights

OKX Ventures systematically reviews the past, present, and future opportunities of account abstraction by tracing back to its conceptual origins.

Author: Kiwi, Researcher at OKX Ventures

This article does not constitute any investment advice.

Since Vitalik Buterin introduced EIP-4337 in September 2021, the concept of account abstraction (AA) has gradually been integrated into mainstream Web3 wallets. Starting from the origin of this concept, OKX Ventures systematically reviews the past, present, and future opportunities of account abstraction.

Key Takeaways

About fundamentals:

Account Abstraction (AA) supports session keys, decoupling transaction sources from signatures while helping users avoid complex operations like backing up private keys or paying gas fees—lowering the barrier to Web3 participation;

To simplify account types, grant greater flexibility for on-chain actions, and elevate accounts to a higher security level, account abstraction is needed.

After EIP-86, EIP-1014, EIP-2938, and EIP-3074, EIP-4337 has essentially become Ethereum’s finalized AA solution due to its compatibility without requiring consensus-layer changes.

Two paths for multi-chain account abstraction: 4337-compatible method and native account abstraction.

4337-compatible approach: Currently, Arbitrum, Polygon, Optimism, and BNB do not natively integrate account abstraction. However, support is often provided through 4337-related products (e.g., Biconomy, Stackup), with infrastructure still largely in the conceptual stage;

Native account abstraction: Starknet and zkSync support native AA, differing from the 4337 model. Differences include: Starknet lacks Bundler and Paymaster; Sequencer determines transaction order, pays gas, and executes. zkSync uses Operator to determine order and pay gas, then invokes bootloader to operate.

Development data: Over 520,000 AA accounts have been deployed across Ethereum, Arbitrum, Optimism, and Polygon, with over 80% created in July-August, driven primarily by new AA product launches on Polygon and Optimism. Few protocols currently offer Bundler and Paymaster services, with projects like Pimlico and StackUp dominating across chains.

Opportunities brought by AA:

Paymaster is a smart contract deployed by dApps that allows specified UserOperations to have their gas paid via Bundler-triggered Paymaster. As a standardized service, Paymaster struggles to stand alone as an independent project but can serve web3 business as a feature integrated by web2 traffic platforms. Commercial opportunities include: subsidized traffic entry points, automatic exchange, integration with DeFi/gaming projects for user referral—similar to innovations in the traditional payment industry. While Paymaster innovation paths are limited, it captures value most stably, lowers barriers for web2 users entering web3, and may attract widespread deployment by web2 institutions.
Bundler is one of the richest opportunity areas, fundamentally similar to relayers, with profit models extending around transaction bundling (e.g., gas arbitrage, MEV, privacy pools catering to B2B needs). However, failed bundles cause financial loss, making transaction selection challenging.
- Protocols already operating nodes and Relayer services can more easily build Bundler networks; RPC as decentralized infrastructure helps decentralize Bundlers;
- Collaboration between Bundler, searcher, and sequencer is preferable, potentially sharing MEV revenue across channels to benefit end users, leading toward fairer distribution;
- Currently all Bundlers operate private pools—no public pools exist. Only Stackup operates profitably; Biconomy performs moderately;
- Bundler is a difficult-to-monetize yet essential public good. No mature operational models exist for such goods, and most teams prioritize privatization for profitability;
- Technical improvements needed: Avoid nonce collisions—p2p networks can optimize via tagging/deletion; modifying contract storage may prevent adequate compensation—requiring proposal-based fixes.
AA and MEV integration: AA, Sequencer, and intent inherently extend on-chain action sequences, lengthening the MEV bribery chain. AA's Bundler and intent solvers could collaborate with roles like Searcher within MEV workflows to form MEV-sharing mechanisms. Theoretically, AA could also share PEV (Prover Extractable Value) income thanks to its Bundler and EntryPoint contracts.

NFTs: Enhanced user experience attracts new users and enables more automated market monitoring and trading. ERC6551 and 4337 both provide account capabilities at the user level, enabling integration with cross-chain gaming, DID, and middleware. Future cross-chain games will require ERC-6551’s composability to deliver multichain + tradable equipment account experiences;

Social and gaming: Identity infrastructure optimization greatly improves product usability. Lowered entry barriers for cross-chain gameplay, optimized account models, and multichain account systems will enable expansive multichain game worlds;

AA and Intent:

Fundamentally, intent and AA aren’t inherently tied. Intent represents UX-layer innovation—better/faster understanding and decomposition of user needs into one or multiple UserOperations. AA is backend optimization enabling better execution of user commands. Telegram bots exemplify intent innovation, yet still rely on EOA wallets without affecting UX.

Intent involves solving optimal op routes toward specific goals. Past intents focused on simple demands; future developments may involve multi-condition, multi-step, multi-environment complexity—even incorporating AI agents.

Intent opportunities: Frontend reduces signature frequency, improving UX. Application layer can spawn new infrastructures, languages, and solver paradigms based on intent narratives—one of the most promising use cases ahead.
- Intent intermediary pools or intent-centric blockchains: Intent-based apps involve not only new message formats for interacting with smart contracts but also alternative mempool forms for propagation and counterparty discovery. Designing incentive-compatible yet non-centralized intent discovery and matching mechanisms remains challenging.
- Diverse Solver implementation paths: In the short term, established Super Smart Contracts will lead integration. Long-term, highly autonomous AI will be ideal—but extremely hard to implement. Solvers will introduce off-chain preprocessing followed by on-chain execution—a paradigm favorable to automation protocols (e.g., Uniswap X). Currently, ZK coprocessor Axiom serves as a demo for private solving.
- New language for expressing intent: Projects like Juvix and Essential already exist. First-mover advantage matters here, requiring early trust-building among users.
Wallet and gateway opportunities: Wallets can fully function as intent layers, significantly elevating their strategic position as traffic gateways and infrastructure for various protocols. Backend intent systems can integrate traditional EOA, MPC, and smart contract wallets. Trading and cross-chain applications will improve user experience through diversified entry points (e.g., automation, multi-path options);

ZK application opportunities: Users’ intents create significant demand for encryption. 4337’s built-in mechanisms support private payments. Deeper integration will evolve within the zkProof ecosystem.

Risks and barriers: Intent requires strong trust assumptions, creating high entry thresholds that lead to excessive centralization and insufficient innovation.

Key projects:

The account abstraction market includes two types of players: one category comprises smart contract wallets featuring social login/recovery, gas abstraction, batch transactions, and integration/aggregation of third-party services (e.g., fiat on/off ramps and DeFi protocols)—this sector sees many startups with immature solutions. The other category includes modular providers of Bundler and Paymaster components, most of which remain early-stage except Biconomy and Stackup.

Notable projects: Biconomy, Stackup, and Pimlico represent mature 4337 solutions today. Continued refinement of SDKs and modular offerings helps capture first-mover advantages and achieve broad market coverage. Stackup already supports two types of Paymasters and Bundler modes. Full-stack solutions combined with diverse component libraries will help these leaders further widen their lead.
- Pimlico leads in Bundler market share (accounting for 52% of total bundled UserOps across chains) and profitability (top profit on Polygon, earning 637 MATIC in July; profitable on Optimism too);
- Stackup runs Bundler operations across chains, leading in profitability on Arbitrum (5 ETH in August) and Ethereum (0.4 ETH in July). Its Bundler fails frequently but earns substantially when successful;
Innovative projects: Privacy is a hard requirement—e.g., ZK coprocessor Axiom demonstrates private solving; Nocturne offers composable privacy-AA layer where users deposit funds from EOA or contracts and interact using ZKPs for privacy. AI is trending—e.g., Echooo Wallet combines MPC and AI for multisig and AI risk monitoring. Innovations building on existing projects also shine—e.g., Uniswap team’s Universal Paymaster creates a liquidity marketplace matching wallet users with Paymaster operators.

Other EIPs and opportunities:

EIPs related to 4337: With official direction set by 4337, most proposals now focus on optimizing AA deployment. For example, ERC6551 assists 4337-derived products; EIP6662, ERC6900, ERC1271, ERC6492, EIP7204, and EIP7197 all aim to enhance AA functionality; ERC7377 facilitates future account migration;

Other funded projects: In Q1-Q2 2023, Ethereum granted funding to four account abstraction-related projects. Two were official 4337 team outputs (the AA core team and Trampoline, their 4337 browser wallet). The other two focused on innovative integrations combining 4337 with existing protocols/technologies (zkShield uses ZKP and account abstraction to hide private multisig ownership; Uniswap team’s Universal Paymaster creates a unified liquidity market for ERC-20 gas payment).

Future outlook: Short-term focuses on market expansion and synergistic growth with Layer 2s. Mid-term emphasizes落地of modular Bundler and Paymaster solutions and SDK deployment, along with UX refinements (e.g., lowering gas costs, adding optional EOA-to-ERC-4337 conversion). Long-term considers mandatory EOA wallet migration.

1. Introduction to Account Abstraction

Definition and overview:

The essence of account abstraction is decoupling transaction source from signature;

Why we need account abstraction:

1) Simplify account types;

2) Decouple accounts from signatures, granting greater freedom for on-chain behaviors and placing accounts under higher security levels;

Evolution of account abstraction: Direct distinction involves high engineering complexity. EIP2938 and EIP3074 require consensus-layer changes. Ultimately, EIP4337 was chosen because it doesn't modify the base layer.

Principles of ERC-4337:

Roles: EIP-4337 standardizes smart contract wallets and related infrastructure into five contract interfaces: Bundler, EntryPoint Contract, Paymaster, Wallet Factory, Signature Aggregator, plus a new transaction type (UserOperation).

Transaction steps: Without altering Ethereum’s consensus layer, 4337 introduces a new logic called UserOperation and adds Bundler to bundle UserOps. After the original process, EntryPoint and Wallet contracts split validation and execution to perform custom tasks. Finally, Paymaster abstracts gas payment logic. User initiates UserOp → UserOp sent to “UserOp mempool” → Bundler selects and bundles UserOps into a transaction submitted to EntryPoint → EntryPoint verifies the operation, wallet executes it and includes it in a block.

Comparison between 4337 and other approaches:

EIP-3074 AA approach: Requires introducing two new opcodes to allow EOA accounts to use contracts, involving consensus-layer changes—thus abandoned;

1.1 Definition and Summary

What is Account Abstraction?

Ethereum has two account types: Externally Owned Accounts (EOA) and Contract Accounts (CA). EOAs rely heavily on key management and ECDSA signatures, with rigid operational logic. Their strict binding of signing rights to accounts hinders new user adoption and long-term development;

A solution allowing users to employ smart contract wallets with arbitrary validation logic is needed—this is known as Account Abstraction (AA), whose principle is decoupling transaction source from signature.

Why We Need Account Abstraction:

1) Simplify account types;

2) Decouple accounts from signatures, granting greater freedom for on-chain behaviors and placing accounts under higher security levels;

Evolution of Account Abstraction: Direct differentiation involves high engineering complexity. EIP2938 and EIP3074 require consensus-layer changes. Ultimately, EIP4337 was chosen because it doesn't modify the base layer.

Direct distinction: e.g., adding new transaction types via EIP-86, EIP-101, EIP-859;

Elevate status of certain account types:

EIP-2938: Makes contract accounts "top-level" accounts capable of paying fees and executing transactions;

EIP-3074: Introduces two new opcodes enabling EOAs to use contracts;

EIP-4337: Introduces new operational logic—the UserOperation mempool—to eventually replace the current transaction mempool, achieving full account abstraction.

1.2 Fundamentals of ERC-4337

Overview: In September 2021, Vitalik Buterin collaborated with Ethereum researchers from OpenGSN and Nethermind to propose EIP-4337. It introduces a new UserOperation mempool aiming to fully replace the current transaction mempool, thereby realizing account abstraction.

Roles

UserOperation: Transactions initiated by users, sent to Bundler and grouped with other UserOperations into a Bundle;

Bundler: Node responsible for selecting transactions from the mempool, bundling multiple UserOperations, and creating an EntryPoint.handleOps() transaction;

EntryPoint: Smart contract handling validation and execution of UserOperation bundles, acting as an intermediary between Bundler and smart contract wallet;

Wallet Contract: Smart contract creating contract wallets for 4337 users;

Aggregator: Validates aggregated signatures;

Paymaster: Smart contract helping users pay gas fees.

Transaction Steps

Transaction signing: User initiates a wallet operation, signs the UserOperation using any private key format (instruction unchanged, field content varies, non-ECDSA signatures allowed), generating a signed UserOperation sent to the pending UserOperation mempool;

Send transaction: Bundler aggregates UserOperations from the mempool, then separately signs a wrapper transaction containing user instructions, processing multiple UserOps into one transaction submitted to EntryPoint. Before submission, Bundlers simulate transactions to detect potential failures and calculate sufficient gas. If simulation passes, the batch of UserOperations is submitted as one transaction to block proposers;

Process UserOperation: EntryPoint verifies wallet existence → requests wallet to validate UserOperation → sends UserOperation to smart contract wallet for execution, serving as intermediary between Bundler and wallet;

Block inclusion: Smart contract wallet executes UserOperation and includes it in a block.

1.3 Comparison with Traditional Wallets and MPC Wallets

1.4 EIP-3074 AA Approach

EIP-3074: Requires two new opcodes to let EOA accounts use contracts, involving consensus-layer changes—thus abandoned;

If EIP-4337 enables CA wallets to function like EOAs, EIP-3074 allows external EOA wallets to gain programmable features of smart contract accounts. Core idea: authorize others to issue commands on my behalf via signature.

EIP-3074 introduces two new opcodes: AUTH and AUTHCALL, allowing Users (EOA) to delegate actions to a contract (Invoker Contract—an immutable contract), giving developers a more flexible framework to design transaction objects and verification mechanisms (signature algorithms), enabling any EOA to act like a Contract Account without deploying any contract themselves.

Advantages: 1) Greater flexibility enabling batch transactions, wrapped transactions, fee payments, multisig, etc.; 2) Multiple fee payment options—external accounts can pay Invoker fees using preferred tokens;

Disadvantages: 1) EIP-3074 involves major consensus-layer modifications, requiring hard forks if issues arise; 2) Since EIP-3074 gives EOA accounts characteristics of smart contract accounts, it still relies on fixed ECDSA signatures, unlike EIP-4337 which supports arbitrary signature methods;

EIP-5003: An extension of EIP-3074 (AUTH and AUTHCALL), introducing a new AUTHUSURP opcode. If EOA address A authorizes another address B via EIP-3074, AUTHUSURP allows B to set code for A—effectively upgrading existing EOAs into contracts and enabling migration from ECDSA to more efficient or quantum-resistant signature schemes.

2. Multi-chain Account Abstraction Approaches

Summary

Two paths: 4337-compatible method and native account abstraction.

4337-compatible approach:

Currently, Arbitrum, Polygon, Optimism, and BNB lack native AA integration. Support is instead provided via 4337-related products (e.g., Biconomy, Stackup), with infrastructure still largely conceptual;

Arbitrum passed a proposal in July this year supporting AA endpoints;

Polygon zkEVM indicates in its official documentation that multi-token gas payment will be supported later;

Optimism and BNB provide partial account abstraction infrastructure, including Alchemy, Biconomy, Pimlico, and Stackup.

Native account abstraction: Starknet and zkSync support native AA, distinct from the 4337 model.

4337-Compatible Approach

Arbitrum:

Arbitrum passed AIP-2 proposal on July 17, 2023, regarding endpoint support for account abstraction. Offchain Labs has since activated this support on Arbitrum One and Arbitrum Nova;

The proposal introduces a new RPC endpoint eth_sendRawTransactionConditional, enabling L2 sequencers to adapt to specific needs of ERC-4337 Bundlers.

Polygon:

Polygon supports 4337 compatibility and has released meta-transaction solutions such as Biconomy (multi-chain relay protocol), Gas Station Network (GSN) (decentralized public good protocol assisting gas abstraction), Infura (node provider), and Gelato (relayer SDK supporting multi-token payment).

Polygon states in its official documentation that Polygon zkEVM supports account abstraction via ERC-4337 and will allow users to pay fees with any token—more details forthcoming.

Optimism: Currently provides partial account abstraction infrastructure on OP Mainnet, including projects like Alchemy, Biconomy, CyberConnect, Pimlico, and Stackup; architectural details not yet disclosed;

BNB: According to BNB Chain's 2023 tech roadmap, the official team plans to establish account abstraction infrastructure. 4377 is already compatible on BNB, with more details pending.

Native Account Abstraction

Starknet natively supports account abstraction—all accounts are smart accounts.

Design goals: Signature abstraction (different account contracts using different signature verification schemes) and payment abstraction (varied transaction payment patterns and token forms).

Process: Transactions undergo nonce validation before entering the pool, then are sent to the account smart contract address for verification, and finally added to blocks. These two phases are encoded in separate functions within the account contract: validate and execute.
- Sequencer first requires the account contract to validate the transaction. To prevent DoS attacks, accepting Sequencers must locally simulate transactions against known state before adding them to the mempool and broadcasting.
- After successful simulation, the transaction executes, enters the pool, and propagates across the network.

Differences between Starknet and Ethereum approaches:

In Starknet’s native account abstraction, all accounts are smart accounts and must include validate and execute functions, allowing users to implement arbitrary logic to extend account functionality;

StarkNet supports multiple elliptic curves, enabling highly programmable signature verification; validate ensures only account owners initiate transactions while guaranteeing executors receive sufficient gas—users can implement different signature verification algorithms within the validate function;

Eliminates additional complexity from Bundler: Starknet simplifies the workflow by assigning Bundler responsibilities directly to the Sequencer;

Starknet lacks a Paymaster-like transaction fee abstraction protocol;

No distinction between regular transactions and UserOperations: All Starknet transactions originate from contract accounts. On Ethereum, Bundlers execute UserOperation transactions, whereas on Starknet, Sequencers handle all transactions;

Different methods for deploying contract accounts:
- Starknet requires pre-deployment of contract accounts. Starknet mandates accounts with token balances to call a dedicated deploy_account function to create new contract accounts capable of paying gas;
- EIP-4337 does not require upfront deployment—Bundlers deploy contract accounts by executing UserOperations with non-empty initCode parameters. Deployment doesn’t necessarily require token balance—the gas can be paid by a Paymaster.

zkSync: zkSync Era belongs to the native account abstraction model while remaining EVM-compatible.

Design goals: Signature abstraction (different account contracts using different signature verification schemes) and payment abstraction (varied transaction payment patterns and token forms).

Process: User sends signed Transaction from local environment to Operator, who forwards it to bootloader for validation. After validation and gas collection, bootloader calls executeTransaction on Account Contract to execute the transaction.

Differences between zkSync and 4337:
- zkSync does not distinguish between EOA and contract accounts;
- zkSync allows validateTransaction function to call externally deployed contracts: Because deployed contracts on zkSync are immutable; Ethereum prohibits this to prevent state changes causing validation success but execution failure;
- zkSync allows validateTransaction and Paymaster to access external storage of the sending contract account: e.g., token balances stored in external contracts—prohibited on Ethereum.

Comparison of zkSync, Starknet, and 4337 Approaches

Similarities:

All three AA mechanisms follow similar flows: Verification Phase → Fee Mechanism (paid by Account Contract or Paymaster) → Execution Phase. Smart contract wallet interfaces divide into validateTransaction and executeTransaction;

Mitigating DoS threats: zkSync restricts contract logic to own slots, disallowing global variables; Starknet requires Sequencers to perform local simulation before adding transactions to mempool and broadcasting; 4337 limits gas during validateUserOp step and requires Paymaster staking to deter spam.

Differences:

Native AA: Both zkSync and StarkNet adopt native account abstraction, architecturally distinct from 4337;

On-chain Gas Consumption: zkSync and StarkNet are Layer 2s, needing to consider Rollup fees;

Different actors executing AA: On zkSync, Operator and bootloader (System Contract) cooperate to complete User operations; On StarkNet, Sequencer handles User operations without Bundler or Paymaster; On 4337, Bundler collaborates with EntryPoint to execute User operations;

Ability to send transactions before Account Contract deployment: Neither StarkNet nor zkSync have an initCode field like 4337’s EntryPoint to deploy Account Contracts on behalf of users—so cannot send transactions prior to account deployment;

Calling external contracts: zkSync allows validateTransaction function to call externally deployed contracts; 4337 and Starknet do not permit this;

Paymaster validation rules:
- Starknet has no Paymaster;
- 4337 Paymaster defines two functions: validatePaymasterOp and postOp. The former specifies logic for Paymaster to subsidize transactions; the latter ensures Paymaster can withdraw gas reimbursement after execution. Paymasters must deposit and stake ETH in EntryPoint contract (for gas payment and anti-spam protection);
- zkSync mirrors 4337 with identical validatePaymasterOp and postOp functions, though this functionality isn't yet implemented. Notably, zkSync triggers postTransaction only when gas suffices—unlike 4337, which skips postOp unless context is returned during validatePaymasterUserOp.

3. Development Data

Summary:

Over 520,000 ERC-4337 accounts deployed on Ethereum, Arbitrum, Optimism, and Polygon, with over 80% created in July;

Polygon and Optimism experienced significant growth in July–August due to new AA product launches: Polygon benefited from CyberConnect network launch driving traffic; Optimism saw growth via Beam wallet and ZeroDev;

Lower activity observed on Arbitrum and Ethereum, with only hundreds to thousands of UserOps;

Few protocols currently offering Bundler and Paymaster services—currently dominated by Pimlico, StackUp, and others across chains.

Overview

Interest in 4337 began surging from July 2023, with narrative momentum starting in Polygon and Optimism. CyberConnect emerged as the primary driver behind this AA surge. Paymaster and Bundler gas usage and transaction volume rose sharply, with StackUp, Pimlico, and Biconomy establishing dominant positions.

ERC-4337 EntryPoint contract officially deployed March 1, 2023. By August 30, 2023, total number of on-chain AA users reached ~616,000, with 1.3 million UserOps executed. Compared to Q1 2023, quarterly user operations grew 11,837% in Q2 2023, user count increased over 27,000%;

Currently, Ethereum, Arbitrum, Optimism, and Polygon all support 4337 accounts, with over 80% created in July–August on Polygon and Optimism. Polygon leads with 43.9% of UserOps, capturing 47% of wallet users. Stackup sponsored over $140,000 worth of gas fees.

Paymaster: Total of 96 Paymasters, ~$414,200 in total gas cost. Compared to Q1 2023, Paymaster transaction volume surged 5,182% in Q2. Rising gas volume and transaction counts indicate growing demand for these intermediary services;

Bundler: Total of 1,300 Bundlers, ~$33,800 in total revenue. Around 1,000 Bundlers active on Ethereum in August, with Stackup accounting for 94% (over 940), forming a near-monopoly in this component.

Polygon Data

Currently hosts 340,000 accounts and 560,000 UserOps, experiencing a spike in usage in July with 440,000 UserOps processed.

Primarily driven by the launch of CyberConnect social network, where all accounts are ERC-4337 wallets. Biconomy follows closely, contributing nearly 30,000 account deployments;

July and August Bundler and Paymaster services mainly provided by Pimlico.

Pimlico is cryptographic infrastructure aimed at accelerating adoption of account abstraction. Pimlico focuses on providing comprehensive infrastructure for Bundlers and Paymasters.

Optimism Data

Currently 150,000 accounts and 400,000 UserOps, with substantial increases in ERC-4337 usage and UserOp count from July to August—mainly driven by Beam wallet (allows users to pay fees with transfer-used tokens rather than native chain tokens) and ZeroDev (an SDK built atop ERC-4337 for developing account-abstraction-powered Web3 apps).

Bundler and Paymaster services mainly provided by Pimlico, Alchemy, and StackUp;

StackUp’s SDK enables building customized Web3 transaction flows and wallets using ERC-4337.

Arbitrum Data

Currently 2,200 accounts and 18,000 UserOps, with July–August growth mainly from Zerodev and Biconomy—most others

Join TechFlow official community to stay tuned

Telegram:https://t.me/TechFlowDaily

X (Twitter):https://x.com/TechFlowPost

X (Twitter) EN:https://x.com/BlockFlow_News

Add to Favorites

Share to Social Media

Author

OKX Ventures

OKX Ventures: A Systematic Analysis of the Past, Present, and Future of the Account Abstraction Sector

TechFlow Selected TechFlow Selected