Introduction

There has been a Cambrian explosion of rollups on Ethereum. At the time of writing, there are 91 live L2 & L3s and 82 upcoming according to L2Beat. As a result, there is also a significant amount of fragmentation in terms of liquidity, user experience, and developer tooling. Current solutions to interoperability leave much more to be desired, as they rely on a combination of third party bridges, externally wrapped assets, and intent frameworks, each carrying their own set of problems.

1. Liquidity bridges are often the targets of the biggest crypto hacks (e.g. the $321m wormhole bridge hack)

2. Externally wrapped assets are undesirable, and data have shown that people would rather hold assets in a native form whenever possible (e.g. there are $22b worth of canonically bridged assets and only $3b worth of externally-wrapped assets, according to L2Beat)

3. Intent frameworks rely on third parties that require some non-negligible trust, and come with additional fees to facilitate cross-rollup activity (e.g. Degen chain user losing >80% of tokens due to official bridge being non-canonical)a. Centralized intent frameworks also mean lower competition and this could lead to suboptimal pricing and performance

In this article, we survey the trustless interoperability landscape by defining and discussing six levels of interoperability solutions between fragmented rollup ecosystems.

We start with the default case of asynchronously withdrawing from the source rollup to L1 and manually bridging into the target rollup, and we end with a hypothetical architecture for cross-rollup composability within a single transaction. We will explore how each level of interoperability will affect the user experience, the developer experience, MEV potential, and rollups themselves (specifically related to infrastructure changes).

We stay mostly within the scope of Ethereum and its L2s for this article and focus solely on trustless interoperability. In this case, “trustless interoperability” refers to in-protocol channels that do not require third parties to facilitate transfers outside of the necessary infrastructure that most rollups already require.

Preliminaries

Definitions

Fundamentally, trustless interoperability requires some shared resource that any two protocols wishing to interoperate must have access to. In the case of Ethereum L1, all smart contracts live in the same environment sharing the full state of Ethereum, so they will always have the highest level of interoperability. However, L2s only share a settlement layer via separate bridge contracts and so interoperability is far more limited.

The crucial shared infrastructure components that can progress us along the trustless interoperability ladder are shared sequencers, superbuilders and shared settlement. The guarantees and new functionality opened up by these shared layers are related, but essentially orthogonal in nature.

1. Shared Sequencers/Superbuilders: Primarily speed and user experience upgrades.

2. Shared Settlement: Asset swaps without externally wrapping as well as in-protocol messaging.

To begin, we will first define the six levels of trustless interoperability alluded to in the introduction:

1. L1 Async:
   → Interoperability via manual asset transfer through the L1 that rollups settle to.

2. Atomic Inclusion:
   → A guarantee that either all transactions in a cross-rollup bundle will be included in the next block for each rollup involved in the bundle, or none will.

3. Shared Settlement:
   → Multiple rollups connecting to the L1 via the same bridge contract.

4. Atomic Execution:
   → A guarantee that either all transactions in a cross-rollup bundle will be included and successfully executed in the next block for each rollup involved in the bundle, or none will be executed. Successful execution refers to each transaction being executed without reverting and being reflected in the updated state for each rollup in the bundle.

5. Block-Level Composability:
   → Next block guarantees on cross-rollup bundles that can contain dependent transactions (tx B on rollup B is dependent on the result of tx A on rollup A)

6. Tx-Level Composability:
   → Smart contract level interoperability requiring only one transaction that can cause state changes across many rollups simultaneously (no bundles). Using any protocol across any rollup is logically equivalent to using different smart contracts on one chain. Importantly, this implies that state changes prior to any call can be reverted when it returns.

To understand each level further, we will walk through the following key use cases to demonstrate the power of each level as well as the implications for users, developers, rollups, and MEV searchers.

Illustrative Examples:

1. Same Token Transfer
   → Send-to-self: Swapping Eth for Eth or ERC-20 for ERC-20 across two rollups

2. Token Purchase
   → Cross-Rollup Limit Order: Using Eth/ERC-20 from Rollup A, purchase a different ERC-20 from a DEX on Rollup B and (optionally) send back to Rollup A

Implications:

The following questions will be answered as well to further understand the impact on key shareholders in any rollup ecosystem.

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

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

3. MEV Potential
   Is there a potential for new MEV opportunities if we achieve this level of interoperability?

