L2 Interop Working Group #13

Transcript

Welcome to the L2 interrupt working group. This is call 13 in the series and it is PM issue 1713 uh in the PM repo. I will share the agenda in the chat and we can just dive into things. Starting off with a recap and maybe brief Q&A of the protocol update 003 that went out last week on the improve UX track. Go for it, Barnab.

Oh, you might need permission to share your screen if you want. >> Oh, that's okay. I I I can just talk. Uh maybe we can drop the link in the chat. So yeah, we had like um a post last week uh from EF Protocol, our R&D teams working on protocol and interrupt uh laying out uh a set of projects that we we intend like to take on to to accelerate um Ethereum interoperability. So some of these projects that you see on on this uh note uh they're things that were already active but I think the aim of the post was to try and frame them like with a greater sense of

strategic purpose or or direction that that ties together like all of these um different initiatives and this is I'm speaking like from my perspective like how I understand this and and and few of us in EF have I would say slightly different perspectives on this But to me the through line of all of this is is trying to close the gap between what would be some kind of ideal uh protocol interrupt so Ethereum protocol interrupt and effectively what we have today uh in terms of of our interperability stack and the gap that exists between the two.

So me I frame it a little bit as uh the gap between what Ethereum provides as as settlement like what the Ethereum protocol provides and what alternative settlements exist. So for instance, if you settlement is is quite expensive because you have to coordinate like this very large set of validators to come together and to sign off on like a route and that takes time that takes like coordination of of billions of dollars and so there's many ways to to to accelerate that and to yeah to have alternatives. So one of them is just uh third party bridges like they have their own uh way of settling um the the messages and the the value that that transits through them. uh either because

they reduce uh let's say the economic security or because they have their own trust or reputation like if you're if you're circle and you're doing your own asset issuance like that's yeah you you you're backing that through through your own um your own brand essentially. Uh that's one way and another way to to bridge the settlement gap or to like almost like make it disappear is is through intents like you you you essentially like move a settlement risk from uh from the user to another party which is the solver or the or the filler. And so in my sense, the more we close the gap between um the ideal Ethereum settlement and and these other various forms of of

settlement, uh the better we can improve uh interoperability like across the stack and for for every types of of use case. For instance, when we close the distance between Ethereum settlement and and third party bridges, I think that makes asset issuance on Ethereum become a stronger value proposition. When we close the gap between Ethereum settlement and between uh intents, we reduce the risk that third parties are are taking on behalf of the user. And so we also reduce the cost and we can make things uh more trustless. And so there's there's also benefits to to doing that.

Um and so in the in the project that we have uh the first stream is is is really about um laying down like some of the foundations of intentbased architecture. So we think it's a good place to start because this intent layer is like very close to to the UX like it's it's been recognized as as a very strong alternative for for users to just like communicate operations that they want to do uh crosschains. Um so this centrality I would say almost of like the the intent layer makes it that it's it's a good place to push standards for instance from like when you when you bundle like other standard like interoperable addresses uh crosschain

messaging along with like these intents that that realize like a lot of the information that the users communicate. uh yeah that can be a very strong vector of adoption and it still feels like at this intent layer there's there's a lot of green field designs that we that we can explore. So open intense framework like we are looking into different extensions different um modules that that can be added to to strengthen its stack the interoperability layer is another like new design that uh that seeks to fill like some of the gaps of the existing like state-of-the-art. So yeah, there's it does feel like there's a lot that we can improve uh here.

Another part that I think makes intense like fairly uh interesting to to to focus on is that the interface is is likely very future proof. So intense today are solved with like these back ends of of solvers or fillers that have their own capital. But as the back ends uh evolve and for instance like with snarkification and faster settlement um the interface remains like pretty much the same like the user can still communicate their intent like the things that they want to do through the same types of things that they they would use today and so it can be very transparent like whenever we improve upon the back ends like this can be immediately reflected to to the to the user. So I think that's a really powerful um thing.

So starting from the this intense like laying down like very strong foundations for uh let's say a unified uh seamless Ethereum stack of interperability. That's part one. And then part two is is seeking as much as possible to to close the gap between Ethereum settlement where it is today and where it should be uh in the future. And so the main thrust here is is essentially making settlement faster. So for L1 itself for instance by reducing slot times by having a more usable fast confirmation rule which is something that I think will be presented in a month uh on this interrupt working group and by having faster finality in the order of a few seconds rather than

13 to 19 minutes as it is uh today. So I think this is really exciting and something that we should really accelerate to to close the gap. That's for L1 and then for L2's faster settlement with for instance this two out of three finality mechanism like we think this is a really interesting option to to explore for optimistic products to to to reduce the length of their uh withdrawal uh windows. That's one thing. Another thing that we also intend to explore quite a bit is uh snarkification of of everything like that's going to be uh also the main thrust for other projects that we have going on in EF and yeah ZK proofs just allow us to to get uh instant uh proofs

and verifiable computation and and be able to make statements about what happened like on different domains. uh and since the costs are becoming lower and lower, I think this is something that we we need to be yeah thinking proactively like how do we integrate this into into the architectures of of tomorrow. So yeah, starting from intense building up our way there and then closing the gap uh for ideal settlement on Ethereum and if we if we do that I think uh we'll have we'll be in a much better place than than we are today. Awesome.

