L2 Interop Working Group #3

Transcript

uh let's kick things off this is interrupt working group call number three thanks all for joining excited to get into it uh lots of good stuff to share today uh and I just dropped the agenda in the chat for anyone that wants to take a closer look uh before we get into things I guess I'll just quickly repeat my my little Mantra sorry people are tired of hearing me say this but I think and and hope most here agree there's a lot of value in us being hyperfocused on what we can ship in the next few months uh and delivering something that can get into the hands of users and solve real problems of course it's also critical that that we do this in a way that doesn't prevent us from achieving our longer term objectives so my ask I guess is only that everyone in

this group helps us stay focused um on these things tries to keep conversations moving forward which which I think we've actually done a really great job on so far all all things considered um and yeah just please keep speaking up about the best ways we can we can all coordinate on this to to unify ethereum okay so uh yeah with that said let's kick off with the first agenda item updates from the message passing group Ellie maybe you can uh start here and then of course anyone else please feel free to to jump in um yeah could I share my screen real quick yeah sorry one second let me do that there you

go okay uh perfect um okay yeah so I recently just pushed a PR to the GitHub which I know we'll talk about in a bit but this outlines the kind of like status of the message passing working group and so I'll kind of go over it um and then a couple of other points so the working group uh message passing working group right now is focused on like a Dev inter interface or a Dev API so that uh you know developers have a single way a unified way to interact with cross-chain applications um even though the actual protocols connecting chains underneath that are going to be different depending on which chains you're connecting so um uh so here's kind of like the plan I

propose for us going forward and people can let me know what they think so so while we work on this Dev API that can be like one task in parallel I think it's really useful for us to uh work on using the like existing protocols in place so for example um maybe we can like make new isms for hyperlane or things like that that are have different properties and I think that this is important because it gives us like meaningful progress in the meantime and we can like still improve interop in the meantime while we're like deciding on this Dev API realistically the dev API even if we decide on it quite soon

it's going to take a long time to implement and have a lot of these core projects adopt it so like in the meantime we can we can work on providing more secure or or different kind of security assumptions underlying messaging protocols using the existing apis um because this brings me to I guess I think a a a concern that I have is that the idea of a Dev API in my opinion is very very good but having applications need to upgrade to it is kind of a really big ask so this is something that we need to discuss in the working group and discuss maybe the best way going forward um you know maybe we can take parts of existing protocols um and reuse them to kind of make these

things easier um okay so that being said uh here's kind of like my proposed timeline for just working on the of API itself um and then in parallel you know projects themselves like espresso can work on uh integrating with these other protocols so the timeline is that uh so first I want to identify like core contributors so I think that um basically have a small group of people that kind of are really active in Telegram and meet on a regular basis to push things forward and then every once in a while that small group will present to the broader group um like our proposal for feedback I think that this works because then no like the broader group doesn't have to follow along in this like huge telegram

chat and we have something concrete to for people to get feedback on so I want to like develop or um identify these core contributors and then like move forward with uh the message passing group that way um the the first thing task is that we're going to do is we are going to revisit like the goals and the properties of the dev API this is because as we' as we have been discussing um the goals that we thought wanted uh like a month ago have actually changed and we realized that we that something else is more useful so we're going to go through and agree on the goals the idea um thanks to Skeletor for this idea but the idea is that like in this GitHub we can actually document like the people who agree the reasons

why they agree the reasons why they disagree so this is all documented it's not just in Telegram and then we kind of actually have like proof of consensus uh that that people agree on us moving forward um so yeah basically the timeline is we're going to agree on these key things and then I feel like by the end of March like people should be able to start actually implementing this if I mean if not earlier and basically we'll have an interface finalized um the other uh part that I want to do is kind of establishing commitments and timelines for some core projects to adopt the API I think this is going to be a a bit of a difficult task but like

