Updates on Ethereum Interoperability

EthCC[9] · 31 Mar 2026 · 21:08

Barnabé Monnot surveys Ethereum Foundation protocol work on interoperability. The presentation discusses recent and planned launches intended to make Ethereum’s separate networks feel like one system.

Speakers

Topics

From EthCC[9], hosted by Ethereum France.

Transcript

Hello. Um hi. My name is Barnaby Mono uh from the Ethereum Foundation working on improving UX uh through Interop and excited to share with you some of the updates uh that we have on that thread of work um today. I'm excited to be in Cannes. Thank you for having me. So, what is really our goal here? Um Ethereum has scaled with L2s uh that has introduced a lot of new use cases, a lot of new users, uh differentiated applications. All of that is amazing.

The cost for it though was fragmentation. And fragmentation is just not good UX uh generally speaking. Users have to pay costs in money or latency when they want to move cross-chain. Uh their balances might look very um distracting or confusing. Um and finally, when they move across-chain, chains have different uh lows, I guess. Um so, they might use different gas tokens, and if you don't have the right one, you might find yourself stuck. So, there's there's a bunch of problems uh and we we set out to think about how we can fix them uh at a at a more fundamental um layer.

And so, this is the gist of a strategy that we've been uh executing since last year, uh end of August. Um our first um let's say pillar is try to get some short-term wins fixing cross-chain UX as much as possible and relying for this on users acquiring liquidity fast. So, using intent-based bridges so that users don't have to pay the latency cost and trying to make uh the liquidity for these markets uh as deep as possible and as wide as possible uh so that the market is open, uh democratized and uh serves new use cases.

So, that's the first uh pillar. The second pillar is is more fundamental, like it's more actual uh protocol work. Uh it's basically improving the quality and the latency of L1 confirmations. So, the L1 finalizes blocks. This is what tells other systems that uh the L1 data is um yeah, valid. Then, we can trigger actions based on it. Um so, yeah, really important for the L1 to be to be fast uh in that in that regards. And also important for L2s to to settle back to the L1 as frequently as possible because this is what uh removes friction when you want to move like across uh across-chain.

And so, the more we do this work in the back end of reducing the latency, uh having faster finality, lower settlement times, um the more uh we get close to really competitive uh native message passing. So, what's new as of uh today? Um I would say that the tools that we've built along with our partners are mostly ready and they they are ready to be integrated. And so, right now we're really focused actually on going to market with them uh and supporting the use cases that will um adopt them.

I would say there are two main products which I'll present uh in the first section of of the talk. Uh the first one is the Open Intent Framework. That's a modular uh secure marketplace for this fast liquidity. So, creating a shared market for users to move assets quickly across-chain. And the second one is the Interop SDK, which is kind of an entry point, uh a set of of libraries and packages uh that allows apps and wallets to to to benefit from uh cross-chain uh capabilities. So, I'll talk about these two and I'll present also like a a few more updates on the Interop and and UX fronts uh that I think are particularly exciting.

So, let me start with the Open Intent Framework. So, a fairly broad collaboration uh between EF, OpenZeppelin, uh Wonderland, Arbitrum Foundation, across Hyperlane. Uh there's many people who have uh participated in in building this um this set of tools and this this community. And what is it exactly the the problem that Open Intent Framework is is attempting to solve? So, if you want to move assets cross-chain, um let's say the the basic option, moving to an L2, is to use the L2's canonical bridge. So, this is what the L2 uh has to connect to the to the L1.

And this is basically the validating bridge that tells uh users of the L1 that what happens on the L2 is is valid. So, that happens either in an optimistic way, where you can challenge the L2 state transition if you think it's wrong, that's optimistic, or it can happen in a pessimistic way, where the L2 gives you proofs of its of its validity uh using uh zero-knowledge technology or SNARKs. So, these validating bridges are the most secure. Basically, the L1 can be completely convinced that what happens on the L2 is is valid, but they tend to be quite slow. So, in the worst case for optimistic bridges, uh it takes 7 days to do the trip from L1 L2 to the L1 because you have to wait

until the challenge period ends in case somebody challenges the optimistic state transition. Um in most rollups, optimistic or ZK, it takes many minutes to go from the L1 to the L2, so deposit assets uh from L1 to to L2. And so, these latencies are just not really acceptable for for many users. Um and so, the solution that has emerged and I think has been quite competitive is to have, instead of a user mechanically moving their funds across uh these canonical bridges, have a counterparty on the other side that fronts assets to the user. So, if I want to move 5 ETH from mainnet to Base, I find someone on Base who has 5 ETH and

