1. Apr 24, 2024
  2. Apr 18, 2024
  3. Apr 12, 2024
    • Adrian Catangiu's avatar
      pallet-xcm: add new extrinsic for asset transfers using explicit XCM transfer types (#3695) · 1e971b8d
      Adrian Catangiu authored
      
      
      # Description
      
      Add `transfer_assets_using()` for transferring assets from local chain
      to destination chain using explicit XCM transfer types such as:
      - `TransferType::LocalReserve`: transfer assets to sovereign account of
      destination chain and forward a notification XCM to `dest` to mint and
      deposit reserve-based assets to `beneficiary`.
      - `TransferType::DestinationReserve`: burn local assets and forward a
      notification to `dest` chain to withdraw the reserve assets from this
      chain's sovereign account and deposit them to `beneficiary`.
      - `TransferType::RemoteReserve(reserve)`: burn local assets, forward XCM
      to `reserve` chain to move reserves from this chain's SA to `dest`
      chain's SA, and forward another XCM to `dest` to mint and deposit
      reserve-based assets to `beneficiary`. Typically the remote `reserve` is
      Asset Hub.
      - `TransferType::Teleport`: burn local assets and forward XCM to `dest`
      chain to mint/teleport assets and deposit them to `beneficiary`.
      
      By default, an asset's reserve is its origin chain. But sometimes we may
      want to explicitly use another chain as reserve (as long as allowed by
      runtime `IsReserve` filter).
      
      This is very helpful for transferring assets with multiple configured
      reserves (such as Asset Hub ForeignAssets), when the transfer strictly
      depends on the used reserve.
      
      E.g. For transferring Foreign Assets over a bridge, Asset Hub must be
      used as the reserve location.
      
      # Example usage scenarios
      
      ## Transfer bridged ethereum ERC20-tokenX between ecosystem parachains.
      
      ERC20-tokenX is registered on AssetHub as a ForeignAsset by the
      Polkadot<>Ethereum bridge (Snowbridge). Its asset_id is something like
      `(parents:2, (GlobalConsensus(Ethereum), Address(tokenX_contract)))`.
      Its _original_ reserve is Ethereum (only we can't use Ethereum as a
      reserve in local transfers); but, since tokenX is also registered on
      AssetHub as a ForeignAsset, we can use AssetHub as a reserve.
      
      With this PR we can transfer tokenX from ParaA to ParaB while using
      AssetHub as a reserve.
      
      ## Transfer AssetHub ForeignAssets between parachains
      
      AssetA created on ParaA but also registered as foreign asset on Asset
      Hub. Can use AssetHub as a reserve.
      
      And all of the above can be done while still controlling transfer type
      for `fees` so mixing assets in same transfer is supported.
      
      # Tests
      
      Added integration tests for showcasing:
      - transferring local (not bridged) assets from parachain over bridge
      using local Asset Hub reserve,
      - transferring foreign assets from parachain to Asset Hub,
      - transferring foreign assets from Asset Hub to parachain,
      - transferring foreign assets from parachain to parachain using local
      Asset Hub reserve.
      
      ---------
      
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: command-bot <>
      1e971b8d
  4. Apr 02, 2024
  5. Mar 27, 2024
  6. Mar 26, 2024
    • Pavel Orlov's avatar
      XCM Fee Payment Runtime API (#3607) · 3c972fc1
      Pavel Orlov authored
      The PR provides API for obtaining:
      - the weight required to execute an XCM message,
      - a list of acceptable `AssetId`s for message execution payment,
      - the cost of the weight in the specified acceptable `AssetId`.
      
      It is meant to address an issue where one has to guess how much fee to
      pay for execution. Also, at the moment, a client has to guess which
      assets are acceptable for fee execution payment.
      See the related issue
      https://github.com/paritytech/polkadot-sdk/issues/690.
      With this API, a client is supposed to query the list of the supported
      asset IDs (in the XCM version format the client understands), weigh the
      XCM program the client wants to execute and convert the weight into one
      of the acceptable assets. Note that the client is supposed to know what
      program will be executed on what chains. However, having a small
      companion JS library for the pallet-xcm and xtokens should be enough to
      determine what XCM programs will be executed and where (since these
      pallets compose a known small set of programs).
      ```Rust
      pub trait XcmPaymentApi<Call>
      	where
      		Call: Codec,
      	{
      		/// Returns a list of acceptable payment assets.
      		///
      		/// # Arguments
      		///
      		/// * `xcm_version`: Version.
      		fn query_acceptable_payment_assets(xcm_version: Version) -> Result<Vec<VersionedAssetId>, Error>;
      		/// Returns a weight needed to execute a XCM.
      		///
      		/// # Arguments
      		///
      		/// * `message`: `VersionedXcm`.
      		fn query_xcm_weight(message: VersionedXcm<Call>) -> Result<Weight, Error>;
      		/// Converts a weight into a fee for the specified `AssetId`.
      		///
      		/// # Arguments
      		///
      		/// * `weight`: convertible `Weight`.
      		/// * `asset`: `VersionedAssetId`.
      		fn query_weight_to_asset_fee(weight: Weight, asset: VersionedAssetId) -> Result<u128, Error>;
      		/// Get delivery fees for sending a specific `message` to a `destination`.
      		/// These always come in a specific asset, defined by the chain.
      		///
      		/// # Arguments
      		/// * `message`: The message that'll be sent, necessary because most delivery fees are based on the
      		///   size of the message.
      		/// * `destination`: The destination to send the message to. Different destinations may use
      		///   different senders that charge different fees.
      		fn query_delivery_fees(destination: VersionedLocation, message: VersionedXcm<()>) -> Result<VersionedAssets, Error>;
      	}
      ```
      An
      [example](https://gist.github.com/PraetorP/4bc323ff85401abe253897ba990ec29d
      
      )
      of a client side code.
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: default avatarDaniel Shiposha <[email protected]>
      3c972fc1
  7. Mar 22, 2024
  8. Mar 01, 2024
  9. Feb 19, 2024
    • PG Herveou's avatar
      Contracts: xcm host fn fixes (#3086) · ca382f32
      PG Herveou authored
      ## Xcm changes:
      - Fix `pallet_xcm::execute`, move the logic into The `ExecuteController`
      so it can be shared with anything that implement that trait.
      - Make `ExecuteController::execute` retursn `DispatchErrorWithPostInfo`
      instead of `DispatchError`, so that we don't charge the full
      `max_weight` provided if the execution is incomplete (useful for
      force_batch or contracts calls)
      - Fix docstring for `pallet_xcm::execute`, to reflect the changes from
      #2405
      - Update the signature for `ExecuteController::execute`, we don't need
      to return the `Outcome` anymore since we only care about
      `Outcome::Complete`
      
      ## Contracts changes:
      
      - Update host fn `xcm_exexute`, we don't need to write the `Outcome` to
      the sandbox memory anymore. This was also not charged as well before so
      it if fixes this too.
      - One of the issue was that the dry_run of a contract that call
      `xcm_execute` would exhaust the `gas_limit`.
      
      This is because `XcmExecuteController::execute` takes a `max_weight`
      argument, and since we don't want the user to specify it manually we
      were passing everything left by pre-charghing
      `ctx.ext.gas_meter().gas_left()`
      
      - To fix it I added a `fn influence_lowest_limit` on the `Token` trait
      and make it return false for `RuntimeCost::XcmExecute`.
      - Got rid of the `RuntimeToken` indirection, we can just use
      `RuntimeCost` directly.
      
      ---------
      
      Co-authored-by: command-bot <>
      ca382f32
  10. Feb 06, 2024
  11. Jan 16, 2024
    • Francisco Aguirre's avatar
      XCMv4 (#1230) · 8428f678
      Francisco Aguirre authored
      
      
      # Note for reviewer
      
      Most changes are just syntax changes necessary for the new version.
      Most important files should be the ones under the `xcm` folder.
      
      # Description 
      
      Added XCMv4.
      
      ## Removed `Multi` prefix
      The following types have been renamed:
      - MultiLocation -> Location
      - MultiAsset -> Asset
      - MultiAssets -> Assets
      - InteriorMultiLocation -> InteriorLocation
      - MultiAssetFilter -> AssetFilter
      - VersionedMultiAsset -> VersionedAsset
      - WildMultiAsset -> WildAsset
      - VersionedMultiLocation -> VersionedLocation
      
      In order to fix a name conflict, the `Assets` in `xcm-executor` were
      renamed to `HoldingAssets`, as they represent assets in holding.
      
      ## Removed `Abstract` asset id
      
      It was not being used anywhere and this simplifies the code.
      
      Now assets are just constructed as follows:
      
      ```rust
      let asset: Asset = (AssetId(Location::new(1, Here)), 100u128).into();
      ```
      
      No need for specifying `Concrete` anymore.
      
      ## Outcome is now a named fields struct
      
      Instead of
      
      ```rust
      pub enum Outcome {
        Complete(Weight),
        Incomplete(Weight, Error),
        Error(Error),
      }
      ```
      
      we now have
      
      ```rust
      pub enum Outcome {
        Complete { used: Weight },
        Incomplete { used: Weight, error: Error },
        Error { error: Error },
      }
      ```
      
      ## Added Reanchorable trait
      
      Now both locations and assets implement this trait, making it easier to
      reanchor both.
      
      ## New syntax for building locations and junctions
      
      Now junctions are built using the following methods:
      
      ```rust
      let location = Location {
          parents: 1,
          interior: [Parachain(1000), PalletInstance(50), GeneralIndex(1984)].into()
      };
      ```
      
      or
      
      ```rust
      let location = Location::new(1, [Parachain(1000), PalletInstance(50), GeneralIndex(1984)]);
      ```
      
      And they are matched like so:
      
      ```rust
      match location.unpack() {
        (1, [Parachain(id)]) => ...
        (0, Here) => ...,
        (1, [_]) => ...,
      }
      ```
      
      This syntax is mandatory in v4, and has been also implemented for v2 and
      v3 for easier migration.
      
      This was needed to make all sizes smaller.
      
      # TODO
      - [x] Scaffold v4
      - [x] Port github.com/paritytech/polkadot/pull/7236
      - [x] Remove `Multi` prefix
      - [x] Remove `Abstract` asset id
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarKeith Yeung <[email protected]>
      8428f678
  12. Dec 12, 2023
    • Branislav Kontur's avatar
      Ensure xcm versions over bridge (on sending chains) (#2481) · 575b8f8d
      Branislav Kontur authored
      ## Summary
      
      This pull request proposes a solution for improved control of the
      versioned XCM flow over the bridge (across different consensus chains)
      and resolves the situation where the sending chain/consensus has already
      migrated to a higher XCM version than the receiving chain/consensus.
      
      ## Problem/Motivation
      
      The current flow over the bridge involves a transfer from AssetHubRococo
      (AHR) to BridgeHubRococo (BHR) to BridgeHubWestend (BHW) and finally to
      AssetHubWestend (AHW), beginning with a reserve-backed transfer on AHR.
      
      In this process:
      1. AHR sends XCM `ExportMessage` through `XcmpQueue`, incorporating XCM
      version checks using the `WrapVersion` feature, influenced by
      `pallet_xcm::SupportedVersion` (managed by
      `pallet_xcm::force_xcm_version` or version discovery).
      
      2. BHR handles the `ExportMessage` instruction, utilizing the latest XCM
      version. The `HaulBlobExporter` converts the inner XCM to
      [`VersionedXcm::from`](https://github.com/paritytech/polkadot-sdk/blob/63ac2471aa0210f0ac9903bdd7d8f9351f9a635f/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465-L467),
      also using the latest XCM version.
      
      However, challenges arise:
      - Incompatibility when BHW uses a different version than BHR. For
      instance, if BHR migrates to **XCMv4** while BHW remains on **XCMv3**,
      BHR's `VersionedXcm::from` uses `VersionedXcm::V4` variant, causing
      encoding issues for BHW.
        ```
      	/// Just a simulation of possible error, which could happen on BHW
      	/// (this code is based on actual master without XCMv4)
      	let encoded = hex_literal::hex!("0400");
      	println!("{:?}", VersionedXcm::<()>::decode(&mut &encoded[..]));
      
      Err(Error { cause: None, desc: "Could not decode `VersionedXcm`, variant
      doesn't exist" })
        ``` 
      - Similar compatibility issues exist between AHR and AHW.
      
      ## Solution
      
      This pull request introduces the following solutions:
      
      1. **New trait `CheckVersion`** - added to the `xcm` module and exposing
      `pallet_xcm::SupportedVersion`. This enhancement allows checking the
      actual XCM version for desired destinations outside of the `pallet_xcm`
      module.
      
      2. **Version Check in `HaulBlobExporter`** uses `CheckVersion` to check
      known/configured destination versions, ensuring compatibility. For
      example, in the scenario mentioned, BHR can store the version `3` for
      BHW. If BHR is on XCMv4, it will attempt to downgrade the message to
      version `3` instead of using the latest version `4`.
      
      3. **Version Check in `pallet-xcm-bridge-hub-router`** - this check
      ensures compatibility with the real destination's XCM version,
      preventing the unnecessary sending of messages to the local bridge hub
      if versions are incompatible.
      
      These additions aim to improve the control and compatibility of XCM
      flows over the bridge and addressing issues related to version
      mismatches.
      
      ## Possible alternative solution
      
      _(More investigation is needed, and at the very least, it should extend
      to XCMv4/5. If this proves to be a viable option, I can open an RFC for
      XCM.)._
      
      Add the `XcmVersion` attribute to the `ExportMessage` so that the
      sending chain can determine, based on what is stored in
      `pallet_xcm::SupportedVersion`, the version the destination is using.
      This way, we may not need to handle the version in `HaulBlobExporter`.
      
      ```
      ExportMessage {
      	network: NetworkId,
      	destination: InteriorMultiLocation,
      	xcm: Xcm<()>
      	destination_xcm_version: Version, // <- new attritbute
      },
      ```
      
      ```
      pub trait ExportXcm {
              fn validate(
      		network: NetworkId,
      		channel: u32,
      		universal_source: &mut Option<InteriorMultiLocation>,
      		destination: &mut Option<InteriorMultiLocation>,
      		message: &mut Option<Xcm<()>>,
                      destination_xcm_version: Version, , // <- new attritbute
      	) -> SendResult<Self::Ticket>;
      ```
      
      ## Future Directions
      
      This PR does not fix version discovery over bridge, further
      investigation will be conducted here:
      https://github.com/paritytech/polkadot-sdk/issues/2417.
      
      ## TODO
      
      - [x] `pallet_xcm` mock for tests uses hard-coded XCM version `2` -
      change to 3 or lastest?
      - [x] fix `pallet-xcm-bridge-hub-router`
      - [x] fix HaulBlobExporter with version determination
      [here](https://github.com/paritytech/polkadot-sdk/blob/2183669d05f9b510f979a0cc3c7847707bacba2e/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465)
      - [x] add unit-tests to the runtimes
      - [x] run benchmarks for `ExportMessage`
      - [x] extend local run scripts about `force_xcm_version(dest, version)`
      - [ ] when merged, prepare governance calls for Rococo/Westend
      - [ ] add PRDoc
      
      Part of: https://github.com/paritytech/parity-bridges-common/issues/2719
      
      ---------
      
      Co-authored-by: command-bot <>
      575b8f8d
  13. Dec 06, 2023
    • Adrian Catangiu's avatar
      pallet-xcm: add new flexible `transfer_assets()` call/extrinsic (#2388) · e7651cf4
      Adrian Catangiu authored
      # Motivation (+testing)
      
      ### Enable easy `ForeignAssets` transfers using `pallet-xcm` 
      
      We had just previously added capabilities to teleport fees during
      reserve-based transfers, but what about reserve-transferring fees when
      needing to teleport some non-fee asset?
      
      This PR aligns everything under either explicit reserve-transfer,
      explicit teleport, or this new flexible `transfer_assets()` which can
      mix and match as needed with fewer artificial constraints imposed to the
      user.
      
      This will enable, for example, a (non-system) parachain to teleport
      their `ForeignAssets` assets to AssetHub while using DOT to pay fees.
      (the assets are teleported - as foreign assets should from their owner
      chain - while DOT used for fees can only be reserve-based transferred
      between said parachain and AssetHub).
      
      Added `xcm-emulator` tests for this scenario ^.
      
      # Description
      
      Reverts `(limited_)reserve_transfer_assets` to only allow reserve-based
      transfers for all `assets` including fees.
      
      Similarly `(limited_)teleport_assets` only allows teleports for all
      `assets` including fees.
          
      For complex combinations of asset transfers where assets and fees may
      have different reserves or different reserve/teleport trust
      configurations, users can use the newly added `transfer_assets()`
      extrinsic which is more flexible in allowing more complex scenarios.
      
      `assets` (excluding `fees`) must have same reserve location or otherwise
      be teleportable to `dest`.
      No limitations imposed on `fees`.
      
      - for local reserve: transfer assets to sovereign account of destination
      chain and forward a notification XCM to `dest` to mint and deposit
      reserve-based assets to `beneficiary`.
      - for destination reserve: burn local assets and forward a notification
      to `dest` chain to withdraw the reserve assets from this chain's
      sovereign account and deposit them to `beneficiary`.
      - for remote reserve: burn local assets, forward XCM to reserve chain to
      move reserves from this chain's SA to `dest` chain's SA, and forward
      another XCM to `dest` to mint and deposit reserve-based assets to
      `beneficiary`.
      - for teleports: burn local assets and forward XCM to `dest` chain to
      mint/teleport assets and deposit them to `beneficiary`.
      
      ## Review notes
      
      Only around 500 lines are prod code (see `pallet_xcm/src/lib.rs`), the
      rest of the PR is new tests and improving existing tests.
      
      ---------
      
      Co-authored-by: command-bot <>
      e7651cf4
  14. Nov 24, 2023
  15. Nov 15, 2023
  16. Nov 13, 2023
    • Adrian Catangiu's avatar
      pallet-xcm: enhance `reserve_transfer_assets` to support remote reserves (#1672) · 18257373
      Adrian Catangiu authored
      ## Motivation
      
      `pallet-xcm` is the main user-facing interface for XCM functionality,
      including assets manipulation functions like `teleportAssets()` and
      `reserve_transfer_assets()` calls.
      
      While `teleportAsset()` works both ways, `reserve_transfer_assets()`
      works only for sending reserve-based assets to a remote destination and
      beneficiary when the reserve is the _local chain_.
      
      ## Solution
      
      This PR enhances `pallet_xcm::(limited_)reserve_withdraw_assets` to
      support transfers when reserves are other chains.
      This will allow complete, **bi-directional** reserve-based asset
      transfers user stories using `pallet-xcm`.
      
      Enables following scenarios:
      - transferring assets with local reserve (was previously supported iff
      asset used as fee also had local reserve - now it works in all cases),
      - transferring assets with reserve on destination,
      - transferring assets with reserve on remote/third-party chain (iff
      assets and fees have same remote reserve),
      - transferring assets with reserve different than the reserve of the
      asset to be used as fees - meaning can be used to transfer random asset
      with local/dest reserve while using DOT for fees on all involved chains,
      even if DOT local/dest reserve doesn't match asset reserve,
      - transferring assets with any type of local/dest reserve while using
      fees which can be teleported between involved chains.
      
      All of the above is done by pallet inner logic without the user having
      to specify which scenario/reserves/teleports/etc. The correct scenario
      and corresponding XCM programs are identified, and respectively, built
      automatically based on runtime configuration of trusted teleporters and
      trusted reserves.
      
      #### Current limitations:
      - while `fees` and "non-fee" `assets` CAN have different reserves (or
      fees CAN be teleported), the remaining "non-fee" `assets` CANNOT, among
      themselves, have different reserve locations (this is also implicitly
      enforced by `MAX_ASSETS_FOR_TRANSFER=2`, but this can be safely
      increased in the future).
      - `fees` and "non-fee" `assets` CANNOT have **different remote**
      reserves (this could also be supported in the future, but adds even more
      complexity while possibly not being worth it - we'll see what the future
      holds).
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/1584
      Fixes https://github.com/paritytech/polkadot-sdk/issues/2055
      
      
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      18257373
  17. Nov 10, 2023
    • PG Herveou's avatar
      Contracts: Add XCM traits to interface with contracts (#2086) · 6b7be115
      PG Herveou authored
      We are introducing a new set of `XcmController` traits (final name yet
      to be determined).
      These traits are implemented by `pallet-xcm` and allows other pallets,
      such as `pallet_contracts`, to rely on these traits instead of tight
      coupling them to `pallet-xcm`.
      
      Using only the existing Xcm traits would mean duplicating the logic from
      `pallet-xcm` in these other pallets, which we aim to avoid. Our
      objective is to ensure that when these APIs are called from
      `pallet-contracts`, they produce the exact same outcomes as if called
      directly from `pallet-xcm`.
      
      The other benefits is that we can also expose return values to
      `pallet-contracts` instead of just calling `pallet-xcm` dispatchable and
      getting a `DispatchResult` back.
      
      See traits integration in this PR
      https://github.com/paritytech/polkadot-sdk/pull/1248
      
      , where the traits
      are used as follow to define and implement `pallet-contracts` Config.
      ```rs
      // Contracts config:
      pub trait Config: frame_system::Config {
        // ...
      
        /// A type that exposes XCM APIs, allowing contracts to interact with other parachains, and
        /// execute XCM programs.
        type Xcm: xcm_executor::traits::Controller<
      	  OriginFor<Self>,
      	  <Self as frame_system::Config>::RuntimeCall,
      	  BlockNumberFor<Self>,
        >;
      }
      
      // implementation
      impl pallet_contracts::Config for Runtime {
              // ...
      
      	type Xcm = pallet_xcm::Pallet<Self>;
      }
      ```
      
      ---------
      
      Co-authored-by: default avatarAlexander Theißen <[email protected]>
      Co-authored-by: command-bot <>
      6b7be115
  18. Sep 25, 2023
  19. Sep 20, 2023
    • Gavin Wood's avatar
      XCM: Deprecate old functions (#1645) · e7d29bc3
      Gavin Wood authored
      Two old functions should be deprecated and have their code altered in
      line with capabilities of XCMv2 and above.
      
      This means we can use the proper `Unlimited` form of weight limit rather
      than guessing weight from the local chain.
      e7d29bc3
  20. Aug 31, 2023
  21. Aug 14, 2023
  22. Aug 05, 2023
  23. Jul 24, 2023
  24. Jul 19, 2023
    • Francisco Aguirre's avatar
      Change Fixed to WeightInfoBounds for Polkadot (#7077) · cc9f8129
      Francisco Aguirre authored
      
      
      * Add polkadot XCM benchmarks
      
      * Add temp
      
      * ".git/.scripts/commands/bench/bench.sh" xcm polkadot pallet_xcm_benchmarks::fungible
      
      * ".git/.scripts/commands/bench/bench.sh" xcm polkadot pallet_xcm_benchmarks::generic
      
      * Add weights to XCM on Polkadot
      
      * Make CI fail on old files
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Update template
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Add reserve_asset_deposited benchmark
      
      * ".git/.scripts/commands/bench/bench.sh" xcm kusama pallet_xcm_benchmarks::generic
      
      * Update weights
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Change initiate_reserve_deposit in runtime weights
      
      * Update weights
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Remove trusted reserves from runtimes
      
      * Fix pallet-xcm-benchmarks mock
      
      * Fix test
      
      * Change pallet xcm weigher in kusama
      
      * Fix
      
      * Remove merge conflict artifact
      
      * Remove initiate_reserve_withdraw from generic benchmarks
      
      * Add missing implementation to XCM benchmark
      
      * Fix failing karura test
      
      * Remove dbg!
      
      Co-authored-by: default avatarKeith Yeung <[email protected]>
      
      * Fix fmt
      
      * Revert "Fix fmt"
      
      This reverts commit 676f2d8db07d7427750c79f95494d4988d06fda5.
      
      * Fix fmt
      
      * Remove duplicated template code
      
      * Add back part of the template
      
      * ".git/.scripts/commands/bench-vm/bench-vm.sh" xcm polkadot pallet_xcm_benchmarks::fungible
      
      * Don't skip reserve asset deposited benchmark
      
      * Remove call to non-generated benchmark yet
      
      * Underscore unused parameter
      
      * Skip not supported benchmarks and hardcode value
      
      * Remove ReserveAssetDeposited benchmark
      
      * ".git/.scripts/commands/bench-vm/bench-vm.sh" xcm polkadot pallet_xcm_benchmarks::fungible
      
      * Add back ReserveAssetDeposited
      
      * ".git/.scripts/commands/bench-vm/bench-vm.sh" xcm polkadot pallet_xcm_benchmarks::fungible
      
      * Use default benchmark for ReserveAssetDeposited
      
      * Add missing parameter
      
      * Revert reserve asset deposited benchmark
      
      * ".git/.scripts/commands/bench-vm/bench-vm.sh" xcm kusama pallet_xcm_benchmarks::fungible
      
      * ".git/.scripts/commands/bench-vm/bench-vm.sh" xcm westend pallet_xcm_benchmarks::fungible
      
      * ".git/.scripts/commands/bench/bench.sh" xcm rococo pallet_xcm_benchmarks::fungible
      
      * Add 'real' benchmarks
      
      * Add TrustedReserve to actual XcmConfig
      
      * Add TrustedReserve to actual XcmConfig (fix)
      
      * Whitelist from benchmarking XCM storage keys read each block (#6871)
      
      * Whitelist from benchmarking XCM storage keys read each block
      
      * ".git/.scripts/commands/bench/bench.sh" runtime polkadot pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime polkadot pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime westend pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime rococo pallet_xcm
      
      * Remove XcmPallet SupportedVersion from the benchmark whitelist
      
      * ".git/.scripts/commands/bench/bench.sh" runtime polkadot pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime kusama pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime westend pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime rococo pallet_xcm
      
      * WIP
      
      * Add necessary traits, remove unnecessary whitelisted keys
      
      * Fix tests
      
      * Remove unused file
      
      * Remove unused import
      
      ---------
      
      Co-authored-by: command-bot <>
      
      * ".git/.scripts/commands/bench/bench.sh" xcm kusama pallet_xcm_benchmarks::fungible
      
      * ".git/.scripts/commands/bench/bench.sh" xcm kusama pallet_xcm_benchmarks::fungible
      
      * ".git/.scripts/commands/bench/bench.sh" xcm kusama pallet_xcm_benchmarks::fungible
      
      * ".git/.scripts/commands/bench/bench.sh" xcm rococo pallet_xcm_benchmarks::fungible
      
      * ".git/.scripts/commands/bench/bench.sh" xcm westend pallet_xcm_benchmarks::fungible
      
      * Fix spellchecker issues
      
      * Remove unused migration code
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarKeith Yeung <[email protected]>
      cc9f8129
  25. Jul 13, 2023
    • gupnik's avatar
      Moves `Block` to `frame_system` instead of `construct_runtime` and removes... · 28024144
      gupnik authored
      
      Moves `Block` to `frame_system` instead of `construct_runtime` and removes `Header` and `BlockNumber` (#7431)
      
      * Companion for substrate
      
      * Minor update
      
      * Formatting
      
      * Fixes for cumulus
      
      * Fixes tests in polkadot-runtime-parachains
      
      * Minor update
      
      * Removes unused import
      
      * Fixes tests in polkadot-runtime-common
      
      * Minor fix
      
      * Update roadmap/implementers-guide/src/runtime/configuration.md
      
      Co-authored-by: default avatarordian <[email protected]>
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      * update lockfile for {"substrate"}
      
      ---------
      
      Co-authored-by: default avatarordian <[email protected]>
      Co-authored-by: command-bot <>
      28024144
  26. Jul 12, 2023
  27. Jun 05, 2023
  28. May 31, 2023
    • Francisco Aguirre's avatar
      XCM: PayOverXcm config (#6900) · a0e2aaad
      Francisco Aguirre authored
      
      
      * Move XCM query functionality to trait
      
      * Fix tests
      
      * Add PayOverXcm implementation
      
      * fix the PayOverXcm trait to compile
      
      * moved doc comment out of trait implmeentation and to the trait
      
      * PayOverXCM documentation
      
      * Change documentation a bit
      
      * Added empty benchmark methods implementation and changed docs
      
      * update PayOverXCM to convert AccountIds to MultiLocations
      
      * Implement benchmarking method
      
      * Change v3 to latest
      
      * Descend origin to an asset sender (#6970)
      
      * descend origin to an asset sender
      
      * sender as tuple of dest and sender
      
      * Add more variants to the QueryResponseStatus enum
      
      * Change Beneficiary to Into<[u8; 32]>
      
      * update PayOverXcm to return concrete errors and use AccountId as sender
      
      * use polkadot-primitives for AccountId
      
      * fix dependency to use polkadot-core-primitives
      
      * force Unpaid instruction to the top of the instructions list
      
      * modify report_outcome to accept interior argument
      
      * use new_query directly for building final xcm query, instead of report_outcome
      
      * fix usage of new_query to use the XcmQueryHandler
      
      * fix usage of new_query to use the XcmQueryHandler
      
      * tiny method calling fix
      
      * xcm query handler (#7198)
      
      * drop redundant query status
      
      * rename ReportQueryStatus to OuterQueryStatus
      
      * revert rename of QueryResponseStatus
      
      * update mapping
      
      * Update xcm/xcm-builder/src/pay.rs
      
      Co-authored-by: default avatarGavin Wood <[email protected]>
      
      * Updates
      
      * Docs
      
      * Fix benchmarking stuff
      
      * Destination can be determined based on asset_kind
      
      * Tweaking API to minimise clones
      
      * Some repotting and docs
      
      ---------
      
      Co-authored-by: default avatarAnthony Alaribe <[email protected]>
      Co-authored-by: default avatarMuharem Ismailov <[email protected]>
      Co-authored-by: default avatarAnthony Alaribe <[email protected]>
      Co-authored-by: default avatarGavin Wood <[email protected]>
      a0e2aaad
  29. May 25, 2023
  30. May 17, 2023
  31. May 09, 2023
  32. May 05, 2023
    • Muharem Ismailov's avatar
      XCM remote lock consumers (#6947) · 245305be
      Muharem Ismailov authored
      * xcm remote lock consumers
      
      * update xcm pallet config setups
      
      * fix import
      
      * update xcm pallet config setups
      
      * rename consumers to users
      
      * rename
      
      * rename users to consumers, more docs
      
      * correct doc
      
      ---------
      
      Co-authored-by: parity-processbot <>
      245305be
  33. Apr 27, 2023
    • Keith Yeung's avatar
      XCM: Implement a blocking barrier (#7098) · d20e3c11
      Keith Yeung authored
      * Move XCM matcher to xcm-builder
      
      * Use ProcessMessageError as the error type in MatchXcm and ShouldExecute
      
      * Implement a blocking barrier
      
      * Fixes
      
      * Add benchmarking for force_suspension
      
      * ".git/.scripts/commands/bench/bench.sh" runtime westend pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime rococo pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime kusama pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime polkadot pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime westend pallet_xcm
      
      * ".git/.scripts/commands/bench/bench.sh" runtime rococo pallet_xcm
      
      ---------
      
      Co-authored-by: command-bot <>
      d20e3c11
  34. Apr 20, 2023
    • Keith Yeung's avatar
      XCM: Properly set the pricing for the DMP router (#6843) · 023d4598
      Keith Yeung authored
      
      
      * Properly set the pricing for the DMP router
      
      * Publicize price types
      
      * Use FixedU128 instead of Percent
      
      * Add sp-arithmetic as a dependency for rococo runtime
      
      * Add sp-arithmetic as a dependency to all runtimes
      
      * Remove duplicate import
      
      * Add missing import
      
      * Fix tests
      
      * Create an appropriate QueueDownwardMessageError variant
      
      * Recalculate delivery fee factor based on past queue sizes
      
      * Remove unused error variant
      
      * Fixes
      
      * Fixes
      
      * Remove unused imports
      
      * Rewrite fee factor update mechanism
      
      * Remove unused imports
      
      * Fixes
      
      * Update runtime/parachains/src/dmp.rs
      
      Co-authored-by: default avatarSquirrel <[email protected]>
      
      * Make DeliveryFeeFactor be a StorageMap keyed on ParaIds
      
      * Fixes
      
      * introduce limit for fee increase on dmp queue
      
      * add message_size based fee factor to increment_fee_factor
      
      * change message_size fee rate to correct value
      
      * fix div by 0 error
      
      * bind limit to variable
      
      * fix message_size_factor and add DeliveryFeeFactor test
      
      * add test for ExponentialPrice implementation
      
      * make test formula based
      
      * make delivery fee factor test formula based
      
      * add max value test for DeliveryFeeFactor and move limit to config
      
      * change threshold back to dynamic value and fix tests
      
      * fmt
      
      * suggested changes and fmt
      
      * small stylistic change
      
      * fmt
      
      * change to tokenlocation
      
      * small fixes
      
      * fmt
      
      * remove sp_arithmetic dependency
      
      * Update runtime/parachains/src/dmp.rs
      
      Co-authored-by: default avatarKian Paimani <[email protected]>
      
      ---------
      
      Co-authored-by: default avatarSquirrel <[email protected]>
      Co-authored-by: default avatarJust van Stam <[email protected]>
      Co-authored-by: default avatarJust van Stam <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      023d4598
  35. Apr 08, 2023
  36. Mar 30, 2023
  37. Mar 23, 2023
    • Just van Stam's avatar
      Vstam1/xcm admin origin (#6928) · f989b2bb
      Just van Stam authored
      
      
      * Ensure for a configurable origin in XCM (#6442), cherry picked from
      5ae05e1a957857c449a43d8759a21292d03fd049
      
      Add new associated type, AdminOrigin, bounded by EnsureOrigin trait in
      XCM pallet. Replace ensure_root() with ensure_origin() from a
      EnsureOrigin trait. Set AdminOrigin as EnsureRoot<AccountId> in xcm
      configs.
      
      * cargo fmt
      
      * small stylistic change
      
      ---------
      
      Co-authored-by: default avatarserkul <[email protected]>
      f989b2bb