Unchained - ETH's HTTP Moment? How Ethereum Interop Layer Hopes to Fix L2 Fragmentation - Ep. 953

Episode Date: November 20, 2025

Thank you to our sponsors! Uniswap Mantle The rise of Ethereum layer 2s has created a need for interoperability. While several solutions have emerged over the years, Ethereum Interop Layer promises to be trustless. At Ethereum Devconnect, the EF’s  developers Yoav Weiss and Marissa Posner join Unchained to explain why trustlessness is necessary for interoperability. They also delve into how EIL differs from NEAR Intents and how it could unlock new use cases and spark an explosion of activity on Ethereum. Guests: Marissa Posner, Product on the Account and Chain Abstraction Team at the Ethereum Foundation Yoav Weiss, Research on the Account and Chain Abstraction Team at the Ethereum Foundation Links: Unchained: Zcash Developer Reveals Q4 Roadmap What’s the Best Way for Ethereum to Grow? Justin Drake and Martin Köppelmann Debate Why the Privacy Coins Mania Is Much More Than Price Action Timestamps: 🚀00:00 Introduction 🤔4:11 What is Ethereum Interop Layer? 🤷‍♂️5:20 What Ethereum Interop Layer is trying to solve 📍7:08 Marissa explains why trustlessness is necessary for interoperability ⛓️8:21 Yoav describes the current state of L2 fragmentation 🔮9:17 How Yoav and Marissa came to work on EIL ⚙️11:53 How EIL works 🔬18:10 How EIL compares to NEAR Intents 🤔22:19 Does EIL bring new security risks? 🚀23:12 Can EIL unlock Ethereum’s HTTP moment? 📌28:26 What EIL wouldn’t make sense for 💭30:09 How EIL can supercharge wallets 📆34:18 EIL’s mainnet timeline 💥35:51 Whether EIL could lead to an explosion of Ethereum activity ⛓️39:06 Why chain security matters 🤔41:17 Does EIL increase attack vectors? 🔮43:20 The future of bridges 📜45:31 The trustless manifesto Learn more about your ad choices. Visit megaphone.fm/adchoices

Each roll-up feels like its own island. I mean, inside each roll-up, it feels like Ethereum used to be, but with a cheaper block space and more bandwidth of block space. But once you need to transact across roll-ups, the experience is that you need to bridge if to the other chain so that you can pay for gas. You need to bridge your assets. So it's like you sign a transaction to bridge,

you send it through a bridge, you wait, you hope that you'll get funds on the other side, and as you may, you know, you know this experience, It's like, you know, you wait and just hope. And then you get them, once you get the funds on the other side, you sign yet another transaction. So it's like there's a lot of friction, especially if you're using a hardware wallet. So all of this friction, it doesn't feel like using one chain. Hi, everyone. Welcome to Unchained.

You're no hype resource for all things crypto. I'm your host, Laura Shin. Before we get started, a quick reminder, nothing you hear on Unchained as an investment device. The show is for informational and entertainment. purposes only, and my guest and I may hold the assets discussed on the show. For more disclosures, visit unchaincrypto.com. Are you a builder who needs to add on-chain trading to your product? The Uniswap Trading API from Uniswap Labs offers plug-and-play access to some of the deepest liquidity in crypto. It's on-chain execution at an enterprise level. More liquidity, less complexity.

Visit hub.uniswop.org to learn more. Mantle is pioneering blockchain for banking. of revolutionary new category at the intersection of Tradfai and Web3. Follow Mantle underscore official to learn more. Hi, everyone. I'm here at the Ethereum Foundation's DevConnect in Buenos Aires, Argentina. And I'm here with Marissa Posner, product on the account and chain abstraction team at the Ethereum Foundation. And Yoav Wyss, research on the account and chain abstraction team at the Ethereum Foundation. Welcome, Marissa and Yoav. Thanks for having us.

So before we get into the details about your... announcement, which is super exciting, which is about the Ethereum interop layer. Why don't we have you just introduce yourself? So give your background and talk about how you came to work at Ethereum. Yeah. Yeah, I can start. So I studied computer science and economics and kind of was always interested in intersection of AI and blockchain. So out of college, I was a machine learning engineer. And then I kind of just fell in love with crypto through a data side of things. I was really interested in understanding everything that was happening on chain. So I started building some analytics tools on top of on-chain data.

Kind of from there, did a few other startups. And last year at DevCon, at DevCon, sorry, I heard about the role at the Ethereum Foundation. It's actually kind of a funny story. I was on a bus to see Moodying, the viral hippo. And I heard someone behind me saying that the EF account abstraction team was looking for someone super specific that fit my exact archetype. And I was like, wait, that's me and like 10 other people. And they introduced me.

And from there, yeah, it was history. And you have? Yeah, so I started working on Ethereum, on Ethereum staff, on public infrastructure in 2017. And when I started using Ethereum, I saw the UX, the onboarding UX was terrible for me because, I mean, I needed to get that. I just wanted to experiment. I didn't want to, so I wanted to experiment with some smart contracts. and I wasn't looking to make some financial stuff and yet it took me like two months to onboard

because I need to pass KYC and I said no just I just want a little to start experimenting so this is not going to work that's not we're never going mainstream with this so my focus became like immediately trying to solve this onboarding problem but doing it in a trustless way we're not not adding like not through intermediaries not through centralized exchanges and this led me to start working on what later became account obstruction.

So at some point, I joined the EF and started building that. The focus is always like improving this, improving UX and user onboarding, but without introducing intermediaries. Okay. So, yeah, let's now talk about your announcement today, the Ethereum Interop Layer. Explain what that is. Right. You want to go?

Yeah. So, yeah, the Ethereum Interoper layer is a way to sort. to solve cross-chain, to cross-L2 transactions. And also the focus here is where we want to have seamless U-X and without, seamless UX without introducing new trust assumptions. And the reason is we are looking at it, the way we look at it, Ethereum scale through L-2s. So L-2s are part of the Ethereum ecosystem.

And as such, you shouldn't have new trust assumptions when you move between them, because otherwise these trust assumptions are part of Ethereum. So we came up with this protocol that does not add the trust assumptions, and yet you have seen as it's going to feel like one chain. You're able to transact on multiple chains as if it's a single chain with the lowest latency possible and without these intermediaries because you self-transact.

You submit your own transactions on each of the chains. So that's EIR. And explain a little bit also about what problem you're trying to solve. with it? Yeah, I think today in a world where we have like an infinite number of chains, such a long tail, and the users are increasingly transacting across many different chains, we need to come around a set of standards, such as interoperability standards between chains, which is something that is kind of a precursor to EIL in our mind. And these interop standards are things that remove chain awareness. So I could send at, send to an address instead of a zero X.

So I could send to, let's say I'm Alice on arbitram.eat. And I, I want to send to Bob at base.aith. I can purely just type in Bob at base. At eath, and my wallet can resolve all of that and send directly to Bob. And this is just one such standard. There's other things like an on-chain config that basically gives one centralized place to look for on-chain information about a chain that lets the wallet be able to resolve this information without having to know the chain before.

Because, like, let's say I'm a user. When I put in this random chain, like XYZ, whatever, Then I like, my wallet doesn't know how to resolve it, but these types of standards let wallets kind of resolve this long tail of chain and do this discovery. And then pair that with EIL, which is basically now you have discovery of chains, but now how do you transact across them? And that's the problem that EIL solves is like when you have all of these chains, now you need a way to move assets across them.

And we were looking at the interoperability space and we were looking at the existing solutions out there. And we were just not impressed by the trust assumptions in many of them. and we felt that it was important and kind of our duty as builders on Ethereum to build a solution that does interoperability in a trustless way without requiring intermediaries, which is why we built EIL. And just explain a little bit more what a trust assumption is, like give an example. Yeah, I think, so trust assumptions, when I think of like trusting someone, that's a way that someone can either hurt you, rug you, or, you. do something bad to you. So that means that they could take my funds, they could block my transaction, they could front run me so I get a worse deal. They can do all of like these different things.

And so I think in a lot of times, we don't realize how many trust assumptions there are and what we're doing online. For example, even with RPCs, there's trust assumptions because we're not verifying the data that comes from the RPC. This is why one of the standards that we're looking into is like client contracts where you can verify the data that you get back from the RPC. So you don't have to trust them blindly. Because when you trust someone blindly, you open yourself up to getting hurt from them. And so a lot of the things that we're thinking about is how can we reduce that attack vector space? And with interoperability, you're actively increasing that space just by nature of compounding different surfaces with each other.

And so, like, we were thinking a lot about that and how to basically make the inter-on solution trustless. And for the explanation of the problem that you're trying to solve with EIL, explain like what the experience is like now and why that's not optimal. Yeah. So nowadays, when you have to, I mean, each roll-up feels like, feels like its own island. I mean, inside each roll-up, it feels like Ethereum used to be, but with a cheaper block space and more bandwidth of block space. But once you need to transact across all-ups, the experience is that you need to, you need to, you need to, you need to, you need to. to bridge if to the other chain so that you can pay for gas. You need to bridge your assets. So it's like you sign a transaction to a to bridge. You send it through a bridge. You wait. You hope that you'll get funds on the other side. And as you may, you know, you know this experience.

