-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
Umpf, this is slightly problematic since it means for each chain we will need to know what 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) |
I also wrote this issue but no one cares 😢 paritytech/polkadot-sdk#690 paritytech/cumulus#2342 (comment) |
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 |
Never say never - trust me on this one… |
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:
The
base_fee
is a set constant in every chain, and is defined asCENTS * 3
. Theencoded_msg_len
can be determined simply by encoding the XCM and checking the resulting encoded blob size in bytes, and theper_byte_fee
is just theTransactionByteFee
which is defined as10 * 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 theDeliveryFeeFactor
storage map. This map is keyed on the destination'sParaId
, and if no entries exist yet for the given parachain, then the delivery fee factor would just be1
.The text was updated successfully, but these errors were encountered: