EIP-7702 on Ethereum and Rollups | Martin Derka, Zircuit | ETHTaipei 2025

[Music] Thank you everybody. Thank you the organizers for having me over here. It's an amazing experience to be in Taipei again. I very much enjoyed the last year and you know I uh always love coming here bringing the best content that we currently have. So I will be talking about Athereum EIP proposal 7702 uh by yours truly adoptive Mudang's father and some other people.

And this is just the excerpt from the EIP itself on the GitHub. I'm just really going to skip about it uh skip over it because I will talk about what is actually in the EIP a little bit later. So this talk is about 7702 and specifically it should give you some inspiration about what you can build using EIP702 because as I heard there is a hackathon upcoming in this town. So what is EIP7702? When I try to understand new concepts I always look at you know look at them and try to come up with some sort of a Martin digestible translation.

So here is Martin's digestible translation for what 7702 actually is and how you should think about it. Okay. So when I think about 7702, I envision this scenario. I am submitting a transaction. It's a regular transaction, the same transaction that you are submitting these days on Athereum.

It has some payload. It has some sender. It has some message value and so on. But for 7702 with this transaction you can submit an additional thing. You can invoke something that is called set code for some accounts together with this absolutely regular transactions.

Okay. So what is set code? Set code is this new thing that comes with EIP7702 and it effectively allows you to delegate the functionality of your externally owned account to a smart contract and this smart contract sorry this account will then start offering the interface of the smart contract and you will be able to call methods on it and anybody else in the Ethereum ecosystem will be able to call methods on it and then this account will start exe executing these methods but it will execute them in its own context specifically in its own storage. Okay. So whatever writes into slots we will have they will be actually writing into the uh EOA's storage but other than that that EOA it's still going to operate in the same way as it normally did before this CIP7702.

So there there will be a private account sorry private key known for this account. Somebody will hold this private key because they needed to sign that original authorization for the delegation and they will be able to invoke transactions out of it as if it was their externally owned account. Okay. So this is what is uh EIP702 how it is implemented in practice. So in practice we are actually using a different EIP.

It's EIP 278 which tells us how we can create new types of transactions. So with this 7702 we are essentially creating a new EIP2718 transaction and we give it a specific transaction type. It's going to be the constant four. Okay. So in practice that means that when you take this EIP7702 transaction you will get a serialization of whole bunch of stuff but really all this black stuff it's actually what was originally present in your very regular normal transaction.

All of this is present in all the transactions that we have on Athereum except this one part and that's the authorization list and this is the one thing where we invoke those set codes. So authorizations come in this particular format. It's a serialized list of lists and in every single authorization we have a chain ID and an address that a given externally own account agrees with becoming and the nons and then we have a signature of that account agreeing with this authorization and what we do during execution. So uh you know before we execute this very regular normal ordinary transaction we actually go through this list of authorization and for each such tpple uh we understand that the signer that's this Y parody R and S value this uh signifies that the signer authorizes this address to execute within the context of their uh EOA and then if anything is calling this EOA uh sorry then we then write the delegation designators into the uh code space for this EOA. So we give it some magic constant concatenated with the address and then if you are executing any kind of code that calls this EOA all code executing operations then know that they should sort of treat this as a pointer and load those instructions from there.

And as I said this all happens processing of these authorizations that happens before my very normal ordinary regular transaction gets to processing. Okay. So this is how you should think about uh EIP7702. So what is it good for? What could we build using such a mechanic?

I'm going to start with an example that I very often hear about uh and yeah it's a good example so why not so imagine that you would like to authorize somebody to spend some of your funds right now you can do that for ERC20s right they have this approval method uh there are also some um other primitives such as the permit functionality and so on not every token implements that so here you have the ability to allow somebody to spend funds from your account and that ability can come in multiple ways depending on how exactly you implement. So you can give them some constant amount of ease that they can spend one time or you can give them a constant amount that that they can spend every period of time or you can tell them hey you can spend up to 10% of my account and you can also use something like 20 tokens that seems pretty useful right because you can start developing new things with that you can uh you know develop some uh monthly contributions as I said you can give some allowances to various roles. We live in the world where we really like AI agents. So imagine giving an AI agent the permission to spend 10% of your funds every single week because that's what you want to do. You can develop subscriptions and so on.

However, you know, while people actually speak about this uh use case, uh I have never seen anybody showing any kind of useful template or even as example of this template that you should delegate into your EOA to achieve this. So this is it. This is how it would look. Uh you basically need to have two methods. One of them needs to enable you to record who are the people who are authorized to call this other method, right?

