L2 Interop Working Group #9

Transcript

Cool. I think let's get started. Uh yeah, thanks everybody for joining. This is the L2 interop working group. We have a really solid agenda today I believe. Uh and excited to yeah just jump into things. Um I yeah I guess there I can just uh hand it off actually. So, let's jump into agenda item number one, which is a few quick updates on ERC7786 crosschain messaging. Yep. Thanks, Josh. So um just a few updates here on the last um over the last few weeks we have had a series of technical calls um involving people from

uh Defi Wonderland, Espresso Glaces and the purpose was to agree on you know any potential changes to this ERC and on the exact messaging interface to propose. Um you can find uh some notes from this call in this link. Um we had quite a bit of back and forth about the exact extensibility mechanism to include. Um but as of last week we've settled on a design for the core of the CRC that we've agreed to freeze. It is now in an open PR.

Um, one of the the uh changes that's included in this PR is uh now the adoption of interoperable binary addresses. Um, this new uh standard that is also coming out of this interrupt working group. Um, and that is the only thing that's that's blocking this this this for me since that's also a for now um an open PR on on the ERC's repo. Um, a couple of things that we will be working on in the future are the an interface for paying for gas uh for messages that are sent crosschain. Um, and uh potentially some

other uh things built on on the extensibility mechanism. Um, but the gas payments is is one of the main ones. And yeah, that's all that I had to share. Thank you, Franjo. Cool. Uh, up next we have some updates from a recent interop event in Athens, Interropolis. Um, and I think a few other notes as well on an upcoming Interop event. Maybe starting off with uh uh Yeah, I can start off. So, uh, last week was Interopolis. Um, it was a very good event. Um I'll share some of my

takeaways and then Jim also will share some of his as well. Um so we chatted about 7786 quite a bit. Um and just like the incentives around that. Uh I think that we kind of all recognize that 7786 is going to be difficult to make successful but we think it's important to still work towards it anyway. Um we also discussed about what apps actually want out of their interop uh infra. And so the things that the core components we came down to were that apps and their users want uh speed. They need uh execution guarantees. So no failed transactions and then the apps need access to users from other chains and liquidity from other chains. And these

are the four most important things for crosschain apps. Um and so any sort of interop infra needs to provide that. Yeah, unfortunately security was not on that was not on that list. Um the other big takeaway I think uh was that a lot of interop and chain abstraction stuff really uh should be happening in the wallets because the wallets is where the user is first interacting with a chain and really the wallets are the ones that have the power to create a very seamless crosschain experience. Um so I think that was uh the other takeaway. Um, and then I think my final takeaway also was that we had a really good AMA with the

EF and um, I can post the picture of the whiteboard we have. Uh, but uh, yeah, I think uh, a lot of the, you know, EF goals were very aligned with a lot of the goals that the rest of us there wanted to see. Um, for example, uh, signaling about which, uh, ERC's, EIP, you know, maybe certain people in the EF support, not like a formal support, but just kind of signaling that they like read it and they think it's a good idea. Um, we also talked about the EF doing more wallet research. Um, as well as faster finality and shorter slot times. So, um, yeah, that was that. And then also before I stop, I will plug that we have

in about two weeks, two and a half weeks, we're having interop days at Zoo Berlin. So this is the kind of the same week or the same chunk of time as Protocolberg and all of those other ones. So we'll have two days of interop. Right now the plan is that the first day is going to be focused on kind of short-term practical interop like what are the problems we have at this very moment and what do we need to solve? Um, and then I'll be leading that day. And then the second day will be kind of more long-term focused on like the vision of L1 interop, native rollup interop, etc.

And Luca from L2B will uh kind of be in charge of that. So if anybody's interested in coming to that, we would uh absolutely love to have you. Cool. Uh, and I can add on to that. Um, first just want to say uh I'll also be at Zuberland. So excited to see Ellie and crew uh there too. Um secondly, um yeah, Interopolis was great. Thanks to Helena and Dylan uh from the Sprinter team from for planning that. That was like a really really cool event. just 48 hours of just straight, you know, nerding out over interrupt uh stuff and and and that was like a really special experience that I personally haven't been to a conference like that um ever really in my crypto career. So, that was

