Account Abstraction: Past, Present, Future

Learn about account abstraction in Ethereum—what it means and why it matters.

by Emmanuel AwosikaApril 25, 2023

Even with a bear market raging on, few people doubt crypto is here to stay—wallets like MetaMask already boast millions of users, for example. But, still, the question remains: “How do we go about bringing the next billion users to web3?”

Depending on who you ask, answers to the question will vary. But everyone agrees on some points—particularly the need to improve the experience of users interacting with blockchain applications. Without making web3 more user-friendly, people have little incentive to switch from the web2 apps they use every day.

“Account abstraction” is a proposal seeking to improve user interactions with Ethereum—one that’s increasingly the subject of many discussions in the crypto community. You may, however, be thinking: “What exactly is account abstraction and why should I care about it?”

This article is designed to help you make sense of account abstraction by putting its past, present, and future into context. We’ll be answering every question you may have about the topic—specifically, the who, what, why, how, and when of account abstraction.

A quick summary of key talking points:

  • Programmable, self-custodial accounts (“smart accounts”) can reduce the friction of onboarding new users to the web3 ecosystem. However, limitations imposed by Ethereum’s design prevent broad adoption and use of smart accounts.
  • Account abstraction introduces significant changes that pave the way for wide adoption of trustless, censorship-resistant smart accounts. Different approaches to implementing account abstraction are being considered—each featuring unique benefits and tradeoffs.
  • MetaMask is supporting adoption of account abstraction through its permissionless innovation platform: MetaMask Snaps. With MetaMask Snaps, developers can extend MetaMask to bring the benefits of account abstraction to crypto users around the world.

What is account abstraction?

Like any other new concept in web3, account abstraction can be hard to define. Nevertheless, we can better understand it by first unpacking the various terms relevant to the discussion of account abstraction in Ethereum:

  1. Abstraction (n): A (fairly complicated) term in computer science that roughly means hiding information about a system or application so it can be used with less knowledge of the processes running in the background. Also defined as “the process of hiding the complexity of a system by providing an interface that eases its manipulation.”

  2. Account (n): A user's representation on the blockchain that can send or receive transactions and interact with other on-chain accounts. Ethereum has two types of accounts: Externally Owned Accounts (EOAs) and contract accounts (aka “smart contracts”).

2a. Externally Owned Accounts (EOA): Ethereum accounts generated using wallet software (like MetaMask) and managed by a cryptographic pair of public and private keys. An EOA is “active” (it can initiate transactions and pay gas fees for EVM execution). However, it is limited to executing basic operations—like sending Ether or interacting with contracts.

2b. Contract accounts: Ethereum accounts deployed as a smart contract and controlled by logic written in code (instead of a private key). A contract account is “passive”: it can only send transactions in response to a transaction from an EOA and cannot pay gas fees. It is, however, programmable and can execute arbitrary logic depending on code stored at the address.

new EOAs vs contract accounts@2x

  1. Wallet (n): An interface for managing the funds in your Ethereum account—how a wallet operates depends on what type of account it is linked with. An EOA-based wallet like MetaMask requires a private key to authorize transactions. Meanwhile, a smart contract wallet is linked to a contract account and can use arbitrary logic to authorize a transactions (eg. using a multisignature scheme).

With these definitions out of the way, we can now define account abstraction.

Defining account abstraction

Account abstraction is a proposal to increase flexibility in the management and behavior of Ethereum accounts. We achieve this by introducing account contracts: special-purpose smart contracts that define and manage a user’s Ethereum account (now called a smart account).

With account abstraction, you can enjoy programmable access to funds by using a smart contract wallet instead of relying solely on private keys for security. This is possible because your smart account can have custom rules for spending coins and transferring assets.

So, how does “abstraction” fit into all of this?

From a network-level perspective, “account abstraction” means the details of account types are invisible to the Ethereum protocol. Every account (including self-custodial accounts) is simply a smart contract, and users are free to determine how individual accounts are managed and operated.

From a user-level perspective, “account abstraction” means certain technical details about interacting with Ethereum accounts are concealed behind higher-level interfaces. This improves wallet designs and significantly reduces the complexity of using web3 applications.

This clarification is necessary because confusion around account abstraction comes from not knowing (a) what is being abstracted and (b) where the abstraction occurs. Accounts aren’t necessarily abstracted from users (even if they are abstracted from the protocol). You still have a wallet address to receive funds and a signing key to ensure only you can spend those funds.

From your perspective, account abstraction is more like using a smart account that abstracts some details about interacting with the blockchain. For context, this is what interacting with a dapp looks like from the perspective of a first-time user:

Workflow of creating an EOA
and interacting with dapp@2x