Who are the people who are able to spend funds from your account? You can notice in here I have a clever trick. Uh this actually uh let's read it out loud. The first line requires that the message sender for this transaction is this particular smart contract or this particular EOA that is here to make sure that nobody else know calls this function without you being aware of this. The second one is transaction origin equals address.

This that means that the co the call actually again came from this EOA. You probably want to add some entrance and whatever. But the goal is that in here you actually update who is allowed to call this other method. So this is some kind of ACL type definition. And in this other method, well hang on, you know, I talked a lot about spending 10% or 10 E or whatever.

There are no primitives that are ready to use for you. This is actually where you will have to code the function from scratch. So you probably will want to check that this message sender who is currently trying to spend funds from your account is authorized, right? But then you know it's kind of a double-edged sword. You have no primitives that are ready for you to use.

That means that you can make up any primitives that you would like. So you will have to do some accounting. You will have to invoke the storage of the smart contract record how much was withdrawn over time by the particular send spender and uh how much they are allowed to withdraw and you know only allow them if this actually falls within the bounds but this is roughly what you would do if you wanted to spend 10% of your funds. Well, here I have a gotcha. There is one thing.

There are actually multiple things in EIP702 uh where the EIP itself doesn't take care of them for you. The one that I decided to include in the talk as an example is the storage. So when we remove delegations from smart con uh from your externally owned accounts the obviously uh the obvious behavior that you expect here is if you are able to set some delegation you can also remove it right. So we remove uh delegations by overwriting them with empty delegations with like zero address. Well when that happens uh we actually do not clean the storage.

So whatever you would put into these storage variables inside of your EOA now that actually will remain there right nobody deleted it. So that means that we can have some surviving records if we then redelegate the account again and the user might not expect that. So in this particular example we have that spend methods and I have decided to add some mapping that says hey those are the you know spenders who are authorized. Well if you delegate this register some spenders then unddlegate this and then delegate this again those spenders will still be registered. So careful about that.

Another thing that could also happen to you is uh two different delegations. Let's say that at the beginning you delegate your account and you record this evil person who should never never never be able to allow to call this right. If you later change your implementation and you actually decide to at this very same slot encode the owner and then say holy only this person is able to call this particular method. Well then you clearly have a clash right? In one case you didn't want this.

In the second case, that's the only person who is capable of doing this. So careful about this. Uh careful with the trick. So since we are coming up with a hack hackathon, I also wanted to, you know, share a little bit of how I would do things differently. So here's my personal trick for separating storage of smart contracts.

If you want to, you can use something uh like a simple key value data store. So this is a smart contract, right? It just records mappings of strings up into some bite values that you can type cast to whatever you want and it has two methods getter and setter. Well, if you wanted to use it, you would use it somewhat like this. You would have a data store that would be a reference to this instance of the data store.

Then you would have some initialization step where you would always create a new instance and thanks to that then these gets and sets they would operate in the context of this new instance of a data store. That's a smart way of quickly quickly wiping out the storage. Okay, just waiting for all the pictures. Good. Cool.

But I want to go back to uh EIP7702 because there is actually much more cooler stuff that we can do with this. So uh as a motivating example uh I chose this this is another thing that I very often hear uh from you know various friends in the space. Hey, listen man. After this EIP7702, you know this like approve and use the ERC20 con uh tokens that construction is going to be gone. We will never ever need to use anything like that.

But that's a misconception. So let me elaborate. When you are using ERC20 tokens, you are somewhere here. You are the user, right? You are actually issuing two transactions to two separate smart contracts.

If here is your ERC20, imagine USDC under there or USDT. The first transaction that you're actually doing is this arrow and there you are calling a proof and giving somebody the permission to spend your money. Then you invoke second transaction and that actually goes to somewhere else. It goes to that somebody who you want to be able to spend your tokens. So here imagine a or your favorite D5 protocol instead.

you in fact send a transaction over to there saying hey I want to deposit some funds. So this smart contract on its own is going to reach out to this ERC20 token and call another method right. So if you wanted to simplify the life through ERC uh or EIP7702 you would arrive to a situation that looks somewhat like this. your account would become delegated to some smart contract and you would want in this smart contract to have some function that allows you to deposit into a atomically or you know in a transactional way. So this function itself would first call the ERC20 and then within the same execution it would call a and a would reach out in here and that would be a way how to make that happen without having to do a proof and transfer from as two separate transaction because then you or anybody else who has the privileges to invoke this deposit a method would just make that call on your EOA.

Okay. But here I'm going to argue that this is actually not what we want as a user experience. Imagine the universe that we, you know, definitely used to live at, we probably still live in where we have whole bunch of these D5 protocols, right? So you have a you have compound, you have unis swap and you can just keep piling and piling and piling. So you would probably want your delegated EOA to sort of be smart and be able to interact with any of these protocols, right?

But they are interfaces. They actually differ. In a you have something called a pool and you call method called supply. In compound, you have something called C tokens. When you want to deposit funds, you actually call a method mint.

And in unis swap you have some I don't know deposit LP or whatever or increase liquidity pair position and such. The point is every single one in this naive approach would probably need to have you know its own invocation method. And on one hand, this is a really cool idea because what I would really like to have for myself is this super cool wallet where I can just say deploy here, pull from there, deploy over there, and so and so on. But what I definitely do not want to have in there are all these pre-coded methods. What I would much rather have is one generic method that can interact with everything, right?

Because what would that allow me to do? That would allow me to essentially position the integration between D5 protocols from the level of smart contracts and EOAs to the level of front ends, which is exactly where this EIP becomes insanely insanely powerful. So what I'm saying in here is that we actually need some universality and batching. So here is this holy grail type method uh that I'm going to show you on the next slide is actually not invented by me but it's heavily inspired by the guys who invented the multi call smart contract and you can actually find some uh other examples for this somewhere else for example in Gnosis uh safe wallet. So this is roughly what this universal structure would look like.

Uh I'm going to encourage you to check the original multi-code code so that you can actually understand all those possible nuances. But in simplicity, you would have some data type that would signify a call. Here I am simplifying this to only have the target that's the two destination and the bytes that actually serialize the call data. Right? We know that we could have multiple options.

We could have u you know value attached to it. We could also care about whether this should fail or not and so on. So you would probably have like three or four such uh data structures inside of your template. But then in your aggregate function that universally executes these calls, you would just accept whole bunch of these calls and then you would do what we did before. You would, you know, first perform some authorization.

Let me tell you, you know, allowing any arbitrary third party to issue any kind of smart contract calls directly from your wallet. That's a really really bad idea without authorization. So some part like this you would probably want to protect against re-entry but then everything else it's just execution of the call through the primitives that solidity as the language and EVM currently allows. Okay, this allows us to interact with any kind of D5 protocol. So as I said uh you would probably want to take some you know security crack at it.

So uh first of all yes make sure that all those calls that are coming into the execute or aggregate method that they are actually signed because as I said you would not want to allow an external party to make up and craft calls that will be called on your account. That is a bad idea. You would probably want to embed in some anti-replayability measures such as chain ID so that if you sign something as an intention for one chain it cannot be replayed somewhere else. You would probably also want to implement some kind of a non-s system, right? So that you can guarantee the order of calls in which they will be executed.

And you would probably also want some global invalidation nons. If you realize, oh, hang on, I actually want to cancel all of these things so that you can uh do this. But overall, it's actually really strong, right? Because if you imagine that we have whole bunch of wallets in some ecosystem that are delegated to this universal executor, you can actually start do doing cool things. You can start building relaying services that will accept these calls, right?

these payloads for the invocation of the method and you can start like playing them onchain by funding the gas for the user and that allows you to abstract away a lot of chain complexity such as gas, such as transaction confirmations and essentially you move the entire user experience from the wallet and user signing and interacting you know with a D app through a wallet into web two space And I say that this is good because through decades and decades of internet, you know, as humanity, we have actually learned how to make pretty good uh user interfaces in web 2. I don't think that anybody is currently complaining about the experience that we are able to achieve, you know, in general in web 2. So this actually gives us the opportunity to let people spend more time in those apps and those crafty interfaces rather than signing their transactions and waiting for some processes. uh processing. As a side note, uh you know, I gave you this weird mixture of programming technique of some template of a different template that can be used for something else.

Uh really we are actually opening completely new chapter in the Ethereum space, right? we have a new way of transacting and while some other and original or more original ways of transacting were fairly standardized up to this point, this one has not yet. So if you also do not know what to do during this hackathon, maybe take a look at standardization, try to craft some EIPs. I think that that would be a really cool outcome for the hackathon itself. But other than that, EIP7702 is actually uh already available.

So you can also hack with it. It is available on the Ethereum test networks that have already upgraded to PCRA. So you will find it on Hleski, you will find it on Sepia. There is also a brand new test net uh hoodie. So, uh, grab some of those links and if you feel like it, do something really cool with EIP7702 to fulfill my duty.

EIP7702 is also coming to Zirket. We will have it live with Pectra. Uh, as far as the timing goes uh, of the call from the last week, this is currently scheduled for April 30. And all the transactions that will be played on circuit regardless of whether they are EIP7702 or not of course will be protected by our feature sequencer level security. With that I would like to thank you for the attention.

