​
Introduction

The Relay Protocol is a cross-chain payments system that connects users to relayers willing to perform onchain actions on their behalf. Relay’s design minimizes gas costs, enables rapid chain expansion, and maximizes capital efficiency all while remaining open and trustless. Such a system is particularly well-suited for low-value, high frequency cross-chain actions such as those expected in a world of chain abstraction.

​
Background: Cross-Chain Relaying

In its current state, the Relay API is similar to other “intent-based” protocols like Across, where liquidity providers known as Relayers use their own capital to “fast fill” user requests to move between chains, and then rebalance using slow, expensive bridges under the hood. This design has two key advantages over typical bridging:
  • Speed - Because relayers are fronting their own capital, they can take on confirmation risk and fill optimistically, without waiting for global consensus
  • Cost - Because rebalancing is done infrequently and in batches, the security cost of using bridges is amortized across many users
The typical flow for intent-based protocols is as follows:
  1. User escrows funds on the origin chain
  2. Relayer fills the order on the destination chain
  3. Relayer later settles the order on the origin, to claim payment
title Each of these steps has a cost, which different protocols minimize in different ways. Across, which pioneered this design, reduces the cost of settlement with two optimizations:
  • Instead of proving every fill with an oracle or cross-chain message, settlement is done optimistically, by assuming it is correct, and having a challenge period
  • Settlement is done in large batches across the whole protocol, every 4 hours
As a result, the vast majority of the remaining cost comes from the Deposit (~77,000 gas) and Fill (~120,000 gas). This is where Relay is able to achieve significant improvements:

​
Overview of the Relay Protocol

The Relay protocol is designed to minimize the cost of deposits and fills by using a novel architecture that separates the concerns of deposit, market making, liquidity providing and intent filling on the destination chain. We design the protocol with the goal of supressing any need for trusted intermediaries, including the need to prove and settle fills. This overview was designed to give a high level summary, and did not go into technical detail or discuss how adversarial scenarios are handled. These will be addressed in a future whitepaper. The protocol will eventually be made of various components which can work independently or together. As of today, some of these components are already implemented and in use, while others are still in development. The ones that are currently implemented include: These components will also evolve over time to support the overall protocol architecture and their current implementation may not reflect the final design, but rather provide a good intermediate state that enables use to evolve from a simple intent filling API to a fully trustless cross-chain payments system. You can interact with the Relay Protocol through our Relay app, which provides a reference UI. You can also find the source code for all the components of the Relay Protocol on GitHub.

​
Basic Flow of the current implementation

Alice sends her funds to the Depository contract on the origin chain. The Relayer fills Alice’s request on the destination chain. The Hub keeps track of that deposit. The Relayer can then trigger the Oracle to verify that the intent was correctly filled. If so, the Relayer can then settle the payment and access their user’s deposited funds. In order to fill on multiple chains, the Relayer needs to keep balances on every supported network. The Vaults are used to rebalance the Relayer’s balances across chains.