if we actually want this API to be useful the like major projects need to adopt it and that's very important that we get their Buy in so this is um also a goal that the working group is doing right now so um just quick uh I wrote down the goals for us to discuss I'd say um if you want to kind of be in this like smaller working group uh it'll still exist in the same telegram Channel probably just like uh maybe like let me know and the goal is that it's going to be very very active and then like once a week we'll present kind of to the broader uh broader group so with that that's kind of the update on the message passing group um does anybody have any comments on that proposal okay we can go to the next

group awesome thanks so much Ellie any other um yeah update comments questions otherwise I think we may actually just uh keep going to the to the next agenda item anyone has anything they want to add now let me know or jump in cool all right one second cool uh sorry agenda item number two uh so we have a new repo for L2 interrup which is great um kindly the folks from Wonderland have have jumped in to help us to put this up and organize it but this really is

intended to be an open repo for for anyone to to jump into um it's living in the ethereum org for now uh for neutrality but maybe in the future we we'll spin it out to its own own thing um yeah so we will have the Wonderland folks here today to do a quick walkr of the of the repo yeah thanks Jos and also thanks Ellie for the first um PR I mean as Josh said this repo is and an as well it's just a matter of um having things documented and easily accessible for everyone I mean we want this to be kind of the single source of Truth there are a couple of things I'm not sure if it's even worth uh to share

screen it's like it's pretty straightforward like you go into the repo uh that usually you will see uh documents under the docs folder we'll try to in index everything as much as we can um but the coolest part is actually under projects or on the issues uh and there like everything is pretty um like new and rough like it's it's mostly uh a work in progress and we really appreciate if you guys um do have like any feedback or any improvements or whatever or you want to start add adding like new new tasks into the project board uh there is a template uh to do that uh so whenever you create an issue you can just choose that template it should guide you pretty well or you can

use the existing issues slash tasks as an example um so yeah so the thing is um yeah I mean we still are kind of in this process of trying to organize everything and trying to kind of always bring back the focus into what uh should be say not important but should be kind of the first lowest hanging fruits um to tackle uh one of the key things that we been figuring out this past week is that intense is something that kind of uh merges all the categories that we currently have uh but it's something

that we shouldn't really rush through since there are still a bunch of things that we need to Define uh but I think that's a good uh carrot or incentive for us to try to tackle the the the other let's say the change specific addresses or the message passing or or similarly kind of a a standard for settlements um so I think yeah I mean sorry to for rumbling a little bit but the thing is go into the repo uh if there is something that you find is incorrect also feel free to review the PRS uh super welcome or if whatever you find that you want to add any information as well as as L just submit a PR um

we'll try to get more reviewers right now it's only Josh andas but if anyone wants to also review things more than welcome go zero uh apologies if we already moved on from from uh the message passing discussion but I I wanted to bring up go back to that really quickly sure yeah one thing I've been thinking about a little bit um starting to work with message passing a little more in depth um one component that I think

would be incredibly valuable to standardize around would be an to basically enable simulation of the message what I mean by that is if there is an interface that you can call and provide the same arguments that you would call to provide to the standard function and the response that it gives back is here's the chain identifier whatever we end up using for that here's the address

here's um like the from address on that chain this message is going to kick off here's the data that it's gonna provide here's the two address that it's going to call here's any value that it's going to add here's the gas that it's going to provide if it's relevant something like that because then if you're about to interact with a contract that in turn interacts with a cross-chain messaging contract or maybe the contract you're about to interact with is the cross-chain messaging contract so often the what you are doing is contingent on the message that's being received on the destination chain

actually working and doing what you think it's going to do like a really relevant example is a cross chain swap if I'm going to go fill on a fill chain somewhere I'm hoping that the message communicating that I filled it gets back and then I can claim tokens right or receive tokens back um if for some reason that uh cross chain message is going to revert then I will avoid doing the fill in the first place and I also want to look and see what's going to happen on back on the Chain where I'll claim um so that I can work out what

price I need to provide or whatever so some component it might be specific to these relay based messages but even in the case where it's not a concrete relay even if it's like a super chain inout right this method could still just provide the exact mechanics of what's going to be triggered on the output chain and I think would really help with building confidence on the Sol side when you are triggering cross chain messages a good idea um do you imagine that that would cost money though uh I think it would be a view