Please build something cool with the IP7702. Talk to me if you do otherwise have a great hackathon. Thank you. Perhaps we have some uh time for some question. Um, is there anyone wants to ask some questions?

It's giving out the Yes, sir. That's a long way to go. Oh, sorry. Let me let me go for this one first. It's just close.

Thank you. Hi, I'm sorry. My name is Kenneth. Uh this might be a very newbie question, but id like to ask uh for EIP7702, why did you choose to introduce a new transaction instead of uh working it off through a smart contract? Okay, so first of all, I didn't choose um the account abstraction uh topic has been around for quite some time.

EIP 7702 is actually not the very first flavor of account abstraction that has arrived to Ethereum. We also have the 4336 EIP. They are a little bit different. Uh they are made to sort of work together and operate together but it has been a longstanding problem that smart contracts in Ethereum and by the very uh like vanilla definition of EDM they just cannot transact. Sorry, they they can transact, but they cannot have this additional logic of code that always, you know, was meant to be zero.

And it was insanely prohibitive because while you can send a transaction to an EOA, it will never ever ever be able to deal with it or react to it or respond respond to it. It's just like this passive element up until the moment when some version of account abstraction shows up. So there are use cases that you wouldn't be able to achieve without it. Sorry, I I want to know about um if 7702 will be danger like permit to uh like um somebody allow uh somebody let you allow the uh attack contract. you you to uh you add the attack contract to you allow this too.

Mhm. Yes. Uh I think the answer is yes. Uh it's a little bit broader yes than just you know this particular instance. There will certainly be malicious smart contracts that will you know fish users to delegate uh their accounts to.

There will certainly be some templates that will contain bugs. There will certainly be you know like elements and aspects that the users have not anticipated for example the clearing of storage right that that is you know not so well anticipated so I think the answer is yes what exactly they are going to look like I think that we are still let's say waiting uh we know that this potentially can be dangerous the truth is if do nothing. If you never delegate your account, the security of it will not be impacted. There is nothing new that can happen without your explicit approval or signature or something like that. So, somebody will always have to, you know, fish you or make you delegate u a malicious smart contract or or do something that you know shouldn't have been done in the first place.

But if you do nothing then your account is going to remain exactly the same way and the safe uh way how it is right now. So um in my understanding the 7702 biggest risk factor is that actually it breaks uh a lot of trust might break some trust assumptions for uh other contracts which were pre-eployed uh which never expected EOAs would have a code um so and I've took a look myself and like we found some really like interesting cases on that so um for you as one who was looking on the security side of uh that standard how much of those deployed contracts already existing projects you feel you've analyzed and looked through. So there is actually a line about this uh inside of the EIP itself. uh somewhere there is a section that speaks specifically about the construction uh message sender equals uh transaction origin right that one used to be sort of used to uh detect whether we are at the top level of execution or whether there could have been you know some smart contract manipulation of state of the blockchain happening prior to the call and so on. So uh situations like this certainly might be broken.

I say might because uh you said that you know they should be analyzed and this is where I'm with you 100%. Uh I think it depends uh case by case even this transaction origin equals uh message sender it actually can remain a meaningful construction because it still signifies something right it still somehow restricts the execution. So um you know what I don't have a clear answer. I think I think that uh something certainly can be broken. If you are operating a D5 protocol, you probably should take a look into it.

I also have this you know secondary opinion that if transaction origin equals uh message sender was kind of the only thing that is protecting your protocol. Maybe the protocol has some you know inherent logic flaw or design flaw. uh so depends I think that uh people actually need to scrutinize it quite deeply and if needs be then exit those protocols that are now v vulnerable. Yeah. So I was like actually referring for not just origin but say transaction hash uh sorry bite code hash which in my opinion was absolutely secure to use and it's actually quite legit way and then yes and then it was actually one of the concerns.

Yeah that semantic also changed. That's correct. What feedback have you heard from wallet teams on the 7702? So I heard uh lot of feedback through the ears and mouths of our ecosystem team at Zirket. Uh the general number one item of feedback is that the wallets probably will not uh you know allow the users to sign blindly any kind of authorizations.

They will also care a little bit about you know what users are doing. if I don't know they are delegating to a general proxy that that's really unsecure right because the proxy can upgrade itself without the user knowing and so and so on so uh I think that the wallets will uh play fundamental role uh I think that this will be a little bit weird model where we have kind of an organized you know uh effort from multiple parts of the ecosystem and multiple levels of the ecosystem but I think it's for a good cause I think that it can produce something pretty Oh, thank you, Martin. Thank you. And let's [Music]