who's willing to give them to me very quickly and be repaid uh eventually. And the Open Market Open Intent Framework is really this idea of trying to create this shared pool of liquidity and standards uh that makes a single market that's as deep and as liquid and as wide uh as as possible to reduce user costs and user latency and to make uh this market more more accessible. So, this is all built on open specifications, uh standards such as ERC-7683. Uh and we also have like some infrastructure uh that is just ready to be deployed and used uh in production.

So, this infrastructure more specifically, that's basically like a full-stack framework uh built with OpenZeppelin and partners. Uh it's a set of contracts first so that you can deploy uh on chains so that you have these endpoints where users can place their funds and counterparties can fulfill uh orders. There's the an aggregator which is off-chain infrastructure, which is basically like a matchmaker. So, finding counterparties that are willing to to fulfill your your orders. And then there's the solver themselves. So, that's the counterparty that manages its own inventory of assets uh and picks up orders when they think that it's profitable um for them. So, all this code is open source and can be run uh by chains that want to add uh

cross-chain capabilities. A new thing uh that I think is particularly exciting is when this counterparty uh proceeds to make an exchange with a user, an exchange of funds, um there are different ways to to settle the exchange, so to make sure that the exchange is fair, uh that the user indeed received the funds uh that they were promised, and that the counterparty eventually gets repaid. You can use different forms of settlements. Some of them are less secure, some of them are more secure.

But if you want to use, let's say, the one that's as secure as the guarantee that Ethereum gives to its own rollups, uh what you need to do is send messages across the canonical bridges that tie Ethereum to its um to its L2s. And so, we now have, as of uh a couple of weeks ago, fully audited um deployment of the broadcaster, which is a way of sending these messages around. And so, you can trustlessly perform this fair exchange between the user and the counterparty. So, this eliminates uh all all safety issues um with the exchange.

So, I think this is very cool. It's also available as an OIF oracle. So, that means OIF bridges can just plug into this uh settlement contract and they get this trustless capability um basically out of the box, which is super nice. So, a quick call to action. I think we are now ready to integrate. Uh we actually refreshed the website uh pretty recently, so you can check it out at openintent.xyz. And we're really happy to chat uh with a few chains, or many, hopefully, uh who want to um yeah uh bolster their Interop capabilities.

Right. So, that was OIF. So, a shared marketplace for uh fast liquidity uh cross-chain. Now, I'll talk about the Interop SDK, which is kind of a counterpart to this market. It's basically a way for uh apps and wallets to to access the shared liquidity and to also benefit from a broader set of uh of cross-chain um capabilities. So, currently, Interop SDK is essentially a suite of TypeScript packages. Uh the first one is uh Interop Addresses. This is built on the standard uh ERC-7930 and 7828. So, that gives you access to interoperable names like barnaby.eth at

base. So, these are like chain specific addresses that are represented in a in a human readable format. And so, interop SDK gives you access to tools so that you can decode and encode these these addresses. The second package in the interop SDK is interop cross-chain. So, you can think of it as adding some kind of switchboard where you can just change the the interop provider that you use to connect to to different networks. And so, yeah, you can maximize your coverage because now you are a bit more provider independent. You can avoid vendor lock-in as well by just having access to this to this switchboard. So, it's a

really little bit like adding some kind of new RPC to to your wallet. But, instead of an RPC, that's something that requests or transfers liquidity across a cross-chain. So, this SDK is developed with Wonderland and it's also fully open. So, I invite you to to take a look. We have a a nice website for the interop addresses. If you are interested in the integration, you can check it out at interopaddress.com. And an update on this is that we now have an on-chain registry so for chains to to register their chain ID or the name that they want to use for these human readable addresses.

The ENS domain on.eth was recently awarded for this purpose by the DAO. Shout out to Androgabule and Wonderland for for making this happen. And so, yeah, arbitrum.on.eth for instance can be registered. This maps the arbitrum name to some metadata that allows wallets to to figure out like how they should call addresses on that chain. And that gives you access to yeah, writing more human readable or human friendly addresses such as let's say vitalik.eth at arbitrum. So, I think this is really cool and it can really improve a UX, avoid let's say user mistakes of sending assets to the wrong address on on on the right chain.

That happens pretty frequently. So, we think it's a it's a really beneficial thing for the ecosystem to to look into. Another call to action. Again, I think this is ready to to integrate. So, we're really keen to talk to apps and wallets who want to increase their interoperable capabilities. All right. So, these are like the two let's say main infrastructure or more user facing, libraries and infrastructure that we that we have.

I want to talk a bit about this fast confirmation rule which is more of a protocol feature that we think is extremely beneficial for for reducing latencies across the the network. So today many systems wait for Ethereum finality before committing some kind of action for instance registering a user deposit or withdrawal. But, finality is very slow. It's on the order of let's say 13 minutes today. We're working really hard to to make it much faster, but it will still take a couple of years to to get there.

