Breaking the Mold: Router Protocol and Hashi’s Collaboration to Redefine Cross-Chain Security

5 min readApr 3, 2024

Deciphering Hashi’s Oracle Aggregation and Router Protocol’s Role

Router Protocol is integrating with Hashi, an EVM Hash Oracle Aggregator designed to facilitate a principled approach to cross-chain bridge security. It aims to bolster the security of cross-chain bridges by requiring multiple independent mechanisms to participate in validating transactions. And as part of this integration, one of the independent mechanisms would be Router Protocol’s CrossTalk!

Before diving further into the integration’s intricacies, let’s first understand what Hashi is doing. This will help us understand the integration better.

What Is Hashi? How Does It Contribute to Safer Blockchain Communications?

Hashi is an Oracle Aggregator. It allows gathering, verifying, and aggregating data from multiple Oracles. But what are Oracles? They are entities that provide external data to smart contracts, enabling these contracts to execute based on real-world events and information.

In the case of Hashi, it creates “additive security” to cross-chain messages by aggregating block headers from different sources.

A block header will be considered valid only when a number of block sources (oracles) above a certain threshold report the same result. As of today, more than 15 oracles and ZK light clients can be used as block sources!

Hashi is the first step towards a principled approach to bridges. Let’s break this down as well!

Aggregation of Block Headers: Hashi collects block headers from multiple oracles. A block header is a “summary” of a block’s contents, including information like the previous block’s hash, timestamp, etc., serving as a compact representation of the block’s state and transactions.
Verification Through Consensus: Instead of relying on a single source for verifying cross-chain messages, Hashi requires that multiple oracles (block sources) reach a consensus on the block headers. A block header is deemed valid only if it is reported consistently by a predefined number of sources that meet or exceed a specific threshold.
Threshold-Based Validation: The “certain threshold” criterion ensures a robust level of agreement among independent oracles before a block header is accepted as valid. This threshold is a crucial parameter for the system’s security, as it must be carefully set to balance security with efficiency.

With Hashi, the security of cross-chain messages does not depend on the reliability of one single oracle, but it is bolstered by the collective verification from multiple independent sources.

But why is this ‘principled approach to Bridges’ required?

The answer to this is very simple: the vulnerability of the Bridging world! And the heart of the problem with blockchain bridges lies in two glaring vulnerabilities. First, there’s a risky bet on a single security measure to guard against complex cyber threats, a strategy that’s akin to putting all your eggs in one basket, underestimating the cunning of potential hackers.

Then, there’s the fierce competition among bridges, each vying to be the top dog by controlling everything from A to Z, which ironically leads to unnecessary duplication of efforts and a detrimental race to the bottom. This breeds vulnerability and stifles innovation as the focus shifts from building robust, secure bridges to merely outdoing the competition.

A shift towards collaborative security models and a bouquet of diverse, fail-safe mechanisms is desperately needed to truly fortify the bridging world.

Hashi steps into the scene like a breath of fresh air in the somewhat tumultuous world of blockchain bridges. It recognized that the way things were being done — each bridge operating in its own bubble and relying heavily on a single security measure was risky.

So, Hashi introduced what’s known as ‘additive security,’ a strategy that layers multiple security mechanisms on top of each other. This approach ensures the entire system doesn’t crumble if one layer gets compromised. Moreover, by acting as a “multi-sign for bridges,” Hashi brings a new level of resilience and robustness to cross-chain transactions.

Now that we’ve understood almost everything required around Hashi let’s return to the integration!

Router Protocol–The New Oracle For Hashi!

As mentioned above, Oracles, in the case of Hashi, consists of the bridge solutions available in the market. An adapter contract is designed specifically for each Oracle, in order to provide a universal interface.

Router Protocol’s Cross-talk will be part of this integration, an extensible cross-chain framework that enables seamless state transitions across multiple chains. This library leverages the Router’s infrastructure (Gateway Contract) to allow contracts on one chain to communicate with contracts deployed on some other chain. Gateway contracts help an application to initiate a CrossTalk Request on the source chain with some parameters, and once the source chain transaction is successful, the Gateway contract emits an event for the same.

Essentially, Cross-talk becomes an oracle for Hashi by serving as a bridge solution that Hashi aggregates with others for enhanced security.

Router’s Support for Breaking Free from Vendor Lock-ins

Hashi’s approach to leveraging multiple oracles for verifying cross-chain messages is a big step away from traditional vendor lock-ins, promoting a versatile and decentralized framework for application security. And we support this flexibility of enabling dApps to seamlessly switch between different oracles, particularly in scenarios where an oracle may not meet the required security standards or become compromised.

dApps can also leverage Router’s Additional Security Module!

Here at Router, we firmly believe in empowering applications that utilize our infrastructure to tailor their security measures according to their unique needs. That’s why we offer the Additional Security Module (ASM), allowing dApps to enhance their defenses beyond our standard security protocols.

By integrating the ASM, dApps can proactively address potential security threats at the application level, ensuring the overall system’s security remains robust. This could involve implementing features like a waiting period akin to optimistic roll-ups, rate-limiting, or other pertinent security measures seamlessly integrated into the dApp, providing an extra layer of protection for users.

Integrating Router’s ASM into a dApp’s security strategy bolsters its defenses and echoes Hashi’s vision of creating a secure, fluid, and adaptable cross-chain communication ecosystem.

We invite you to stay connected with us for further updates and join our community across our various social platforms.