Summary

In this article, I give an overview of the Mantis rollup and its subcomponents. First, I present an overview of the rollup design and the transaction flow along it. Then, I introduce the core components of the rollup: the bridge contract, interoperability, finality, and security from the L1.

Keep an eye out for upcoming forum posts with more detail on each of these rollup components.

Design Overview

Previously, rollups have been limited to the optimistic or ZK rollups in the Ethereum ecosystem. Thus, Composable created its own rollup design on Solana: the Mantis rollup, the first Solana Virtual Machine (SVM) rollup.

The Mantis rollup’s core role is to be a coordination and settlement layer for cross-domain, intent-based mechanisms. The Mantis rollup also provides a framework for block proposals and credible commitments across domains. These commitments are held accountable through IBC’s security model, ensuring transparency and trust in multi-chain interactions.

All major components of the Mantis rollup are depicted in the following diagram and described in subsequent sections of the article:

Transaction Flow

Transactions settle down from layer 2 (the Mantis rollup) to layer 1 (the destination chain of the transaction). First, transactions on the Mantis rollup are used to construct blocks by the Mantis rollup validators. In this way, validators of the rollup also act as block builders. Then, the blocks of Mantis rollup transactions are picked up by the sequencer on Mantis. They send blocks to the bridge contract. When there are transactions submitted through the L1, the bridge contract sends the blocks out using a light client that we have created between L1 and L2 In this case, the layer 1 validates the layer 2 blocks. This is also a change in the consensus algorithm that ensures finality of the L2. This is a change to the validator client we’ve made.

This transaction lifecycle is depicted in the following diagram:

Rollup Components

Bridge Contract:

The bridge contract interacts with the rollup to facilitate bridging. Any asset can be deposited into the bridge contract to be staked in proof-of-stake validation, providing the users with staking rewards. However, users depositing SOL, liquid staked tokens (LSTs) from SOL, or Solana-based stablecoins into this bridge contract are able to earn additional yield in the form of restaking, DeFi integrations, and native yield. The types of yield that each asset can generate on the bridge contract are displayed below:

Interoperability

The IBC is used to settle transactions down from the L2 (i.e. the Mantis rollup) to the respective L1 (i.e. the destination chain, which can be any IBC-enabled chain). This is accomplished via the Picasso Network’s expansion of the IBC’s connections to not only the Cosmos Hub and Cosmos SDK chains that it originally linked, but also Polkadot and Kusama parachains, Ethereum, and Solana.

This interoperability is natively integrated into Mantis, as we’ve created state proofs on the Mantis rollup in the SVM. These state proofs will be generated in the validator client of the Mantis rollup. This is a change to the validator client we implemented.

However, not all blockchains (such as Solana) meet IBC requirements. Thus, we have had to develop other mechanisms to allow IBC connectivity on these chains. For example, we have developed a guest blockchain that essentially replicates the underlying chain, but is compatible with state proofs. Moreover, we have created an alternative proof that should meet the state proof requirements of the IBC. This is explored in more detail in this forum post by Michał Nazarewicz.

Security from the L1

In the Ethereum context, there are two requirements for being a rollup:

1. Rollback based on the L1: Rollup blocks are validated by the corresponding L1. If the L1 says the transaction is invalid (i.e. the L1 does not accept the transaction), the rollup rolls it back.

2. Emergency withdrawals from L1 using the L2: The state root can be used to make an emergency withdrawal from the layer 2 in the event the L2 stops running.

The Mantis rollup fits these requirements, as we will describe in a future forum post.

Finality

As Mantis leverages the IBC, finality comes in the form of light client updates. This involves L2 blocks being posted on the L1 and verified by the light client. This also includes posting state proofs to the L1.