Skip to content
Snippets Groups Projects
  1. Apr 12, 2024
  2. Apr 11, 2024
  3. Apr 10, 2024
  4. Apr 04, 2024
    • Michal Kucharczyk's avatar
      `GenesisConfig` presets for runtime (#2714) · f910a15c
      Michal Kucharczyk authored
      The runtime now can provide a number of predefined presets of
      `RuntimeGenesisConfig` struct. This presets are intended to be used in
      different deployments, e.g.: `local`, `staging`, etc, and should be
      included into the corresponding chain-specs.
      
      Having `GenesisConfig` presets in runtime allows to fully decouple node
      from runtime types (the problem is described in #1984).
      
      **Summary of changes:**
      - The `GenesisBuilder` API was adjusted to enable this functionality
      (and provide better naming - #150):
         ```rust
          fn preset_names() -> Vec<PresetId>;
      fn get_preset(id: Option<PresetId>) -> Option<serde_json::Value>;
      //`None` means default
          fn build_state(value: serde_json::Value);
          pub struct PresetId(Vec<u8>);
         ```
      
      - **Breaking change**: Old `create_default_config` method was removed,
      `build_config` was renamed to `build_state`. As a consequence a node
      won't be able to interact with genesis config for older runtimes. The
      cleanup was made for sake of API ...
      f910a15c
    • Liam Aharon's avatar
      Migrate fee payment from `Currency` to `fungible` (#2292) · bda4e75a
      Liam Aharon authored
      Part of https://github.com/paritytech/polkadot-sdk/issues/226 
      Related https://github.com/paritytech/polkadot-sdk/issues/1833
      
      - Deprecate `CurrencyAdapter` and introduce `FungibleAdapter`
      - Deprecate `ToStakingPot` and replace usage with `ResolveTo`
      - Required creating a new `StakingPotAccountId` struct that implements
      `TypedGet` for the staking pot account ID
      - Update parachain common utils `DealWithFees`, `ToAuthor` and
      `AssetsToBlockAuthor` implementations to use `fungible`
      - Update runtime XCM Weight Traders to use `ResolveTo` instead of
      `ToStakingPot`
      - Update runtime Transaction Payment pallets to use `FungibleAdapter`
      instead of `CurrencyAdapter`
      - [x] Blocked by https://github.com/paritytech/polkadot-sdk/pull/1296,
      needs the `Unbalanced::decrease_balance` fix
      bda4e75a
  5. Apr 03, 2024
  6. Mar 27, 2024
  7. Mar 21, 2024
  8. Mar 18, 2024
  9. Mar 17, 2024
  10. Mar 15, 2024
  11. Mar 13, 2024
  12. Mar 04, 2024
  13. Mar 01, 2024
  14. Feb 28, 2024
    • Oliver Tale-Yazdi's avatar
      Multi-Block-Migrations, `poll` hook and new System callbacks (#1781) · eefd5fe4
      Oliver Tale-Yazdi authored
      
      This MR is the merge of
      https://github.com/paritytech/substrate/pull/14414 and
      https://github.com/paritytech/substrate/pull/14275. It implements
      [RFC#13](https://github.com/polkadot-fellows/RFCs/pull/13), closes
      https://github.com/paritytech/polkadot-sdk/issues/198.
      
      ----- 
      
      This Merge request introduces three major topicals:
      
      1. Multi-Block-Migrations
      1. New pallet `poll` hook for periodic service work
      1. Replacement hooks for `on_initialize` and `on_finalize` in cases
      where `poll` cannot be used
      
      and some more general changes to FRAME.  
      The changes for each topical span over multiple crates. They are listed
      in topical order below.
      
      # 1.) Multi-Block-Migrations
      
      Multi-Block-Migrations are facilitated by creating `pallet_migrations`
      and configuring `System::Config::MultiBlockMigrator` to point to it.
      Executive picks this up and triggers one step of the migrations pallet
      per block.
      The chain is in lockdown mode for as long as an MBM is ongoing.
      Executive does this by polling `MultiBlockMigrator::ongoing` and not
      allowing any transaction in a block, if true.
      
      A MBM is defined through trait `SteppedMigration`. A condensed version
      looks like this:
      ```rust
      /// A migration that can proceed in multiple steps.
      pub trait SteppedMigration {
      	type Cursor: FullCodec + MaxEncodedLen;
      	type Identifier: FullCodec + MaxEncodedLen;
      
      	fn id() -> Self::Identifier;
      
      	fn max_steps() -> Option<u32>;
      
      	fn step(
      		cursor: Option<Self::Cursor>,
      		meter: &mut WeightMeter,
      	) -> Result<Option<Self::Cursor>, SteppedMigrationError>;
      }
      ```
      
      `pallet_migrations` can be configured with an aggregated tuple of these
      migrations. It then starts to migrate them one-by-one on the next
      runtime upgrade.
      Two things are important here:
      - 1. Doing another runtime upgrade while MBMs are ongoing is not a good
      idea and can lead to messed up state.
      - 2. **Pallet Migrations MUST BE CONFIGURED IN `System::Config`,
      otherwise it is not used.**
      
      The pallet supports an `UpgradeStatusHandler` that can be used to notify
      external logic of upgrade start/finish (for example to pause XCM
      dispatch).
      
      Error recovery is very limited in the case that a migration errors or
      times out (exceeds its `max_steps`). Currently the runtime dev can
      decide in `FailedMigrationHandler::failed` how to handle this. One
      follow-up would be to pair this with the `SafeMode` pallet and enact
      safe mode when an upgrade fails, to allow governance to rescue the
      chain. This is currently not possible, since governance is not
      `Mandatory`.
      
      ## Runtime API
      
      - `Core`: `initialize_block` now returns `ExtrinsicInclusionMode` to
      inform the Block Author whether they can push transactions.
      
      ### Integration
      
      Add it to your runtime implementation of `Core` and `BlockBuilder`:
      ```patch
      diff --git a/runtime/src/lib.rs b/runtime/src/lib.rs
      @@ impl_runtime_apis! {
      	impl sp_block_builder::Core<Block> for Runtime {
      -		fn initialize_block(header: &<Block as BlockT>::Header) {
      +		fn initialize_block(header: &<Block as BlockT>::Header) -> RuntimeExecutiveMode {
      			Executive::initialize_block(header)
      		}
      
      		...
      	}
      ```
      
      # 2.) `poll` hook
      
      A new pallet hook is introduced: `poll`. `Poll` is intended to replace
      mostly all usage of `on_initialize`.
      The reason for this is that any code that can be called from
      `on_initialize` cannot be migrated through an MBM. Currently there is no
      way to statically check this; the implication is to use `on_initialize`
      as rarely as possible.
      Failing to do so can result in broken storage invariants.
      
      The implementation of the poll hook depends on the `Runtime API` changes
      that are explained above.
      
      # 3.) Hard-Deadline callbacks
      
      Three new callbacks are introduced and configured on `System::Config`:
      `PreInherents`, `PostInherents` and `PostTransactions`.
      These hooks are meant as replacement for `on_initialize` and
      `on_finalize` in cases where the code that runs cannot be moved to
      `poll`.
      The reason for this is to make the usage of HD-code (hard deadline) more
      explicit - again to prevent broken invariants by MBMs.
      
      # 4.) FRAME (general changes)
      
      ## `frame_system` pallet
      
      A new memorize storage item `InherentsApplied` is added. It is used by
      executive to track whether inherents have already been applied.
      Executive and can then execute the MBMs directly between inherents and
      transactions.
      
      The `Config` gets five new items:
      - `SingleBlockMigrations` this is the new way of configuring migrations
      that run in a single block. Previously they were defined as last generic
      argument of `Executive`. This shift is brings all central configuration
      about migrations closer into view of the developer (migrations that are
      configured in `Executive` will still work for now but is deprecated).
      - `MultiBlockMigrator` this can be configured to an engine that drives
      MBMs. One example would be the `pallet_migrations`. Note that this is
      only the engine; the exact MBMs are injected into the engine.
      - `PreInherents` a callback that executes after `on_initialize` but
      before inherents.
      - `PostInherents` a callback that executes after all inherents ran
      (including MBMs and `poll`).
      - `PostTransactions` in symmetry to `PreInherents`, this one is called
      before `on_finalize` but after all transactions.
      
      A sane default is to set all of these to `()`. Example diff suitable for
      any chain:
      ```patch
      @@ impl frame_system::Config for Test {
       	type MaxConsumers = ConstU32<16>;
      +	type SingleBlockMigrations = ();
      +	type MultiBlockMigrator = ();
      +	type PreInherents = ();
      +	type PostInherents = ();
      +	type PostTransactions = ();
       }
      ```
      
      An overview of how the block execution now looks like is here. The same
      graph is also in the rust doc.
      
      <details><summary>Block Execution Flow</summary>
      <p>
      
      ![Screenshot 2023-12-04 at 19 11
      29](https://github.com/paritytech/polkadot-sdk/assets/10380170/e88a80c4-ef11-4faa-8df5-8b33a724c054)
      
      </p>
      </details> 
      
      ## Inherent Order
      
      Moved to https://github.com/paritytech/polkadot-sdk/pull/2154
      
      ---------------
      
      
      ## TODO
      
      - [ ] Check that `try-runtime` still works
      - [ ] Ensure backwards compatibility with old Runtime APIs
      - [x] Consume weight correctly
      - [x] Cleanup
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarLiam Aharon <liam.aharon@hotmail.com>
      Co-authored-by: default avatarJuan Girini <juangirini@gmail.com>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      Co-authored-by: default avatarGavin Wood <gavin@parity.io>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      eefd5fe4
    • Liam Aharon's avatar
      Runtime Upgrade ref docs and Single Block Migration example pallet (#1554) · 12ce4f7d
      Liam Aharon authored
      Closes https://github.com/paritytech/polkadot-sdk-docs/issues/55
      
      - Changes 'current storage version' terminology to less ambiguous
      'in-code storage version' (suggestion by @ggwpez
      
      )
      - Adds a new example pallet `pallet-example-single-block-migrations`
      - Adds a new reference doc to replace
      https://docs.substrate.io/maintain/runtime-upgrades/ (temporarily living
      in the pallet while we wait for developer hub PR to merge)
      - Adds documentation for the `storage_alias` macro
      - Improves `trait Hooks` docs 
      - Improves `trait GetStorageVersion` docs
      - Update the suggested patterns for using `VersionedMigration`, so that
      version unchecked migrations are never exported
      - Prevents accidental usage of version unchecked migrations in runtimes
      
      https://github.com/paritytech/substrate/pull/14421#discussion_r1255467895
      - Unversioned migration code is kept inside `mod version_unchecked`,
      versioned code is kept in `pub mod versioned`
      - It is necessary to use modules to limit visibility because the inner
      migration must be `pub`. See
      https://github.com/rust-lang/rust/issues/30905 and
      
      https://internals.rust-lang.org/t/lang-team-minutes-private-in-public-rules/4504/40
      for more.
      
      ### todo
      
      - [x] move to reference docs to proper place within sdk-docs (now that
      https://github.com/paritytech/polkadot-sdk/pull/2102 is merged)
      - [x] prdoc
      
      ---------
      
      Co-authored-by: default avatarKian Paimani <5588131+kianenigma@users.noreply.github.com>
      Co-authored-by: default avatarJuan <juangirini@gmail.com>
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatargupnik <nikhilgupta.iitk@gmail.com>
      12ce4f7d
  15. Feb 26, 2024
    • Branislav Kontur's avatar
      [pallet-xcm] Adjust benchmarks (teleport_assets/reserve_transfer_assets) not relying on ED (#3464) · 3d9439f6
      Branislav Kontur authored
      
      ## Problem
      During the bumping of the `polkadot-fellows` repository to
      `polkadot-sdk@1.6.0`, I encountered a situation where the benchmarks
      `teleport_assets` and `reserve_transfer_assets` in AssetHubKusama
      started to fail. This issue arose due to a decreased ED balance for
      AssetHubs introduced
      [here](https://github.com/polkadot-fellows/runtimes/pull/158/files#diff-80668ff8e793b64f36a9a3ec512df5cbca4ad448c157a5d81abda1b15f35f1daR213),
      and also because of a [missing CI
      pipeline](https://github.com/polkadot-fellows/runtimes/issues/197) to
      check the benchmarks, which went unnoticed.
      
      These benchmarks expect the `caller` to have enough:
      1. balance to transfer (BTT)
      2. balance for paying delivery (BFPD).
       
      So the initial balance was calculated as `ED * 100`, which seems
      reasonable:
      ```
      const ED_MULTIPLIER: u32 = 100;
      let balance = existential_deposit.saturating_mul(ED_MULTIPLIER.into());`
      ```
      The problem arises when the price for delivery is 100 times higher than
      the existential deposit. In other words, when `ED * 100` does not cover
      `BTT` + `BFPD`.
      
      I check AHR/AHW/AHK/AHP and this problem has only AssetHubKusama
      ```
      ED: 3333333
      calculated price to parent delivery:  1031666634  (from xcm logs from the benchmark)
      ---
      
      3333333 * 100 - BTT(3333333) - BFPD(1031666634) = −701666667
      ```
      which results in the error;
      ```
      2024-02-23 09:19:42 Unable to charge fee with error Module(ModuleError { index: 31, error: [17, 0, 0, 0], message: Some("FeesNotMet") })
      Error: Input("Benchmark pallet_xcm::reserve_transfer_assets failed: FeesNotMet")
           
      ```
      
      ## Solution
      
      The benchmarks `teleport_assets` and `reserve_transfer_assets` were
      fixed by removing `ED * 100` and replacing it with `DeliveryHelper`
      logic, which calculates the (almost real) price for delivery and sets it
      along with the existential deposit as the initial balance for the
      account used in the benchmark.
      
      
      ## TODO
      
      - [ ] patch for 1.6 -
      https://github.com/paritytech/polkadot-sdk/pull/3466
      - [ ] patch for 1.7 -
      https://github.com/paritytech/polkadot-sdk/pull/3465
      - [ ] patch for 1.8 - TODO: PR
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      3d9439f6
  16. Feb 20, 2024
  17. Feb 09, 2024
  18. Feb 06, 2024
  19. Feb 02, 2024
  20. Jan 31, 2024
    • Branislav Kontur's avatar
      [frame] `#[pallet::composite_enum]` improved variant count handling + removed... · bb8ddc46
      Branislav Kontur authored
      [frame] `#[pallet::composite_enum]` improved variant count handling + removed `pallet_balances`'s `MaxHolds` config (#2657)
      
      I started this investigation/issue based on @liamaharon
      
       question
      [here](https://github.com/paritytech/polkadot-sdk/pull/1801#discussion_r1410452499).
      
      ## Problem
      
      The `pallet_balances` integrity test should correctly detect that the
      runtime has correct distinct `HoldReasons` variant count. I assume the
      same situation exists for RuntimeFreezeReason.
      
      It is not a critical problem, if we set `MaxHolds` with a sufficiently
      large value, everything should be ok. However, in this case, the
      integrity_test check becomes less useful.
      
      **Situation for "any" runtime:**
      - `HoldReason` enums from different pallets:
      ```rust
              /// from pallet_nis
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		NftReceipt,
      	}
      
              /// from pallet_preimage
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		Preimage,
      	}
      
              // from pallet_state-trie-migration
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		SlashForContinueMigrate,
      		SlashForMigrateCustomTop,
      		SlashForMigrateCustomChild,
      	}
      ```
      
      - generated `RuntimeHoldReason` enum looks like:
      ```rust
      pub enum RuntimeHoldReason {
      
          #[codec(index = 32u8)]
          Preimage(pallet_preimage::HoldReason),
      
          #[codec(index = 38u8)]
          Nis(pallet_nis::HoldReason),
      
          #[codec(index = 42u8)]
          StateTrieMigration(pallet_state_trie_migration::HoldReason),
      }
      ```
      
      - composite enum `RuntimeHoldReason` variant count is detected as `3`
      - we set `type MaxHolds = ConstU32<3>`
      - `pallet_balances::integrity_test` is ok with `3`(at least 3)
      
      However, the real problem can occur in a live runtime where some
      functionality might stop working. This is due to a total of 5 distinct
      hold reasons (for pallets with multi-instance support, it is even more),
      and not all of them can be used because of an incorrect `MaxHolds`,
      which is deemed acceptable according to the `integrity_test`:
        ```
        // pseudo-code - if we try to call all of these:
      
      T::Currency::hold(&pallet_nis::HoldReason::NftReceipt.into(),
      &nft_owner, deposit)?;
      T::Currency::hold(&pallet_preimage::HoldReason::Preimage.into(),
      &nft_owner, deposit)?;
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForContinueMigrate.into(),
      &nft_owner, deposit)?;
      
        // With `type MaxHolds = ConstU32<3>` these two will fail
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomTop.into(),
      &nft_owner, deposit)?;
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomChild.into(),
      &nft_owner, deposit)?;
        ```  
      
      
      ## Solutions
      
      A macro `#[pallet::*]` expansion is extended of `VariantCount`
      implementation for the `#[pallet::composite_enum]` enum type. This
      expansion generates the `VariantCount` implementation for pallets'
      `HoldReason`, `FreezeReason`, `LockId`, and `SlashReason`. Enum variants
      must be plain enum values without fields to ensure a deterministic
      count.
      
      The composite runtime enum, `RuntimeHoldReason` and
      `RuntimeFreezeReason`, now sets `VariantCount::VARIANT_COUNT` as the sum
      of pallets' enum `VariantCount::VARIANT_COUNT`:
      ```rust
      #[frame_support::pallet(dev_mode)]
      mod module_single_instance {
      
      	#[pallet::composite_enum]
      	pub enum HoldReason {
      		ModuleSingleInstanceReason1,
      		ModuleSingleInstanceReason2,
      	}
      ...
      }
      
      #[frame_support::pallet(dev_mode)]
      mod module_multi_instance {
      
      	#[pallet::composite_enum]
      	pub enum HoldReason<I: 'static = ()> {
      		ModuleMultiInstanceReason1,
      		ModuleMultiInstanceReason2,
      		ModuleMultiInstanceReason3,
      	}
      ...
      }
      
      
      impl self::sp_api_hidden_includes_construct_runtime::hidden_include::traits::VariantCount
          for RuntimeHoldReason
      {
          const VARIANT_COUNT: u32 = 0
              + module_single_instance::HoldReason::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance1>::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance2>::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance3>::VARIANT_COUNT;
      }
      ```
      
      In addition, `MaxHolds` is removed (as suggested
      [here](https://github.com/paritytech/polkadot-sdk/pull/2657#discussion_r1443324573))
      from `pallet_balances`, and its `Holds` are now bounded to
      `RuntimeHoldReason::VARIANT_COUNT`. Therefore, there is no need to let
      the runtime specify `MaxHolds`.
      
      
      ## For reviewers
      
      Relevant changes can be found here:
      - `substrate/frame/support/procedural/src/lib.rs` 
      -  `substrate/frame/support/procedural/src/pallet/parse/composite.rs`
      -  `substrate/frame/support/procedural/src/pallet/expand/composite.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/composite_helper.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/hold_reason.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/freeze_reason.rs`
      - `substrate/frame/support/src/traits/misc.rs`
      
      And the rest of the files is just about removed `MaxHolds` from
      `pallet_balances`
      
      ## Next steps
      
      Do the same for `MaxFreezes`
      https://github.com/paritytech/polkadot-sdk/issues/2997.
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Co-authored-by: default avatarDónal Murray <donal.murray@parity.io>
      Co-authored-by: default avatargupnik <nikhilgupta.iitk@gmail.com>
      bb8ddc46
    • Branislav Kontur's avatar
      [cumulus] `parachains-common` testnet constants cleaning (#3134) · 4450b615
      Branislav Kontur authored
      
      The `parachains-common` contains a lots of constants and type
      definitions which are used for `polkadot-sdk`'s testnet runtimes and
      also for `polkadot-fellows`'s production [SP
      runtimes](https://github.com/polkadot-fellows/runtimes/tree/main/system-parachains/constants).
      This PR cleans `parachains-common` module to contain only common and
      generic functionality.
      
      Testnet-specific constants have been moved to the separate module
      dedicated just for testnets:
      `polkadot-sdk/cumulus/parachains/runtimes/constants/`
      
      
      Part of: https://github.com/paritytech/polkadot-sdk/issues/3054
      
      ---------
      
      Co-authored-by: default avatargeorgepisaltu <george.pisaltu@parity.io>
      4450b615
  21. Jan 30, 2024
    • Oliver Tale-Yazdi's avatar
      Revert "[Runtime] Bound XCMP queue" (#3117) · fafe2722
      Oliver Tale-Yazdi authored
      Reverts paritytech/polkadot-sdk#2302. :face_palm:‍♂️ should have checked the
      migration CI first.
      
      We either need to reduce the `max_message_size` for the open HRMP
      channels on the failing chains or increase the `PageSize` of the XCMP
      queue.
      Both would be fine on a test-net, but i assume this will also fail
      before the next SP runtime upgrade so first need to think what best to
      do.
      AFAIK its not possible currently to change the `max_message_size` of an
      open HRMP channel.
      fafe2722
  22. Jan 29, 2024
    • Oliver Tale-Yazdi's avatar
      [Runtime] Bound XCMP queue (#2302) · b8f55d1b
      Oliver Tale-Yazdi authored
      
      Remove `without_storage_info` from the XCMP queue pallet. Part of
      https://github.com/paritytech/polkadot-sdk/issues/323
      
      Changes:
      - Limit the number of channels that can be suspended at the same time.
      - Limit the number of channels that can have messages or signals pending
      at the same time.
      
      A No-OP migration is put in place to ensure that all `BoundedVec`s still
      decode and not truncate after upgrade. The storage version is thereby
      bumped to 4 to have our tooling remind us to deploy that migration.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      b8f55d1b
  23. Jan 24, 2024
    • Just van Stam's avatar
      Transactional processing for XCM (#1222) · 50eb12cf
      Just van Stam authored
      
      Moved from: https://github.com/paritytech/polkadot/pull/6951
      
      closes https://github.com/paritytech/polkadot-sdk/issues/490
      
      - [x] update cumulus
      
      --- 
      This PR introduces transactional processing of certain xcm instructions.
      For the list of instructions checkout
      https://github.com/paritytech/polkadot-sdk/issues/490. The transactional
      processing is implemented as an xcm-executor config item. The two
      implementations in this PR are `FrameTransactionalProcessor` and `()`.
      The `()` implementation does no transactional processing. Each
      implementation of the `ProcessTransaction` trait has an
      `IS_TRANSACTIONAL` const that tells the XCVM if transactional processing
      is actually implemented. If Transactional processing is implemented,
      changes to touched registers should also be rolled back to prevent
      inconsistencies.
      
      
      Note for reviewers:
      Check out the following safety assumption:
      https://github.com/paritytech/polkadot-sdk/pull/1222/files#diff-4effad7d8c1c9de19fd27e18661cbf2128c8718f3b2420a27d2f816e0749ea53R30
      
      ---------
      
      Co-authored-by: default avatarKeith Yeung <kungfukeith11@gmail.com>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      Co-authored-by: command-bot <>
      50eb12cf
    • Branislav Kontur's avatar
      Refactor `pallet-state-trie-migration` to `fungible::*` traits (#1801) · 4374b5d5
      Branislav Kontur authored
      
      ## Summary
      
      This PR consolidates `pallet-state-trie-migration` as a part of
      https://github.com/paritytech/polkadot-sdk/issues/226 /
      https://github.com/paritytech/polkadot-sdk/issues/171:
      
      `pallet-state-trie-migration`:
      - [x] replace `Currency` with `fungible` traits
      - [x] run benchmarks
      - [x] refactor to `DefaultConfig`
      
      `pallet_nicks`:
      - [x]  remove
      
      others:
      - [x] remove `as Fn*` or `asFun*` stuff based on discussion
      [here](https://github.com/paritytech/polkadot-sdk/issues/226#issuecomment-1822861445)
      
      ---------
      
      Co-authored-by: default avatarRichard Melkonian <35300528+0xmovses@users.noreply.github.com>
      Co-authored-by: command-bot <>
      4374b5d5
  24. Jan 23, 2024
    • Branislav Kontur's avatar
      Various nits and alignments for testnet runtimes (#3024) · a817d310
      Branislav Kontur authored
      There were several improvements and PRs that didn't apply to all
      runtimes, so this PR attempts to align those small differences. In
      addition, the PR eliminates unused dependencies across multiple modules.
      
      Relates to PR for `polkadot-fellows`:
      https://github.com/polkadot-fellows/runtimes/pull/154
      a817d310
  25. Jan 22, 2024
  26. Jan 19, 2024
    • Sergej Sakac's avatar
      Enable cross-chain NFT transfers on asset-hub (#2796) · 50a2e28b
      Sergej Sakac authored
      
      This PR introduces the following changes:
      
      - [x] Adds a `UniquesTransactor` to asset-hub-rococo
      - [x] Adds a `UniquesTransactor` to asset-hub-westend
      
      We can't add a transactor for `pallet-nfts` like we do for
      `pallet-uniques` because `pallet-nfts` uses `nonfungibles_v2::Mutate`
      instead of `nonfungibles::Mutate`, and making that work would be out of
      scope of this PR.
      
      With these modifications, reserve-based NFT cross-chain transfers can be
      performed on asset-hub.
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <25483142+joepetrowski@users.noreply.github.com>
      50a2e28b
  27. Jan 17, 2024
  28. 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 <kungfukeith11@gmail.com>
      8428f678
    • Muharem Ismailov's avatar
      XCM WeightTrader: Swap Fee Asset for Native Asset (#1845) · 2cb39f8d
      Muharem Ismailov authored
      
      Implements an XCM executor `WeightTrader`, facilitating fee payments in
      any asset that can be exchanged for a native asset.
      
      A few constraints need to be observed:
      - `buy_weight` and `refund` operations must be atomic, as another weight
      trader implementation might be attempted in case of failure.
      - swap credit must be utilized since there isn’t an account to which an
      asset of some class can be deposited with a guarantee to meet the
      existential deposit requirement. Also, operating with credits enhances
      the efficiency of the weight trader -
      https://github.com/paritytech/polkadot-sdk/pull/1677
      
      related PRs:
      - (depends) https://github.com/paritytech/polkadot-sdk/pull/2031
      - (depends) https://github.com/paritytech/polkadot-sdk/pull/1677
      - (caused) https://github.com/paritytech/polkadot-sdk/pull/1847
      - (caused) https://github.com/paritytech/polkadot-sdk/pull/1876
      
      // DONE: impl `OnUnbalanced` for a `fungible/s` credit
      // DONE: make the trader free from a concept of a native currency and
      drop few fallible conversions. related issue -
      https://github.com/paritytech/polkadot-sdk/issues/1842
      // DONE: tests
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <25483142+joepetrowski@users.noreply.github.com>
      Co-authored-by: default avatarLiam Aharon <liam.aharon@hotmail.com>
      2cb39f8d