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.
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.
We are doing experiments with millions of Atoms each year, and I think this is a very reasonable ask for a public good.
Thank you thats great. Looking forward to see how we can apply.
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
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 )
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!
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.
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.
We will go on-chain later today with the following onboarding requirements and multisig participants:
Onboarding requirements
- 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
- 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
- The multisig will re-evaluate the Chains and thereby the grantees on a monthly basis
- Operation is allowed with the following relayer softwares: ts-relayer, go-relayer (RLY), rust-relayer (Hermes)
- 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
- packet efficiency > 10%
- 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
- Apply via Github PR & provide relayer account address
- Automation checks eligibility
- Multisig confirms - Sends fee-grant message
- 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
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
Sounds fucking amazing
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)
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.
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?)
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.
Letâs do this. Witval will support the proposal
We still need to figure out the long term solution for this as its the crux of the Cosmos IBC philosophy
Basically IBC is the backbone of this will be a great foundation, canât wait for great things with Namada
I fully support this proposal, but I donât know if the applications are full and how can I join?