Composability in a rollup ecosystem

One of the most common criticisms of rollups is that they “break composability”. This has been a major argument from most monolithic chain maximalists. However, ‘one chain to rule them all’ is an impossibility. A multi-chain ecosystem is the only path forward. With that in mind, what are the implications of composability in a primarily rollup-based ecosystem?

While the concept of composability may seem straightforward, more nuance is required to explore it in a multi-chain setting.

Composability: The ability of a smart contract to read and write to the state of another smart contract.

Simply, applications are composable when they can interact with other applications. For example, an application that automates Uniswap v3 liquidity positions can compose with Uniswap because it can read current data of the Uniswap liquidity pools and execute the addition or removal of liquidity positions for its users. If Uniswap and the liquidity app live on the same chain, they can compose synchronously.

Synchronous composability: Composability between smart contracts where interactions occur within a known and finite amount of time.

Synchronous composability is simply interactions between applications that occur within the timespan of a single block. For example, a flash loan requires that the borrower borrows and repays the loan in a single transaction. Since a single transaction can’t span multiple blocks, it must occur within a single block. Generally, applications that compose with each other on the same chain do so synchronously. All DeFi apps on Ethereum compose with each other synchronously. However, synchronous composability is not the only type of composability.

Asynchronous composability: Composability between smart contracts where interactions occur within an unknown and unbound amount of time.

Unlike synchronous composability, where interactions between applications must occur within a block, asynchronous composability enables interactions to occur between applications across multiple blocks. While asynchronous interactions can take infinite time, practically nobody wants to wait forever. Timeouts can mitigate this by stopping an interaction after a predetermined amount of time. Importantly, asynchronous composability enables applications on different chains to interact with each other. But how do applications compose if they are on different chains?


Passing data between different blockchains requires a bridge. While many bridges exist solely to bridge tokens between chains, the beauty of asynchronous composability enables users to interact with an application on a different chain without any token bridging. For example, let’s assume Uniswap v3 and the liquidity app from our first example live on different chains. When a user makes a transaction on Chain A with the liquidity app, it will interact with a bridge linked to Chain B. The liquidity app will specify to the bridge what application it wants to interact with on Chain B and what type of interaction it wants to make. In this case we’ll say it creates a liquidity position on Uniswap. The bridge then relays data to Chain B to create the liquidity position on Uniswap, and returns the result to Chain A, including an LP NFT from Uniswap.

For the bridge to enable asynchronous composability, it needs general data passing capabilities. General data encompasses any arbitrary type of data that a blockchain could relay, like application state, validity proofs or block headers.


Applications that live on the same rollup can compose synchronously with each other. However, applications on different rollups require a bridge to compose asynchronously, which is the same requirement for applications on different monolithic chains. Since it is impossible to scale all web3 activity with a single blockchain, a multi-chain ecosystem with asynchronous composability is the only solution. The argument that rollups "break" composability is short sighted because:

  1. Applications can’t inherently all live on a single blockchain. So, they must split across multiple chains.
  2. Applications can compose despite living on different chains.

Consequently, a multi-chain ecosystem comes with its own fundamental set of problems.

  1. Each blockchain needs to bootstrap its own secure validator set.
  2. Blockchains require secure bridging.

Aside from the scalability properties rollups can possess, they also solve both fundamental problems. Rollups don’t need their own validators, only a set of sequencers to produce blocks. The base layer provides the secure validator set. Rollups that share a settlement layer can build trust-minimized bridges between them because their state transitions can be easily verified through the settlement layer.

Finally, asynchronous composability partially alleviates the other fundamental problem of a multi-chain ecosystem, fragmentation, because applications can access liquidity from different chains. For example, DEXs that aggregate and route trades across multiple chains would decrease price impact for larger trades due to the increased access to liquidity – even better for stablecoins and staking derivatives.