Breaking Down Router Chain's Whitepaper
All you need to know about Router Chain
Router Protocol introduced Router Chain and announced the Devnet launch of the L1 blockchain. To help everyone understand the vision behind Router Chain, the team published a comprehensive 41-page whitepaper.
Your bridging senses must be tingling to read through this whitepaper, but let’s be honest, whitepapers are incredibly hard to read. If you wish ChatGPT could help summarize them, you’re in the right place.
In this piece, we’ll break down Router Chain’s whitepaper and understand the case for building sovereign blockchains as hubs for interoperability-related use-cases.
Let’s dive in!
Router Chain – An Overview
Router Chain is a Cosmos-based L1 chain that caters to the interoperability needs of the cross-chain ecosystem.
To understand what Router Chain offers, we need to look at it from two different perspectives:
Router as a Cosmos Based Blockchain
Router Chain is a Proof of Stake (PoS) L1 blockchain built using the Cosmos SDK. As a result, it has the following characteristics:
It leverages tendermint’s Byzantine Fault Tolerant (BFT) consensus mechanism — a popular choice for many blockchains as it provides benefits such as security (only transactions deemed valid by more than ⅔ validators are added to the blockchain), speed (txs are validated quickly and block confirmation times are low), and scalability (can handle a high volume of txs).
It leverages the CosmWasm toolkit — this gives developers the flexibility to either a) build new dApps on the Router chain using the toolkit’s robust set of tools and libraries or b) port their existing dApp to Router Chain with minimal technical overhead.
It is a PoS blockchain — Router Chain distributes the trust in the system across a set of validators with economic incentives and slashing penalties to act honestly.
Router as an Interoperability Hub
Router Chain caters to one specific function – interoperability. As a result, it has been optimized to offer specialized features to make cross-chain bridging easier for dApps building on it.
Some of the noteworthy features Router Chain’s specialization as an interoperability hub offers include the following:
Default connectivity with any chain — dApps deployed on Router Chain will be able to interact with any chain by default. As a result, these dApps can benefit from any chain’s ecosystem growth, tapping into their liquidity and users.
For instance, cross-chain dApps these days are largely restricted within zones of sovereignty (like EVM chains, Cosmos chains, etc.) due to the varying consensus mechanisms and languages used by different blockchains. However, given Router Chain is essentially a Hub specialized for cross-chain communication, it enables dApps to connect with EVM and Non-EVM chains like Cosmos (through IBC).
The ability to perform more complex cross-chain functions — Router Chain’s validators can monitor state changes on other chains. This enables complex cross-chain interactions for dApps on Router Chain, such as cross-chain governance, staking, etc. Additionally, dApps on Router Chain have the ability to trigger events on smart contracts on different chains, unlocking the potential to enable even more complex cross-chain flows.
Flexibility as a result of customizability — Router Chain offers dApps the flexibility to customize important characteristics like security. It allows them to leverage the security offered by Router Chain’s validator network but additionally enables them to configure their dApp and further include supplementary security modules.
Note: Customizability in terms of dApp-specific security is a common offering across different arbitrary messaging bridges (AMBs) but is promoted using different terms like Hyperlane’s sovereign consensus, Axelar’s future-proof interoperability, or LayerZero’s isolated security offering through flexibility to choose/build different Relayer-Oracle combinations.
The Chains as Interoperability Hubs Thesis
The features mentioned above can essentially be offered by any specialized blockchain built to serve as a hub for interoperability. Such interoperability hubs have the potential to power the next generation of natively cross-chain dApps. Their ability to act like a Hub Chain and coordinate events on other chains unlocks unprecedented functionalities and makes a strong case for dApps that want to be natively cross-chain from Day 1 to deploy on them.
In the future, cross-chain dApps deployed on AppChains will be able to offer omnichain experiences that abstract the blockchain layer from the users, i.e., the UX will feel like interacting with a single chain (Hub) while the functionality would enable them to interact with the dApp on different chains.
How It Works – Transaction Lifecycle
A simplified cross-chain transaction via Router’s architecture looks something like this:
Here, the dApps’ smart contract and Router’s gateway contract pass requests from the source chain to the Router Chain, where these requests are validated and confirmed by Router Chain’s validator set before being forwarded to the target (destination) chains.
This is a high-level description of the flow of funds via Router’s architecture. In reality, there are several components in Router’s design that coordinate to enable cross-chain transactions. And before we dive into the deep end of how a transaction via Router Chain works, we must understand the different architectural components of the Router Chain:
Source Chain — the chain from which a cross-chain transfer originates. It’s the chain where the tokens transferred in a cross-chain transaction currently reside.
Destination Chain — the chain that receives the tokens transferred from another blockchain (source chain). It’s the chain where the tokens end up after a cross-chain transfer.
Relayers – third-party entities responsible for listening to events on the Router Chain and relaying this information to the destination chain.
Validators / Validator Set — entities responsible for verifying the accuracy and integrity of transactions and data being transferred between the Router Chain and other chains. For a transaction to be confirmed by Router’s PoS Chain, it must be signed by ⅔+1 validators weighted by stake.
Orchestrators — work in tandem with Router’s validators (run by validators themselves) and are responsible for 1) listening to incoming events from other chains, 2) attesting their validity before Relayers pick them up, and 3) forwarding them to the Router Chain.
Gateway Contracts — serve as the interface for a dApp to communicate between Router Chain and other chains. They act as intermediaries between a dApp’s bridge-specific contracts on Router Chain and its contracts on other chains, enabling transactions to be initiated on one chain and executed on another.
Middleware Contract — maintain states across different chains and enable dApps on Router Chain to implement custom bridging logic directly in the bridging layer, allowing them to implement ‘if this, then that’ kind of logic in their application. These contracts are crucial to Router Chain’s ability to offer application-specific customizations and features such as batching, sequencing, and atomicity in the bridging layer.
Inbound module — connects different chains to the Router Chain and ensures the legitimacy of the inbound requests from an orchestrator.
Outbound module — connects Router Chain’s smart contract to other chains, ensuring that the Router Chain’s smart contract can send requests to the destination chain’s contract.
Now that we have a better understanding of each component's specific roles in the Router Chain, let's dive deeper into a detailed description of how a cross-chain transaction flows from the Source Chain to the Destination Chain via Router’s architecture.
Inbound Flow – Source Chain to Router Chain
Step 1a — User initiates a transaction on the dApp’s smart contract on the source chain.
Step 1b — The dApp’s smart contract calls the requestToRouter() function (allows the dApp’s contract to send messages to the application-specific bridge contract on Router Chain) on the Router Gateway contract with key information about the user’s transaction such as:
routerBridgeContract — address of the application-specific bridge contract on Router Chain.
payload — data such as the destination chains type and Id that needs to be passed to the bridge contract.
gaslimit — gas limit to successfully execute the request on the Router Chain.
feePayer — address from which the fee will be deducted.
Step 2 — The Router Gateway contract on the source chain emits an event. The Orchestrators gather the event.
Step 3 — The Orchestrators dispatch this event to the Inbound Module which then validates the event using the attestation module, wherein all the votes from the validators are processed and if an event attains ⅔ + 1 majority, it is considered valid.
Step 4 — The inbound module deducts the fee and executes the transaction on the application specific bridge contract on the Router chain.
Step 5 — The inbound module executes the transaction on the application-specific bridge contract.
Step 6 — The application-specific bridge contract validates the correctness of the source contract from which the request has been generated and applies the relevant logic depending on the destination chain (Router Chain or third-party chain).
Outbound Flow – Router Chain to Target (Destination) Chain
Step 1a — The Outbound Module picks up the corresponding outbound request coming from the application-specific bridge contract.
Step 1b and 1c — The outbound module estimates the transaction fee and deducts it from the application specific bridge contract.
Step 2 — The outbound module collects the validator’s signatures (given by orchestrators) and validates the event using the attestation module.
Step 3 — If the event attains ⅔ + 1 majority, it is picked up by the Relayer who then forwards it to the Router Gateway contract on the destination chain.
Step 4a — The Router Gateway contract on the destination chain calls the handleRequestFromRouter () function to handle the transaction request coming from the Router Chain.
Step 4b — The application-specific bridge contract on the destination chain executes the required logic based on the data transferred.
Acknowledgement Workflow – Confirming the Transaction
Step 1 — Once the function is executed on the destination chain, an acknowledgment event is emitted by the destination chain’s gateway contract.
Step 2 — The orchestrator listens to this event and sends a request to the Outbound module which validates the event using the attestation module. After receiving more confirmations about the validity of the event, the process gets completed.
Step 3a — Relayer receives the fee spent for the cross-chain transaction along with the incentive for running a relayer.
Step 3b — The excess fee is refunded to the bridge contract on Router Chain.
Step 4 — The Outbound module forwards the acknowledgement of the completion of the process on Router Chain to the application-specific bridge contract.
Trust Assumptions
Router Chain makes the following trust assumptions:
External verification by a set of validators — Router Chain adopts a ‘decentralized trust-based approach’ in order to offer more flexibility in terms of what can be built using Router Chain. This means, the Router Chain uses a set of validators to execute transactions and if ⅔ + 1 validators weighted by stake collude, users funds can be stolen. Thus, it can be said that Router Chain inherently trusts that over ⅔ + 1 validators weighted by stake will not collude maliciously at a certain time.
Note: Router Chain is currently in the Devnet phase. The team aims to onboard 50-70 validators for mainnet.
Censorship Risk — ⅓ of Router Chain’s validators weighted by stake can collude to censor a message.
Validators will act honestly because of slashing penalties — Router Chain’s design assumes that the slashing mechanics wherein if any validator experiences excessive downtime or engages in malicious activity will have their ROUTE slashed, will discourage validators from acting dishonestly.
Note: Once Router Chain is deployed on Mainnet, we will conduct a deeper analysis of its architecture and present our findings.
Router Chain Overview
Here’s a table with all the key information you must know about Router Chain:
Community & Resources
You can learn more about Router Chain and stay updated about its community through the following:
Get Started With LI.FI Today
For more information about the LI.FI protocol,
Head to our link portal at link3.to/lifi
Read our SDK’ quick start’ at docs.li.fi
Join the official Discord server
Follow our Telegram Newsletter
Subscribe on our Substack
or try our any-2-any swaps NOW at jumper.exchange