What is ERC-4337 anyway?

ERC-4337 is being touted as Ethereum’s most awaited “UX Upgrade”. But why?

Motivation

If you’ve ever tried to build Web3 apps with amazing user experiences you’ll eventually hit roadblocks that are imposed by the limitations of an EOA.

In other words, the UX ceiling in terms of what you can achieve with an EOA is not very high. Here are some of the things contract accounts can enable that aren’t possible with EOAs.

• Arbitrary verification logic: Support single and multi-sig verification and any arbitrary signature scheme.
• Sponsored transactions: Allow users to pay transaction fees in ERC-20 tokens or build your own fee logic, including sponsoring transaction fees on your app.
• Account security: Enable social recovery and security features like time-locks and withdraw limits.
• Atomic multi-operations: Build flows that better align with your user’s intent such as trading in one click rather than approving and swapping separately.

Account abstraction sounds great! But there are some down sides to also consider.

• Signing issues: Ideally, all apps would follow EIP-1271 to validate signatures. Unfortunately, this is not always the case, and those apps would be incompatible with contract accounts.
• Higher gas cost: On L2s and other scaling solutions this becomes less of a problem. However more research on how to reduce gas cost in this context, especially on the Ethereum mainnet, is required.

Description & Implementation

Without wasting anymore time, lets get into the design and working of ERC-4337. This whole proposal, or I would say “concept”, is divided into 6 major components. The following table briefly discusses them.

User Operations

Just like EOAs have transactions, smart contract accounts have something called “user operations”. While, both of these concepts have some similarities, they also differ in many other ways. This table lists down and explains key components of a user operation.

Bundler

These independent servers act as intermediaries. Following a successful or unsuccessful execution of a user operation, these actors are compensated with the gas cost they paid for the set of transactions.

1. Listen in to a UserOperation mempool.
2. Runs simulations.
3. Bundles an array of operations.
4. Relays bundles to the EntryPoint.

Note: mempool is the cache pool that temporarily holds user transactions.

Entry Point

The EntryPoint is a contract that acts as a central entity for all ERC-4337 accounts and paymasters. It coordinates the verification and execution of a UserOperation. For this reason, it’s important for all implementations of an EntryPoint to be audited and not controllable by any single entity.

Contract Accounts

The Contract Account is an end user’s account. At minimum it needs to check whether or not it will accept a UserOperation during the verification loop.

Additional features to support other account functions like social recovery and multi-operations can be added here too.

Aggregator

The Aggregator is a smart contract that is trusted to validate signatures for Contract Accounts.

Pay Master

The Pay Master is another contract account that handles any UserOperation with sponsored transactions. It is required to do 2 things:

1. Check whether or not it will accept a UserOperation during the verification loop.
2. Run any required fee logic in the execution loop.

An example of a Paymaster logic could be to withdraw a certain amount of ERC-20 tokens from the Contract Account after the UserOperation is executed. This allows for a UX where users can pay for gas in any currency they choose.

This article was written by Farrukh Raza, a blockchain engineer @ antematter.io.