ERC-4337 (Account Abstraction) is an Ethereum protocol that moves account management functionality from the base consensus layer to smart contracts, enabling developers to create flexible wallet systems with alternative signing algorithms and gas payment mechanisms. This system uses an alternative memory pool (alt-mempool) for transaction processing, bundlers to aggregate transactions, entry point contracts to process bundles, paymasters to handle gas payments, and account abstraction wallets to manage authorization. While this enables gasless transactions for users, it's not truly gasless as the bundler still pays gas fees, and the system requires careful implementation due to its complexity and potential security risks.
ERC-4337 Account Abstraction on Ethereum Explained
Added:Hi, it's Keifan Labates here and in today's video I'm going to talk about ERC 4337 or account abstraction on Ethereum. And I imagine this is going to be quite a long video so buckle yourselves in for this. What I'm going to try to do is explain what it is, what its significance is, and some of the problems I see with it too. So we'll start off with the very sort of global overview of what ERC 4337 is trying to address. And I think the fundamental idea behind it is the idea of moving protocol designs off the base consensus system of the blockchain into smart contracts. And this is quite significant. If you remember in blockchains, you have a consensus system and a set of protocols that are built into the node software and changing those protocols is very very hard. You need to get consensus across all the miners and the coders and foundations and various parties that are interested in um designing and improving the blockchain system. And it can get very acrimonious when people discuss changes and they take a long time to roll out.
Something like a hard fork on a blockchain where the protocol is changed in such a way that certain transactions that were valid are no longer going to be valid if you try to submit them after the hard fork um cause a lot of upset.
So there's a real problem in blockchain that it's a bit inflexible when it comes to making significant changes. And in this sense, you can think of the blockchain protocol as an underlying operating system. And then smart contracts on a smart contract blockchain are like the apps that you run on that operating system. And so making a change to an app is fairly simple and it just affects the app users. But making a change to the operating system that breaks previous functionality is really really annoying to developers. And so what ERC 4337 really is trying to do at the most high level and abstract level is move protocol changes from the operating system into the applications that are concerned with it. And that gives you more flexibility. It also carries some risks because protocols should be thoroughly tested and it's not necessarily a bad thing that blockchain communities take a long time and a lot of arguing before they make such protocol changes. So, it's a it's a trade-off as is always the case in life.
And Ethereum has moved towards the idea of deploying special contracts on the blockchain to handle protocol changes. We saw that with the move from proof of work to proof of stake where you actually stake your stake to become a validator on Ethereum with a smart contract that is on the blockchain. It's not baked into the protocol. So there's a first example of a change to the way that the blockchain operates with some of the functionality being in a smart contract rather than in the code that implements the nodes. And I think that may have been the trigger that inspired people like Vitalic Buterine to continue to make changes that apply at the smart contract level rather than at the base protocol level. So having talked a bit about the background now we can look at how ERC 4337 functions and what its purpose is. And the idea behind ERC 4337 is to make the process whereby Ethereum accounts, Ethereum wallets function be designed and built at the smart contract level rather than at the base protocol level. And the reason for that is that that then opens up the possibility for all sorts of groups to design all sorts of different wallet mechanisms, not having to just rely on ECDSA as a signing algorithm, not having to rely on the users having Ethereum to pay for gas. So that allows for what are called gasless transactions, although technically it's wrong. What it is is um users not requiring gas transactions and things like that. And as is always the case with Ethereum, the design of ERC 4337 is at first viewing immensely complicated. And I found this to be the case with Ethereum time and time again.
Whenever there's a proposal, it always seems to be built in a very complicated way and it takes me ages to understand it. And I really only feel that I fully grasped it when I've actually gone and written some code and built some things using the changes. You can't just understand changes in Ethereum as far as I'm concerned by just reading the docs.
You have to get your hands dirty because that's what in my case reveals what is really going on. So having said that, ERC4337 is about allowing individual developers to design and deploy new wallet systems rather than having to rely purely on um these externally owned accounts. These are your Ethereum addresses in your wallet such as MetaMask and where you are using the digital signing algorithm ECDSA to sign your transactions and where you have to have Ether to pay for gas. You can use ERC 4337 to give your users different designs of wallet and to pay the gas for their transactions. Um, and then you can bolt on other things that allow your users to pay for the gas in tokens or cryptocurrency other than ether.
For example, you can say to your users, you no longer need to go and buy um ether to pay for your transactions. You can pay for your transactions using a stable coin. Um, that's particularly relevant if you're building, say, a payment system where the users are going to be paying um each other using a stable coin.
Your users then don't care about ETH.
They don't want to have to go to an exchange and buy some Ether and load up their addresses in their wallet with the Ether. Another problem that uh Ethereum users who have lots of different wallet addresses face is that all those addresses end up with teeny tiny bits of Ether in them, maybe 10, $20 worth in each one. And if you have 20 or 30 addresses, it can be hundreds of dollars that is scattered like dust across all your addresses. And that's immensely annoying and trying to aggregate that all into one address. The transaction costs on all those little transactions can eat up most of the dust that you have in all those wallet addresses.
Incidentally, this is a problem you don't face in Bitcoin because in Bitcoin when you're producing a transaction, you can suck in the Bitcoin from a whole bunch of addresses. Those are the unspent transaction outputs that become the inputs to your Bitcoin transaction.
So, Bitcoin faces that problem less than Ethereum. And a particular problem in Ethereum is there's a gas estimate. So, you need to have more Ether than you probably are going to need. And that ends up with you having lots and lots of dust in all these different addresses.
It's just till now been unavoidable.
Right, let's dive into the design. Now having talked a lot about the background and the first thing to understand about ERC4337 is that a whole new peer-to-peer network has been stuck on top of Ethereum to handle these um account abstraction transactions. It's called the alt memp pool. So it's an alternative memory pool for transactions. These transactions take a slightly different format to traditional Ethereum transactions and as a result they need to be stored in a different place. So now you have two sets or two pools of Ethereum transactions, the traditional ones in the meool and ones that users submit to the altmeool. And this peer-to-peer network that maintains the altmeool um is a bit more flexible in how it uh allows you to transmit and accept the the transactions into the altmeool and remember they haven't been processed at this point or whether you drop them. So people can run their own design of their own node running on that altmeool peer-to-peer network and decide whether or not they're going to forward transactions that they receive. You can build little local nodes and have your own little local altmeool for your particular application and only accept transactions from particular wallets or particular users that you have whitelisted for example. So, uh, we've got this altmeool and we have these transactions. How do they get on to the, um, Ethereum blockchain itself? And the answer there is that people who are providing these services run something called bundlers. These are um, programs that look at the alt meool, gather these alternative transactions that they are willing to process into a bundle. they verify that all those transactions will pass and they can do that for free because the verification is not making a state change to Ethereum and so um it doesn't cost anything to make queries to the Ethereum blockchain. So they could basically can run a simulation. They may even use a sandbox to check that all the transactions will execute properly on the chain as well. And when they're happy that all these transactions that they've pulled from the altmeool will succeed or at least not fail catastrophically, they bundle them into a bundle and they submit them to a specific smart contract that has been deployed on the Ethereum blockchain that is called the entry point. And this is a smart contract that accepts a bundle and the bundler has to pay ETH uh to cover the gas cost for the entry point contract to process the bundle of transactions. So this is why it's not gasless. All the transactions still end up using gas to get processed. It's just that the user who submitted the transaction to the altmeool hasn't had to pay any gas. there's been some kind of prevalidation of their transaction, reducing the risk of it failing and therefore reducing the risk of the proxy who is um going to process the transaction for them ending up out of pocket. So, as I said, Entry Point is a smart contract on the Ethereum blockchain, and I think they're now on version seven or so, showing that you also have the advantage that you can debug the protocol and upgrade as you find flaws or as you want to add more functionality. And this entry point, I believe, is deployed by the uh Ethereum uh developers. So, there's a community of them. And there's a mailing list and a bunch of people who are have been put in charge of maintaining the Ethereum protocol and the Ethereum system. And the entry point has now received this bundle of transactions. And the entry point unpacks each individual transaction and looks at it to see what details are needed for that transaction to be executed. And this is where two further components appear. One is called a pay master and the other one is called an account abstraction wallet. And these are both smart contracts that are deployed by the service provider. So not by the Ethereum community or the Ethereum devs but by individual developers or companies who want to provide such a transaction service. And they form uh they have two different responsibilities. The pay master sets out the conditions under which the service provider will pay for the transaction and what they expect in return. And the account abstraction wallet handles the authorization and authentication. So what you can think of these as is the account abstraction wallet is the uh signing algorithm that is going to be accepted and checking that the signatures are valid and things like that. Um and the pay master is handling the money side of things, the covering of costs. So the bundler has paid to submit the bundle of transactions to the entry point. The entry point expects to get paid for that and the bundler expects to get reimbursed. Um and the whole thing is set out in smart contract logic and the pay master uh has to have provided funds to the entry point in advance in the form of a stake and describes the conditions under which it will pay the ether gas fee for the transaction and what it expects in return. for example, a certain amount of stable coin. And the account abstraction wallet does the check of the signature in each individual uh transaction that's relevant to it in the bundle to say whether or not the pay master should go ahead and pay so that the entry point will execute the transaction. And I realize when I say this, this sounds awfully awfully complicated. And you're right, it's not a simple design. But uh let's recap again. You submit your transaction to the alternative memory pool. The alternative memory pool peer-to-peer uh network nodes forward it until it reaches a relevant bundler who is happy to process the transaction. The bundler takes the transaction, puts it in with a bundle of a bunch of other transactions too, submits it to the entry point on the Ethereum blockchain. The entry point takes out each individual transaction and looks inside it to see who is going to authorize or check the authority behind the transaction through an account abstraction wallet smart contract that is referenced in the transaction. If the account obstruction wallet uh smart contract says yes this is a valid transaction I approve it then the uh entry point checks the pay master that is specified in the transaction and the pay master um will pay for the transaction if the authorization has come through from the account abstraction wallet and then finally god I'm getting out of breath here the transaction has been approved it has been paid for and the entry point executes it. And the execution may involve calling some other smart contract on the Ethereum blockchain such as a unis swap um smart contract or a stable coin or some ERC20 token or whatever it is. And then the transaction has been executed. And the upshot is for a user that they haven't had to buy ETH for that whole process to work because the service provider who has run the bundler and the account abstraction wallet smart contract and the pay master contract are doing all the plumbing underneath and working out how to handle the payment on the user's behalf. So these are not gasless transactions.
They have occurred using ether. It's just that that use of ether has been hidden from the user. It's like getting onto a bus. You as a passenger on a bus don't have to put in some petrol into the fuel tank of the bus. The bus company does it for you, but you do pay for that petrol because you've paid for your ticket to get a place on the bus in the first place. So, as I said, awfully long video. Um, probably worth watching again if you are interested in the underlying technology and are thinking about implementing some ERC 4337 functionality. Um, if you're not, maybe it's not worth a second view. But just to go back and recap, the whole idea behind this complicated system for handling gasless transactions on behalf of a user is the idea of moving some of the underlying blockchain functionality from the base protocol encoded in the software of the nodes into smart contracts. and to provide developers with the tools and the design to allow them to do that without having everybody coming up with their own individual system for doing it. Um, of course, in practice for companies at the moment, it's quite hard to deploy this stuff.
There are template smart contracts being put out there by organizations such as Open Zeppelin that implement this stuff, providing you with the Lego blocks that you can then pick and choose to build your own system.
Um but it at the moment remains an area where there's not a lot of expertise around for providing this functionality to users. Um will it be significant in the long run? Um it does seem to be getting some traction. I think as more people understand how it works, it's becoming more relevant and as we see more uh cases of ERC 4337 systems being deployed by uh organizations out there, it continues to gain traction, but I think it's a bit slow at the moment. Um the majority of Ethereum developers not really launching wholehearted into this, nor should they. It's new. It's not entirely proven. It's complicated.
Better to wait and see what other people do and what mistakes other people make before you start deploying your own systems handling potentially millions or even hundreds of millions of dollars and then having it all go wrong because there's something wrong in your account abstraction wallet smart contract that allows a hacker to authenticate instead of one of your valid users. Um, on the other hand, as an inventor, it's nice to see this kind of innovation going on in the Ethereum ecosystem. It is, I think, one of the more innovative blockchains in that respect that despite the fact that it's been around for a long time, it hasn't stagnated. This does feel that there's constant progress and I do look forward in the future to seeing what other weird and esoteric things will roll out in the future. Um, I should probably wrap it up at this point because I'm hitting the 20 minute mark.
So, this is a long video for me. But if you have any queries or if there's anything specific in this video that you would like to hear me talk about at a bit more length, then please do leave a comment below and I'll do my best to make time to go and tackle the issues that you raise. Um, now all that remains just me for me to say, I hope you've enjoyed and at least partially understood this video. And I look forward to seeing you in the next one.
Bye for now.
Up Next

Building an ERC-4337 Wallet: Account Abstraction Explained
@ETHGlobal
9.8K views•2022-10-16

Torrent File Format & Bencoding: A Technical Deep Dive
@AsliEngineering
12.5K views•2022-08-08

Operational Security Essentials: A Guide for Hacktivists (OPSEC)
@hitbsecconf
157.4K views•2012-11-26

Understanding Ethereum: A Comprehensive Beginner's Overview
@99Bitcoins
3.1M views•2018-06-26
Related Study Plans & Knowledge Roadmaps
Structured learning paths in Blockchain & Crypto



































![[Cortes] Como garantir a segurança do projeto DeFi? (Caique Beringui)](https://i.ytimg.com/vi/_zXyuMw2-vA/maxresdefault.jpg)
![Cybersecurity workshop, 29 October 2019, Brussels [Part 1]](https://i.ytimg.com/vi/qyEGekvX9ks/maxresdefault.jpg)