Hyperbridge: Achieving break-even with just 10 million messages processed annually!

In the blockchain world, many cross-chain protocols are merely "combinations of components"—a chain, a set of nodes, some cryptography—but Hyperbridge is completely different.

Hyperbridge is a more complex, rigorous, and bold system: it is composed of multiple layers of nodes, verification mechanisms, economic incentives, and the security of Polkadot itself. No single part can be missing, and no component can operate independently.

The first time I realized this was at the inaugural Sub0 in Brussels. At that time, everyone was discussing the cryptographic foundations of Hyperbridge—proofs, verification, cross-chain logic. But it was only later, through ongoing conversations with the team, that I truly understood: the core of Hyperbridge is not just cryptography, but the crypto-economic mechanism that allows it to continue operating even after developers have completely withdrawn.

It is from this question that we can see the true nature of Hyperbridge: it is not a parachain, not a type of relay node, nor a submodule of Polkadot, but a cross-chain system with a layered structure, clear roles, dynamic incentives, and economic security endorsed by Polkadot.

• From an "untrusted relay layer" to a "trusted layer that achieves final verification through Polkadot";
• From Collators responsible for proof verification, to consensus relays maintaining consensus synchronization, to message relays actually transmitting cross-chain data;
• From lightweight nodes with extremely low hardware requirements (2GB RAM is enough), to the Polkadot validator set that supports the entire security model…

Every detail of Hyperbridge answers the same question: "How do you build a truly non-custodial cross-chain protocol that can reliably operate for the long term?"

This article will guide you through the entire internal structure of the Hyperbridge cross-chain machine—from architecture, nodes, economic model, to the role of Polkadot!

The Hyperbridge Protocol Is Not a Single Component

The Hyperbridge protocol is not a single component. It is not the Hyperbridge parachain itself, nor a certain type of relay node, nor is it a part of the Polkadot network. Rather, it is an organic whole composed of all these elements together.

This whole includes consensus relayers, message relayers, block producers, stakers, and also relies on Polkadot as the underlying network. Without any one of these, Hyperbridge cannot function properly.

If Polkadot is unavailable, Hyperbridge cannot exist; if a certain type of relay node goes offline, the protocol will also come to a halt. Therefore, we must build a clear incentive structure and crypto-economic guarantees so that all participants can be effectively united to jointly maintain protocol operation.

If you are familiar with the OSI model (especially the layered architecture of TCP), you will find it easier to understand Hyperbridge's design logic. The OSI model has physical, link, application, and presentation layers, and in cross-chain interoperability, we also adopt a similar layered approach.

At the top of the entire structure is the Polkadot network, which provides the operational foundation for all other parts of the Hyperbridge protocol stack. Beneath it is Hyperbridge's own network, including its parachain system. At the lowest level are the relay nodes, which are equivalent to the "physical connection" of the Hyperbridge protocol, responsible for interfacing with all external networks, collecting external information, verifying various proofs, processing cross-chain data, and submitting this content to Hyperbridge; after Hyperbridge completes preliminary verification, the results are handed over to Polkadot for final confirmation. In other words, Polkadot provides a final endorsement that "all data and operations have been executed according to the rules."

There is an important structural feature here: the Hyperbridge network and relay nodes themselves are "untrusted", and this layer has no economic security guarantee; only when data flows to the top Polkadot network does it enter the "economically secure" layer. That is, Polkadot supervises both Hyperbridge and the relay nodes, ensuring that both layers operate according to the rules. In terms of division of responsibilities, relay nodes need to cooperate with Collators to complete the cross-chain process: relay nodes collect transactions, proofs, and cross-chain data, and submit them to block producers; Collators are responsible for verifying whether all information is authentic, complete, and compliant. Only transactions that pass verification enter the block, while invalid data is intercepted at this stage.

This is crucial, as intercepting invalid transactions in advance can greatly save valuable block space. After Collators complete all verification and packaging, they submit the block to the Polkadot network. One of Polkadot's core capabilities is to verify all blocks. Unlike Layer2 in the Ethereum ecosystem, which needs to generate zero-knowledge proofs themselves, Polkadot will directly complete block verification for you. After verification, Polkadot confirms that "the block content complies with all rules" and generates a "block validity proof" (or validity certificate). This is very important and will be elaborated on later.

The Three Main Roles in Hyperbridge: How Collators, Consensus Relayers, and Message Relayers Drive the Entire Cross-Chain System

Let's start with the first key role in the Hyperbridge network: Collator (Block Producer)

Their core responsibility is to collect and verify various proofs for cross-chain interoperability, mainly handling two types of transactions with attached proofs: one is consensus messages, and the other is cross-chain messages.

