Router Nitro’s Architecture

Bridges, the iconic structures that span rivers, valleys, and chasms, have played a pivotal role in human history, connecting communities and facilitating trade and travel for centuries. These magnificent feats have not only withstood the test of time but have also evolved with technological advancements.

In our earlier blog, we went through the world of bridges, their technology, design, and innovation and also discussed the four important pillars — Capital Efficiency, Security, Latency, and Cost! We also discussed how the existing bridge solutions fail to achieve these critical benchmarks. However, on a promising note, we concluded by shedding light on the Router’s Asset Swapping Engine and its potential impact on the bridge landscape.

On that note, let’s begin-

Before we do that, we’re calling our bridge “Router Nitro”.

Router Nitro is a bridge built using our cross-chain primitive “Reverse Verification” flow, which enables high-speed and low-cost transfers.

The reverse verification flow is created using the application-specific bridging construct enabled by our chain. This primitive can be used by other applications to make them more efficient in the future.

Moreover, Router Nitro enables the flow of arbitrary instructions along with asset transfers, thus expanding the realm of composability within the DeFi ecosystem across diverse blockchain networks.

Picture a scenario where you need to transfer funds from Bank A to Bank B. In this process, Router Nitro acts as an intermediary, collecting the money from Bank A, and then its partners, referred to as forwarders, personally convey the funds to Bank B.

Following the transfer, Router Nitro undertakes a crucial verification step to ensure that the amount you originally deposited in Bank A matches the amount that arrives at Bank B. If the verification is successful, Router Nitro’s partners retrieve the funds they initially transferred to your Bank B, effectively completing the transaction.

Router Nitro has three flows with which it enables this swapping -

Forwarder Flow — It uses a trustless optimistic approach to handle cross-chain asset transfers and has an entity called the forwarder that provides the users with their desired assets on the destination chain.
Burn and Mint flow — For certain tokens, the bridge has mint/burn rights, which allows the bridge to burn the tokens on one chain and mint them on another.
USDC circle flow — This flow uses Circle’s CCTP infra to provide cross-chain transfers of USDC. The flow works for USDC transfers on chains where CCTP is live.

In this blog, we will be covering the Forwarder flow, and before we do that, here are some terms and their explanations for you to understand the flow in a better way

