Scaling Ethereum with Intent-Based Interoperability | Philipp Zentner - LI FI

Hello everybody and welcome back to the developer summit here at ETH Denver 2026. My name is Kanesh Canal. I'll be your MC for the rest of this program. Uh I run the Devril team at Across which is an intentbased protocol. On that note, we have Philip Zentner coming and presenting how he how he's scaling Ethereum with intentbased interoperability protocols as well at LiFi.

Philip is the co-founder and CEO. Please give a huge round of applause as he takes over the stage. All the best, Philip. Hey. Hey.

Thank you all for coming. I'm Philillip. I'm the founder and CEO of Lei. For those who don't know us, we are an orchestration layer on top of DeFi. Essentially, we have been trying to solve the fragmentation problem across um dozens of blockchains, intermobility solutions, DEX aggregators, and millions of assets by now.

Um and as such we've been able to help like big companies to go to market way faster like Robin Hood or Binance web wallet. Um but we implemented in over 800 B2B applications which gives us a good idea on how the space functions and also it gave us the opportunity to really invest into uh new technology that now drives the which is the open 10 framework. But I'll start with the problem. Five years ago when I joined the space Ethereum was really hard to use. It was slow.

It was very very expensive and simply simply put like Ethereum had a scaling problem and the solution to that proposed by Vitilik was a rollup ccentric road map. Well that didn't play out as intended. Um we saw a bunch of L2s coming but at the same time we also saw different L1's coming up. Um so immediately um we were not only seeing more exchanges popping up but also intermobility solutions. Um for those of you who have been around remember maybe connects hop and cbridge or even any swap or multi multi- chain as like these very first bridging solutions then over the years we saw stargate across and relay and many others coming up um all these solutions are great but if you want to build a multi-chain native application by multi-chain native I don't ultimately mean an application that that makes use of external liquidity but an application that makes it easy for the user to come to the application and use it.

Um at that moment uh it just becomes difficult and a huge integration overhead. The problem is simply um that there are many solutions for for good reasons. They have different trade-offs, different architectures and all these architectures may be an intentbased bridge or liquidity network or mint and burn bridge. All these different types have reson data. They have a good reason to exist with different advantages and disadvantages.

However, from an implementation standpoint, all these APIs are different. There's very little standardization around all of this and that makes it incredibly hard not only for applications and users, but also for systems that aim to market make in this space. And we like to call these market making systems solver systems because compared to an order book, they tap into all kinds of liquidity sources. And again, here it's important to have access to all kind of liquidity sources and that is just difficult. Everything is heterogenous and we need to find a better way to unify Ethereum.

What we want is to be able to transfer any asset to any other asset via swapping and bridging or combination of both um at the best price possible as fast as possible and as secure as possible. And we want to do that without having to think about how right we don't want to think about which solution should I take this time um and what gives me the best price. um all of that should be abstracted away and the user doesn't want to deal with it. And this is where the concept of intents comes into play. We grew up with crypto in a way that we knew exactly which protocol to use in order to swap and bridge uh in a heavily fragmented market that implies um um research overhead.

So, we want to get away from that and instead we just want to state our intent, our intention on what do we want to achieve and it just might be swapping an asset A into an asset B. Um, and that that is my intent and I actually as a user don't really care how this is supposed to happen and this is where solvers come into play. So, instead of me making the choice swapping via unis swap, swapping or bridging via across, I simply state my intent. I want to go from A to B and then there should be a marketplace of solvers and these solvers they should compete on on exactly my order on my intent um in order to fulfill it. Um and uh this is um this is essentially what we've been trying to achieve.