With account abstraction, wallet developers can create systems that handle these processes in the background and simplify the experience of using web3 (TL;DR: wallets become “invisible”). Some use cases (which we’ll expand on later) include: eliminating the need for you to store seed phrases/private keys, pay gas for transactions, or even set up an on-chain account by yourself.

The benefits of account abstraction

As mentioned previously, account abstraction removes most of the friction associated with using web3 wallets and interacting with dapps. This brings web3 closer to the ideal of web2 where all users—both novice and experienced—can benefit from the same degree of flexibility, security, and ease of use.

Screenshot 2023-04-25 at 1.00.34 PM

In particular, account abstraction has huge implications for the future of self-custody. With the features provided by account contracts, using a web3 wallet will feel like using a bank account or application without having to trust the bank.

In subsequent sections, we’ll touch on the different dimensions of account abstraction and discuss how they improve the experience of using Ethereum. Specifically, we’ll talk about signature abstraction, fee abstraction, and nonce abstraction.

Signature abstraction

Today, transactions from your EOA must have a signature generated by the account’s private key using the Elliptic curve digital signature algorithm (ECDSA) to be valid. This gives most EOAs a simple security model: funds are safe if private keys remain in the user’s possession. But it also has several limitations:

  1. EOAs are notoriously difficult to secure, particularly as malicious actors are always evolving new ways of compromising private keys. At MetaMask, we’ve seen firsthand the challenges that phishing, social engineering, spoofing, malware injection, and similar attacks pose to user security in web3.

  2. Self-custody may feel like an extreme sport. Unlike your regular bank account, you cannot “recover” an EOA wallet if the seed phrase/private key is lost. This creates a challenge for new users who must grapple with the implications of completely losing assets held in Ethereum accounts without any recourse.

Security-related drawbacks of EOAs@2x

Signature abstraction solves these problems by removing ECDSA signatures as the default authorization mechanism for non-custodial accounts. Rather, users are permitted to define custom rules for authorizing wallets to initiate transactions. Or, said another way, you can decide what it means for a transaction to be valid.

Implementing signature abstraction opens up possibilities for more advanced authorization schemes. This way, using your web3 wallet will feel similar, if not better than, a web2 banking application. Here are some use cases:

  1. Transaction limits: A wallet linked to your smart account can reject a transaction (or ask for additional authorization) if the value exceeds a preset limit. Sounds familiar? It should—banks do it already to protect your accounts and credit cards against fraud, unauthorized usage, and other reasons related to security.

  2. Multi-party approvals: You could delegate partial control of your account to trusted parties aka “guardians”. Guardians can be friends, family members, service providers, or even a separate device that you own (eg. a hardware wallet). Thus you can enable web2-style multi-factor authentication (MFA) for your wallet by requiring guardian approval for transactions that withdraw funds from your smart account.

Multi-factor authentication for web3 wallets@2x

  1. Key rotation and revocation: With smart accounts, you can generate a new signing key if the previous key was lost or stolen. For additional security, you can have guardians freeze your account during the recovery process and demand approval for key rotation/revocation flows (ie. social recovery). This is similar to how you can freeze your credit card if it’s misplaced/stolen without losing access to your bank account

  2. Trusted sessions: Do you dislike having to approve every action when interacting with a dapp in your browser? Great! You can create special “session keys” with your smart account for dapps to automatically sign transactions for a specific period. This means you can interact with dapps—playing a blockchain game, say—without getting pestered with wallet pop-ups.

Using a dapp with session keys@2x

At a high level, session keys are based on a smart contract that controls interactions between your account and a dapp. You always have control of session keys and can regulate the dapp’s signing authority, such as how much it can deduct from your balance or what functions it can call.

How a user “approves” a trusted session@2x

  1. Automatic payments: Similar to the idea of session keys, you can approve service providers to “pull” funds from your smart account (subject to predefined rules). This makes it possible to set up recurring payments and subscriptions with your web3 wallet. Can you imagine paying for a Netflix subscription or utility bill using your Ethereum account?

Fee abstraction

Currently, every Ethereum transaction must have a “gas fee” denoting how much the sending EOA is willing to pay for execution. Gas fees are denominated in Ether, Ethereum’s native token. This creates problems, especially for new users who now need to source for ETH before sending their transaction.

Account abstraction doesn’t eliminate the need to pay gas fees, but it abstracts away details of how and when users choose to pay for gas (fee abstraction). For example, account abstraction enables “sponsored transactions” where another account covers the cost of gas for a user’s transaction. Some benefits of sponsored transactions:

  1. Non-ETH gas payments: Have you ever wished you could pay for transaction fees with ERC-20 tokens in your wallet? With sponsored transactions, you can get a relayer with ETH to front the cost for your transactions and pay them back in another token like DAI or USDC.