4. Rollup Implications
   Does the rollup have to opt-in to any new infrastructure to achieve this?What are the changes in fee structures for the rollup?What might the potential benefits be for rollups to participate in this infrastructure?

High-Level Overview

The Six-Level Progression Towards Trustless Interoperability

1. L1 Async

Required Infrastructure:

N/A

As defined, this refers to the current default mode of trustless interoperability. All rollups are defined as such because they are built on an L1 as a settlement layer and have access to that L1 only via the bridge contracts where they periodically post state updates in order to secure the network.

The only canonical way to perform any trustless cross-rollup activity in this case is to withdraw assets from the source rollup via the canonical bridge and manually deposit them into the target rollup once they are available on the L1.

For optimistic rollups, this withdrawal latency is ~7 days to account for the fault proof window. In a ZK rollup, the withdrawal latency is less certain but could be anywhere from 15 minutes to a full day, as is the case with ZkSync.

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

It is worth noting third party solutions that currently exist:

1. Liquidity bridges

2. Intent frameworks

Both of our illustrative examples require third party solutions to facilitate.

Send-To-Self:

1. Canonically:
   → Withdraw assets from Rollup A
   → Manually deposit into Rollup B

2. Third Party:
   → Liquidity Bridge / Solver Networks

Cross-Rollup Limit Order

1. Canonically:
   → Withdraw assets from Rollup A
   → Manually deposit into Rollup B
   → Perform limit order
   → To send back, one would have to externally-wrap the target ERC-20

2. Third Party
   → Nascent solution space for cross-rollup limit orders
   → There are open designs around using intents to facilitate this

As this is the default case, it is unnecessary 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 can theoretically be achieved without one manually if the sequencers on two given rollups are not at max throughput (one could simply submit two transactions to each rollup individually). This is why we have added an asterisk to the required infrastructure.

However, we do not assume that the shared sequencer is running a full node of each of the connected rollups and so cannot guarantee successful execution for a bundle of transactions. The shared sequencer in this case can only guarantee that transactions are well-formed and that they will be included in the next block, but not necessarily that they will successfully execute.

Because there are no execution guarantees, it is impossible to programmatically take advantage of atomic inclusion in any meaningful way without incurring the risk of one of the transactions reverting. As a result, we are essentially in the exact same case as L1 Async interoperability.

Consider initiating 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 destination rollup

We may have atomic inclusion guarantees in that both transactions are in fact included in the next blocks for each rollup, but if the first transaction reverts and the second does not, the user would be incorrectly allocated funds on the destination chain without having locked or burned them on the source chain and we’d encounter a double spending problem.

Any interoperability solution, whether it be a liquidity bridge, intent framework, or xERC-20 swap, would be vulnerable to this risk and it’s impossible to mitigate it. Because of this risk, current solutions require the initiating transaction to have been successfully executed and included in a block on the source chain before using relayers to pass an emitted message and execute the second transaction on the destination chain.

Important Takeaway: Atomic Inclusion does not meaningfully impact interoperability potential

3. Shared Settlement

Required Infrastructure:

Proof aggregation layer // Shared bridge contract

This is where things begin to get more interesting. As a result of the shared bridge contract, all liquidity deposited into the rollup ecosystem from the L1 can be moved freely between all connected rollups. Until this point, we could not perform swaps between rollups without passing through canonical channels, externally wrapping assets, or using a third party solution.

Why build a shared bridge contract? To understand why having a shared bridge contract allows us to trustlessly move assets across rollups, first consider what would happen if it was possible to have Eth in Rollup A, burn it, and mint it natively on Rollup B without a shared bridge contract on L1.

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

To solve this, external asset wrapping protocols are built that issue an externally-wrapped version of tokens across rollups that symbolize a native version somewhere else in the network.

With a shared settlement layer, the situation looks different. Because all liquidity for each connected rollup is locked in the same bridge contract, one can move freely between rollups, as the total amount of value in the bridge contract stays the same and can always be withdrawn.

There does need to be an update at the L1 contract level about *where *the liquidity is to allow users to withdraw from anywhere, but this is trivial because all connected rollups can read/write to the shared contract.

With a shared settlement layer, the flow may look like the following for a simple send-to-self case.

Send-to-Self:

1. User creates the initial transaction:
   → Tx 1: withdraw Eth on rollup A (with message to mint it on rollup B)
   → Transaction is batched and submitted to the L1 contract
   → It is aggregated into transaction root which groups all shared settlement rollups

2. Rollup B imports this tx root

3. Relayer submits transaction to mint along with Merkle Proof to rollup B

4. Rollup B verifies the burn transaction using Merkle Proof and transaction root

5. User is minted Eth on Rollup B

6. Rollup B submits proof to L1

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

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

This gets us closer to composability, but because of the necessary steps of aggregating proofs and relaying messages only after the state changes are reflected on L1, there are high latencies (though notably lower than the L1 async case). Additionally, any complex cross-rollup activity like using a DEX on rollup B starting with assets on rollup A for a cross-rollup limit order would still be a tedious process for the user as they would still have to send-to-self and manually swap assets on the destination rollup. One can not create atomic cross-rollup bundles in this case.

Another important benefit with shared settlement is that there is less friction for liquidity providers or solvers that are filling orders in multiple environments. Because their liquidity across all connected rollups is reflected in the same bridge contract, they do not have to wait for the full withdrawal window to manage their cross-rollup liquidity.

Implications on Stakeholders:

1. Users:
   Can now transfer assets in a native form without L1 withdrawal period

2. Developers:
   Changes are limited to token issuers who can now use in-protocol messaging to issue native versions of ERC-20s across all connected rollups

3. MEV Searchers:
   Because this happens over multiple blocks for each rollup, there is no new MEV potential

4. Rollups:
   Rollups will have to opt-in to using a shared bridge contract and likely add pre-compiles to handle cross-rollup messages

Important Takeaway: Shared settlement allows for non-externally-wrapped asset transfers and arbitrary messaging across all rollups sharing the bridge contract and proof aggregation layer, but there will still be non-negligible latencies (though far shorter than L1 Async) and one cannot create cross-rollup atomic bundles.

4. Atomic Execution

Required Infrastructure:

Shared Sequencers // Superbuilders

Atomic execution allows us to guarantee the successful execution of cross-rollup bundles, but as we will see, the number of use cases for cross-rollup bundles that do not have dependent transactions is smaller than one might initially expect.

If any single transaction in a bundle of dependent transactions reverts, then all other transactions become invalid and must also revert, as is the case with burning and minting tokens across rollups. Minting tokens on a destination rollup is dependent on them having been burned or locked on the source rollup, so we would say that a bundle of burn and mint transactions is a bundle of dependent transactions.

Creating this bundle is impossible without a middle party such as a superbuilder that can create the destination transaction.

Consider what would have to be true for cross-rollup swap bundles to be built without another party beyond the user. A bundle would have to be created to lock/burn the asset on the source rollup and mint the asset on the destination rollup, but we run into issues:

1. Contracts on the source rollup can only emit a message when locking/burning the original source asset, they cannot call and create a transaction on the destination rollup.
   → This is why message protocols and relay networks exist.
   → The message can be used to structure what the call on the destination should be, but it can not actually create the transaction itself.

2. Creating the second transaction on the destination rollup to mint:
   → The user themselves cannot create this tx because they don’t have minting rights for the token on rollup B
   → I.e.) The destination chain needs a proof that tokens have been burned/locked on the source chain, but this proof is not available until after the initial transaction has been executed which would break our requirement for atomicity.
   → Any other party that could create the second transaction with minting rights theoretically could create a “mint” transaction on the destination chain at any point without having first created a “burn” or lock on the source, which is a massive vulnerability.

We can see that even though we could guarantee execution of cross-rollup bundles, we run into difficulty in how we could build them in the first place to transfer assets of value.

However, there are still a few use cases for atomic execution without dependent cross-rollup bundles. One of which is cross-rollup arbitrage:

Because there are no strict dependencies between these transactions, anyone can create this atomic bundle and submit it to a shared sequencer that will guarantee atomic execution.

However, to have atomic execution guarantees in the first place, rollups must opt into a shared sequencer and superbuilder that would run full nodes of all connected rollups, so the step from atomic execution to block-level composability is quite small and all shared sequencing solutions will do this. The only change required is that the block builder or another third party must be able to create transactions on behalf of the user to complete dependent cross-rollup bundles.

