L2 Interop Working Group #14

Transcript

ENS-Based Chain Registry Update

All right, welcome to the L2 interop working group. Uh we have a few things on the agenda today. Starting off with updates and discussion on the ENSbased chain registry moving over from the GitHub list which is something that has yes been in the works discussion for a long time now. Um and I think we are finally making good headway here. So anyways we can we'll talk more about this and unruggable wonderland many others have been contributing to the discussion here. Uh agenda item number two is some uh work happening around multi-proving on the L2 side and accelerating the uh eventual shift to uh getting rid of the 7-day windows

pragmatic fast finality. Vitalic wrote a post about this a while back. It's linked in the agenda. Uh and then last up is uh presentation and discussion on permit 3, some recent work from Echko. Cool. Starting off uh with Martin whenever you're ready. >> Great. Hi everyone. Uh my name is Martin. I'm from Unraul. We're an independent R&D firm within. and uh yeah we've been working on the onchain registry as part of the broader uh interal proposals. So let me take it back. So uh ERC7785

proposes u the derivation of a 32 byt chain ID and it also proposes that a human friendly name for that chain that is um something like base.2.f Earth uh resolves to this specific chain identifier. So we've been working to validate this and uh we've built uh a proof of concept uh that works with ENS uh that is ENS compliant and has you know it's it's brought out a few things. Uh I'd like to I've sent you the link right now. Uh you can check out that demo. I'd like to maybe just go

through the process of registering one chain while I share my screen. Uh just to take you through it all and then from there we can discuss what it is that we've you know we we've concluded from this validation that we've done. So let me just share my screen. Okay. So um to start off the ERC proposes using several attributes that will be hashed to get the chain identifier and that is what we have here on these fields. Uh we can have the

chain name like uh maybe let's work with optimism. Uh we can have the settlement chain ID which is Ethereum. The chain ID is going to be one. Uh the version is something that the chains themselves decide. Uh roll up contract. This is where the the L2 state anchor where it lives on the L1. And then uh the name space. Now these are attributes that are coming from kite and um EVM chains are basically categorized as EIP 155. And then the chain reference in this case will always be the chain ID. So for this case optimism it's going to be 10. Uh based on this EIP 155 um name spaces it

will automatically derive a coin type which is used by ENS to resolve to different addresses. So I'm going to just simulate this call. It's going to fail. Reason being we already have an optimism that exists. So what we can do is uh we can just do an optimism 2 and then change the change the chain ID. We can simulate it and now it gives us the 32 byte uh chain identifier. So, I'm just going to go ahead and um I'm just going to go ahead and try to change this um to register this and then uh we can move

on. I hope you can't see my wallets. Um there we go. Okay. So, let's try this. Okay. Fine.

So that's going to create that's going to register our optimism 2 chain and it's going to derive the chain identifier that ERC7785 uh specifies. So once we have this uh we have two contracts in this architecture. The first one is the registry that's going to store all the information that we just put in and then we have a resolver. Uh if you go to assign now here the resolver's work is very simple. We use optimism 2 which was our chain name and we assign it to the chain ID.

We can check if it exists, it doesn't. Uh and that's really the process. You first register it in the registry and then after that you assign it in the resolver and then that's it. You should be able to resolve this name to its chain identifier and its chain attribute. So this this is how we will be replacing the uh centralized list. Uh let's just wait for this to go through. There we go. And if we go to resolve and we want to check what we just recorded here and we resolve the chain, we're going to get back all the information that we had put in uh while registering this chain. So you can see the name,

chain ID, roll out, the coin type was derived automatically. So that's just an overview of how we going, you know, we would register a chain and how we will be resolving it to its 7785 uh chain identifier. Um, one thing to point out is that as it stands, ERC7785 does not use the attributes that you see here. These attributes have been modified to include uh mostly the Skype 2 attributes uh mostly because of its connection to another standard. So anyone who's really interested everything is on this land