Normal transactions vs ETH-less transactions@2x

  1. Gasless transactions: Dapp developers can sponsor transactions and minimize onboarding friction for new Ethereum users. You could essentially be using web3 apps without knowing anything about “gas” and enjoy the same one-click experience that web2 apps provide.

Normal transactions vs gasless transactions@2x

  1. Social logins: A dapp might deploy a contract wallet on your behalf, solving the pain point of setting up a wallet before sending on-chain transactions. The great part? Wallets can use authentication infrastructure (eg. Web3Auth and WebAuthn) to enable users to create web3 accounts with existing credentials like an email address or Facebook/Twitter account.

Nonce abstraction

Smart accounts on Ethereum have another special feature: transaction batching. With batched transactions, you can combine multiple operations into a single on-chain transaction and reduce the cost and complexity of interacting with dapps. Here’s why transaction batching is important:

Your EOA stores a value known as a “nonce” that shows how many transactions you’ve sent (think of it like a transaction counter). A new transaction must strictly increase the nonce by 1 to be valid—a rule that prevents someone else from “replaying” the same transaction to steal your funds (yup, it can happen).

But there’s a catch. Nonces force you to process transactions in first-in-first-out (FIFO) style. Imagine you have two transactions (A and B) with nonce of 0 and 1, respectively. Here, you’d send transaction A and wait for a confirmation (of its execution) before sending B.

Sending B while A is still pending would simply have the former rejected since the nonce would be higher than the prescribed range (EOA’s current nonce + 1). In fact, this is a big reason you have “stuck transactions" when using a wallet.

Nonce abstraction allows you to create custom replay protection mechanisms (instead of the Ethereum protocol enforcing strict ordering on transactions). For example, you can have a nonce scheme that permits processing multiple transactions in parallel. This would solve the problem of clogged/stuck transactions and significantly improve interactions with dapps.

Nonce abstraction@2x

That said, nonce abstraction is difficult to implement in practice and can potentially break certain invariants critical to security and UX, such as transaction hash uniqueness). This is where transaction batching comes into the picture:

Since smart accounts can process multiple transactions at once, the need for complex nonce abstraction schemes largely disappears. Going back to the previous example, we can imagine transaction A and B are merely parts of a single hypothetical operation like swapping assets on Uniswap:

  • Transaction A: Approve the Uniswap contract to access your tokens
  • Transaction B: Complete the token swap

With transaction batching, you can combine the approve-and-swap workflow into one transaction. The result: lower gas fees and reduced wait-times when using dapps. Cool, eh?

How transaction batching improves the workflow of using a DeFi dapp@2x

The “how” of account abstraction

At this point, you already know account abstraction allows us to add custom functionality and authorization policies to user accounts. But we really haven’t talked about how any of that is possible. This section discusses different approaches to implementing abstraction on Ethereum (if that doesn’t sound too appealing, feel free to skip to the next section).

There are two generally accepted ways of achieving account abstraction: (a) letting EOAs execute EVM code and (b) allowing smart contracts to initiate transactions. Hence, you’ll find that many account abstraction proposals either want EOAs to behave as smart contracts or contract accounts to act as EOAs.

This naturally brings up some questions:

  • “How exactly are these approaches different?”
  • “Why does it matter which approach we adopt?"

Account abstraction: Approach #1 (Upgrading EOAs to execute code)

By giving EOAs the ability to execute code, we can add complex functionality to user-controlled accounts. This supercharges EOAs and transforms them into smart accounts, setting the stage for native account abstraction. Importantly, this approach allows you to enjoy the benefits of a programmable wallet without incurring the cost of deploying a new contract account.

Some approaches to upgrading EOAs to contract accounts involve treating the data payload of EOA transactions as EVM bytecode. Others involve delegating control of an EOA to a special account contract that makes transactions on the EOA’s behalf. In the latter case, the same account contract can be reused by different EOAs, reducing the need to have different contract wallet implementations.

Below is an infographic showing different account abstraction proposals in the “make EOAs programmable” camp, including their key features and status of implementation:

Account abstraction proposals (I)@2x

Account abstraction: Approach #2 (Upgrading smart contracts)

With this approach, we upgrade contract accounts so they can approve transactions and pay gas fees (just like EOAs). This provides another route to achieving account abstraction by introducing “supercharged contracts” that can act as EOAs (ie. account contracts). Plus, it solves a pressing problem in Ethereum: lack of support for contract wallets at the protocol level.

You see—some smart contract wallets already exist today and provide many benefits of account abstraction. But using these wallets can be incredibly difficult because Ethereum treats smart contracts as “second-class citizens” and requires all transactions to start from an EOA.