Thanks, Barnaby. Any questions? >> So, I had a quick question about uh EIL. What is this EMT layer exactly? >> Yeah, I can jump in there. Um Josh Barnaby, you want me to take the um lead on that one? >> Yeah. So yeah, kind of as we outlined in the post, Yayel is this trustless um cross L2 interop layer. Um so it's all about kind of having these multi-chain transactions but while keeping the user in control and preserving Ethereum's core values. Um so just I just put out like a tweet about it. I can share it in the chat um after I finish this. Um kind of clarifying what it is, what it isn't.

Um and currently we are still very early on. we care the most about like making sure that Nurop stays aligned with Ethereum's core values. Um so we're just trying to figure out some more of the details on that. So a more detailed spec will be released mid-occtober. Um and then in November at Dev Connect we'll open things up for like broader community feedback um experimentation. We want to hear your guys' thoughts about it. But will it be like a layer or will it be like chain link? Will it be like any of these bridge solutions where multiple validators transfer information across chains or >> Yeah, we'll we'll release more details

kind of as we get closer to um but uh I kind of in my post kind of talked about some of that that um we are it is only a solution for Ethereum and Ethereum's rollups. It is not a solution for alt L1's for example. Just to clarify, so this is like a crosschain messaging protocol in a way or improving something like that, right? What is exposed in the in the block? >> It's a it's a c Yeah, I would say it's a crosschain um transaction layer. It's kind of how we're thinking about it.

>> Okay. >> And so this transaction layer I I read a little bit in the in the post that it's basically executing transactions on on multiple chains. Is this on the level of sending messages from chains on execution or is this being executed on the application layer or or is this something you can't share at this point? >> Yeah, that that's something that is still an implementation detail that we are working through. Um and that will uh go out uh a more like detailed answer to that question will come out mid-occtober.

>> All right. Thanks. Uh another question on this one will the will this be this EIL will be part of the protocol will be something on top that users can implement right so how will that look like >> yeah that's a great question um that we can share uh so it is not a it is not something that will go into a hard fork for example it does not require protocol um changes in that regard it will be um there will be a bunch of ERC's um that kind of combine together to define the standards um around the protocol Okay. So, basically only on the

execution layer, >> correct? >> Thanks. >> Um, quick question. Is there a reason that it isn't that it's EVM only and not ALT L1? Just is it just because this is built on Ethereum, so you're just keeping it EVM compatible? Yeah, I think the thinking was like you know we work for the Ethereum Foundation so we prioritize interoperability with Ethereum and Ethereum's roll-ups. Um there are complexities in implementation details um around alt L1's that it just wouldn't be compatible with. Um so yeah it yeah it wouldn't it wouldn't work but um perhaps there's a way in the future

someone could perhaps like build an adapter. Um yeah I don't know that it would be able to work though. >> Thank you. How do you think about like alt EVM L2s that are settling to Ethereum? >> Yeah, that like I I would say that is not our main focus. Um kind of our our main focus of this is mostly on like Ethereum um and its roll-ups. So, so what I'm getting from this, this is essentially an multi-chain extension of the relaying bundling part of like like ERC 4337 and stuff similar to that.

>> Um, I can't comment on that at this time. Um, but more details should be made available in October. >> All right. Thanks. Can I ask um last question? Um, is this only available for EVM roll-ups or is this all roll-ups that settle on Ethereum? >> Um, right now so the plan is EVM um to start in the future there might be a way for other rollups. Um, but yes, the plan is EVM. And just so you know, we're not we're not secretive. I see a comment in the chat. We're not secretive because like we are trying to hide something. we're secretive because we just haven't figured out all the implementation details. And ideally, this would have come out later. Um, but this blog post

was coming out and it didn't feel right to have a post talking about how we're improving like crypto UX on Ethereum without talking about Ethereum interop layer. Um, something that is going to become part of the conversation towards the later end of this year. Um, and so that's why we included it. Um, ideally this would have I think waited until uh mid-occtober when we come out with the post. Um, so I'm so sorry for like not revealing all the details now. I know it must be so annoying. >> It's totally understandable. I was going to say, what's the best thing we can do in the meantime to either keep up with it or support any of the research behind it or is there not really a way because there needs to be kind of a full coming out party in October?

>> Yeah, that's a great question. I think like once we post um mid-occtober um then we will really like be able to solicit feedback from the community your ideas how we can make it better. I'm sure there's some extensions um that we could write. Yeah, like someone in the chat says crossVM support um for the implementation would be interesting and like of course like all of that comes with once we share the implementation details and the specs which is not finished um and things are still changing. Um, so yeah, once that is all out, we would love to have you guys like think of how you can break it, like how like how it can be improved, like things like that. Um, I mean, we would like to think that it will be um tested as well.

>> Cool. Maybe one last question in the chat from Georgio. MRS, did you want to touch on that one? >> Got it. Yes. Oh, yeah. Is is this related to the OAF initiative at all? Um yeah. So like this does not contradict OAF. OAF will continue to exist um and uh it has like use cases that are best for it and and I think like intents also have a use case um in that regard. So yeah, this this is not in contrast to OAF. Um this is a different like trans transaction layer I would say.