Like, you know, you wait and just hope. And then you get them, once you get the funds on the other side, you sign yet another transaction. So it's like there's a lot of friction, especially if you're using a hardware wallet. So all of this friction, it doesn't feel like using one chain, it feels like you are moving between them. Every roll-up is an island and the bridges between them are complex. And what we want to have, we want to have an experience of having one chain but with abandoned block space. So I want to sign one operation regardless of how many chains are involved. And then I want to send it. So I want my wallet to show me exactly what I'm going to do in each chain, but only show it once, let me sign it, and then not have the friction of

bridging or waiting or. And so that's the, that's a, that's a problem we're trying to solve. Yeah. Yeah. It sounds a lot more comfortable or like, like it would give you confidence in transacting. So how did you guys come to work on the EIL? Like you both just talked about, you know, how you came to work at Ethereum, but how did you end up working on this particular problem? So, you know, after we saw, we saw that L2s become increasingly important. A lot of the traffic has been moving to L2s. And we started seeing protocols emerging for solving interoperability between them. And the trust assumptions were not great.

The U.S. was not great. So we figured that we should start working on solving this. And I had this idea of something like the general idea of EIL is something that I've been thinking about for many years now. Because, I mean, I'm a security researcher. and I found quite a few vulnerabilities in bridges. I reported various vulnerabilities over the years. So I know how risky bridges can be. And when I designed ELC 437, the Account Abstruction Standard,

one of the first ideas I had, so one of the first ideas that I had is that actually, since we obstruct the gas payment, you should be able to transact on chains where you don't hold it. and you should be able to do it with one signature because you can obstruct the validation and make it work on multiple chains.

So this has been an idea around ERC 4037 for several years now. And we realize that now that interoperability becomes more important, it's time to actually implement that. So that's how we came to a, and it's a direct continuation of our account of suction work. Yeah, we're actually calling it,

we're calling EIL, account-based interiol. because we're moving all of the interoperability into the users and into the account or the wallet level instead of other types of interop out there like message passing for example okay yeah so explain more about how it works exactly yeah so we are pushing the logic into the wallet you want to make the wallet the user the user agent as opposed to trusting a third party instead of having a silver operate on your behalf all the logic lives in your own wallet And so no matter how many chains you're going to transact on, you're going to generate your own transactions in your own wallet and send them directly not for an intermediary. Now, of course, the complex part is who pays for the gas and how do you have your assets on another chain. So for that, we used paymaster contracts. That's part of ELC437, where it's a contract that can pay. for your gas. And this, and so we created a cross-chain paymaster, which gives you a way to move assets and to pay for gas across chains. And this works by, I mean, for this, you actually

need someone, you need someone to give you funds on the other side, but we didn't want this someone to be involved directly in your transaction. We didn't want to go through that someone. So instead, we have liquidity providers, but the liquidity providers provide you liquidity if you were an atomic swap. By giving you some, on the source chain, when you want to transact, you send a request, and you don't expose your intention.

You don't say, I'm going to mint this NFT on that chain. What you say is, I need the, so I need one if on that chain. So I need one if on the chain to pay for something and for gas. And they give you a voucher. Now, this voucher is an atomic swap. So it's a, but they claim your one if

on the source chain, by giving you this signed voucher. And then the same voucher, you can use it yourself with the Paymaster at the destination. So it's atomic. Like, either they give it to you or they don't. And if they give it to you,

then they already gave you the funds on the other side. So there's no risk that you don't have the, that you end up without the funds. And this allows you to self-transact. So you buy a voucher for gas and for funds on another chain without exposing, without exposing your intention, without exposing your IP address,

because this is fully on-chain, there is no direct connection. They don't know your IP address. You don't connect to some server. Instead, you send a request on-chain. You immediately get a response, which in a competitive landscape is going to happen in the same block

because they're going to sit in the mempool. So someone is going to bundle your request with a voucher because they want to be the first one to claim to claim the fee. And by claiming the fee, they gave you the voucher that you're going to use like in the next block on the destination chain to submit your own transaction. So that's basically how EIL works. Can I, I like to illustrate an example that I have kind of related to what Yoav was saying in kind of the difference between a lot of the existing models, which are a lot of

solver-based models and EIL. So I brought these envelopes with me. This one says user's intention. And inside the envelope, so this is, so I as the user would give this to the solver. The solver takes this envelope and they open it and they read what is in it. And I can see it says to swap 100 USDC to ETH on Arbitram, send that ETH to my friend on base, Bobbibase. So I as a solver, in order to move this from one chain to the other, I need to open the envelope. I need to see the full user intention of what is inside. Now that means that I, as a solver, can front-run the user. I can censor the user.

I can decide not to pass this. And I know what they're going to do. So I have a lot of information about them, like IP address. So I can choose not to pass that. So this has a lot of trust assumptions in it. And so that was something that when we were designing EIL, we wanted to avoid. And so I'm now going to give the example of EIL. So EIL, I have an empty envelope.

And I have an empty envelope because there is no message in it. What is passed, what is past to the voucher is I have a fee, like a stamp of 0.02 cents of USDC. This could be USDC because it could be a non-native gas token. It doesn't have to be ETH because of 4337 paymasters. I have two base. I'm saying who it is sent to and the amount, which is 100 USDC. And all that, so I don't know who my friend is. I don't need to know what I'm doing on the destination.

All I need to know is the amount and who I'm sending it to. It's kind of like if you were going to, if I was good. Not the who on each chain, you don't explain which who on this chain you're going to send it to. Exactly. And so I now as the liquidity provider, which in our case is kind of like the solver, except that I don't know anything about the user, I am only providing liquidity. So if you were kind of thinking about this, let's say I'm going on a trip, right? I'm going from Buenos Aires to Patagonia.

I could take a bus, right? and I could get on this bus. I buy my ticket. The driver knows where I'm going. He knows I'm getting off at Patagonia. He can decide to reroute. He could stop the bus. He can do all of these different things

that would prevent me from getting to Patagonia. But let's say I'm driving my car and I go to a gas station. I need to fill up on gas. That gas station is like the liquidity provider in our example. And that gas station doesn't know where I'm going after. It doesn't know what I'm doing. All it knows is I need this amount of money

and it can choose to give me the gas or not. And it is completely atomic. And then I can go on my way and do the rest of my trip myself. And I don't need to rely on someone else. So that's kind of like one of the big advantages that we're thinking of with Ethereum Interop layer and kind of how it relates back to trustlessness and designing this whole system around it. So it's so interesting hearing these descriptions because also I'm sure you're aware that

near Intense has kind of taken off with the whole Zcash craze recently. So can you explain how this is similar or different from that? So intents in general are a high level construct. It's a different level of obstruction where transactions are, you know, transactions are very prescriptive. You say exactly like, this is my call data, this is a contact address. I want to make exactly this call. Whereas with intense, with intense, you don't say how to do it.

you just say what you want to achieve. Like, okay, I want to have one eith on that chain or I want to have this NFT. And then I let someone, I let the solver figure it out. Now, the problem is this model, it's great, it's very flexible. And if we could have it trustlessly, it would really be awesome.

But it's, but there is room for interpretation, right? I mean, you are not telling the solver how to do it, only what you want to achieve, which gives them a lot of leeway. And the more, the more the way you give a third party, the more they can also hurt you. So you have to introduce some trust assumptions.

So we chose to have EIR. So EAL is a transport layer that works at transaction level. When you use a DAP that needs to do something, it actually tells the wallet exactly this is the call I want to make on this chain and also make that call on that chain. But with an intent, it would just state what it wants achieved and let this third party figure out how to do it. And this is really hard to decentralize.

I mean, having spent a few years on these problems, I can tell you that decentralizing something like intents, there are a lot of ways where the user can grieve the solver. There are a lot of ways that the solver can censor the user. So making it a mutual distrust between solvers and users is a really hard problem. And we chose to, like, instead of having to deal with this problem that I'm not sure how easy it would be to solve. Let's say let's use transactions because DAPS generally know what they want to execute.

It is possible to build an intent framework on top of EIR by having like a local solving. So you could implement some of this logic locally. And instead of having this black box that you send intent to, you can have this transparent box on your own computer that will apply some of this logic. but this requires a lot more research. So maybe we'll get there in the future. Hey, founders and developers. If you're looking to bring on-chain trading

to your product, wallet, or platform, check out the new Uniswap Trading API from Uniswap Labs. It's your plug-and-play gateway to global on-chain liquidity. No deep crypto experience required. And no need to manage complex integrations or ongoing maintenance. With the Uniswap Trading API, you'll get enterprise-grade on-chain execution, combining both on-chain and off-chain sources for the most competitive prices.

Simply put, more liquidity, less complexity. And this isn't just any API. It connects directly to the Uniswap Protocol, which has securely processed over $3.3 trillion in total volume with zero hacks. So stop worrying about liquidity infrastructure and focus on building your product. Get access to the same liquidity that powers billions in swaps through one powerful API. Visit hub.uniswap.org to learn more. Mantle leads the establishment of blockchain for banking as the next frontier. UR is the access layer that transforms Mantle Network into a purpose-built vertical platform,

the blockchain for banking that enables financial services on-chain. UR unifies and vertically aligns Mantle's focus on payments, trading, and assets, MI4, MEath Protocol, Functions, FBTC, supported by developer grants, ecosystem incentives, and the industry-leading distribution platform through the UR app, reward station, and by-bit launch pool. All economic activity within UR will be captured by Mantle Network to further drive value to token holders and establish its significance in blockchain for banking. Follow Mantle underscore official to learn more. Okay. And then as you mentioned, so it's built on account abstraction and that is, you know, something that enables smart contracts

to initiate transactions in an externally owned account, which traditionally has been kind of manually operated by a human. So are there any security risks in this, you know, setup? So account obstruction, I mean, regardless of interim of account obstruction, it gives you a lot of new powerful tools, but also a lot of risk. Like, for example, now you have on-chain code that manages your assets. It's your, it's your account, but if there's a bug in your account, and of course there's risk. But it's not that it's riskier, it's different kinds of risk. Because, for example, with an EOA, you could lose your key or someone could steal your case.

If you lose your key, you lose your asset. If someone steals your key, they have full control over your account. Now, with the account obstruction, it can be more nuanced. You can apply excess controls, like you can have spending limits, can have different keys for different operations, you have session keys that are temporary. So account obstruction improves your security in many ways, but you need the contract to be well audited. So of course, don't go use, put your asset in an account that you don't trust. I mean, you should check that, check that it's been audited.

But once you have that, the security adventures, in my opinion, far outweigh the risks. And at some point, we'll have to get there anyway because of things like quantum resistance. because Ethereum enshrines ECDSA. But ECDSA is not quantum safe. So at some point, we're going to have to switch to other signature schemes. With account obstruction, you can implement any scheme. So this allows us to start migrating accounts to different schemes. So that's a bullet we'll have to buy it in any case.

Okay. And so in order to implement this, Is this something where each chain has to individually integrate it? No, no, okay. So that's the... Okay, you want to understand? Sure. Yeah, so EIL works out of the box on all EVM chains that settled to the L1.

So no, a chain doesn't have to implement anything. Actually, no. It's sort of like, I, in the blog post, they talked about it being similar to HTTP. So can you explain, yeah, just... Oh, yeah, yeah. Yeah, that's a different analogy. But if I just to answer the question, first, so EVM is, sorry, any EVM chain can use it because it's just a smart contract.

Yeah, yeah, it is a set of smart contracts, which you can just deploy. It's permissionless. Anyone can deploy it on any chain. You don't need the team that manages the chain to do it. Currently, it's deployed on TestNet. So we're on Sepolia, Arbitron's Spolia-Betam-Spolya-Based Spolia and Optimism Sipolia. Yeah, that's an important distinction to make. there's not a, we are nowhere near main net yet.

It's a test net, it's a test net rate right now, and we let people start experimenting and integrating, but it's not launched officially yet. Now, the HTTP analogy, that's something I like to use. I mean, being old enough to have used the internet before the mid-90s, I know that, I mean, Ethereum feels a lot, a lot like the pre-HTTP internet. So before HTTP, we had the internet,

and it wasn't very usable. I could telnet to a server and I could tell net to a server and run commands. I could FTP to a server to download a file. Could IRC to yet to yet another server and chat with my friends? We had all of this, but the friction of switching between them, I mean, each application was an island, which each server was an island. And all of these use cases required talking to a single server. So I have one server where download files, but I don't have any usability like chatting with people there.

and the friction of moving between them was actually closing one application on a computer, starting another one, authenticating myself to yet another server. And this is what Ethereum feels like when you move between L2s right now. Now what changed it and made the Internet what it is today is the web. This is HTTP. So with the HTTP protocol, you can have an application that spans across multiple servers. You can have like load the HTML from one place, the images from another, clip call from yet another and even have things like managing your identity on another server,

like authenticating to one server to use an application or another, so you have your identity in one place. And you can have a secure payment server, so now e-commerce becomes possible. All of this composability made it possible for developers not to reinvent the will, but to reuse existing services and build upon them. And what we're thinking is that EIL can do the same for Ethereum. because once you can you can easily compose

with one operation that feels like making one transaction you can actually use up chains and you can combine different up chains to achieve one result then it opens up all this design space which is what

HTTP did for the internet so that's the one so interesting but it's only for L2s right because there's so many EVM chains that are layer ones but it won't work for them right yeah because that So one to us, the assumption, in order to avoid the trusting and oracle,