cool. Um, in terms of takeaways, I also want to echo that there was just like a lot of interest for the the EF to have kind of more dialogue around with builders around what standards they want to coales around in order to improve the crosschain experience uh between roll-ups and also with rollup to to mainet. So that was like definitely uh such a big takeaway for me that I want to just repeat what Ellie just said. Um and then um new stuff. So we also uh ran a few sessions uh on uh two topics. One was on solver economics. Um so around how do you um you know incentivize more solvers to participate in the system.

What can you build in order to uh do so if it's you know public goods or or open standards uh in order to uh involve more participation on the solver side. It also kind of got philosophical in terms of you know do we want to have more solvers? Do we want to build incentives to have more solvers or is it okay to have solver centralization and have wintermute basically facilitate all this flow. So uh you know solver stuff always gets philosophical really quickly. Uh and then lastly we kind of coalesed around auction mechanism design as one lever that we can pull in order to incentivize more participation more than just like a vanilla first come first serve or even like a Dutch auction. you can have scoring, you can have, you

know, exclusivity windows and so it gets pretty interesting of a design space. Um, and then the second thing we talked about was resource locks and just, you know, talking about various implementations of it. um you know with the compact and in some other implementations and it was basically just kind of like a a 101 or a 202 session so to speak just you know showing people what resource locks were how they're different from the standard flow that intent protocols have right now and what the benefits were and the different types where we have onchain versions like the compact and you have off-chain versions that you know maybe rely on some sort of MPC scheme uh and would need maybe some additional

reassurances on top of um 7702 in order to enable that. So that was a pretty cool discussion. Awesome. Thanks, Jim and Ellie. Yeah. Uh just plus one. That was uh yeah, really really great event. really appreciate the Interropolis team, solver team for uh sorry, Sprinter team for for putting that together. It was great and uh yeah, excited to to see more people hopefully in Berlin. Cool. If there's nothing else on that on Interopolis, we can move on to

the next agenda item, which is a few quick updates on the open intents framework. Uh, one second while I actually have a few slides I will share here quickly. Just give me one second. Oops. Sorry. Just need one minute. Having some technical difficulties. Apologies. One second. Sorry. Cool. All set. This should work. Okay. Uh hopefully you can see my

screen. Just yell if you cannot. Um yeah. Uh okay, cool. So yeah, starting off with this quick update on the open intents framework. As many people here I think already know this is an effort that was initially seated by Hyperlane EF and a few others late last year early this year. Uh the goal from the start was to have a a maximally open and neutral framework to accelerate getting intense based systems on all chains both existing chains of course and new longtail chains. uh open and neutral are are key characteristics

here. But I think just as important or in some ways even more important here is that this needs to be a solution that delivers a highquality experience to users both uh both developers and and I guess end users of course. Uh so as we started iterating on this and discussing what's the best possible version of this open intense framework uh I think it it quickly became obvious to many of us that the best path forward here was to expand the group of core contributors to help drive this forward again both to deliver a neutral product but also to deliver a a high quality product that we can actually get into the hands of as many users as possible as quickly as possible. So with this um again just this is a some some of this is is sort

of already been shared on previous calls but just as a quick recap this we're we are calling the open intense framework 2.0 uh not to you know overdo it on the marketing but just to sort of uh to to separate out what this new initiative is. Um super happy that we now have Lei Across Open Zeppelin and Hyperlane all coming together to drive this forward with folks from the EF and yeah uh so just quickly recapping the goals of the OIF 2.0 as a bit of a refresher again. So this remains unchanged from the 1.0 know needs to be dead simple to get intense base bridging to all chains.