But, we can leverage the way that this finality is obtained which is that we have this very large validator set and they vote over time. And so, pretty quickly actually we can be fairly confident that blocks that are produced won't be reorged just by looking at the votes that have been cast so far. And we can in fact get a very strong guarantee and an actual proof of the safety of these of these blocks. And this is what we call the the fast confirmation rule. So, it's like a flag that tells you, I've seen this block, I've seen these many votes on that block, and I think now as long as some assumptions hold, I the block will not be reorged.

And we think that these assumptions, even though they're weaker obviously than the finality assumptions, they still make sense to to assume in many different use cases. So, namely the assumption is that the network remains synchronous. This is usually the case. Messages that are sent, they get delivered under some kind of bound. And we also assume that there's a smaller than 25% attacker. And as long as these two things don't break, the rule is safe. And in many cases, we think that this is a strong alternative to to using finality.

So, some of these use cases like for instance with faster confirmation, you can reduce the user deposit and withdrawal latencies from L1 to other off-chain systems like centralized exchanges for instance. So, that can remove some of the friction for onboarding users let's say. For rollups, they often times wait for finality or some kind of rule that is let's say a bit more arbitrary so that they can be reasonably certain that the L1 data they are working with is not going to be reorged and yeah, be given like different values.

And so, if rollups were to adopt this fast confirmation rule, they could run at much closer latency to the to the L1. So, for instance, they could price the block space better for their users because they would see the congestion on the L1 almost within the order of 10 to 15 seconds as opposed to today when they wait perhaps 8 to 10 minutes to update their view of the of the L1. So, there's a lot of systems that will suddenly be much more frictionless and much better quoting actual data from the from the L1.

So, yeah, implementations are progressing. We'll have like this production ready pretty soon. You can reach out for integrating this fast confirmation rule and check out our website. Okay, this is another really exciting initiatives. The Ethereum economic zone that was announced a couple of days ago. There's been a few talks on this at at ECC as well. This is something that Gnosis Risk and and their partners have launched.

It's pronounced easy, e e z. And it's essentially a zone for making synchronously composable interactions between the L1 and L2s and between L2s themselves. This is powered by real-time proving so that allows messages to be passed with these validity proofs so allowing the different chains to attest to the validity of the of the interactions. And it can be extended in fact to current L2s, new L2s as well as previdiums. So, there's a very wide set of of ways that this zone can just keep growing based on on today's infrastructure.

So, the mainnet will happen in in summer and you can check out also the website easy.io. And I think yeah, synchronous composability is something that has been quite discussed in the ecosystem. It's it's almost like the holy grail of interop because this means when I do something on one chain and I do something on another chain, they either both execute or they either both don't execute. And this is like a really nice property to have that also yields good UX for for users. How this fits into the picture let's say of OIS and the more asynchronous types of cross-chain interactions.

I like to think of it as a as a barbell especially after this famous Vitalik tweet that was in February that was challenging a little bit how we see the L2s and their interactions with the with the L1. So, I think of it really as on one hand there's maybe this more asynchronous world where you have differentiated sequencing so L2s that don't look that much like the L1 and are chasing let's say their their own goals. Yeah. And the end game here is really having this as fast as possible async interop. So, this is really strengthened for instance by faster finality. So, that's on the one end of the barbell. Now, on the other hand you have this more idea of synchronous messages relying on

rollups that look very closely like the L1 not only in shape but also in the way that they are sequenced. So, they are based and native rollups. And then you have these zones of synchronous composability where perhaps a shared builder is packaging together interactions that are across chain. So, these two ends of the barbell to me there's value proposition on on both sides and I think they also meet in the sense that each of these three things improve each side of the barbell. So, faster finality I think is beneficial for for both sides. Real-time proving is definitely something that allows the system to to just have yeah, stronger

security guarantees. And then standards help having a more unified system where we don't need to have different infrastructures that can't really talk to one another. So, in my opinion, intent and general message passing standards are quite important to to think about to to unify the the system. I invite you also to check out this blog post by Josh Rudolf and the platform team on the Ethereum blog on yeah, some more thoughts on on the L1 and L2s. Okay, I'm almost out of time. It's the last thing I want to show.

A new website that we introduced today from the Ethereum Foundation. If UX. And so the idea here is try and map and solve the most common UX issues. So when we started talking about improving the UX from the Ethereum Foundation, a lot of people came to us and said, "Why does this still happen?" Like these very basic user issues. And so this website is really like a survey and and a funnel of the inbound that we received or that or that we see on social media to try and understand like what are the UX improvements that are at hand, what are the solutions that exist, and how can they be deployed. So yeah, I invite you to to check it out. There are some agent skills. So if you're a developer, you can just point your agent to it and

say, "Learn what good UX is." That's all on the website ifux.design. Yeah, that's all from me. Thank you. I'm not sure if we have time for questions now. I'm Okay, but thank you so much.