you need to have a single shared source of truth. And Ethereum has that. In Ethereum, we have L1, which acts as, I mean, everyone settles to Ethereum. So ultimately, you have a way to settle any disputes. There is only one truth. Once you have Alt-L-1s, now you need some intermediary to tell you the state of this L1 is that. And you have to trust that someone. There is no way to prove it on chain. You can vote on it or you can, but we, we chose not to have these trust assumptions, but instead to use L1 for any resolution. Okay. So what types of transactions do you think will use EIL and what types of like new behaviors will emerge from its implementation?

Yeah, I think we're really excited to see what people are going to build. There are so many different UTIP. So today we came out. We demoed our demo app stitch that lets you do a cross-chain composable transactions using Ethereum Interop layer. And some of those examples could be like I could lend 100 USC to AVE and then I could bet yes on a specific prediction market in limitless. And all of these are on-chain things. I can then batch them. Like I could batch five different actions into one. I could even like let's say I want to like swap 100 USDC to eat and then like, like, stake it, for example. But I don't know how much ETH I'm going to get back, right? Like, this value, because, like, the rate might change. It's kind of a dynamic value. But then I'm staking that result. So I can chain all of these things together. And the, like, primitives that you can build on, or, like, what you could build on top of these primitives is a really, like, interesting concept. And I think we're excited to see that. I think I don't know that, like, at the beginning of, like, H. H. H. H. H.T.P., like, if people could even conceptualize what the Internet is today. And so I think

we're really looking forward to what people are going to build. And what are, examples of transactions that it wouldn't make sense to use EIL for? Yes, that's a great question. So for EIL is perfect for single user transactions. When you have a case of multi-party, when you need multiple people, such as like CalSwap, for example, you need multiple users like in the same transaction. EIL isn't the best fit for that. Or is not a fit for that at all because EIL is just a single user and there's no intermediary or like AMM in the middle. Yeah, I will say that any case where there is information, asymmetry, inherited to the use case, such as the example of cows, where someone has an order book and you as a user do not have the same level of information,

this is very intense Excel. So with intense, you can talk to someone who has more information than you, like knowing about the entire order book, and they can match you with counterparties and get your best deal. But as long as you know exactly what you want to do and you have all the information, you don't need to trust a remote server. There's no need to go to a cloud server and add this dependency. If you have all the information, just do it on your own computer. And I think just this morning, we had this, I don't know if you noticed that.

I mean, many things here were not working because Cloudflare had an outage. Now, the notion that you're unable to access your crypto because Cloudflare is done, it doesn't make sense to me. I mean, that's not why we are building Ethereum. So for any use case where you can operate locally on your own computer without adding intermediary, I think you should. Okay. So I did also want to ask, oh, just when you talked about

how this is going to be a wallet level capability instead of like an app-by-app integration, you know, what do you think that unlocks? Like, why is that significant? Yeah, I guess just to clarify, so apps can integrate EIL as well. But when we call it wallet-based interop, because like the interop itself, like what the moving of money is occurring within the user's wallet with the user itself. Wait, sorry, what was the rest of your question? Oh, just like, why is that significant? I don't know if it will, like, unlock new behaviors or just make certain things possible that aren't possible now.

Yeah. So I would say that if we go back to the HCP analogy, the wallet is your browser. And what made a browser special is before that we had an application for, we had an application for each use case. But then with the browser, the browser is much more complex than these applications. It's basically an operating system. And this is the only thing you need as a user. I mean, how much, how much work do you do outside your browser nowadays?

Your browser is one up with infinite use cases. and it just does everything you need. And I think the wallet can become the browser. We empower the wallet to not need any, not have dependencies on any third parties. And now the wallet itself can, now the wallet itself can run any multi-chain, can any multi-chain operation, no matter how complex.

And the way it works for DAPs is a, so now the application, the application doesn't need to know much about EIL. It just needs to tell the wallet, here are the calls I want to execute on optimism, and then I want to execute this on the Arbit Room, and I want to move the tokens that resulted from this call to that call on the other chain.

And so the DAP only needs to communicate that, not knowing how it's going to work, and the wallet is going to figure it out for you. So by empowering the wallet, you enable all of these applications, because now the application doesn't need to worry about plumbing. Currently, applications have a lot of plumbing work to do for Interop. Yeah.

Instead, just tell the wallet and let the wallet figure it out. Yeah, this is part of the bigger vision, I would say, with the interop standards plus EIL, like allowing for, I guess, the greater discoverability and, like, letting the wallet power a lot of the things on chain. It also, one additional benefit is that it kind of reduces the attack factor. When you're not detending on so many different types of intermediaries, you've now reduced the scope. And now, when you concentrate a lot in the wallet side of things, like with the user,

