Assets First, Proofs Later: Building Verifiable Cross-Chain Intents with OIF | ETHTaipei 2026

Uh hello everyone. Uh I'm Alfred and I am a blockchain developer in I'm token labs and today I will give a talk about open intense framework and this is what I'm token labs contributing recently and is a huge framework. So I want to shout out to my uh teammates uh shout out to Changu Jan and Alex CT and Aurora and uh we want to share our experience for you when we implement the OF in our testing product and I want to use a question to start today's talk when you move asset across chance what actually crosses And most of you may answer the asset but in the intentbased bridge it may not 100% true because uh what actually crosses is a claim and claim means you want to prove something has already happened on another chain. So we can call the claim as proof or a testation too. So the another question is how to make the message safe to trust if we want to transfer the proofs instead of the asset and this is a claim issue we will mention uh after and uh here is the example for the whole talk uh it is a simple example uh a user want to transfer 1,00 CHR from 1,000 USD on CR and want to get 900 USDC on hypervian.

When you are using the traditional bridge, you need to bridge first and swap. Uh there are two steps to transition. It means there are two thing can go wrong. But in the OF you can directly let the server delivers 900 USDC on hypervian from its own liquidity and from the view of user your journey is uh and your journey has an happy end and but uh from the solver from the view of solver he is out of pocket on hypervian because nothing of users asset has moved it's uh lock on the trunk. So the server has taken on risk and something has to make less risk resolvable.

So this is what I mention of the claim issue and this is a quick slide of intro. We want to define the naming convention. Uh if you focus on the money uh you you focus on the cash flow you can see the input chain the trunk is where the users want or lock and what they want is to get the asset on the hyper event it is the output chain. So front view of the cach flow you can see the chunk is the source chain and hypervian is the destination chain. But when you are a solver oracle you can see the proof system or a test station is go from hyper event to char because you want to prove the uh users intent is filled on the destination chain.

So you can see the proof is uh start from the hypervian uh it is where the server proves it has failed and then the server claims the user's lock found on chunk. So the proof system uh the proof flow is go through from hyper event to chunk. So you can see the chunk can be source chain and destination chain and hyper event can be source chain and destination chain too. So let's avoid it. We just say input chain and output chain.

Uh the input chain means the end to end of workflow is start from users call the open and code on the trunk and what they want to do is get the asset on the hyperben. for hyperban is a chain and after intro uh I will introduce three uh chapter uh the mechanism who benefits and what actually breaks your OF system. Uh for the OF architecture the open intent framework give three uh parts the layer standardized and modular. uh you can see some layers in the OF uh whole protocol. Uh the first one is orderflow origination.

It means you need to give the open source user interface or chain abstraction wallet for the user to let join the multi- chain ecosystem and uh the intent expression means you need to decide the lock mechanism. For example, you can choose the 76 A3 or the competit as known as the resource lock to lock users asset on the input chain. And the orderflow option means you can decide the first come, first serve or other ocean mechanism for your server to uh choose the ocean priority. And in fulfillment means you need to implement your own solver and the OF encourage people to implement the opensource solver but yeah and crosschain validation is the claim issue. So this is the proof you need to uh proof something has been completed in our chain.

So this is what solver and this is how solver claim back the user's fund and the rebalancing uh there may be some liquidity problem you may met because the solver directly give the users what they want on output chain but they claim back the payment on the input chain. So you need to solve the liquidity problem and standardize the O of gives some uh standard in their documentation. Uh I will quickly recap the ERC they mentioned. Uh the first one is 7785. It means you can use the ENS to replace the JSON file in GitHub for tren identifier.

So in the past we need to use a file to record the uh chain identifier. So the measurement management is depends on the GitHub. But in this ERC you can use the ENS to replace it and 79 30 and 7828 unifies the multi- chain address format. So you can get more information uh especially uh multi- chain address in the in this address and you can use the check sound in the standard and 7811 means it lets the dep discover the multi chain asset of user with one code so it just define a code and 7786 means it provides a interface for the multiple crosschain message protocol so you can use this standard for your product to uh integrate many cross chain messenger protocol and the modular part is the most important part uh or splits three jobs that bridges normally do together uh in the whole workflow the open source server interact with these three components uh the first one is input setler it is a contract on the input chain uh users call uh open to express express and lock their font on the input setter contract and after the proof come from out chain uh the info settler could release the input to the server and the oracle is a service and yeah with the adapter contract in the OF protocol uh oracle bring a carries and verifies the claim from output chain to input chain and settler is also a contract it uh get the fonts from the server and give the uh give what user wants on the opport. So this is the overview of you can see there are so many components here uh imposet service and hyper hyper oracle is the oracle part.

So why uh splitting lamb is matter? It is is because they can be uh they can choose different security model and different implementation and built by different people. So when you change one of them you don't need to rewrite others you will not affect others. And this is modular do and let's go through the workflow detail in detail. Uh the step one is uh lock in the input the user user uh aka the sender in the off protocol.

