IBC Relaying as a Service: The In-Protocol Incentivization Story

Are you willing to start supporting the network by becoming an Interchain relayer operator? Are you a relayer operator interested in understanding how to refine your business model to make it profitable? Are you a dev looking forward to putting all the pieces together before starting your IBC gang chain? This article is everything you need! Read more about the fee payment design and start your Interchain journey.

Inter-Blockchain Communication (IBC) is an interoperability protocol that has been designed with two layers: the transport layer for handling the assembly of data into generic packets and the verification of this data across chains; and an application layer that understands the contents of the packets and what to do with the data that has been passed. Security of the protocol in terms of transaction verification and packet correctness is guaranteed by light clients on the transport layer, rather than the relayers who pass the data packets between IBC clients on each chain.

Though IBC does not depend on relayer operators for transaction verification, the relayer infrastructure ensures liveness of the Interchain network — operators listen for packets sent through channels opened between chains, and perform the vital service of ferrying these packets (and proof of the transaction on the sending chain/receipt on the receiving chain) to the clients on each side of the channel. Though relaying is permissionless and completely decentralized and accessible, it does come with operational costs. Running full nodes to query transaction proofs and paying for transaction fees associated with IBC packets are two of the primary cost burdens which have driven the overall discussion on a general incentivization mechanism for relayers.

Initially, a simple proposal was created to incentivize relaying on ICS20 token transfers on the destination chain. However, the proposal was specific to ICS20 token transfers and would have to be reimplemented in this format on every other IBC application module — including, but not limited to, Interchain Accounts, Interchain NFT transfers, and Interchain Query transactions. After much discussion, the proposal was expanded to a more general fee payment design that can be adopted by any ICS application protocol as middleware, and the first testable beta version of this middleware implementation has been released!

This blogpost seeks to illustrate how ICS29 fee payments will function for IBC channels. Chains that wish to integrate fee payments to incentivise relayers will need to upgrade their ibc-go versions to a version which includes the new middleware module, and set up the corresponding escrow module which handles the storing of fees to be paid out to relayers. Furthermore, v1 of fee payments middleware will only support incentivisation of new channels. The upcoming channel upgradeability feature slated for Q3 2022 will, however, enable incentivisation of all existing channels and will ensure a simple, in-protocol mechanism for operators to be rewarded for their work ensuring Interchain liveness.

Fee Payments Part 1: Registering the Relayer Operator Address (automated)

ICS29 fee payments are built on the assumption that sender chains are the source of incentives — the chain that sends the packets is the same chain that pays out fees to operators. However, for those familiar with the IBC packet flow, this may raise an immediate question.

The IBC packet flow (eg: for token transfers from chain A to chain B) has three transactions: first, a relayer operator must listen for the SendTransfer event. When this event is emitted, the operator (chain A) will then submit a RecvPacket transaction to chain B along with proof that the transaction was, in fact, committed on chain A. After chain B has registered the RecvPacket transaction, it returns an Acknowledgement which the relayer must submit to chain A. If chain B does not send back an Acknowledgement of packet receipt within the allotted timeout time frame, the relayer will submit a Timeout packet instead to chain A. While the latter two transactions are submitted to chain A, and therefore are easily incentivized through fee disbursement to the operator address on chain A, the first transaction occurs on chain B, and therefore the relayer address which has submitted this transaction on chain B is not accessible to a chain A fee disbursement.

ICS29 addresses this concern by allowing the relayer to register its counterparty address on chain B in the address registry provided. This registration is required before fees can be disbursed for the first transaction in the packet flow, however, the registration will be automated as part of the initial relayer startup flow from the configuration files. As the relayer paying for the RecvPacket transaction and the relayer paying for the Acknowledgement/Timeout packets could be different operators, this step allows for the accurate incentivisation of each operator who has participated in each step of the packet lifecycle.

After a transaction has been submitted, a lookup is performed and the registered address on chain A (associated with the signing address of the operator who initially submitted the RecvPacket transaction to chain B) will be sent back with the Acknowledgement. Then, when the full packet life cycle is complete — either through Acknowledgment or through Timeout — the registered address will be compensated with chain A fees.

Fee Payments Part 2: Escrowing the fee

Fees paid to operator addresses associated with IBC transactions are submitted in MsgPayPacketFee. This fee message contains fees which will be paid out for RecvPackets, Acknowledgements, and Timeouts. In the case of a successful transaction, RecvFee and AckFee will be paid out to the relayer address which has submitted the packet, and TimeoutFee will be reimbursed to the paying account. In cases of timeout transactions, AckFee will be reimbursed. This can be accomplished either synchronously with a MultiMsg transaction to incentivize the packet contained in the message:

or asynchronously where multiple parties incentivize a packet:

Escrowing of the fee associated with a packet can be carried out by any party because ICS29 does not dictate a certain fee payer. In fact, chains can choose to simply not expose this fee payment to end users at all and rely on a different module account or even the community pool as the source of relayer incentives.

Fee Payments Part 3: Incentivized RecvPacket, Acknowledgement, and Timeouts

A successfully incentivized packet life cycle will look as follows:

Note, although all three fees are contained in one Fee message, each fee is recorded individually such that the paying account could incentivize RecvPackets differently than Acknowledgements, or Timeouts.

Fee Payments Part 4: Profit!

As we have learned in this blogpost, relayer infrastructure is critical to securing IBC ecosystem liveness, and we will release a series of posts detailing this relayer landscape shortly. Along these lines, we firmly believe that the ICS29 in-protocol incentivization feature is a foundational necessity for scaling the Interchain dream, though we also acknowledge that in-protocol incentivisation does not need to be the only source of relayer monetary incentives (for example, off-chain mechanisms such as foundation delegation to validators also running relayers, or service work agreements signed between operators and chain teams currently form the bulk of compensation for relayers).

As the Interchain continues to flourish and grow, it will only become more and more necessary to ensure that the relayers critical to its liveness have access to the same kind of monetary incentives currently driving the validators critical to its security. We look forward to the first integrations of fee payments for relayers and welcome any ensuing feedback!

For more information, join the Discord.

About the author:

Charly Fei works at Interchain GmBH and is the Product Lead of IBC (the Inter-blockchain protocol). Follow Charly on Twitter: @charleenfei

If you’re a chain developer looking to build your custom IBC light client, and have any questions, comments or feedback on the above, feel free to reach out to us here.