[Case Study] Interoperability For the Modular Rollup Stack, Featuring Nautilus

Recently, we announced Hyperlane as the interoperability provider for Nautilus, enabling interchain token transfers and interchain composability. What does this mean? How does Nautilus work? What was the thought process behind it? How do modular rollups and Hyperlane fit together?

A case study of Nautilus Chain, one of the first implementations of the modular rollup stack and Hyperlane’s modular rollup interoperability:

The TLDR

• Nautilus is built using the Eclipse modular rollup stack, which includes Hyperlane interoperability.
• Nautilus Bridge is the first production version of Warp Routes on mainnet, showcasing the utility of self-deployable token bridges.
• Hyperlane now live on Solana mainnet (more implementation info coming to docs soon!)
• First look at Relayers-as-a-Service, where Abacus Works, the core developer team behind Hyperlane, runs Hyperlane infrastructure for you as a service to facilitate easier Permissionless Deployments.

The Problems Nautilus Faced

For context, Nautilus was incubated by Zebec, a token streaming platform with features such as payroll, vesting, multisig, and payments.

To start, they had some key needs:

1. They wanted a dedicated chain for their platform that could handle the high TPS demand of their token streaming features and an ecosystem of apps built around it.
2. They wanted to use their existing ZBC token as the gas token for Nautilus. However, ZBC was already on Solana and Binance Smart Chain. It needed to be bridged quickly to Nautilus at launch.
3. They wanted all of these features fast, and preferably out-of-the-box.

So how did it work in the end?

The Modular Rollup Stack

Nautilus ended up enlisting Eclipse to help them build their desired blockchain. Eclipse is a customizable rollup provider for developers building decentralized applications.

With this integration, they fulfill need #1 and need #3 thanks to a modular approach to blockchain design. By separating the different layers of the blockchain stack, Nautilus is able to cheaply scale TPS while maintaining flexibility on the VM and forkability, plus save time on development. They use:

• Solana-based rollup for settlement
• Neon EVM for execution
• Celestia to be used for data availability once live

Which is all to say that Nautilus is an EVM rollup with Solana-level TPS and optionality to upgrade to more future proof designs over time thanks to the plug-and-play modular design.

Why Hyperlane was the Solution

Permissionless Interoperability

As part of the Eclipse stack, Hyperlane interoperability was available out-of-the-box for Nautilus. Importantly, Nautilus didn’t need to lobby any permissioned interop provider for the chain connection. They were able to self-deploy Hyperlane and have interoperability + interchain token transfers ready on short notice (about a week). In the near future, we envision Hyperlane interop being built into the rollup stack for even easier/faster deployment.

Hyperlane on Solana

To accommodate the ZBC tokens on Solana (Hyperlane is already on BSC), we developed and added a Hyperlane deployment on Solana mainnet. Solana support has been in the works for a few months now, so we’re excited to finally ship it to mainnet and achieve interoperability with another major ecosystem. Looking forward, Hyperlane is now optimized to be permissionlessly deployed to any Solana-VM rollup, especially future Eclipse rollups.

Onboarding with Warp Routes

To onboard ZBC from Solana and BSC, Nautilus deployed Warp Routes for permissionless interchain token transfers. The Nautilus team was able to have their Warp Routes production ready within a week, showcasing the simplicity and speed of using Hyperlane for interop and token transfers.

This marks the first-ever production version of Warp Routes on Mainnet, another important milestone for Hyperlane.

Relayers-as-a-Service

As part of a new white glove service, Abacus Works, the core developer team behind Hyperlane, is operating the Hyperlane relayers for the Nautilus deployment.

For teams that want a quick Hyperlane deployment but don’t want the overhead and learning curve of running Hyperlane infrastructure, Abacus now offers relayers-as-a-service to facilitate the process.

Nautilus x Hyperlane Use Cases

• Interchain Apps. Nautilus apps can now use Hyperlane APIs to compose with apps on other chains, accessing external liquidity and simplifying the user experience.
• Nautilus users can bridge in other tokens like stablecoins (in addition to ZBC) with Warp Routes.
• Warp Route assets can/will be used in DeFi protocols like PoseiSwap.
• Interchain payment streaming/collateral with Zebec
• Bring tokenized Real World Assets (RWAs) from other chains to Nautilus and vice versa.

Interested in any of the mentioned Hyperlane features? Try out the Nautilus Bridge, access interoperability by permissionlessly deploying Hyperlane on your chain, or start transferring any tokens between any chain with a Warp Route deployment.

More about Hyperlane

Hyperlane is the first Permissionless Interoperability layer, enabling anyone to connect any blockchain, out-of-the-box. With Hyperlane, developers can build Interchain Applications, apps that abstract away the complexity of interchain interactions and serve users on any connected chain. Additionally, Hyperlane’s modular security stack gives developers the power to customize their interchain security. Hyperlane development is open-source and led by core developers at Abacus Works.

Go Interchain with Hyperlane

Start building with our Docs.
Experiment with Hyperlane in 5 minutes with our Quickstarts.
Join our Discord if you have any questions.
Apply to join our crew Here.
Find us on Twitter.