Trustless Interoperability Between Rollups: Overview, Construction, and Challenges

Author: Marshall Vyletel Jr. Source: 1kx Translation: Shan Ouba, Golden Finance

Introduction

The number of rollups on Ethereum has exploded. According to L2Beat, as of this writing, 91 L2 and L3 have been launched, with 82 more to come. As a result, there is also a lot of fragmentation in terms of liquidity, user experience, and developer tools. Current interoperability solutions leave much to be desired because they rely on a combination of third-party bridges, externally packaged assets, and intent frameworks, each of which has its own problems.

1. Liquidity bridges are often the target of the largest cryptocurrency hacks (e.g. the $321M Wormhole Bridge hack)

2. Externally wrapped assets are unpopular, with data showing that people prefer to hold assets in native form whenever possible (e.g. canonical bridge assets are valued at $22B, while externally wrapped assets are only valued at $3B, according to L2Beat)

3. Intent frameworks rely on third parties that require some non-negligible trust and charge additional fees to facilitate cross-Rollup activity (e.g. Degen chain users lost over 80% of their tokens due to irregularities in the official bridge). Centralized intent frameworks also mean lower competition, which can lead to suboptimal pricing and performance

In this article, we investigate the trustless interoperability landscape by defining and discussing six levels of interoperability solutions between the decentralized Rollup ecosystem.

We start with the default case of asynchronous withdrawals from a source rollup to L1 and manual bridging to a target rollup, and end with a hypothetical architecture for cross-rollup composability in a single transaction. We explore how each level of interoperability will impact the user experience, developer experience, MEV potential, and the rollups themselves (specifically related to infrastructure changes).

This article focuses on Ethereum and its L2, and focuses only on trustless interoperability. In this context, “trustless interoperability” refers to intra-protocol channels that do not require a third party to facilitate transfers beyond the necessary infrastructure that most rollups already require.

Preparation

Definition

Fundamentally, trustless interoperability requires some shared resources that any two protocols that wish to interoperate must have access to. In the case of Ethereum L1, all smart contracts exist in the same environment that shares the full state of Ethereum, so they will always have the highest level of interoperability. However, L2 only shares a settlement layer through separate bridge contracts, so interoperability is greatly limited.

The key shared infrastructure components that can move us forward on the trustless interoperability ladder are shared sequencers, superbuilders, and shared settlement. The guarantees and new capabilities opened up by these shared layers are related, but essentially orthogonal.

1. Shared sequencers/superbuilders: primarily speed and user experience improvements.

2. Shared Settlement: Asset exchange without external wrappers and in-protocol messaging.

First, we’ll define the six levels of trustless interoperability mentioned in the introduction:

1. L1 Asynchronous:
   → Interoperability is achieved through manual asset transfers over aggregated settled L1.

2. Atomic Inclusion:
   → Guarantee that all transactions in a cross-Rollup Bundle will be included in the next block of every Rollup involved in that Bundle, or none of them.

3. Shared Settlement:
   → Multiple rollups connect to L1 through the same bridge contract.

4. Atomic Execution:
   → It is guaranteed that all transactions in a cross-Rollup bundle will be included in the next block of each Rollup involved in the bundle and executed successfully, otherwise no transaction will be executed. Successful execution means that each transaction is executed without rollback and reflected in the updated state of each Rollup in the bundle.

5. Block-level Composability:
   → The next block of a cross-Rollup Bundle is guaranteed to include dependent transactions (tx B on Rollup B depends on the result of tx A on Rollup A)

6. Transaction-level Composability:
   → Smart contract-level interoperability requires only one transaction to cause state changes between multiple rollups at the same time (no bundling). Using any protocol on any rollup is logically equivalent to using different smart contracts on a single chain. Importantly, this means that any state changes prior to the call can be restored upon return.

To further understand each level, we will cover the following key use cases to showcase the capabilities of each level and its impact on users, developers, aggregates, and MEV searchers.

Examples:

1. Same-Token Transfers
   → Send to yourself: Swap Eth for Eth, or ERC-20 for ERC-20 between two Rollups

2. Token Purchases
   → Cross-Rollup Limit Orders: Use Eth/ERC-20 from Rollup A to buy a different ERC-20 from the DEX on Rollup B and (optionally) send back to Rollup A

Implications:

We will also answer the following questions to further understand the impact on key stakeholders in any Rollup ecosystem.

1. User Experience
   How would the user experience change by achieving this level of interoperability?