Yeah, I'll just add that we're excited to continue supporting the OIF and for the OAF to play a big role going forward as well. >> Any any other questions on EIL or Y? >> Yeah, maybe maybe um zooming out a bit from the EIL. Um I'm I'm wondering like there's a bunch of different I guess efforts going on, right, which is great like laid out in the blog post. Um, for me for example, I think I striking out is like the OAF, I think it's like 7786, now the EIL. And I'm wondering like if you guys have kind of like a view of like hey like if I'm like a let's say application developer if I'm a D5 developer if I'm like an inter developer like how should I think about basically

like how to kind of like right like do so in an aligned like collaborate in aligned manner or like how am I supposed to like how would I how should I think about like okay if I built a lending protocol right like I can rely on this being there and this is the recommended path going forward or is that something that yeah Yeah, I guess that's maybe my question. >> I can give some thoughts. Oh, sorry, Josh. Go ahead. >> Yeah, go for it. >> Yeah, I I think the ideal state would be having like clear user stories and and use cases and say if you're building this that that's what the stack looks

like. Like OIF is point sense extremely modular. So it addresses or at least it's supposed to address like many different um parts of the app stack like if it's more like the back end with solvers or if it's more the interface or the intent expression and dissemination etc. Um so making clear like what's the right interface for which problem and making the interface as agnostic as possible with like the back end that that supports it. I think that would be to me at least a clear wink because then you don't have to point people to oh there's like three different things that you should be thinking about and

supporting but say more like there's this one interface that you should be familiar with and if you use the default it's going to be great and if you want to tweak the defaults like the interface allows you to to do that so yeah abstract away as much of the complexity as possible abstraction is also good because that allows you to have I would say less vendor lock in and more like yeah freedom to to customize your own stack. So personally like that's what I would support and and where I want us to be uh within a couple of months with like yeah OIF being much further along in his development EIL becoming uh more public and and open source. So yeah I think we we we'll get there pretty

quickly. Gotcha. Maybe if I can repeat back, are you saying that like basically developers ideally should use the OIF or intent interface and like basically every kind of effort otherwise will kind of like support right like faster more trustless settlement of intents but the kind of like the way app developers say should think primarily is like hey you should use the if you can. >> Right. Right. they should they should be given like a a list of interfaces and I would say many of them right now would be available like through or 77x I don't know that's directly under but it's definitely related um yeah so having just like clear signpost of what to use

and and when um but I would say right now if being available like that's a good start yeah >> yeah uh just piggyback Backing off what NOM is saying, are you going to target the interface layer or are you going to just like use OIF and 7786 and then sort of innovate on just like the verification proof layer um side of it? Do you understand the question? Um, >> so you're asking like are we are we only going to design like interfaces and standards or are we actually like going to propose like different mechanisms? Um >> what I'm asking like OAF and 786 are two

interfaces for crosschain and they sort of serve different use cases like are should we expect to see a third interface come out of this effort or will EIL like integrate with those existing interfaces? >> Oh I see. Yeah I would p that to Marrison. >> Yeah. Again uh I would say like more of those implementation details will come out in October. Okay. Okay. Well, yeah, just to keep things going on the agenda, maybe we can uh move on. And yes, uh we'll have more in weeks, not months here on the EIL and

others. Thanks for your patience on this. Cool. Uh, coming up next, ERC 3643 on RWA tokenization. Dennis, >> thanks Josh. Hi, everyone. It's so nice to meet you. I recognize a lot of great faces. Um, I have a hard stop at 10:30, so I I do apologize and I want to thank Josh and the Ethereum Foundation for being so fantastic. Um, I'm going to give a just a quick overview how you guys uh can get involved as well as a um uh quick uh summary of of what ERC3643 is. So, I did have a deck prepared, but perhaps Josh uh in in slower time I

could share uh that whole deck. Uh what I do have for everyone is because I know there's a lot of big brains here, a lot of really smart people, which I am not. um how to get involved into um ERC 3643. So what ERC3643 believed it is a um approve a final Athereum standard um passed in December of 2024. Um we have built a nonprofit technology nonprofit group uh in Luxembourg um around uh the standard and getting people involved. Um and uh we've had some an interesting two years. Uh in doing so um we um have over 120 institutional members. Uh we have uh

billions of dollars uh on public and private chains uh used um on the asset uh using the asset. Um and most recently we were named by the SEC in the project crypto speech um as the only innovation exempted standard. Don't worry, there'll be more um that can uh that you can use to tokenize securities and I'm happy to report that seven other Latin American countries in the world have adopted this standard. Um the standard uh has wide adoption um overall um if you're in Europe, Middle East or Asia, you generally can use uh the standard. Um and so how to get involved? How how can you do do that? So Josh um asked me to put together a couple of projects that I

think you guys would find interesting. Again, apologies for uh the shortness of time I have and I'm happy to come back next session and give like a full full presentation. Um we have an onchain ID project. So if anyone finds decentralized identity interesting, we have a chain link um AC project. So if anyone finds data orization interesting, we have lots of policy work in the US and the EU that that we're doing with the crypto task force, the treasury task force as well as NIST. Um we have a crosschain project with layer zero between base and polygon. We have a privacy project with ZMA. We have a silent data applied blockchain uh project for zero knowledge for inco. We have an open zeppelin reference implementation and most exciting we have