page the original proposal the spec code for the registry um the kite 2 aspects and all the other resources. Um yeah, what we would like most feedback on is the the actual update for the spec, the ERC 7785 spec and just general feedback on the registry architecture. Um yeah, just those two, the spec and the registry and the architecture that we've put in there.

Yeah, thank you. >> I'll take any questions. >> Thanks, Martin. Any questions? We can also >> Yeah, go ahead. Sorry. >> Uh actually, oh yeah, I actually have a few questions. So, uh the first one is the settlement chain ID. Uh isn't it better to use the resolved ENS name or the hash instead of the chain ID because so the issue is right now that we have chain IDs that make collide. I don't know. I know that that is extreme extremely you know um improbable let's say but still isn't it better to move from chain ids alto

together uh in the future and so not use chain ids as a requirement as an attribute to do the linking I mean >> I'm not sure I understand uh what you mean in terms of the chain IDs do you mean it like as an attribute in the computation or general. >> Yeah. Yeah. Like when you when you when you input the set ID and you say one because that is Ethereum is name.

>> Um why use that instead of the hash or the ENS name of of mainet? >> Um I don't see why not. I think these are things that uh ultimately we're looking for feedback on. I'm not an author of the ERC. >> Um but those are the questions we're trying to raise here because um on top of we're trying to validate why are these attributes used and why were they selected. So you know really like would really like to hear your opinion on that as well.

Discussion on Chain ID Usage and Compatibility

>> Yeah. Yeah. Yeah. And and also I I believe I um I already asked this but I don't remember when. Is this going to work for any L1 or L2 or just um for for Ethereum rollups? >> So a very sweet side effect of introducing type two attributes is that this would support nonem chains because that exists for pretty much all chains. So if we were to adopt this standard and in include those type 2 attributes that is the name space and the chain ID we would be able to support as a side effect both EVM and nonvm chains. Yeah.

>> Yeah. Because that that is actually I'm not even talking about nonem but just like for example a roll up on B&B that is still all it EVM but everything is on Ethereum. So yeah that and there that's a lot there's a lot of um use like it's not like uh like more than 10% of of the chains but still I believe that we shouldn't like since the GitHub repo is actually the place where everything gets in that everything EVM gets in we shouldn't be um you know leaving every like leaving anything behind otherwise the GitHub repo will still be used for some

specific edge cases, you know, there shouldn't be any reason to use the GitHub repo. So, yeah, I'm just going to, you know, provide some feedback in the in the in the in your repo as well. So, thank you. Thank you for now. And also the last the last question would be uh can you provide like an example of how the transaction is being like displayed? Maybe you have a because I saw that there's there is a transaction so that is not an attestation. So you need if to >> Yeah. Sorry to cut you off, Jack. I just want to be mindful of time. Maybe we could move this last part uh maybe async to the to the chat. Is that okay?

>> Yeah. Yeah. Yeah. >> Okay. Yeah. Sorry to cut you guys off, but uh maybe just to Yeah. keep moving things along. Um I do want to give things uh give it over to Skellyy, I think from Wonderland team, maybe has a few things to to add. >> Sure. Um just to continue with the I mean with the questions here and the concerns. Uh I mean we agree the main idea for the chain list to be on chain is to be able to fully deprecate any uh say third party um dependency that being GitHub or whatever basically and allow uh I don't know composibility etc etc to

On-Chain Chain List and Resolver Development

be basically to live on chain. Um the this is basically why uh we built um both 78 and and 7930 uh is to be able to accommodate for all and any chains. There are some limitations that we've been raising regarding uh ENS only allowing you to register 32 bytes. We uh are circumventing that on the resolver implementation that we already did. um that's being internally audited uh by the Wonderland security team right now.

Uh the repo is public though. I will show the link in a bit. Uh so you can check that out. Obviously it's a non-standard resolver for UNESC just because it it's needs to go above the 32 byte limit, right? Um that being said on top of that resolver you can just extend that uh let's say wrap that to basically uh I don't know create a subset of domains that use um I don't know the whatever ERC's uh that you want to use and that should work. Uh you can also extend that uh to be able to add different properties to whatever you're

