[trustless://interop.landscape] Alon Muroch - Compose Network: Connecting Every Corner of Ethereum

trustless:// at Devconnect Argentina 2025 · 19 Nov 2025 · 16:03

Alon Muroch, founder and CEO of SSV Labs, introduces compose.network at trustless:// during Devconnect Argentina 2025. The project is an Ethereum-aligned ZK composability layer that links today's many L2s into a network of composable ZK rollups, with one-click UX and same-slot withdrawals. He outlines how a Wrapped Publisher backed by Ethereum validators coordinates atomic, synchronous execution across rollups while each keeps its own sequencing.

Speakers

Topics

From trustless:// at Devconnect Argentina 2025, hosted by Account and Chain Abstraction.

Transcript

Now, from the topic of interoperability to the topic of connection, we're going to have a very special speaker next who's going to introduce a whole new network that connects all corners of Ethereum. Please welcome to the stage Alan Moroc. Hi everyone. Hi everyone, my name is Alan. I'm the CEO of SSV Labs, which is the core team behind both SSV and uh Compose. Uh we're at Compose has the vision of really connecting all corners of Ethereum with this new technology called synchronous

composability. The idea that we can do instant and atomic transactions between rollups and this is fundamental for what I think Ethereum should be uh in the future and what I think uh we should strive for. We've been working on essential infrastructure for Ethereum for quite a while now. Uh building first SSV and then compose which actually uses a lot of the SSV validator set and uh we really are tuned and and aligned with what Ethereum should be and what we want it to be uh which is uh the most powerful uh smart contract uh platform and blockchain in the in the space.

Initially when uh um the kind of the dream of scaling Ethereum was born, we actually started talking about charting uh where validators were both securing Ethereum but also uh facilitating interop between rollups or between shards as we called them back in the day. It proved to be quite difficult to do and so um we moved to the rollupcentric road map where rollup by independent parties still secured by Ethereum but scale it in a much easier way. The problem was that there is no ba based in or builtin interro between those rollups which kind of causes fragmentation across the various roll-ups in the entire Ethereum ecosystem. Every rollup is kind of its

own economic island has its own DAPs users and liquidity. And it's not necessarily that you can move between those rollups or interact between those rollups easily. And it doesn't really feel like one big Ethereum. feels like a bunch of different rollups, economic islands with Ethereum being kind of the main main continent and uh and that's I think a problem. Um, we previously saw other blockchains with some similar approaches like Cosmos really suffering for the fact that various parts of the ecosystem are not one. Even though we are building a bunch of different bridges quote unquote, but those bridges are not really composable rather than fixing or temporarily fixing different things like swaps and cross-chain bridging.

One of those solutions is a synchronous message passing where you basically can move messages between rollups with some kind of an oracle or a committee trusted committee. Uh the problem is that that creates latency and it's not really composable. If you want to do some kind of an interaction between rollups where you ask or read some state from one rollup and and then write a state on another rollup, you can't really do that in one transaction. You have to send a message, wait for it uh to return. there is no guarantee that that message will be delivered or when it's going to be delivered and so composability is really breaking if you try to do um if you try to compose something with uh a synchronous message passing the leading actual uh interrupt solution is our

intents intents flip the script around and say let the user describe what they want to get for example bridge an asset or or or swap a token for something else and offchain solvers or intermediaries will figure out how to fill that um that demand. There's no guarantee of execution and it still uh has some latency even though it's shorter than the the previous solution. There is some latency at least one block and it's not really composable. Again, if you need to wait um um you break composibility and for the most part when people bridge or crosschain swap, it's not the end goal of what they're trying to do. It's just a step. They want to do something on another chain. And so interop uh with intense does solve some of the problems

because it has a better UX but composability is not within reach yet. We're building something called synchronous composability. With synchronous composability we try to bring the main properties of transacting on Ethereum across to rollups. Those three properties are one the idea that we can encapsulate or compose a bunch of inter interactions between one transaction. We can do that in an atomic way, meaning all of those interactions happen together or don't happen at all, which is extremely important for financial applications and transactions.

And ultimately also in a synchronous way, meaning that all of those interactions happen one after the other in one single transaction. Those are the properties that we are used to get on Ethereum and we're trying to port into cross rollup transactions. And when you port them to cross rollup transactions, we give them a name called synchronous composability. And if we now need to kind of compare between all of them, then the current state of affairs is that either we have a very generic type of solution which is slow uh message passing a synchronous message passing or we have something which is faster but it's very specific. Intentbased interrupt is very specific for the fact that it needs or requires intermediaries

and liquidity. meaning that it's mostly focused around one or two use cases and specific tokens that have deep liquidity. Anything else doesn't really work or work well. And of course, composibility is never uh never really existed because again it's it's synchronous and need to wait until the intent is actually executed. With synchronous composability, we actually try to solve both things. We try to do something which is extremely generic and composable but also extremely fast. This is kind of the end goal of where interop should be and what rollups on Ethereum should behave and make you feel like as a user and that's where compose comes along. We're building synchronous composability uh that consolidates liquidity users and DAPs across rollups.

The transaction itself feels like Ethereum. It's not something foreign. It's not it just feels like you're transacting on one big chain. It's instant. transactions are instant between rollups and you have um Zika guarantees for auto atomicity. All of that sounds amazing and that's what we're aiming for. For the first time with ZK technology and the research behind synchronous composability, we can actually do that. We can actually it's within reach and so the tech it's built on top of is called the shared publishing. The idea there is that each rollup that joins the network is actually has an independent sequencer which is extremely important for the business model behind rollups and how they operate. Each one of those rollups has its own sequencer and the

sequencers themselves coordinate, simulate and then execute cross-chain transactions. They produce blocks and ZK proofs for those blocks and a shared aggregation layer called the shared publisher which is made out of Ethereum validators takes those ZK proofs aggregates to one single proof and submits them to the L1 to Ethereum itself. This enables us to guarantee automity through ZK proofs. It enables us to get a lot of rollups independent sequencers to coordinate and do something together for the for the sake of interop. And if you'll notice, it doesn't end just with an integrated set of rollups. It also expands beyond that to external roll-ups like base,

arbitrum, optimism and others which can still facil we can still facilitate synchronous composability with them which is really a breakthrough because we can bootstrap using the biggest rollups with their users deps and liquidity which is essential because competing against them is quite hard. And so [snorts] with the shared publisher layer, we can still make roll-ups be independent, integrate the biggest roll-ups in the industry and do that by the way without their consent. We can just integrate them um through something called the rep sequencer and then have great economies of scale and actually for actually validating ZK proofs on chain because we're validating a bunch of rollups into one single transaction.

The way it works is starts with the mailbox. It's a very simple construct but a very powerful one. The mailbox is where messages are stored during simulation between rollups. You have an inbox and outbox. Inbox is the messages coming into the rollup you're on. Outbox is the me are the messages going out to another uh rollup. The simple check for validity is just comparing the inbox of one rollup to the outbox of another. It's such a simple construct, but it's a very powerful one because it enables us to not just understand how crosschain rollups, crosschain transactions work, but also guarantee their validity.

In order to facilitate and pre-populate messages within those uh mailboxes for synchronous execution, we do a simulation between the sequencers. That simulation happens offchain h and it's based on a very lightweight consensus protocol. It's extremely fast. And during that simulation, all messages are exchanged between sequencers. When they do that, they know which messages are in and which messages are going out. And they decide if they willing to go for execution once the simulation is done. And when they do that, they're executing and then through the shared publisher validate that the execution was valid and also atomic. Meaning there is no way that just one rolled up executed while the other didn't. That's extremely

important for the types of interactions and transactions happening on in crypto in on blockchains. And so all of that is what facilitates the synchronous composability nature of transactions uh within compose. The cool thing about it is opens up the door for many use cases which are not really available today. I'll start with the two most common ones bridging and swapping. We used to have intermediaries or liquidity providers to facilitate those types of transactions. But with synchronous composibility, we don't need them. We don't need any intermediaries. We don't need any liquidity in between the rollups. It's simply a programmatic bridge or programmatic swap on another decks. And that's extremely important because it expands what type of tokens, what type

of uh chains can actually participate. But it goes beyond that. So for example you can facil you can enable crosschain flash loans crosschain art atomic arbitrage you can enable arbitrary read and write for developers which is a gamecher because they can now build multi-chain apps. It also affects how developers deploy their apps because if you have synchronous composability you don't need to deploy your app on a million different rollups. You can just deploy it once on a one rollup because everything every other user on any other rollup is just can interact with it.

It's like on Ethereum. If you deploy your your app on one part of Ethereum, every other user on Ethereum can reach it and use it. The same goes here with synchronous composibility. And so it affects the very way that we develop apps and how we build them and deploy them. And it also enables things like NFD bridging, something which is not really available today because it requires liquidity. So synchronous composability is this construct where we change the way interrupt looks and feels instead of being driven by intermediaries and liquidity. It's actually driven by code. It's driven by ma message passing between rollups and it's completely programmatic and it doesn't have any intermediaries in between. We've been developing the test net for compose for quite a while and

we're almost ready to release it publicly and by end of year we'll also integrate for the first time on testn net the base rollup. So we'll have both integrated roll-ups where there's sequencers published to the shared uh to the shared publisher but also an external rollup like bass and later on arbitum and others that will enable fully synchronous composable instant and atomic transactions between them. So thank you so much. We are super excited to bring synchronous composibility to Ethereum mainet. We think we desperately need this. Composability is probably one of the biggest challenge we have. Thank you so much.

That was such a great session. But don't go too far away because we do have some questions from the audience. So question number one, how can compose leverage and benefit from L1 validators? >> So the shared publisher are the L validators L1 validators themselves. It's a credibly neutral layer uh obviously building on what I think is the best infrastructural component in Ethereum today which are the validators themselves. meaning that validators are the ones running the aggregation proofs for the different rollups and then they publish them to Ethereum that will always always also give way to L1 to L2 composability once ZK proofs are commercially available for real-time proving and so validators are at the heart of what we're doing and it's kind

of going full circle back to the sharding days uh which I think is pretty cool >> that is pretty cool the next question that we have will it work will it work with based rollups or roll-ups with many sequencers as you mentioned they need to do some kind of message exchange if so how will they know which with what sequencer to talk >> yeah so it definitely can work with base sequencing ultimately what we're looking at is the shared publisher just waits for zk proofs in a certain format so whatever happens behind the scenes does it doesn't really matter as long as you provide a valid block with a valid zk proof and so finding the ways to do the the the simulation part is actually not that difficult. If you have one rollup

which is base and another rollup which has a centralized sequencer, then the centralized sequencer always has a constant IP address and so on. And so we can find the solutions for those things and I I I definitely hop and to see base rollups within within compose. >> Next question is how will ZK proofs work with optimistic ones? How do you map their assets? Did you use another bridge composer bridge? >> Yeah, so that's actually a great question. So most of uh fraud proofs rollups uh publish a state and obviously DA um every hour or so uh so mostly states every hour or so what we're going to do is actually ZKI base arbitum and others before they ZKI themselves we're

going to prove on chain the states that they publish and absolutely correct whoever asked that question we we will have uh a shared bridge that is uh ZK proven and also withdrawals will be much quicker and that will be the entry entry and exit point from uh the composable asset class as as we we call it. Um those asset class are going to sit on on base on arbitum and any rollup but they are instantly transferable and usable across the entire uh ecosystem which is really really powerful. Uh and so that's why we need the zk proofs for those types of rollups and yeah we will have a shared uh bridge for for entry and exit.

>> Very cool. This next one says what if base/ optimism reorgs? >> Exactly. So that's why we're producing ZK proofs for the moment they um set a new state on chain. When they set a new state on chain, they actually start a fraud proof game and you can immediately offchain see if that's valid or not. What we're going to do is actually take that computation from the offchain node, zky it and get the proof on chain. So they cannot reorg unless the fraud proof is uh valid or not valid and we can actually check that through the zk proof. And so in between those points they they can reorg but we are doing ZK proofs for the points and not between them. So that's an important point.

Excellent. So many good questions from the audience. Guys, if you have anything super specific that you would like to ask Allan, you can let him know after the session. Thank you so much. Big round of applause, please. >> Thank you. Thank you very much.