Moving Relayer Incentives On-Chain: Fee Middleware, Fee Grant and Budget Modules

Relayers are the heartbeat of Inter-Blockchain Communication (IBC). They ensure liveness of the protocol by performing the key function of ferrying packets from point A to B. Given their importance within the IBC domain, it is necessary to effectively incentivize relayer operators to adequately scale the Interchain.

Until now, teams running validator setups have had altruistic and/or strategic reasons to maintain relayer infrastructure. Today, a majority of relayers are those validating on the chains between which they relay packets. Team (stake) delegations, grants, and direct funding from chains or community pools are a significant portion of how relayer operations are currently funded.

At a stage when IBC volume increases by an order of magnitude or more, these existing methods alone will not suffice to adequately fund relayers. Similarly, off-chain negotiations do not scale well as the number of channels increase and more relayers enter the ecosystem. Therefore, while the current processes have been viable in the short-term, they are not sustainable.

This piece is intended to shed light on three alternative on-chain mechanisms that could serve as long-term solutions to incentivize relayers. Later on in the discussion, we provide an overview of the advantages and disadvantages associated with these mechanisms.

On-chain relayer incentivisation methods

1. General Relayer Incentivisation Mechanism (fee middleware module)

The Interchain Standard (ICS) 29 General Relayer Incentivisation Mechanism (herein referred to as the “fee middleware” or “fee module”) is an IBC application-level standard that specifies a design which can be implemented as middleware by any application module. It serves to incentivize relayers on a per-channel basis.

The fee middleware specifies all information regarding fee distribution on the source chain. Given two chains, A and B, the fee middleware functionality for a packet flow works as follows:

1. Relayer A registers their destination address to source address mapping on the destination chain’s fee middleware.
2. A user submits a send packet on the source chain, along with a message to the fee middleware module with some tokens and fee information on how to distribute them. The user can indicate the amount to be paid out for 3 separate fees: ReceiveFee, AckFee, and TimeoutFee. The fee tokens are all escrowed by the fee module.
3. Relayer A submits MsgRecvPacket on the destination chain.
4. Destination fee middleware will retrieve the source address for the given relayer’s destination address (according to the mapping registered in step 1) and include it in the acknowledgement.
5. Relayer B submits MsgAcknowledgePacket which provides the reverse. relayer address on the source chain, along with the source address of the forward relayer embedded in the acknowledgement.
6. Fee middleware on the source chain can distribute the tokens escrowed in step 2 to both forward and reverse relayers, as well as refund remaining tokens to the original fee payer(s).

For simplicity, packet flow in the case of timeouts is not shown here. To learn more about this, and for an in-depth explanation of how the fee middleware works, refer to this blog post.

The fee middleware module v1 was included in the recent ibc-go v4.0.0 release and can be opted into by new channels. With the release of channel upgradability, the middleware can be implemented on existing channels as well.

2. Fee grant module

Fee grant is a Cosmos SDK module that allows an account (the granter) to provide an allowance for gas fees to another account (the grantee).

The module can be instantiated to specify the maximum allowance amount, time of allowance expiry, periodic intervals to refill the allowance, and may even be specified in such a way that the funds can only be used for certain types of message execution.

For end-users, creating a new wallet and funding it with tokens for gas fees can be cumbersome and/or a barrier to entry on certain platforms. This is the primary issue that the fee grant module fixes.

OmniFlix is a great example of the fee grant module being used in the wild. The chain utilizes the module to pay gas fees incurred by new users as well as to cover the on-chain fees paid by relayers. Even though their native token was not yet issued, the use of the fee grant module allowed OmniFlix to launch their product.

3. Budget module

The budget module, which is made available in the Cosmos SDK, can be implemented through governance, which allows for inflationary rewards and gas fees to be distributed from a source to a destination address.

The budget amount, source address, and destination address(es) can be specified as governance parameters. The amount can be dispersed on a block-by-block basis (or with any other time interval agreed upon through governance).

What are the pros and cons of these methods?

Fee Middleware/Module — Pros

1. Scalable and Sustainable

