[trustless://interop.landscape] Workshop - Open Intents Framework Overview and Demo

Transcript

on on that in a moment. And then this is a framework. Um a framework means that even though we are giving or we're developing tooling, it's not a product by itself. is some framework for other companies and other protocols to build on top of. So we've been developing reference implementations for most of the components. But the idea is that this serves as a common layer for people to build on top of the all the components have been very modularized. Um it was very important for the OIF um like framework to to be very modular, very compatible with new protocols and being able to facilitate

integration with protocols that may have their own complexities. So what is the benefit of OAF as a framework? Uh the main benefit is being able to like plug and play new components, new wallets, new networks, new protocols very easily with the same API. So imagine we have like an ecosystem where multiple wallets are compatible with OIF, multiple solver networks, which we will go in a little bit on what a solver network is, um operate within different networks. Now if we have a new wallet, this w this wallet is automatically able to interact with every single piece across the stack

because of the common um APIs and and models. If a new protocol wants to run a solver and operate and provide liquidity and and do things, it's also very easy for them to just get running and get exposure to all of the wallets. Uh straight >> [music]

[music] >> Heat. Heat. [music] >> [music] >> Heat. Heat. [music] chain mainly, but there is already a

standards that we will go more in depth later to like put that intent on chain and for solvers to pick them up. Once the intent has been opened on chain that can be done either by the user directly or by um the solver opening on their behalf, the liquidity gets uh screwed. The OAF is very modular in the scroll options. You can have a direct scroll into the smart contract, but you can also leverage resource locks for doing this. Resource logs, you can research smart much more onto that, but it's basically a technology that allows you to have a common liquidity pool that just by doing signatures can be moved

with the help of a offchain party. >> Once this liquid is um properly secured in a contract in an escrow the solver then fills your intent. So you straight away get the output money. This um is done through an output settler contract uh which is also very modular and allows you to do farther actions once the like intent is is fulfilled. Like it's not just transferring a token. It can be transfer a token and call a contract and like kickstart a chain reaction of different things.

This action will create a proof um that an oracle has to then forward back to the origin network for the solver to claim their like the assets that they now belong to them. This oracle is also very very modular in the way that is structured and it allows solver networks and users to adapt to the protocols available to them but also for the trust assumptions required for different types of operations. you may have a smaller transfers that you're okay with using a centralized oracle. While if you want to move like $5 million, you may want to have like a more secure oracle that

ensures full um competition and and full trustlessness. >> I'm pretty sure the two voices in your head also are pretty disturbing. Um so sorry for that. So what is open sle building? When I was thinking about this like where is the camera? Hello. You remember the Steve Jobs iPhone presentation? Like it's a phone. It's an it's like a like it's three things in one. Oif is kind of on the same vibe. So I'm not going to do like a Steve Jobs wannabe. I'm not very far from that. But um OIF uh builds on that same ethos in

the sense that we are building reference implementations on everything that is required through the protocol. So we are building a smart contracts which is the core kind of base of the OIF. It's an onchain protocol and should always be fully available onchain. We are building a solver which allows for new networks to like just take them run it provide their own liquidity and get and get started as part of this ecosystem without having to go and talk with with other providers.

And we are building a rest API to facilitate [music] a standard way for communicating with that solver. When we built all of these things, we also realized that wallets will have to connect to multiple solvers to get more quotes. So we also built an aggregator that I will also I will explain a little bit later. So smart contracts smart contracts um we are doing collaboration with LiFi. So something that is very important for if is like it's not just open silum foundation um like project that uh multiple projects are are collaborating into it's not just open sil contracts have been collaborated along with with lifi. they are the main core

contributor. They are very very modular and extensible. Um we have like the input and the output contracts and they all allow for extra actions and very like customizable approach to things. They allow as I said earlier for like kickstarting a chain reaction where when you complete your intent you can call with a specific data to a specific contract and that may kind of start another intent or do more things on other protocols.

It's also very modular both in terms of how the money is secure and how the validation is proven. So right now we have support for resource locks and we have support for direct escrow of tokens um either through like permit 2 we have also support for 309 uh which is also a signature protocol to a signature standard to facilitate um signing and for oracles we actually have like like five to 10 different oracles um and the list is just growing because we've seen a lot of interest from Oracle providers to be integrated into the into the standard. So this modularity allows for

users and protocols to have a very clear uh trust assumption among them. So you may have solvers that prefer some oracles while others like have a a lighter requirements for trust. >> We are also building the solver. The solver is the primary offchain component. uh is the component that actually feels the intent and the component that handles all the liquidity. It's built in Rust the reference implementation and is very modular to like configure every single detail um that a solver may want. So you want to adapt how fees are applied to your project, we have a model for that.

You want to adapt which uh oracles you support, we have a model for that. So the idea is that these solvers is a base for um projects that are actually going to be running this to adapt their own needs. It supports the OIF APIs and it's it facilitates basically uh all of these of this management. It's very modular also in terms of which network and token it supports and which kind of actions are provided. So a key element in this is that a solver requires like context and estimation of gas on the intent that they are fulfilling to provide a good quote. So they need to

have a clear trust assumption and a clear view of what's actually going to be executed so that they don't get drained or they don't get yeah messed around. This rest API I think I said too many times like it's modular and extensible but like it's really the foundation of this project. It's a very modular uh project and this API is minimalistic at core but extensible to the maximum. Uh basically we provide classical metadata as like what do you want for input? What do you want for output? Is there any trust assumption you want us to respect like a specific oracle that you want to blacklist? Is there any um

like pair of tokens that you don't want to touch? uh is there any time to execution that you require and all of this gets formed into a quote submits to the solver and then the solver will give you um all the data needed to sign to then propagate that that intent. All of this is obviously a little bit complex to do when you are having to communicate with so many different solvers at the same time. So we built an aggregator. an aggregator that again is modular and extensible and it also has a unique capacity that other than or on top of being able to aggregate multiple OIF API

solvers, you we can transform the API to connect with other protocols that may not be fully OIF compatible right now and we are able to transform their API calls to make it transparent to the end user. So OIF does not only support or does not only work for pure OIF protocols, it also works for other intentbased protocols. >> So now we are going to do a little bit of a deep dive with Fran about an ERC that we've been working on together.

>> Okay, can everyone hear me? Well, yeah. Awesome. So um ERC 7683 is kind of its own thing but we are working on it as a part of OIF. Um and in order to understand why it makes sense to have a standard um I want to take a step back and give an overview of the life cycle of an intent which Pepe brushed on but this is a bit of a more simplified view. So um at the at the beginning you're have going to have a user that's going to be interacting with an application um and they're going to express some intent which is some outcome that they want to

see um affected. The the app or the wallet are going to synthesize from that an order that implements that intent uh in some intent protocol. Um and that means that it's going to sort of verify that the intent is is actually um um achieved. The user is going to get this order back. They're going to assign it and then they're going to submit it to some order feed. Um, which could be onchain, could be offchain. Um, um, and from this order feed, it's going to go to a network of fillers. Uh, which are the ones that actually will kind of make sure that this intent uh, executed on chain. Um so that is the the last arrow uh the last arrow that we see right

there the fill in which the filler will interact with the intent protocol or the the settler contracts of the intent protocol to do to give the user their assets and then to verify that they did that and then get paid and so on. So the problem and the context in which the the ERC uh comes in is that this this last arrow that we see the fill is protocol specific. Um so it'll be each intent protocol will have a different interface uh maybe even sort of a different structure of things that the filler has to do to get their payment um or values that they have to provide. Um and so what this what this implies is that every filler will have to integrate

with every intent protocol separately. So they will have to write up the you know the solver that we're developing. They will have to make their own solver code for the intent protocol or or use the one that's provided by the intent protocol. Um they will have to you know do separate audits. um they will have to uh you know do do you know set up infrastructure that's specific for that um maybe connect to some off-chain service and so it it'll all be very uh protocol specific and that's a lot of work that needs to be done right it's it's development it's reviews it's it's audits um and so the consequence that this this has for the intense ecosystem

is that it raises the barrier for a filler to participate in an intent or for new intent protocols to come up because it's very difficult to to bootstrap this this network of fillers um because of all of that work that needs to be done. So the the the goal and and the ideal that um the ERC is going for and that the authors originally sort of saw a problem and wanted to solve is to say well can we can we have a standard whereby uh fillers just sort of are are agnostic about the protocols that they are working with and when someone comes in and they develop a new intent protocol they they can sort of get for free uh the that that filler network and the

filler can also get for free the the order flow that goes to that intern protocol without doing so much uh development and and specific integration uh that is currently required. So um with this motivation in April 24 uh across and and unis swap got together and they uh built uh ERC 7683. um it got a lot of interest from from the industry and u we saw it a lot in like crypto, Twitter and all of these logos which really means that you know there really was something there. Um and um so they worked on it all throughout 2024 up until 2025.

Um but as protocols started implementing it, they started to find that it wasn't really optimal there. there were many things that uh weren't quite right uh with the ERC as it was originally speced. So, we're going to go over uh first go going to go over um some of these things that uh could could be improved. So, this is a a part of the the ERC. Uh it defines some strcts to encode orders. It defines functions to initiate intents on chain. Um, and there's a few more things that are in in the screen right now. Um, and the the problems that this these three main problems that the ERC

had that implement sort of discovered were first it sort of forces a lot of gas overhead in the intent flow. Um, the two things that I highlighted here are that there are these really big strcts that you have to submit to the open functions. Um and then this even bigger strct the resolved one that has to be emitted as an event. Um and this is a lot of gas overhead. And I I think um you know we talk about gas a lot but in in this particular case is really interesting because um you know protocols often compete in having the best gas efficiency for their users. Um, and if we have this standard that, you know,

it's very very pretty and, you know, standardized and whatever, but it has so much gas overhead, nobody's going to use it. So, it's not really achieving the goals of standardization that we're after. Um, so this was a really really big problem that uh um Vzero uh has. The other problem is that the protoc the the interface was designed in this escro ccentric um framework and I mean escrow here in in the sense of a cross which is uh um the the first one sort of that Pepe mentioned uh which is when you have to make a deposit on chain um before you then go ahead and and and do the fill on the destination chain and as also Pepe mentioned there are some newer

constructions such as resource locks that don't need that um that step that provide um potentially much better UX for users and that we would also want to kind of fit in this in this standard. Um and so you know in addition to this point about the life cycle there's also uh some parameters there in in the order such as the open deadline that are included that again many protocols won't need and like I said it's adding gas overhead. So we've got this kind of thing where it's sort of pushing many protocols away from actually being uh compliant. And lastly, point three is that the ERC actually kind of realized that well, you know, there's there is this variety of protocols out there that um is quite

natural, right? Because if you're building a protocol, you want to do something innovative. You you want to make some uh something different with your protocol, you know, different differentiate yourself from from from the rest of what's out there. So, you're going to have, you know, your own protocol specific things that you want um to to to build and to to offer to the user. So they they included this kind of very generic bytes order data thing inside um that actually ends up doing a lot of the work of like protocols being compliant. um you know, you just have whatever it isn't standard, you just shove it in there and it looks like it's good, but it's actually, you know, you end up with something that's sort of only semi-standardized because every protocol is going to end up defining

their own uh kind of order data and you're sort of back where we started where every filler has to still integrate with with each of these different things. So, I'm just going to go over a few more more issues that this uh standard has. This is sort of the other half of the the interface that the standard defines. Um and I'm just gonna Yeah. So, um you know, first problem listed here is that the the proceeds and the costs of an order are only really approximate approximated and in some cases like extremely coarsely. Um and this is the max spend and min received uh parameters there. And you should understand that

it's it's very important these these things, right? Because when the filler, they're subscribed to this feed, they they get orders and they're going to sort of analyze each of these orders. They're going to assess whether the order is profitable. And if the order isn't profitable, they're going to drop it. And so, um, representing the the proceeds and the costs very accurately uh is really important because, you know, if you don't, the filler is going to most likely just drop it or be taking on more risk than they would be comfortable with. And again, this ends up with like a dysfunctional uh network of of fillers, and that's not what we want. So, the second point here is that like I said, we've got some extra parameters like the open deadline that some protocols don't want, but we

also have some missing parameters like the settlement deadline um in in this resolved order. uh which is very important and uh because it implies like um well if the if the intent hasn't been filled uh and even and settled at at a certain point the user want wants their funds back right um and I want to stop here and sort of point out why it's very important to to to give all of these parameters is because um these orders right which the filler signs which sorry which the user signs and the filler receives are really the coordination mechanism where they are you know agreeing to very important parameters and you know the funds of one will be locked in one place and the

other one will be sending funds to some other place and sort of hoping that everything resolves and but but no you don't want them to be hoping you want them to have certainty um that they're going to get their money back right and so parameters such as this settlement deadline uh that ensures that um you know users can get a refund if the the intent is is never filled are very important to include um across the the standard. And finally, two points two more points are um this was built at a point where we didn't really have any good uh standards for chains and and addresses. So in any multi-chain setting, you need to refer to the chain uh where you're sending funds or the chain where you're you're taking funds.

And we we have it here as the destination chain ID for example which would be using the uh EIP155 chain ids but that's not really uh sufficient in you know when we want to have a wider reach like just as one example startnet uh doesn't have a chain ID you know and they're a good friendly rollup that we want to be able to have intents to and from um and they wouldn't be supported here and also addresses uh here they're represented as a bytes 32 2, but that's not a standardized format in any way like um and in some cases an address may not even fit in bytes 32 and and you want to be able to support that. Um but again, you know, having this be

standardized is super important for this coordination property that uh the standard requires. And so, you know, this was another problem that we had. And the final one here is that there were some parts of the interface that were sub underspecified like this filler data u over there. It's just like a bytes parameter and then you know the filler has nowhere to see okay how do I even provide this this value um it's it's a thing that's usually used to like put the address where the filler wants to receive funds but you know some protocol might want some other thing and there nowhere in this interface says how to actually do that. Um so these were uh

most of the problems that that we saw and that's what motivated us uh going towards a a kind of an iteration um of the the ERC uh that we are calling B1. So to introduce the the direction that we have taken with B1, I want to highlight first um you know the the one uh thing that I think was a really good idea that uh Vzero introduced is this this resolve function um and the resolved uh crosschain order whose um role is as you might see it has no protocol specific order data in it. um and it attempts to be this comprehensive description of

what the order is uh in a in a in an actually common standard language and I think that was a really good idea uh that we took and we um um even sort of furthered in in the v1 that we are doing. So the way that resolution works is that the filler is now uh going to be receiving from the feed protocol specific orders but in some uh standardized sort of packet format that the ERC defines. Um and they uh but you know they're going to be encoded in some opaque way that the filler won't really understand as is. uh but we introduced this this this role of the resolver um

and the resolver provides a service of like taking these protocol specific payloads and translating them to this common language uh that is standardized by the ERC that we're calling the resolved order. So when they receive it before doing the fill they go through this resolution process and that can tell them exactly uh you know what the order entails and and and what steps um to follow. So that uh is sort of the the the transition that we are making and so the challenge then becomes okay what you know what how do we specify this this resolver um it's got like a very difficult task of representing very very

wide very um a wide variety of of of protocols and orders that they can implement. So the philosophy that we have taken with this uh redesign which is essentially what it is a redesign almost from the ground up except for this one bit of the resolver um is to try to use as much as possible these general purpose building blocks. So this is in in in contrast to what we saw before about this order data thing. You know that would be non general purpose and what we want here is to have like very general purpose things that can be used across protocols so that the implementation of those things in the filler um can be reused and

doesn't have to be reimplemented. Um so what we have done is taken the the notion of an order and tried to um you know uh pin down what exactly uh does an order consists of and we have reduced it to these these four things that you see here in the uh resolved order strct. An order uh in an intent protocol will imply that the filler has to take a certain series of steps, right? And the steps will be um transactions. You can think of it in that way. Um and the transactions might be that I take a signature from the user and I submit it to a contract to pull the funds in. Um I

then go to the destination chain and I send the failed transaction to to provide the funds. then I go back to the origin chain and send another transaction to claim my funds. Right? So those would be like three steps that a protocol might require from a filler. Um and uh that would be modeled in the in the steps part. So uh let me take a one small step back and explain like who writes this resolver uh where is it and and and um yeah so the resolver is as I show here is an interface for a contract. Um this would be a contract that lives in what is often called the periphery of uh a protocol. Um so say that unis swap develops a new intent

protocol. They would along with it develop a resolver a compliant resolver and deploy it on chain even though it only has a view function. Um and you know you would obtain then the address of the the resolver. um and they would implement it in a way that understands UNISOP's uh new intent protocol and is able to translate it into these generic representations. Right? So um this is a a periphery contract again that would be used by the filler uh in this step that we showed before. Right? So the resolver here is a contract on chain.

Um so you know it takes the protocol specific order and it translates it um into this this format. Like I said uh the first thing that's very important is okay what are the steps that the filler has to follow. The other important component uh of an order that we've identified is what we call here variables. And these are some choices that the filler has to make um and that eventually would become like pieces of data that have to be injected in these these transactions that have to be submitted on chain. And by choices I mean things from very simple things like what is the address where I want to receive the funds to potentially more complex [music] things like um you know

how do I participate in this auction? Um so to give an example of that um some intent protocols nowadays including uh Lei that we are collaborating with uh are using Dutch auctions to do parts of the intent flow and when a filler has to participate in a Dutch auction they have to decide uh based on sort of the the pricing function at what point in time are they going to go ahead and fill the user's intent um and what price are they going to give it give uh to them. So it's kind of crazy, right? Because this is a very complex thing. Uh but it's it's quite cool that we we I think we have actually achieved uh you know to to to represent it in in this generic way

which is the the time stamp at which you send the transaction is a variable that the filler has to choose and it's sort of injected in one of the steps as a as a as a attribute of the transaction that has to be sent. Um, and that gives the filler all of the information that they need. So, as as I now move on to talk about assumptions, this this last thing that I just said is very important. The goal here that we have is to take all of the information that is relevant about an order for a filler to know um, and to put it in here in in these general purpose building blocks that uh, that we're trying. So, the next one is the assumptions. Um, and this is kind of a trust assumptions kind of thing. The

truth is that uh ideally you would only sort of trust the intent protocol that you are interacting with. Um but sometimes there are pieces where there's say you call a contract that the user provides right to implement some sort of callback handler. Um and the protocol uh requires that that doesn't revert. And if if the call back does revert, then you're sort of uh reverting the entire fail and that might leave the the filler at a loss. So there are these points and and this is not just something we've made up. It's actually something we observe in in actually live protocols.

You you have to make sure that the callback that the user has provided will not revert. So we have to take this and and represent it somehow and we put it there in this assumptions field. Uh and lastly, the payments field is the the proceeds part of the order. So it's what the pill uh the filler will will receive. Um one note that's very important as as you will see here there are a lot of bytes in these in this ERC a lot of bytes types but um in in in contrast to V0 each of these bytes actually has a very specific format that has to be followed um and with a very specific uh semantics that the filler will will um

assume. Um so one let me think about what am I missing? Yeah. So we we have solved here uh the the problem about only approximating the coast and the proceeds. the the the way what we have defined here allows us to do that very accurately and even um to support these kinds of uh pricing functions um where it's not just a constant uh number of of funds that you would receive but that depends on the choice that you make um so we support auctions like I'd said and and we also support uh resource locks right so not only escro ccentric like the the version

that we had before Um yes so I did uh I am missing one thing that's very important to understand which is you know our goal here is to reduce the effort that is required from the filler to integrate with a new protocol right this was like the our our goal the thing that we are after um but it's not really possible to completely eliminate that um because you know you you at least have to know that the protocol isn't going rug you right so um the the the thing that we reduce this to is just a white list right and that's that is the goal it is that the filler operator would be

able to configure their their filler software to say yeah I trust this protocol at this address and I trust this resolver at this address to to tell me what steps to follow how to participate in the auction and so on and so that would be the only integration step required from the filler and it's it's it's a little bit difficult because you do have to understand the protocol but it's something that you know you can um look into audits that uh professional companies have done um you can look at TVL and you can look at sort of ecosystem adoption so filling a white list of protocols that you you support is a lot a [clears throat] lot easier and a lot of um a lot lower barrier than

um you know writing of the whole filler software like we sort of had before. Um, so this is just a a little taste of uh what one of these resolvers looks like. Admittedly, it's not easy because it's it's doing a lot. Uh, but this is uh a part of the prototype that we built last week in in this sort of um um buildathon that we ran with some uh community members. Um, and so here what we see is one of these steps, right? Is the step to call the fill function that we see at the at the very bottom. And we're you're we're saying what is the contract that we have to hit, what is the function that we

have to call, all of the arguments that have to be provided, and these attributes that I mentioned before, right? Like, you know, this is a call that you can only make before the fill deadline. Um, and this is all of the information about this step that is uh relevant for for the filler. So, um yeah, that was the overview that I wanted to give. This is really just kind of like an overview then of of what uh this this filler um what sort of the the rightmost part of the life cycle would look like um or actually all of it which is you know you go from an intent to a protocol specific order. You then encode this in this uh compliant uh

packet which consists of this this payload and a resolver, right? And then you give that to a filler and then going through the resolver, the filler can get a resolved order which has all of the structural information needed to then go ahead and do the fill for the user. >> Okay, thank you Fran. So now that we know what OIF is, what's going to happen with OIF in the future and it's something that we're still looking into how to solve but there is a classical problem that we want to avoid and is that this is a standard that is trying to substitute other standards. So

it's a there is a possibility of us running into like okay this is just another standard. The way we want to avoid this is by build it along the people that actually use the applications that actually build the protocols that build the wallets and that build everything around it. So that at least this is a recognized open-source uh fully modular standard. We understand businesses will try to come up with their particularities and they will have their own like nitpicks and they may have their own APIs but this is intended to be a fully open available for everyone standard that

everyone can use and the way to get there um is is to like expand and build together. We want to on board new layer choose. We want to make sure that the experience from getting to zero to one is as good as possible. We want to make sure that the solver and the aggregator meet the demand from the protocol operators, the networks and the community. We want to make sure we want to facilitate existing protocols and existing wallets to be compatible with these APIs. And we are obviously open for all protocol operators and and standards to come and build with us. And and once we have these basic blocks uh

with more oracles, with more wallets, with more things, then that vision that we talked about at the beginning of um any new wallet being able to integrate this standard and connect to multiple solver networks, to multiple um protocols at the same time, it's going to become a reality. So now it's time for the demo. Um, I actually had this fake quote uh prepared before, but it's it's now more true than ever because as you've probably been uh suffering, the internet in the event has not been the best. So, we're going to give it a try. We are going to take a look at a reference UI that we've built uh for demo purposes. So this is um

like testing UI that we've built inside the open sampling team to it was first intended to like test internally um how let me make it a bit bigger. It was intended to understand and facilitate testing of the APIs, testing of everything. But we've realized that it's also a very powerful tool to show to people the power of of these things. So this UI basically allows you to swap between tokens on different networks.

Right now it's connected to two different solvers. Each one of those solvers have and now is where the demo may fail because internet oh internet is working. Awesome. So we have two different solvers. One is our mainet and one is our test net solver. the test net solver. We can go here and select the assets and networks that that it supports and same for the same for the mainet one. The idea or why the reason why we have a mainet solver is not to test with real funds because the tokens that we have in here and we have supported fake USDC. um it's more to ensure that people and protocols can build and test with real oracles, real

RPCs and the real building blocks that they will be actively using. So there is like for me there is a cool thing about the OIF and about internet protocol that we've built is that when you want to for instance pay for a coffee the coffee will cost you $2. um whatever amount of thousands of Argentinian dollars that is um but you will like actually have to think okay $2 plus gas fees plus the silver fees plus other things I have to send like 2.35 and then the guy in the coffee shop will

not receive $2 will receive like 1.99999 so something that it was very important for this protocol is to be able to have a exact output number. So, let's give it a try. Let's see if internet behaves. Um, I'm going to do a transfer of one USDC from Optimus Sapoleia to base Sapoleia. Once I input my my information, I can request for quotes. This is connecting to the aggregator that is uh deployed live. By the way, you can go to the URL above. I will show how QR in in just a second.

Um, bear in mind this is test net infrastructure. It's intended to like be used. Um, but you may encounter some some hiccups. So, the aggregator has now filtered based on the tokens and networks that I have selected which solver is able to give me a quote. In this case, it's just the test net solver because I selected test net um networks. Each solver will give you a quote with a deadline. A deadline because maybe well in this case USDC is relatively stable, but maybe you are moving from Ethereum to Bitcoin and the volatility in there may be higher. So the solver will give you just a quote for like a minute for

instance, which is more than enough for normal use cases. But in this case, I've been speaking for more than a minute. So this quote is outdated. So I'm going to go ahead and refresh. The quote is the same because it's the same. Once I select this quote, it's going to give me a lot of information about what is going to happen. is going to give me the solver that is going to be doing the the field, a quote ID for reference, the information about the inputs and the outputs, and then I'm going to be able to in here um sign the intent and propagate it and send it to the solver.

When we think about how to integrate the um all of these will be built into the app. So for instance in here you can override the private key that is going to sign the intent for testing purposes but in reality it's going to be just built into the app. Just for preventing problems I'm going to refresh quotes again and go ahead with it. So I'm going to assign >> I'm going to assign the intent >> and I'm going to submit it.

>> Once I submit it through the aggregator, it's going to go through the full process. Um hopefully internet stands and doesn't get stuck in the middle. But basically what this is doing is getting my funds transferred into the um input settler via in this case it's an it's a direct escro. The solver is picking this up and it's going to fill the intent. After the intent is filled, the Oracle will pass along the message to the like primary network and the solver will be able to claim their tokens. So while in this case the oracle is doing things

we can go to uh this was opia scan. And we can see this initial transaction that does not exist. Okay, maybe it's in Bible. Yeah, >> there we go. So we can see like this USDC was was fully transferred. So the oracle different will take different times. Uh the oracle will propagate the information and the solver will be able to claim this uh back in the source chain. It's very important to choose the proper oracle not only for the time that

it takes a solver to like get the money back but also for the trust assumptions and we have seen this will become one of the main uh areas where OIF will need to be motorized and and executed. This may take a while. So let's go back to the presentation this demo. I just want to make something clear which is like >> at that point the the user's funds were already delivered, right? >> Yes. The user like the speed of the intent is super fast. So the user doesn't have to wait for an oracle. The user has the money. Um the actual intent takes like whatever amount of time the solver thinks is safe for them to assume

that the funds are properly scrolled. So if it is a higher volume, the solver may want to take like proper finality time on Ethereum. If it is more day-to-day activities, it may be okay with a couple of blocks of confirmation. So you can all access this uh demo on oif.optylene.com. Give it a try. Uh you can freely mint all the tokens supported there. So, I mean, the solver doesn't have a lot of millions of liquidity, but feel free to mint. Um, give it a try and and move funds around.

>> Oops, sorry. We've also built um this for the community like the open intense framework is supposed to be open. So, there is a lot of documentation that we've put together at docs.openance. um XYZ um and we also have everything in the open intense org in GitHub. I encourage everyone to like actually take a look, reach out to us if you are building things. Um get interested if you are like integrating a wallet or you have a solver or you have a network, reach out to us and we will be super happy to support on that. So thank you very much.

Um, we have 10 minutes if I mean we've started a bit late, but we have a couple of a couple of minutes for questions. So, if anyone does have any questions, I assume someone will be able to pass them a microphone. >> Any questions? >> Any questions? >> Yeah. Can anyone pass a microphone to him? I think you said the first step is to comm um we've actually built a test net app

um which was a fork of privacy pools and then open intents coming in and out. But one of the things we realized is we had to like the create order interface of the open intent in order to provide like that compliance layer of the associated set provider. We have to also we modified it to also prove like that this address created the intent. So there's an extra dual oracle and because we've modified it now we can't just plug into like the default solvers. They're going to have to be aware of that extra step. Is am I think am I talking about this correct? Okay. So, I guess like uh yeah, we want a hackathon, but I'm wondering like you're probably the right person to talk to in terms of like how do we because it's like hard building on intents, right? It's not like before

where you just build a contract, point it to an RPC, deploy it, and yay, like it's a lot more complicated. So, I guess like I'm kind of here to find out what the next step is in terms of how do we connect to people running these solvers? How do we tell them about our modified order interface? And did we even do it in the right way? I guess and really looking for feedback on that. >> So I think there is there is two parts to to it. The first one is how do you reach out to like existing solver networks um and the OF at the end is a is a framework and we run like a demo solver but the reality is that um the real solvers with real liquidity will be needed to like okay um talk to me modify

this and and all that. Right now the biggest solvers networks that we are talking with are LiFi and and Across. Um we can get you in touch but like the reason why OAF exist is because very likely Lifi and Across will tell you like come back to us when you have a couple of millions in liquidity. So the cool thing about OA if is that you can go take a look at the solver code ask uh someone with Rust experience uh to like take a look it's very easy we on the hackathon that Fran mentioned earlier um we got people running their own solvers modifying their own solvers within a couple of days so you will have to adapt

to it there is a second part to that that is the 763 so if you are able to like fully standardized and modularized the steps that your intent requires um in a 763 compatible system, the solvers following that will hopefully be easier to integrate. So, I'm not sure Fran if you want to kind of expand on that or like >> No. Yeah, I mean the first the first point is like uh uh I'm not sure if I mentioned this but the this new version of the ERC that I described I would say it's kind of like in final research stages so not deployed yet but if I understand correctly you uh edited the contracts >> the contracts right so that's like I think a perfect use case for uh you know

you want to tell fillers what they have to do to fill this um and in that case you know once Since we have this you what you would do is you implement a resolver or you fork a resolver to u properly work with this this new field that you have and construct whatever data you need and and so on. Um so I think it's a perfect use case um uh and yeah I would love to know a little more and and understand if it does work for it. >> Perfect. Any more questions from anyone? Hey, thanks for representation. Uh I was curious uh how's wallet adoption around

this um like from what I demo and sorry I'm bit bit of a beginning around the intents like it's a standard like central signature. I'm curious if there is work on wallets to adopt the standard and make it more clear to to the user what's the intent they actually signing. >> Yeah there is so there's two parts to that. First there is wallets actively collaborating with us on like supporting if API especially because Lei being one of the the biggest contributors to the to this there is a lot of wallets connecting to them. uh the wonderland team also we are are working on wallet integrations and they are part of the UIF there is also a standard that I don't remember the name about kind of

facilitating clear signing of um 712 uh data and OF relies a lot on that so it's still going to be encoded it's still going to be um a a layer of decoding that uh based on current expectations is likely going to live in an SDK because when building the API we had to decide okay do you trust the metadata that the solver is sending to you and then you construct the encoded version and then set it on chain or vice versa. So we went for the solver sending you the encoded with an extra metadata field that is like it must be used just as a

helper but if you want real trust assumptions you need to decode it. So the first steps are being done to like facilitate this wallet integration. There is an ongoing work on SDK that will like actually be able to allow wallets to decode the data and fully like trust the data they are showing. >> Okay. So unless there is any more questions again thank you very much for being here. Any questions happy to chat around. Thank you very much.

>> Thank you all.