function that you would call it's a little hard right because the underlying infra still needs to like do work for you um so the caller would probably have to compensate for that work potentially I mean you could if if the assumption is that there is some kind of fixed relayer then you could provide that if the relayer is uh variable like there's it could be selected from a number of things then you could just provide like a null address basically saying we don't know that it could be anyone um for the the data in particular I think in the vast major majority of

cases the data is going to be fixed right if if the data that's being relayed is variable somehow then um yeah I mean the one the one catch here is many of these Rel layers do have like an ID that gets incremented or a nons that gets incremented as you call it so that could change and I think that's okay to basically say this is a snapshot point in time best guess just by running the code on the CH the origin chain of what is going to be relayed and if there's extra work required

then there's there's not a hard expectation that that's going to be available but there's still a standardized way to get you part of the way there and not have to because otherwise you have to roll your own in impementation of this by digging into the internals of whatever the protocol or the service that's running the the relay right well are you trying to stimulate like can I just sorry can I really jump in here I'm not sure like this is a really good discussion but I'm not sure it needs to have like everybody on this call having it that is so true and a good point I need to derail the agenda but I just wanted to bring this up and

we should take it to a more appropriate thank you thank you z i I would even say like if you have a draft spec or an idea draft or whatever do a PR on GitHub and then like if we can reference that and discuss that on telegram that would be even better yeah it's always good to have like a concrete thing to reference 100% cool awesome thank you all yeah thanks your agent and CJ and La for helping keep us on track here cool but um if nothing else we can um yeah we can keep going cool um so just one thing real quick but yeah I think we're ready for we're ready

for the third agenda item here which is um yeah we have a few presentations from teams all under this General theme of accelerating intents everywhere for ethereum there's been a lot of great progress on the intense front even just in the past two weeks um which has been really EX for me to see so yeah I guess let's just uh let's get into it and I actually need to share my screen here so let me do that real quick all right and you will see my

screen yes y looks good cool thanks uh cool sorry uh so yeah so so what's the goal here again accelerate intense everywhere and ship something in 2025 uh what are the needs and mus haves of of this we need we need to ship near terms Solutions and do so in a way that that plays nicely with our shared long-term objectives AKA don't destroy the uniquely valuable properties of ethereum uh and finding the fastest path to getting trustless cross chain sends in the hands of users in the next few

months so what's the problem here well intense are great it's not a silver bullet of course but probably most agree here on what they do really well the problem is it can take a while to get to New chains and and at the end of the day we need all of the flavors all the flavors of intent based interop to be compatible with each other that's sort of the name of the game so so how do we do that we need a shared neutral open intense framework that makes it easy for every team that wants to to adopt intense for their own their own flavors of interrup while also maintaining broad compatibility and again let's get it into the hands of users uh so intents are accelerating

this is great just in the past two weeks here's a quick overview of a few things that's happened not exhaustive of course sorry for any teams that are not here please reach out to me if you have things I want to make sure it's shared try just to you know have a quick sampling here from from teams that did reach out um and all of this here on the screen will be demoed shortly here on the call in a few minutes so there is a common pattern emerging this is something that I've been discussing with many people in the interupt working group what are these common patterns that are emerging and how do we better work together well the common patterns probably not a huge

surprise to folks here um yeah standard to describe intense the solware implementations and the settlement systems okay so how do we turn these common patterns into a shared standard well that's the tricky part of interrupt uh especially in a large diverse Community with strong opinions and tokens but great news is we have a path forward here um this is not I guess just to be clear and I'll repeat this a few times this is not intended to be the be all end all that every chain everywhere for all time must um must Implement of course this is simply a a a reference implementation and a framework to try to

unify the efforts um this defines the standard for intents this framework that we'll get more into in a second here plays nicely with uh 7683 for example and provides for uh multiple reference Sol for implementations and settlement systems and if anyone has questions or comments sorry I should say feel free to just to jump in at any point during this presentation just a couple more slides here uh so the open intense framework U this is something again that anyone in ethereum can contribute to and improve there is for sure much to improve again just an initial reference implementation with with more to follow

and a canvas that that every L2 and interrupt team can and and should add on to to me this is a critical pie that um in order for for us to achieve this sort of broadly uh broadly valuable thing what is it not this is not an enshrined implementation just a framework and the goal is to inspire more and more experimentation but in a way that is actually more broadly productive um and and also should give credit to all of the all of the efforts that are underway that are pushing in this direction there's and and we'll get into this here in a second but uh many many teams have been pushing forward with with intents and other things for a long time um again intense and and this framework not intended to be you know

com in here and and be the magical solution that will solve interop for all time but it's more around this goal of let's move forward let's maintain momentum let's ship things the next few months um and let's let's unite all of the interupt efforts under underway to the extent possible status um opening this up now this meaning the intense framework still early days let's move quickly and find the best path to making this adoptable and extendable by any team that wants it um a few just really you know these are not intended to be sort of um official uh official splashy announcement here but teams that have already Express their interest to um to support and and be a part of the open intense framework

here at the bottom again this is just from this is all happening in the past 24 hours so I'm sorry if I did not reach out to you this was me kind of scrambling at the last minute to to have conversations with teams um not intended to be in any sort of order of priority I would love to have more conversations with teams please um I'll reach out please reach out to me this is me again just kind of scrambling to to check with teams at the last minute um but yeah excited to have a lot a lot of a lot of support and excited to excited and relieved to see you know people just being very open to to adopting this framework cool um well that's it that's my that's my quick overview before I hand it over to the first demo which is

actually n from hyperlane who has been huge instrumental in this open intense framework um I guess before I hand it over any quick questions comments feedback before we keep going with the demos maybe maybe just a small question from my side uh I think like it's important to have like the intense framework itself uh there's a lot of intent Frameworks out there kind of comp in for how to do things how much are you thinking also about like the solver side because what I heard from a lot of people is that eventually like the solver side is where the problem lies uh like you can adopt different intent

Frameworks you just need solvers so what do you think about that agree this may actually be a good segue for for n to jump in um not to put you on the spot n but you might have a more eloquent answer to this yeah um I think I maybe answer your question like I think um or maybe to make the question even bigger which is I think there's a lot of work to be done right and I think to Echo what Josh said like the Frameworks I think that we and a lot of other people have been working on is not meant to like be the solution that just like has solved everything now and like we all can go home I think the goal is just to have a like shared substrate where we can all work together right that is like credibly neutral like fully

open source like because I think one of the reasons um why we started working on this was basically like hey we also wanted to have intense every everywhere but it turns out building all this is very hard and when I was talking with other folks including Josh right like I think it just like Turned like we just learned that like there's so many like shared abstractions and tooling that could everybody could benefit from that like currently do not exist uh and so part of I think what you say right is like yeah for solvers right like what are the like share tooling and Sol like uh infrastructure that we need to create to make it easier for solvers but also right like if you are like like a new L2 ecosystem right and like you are now wanting to create intents everywhere like you basically end up oftentimes

building the whole stack yourself so the goal of uh what we've been working on with uh the EF uh with a team called boot node is to kind of like start with a a very like rudimentary basis that is super modular so that people can come in and add kind of their own flavors of it to it so that we don't end up all like you said having like a lot of different approaches that are like hard to kind of like uh well we duplicate a lot of efforts I guess uh so maybe um not sure if I answer your question Eric but uh maybe if I can share my screen real quick um I think I've been talking to a bunch of y'all um on the call here about this um but maybe it's easiest to actually just go through the uh kind of

like post that we've been working with a bunch of you guys on but currently the the state of the framework is really three things it's an open source solare implementation right so it's like one that supports not only the like smart contracts that are in the framework but also other protocols such as Eco um such as the Compact and the idea is that like right if you buil an intent protocol like you can easily have this framework solver like uh supported so that people who use this uh reference solver can easily run it for these different protocols um it also contains uh super composeal smart contracts and I will dig into the GitHub in a bit real quick but the idea is that right like a lot of on this call are working on l2s are working

