Kristof Gazso - ERC-4337 in a post-Pectra world

Welcome everyone. Oh, this is the pointer. This is the slide. Thank you. Thank you.

Thank you. So, my name is Kristoff. I'm the founder of Pimlo, a company that specializes in giving tools for developers to build with smart accounts. And today, I'll talk a bit about what um Red is going to be like for smart accounts after the Pectra upgrade. So I have three very specific goals in this presentation.

One is to explain to people the difference between ERC 447 and 7002. This might be of a technical talk. Um and before I actually continue, I want to know who here in the audience has heard about ERC 4337. Can you put your hands up? Okay, that's a lot of people.

That's great. And how about um EIP7702? That's that's also great. And one final question here is um who in the audience thinks ERC 457 is competitive with EIP7702. Okay, a couple hands not not too many.

Um but uh that we we'll touch on that in a second. Then next the second thing I want to address afterwards is future smart account relay. Right? For a long while, the only real way to relay smart accounts was with ERC47, but that now changes with this new EIP. And finally, what can developers actually do today to improve the user experience for their applications, for their wallets using all this existing tech that's out there.

Okay, let's quickly do a recap of ERC 447. So, this ERC at the end of the day is a standard that allows smart accounts to plug in to an existing large set of relayers and gas sponsorship modules. So before if you were building a smart account, you've had to build the actual account yourself. You would have had to set up relaying for yourself, set up the way you sponsor Gasper users and actually secure the whole thing yourself, making sure there's no problems the whole flow of the transaction, the validation, all of that. Now instead there's this new ERC which introduces this user operation strct that Walt can send to these specialized re layers called bunders.

And with this um these bunders will take these user operations and put them into a so-called bundle submit them on chain through a specialized entry point smart contract. with this smart contract. Um, this the specialized contract which is very well audited, handles all the security implications, all the entire flow, the the gas management, all the things you you really need to make sure are secure when you're building a smart account. Next quickly is EIP 1702, which is part of the Petra upgrade that went live on May the 7th. And this EIP is doing slightly something different, right?

So this allows um developers and users um a new way to turn their existing accounts into smart accounts. So previously there was no real way to sort start using a smart account beyond creating a new account, transferring all your funds and going from there. Now you can turn your existing accounts that you might have, you know, Metamas, all similar wallets and actually make them smart accounts, have all the smart account functionality. So um there's actually been quite a bit of adoption already of 772. If you look there's actually already over a hundred million dollars of TVL that is inside these EIP72 deployed smart accounts and it's over uh basically 200,000 deployed accounts already.

So this has been only two months. I think that's quite impressive so far for such a new upgrade. Now my first goal right my first goal was to um dis like dispel this myth that these two aren't competitive. So ERC 447 again is an interface for how your smart account can look that will make it easy to plug into all these existing systems, these existing ecosystem of bunders, pay masters, all that stuff. And EIP702 is not uh does not designate how your smart account should look like.

It gives you a way to turn your existing EOA into a smart account. And so because the first was a standard, it does not need a hard fork. And because the second one introduced a new transaction type and a bit more complexity there, it does need a hard fork. So these are the fundamental differences, right? But the point is they are completely independent.

You can use ERC 447 accounts but not deploy them with 7002. Um you can use you can deploy with 1702 but with a different account type that's not 447. Um you can use both. You can use neither. These are two completely independent things.

They actually take care of very different functionality and enable different things for users. Okay, so this was the first part of the talk. Second part is the future of smart account relaying. So now um for for the longest time the ERC 447 was the main way that people are relaying transactions to smart accounts and this is you know this has worked pretty well. There's been over 300 million user operations sent in the history of 4v7 across many different chains.

Uh there's been more than 30 million accounts deployed and some of the major smart accounts that have been live so far. You know, Coinbase wallet, metamask, um, unis swap wallet, these are all actually ERC 4% compatible or have a version where you can upgrade to make it compatible with this ERC, right? So, this is really already taken off. It's really quite become standard in the space. But that's not the only way that things get, right?

That that's the default, but you can imagine new custom, more efficient, but potentially more proprietary systems emerging. So in the standard flow of how you submit a transaction with smart accounts is the following. First you get the gas price for how you're going to create the user operation the transaction. You're going to get stuff data which is basically like fake data. You just need to make sure matches the structure of the transaction for the pay master.

Um you estimate the gas limits. Then you actually get pay master data for real. Then you send these operation. Then you pull to make sure you actually get the receipt and it's included as you expected. Now um this is again the flow if you're using payoffs you're sponsoring the gas but you can actually cut a few corners here to improve latency if you really want to.

So for instance uh most straightforwardly you could make it so the relayer itself um which typically is the bundler um it actually pays the whole gas of the transaction instead of delegating this to a custom pay master. Uh, with this you already collect two RPC calls, but it means that the payment that the relayer you choose is the only one that we able to actually relay your transaction for you because you need to have a custom deal with them to make sure they get compensated after the fact. You can also do some other optimizations. You can make it so you fetch the gas price in the background. You don't fetch directly for the transaction.

You can make it so that for some of the most common things, you know, user might do, you would hardcode the gas because you just know that this is how much it's going to cost. And so with this with these optimizations you can really cut a lot of latency out of the whole flow. Um so the third potential feature here is self pulse. So with EIP72 because the account that you deploy with this EIP um you it still has a private key that you own. You can submit transactions on your own behalf to the smart account that you that you deploy to your own address.