The fee middleware was developed with the specific goals of scalability and sustainability in mind.

It removes the need for an off-chain entity to manually keep track of relayer activity and fund them accordingly (or any other form of off-chain funding mechanisms). The fee module can be opted into by any application wishing to incentivize its relayers, and they are funded on-chain in accordance with the exact number of packets relayed.

Chains choosing to adopt the fee module can decide whether end-users or the chain itself must bear the costs of packet relay.

A scenario where end-users pay the fees creates a fundamentally sustainable system, where the incentives coordinate public goods and value distribution is aligned with value creation. This would also require front end applications and wallets to integrate the fee middleware in order for an end-user to indicate their fee preferences. Alternatively, the chains themselves can choose to fund relayers, either directly or via community pools and other altruistic mechanisms, thereby bootstrapping IBC volume by attracting more users onto their platforms.

What is important to note is that the fee middleware was designed to be as general as possible, without being opinionated on who bears the costs of funding relayers. Chains that implement the middleware might choose different methods for this purpose. Hence developers have a high degree of flexibility with respect to customizing the module. This leads us to the next point.

2. Flexibility

While the fee middleware creates a standardized interface for all applications choosing to implement the module, the fee handling logic itself can be customized. This can be implemented as an IBC Middleware (ICS-30), which acts as an intermediary between the application module and the transport layer (core IBC) to execute custom logic.

By using the IBC middleware (ICS-30) to design the custom fee handling/distribution logic, the fee module (ICS-29) can be plugged into the IBC packet flow design without having to place its code either within core IBC or in the application module.

3. Granularity

Yet another benefit of using the fee middleware is the granularity it offers. Incentivisation on a per-channel basis is made possible using this module. For example, the channel for token transfers between any two zones can be incentivized without incentivising the ICA channels. Alternatively, it can be used to encourage relaying on channels with the least amount of packets relayed.

4. Permissionless

Unlike the fee grant and budget modules, funding relayer operators using the fee middleware is entirely permissionless. Once a channel is incentivized, any relayer ferrying packets to or from said channel is funded on a per-packet basis. There is no need to whitelist a set of relayers.

5. Transparency for relayers

The fee middleware exposes the following queries: GetReceiveFee, GetAckFee, and GetTimeoutFee. Relayers can call these functions in order to know their expected fee on relaying a RecvPacket, AcknowledgePacket, and TimeoutPacket respectively.

This could potentially create an interesting dynamic where relayers (by customizing their own software implementations) choose to prioritize the relaying of certain packets over others depending on the expected fees. A natural fee market for IBC relaying could emerge as a result.

6. Coverage of full packet flow

With the use of fee middleware both sides of a channel can be incentivized, even though the disbursement of fees is performed on the source chain. This is in contrast to the fee grant or budget modules, which can only incentivize packets that are being sent to the source chain.

Fee Middleware/Module — Cons

1. Channel upgradability

Currently the fee middleware can only be implemented for new IBC channels. Therefore tokens sent over a new incentivized channel will be non-fungible with the same tokens sent over the existing non-incentivized channels. This leads to liquidity fragmentation and loss of network effects accumulated on already existing channels. However, with the release of channel upgradability existing channels can also be incentivized (slated for 2022 Q4).

2. Requires an update on both chains

In order for a channel to be incentivized, both ends of the channel need to be upgraded (however, only one side needs to provide incentives since all fee handling logic is performed on the source chain).

3. Revenue accrual to the fastest relayers

For a channel incentivized using the fee middleware, only those relayers that successfully deliver packets are funded. Those that don’t receive no payments, despite being online.

This creates a situation where the fastest relayers (typically those with the best equipment and geographical advantage) accrue most of the revenue. This has been the primary reason why off-chain methods of funding have been proposed as a better alternative. However, these too succumb to the same centralization issues given the social dynamics that come into play. Additionally, scaling off-chain negotiations becomes cumbersome as the number of zones increase and more channels are opened.

Sidenote: a potential solution to the problem of revenue accruing to the fastest relayer(s) is to implement a voting mechanism by which a small subset of relayers are selected at specified time intervals to deliver packets on a certain channel. By alternating between different subsets on a consistent basis every relayer gets a chance to send packets.