a full dowo full t-rex dow um that you can you can get involved. So um if those of you who haven't seen I think I'm sharing my screen. You can see 3643 here is our website that will go through um a lot of uh the stuff. Um you can see our members reference here who's here and most importantly for this group the docs. So everything's open source. We have a white paper at GitHub. Um and we're looking for new members and new projects all the time. But the exciting thing is the T-Rex. So you can imagine ERC3643 it's a permission token standard. Um a lot of institutionals like to look at it adopt it a lot of policy work but what

about everybody else? What about you know the small DeFi team or the individual who wants to take the open standard and develop it and build it? Well T-Rex is going to be for you. It's going to be a full DAO community um feature marketplace and grants and the next grants um that will be able to support your idea, your project uh to build on top of this RWA ecosystem standard. Um we do not force single standards. We are open standards. What are open standards? So open standards is a concept that Ethereum uh which is the leading blockchain the community has developed standards ERC and EIP standards and what we want to do is broaden those standards away from just the community but actually into

government and actually into policy which is very exciting and we achieved that um this summer with ERC 3643 but open standards matter and mult you know multiple standards um so we don't have single winners are very important. So, if you want to get involved about it, find out more, go to erc3643.org. We have 120 uh different institutional members. If you're an interested individual, go to T-Rex Network. Uh you can absolutely follow all of our exciting developments um on our uh AX account or Twitter account. You can see chairman Atkins announcing the standard.

Lots of cool stuff featured in White House report. Um, another great thing to check out is the foundation was amazing and has been really amazing to ERC3643 and we had the opportunity for the first time ever to present at HCC in cons with my other founder Joe uh who's actually the technical mind behind ERC 3643 which you guys can absolutely uh check out. Um, so lots of good links, lots of great ways to get involved, lots of ways to find out more about the standard, build open standards. Let's get excited about that. Um, and I know this is an incredibly special uh uh community. Um, I want to reserve some time for questions. Um, so does anyone have any

questions about what I've presented so far? If there's no questions or Josh, I don't see any questions, but if there's no questions, I'll take the extra time and I'll do go through a little bit of the deck. Again, I do apologize that I'm so short on time today, but I'm very happy that Josh invited me. Um, so I'll do a quick presentation and if questions come up, feel free to interrupt me. Um, so like I said, it's leading standard for permission tokens. not the only standard but we're one of the leading ones um out there um where you know we have a huge collaboration of law firms policy makers blockchains infrastructure providers L2s and of course um uh lots

of uh institutions uh using our standard green DTCC um common tokenization framework right 1400 really great never actually official standard lots of different implementations by really smart people but what we're solving for It's not cleverness. Um, it's standardization, right? And and we all remember the ERC20 days, there's a lot of ways to represent a token, but ERC20 was the one and we kind of all moved on. I call it like a coral reef. You know, you set the standard, then you build you build on top of it and um and support Ethereum. Um, it's a permission standard, so there's really no context of it, but most of the time you want to elevated gas and complexity. You really want to use this for like securities,

although it could be used for lots of other things. uh we call primary and secondary marketplace. That's a fancy way of saying you have to KYC if you need to KYC or credit yourself to buy a particular asset. If you buy from the issuer, it's primary. You buy from the other investor is secondary. All we need to make sure is that whoever is receiving the tokens um has the correct identity. Um here's a a couple and again I'll I'll share all the uh uh deck with uh with Joshua so you can vote over and then I'd like to do a more um full presentation. um at the next time if that's possible. Um but we are official EIP standard which you can definitely check out. We're on Ethereum magicians as well um which you can take a look. Um we're building dashboards. A lot of

people like hey you know 35 billion that's a big number. Where's that coming from? Fully valid question. I wish it was easy to answer. We have a dude analytics dashboard. We all are working with RWA uh XYZ team. Um a lot of issuers don't want to disclose which is a problem. T-Rex going forward the Dow will be totally transparent but a vast majority of the assets tokenized are on EVM chains mostly mostly prior to pilots but we have still a fairly healthy amount uh which you can check out on Dune um as I mentioned over 120 institutional members across the whole time uh stack good news membership is free it's no obligation the ERC3643 is a community of people who care about

permission tokens token standards and and all that sort of stuff So, um, if you have a really good project, you're interesting L2 and you haven't joined us, come on in. There's tons of great cool stuff, cool people to meet and work on. Um, we've been very busy with institutional adoption with, you know, City, JP Morgan, A&M recently in Fasinara. Um, and we continue with DTCC. We won an award from Deote. We announced chain link CR and then we even did a crosschain as I mentioned uh with uh with layer zero. Uh, we've been busy regulatory. So, as I mentioned, we have about 22 regulators I presented with my partner Daniel um on the adoption of open standards specifically for 3643 um and jurisdictional approval. So, you

know, as of today, you could put the US in a green circle and uh we'll be adding five more Latin American countries in the green circle as well. What does this mean? If you have a security and you use 3643 in the US, you can now tokenize on Ethereum. And that's that means public and private securities. You you go to the SEC, you say, "Hey, this is my filing. Um, I'm using this standard. Tell me what I need." And and off we go. And so that's a lot of the work that I do on the regulatory policy side in DC. As I mentioned, if you want to get involved in that, we have lots of work to do um on that sort of side. We've been featured in regulatory papers. So if reading about how regulators interpret open standards, that's your

