Add on chain data for fees paid for successfully relayed packets

[womensrights]

Summary

Currently no on chain information is stored about the relayer incentive fees paid for successfully relayed packets. This makes it difficult to know the fees that should be specified for both a human user and smart contract to ensure a given packet is relayed in a timely and cost effective manner.

Problem Definition

It is undesirable for IBC enabled smart contracts to have hard coded fee amounts, it would be preferable to dynamically change the RecvFee, AckFee and TimeoutFee based on information about recently successfully relayed packets. This would avoid under payment - which could result in packets not being relayed in a timely manner and additional fees needing to be added beyond what was originally specified, or over payment - wasting funds paying more than is needed to have the packet relayed.

Smart contracts cannot query off-chain data to determine reasonable fee amounts for recently relayed packets so there needs to be some data on chain that can be used. Moreover, as different transactions will have different gas requirements, it would also be good to understand the per gas fee amounts to ensure successful delivery.

Proposal

There should be some on chain data stored aggregating the fees paid for successfully relayed packets within a certain time frame per unit gas the packets consumed. This could be a moving average for the previous x blocks, or something similar.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[womensrights]

Summarising here some more feedback:

• The granularity of specifying an incentive for all three packets seems a bit excessive when the concern of a user is for their packet workflow to be completed. Abstracting away specifying each packet would improve usability, this could be as simple as the user having the incentive they want to attach to their workflow automatically split between the recv, ack and timeout

[ValarDragon]

I think putting some on-chain trackers is useful.

I was proposing some basic per block aggregations for tx fees as well. I do generally think this problem goes down once we get more of cosmos onto a base-fee controller which Skip is working on, since then chains can also query base-fee / average tips for their counterparty chains.

However basic tracking is:

• Cheap in terms of computational work
• A relatively easy add on
• Only really helpful, and can easily be deleted later if obsoleted

So I am in favor!