registering. Those being the portal address, the I know fault proof, this and that or whatever uh additional uh parameter. Those ideally should be under an ERC so people uh know uh how to basically quote and what to expect back as a value. Um but yeah so that's it. We'll be showing you guys uh some links and like whatever effort the guys uh from Arugal are doing it's it would be just supported on the resolver that we built. So yeah that should be fine.

Any comments or questions? Anything? Maybe throwing it back to unruggable guys. We can also maybe this is I don't know how relevant or interesting this is to the larger group. I think we've been meaning to schedule a smaller call for a while now with Unugable Wonderland. Anyone else who wants to join, of course. Um so maybe we move some of this conversation over there. >> Josh, if I'm okay to quickly jump in. >> Sure. Of course. >> Um just for context, I'm Thomas from Unruggable. Um, yeah, the work Martin's been doing on this, uh, we're obviously engaging with Josh and the team at Wonderland, but this demo is kind of a proof of concept of a registry cont contract and, um, a fully ENSIP spec compliant resolver for resolving um,

these chain IDs on a subdomain of whatever ENS name is chosen to go with. Uh, so L2. one that was discussed. Cid was another one. Um, in terms of Jack's questions, I think kind of the reason that a lot of these parameters have been included in the derivation of the 7785 chain ID is sort of um so that you can interchangeably work with any of these values assuming that you have that 7785 chain ID. So our registry allows you to convert between all of them. So if for whatever reason you need um a Cape 2 identifier for example, you can get that

from a 7785 chain identifier. Same with the 7930 and the coin type um as defined within ENS specifications. Uh yeah, I think that in terms of 7785, obviously lots of people have been contributing to that um to the development of that spec, but basically that's kind of I guess the outstanding thing exactly what parameters go into the generation of that hash are up for debate, but we kind of need to agree on it. Ultimately, like the Cape 2 hash can be used for nonem chains, for example.

Um but the uh the standard chain ID one for Ethereum mainet standalone is not particularly clear for non EVM chains. So yeah, as Martin suggested, uh it would be ideal if people could kind of have a look at the the registry and resolver contract that we built as well as these specifications 7785 and 7930 as well and comment now so that we kind of do it right first time. >> Yeah.

Yeah. And then sorry to t but it's just um yeah the the thing about the chain ID was actually um if we find a way to standardize uh chain identification like the like the EVM train ID across chains that are non EVMS as well like I don't know there's a parach chain ID or a cosmos chain also have some kind of uh string that is attached to a chain identification. So we can just hash that into a unified um into a unified hash uh of a chain ID and not the number of the chain ID like is EVM. I I know if it's it sounds like convoluted but um but for example this makes makes sense for a possible L2

building on Cosmos whatever that may mean but we know that some weird stuff has been happening lately of L2 becoming L1 becoming L2. So um so what I mean is simply like not using the EV unbiased chain ID but instead using a generalized hashed baby chain ID um like the type 2 um for um for um actually using set like referencing chains uh between each other. That's just it.

>> Yeah. Um, yeah, I agree. I think like even things like the rollup address makes the kind of naive assumption that uh roll-ups will all continue to work in the same way in the future and that nonem chains work in similar ways. Uh there's kind of outstanding questions for example what exactly goes into that role address field or a chain that doesn't post state routes to L1 for example. Um I mean yeah these chain identifiers for interop could in practice be just a hashed version of the cape 2 identifier for example. Um then yeah I mean

yeah Martin and I have discussed this a lot. There's elements of 7785 where you kind of think to yourself actually do we need this? Does this solve the problem? Does it create more problems? Um, and that's why, yeah, we need to kind of continue to have conversations about it and people need to be kind of proactively engaging in the conversation. Um, rather than sort of when it's getting to that stage of being very close to completion, um, people sort of coming out of the woodwork sort of late in the day. We want to kind of have that conversation up front.

>> Yes. Yes. be happy to to help with uh with our with our experience in you know indexing chains across different ecosystems. >> Okay. Um well maybe on that note we can um yeah move on to the next agenda item if that's okay. All righty. We have Demar here from Flashbos team who has been waiting patiently for some uh discussion on multiproving. De Mars whenever you're ready. Oh yes. Hello everyone. Um let me share my screen.

L2 Multiproving Initiative. Discussion on starting a working group for L2 multiproving

cool. Yeah. So I think there's like um a bunch of disclaimers to add here. We we work with a bunch of rollups uh L2 teams at Flashbots and you know there's uh you know certainly conflict of interest. I think I'll I'll get out of the way before uh uh when we like officially kick off this effort. Um but yeah, I wanted to basically talk about how we're going to start a working group to accelerate L2 multiproving and um you know, in particular, this is something that uh Ethereum in general has been very excited about. Um something we're hearing that institutions are are very excited about as well to um you know, ensure the highest quality of security on their assets on on Ethereum. Um and so I put together this document uh which I believe is on the agenda and I'll just

share in the chat as well. Um and it outlines a few of the um sort of opinions uh that we want to take with this group uh in order to to to move it forward and maximize success. Um so yeah, the north star here is for us is like to make multiproving the default security model for Ethereum L2s uh with non-trivial value. And that doesn't mean everyone needs to do it. Um but we we do want to kind of create this like very uh you know wrapped up package that people should be able to use. Um and so there's a lot of ways we can do this but I want to uh share these like three goals that we want to start with is like one so we want to take the paro principle I think there are an insane amount of rollup

architectures and teams and I think that's super exciting and I don't want to um you know belittle any of the work there but our goal is to focus on like the top 80% of TVL first um in this like work stream um and that doesn't mean we can't uh eventually uh expand some more or it doesn't mean that like other chains and stacks as well can't uh follow along and like contribute to this effort. Um but like when we're making decisions like we want to ensure that like decisions are not blocked if if they're like outside of this 80% at least for the first phases.

Um we want to take a research engineering approach. So our you know the goal of the working group is not to have the finalized architecture uh in the sort of like first sprint or phase but we want to progress via PC's to uncover unknown unknowns um and not design for the end state by day one and then another concrete thing is going to be very hard to do but like we want to try and keep logos out of this as possible and that's why I will do a bunch of conflict of interest sharing and all these things at first. Um, but yeah, we we really want to make it about shared marketing. Whoops. Nope, that's the wrong word. We want to make it about shared architecture, not marketing. Um, and so yeah, that being said, I think because of the 80%, we'd we'd love to

start kicking off an OPAC multirover PC and an arbitrum orbit multi-prover PC. Um, and as well another one of the more extremes we want to enable is a design go design goals document for a multi-prover market uh interface. So there's a lot of interesting questions there similar to like PBS on Ethereum L1 or L2s where like how many uh approvers is the ideal structure for livveness? What are the ideal livess properties we want? Um you know uh should like the cost burden be on the user or should it be socialized? Um these these types of questions we want to like dig into and have like an opinionated uh design document that we can propose to the community. And then longer term we want

to you know expand to greater than 90% after that converge on a generalized multi-prover uh architecture and uh build a shared open source codebase if possible. Um yeah uh so the rest of the document I won't go through it but it sort of we explain why you know the risks of a single prover um multiproving as the solution what it enables there's a document from vitalic which is the architecture that we most likely will go towards but it's this pragmatic fast finality um and I can share that document here as well if you haven't read it um oh that's here you Um yeah and so I I sort of mentioned the

northstar about this and in the tlddr above um some of the guiding principles and then our immediate goals for PC phase. Um cool. So that's it. I'd love to answer any questions and uh what we want to do is start assigning basically a coordinator for each of the PC's in the PC phase. Uh, and then we'll try to set up like um some type of call and we'll report progress back to this this call as well. Um, and yeah, we'll we'll try to do all of our updates in the L2 interop GitHub repo and the Telegram chat. Um, yeah, that's it from Mina.