thing. Uh we have the HKMA, Singapore, FCA and uh European securities market. Um uh I will reserve another time to go through the technical architecture, but this is the architecture to fully decentralized smart contract infrastructure. You think of it like we took an ERC20 and we added a whole bunch of stuff on top of it, including a self-server ID, onchain ID, which usually gets a ton of questions. Um onchain ID big area for people to innovate in. So, if you're interested in self-s sovereign ID or identity, go to T-Rex Dow, get involved. Lots of cool stuff there. Uh, registry, modular compliance, and I'll go into how that works at another time, but it's a fully decentralized uh architecture. Okay, I have to stop there. Um, any questions to

this amazing group? >> Okay, I don't see uh Josh, any questions? >> No, I think that's it. And people can get a hold of you via Telegram. >> Yep. You can get me at real Dennisl and you could go on the T-Rex down, which I encourage you to. Someone said, "Sad to say I'm too dumb to understand RWAs." So am I. Uh so am I. Good. You're in good company. If you're too dumb to understand RWAs, uh you're good company, which is why you should come join T-Rex Dow. Uh and help us all become less dumb. Um we're we're a big uh 3643 exists because of the great community of Ethereum and we want to encourage more people to come in and and build what

they need. Uh Han says still think about how the compliance part works connecting the onchain off more and connect through telegram. Yes, please do Han. I do apologize. Uh I'm now way over time. I actually have another presentation I have to give to a regulator. Um so uh Joshua everyone thank you so much for the time. Thank you for giving me the space to do a crash course. Uh please uh I'll put some of the links down or Joshua will give you some of the links. I wish you could share with everybody and get involved and and help build in the future with open standards. Thanks everybody.

>> Thanks Dennis. >> Cool. Up next, an update and discussion on chain specific addresses 7828, the L2 resolver spec that Wonderland and others are working on, and the move away from the GitHub list to an onchain config. Starting with ENS. Um, yes, I think we have Skellyy from Wonderland. Do you want to start off? >> Yeah, definitely. Hey guys. Um so regarding 7828 I think we are I mean that's that's done the is done if you guys have any comments or you would like to learn learn more there is the L2

interrupt repo there's a lot of information there uh through magicians as well then uh as well similarly uh 7930 uh thank you as well for all the feedback as always uh that's as well finalized. The cool thing now is this resolver Josh was mentioning. Uh we do have some comments here as well uh from the unravel team. Uh I think they are here as well on the call. Uh so we'd love to hear from them as well. Um but the main goal is to as a first step move uh or let's say deploy uh resolver for ENS that already has prepopulated

uh a somewhat clean list of what's currently on the chain list git github repo. Uh so we um have the contracts ready. Everything uh should be uh public for you all to review. We can share the links later on the uh telegram group um with the script obviously for the script to work. Uh if you ever went to the chain list repo all the namings are a mess. So next step is let's find some cute names that the chains are going to be happy with. Uh so that's going to be uh tough work. Hopefully we can get that done uh let's say soonish. Uh right. So no uh L2 or chain uh I don't know is sad

that they ended up with an ugly name. Um besides that uh whenever we have everything populated this like anybody uh can check um yeah locally that the script and everything resolved uh correctly and we'll create a proposal for the ENS uh DAO to take ownership of that resolver later on and probably you guys have questions on okay what if I don't know somebody wants to update or modify the records etc etc the ownership keep part is not yet uh defined. We are aiming to define this as a separate scope of work. If you have any ideas or any concerns regarding ownership uh

please let us know. We'll be working and we'll let you guys uh as well know when we start working and tackling these problems uh soon enough. That's it. Uh we had a question about a comment um regarding the work from unroable but think we lost you skelly. I don't know Mobius if you could finish Skelly's sentence.

Yeah, we lost you. >> Oh, sorry. Yeah. Uh, yeah. Yeah, sorry. Sorry. Um, yeah, just uh I was saying that uh if you wanted to present 7785, then we can go uh and ask uh some questions that we had regarding that. >> Cool. Yeah, maybe we hand it over to the unruggable folks here. >> Yeah. Hi, my name is Martin Leto. um representing Unraul we are an independent R&D firm that's embedded within the ENS DAO and that is to say um we are here to represent some of the ENS

specific interests um there's uh we've been doing some work on the registry and u basically there's two main things uh that I would like to bring up. The first one is um uh it involves the resolver that should be used for this registry. Uh because when we want to use ENS as the canonical canonical registry for these chains, it introduces um some strict requirements. We need to be able we need to comply to some of the ENSIPs um that specify exactly how you resolve

some of these chain records and um even maybe some how we you know the kind of data it takes like the name hashes or basically the DNS and coding. So that is one key area that uh we need to be alert about if we are working with ENS as the registry. It has its own um rules and compliance. So I can send um a couple of them just to show the main ones. Um starting with ENS IP10 here which basically it's it's it uh it's the spec

