[ATOM Accelerator] IBC relaying operations: designing a long term solution while positioning ATOM

[Youssef]

Hey everyone,

Happy to see a large support so far on prop 862 to urgently fund the operators following a spike in gas fees. I am opening a discussion here on the topic of IBC relayer’s operation issues brought up in the following topic by @Ertemann

This discussion is not a duplicate of the IBC relayer gas cost restitution plan but rather an attempt at exploring how we can design long term solutions for this critical piece of the IBC ecosystem and how AADAO specifically can help achieve the desired outcomes.

I’m personally very interested in knowing more about the operational challenges IBC relayers are facing in the day to day and how AADAO could potentially help in that context, either by simply providing a direct financial help (like we did with the ICS testnet group) or by funding an initiative that will fix the issue at its core, making IBC relaying sustainable (and why not attractive for operators) in the longer run.

I also believe there is probably a world in which we could make IBC relaying both sustainable and aligned-value accretive for ATOM. Carter has shared some initial thoughts on how ATOM could benefit from a strong positioning at the relayer infra level.

My summarized understanding of how IBC relaying currently works in Cosmos

Relayer operations in the Interchain involve transmitting data between different blockchains using IBC. Relayers listen for packets on one blockchain and post verifications for those packets on another. They are essential for trust-minimized asset and message transfers between networks. Currently, relayers pay the gas fees for these transactions, often operating at a loss as a public service to the interchain. ATOM’s integration into this system is primarily as the transaction fee currency on the Cosmos Hub, which relayers use to pay for the gas fees incurred during relaying operations.

I’ve done some preliminary research and I am introducing here a few suggestions (apologies if they have already been suggested on the other topic)

Some long-term solutions

• Integrate relayer costs into transaction fees: Implement a system where a portion of transaction fees directly compensates relayers. This creates a self-sustaining model where relayers are funded by the transactions they facilitate.
• Develop a Relayer Reward Mechanism with ATOM: Establish a reward system where relayers earn ATOM for their operations. This incentivizes the use of ATOM and integrates it deeply into the relaying process.
• Promote exclusive use of ATOM in IBC relaying: Encourage agreements within Cosmos that prioritize or exclusively use ATOM for relaying fees and operations.

Also super happy to do a working session with a few relayers to explore how we can move forward.

[vixcontango]

Agree with all 3. ATOM as the most liquid asset on the interchain being used for relayer fees would actually lower the costs for IBC relayers. Using smaller currencies introduces friction since the relayers ultimately want to convert those to fiat to pay their electricity and equipment bills. The spreads of smaller, no name tokens to fiat are far larger and as such IBC relayers would incur bigger operational losses and be more unprofitable simply from the currency exchange operations. They probably don’t think about that but that is what is happening. As such ATOM should be default currency used for IBC relaying and people need to specifically override that setting. If the IBC channel is to the Cosmos Hub, then ATOM should be the mandatory unit used.

I just want to mention that at the merchant bank at Goldman I had to write a few apps specifically dealing with cost reduction stemming from currency exchange (hedging, etc). People often don’t realize how much money is being wasted on currency exchange. Especially as the numbers get larger. We didn’t just hedge the overall portfolio’s currency exposure (which was rather large) but also the monthly dividends and earnings we were getting and we went as far as helping the portfolio companies with their currency exchange operations because FX vol would be hitting their earnings and revenue numbers as well. Bringing IBC relaying fees back into ATOM would help the relayers tremendously, in ways they don’t realize.

[Guinch_Roze]

agree with all 3.
Need to choose the best of them

[Tricky]

Thanks for continuing the discussion on this topic @Youssef. It is good to see the community has acknowledged this challenge and is now working towards solutions.

There definitely needs to be some sort of reward/incentive mechanism for relayers. At the moment, relayers are subsidizing the IBC protocol and the interconnectivity for both users and developers. We have gotten to a point where this is no longer sustainable, and we need some sort of economic model to make this viable in the long term with a short term stop gap as well.

ICS-29 hopefully becomes a reality in the short term, but that is something that has taken so long and still has so much work to be properly implemented that we cannot count on that yet. When it does come to fruition, I really hope the IBC team recognizes the need for an economic model and not just think this should be free forever. Other teams are already starting to monetize IBC for themselves because they see the PMF and how much the market values bridging solutions. The fee should be similar to what Noble charges, and where possible give preference to the selected token of the relayer. The fee abstraction module could help with this as well. Tagging @susevans & @AdiSeredinschi for this one.

If there is proper alignment, relayers as a majority could decide to make ATOM their preferred fee token for relaying to help further the mission of ATOM as interchain money. The fee abstraction module, ICS-29, and future SDK releases should make this effort reasonable and not require such a heavy lift.

Ideally, we level up the Relayer DAO that is being formed through prop 862 for the temporary solution Hub’s relaying. The DAO can enter negotiations with chains/teams beyond relaying like with public RPCs, archive nodes, and any other demanded infra. We then coordinate a reward structure for top providers. Chains have access to a wealth of experienced operators, and operators have the ability to be rewarded for the contributions. It is important to balance support for the top providers while still allowing for smaller operators and new entrants to contribute to the ecosystem. Making sure this is still economically viable for operators is a major factor in how the final structure would play out.

In reference to Carter’s post, making sure our roads, waterways, and airports are top notch is in the interest of ATOM as interchain money. The Hub has a chance to play a crucial role in shaping the future of IBC relaying.

Some questions we need to answer:

1. Wen ICS-29 & channel upgradability? Will ICS-29 deliver on the needs of relayers?

