New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

An introduction to EIP-7702 | Jan Gorzny - Zircuit

Ethereum DenverThu, Oct 9, 2025, 12:00 AM

Speaker

Jan Gorzny

A new transaction type that permanently sets the code for an EOA. πŸš€ Get Ready for ETHDenver 2025! πŸš€ We're already hard at work preparing for next year's biggest Web3 event! Keep your eyes peeled for more info on ETHDenver 2025β€”it’s going to be epic! 🌟

Transcript

[Music] hello how's it going I'm GNA wait for my slides there it is perfect hello everyone my name is Yan gorsy and I am a co-founder and Technical lead at zerit and I am here to talk to you today about EIP 772 which you may know a little bit about or maybe you don't this is mostly for the people who don't but if if you uh do know something about it maybe you'll still learn something and uh still find it interesting so without uh further Ado let's get into it so the boring technical details or sort of the details of the EIP um which aren't that technical uh what is it the Vital Information what does EIP 7702 do well it is an EIP that's uh about setting an EA account code that's the name of it and it's authored by a bunch of you know well-known people or or established uh researchers in the space and one thing I really want to highlight here is that on that list of authors which is a great list of authors I'm not on it so if I say anything wrong I apologize please you know call me out on that later but uh you know hopefully it's all still good and just if I do misspeak this is exactly why but anyways the EIP aims to add a new transaction type where you can set account codes for eoas it's been out for a couple of uh you know not quite a couple of years but a couple of half years maybe in terms of uh drafts and it's actually going to be included in the upcoming Petra release of eum um so it's a pretty core um EIP that everyone's going to have on ethereum L1 and then probably shortly after on a bunch of l2s as soon as it goes live which is um something we'll talk about a little bit later in terms of the release timelines and things like this so why do we want it why do we care about EIP 7702 well we wanted a better user experience that's the full sort of short version of this we wanted something that we could do many different um transactions at once on chain for a bunch of reason reasons so for example right now if you want to deal with sending someone in near C20 if you don't know them you've never dealt with it before you have to approve your spend and then you have to actually spend it this is really annoying uh and requir is doing multiple transactions and you know they might haveit the chain at different times things might happen weirdly it's not great if only you could do it all at once in fact that's one of the goals of uh vip7 NO2 and one of the things you can do so you can batch transactions but once you start going down this Rabbit Hole of what type of ux you want to improve for end users you actually want to do um other things too there's a bunch of use cases you can do with arbitrary code attached to an EA um and two of the more popular ones are sponsorship so I could sponsor someone else's transaction I could say I'll pay for my colleague or my friend's um transfer or smart contract call or something like this and that's really helpful for onboarding people um if people are new they don't have eth maybe this will help them get some eth it's also really good if I'm a Dap uh because maybe I want to sponsor transactions that will Target my dap and I will gain users as a result of it um so there's a lot of benefits of doing this also great for things like l2s where we can sponsor onboarding onto our chain one of the reasons that zerit here is also interested in it um but you can also do other cool stuff you can do things like priv privilege deescalation where you sort of assign different subsets of your sort of account to different people based on the logic you give in that code essentially you can say someone that I know has a key that can only do certain things with my account not everything While others can do different things so you can imagine one of my friends could spend my usdc and the other could only spend my usdt or something like this um how we'd actually do this is you know subject to the code and we'll talk a little bit more in the future but keep all of these things in mind part of the reason I wanted to give this talk is not because this topic isn't uh already been covered by a couple of people it certainly has there was a great talk at Devcon for example by one of the authors like Lance but the other one is that we're at the beginning of build we carity Denver and honestly it's a hackathon so if you're looking for things to hack one of the things that would really interesting is figuring out ways to use ip7 72 set codes as um you know an interesting project and I think that's sort of the the moment to do it is right now before pectra Comes live but while the protocol is still you know relatively final and if you do this you'll be building into this sort of larger notion of account abstraction so um EIP 772 is one step towards uh this notion of account abstraction where we don't sort of need to know that the EA is in fact an EA rather than a multisig or something like this but essentially you know the etherum foundation uh or at least ethereum website uh defines account abstraction as um flexibility Flex flexibly program more security and better user experiences into the accounts and that's sort of what I said with batches and and sponsorship and uh privileged deescalation but essentially you want to be able to do stuff where the daps that receive transactions from the transactions don't know if it's an eoa or another smart contract and honestly they don't really care they just do what they're supposed to do and this is only one step because this is not quite native um this is in fact something you have to do separately through the set code transaction type that I alluded to in the last slide um and it's not uh Native in the sense that you still have to do this you would like to have full AA on ethereum or at least many people would um and this won't get us there but it will get us part of the way there and until we have that full all the way native account abstraction this is a pretty good starting point where we can start to get users um ready for the notion that they could have a smart contract wallet that can do some of the things that they would do maybe by default in the future so this is a really good stepping stone and it's important to note that uh this approach is not incompatible with other approaches towards account abstraction like uh EIP 44 4337 or um other things that have been looked at so if you hear all of these words this is one good starting place and this is again why I want to bring it up at this hackathon so you can start building something something that works something that's interesting and takes us in uh to the direction of of the future ethereum chain itself anyways so let's dive a little bit deeper into some of these use cases because I think the motivation is actually really really important and a lot of people gloss over it because this Topic's fairly old um in fact a has been sort of Hot Topic for two or three years if not longer and although 772 only sort of got draft status um last year I think uh you know AA has been around so let's look at some of the critical use use cases first batching I've already said the case of the ERC 20s with the approve and the spend this is I think one of the easiest things you can fix to get users on onto the chain most end users you know if they only come from web 2 or cash or VISA don't understand the need to approve they just go and they spend the money and it's all good doing this atomically would be very good you could you know alternatively not go down this route and require people to deploy their own smart contracts to do this but that's a real pain and that's why we don't want that um but you can also do things like trades you can also think of more critical sort of infrastructure upgrades so if you have a big dap and you need to deploy a new proxy and then initialize it before it's front run that might be really problematic if you can't do things in batches automically EIP 772 allows people to do this with the right code the next major use case I think is really really interesting is this notion of sponsorship where people will pay for your gas or you'll pay for someone else's gas um this is helpful I think for onboarding a bunch of people because now you can build apps where if you're willing to pay for you know the onchain costs of some users those users don't even need to be really touching um a kyc process or maybe they do I don't know I'm not a lawyer but they don't need to have ether in their account they can you know just have an account made an address and you can pay for their um their onchain transactions and this means as adap developer you sort of get closer to that web to seamless thing where you just say log in and everything just works and maybe you still need an address so maybe it's not you know 100% just click here and log in and there's no web three stuff but it's a lot simpler this also means that um infrastructure projects like zerit where we're building a rollup um Can sponsor their users to get people on on chain to do particular things or just anything we want so this is really cool and this is not limited to just eth right you can sponsor things um in other ways as well uh you could sponsor people's onchain transactions which are paid andne but you could say that those persons should pay you back in usdc or some other currency or offchain favors or whatever you want so I think it's really cool but the the list of use cases does not stop there um one of the next big use cases is the idea of enhanced safety what you could actually do is have part of your um account code talk to uh smart contract that will allow some level of social recovery that is you know if you lose your part of your key to that account um there might be a multisig attached where if you can go talk to the other people who hold you know that types of privilege or those types of sub Keys um they can say oh yeah actually well that is you know the person so I'm going to give back privilege to that account and we're good and that's really really cool because this is also another feature that scares a lot of people who aren't web 3 native right if you lose your private Keys it's over here maybe we can do better we can build it in a little bit more and that's really really exciting and this sort of brings to this notion of session keys and and revocability if you like those people and you want them to always have the ability to socially recover your account that's great if you don't you can also make it so that those keys and those privileges expire over time or you can revoke them and this means you can sort of do things like approvals that are a little bit more general not just for tokens but for actions and sort of General sequences of of things arbitrary code uh and then you can revoke them at certain time so this is really helpful for building out um different ways to sort of put yourself partially uh in the hands of someone else without giving up entire trust so this is really cool so I did say it was an introduction it's a bit technical let's go a little bit into it what the EA sorry what the EIP does is introduce a new account trans account type oh sorry a new transaction type and the transaction type is called a set code transaction uh it's built on previous work um EIP 22718 introduced the ability to new add new transaction types and so here we're building on that we're using it and that's not super important so let's keep keep going a little bit but essentially you get this new transaction and the transaction contains a whole bunch of things like this and I'm not going to go through every single one of these this is definitely helpful if you're going to try to implement some of these things on uh this hackathon or Beyond but um there's a couple things that are really really important I'll dive into so at a glance there's sort of stuff you'd expect a chain ID and a non this has to come from the people you know signing this transaction and submitting it on the right chain if that's appropriate um gas and all of that and then there's one really really interesting parameter which I've highlighted here in green and that is the authorization list the authoriz authorization list is actually where all of the magic happens for your I 7702 so let's look deeper into it the authorization list has um a couple things in it it's a list of of lists and um the inner list has a chain ID it has an address a nons and a y r and s so what those things are um is a way to set up other people's privileges for you to do sorry set up other people's privileges to act on your behalf and the chain ID and address are somewhat straightforward the chain ID should match the chain you're putting this uh this transaction on but you can set it to zero so it can be replayed subject to some sort of cave ances or caveat sorry uh and then the rest of it is a signature that actually comes from you so when you create this entry in such a list you sign it and you sign with your public key and you can recover this from the RNs values and then what what happens is the address there um is actually entitled to act on on your behalf and that's that's really cool now it's got to be nonzero and why it's cool that you can do this by just signing this entry is that this means someone else can actually submit this transaction for you you don't even have to pay for the transaction to set your account code you just need to sign the tupal here and it'll go through which is really cool some technical details has got to be non zero no surprise wouldn't be very helpful if it was Zero um but essentially what happens is that this we call this a delegation yeah Del delegation designator where we have um some ability to say that the code that's in that delegation designator will be run when someone else who you've delegated um wants to run the code and the person who you then allow to act on your behalf runs the code that you point to in this list and everything kind of just works out so actually you can load an arbitrary code there's smart contracts you can point to and it'll be copied in it's not quite exactly the same as normal deployment um you have to call an initialization call I think is my next slide um yeah you have to call an initialization after you put in a stuple but once this is done so you have someone submit this authorization list and then you have yourself or someone else relay the initialization the code that's pointed to at each address can be executed by the person you've delegated it to and this is really really cool because that's an arbitrary piece of code and so they can do stuff that you've allowed them to do which is smart contracts and that might be sounding really abstract I probably went too fast still despite my efforts to slow down um one thing that's really really important is that uh what you delegate the code to it should be what you want it to do and here's my call to action this is the main reason I want to give this talk at this venue rather than just a technical Deep dive of what's going on because I think other people have covered it better is that when I say someone can execute that code on your behalf I'd like to see some of that code and I was looking around for a while and I didn't see a lot of that code there are some examples I think coinbase has a couple um I think open Zeppelin is going to work on some I saw some tweets but I haven't seen a whole lot right now and there are test Nets out there that actually do support um EIP 7702 I forget on the networks but if you look around they are there so we should really be at a point where we can say I want to delegate my code to something that's well trusted because as someone who used to be a security researcher in this field I think it's very important that you don't delicate code to something you don't trust and the reality is the two or three or four use cases that I pointed to in the last in the first couple of slides of this talk are probably the most common and probably the ones that most of the people in this room and Beyond really want to see batching sponsorship and social recovery it's probably the biggest ones and yet we don't have standards for the delegation code to actually run them so I'd really like to see uh some ideas of how that could look um you know it's a hackathon come build some we don't technically have a prize for this at this one but if you do deliver anything good tag me or Dr Z on circuit and I'd happy to take a look um for reasons I'll explain in the next couple of slides either way I think this is a good project this time even if it's not quite as sort of you know sexy or on hype as AI or defi or other things because at the end of the day this might actually onboard people quicker than an AI that does something else but part of that concern is security um so the delegation of your uh account to other people or parts of it um is risky so you know this is the reason I want to see stuff early because if we develop the stuff early and then it fails well we can fix it for later users so let's get started um ideally we don't have any issues but probably we will uh nonetheless if you do start this be careful um if you delegate to a proxy contract it can upgrade itself now you're delegating sort of arbitrary powers that might be very desirable maybe you trust the person maybe you want the ability to update that in some way in other cases I'm guessing in a lot of cases you don't want to do that that might be very scary because the person you delegate to can arbitrarily update their code and then uhoh you've got to you know worry about if they can do something bad or something that you didn't want them to do um for now I would then re therefore recommend keeping the delegated code simple you know choose one action and delegate to different people different actions this way it's easy to audit this way it's easy to understand and this way you know what rights you're delegating away um I also think that we should practice and sort of work with the idea of removing delegation access um there is a way to overwrite that list so that delegation goes away and I think this is important I think in in the past we've seen a lot of hacks where people said revoke your approvals revoke your approvals I bet you're going to see you you know similar things maybe on a smaller scale about revoking delegated access either because the person you delegated to is not trustworthy or because the code that's been at that address um is problematic itself and then finally if you're building just any other dap out there um be aware that now with the introduction of VIP 7702 the invariant that um TX origin should be the message sender is no no longer going to hold so if you're using that to check if something's an eoa you're out of luck after AIP 772 you got to do something else so all of these things should be sort of considered um and this is the time to do it and that brings us to what we're going to do next with it so zuit is z knowledge rollup um if you're familiar with us great if not um we're a Zer knowledge rollup with some nice features and we're standing by to be one of the first to adopt 7702 as soon as it goes live um our new test net which is going to be coming out very very soon um sometime this week for sure possibly in the next couple of hours um we'll be going live and while I won't actually support um 7702 just now as soon as goes live on mainnet uh or sorry maybe not mainnet sometime very very soon we're going to have support for this um possibly before ethereum mainnet is actually what I'm trying to say and what this will also mean is that uh zerit where we uh zirc unique feature of sequence or level security where we actually look for malicious transactions to the network will also be adapted to look for malicious 7702 transactions so this will include um delegating things to people that you shouldn't be delegating or you know problems in that delegation code and that's really exciting it's going to take us a a little bit longer to get that online but honestly we're really excited and I think that'll be an extra level of security so almost out of time what's next well for 7702 it's got to go live um Petra is supposed to go live on Holi today uh I don't know if that's happened yet I haven't looked I was too busy practicing the talk uh on March 5th it's going to go live on seoa that's really cool uh at some point then on that day if everything goes well or shortly after that day uh people will decide when the main net launch of pectra will be and that will include um 7702 and so it'll come very soon probably a month or so after I think is what I heard so free IP 7702 if you have any comments about the technical implementations better get them in real quick because it's going live for ethereum the road to abstract uh uh account abstraction is not done here 772 is a great first step but maybe we still want 4337 or something like it in order to get native AA and that would be really cool there's going to be a lot of work here but getting used to 7702 C and then for you as an end user the call to action is twofold first come up with some good delegation code here at Denver I think that's really exciting I'd really like to see it and second as soon as networks particularly circuit start to deploy 7702 test and play around with it see what works see what doesn't work see what breaks see what doesn't break I'm not saying you're going to break the network but I want to see those delegation code things break when it's a test run not when someone puts a lot of money in it and we have to have a bad twitter thread and people calling for rollbacks of chains which is is not so great so for now play around be aware learn use that's all I've got to say so thank you if you have any questions about me 7702 or circuit come talk to me I'll be at a booth here or a table over there or hit me up on email or telegram or Twitter and check OD circuit thank you

Automatic transcript β€” names and jargon may be misspelled.