ERC-4337's scaling failure is not gas cost or wallet UX, but the fundamental overhead of verifying individual signatures for every bundled user operation. The current model replicates the Ethereum L1 bottleneck within the bundler network, making mass adoption economically impossible.
Why Signature Aggregation is ERC-4337's Unsolvable Puzzle
A technical analysis of the fundamental barriers—cryptographic, infrastructural, and coordination—that prevent efficient BLS signature aggregation for ERC-4337, limiting its long-term scalability promise.
Introduction
Signature aggregation is the critical, unsolved scaling constraint preventing ERC-4337 from achieving mainstream viability.
The signature verification wall is a first-principles problem. Each ECDSA or BLS operation consumes ~20k-45k gas, which compounds per user in a Paymaster-sponsored bundle. This creates a perverse scaling tax where adding users linearly increases bundler costs, unlike L2 rollups which amortize costs.
Compare to L2 scaling: Arbitrum and Optimism batch thousands of transactions under a single validity proof, achieving ~2k TPS. ERC-4337 bundles today handle dozens. The architectural mismatch is clear: account abstraction needs its own execution layer compression, not just L1's.
Evidence: A bundle with 100 simple transfers requires ~2-4.5M gas just for signatures, dwarfing the core logic cost. Projects like Etherspot's Skandha and Stackup's bundler optimize everything except this root cause, proving it's a protocol-level, not implementation-level, problem.
The Core Argument
ERC-4337's decentralized architecture inherently prevents the signature aggregation required for mass-scale, gas-efficient adoption.
Signature aggregation is impossible under ERC-4337's current design because the UserOperation mempool is permissionless and asynchronous. Any bundler can submit a transaction, making it impossible to coordinate the cryptographic aggregation of signatures across independent actors before execution.
This creates a fundamental scaling bottleneck. Without aggregation, each bundled transaction pays the full gas cost for its ECDSA signature verification, a cost that does not scale with batch size. This negates the primary scaling benefit seen in rollups like Arbitrum and Optimism, which batch execution but not verification.
The core conflict is decentralization versus efficiency. A centralized sequencer, like those in most L2s, can trivially aggregate signatures. ERC-4337's decentralized bundler network sacrifices this optimization to preserve censorship resistance, creating a permanent gas overhead for every account abstraction transaction.
Evidence: A single ECDSA signature verification costs ~3k gas. In a bundle of 100 UserOperations, this creates a fixed 300k gas overhead that aggregation protocols like BLS could reduce to ~1k gas total. This inefficiency is a structural tax on the system.
The Scalability Trilemma of Aggregation
Signature aggregation promises to slash gas costs for ERC-4337 account abstraction, but its implementation is blocked by a fundamental three-way trade-off.
The Problem: On-Chain Aggregation is a Gas Trap
Aggregating signatures on-chain (e.g., BLS) requires expensive cryptographic operations. The verification cost for a single aggregated signature can be ~200k gas, which only beats naive multi-sig for batches of 10+ users. This destroys the business case for paymasters and defeats the purpose of gas sponsorship.
- High Fixed Cost: Base verification gas negates savings for small batches.
- No Sponsor Viability: Paymasters cannot economically subsidize unpredictable, expensive ops.
- Network Bloat: Every bundler must perform this costly computation.
The Problem: Off-Chain Aggregation Breaks Composability
Moving aggregation off-chain (like zkSync's approach) shifts the cost burden to the bundler's pre-chain infrastructure. This creates a centralized bottleneck and fragments the user experience.
- Bundler Monopoly Risk: Only well-capitalized bundlers can run expensive proving setups.
- Chain-Specific Fragmentation: Aggregation schemes are not portable across Ethereum, Optimism, Arbitrum.
- Broken UserOps: A UserOp validated off-chain cannot be easily composed with other on-chain actions.
The Problem: Native Protocol Support is a Governance Nightmare
Embedding a specific aggregation scheme (e.g., EIP-4337 with BLS) into the Ethereum protocol itself requires consensus changes. This is politically untenable and would lock the network into one cryptographic primitive for decades.
- Years-Long Timeline: Protocol upgrades move at glacier speed (see EIP-1559, The Merge).
- Cryptographic Rigidity: BLS today may be broken or obsolete tomorrow.
- Vendor Lock-in: Forces all L2s and alt-L1s to adopt the same standard.
The Solution: Aggregator-Specific Precompiles on L2s
Layer 2s like Arbitrum and Optimism can implement custom, cheap precompiles for specific aggregation schemes. This sidesteps Ethereum governance and makes aggregation viable within that L2's walled garden.
- L2-Specific Optimization: Tailor precompile gas costs to the chain's architecture.
- Faster Iteration: L2s can upgrade cryptographic primitives independently.
- Immediate Relief: Provides a path for dYdX, Uniswap to offer sponsored transactions at scale.
The Solution: Intent-Based Abstraction with Solvers
Projects like UniswapX and CowSwap bypass the signature problem entirely. Users submit signed intents (off-chain), and competing solvers compete to fulfill them in the most gas-efficient bundle, abstracting away the verification mechanism.
- Solver Competition: Market forces drive down costs, not cryptographic tricks.
- Signature Agnostic: Works with EOA sigs, ERC-1271, or future schemes.
- Existing Success: ~$10B+ in volume processed via this model.
The Solution: Modular Security with Alt Layer-1 Primitives
Chains built for verification, like Monad with parallelized EVM or Berachain with native BLS, can make on-chain aggregation cheap by design. They treat it as a first-class primitive, not an afterthought.
- Architectural Advantage: Throughput designed for heavy crypto ops.
- Native Sponsorship: Paymaster logic is a core part of the state machine.
- Long-Term Bet: Aims to make the trilemma irrelevant through raw performance.
The Cost of Inaction: Gas Overhead Analysis
Comparing gas costs and trade-offs for signature verification methods in ERC-4337 account abstraction, illustrating the unsolvable overhead of native ECDSA.
| Gas Cost Component | Native ECDSA (Status Quo) | BLS Signature Aggregation (Ideal) | ERC-1271 + Off-Chain Verifier (Hybrid) |
|---|---|---|---|
Per-UserOp Verification Cost | ~45k gas | ~20k gas (post-aggregation) | ~5k gas (on-chain) |
Bundler Batch Overhead (10 ops) | ~450k gas | ~200k gas | ~50k gas + off-chain cost |
Relies on New Precompile | |||
Requires Fork / L2-Only | |||
Trust Assumption | None (pure crypto) | None (pure crypto) | 1-of-N off-chain verifier set |
Implementation Complexity | Low | High (cryptography, coordination) | Medium (oracle/network design) |
Total Potential Gas Savings | 0% Baseline | 55% Reduction | 89% Reduction (on-chain) |
Deconstructing the Unsolvable Puzzle
ERC-4337's signature verification model creates a fundamental scaling bottleneck that cannot be patched.
The core problem is verification overhead. Every UserOperation requires a separate validateUserOp call, forcing bundlers to execute signature checks serially for each account. This linear scaling makes high-volume, low-value transactions economically impossible for bundlers, unlike the parallelized execution in L2s like Arbitrum or Optimism.
Signature aggregation is the theoretical fix. Protocols like BLS or Schnorr allow combining many signatures into one proof. However, ERC-4337's modular account abstraction standardizes the entry point but not the account logic, creating a coordination nightmare. A BLS-optimized wallet cannot validate a transaction from an ECDSA-based Safe multisig.
The ecosystem cannot converge on a single scheme. Major players like Coinbase's Smart Wallet, Safe, and ZeroDev have entrenched, incompatible signing implementations. Forcing a universal standard would break all existing deployed smart contract wallets, a non-starter for adoption. The fragmentation is permanent.
Evidence: A bundler processing 100 UserOps with standard ECDSA pays ~2.1M gas just for signature checks. With BLS aggregation, this drops to ~45k gas. This 46x efficiency gain is locked behind an unsolvable coordination problem, dooming ERC-4337's on-chain scaling to its current linear model.
The Hopium Counter-Argument (And Why It's Wrong)
Signature aggregation is a theoretical scaling solution for ERC-4337 that fails under real-world economic and security constraints.
The core promise is false. Proponents claim BLS signature aggregation will reduce gas costs by 90% for UserOperations. This ignores the mandatory on-chain verification overhead for the aggregated signature itself, which consumes most of the theoretical savings.
Aggregation requires centralization. To batch signatures, a central aggregator must collect all UserOperations before submitting a bundle. This creates a trusted, rent-seeking intermediary, contradicting Account Abstraction's permissionless ethos and introducing MEV risks.
Real-time finality is impossible. The need to wait for aggregation creates user experience latency. Protocols like UniswapX or CowSwap that rely on fast, intent-based settlement cannot tolerate this delay, making the system unusable for high-value DeFi.
The economic model breaks. The aggregator's fee must cover its gas cost plus profit. In low-fee environments, this creates a negative-sum game where the aggregator's cut erases user savings, a problem already observed in rollup sequencer economics.
Key Takeaways for Builders and Investors
ERC-4337's reliance on on-chain signature verification creates a fundamental scaling contradiction that current infrastructure cannot resolve.
The Core Contradiction: On-Chain Verification
ERC-4337's security model mandates on-chain signature verification for every UserOperation. This creates a direct trade-off: more user adoption linearly increases the verification load on the EntryPoint, making it the system's ultimate bottleneck. Unlike L2s that scale execution, this is a protocol-level constraint.
- Bottleneck: EntryPoint contract becomes the single point of congestion.
- No Parallelization: Each
validateUserOpmust be processed serially per bundle. - Cost Anchor: Verification gas is a fixed, irreducible base cost for all AA interactions.
Aggregation's Promise vs. Reality
Signature aggregation (e.g., BLS) is the theoretical solution, allowing one proof to validate thousands of actions. In practice, its integration with ERC-4337's modular account abstraction is architecturally broken.
- Stateful Incompatibility: Aggregated signatures require knowing all signers upfront, conflicting with ERC-4337's permissionless bundler model.
- Coordination Overhead: Requires new, complex off-chain protocols between bundlers and wallets, defeating the purpose of a simple, open standard.
- Limited Benefit: Only reduces calldata; the computational verification of the aggregate proof itself remains an on-chain cost.
The Bundler's Dilemma
Bundlers are economically incentivized to maximize profit, not system efficiency. Aggregation introduces latency and complexity that directly oppose a bundler's goal of fast, reliable bundle inclusion.
- Profit Erosion: Time spent waiting for signatures reduces MEV opportunities and increases orphan risk.
- Walled Gardens: Efficient aggregation may only work within closed bundler-wallet alliances (e.g., Stackup, Biconomy), fragmenting the ecosystem.
- Real-World Latency: Achieving critical mass of UserOps for aggregation adds 100s of ms to seconds of delay, a non-starter for UX.
Strategic Implications for L2s
The signature problem shifts the scaling burden entirely to L2 and L3 execution layers. The winning chains will be those that optimize the verification precompile and offer native AA support at the protocol level.
- Verification Arms Race: L2s must compete on the speed/cost of the
validateUserOpprimitive. - Native Advantage: Protocols with built-in account abstraction (e.g., zkSync Era, Starknet) bypass this constraint entirely.
- VC Play: Investment should flow to infrastructure that abstracts this problem away, like alt DA layers or dedicated AA rollups.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.