Um and we saw the first systems I think co cow swap was the first same chain swap system that was intentbased and then later on at least it was the first popular one and then later on we saw the first intentbased bridges across with 7683 was trying to propose a standard um to go in that direction that standard came with a few disadvantages um but it was in an early first step in the right direction and from there on we have evolved and today I want to talk about a little what has changed in the intent realm what is there when we talk about intent systems what is it we actually have to take a look at um and uh this is essentially where we are going yeah um one of the big existing problems with the intent systems is still that let's say there isn't a cross and I'm launching a new chain um I have to put in a lot of business development efforts to get this system to deploy on my chain it's out of my hand there is no real permissionless deployment of existing intent systems and it comes with overhead for this industry to support new ecosystems and that's not how it's supposed to be. The future will be multi-chain for physical reasons, for economic reasons and for anyone who wants to deploy their own chain. They need to be able to plug into the wider system and we want need to make this as easy as possible. At the same time, solvers need to adapt. So whenever there's a new solver system, we are looking at new standards.

How are things being verified? How do I rebalance my liquidity within that system? Um and so solver systems who already have a hard time being profitable um they need to put a lot of manual effort into supporting these new system. There's a lot of duplicated effort um whereby all of that could simply be standardized and this is exactly where the open intent framework comes into play. Lei was looking into intent systems as we were aggregating these different bridging solutions um over two years.

uh we were looking into these systems and we tried to understand if we were trying to build our own system what could we actually do to make it better um and here the very clear idea was okay we need to standardize across the board and then we talked to the EF and we talked to unis swap and we spoke to open zeppelene who's really good at standardizing things and many many other players in this in the space and we came up with the open intensus uh framework for that we initially bought a whole company catalyst um 0x Jim for those of you who know him um has been building Catalyst for a couple of years and catalyst um managed to build a good foundation for the OAF. It's a foundation because um Catalyst was a bridging system or an intense system that was completely modular and flexible across the board and I will dive into what that actually means. Great. [snorts] Little connectivity problem. One second.

It was supposed to be all cached, but I guess web 2.0 is still not the way it's supposed to be, huh? But maybe maybe I'll just do it um the ugly manual way. That is fine, too. That works, right?

Not as pretty, but you know, we got to start somewhere. All right. So, um the OAF simplifies intents in multiple ways. For once, it is very easy to deploy on new chains. Everything is open source.

So if you're new chain, you can deploy the OAF smart contracts on your own chain. And as you do so, you immediately make it make it easy for applications to send autoflow in that direction. At the same time, servers can plug themselves in with the existing tech they have. It doesn't take them much. They might have to add an RPC, but apart from that, not much else they have to do because everything is provided out of the box.

Um, so it's not only the smart context that are open source, also the whole tooling. Everything in terms of infrastructure and solver and customer support tooling and transaction scanning, whatever you need as a solving system or as an application comes for free open-source out of the box. Um, and as that creates a great foundation for for standards. Um, we have a unified source of truth for intense. um and it can be adopted by not only chains but also applications and that's a great thing.

So if you have massive autoflow and you do not want to rely on third party systems um you can simply use the OIF skip everything else and attract solvers directly in your network. So we really did this with lots of altruistic motives and simply said okay for this space to grow and that's important to us at Leifi. We're like okay we're donating the catalyst system to the O of we make it all open source. We give it all away for free resource locks. So I was already alluding to that 7683 was in the beginning u not the most um flexible solution.

um it was still a little bit too slow when it cames to um fulfilling intents because we would wait for inclusion on the on the source chain before the server would have the guarantee to execute on the destination chain. Now with resource locks we are taking exactly that part offchain. So the idea here is essentially instead of waiting for inclusion on source or destination chain, we simply let the user give a signature and that signature guarantees that funds are locked um and we don't have to wait on finality. That signature is collected offchain. So we have a third party model here.

So we have uh the solver, we have the system that provides the resource lock um and then we have the user and then um that essentially means uh we have web two speed in terms of giving a commitment and being able to trust um and at that time the solver can actually act on the destination shine um and release funds already um and that really allows us to solve for intents within seconds um and uh that's a great benefit. Um the OAF supports all kinds of transaction flows. So we also support 7683 or any other form of escrow mechanism. Um however resource locks are really um the state-of-the-art right now and it's the default thing on how you want to do things. Um this comes with great advantages.