2. Developer Experience
   How would the developer experience change by achieving this level of interoperability?

3. MEV Potential
   If we achieve this level of interoperability, are there new MEV opportunities that could emerge?

4. Rollup Impact
   Do Rollups have to opt-in to any new infrastructure to make this happen? What are the changes to Rollup fee structures? What potential benefits could Rollups have from participating in this infrastructure?

High-level Overview

Six Phases Towards Trustless Interoperability

1. L1 Asynchronous

Required Infrastructure:

Not applicable

By definition, this refers to the current default trustless interoperability mode. All rollups are defined this way because they are built on L1 as a settlement layer and can only access that L1 through a bridge contract, which they periodically publish state updates to protect the network.

In this case, the only canonical way to perform any trustless cross-Rollup activity is to extract assets from the source Rollup through the canonical bridge and manually deposit them into the target Rollup once they are available on L1.

For Optimistic Rollup, withdrawal latency is about 7 days considering the error-proofing window. In ZK Rollup, withdrawal latency is less certain, but can be between 15 minutes and a full day, as is the case with ZkSync.

Also, peer-to-peer atomic swaps are possible using smart contracts, but this is a smaller use case and does not scale effectively.

It is worth noting that there are currently third-party solutions:

1. Liquidity Bridge

2. Intent Framework

Both of our examples require third-party solutions to assist.

Send to yourself:

1. Canonical practice:
   → Withdraw assets from Rollup A
   → Manual deposit into Rollup B

2. Third Party:
   → Liquidity bridges/solver networks

Cross-Roll Limit Orders

1. Canonical:
   → Withdraw assets from Rollup A
   → Manual deposit into Rollup B
   → Execute limit orders
   → To send back, the target ERC-20 must be externally wrapped

2. Third Party
   → The emerging solution space for cross-roll limit orders
   → There are open designs around using intent to facilitate this

Since this is the default, there is no need to discuss changes to UX, DevEx, MEV, and rollups.

2. Atomic inclusion

Required infrastructure

Shared sequencer *

Atomic inclusion only guarantees that a cross-rollup bundle will be included in the next block.

This requires a shared sequencer, but in theory this can be achieved manually (just submit two transactions to each rollup separately) if the sequencers on two given rollups are not reaching maximum throughput. This is why we added an asterisk on the required infrastructure.

However, we do not assume that the shared sequencer runs a full node of each connected rollup, so successful execution of a set of transactions cannot be guaranteed. In this case, the shared sequencer can only guarantee that the transaction is well-formed and will be included in the next block, but not necessarily that it will be successfully executed.

Since there are no execution guarantees, it is not possible to programmatically exploit atomic inclusion in any meaningful way without incurring the risk of one of the transactions being revoked. Therefore, we are essentially in the exact same situation as with L1 Async interoperability.

Consider launching a simple cross-Rollup swap with only atomic inclusion guarantees:

1. Cross-Rollup Swap Bundle
   → Tx 1: Lock/burn tokens on source Rollup
   → Tx 2: Mint tokens to user address on target Rollup

We may have atomic inclusion guarantees, i.e. both transactions are actually included in the next block of each rollup, but if the first transaction rolls back and the second does not, the user will incorrectly allocate funds on the target chain without locking or burning them on the source chain, and we have a double-spend problem.

Any interoperability solution, whether it’s a liquidity bridge, an intent framework, or an xERC-20 swap, is vulnerable to this risk, and it’s impossible to mitigate it. Because of this risk, current solutions require that the originating transaction must have been successfully executed and included in a block on the source chain before a relayer can be used to pass the outgoing message and execute the second transaction on the target chain.

Important note: atomic inclusion does not have a significant impact on interoperability potential

3. Shared Settlement

Required Infrastructure:

Proof Aggregation Layer // Shared Bridge Contract

This is where things start to get more interesting. Thanks to the shared bridge contract, all liquidity deposited into the rollup ecosystem from L1 can move freely between all connected rollups. Before this, we could not exchange between rollups without going through canonical channels, externally wrapped assets, or using third-party solutions.

Why build a shared bridge contract? To understand why shared bridge contracts allow us to transfer assets across Rollups in a trustless way, first consider what would happen if you could own Eth in Rollup A, destroy it, and then mint it natively on Rollup B without having to build a shared bridge contract on Layer1.

We see that each rollup will be out of sync with the bridge contract on the mainnet. The rollup B bridge contract still has 50 Eth, so the user cannot withdraw their 1 Eth to L1.

