[trustless://interop.landscape] Jim Chang - Chain Abstraction with the OIF

Transcript

Please welcome to the stage Jim Chang. >> Thank you. All right, let's see if this works. All right. Hello everyone. Hello. Hello all. That is the extent of my Spanish knowledge. Thank you for entertaining me. Uh but I am very happy to be here today. Happy being Buenos Iris. Beautiful city, beautiful country.

And I get to talk about my favorite thing ever. Uh which is chain abstraction of course. Uh but before I get started, maybe just a quick introduction on who I am. I'm Jim Chang. I am the product lead at Leifi. I lead the intents products a series of products that we have at Leifi and we are also contributor to the open intent framework which I can talk about in a second. Um and what I'm going to talk about today is how the open intent framework and the products that we've been building at Leifi contribute into this broader goal that we have of finally delivering chain abstraction which I think is really really close to being actuality.

And so first, what is the open intent framework? And so the open intent framework is effectively a open-source permissionless framework or set of developer tools that a coalition of companies are contributing to in order to expand interoperability throughout Ethereum and beyond. And so the goal of one Ethereum of many roll-ups, many chains, but that feeling of one Ethereum as a UX is something that we're working really closely on um in order to make it a reality. And so everything that's been talked about with the EIL and with other initiatives today, we are also trying to make that a reality through a different lens with the OIF.

And so the OAF is really special because it is not just a product that one company is building. It's more of an open coalition that is actually led by the EF and there's a lot of contributors to it of which we are proud to be one of them. Um, but there's other ones like Coinbase Hyperlane Across Uniswap Open Zeppelin, Polymer, T1, and the Wonderland team. And we love working with everyone uh in that team in order to make this one Ethereum dream possible with the OAF. And so what we've seen for the past few years is that crosschain has largely been a solved problem, at least within a set of chains, through a primitive that we call intents. And with intents, we

basically allow a permission set of counterparties that we call solvers to fulfill users intents in order to have this really fast user experience. But the issue with intents that we've seen over the past 2 years, it's that while it's really really good for short tail chains like Ethereum, mainet, arbitrum, base, optimism, etc., it's not really good for longtail chains. And so the future of modular chains and any team that wants to build their own chain or build their own rollup even if it is EVM compatible, it's actually quite difficult to get a crosschain experience or even a seamless experience in general with those chains. And so what we've seen with intents is that there's been

three major problems uh to ensure that we have all these longtail new chains being able to be connected with the broader Ethereum ecosystem. The first problem has been that a lot of these intentbased protocols are private companies. And so and there is a lot of infrastructure that is entailed in order to support a chain. And so if you were a new chain team and you wanted to support a new chain, you actually had to reach out to these private companies and actually pay a BD fee or at very least establish some sort of partnership in order for them to deploy on your chain and for them to support cross-chain bridge transfers to this chain. And so that inherently is a centralization risk and a lack of permissionlessness.

The second piece that we've seen is that building something from scratch, let's say you're a chain team, you say, "I don't want to pay this large BD fee for all these intent protocols to come on board. How do I participate?" Well, building from scratch isn't really an option either because it is incredibly complex to be building an intentbased system. And then on top of that, you have to run your own solver, which is also a very high barrier to entry, not only to build, but also to maintain. And then the third piece is that there are a lot of chain teams that are all trying to do this themselves, right? They don't want to pay this high BD fee.

They're all trying to build these very complex systems and they're all building the same same thing over and over again. And as a result, there's a lot of duplication that happens within industry as it pertains to intent. And so the goal of the open intent framework is to basically lower that barrier of entry. We want to make it incredibly simple for anyone to be able to deploy intents and support it on their chain to connect to all these short tail chains like base and optimism and ethereum mainet and to do so permissionlessly. And so how we do that is through three core pieces. The four the first piece is that we have permissionless chain deployment of an open source set of contracts. And so anyone can go to the OAF repo, they can see the intent

contracts that we've made and they can deploy them themselves and they're built in such a way that no matter how different your rollup is, maybe it's a different VM, maybe it has different trust assumptions, it's a ZK rollup versus an optimistic rollup, it doesn't really matter because we built the OAF contracts in a way such that they are so lightweight and simple that they support all sorts of different use cases for whatever rollup you want to deploy on. And the second thing that we did is that we built an open-source solver and other infrastructure to make it incredibly easy to not only deploy contracts and support intents, but also to continuously use it over and over again.

And so even after you've initially supported contracts, you still need to do ongoing maintenance. You need to do things like issue intents. You need to do things like be aware of intents to provide quotes to solve them to rebalance. And so those are things that we've all open sourced and built such that anyone can run their own solver. that can improve on top of it. There's an open source of libraries that continue improving on top of it. And there's other infrastructure you can run as well. Things like an intent API, things like a rebalancing module, things like um indexing. And so those are all tools that we provide open source and for free for any developer that wants to support intents and continue maintaining that support.

And then the last thing we do is that we hope that the OAF as a repository is a unified source of truth for intents. And so anyone that wants to in the future build with intents, they can just go to these set of repositories. They can see all the tooling that has been contributed to it and they can continue to either use that or to even add on to it as well. And so my hope is that all this duplicative work that all these teams are doing, ourselves included, can be contributed to this general source of truth such that people can build on top of it instead of trying to rebuild the same thing over and over again.

>> [snorts] >> And so what does it mean to use the OAF? Right? I've been using that term kind of an abstract concept. And so I wanted to make it slightly more concrete. And so the first thing that you do is that you can go to the OAF repo. You can deploy the OAF smart contracts on a new chain, right? Maybe it's a maybe it's your own chain or maybe it's just a chain that doesn't support intents yet. You can go and deploy it permissionlessly. The second thing you do is that when you initialize your contract deployment, you can set a number of parameters that make it incredibly customizable based on whatever use case you want. And so some examples that I give are you can give it resource locks, which I'm going to talk about in a second. You can configure the

auction type. You can make it permissionless permission offchain onchain, Dutch auction, sealed bid, first come, first serve. It doesn't really matter because we support it all. The third thing you do is that after you deploy these contracts, you configured it is that you run our open source solver. And so you're able to see intents, you're able to provide quotes, and you're able to fill them. The fourth thing that you can do is that we also have a UI that we're building that will be able to detect new intents. And so you can have this UI that can see new intents on these new chains. You can issue them, solvers can see them through some sort of um order subscription, and they're able to fill them on chain. And so again, another thing that a team doesn't have to build in order to support intents. And then as a result,

not really if it's set, but as a result, what you get is permissionless intents enabled on any chain. If you have a brand new chain, you can go to OAF repo, you can deploy these contracts, you can support intents out of the box. And so what do I mean by modular tooling, right? What does it mean to go to the OAF repo to configure all these different pieces of the smart contract? Well, it in a very detailed sense on this page uh is what's behind me. It's it's effectively six different pieces that you can configure in order to customize intents based on whatever parameters or whatever requirements that you need. And so the first piece is

something that we call an orderflow origination, but basically the UI. So this is anywhere that someone issues an intent, anywhere that you see userbased volume flows uh going in and out of chains. And so this could be something like a UI like what we're familiar with. This could be something like a wallet like Phantom or MetaMask or this could be something like an aggregator. And so an aggregator in this case is what Leifi is of course, but in a broader sense it's basically just an API that gets intents and then funnels them to solvers to see. They provide quotes and then they fill the intent.

>> [snorts] >> The second piece that you can modularize is intent expression escrow. So you can do things like make your escrow ERC 7683 compliant. Escrow in this case is just the smart contract where intents um are the collateral for intents are deposited into and so you can make it 7683 compliant which is something that we're working on uh the new spec for that uh ER6 sorry ERC 7683 v1 uh in tandem with across and and unis swap and open zeppelin and others you can use something called the compact which is a resource lock implementation that I can get into in a second or you can build a bespoke escrow again you can really retrofit fit it however you see fit.

The third piece is something that we call an orderflow auction. And so this is actually the auction mechanism that sorts all these user intents and determines who is the winning solver that will actually fulfill this intent. And so I already talked about this. You can do things like make it private, public, permission, permission lists, offchain, onchain, dutch, first come, first serve, etc. The fourth thing that you can do is build something called or customize something called intent fulfillment. So you can do things like only using KYB solvers, only using your specific solver that you run, only using open source solvers, only using solver networks like Sprinter.

And that's good because that allows you to have a lot more say into who is actually filling these orders. And if censorship, excuse me, censorship resistance is something that's important to you or resiliency in the network is something that's important to you, this is something that you want to really pay attention to. The fifth thing that you can do is something called cross-chain validation. But this is basically a way that two chains are able to talk to one another. Right? When you're dealing with a doublechain context, you're effectively spanning different trust domains. And you need to have ways in which you ensure something happens on one chain is actually propagated and validated on the other chain. That's the only way that intents and that crosschain can work, right? And so we have modules that allow you to do a lot of different things. Uh

the most popular thing you could do is to use a GMP which is a general message passing protocol. And so those are things that we're all familiar with like wormhole and layer zero and axel and hyperlane. Uh pretty standard stuff. You can also use a lot of these newer primitives that are being discussed. things like the broadcaster which is a flavor of RIP7755 or ERC7786 which is basically like an aggregator of these GMPs or a way in which two roll-ups that use the same settlement layer like Ethereum roll-ups are able to communicate in messages between each other albeit in a very slow sense and so that is something you can configure as well if you care about trust assumptions if you care about the connectivity between different chains that's

something you can configure as well and then lastly you can also configure something called solver rebalancing which very long slide so I won't uh I won't belver the point there so you can use open intents today like what I said you can go to open intents.xyz XYZ. You can go to the documentation page, go to the GitHub repository, see the contracts that have been audited by a lot of leading auditing firms in the space, and you can follow a guide on how to deploy them, uh, how to interact with them. We're still actively working on more UI tools for folks that are, you know, non-contract developers to to work with it. But if you are a contract developer, you are curious supporting it on various chains, various test net networks, uh,

you can do that today. So that's the OAF, but I didn't come here to talk about the OAF, even though I spent a lot of time doing so. Sorry. What I came here to talk about is two new primitives that we just added to the OAF a couple months ago. Well, one two months ago and one last week, uh, that allow the OAF to become even more powerful. It's not enough to simply do crosschain intents, which is a better word for just saying bridging, right? Bridging the same asset. That's fine.

But what if you want to move different assets? What if you want to move different assets between multiple chains? That is the problem that we're trying to solve to to achieve true chain abstraction with these two new primitives. So the first primitive that I'm going to talk about is something called resource locks, which is a new escrow mechanism that we support in the open intent framework. And so what resource locks do is that they're basically an account that allows for chain abstracted intents to be fulfilled. And so you have assets that live on one chain. In this example, we have Ethereum. And you are able to fulfill intents on any other chain against this one balance of assets, right? And the really cool thing about

that is one, it uses intentbased execution. So pretty, you know, on par with what we were just discussing uh discussing with the OAF. Uh two, it's actually faster than source chain finality. Now, what what does that mean? That means even before it is included on the block of the source chain that you're interacting with, in this case, Ethereum, you can have your intent fulfilled on the destination chain. Now, how is that possible? It's because we use a mechanism uh using off-chain commitments that basically are pre-confirmations to allow the assets to to allow the solvers to know that the assets are good to go in terms of collateral so that solvers can effectively fill this intent

before they even receive the assets, right? And we use something called a three-party model. Um and so there is, you know, no kind of centralization risk. There's there's three people that are interacting with it. And one of those people are called the allocator. And then this allocator is super important because they are basically the entity that is pre-committing these funds. And these solvers trust the allocator in order to fulfill them. And so it's a little complicated. I'm sorry if I had more time I would dive into the details, but feel free to meet me after the talk if you're curious to learn more about it. And so the really cool thing about resource locks outside of what I just discussed is the capital efficiency of it. And so you can have one account on Ethereum and you're able to do any action that you want on any other chain

genuinely. And so we never have to think about USDC on arbitrum on base and all these things. You only have to think about on one chain and it can do all these intents on every other chain via this mechanism. And so one thing that we support is called the compact. This is unis swap's resource lock implementation. Um it's effectively what I just discussed. Um it's personally the the resource lock implementation that I know the best. You deposit into one account on one chain. You can use it on any other chain via intent and they are yours. It is your wallet, your account. And so there is no custodian that is uh taking custody of these funds. U but I won't for the

interest of time spend too much time on the compact but we do support it. The second primitive that I wanted to talk about um that we support is called multi-chain inputs, which is something that we just added last week into the OAF. And so what multi-chain inputs are is effectively the reverse of resource locks. And so what that means is that we can go from instead of going from one to many in the case of resource locks, right? one account on Ethereum to many chains, we actually go reverse. So we can go from many chains into one intent into one asset. And so in this case, what

we're doing is that we have three chains. There's different assets on them. We have USDC on one, ETH on another, die on another. You can issue one intent, so one signature in order to consolidate all those assets into one asset on one chain. So in this case, we're getting 0.2 ETH on chain X. And so what's really cool is that you have resource locks. They are a balance that you hold and you perform all these actions. I think the implication of resource locks that's been under discussed is what happens after you do so, right? What happens if you have $1,000 on Ethereum and you want to mint an NFT on base, you want to buy a new token on Salana, you want to tip your

friend on Farcaster. What happens to all those balances? They get spread out, right? They get spread out. And so your initial resource locked balance depletes. And now you're stuck with a lot of funds that you still own, but a lot of funds on different wallets on different chains. And so how do you get that back into your resource locked account? Well, that is through multi-chain inputs, right? And so you can have one intent of your account and you're able to sweep all these assets back into your resource locked account. And so you can still have that chain abstracted UX even if you have this fanning out issue that I just talked about. And that was something that we thought really deeply about and built multi-chain inputs as a result.

[snorts] And so what I want to do with you guys now is that I actually want to demo using multi-chain intents with the compact. And it won't be pretty and there's a non-zero chance it doesn't work, but I figured why not, right? Because what's what's fun about watching someone talk in front of a big screen, right? You rather see me mess up and get nervous. Uh and so we have a demo that I'm going to share my screen on uh and show you guys what multi-chain multi-chain inputs looks like live. Uh and you guys can try it out yourselves, too. But not right now.

Okay. So, what you see here is a 100% not vibecoded UI. as you can tell because it's pretty much all in HTML. Um, but what we threw together really quickly is a demo UI that allows folks to use the OIF to issue intents. And I'm using a particular feature on it that allows folks to issue multi-chain inputs. And so what we have on the right hand side is what we call the asset management tab. But that basically allows us to configure our assets um on on the compact. And so there are pieces

here that are slightly complicated that I won't spend too much time talking about, but I think the most important one is something called the allocator. And so again, as I said, the allocator is this pre-confirmation service or entity that allows for pre-chain finality or pre source chain finality for intents, right? So you can have sub-second intents using this pre-MP service called the allocator. And so I'm on testn net right now. You can certainly do it on a mainet but you know bare market. Uh and so I will be using testn net and I'll be choosing the always yes allocator which is purely for testing purposes but we also support other allocators as well. And so here you could see that I can deposit a series of assets here and it's reading my wallet balance of a wallet that I

already connected on testn net. I am balling out on baseia and so what I will do is that I will deposit some of that USDC on base uh in order to do so. Oh Very interesting.

I didn't anticipate getting logged out. Oh, here we go. I don't know where my other thing went. Oh, here it is. Okay. All right. Let me do that again. That's how you know it's live, guys. I'm not touching a recording. But anyway, I'm depositing my USDC from Bipoleia into my compact, right? And I'm only doing that for demo purposes. It's not really related to multi-chain inputs.

And so what I'm going to do now is kind of the core of what multi-chain inputs is good for. Uh we're going to issue an intent. And so I have just deposited assets into my compact. I didn't really need to do that as you'll see because I already have funds on different chains from the compact. But I'm going to be issuing a multi-chain intent right now. And so as you see here, I have four networks, four test net networks that I have balances on, and I'm able to select different inputs from them. And so what you can do on the UI is that you can just select, you know, some sort of arbitrary amount and it'll kind of do an auto allocation for you that can be tweaked. Um, but I think for the sake of demo, I'm just going to purposefully pick a few networks.

So I'm going to pick base and I will pick arbitrum and I will say that I want two two USDC onia out. Is that right? Yes. Okay. And so as you can see here this is test net and so there are no solvers that are providing quotes. But if you go to our actual UI which we call lintent.org I'll share the the link later. um you and you go on the main net, you'll see that we have solvers already that are getting intense streamed and they will provide quotes for them, right? Uh but because it's test net, it's saying that there's no quote, which is which is fine.

So going to sign the order for this multi-chain intent. And so that is my order live. And so again, the magic would have occurred if I received my assets on different chains immediately, right? But because we're in a test net setting and we just launched this product last week and haven't onboarded solvers to it yet, um it's not getting filled automatically. And so what I can do instead is that I can be my own solver.

Again, no reason to do this in a production setting, in a mainet setting, but purely from a demo perspective, I can do it on testn net. And so now I'm basically a solver, right? Like switching the point of view effectively and I'm seeing this intent getting broadcasted to me and I will choose to fill it. So you can see here goes the fill intent. I click fill which is basically just a transaction. I filled it. Okay. And so now from the user's perspective, they just received two USDC

um on Sapoleia and they have locked up or effectively locked up two USDC, one USDC on base and one USDC on arbitrum into the compact. And so what I need to do now as a solver is that I've effectively l I've loaned money to the user, right? User has money locked up in some sort of chain. I have given them money on another chain and I need to be paid back. Basically, I need to get their collateral. And so, in order to do so in a permissionless setting is that I need to pass a proof to fill it, right? There needs to be a crosschain validation module. Again, going back to the OAF menu that shows uh that I actually as a solver filled these

routes. And so, there's some sort of hash or there's some sort of proof that I need to pass in order to do so. And so, in this case, we're using Polymer. They generated a proof for us. And so we just need to relay that proof uh into the destination chains in order to release the funds. And because there's two chains in this case, there's two proofs to relay. But in the future, we're going to be building a batch proofing system that allows only one proof to be relayed, even if it is for multiple chains. All right. And Polymer is being very

slow. That's how you know it's live, guys, cuz it's not working. But what should have happened is that after I click these buttons, my wallet will pop up. I will relay the proof. I have to pay for the gas for the submission. Um, and I will be able to claim and release the funds, right? And so sometimes what's happening is that it takes a while for the proof to generate. Usually when you're talking about solving something in mainet, it actually takes a few minutes upwards to 20 30 minutes for a proof to actually be generated and relayed. And so there is a bit of capital management needs to be done from a solver side in order to reclaim their funds, right? It's not instantaneous otherwise they wouldn't be charging a fee for it.

Okay, I'm clicking on it hoping that it gets a little bit faster because it's test net. But I do think if we if we come back to at the end, I will show you guys the actual flow. But what should have happened is that I relay the proof pops up on my wallet. Those yellow boxes you just saw turn green and then what I'm able to do is that I'm able to claim the funds that are locked on these chains, right? And so I would have claimed it. I think even if I could claim it might open up my metam mask, but it will fail. Uh so I won't do that. One last try.

All right, here we go. Last try and it actually worked. There we go. I'm so blessed by the demo gods right now. All right, now they're green and I can as a solver claim my funds. What is this? Metamas PM DM me what this

is but okay there's no success animation uh we forgot to add it but it should have like confetti and stuff it's like you claimed the funds or something um but we made this really quickly so couldn't do that but that is multi-chain intense it's not glamorous but the foundation is there and I assure you we are getting there and it's more than just a slide so thank you guys for coming my talk hopefully you guys will see true chain abstraction at the next conference but I appreciate you guys letting me demo and tell you more about the open intense framework. Thank you.

[applause] Thank you, Jim. That was wonderful. And even though the internet doesn't always love us, we were still able to get a really good look at the demo. Thank you so much. Please, one more time, a big round of applause for Jim Chang. Now we heard