Is ERC-4337 Bloated? A Real-World Analysis

You may have heard complaints that ERC-4337 and account abstraction as a whole are bloated in the sense that they add a s overhead to transaction fees, or, more rarely, from actual builders, that it adds a network overhead that makes products sluggish.

What ERC-4337 is (and isn’t)

Before we begin, we need to explain what ERC-4337 is and what we’re comparing it to.

Let’s start by reminding ourselves of Smart Accounts (a.k.a. account abstraction): the ability of accounts to be smart contracts, thereby carrying more logic than a typical single-private-key account (EOA).

Ethereum doesn’t have this functionality built in, but nothing is stopping any wallet provider from using a smart contract as the user account. Except for one big limitation, which is the inability of a transaction to originate from a smart contract.

This is where ERC-4337 comes in: to put it simply, it’s a protocol that defines a special smart transaction type (userOp), and defines infrastructure on how these are handled. It is, however, in the application layer rather than the protocol layer, which is good because it means it was shipped quickly, but it comes with some associated overhead and complexity.

However, smart accounts existed well before ERC-4337,  so how was that possible? 

The answer is proprietary relayers. You can actually equate a proprietary relayer to a rudimentary version of an ERC-4337.

In practice, both approaches must adhere to the reality of the Ethereum network, which is that all native transactions must originate from an EOA and pay gas in ETH. This is how both relayers and ERC-4337 work: there’s a “service” EOA that transactions actually originate from, but it’s merely used to pay the ETH fee and get reimbursed in some other way, and has no actual authority over your account. 

However, ERC-4337 offers a significant advantage over proprietary relayers, which is decentralization, denial of service (DoS) attack protection, and censorship resistance. With proprietary relayers, you have the following problems that are addressed in ERC-4337:

• A relayer going down will mean the user is partially locked out of their account (even if there’s an alternative way for them to access their funds)
• Relayers can censor your transactions
• There’s no standardization for relayers, so they’re not easy to replace
• Transactions can be griefed - they can be made to fail between the moment they’re received by the relayer and actually confirmed, costing the relayer money and availability (denial of service attacks)

Does EIP-7702 change things?

EIP-7702 allows existing EOAs to have contract code, but contrary to popular belief, it doesn’t make ERC-4337 irrelevant: when you think about it, it’s actually the opposite: the problem of broadcasting “smart transactions” to the network is MORE relevant with the existence of EIP-7702, as EOAs are like smart accounts too now, except EIP-7702 does nothing to solve the problems that ERC-4337 solves. 

With EIP-7702, you actually have three ways of broadcasting transactions: 

• The native EOA way, where gas must be paid in ETH, and the signature must still come from your private key
• ERC-4337
• Proprietary relayer

Is ERC-4337 worth it?

Now we’ve established that ERC-4337 is a huge security and decentralization improvement over proprietary relayers, but we also mentioned overhead and complexity.

This has been a common criticism of ERC-4337 so far.

So now let’s dive into how much the actual “cost” of having this DoS protection is…

The comparison

Note: those tests are performed to be as scientific as possible: using the same token, sending a token that the recipient already has (to avoid the 20k gas cost of setting a zero slot), using the same Ambire version.

Because Ambire uses its proprietary relayer on Ethereum and ERC-4337 everywhere else, we’ll compare Ethereum and Optimism separately to calculate the distinct overhead of each broadcast mode.

For Optimism, the sending account is an ERC-7702-enabled EOA to allow the cleanest direct comparison between smart accounts and EOAs.

For Ethereum, we send from a Smart Account, as Ambire supports relayer mode only for pure Smart Accounts. The baseline there will be a Smart Account with an ETH gas payment (transaction triggered from an EOA). For completeness, we will compare this to an actual EOA transaction to measure the PURE overhead of Smart Accounts.

Now, an Ambire-specific feature: there is a feature called Gas Tank that is essentially a gas pre-payment. This allows optimizing the one additional token transfer incurred by the fee payment in tokens.

Native gas payment (Ethereum, EOA): 62k

https://etherscan.io/tx/0x7ca80c1a5babba9eaab89da971a73c064776c0cf8df794f7bbf1cb573d483e11

Native gas payment (Ethereum, Smart Account): 71k 

https://etherscan.io/tx/0x8b77407fc72a3bd899877c78716c6b4663ba49bfd23eb892ab5a590cb59a7db5

From this, we can gather that the pure overhead of Ambire smart accounts is 9k gas. Not bad at all!

Relayer: gas tank (Ethereum, Smart Account): 77k https://etherscan.io/tx/0x52263058ce51002238c4b3bfb422ad74e906f577bdf613d09ae0b049189f961c

Relayer: payment by USDC (Ethereum, Smart Account): 84k

https://etherscan.io/tx/0x42406a6634fca76ea9f7b952492146efc1685323a20c6dabc734cfc9afd01ea6

Now we know that the relayer overhead is quite lean: only 6k when using the Gas Tank and 13k when paying in USDC. 