Intents aren't a silver bullet. Of course, they don't magically get us to this fully chain abstracted future. Uh but they do help to solve real user pain points today in a really meaningful way. Um which is why myself and many others are excited for them. So who are the customers of this? Both existing chains and new chains. a bit of a second secondary customer here are the solvers. U there are of course uh different classes of solvers in terms of more institutional highly sophisticated solvers uh and those on the other side of the spectrum. So uh TBD if we can solve problems for the more

institutional solvers or or sort of like what you know what we are best positioned to solve for uh these players. Uh but I do think there is a path where we can develop some components and tools that provide value to a large number of solvers in a real way. Um and yeah again this is something that that many folks who are part of the OAF 2.0 have been thinking about for a long time. Open Zeppelin, Levi, across Hyperlink, really everyone. Uh, and just as a quick note again, like for anyone who wants to provide feedback, input, get more involved, please message, message me, message any of us involved.

Um, again, this is um still somewhat early days though we we hope to hope to move quickly here. Um, so yeah, let me go to the next slide. Um so yeah uh how are we actually uh doing work with this uh big collection of diverse teams joining together on the OAF? The default for these kinds of of group projects probably is that it moves slowly eventually grinds to a halt delivers a lower quality product than than a single team would deliver. But I wanted to share just a few thoughts why I'm bullish that I believe this won't be the case here for us with the O of and

hopefully I'm not uh eating these words in a few months, but and you know something that that we'll have to continue to be mindful of the the way that we're splitting up the work um it just makes a lot of sense to me. Um which is basically dividing it up into the work streams that that you see here. Um, anyone that's on the call and is uh leading any of these work streams, feel free to to jump in here in a second, but uh if you have anything to add. Uh, so all of these work streams will be worked on in parallel. Of course, won't all be delivered in the same time. And um, yeah, I I I don't want to uh, you know, have any of us commit to timelines um, at this point since it it may be a little difficult or just too early to

say. Um but just maybe spending a I I can just maybe share a bit here for uh this workstream one the smart contracts workstream. Um this is likely to be delivered first. Um partially because we are very fortunate and grateful that that le that this is something that the Levi team has been uh working on for for quite a while that they're not starting from scratch here. Um all of Ethereum will will fortunately get to leverage and benefit from this. Um and just really quickly some of the milestones here in in this workstream one uh is includes integrating with compact which is something that the unis swap team has uh been working on for for a while here

uh shipping intent expression smart contracts shipping onchain auction smart contracts and shipping crosschain verification module. So just to give sort of a brief taste for what what is in this uh this workstream here. Um yeah that is most of what I had here for um just wanted to to share those uh sort of updates and and refresh on the OAF. Anyone who's been involved in the OAF um if you have anything you want to add feel free to jump in right now.

Otherwise I can uh yeah keep going. Just give you a Oh go for it. No, Jim. I was just gonna give Josh a shout out for pushing this forward. That's all. Yeah. Uh, agree. Josh, you're didn't add your own name into the the work streams. Um, so yeah, calling you out on that one. Um, so yeah, just just maybe like the super brief update on on the OIF. So, um, I think Alexander shared the link for the repo for the OAF. Um, and so we had our initial uh few commits there for uh the smart contracts workstream. Um, it's like what Josh

said. It's basically just like a bunch of interfaces that can um, you know, connect to a few modules that have different ways in which you can express an intent, whether it's through um, you know, resource lock or a non-resource lock, whether you can configure different um, oracles, whether you have different auction mechanisms. Um so please do take a look at that um and and any comments or you can reach out to us and we can talk about it because yeah I mean we we hope it's you know the foundation of intents uh for the Ethereum ecosystem. So want to make sure everyone feels bought into looking at it and um you know adding comments into how it can be more uh modular or could be even more extensible uh or even more