This limitation also means smart contract wallets lack the trustlessness and self-custodial nature of EOA wallets like MetaMask. For context, let’s consider the flow of creating and using a smart contract wallet:

  • Deploy a new contract account
  • Send transactions to call functions on your wallet contract

The problem is already obvious: you now need to manage two wallets. Why? An EOA (pre-funded with ETH) needs to cover the costs of deploying the wallet and calling necessary functions afterwards.

Interacting with a smart contract wallet@2x

Enter relayers: EOAs that can pay for your wallet’s transactions in exchange for a fee. Smart contract wallet providers will often run relayers to subsidize transactions for users. That is, the relayer pays ETH from its wallet to cover your transaction fees and recoups the costs by charging you elsewhere—perhaps in fiat or some other token.

This system works fine in most cases: you can create and use a contract wallet without worrying too much about the intricacies of paying for gas. However, it also requires trusting the relayer not to censor or tamper with your transactions.

But this is crypto, and we like trustless systems.

By letting contract accounts approve transactions and pay gas fees, account abstraction makes the process of creating and using a smart contract wallet more trustless. To be specific, it allows anyone that runs a relayer to execute transactions on your behalf. You just need to sign a message approving the relayer to deduct funds from your wallet balance after executing the transaction:

Now the flow of using a smart contract wallet looks somewhat different:

  • Deploying a wallet contract? By using counterfactual deployment workflows, you can send funds to the contract account before deploying it and pay a relayer’s EOA for deployment costs from your wallet’s balance.
  • Interacting with a wallet contract? Sign a message off-chain and have a relayer make the call to your account contract. The message will include an instruction for the account contract to refund the relayer’s gas costs.

Interacting with a smart contract wallet via a relayer@2x

This idea of enabling trustless and censorship-resistant smart accounts underpins many account abstraction proposals in this category. For example, ERC-4337—the most popular account abstraction proposal yet—decentralizes relayers by introducing an alternate mempool where users can submit contract wallet transactions for processing.

In this case, relayers (called “bundlers”) can compete to execute smart account transactions, reducing the risk of censorship or over-reliance on wallet providers. Below is an infographic showing different account abstraction proposals in the “give smart contracts EOA features” camp, including their key features, and status of implementation:

Account abstraction proposals (II)@2x

On the future of account abstraction

Years after Vitalik Buterin first introduced the concept, there’s still some disagreement about the best way to implement account abstraction. For example, implementing EIP-3074 and EIP-5003 would enable existing EOAs (including MetaMask users) to upgrade to smart accounts. But these proposals require a hard fork which, given the community’s focus on more pressing upgrades, seems infeasible for now.

In contrast, EIP-4337 has received broad support as it implements account abstraction without requiring large-scale changes to the Ethereum protocol. But for users currently using EOA-based wallets, it means having to move assets from an EOA to a newly deployed contract account—a potentially complex and costly process, given high gas fees on Ethereum today.


At MetaMask, we believe account abstraction is key to providing a seamless onboarding experience for new web3 users. We also know that EOAs cannot guarantee crypto’s adoption (“The next billion users won’t write 12 words on a paper,” as Ethereum Foundation researcher Yoav Weiss colorfully puts it.).

As such, we have begun thinking of ways to deliver the benefits of account abstraction without compromising on the MetaMask wallet users know and love. Part of this effort includes turning to MetaMask Snaps—the permissionless innovation platform that allows developers to build custom features on top of existing MetaMask infrastructure.

Using Snaps, developers can extend the functionality of your MetaMask wallet to support different account abstraction use cases. From session keys to complete smart account integrations built with MetaMask—all built with Snaps—we have seen developers rise to the challenge of using MetaMask to democratize access to account abstraction for users.

MetaMask loves Account Abstraction@2x

“Don’t let perfect be the enemy of good.” — Voltaire

The current account abstraction proposal—even if slightly imperfect—is a giant step towards achieving trustless, censorship-resistant smart accounts on Ethereum and deserves enough support. To quote one of our own, Taylor Monahan, “A shipped half-solution is still better than an unshipped perfect solution.”

Which is why our next article on the topic of account abstraction will take the form of a deep dive into the details of ERC-4337. Importantly, we’ll discuss how web3 developers can start building the future of account abstraction and onboard the next billion users—one line of code at a time—with MetaMask.

Stay tuned!

Special thanks to Patrick McCorry, Simon Brown, Mirko Garozzo, Christian Montoya, Oliver Renwick, and Megan Dias for feedback on earlier drafts of this article. My appreciation also goes out to Clarissa Watson and Francesco Andreoli who provided guidance and support in the early stages of the project.

Receive our Newsletter