It is unlikely that infrastructure will be built that only allows atomic execution without going a step further to have composability. The relative gain of jumping to full block-level composability far outweighs the difficulty in achieving it given the infrastructure already having atomic execution.

Implications for Stakeholders:

1. Users:
   Likely no change, although it’s possible that third party facilitate solutions like intents could be atomic, but specifically how is not clear

2. Developers:
   Likely no change

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

4. Rollups:
   Rollups must opt-in to using a shared sequencer/superbuilders submitting blocks with transactions from each rollup wishing to interoperate, which may change the rollup revenue structure. It is not yet clear how it will change.
   - Sequencing marketplaces may increase revenue to rollups by allowing ToB space to bought by sophisticated builders

Important Takeaway: While cross-rollup bundles are guaranteed to execute atomically, it is not clear how these bundles will be built if there is no superbuilder that creates part of the bundle, so it is unlikely that atomic execution on its own will impact interoperability. Shared sequencers/superbuilders should by default build instead for block-level composability.

5. Block-Level Composability

Required Infrastructure:

Shared Sequencer // Superbuilder // Proof aggregation layer* // Shared bridge contract*

(* = optional)

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

We have modified this term slightly to be more descriptive. Updating the nomenclature to Block-Level Composability implies that it is possible to compose between two rollups in a bundle of cross-rollup transactions that will be included and executed successfully in the next block. Synchronous composability might get confused with transaction-level composability, which we explore in the next section. Importantly, this requires a middle party (the shared sequencing infrastructure) that can be the conductor and creator of dependent transaction bundles.

At this level, we begin to see true composability between rollups beyond simply sending to self to participate in a dapp on another rollup.

With the addition of a shared sequencer that can create transactions, we are now able to make cross-rollup bundles that developers can take advantage of programmatically.

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 activity but in the second case with shared settlement we can use native assets, which could have better price implications for cross-rollup DEX activity, for example.

With block-level composability, we have both the advantages of atomic execution with the added ability to create dependent transaction bundles. Let’s examine our two illustrative examples.

Same Token Transfer via xERC-20 (No Shared Settlement):

1. User has ERC-20

2. User creates tx via dapp:
   → Deposit ERC-20 into xERC-20 lockbox to receive xERC-20 wrapped version
   → Burn xERC-20
   → Emit a message signifying to the shared sequencing infra that a cross-rollup transfer has been initiated along with relevant data to facilitate the swap

3. Superbuilder picks up transaction and creates a cross-rollup bundle
   → Tx 1: The aforementioned wrap and burn transaction
   → Tx 2: Mint xERC-20 on rollup B

4. Superbuilder submits this cross-rollup to the shared sequencer
   → Because the superbuilder is running a full node of the two connected rollups, they simulate the transactions to guarantee successful execution of the bundle. If either transaction would revert, the whole bundle is reverted.

5. Shared sequencer submits the block containing both transactions to the DA layer as well as to the nodes that execute the state change

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

With a shared settlement layer, the flow is even further simplified because there would be no need to first wrap the ERC-20 as an xERC-20 to swap.

Let’s now examine the cross-rollup limit order to buy an ERC-20 on Rollup B with an initial (different) ERC-20 from Rollup A and have the resulting ERC-20 sent back to Rollup A. In this case, we do not assume that we have a shared settlement layer, although a similar flow exists in the case with one. The only difference is not additionally having to externally-wrap assets.

Here are the required transactions in this case:

1. Wrap and Burn ERC-20 on A

2. Mint xERC-20 on B

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

4. Wrap and Burn target ERC-20 on B

5. Mint xERC-20 on A

Here is a potential flow for how this could work:

Flow:

1. User initiates the first transaction:
   → Wrap and Burn xERC-20 with message emitted to specify swap parameters (destination chain, DEX address, ERC-20 to swap with, limit order price, boolean to send back or not)

2. Superbuilder sees transaction and creates bundle:
   → Tx 1: User create tx described above
   → Tx 2: Mint xERC-20 on destination (superbuilder must have minting privileges)
   → Tx 3: Limit order using data from tx 1
   → Tx 4: Wrap and Burn ERC-20 on B assuming full fulfillment on limit order with message to mint on source chain
   → Tx 5: Mint target xERC-20 from output of the swap on source chain