permissionless. And so yeah that's that's it. Cool. Thanks, Jim. And yeah, it was a good point. I did leave out the coordinator workstream, which myself and the EF is leading uh less in some ways less critical, but also important role here. So, yeah, excited to be serving in this coordinator workstream as part of the OAF. Cool. Um, well, yeah, thanks all for listening to that update. And then next up, we have some updates on this interrupt wallet work that has previously that we've previously touched on on on prior calls, but maybe didn't

dive much into. Um, still a bit early in in this work, but I just wanted to make sure that that we're keeping this group updated, sharing a bit more like what what this thing actually is, where did this come from, what is our goals, is this the EF making a wallet? No, it's not. Um, but but what is this? and and and why is this something that um yeah that I'm excited for and I think will help to uh to drive UX crosschain UX forward in some hopefully very meaningful ways. Um yeah and so for now we're calling it interop wallet. We do need to find a better name for this soon. If anyone has suggestions maybe we can do some crowd sourcing at some point. Um but yeah anyways at a very

high level the idea with this project is to create a test net only proof of concept wallet to help accelerate UX improvements um specifically in the realm of crosschain UX but also eventually touching on other things such as privacy. Uh again like to be clear just to emphasize this this is not the f shipping a wallet. uh but I wanted to uh yeah just spend a bit more time on on why this testn net proof of concept can still be a very uh high value initiative. So yeah so so so what is this interop proof of concept wallet?

Well we have all of these emerging standards around crosschain UX. Uh we also have a bunch of other lowhanging fruit that's been out there. Um, and so like how can we um as an ecosystem, we as the EF and we as as other teams involved in this and I I should I I neglected to mention this at the beginning of the slide, but um Wonderland is is really uh the key contributor here helping to drive this forward. Not not just the EF, not just myself, but um just quick shout out to the Wonderland team who has been helping to do all the heavy lifting behind the scenes to um to yeah help get this off the ground. Um and also as a note we hope to expand the group of contributors here beyond the EF in the wonderland in

the very near uh EF and Wonderland in the very near future. Um so yeah so um and also I should also say here that um I want to give a shout out to the AMIR team. So what's the fastest path? Well, we want to take a very pragmatic approach here on this wallet. The fastest path is start with an existing highquality wallet. In this case, we landed on Ampire. Can can share more around why we uh really um fell in love with with Ampire as as a great solution in this case. Um but just as a as a quick note there that that's what we're doing. We're starting with Ampire. We've started with Ampire as as the base. Um and uh and and the idea is let's let's pave the path. Let's let's demonstrate

in sort of a more practical real world. um scenario like what what these uh what these crosschain standards can look like and and getting into people's hands even it is just as a as a proof of concept. So as a quick summary let's validate standards in a in a real world context. Let's provide a blueprint and and perhaps even sort of a reference implementation that other wallets can can adopt. Uh we do hope and strongly desire to work with wallet teams uh as as we are iterating on this many teams uh MetaMask Phantom

uh Zerion I'm creating some of the others that that we've already been in contact with. Um but there's been many wallet teams that I've already reached out and had conversations with. It's been great. really appreciate all the wallet teams who have their own existing road maps and priorities of course but they've been really great in terms of uh working with us on this helping us learn helping us uh better understand how we can collaborate on these kinds of things and uh you know I want to acknowledge of course that um like we are this is something where we have um a lot to to learn ourselves uh there's been a lot of of great work that that's especially in the past few months with 772 and other things in terms of wallets starting to to innovate more and more on UX. So, how

can we just act as an accelerant to that? We're not going to, of course, uh replace that work, but just how can the EF and others um with this wallet initiative, how can we accelerate this um and and then 10x the the crosschain experience in in the next few months hopefully? Uh and point three here I guess just to maybe hit on that really quickly is um this will create hopefully a nice feedback loop where uh it informs we were able to take lessons from this as we're as we're iterating on it and and help to inform and improve the standardization work as well.

