[trustless://interop.landscape] Workshop - Future-Proofing EOAs: Free EIP-7702 Infra Integration
trustless:// at Devconnect Argentina 2025 · 19 Nov 2025 · 44:12
Michael Messele, CEO and co-founder of Etherspot, and Nikhil Kumar, a software developer at Etherspot, lead a workshop on future-proofing externally owned accounts at trustless:// during Devconnect Argentina 2025. They guide attendees through integrating Etherspot's free, censorship-resistant EIP-7702 infrastructure SDK. Wallet teams learn how to reduce infrastructure costs, and dapp developers see how the infrastructure improves UX and adoption.
Speakers
Topics
From trustless:// at Devconnect Argentina 2025, hosted by Account and Chain Abstraction.
Transcript
If they were to censor us and think of the situation I've I've mentioned with the hack defy protocol and how it was mitigated by the various parties then would it be too far-fetched for me to say the jurisdiction can say to us use whatever mechanism you've used to mitigate this and censor this wallets for me. In fact, I will give you an even more not so far-faced scenario where a certain jurisdiction can say to us infra providers give me a list of all wallets from this geolocation positions from this country, that country and that country and take those say 10 million
wallets and go to the stable coin providers. Guys, for these wallets, can you freeze all the stable accounts in their wallets? That's why we have to be wary of centralization. That's why we have to increase our commitment to building trustless solutions. And the censorship comes so long with that. As much as those entities can do that to us, then if we're not going to be able to have alternative solutions, is the ecosystem going to end up being the efficiency layer of tradfi or fintech 2.0?
That's why we have to increase our commitment. So this infrastructure that we have the EIP770 auto infra number one it is free courtesy of the Ethereum Foundation. Number two it is so easy to integrate with VM library. Number three it is built on the tried and tested ERC 4337 infrastructure. There is more to it. There is more to it because it uses the shared meool. Shared meool is built on gossip protocol. What it means is when you have one user operation in in the meool, it will be shared amongst many mempools and that automatically gives you
redundancy. eliminates a centralized point of failure. And quite a lot of our clients, especially mature web 3 projects, have been asking us and and institutional clients as well, have been asking us lately to have an service level agreement SLA with 99.9% uptime by us using the shared mepool. We easily can achieve that because we eliminate ourselves being the centralized point of failure. There is an added incentive. We have censorship resistance. If a certain um regulator or or or jurisdiction says I want you to censor this this this wallets and this bundlers and as a user I don't care I
can spin up a bundler in this opensource shared me pools and process my own transaction. So it is quite important. It is important but the shared meool has been out for over a year. The adoption has been slow. So it is a worrying point that we might be walking sleepwalking to a centralized disaster at some point. and wallets that use the 7702 to enhance their usability but used a centralized bundler, they're taking a backward step because you've got an EOA, you're chokeolding it into one bundler.
Even worse, those wallets that use real layers, their own relayers, which are centralized in nature as well. And the this infrastructure is available will be available on seven chains and it has a 24-hour support for any developer or projects that integrate it. You will get 24-hour support and we have right now it's rolled out on three chains Ethereum, Optimism and Arbitum for free and a few wallets that have integrated it. So I will show you quickly show you a video just a short video where one of our partners one of our partners the pillar X from
pillar wallet have integrated the 7702 infrastructure. In this simple use case what it shows you is they upgrade the wallet. it takes not long and to use 7702 then you can see the EOA being used to send multiple transactions to multiple addresses in this case one uh to a distinct address using USDC another one sending it to another address both of them sent on an EOA and you can see the transaction then going through it scan and it scan now do have a new tab that shows 7702 transaction. So, this is just showing you how simple it is to use
7702 for your EOS and have an enhanced user experience. Now, when I show you this simple use case, think of the more complex things you can do, not just batching two transactions, you can do a whole lot more as a wallet. So my section is making the case for why we should use 7702 infra and my colleague Nikl will take us through the infrastructure of this 7702 infra and takes us through code use cases. So thank you take it over.
>> Yeah thanks Michael. So yeah uh this is Nikil. I've been working at Etherspot as a backend engineer. So I'm here to speak about the technical details of 7702. I'm here to speak about the technical details of Can't hear. >> Hello. Hello. Is that better? Hello. Hello. Is that better? Okay. Thank you.
Yeah. I'm Nikil. So I'm working at Etherspot as a back end engineer. Uh so today here I'm to I'm here to speak about the technical details of 7702. Uh which involve how do you sign authorization? What does it mean to sign authorization and uh what are the various steps involved when one has to send a 7702 user operation in specific and uh most importantly introduce you all to the Ethereum Foundation's new bundler infrastructure which is built on it which is built using entry point 9 which uses entry point 9 and introduce you all to that infrastructure and uh you know discuss what are the various steps involved to make use of this free infrastructure And uh a few key key
points to highlight on the infrastructure is that it's 100% free to use. You do not need any API keys or you do not face any rate limits while you use this infrastructure. So it's 100% free to use. Uh so yeah, we'll be we'll be we'll we'll run a few user ops during the workshop to understand uh uh to get a feel of how the 772 user operations work. How do you prepare 7702 user operations? how do you sign and how do you make use of this infrastructure to you know uh send transactions for free. Uh so yeah that that's the whole agenda for this uh workshop. So yeah uh let's let's get started. So uh over here I have a flow diagram which gives a good understanding of what 7702 is uh and
also it also gives a gist about how the Ethereum Ethereum foundations bundler infrastructure architecture is about and uh how does the infrastructure uh responds whenever there are incoming 7702 user operations. So that's what this whole diagram is about. So assume that we have a EOA valad connected to a DAP which is which does not yet have the 7702 capabilities. Now the first step in any 7702 user operation is that we sign the authorization. Now what does sign authorization mean? The sign authorization means that you are uh allowing a already deployed smart contract address to delegate to it. So when you as soon as you sign the
authorization for this particular smart contract address which is already deployed that means the EOA is now no longer a regular EOA it becomes a delegated EOA. So it's all of its characteristics can now you know take advantages of a smart wallet. So it's like it can make use of you know EOS can with sign authorization EOS can make use of you know uh advantages like you know batching the transactions making use of pay masters and things like that. So effectively and a delegated EOA becomes a smart ballot but also be a EOA at the same time. So that's what sign authorization means. And how do we sign authorization is that we would need three things to sign authorization. The first thing is the nuns to which chain
ID chain you want to connect to. And the second thing is the delegate address itself and the third thing is the uh chain ID nons and the contract address. These are the three things you would need. So once you sign the authorization we get the uh you know RSV fragments for a ECDSA signature. So after that the second step is to you know compute the 7702 O tpple. So that again consists of all of these things the along with the RSVP signature. So that's what we call a um you know 7702 ospple. Uh and that's what the bundler recognizes that this is a 7702 delegation call. So as soon as this is done we prepare the user operation along with this uh 7702 ostpple and once the user operation is prepared you we get a hash out of it and
then we you know that's just the regular 4337 flow we sign on top of the user operation hash and then that is sent to the bundler using uh ecore send user operation method RPC method uh so yeah once once that's done the bundler recognizes that there is a odd stuple over here and uh uh you makes a type four transaction. So now what is a type four transaction? Type four transaction is something which includes a field called authorization list. So this is basically you know uh a different version of you know the 7702 ostle which can have like multiple EOS and which specifies what EO is delegating to what.
So that's how the whole delegation setup happens and that's how once the transaction is relayed on chain the uh you know the actual actual operation what the EOA wanted to do as well as the delegation both of them happens in the single transaction. So that's how the whole you know 772 user user operation work. So now uh whatever I explained so far is is if it is a standalone bundler the bundler recognizes that this is a you know delegation call and then 7702 user op and then it relates to the chain but what happens with Ethereum foundations bundler infra is a little different because of the shared meool architecture that it follows. So Ethereum foundation bundler
infrastructure has like two components for it. So the first component being a proxy layer which is a which is again a bundler node. So what does this proxy layer do is uh it it it accepts all of the user operations that's coming it coming its way and it would validate all of these user operations and save it to the meool and relay it to the connected bundler peers. So it's like Ethereum foundation bundler infra is not any other standalone bundler but it has the capability to you know host a network of bundlers which are connected to each other with P2P which uses gossip protocol of course to you know uh relay the user ops safe and securely to the connected bundler peers. So that that's why it's that that's how the Ethereum
foundations infrastructure you know uh eliminates the uh single point of failure risk also also it increases the robustness and effectiveness of your user operations getting included on chain easily. So yeah that's that and then uh once this you know proxy layer accepts the user operation they are then relay to the all of the connected bundler bundler pairs and all of the connected bundler pairs would then again you know send it to the chain. So that's how this works and that's how this is censorship resistant also because the proxy bundler which receives the user operation does not bundle it and attempt to send it to onchain. This is because we need all of the participating bundler clients to have a fair chance to send
the user operation to the to the chain because of course bundlers also have a certain certain fee cut for the uh you know user operations which they rely on chain. So it there needs a fair chance for all of the bundlers connected uh in this you know P2P network. So that's why the proxy proxy bundler does not relay user operations on chain. It only validates it and relays it to the rest of the peers and then the rest of the peers would then again compete each other to you know relay it on chain. So that's how it's censorship resistant. Uh so yeah uh that's all I had for this slide. Moving on.
Yeah. Uh so how do we how do we integrate this whole infrastructure? Uh the infrastructure is great but then again how do you what are the next steps to you know integrate this? So Etherspot has provisioned a SDK called Etherspot free bundler SDK which has a function called create free bundler which would create you a bundler client uh similar to you know the public clients or the pay master clients whatever we create from. So this is just an extension of VM library and also it's not it's not really mandatory to you know use etherspot's free bundler SDK itself to to have access to the infra even without the SDK you can still have access to the infra it's just that etherspot has provisioned a bundler SDK to you know abstract away the difficulties of
creating the bundler client itself that's all uh and as you can see over the code here uh there is a there is a function called create free bundler and then using this you would get a bundler client hack all you have to pass in is the chain VM chain definition to which chain you have to connect to and like Michael said earlier we support currently like six chains arbitum sepoleia and ethereum mainet along with their corresponding test nets so these are the six chains which are being supported currently and in the coming few weeks there will be more chains added as well uh and yeah this is how you create the bundler client and also one more interesting thing to note here is that uh you can optionally you know uh extend this client and to use for RPC actions as well. So it's it's not just
the you know bundler client RPC but it's but it can also be used that used for your regular RPC no RPC actions as well. So it's like uh you do not have to have you do not have to maintain two different URLs with one uh you know uh with one URL one RPC URL you'll be able to manage all of your actions all of your bundler actions as well as your RPC actions. So that's what this means. So yeah moving on So how do we send user operation after creating the client itself? So once we have the client um there is a once you have the bundler clients it's it's straightforward. If you can have a look at the code over here. So what I'm doing in the first step is that I'm checking
if the if my EOA account is already delegated. If it's already delegated then I do not have to sign authorization because sign authorization to delegate your EOA account to a different address it it takes certain gas it's it's 12.5k gas I think uh gas units. So it's like uh 12,500 gas units you you would have to pay for that gas. So if it's already delegated then you then you do not have to sign authorization again because it's already delegated. So that's the check I'm doing over there. So I'm checking if it's if the if my sender code is already delegated and uh the first marker which you see which is ox ef0100 that's the 7702 initial marker. So if if
any eos ea is already delegated that would definitely have that marker uh you know appended appended prior prior to its delegate address. So if that contains that code then you do not have to sign authorization. After that you just you know call uh dot send user operation using the smart account client. I'll get to the part wherein how you can create smart account clients later and then you specify your batch of calls whatever you want to do and then that can be multiple in this case there's only one but that can be multiple as well and then you get the user of a hashback. So yeah so yeah now I'll be uh you know doing hands-on. So these are the links that you would need. If you want to you know follow along then you can you can you
can you can use this. Uh so yeah this is the documentation link. The first one is the documentation link which is uh which is on which is hosted on docs.c437.io and then uh there is a GitHub example where wherein it has various account specific 772 examples. So it's on my personal GitHub it's niclumar 1612 and you will find a repo called 7702 examples over there. So yeah I'll be opening that. relition And one of the reason we do that is provides much better
way. Okay. Um, so I'll I'll first I have the documentation open which is on uh you know docs.4 PRC4337.io you will you'll find a section called 7702 user op guide which will have the necessary guide to you know >> put the the slides links again just for
taking a picture and follow on. >> Yeah sure. >> Thanks. >> Can you put the slide links again? >> Okay. >> So they want to take pictures. >> They just want to take pictures. that you are executing on. >> Oh yeah. Uh I have the documentation open. You will find a section called 7702 user of guide which should which should have uh which should have the necessary information for you to get started. As you can see I uh there is the first step is to install the ether sport free bundler SDK. And by the way,
in this workshop and this in this demo, I'll be showcasing uh how do you access, you know, Ether Ethereum Foundation's free bundler infrastructure via the Ethersport free bundler SDK. But uh you can you can even choose not to use you know, Etherspot free bundler SDK and still have access to it. Uh so yeah, uh it's so the SDK supports both npm and bun. So you can use whatever you are comfortable with or whatever your project fits best. Uh so this is the installation step and then uh I I have the repository cloned as well. Uh >> yeah this is the repository which contains 7702 examples. So I have it cloned already. So I'll be opening that.
>> I think it is actually possible to do it in a very >> yeah if you if you have cloned this run npmi to you know install dependencies after that you're good to go. Uh so I'll I'll just create a new file called test.ts just to run a few examples whatever is there on the documentation >> um >> so yeah so the first thing is to you know get all the supported networks so what what networks does you know um the infra support so to get to know that I'll just copy over this >> past this and the second one is to you
know get the bundler and the RPC URL for the chain which you want to connect uh copy over this question. I want to share my personal experience. >> I'll just add logs from other people experience. So we had a need to move some of our one to another and we decided to use a crosssection. So we tried a small amount. >> Yeah. To run this, I'll run uh npx tsx uh src test.ts.
So as you can see these are the chain ids which are uh you know supported by the infra which is uh like we already discussed it's Ethereum mainet it's uh optimism arbitum se arbitum seapoleia seapoleia and the optimism seapoleia and notice that I don't know if you can see this is this better yeah so notice that you can see a uh see the RPC URL over here so this is where this is the RPC URL which you can use to you know connect to connect to the bundler as well as your normal RPC action as well. So this is basically the URL >> I did.
>> Just ask them if they can see it. >> Yeah. So this is the bundler RPC URL which you can use to connect to connect to the bundler. Uh moving on. >> Uh how do you create bundler client? I'll copy this piece of code over here. Uh common clients. So this is basically how you create the common client. You have the uh create free bundler uh utility function from the SDK. I'll use that. And for chain I would say uh >> hanging somewhere in the middle and not very experience right so
>> I'll import the chain to which I want to which which I want to use now. And you know, >> I'll use optimism sepoleia for uh for this demonstration. >> Um yeah, I'll be using that here. >> We chain and then uh notice that I'm extending this valid client to use, you know, uh to make use of it for all of my public actions as well as valid actions. So yeah, this is how you create the common client. Once you have the common client, we'll next see how to send the user operation itself. Uh also just to show that uh this client can be used for
both RPC as well as uh you know normal bundler actions. I'll create a function main >> and then I'll say >> piece from perspective >> supported entry points >> then say common client dot >> get block >> get block number maybe yeah start log PS
then the block number so notice that I'm doing two actions over here one is one is a bundler client action the and the other one is the normal RPC action so since the you know the hosted network the hosted infra supports the common URL supports for both you know RPC and bundler actions I should get the result for this uh I'll call this function again I'll run it the same way yeah as you can see these are my you know supported entry points and uh this is the block number which which I which I get now for uh you know optimism seleia uh moving on So the next step is to you know
construct user ops and understand how do we send user operations itself to the next section. Uh so so from a implementation standpoint there are three steps that you would have to follow whenever you're uh you know trying to send a 7702 user operation. So the first thing is to create the smart account client. In this case we'll be using the u account abstraction simple 7702 account uh which is you know fairly easy to use. So we'll be using that in the example. Uh, okay. I'll just copy over the function here.
>> I'll just have this commented because I don't need them anymore. >> So, this is how we create the smart account client itself. So, >> then I I need to, you know, have the owner. I'll get that. curious to know about you >> and I'll guess >> as hex.
>> So I'll import the env package so that it can read from my env. Can I ask a question because like I doubled with uh 7702 uh before and the issue that I encounter is that you always have to uh use a private key account to sign the authorization. I I you cannot use like there's no JSON RPC method to sign. Is it still the case? >> Yes. Yes. Yes. Uh actually there is a reason for that case also. Okay.
>> There is a there is a reason why you know JSON RPC accounts do not allow sign authorization. >> Yeah. Because ultimately anyway with Ethereum based ECDSA signatures it's anyway you are signing a hash at the end of the day be it sign type data or be it personal sign or be it sign message you ultimately you would end up signing a 32 bytes hash but uh you know with sign authorization there's a security risk because you know like the attacker DAP or the DAP which you are trying to you know connect to might you know deceive you by giving you a hash which you can sign if you sign that hash that can be used for used to delegate your EUA account. So that's the main reason being why you know it it's not allowed on the
UI that you sign authorization but it becomes at the same time it becomes valid specific implementation like let's say you are using some some valid that valid would know that if I want to use 7702 that valid would know to which account I have to delegate it to >> so it would internally sign on behalf of you but it's not presented to the user. Yeah, exactly. Because like I've I've seen that like with u 5792 the wallet send calls uh namespaced uh the wallet namespaced uh ERPC RPC methods like wallet send calls the implementation of how to batch multiple calls is left to the wallet and for example MetaMask has is actually using 772 but it's doing it as part of the
wallet. It has my keys. It makes me sign like you know I'm making an RPC request to the wallet. The wallet internally uh process it and say oh I need to make the user sign this thing. But like this is a walled garden because like first of all it's left to the implementation of the of the wallet like you know your mileage may vary depending on which wallet are you using and then it makes them more powerful. I said I um I cannot basically build a web app relying on the fact that the the um you know 772 will be used or not like I actually want to be purposefully build a web app that leverages 772 but at the moment because of the absence of the
sign authorization uh uh method I cannot right so I don't know basically I don't know how to get around these things I I don't want to hijack the thing. Maybe we can uh Yeah. >> Yeah, we we'll maybe connect later because there's only 10 minutes. >> Yeah. Yeah, absolutely. >> We can connect later. Yeah, that's >> the moment. >> So, yeah. Uh moving on. Uh how do we send uh you know the user of itself? Uh I was in the middle of copying you know the private key and things like that. Some import issues. I'll do that. Uh and then so this is this is how we create a smart account client. So in this case you know we are using the two simple 7702 smart account you know uh utility
function from the VM itself which which will give you the smart account client back uh and after using this >> question is like right you will these risks the question is like will people care and maybe right now >> yeah so the next step would be the same thing which we discussed on the slides >> this see if there are port issues more intelligence or something but you know I don't think the >> yeah that's all so uh this is how you you know send the user operation I'll run this now >> try and hope for the best and works and
if it doesn't then >> well >> I think I'm missing my private key over here I'll just grab I have my private key directly in this case. >> Yeah, it's add this private key here. >> So, as you can see, this is my valid address which is which is you know both my uh smart valid address as well as my EOA account address. So, this is the user operation hash which I get back.
So, I'll I'll try now and uh you know open this on the explorer. you can upgrade your contracts and we first and foremost we want these risks to be >> so if I can head over to internal transaction you can see that there was a transaction 14 seconds ago so this is basically using the uh Ethereum foundation's bundler infrastructure actually it went to the RPC node and one of the connected bundler peers took that transaction and relay it on chain uh so yeah that's that's how you do it uh and then moving on to the documentation section so yeah if If you if you want to have your uh 7702 user operation sponsored then what are the you know extra steps that you would have to take care. So
I'll be speaking about that now. So all of the steps are still relevant even if you want to have it sponsored. The only extra step would be to you know create a pay master client. When you when you are creating a pay master client uh you would have to you know add the pay master URL. Of course uh now there are I don't think there are any pay masters which is supporting entry point 9 given the entry point 9 is very you know very recent but once we have pay master supporting entry point 9 we can use the pay master URLs here and create pay master clients and then all we have to do is uh you know during the send user operation just add the pay master related details here and then you'll be able to sponsor your uh 7702 transactions as well. Um so yeah if you
if you guys want to you know like try out the stack blitz also we have stack blitz uh integration also over here. If you can open this this should you know like uh clone the free bundler SDK repo itself which is uh on this uh GitHub over here. Uh I don't know if I have it open. Yeah, this is here. So this is the free bundler SDK uh you know whole repo which which has an examples folder and a you know like a usage MD file also which you can use which gives you like a minimal command line terminal which you can use to you know just just try out 7702 user operations. So yeah that's that's one way that's another way of you know trying uh 7702 user operations. Okay. uh
>> and then moving on now uh I'll speak a little bit about account specific examples in the in this example whatever we see here we had a u utility function from VM so that you could use that to you know create your smart account client but what happens if you have your own custom valid implementation because all validot implementations are not the same uh they behave differently like the signature schemes may be different the way you sign user operations might might be different so how do you do it if you have a custom uh you know 7702 valid implementation. So I have a few examples on my repository over here. Uh for the sake of uh you know for the sake of this example I'll be choosing AMware over here. Uh I'll head over to send.ts here.
So yeah, I'll try to give a walk through of uh you know what are the various steps I took to you know make it work for uh the valot which I've chosen here because uh you know VM inherently doesn't give you a doesn't give you uh you know two smart accounts for all of the valid implementations. So what I had to do over here is I had to create a uh you know smart account client myself by using two smart account uh VM library you know utility function from VM. So when you are creating a smart account client for your custom valid implementation, you would have to specify all of the fields needed like the entry point. This is the new entry point address by the way. And then I'm using entry point 8 AI itself because
it's still compatible with entry point 9 also. And the and then because just to be type safe with VM because VM doesn't know anything about the entry point 9 now. So that's why I'm reusing the entry point. 8 and over here also I'm specifying the version entry. 8 because VM doesn't know anything about entry point.9 currently. So just to be type safe I'm using entry point.8 and then how do you encode calls? Uh that's basically what goes into the call data field of your user operation. So that's that. How do you encode calls? How do you batch transactions for your uh particular smart account implementation?
So that would have this details and then decode calls you know it's just the opposite of what encode call encode calls. encode call does and the authorization like your private key account which you just created and then the implementation address itself. So this this is the address which holds the you know uh the implementation details for your uh 7702 account and then how do you get address because this is a 7702 account. Uh the EUA address itself will be your smart wallet address also. And then how do you get factory ars? This goes into the uh init code section of your uh of the user operation strct. And then how to get sub stop signature? Stub signature is something which will be used during estimate user operation user operation gas call. So this is the stop
signature which will be used. Uh and then how do you sign message? All of uh all of the details uh in this case it will of course be using the uh owner private key account. And then how do you sign type data which is 712 signatures. How do you do that? And then the sign sign user operation itself. So I convert the user operation to packed user operation uh to be compliant to be you know u compliant with whatever is there on solidity and after that I'll get the user operation hash back and then uh you know I'm decoding it because because of the valid implementation which I have chosen this this is all specific to the valot which I've chosen now and then I get the 712 data uh for the user op and
then I sign the signature and return it back. That's that's the implementation for sign user sign user operation. Uh and then yeah rest of the rest of the steps remain same. You check if it's already delegated or not. If not then sign authorization and then uh hit send user off. >> Uh I'll try to run this now. designed solutions so that you can >> so yeah as you can see uh previously I used the same account to you know uh use a different thing so that's why you can see the uh you know the authorization over here for some reason it failed
let's take a look uh If you can provide that protocol and what about I want to actually it's not just a nice >> I think I think uh there is a mistake on the delegate address which I used over here but you get the idea. Yeah. So that's how you you know use account specific examples to you know send user operations. So yeah uh that's all I had and moving on to the slides back uh I had a slide on dos and don'ts of
the uh you know of 7702. So basically it it all comes down to the valid because they are the gatekeepers for your you know uh 7702 delegation. So it becomes very important on which valid to trust and which delegation address they choose. And then the storage collisions the smart contract developers for 7702 implementation it becomes important because the address space is same because it's the EOS address space on which all of the code resides and the uh storage resides. So it's it becomes important for you know uh valid you know smart contract developers to have uh actual logic or implementations [clears throat] in place such that the storage stoages between multiple
delegations do not collide and then the broken assumptions like tx origin should be equal to message sender that's those are no longer uh relevant. >> Uh >> any questions? >> Yeah do you do you guys have any questions? I can take questions now. Thank you very much. >> We will answer your question offline. >> Yeah, we can. >> Yeah, you can just take it off and sit down.
that is also I guess we can continue on on what I was saying earlier like the biggest qu bigger question is like how can we use this in a web app essentially because like in a web app I'm connecting my wallet through you know the wallet connector for example and through that I cannot sign the authorization right >> uh this is this is more of a implementation detail for you know valid developers itself like let's say if there is some other XY Z valid which is a browser plug-in over there and how do they you know sign authorization and then send 7702 user ops. Uh if if you are like if your web app is relying on already existing Chrome plugins like
MetaMask and all of that then uh this this does not become relevant to those because MetaMask would you know have their own procedures or things like that to you know send transactions. So if I add to this ultimately 7702 brings a risk in that imagine you are a DAP and you say to me can you delegate your account and it could be a malicious DAP. So for that reason when 7702 was approved it was decided the wallets would be the gatekeepers so that a wallet would say unless we've got it on a white list we cannot allow any smart contract to be delegated to. So obviously that brings the issue you've
raised I think is it um EIC 59 >> 5792 yeah wallet send code >> exactly you can check with that so if you're a DAP you can check is this EOA or is it smart account because basically when you have a 7702 wallet it satisfies the smart account so it becomes onto the dabs on basically to have a fork EOA smart account other than that until we get enrined if if [laughter] this is opened, every EOA is going to get hacked. Think of the calamity.
>> Yeah, I I get it. Yeah. It's just that as you said, they become the gatekeepers. And so, >> yes, >> um >> they become the gatekeepers. At least what we are arguing about is do not send it to centralized bundler because you're bringing the EOA to a centralization and you are introducing a new risk. At least [music] put it on the shared main pool. That's what we're arguing. So yeah, I mean I guess all I understood even the security concerns which are yeah valid but ultimately like what is your advice if I want to build a a web app that because I'm actually doing it we're we're doing it with pose we're batching multiple calls and as of now we're using
just ERC437 but it's a pain in the butt because you need to move funds every time like this is to me this is the solution >> but as a developeractly I cannot use it. >> Yes. So basically as it's for for people like us we have to evangelize the wallets to adapt 7702 whether they use the shared mele or even a centralized bundler at least in terms of usability it would address your concerns because >> it's just a like in the specific case where on on a test net right so I cannot go to metam mask and say hey please can you deploy your delegation uh toolkit on my scrappy rollup it's going to be alive
for another two week before we tear it down like you know what I mean so the whole thing that we're building is ephemeral by nature and so basically >> because of the wallet gatekeeping um I cannot leverage this right you know what I mean >> yes I mean not this specific infra I completely agree with you so when you you talk about the metamas they would only allow you whatever they've rolled out >> yeah or or I'm talking about metamas but in general you know >> so so What we are trying to do is we're trying to get more and more wallets to use the shared main pool. As soon as they do that, then it would be available in all infra supported. Otherwise, as you said, it would be up to that wallet to say, are we going to deploy our
infra? >> Mhm. >> So, I do feel you I do feel the frustration. >> Yeah. Yeah. It's I think it Yeah. Yeah. It's just a it's it's in a way it's it's a valid problem but it kind of separate because for me like my problem is the sign authorization bit right like because as you said it like for security reasons it's like demanded that the wallet do it but like I have to go through them >> yes they're the gatekeepers yes >> of 772 no doubt >> will they remain in European like should they remain >> when we get to 7701 if one >> gota >> it would be protocol level. No one is the gatekeeper. You don't use the oneless this and that.
>> 701. >> Yes. Okay. >> So that would be the ultimate aim to enshrine this into the protocol. >> Is there a road map for that? Did you know? >> I think a couple of years or so because it would require a hard fork. >> Oh, okay. >> So the whole point is trying to avoid the hard fork >> unfortunately. No again. Okay. >> All right. Thank you. Thanks. >> Thank you so much. >> Good job. >> Yeah. >> Thank you.