To solve this problem, we built the External Asset Wrapping Protocol, which issues external wrapped versions of tokens in rollups that tokenize native versions elsewhere in the network.

With a shared settlement layer, this is different. Since all liquidity for each connected rollup is locked in the same bridge contract, people can move freely between rollups because the total value in the bridge contract remains the same and can always be withdrawn.

It does require updates at the L1 contract level to understand where liquidity is to allow users to withdraw from anywhere, but this is simple because all connected rollups can read/write to the shared contract.

With a shared settlement layer, the flow might look like the following for a simple send to yourself case.

Send to yourself:

1. User creates initial transaction:
   →Tx 1: Withdraw Eth on rollup A (and mint on rollup B)
   →The transaction is batched and submitted to the L1 contract
   →It is aggregated into a transaction root that groups all shared settlement rollups

2. Rollup B imports this transaction root

3. Relayer submits transaction to mint and Merkle proof to rollup B

4. Rollup B uses Merkle Proof and transaction root to verify destruction transaction

5. User sends transaction to mint and Merkle proof to rollup B

6. Rollup B uses Merkle Proof and transaction root to verify destruction transaction

7. User sends transaction to mint and Merkle proof to rollup B

8. Rollup B uses Merkle Proof and transaction root to verify destruction transaction

9. User sends transaction to mint and Merkle proof to rollup B

10. Rollup B sends transaction to mint and Merkle proof to rollup B

11. Rollup B submits proof to L1

We can extend this flow to any ERC-20 that has contracts in all rollups in the shared settlement ecosystem.

We can think of the shared bridge contract as an intra-protocol messaging layer between all connected rollups, so in theory this flow can actually be extended to any arbitrary messaging standard.

This gets us closer to composability, but since aggregation proofs and messaging are only required after the state change is reflected on L1, latency is higher (although significantly lower than the L1 asynchronous case). Additionally, any complex cross-Rollup activity (such as placing a cross-Rollup limit order using a DEX on Rollup B starting from an asset on Rollup A) will still be a cumbersome process for users, as they still have to send themselves and manually swap the assets on the target Rollup. In this case, it is impossible to create atomic cross-Rollup bundles.

Another important benefit of shared settlement is that there is less friction for liquidity providers or solvers who execute orders in multiple environments. Since their liquidity across all connected Rollups is reflected in the same bridge contract, they do not have to wait for a full withdrawal window to manage cross-Rollup liquidity.

Impact on Stakeholders:

1. Users:
   Assets can now be transferred in native form, without L1 withdrawal period

2. Developers:
   Changes are limited to token issuers, who can now issue native versions of their ERC-20s on all connected Rollups using in-protocol messaging

3. MEV Seekers:
   Since this happens over multiple blocks per rollup, there is no new MEV potential

4. Rollups:
   Rollups must choose to use a shared bridge contract and potentially add precompiles to handle cross-Rollup messages

4. Atomic Execution

Required Infrastructure:

Shared Sequencer // SuperBuilder

Atomic execution allows us to guarantee successful execution of cross-rollup bundles, but as we will see, the number of use cases for cross-rollup bundles without dependent transactions is less than initially expected.

If any single transaction in a set of dependent transactions is reversed, then all others become invalid and must also be reversed, as is the case with burning and minting tokens across rollups. Minting tokens on the target rollup depends on whether they have been burned or locked on the source rollup, so we can say that a set of burn and mint transactions is a set of dependent transactions.

It is impossible to create this bundle without an intermediary party (such as a super builder) that is able to create the target transaction.

Consider what conditions must be met for the construction of a cross-Rollup swap bundle without the participation of other parties other than users. A bundle must be created to lock/burn assets on the source Rollup and mint assets on the target Rollup, but we have a problem:

1. Contracts on the source rollup can only issue messages when they lock/burn the original source assets, they cannot call and create transactions on the target rollup.
   →This is why the message protocol and relay network exist.
   → Messages can be used to construct what the call on the target should be, but it cannot actually create the transaction itself.

2. Create a second transaction on the target rollup to mint:
   → The user cannot create this tx themselves, as they do not have minting rights to the tokens on rollup B
   → ie) the target chain needs proof that the tokens have been burned/locked on the source chain, but this proof is not available until after the initial transaction executes, which breaks our requirement for atomicity. → In theory, any other party that is able to
   create a second transaction with minting rights can create a "minting" transaction on the target chain at any time without first creating a "burn" or lock on the source chain, which is a huge loophole.