So for example, the ability to have multi-chain inputs. Multi-chain inputs um are more and more important as our funds are spread across so many chains. So let's say you have USDC on four different chains but now you want to make a big purchase somewhere right um at that moment I can simply give a soft commitment um or give that commitment offchain for multiple chains at the same time um I can lock my funds in multiple wallets at the same time and then uh uh I so I don't need to um accumulate my uh my my fragmented resources I I can simply use the funds where they are and then um get to the result I want to um it's much simpl much more simplified approach some sort of chain abstraction essentially the user doesn't care um if you combine that with balance abstraction which is something Metamas and these big wallets are trying to get into already so balance abstraction um combined with this multi-chain input system based on resource locks that really allows us to take this whole space one step forward uh in order um to sec chains further Um, the future of intense is supposed to be modular. Um, I'm going to dive right into this. Um, I've been talking about modularity a little bit already.

Here is a complete overview on what that means when it comes to the intent stack. Uh, we have autoflow origination. Of course, that's that's low hanging fruit one, right? It doesn't matter where autoflow is coming from. Um, the off uh aggregators like Lei or you have your own interface.

Um and then from there on you can really decide by yourself how you want to express your intents. Um there are lots of uh domain specific languages around intents already like those from essential. Um but uh however you want to design these things. Um there are different systems on how you can treat intents and how you want to actually go for transaction flows. 7683 is one.

um unis swap and paradigm they're releasing the compact and then um uh we have escom mechanisms and we have uh resource locks so all of this um is completely modular in the same time you can also depending on the use case decide what kind of an auction model you want to have Dutch auctions first come first ser um or you want to have maybe a subset of solvers that are allowed to compete for something um imagine you are an application like um like like Phantom uh and now you have been able to to provide uh DeFi trading for everyone but now you're going to go towards RWAS and here actually suddenly based on regulatory constraints you need KYC users to be able to use it only so you can you can essentially filter users at the top but you can also be like all right only the following solvers are compliant they have KYB with us so if you need this kind of um restrictive framework um you can do that with um the OAF you have all kinds of solutions to just restrict who can do what. Everything is flexible and modular. Um and you can customize this to your use case. Uh same for the validation side. Um Lei for example is using polymer which is super fast uh in terms of uh validation um and super cheap.

Uh but you can use your own GMP uh general messing passing general messaging uh passing bridge. So it depends really um um um on what you want and what you need. We often see this with chains that partner up with specific messaging bridges like hyperlane or layer zero. Um uh then you can of course just choose your own standard. Um at the same time we are providing lots of modules for solver systems to rebalance the liquidity and it's our continuous effort in the future to build out these systems.

The design space is big. Um we want to make sure that Lei as one of the leading um abstraction protocols in the space um helps the space to grow as a whole. I think for all of us it's very important that um we don't look too much just about our own protocol. We need to grow as a space. We need to work on standards.

We need to communicate. I think decentralization is is really all about um scaling coordination and information exchange right but if our own industry is not able to collaborate here then then like this will never work out. So we need to put a greater emphasis on collaboration um no matter how fierce the market is. Um so we are asking you to look into that standard and really try to understand what we what we are doing here. Um approach us, ask us questions, contribute.

It's open source. Uh and uh yeah I think um this is really uh exciting for us. Um and uh we hope you going to like it. uh Lei itself we do around5 to8 billion dollar month transaction volume and we uh have been sending this order flow to all these aggregated solutions end of March on we going to have our own OAF implementation or like our own intent system uh we already have a variety of solvers queuing um and integrating with us um so if you are a solver system please approach us there's also a form you can fill out I added like a short link um and talk to us, tell us what you need. Um, especially curious if you are looking into solving for different things like pers um or money markets of any kind.

Swapping, bridging are the obvious use cases, but uh the OF is really flexible and we would welcome people that want to work on supporting different types of transaction domains. Um I think uh this is where we're heading in the over the course of the next year. And yeah, thank you all for listening uh and uh showing up. And if you have any questions, feel free to contact me. Um yeah, see you soon.