Account Abstract: Signs of On-Chain Ecosystem Transitioning into a Buyer's Market
TechFlow Selected TechFlow Selected
Account Abstract: Signs of On-Chain Ecosystem Transitioning into a Buyer's Market
This article will introduce account abstraction and ERC-4337, and based on the application of account abstraction and the development of Web2 account systems, speculate on the future evolution of Web3 account systems and the ownership of traffic entry points.
Navigating Web3 tides with focused insightsAuthors: CloudY, Jam
Wallet accounts are an essential gateway to Web3, and the UTXO model of Bitcoin versus the account model of Ethereum has long been compared in terms of strengths and weaknesses. Each approach has its merits, so rather than declaring one superior, it's more accurate to assess which is better suited for specific use cases.
In reality, the Ethereum EOA (Externally Owned Account) being used as a benchmark is a relatively primitive product. Specifically:
• Account control is overly simplistic—either fully authorized or not at all. Whether executing a $1 transaction or a $100 million transfer, users must first approve and then sign. This means falling victim to malicious permissions differs from legitimate transactions by just one signature, making every new user extremely cautious during interactions. While MetaMask now allows users to set spending limits when approving token permissions, frequent interactors often prefer granting full allowances to avoid repeated approvals and gas fees. Compared to Web2 systems like Two-Factor Authentication (2FA) or USB security keys for high-value transactions, and facial recognition or passwordless payments for small ones, EOA accounts feel rigid and difficult to use.
• The high barrier of gas fees deters many new users. Ethereum mainnet and Layer2s such as Optimism and Arbitrum require ETH as gas, forcing users to convert fiat into USD stablecoins, then exchange them for ETH before transferring to their wallets. Many users only realize they need ETH after depositing stablecoins, requiring another purchase. Furthermore, chains like BSC, Polygon, and Solana each have their own native gas tokens, creating yet another pitfall for newcomers. Additionally, most users don’t actually want to hold gas tokens but are forced to keep surplus balances due to on-chain interaction requirements.
Vitalik and the Ethereum team have long recognized these usability issues and have been working on solutions—account abstraction being one of them. However, since modifying Ethereum’s base-layer consensus to enable account abstraction was impractical, it wasn't until ERC-4337—an application-layer standard based on smart contract wallets—was proposed that account abstraction gained real traction and became a hot topic.
This article introduces account abstraction and ERC-4337, then explores the future evolution of Web3 account systems and potential traffic gateways, drawing parallels with the development of Web2 account models.
From an ecosystem perspective, users previously needed EOAs to perform complex on-chain operations, and due to limited growth in the current ecosystem, only a narrow range of protocols were available, leaving actual user needs unmet. Account abstraction simplifies execution—users provide input and receive output without constant clicking and repetitive signing. In essence, the adoption of AA shifts the on-chain ecosystem from seller-driven to buyer-driven.
Account Abstraction (AA) and ERC-4337
What exactly is account abstraction (hereafter referred to as AA)? It abstracts underlying technologies and data structures to simplify operations for users and developers. Simply put, it brings Contract Account (CA) functionality on top of EOA.
ERC-4337 has become the foundational standard for AA. It introduces UserOperation—a special type of transaction representing user intent—allowing contract accounts to proactively execute actions. These UserOperations are managed by a role called Bundler, which simulates execution and adds valid operations to a dedicated mempool. Then, the EntryPoint contract verifies and executes these operations to fulfill user intents.
Account Types
Ethereum has two primary account types: Externally Owned Accounts (EOA) and Contract Accounts (CA).
An EOA address is 20 bytes long, derived from a private key generated upon creation and the corresponding public key via elliptic curve cryptography. The state of an EOA includes nonce (transaction count) and balance (asset amount). A Contract Account address is also 20 bytes, computed from the sender’s address and nonce of the contract creation transaction. Its state includes nonce, balance, code hash, and storage root hash—the Merkle Patricia Trie root storing contract data.
These account types and their states are crucial for Ethereum transactions and smart contract execution, and represent the core differences between EOA and CA.
Transactions
An Ethereum transaction includes sender and receiver information, digital signature, nonce, value transferred, optional data, gas limit, and gas fee. These two distinct account types result in two fundamentally different communication patterns.
During signing, transaction data is hashed and digitally signed. Validators verify the signature by computing points on the elliptic curve, requiring only the public key and transaction data—not the private key. Public key recovery uses the "v" value in the signature, ensuring both security and efficient verification.
Account Abstraction
Ethereum’s transaction structure and signature verification reveal a critical limitation: only EOA accounts possessing a public-private key pair can initiate transactions.
Contract accounts lack a key pair and thus cannot initiate transactions independently. They only react—executing smart contract logic upon receiving a transaction, sending messages to other accounts, or deploying new contracts. Therefore, mainstream wallet apps like MetaMask currently create EOA accounts. However, EOAs come with several drawbacks: private key risks, limited signature algorithms, excessive signing authority, and gas cost constraints.
Contract accounts can store code and data and execute predefined logic to resolve EOA limitations. But they cannot initiate transactions autonomously.
Account abstraction improves upon these two models by blurring the line between them—creating a generalized account with complex logic capable of combining functionalities of both CA and EOA.
ERC-4337
ERC-4337 achieves account abstraction without altering Ethereum’s consensus layer, making it the de facto adopted solution. It realizes the ultimate vision of off-chain coordination and on-chain settlement.
• UserOperation
ERC-4337 introduces a new concept called UserOperation to solve the problem of contract accounts’ inability to initiate transactions, while avoiding changes to Ethereum’s base-layer transaction format.
UserOperation resembles a standard transaction but represents user intent rather than direct action. Standard transactions go to Ethereum’s mempool, where searchers and builders assemble blocks, usually selecting those with highest rewards. In contrast, UserOperations are not real transactions, so ERC-4337 introduces a new mempool and a new actor—the Bundler—to decentralize their execution. This innovation enables processing of user intentions without direct participation in the standard transaction flow.
• Bundler
When handling UserOperations, the Bundler first performs basic validity checks, then simulates execution to confirm signature validity. If simulation succeeds, the UserOperation enters the UserOperation mempool, awaiting on-chain execution. To ensure consistency between simulation and real execution, UserOperations are restricted from accessing variables that may change during execution, allowing access only to data tied to the sender’s address. Bundlers can prioritize operations based on their own preferences, typically favoring higher-fee requests. Ultimately, the Bundler sends batches of valid operations to the EntryPoint contract for on-chain execution.
• EntryPoint
EntryPoint is a singleton contract on Ethereum responsible for executing UserOperations. It has two key functions: handleOps and handleAggregatedOps, both of which first validate the UserOperation—checking account status, signature validity, and fee payment—then proceed to execution. During execution, it invokes smart contract code within the target contract account using data from the UserOperation. Different smart contract wallet protocols may implement parsing and execution differently.
• Data
According to SixdegreeLab’s semi-annual ERC-4337 data report:
-
Since deployment of the ERC-4337 contract, over 687,000 AA wallets have been created on-chain, with over 2 million UserOps invoked. However, 88.24% of AA wallets have been used fewer than five times, mostly for simple transfers or NFT minting.
-
Among 15,000 Bundlers, Pimlico holds 43.48% market share, while Alchemy achieved record revenue of about $20,000.
-
Yet 97.18% of bundled transactions contain only one UserOp, meaning 90% of Bundlers cannot profit from bundling.
-
117 Paymasters collectively covered $465,000 in gas fees across 19 million UserOps, with Pimlico paying 43.45%.
-
ZeroDev dominates Wallet Factory deployments, accounting for 62.63%.
-
The most common way to build AA wallets is LEGO-style—mixing third-party Paymasters, Wallet Factories, and Bundlers.
This shows that ERC-4337 adoption still has significant room to grow, and infrastructure is only beginning to take shape—making the future of AA highly promising. With the rise of Layer2 and social applications, AA wallet usage is poised for rapid growth.
Future Directions of Account Abstraction
Having understood the fundamentals of account abstraction and the architecture of ERC-4337, we now explore further expansion possibilities. Rather than reiterating basic features like keyless or gasless smart contract wallets, we focus on deeper innovations within AA components:
Architecture
Native Account Abstraction
ERC-4337 is merely an application-layer workaround due to Ethereum’s inability to modify its base-layer consensus. Although it popularized the concept of account abstraction, it ultimately relies on contract accounts for indirect interaction. Additional gas costs from validation, competition from alternative ERC standards, and dApp restrictions on contract account interactions hinder ERC-4337’s scalability.
Thus, native account abstraction—especially on Layer2—is particularly important. Currently, only Starknet and ZKSync support native account abstraction. As shown below, native solutions eliminate the need for Bundlers and Paymasters. Starknet uses Sequencers to order transactions, pay gas, and execute them. ZKSync uses Operators for ordering and gas payment, then calls the bootloader for execution.
DeBank Chain, announced to be built on OP Stack, plans to natively integrate an account abstraction-like system at the chain level, though its exact architecture remains to be seen upon mainnet launch.
NFT Contract Wallets
NFT contract wallets are application-layer account abstraction schemes similar to ERC-4337. They equip EOA-owned NFTs with CA capabilities without relying on Bundler calling EntryPoint. Two major implementations exist: ERC-6551 and A3S Protocol.
ERC-6551 allows users to use an ERC-721 NFT in their EOA wallet as a controller for one or more newly created smart contract wallets. This “bolt-on” method attaches a wallet contract to existing NFTs without modifying the ERC-721 standard itself, combining NFT utility with account abstraction concepts.
A3S Protocol, on the other hand, turns the NFT’s own smart contract into a wallet. Assets reside directly within the NFT’s contract and move seamlessly with ownership transfers—eliminating the need for external wallet contracts. This shorter path achieves NFT wallet functionality but sacrifices compatibility with existing NFTs.
For unified multi-chain wallet addresses, both approaches use a salt value to generate identical addresses across EVM-compatible chains, solving the issue of fragmented contract account addresses. This very issue caused Wintermute to lose 20 million OP tokens by sending to incorrect multi-sig addresses across chains.
Modularity and Cross-Chain Abstraction
Modular account abstraction aims to minimize development and maintenance costs—similar to OP Stack—freeing wallet developers to focus on product innovation rather than infrastructure. Naturally, the resulting modular ecosystem becomes the foundation of such platforms. Thus, modular account abstraction must achieve:
• Inter-composability of modules (EIP-6900 attempts to standardize this)
• Functional diversity (signature schemes, privacy, MEV resistance, on/off-ramps, intents, etc.)
• Security (standardized modules to prevent storage conflicts)
• Cross-chain abstraction (Vitalik proposes a unified single-chain key repository contract to coordinate cross-chain smart contract accounts)
Earlier we mentioned using salt values to unify multi-chain contract addresses. But consistent addresses are just the first step. More importantly, users should experience no friction during cross-chain operations—true cross-chain abstraction. This is both a critical milestone for modularity and a cornerstone of account abstraction.
Signature Verification
Previously noted, all Ethereum transactions must be initiated by EOAs paying ETH as gas. Moreover, EOAs are limited to ECDSA signatures, making them cumbersome, functionally limited, and vulnerable to private key exposure. When quantum computers arrive, Ethereum EOAs will become sitting ducks.
Signature Algorithms
Currently, there are smart contract-based solutions for multi-signature and social recovery (e.g., Gnosis Safe, Argent), and "signature abstraction" schemes enabling broad contract interaction after one-time authorization (e.g., Lens Protocol). But following “Not your keys, not your coins,” we should also examine signature algorithms themselves:
• Signature Aggregation
Using Schnorr or BLS enables more efficient, compact signatures. This supports native multisig and reduces gas through aggregation. However, challenges remain: additional communication rounds, inefficiency for large m-of-n setups, and high verification overhead.
• Post-Quantum Secure Signatures
One-time signatures like Lamport or W-OTS protect against quantum attacks by preventing adversaries from deriving private keys from public data to forge messages.
UserOperation
ERC-7521 Intent-Centric
Comparing account abstraction—especially ERC-4337—with intent-centric architectures reveals that Bundler and Solver could be the same entity. That is, the interaction content ("UserOperation") could be proposed by the Bundler, who interprets user intent, suggests a matching resolution path, submits it to the EntryPoint for user validation to prevent malice, and finally executes the verified path.
Combining account abstraction with intent enables simultaneous abstraction of accounts and interactions, delivering user experiences surpassing Web2.
Entire transactions can leverage zero-knowledge proofs for privacy-preserving payments via witnesses/challenges and responses. Users prove transaction validity without revealing sender addresses, batch multiple transactions into a single proof to reduce computation, and significantly improve scalability—achieving cost reduction and efficiency gains. Enterprise users subject to regulation can selectively disclose transactions to authorities without compromising confidentiality, meeting compliance needs.
Bundler
Bundler MEV and Bundler Competition
Both Bundler MEV and Bundler Competition stem from immature infrastructure. Bundler MEV arises because Bundlers, like Searchers, can reorder UserOperations for profit. Bundler Competition occurs when multiple Bundlers attempt to bundle the same UserOperation—similar to Gas Wars among Searchers. The Bundler whose transaction fails pays gas but gains nothing.
Solutions can borrow from existing infrastructure like MEV-Boost, establishing communication channels between Bundlers and between Bundlers and Block Builders. Etherspot is developing a p2p network for AA mempools, where pending UserOperations propagate peer-to-peer. Once packed and processed on-chain, they’re marked and removed, preventing redundant packaging.
Paymaster
Paymaster On/Off-Ramps
Paymasters can cover users’ gas fees and accept any token or fiat in return. Integrating Paymasters with payment providers to offer on/off-ramp services is a powerful approach.
Visa deployed two experimental Visa Paymaster contracts on Ethereum’s Goerli testnet—one exploring fee payments in non-ETH tokens including stablecoins, the other testing direct transaction sponsorship. Integrating Paymaster with ERC-20 requires an oracle for price feeds and checks on whether the Paymaster approves charging users in specified tokens. With mature implementation, direct Visa card payments in fiat—or real-time conversion to ERC-20 tokens—could abstract away on/off-ramps, dramatically lowering entry barriers for Web2 users.
Evolution of Web3 Account Systems and Future Web3 Gateways
The evolution of Web2 traffic gateways and corresponding account systems reflects the rapid advancement of the second-generation internet and shifting user demands.
Initially, users accessed the internet through portals offering curated online resources. Then came search engines, allowing keyword queries and returning results via URL analysis. The rise of social platforms—both PC and mobile—enabled passive discovery via media platforms or active engagement through self-publishing. This era saw two shifts from passive to active behavior and one wave of information decentralization.
Web2 account systems evolved accordingly—from SMS/MMS using phone numbers as IDs, to QQ/WeChat/blogs/weibo creating diverse accounts with rich features and independent digital identities. Platforms introduced profiles and contact lists, expanding user identity beyond simple URLs to complex user IDs and social graphs.
With advances in network and hardware technology, two distinct ecosystem-building strategies emerged:
-
“iOS + Apple Pay + App Store” and “WeChat Pay + Mini Programs” leveraged their account and payment dominance to open ecosystems for third-party developers, retaining users within their walled gardens.
-
“Taobao + Alipay” and “Douyin + Douyin Pay” built their own account and payment systems atop massive app-driven traffic, later integrating other apps under a unified framework.
Both models proved effective and carved out dominant positions—WeChat fulfills most user needs in one app, while Alipay integrates widely across platforms.
Overall, Web2 gateways aimed to empower users with more autonomy and decentralized access, while account systems evolved from monolithic to rich and multifaceted, growing ecosystems through two strategic paths.
Account Systems
The evolution of Web3 account systems retains echoes of Web2 while forging unique paths.
Web3 account evolution inherits aspects of Web2 while charting new directions. Multiple account types have emerged: browser wallets like MetaMask, software wallets like Math and Trust, “operating platforms” like dAppOS and Gnosis Safe, and embedded wallets like UniPass and OKX Web3 Wallet inside dApps or exchanges.
-
Browser wallets like MetaMask resemble early SMS—meeting basic needs, functional anywhere, but overly simplistic.
-
Software wallets like Math and Trust enhance core features with UX improvements—multi-account management, social modules, companion apps—akin to how QQ and WeChat evolved.
-
Operating platforms like dAppOS and Gnosis Safe elevate foundational tools into advanced account systems, building mini-program-like ecosystems around themselves—similar to Apple or WeChat.
-
Embedded wallets like UniPass and OKX Web3 Wallet follow the Alipay/Douyin Pay model—leveraging viral app traffic to grow users and form alliances to expand ecosystems.
Traffic Gateways
We previously stated in “Web3 Traffic Gateways”:
“Based on how users enter Web3, we categorize Web3 gateways into two broad types:
-
Account systems (on/off-ramps & fund management): centralized exchanges, standalone on/off-ramp projects, aggregators, crypto ATMs, crypto debit cards, OTC; EOA, CA, MPC wallets, and account abstraction (AA).
-
Web3 dApps (tools, social, entertainment): DEXs, NFT marketplaces, domains, DeSoc, IP markets, GameFi, X-to-Earn.”
We still stand by this view. But given the above discussion, all these gateways can become part of an AA wallet. Conversely, they split AA adoption into two paths—account-first vs. app-first: do users get an account before interacting with apps, or vice versa?
Wallet Mini-Programs and Wallet-as-a-Service
Looking at AA adoption trends: Instadapp launched Avocado, an independent AA wallet. Then MetaMask released Snaps—mini-program components supporting partial AA features. Payment giant Visa tested Paymaster integration, even enabling Visa card payments. Soon after, social app Lens Protocol experimented with ERC-6551 for AA wallets. Safe added ERC-4337 support to strengthen its “mini-program” marketplace. OKX Wallet enabled AA functionality. Circle launched its own AA wallet.
Two clear adoption patterns emerge:
-
Existing wallets launch or integrate AA features, leveraging their user base and internal mini-apps to attract and retain users.
-
Applications, exchanges, or payment providers leverage their traffic advantage to convert users into AA wallet holders.
This leads to our central question: Since AA will shift the on-chain ecosystem from seller-centric to buyer-centric, which model will users prefer?
Mini-Programs
In the short term, the mini-program model—building ecosystems atop native wallets—is more likely to gain user acceptance. At its core, it’s a To-C strategy. Most early AA adopters are already Web3 natives, so wallets feel familiar and require no learning curve. Rich features and smooth UX further attract and retain them. Take MetaMask Snaps: by exposing APIs for third parties to build mini-programs—even on non-EVM chains—it appears to drive traffic elsewhere, but in fact educates users and strengthens its own ecosystem. There’s no doubt that once MetaMask fully embraces ERC-4337, it will dominate the AA wallet space.
Take dappOS as an example:
dappOS = dappOS Account (unified multi-chain EOA) + dappOS Network.
dappOS Account: Enables users to adopt a “unified account” based on account abstraction instead of standard EOAs, enabling account recovery, pre-batching, automation, and unified asset management across chains.
dappOS Network: A decentralized network that automatically handles wallet and cross-chain operations, abstracting away complex backend interactions.
dappOS abstracts away concepts like accounts, blockchains, and gas tokens, delivering a Web2-like UX. Though still early with limited partner dApps, user growth continues because migration benefits outweigh costs—especially for users managing multiple accounts and chains. Crucially, once onboarded, users rarely leave: they’re educated from day one to use only AA wallets; dappOS satisfies most needs; and even if they want to migrate, cross-chain abstraction makes the process cumbersome.
Clearly, mature wallet products can quickly acquire and retain Web3 AA users—examples include Safe, Avocado, OKX Wallet, etc.
WaaS
WaaS represents the application-first alternative to the mini-program wallet route. Here, apps come first, wallets second—a To-B strategy. Apps use WaaS to customize wallets tailored to their features, pick from standardized modules, leverage app traffic to scale their ecosystem, build AA wallet platforms, then pivot to C-end with customizable user wallets.
Take Stepn: a breakout app with tens of millions of global users, each having created a wallet through Stepn. If Stepn embeds an AA wallet as its core—not just the GMT token—and expands its ecosystem (e.g., MOOAR NFT marketplace, Mahjong game, Gashero), this single AA wallet could bring millions of new users to crypto—all highly sticky due to high migration costs.
The same applies to Friend Tech: every Twitter user is a potential AA wallet user. Fiat on-ramps and gas sponsorship remove Web3 interaction barriers, enabling fast onboarding.
In practice, watch WaaS Pay and UniPass—representative of the WaaS path:
• WaaS Pay is a smart contract account deployment platform built on Safe{Core} protocol suite and SDK, designed for organizations seeking instant blockchain payments with strong privacy. It offers a user-friendly no-code interface to customize features like social login, fiat on/off-ramps, and gasless transactions for recipients. Powered by ZKBob’s zero-knowledge proofs (ZKP), WaaS Pay ensures financial data remains secure and confidential. Hosted on Polygon zkEVM for scalability and efficiency, with self-hosted IPFS nodes via Helia protecting sensitive metadata.
• UniPass is essentially an SDK for third-party dApps, allowing them to bypass traditional private key management, complex signing flows, gas fees, or centralized email-bound address hosting. Using DKIM verification, it enables non-custodial email-controlled accounts. Through Relayer, it simplifies on-chain interactions—offering gasless, signature-abstraction, and social recovery features that greatly enhance UX. As a use-case-driven app, UniPass adopts a federated social network model, providing customized services to different apps while building an interoperable account system. Leveraging this interoperability, it securely anchors social relationships on-chain—preserving data ownership and privacy—creating verifiable DID use cases to attract more dApps to integrate UniPass SDK. These apps’ users naturally become UniPass users, continuing their Web3 journey with high stickiness.
Thus, WaaS-path AA wallets hold greater potential for growth and Web2 user acquisition. However, success heavily depends on product quality and business development prowess. Once network effects kick in, momentum builds—making it a late-bloomer with long-term staying power.
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