Native gas payment (Optimism, EOA) 45k 

https://optimistic.etherscan.io/tx/0xb09909a095ae20ba5a8a2778040add53ec030f34d63560618b4e68a80ac5dccb

ERC-4337 gas tank: 133k (Optimism, EOA) https://optimistic.etherscan.io/tx/0xcf0da2cc0cf9085420c1643645aaf843e853314758207a7c5e822d2f6dbe7608

ERC-4337 payment by USDC: 140k (Optimism, EOA): https://optimistic.etherscan.io/tx/0x8b6692384e9611ffea76dca43ee1dd736410faba7c8a2a67256f0a33f675df44

Ok, we have a slightly different picture here: 88k gas overhead just for using ERC-4337, and 95k when you include a fee payment call. Please note that around 9k comes from the AmbireAccount overhead itself, which is NOT used in the pure EOA benchmark. 

So what’s the verdict? Let’s compare everything against “baseline” (native fee payment), but also calculate fees in dollar amounts. We’ll use an “expensive” value for both Ethereum and L2s, as of October 2025. It’s undeniable that the Ethereum mainnet has had much more expensive periods, so we’ll include a 10 gwei worst-case too. We’ll use 3900 USD as the ETH price.

The table only includes the isolated overhead.

However, for added perspective, we’ll also add a relative comparison: what % is that gas overhead compared to an average-ish aggregator swap (400k).

So we can draw a few key conclusions here:

• The overhead is small in $ amount at current gas prices
• Relative numbers are decent as well
• The relayer includes a griefing risk that the Ambire team is willing to take (even though it contains built-in circuit breakers for griefing) - this is a compromise that ERC-4337 doesn’t need to make

In summary, this is a reasonable price to pay for security and decentralization, especially on L2s or even the mainnet with cheap gas prices.

Ok, but what about network overhead?

Another common criticism of ERC-4337 that’s coming from developers is that it requires too many network calls.

The best way to address this would be to speak from Ambire’s point of view directly, as we’ve been building with ERC-4337 for over two years now.

In our development, we found that while network roundtrip overhead cannot be neglected, a user would hardly notice it: ERC-4337 requires up to one roundtrip more than a relayer, depending how optimized your relayer is: normally, you need two calls to the bundler and a paymaster call in between* - but the positive side here is that one of the calls is already a replacement for eth_sendTransaction in the EOA flow, and the bundler estimation call can be seen as a replacement to eth_estimateGas. So the only truly additional call is the optional paymaster call.

So in reality, in a well-optimized system, ERC-4337 has only ONE additional network round-trip, which should be resolved in around 300-400 milliseconds, which most users won’t notice.

There are further improvements in EntryPoint 0.9, allowing the paymaster call to be parallel to other operations, further negating this overhead. 

*Note: Paymaster call is optional by protocol, but then you have no gas fee flexibility, which is the main user value out of ERC-4337

Zero compromise solution

Ok, but can we do better? Can we have a no-compromise solution that doesn’t sacrifice denial-of-service safety or efficiency? Of course! This is where native account abstraction comes in.

Native account abstraction enshrines the functionality of the entry point, or in other words, it builds in the processing of smart transactions into the protocol. This allows for significant savings, with overhead dropping to near zero in ideal conditions. Of course, some added costs are non-negotiable, like everything related to the extra storage used for accounting, but ultimately, at least half of the overhead is expected to go away.

So, when is this coming, and what’s the progress? In the last 5+ years, there’s been a significant evolution of native account abstraction proposals, to a big extent driven by the valuable learnings of ERC-4337 itself. If you want to dig deep, the evolution of proposals goes like this: EIP-2938 -> RIP-7560 -> EIP-7701 (not to be confused with EIP-7702).

The Ethereum Foundation is putting account abstraction at a high priority right now, which can be seen by the quick shipping of EIP-7702, so native account abstraction is closer than ever, even if there’s no concrete timeline at the moment.

Conclusions

We can happily report that ERC-4337 doesn’t really have any deal-breaking or, in most cases, even noticeable overhead. 

We believe that just like with any other big EIP, it followed a media cycle of initial excitement, followed by disenchantment once user experience didn’t change overnight, which was never possible to begin with. The core reason for this is that the true nuances of technical improvements like ERC-4337 are not compatible with a good media story, so naturally, it was communicated like “this will give us all the AA features we ever wanted overnight once it goes live”.

In Ambire, we believe that account abstraction is a big part of what makes a wallet experience great, even though it’s not the whole story. As such, we’ve shipped Smart Accounts in 2021, way before ERC-4337 or EIP-7702, and we can confidently say that both of those EIPs are a huge success for us, allowing us to ship better products.

We are also positive that a lot more value is yet to be extracted from ERC-4337 and EIP-7702, so the future is bright for Ethereum UX!

​​Interested in Ambire? Follow us:
Discord | X (Twitter) | Reddit | GitHub | Telegram | Facebook