It's quotes from the solver and call the open country open function on the input set to country. So if you are implementing the input set to country you need to choose the custo mechanism. For example you can choose escro or resource lock and it affects your intent expression and you also need to choose the security model. So uh what how to authorize and what's the uh mechanism you want to use in the input set contract. And next the simplest step in the O workflow the solver directly fill the uh users intent on open chain.

So in this step the users journey is is is over. We can see the good uh user experience. This is what we selling. And after the field uh you can see uh user is uh user is happy but solver solver spends their liquidity on opportun. So we need to solve this problem.

So the step three the solver want to claim back what they spend on opport. So they need to submit the proof. Uh firstly in uh here they want to they want to prove that they they have fulfill the users's intent on open chain. So they need to interact with the hipline oracle. Uh here uh we take hyper oracle as an example here because we can choose other crosschain messenger protocol like one hole polymer proaster.

So hyp oracle just a just an example. So you can see the server call the submit proof on hyper oracle adapt to contract. Then the hyper oracle send the proof from output chain to input chain and in the end the server could prove they have fulfilled the user's intent on our input chain and claim back the user's lock phone. So who benefit? Uh from the view of wallet uh it is that the product stop being routed because in the past the user need to choose the routes and uh decide the interchain payment and user ask for bridge x then swap but in the inbased bridge especially the off they just need to express what they want to spend what they want to receive and before what time and just let the server picks the route.

So from the view of wallet the user experience is very good and uh this is a new try for us to enjoy uh to join the intent best defy ecosystem and from the so from the view of sober uh the oil benefit is not more profit and not more liquidity because it is not a go for the profit model it just a a transporter and uh intent based intentbased model not a profit model. So it just lower integration cost. So you can use one integration for many sources of orders and you can reuse your own quoting simulation risk and settlement but you need to keep control of inventory routing pricing and rebalancing. So uh we we don't promise too much because there are still something you need to you need to face some some problem you need to face because the uh or doesn't give you more liquidity and doesn't give you more profit and oracle uh or makes the oracle slot in oracle in the or protocol the oracle just a transport layer So it is a new opportunity for the crosschain messenger protocol to join the interbased eos e ecosystem. Uh Oracle is not a competitor of server.

They don't compete for the send target user. It's a new profit weight for the crosschain messenger protocol to join the uh crosschain defy ecosystem. And what actually breaks? This is uh a chapter we want to share with you because when we implement the oil in our testing product, we may made some problem and uh yeah. So what actually breaks your OF system when you want to implement the OF in your product?

Uh you may made the uh you may meet the safety issue, fe issue and your component may be may be shut down. So we need to uh solve it and the first issue is security issue because the oracle is a transport layer for for everyone. It is public. So anyone can submit proof on the oracle hyper oracle. Hyper oracle here is a country adapter contract.

So it is public. So we can see uh attack example. If I'm attacker uh I can deploy my own country on the output chain. So I can deploy my hypacracle or other adapter contract on the upchain and then I send a message order order number 42 was filled but pay nothing. So the hyper oracle oracles validator can sign it and then check by the uh oracle adapter and send the proof from the out chain to input chain.

So you can claim the server's profit or you can claim the user's locked fund if you don't check the payload with the person who sent it because in the attack example nothing here was fake the crosschain message protocol just answer is this message real uh but nobody ask did a real obsettler said it or not so when you implement the oracle or when you imple implement the impossettle You need to make sure it has X ask is this P from let oracle on L chain instead of just asking is there an attestation for attestation for P because the signature and the question message is always right and next the face issues. So who actually pays? Uh you can see when when we take a look on server the server uh give the user what they want on the output chain and claim back the user's font on the input chain and from the view of oracle they charge server on output chain and call the function on the input chain. So you may meet the interchain gas payment issue when you are solver or O or O or O or O or O or O or O or O or O or O oracle. So who actually pass if you are user the customer in OF doesn't need gas on the other chain is true because you don't need to consider the upchain gas fee.

You just need to consider what what you want what you want to pay and the code of server is is okay or not. So the user doesn't need to pay on opportun for the gas but you are if you are a server or O oracle you need to make sure the interchain gas get payment or aka IGP you need to make sure the IGP is uh is is good for your economics model because you pay and claim in a different chain so you might meet the separate problems like quoting collecting funding and recovery. So the fee issues is not a uh proof breaking issues. It just break your economics if you are if you don't consider uh in detail for your interchain gas payment. And next issue is [clears throat] blockchain issue.

So uh we can just go through the four steps to introduce this issue. Uh the the step one is the server pay 900 USDC on hypervenian. So the user can get what they want on output chain and then oracles signer see the event uh proof it and sign it and transfer from transfer the proof from output chain to input chain. Then the trunk the chong is a input chain release 1,00 USDT which is locked by user to the solver. So every check passed and in the final step the hyper event reox the block is gone.

So you can see in the end the server has uh 1,000 USDT user lose their 10,00 USDT on the trunk and uh 900 USDC never happened. So this is a trust issue of the software because if you are a software provider you you don't lose your money but you lose your trust of the user. So if if you if you care about this you need to make sure you implement the challenge window optimistic settlement and if you can sign the oracle or choose the oracle you need to make sure it sign the proof after the opportunity is finality. And this is a table for you to know if there are some components breakdown uh and who pass and bears. Uh the first row is sovereign never fails.

You can see the user lock their font on the input chain and expect the server give what they want on the output chain. But if the server never fails, the user got nothing but it can get a refund after the order deadline. And the second row is view arrives after expiry. Uh the user still got nothing but can get a refund and uh from and from the view of server uh it want to fail to make the profit but it may find the f reverts. So when you made revert on the blockchain you lose your guess.

And third row is field but a testation never arrives. So the user can get what they want on the output chain is it is paid and the server want to claim back the user's lock asset on the input chain but when you meet the uh problem that Oracle relay is done or has no gas uh the solver profit will get will lose uh we mentioned the has no guess because uh we made a problem that if you are operate if you operating a solver, you need to make sure you're choosing Oracle is operate normal normally because if you are choosing not very famous Oracle relay or not very famous chain the official relay may forget to refill the uh relay EOA and your profit may gone. So the cost uh cost they do not go the way when you run the OF protocol. You need to make sure you have a good quote because the quote is your profit model and the operations problem is you need to monitor lots of things because the quoting founding relaying and retrying will uh bring a trouble to you and when you want to adapt the off uh the open source server reveal the profit more. So you may not want to open source it and in my opinion the framework is too big to be adopted.

So if you want to join the OF's ecosystem, you need to make sure you can control each component because the the other component may uh break down your service and in the workflow is the user open on input chain the server page first and a test stations. So different from the traditional bridge this is SS first proof later and I want to reiterate again because uh the OF doesn't make crosschain complexity go away uh someone must bears the problems uh thanks for listening thank you Alfred so we have a few minutes for questions anyone has any questions Oh, here's one. Alan,

hey, I really like this talk. I like intense. Um, my first question is in practice, what do you think will be the most common oracle people use and like what's special about that oracle that um would make it like that? Uh in in our in our implementation we choose uh hyperl because we want to support lots of chain in our uh existed uh product like wallet or we we make wallet. So we want to support like hypervn and blah blah blah chain.

So when we choosing the Oracle model, when we choosing the Oracle provider, we want to make sure it can support most often. Yeah. What if there was like another Oracle provider that had the exact same chain supports? What would you want to look for between them? If um there was another oracle that supported the exact same chains as hyperlane, um what types of things would you look for to distinguish between them?

Um I want to in the practical implementation uh we actually we implement our we operate our own relay of the oracle. So we don't depend we don't rely on the official relayer. So when we want to choose the Oracle relayer and Oracle model, we want to make sure the codebase is audit or the code basease is uh has enough feature for what what we want. And um so the the I want to I want to we want to make sure the uh oracle is has a good implementation of codebase because we want to operate the relay or re relay by our own instead of rely on the official relayer. Yeah,

I see. And then if you're a wallet and you're ser using this like offering crosschain for people, how do you decide which chains you want to offer? Because even if the oracle supports it, you might not want um like the risk of bridging between certain chains is different than like others, right? Like some chains are just inherently more dangerous than others. How do you think about that

from the user uh from the wallet product? We want to make sure the user's quoting and users users intent is executed uh successfully and we want to make sure the because because we profit from the from the fee and charging charging users from when we operate a wallet. We want to build our server and oracle to make sure the whole profit fit model is under control. So uh for the user we want to support more most of trends and the great quotes and the high uh availability of service. Yeah.

Okay. Um, I'm also curious on like how you think about the UX of um, the swappers because I saw in your example you had like a deadline of 1 hour and then like a refund of one day. Um, why would there need to be such a big difference? Um, like why can't I say um, the deadline is 1 hour and then if it doesn't fill I can refund it in like 61 minutes or something. How do you think about those timings?

uh for the time uh we want to make sure two things because uh for the profit model we need to make sure the server won't lose their money because in the in this table you can see uh if use if server has f the users intent it may get not it may not repaire because it after the order daylight or or field daylight so the time decision is depends um uh we don't want our servers to be to to lose their profit and the another consideration is the user experience. So if the field deadline or or order deadline is too long the user will will consider that or I I may be I may be cheated. So uh it is still in consideration to decide the time here. Yep. So I can I just can give you two uh reason for the time decision.

First one is the sovere profit and so avail profit availability and the user experience.

Okay.

Um do I still have time?

Okay. Um I'm wondering what your proofs actually look like when you submit this proof to the oracle. Is this something like from a smart contract doing a verification or do you do stuff offchain like what is tangibly the proof? Wait. Okay.

Uh the proof is uh can be the optimistic window or zap proof or single signature or multi- signature. So you can choose your own proof system. Uh in our imple implementation we can we choose the multi- signature here and the multi- signature is verified uh in the multi signature is verified in the hyperl oracle. It is a adapter count. So uh the oracle need to need to make sure the uh intent has fulfilled on the upper chain and the oracle relay sign the multi signature and send to the uh input chain.

But in the future we may use more complex uh signature or complex uh cryp cryptography algorithms here for the higher security model. Yeah.

Okay. Thank you.

Thank you. Thank you Alfred. Let's give him another round of applause. [music]