We can see that even if we can guarantee execution across rollup bundles, we run into difficulties with how to structure them in the first place to transfer valuable assets.

However, there are still use cases for atomic execution that do not require relying on cross-rollup bundles. One of these is cross-rollup arbitrage:

Since there are no strict dependencies between these transactions, anyone can create this atomic package and submit it to a shared sequencer that guarantees atomic execution.

However, in order to get the atomic execution guarantee in the first place, the rollup must elect a shared sequencer and superbuilder to run the full nodes of all connected rollups, so the step from atomic execution to block-level composability is very small, and all shared sequencer solutions will do this. The only change required is that block builders or other third parties must be able to create transactions on behalf of users to complete dependent cross-rollup bundles.

It is unlikely to build infrastructure that only allows atomic execution without further enabling composability. Given that the infrastructure already has atomic execution capabilities, the relative gains of achieving full block-level composability far outweigh the difficulty of achieving this goal.

Impact on Stakeholders:

1. Users:
   Probably no changes, although third parties may offer solutions like intent, it’s unclear exactly how this will be achieved

2. Developers:
   Probably no changes

3. MEV Seekers:
   Cross-rollup arbitrage is safer given atomic execution

4. Rollups:
   Rollups must opt-in to use a shared collator/superbuilder, submitting blocks containing transactions from every Rollup that wishes to interoperate, which may change the revenue structure of Rollups. It’s not clear how it will change. -
   Ordering markets may increase Rollup revenue by allowing sophisticated builders to purchase ToB space

Important note: While atomic execution is guaranteed across rollup bundles, it is unclear how those bundles will be built without a superbuilder that creates parts of the bundles, so atomic execution itself is unlikely to impact interoperability. Shared sequencers/superbuilders should build block-level composability by default.

5. Block-Level Composability

Required Infrastructure:

Shared Orderer // SuperBuilder // Proof Aggregation Layer* // Shared Bridge Contract*

(* = optional)

In much of the discussion about shared sequencers and shared settlement layers, the term often used to describe this level of interoperability is “synchronous composability”.

We have modified this terminology slightly to be more descriptive. Updating the terminology to “block-level composability” means that cross-rollup transaction packages can be composed between two rollups that will be included in the next block and successfully executed. Synchronous composability can be confused with transaction-level composability, which we explore in the next section. Importantly, this requires an intermediary (shared ordering infrastructure) that can be both the executor and creator of dependent transaction packages.

At this level, we begin to see true composability between Rollups, beyond simply sending to yourself to participate in a dapp on another Rollup.

By adding a shared sequencer that can create transactions, we can now make cross-rollup packages that developers can programmatically leverage.

There are two cases to consider:

1. Block-level composability

2. Block-level composability + shared settlement layer

In both cases, we can create cross-rollup bundles for more complex activities, but in the second case, with shared settlement, we can use native assets, which may have better price impact on cross-rollup DEX activities, for example.

With block-level composability, we have the advantages of atomic execution and the additional ability to create dependent transaction bundles. Let's take a look at our two illustrative examples.

Same token transfer via xERC-20 (no shared settlement):

1. User owns ERC-20

2. User creates tx via dapp:
   → Deposit ERC-20 into xERC-20 lockbox to receive xERC-20 wrapped version
   → Destroy xERC-20
   → Send a message to shared ordering infrastructure indicating that a cross-rollup transfer has been initiated, with relevant data to facilitate the exchange

3. Superbuilder picks up the transaction and creates a cross-rollup bundle
   → Tx 1: Wrap and destroy transaction above
   → Tx 2: Mint on Rollup B xERC-20

4. Superbuilder submits this cross-rollup to the shared sorter
   → Since Superbuilder is running full nodes of both connected rollups, they simulate transactions to ensure that the bundle executes successfully. If either transaction rolls back, the entire bundle rolls back.

5. The shared sorter submits the block containing both transactions to the DA layer and the nodes that execute the state changes

6. xERC-20 is minted to the user on Rollup B

With a shared settlement layer, the process is further simplified as there is no need to first wrap the ERC-20 as an xERC-20 for exchange.

Now let’s look at a cross-Rollup limit order, where an ERC-20 is purchased on Rollup B with an initial (different) ERC-20 from Rollup A, and the resulting ERC-20 is sent back to Rollup A. In this case, we do not assume that we have a shared settlement layer, although a similar process exists in the case that there is a shared settlement layer. The only difference is that no additional external wrapping of the assets is required.