on uh settlement mechanisms that make it much faster and better and uh less trusted than a lot of the multis approaches that are out there today right and again the idea is that like the implementation that exists right now in the framework is not meant as like oh this is done it's meant to allow all these different settlement mechanisms to have an easy place to add their module so that uh they can deploy these intent experiences themselves and also has a very easy build UI template to like obviously expose those uh intents to the users and so the goal here is think of it really as like a a bunch of pieces of Legos that people can kind of mix and match together so that they can have intense on um again a

their ecosystem on L2 but also do that in a way that allows people like that allows these intents to kind of work across ethereum um and obviously like 7683 is a very big part of it um maybe to just quickly show like when we started working on this uh right like when we took a couple months ago when we took the leap of faith to kind of like fund this effort based on ideas that we've had with uh the EF like the the hypin part I'm Hy is like just one contract right like most of the logic is in these two like base 7683 contracts and so as a settlement mechanism right like if you like op super chain if you like arbiter's broadcast standard if you espresso if you polymer right like all you have to do is Implement a single

contract like this where you override these two uh basically you uh override the settle uh and then you like uh actually settle the order like that's all you have to do and now you have basically a fully working intent uh smart contracts on your intent settlement system specifically right and then on the solver side there's kind of these different modules here um and again like now the reference solver can support your like intents uh and so the goal here was to have a uh um yeah to basically have a substrate like a canvas I think like Jos called it right to allow people to basically innovate on intents without having to reinvent the whole wheel um all by themselves uh and

so yeah as part of the effort um we've been already working with right like Eco like I said to kind of like support it in the protocol uh we've been working with uh right like Z AG uh to have have the solver solve in the compact um with Hashi like the hashi's Oracle could be like another set M option in this uh framework right like uh part of the arbitrum announcement last week right was for nomial to offer uh loans for solvers right to answer your question AR to make it easier to have less inventory um for solvers on these chains um and that could be again like a reference implementation of that integration in the open framework solver uh right like rebalancing right like

making more rebalancing tooling for solvers will make solvers lives easier uh so there's a lot of kind of like opportunity to have these kind of like shared abstractions that we all work on together right for example like transaction indexing like uh transaction submission right like these are all things that are very hard but that I think we together um yeah I think can uh work on um and so I just wanted to quickly like add with like one one demo which is again this open template it's totally like not tied to any particular settlement mechanism can be used in the framework to U yeah have working intents by just basically overriding that one smart contract um to uh to have intents in right like all of the L2 ecosystems

across ethereum widely and I think what's really like strong about hopefully us all working together on this is it really plays into the strengths of ethereum where right like I think we've always had this kind of notion of like innovating right like working on similar things but innovating in different directions and improving uh by having people experiment with different approaches and I think if the Dem works then I think here on my uh never mind okay I guess that's what happens to life demos um I swear it just worked 40 minutes ago

um but uh yeah I think that's I guess that's yeah that's all I have and yeah um again this is just a very early uh uh this is just the first step of hopefully many for all of us to come together and work on shared abstractions to make um yeah intents be everywhere take can you clarify um how this relates to 7683 and across just like as one example like where does this fit yes right so 7683 obviously is the

uh right like the U most widest supported uh intent standard uh that we have right now and that's the reason why we started with a reference 7683 implementation right like when you inherit from that contract like I said you basically get 7683 compatible like protocol um and so but the idea is also that the framework can obviously support right like different protocols for example EOS for example the compact right like we've been talking with Jack from base about 7755 the idea is definitely to like have kind of like shared building blocks that people can use mix and match uh where kind of like serves their goals while we all have these kind of like shared building blocks that help us all but we don't have to invent a whole stack if

that makes sense and how does this relate to an existing protocol like across like would this replace it or integrate with it definitely definitely does not replace for sure right like I think the idea is to like just have share tooling to make it easier even to write like build with a uh to like integrate with a cross to have a solver work like solving for a cross protocol right like one thing for example that the um that the framework does not address at all is like right like how do like how does the user intent get uh communicated to the like solver right like how does like an intent get maybe auctioned off to solver like those are all things that like uh

