ERC-4337 Primer: What You Need to Know

ERC-4337, or ”account abstraction”, is an Ethereum proposal that introduces “account” smart contracts. Account abstraction simplifies the handling of Ethereum accounts, providing a generalized interface for both traditional externally owned accounts (EOAs) and smart contract accounts. Social recovery, paying for gas, and transaction security are some of its proposed improvements. In this new approach, users are no longer bound to handle their private keys and enjoy the flexibility of setting up additional account rules, which improve their security posture.

In this post, we’ll break down the main advantages of account abstraction over current wallet solutions, as well as its security considerations for users and developers.

Current Wallet Management Solutions

Externally owned accounts (EOAs) are the fundamental type of account on the Ethereum blockchain. Whoever possesses the private key has complete control over the actions of the associated EOA. While it allows for straightforward interactions with the network, it also comes with the inherent challenge of managing private keys. A simple mistake could mean permanent loss of funds, and on chain, permanent really means permanent. Apart from that, there’s also the concept of gas fees. This is counterintuitive for most Web2 users, as there’s rarely any type of pay-per-action situation in a modern Web or mobile app.

Given these challenges, several alternatives and enhancements over the basic EOA structure have been implemented:

• Web browser wallets: Integrated directly into Web browsers, either as extensions or plug-ins. Examples include the MetaMask and Coinbase browser extensions. They provide a user-friendly interface for viewing balances, performing transactions, and interacting with dApps directly from the browser. Operating within a browser makes them susceptible to various attacks, including phishing, XSS, social engineering, and so on.
• Multi-signature (multi-sig) wallets: These are smart contract–based wallets that require multiple private keys to authorize a transaction. Thus, even if one key is compromised, the attacker still needs access to the other keys to move funds or execute critical actions. Examples here include Safe, Argent, and Armory multi-sigs.
• Multiparty computation (MPC) wallets: Similar to multi-sig wallets, this type of wallet distributes the transaction authorization by dividing a singular private key among multiple actors. Some examples include ZenGo and Fireblocks. Some MPC implementations use the novel threshold signature, where only m of the n total signatures are necessary. Unlike multi-sig wallets, this threshold property is an intrinsic property of the cryptographic primitive itself, not a programmed smart contract constraint.
• Hardware wallets: Devices like Ledger or Trezor provide a physical layer of security. They store private keys offline and require physical confirmation on the device to sign transactions. The keys in a properly designed hardware wallet should never leave the device. This makes them most resilient against online hacking attempts.

While these solutions partly address the challenges associated with vanilla EOAs, they also introduce complexities and trade-offs of their own. For example, none provide an actually effective account recovery mechanism. Some use a recovery passphrase that itself can be lost or even stolen, thus still leaving all the responsibility in the hands of users.

First, let’s start with the rationale behind the ERC-4337 proposal and discuss some of its benefits.

Account Abstraction In a Nutshell

At its core, account abstraction streamlines users’ interaction with the Ethereum network. It makes the learning curve gentler for new users, who may otherwise be intimidated by the technical aspects of Ethereum. They no longer need to handle private keys, and the transaction approval procedure can be delegated to other trusted parties.

Meanwhile, developers benefit from greater flexibility when designing and implementing dApps. Account abstraction enables new ways to improve the user experience. These include sponsoring gas fees, transaction legitimacy checks by whitelisting particular addresses, and authentication via social log-in (e.g., “Log-in with Google”), among others. Account rules like transaction spending limits can be set up to eliminate the potential of leftover approvals being misused when a protocol is compromised.

Despite the complexities involved in developing a feature-rich account abstraction wallet, the general architecture is transparent. In fact, there’s only one “off-chain” component, the new mempool. Everything else is handled in smart contracts. Without all the external components that previous solutions had, the attack vectors are significantly diminished.

We see great improvements in user experience with account abstraction, but when things sound overly promising there’s usually a catch. Let’s explore some of the need-to-knows for developers and users, including potential security pitfalls.

How an Account Abstraction Transaction Works Under the Hood

Under the hood, the following steps take place in a typical user interaction:

Step 0: The user sends a UserOperation to a special mempool customized for the ERC-4337. This new mempool is needed so that users don’t pay the gas fees upfront. Bundlers (which are essentially EOAs) will then pick up the newly added UserOperation from the mempool and add it to a bundle transaction.

Step 1: The bundle transaction is then forwarded to a singleton contract called “Entry Point”.

Step 2: Entry Point then individually calls validateUserOP on each user’s account contract (i.e., the wallet smart contract that inherits IAccount) for each transaction in the bundle. (For simplicity, we assume that the bundle only contains one UserOperation in the bundle transaction.)

Step 3: The user’s account contract returns whether the UserOperation it has been asked to verify is valid, according to the rules they set in the validateUserOp function.

Step 4: If valid, the Entry Point verifies that the user account has paid it enough for the gas fees and then calls execute back on the user’s account contract.

→ If invalid, terminate the execution and return the appropriate response back to the Entry Point contract.

Step 5: The user account contract then performs the low-level call with the calldata and target provided in the actual UserOperation, finalizing the execution chain.