for how we do the resolving and um we will potentially need to introduce um another ENSIP that can help us resolve a name record like a human friendly name like base.l2.f F um we resolve the chain ID and it gives us the 7785 chain identifier. So all this is to say there's a lot of ENS specific stuff that is going to be involved here. Um, moving on to my second point. Looking at the 7785 registry, we were trying to figure out um the

logic behind the attributes that are used to derive this 7785 identifier. And we wanted to, you know, some of them some of them um Oh, basically, let me let me let me send this and then uh we can rephrase it. Looking at the 7785 uh spec, we are using different attributes like the settlement ID, uh chain ID, we are using um the rollup contract. Let me just send the link right now.

Uh, sorry. Let me open the right file. >> Skelly, I think you also had some some thoughts on how maybe 7785 fits into this. Um, >> yes. Um, yeah. So regarding 7785 um the way we envision the resolver is for it to be uh very very flexible. So not necessarily we are tying this up for uh 7785 or any other let's say way in the future to come up with a strct or any subsequent ERC ens

uh to be able to define what extra data uh chain can provide uh that is useful for I don't know uh offchain or smart contracts or whoever to resolve right just using I know for example uh as you said like base.l2.th and you'll get the portal address this and that and etc etc etc right so you'll get a lot of the the cool uh very very useful uh addresses that some sometimes are very sensitive and people shouldn't go into like random websites to get those. Um the the other thing is that since we don't yet know uh what those uh strcts would look like nor we have the

information nor we have the ownership mechanisms for those to be uh properly handled. This is why we are kind of aiming to uh just release uh this more flexible uh resolver for now which will allow us to uh wrap wrap it um with uh any other let's say subsequent standard that we can all agree on that would be useful for for this change to populate. Um, having said that, uh, as well, I I'm not sure I understand the requirement for having to create a specific ENSIP

for something that already is an ERC such as 7930 or 7828. Do you think uh we should also create an ENSIP that standardizes or showcase how the resolver would work rather than just doing the spec? Okay, perfect. Okay, we can do that. That should be pretty straightforward. That's >> I want to say I do agree with what Kelly is saying. Um we needed to be as minimal and as

abstract as possible. Um I was just studying that we also needed to be NS compliant which um we can help. That's our area of expertise. So yeah. >> Awesome. Yeah. As Josh said, like yeah, we can we can take this on another call and we can definitely work with you guys. So you can I mean you have all the assistant that you all the assistance that you might need from from our end. Uh if you want to just champion that NSIP, we love that.

>> Okay, great. Um anything else on this topic? Otherwise, we can keep moving. Cool. Uh, up next we have the Axile team on 7702 and transaction batching. >> Yeah, thanks Josh. Good to see everyone. Ash from Axel. Uh, we're building a pretty consumerf facing app focused on DeFi saving kind of so just making it really easy for people to get access to USDC and then earning yield on it. Aggregate over a bunch of protocols and then automate uh the movement of funds between them. I'm here with Dev who's gonna go through a lot of the technical challenges we've encountered. Tons of fun stuff, but yeah, I'll just pass it on to Deb.

>> Thanks, Ash. Uh, so yeah, I products goal is uh savings accounts must die and we're starting out with stable coin investments. So, uh, currently we're investing in four different protocols all base and we're working on increasing protocols uh to be also on mainet, arbitrum, and polygon. I'll get into what chains we're going to support in a second. Uh yes, but but the key features our platform uh provides is all transactions are processed through a trusted execution environment with the signer always being in an enclave. So no one can see the signer. All signatures are verifiable for user operations uh in order to increase their yield per year.

Uh we've we've audited our entire application by Sherlock before we release into production last month. Um yeah, so we have uh our goal is to have the best yield across all our competitors not just through protocol diversification but also through multi-chain uh non-slipage deposits. Uh that's our main goal at the end. Um yeah, best non-speculative yield on stables and uh we don't really have a budget because our operating cost for this application is incredibly low as we'll see in one sec. So current integrations include Morpho, Oiler, Yo, Gauntlet, Walts all in base uh with an average API of around 10%.

Um like uh including rewards. Uh so there's literally zero gas uh thoughts on behalf of our users because we wanted to be as non cryptonative of an app as possible. So uh yep uh challenges on the technical side mostly include gas accounting uh and sequential processing that's what we faced with our previous applications previous iterations of our application. Uh so for gas accounting we always needed to ensure that uh that the native gas token is goes to zero which is incredibly annoying for users and us uh to manage and sequential processing meant that we were waiting for

transactions to uh process one after the other. And we did uh we moved to 4337 wallets uh but the session key management and uh and having the session key in accordance with user uh with user login because we don't want to uh create session keys with unlimited permissions and we also don't want that to be an issue on the user side while also giving them access to their wallet. Uh that that was an entire uh arc of just uh trying different things with session keys. But ultimately we decided it's best if users always have access to their wallets. With 4337 we realized that uh users would lose access to their

wallets if us or our bund provider go down for even a day. So uh yeah and then cross protocol integration and security and performance. These are some things that we focused on and uh try to make it as and as bleeding edge as possible. There's other market and operational reasons we've why we moved to the product but that's maybe for another demo. So I'll first start with the 772 implementation. So it's only available for all pectra upgrade chains which are currently uh base arbitum all OP stack chains and mainet for the most part. Uh so we are uh currently working on mainet and arbitum deposits for USDC.

Uh I'll get to that in one second again but goal is to have uh user owned EOA wallets with uh quum key signers right and uh we can shift these signers every few months or every few weeks depending on our uh our operations. So when the user first deposits money with us, we convert the wallets into 7702 uh which are smart accounts but that can also act as EOAs. We bundle all transactions so that all protocol deposits happen atomically within a matter of seconds. And for crosschain compatibility, we are uh currently working with hooks and CCTP. So that even crosschain, we don't really need to

uh compose transactions one after the other and we can just have uh minimal amount of transactions and waiting between deposits. Uh so our implementation currently deposits into these protocols in around 400 milliseconds including the trusted execution environment signing. Uh we've tried seven figures stable coin deposits withdrawals across uh this is inaccurate m this is seven pools and it's uh the the average cost is around 1 cent. Uh so this screenshot was taken when there was a gas spike on base which meant we were paying a bit more but I think it's still pretty impressive considering you can have around um 14 transactions in one

batch including approvals to all of these pools to uh uh sorry including approvals to USDC to spend on these contracts. Uh with pre the previous approach it was uh with EOA it was a dollar in gas fees and a minute or more in processing time for just one pool. So this is incredible uh progress and the user can always access their funds through multiffactor authentication which is also really uh really important. If if the user wants to go on oiler and moro and withdraw they can easily do it and we'll still detect it because we listen to ERC20 logs instead of uh instead of making contract calls every every few seconds. So on the user side, this results in gas uh gasless

transactions and seamless multi-protocol deposits as you'll see in our demo in one second. And uh we have an average APY of 9%. We're including more protocols every day uh in order to uh increase the yield for the user. On uh the DE implementation, we're using nitro enclaves on AWS. So this uh isolates our signing operations completely uh so that no one can go into even the memory and see what's going on. Uh we have an open- source signer implementation in the TE which you can find on our GitHub. And uh we also have custom policies enforced within the TE and also on multiple other layers of our stack to ensure that all wallet operations either uh transact

with a known user wallet or uh one of these uh 4626 wallets. for now. Um and then the round trip for this is around 200 millconds as well. Our upcoming features for the DE include reproducible bills and uh attestations for oracle pricing that we use for rebalancing in order if if we want to move the user's funds into another vault. We need an addestation that that is indeed uh that that a condition indeed was met of a higher APY or a lower token price. one of these things on uh so one one major thing that most protocols don't currently do is autoclaiming of user rewards. The way these vaults work is you get a base API

on the token shares that you get and also additional rewards uh that are volatile tokens and non-stables. So our goal is to convert the keys into stable coins as soon as possible in order to combat uh volatility. What we do is have websocket listeners stream plugged directly and we we listen for root set events from those from the reward distributor contract so that we can immediately take actions on them. Uh we also listen to the mercury because we need a proof in order to submit the claim for the rewards and then we can batch claim these for all our users using our own wallet. We don't even need the users wallet to claim uh to claim rewards for them. the rewards will

obviously stream to their wallets uh immediately. Uh and I think the last step uh is swapping rewards to stables. So we we've been using software aggregators like LiFi, Unison and uh 1 in and Audi and so on. I think uh uh we're working on this. I think this should be out in a few weeks time but yeah uh we just reinvested. So your your returns are always compounding as uh as soon as it can be. This is the technical diagram for our claimer service. Uh what we're doing is literally just listening to log events and as soon as we detected we uh we send it to the claimer. We send the request to the claimer contract and

uh the rewards are then streamed to the user's wallet. Um lastly uh we're currently working on CCTP crosschain swaps. This enables us to have non-slipage deposits on other chains. Let's say the user has USDC on mainet, but they want to invest on base boost or vice versa, they can do this without any slippage, which I think is incredibly important. If a user deposits um let's say $5,000, if if they even see 4,999.99, they're going to lose their about where the money went, right? without any disclaimers that doesn't make sense um to most our users. Uh and this this uh I think this approach will obligate all of

those issues where if we have a uh burn and mint on the source and destination chains, we'll get the exact amount of circles circles token. And for non-circle tokens, we're thinking of using layer zero that enables us uh with hooks uh after the after the mint has been uh finished on the destination chain and then we can uh concurrently deposit into the 4626 vault uh directly. Uh so yeah I think to wrap up my transaction flow is just the user action and always the user action as you can see in our uh in our GitHub is uh >> is process I'm sorry yeah I'll

>> yeah uh yeah future road map includes crosschain and then uh also smart rebalancing non4626 protocol integrations like pendal and real world assets as soon as we can. Um, this is a brief demo. I'll just show half of it. So, uh, yeah, I'm already already invested in it and I want to withdraw from all these positions. It's as simple as just two clicks and then you can see on the block scanner that it's already there. One sec. Yeah. Okay.

Yeah. All these transactions were um, and you can access this wallet as well, by the way. So, that's nice. Um, yeah, I think that's it. Uh, go visit axel.com. Um, it's pretty fun. Uh, we have a mobile app coming soon by the end of the month hopefully. That's all. Thank you. >> Cool. >> Thanks, Dad. Last up, 7806. >> Uh, I need to share the screen. Yeah, I believe everyone can see can see Yeah. Hi group. Uh Ian, I work at circle

