Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update UI to reflect DMP/HRMP message delivery fees #9298

Open
KiChjang opened this issue Apr 6, 2023 · 4 comments
Open

Update UI to reflect DMP/HRMP message delivery fees #9298

KiChjang opened this issue Apr 6, 2023 · 4 comments

Comments

@KiChjang
Copy link

KiChjang commented Apr 6, 2023

After paritytech/polkadot#6843 and paritytech/polkadot#7005 have been merged, we will need to look for a place to inform the user of the delivery fees to collect for the XCM executor to send an outgoing XCM.

This new delivery fee is not included in the weight of the extrinsic and is collected separately. The formula for calculating the delivery fee is:

delivery_fee_factor * (base_fee + encoded_msg_len * per_byte_fee)

The base_fee is a set constant in every chain, and is defined as CENTS * 3. The encoded_msg_len can be determined simply by encoding the XCM and checking the resulting encoded blob size in bytes, and the per_byte_fee is just the TransactionByteFee which is defined as 10 * MILLICENTS on every chain.

The only weird one is delivery_fee_factor, but that is also easily fetched by checking the chain state on the DMP pallet (the XCMP queue pallet if on HRMP) via the DeliveryFeeFactor storage map. This map is keyed on the destination's ParaId, and if no entries exist yet for the given parachain, then the delivery fee factor would just be 1.

@jacogr
Copy link
Member

jacogr commented Apr 6, 2023

Umpf, this is slightly problematic since it means for each chain we will need to know what CENTS refers to.

Is there no way to expose this as a runtime API, meaning that if any changes is made on the chain we don't maintain this in different places? This is really what is done with fee calculations, instead of hardcoding there is an API which means that the whole world doesn't need to keep track of how calculations are done.

I may not be that bad if all those above are exposed as constants in the metadata, but we obviously still need adjustment if the formula changes, i.e. needs to be kept track of. (It does look pretty stock-standard through, it is always base + len * fee in the past)

@xlc
Copy link
Contributor

xlc commented Apr 6, 2023

I also wrote this issue but no one cares 😢 paritytech/polkadot-sdk#690 paritytech/cumulus#2342 (comment)

@KiChjang
Copy link
Author

I don't believe the formula is ever going to change, but the constants may, as it has happened with Kusama. I think as long as we have a runtime API to keep track of CENTS and MILLICENTS, then we're good. Do we?

@jacogr
Copy link
Member

jacogr commented Apr 10, 2023

Never say never - trust me on this one…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants