The reality of the account abstraction stack

Bundler and paymaster dominance

Bundlers act as the equivalent of EOA mempool relayers, but they run a validation simulation locally before accepting a UserOp into the mempool. If the simulation passes but the onchain transaction reverts, the bundler eats the gas. This is why bundlers enforce a restricted opcode list during simulation. Pimlico and Alchemy lead the bundler and paymaster market with the widest chain coverage across Ethereum, Base, Arbitrum, and Optimism. Pimlico provides a single API surface for its bundler and paymaster services. Its ERC-20 paymaster allows users to pay gas in tokens like USDC, USDT, or DAI by pulling the equivalent value from the account during the postOp phase. I find the Pimlico exchange rate model efficient because the provider bakes its fee directly into the rate to cover infrastructure and slippage. Alchemy bundles its paymaster into the Account Kit SDK. Its Gas Manager acts as a sponsorship-only product with a policy dashboard and per-user spend limits. Coinbase Developer Platform Paymaster also provides sponsorship on Base, but it charges sponsored gas plus a 7% fee. Verifying paymasters dominate gas-sponsorship APIs. These systems use an off-chain signer to evaluate a UserOperation against business logic, and the on-chain contract verifies the signature in validatePaymasterUserOp. Biconomy also provides both sponsorship and ERC-20 modes. Biconomy’s modular account stack integrates with its paymaster and includes a session model where a user can spend gas from a prefunded allocation without re-signing.

Account implementations

The market splits between minimal implementations like Alchemy’s LightAccount and modular systems like ZeroDev’s Kernel. LightAccount provides a single-owner account optimized for gas costs in high-volume consumer apps that do not need module installation. ZeroDev’s Kernel account allows developers to extend functionality with plugins, enabling a single account to hold an ECDSA validator, a passkey validator, and a session-key validator. This allows a single account to manage different permissions simultaneously. Kernel users can also use ERC-7715 session keys to scope sponsorship to a specific contract allowlist. I see a clear trade-off where developers must choose between the gas efficiency of a single-owner account and the flexibility of modular validators. Different vendors ship different implementations, each with trade-offs across audit history, modularity, gas cost, and recovery features. Safe fits treasuries, DAOs, and any team that needs multi-signer governance. Etherspot offers ERC-7579 support plus a built-in session-key system for teams that want a modular shape without writing module code themselves. Developers must choose between the minimal ERC-7579 standard and the more opinionated ERC-6900 standard led by Alchemy. Safe remains the standard for treasuries and DAOs that require multi-signer governance and have tens of billions in TVL.

Technical trade-offs

EntryPoint v0.7 reduced calldata costs by packing callGasLimit and verificationGasLimit into a single accountGasLimits field. This redesign cuts roughly 7,000 gas off a typical UserOperation. The v0.7 redesign also requires paymasters to implement postOp with an explicit mode parameter to fix edge cases where a paymaster could be charged for a transaction that reverted after its initial check passed. The counterfactual deployment pattern matters because ERC-4337 supports counterfactual deployment, where a user’s account address is computed deterministically from the factory address, the implementation address, and a salt. Every account implementation has its own factory, such as SafeProxyFactory, KernelFactory, or LightAccountFactory. The factory typically takes the owner’s public key plus a salt and returns the new account’s address. I observe that while Pimlico and Alchemy lead in infrastructure, the modular reality of Kernel creates a different developer experience.

Developers using modular stacks must maintain separate integration paths for EIP-4337 bundlers, paymasters, and custom signature schemes. This complexity acts as a tax on innovation. You should decide if your application requires the enterprise-grade security of Safe or the flexibility of Kernel. Can the market consolidate around a single validator standard?