-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Introduce XcmFeesToAccount fee manager #7005
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Top notch. There's a lot to like.
I think your right not to include the bridge hub in free xcm fees as bridge hub really should only be talking to statemine/t.
type PalletInstancesInfo = AllPalletsWithSystem; | ||
type MaxAssetsIntoHolding = MaxAssetsIntoHolding; | ||
type FeeManager = (); | ||
type FeeManager = XcmFeesToAccount<Self, SystemParachains, AccountId, TreasuryAccount>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with this change () -> XcmFeesToAccount
Is there any change or consequence for non-system parachains or end users?
I mean, is there anything which will start failing after this is upgraded on-live?
Something like: non-system parachain should drip their sovereign account on relay chain?
If so, maybe should be part of release notes or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There shouldn't be -- with or without a FeeManager
, we've still been collecting fees, the only difference here is that previously we were just burning them after collecting them, but with this change, we simply deposit them to the treasury account.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actual impl FeeManager for ()
here behaves as everything is waived now,
so, iiuc charge_fees
and takes_fee
they never do AssetTransactor::withdraw_asset
, but now with XcmFeesToAccount
they will do AssetTransactor::withdraw_asset
,
so I think this is the change, that origin needs to have some balance > ED + fees, but I dont know how much this is a really issue. I can imaging just some scenarios/calls from some non-system parachain that does not have sovereign account with balance on relay chain, so after this change they will need to drip some DOTs/KSMs to pass
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, so I just took a look at where we collect fees in the XCM executor: it looks like any instruction where it creates and sends an XCM back to the origin would require the origin to pay for fees, and this includes the Query*
instructions, the Report*
instructions, the ExportMessage
instruction and most of the cross-chain asset transfer instructions (e.g. InitiateTeleport
).
This isn't a huge deal, I think what we do need to do is to display delivery fees in the UI clearly so that users are informed about how much they need to pay, otherwise their XCM would fail to be sent.
The CI pipeline was cancelled due to failure one of the required jobs. |
@KiChjang what is the status of this PR? can we merge it? |
@KiChjang @joepetrowski |
It is ready whenever the cumulus companion is fixed. |
bot rebase |
Rebased |
Seems like this PR breaks |
I made a cumulus companion to compile,
so that fix #7585 is really needed |
with fix those tests fails on Balance asserts which needs to be corrected, because of these new xcm fees are charged from user account:
|
bot rebase |
Rebased |
bot rebase |
Rebased |
bot rebase |
Rebased |
This PR introduces a new
XcmFeesToAccount
struct which implements theFeeManager
trait, and assigns this struct as theFeeManager
in the XCM config for all runtimes.The struct simply deposits all fees handled by the XCM executor to a specified account. In all runtimes, the specified account is configured as the treasury account.
XCM delivery fees are now being introduced (unless the root origin is sending a message to a system parachain on behalf of the originating chain).
Important note
After this change, instructions that create and send a new XCM (
Query*
,Report*
,ExportMessage
,InitiateReserveWithdraw
,InitiateTeleport
,DepositReserveAsset
,TransferReserveAsset
,LockAsset
andRequestUnlock
) will require the corresponding origin account in the origin register to pay for transport delivery fees, and the onward message will fail to be sent if the origin account does not have the required amount. This delivery fee is on top of what we already collect as tx fees and XCM BuyExecution fees!Wallet UIs that want to expose the new delivery fee can do so using the formula
delivery_fee_factor * (base_fee + encoded_msg_len * per_byte_fee)
, where the delivery fee factor can be obtained from the corresponding pallet based on which transport you are using (UMP, HRMP or bridges), the base fee is a constant, the encoded message length from the message itself and the per byte fee is the same as the configured per byte fee for txs.cumulus companion: paritytech/cumulus#2433