there can be shared abstraction apis that we can work on together right and of which then across for example is one of possibly many implementations but we just make it easier for people when they build within this framework to not be like on the own Island completely independently and um I think uh My Demo will showcase how this all fits together very nicely cool cool any other questions for n or maybe Hart since you uh since you recently spoke we could just go straight to you here and just um if you're are

you ready I can also quickly share I just wanted to uh repeat the quote from uh from Mark from optimism um yeah he he is supportive of open intense framework you can read the quote there in the chat um could make the call today but um it's been great to see just generally that um yeah we have more and more people jumping in and supporting the initiative so thank you to Mark sweet can you guys see my screen we can perfect okay great yeah um okay I'll go next then um so how does this fit together so um I'm stealing a couple slides from my Devcon presentation here um and I across co-authored 7683 with Y Swap and with Mark that uh Mark Toto was

like one of the main authors on this uh which Josh just was speaking about his quotes there um so we quoted the standard for cross intense um and my mental model for this is to think of it like an order ticket like you you fill out the fields fill in your details of what you want to do and then you just send it into the network and it gets done um and so all the complexity about how this intent gets settled all the trust assumptions all that all the solver Network it all gets abstracted away so the developer just has this simple experience of I fill out this intent and it gets filled and um in our spec if you go to ERC 76 83.org um you'll see like this is

what the spec looks like uh on the call two weeks ago we're like hey has this got to production yet and so what I wanted to kind of demonstrate is 7683 in production and then we'll go deeper into how this flows super nicely into this open intent framework um so in this spec you know we got it to specify Phill deadline and Order data type which is the the EIP 712 typ has um and then just this order data field that includes the information of what you want to do um in the intent and we have like this is a very simple script that basically does the Avi encoding of this order data uh I ran this ahead of time and I've got

a few data fields to fill in and just to show you guys this all live in production I can go to this 7683 contract this is on base right here and I can write uh my order data what this is going to do is send if I go back here it's going to send uh 10 usdc uh from base to chain 42161 which is arbitrum um paying like a tiny fee so let's see live demo Gods let's see if this works for me um see how this goes um but to start off here

we can show that on base I've got a little bit of eth I've got uh some usdc on arbitrum in this account I got eth and uh no usdc so so on production let me write oops sorry wrong button let me write my intent uh to base here it's probably not gonna it's probably not GNA work you need to make sure deadline because if you if you need to generate you need to regenerate your deadline I can paste a deadline in that's I think it works I updated a few minutes ago but let's let's see okay yeah oh okay I thought the I thought the

failure to SM gas was going to say it was G to fail yeah no no no I I uh I I updated this so so okay so this got filled here's my deposit transaction on base if I go over to arbitrum let's see there we go I've got my 10 bucks on arbitrum um and if I look let's see this got filled the 10c mark relative to wait where was I so from nine seconds to 10 seconds it took one second to do our our our fill here so pretty good performance 7683 in production um you know anyone can go to Ether scan or Bas scan um and execute these intents which

uh which we think is kind of cool um and so yeah we'll be putting out a blog post like documentation documenting how this works um but I wanted to kind of just give some context of like this this framework is exactly what Nom has been talking about there's like the app layer that's creating the intent there's a solver layer that's like maximally competitive filling these intents and and I can actually maybe speak for a second on solver competition maybe I'll come back to that um and then there's this many settlement layers many of these ERC 7683 settlement layers that in my world they should reach all the corners of the L2 L3 ethereum ecosystem so that we have like day one

permissionless coverage uh to get intense everywhere and um at my Devcon presentation you know we spoke of this we spoke about 7683 being purposely designed to be modular in its settlement architecture um this settlement system is meant to be a Lego block I literally put the Lego block in my slide back in November and it can support super chain interop we're working with a super chain team on a settlement system that that would do this when it ships uh it can support egg layer interupt it can support uh the storage proofs that Jack and the team at base are putting out it literally can can that the the standard is designed to support any type of