There are several enhancements over this simple architecture. One is the usage of Paymasters, which handles sponsoring the transaction’s fees. In this scenario, at Step 4, the Entry Point will verify that the Paymaster has supplied enough for the gas fees to cover the particular UserOperation that’s being verified. This may be crucial for projects concerned about user adoption, as the interactions on the Ethereum blockchain will be more seamless, much like current Web and mobile apps. Alternatively, users could be allowed to pay in stablecoins for gas for a more familiar and convenient pricing scheme.

Moving the transaction execution logic into smart contracts increases developers’ security responsibilities. We present several security considerations when developing account abstraction wallets.

Need-to-Knows for Developers

As we just saw in the previous section, in order to support the ERC-4337 (i.e., account abstraction) standard, a wallet contract must implement the function validateUserOp.

interface IAccount {
  function validateUserOp
      (UserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds)
      external returns (uint256 validationData);
}

The validateUserOP function should ensure all of the following:

• Assure↗ that the function call originated from the singleton EntryPoint (i.e., require(msg.sender == EntryPoint);), to prevent forged calls.
• Assure that the user operation is valid based on the userOpHash.↗ This is mainly to prevent malicious UserOperations from being executed on behalf of the user account wallet. Also, return SIG_VALIDATION_FAILED (do not revert) on signature mismatch, as per the standard↗. Revert on any other type of error.
• (In the case that the Paymaster is not supported) Pay the EntryPoint (msg.sender) at least the missingAccountFunds, thus ensuring that the gas fees are paid for the particular↗ userOp transaction.
• The return value should be packed encoded of (authorizer, validUntil, validAfter).
  • authorizer - 0 for valid signature, 1 to mark signature failure. Otherwise, an address of an authorizer contract. The ERC defines “signature aggregator” as authorizer. More details on the signature aggregator can be found here↗.
  • validAfter and validUntil are six-byte timestamps. The UserOp is only valid either until validUntil or after validAfter, or within the validAfter ... validUntil range.

For reference, the ERC-4337 core team has implemented SimpleAccount.sol↗, a sample account contract, with all the necessary checks in place. Over time, developers will begin prototyping different improvements over the default ERC-4337, and we anticipate that the following security considerations will come in handy:

• Upgradability: Since most of the account abstraction’s components are smart contracts, it’s safe to assume projects will make them upgradable. Bugs to look out for here include mismanaging storage variables against overwrites and mishandling the migration functions, business-logic wise. In this Twitter thread↗, we describe a storage collision hack that led to over $6,000,000 in lost funds. Recently, we also identified an issue that would permanently lock the contract after it was upgraded.
• Reentrancy: Sponsoring gas is tricky to implement securely. Will there be a Vault that will pick up UserOperations, pay the gas, and forward the transactions? Or will there be some sort of permit-based transaction? Regardless, we anticipate that protocols will opt for custom Paymasters, maybe to allow for ERC-20 transfers, swaps, and so on. Considering this, the most likely attack vector here is reentrancy, as Paymasters will forward some sort of tokens, either native or ERC-20, via calls and callbacks to external contracts.
• Front-running: Since transactions will be publicly available in the special mempool, front-running attacks will be prevalent, regardless of how transactions are eventually bundled and executed.
• (For third-party contracts) Reliance on tx.origin: The user will transact via a contract rather than an actual EOA; thus, the tx.origin will no longer match msg.sender. Any EOA-only checks will thus be obsolete, and necessary modifications must be supported by all protocols wanting to offer support for account abstraction wallets. All smart contract developers, even those not directly working with ERC-4337, should be aware of this.

Need-to-Knows for Users

On its own, account abstraction does not come with more security risks for the users. As an ERC, the standard code will be heavily audited and the room for error is minimal. The default implementation, however, does not come with all the features we’ve talked about in this post. So, before any features like transaction spending limit, social recovery↗, or authentication and so forth are implemented, heavy development and customization are needed. As we all know, smart contracts often turn out to be insecure. Selecting a security-focused account abstraction wallet solution still requires careful diligence.

The Takeaway

The goal of account abstraction is to simplify the implementation of account abstraction–like user experiences. Centralized components are no longer needed to provide an effective alternative for the default EOA. It’s an opportunity for developers to onboard a larger audience to Ethereum, as less technical knowledge will be required to operate an account. This simplification doesn’t directly translate to bug-free code. By reducing the possible external attack vectors, however, developers now have a smaller sandbox to deal with; here, security invariants are more easily defined. We consider account abstraction to be an important step towards a more secure and resilient Ethereum ecosystem, paving the way for additional use cases and user experiences.

About Us

Zellic specializes in securing emerging technologies. Our security researchers have uncovered vulnerabilities in the most valuable targets, from Fortune 500s to DeFi giants.

Developers, founders, and investors trust our security assessments to ship quickly, confidently, and without critical vulnerabilities. With our background in real-world offensive security research, we find what others miss.

‍Contact us↗ for an audit that’s better than the rest. Real audits, not rubber stamps.