>> There's a question from Nom in the chat. Sorry if I did you already answer that, Darus. Maybe I missed >> Oh, sorry. misting this in the proof system for the built-in canonical rollup bridges or for applications using the multi-ruer uh yeah the goal would be for the canonical rollup bridges at first um and and on top of that like for the PC's I think the goal would actually to just be to like have like a parallel bridge so I think that's I'm I'm not sure what the um or or at least that's how I've seen a lot of the ZK proving teams had developed their uh initial versions was they just had like a parallel bridge that was like ZK proven. Um, so I think it would be great if for the PC's we like get that to test net and and

validate that in like a semi-production setting >> would be very if that's the wrong focus. Yeah, I'm sure that could be a debate in of itself, but um I think it's it seems to me what you're saying is that the like the kind of like the production end goal which I recognize is not part of research engineering, but like the eventual um goal would be for let's say base optimism arbitums like the canonical rollup bridges to basically move to this multi-rover system and specifically within their interface.

>> Yes, exactly. Yes. Any other questions, comments? Thank you for coming on the call and sharing this. Looking forward to future updates on the multi-proving work. All right, up next, permit three from the echo team.

Introduction to Permit 3. Shra from Eco team introduces Permit 3 project

All right. Let me just share my screen. All right. Can you guys see my screen? It's looking good. All right. Hey everybody. Um, my name is Shra. I'm product lead at Eco. Um, longtime listener, first- time presenter, so bear with me. Uh, today we're going to be talking about something that we've been working on internally, called Permit 3. Um I'm going to share these links in the chat after I present. So just uh I'm going to so I'm just going to share the screen for now but and I want to reserve most of the time in this call for the time that we have to address some of the technical feedback. Um and I want to

give a shout out and a thank you for the people who did um start the feedback loop in telegram. Thank you so much for raising the concerns and some of the changes proposed changes. We really want to address those directly. hopefully if you have time in the call but for those who are not aware who are not caught up to the telegram I'll just start with a quick TLDDR of what permit 3 is and why we built it and then I'm going to kick it to Kuriel who's one of the lead engineers that helped build permit 3 to address some of those uh implementation decisions. So quick TLDDR of why we built permit 3 is that Eco is obsessed with creating singleclick stable send experiences. Um and we want to and we are Ethereum first and what we found is increasingly with the proliferation of

Introduction to Permit 3. Explanation of its purpose and benefits

L2s. Um our users that want to en that want to do stable coin actions have their balances spread across multiple source chains and the the extent of the best technology that we have seen so far um to allow like really smooth interactions is permit 2. But permit 2 in essence is domain constraint and really the UX the singleclick UX we want to achieve kind of breaks apart with a fragmented balance if it's spread across multiple input chains. Um and so permit 3 was built directly to address that problem directly and simp quite simply permit 3 is a is a protocol that allows people to do crosschain token approvals

and transfers with a single signature. How this works if I want to eli it and then CL can go into more detail is that we if a permit 3 is set up once on source chain for the user. If a user has multiple their balances spread across multiple source chains in the applications that we build, we can abstract their balances into a single global balance and then with a single signature do any desired action they want regardless of the number of source chain that their balances may be on and you can think of it very simply as an extension extension of the same pattern as permit 2 but in a multi-chain setting. So what happens on the back end when a user

creates a permit 3 signature is that you can think of it quite simply as like nested permits that solvers in the eco intent protocol can then unpack on the relevant source chains and then create intents on behalf of the user and those intents can either do the desired action directly when message sender is not a concern um on the target chain or what it permit 3 can allow you to do is create intents to transfer the funds to the user uh to the user's wallet on the destination chain and then use the final permit to actually do the desired action for the user so that you can preserve the message sender and the attribution which is very important for payments. Um so that's basically it's a very it's very simple but very powerful

