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

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.…

Excerpt (1198 of 2754 characters). Read the whole post on the forum ↗

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…

Excerpt (1195 of 1481 characters). Read the whole post on the forum ↗

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

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.…

Excerpt (1194 of 3602 characters). Read the whole post on the forum ↗

Tricky | Cosmos Spaces:

• 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.

I’ll share my thoughts and try to address the questions raised - • 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. • 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…

Excerpt (1197 of 2637 characters). Read the whole post on the forum ↗

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…

Excerpt (1196 of 1225 characters). Read the whole post on the forum ↗

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

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!

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.