Here is a design very different from traditional blockchain systems: Collators are not staking nodes. In most blockchains, to become an active node, you usually have to stake a large number of tokens to join the node set. But in Hyperbridge, we use a completely different mechanism:

• To become a Collator, you only need to lock a small amount of Bridge Token as a minimum threshold; 
• But to actually be selected by the system as a Collator, you must consume "reputation points"; 
• And reputation points can only be earned by serving as an active relay node for a long time. 

In other words, only relay nodes are eligible to become Collators, with no other channels. You cannot bribe, use connections, or buy your way into the Collator set; the only way to become a Collator is to perform relay work stably over the long term and accumulate reputation points. In addition, applying to become a Collator requires a small security deposit to enter the verification process.

The final selection method is also very straightforward: the system sorts by reputation points, and the relay nodes with the highest points become the Collators for that period. Moreover, the Collator set rotates every 24 hours, ensuring that new, high-performing relay nodes have a chance to enter the next round.

Collators are clearly rewarded for their work: for each block packaged, they can earn about 0.7 Bridge Token. However, if they miss a block or fail to complete packaging on time, they do not receive this reward.

Next, let's talk about consensus relay nodes

Consensus is crucial for cross-chain messages, because all cross-chain transactions need to be confirmed on Hyperbridge as "already finalized on the source chain." To achieve this, we must obtain consensus proofs from external chains.

The problem is: modern blockchains—especially slot-based blockchains—continuously produce blocks whether or not transactions occur. This means that even if there are no cross-chain activities, the external network's blocks keep growing. Therefore, Hyperbridge must synchronize this information in real time to correctly verify future cross-chain messages.

This is the main responsibility of consensus relay nodes: to continuously submit consensus messages from external networks, keeping Hyperbridge synchronized with external chains. Even if no transactions occur, this synchronization must continue. When submitting these consensus messages, they do not need to pay transaction fees; instead, the Hyperbridge protocol directly pays them for their work.

To incentivize consensus relay nodes to perform this ongoing work, the protocol provides Bridge Token rewards—meaning consensus relay nodes can earn stable token income by performing synchronization tasks.

Now let's talk about message relay nodes

Let's first understand their relationship with consensus relay nodes: suppose an external blockchain continuously produces blocks, consensus relay nodes sit between this chain and Hyperbridge, collecting proof files for each newly finalized block and submitting these proofs to Hyperbridge, thus earning Bridge Token rewards from the protocol. This process ensures that consensus relay nodes must remain online long-term, keeping Hyperbridge and all external chains in consensus synchronization.

Message relay nodes are similar to consensus relay nodes, but their focus is different: they are specifically responsible for submitting cross-chain messages. Once Hyperbridge has synchronized to a new finalized block, message relay nodes compare this block with the previous finalized block to scan for new cross-chain messages generated during the interval. If they find cross-chain instructions that meet the rules, they submit the message along with the proof file to the Hyperbridge blockchain.

However, there is a very important difference between the two: message relay nodes do not always receive rewards for submitting messages; sometimes, they even need to pay fees to Hyperbridge.

The process is as follows:

• Users or applications can initiate cross-chain messages from any blockchain, attaching a certain amount of stablecoins as a source of handling fees. 
• When message relay nodes scan block content and find such cross-chain messages, they forward them to Hyperbridge. 
• After the message is successfully submitted, the relay node can extract the stablecoins attached by the user as a reward from the protocol. 

In addition, there is a regulatory mechanism:

• If the message processing volume does not reach the threshold set by the protocol, Hyperbridge will additionally issue Bridge Token rewards to message relay nodes; 
• If the message processing volume exceeds the threshold, message relay nodes need to pay Bridge Token fees to Hyperbridge. 

This design allows the protocol to naturally form a revenue pool while controlling the behavior of message relay nodes, ensuring that message delivery capacity is neither excessive nor insufficient.

Essentially, this entire mechanism is to keep message relay nodes online: once cross-chain data is generated, the system can deliver it to Hyperbridge in the shortest possible time. The overall logic is similar to consensus relay nodes—message relay nodes also sit between external chains and Hyperbridge, responsible for collecting cross-chain transactions from external chains and delivering them. The difference lies in the reward mechanism: when message processing volume is insufficient, Hyperbridge subsidizes relay nodes with Bridge Tokens; when message volume exceeds the set target, relay nodes need to pay Bridge Tokens to Hyperbridge, which then accumulates token revenue.

ZK Cross-Chain Costs Can Reach Millions, While Hyperbridge Only Needs a 2GB Server

Let's briefly discuss the hardware requirements for running these Relayers (relay nodes) and Collators.