Because the superbuilder creates the block and orders transactions, it can simulate each transaction and omit the bundle if any of the transactions would revert. For instance, if it is found that the user would not receive complete fulfillment on their limit order, the bundle would be omitted before the block is executed.

In this case of shared sequencing infrastructure without a shared settlement layer, an externally wrapped version of Eth and xERC-20 would need to be used, which could result in worse market conditions on the DEX due to thinner liquidity pools for wrapped assets. In this case, a user may have to use a softer limit with more tolerated slippage and could receive suboptimal prices. One exception to this is if USDC is involved. It is possible that a shared sequencer without shared settlement could work with Circle to gain exclusive rights on the USDC contracts across rollups to facilitate native USDC transfers and swaps cross-rollup.

With a shared settlement layer, this external wrapping is not necessary, and would likely provide better prices due to deeper liquidity pools for native asset swaps, but the flow is essentially the same.

Optimistically Trusting Sequencer

Rollups would need to optimistically trust the shared sequencer/superbuilder to create valid cross-rollup bundles. This is primarily due to the fact that this cross-rollup bundle contains dependent transactions that individual rollups cannot verify until after the block is added to each rollup’s chain and aggregated to a settlement layer on L1. An example is the initial burn and mint of Eth from source to destination. It is crucial that Eth is actually burned on the source chain before being minted on the destination chain, or else double spends are possible.

However, to have this full bundle executed in one block, all transactions must be present in that block even if the transaction represents a state that is invalid before the block itself (such as having Eth on the destination chain for the swap if the user does not have any before the block). For that reason, we must trust the sequencer that it has actually included the valid dependencies in the cross-rollup bundle. One could submit proofs after the fact to prove the validity of each transaction.

This is slightly less important when using wrapped assets, however, because they have no impact on the native liquidity stored in the L1, but fallback mechanisms must still be in place to counteract the risk of a malicious sequencer or a bug in the code that allowed a transaction bundle to be executed with a dependent transaction that was reverted.

Implications for Stakeholders:

1. Users
   Massive upgrades to UX in allowing cross-rollup limit orders in a single block

2. Developers
   Would need to be cross-rollup aware for cross-rollup activity, likely taking advantage of custom precompiles. Instead of just transactions, devs have to think in terms of bundles, but it’s likely that superbuilders and custom rollup infrastructure could abstract away most developer complexity.

3. MEV Searchers
   MEV searchers have essentially equivalent opportunity to use L1 strategies on cross-rollup bundles, but it depends on how PBS (Proposer-Builder Separation) is implemented.
   → Cross-rollup bundles are essentially viewed as a single transaction, so MEV could be found by front-running or sandwiching these bundles as long as they don’t move prices outside of tolerated slippage amounts (because then the whole bundle would revert and MEV attempts would fail)

4. Rollups
   Would need to opt in to shared sequencing infrastructure (including superbuilders) as well as allow access to burning/minting of Eth to shared sequencer in the case of a shared settlement layer.
   → Could internalize MEV by selling blockspace to builders

6. Transaction-Level Composability

Required Infrastructure:

VM-Level Changes // Shared Settlement // Superbuilders

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

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

Although there is limited new functionality unlocked with transaction-level composability beyond flash loans, the developer experience for creating cross-rollup applications can be greatly improved. The ability to create dapps that interact with all connected chains without reasoning about cross-rollup bundles will make it far easier to innovate in a multi-rollup landscape. Furthermore, it’s possible that new use cases and behaviors will emerge as a result.

There are many open design questions for transaction-level composability. For one, how devs can opt into or out of cross-rollup calls for their smart contracts needs to be carefully considered. Allowing arbitrary composability without restriction means that we regress to one monolithic rollup. We think the answer here is for devs to explicitly indicate where cross-rollup composability is necessary in their contracts, for example via a Solidity modifier like `composable` which marks certain entry points of the contract as callable cross rollup.

Implications for Stakeholders

1. Users:
   Same implications as block-level composability with additional advanced capabilities like flashloans
   → UX is virtually identical to using one chain for dapps that opt-in

2. Devs:
   Developer experience massively improves as dapp devs can natively call contracts cross-rollup and use outputs from these calls like single rollup calls
   → Superbuilder/Sequencer infra will still have to place the transaction in blocks for the rollups that the cross-rollup call affects, but will not have to build the same bundles as in the case of block-level composability.

