Thank you for the thoughtful write up, whilst I agree that the current approach to funding relayers with off-chain agreements and delegations is unsustainable, my main concern with the proposal is as you highlighted:
This proposal will most likely remove some of this competition and “free market” principles for relayer operators, that is something voters should take into consideration for better or worse.
Relayers ensure liveness of the network and timely packet delivery. Putting certain relayers in a privileged position to have their relaying fees funded whereas other relayers would not be subsidised does not seem like the ideal solution and seems somewhat unfair. I understand that you would want to avoid subsidising malicious transactions that are simply to drain the allocated amount for the feegrant but it would be good to clarify in more detail the criteria for being eligible for the feegrant. I think it is reasonable to look at the existing relayers in the past 3 months and already sign up all of those to be eligible within the 500 message criteria, without requiring them to manually sign up.
Additionally feegrant only covers costs on one chain and not for an entire packet lifecycle between source and destination which I also think is a big drawback. For those interested, here is an article detailing some of the trade-offs between different on-chain relayer funding approaches - Moving Relayer Incentives On-Chain: Fee Middleware, Fee Grant and Budget Modules | by IBC Protocol | The Interchain Foundation | Medium
However, I think all of this is ultimately a short term solution and agree that using ICS29 in the medium term makes more sense.
I wanted to address some of your comments on ICS29 in the proposal:
Why are relayers not pushing ICS-29? That should pay them pro-rata.
ICS-29, also known as “relayer-fee-middleware” aims to charge users for IBC transaction fees. In its current design, ICS-29 hasn’t gotten much adoption for a number of reasons. It is subject to MEV by validators misbehaving and it puts a too significant effort on the # of packets transferred and not the quality of service. It will cause a race to the bottom for relayers to the point where users pay more but relayers still don’t make a profit. Furthermore, currently only new channels can use this feature (as channel upgradeability is yet to be completed), which means that ISC-29 is no viable option for now. We would love to see this change in the future.
I don’t have data on actual usage and assume it is not actively added to any channels yet, but there are 25 / 107 chains with fee middleware wired up including Archway, Cronos, Juno, Kyve and Terra to name some. At least this would contribute towards the rollout once channel upgradability is released (latest Jan 2024).
In terms of the MEV race to the bottom, we discussed this on an issue. It is not clear validators would misbehave, but even from the perspective of a user, if this did happen, the packet still gets delivered. If relayers consistently saw a validator taking the fees as a block proposer, they would not relay the packet when the specific validator is the proposer.
I think the biggest open question for ICS29 is how do you determine what a reasonable amount to pay actually is to ensure that the gas fees are covered on source and destination chain, infrastructure costs are covered and I also think it isn’t unreasonable to give a small additional incentive purely as profit to the relayer, however this is up to chains to decide. There is an issue open on this subject.
From my perspective, relayers are responsible for ensuring the ibc network is live and packets get delivered. There is always going to be a trade-off on speed of delivery and cost but purely from the user perspective, you just want your packet to be delivered for as cheap as possible - I’m assuming this is what you mean by a race to the bottom for relayers?