So really quickly um just one or two more minutes on on this interop wallet work sharing a bit of a road map here phase one which is underway focused on accelerating seamless crosschain transactions. What does this mean? It means leveraging standards such as 7828 chain specific addresses which again the Wonderland team has and others uh from ENS team from ZK sync team many others have been have been helping to uh push forward since really since late last year um it's been a bit of a slo but really excited to sort of be approaching the finish line here with uh 7828 and uh yeah the next agenda item actually Wonderland team will we'll share some updates there um this will be using an

adapter layer so we can easily switch out what's powering the crosschain transfers under the hood starting with intents but later exploring other solutions. Uh sort of just a guiding principle here is as much as possible like maximizing pragmatism and and not reinventing the wheel. If there are existing UX patterns if there are existing uh trust minimize building blocks that we can leverage we will. Um and then uh yeah part of this uh sort of like the main focus of this phase one is creating these uh not just sort of the backend the uh and plugging into intents and but how do we create these UI components in a seamless way for

displaying and validating these uh chain specific aka interoperable addresses so that you can enter something like Alice. at base alice e atar arbitum alice eeth at pick your favorite chain uh and have the wallet handle the rest you simply select the asset hit send um and everything else is is handled for you automatically under the hood um so this is leveraging both the uh interop wallet and chain specific address work um that's the yeah that's the that's the gist of phase one phase two uh the p the goal right now is to shift the focus a bit more into privacy realm. Make privacy native to the wallet experience, meaning one click, frictionless, uh

don't need to uh jump through a bunch of hoops. Having something that is a protocol agnostic implementation starting with Oxbow and privacy pools. A mean and many others have been pushing this forward. Uh really excited to to leverage this work that that is has been years in the making. Uh and we'll also design this to support other privacy systems in the future. Uh so what what will this look like? Shielded balances, private transfers, and also cross-chain private sends. And I have just an example of what this flow could look like here. Um this may be obvious to folks that are somewhat familiar with how privacy pools work. There are some limitations, but uh I I'm optimistic that we can get this to still deliver a

really high quality user experience um as we continue to extend and improve the privacy works the privacy pool work as well. Um yeah, I won't read I guess all of this, but you can kind of get a sense for um needing to deposit into the privacy pool before you can then withdraw from the pool uh to whoever you want to send to and hopefully routing using something like a 4337 me rather than uh a relayer which might not be as privacy preserving. Uh and then just wrapping up sort of the phase three, this hopefully won't be the the end of the wallet work.

Hopefully this is something that we continue for months uh to to go um extending into into 2026. We'll we'll see. Just sort of taking this uh these these three phases for now. Um but you know what is the next phase of this additional interop work continuing to iterate work towards uh endgame interop making se making crosschain swaps even more seamless and handling even more complex transactions. exploring what it what does it mean to really enter this fully chain abstracted future. Um things that um actually the unis swap team I want to give a quick shout out as well that have have really shown some some really amazing demonstrations recently around um like what does like a unified

balance look like? What does batch spending look like? I think these are things that we also want to play around with. Uh yeah, not just unis swap, reown, meta mask, many others have been working on this for a while. So we get to stand on those shoulders and and hopefully um yeah, continue to iterate also leveraging standards like 5792 and and 7811. So yeah, that was it. Hopefully that sheds a bit more light on what this interop wallet name TBD U project is. If anyone has questions, um yeah, happy to to talk through things.

and and yeah, feel free to reach out to me if you want to get more involved. Um, still somewhat early days, but yeah, really excited to to see what we can do here with this interop wallet project. Uh, and yeah, if anyone from the Wonderland team who's here wants to add anything, feel free to to jump in now. [Music] I think it's a very good overview. Thank you, Josh. Cool. Thanks, TT. and and yeah, excited to have Titi who uh who actually is um yeah, just recently joined the Wonderland team and and has been doing an amazing job to to drive to jump in and to drive this uh this wallet project forward. So yeah, thank you to to TT here. Um cool. Okay, well I guess that's a nice segue. Then I will stop