messaging layer to ver verify these intents just like what n was talking about um and yeah so from our perspective this open intent framework is just the natural extension of uh 7683 uh from Developers for both the app and wallet developers we get this common format to do whatever want cross chain um for solvers this intent framework is defining multiple solver reference implementations uh Nom's written a a solver reference implementation we have one as well um I think his blog post will link to both of them and then for chains uh this framework is just embracing and

encouraging uh competition and experimentation in settlement system design which will let us bring intents to all the corners of ethereum uh from day one um so my hope right um at Devcon we got a lot of people to support 7683 we have this big logo wall of people supporting this standard for crossing intense um I'm hopeful we can push the open intent framework forward and get the same sort of support with this being this open credibly neutral framework that you know all of us in the space can take our own work our own projects our own technology and contribute to uh be it like an L2 ecosystem supporting the

these standards uh or these interop messaging passing um protocols being able to pass messages so that's my my unify ethereum bit um and what I maybe also wanted to touch on just because there was you know a question around solvers and solver competition um I just this is just some data from the first few hours of unich chain um you know just launched on Tuesday and um one of the things that's actually kind of cool about is first of all Unis swap wanted to keep uni chain secret uh like no one knew about the RPC endpoints much ahead of time at all um

and even in the first few hours we had like median fill times going to UNI chain of three seconds the P90 fill time was 4 seconds with uh eight unique solvers showing up um and I thought this was pretty cool because in like literally just the first few hours the mechanism behind this intent architecture inspired many independent uh completely autonomous uh relays or solvers to show up and compete uh to fill users with like exceedingly fast times for like a brand new chain um which I thought was pretty cool uh anyways that's that's my presentation um and yeah I'm pretty stoked that we've

got 7683 in production uh right now thank you Hart uh cool Spencer from arbitrum are you free to jump in now yeah so I'm Spencer I'm a product manager at offchain Labs um last week we announced a blog post for the universal in 10 engine um this this kind of came about from the notion that 90% of desired interrup today is cross-chain token chancers and swaps um it's acknowledgement that all the components for interupt exist right now today and the only thing that's missing is the

actual alignment of L2 Stacks to formalize these and get them everywhere uh this aligns with the open intent framework in in the same notion that we we have the ability to express our own opinions on what the actual design is and make sure it's actually implemented by Every evm Chain in doing so we have interrup I mean if you just watch the demo right there it's pretty clear we have interrup right now and um I think that it's just not being communicated appropriately distilled to the right like media firms what have you um but intense makes sense because this fills a

valid use case right now and uh the universal intent engine Is our commitment to making sure that we can proliferate intents everywhere probably sometime next week we're going to be publishing what we call the cross-chain broadcaster this is a trustless message passing protocol and we think it's very unopinionated and widely applicable to any evm chain without customizations to how an L2 works I do not have a presentation today but I just wanted to spread the word and announce that you know we're fully in support of the open intent framework and we're looking forward to building this Hall in public with you amazing thank you

Spencer cool uh last up KH from T1 hey everyone actually my name is pronounced John uh Turkish so uh but uh great to see so many familiar faces I'm not going to be doing a demo but I'm going to be discussing what an alternative settlement system uh can look like uh for these uh um you know 7683 uh or open intent uh Bridges can I share my screen yep yeah all right so I guess um maybe a bit of background about what we do uh we're building a trusted execution environment enable

rollup that uh can produce realtime proofs today and um you know not wait for the ZK research to catch up and we believe this is like the single biggest Unblocker to solve our fragmentation issues and uh we also you know um think that this can bring some interesting um rollup interrupt uh benefits but uh like you know you all know this like what we do is we run our runtime in a te and and then can prove T1 execution back to ethereum within 12 seconds um and we also do something that's like different than the traditional rollup uh rollups that are out there we're running um partner rollup full noes in addition to

an an L1 full node and the T1 node infrastructure so right now we're doing uh eum spolia and arbitrum spolia um and what that allows us to do is we can you know by following the uh arbitrum sequencer we can reexecute arbitrum State and be aware of what's going on in arbitrum inside T1 and you know we can post those proofs back to the L1 within a few L1 slots um and yeah security wise today we depend on tees but I've been working with tees since 2018 I started secret Network which was the first production uh T project we have a plan to you know add defense in depth and still achieve real time proving which is

