Account Abstraction: The Future of Accounts on Ethereum?

Kai· 7 min read

Account Abstraction is one of those developments that the Ethereum scene is hoping for a lot. It is “a long-term dream of the community” wrote Vitalik Buterin.

Account Abstraction, they say, is supposed to bring the longed-for “mass adoption.” It is supposed to make Ethereum — heck, crypto in general — mainstream. But what’s behind the term?

“In summary,” explains the Argent wallet’s blog, “Account Abstraction takes crypto from the current state of having one model for everything and losing it all because of one small mistake, to a future where an account can be customized to meet individual needs.”

This, Argent continued, “makes self-preservation a viable option for a mainstream audience. An alternative to a scary world where you have to choose between seed phrases and centralized exchanges.”

Sound exciting? But to understand it, you first have to realize what an account is — and what its limitations are.

The hard, simple logic of accounts

An account on Ethereum is more or less the same as an address on Bitcoin: the user’s wallet generates a private key, derives a public key from that, and derives an address from that.

Accounts are simple in design: You can receive coins and tokens with the address, like with an IBAN number, and you can send them if you sign the transaction with the private key. That’s all there is to it.

This hard, simple logic allows a user to manage their keys autonomously, either as a key itself, or as a seed from which to derive keys. This is great for nerds and early adopters — but can be off-putting for the masses.

Keys and seeds can be lost or stolen, and if that happens, nothing can save the owner. Everything that was in the account is gone. This is the hard, simple logic of accounts. That’s why many users — quite rightly — choose to entrust their coins to an exchange.

Smart Contract Accounts

With Ethereum, there is a second type of account: Smart Contract Accounts. These are able to change their state, just like an address changes its balance, without a private key being involved.

Smart contract accounts are versatile. They can use the full range of Ethereum Virtual Machine (EVM) codes to program state changes. For example, a smart contract account for tokens has as its state a table of tokens and accounts.

With such smart contract accounts, one can break the hard, simple logic of accounts. One can introduce arbitrary transaction logics:

  • One can determine that only a certain amount can be debited per day,
  • that two or three signatures are needed to trigger a transaction,
  • that transactions can be reversed for a certain time by a third party,
  • that the tokens associated with the account will be returned to a certain address when a certain amount of time has passed,
  • that one must have a certain token in the wallet to transfer another, etc.

Smart contract accounts enable a variety of new transaction terms. They allow money — and the bank account — to be programmed like an app. They make so much possible — but so far, the ecosystem continues to use the simple, basic standard accounts.

“You can already do all these things with smart contract wallets today,” writes Vitalik Buterin, “but the Ethereum protocol makes it very difficult because it requires everything to be packaged into a transaction that originates from an external account.”

Smart contracts themselves do not form transactions. They merely change state when a user sends a corresponding transaction to them. That transaction must come from a traditional account and be signed with a private key. So the problem with the key and seeds is still there.

But not only that: smart contract accounts also make things much more complicated than they need to be. An example: one holds tokens on a smart contract that only pays out a certain amount per day. To make a payout, one would have to trigger the smart contract by making a transaction from a traditional account. For that, in turn, one has to pay a fee, for which the conventional account needs some Ether.

To get around such complications, one can bring a third party into play to send the trigger transaction. But even that would be suboptimal.

When accounts become smart contracts

Account abstraction means, in Vitalik Buterin’s cerebral but apt way of putting it, that “the EVM code is used not only to implement the logic of the application,” — as in smart contracts — “but also to implement the verification (nonces, signatures …) of the individual users’ wallets.”

Argent puts this in slightly less complex terms: “You turn accounts into smart contracts with their own logic, which is a valid transaction.” So accounts become smart contract accounts without the need for a trigger transaction by a traditional account.

“It’s no longer one model for everything,” Argent continues, “instead, each user can have an account customized to their needs.” You can do virtually anything. Other signature algorithms, such as quantum-safe, multisig accounts, accounts that change hands every week, accounts that can only hold a certain amount of money — there are more possibilities than we can dream up.

You can form accounts with “parental controls”, accounts that you can mine through a social network, accounts where you pay transaction fees not with Ether but with tokens, and so on.

And all this is made possible by a tiny detail: By making the account a smart contract.

Three suggestions

With all the advantages, one wonders, of course: why doesn’t this exist yet? If everyone wants it, and it promises so much — what are we waiting for?

The reason, according to Argent, is that it’s not easy. Account abstraction requires “multiple changes to the heart of the protocol.” Such changes are hard to coordinate, the harder the older and bigger Ethereum is. As a result, Account Abstraction has been discussed since 2016, but is still not implemented.

At the same time, there are several promising proposals:

  • EIP2938 proposes a reduced type of Account Abstraction, allowing smart contract accounts to act as “top-level accounts” — accounts that can initiate transactions and pay the fees. To do this, it introduces a new transaction type and two new opcodes, making the change manageable and simple. The price, however, is that EIP2938 does not support all possible functions, and does not replace the old accounts.
  • EIP3074 goes the other way: it wants to enrich the existing accounts with capabilities like from smart contracts. Users should be able to delegate control of the account to a smart contract. This way, users can benefit from account abstraction with their existing accounts without having to generate new accounts. In doing so, however, users will still need to store their seed phrases, which is why Argent compares it to modernizing carriages with faster horses.
  • EIP4337 comes closest to full account abstraction without requiring consensus-driven changes. However, it is also by far the most complex proposal. It breaks the transaction into individual operations that miners or stakers then assemble and execute. This makes it easy to build smart contract wallets without worrying about transaction fees. At the same time, the implementation of EIP4337 would be relatively disruption-free, as legacy accounts would still be maintained.

Argent does not seem 100 percent happy with any of the proposals, but would welcome any as progress. But when there are multiple approaches but no clear criteria to evaluate them, it is difficult to choose one. This could mean that it will be a very long time before Account Abstraction comes to Ethereum.


In some ways, Bitcoin is further along than Ethereum here. With the P2SH address format, Bitcoin already has a kind of account abstraction: A P2SH transaction is triggered by submitting the script, which is based on a previously determined hash. In principle, you can put anything into the script.

This means that you can already form multisig addresses, which, unlike with Ethereum, do not have to be triggered by a transaction from another address. You can also form addresses where funds are frozen until a certain point in time, and there are plans to allow so-called “vaults” through this, which only allow withdrawals under certain conditions.

P2SH addresses come close to the desired account abstraction — but have their own unique problems. For example, they support only limited functions, usually have a terrible user experience, and often the essential operations take place offchain — such as signing a multisig transaction — for which there is then no commonly used protocol.

So there are reasons to look forward to account abstraction on Ethereum.

All Comments