sharing and I can hand it off to you TT for the uh next agenda item. Let make sure I do this correctly. No more technical difficulties. Cool. Um, so yeah, next up we have an update on chain specific addresses aka interoperable addresses. Perfect. Uh, I do not have access to share but um to share screen but I just shared the link of the presentation if you want to follow me. Cool. Uh, so I'm going to you can you can share now if you want but yeah either way. Okay, perfect. Give me there. Hope you can see my screen.

Perfect. Okay, amazing. So I'm going to do a quick overview about the intraural addresses standards that we are working on. It's the 7828 on the 7930. The format is this syntax you can see over here of the address chain hashtag the checksum and we have splitted the efforts into two standards uh because they're aimed for a different target audience. The 7930 U defines the binary format of this um interoperable address and it's almost ready to be merged to draft. Um we have addresses um the the comment that the editor left us was

regarding like um a link reference. So now it should be ready to be approved this week. And I know that 776 is referencing this one. So it's important for that standard as well. So just FYI by this week uh you should have this ready. Um and then 7828 uh represents the human readable names of these interro addresses and we are using and regarding that um Teddy already like in other uh working group calls share more uh details about this and you can go to the standards if needed for more specification. I I would just go on a high level overview right now because

there is a change that I want to to present is is regarding the chain list migration and I will go over that in few minutes. Um this will be quick though. So one small thing I want to mention about the interresses is to for us to be on the same page on how this helps improve the the UX and mainly uh provides this an ambiguous way to refer to an address on a specific chain of course uh but this helps to mitigate the errors when interacting crosschain and also to specify the the target address both for like user addresses but also for for assets. So, it's really improving the UX and mitigating errors.

It's really important and also um allows to create more smart flows and automations where the wallet can know where the payment is expected to be received based on the information the address is providing. So, some of the addresses would look something like that. Uh the one we expect to be mostly seen is this one where you are using ENS and for the for the chain portion um what we are suggesting and we are expecting to have fully define in the next two weeks. So regarding the standard uh the the timeline we are defining is two weeks. Regarding the

implementation might take a little longer but I will go over that in a second. So what are the next steps of 7828 to get it finalized? The first thing that we are doing is that we need to fork the Ethereum chain list. Uh this is because we're going to polish some short names to be more um user friendly. Um and then this needs to go through consensus with all the rollups for it to be register on chain because the end goal is instead of um fetching the information from the GitHub list we're going to get this information on chain and to do so the first step is that um

we are already working on it and we're going to do a proposal to the NSL to get uh L2. So with that we are going to create a custom resolver for the short name of the chain and the chain ID. Um and this will be resolve uh on the human uh readable name of the interal addresses and what we are aiming for is so if you check this one there is no top level domain uh under the hood what's going to be is a region.l2. Um so that uh mainly like the specification of this custom resolver is what's being worked on and will be all um specified on

7828. After that uh we will move forward into the development of this custom resolver to be deployed and then used. But in the meantime uh what we're doing uh aside from the from the wallet development that is um um yeah it's getting paralyzed is an SDK development for all wallets to consume these methods for a better UX in interparable uh at home. Um so what we are doing now is this uh SDK method will consume the information from the centralized list on GitHub but for wallets to consume so I expect uh two weeks from now for wallets to be able to consume this and to be fully specified as I mentioned um right

now it's going to be get consumed through the GitHub list but then it will be migrated to the onchain list and for the wallets they will just need to upgrade the the version of the SDK everything else will be handled uh under the hood so shouldn't be like uh shouldn't generate much friction but that's the blank person um I would love to hear like your thoughts on it and of course we can continue this discussion on each of the of the standards on GitHub and one more thing this like we are thinking of as a long-term solution for the decentralization of the chain list involves 7785, but we are still like looking into

