[on-chain proposal] - Cosmos Hub IBC relayer gas cost restitution plan - FeeGrants

[Ertemann]

@waqarmmirza

but are we setting that aside for human and tech resources?

Yes we could see that as an incentivisation to run the required infrastructure and provide support, it
doesnt come close to covering fees at the current gas price.

[Ertemann]

@Flo

Only funding a self declared subset is market distortion

ALL relayers are welcome to apply, we do NOT expect to hinder anyone from obtaining the feegrant.

The requirements will be low and are only to ensure no extremely malicious behaviour takes place.

Anyone with 500Txs a month already can be fast-tracked to ensure a fast and smooth rollout.

[waqarmmirza]

We are doing experiments with millions of Atoms each year, and I think this is a very reasonable ask for a public good.

[Flo]

Thank you thats great. Looking forward to see how we can apply.

[ArchitectNodes]

It’s an interesting problem to solve but I can see some similarities to incentivizing validators. Let’s say there was no mechanism for validators to get a portion of rewards, no one will be running validator as a business. To solve that, there is an option for validators to get a percentage of rewards allocated based on their total delegation. Whatever rewards delegators get, validator gets a configurable percentage of that as fee. If validator feels that their percentage of rewards is not worth running a validator, they have the option to shut down.

We need something similar for relayers too. Now i know devil is in the details, however relayer incentivization also needs to be transparent to relayer operators. We need a way to pass on a portion of relayer fees (or a small portion of inflation or a portion of dedicated pool for relayers paid out per transaction or ???) to relayers so it becomes self sustainable. I am not suggesting what exactly contributes to relayer incentivization, just making a point that mechanism needs to be automated and meaningful without requiring every chain to have a different solution or significant impacts to all chains and front ends.

Just sharing my $.02

Cheers,
Architect

[Syed]

Agree - users should pay their own fees, which Fee Middleware will partly fix, when it gets adopted post-Channel Upgrability release (+ some time for all chain pairs to upgrade, etc etc)

I personally am for this prop, with the understanding that this is just a short-term, stop gap measure. This arrangement should last longer than ~6months (I know this prop is for 3ish months, but I don’t think that will be enough time for Fee Middleware to become available on every chain)

With regards to “any plan from informal” - the question is better suited to @AdiSeredinschi or @jtremback from Informal
(I’m not from Informal )

[Syed]

And just want to add - the relayers are ONLY asking for fee reimbursement - not profit, time/labour or infra costs - a very chad move.

Hub’s vals & relayers are the best!

[AdiSeredinschi]

@luisqa

@Syed is there any plan from informal to address this effectively?

On Informal side, we have put significant effort into ICS29 specs, implementation, and adoption. Hermes relayer has been ready for use with relayer fees and we ensured UX is smooth for relayer operators wanting to use it: Hermes has telemetry support for fees, a few CLIs to interact with the fee middleware, and support to automatically register the counterparty payee on the destination chain, and operators can also filter packet relaying by incentivization.

This is with the understanding that ICS29 is not a solution to all problems.

Beyond ICS29, there was not much progress since we could not land on a problem statement that would be appropriate from a public goods perspective: What makes sense for Osmosis would not make sense for Hub or other chains, or it doesn’t make sense for relayer operators.

Put differently, what is the problem to solve exactly? DEXes/DeFi app-chains need relaying to be free for users and seamless to attract activity; relayer operator want relaying to be sustainable (i.e., include fees/revenues); end-users need relaying to be transparent and non-fragmented. Agreeing on the problem statement would be a great first start, but it’s not clear to me which one is it.

[Ertemann]

Last Call

Please provide additional feedback or mention your name to be on the multisig, if not we will make the multisig with people from the proposal.

[Ertemann]

We will go on-chain later today with the following onboarding requirements and multisig participants:

Onboarding requirements

1. Be a relayer on the hub and relay on channels to active and important counterparty chains**

• stride
• neutron
• osmosis
• kujira
• crescent
• persistence
• juno
• secret
• evmos
• quicksilver
• injective
• kava
• archway
• comdex
• umee
• lum network
• akash
• noble
• axelar
• gravity bridge

2. Have > 10 IBC txs relayed for any of the channels connected to the listed chains in the past 30 days. For the baseline we use Map of zones
3. The multisig will re-evaluate the Chains and thereby the grantees on a monthly basis
4. Operation is allowed with the following relayer softwares: ts-relayer, go-relayer (RLY), rust-relayer (Hermes)
5. relayer must set batch_delay / polling frequency of at least 500ms or more

