• Keith Yeung's avatar
    Introduce XcmFeesToAccount fee manager (#1234) · 3dece311
    Keith Yeung authored
    
    
    Combination of paritytech/polkadot#7005, its addon PR
    paritytech/polkadot#7585 and its companion paritytech/cumulus#2433.
    
    This PR introduces a new XcmFeesToAccount struct which implements the
    `FeeManager` trait, and assigns this struct as the `FeeManager` 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).
    
    # Note for reviewers
    
    Most file changes are tests that had to be modified to account for the
    new fees.
    Main changes are in:
    - cumulus/pallets/xcmp-queue/src/lib.rs <- To make it track the delivery
    fees exponential factor
    - polkadot/xcm/xcm-builder/src/fee_handling.rs <- Added. Has the
    FeeManager implementation
    - All runtime xcm_config files <- To add the FeeManager to the XCM
    configuration
    
    # Important note
    
    After this change, instructions that create and send a new XCM (Query*,
    Report*, ExportMessage, InitiateReserveWithdraw, InitiateTeleport,
    DepositReserveAsset, TransferReserveAsset, LockAsset and RequestUnlock)
    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 in
    pallet-xcm 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 (i.e. `TransactionByteFee`).
    
    ---------
    
    Co-authored-by: default avatarBranislav Kontur <[email protected]>
    Co-authored-by: default avatarjoe petrowski <[email protected]>
    Co-authored-by: default avatarGiles Cope <[email protected]>
    Co-authored-by: command-bot <>
    Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
    Co-authored-by: default avatarLiam Aharon <[email protected]>
    Co-authored-by: default avatarKian Paimani <[email protected]>
    3dece311