it and we expect to get more involved after these two weeks and finishing 7828 uh because 7785 uh sort of breaks a little bit um with the with the format of the 1080 type. So we're thinking this as a long-term solution for later and proposing this as the midterm solution in improving the interal experience. And that's all I have. We have one question from uh yeah comment. Hey will this uh short-term solution will it not become permanent?

They have a tendency of becoming permanent unfortunately. Sorry. You mean like you think this will become the permanent solution instead of Yes. So these short-term tendencies sometimes they become long-term, right? So uh are we sure that it's just a short-term solution and it will not be forever basically? Yeah, I can jump in. That would be Yeah, I can jump in real quick. Uh the main purpose of as I said on the chat but the main purpose of the new list like right now we do have a list but the names are kind of ugly to showcase uh for users like uh some chains have very very weird

names that are really confusing sometimes. Um so the list is mainly to be used as the uh first iteration for the seeded values when we migrate to the L2 resolver. So we definitely need a list uh or some consensus on chain names etc to basically bootstrap the onchain resolver which will have a governance after that's done it with just a matter of uh changing the SDKs to point to the resolver rather than pointing to the list and we can deprecate the list and any new chains that want to register will be pointed uh to register through the appropriate process uh on chain

Uh Christian, yeah, I have one concern about, you know, I know one of the goals here is to make the naming, you know, prettier and human readable. Um, but what will happen if a name of a rollup changes, right? Like at one point OP mainet was called optimism, I think. um some roll-ups could get renamed over time or you know the yeah the official name changes. So like obviously in the you know um traditional like TLD space I mean people do redirects right at one point Gmail had to be renamed Google mail in in the UK and it was like well you know if you have a Gmail address they'll they'll just redirect it for you but your your email address going forward became at

Google mail right so um in this new model with like an onchain registry I mean what happens in the future if one of these rollups wants to change their name and wants to change the sort of like address uh that everybody uses to to represent themsel? That's a great question. Uh I mean, as long as they don't um collide with each other, they can create a new entry and both uh options should leave on chain. Uh we we definitely don't want to support um let's say changing the name uh forcefully. for example, as you said, like replacing optimism with op mainet or the other way around because that

would break a ton of things. So, ideally, um as long as they don't, uh step on each other's toes, uh they can register uh additional names. We don't really see this happening a lot, but in those edge cases that might happen. Uh there is nothing uh blocking them to just register a new entry. Okay, I think that makes sense. Yeah, thank you. Amazing. Yeah, no problem. Cool. Thank you for the questions. Any other questions? Awesome. Uh well, thank you

TT and Skellyy and this was great update on 7828. So then I think we can move on to the uh yeah to the final agenda item which is we have VC from socket team sharing a bit on their recent work on filler vaults and liquidity for intent markets. Is VC here? Yes. Awesome. Hello. Hey folks. Hope you can hear me well. Um let me try and share my screen. I don't use Zoom often, so let me know if this is the right. Hope you can see my screen. Yep,

perfect. Perfect, guys. Yeah, this uh last week or maybe this week, I don't seem to remember, we posted something about filler walls and the idea is to sort of like deepen the liquidity available in intent markets by using like hyperlquid like W systems. and I'll just like walk you guys through it. Um, these are like two highle screenshots. So, this is the one where you know you you try and send 500 or like 600k of a blue chip asset like die between two blue chip chains like arbitum and optimism and because like intent markets aren't able to do it unfortunately today. Uh, this is another

screenshot of how concentrated uh these markets are, right? So really um these intent markets today are used for like really small size um transactions and uh as things scale as these markets scale the liquidity dynamics uh sort of even get like more fragmented. Um so for us we were like how do we make this situation better? Um but before we do that I think the core inside here is today becoming a filler. Uh requires you to have skill and capital and the number of people that lie in this intersection are very small.