and it really allows us to create really nice experiences. Um so that's basically the tlddr for permit 3. Um, I'll stop here and Kel, if your mic is on, I'm going to jump a little bit into GitHub and maybe you can help walk them through some of the architecture in a little bit more detail and then we can maybe save some time uh to address some of the feedback that we saw in Telegram or any other feedback that people may have in the time that we have. >> Awesome.

All right. go for it. >> All right. So basically you know like if you're familiar with permit to architecture is uh what they're trying to do is to create like a batch signing process where in one batch you can have uh multiple allowances and also like it can be allowances for multiple tokens and then if you've been using unis swap uh knowingly or unknowingly you've been already using permit 2 a lot and the general idea that instead of giving20 allowance to the contract uh that you're working with for example unis swap router uh you will just create uh basically an infinite allowance to that

permit to contract and then permit two contract is your intermediary for creating uh single signature allowances. Uh so we're extending this idea for permit 3 is now instead of creating a batch of approvals for a single chain we're basically creating several batches. uh one is for each EVM chain and then we basically create a Merkel tree uh from those batches and requesting only one signal uh user signature for that tree. Um okay so there is many things that you can do with permit tree and um like

things that are different from unis swap is the allowance system. So uh with unis swap you can have like a synchronous nonsis but you still like set an allowance as a final number. With permit 3 the change that we did is to allow a synchronous nature or environments where you have like a lot of transactions and a lot of authorization can be happening and balance can be adjusted. So in essence permit uh three allowances they're incremental. So they're rather operations like increase allowance and decrease allowance instead of set an allowance. And then for each chain you create a batch and batch inside of it can be also not uh uniform because in one batch you can mix allowance

increases, allowance decreases and direct token transfers and you and you can include as many tokens as you want. Uh then like you multiply it by amount of chains and now you can have five chains and for each of the chains you can put a batch with uh different tokens uh different addresses uh um being created allowance and then you create a Merkel tree of the whole thing and create one signature. And one optimization that we also included here is we were thoughtful about gas cost and uh making sure that on the most expensive chains uh eg Ethereum uh we are trying to get as small uh Merkel proof as possible. So we're going to

save up on the call data on the gas used and to do that we basically leaning heavy in in in into using unbalanced Merkel tree. Uh and in this case for Ethereum the amount of leaves that you need to supply for the proof is just one and then for cheaper chains they can be like down in uh down down the path in that balance tree and in this case we we are not caring about uh you know the length of the of the uh Merkel proof. Um do you guys have any questions? Uh do you do you want me to like elaborate in any of that?

Um, just one more. >> I dropped a question in the chat and sorry, this is also coming from me having not spent enough time digging into the documentation yet, but I'd be curious to hear more about just sort of this. Yeah. Yeah. So trust assumptions for the offchain system you know like uh we there was already u a concern brought up that like oh now we building a miracle tree and that the actual like underlying data is abscated for from the uh wallet signing user. So you know like the first or actually the answer comes from from the way you phrase the question is trust assumptions in in in many cases users still trust the front end or any other application that is using like when

you're creating a permit 2 signature you also not exposed too much of what's going on under the hood and even if there is more exposure into the u 712 signing with like MetaMask wallet there is still a possibility to do some fishing attack if the front end or any other software that it used is malicious. And another aspect of it, we basically just released, you know, like final public release of the permit 3 happened yesterday. And in the future, we're thinking about working with wallet providers and making sure that uh they can be supporting 712 signatures with nested Merkel tree data structures. So as right now like it is not ideal but

Permit 3 and Intent System Integration

you know we're working on that and we're seeing that in near future as we get more traction and user adoption the wallet is going to be able to understand you know hashing of the substracts and organizing it into the Merkel tree and presenting it with a nice UI. Cool. And just to give you like a little bit of idea why permit 3 is so powerful for us like it uh basically combines together nicely with the intent system that we are building where uh to create an intent we basically just doing user log into a unique w unique wa. So for each wault uh for each intent uh on the source chain unique wault address is