it's much easier to add, I guess, verification and to check things like I was talking about with light client contracts earlier, to verify the RPC calls and to standardize things around the wallets. There's a lot of standardization work going on about that. Okay. And so earlier you mentioned that right now you're on test net. So what is the timeline for? Yeah. Well, we don't want to commit to a timeline. But we are currently released all of the protocol docs to the public today. There's an ETH research post up that people can check out. And the code is also, I think, going live later. So we encourage people to build on EIL to test it out. We want to test out.

There's a lot of crypto economic guarantees and mechanisms behind it. So we just want to make sure that those are solid before releasing to Mainnet. So, yes, I would say sometime in 2026 is when we will go to Mainnet. But in the meantime, people can start experiencing. Since the code is out there, and it's both on TestNet, and we have a setup based on mainnet forks of various roll-ups, so you can actually try it out with existing protocols without risking funds. And we want to see what people start building and get feedback, and maybe this feedback will also make EIL better. Maybe we can learn for this feedback.

So, for example, we're going to offer prizes at the If Global later this week. And we want to see what people build on this network, on these main networks that are now live. So people can start building and telling us how it's going. And we learn from it. And this will take us closer to Mainnet. Then we need to get an audit, of course, as security is important here. And then Mainnet. Yeah.

Okay. So once it's implemented, how do you think it will impact activity on Ethereum? Oh, I think it's going to completely change activity. actually because the moment that you remove the concept of what a chain is from the what a chain is what a bridge is like what gas fees are you've just made it so much easier to transact on chain and you've removed so much friction so by removing this friction you've like opened the floodgates I would say to a like a whole new set of like use cases like I know there's been times where I've wanted to do things on chain I'm like oh well I have to bridge and

then swap and I'm like okay never mind I'm like I don't need to do that but if I could just click with one button like sign this transaction and in all of the that would move at once, like I would have made many more transactions. So we're just hoping that other users agree with us and do the same in the future. I think it also unlocks, I mean, since before all apps, you were able to make transactions on Ethereum the same way because it was one chain, but you did not have enough block space. And we all remember paying insane gas fees. So this, so not many use cases were possible.

because we were just outpriced. Any application that is not financial in nature was outpriced on Ethereum and moved to maybe to alt chains. Now, Roll-ups made it abundant block space, but on each roll-ups separately. So now you could not compose it. Now, what we are doing here is it unlocks it

by having abundant block space, but also being able to use it like a single chain. And that's the unlock we expect to see. see. I don't know what use cases we'll see, but I'm excited to find out. Well, in my head, it sort of feels like this is going to supercharge D5 because it's like the whole little money Legos thing that sort of temporarily became not fully possible. The composability, now if it works correctly, will actually come to fruition. Yeah, that's correct. But something that I have to, like, I mean, if I'm allowed to get

a bit technical, there is one distinction to make here that, you'll be able to make seamless transactions that use multiple protocols, like swap in one place and stake it in another or another chain. But you are not able to make a synchronous calls from a contract on one chain to another. That's not possible due to to finality, which is not a, you don't have this in sync. So it's not that contracts themselves can become composable. Like, you know, it's like having one, like having one protocol, or make direct calls to the contact on another,

that doesn't become possible with EIL, and not with any other protocol right now. But what becomes possible is that you can combine them in a single user flow. Oh, yeah. Yeah, and technically, I guess on the back end, just to clarify for anyone listening, that means that while I, as the end user,

I am signing one transaction. In the back end, like, what is happening is a transaction, let's say I'm going from base to optimism. There's a transaction sent to base, and a transaction sent to optimism. But I, as the user, do not see that nor feel that. Okay. Okay.

Yeah, I'm just thinking, so it'll be one user flow. But essentially what I'm thinking about is, do you remember? I guess this was like in the 2020 era when we would see these crazy hacks where they just combined so many transactions in one block. And I don't remember all the attacks, but some of them may be. also did some economic manipulation. And anyway, point is, so this will not enable that type of behavior again, right?

Because if each chain still has to have its own finality for each stuff, then you can't just, like, string together a bunch of transactions in one block that enable somebody to steal a bunch of money. Is that? So if I do think of the same quote, I mean, there is, you do have the finality risk of each of these chains. So, yeah, when you're interacting across multiple chains, and if one of these chains, for example,

if one of these chains reorgs, and then it undoes some part of your transaction, you are exposed to it. There's no way around it because you are, I mean, you have to trust the chains you use. And the operation is always, The operation is always as weak as the weakest link. So let's say you are using, in the same operation,

you are using three different chains. And one of these chains is not as good as the other ones. And something bad happens there. So you should be aware. And let's say you don't want, at the end of the operation, try not to leave your funds on that chain. So you don't have exposure for,

I mean, after you move your funds out, you don't have exposure, because now your funds are in the destination. But if your destination, like if your funds land on a chain where it's not safe, then EIA is not going to protect you. It is as weak as the weakest chain that you are using for this transaction. I don't know if that's what you meant, but that's the... Okay.