People that have capital don't necessarily have the technical sophistication to run a filler on any of these intent protocols and people that have the skills don't necessarily have the largest like you know access to capital for them to be productive on these markets. So ideally we want to be in a world where we can decouple this where anyone should be able to come up with skills sort of like searchers where you can be like really smart at indexing the chain reading what's happening on chain and come up with like this technical sophistication these skills and anyone else should be able to fund this like fund capital to this strategy so we can use those skills and capital together and solve for these like intel markets.

Um and this is not something completely new like demand for this somewhat already exists. So HLP walls that I mentioned before on hyperlquid were used as a mechanism to bootstrap the perpetual the the per order book right and at some point uh via the screenshot um 50 to 75% of the open open interest in the platform was via these vaults and what what happened was the order book is like bootstrapped this way and then the sophisticated parties like enter and sort of like you know really make this market more competitive and liquid but you need these sort of like systems to sort of um initialize this markets and sort of like at that initial sort of like threshold otherwise these intent

protocols are stuck in this like chicken and egg problem where users don't come because there's no liquidity market makers or fillers don't come because there are no users uh we also have a screenshot on the right uh talking about how arbitum foundation is willing to sort of like loan uh funds to solvers right there is no mechanism why they can do this today it's very manual uh but it is a clear insight that chains and foundations will want to help with the capital and users would likely want to access the filler yield as well uh which is likely uh very high uh at least for the smaller amounts. Again there are no like numbers on this so very hard to say how much that is but it is a source of yield that users can participate in.

um how this is built. Um so sort of enables and anyone to build these like verifiable strategies offchain. These strategies have onchain vaults attached to them across different networks. So as a user you can just like put up funds on these vaults. U these strategies would include like logic like hey when should I fulfill an intent? Should I wait for one block? Should I wait for 10 blocks? What sort of settlement oracle should I use? Should I use the uma optimistic oracle? Should I use chain link or something else? What sort of rebalancing logic should I run? anyone can sort of like look at these strategies and then u sort of like deploy capital to these strategies. These strategies can then go and prove to the vault that hey I I ran the strategy uh as intended and I can

withdraw capital from the vault. Um I can also quickly walk you guys through this example of like um how this filler strategy works on across. So this is like an across spoke pool on the source network which is arbitrary as as a user you sort of like deposit um your intent to this contract. uh if the filler strategy gets sort of like triggered as soon as this happens it waits for let's say one block and then it sort of relays a proof along with the ZKP to sockets uh switchboard contract which sort of validates that the uh the strategy ran as intended and um post that we can sort of send an instruction to the vault that hey let's use the fund in the vault to

fulfill the intent. Uh the interesting part is uh and this this this comes with the socket like stack is that these um the the verification could mean anything. It could mean a ZKP. It could mean a quorum based attestation. It could even be run by some like single party that we all trust that just like signs off on it. It it could be run in a TE and u users would be able to like put a funds knowing uh the trust assumptions that come with it. Um so filler walls overall help with bootstrapping for new intent protocols.

It helps these intent protocols expand across different networks because you know chain and foundations can just deploy capital easily. Now uh it helps intent protocols get deeper liquidity in their markets and it helps users tap into filler yield. Uh this is not all theory. There is uh so there are like two QR codes here. One is a QR code for the full proposal and there's a demo video on YouTube where you will see there are two sort of like filler walls with differently configured strategy. One waits for say one block, one waits for let's say six blocks and uh both of these sort of like compete on chain to fulfill a user order, right? Um so yeah uh go check it out and this is an open

call. So if you want to come and build this uh socket can provide the infrastructure for you to build this and once you've like built out this sort of system bungee can provide your walled autoflow so you can onyield on the intensive fulfill. Um that's pretty much it. Um happy to take any questions. Thanks VC. Any questions for VC? Cool. I guess not. It was explained perfectly. Um, but yeah, I think maybe people can reach out to you on Telegram

if they have if they want to follow up or yeah, maybe drop a message in the chat, wherever you prefer. Perfect. Cool. All right. Well, I think that's all we have for this week's call. Uh, if nothing else, we'll see you all back here in two weeks. Thanks for joining.