Fee grant module — Pros

1. Flexibility

Using the fee grant module offers the granter a high degree of flexibility and customizability in the following ways:

• A grant can be set to a maximum amount for a certain time period
• A grant can be filled up according to specified time intervals
• A grant can be set as an unlimited allowance without an expiry date
• A grant can be instantiated to be applicable for certain message types

Perhaps the most important advantage of using the fee grant module is that it considerably streamlines the UX. Therefore, in terms of flexibility, not only can it be used to incentivize relayers, but also to pay for gas fees incurred by end-users. As we saw with the example of OmniFlix, this goes a long way with respect to onboarding new users to your platform.

2. Ease of implementation

As opposed to the fee middleware, the fee grant module only needs to be implemented on one side of the channel in order to fund relayers (however, in this situation it would only be possible to incentivize packets being relayed to the chain on which the module is implemented).

3. Control

A key feature of the fee grant module is that the funds used for the allowance remain under the control of the granter at all times. This provides strong security guarantees for the granter.

4. UX

With the use of fee grant module, users of IBC would not need to concern themselves with paying a fee for relayers.

Having as few user interactions with IBC-level interfaces helps in abstracting away the concept of IBC. This improves the level of composability and UX.

Fee grant module — Cons

1. Manual processes

Even though the fee grant module does provide the option of creating an unlimited allowance amount that never expires, there can be scenarios where this design is ill-suited.

Instead, in some situations the granter might want to set an upper limit in terms of the allowance granted, along with a grant expiry date. In such cases, it could be a manual process to refill the allowance every time it gets depleted.

2. Only reimburses on-chain costs

Costs associated with relayer operations include the on-chain costs of relaying packets, as well as the operational costs of maintaining node infrastructure. Using the fee grant module only reimburses the on-chain costs. No additional incentives can be provided using this module.

3. Permissioned

Since a chain using the fee grant module specifies which relayers are funded for their operations, it creates a permissioned system where only whitelisted relayers receive payments.

Budget module — Pros

1. Flexibility

The budget module offers a fair degree of flexibility. Anyone can create a governance proposal to allocate funds from a source to a destination address. The time intervals to allocate the funds can be specified as part of governance.

Once the proposal is voted on and passed, the budget plan is automatically set to work as specified.

2. No direct economic impact on end-users

Given that end-users don’t pay transaction costs for packet relay, this method creates no direct impact on them. Similar to the fee grant module, this helps to abstract away the concept of IBC.

Nevertheless, costs will be imposed on the end-user in an indirect form, as their yield on staking gets reduced.

Budget module — Cons

1. Limited in terms of scalability and sustainability

Block rewards and transaction fees are revenue sources for a chain. Using these funds to incentivize relayers is effectively a form of indirect tax on validators (as well as users). Also inflation schedules on most chains taper off with time, with some chains having no inflation after a certain point.

Therefore, whether or not this method is sustainable in the long term becomes questionable. It remains to be quantified whether transaction fees alone will suffice to fund relayer operations, especially when IBC usage increases by an order of magnitude or two.

2. Alterations to the budget plan can be a slow process

Given that a budget plan is executed via governance, it can be a relatively slow-moving process to implement new parameters or to alter existing ones.

Trade-off summary

Conclusion

Comprehensive solutions to incentivize relayers are important for IBC’s long-term growth. The fee middleware, fee grant, and budget modules offer three different ways to achieve this, with each module having its own tradeoffs. Different chains have the option to implement one or a hybrid of these options.

The goal is to create a sustainable revenue model for relayers in return for the vital services they perform. On-chain incentivisation schemes that lead to profitable (or, at the very least, break-even) relayer operations are beneficial to the overall ecosystem, and help further the Interchain vision.

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.

About the Author:

Adi Ravi Raj works at Interchain GmbH and is the Protocol Analyst for the IBC team.

Shoutout to Charly Fei, Susannah Evans, Thomas Dekeyser, and Carlos Rodriguez for the feedback and review.