Yeah, I guess what I'm realizing is I do think, though, it will, like, increase the attack surface area to some extent or no? I don't see how. Since we are not introducing new trust assumptions, if you're going to use this network, then using it with EIL does not increase your risk. You are still, you would be transacted. I mean, if you bridged your asset to this network,

it is strictly worse because now you trust the bridge, you trust the bridge operator and you trust the network. With EIL, we remove the bridge operator. You still trust the network you are going to execute the call. Right, right. But actually, what I'm talking about is more the composability of different smart contracts on different chains, like if you're combining them in different ways. So I'm not talking about the bridge itself.

Ah, you mean using things? So since we are not actually adding composability between contracts, the compulsibility happens at the wallet. So like, it's not like, let's say, let's say I'm swapping in uniswop on one chain and then like putting the resulting funds. in Ave on another. So it's not that we added composability between Ava on one chain

and Unisw on the other. They don't trust each other and they could not affect each other. The user just created this one flow, this single signature operation where initially did something on Uniswob,

then took the resulting tokens and deposited it to Avae on the other chain. But now if something bad happens on one of these chains, let's say one of these contract get hacked, it does not affect the contract

on the other, because even if you wanted to, we could not introduce dependencies between this contract. Everything, this composability happens at the wallet, and it only affects the operation for that current user at that current time. Okay. Yeah. Okay. Well, so, you know, as we just mentioned, so bridges are some of the least secure

aspects of crypto infrastructure. So do you feel like now multi-chain transactions will just become inherently more secure, but then also what does it mean for the bridges? Like, do you expect that they'll continue? I mean, I think canonical bridges definitely still have a place. We use canonical bridges. So I think it depends on like what type of bridge. I think that, yes, there's a lot of trust assumptions in bridges these days.

And we would hope that people would migrate towards safer ways of moving money across Shane. And we hope that EIL enables that. So, yeah, I would say that with bridges, so not all bridges are created equal. You have the canonical bridges that are as safe as the underlying chain because in roll-ups, the bridge is a part of the roll-up. And then you have bridges, you have some bridges that have some proof mechanisms, and the worst kind is the kind where you don't have any, and you just send funds to an operator. Now, the problem right now is that they are not held accountable.

So users just pick the cheapest one. they pick the cheapest one and it gets obstructed away they don't even realize that it's riskier and the way to fix that is with something like L2Bit that also gives you like it gives you the information

and say yeah if you're going to use this bridge this is the risk you are taking and just today so Bartek from L2Bit we have the trustless event and Bartek just gave a talk where he presented this new framework they're working on

which will do they're going to do for interrup what they did for L2s. With L2, you know that this L2 is a, so let's say this one is a stage 2 or stage 1, and this other L2 is like stage 0 or worse. So now you get this red warning telling you, you know, this actually, you're going, you're using a chain that is not as safe.

And we want the same for interim protocols. We want the same for bridges. If you're going to send funds with something insecure, maybe you're okay with it because it's just, $10, but you should at least be aware because if it's $100,000, maybe you should reconsider. So the user should be able to make an informed choice, and L2Bit is going to help with that. Yeah. Okay.

Great. Is there anything that I didn't ask you that you feel we should mention in this pod? I don't know if you want to talk about the Trusted Manifesto at all. Oh, yeah, yeah. Talk about that. You talked about how, or you wrote about how the manifesto was like infusing, or you're infusing the values of it into this implementation. So yeah, explain that. Yeah, I think that we wrote the Trussus Manifesto because we felt that it was, we were looking at all these like interop protocols

and we were just seeing all of these crazy trust assumptions and we wrote the manifesto to kind of bring people back and remind people of Ethereum's values and kind of what Ethereum stands for. you know, I think that we wanted to lay out the groundwork, like, rules for the road, like laws that people have to abide by and, like, what builders should be doing in order to build trust the systems and, like, how they should be letting their users know of those, like, trust assumptions. And I think, you know, we kind of, the trust manifesto was a largely inspirational piece. I think, like, at least in the past few days, I've been thinking a lot about, like, okay, what is the action-oriented thing that we can give builders going forward? And that's not something that we've written yet. But I think, I do think that, like, I guess giving builders some more type of guide of how to concretely implement recommendations to improve trustlessness within their systems is something that, like, would be very helpful going forward. All right. Well, it's been such a pleasure.

Have you live on Unchained. Thanks so much. Thanks for us. Unchained is produced by Laura Shin with help from Juan Oranovich, Margaret Curia, and Pam Majumdar. Thanks for listening. Thank you.