This means that you can keep submitting um transactions to your smart account without needing to rely on a custom relay layer contract and this is quite cool again because you don't need custom infra custom tooling custom payoff funders to interact with your account. But it does mean for instance that one you always need ETH on your account to initiate your transactions. This completely gasless flow doesn't become completely possible. There's caveats now to that. Um And second is you still need to sign every single transaction with your uh master private key if you're going to do these self calls which means it it does make it more difficult to do flows like session key flows where you say delegate some of your access to your account um to to different entities or for instance transaction automation you know DCA into um different contracts different points so it has its own limitations and so you know the typical questions people often ask projects is you know will the dev do thing.

Well, the question is what should the devs do? Um, in this situation, I'm going to split this into two different parts, right? For for the wall devs, um, this is this is a lot more relevant, but there's also things some some things that DAP devs can do. So, for Walt developers, really the, you know, I gave you three options. Why not both?

Why not all of them? So uh what you can actually do is if you see the stats I showed you before with how many EIP702 deployments have happened, how much TVL is in it. If you actually filter, you'll see that almost all there's a couple exceptions. Um the biggest wallets also implement ERC 457. They implement 72 and 457 with many of them actually by default do self calls that I just mentioned.

the third option but then they can always fall back on ERC 427 just a very decentralized very you know eosystem with a very widespread amount of adoption in case something goes wrong in case the user doesn't need funds on the chain in case they don't have ETH in case they want to do some session key flow that wasn't possible with self calls so basically you don't need to choose between the two you can get both now um again this name session key flow and automations but okay that's that's one thing about the wall devs What should that dev do? Now, before I go any further, I just want to quickly ask, who here has heard of EIP5792? Okay, that's that's a couple people. No, not too many, but okay, that's great. That's perfect because if you're building any application that's not basically a wallet, you should really be paying attention to this.

Uh, this EIP came out a while ago, but was sort of, you know, reborn as as like kind of a phoenix um basically a year ago. and it gives ways for DAP developers to actually make use of all the cool things that smart accounts can do. Now, so before if you're building a DAP, you would signal to the wall that you want to transaction executed by making an east send transaction raw call. This would encode all the parts of the transaction like what you're trying to call, but also the gas price, the nons, um the sort of you know sender address, all the potentially, you know, and then ask the signature and then send it yourself, right? So, this had not just what you wanted the user to call, but also a lot of hardcoded things which should really be the wallet's responsibility, you know, like picking the gas price, uh picking the nons the transaction.

Well, uh with this um EIP with EIP 5792, I know it's a lot of like these four other um four number four number EIPs that get turned around. This enables a new RPC method called walt send calls and this looks slightly different from the eat send transaction call.

So with this you can see um w send calls has a list of calls that you can make that specify the two data and the value of what you want to do. So you can be like hey I want to swap this on on unis swap and I want to then transfer this and then this actually makes it so you can signal that you want a batch of transactions to be executed at once which is not possible before and then as an extra you can also signal as the DA that hey um I'm as a DAP I'm willing to actually sponsor this transaction um and you can actually see the capabilities that walts have and make use of them right so finally if if we implement this as as ecosystem we can actually make use of all these cool things that front accounts have had for quite a while now really and so this is you know not a uh this is you know quite a a recent thing but actually a lot DAPs already have implemented and have this EIP in production. Um, so so definitely really recommend taking a look at this, making sure you're you're compliant. There's actually a lot of easy ways now to to enable this on your app. Okay, so so that was the uh what I want to touch on.

Uh, thank you very much for building with smart accounts. I have some of the sources here for for bundle bear walt a some of the sources we used and some resources you can check out. Maybe you want to take a a picture of if so and I assume there time. I have to take one or two questions. Is there time there?

Oh, I think as you mentioned this EIP7 5792 we can send multiple calls to the um wallet, right? So is it like a batched transaction or something?

When you send multiple transa Okay, let me go back to the slide here. Um yeah if okay here we go. So here um yes if you see on the on the example transaction here um on the calls part you can see that's an array right so you can actually put multiple different transactions together that you want the wall to execute. So for instance, unis swap uses this to combine if it seems that you have a smart account the approve and the swap flow which you know for way too many years really has has been completely separate and you've had to make two separate transactions to make that possible. Again this is only possible if you have a smart account but if so this is now you know one a one step flow

but the gas is going to be for a single uh transaction right not multiple trans gas is like we are reducing the gas. Yeah. Yeah. You will very likely reduce the gas as well if you do this. Um if the if the wall can bash these two because it is a smart account because it has the capability then yeah you will spend less gas overall than if you just did two separate.

Okay. Perfect. Yeah. Thank you.

One three. Nice. Um so first I wanted to mention that wallets are struggling with redelegating the code. For example, if I delegated the code in MetaMask, then it would be problematic for me to set up let's say Empire wallet. So, you could explain some of the statistics.

And the second thing that with Pi 792 handling um failing of like middle steps in the transaction is quite hard yet. So that developers they should still consider the normal flow with sequential execution as a basic one. So probably this

yeah I mean for sure 100% agree. Um the part of actually one of the capabilities that you can get if you're using this 5792 EIP is to see if the wallet supports atomic calls, right? If you can actually include both of the transactions together and if one fails, make sure the other fails as well. Not all wallets can support this, but if they can, um that's really great, right? But not all of them can right now.

Awesome. Well, in that case, thank you so much, guys. Hope you learned a couple things. [Applause]