Intern Breakdown #6: Account Abstraction
Account abstraction explained at 3 levels of depth (👶, 🐸, 🧠)
Move over AA batteries, Alcoholics Anonymous, American Airlines, double-A baseball teams, and this 2010s K-pop boy band — there's a new dominant “AA” in town: Account Abstraction.
Maybe you’ve never heard this term before, maybe you’re vaguely familiar, or maybe you’re an expert currently co-authoring EIP-4337. Whatever your level of prior knowledge, please allow me to regale you with an explanation of this topic in three levels of increasing complexity. Together, we’ll learn why it’s apparently:
- “a game changer for crypto's adoption”
- “Ethereum’s broadband moment”
- an upgrade that turns a wallet from an abacus into a computer
- “the most game changing feature in web3 that you have never heard of”
I believe all this excitement is warranted — account abstraction is still vastly underrated right now.
Yep, I’m all-in on account abstraction. Drinking the kool-aid. Onboard the hype train. AA-pilled. Let me see if I can convert you, too.
Level 1: Normie
It’s no secret that web3 currently has some major user experience (UX) problems. I figured the industry would chip away at these over time, gradually improving the usability of crypto apps until finally, after years of hard work, blockchain-based applications feel as smooth as web2. Account abstraction is exciting because it addresses a bunch of these seemingly distinct UX issues all at once. I’m not saying it’s a silver bullet for every UX problem… but it’s almost comical just how many problems it helps alleviate, if not altogether solves.
To get into some specifics, let’s examine the current state of web3 UX. We’ll walk through the user journey of someone just getting started as they try out their first crypto app. Keep track of how many times the process feels inconvenient or antiquated. Every one of these frictions is a roadblock to mainstream crypto adoption.
1. Let’s set up a wallet
Your wallet is where you store all your crypto goodies (NFTs, tokens, coins), and it also acts as your identity, username, and password.
Oh, but this password isn’t a normal password — it’s a “seed phrase” of random words, and you have to be extra careful not to lose it, because there’s no “forgot my password” option. If you lose or forget your seed phrase, then I’ve got some bad news about all of your assets…
Trying to change your “password” (private key)? Nope. Can’t do that. If you want to rotate your keys, you’ll have to move all of your assets to a new wallet.
What’s that? You want some extra security for your wallet — maybe one of those 2FA systems that makes you confirm transactions using a second device? Nah, can’t do that either. But if you want to be like the most secure crypto OGs, here’s what you can do: buy a piece of metal and engrave your magic words into it! (Take a look at these “9 Best Crypto Metal Plates” for some recommendations.) That’s right, crypto is supposed to be the future of the internet, and we’ve got people trying to store their seed phrases like they’re Moses recording the 10 Commandments.
Oh and btw, even if you keep your keys super secure, the underlying math that makes them work is going to become hackable once quantum computers become more powerful.
2. Let’s do some stuff
You’ve got your wallet — now it’s time to play some games, or do some DeFi, or buy some NFTs. Well, right after we jump through a few more hoops. Because before we can do anything, we need to acquire some coins to pay for gas.
Bootstrapping your wallet with even a tiny amount of gas money can be a real pain, and although there are several options for loading up your wallet, none are very pleasant. One option is to ask someone who has some coins to send you some of theirs for you to keep for your personal use — the “SBF method.” But maybe you don’t know anyone who holds crypto, or maybe they don’t want to act as your personal bank account. You could try buying some coins through an exchange or a service like Moonpay, but you’ll almost always need to perform a bunch of KYC verifications. You just wanted to buy a stupid JPEG, and suddenly you’re uploading photos of your passport to a random website and trying to remember your social security number. Not ideal.
But wait, the app you’re trying to use is super simple — it can’t require that much gas. Why can’t the app just pay the gas fees for you? It’d probably be good for them — they might be willing to sponsor your gas costs as a first-time user in order to acquire you as a customer. Unfortunately, there’s no simple way to do that right now due to the technical constraints of Ethereum and similar chains. Bummer.
3. Let’s actually do some stuff
We’ll suppose you’ve found some way to get the coins you need to pay for gas. Now you can actually surf the web(3)! You’ll soon find that the UX isn’t exactly what you’re used to in the world of non-crypto apps. Seemingly simple tasks require you to respond to several pop-ups from your wallet asking you to “sign a transaction.” You’re not totally sure what this means, and although you’ve been told to “be careful about what you sign,” you’re not confident you can distinguish a malicious request from a legit one. Sometimes, you need to sign one transaction, then wait a bit for it to “be confirmed,” and then sign another one. This whole process feels needlessly inefficient, complicated, and unintuitive.
We get it, web3 UX is bad
Ok, some of what I just described was kind of like those infomercials that make simple tasks look impossible. Of course web3 UX is going to sound terrible when we only look at the parts with the most friction.
There are solutions that help ease some of the issues I mentioned, like multi-sig and smart contract wallets, or systems that enable gasless transactions. But a lot of these workarounds are kind of janky — they’re not first-class solutions that get to the root of the problems.
Account abstraction is a first-class solution. It’s a feature that unlocks new ways for users of a blockchain to send transactions (technically, it’s a new way for users’ transactions to be verified, but we’ll get to that later.) Ideally, users should never have to even hear the words “transaction” or “signature” — account abstraction should help make web3 apps feel familiar and intuitive. It should feel like apps have finally implemented common sense.
Let’s explore how account abstraction improves UX by walking through a new user journey. (This is the part of the infomercial where we cut from black and white to color, and suddenly the person using the product becomes competent and happy.)
1. Let’s set up a wallet
The wallet you’ll use to take advantage of account abstraction is a “smart contract wallet.” When you set up a smart contract wallet, you’ll still be given a seed phrase to remember, but the wallet provider will tell you something like this:
Hey, make sure to remember this seed phrase! But if you lose it, no worries. There are plenty of options for you make sure you can recover your wallet if that happens. You can:
- List a trusted friend as a backup who can help you recover your wallet using their credentials
- List a secondary wallet you control as a backup that can help you recover your wallet
- Sign up with a company that helps you manage a backup recovery method
- Feel free to choose any combination of the above options!
In addition to these “social recovery” methods, you can easily change the private key(s) that control your wallet, similar to how you might periodically change your password for web2 services. And you can set up arbitrarily complex authentication logic for additional security, such as requiring approval from a secondary device for transactions greater than $100, or restricting a wallet to only be used for applications A, B, and C.
The flexibility provided by account abstraction even means that your phone — which has built-in encryption features in a piece of the hardware called the “secure enclave” — could act like a hardware wallet, making for a seamless and secure mobile UX.
But wait, there’s more! The same encryption algorithm agnosticism that allows account abstraction to leverage your phone’s hardware also lets you opt into using an algorithm that’s safe from quantum computing if/when that becomes a pressing concern.
2. Let’s do some stuff
When you’re ready to take your smart contract wallet for a spin, you’ll be pleasantly surprised by how easy it is to use apps that support account abstraction.
Suppose an app decides it’s willing to pay for your gas costs. Now it actually can! No more begging friends to send you a bit of ETH, and no need to plug your SSN into that sketchy no-KYC exchange just to get some gas funds. Gas sponsorship could even become the norm for simple transactions, especially on layer 2 blockchains that have cheap fees. After all, when was the last time you used a web2 app that asked you to pay for its server fees?
We’ll cover other features like multicalls and session keys in the next section, but suffice it to say you won’t need to deal with nearly as many wallet pop-ups asking you to sign things. As you play games, trade tokens, and buy collectibles you’ll have to deal with the bare minimum number of inconvenient authorization prompts.
Normie Additional Resources:
📖 “What Can You Do with Account Abstraction?” (Derek Chiang)
📖 “Random thoughts on Account Abstraction” (Sylve Chevet)
🧵 “The most game changing feature in web3 that you have never heard of” | @MagikLabs
📖 “Ethereum's broadband moment” (proofedloaf.eth)
📖 “What is Account Abstraction and Why is Everyone Talking About It?” (Aleksandr Malyshev)
Level 2: Degen
A few months ago, all of Ethereum was hyped about a single event: the Merge. It was the narrative of the summer. At the time, I wrote:
From a user experience (UX) perspective, the Merge might actually be a bit… underwhelming. Dapps will feel the same, and ETH holders don’t need to do anything to upgrade or convert their coins.
[…]
Core Ethereum developer Tim Beiko describes the Merge as an “under the hood” upgrade, analogous to replacing a car’s combustion engine with an electric engine while the car is being driven without the driver realizing what’s happening.
That turned out to be pretty accurate. The Merge went off without a hitch, meaning it was super boring (in the best possible way).
Account abstraction offers a new narrative for Ethereum — one we desperately need during this not-so-fun part of the market cycle. From a user’s perspective, account abstraction is the anti-Merge. It’s noticeable. It changes the UX. It allows app developers to implement cool new features. And unlike the Merge, it’s not a change to the underlying Ethereum protocol that requires a hard fork. To stick with the car analogy, it’s like keeping the car’s engine the same but upgrading all the parts passengers interact with — think butterfly doors, a better stereo, and a sweet high-tech Infotainment system.
What’s even more exciting is that account abstraction is already here — at least on select L2s. StarkNet and zkSync both natively support account abstraction, so you can try out some of these features on apps deployed on those chains. EIP-4337 (more details to follow) is working on bringing account abstraction to the Ethereum mainnet, but that’s a slower process that’s still being ironed out. It will require lots of app developers to make changes as they adopt the proposal’s specifications and support smart contract wallets. Although we’re still in the early innings of the rollout, we can already see and imagine some of the exciting features that are emerging. Here are the highlights.
Dame más gasolina
We’ve covered how apps will now be able to sponsor your gas fees, but that’s not the only gas-related benefit of account abstraction. You’ll now be able to pay your gas fees using tokens other than L1 coins — i.e. using ERC-20 tokens rather than ETH. This is, of course, big news for all the degens out there whose wallets look like the 15th page of CoinMarketCap (“ayyo KeanuReevesInu is legit about to pump”). But it’s also helpful for anyone who’s used a bridge to transfer tokens between chains only to realize they’re unusable unless the wallet also has L1 coins for gas. Paying for gas with arbitrary tokens is basically the web3 equivalent of walking into a store, realizing you have no cash on you, and paying for your groceries using a handful of Chuck-E-Cheese tokens and a half-used Dunkin’ gift card. Nice.
To give one more illustration of the flexible gas payment mechanisms enabled by account abstraction, I’ll present a very uncontroversial example: Tornado Cash. Suppose you’re an innocuous non-hacker from a country that doesn’t conduct state-sponsored criminal acts, and you want to use the Tornado Cash mixer to privately move funds from one wallet to another. Your plan might look something like this:
There are relayer systems that help get around this problem, but it’s not ideal to have to trust a third party. Account abstraction offers a much better solution by allowing users to pay for the gas needed to initiative the withdrawal using some of the ETH they’re withdrawing. This is a somewhat niche use case, but it’s a good demonstration of how account abstraction provides flexibility that makes a variety of tasks simpler.
Multicall
I’ll bet most people who’ve used any sort of DeFi app will agree with Hasu that the current step-by-step transaction flow sucks. Multicalls are a feature that fix this by allowing users to queue up several transactions to submit all together as a batch, and they’re supported by smart contract wallets like Argent. Here’s how that looks when interacting with Uniswap:
Other apps are using multicalls to implement familiar “shopping cart” features that let you stash a bunch of transactions that you can eventually submit all at once — for example, purchasing several NFTs with a single click.
Session Keys
Imagine a super simple on-chain game — say, a web3 version of Chess.com where every move is a transaction stored on the blockchain. In a naive implementation of this app, every time you make a move you’re prompted by MetaMask to sign and submit a transaction. This would be extremely distracting and inconvenient, and you’d probably end up pulling a Magnus Carlsen and rage quitting.
With account abstraction, the app could instead allow you to authorize a session key at the beginning of the game and then leave you alone to play. Session keys are temporary keys that give an app limited abilities to perform transactions on your behalf. When you start a new chess game, you could be prompted to approve a session key that will only be valid for 30 minutes and can only be used to call the movePiece function of the verified Chess.xyz smart contract. Then, every time you make a move, the app’s smart contract and your wallet’s smart contract can communicate directly without requiring anything from you.
Security
In addition to providing tools for social recovery (dealing with lost keys/seed phrases), key rotation (changing your private key(s)), and a wide array of options for signature schemes, account abstraction offers other neat security configurations. Here are a few mentioned in Argent’s great “WTF is Account Abstraction” series:
Multi-chain
Account abstraction will enable a smooth multi-chain experience by letting you create several separate smart contract wallets that can all be controlled from a single UI, using (optionally) a single private key. You could have a single signing key (or maybe a few, for casual use/trading/long-term holding) stored in an app that you use to dispatch operations to smart contract wallets across Ethereum, Starknet, zkSync, etc. — any chain that supports AA.
Other
I’ll end this section with an idea that’s a classic within crypto write-ups and discussions — some of the coolest applications of account abstraction are those we can’t yet imagine. Any time you change a system from having hard-coded logic to offering completely open-ended configurations (your wallet is a single, specific private key → you can configure your wallet with basically any type of code you’re creative enough to write) you get interesting and novel results.
This post highlights some of the cool things that could lie on the horizon, such as an app-store-like ecosystem of wallet “plug-ins,” and the ability for apps to run recurring transactions on your behalf (e.g. for DCA investing or subscriptions).
Degen Additional Resources:
📖 “WTF is Account Abstraction?” [Julien Niset from Argent] Part 1 // Part 2 // Part 3
📖 “The History and Future of Account Abstraction” (Ismael Darwish)
📖 “How to Make On-Chain Gaming Competitive: ‘Session Keys’ [Part 1]” (Matchbox DAO)
🧵 “Session keys are going to radically improve the user experience…” | @argentHQ
Level 3: Gigabrain
I’ve tried to avoid using terms like EOAs, signers, and bundlers so far, but now let’s get a bit more technical. After all, if you’ve reached this section, you might be the type of person who hears “account abstraction” and thinks, “thank god, I’ve always hated being locked into using secp256k1 with ECDSA on Ethereum, why can’t I use another curve?”
Technical Overview
Accounts on Ethereum come in two flavors: externally owned accounts (EOAs) and smart contract accounts. EOAs are associated with a public/private keypair, also called a signer. An EOA’s address is derived from the signer’s public key, and the EOA can be controlled using the signer’s private key (e.g. to send transactions and sign messages).
This article does a good job of emphasizing the relationship between an account and a signer, which are tightly coupled in current model of Ethereum EOAs:
the concept of Account (the object holding your tokens) and the concept of Signer (the object authorized to move these tokens) are basically the same thing! If you have a private key you automatically have an account at the associated address, and to own an account at a given address you must be in possession of the corresponding private key.
The main problem with the status quo is that EOAs are a privileged class of accounts within the Ethereum protocol. They have special powers that smart contracts lack — most crucially, the ability to initiate transactions. But due to the tight coupling of EOAs and signers, they’re also too rigid to allow for all those cool features mentioned earlier.
Account abstraction aims to jailbreak the accounts we’re used to using on a daily basis. Vitalik’s pithy description of AA covers this nicely:
Instead of EVM code just being used to implement the logic of applications, it would also be used to implement the verification logic (nonces, signatures…) of individual users’ wallets.
In other words, account abstraction won’t change the execution of Ethereum transactions, but it will create more flexibility around how a transaction can be verified. This separation of the verification and execution stages of a transaction will become important when looking at specific implementations of AA.
A Brief History of Account Abstraction
Account abstraction is not a new idea. It’s been around since 2016, when Vitalik first proposed a version of it in EIP-86. Since then, there have been a range of proposed implementations (the timeline below is decent, and there’s an even more in-depth history here).
There are several different conceptual ways to achieve account abstraction, including modifying of EOAs to make them more programmable, and upgrading smart contracts to give them the ability to initiate transactions. Anything and everything has been proposed at some point. The main roadblock for implementations like EIP 2938 — an implementation that lets transactions start from a contract — is that they require significant changes to the Ethereum protocol itself. Adding new EVM opcodes and requiring a hard fork is no small ask, especially for the saintly Ethereum devs who have been busy grinding away on the Merge, sharding, stateless Ethereum, and other exciting roadmap milestones.
Enter EIP-4337. This is the most promising proposal to unlock the best features of account abstraction, and it avoids the need for consensus-layer protocol changes by instead relying on new, higher-level infrastructure. To sum it up in a single sentence: under EIP-4337, users do stuff by submitting transaction-like objects called UserOperations, which are then sent to a new mempool → bundled together → validated using a special entry point contract → included in a block.
Basically, EIP-4337 says “ya know, there isn’t enough jargon in the Ethereum world, so let’s introduce new terms like ‘bundler’ and ‘paymaster.’” Because things weren’t confusing enough when newcomers had to learn the nuances between terms like miners, validators, block-builders, block-proposers, and relayers.
The rest of this section is devoted to EIP-4337. First, we should break down the three key parts of the specification: the UserOperation mempool, the entry point contract, and the notion of a paymaster.
Pool Party
When a user wants to perform an on-chain action using an AA-compliant smart contract wallet, they’ll start by submitting all the relevant data: a payload containing the details of the transaction they want to perform, plus the signatures and other data needed for the wallet’s custom verification logic. This will all be packaged within a UserOperation object and will be sent to a mempool, almost exactly mirroring the current flow of sending a transaction to the familiar transaction mempool. Bundlers will take a bunch of these UserOperations and parcel them up into a “bundle transaction” which will get added to an Ethereum block.
What’s the (entry) point?
To be conformant with EIP-4337, smart contract wallets must implement a validateUserOp function that takes a UserOperation and checks if it passes the wallet’s configured verification logic (i.e. are the signature(s) and nonce value legit?). For extra security and simplicity, calls to this verification function will only originate from a single special contract called the entry point contract. This contract will act as a trusted component of the Ethereum network that is the only entity able to compel a wallet to perform an action or pay a fee.
The entry point contract acts as the maestro and the bouncer for all smart contract wallets, dispatching UserOperations for verification and also handling the creation of new wallets when necessary.
PayPalMaster
Two of the new fields included in UserOperation objects that are not present in current transactions are paymaster and paymasterData. These fields are what enable accounts to sponsor a user’s gas fees, and for users to pay for gas using ERC-20 tokens. If the UserOperation specifies a paymaster, then part of the verification process that must succeed before execution occurs is ensuring that the paymaster has actually agreed to pay for this operation on behalf of the user, and that the paymaster has the funds to do so. To sponsor an operation, a paymaster will have to stake ETH inside the entry point contract.
In addition to having a validatePaymasterUserOp function to decide whether to sponsor an operation, every paymaster account also must have a postOp function that gets called after the user’s operation is executed. This is what allows many of the interesting uses of paymasters to occur, such as conditional sponsorship and gas payments using ERC-20 tokens.
Understanding the details of the paymaster mechanism is important for grasping the capabilities and limitations of account abstraction. For example, a paymaster can enable you to pay for gas using an ERC-20 token, but it might not be as simple as submitting an operation and watching your USDC balance decrement. Looking at the architecture above, we can see that the ERC-20 you’re using to pay for gas must be managed by the paymaster contract itself so that the contract can claim its tokens in the call to postOp. If you want to pay for gas using an ERC-20 whose managing contract is not configured to be a paymaster, you might be out of luck, or you might need to go through a more complex token wrapping or swapping process.
Clearly, there’s a lot of technical nuance to this EIP. (For example, did you know it’s technically an ERC, not an EIP?) If you really want to get into the weeds — including the potential difficulties around DoS attacks on the mempool by malicious paymasters — the official spec is worth a read.
The Present and Future of EIP-4337
EIP-4337 is still technically in a “Draft” status, but that hasn’t prevented plenty of projects from building out products that more or less conform to its specifications. The most prominent examples are the Ethereum rollups StarkNet and zksync, both of which feature native support for account abstraction and use an implementation that’s inspired by EIP-4337.
Layer 2s are a natural place for these early realizations of account abstraction for a couple of reasons. First, there is a slight overhead in terms of gas usage when you rely on smart contract code to validate transactions instead of the simpler, hard-coded EOA verification logic that happens outside the EVM. Since mainnet gas costs are much higher than on L2s, this increase in cost is much more palatable on L2s (maybe a cent or two, compared to several dollars on L1 Ethereum). Layer 2s are also a great place for trying out novel features since they’re designed to be more nimble and experimental than the L1 settlement layer.
Still, there is some urgency for account abstraction to become the norm across the entire Ethereum ecosystem, including mainnet. Argent co-founder Julien Niset has been especially vocal about account abstraction’s importance as a tool for enabling self-custody through better UX. He argues that if account abstraction doesn’t become mainstream, then as new crypto users are onboarded, they’ll opt for using centralized exchanges. With wallets as they are right now, centralized players are by far the most convenient choice for users who want to avoid the difficulties of current EOA self-custody, including the lack of key recovery mechanisms. From this perspective, account abstraction isn’t just a tool that unlocks neat app experiences and improved gaming capabilities — it’s also crucial for crypto’s core values of decentralization and self-sovereignty.
The endgame for the strongest advocates of account abstraction is the complete elimination of EOAs. This would, of course, require protocol-level changes to Ethereum, and is a very long-term vision. There are a few ways this could happen, including a “weaker” conversion mechanism in which a new transaction type is added to Ethereum that lets you convert your EOA into a smart contract account, allowing you to keep all your tokens, NFTs, etc. at the same address. A “stronger” version would involve a hard fork that forcefully converts all EOAs into simple smart contract accounts en masse — a complete EOA extinction event.
Maybe we’ll have to worry about this someday down the line, but for now it’s just speculation. EOAs are here to stay for a while, whether we like it or not. But that’s the beauty of EIP-4337 — it might not get us to 100% pure, EOA-free account abstraction, but it’s simple and it’s something we can get excited about now.
Gigabrain Additional Resources:
📖 “ERC 4337: account abstraction without Ethereum protocol changes” (Vitalik Buterin)
📖 “Account Abstraction in zkSync 2.0” (Angela Lu)
🎦 “Why Account Abstraction is a Game-Changer for Dapps | Devcon Bogotá” (Julien Niset)
🎦 “Talk | ERC 4337: Account Abstraction via Alternative Mempool” (Yoav Weiss)
Hopefully, it’s now clear why account abstraction is a BFD. If we think of the challenges facing widespread crypto adoption (onboarding 1B+ users) as a hydra-like FUD monster, the Ethereum community has been bravely chopping off its heads one by one. The Merge slayed criticism about the network’s energy usage, but there remain significant concerns about scalability, privacy, UX, MEV, and maintaining decentralization, to name just a few. Luckily, there are technologies and systems to fight each of these, including ZK tech, sharding, rollups, Flashbots/MEV-Boost, and other planned protocol upgrades on the roadmap. This is an epic battle of good versus evil — technology versus chaos — and account abstraction is a crucial part of the Allied forces.
I’ll end with a few unsolicited predictions about the future of account abstraction:
Rollout and adoption will be slow. Account abstraction was first proposed in 2016, and it’s taken until now for it to really gather steam and start to be implemented for real. Almost all major developments in Ethereum take longer than we think — but the upside is that they’re usually well done when they do arrive.
AA will act as a tailwind for the “crypto wallets as your log-in / identity” thesis. It will also disrupt certain behaviors we take for granted right now (e.g. how will “Soulbound” tokens adapt to smart contract wallets, which can more easily be sold from one person to another?), but these issues will be surmountable.
There will be speed bumps along the way. Although giving people more flexibility in terms of how they secure their assets is a net good thing, it’s almost inevitable that some users or niche wallet providers will screw something up. I hope I’m wrong — I hope code audits and other preventative measures prevent these issues — but I can imagine hackers taking advantage of smart contract wallets as a new attack surface, or careless wallet providers flubbing social recovery or 2FA systems.
People will continue pushing for a protocol-level upgrade even as EIP-4337 gets rolled out more broadly. I’m very skeptical that a protocol update will come any time remotely soon, though — maybe 3-5 years away. There’s even a world in which EIP-4337 works well, the vast majority of app usage becomes entrenched on L2s, and everyone collectively decides that a protocol-level update for adding AA to Ethereum mainnet is a super low priority. Path dependence is a powerful force.
All of this is very exciting and makes me super bullish on the future of web3. The bear market is a great time to build and…
HAHA psych! Crypto is dead, and this was all a ruse. Tune in next week when I announce that I’m pivoting to writing AI breakdowns.