[trustless://interop.landscape] Barnabé Monnot - Open Intents in Patagonia

Transcript

Well, I am very curious to hear from our next speaker because imagine what happens when 30 developers descend on San Martin de Los Angeles for three days. What are they doing? What are they hacking? What are they talking about? I don't know about you, but I am dying to know. Our next speaker will reveal just that. Please welcome to the stage Barnaby Mono. Hey, hello.

Um, yeah, good to be here. Thank you for attending the talk. I want to tell you a little bit about some work that we did uh last week in Patagonia at Edge City uh on the open intense framework which is an interrupt stack that is very modular, very extensible and very valuable for the Ethereum ecosystem. Okay, so last week we were basically entrenched uh in this hotel room uh hacking away on many many fun projects um trying to kick the tires of the emerging uh open intense framework.

We are lucky to have over 30 builders uh from these amazing companies. Um and throughout this talk I want to give you some quotes from what they had to say about the event because I feel it there was such a great connection u the human element of of this experience is really important to me. So weeks like this remind me how rare it is to find deep alignment technical focus and humanity in the same room. So I think we really had something very special there and we want to show you how that translates to to the open intense framework as a as a stack.

So the by the end of the week like we managed to get through seven projects which are listed here and I'll get into them uh in a little bit but let's first rewind a little bit and uh understand what the open intense framework is and what it's trying to achieve. So the open intense framework started as a collaboration between many companies uh including the Ethereum Foundation uh across Leifi, Open Zeppelin, Wonderland, Hyperlane Arbitrum Uniswap Coinbase and many others. I'm reading from the notes because we have so many great partners that I didn't want to forget any one of them. Um why are we building this stack? uh we

want to make interrupt accessible and we want to meet the users where they're at and try to uplift the ecosystem with a modular set of components. The idea of is to provide these turnkey intentbased bridges for new L2s. So it should be very simple for anyone to just deploy that and be connected to the Ethereum network uh when they launch a new a new chain. We want to design OAF so that we don't have any vendor lock in for apps and wallet and we have standard tooling. So you don't have to be opinionated about single solution uh that you are picking. You you leave the choice to the user. We also want to build this stack to bridge different protocols that have different pools of

liquidity uh as we believe this gives you better pricing, better latency and just simpler intent enabled UX uh for users. So these network effects are very important to make intense a great crosschain UX solution. We're also building it very modularly in particular the settlement. Uh so how much trust do you need to have in the components of the system? Um you can be pretty extensive with this and in particular we are building trust minimized components to have fully trust minimized uh interrupt with intents.

And the last thing uh the stack aims to achieve is to simplify the operations of solvers and fillers. In particular, today's solvers they have to custom integrate every single inter protocol. With this stack, there's a legible interface that they can just uh conform to and yeah be plugged into the market immediately. Here's another quote. I played around with the contracts and was pretty impressed with the mod modularity it provides. It different settlement paths can be easily swapped in and out depending on the trust assumption the user is comfortable with.

So what is OF? Uh it's a full stack framework for intentbased crosschain interrupt. In particular these are the three main components of the OAF stack. So there's a suite of contracts, there's something called the aggregator and there is a solver implementation. Another way to think about it is the contracts are there. They're solidity contracts that you just deploy on the source and destination chains. And there are the contracts that ensure that the fair exchange is performed between the user and the filler. So the user puts funds in the contract on source. The filler puts funds on the contract at destination and there's another contract that does the settlement to ensure that the fair exchange proceeded fairly.

You can think of the aggregator as something like a matchmaker. So the user can talk to the aggregator. It can be run locally. It can be run remotely. That basically helps the user like find the right quote to yeah to to send their intent to be filled. And then you have a solver which is the counterparty that manages their inventory that fills the user intent at destination. There's other parts to this uh universe. So something that's pretty important is the interrupt SDK. So if you think of OAF as the engine uh the interup SDK is kind of the wheel or the interface like the the access control um to this suite of components and the SDK should contain

um interrupt addresses as well as crosschain operations. So it should allow you to plug in to crosschain protocols such as OAF supported protocols. In fact, the module of interrupt address is available now. So you can already use two types of addresses. ERC7828 which is a human readable interoperable addresses. So you can write barnab.bit room and this will be legible. It will give you like the right chain specific address and there's also 7930 which is the machine readable version which is a binary format of this. So you can already use this and integrate it uh with the module that's here.

Another part of OIF that composes really nicely with the stack is ERC 7683 which is a standard for liquidity order. So with this standard it makes it easier for solvers to compete and to plug into the market which means that you have deeper markets, deeper liquidity pools and that means you have cheaper fees, lower latency for users that uh transit over over this. You can see a diagram here. the user will receive an order from the market uh will sign the order and then the order will be filled by the filler that then settles it uh with a with a settler contract. So it's a it's a fairly simple flow.

All right, so that was a few words on OAF and the stack and components that relate to it. Now I want to talk a little bit about what was built in Patagonia on top or with the OAF stack. So our goal coming into this week was to have an end toend demo of OAF from the user being on an app to the wallet uh showing some kind of legible crosschain operation to the user for them to sign to the order being um broadcasted to the network of solvers uh to solvers then performing the field. So filling the the user funds at destination and then to the settlement that ensures that the fair exchange between the user and the

filler proceeded correctly. By the end of the week we had these seven different projects uh which were chaotically related as per this uh whiteboard and I think it was really interesting. Basically what this quote says once everyone started hacking IDs basically turned into prototypes instantly. the pace was wild. I think this is very much due to the fact that the OAF itself is so extensible has been really designed with modularity in mind making it like very easy to just start hacking and customize it to to your needs and the needs of your protocol and users.

So we had these seven projects. They're not end to end yet. So the thing that we haven't finished by the end of the three days is uh what's highlighted here in the red rectangles. We still need to connect these components together, but we're hoping to make some progress on that asynchronously in the in the next weeks. All right. So, the first project that we had was to have an app, a crosschain app that will make use of OAF components and interup SDK. So, in particular, we build this payment request app. So, somebody asks you for fund says please send me 10 USDC on a bit room for instance uh using the interup addresses. So ERC7828. So like Barnaby at Arbitrum as well as the

payment request ERC78 56. Once the payment request is made and the user signs it, the payment is made over OAF. So it it transits over like the the pipes of the OIF supported solver and aggregator. Uh one part that was not so easy to build is that you want the exact amount to be received. So if I request $10, I want to receive $10, not 9.96. And so you have to account for for the fees uh for the sender to send like the the right amount at at the source. And yeah, this is something that was done.

I have a little video. Not sure. Maybe it's not in there. That's all right. I think the video didn't make it to the slide. Um okay. Okay, so that was the first project, a payment request um app. The second uh project that we had is one of our builders uh actually does this website called vaults.fyi, which is a curated list of all the vaults where you can deposit your assets across many different chains. And one pain point that this builder found, they wanted their users to be able to send uh funds very quickly. Let's say from an

arbitrum vault to a base vault, but they don't want their user to leave the app. Like they wanted that to be just seamless. Um so how do you make sure that you can integrate components that allow let's say the wallet to to tell to the app that the user has these funds and this action can be can be processed. And so what they ended up building is these types of complex flows where maybe you have an action on source, then you want to bridge your funds to another destination and then you want to take action on destination. But all the time that you do this, let's say you exceed the vault, you want to swap your assets, send them around, uh there's a lot of slipage and fees along the way, and you don't want to like leave dust in in many places. And so what you want to be able

to do is dynamically inject the values of the outputs that you get as inputs to the next step of a process. and 7683 the liquidity order standard makes that actually very simple to do at runtime. And so they were able to code like this end to end flow where every time the inputs matched the outputs from the previous step. My clicker is not clicking.

All right, I think we're back. Thank you. Um, okay. So, that was the second project, uh, having the ability as an app to create these complex flows with 7683 and send them over the OAF stack. The third project that was attempted was trying to repay the fillers that provide the funds on this nation as quickly as possible using T proofs. The person who wanted to build this uh this project was looking to replace a custom integration

they had made with across by integrating OAF instead using vert oracle that actually took them longer to remove all the custom stuff that they had to build to integrate across. And I think this shows that something that doesn't have this vendor lock in that allows you to perhaps decide on different protocols depending on the needs that you have either in time or per user uh is very attractive to to app builders who who want to enjoy this uh optionality. So I would say bonus points for OAF here. The fourth project that we had is ERC 7683 compliant rails. So 7683 is like a standard order. You may still need to translate

data from specific intera protocols into the right format that makes them legible to the solver so that the solvers can compete on uh filling these intents. So to do this you would implement a resolver which is a contract that that performs this uh this translation and that makes it that any solver that complies to the 7683 interface will be able to read orders that come uh from this from this protocol. In particular the team that worked on this led by Franjo they used a new version of ERC 7683 which is V1 which is an upgrade from V0. At the same time as I'm giving this talk, they're giving a talk about what uh this new version contains. So please catch it, catch the replay after

this. Another quote, if you care about seamless crosschain transactions, keep an eye on this standard 7683 and consider contributing. I think it's a very important standard to try to widen the market and make it as accessible as possible. Our fifth project had to do with settlement. So we wanted to build an oracle, a settlement that was as trust minimized as possible while being efficient. What we opted for is an optimistic game for the settlement where in the happy case, the solver attempts to claim the funds and if there's no dispute, uh the funds are just given to to the solver. In the unhappy case, somebody can dispute uh this claim and the challenge gets resolved using the

trust minimize broadcaster. So basically the canonical bridges of the roll-ups to to resolve the challenge. So to decide did the solver actually uh fill the user order or did they not we went a bit further uh someone else attempted to try a more complex optimistic game which is two stages so in the happy case again no dispute the solver actually claims the fund legitimately in the first unhappy case when there's a challenge that gets triggered you can resolve the challenge using a TE proof but again that proof can be challenged so if the TE proof itself is not right somebody you can challenge it and then you go back to the uh trust minimize settlement using the the broadcaster that can take up to seven days given the canonical bridges

on optimistic rollups. So you can really make an OIF flow as trust minimized as you want. The sixth project oh right thank you. The sixth project is the ZK proof of field. So given that we obtain settlement we want to prove that a field is valid using a zk proof instead of a storage proof. So storage proofs are just fairly gas expensive and you can amortize the cost by passing a zik proof to show that on destination the field of the solver is valid and uh yeah is is legit. So the the person that worked on this uh requested a proof from the boundless network and that's what happened.

Okay. Okay, the seventh project is really uh that was built by um very enthusiastic people who wanted to think about agents who don't have liquidity on on chain for every action. Uh but they want to request services across chain. So you have your agent which is on a room. They want to do something for you on bay. They have to find funds on base to be able to perform this. So here they use the resource lock protocol which can also be part of the OAF stack uh creating access for the agents to access passive funds on destination. They use the TE as the allocator to ensure that there's no double spending uh that tells you whether the resource can be spent or not. That's why it's it's locked in the first place.

So I want to end with a bit of a call to action like these are the seven projects that we that we built. I hope they show the breadth of things that can be built with OF in particular how quickly you can get started with it and build like just really valuable components or apps on on top of a stack. We're really looking to talk like we want to understand better the needs of different categories. So for instance, if you're an app with crosschain needs, uh we want to talk to you about the interup SDK. We think that this is something you should be looking into integrating if you just want to have access to this interrupt uh stack your wallet. There are many different components here as well. The interup SDK again should support many of these needs in particular interrupt

addresses. Something that can be very nice for your users to orient themselves across chains. If you're an intent protocol, we want to discuss about the OAF contracts themselves as well as ERC 7683. We think like the more integration we have on these open interfaces again the deeper the markets the better the users are. For solvers we want to talk about 7683 as well as solver operations like we think some of the stack that we have in particular the solver implementation can be yeah just very easily reusable and extensible by current players. And if you're a chain launching on Ethereum, uh we want to ask you about using the OAF contracts as

well as deploying a solver to ensure that your chain gets out of the box connectivity with the broader uh Ethereum ecosystem. So these are our Telegram handles. I'm Barnab Mono. I work a lot with Josh Rudolfph. Uh so please reach out. And I want to end also by saying uh thank you to the amazing builders that were part of this experience in in Patagonia. Thank you. >> Actually have time to take a question. So let's step over this way while we make sure the next speaker is set up. So if you guys have not noticed yet, there is a QR code that appears on the right of the stage. So you can scan that and ask our speakers anything you would

like. And if we have time, we will take questions. Now Barnaby, this question for you says, "We built a test net app on OIF. How can we best connect with LPS, market makers, and individuals running solvers? Is there an obvious way to plug into them? And what if we have custom OIF interface requirements? >> Yeah. Um, I think the best for you, I'm not sure who you are in the audience, but will be please reach out to me. I'm happy to chat. Uh, on the other stage at the same time, we have Pepe from Open Zeppelin who's working a lot on solver integration and market integration. uh I think he might be the right person to to have a chat with should be very easy to

to plug you to to the open intense framework market to the solvers to the 7683 interface. Yeah. And if it's not we should understand why because that's what you what the question asks. I think it's really the point of of YF in the first place to make it like almost a no-brainer to plug yourself to this uh to this market and for your app to suddenly obtain like all of these crosschain capabilities under the hood. Now another question that someone asked from the crowd is how can I join next time and hack and build with you? So what do people have to do to be there with you?

>> Yeah, I mean we had an open call on Twitter. Uh we had many people who joined I didn't know them. Uh but I was very happy to to get to know them better through this experience. So I know follow me on Twitter. Uh I really hope that we get to do this again. I think it was a very productive experience. Um yeah, stay aware of like our next call for u for invitations to to such events and reach out in the meantime of course. >> So the so the I guess the best way is to follow him on Twitter and see when there's an opportunity and don't be shy. Talk to Barnaby. You can see he's a nice guy. He won't bite. Thank you so much Barnaby. Thank you very much.