Orchestrators: It ensures that all the validators and relayers are playing in sync and that the information being passed between them is accurate and legitimate.
Middleware contract: It is a contract which is deployed on the Router chain, which enables custom business logic directly in the bridging layer.
IBC: Inter-Blockchain Communication Protocol is an open-source protocol to handle authentication and transport of data between blockchains (within the Cosmos ecosystem.
Gateway contracts: Gateway contracts serve as the interface for the application contracts on any chain to interact with contracts on other chains.

This is how the entire flow of bridging using forwarders looks-

In the forwarder flow, first of all, a user invokes the Nitro contract to transfer funds from Chain A (source) to Chain B (destination). The source chain Nitro contract will validate the request, deduct funds from the user’s account, increment event nonce and emit a FundsDeposited event.

Whenever a FundsDeposited event is emitted from a Nitro contract, Orchestrators listen to this event and submit the event to the Router chain along with their attestation. Parallely, the forwarders also listen to the FundsDeposited event.

After 2/3+1 validation, the Router chain will invoke the middleware Nitro contract with the event info, and after this, the middleware contract will persist with the request!

While the event was being processed on the Router chain (attestation, validator, submission on the middleware contract), in parallel, the forwarder also listens to the FundsDeposited event and invokes the Nitro contract on the destination chain.

Upon receiving the transaction, the Nitro contract on the destination chain will (a) transfer the defined amount from the forwarder address to the receiver address, (b) create a hash of the fields included in the request and persist it in the status map (to skip the replays), and © emit a FundsPaid event confirming the execution.

Orchestrators on the Router chain listen to the FundsPaid event from the destination chain Nitro contract and submit it to the Router chain with their attestation. Upon receiving the FundsPaid event, the middleware contract verifies that the message generated from the request data is the same as the message hash from the executed event, marks the request as Completed and persists the forwarder address and amount.

After the request is marked as completed, the forwarder can claim its funds by triggering an outbound request on the Router chain. This request undergoes processing through both the Router chain and the existing Gateway contracts. Subsequently, the Gateway contract will engage with the Nitro contract on the source chain, ensuring the settlement of funds for the forwarder.

So, just like that, Router Nitro bridges your assets from Chain A to Chain B efficiently, securely, and with minimal cost using the reverse verification flow!

Managing L1 and L2 Dynamics in Cross-Chain Transfers

When there are L1 chains on both ends, a similar process unfolds, with assets and instructions making their way across the bridge. However, when we shift our focus to transactions originating from an L2, a distinct challenge emerges. This challenge is the potential for a “rollback” during the fraud-proof window, a phenomenon that can disrupt the typical flow of things. Let’s understand how -

The Rollback Challenge

In an L2 ecosystem, a transaction is considered optimistically valid, and there’s typically a designated window of time within which verifiers can submit a fraudulent rollup transaction, often spanning several days. Now, consider a situation where a verifier, two days after the fact, reports an alleged invalid state transition (transaction), calling for a complete reversal, aka rollback of the entire batch of transactions.

Suppose this report is substantiated and a discrepancy between the state root on the L1 and the actual state of the rollup chain is identified. In that case, transactions executed during the past two days are deemed illicit.

Consequently, the rollup chain initiates a rollback, reverting to the last state root proposed by the sequencer, essentially nullifying all transactions within that time frame.

However, this creates a predicament for the bridge as users on the destination chain have already received assets based on the assumption that the transactions were valid. Due to the rollback, these transactions are invalidated, necessitating a return of assets by the source chain to the users.

This basically means that forwarders will not be able to claim the assets that they’ve already given on the destination chain as the source chain has returned the assets locked on the bridge contract back to users (because of the rollback).

This situation presents a significant challenge for the bridge that connects the source and destination chains, resulting in financial losses because assets have already moved on both sides and now reconciliation becomes imperative.

How do we address this challenge?

To address this challenge, forwarders can take a proactive approach. They can perform a quick status check of the chain (if the chain is in the correct state) before taking up a transaction event to handle.

The way to check the chain’s status is to get the transaction data, recreate the state root of the chain and then compare it with the existing root on the chain. After comparison, if both the roots align, then the forwarders can proceed with the transaction execution on the destination side.

This step is essential in maintaining the integrity and reliability of cross-chain transfers. In the coming future, Nitro will provide certain modules to enable this check.

Managing EVM and Cosmos Dynamics in Cross-Chain Transfers

Firstly, when we go from an EVM chain to a Cosmos chain, the flow pretty much remains the same; however, as there is Cosmos on the destination side, the orchestrators are replaced by IBC relayers!

The process begins with the user depositing funds into the EVM chain’s Nitro contract, which triggers a FundsDeposited event. Upon listening to this event, forwarders call the contract on the destination (Cosmos) chain to allow the transfer of tokens from his wallet to the user’s wallet. Simultaneously, orchestrators listen to this event and submit the event to the Router chain along with their attestation.

After 2/3+1 validation, the Router chain will invoke the middleware Nitro contract with

the event info, and after this, the middleware contract will persist with the request!

The contract on the Cosmos chain transfers the funds to the user from the forwarder’s account. Once the transfer is successful, the FundsPaid IBC message from the Cosmos chain is received by the Nitro middleware contract on the Router chain and the reverse verification is initiated. Post successful verification, the forwarder can initiate the withdrawal of the funds.

In another case, when we go from one Cosmos chain to another, a user deposits funds on the Nitro contract on Cosmos Chain A, and the Nitro contract on Cosmos Chain A triggers the FundsDeposited event. Here, we should remember orchestrators are not required as we have Cosmos chains on both ends!

Then, the Nitro contract on Cosmos chain A initiates a cross-chain request by sending a FundsDeposited IBC message to the Nitro middleware contract on the Router Chain.

A forwarder picks the deposit from the Nitro contract on Cosmos Chain A and transfers the funds to Cosmos Chain B from their account. After a successful transfer, Cosmos Chain B sends a FundsPaid IBC message to the Nitro Middleware Contract on the Router Chain.

The Nitro middleware contract on the Router Chain listens to both the FundsPaid IBC message from Cosmos Chain B and the FundsDeposited message from Cosmos Chain A. It then performs a reverse verification to ensure accuracy.

The forwarder can then initiate withdrawal from the Nitro middleware contract on the Router Chain. To enable this, the Nitro middleware contract on the Router chain triggers an IBC Crosschain Outbound Request to the Gateway contract on Cosmos Chain A.

That’s how Nitro will be pivotal in extending Cosmos chain connectivity to a broader spectrum of blockchain networks. This extension is a significant development, as it not only enhances interoperability but also expands the reach and utility of Cosmos-based chains within the larger blockchain ecosystem.

NOTE: The integration of Cosmos chains is a conceptual framework that is presently in the development phase.

As we’ve laid the foundation in this part, stay tuned for the upcoming blogs, where we’ll dive deeper into the other two flows and the individual pillars of Router Nitro’s architecture.

We’ll explore how it excels in capital efficiency, security, latency, and cost-effectiveness and how it is not just an ordinary bridge!!

To stay updated with our latest developments and to be part of our growing community, we invite you to follow us on our socials -