and this proposal uh 7806 is about a minimal intense entry smart contract account. It's a SCA standard bill 4 to72 error. So it works with EOA. First of all, just clear the terminology that the intent we are defining here is like a type of outcomes that the user want to achieve. It should be like pretty simple uh unified human readable which is kind of very important for user experience when they see when the user need to understand what they're signing or what they're approving and it should be execution agnostic which means to or to achieve this outcome the solver or relayer can do whatever they want but

the intent layer will make sure that uh the outcome is always correct and the motivation we have been seen in 10 in offchain application a lot of times is like when you taking Uber, you set up your current location and destination and broadcast to the Uber network and somebody will pick you up and want to achieve similar uh user experience on trend. We make want need to make sure that the intent is non-custodial very important and it's verifiable on trend by anybody. So if I provide this signature that's from me and only me can sign it and it's can be easily converted to any prescripted uh operations basically the solidity destination value core data pair and we want to change

user to control or interact with their accounts through intents and account on chain can correctly understand those intents and carry out the operations in in a good way. Yeah. And intents are by nature interoperable because it is like a abstract layer of the uh the result user want. So we only keep the core elements from users demands. For example, taking the very common use case is token swapping. Basically every token swap is just sending out a specific amount of token A and taking in a specific amount of token B and that's all. It actually apply to any chance, any applications, any token, any amount.

You can swap with unis swap curve, any onch protocols. But basically the user is just trying to achieve this intent. And yeah, intents are also uh within single trend. Intent are autonomic and can be matched directly without the need of any other smart contract to be engaged. For example, we have two swap intent. The first one uh swapping out USDC for USDT. The second one they want to swap out USDT for USDC. And as long as the gas fee can match with these two orders or these two intents, we're actually having a deal. We don't need any like uh AMS or other smart contract on trend to keep to uh trading for for

the intensometers. we just match me match them together directly because this step can be done offchain in a very high efficient way. It's pretty scalable and uh with the intent defined in our 7806 standard. It doesn't limit it to for you to have a sequence noun re-entrance attack. It can be it can be uh it even the attack can also be replace replayable. So which means multiple intents can be executed in parallel for each user and uh also the our 7806 SCA support all the basic smart contract account

functionalities like gasless on transcription batch on transcription as a delegation is fully customizable and modular and uh we're building for 7702 because we think it's a huge milestone for for intent Basic uh fundamentally it enable EOAS to verify their own intents which is very important because if you dedicated this verification to another smart contract it basically turn into an escal or another protocol that it that like it's just the traditional way of how uh relayers things work on on chain but with 772 everybody can verify their own intent so they can use their own

standard they can define their own way to keeps things secure for themsel and also keep the intent layer uh unified and interable across multiple accounts. Uh we have a website erc786.io uh feel free to check. We also have a playground that basically demo how to how everything work from creating a wallet to upgrading to SE uh 786 to carry out on trend operations and then in the last step we are able to execute a batch transaction using the token which just mean yeah uh I'm running out of time so I will not go into details about all the technical implementations and how it works but just rest assure

everything is pretty simple our standard only define two interfaces is with three uh APIs and that's all. We leave everything else for the developers to work to work on and hope people can uh start trying with the standard and see what kind how simple it is, how easy it is to use and if everybody can get together to build an interoperable intent layer. I think it will resolve lots of gaps uh between different wallets providers, different applications and definitely help a lot for crosschain intent as well.

Thank you, Han. I think you have a couple questions in the chat. And do you have a link to the Excali draw? >> Maybe you could share it in the Telegram later if possible. Oh, >> of course. I can just share it. And >> I think Ash had a question as well. Uh >> yeah, I was just curious if there's like a circle specific use case that you guys had in mind because this is pretty general and cool, but yeah, just curious. >> Yes. So uh this is not specific uh or circle products or raised by uh like proposed by circle. is just I I come from I come on circle and work with lots of uh web two customers and this you can

you can feel that they their uh demand of using crypto is like they don't want to really know the technical detail about that they want to move this liability to a relayer or trustworthy partner and and in that case we right now if you are thinking that uh all the CCTP stuff you just mentioned and all the other interaction with USDC is still transaction based. You need to know what you're actually doing. You're sending out this token to somebody else and uh you're trading with unis swap. You're trading with curve. You don't have to but it's good if you understand how those contracts works. But if we can take this layer abstract abstract technique out and only have user focusing on their intent and yeah and

then it will be much easier for everybody to to use those products and the underlying contract protocol can switch while keeping the intent always the same. For example, the swap token intent I don't think it would change uh like it it doesn't need any modification. It would just work forever if you're swapping two type of tokens. And this is what you need. Unless ERC20 is broken, we will introduce a new standard. But yeah, that's bas basically the idea here. Good stuff. What's your uh telegram? Let us >> Yeah. Yes. In the in the chat as well.

Yeah. >> Any last many questions? >> No, I think that's all. >> Thank you. H. >> Thanks, George. And here's his toilet for him. There you uh cool. All right, we can end it there. Thanks everybody. Sorry, a little bit over. See you next time.