like proving in one L1 block and we can get into that but like not to Shield too much um how we think about intent uh with T1 is I think there are two main areas that we are excited about uh the first one is you know realtime proving enables um faster uh verification and therefore faster payment to solers and this tremendously increases Capital efficiency that we have and um another area that is interesting for us is um I briefly touched on this earlier but we have um we run other rollups full noes we have deposit contracts on other rollups uh that read uh you know

requests from our uh ethereum L1 uh Bridge contract but what that means is like unlike a traditional rollup um like we don't enforce that if you come to T1 from ethereum you only have to go to etherum but you can go from anywhere and that creates a liquidity mismatch right if I come from etherum and if I go from arbitrum someone who came from arbitrum may not have the funds to go out and integrating something like 7683 in that setup creates tremendous Capital efficiency for us because we're no longer like fully Bound by the liquidity of our Bridge contracts assuming you know we have solvers in those in those places um so to tap into

the first one um I think you all know this uh how 7683 works but what we want to what we're saying is you know the origin chain and the destination chain can be uh you know T1 partner rollups we would have P nodes running uh we'll have follower nodes of these rollups running in our node infrastructure so we can verify Alice's uh deposit to Escrow and the filler's performance on T1 and and and therefore release the funds uh to the uh to the filler um you know in I'm you know I'm hoping in the in a minute or so with you know taking some

reor risk uh I I do acknowledge that um but yeah um I guess um across one of the products I love dearly and heart thank you for building such a cool thing uh requires 60 Minutes for solvers to uh or like the optimistic uh challenge uh period and um and you know that's um that makes life more difficult for solvers uh because they need to have funds uh to fill for 60 Minutes of demand and if you can reduce that to like you know repayment to a minute then they need to hold less funds basically um and yeah that's like that's what

we're working on we're putting together a prototype as we're speaking now and it's super cool um I mean I am new to the game compared to most of you guys but it's super cool that this initiative is going on that we can you know like plug in our settlement system to the work that you're doing and um you know just um push the experimentation that is going on in the space yeah um I did some back of the envelope calculation this is like super basic and I have like bad like oversimplified assumptions but basically the idea is like you know this is yesterday across did 5,300 transactions for like 11.5 million on ethereum um so

like if you believe all the transactions are equal in size and happen in equal intervals you have a a bridging request every 16 seconds almost $2,200 uh and if you pay a solware in 60 minutes the solare needs to have 480k to like meet all the demands uh if you pay a solver every minute you basically cut that by 60 um and this is obviously a theoretical limit but just gives some idea of like how uh we can make these systems more efficient so all polls there um and thank you everyone for your time thanks John can I can I just jump in and say how awesome I think this is

and how like aligned I feel like for us if we can this is another settlement system that just makes intense better so we want to repay solvers faster and if we can go uh like again more Innovation on these settlement layers just kind of awesome so amazing yeah like we're we're not in the in the business of Building Bridges so if we can support in any way um you know we'll have our devet coming up in a month or so so yeah let's I we have our channels Let's Jam awesome cool I do want to save the thank you again and I do want to save the final five minutes that we have here uh bo from polymer put together a helpful doc that he would like to

quickly walk through so B do you want to jump in yeah I'll keep it short um I shared a doc in the L2 interop chat around to open some discussion around the goals of the open intense framework aligning on those and some of the issues that we saw when we actually dug into the implementation differences and how they would diverge between different protocols uh the doc is meant to start the conversation around this perhaps we can continue the actual discussion async in the intense working group I and I encourage like different teams to add their team's perspective to the doc um for discussion uh the Catalyst team has ADD added their uh point of view um on on this effort as well at the bottom of

the dock so I encourage more folks to participate cool thank you in the final two three minutes here any quick parting thoughts feedback comments questions for next time cool well let's keep the discussion going async then we can end it a couple minutes early actually uh awesome thanks everybody for joining thank you thank you

[Music] everyone thanks everybody