First, relay nodes. The relay node software itself is very lightweight, and its main task is to send RPC query requests to blockchain nodes, so hardware requirements are almost negligible. A quad-core CPU is more than enough, and even a server with only 2GB of RAM can easily handle it. After all, the entire software is written in Rust, with very high memory efficiency.

Bandwidth requirements are also not high. If the relay node and the RPC node are deployed in the same data center, 20 MB/s bandwidth is sufficient; if you need to access RPC nodes over the internet, it is recommended to choose higher bandwidth for stability.

In fact, the biggest cost of running relay nodes comes from the subscription fees of RPC service providers.

Whether you use Alchemy, Quicknode, or Anchor, you can directly obtain all the proof files and data needed for cross-chain from their full nodes, so the operational cost is extremely low.

This is one of the fundamental reasons why Hyperbridge has a significant advantage in large-scale cross-chain interoperability. Many current cross-chain solutions rely on zero-knowledge proofs (ZK proofs), which are not only expensive to generate but also have considerable long-term operational costs; in contrast, Hyperbridge's operational costs are almost unbelievably low.

Now for Collators. Their hardware requirements are higher, because Collator software must run a local Polkadot relay chain node internally. This means significant storage pressure—Polkadot archive nodes require about 3TB of space, so it is best to equip at least a 4TB SSD when deploying.

At the same time, to ensure efficient communication with the Polkadot relay chain and timely block submission, Collators also need servers with higher bandwidth. The monthly cost of such servers is about $200. Of course, if you are already a home validator and willing to deploy nodes at home, this cost can be ignored.

What Role Does Polkadot Play in Hyperbridge?

Finally, let's look at the role Polkadot plays in Hyperbridge.

As a parachain in the Polkadot ecosystem, Hyperbridge essentially acts as a "cryptographic verification coprocessor" for cross-chain message delivery. But this coprocessor's verification capability does not come from itself, but from the security of the Polkadot mainnet. The aforementioned Hyperbridge block "cryptographic validity certificate" is actually a digital signature generated by the Polkadot validator set, meaning these certificates are jointly endorsed by the currently active validators of the Polkadot network.

Understanding this is crucial: at its core, blockchain is a large-scale "multi-signature mechanism," and the validator set is a dynamically operating giant multi-signature account.

So, what is the essential difference between such a blockchain-level "multi-signature" and traditional multi-signature bridge solutions? There are two main points:

First: the validator set rotates dynamically, while multi-signature committees are statically fixed

• In Polkadot, the validator set rotates automatically every 4 hours; 
• In multi-signature bridge solutions, the "signing committee" members are fixed for the long term, and their private keys are usually stored on the same devices for a long time. 

This means that traditional multi-signature bridges are more easily compromised by private key leaks, while Polkadot's dynamic validator design greatly enhances security.

Second: blockchain validator signatures carry "on-chain economic security guarantees"

• Polkadot validators must stake assets, and if they sign incorrect or malicious information, their staked assets will be slashed.
• In contrast, traditional multi-signature committees have no cost or risk constraints, and even if they collude maliciously, they do not bear any losses.

This also explains why, when multi-signature bridges are hacked, attackers can easily steal billions of dollars, while committee members bear no consequences.

Why not use blockchains directly as "giant multi-signatures"? The only issue is scale. Blockchain validator sets are usually very large. For example, in Polkadot:

• There are currently over 600 validators 
• In the future, this may expand to 1000+ 

Without any optimization, verifying signatures at such a large scale would be very costly. But this can be solved with the following technologies:

• Aggregatable BLS signatures
• Zero-knowledge proof (ZK) assisted verification technology

These solutions can compress the cost of large-scale signature verification to an acceptable range.

In contrast, multi-signature committees can only remain small to keep verification costs low, so their security is far inferior to blockchains.

There is also a fundamental difference: the governance structure is completely different. The blockchain validator mechanism is open and permissionless:

• Anyone who stakes enough assets can join or exit the validator set; 
• Multi-signature committees are closed and permissioned: members must be manually selected and trusted, which is inherently highly centralized. 

Hyperbridge Only Needs to Process About 10 Million Messages Per Year to Break Even

Next, let's look at the economic model of the Hyperbridge protocol. Hyperbridge's annual operating costs are clear and relatively fixed. As mentioned earlier, the protocol needs to provide incentives to different roles, including:

• Consensus relay incentives: about 3 million Bridge Tokens 
• Message relay incentives: about 1.4 million Bridge Tokens 
• Collator incentives: about 3 million Bridge Tokens 
• And the core time cost of Polkadot (although variable, the overall cost is not high) 