Here are the transactions required in this case:

1. Wrap and destroy ERC-20 on A

2. Mint ERC-20 on B

3. Swap initial xERC-20 with target ERC-20 on B

4. Wrap and destroy target ERC-20 on B

5. Mint xERC-20 on A

Here is a possible workflow:

Flow:

1. User initiates the first transaction:
   →Wrap and destroy xERC-20, and send a message to specify the exchange parameters (target chain, DEX

2. The superbuilder sees the transactions and creates bundles:
   → Tx 1: User creates transaction above
   → Tx 2: Mints xERC-20 at destination (superbuilder must have minting permission)
   → Tx 3: Makes limit order using data from tx 1
   → Tx 4: Wraps and destroys ERC-20 on B, assuming limit order is fully fulfilled, and sends message on source chain to mint
   → Tx 5: Mints destination xERC-20 from swap output on source chain

Since the superbuilder creates blocks and orders transactions, it can simulate every transaction and omit bundles if any transaction is reversed. For example, if it is found that a user cannot fully fulfill their limit order, the bundle is omitted before the block is executed.

In the case of a shared sorting infrastructure without a shared settlement layer, external wrapped versions of Eth and xERC-20 would need to be used, which could lead to worse market conditions for the DEX as the liquidity pool for the wrapped assets becomes thinner. In this case, users may have to use looser limits, have a higher tolerance for slippage, and may receive sub-optimal prices. There is an exception if USDC is involved. A shared sorter without shared settlement might work with Circle to obtain exclusive rights to the USDC contract across rollups to facilitate native USDC transfers and swaps across rollups.

With a shared settlement layer, this external wrapping would not be necessary and may provide better prices due to the deeper liquidity pools for native asset swaps, but the process would be largely the same.

Optimistically Trusting Sequencers

Rollups need to optimistically trust the shared sorter/superbuilder to create a valid cross-Rollup bundle. This is primarily because this cross-Rollup bundle contains dependent transactions that the individual Rollups cannot verify until after a block has been added to each Rollup’s chain and aggregated to the settlement layer on L1. An example is the initial destruction and minting of Eth from a source to a destination. It is critical that the Eth is actually destroyed on the source chain before it is minted on the destination chain, otherwise double spending could occur.

However, for this complete bundle to be executed in a block, all transactions must be present in that block, even if the transactions represent state that was invalid before the block itself (e.g. if a user did not have any Eth before the block, then had Eth on the destination chain of the swap). Therefore, we must trust that the sorter actually included valid dependencies in the cross-rollup bundle. Proofs can be submitted after the fact to prove the validity of each transaction.

However, this is less critical when using wrapped assets as they have no impact on native liquidity stored in L1, but there must still be fallback mechanisms to offset the risk of a malicious collator or a bug in the code that allows a transaction bundle to be executed with dependent transactions being reverted.

Impact on Stakeholders:

1. Users
   A massive upgrade to the user experience, allowing cross-rollup limit orders in a single block

2. Developers
   Need to be cross-Rollup aware of cross-Rollup activity, possibly leveraging custom precompiles. Developers must think in terms of Bundles, not just transactions, but superbuilders and custom Rollup infrastructure will likely remove complexity for most developers.

3. MEV Seekers
   MEV Seekers have essentially the same opportunities to use L1 strategies on cross-rollup bundles, but this depends on how PBS (proposer-builder separation) is implemented.
   → Cross-rollup bundles are essentially treated as a single transaction, so MEVs can be found by front-running or clamping these bundles, as long as they do not push the price beyond a tolerable amount of slippage (as then the entire bundle would revert and the MEV attempt would fail)

4. Rollups
   Requires opt-in to the shared sorting infrastructure (including superbuilders) and allows access to Eth burning/minting in shared sorters in the case of a shared settlement layer.
   → MEV can be internalized by selling block space to builders

6. Transaction-level composability

Required infrastructure:

VM-level changes // Shared settlement // Superbuilder

Transaction-level composability refers to the same level of functionality shared by smart contracts on one EVM chain. In this case, a single transaction can update the state of multiple rollups simultaneously, and ensure that if a call does not return successfully, any state changes before any call can be reverted. In fact, atomic transaction packages in a block-level composable environment can be done in a single cross-rollup and cross-VM transaction. In addition to a shared settlement layer and superbuilder, this requires VM-level changes to all connected rollups.

We describe a possible mechanism at a high level here. (To the best of our knowledge, this construction is attributed to the Espresso team). First, a user submits a cross-rollup transaction to all rollups whose state is changed by the transaction or to a superbuilder who can build blocks on all relevant rollups. The superbuilder simulates the transaction and forms a list of input-output pairs, one for each relevant rollup, that specifies the necessary and expected cross-rollup messages in the transaction. (Note that the superbuilder can only do this if it has secure ordering rights over all relevant rollups for some period of time). The superbuilder then sends the simulated block to the proposer of each rollup along with the list of expected input-output pairs for each cross-rollup transaction. During execution, each rollup executes its own state transition function normally, assuming that the inputs from the list of cross-rollup transactions are correct. During settlement, the input-output lists can be cross-compared and proven to be safe during the proof aggregation phase of the shared settlement layer. Specifically, if any expected input of a cross-rollup transaction does not match the output specified by another rollup, the settlement process will reject the entire cross-rollup transaction.

While transaction-level composability is limited in the new capabilities it can unlock beyond flash loans, the developer experience of creating cross-Rollup applications can be greatly improved. Being able to create dapps that interact with all connected chains without having to think about cross-Rollup bundles will make it much easier to innovate in a multi-Rollup environment. In addition, new use cases and behaviors may emerge.

There are many unresolved design problems with transaction-level composability. First, careful consideration needs to be given to how developers can opt in or out of cross-Rollup calls to their smart contracts. Allowing arbitrary composability without restrictions means we return to a single Rollup. We think the answer here is for developers to explicitly indicate where in their contracts they need cross-Rollup composability, such as by marking certain entry points of a contract as callable across Rollups through Solidity modifiers such as "composable"

Impact on Stakeholders

1. Users:
   Same meaning as block-level composability with additional advanced features like flash loans
   → UX is nearly identical to opt-in dapps using one chain

2. Developers:
   Developer experience is greatly improved since dapp developers can natively call contract cross-rollups and use the outputs of those calls like single-rollup calls→ Superbuilder/Sequencer infra still has to place transactions in blocks that are rolled up by cross-rollup calls, but don’t have to build the same bundles as with block-level composability.

3. MEV Seekers:
   Cross-rollup bundles are now essentially equivalent to a single transaction on one chain, so MEV potential is high

4. Rollups:
   Requires VM-level changes, and the choice of a shared sorter and shared settlement layer
   → Inputs and outputs of other rollups must be trusted before state can be verified via proofs, which involves additional trust assumptions, but slashing mechanisms can reduce the trust burden

Summary and Ecosystem Diagram

After understanding the technical details of each interoperability level defined here, we can summarize:

1. Shared settlement allows cross-rollup swaps without externally wrapped assets, and creates an in-protocol messaging path between all connected rollups

Summary and Ecosystem Diagram

After understanding the technical details of each interoperability level defined here, we can summarize:

There are currently many projects emerging that aim to create these natively interoperable ecosystems. Here is a high-level overview of the space: Ecosystem Map Ecosystem Map src src https://miro.medium.com/v2/resize:fit:1400/format:webp/0*y0VAdd4UXqa6d4OG Ecosystem Map Concluding Remarks There are still some open questions about the technical details of the frameworks outlined in this article. For example, building bundles for cross-aggregated limit orders in a blockchain-level composable ecosystem may require more detailed designs to handle partial fulfillment and slippage tolerance for market orders. We offer a potential solution here to recover cross-aggregate limit order bundles if the order is not fully filled, but the design space is open.

Also, it’s worth mentioning that this is relevant to the growing mindshare in the appchain space right now. Appchains are the long-tail L2s that are either general purpose or permissioned and are designed to isolate specific related protocols on a single L2. As we reach block-level composability, we will likely also start to see appchain environments gain significant traction with native composability between all connected networks.

Right now, it remains difficult to bring liquidity to these appchains, but once larger chains are connected as on-ramps to interoperable environments, we will likely see walled garden ecosystems around shared infrastructure.

Another important open question is how the design space around super builders will be resolved. Developments in this area are still in their infancy, and it is not clear how to create a complex network of builders that can create cross-aggregate bundles in the most efficient way. How these cross-Rollup packages will be optimally included in blocks, and the impact on rollup revenue is an open question with many teams exploring different strategies.

Ultimately, the future will likely involve a combination of in-protocol and out-of-protocol bridging solutions that work together to make the interoperability process better for everyone. We believe that the progress defined in this article can serve as a guide for developers and builders who are focused on making cross-Rollup interoperability more seamless for end users.