Hyperbridge Relayer Incentivization Protocol

Do not index

While we continue to wrap up the changes for Gargantua V2, We’d like to announce an exciting opportunity for our community members to be a part of the Hyperbridge network by running permissionless relayers. Hyperbridge will be the first fully trust-free cross-chain bridge to offer this feature and allow it’s community to be compensated by relaying requests & proofs of these requests to the appropriate chains.

Existing interoperability protocols today cannot boast of a decentralized pool of relayers, as their security model depends on a select few trusted actors who are authorised to submit cross-chain messages to the counterparty network. Unlike these protocols that rely on a few privileged actors - an approach that has led to over $2B in bridge exploits - Hyperbridge allows anyone with the finality and state proofs of these messages to execute cross-chain requests. These proofs are unforgeable and backed by the security of the originating blockchain. As a result, Hyperbridge can host the first-ever decentralized and permissionless pool of relayers who relay cross-chain requests on behalf of users. Relayers will operate without the need for whitelisting or staking. Additionally, they will have the freedom to choose the networks they wish to relay for.

The protocol works as follows at a high level. A user transacts with an application that emits a cross-chain message. In the context of the ISMP framework, these are called “requests”. The ISMP framework allows users to lock up funds alongside the request, which are to be used to pay for the execution cost of the message on the target chain. Once the message is successfully delivered, a relayer can claim these funds. But how can the user on the originating chain verify that the request has been successfully delivered? This is where state proofs come into play. Hyperbridge already utilizes the security and unforgeability of state proofs for message delivery and execution. This is what allows for decentralized relayers. But even more so, it forms the foundation of our relayer incentivization protocol.

After a request is made, relayers estimate the gas needed to execute the request on the destination chain, considering the current gas price. They compare this with the value of the funds the user has locked up on the source chain. If the user has provided enough funds, the relayer executes the request. However, if the user has not provided sufficient funds, or if a sudden spike in gas prices makes the funds insufficient, then relayers will ignore the request. Consequently, the request will time out gracefully, and the protocol will refund the user the funds they had provided as the execution fee.

When a relayer successfully delivers a request, the ISMP framework records the address of the responsible relayer in its storage. However, if a request cannot be successfully executed on the counterparty due to issues like the destination module reverting or an unintended state of the application, the relayers will be unable to claim the delivery fee, despite having already paid for the execution. In the Hyperbridge relayer, requests are dry-run before attempting to execute them on-chain to ensure that only requests that will execute successfully are delivered by the relayer. After successful message delivery, the relayer can submit state proofs of the request on the source chain and state proofs of the request delivery on the destination chain to Hyperbridge itself.

It is worth noting that the Hyperbridge will not have any transaction fees, as it does not host any user applications. It's users are on its connected chains. Hyperbridge only admits transactions that have the relevant proofs, such as consensus proofs, new cross-chain messages with their relevant state proofs, or relayer fee claims with their relevant state proofs. Once Hyperbridge verifies proof of delivery, it sends a privileged request to it’s contracts on the source chain, instructing them to release the delivery fee to the relayer.

We've chosen to use stablecoins as the payment method for message execution to avoid the volatility issues associated with non-stable tokens. Consider a scenario where a user has locked up non-stable tokens and their value falls rapidly. This can result in no relayer picking up the transaction, and as a consequence many users experiencing transaction timeouts, creating a poor user experience. Alternatively, if the token's value increases rapidly, users may overpay for their transactions. While this could benefit the relayer, it's disadvantageous for the user. To ensure a consistent user experience, we've chosen to use stablecoins.

A decentralized and permissionless protocol requires a similarly decentralized and permissionless stablecoin, hence our choice of DAI. DAI is a permissionless and over-collateralized stablecoin that has maintained its peg for most of the past seven years. We are confident in its ability to continue maintaining its peg into the future. In contrast, other centralized stablecoins have a privileged issuer who can freeze user accounts, a practice we believe contradicts the core value of censorship resistance. Users can always swap their tokens for DAI through some local AMM to pay for message execution on the destination chain, prior to dispatching their requests.

How much can relayers expect to earn? This is where the excitement begins. The cost of executing a cross-chain request is equal to the cost of state proof verification of the request plus the cost of executing the destination module logic. Since we verify proofs before executing any message, users must cover this cost. Currently, the cost is a mere 150k gas, which would be quite expensive on the Ethereum mainnet today but only costs a nominal $0.03 on L2s.

Users pay individually for their transaction execution, but relayers will batch them up for efficiency gains. With our chosen state proof scheme, Merkle Mountain Ranges, relayers can expect to pay less than half the total sum of requests for proof verification due to the efficiency of merkle multi proofs. For example, a batch of 10 transactions, each costing 150k gas to verify individually, would collectively cost only 750k gas, allowing relayers to earn double what they pay for. In other words, users lock up $0.03 for 10 transactions, but relayers only pay $0.15 to execute them and freely pocket the difference.

We anticipate this cost will decrease significantly when we replace our Merkle Mountain Range scheme with Verkle trees. With this scheme, the cost of verifying a single transaction is the same as the cost of verifying a batch of transactions, thanks to its constant size proofs and constant time verifier. This increases the profit margins for relayers by over -times, where represents the size of the transactions in their batch.

We believe that the resiliency and reliability of any interoperability protocol, will hinge greatly on it’s ability to leverage a permissionless and incentivised pool of relayers. We see relayers as important stakeholders in the Hyperbridge network and this is why we’re calling on members of our community who want to contribute in some way to Hyperbridge to sign up to be part of our testnet v2 launch as relayers. This is to allow you properly simulate your relayers on testnet in anticipation for our mainnet launch. Please sign up here.