3. MEV Searchers:
   High MEV potential as cross-rollup bundles are now essentially equivalent to single transactions on one chain

4. Rollups:
   Would require VM level changes, as well as opting into a shared sequencer and shared settlement layer
   → Additional trust assumptions involved in having to trust the inputs and outputs for other rollups before being able to verify state via proofs, but slashing mechanisms could reduce the burden of trust

Summary and Ecosystem Map

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

1. Shared Settlement allows for cross-rollup swaps without externally wrapping assets and creates in-protocol messaging pathways between all connected rollups

2. Shared Sequencing/Superbuilders allow for next block execution guarantees on cross-rollup bundles

3. Block-Level Composability allows for complex, fast, dependent cross-rollup bundles to be created, achieving a near smart contract to smart contract level composable ecosystem.
   → With the addition of shared settlement, these cross-rollup bundles can be created without using externally wrapped assets

4. Transaction-Level Composability is possible, and while the new use cases opened up might be for more sophisticated users, it has the potential to massively upgrade the cross-rollup development experience.

At present moment, there are many projects emerging to create these natively interoperable ecosystems. Here is a high-level overview of the landscape:

Ecosystem Map

Closing thoughts

There are still open questions about the technical nuances within the frameworks laid out in this article. For example, building bundles in a block-level composable ecosystem for cross-rollup limit orders may have more detailed designs to handle the case of partial fulfillment and slippage tolerance for market orders. We offered one potential solution here to revert a cross-rollup limit order bundle if the order is not completely filled, but the design space is open.

Additionally, it is worth relating this to the current mindshare growing in the space about appchains. Appchains are long-tail L2s that are either generalized or permissioned with the goal of siloing specific related protocols on one L2. It is likely that when we reach block-level composability we will also begin to see appchain environments gaining significant traction as a result of having native composability between all connected networks.

At present moment, it is still difficult to bootstrap liquidity to these appchains, but once a larger chain connects as an onramp to the interoperable environment, it’s likely that we’ll see walled garden ecosystems around shared infrastructure.

Another important open question is how the design space around superbuilders will settle. Development on this front is still quite nascent, and it’s not yet clear what will be the most efficient and effective way to create a network of sophisticated builders that can create cross-rollup bundles. Where these cross-rollup bundles will optimally be included in a block, and the impact on rollup revenue is an open question with different strategies being explored by many teams.

Ultimately, the future will likely involve a combination of in-protocol and out-of-protocol bridging solutions and they will work in tandem to provide a far better interoperability process for everyone. We believe the progression defined in this article can serve as a guide for developers and builders alike who are focused on making cross-rollup interoperability more seamless for end-users.

It’s also likely that there will be completely new paradigms for cross-rollup interaction that have yet to be discovered. If you’re a builder working on approaches that expand on the topics here or are not covered above, please reach out (dms are open). The technology has finally matured enough to put real pressure on finding solutions for liquidity/ecosystem fragmentation, and we are always looking to connect with founders that are taking risks to build creative solutions.

Acknowledgments

This article grew out of an incredibly insightful rollup interoperability roundtable discussion held by 1kx at EthCC. Special thanks goes to Noah Pravecek, Ellie Davidson, and Terry for reading early versions of this article and providing feedback, as well as to Marti, mteam, and Bo Du for further conversations on the subject.

— — — — — — — — — — — — — — — — — — — -

Disclaimer: This article is for general information purposes only and should not be construed as or relied upon in any manner as investment, financial, legal, regulatory, tax, accounting, or similar advice. Under no circumstances should any material at the site be used or be construed as an offer soliciting the purchase or sale of any security, future, or other financial product or instrument. Views expressed in posts are those of the individual 1kx personnel quoted therein and are not the views of 1kx and are subject to change. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell or a solicitation of an offer to buy any securities, and may not be used or relied upon in evaluating the merits of any investment. All information contained herein should be independently verified and confirmed. 1kx does not accept any liability for any loss or damage whatsoever caused in reliance upon such information. Certain information has been obtained from third-party sources. While taken from sources believed to be reliable, 1kx has not independently verified such information and makes no representations about the enduring accuracy or completeness of any information provided or its appropriateness for a given situation. 1kx may hold positions in certain projects or assets discussed in this article.