In total, the annual cost to keep the Hyperbridge network running is about 10 million Bridge Tokens.

So the question is: where does the funding come from to cover this expense?

The answer is Hyperbridge's on-chain treasury. The treasury holds about 40% of the total Bridge Token supply, making it the largest token holder in the system. This reserve is enough to support the protocol's continuous operation for about 40 years, giving Hyperbridge ample time to achieve sustainable profitability.

The profit model is also very clear: whenever users initiate cross-chain messages, cross-chain transactions, cross-chain storage queries, etc., the Hyperbridge treasury can collect a certain fee, which is collected on behalf of the treasury by message relay nodes.

According to the current model, Hyperbridge only needs to process about 10 million messages per year to break even.

According to Token Terminal data: global cross-chain transaction volume exceeds 1 billion per year. Therefore, Hyperbridge only needs to capture about 1% of the market share to reach the break-even point, after which it will enter a phase of sustained profitability.

Here are some key current metrics for Hyperbridge:

• Saved over 13 trillion gas for various verification operations
• Processed over 50,000 cross-chain messages: including messages from Polytope Labs' own applications as well as cross-chain operations initiated by third-party applications on the mainnet 
• Verified over 10 million proof files (consensus proofs, message proofs, etc.) 
• Cross-chain message-related transaction volume has exceeded $180 million
• Economic security provided by Polkadot, currently exceeding $2 billion
• Supports more than 14 mainstream EVM public chains: Polkadot, Hydration, Bifrost, Arbitrum, Polygon, Base, Gnosis, Ethereum Mainnet, Unichain… and is continuously expanding 

Core Application Scenarios of Hyperbridge

Let's quickly introduce the core application scenarios of Hyperbridge.

1. Token Gateway

• Supports burn & mint cross-chain mode; 
• Fully compatible with existing ERC-20, and can also choose lock & mint mode; 
• Can bridge any token and attach custom call data; 
• Already supports multiple assets on the mainnet, including DOT, vDOT, ZKVerify, Manta, etc. 

2. Intent Gateway

• Supports fast cross-chain transactions; 
• Most cross-chain operations can be completed within 30 seconds; 

The biggest innovation is:

• If a cross-chain order is not executed, users can apply for a refund permissionlessly and autonomously on the Hyperbridge frontend and receive the refund immediately.
• The entire mechanism relies on the verification proof system: Hyperbridge can query the counterparty chain status in real time, and once it confirms that the order was not executed, it immediately triggers the refund process. 

3. Developer Ecosystem and Third-Party Applications Under Construction

Currently, many third-party teams are developing based on Hyperbridge:

• Hydration: building their customized Intent solution based on Hyperbridge, and also developing a price oracle for some ETH staking derivatives. 
• Bifrost: building a price oracle for vToken and planning to launch asynchronous vToken minting functionality. 
• Multiple hackathon teams have successfully deployed applications on the Hyperbridge testnet. 

We are also actively exploring more native application directions, including:

• Verifiable price oracles 
• Cross-chain governance (initiate governance proposals on one chain, results readable across all chains) 
• Cross-chain identity authentication (identity data stored on one chain, callable directly by multiple chains) 
• Historical storage query function (allows contracts to read the historical state of the target chain, extremely important for protocols that use Merkle trees for incentive distribution) 

We have also recently released a brand new developer toolkit, which includes:

• Complete Hyperbridge Solidity interface for Solidity applications
• TypeScript SDK for wallets and frontends
• Subquery indexer
• Intent Filler and other auxiliary components to help developers quickly build cross-chain applications. 

Major Release: Hyperbridge Will Soon Be Natively Integrated into Polkadot Hub

Hyperbridge will be natively integrated into Polkadot Hub. This means that all applications running on Polkadot Hub will be able to directly interact with blockchains outside the Polkadot ecosystem through Hyperbridge, using cross-chain storage, cross-chain queries, cross-chain messaging, and other capabilities.

We are also working closely with the Parity team to advance the implementation of BLS Beefy:

• Currently, Polkadot consensus proof nodes are still operated by the Polytope Labs team 
• In the future, decentralized validation will be achieved through aggregatable BLS signature technology 
• This will also realize the ultimate fully decentralized operation of Hyperbridge 

Hyperbridge's EVM ecosystem integration is still expanding, and we will soon add support for:

• Arc 
• Tempo 
• Monad 
• Sonic 
• Tron (Tron is developing state commitment functionality, and will be officially supported once completed) 

In addition, we already support EVM chains in the Cosmos ecosystem, including:

• Sei 
• Cronos 
• Injective
• and several other Cosmos ecosystem networks compatible with EVM. 

That's all for my sharing. Thank you all for listening and participating!