• block time / batch delay = ~5s / 0.5s => max 10 txs per block per account
• if any account posts more than 10 txs into one block: misbehaviour

6. packet efficiency > 10%
7. Multiple wallets per entity are eligible > every account that is eligible within the outlined criteria

**relaying to other chains using the feegrant is allowed as well, its merely for qualification

Onboarding steps

1. Apply via Github PR & provide relayer account address
2. Automation checks eligibility
3. Multisig confirms - Sends fee-grant message
4. Review of eligibility on a monthly basis

A tier system will be followed for the total daily budget:

• Low tier - 5 ATOM daily spend limit

• High tier (top 10 accounts by effected packets confirmed) - 50 ATOM daily spend limit

The oversight committee (multisig members) reserves the right to evaluate and revoke whitelistings on a daily basis. Furthermore, the oversight committee has the right to evaluate and update the onboarding parameters if needed. Reasons for revocation include but are not restricted to: spamming (unnecessary or unnatural transactions), misbehavior against onboarding criteria (batch delay, efficiency), use of feegrants for non-IBC related messages, making use of misconfiguration by mistake of the multisig.

Analytics and multisig

Clemens from CryptoCrew has created a repository for the relayer-dao (GitHub - clemensgg/ibc-relayer-dao) and has setup analytics and automation to help the multisig operate the feegrants.

Functions include:

• monitoring of feegrant state (prom exporter + grafana)
• relayer efficiency metrics (indexer + prom exporter + grafana)
• PR checking for onboarding

The oversight committee consists of:

Clemens (CryptoCrew): cosmos1705swa2kgn9pvancafzl254f63a3jda9ngdnc7

Ghazni (StakeCito): cosmos1qm5agp78atuf9pyalsq4w30mzc3lxtj0vgq2qe

luisqa (Interbloc): cosmos1ze09kc5ackut7wc4pf38lysu45kfz3ms86w3em

tricky (CosmosSpaces): cosmos1a8x3fn37gjnglcr25fsfyr6c5m4ed5euwvae2n

Ertemann (Lavender.Five Nodes): cosmos1xfl6qve3plepgk7wlgxypem5ngntavrnkng3vz

Multisig address - cosmos14r8ff03jkyac2fukjtfrfgaj8ehjlhds5ec2zp

[jacksteroo]

This is a fine stop gap solution for the short term.

We still need to figure out the long term solution for this as its the crux of the Cosmos IBC philosophy

[ladyrenny]

Sounds fucking amazing

[Anggriyani_Ani]

Agree - users should pay their own fees, which Fee Middleware will partly fix, when it gets adopted post-Channel Upgrability release (+ some time for all chain pairs to upgrade, etc etc)

I personally am for this prop, with the understanding that this is just a short-term, stop gap measure. This arrangement should last longer than ~6months (I know this prop is for 3ish months, but I don’t think that will be enough time for Fee Middleware to become available on every chain)

[Eftal_Oncan]

Please provide additional feedback or mention your name to be on the multisig, if not we will make the multisig with people from the proposal.

[yogi_barutu]

Agreed - we need a tech solution - and we have it already, aka Fee Middleware. With that, costs for relaying can be baked into the tx fees we pay - part going to validators on each chain for validating the tx, part going to relayers in each chain for both costs of relaying, and maybe even a profit percentage.

It’s just that current IBC channels can’t be upgraded to include that feature yet.

So yeh, this Fee Grant isn’t a clean or ideal solution, but it’s the best short term fix till Fee Middleware is deployed everywhere (soon?)

[coolqas]

I support this idea.

Validators and Relayers should be rewarded as much as they work for sustainable network. I think it’s OK to pay a little bit too much for them not only gas-fee. But as it’s written in Q&A and others says, basically users should pay that money. So I want to know what and when solution will come next. ICS-29? Self-relaying?(I don’t know what it it and even non dev ppl like me can do it.). Or this is just short term solution while team are discussing about it.

[Yang_Tao]

@anilCSE

Let’s do this. Witval will support the proposal

Let’s do this. Witval will support the proposal

[CemGym]

We still need to figure out the long term solution for this as its the crux of the Cosmos IBC philosophy

[ramafadillah]

Basically IBC is the backbone of this will be a great foundation, can’t wait for great things with Namada

[far]

@Ertemann

**We are seeking 3 community representatives to join the multisig along with 2 relayer representatives. Please reach out to @Ertemann on Telegram if you are interested in participating or indicate so in this forum post! - There will be no compensation for this role or any role performed by the proposers for that matter.

I fully support this proposal, but I don’t know if the applications are full and how can I join?