created and then for user to create an intent the only thing that is noted that is needed is to transfer that required token into the vault and with pyramid 3 and gasless system all that it needs it is to create allowance for that vault and then vault is capable to pull from you know using like transfer from and pull from that allowance and with permit 3 uh in the gasless experience and a stable coin experience experience. All user needs to do is sign uh a message that contains permits for bunch of chains and uh those allowances that are created going to be for different intent walls. And in this case, just with one signature, we can create as many actions as as needed on as many chances needed.

And that that enables us to to bring ethos of eco to to any user which is uh with one signature user can create any amount of actions with stable coins and achieve any amount of results. >> Can I can I ask you a question? Um in like the worst case scenario, let's say like the spender does nothing and or just like drains my tokens and walks away. like what recourse do like I as the user have to get my money back? >> Uh as blockchain you know it's like it's a simple send with ERC20 or given allowance with RC20. If if an allowance is given to malicious actor and token is transferred there is nothing can be done

because uh permit 3 in essence doesn't you know like create balances or wrapping tokens any house. So it's only like managing allowances and let's say if uh if allowance was created and then like some for the contract let's say contract gets compromised we support uh a system of locking down the allowance and it's similar as permit 2 does it so you basically have an emergency path to disable allowances for a certain actor. >> Got it. So, so there's no recourse I guess in those that case. Would you say that there's al is there a way that enforces like um I guess settlement outcomes because like what if I say I

want to do one thing but something else happens instead is is there a way to enforce that at all? I think not with permit 3 directly as as as I mentioned because you know in ACRC20 allowance whoever give it to or like whoever we send token it's done but if we're talking about the whole EOS eco ecosystem we're pairing it with uh our uh intent and our intents describing clear action that can happen and then that action is abstracted away by you know behind that unique vault address and then you basically create allowances for specific intents rather than like huge wide allowances for the whole smart contract and then intent can only result

into desired action and if it does not happen uh before the deadline then all the funds are refunded. So I hope that I hope that answers your question. >> Okay, got it. Any other questions for >> all right and just you know like uh I hope no more questions on that part you know so now we sort of covered you know uh all this powerful experience of having one signature and being able to move as many tokens on as many uh chains as you wanted. And uh when we created permit 3, we were like solely thinking about

Expanding Permit 3 for NFTs and Future Plans

pushing experience and we were googling other permit 3 like ideas, implementations and there was nothing. And then like at the late stage of the audit somehow two more permit 3 projects came up that was done like some time ago but never gained attraction and uh a lot of like their innovation were to expand the RC20 tokens and that means supporting NFTTS and supporters ERC 11155 and we decided to hop on the train as well and make sure that we are not competing on with other like permit suggestions but rather improving what came before and what else we added is with our permit three system in one signature user can create allowances for

ERC20 tokens allowances for NFTTS and ERC 11155 tokens as well and allowance can be per unique NFT ID or user can say I give like a wild card allowance for uh five NFTts that I own from from the whole collection. So yeah, this is some additional bonus that we support right now. And in some future we're also planning to bring uh ERC basically NFTs and other like token senders to our uh to our intents and create like a whole ecosystem where in with one signature user can basically authorize any amount

of any types of assets and create any kind of complex crosschain actions where user just you know gaslessly creating one signature and covering everything and also like I wanted to mention that uh we are utilizing the benefit of ERC7702 and if user you know completely trusts eco and uh they don't have smart account smart wallet or they can upgrade uh just do 7702 upgrade for permit 3 approver and what that thing does is it allows to create ERC20 approvals for user tokens to the permit 3 contract uh without any user uh input in the future. So that

means like with doing 7702 upgrade user creating like uh infinite allowance for all their RC20 tokens for permit 3 contract and in this case like uh future tokens all things like that can be just you know like already available and be just behind one signature and if user has a smart wallet we also created a smart wallet module. So like any user can install that module to their smart wallet and also enable that behavior. Well, thank you Echo team. It's great to learn more about it.

>> Awesome. Thank you guys. >> Thanks everybody. >> All right, I think that maybe brings an end to this week's call. Thank you all for joining. See you next time. Adios. Thanks, guys.