2. How can we develop a sustainable relayer model without having to always require additional capital from CPs or grant programs?

3. Can we incentivize validators to opt-in to an ATOM based relaying system when those features become available? Would this benefit the Hub?

4. What features are coming in the next SDK releases that can make this easier? Can we coordinate with SDK & IBC teams on this solution?

5. How do we decide on the reward structure criteria? How do we balance operator efficiency, with the needs of the user and developers?

Overall, we are happy to contribute wherever we can to find a solution and continuing relaying throughout the ecosystem knowing there are solutions being worked on. We definitely need some working sessions with relayers, the IBC team, and the SDK team to get a clear picture of what options we have. No sense in us all working in silos when we can pool our efforts together to make sure we have a wholesome and well thought out solution.

[AdiSeredinschi]

@Tricky

• Wen ICS-29 & channel upgradability? Will ICS-29 deliver on the needs of relayers?

This is already available and being piloted by several networks. @susevans might have concrete numbers. There was an announcements of the upgradability module here that the Interchain team provided: Channel Upgradability and Fee Middleware: A Closer Look at Relayer Costs and Incentivisation | by IBC Protocol | The Interchain Foundation | Medium

As for relayer-side support for ICS-29, it’s ready. I detailed some of the status of efforts from the Hermes team here. Upgradeability support is not fully ready yet.

I would not consider ICS-29 as the end-state for relayer needs, however.

Very much in favor of creating a working group to tackle this issue holistically, centered on the $Atom’s interests.

[susevans]

I’ll share my thoughts and try to address the questions raised -

1. As Adi said ICS-29 is ready but channel upgradability will be in ibc-go v8.1.0 which will be released in January 2024, but there is a delay between when we make a release and chains upgrade to the latest versions of the sdk and ibc so I think the earliest we would see this on mainnet on a chain would be towards end of Q1.

2. If the view of a sustainable model is to not use grants or the CP, then its ultimately users that would need to fund relayers. The challenge this poses is then how do you know how much is going to cover transaction fees and a contribution to infrastructure costs given you need to cover gas costs on 2 chains and likely the tip isn’t going to be in the same token used for gas on the receiving chain. I think even with the rollout of ICS-29, I don’t think at first the tips will cover all the costs for relayers, I think likely it will start as a user subsidy because specifying that tips should be added and are a small increase in what users are already paying in initiating an IBC transaction would be a smaller degradation to UX compared to suddenly paying perhaps 3x what was previously paid by an end user in fees. Over time I could see the fees increasing as more channels become incentivised and users are getting accustomed to the additional fees.

3. With ics-29 a relayer can choose to not relay packets if the fee isn’t a certain amount, or they could choose not to if the fee wasn’t in a certain token. I don’t personally agree that users should be forced to pay in ATOM and for this to make sense I think you would need chains to accept ATOM as a gas token as well

4. I understand that the skip team have been working on UX improvements around fees with the SDK team, tagging @hxrts who will have more context

5. I think this is the crux of the problem:

How do we balance operator efficiency, with the needs of the user and developers?

End users have been blessed with free IBC but it is clear it is not a sustainable model. At the same time, chains are concerned about how users respond to having additional fees placed upon them and chains don’t want to put themselves in a detrimental position by charging additional fees - basically no one wants to compromise the current ux. As the transfer channel between the hub and osmosis is the most active and already experiencing some relayer related issues, I think a more sustainable fee model should be trialed there first and I think this should be done incrementally with an initial ics-29 rollout adding a small user paid subsidy to their packet delivery.

[jack]

This is a great topic @Youssef thanks for opening it. I will start by saying that the reason that ICS-29 hasn’t seen significant adoption is that it misunderstands the fundamental structure of Cosmos and IBC in general. It is also a solution researched and developed years ago for the world of years ago. It is not tractable in the current world of IBC.

The cosmos thesis promotes app chains and applications running across the broader IBC. The role of the relayer is permissionless and can be completed by anyone, including the end user themselves. These two features point to an obvious coincidence of wants. Applications want users and are willing to pay their IBC fees in order to bring the users to their platforms. This solves the complexity of fees for the end user (they aren’t exposed to the boundaries between chains and comfortably use the IBC network as a coherent whole) and also solves a problem for applications (makes for much better user experience).

This indicates that the best solution here is an on chain marketplace where these transactions could happen which would provide obvious economic benefits for atom holders. It would also help solidify the place of ATOM as the center and birthplace of IBC

[Tesla369]

Im agree with all of those 3 long term solution.
The first option are probably the best one out of the 3.

[ccclaimens]

Thank you @Youssef for your post, it is great to see the AADAO coming forward with this initiative!

Similar to @AdiSeredinschi we think that ICS-29 will probably not be the end-state of relayer incentivization mechanisms in IBC, mainly due to the facts that @jack stated. It’s very good that we’re having this discussion by the way, we’d like to thank everybody for the provided information and context.

Until a fully-working on-chain relayer marketplace has been established we are of the opinion that ecosystems should secure relationships with professional service providers to ensure enhanced service quality at any given time.

CryptoCrew will be happy to contribute our expertise and experience to an eventual working group!

[hxrts]

Just responding to @susevans’s comment. I’ve been working with the Binary team on a fee abstraction mechanism, which would complement the Osmosis fee abstraction module to pay for fees in different scenarios, whether fee tokens reside on another IBC-enabled chain or locally. The module should be available alongside the 0.51 Cosmos SDK release, so it may be a little while before it lands on the hub.