1. Nov 13, 2023
    • gupnik's avatar
      Adds syntax for marking calls feeless (#1926) · 60c77a2e
      gupnik authored
      Fixes https://github.com/paritytech/polkadot-sdk/issues/1725
      
      
      
      This PR adds the following changes:
      1. An attribute `pallet::feeless_if` that can be optionally attached to
      a call like so:
      ```rust
      #[pallet::feeless_if(|_origin: &OriginFor<T>, something: &u32| -> bool {
      	*something == 0
      })]
      pub fn do_something(origin: OriginFor<T>, something: u32) -> DispatchResult {
           ....
      }
      ```
      The closure passed accepts references to arguments as specified in the
      call fn. It returns a boolean that denotes the conditions required for
      this call to be "feeless".
      
      2. A signed extension `SkipCheckIfFeeless<T: SignedExtension>` that
      wraps a transaction payment processor such as
      `pallet_transaction_payment::ChargeTransactionPayment`. It checks for
      all calls annotated with `pallet::feeless_if` to see if the conditions
      are met. If so, the wrapped signed extension is not called, essentially
      making the call feeless.
      
      In order to use this, you can simply replace your existing signed
      extension that manages transaction payment like so:
      ```diff
      - pallet_transaction_payment::ChargeTransactionPayment<Runtime>,
      + pallet_skip_feeless_payment::SkipCheckIfFeeless<
      +	Runtime,
      +	pallet_transaction_payment::ChargeTransactionPayment<Runtime>,
      + >,
      ```
      
      ### Todo
      - [x] Tests
      - [x] Docs
      - [x] Prdoc
      
      ---------
      
      Co-authored-by: Nikhil Gupta <>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      60c77a2e
  2. Nov 10, 2023
  3. Nov 07, 2023
    • Liam Aharon's avatar
      Initialise on-chain `StorageVersion` for pallets added after genesis (#1297) · c4211b65
      Liam Aharon authored
      Original PR https://github.com/paritytech/substrate/pull/14641
      
      ---
      
      Closes https://github.com/paritytech/polkadot-sdk/issues/109
      
      
      
      ### Problem
      Quoting from the above issue:
      
      > When adding a pallet to chain after genesis we currently don't set the
      StorageVersion. So, when calling on_chain_storage_version it returns 0
      while the pallet is maybe already at storage version 9 when it was added
      to the chain. This could lead to issues when running migrations.
      
      ### Solution
      
      - Create a new trait `BeforeAllRuntimeMigrations` with a single method
      `fn before_all_runtime_migrations() -> Weight` trait with a noop default
      implementation
      - Modify `Executive` to call
      `BeforeAllRuntimeMigrations::before_all_runtime_migrations` for all
      pallets before running any other hooks
      - Implement `BeforeAllRuntimeMigrations` in the pallet proc macro to
      initialize the on-chain version to the current pallet version if the
      pallet has no storage set (indicating it has been recently added to the
      runtime and needs to have its version initialised).
      
      ### Other changes in this PR
      
      - Abstracted repeated boilerplate to access the `pallet_name` in the
      pallet expand proc macro.
      
      ### FAQ
      
      #### Why create a new hook instead of adding this logic to the pallet
      `pre_upgrade`?
      
      `Executive` currently runs `COnRuntimeUpgrade` (custom migrations)
      before `AllPalletsWithSystem` migrations. We need versions to be
      initialized before the `COnRuntimeUpgrade` migrations are run, because
      `COnRuntimeUpgrade` migrations may use the on-chain version for critical
      logic. e.g. `VersionedRuntimeUpgrade` uses it to decide whether or not
      to execute.
      
      We cannot reorder `COnRuntimeUpgrade` and `AllPalletsWithSystem` so
      `AllPalletsWithSystem` runs first, because `AllPalletsWithSystem` have
      some logic in their `post_upgrade` hooks to verify that the on-chain
      version and current pallet version match. A common use case of
      `COnRuntimeUpgrade` migrations is to perform a migration which will
      result in the versions matching, so if they were reordered these
      `post_upgrade` checks would fail.
      
      #### Why init the on-chain version for pallets without a current storage
      version?
      
      We must init the on-chain version for pallets even if they don't have a
      defined storage version so if there is a future version bump, the
      on-chain version is not automatically set to that new version without a
      proper migration.
      
      e.g. bad scenario:
      
      1. A pallet with no 'current version' is added to the runtime
      2. Later, the pallet is upgraded with the 'current version' getting set
      to 1 and a migration is added to Executive Migrations to migrate the
      storage from 0 to 1
          a. Runtime upgrade occurs
          b. `before_all` hook initializes the on-chain version to 1
      c. `on_runtime_upgrade` of the migration executes, and sees the on-chain
      version is already 1 therefore think storage is already migrated and
      does not execute the storage migration
      Now, on-chain version is 1 but storage is still at version 0.
      
      By always initializing the on-chain version when the pallet is added to
      the runtime we avoid that scenario.
      
      ---------
      
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      c4211b65
  4. Nov 06, 2023
  5. Nov 02, 2023
    • Richard Melkonian's avatar
      Create new trait for non-dedup storage decode (#1932) · 15a34838
      Richard Melkonian authored
      - This adds the new trait `StorageDecodeNonDedupLength` and implements
      them for `BTreeSet` and its bounded types.
      - New unit test has been added to cover the case.  
      - See linked
      [issue](https://github.com/paritytech/polkadot-sdk/issues/126
      
      ) which
      outlines the original issue.
      
      Note that the added trait here doesn't add new logic but improves
      semantics.
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: command-bot <>
      15a34838
    • Oliver Tale-Yazdi's avatar
      Use `Message Queue` as DMP and XCMP dispatch queue (#1246) · e1c033eb
      Oliver Tale-Yazdi authored
      (imported from https://github.com/paritytech/cumulus/pull/2157)
      
      ## Changes
      
      This MR refactores the XCMP, Parachains System and DMP pallets to use
      the [MessageQueue](https://github.com/paritytech/substrate/pull/12485)
      for delayed execution of incoming messages. The DMP pallet is entirely
      replaced by the MQ and thereby removed. This allows for PoV-bounded
      execution and resolves a number of issues that stem from the current
      work-around.
      
      All System Parachains adopt this change.  
      The most important changes are in `primitives/core/src/lib.rs`,
      `parachains/common/src/process_xcm_message.rs`,
      `pallets/parachain-system/src/lib.rs`, `pallets/xcmp-queue/src/lib.rs`
      and the runtime configs.
      
      ### DMP Queue Pallet
      
      The pallet got removed and its logic refactored into parachain-system.
      Overweight message management can be done directly through the MQ
      pallet.
      
      Final undeployment migrations are provided by
      `cumulus_pallet_dmp_queue::UndeployDmpQueue` and `DeleteDmpQueue` that
      can be configured with an aux config trait like:
      
      ```rust
      parameter_types! {
      	pub const DmpQueuePalletName: &'static str = \"DmpQueue\" < CHANGE ME;
      	pub const RelayOrigin: AggregateMessageOrigin = AggregateMessageOrigin::Parent;
      }
      
      impl cumulus_pallet_dmp_queue::MigrationConfig for Runtime {
      	type PalletName = DmpQueuePalletName;
      	type DmpHandler = frame_support::traits::EnqueueWithOrigin<MessageQueue, RelayOrigin>;
      	type DbWeight = <Runtime as frame_system::Config>::DbWeight;
      }
      
      // And adding them to your Migrations tuple:
      pub type Migrations = (
      	...
      	cumulus_pallet_dmp_queue::UndeployDmpQueue<Runtime>,
      	cumulus_pallet_dmp_queue::DeleteDmpQueue<Runtime>,
      );
      ```
      
      ### XCMP Queue pallet
      
      Removed all dispatch queue functionality. Incoming XCMP messages are now
      either: Immediately handled if they are Signals, enqueued into the MQ
      pallet otherwise.
      
      New config items for the XCMP queue pallet:
      ```rust
      /// The actual queue implementation that retains the messages for later processing.
      type XcmpQueue: EnqueueMessage<ParaId>;
      
      /// How a XCM over HRMP from a sibling parachain should be processed.
      type XcmpProcessor: ProcessMessage<Origin = ParaId>;
      
      /// The maximal number of suspended XCMP channels at the same time.
      #[pallet::constant]
      type MaxInboundSuspended: Get<u32>;
      ```
      
      How to configure those:
      
      ```rust
      // Use the MessageQueue pallet to store messages for later processing. The `TransformOrigin` is needed since
      // the MQ pallet itself operators on `AggregateMessageOrigin` but we want to enqueue `ParaId`s.
      type XcmpQueue = TransformOrigin<MessageQueue, AggregateMessageOrigin, ParaId, ParaIdToSibling>;
      
      // Process XCMP messages from siblings. This is type-safe to only accept `ParaId`s. They will be dispatched
      // with origin `Junction::Sibling(…)`.
      type XcmpProcessor = ProcessFromSibling<
      	ProcessXcmMessage<
      		AggregateMessageOrigin,
      		xcm_executor::XcmExecutor<xcm_config::XcmConfig>,
      		RuntimeCall,
      	>,
      >;
      
      // Not really important what to choose here. Just something larger than the maximal number of channels.
      type MaxInboundSuspended = sp_core::ConstU32<1_000>;
      ```
      
      The `InboundXcmpStatus` storage item was replaced by
      `InboundXcmpSuspended` since it now only tracks inbound queue suspension
      and no message indices anymore.
      
      Now only sends the most recent channel `Signals`, as all prio ones are
      out-dated anyway.
      
      ### Parachain System pallet
      
      For `DMP` messages instead of forwarding them to the `DMP` pallet, it
      now pushes them to the configured `DmpQueue`. The message processing
      which was triggered in `set_validation_data` is now being done by the MQ
      pallet `on_initialize`.
      
      XCMP messages are still handed off to the `XcmpMessageHandler`
      (XCMP-Queue pallet) - no change here.
      
      New config items for the parachain system pallet:
      ```rust
      /// Queues inbound downward messages for delayed processing. 
      ///
      /// Analogous to the `XcmpQueue` of the XCMP queue pallet.
      type DmpQueue: EnqueueMessage<AggregateMessageOrigin>;
      ``` 
      
      How to configure:
      ```rust
      /// Use the MQ pallet to store DMP messages for delayed processing.
      type DmpQueue = MessageQueue;
      ``` 
      
      ## Message Flow
      
      The flow of messages on the parachain side. Messages come in from the
      left via the `Validation Data` and finally end up at the `Xcm Executor`
      on the right.
      
      ![Untitled
      (1)](https://github.com/paritytech/cumulus/assets/10380170/6cf8b377-88c9-4aed-96df-baace266e04d)
      
      ## Further changes
      
      - Bumped the default suspension, drop and resume thresholds in
      `QueueConfigData::default()`.
      - `XcmpQueue::{suspend_xcm_execution, resume_xcm_execution}` errors when
      they would be a noop.
      - Properly validate the `QueueConfigData` before setting it.
      - Marked weight files as auto-generated so they wont auto-expand in the
      MR files view.
      - Move the `hypothetical` asserts to `frame_support` under the name
      `experimental_hypothetically`
      
      Questions:
      - [ ] What about the ugly `#[cfg(feature = \"runtime-benchmarks\")]` in
      the runtimes? Not sure how to best fix. Just having them like this makes
      tests fail that rely on the real message processor when the feature is
      enabled.
      - [ ] Need a good weight for `MessageQueueServiceWeight`. The scheduler
      already takes 80% so I put it to 10% but that is quite low.
      
      TODO:
      - [x] Remove c&p code after
      https://github.com/paritytech/polkadot/pull/6271
      - [x] Use `HandleMessage` once it is public in Substrate
      - [x] fix `runtime-benchmarks` feature
      https://github.com/paritytech/polkadot/pull/6966
      
      
      - [x] Benchmarks
      - [x] Tests
      - [ ] Migrate `InboundXcmpStatus` to `InboundXcmpSuspended`
      - [x] Possibly cleanup Migrations (DMP+XCMP)
      - [x] optional: create `TransformProcessMessageOrigin` in Substrate and
      replace `ProcessFromSibling`
      - [ ] Rerun weights on ref HW
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: command-bot <>
      e1c033eb
    • Branislav Kontur's avatar
  6. Nov 01, 2023
  7. Oct 31, 2023
    • Adel Arja's avatar
      1953 defensive testing extrinsic (#1998) · 6e2f94f8
      Adel Arja authored
      
      
      # Description
      
      The `trigger_defensive` call has been added to the `root-testing`
      pallet. The idea is to have this pallet running on `Rococo/Westend` and
      use it to verify if the runtime monitoring works end-to-end.
      
      To accomplish this, `trigger_defensive` dispatches an event when it is
      called.
      
      Closes #1953
      
      # Checklist
      
      - [x] My PR includes a detailed description as outlined in the
      "Description" section above
      - [ ] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
      of this project (at minimum one label for `T`
        required)
      - [ ] I have made corresponding changes to the documentation (if
      applicable)
      - [ ] I have added tests that prove my fix is effective or that my
      feature works (if applicable)
      
      You can remove the "Checklist" section once all have been checked. Thank
      you for your contribution!
      
      ✄
      -----------------------------------------------------------------------------
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      6e2f94f8
  8. Oct 30, 2023
    • Liam Aharon's avatar
      Improve `try-state` developer experience & fix bug (#2019) · d715caa6
      Liam Aharon authored
      Making some devex improvements as I audit our chains adherence to
      try-state invariants, in preparation for automated try-state checks and
      alerting.
      
      Note to reviewer: while you're here, if you have time would be great to
      get your eyes on https://github.com/paritytech/polkadot-sdk/pull/1297
      also since it touches a similar file and I'd like to avoid merge
      conflicts :P
      
      ## Devex Improvements
      
      - Changes the log level of logs informing the user that try-state checks
      are being run for a pallet from debug to info
      - Improves how errors are communicated
      - Errors are logged when they are encountered, rather than after
      everything has been executed
      - Exact pallet the error originated from is included with the error log
        - Clearly see all errors and how many there are, rather than only one
        - Closes #136 
      
      ### Example of new logs
      
      <img width="1185" alt="Screenshot 2023-10-25 at 15 44 44"
      src="https://github.com/paritytech/polkadot-sdk/assets/16665596/b75588a2-1c64-45df-bbc8-bcb8bf8b0fe0">
      
      ### Same but with old logs (run with RUST_LOG=debug)
      
      Notice only informed of one of the errors, and it's unclear which pallet
      it originated
      
      <img width="1185" alt="Screenshot 2023-10-25 at 15 39 01"
      src="https://github.com/paritytech/polkadot-sdk/assets/16665596/e3429cb1-489e-430a-9716-77c052e5dae6">
       
      
      ## Bug fix
      
      When dry-running migrations and `checks.try_state()` is `true`, only run
      `try_state` checks after migrations have been executed. Otherwise,
      `try_state` checks that expect state to be in at a HIGHER storage
      version than is on-chain could incorrectly fail.
      
      ---------
      
      Co-authored-by: command-bot <>
      d715caa6
  9. Oct 27, 2023
    • juangirini's avatar
      feat: FRAME umbrella crate. (#1337) · 43415ef5
      juangirini authored
      ### Original PR https://github.com/paritytech/substrate/pull/14137
      
      This PR brings in the first version of the "_`frame` umbrella crate_".
      This crate is intended to serve two purposes:
      
      1. documentation
      2. easier development with frame. Ideally, we want most users to be able
      to build a frame-based pallet and runtime using just `frame` (plus
      `scale-codec` and `scale-info`).
      
      The crate is not finalized and is not yet intended for external use.
      Therefore, the version is set to `0.0.1-dev`, this PR is `silent`, and
      the entire crate is hidden behind the `experimental` flag. The main
      intention in merging it early on is to be able to iterate on it in the
      rest of
      [`developer-hub`](https://github.com/paritytech/polkadot-sdk-docs/)
      efforts.
      
      The public API of the `frame` crate is at the moment as follows: 
      
      ```
      pub mod frame
      pub use frame::log
      pub use frame::pallet
      pub mod frame::arithmetic
      pub use frame::arithmetic::<<sp_arithmetic::*>>
      pub use frame::arithmetic::<<sp_arithmetic::traits::*>>
      pub mod frame::deps
      pub use frame::deps::codec
      pub use frame::deps::frame_executive
      pub use frame::deps::frame_support
      pub use frame::deps::frame_system
      pub use frame::deps::scale_info
      pub use frame::deps::sp_api
      pub use frame::deps::sp_arithmetic
      pub use frame::deps::sp_block_builder
      pub use frame::deps::sp_consensus_aura
      pub use frame::deps::sp_consensus_grandpa
      pub use frame::deps::sp_core
      pub use frame::deps::sp_inherents
      pub use frame::deps::sp_io
      pub use frame::deps::sp_offchain
      pub use frame::deps::sp_runtime
      pub use frame::deps::sp_std
      pub use frame::deps::sp_version
      pub mod frame::derive
      pub use frame::derive::CloneNoBound
      pub use frame::derive::Debug
      pub use frame::derive::Debug
      pub use frame::derive::DebugNoBound
      pub use frame::derive::Decode
      pub use frame::derive::Decode
      pub use frame::derive::DefaultNoBound
      pub use frame::derive::Encode
      pub use frame::derive::Encode
      pub use frame::derive::EqNoBound
      pub use frame::derive::PartialEqNoBound
      pub use frame::derive::RuntimeDebug
      pub use frame::derive::RuntimeDebugNoBound
      pub use frame::derive::TypeInfo
      pub use frame::derive::TypeInfo
      pub mod frame::prelude
      pub use frame::prelude::<<frame_support::pallet_prelude::*>>
      pub use frame::prelude::<<frame_system::pallet_prelude::*>>
      pub use frame::prelude::<<sp_std::prelude::*>>
      pub use frame::prelude::CloneNoBound
      pub use frame::prelude::Debug
      pub use frame::prelude::Debug
      pub use frame::prelude::DebugNoBound
      pub use frame::prelude::Decode
      pub use frame::prelude::Decode
      pub use frame::prelude::DefaultNoBound
      pub use frame::prelude::Encode
      pub use frame::prelude::Encode
      pub use frame::prelude::EqNoBound
      pub use frame::prelude::PartialEqNoBound
      pub use frame::prelude::RuntimeDebug
      pub use frame::prelude::RuntimeDebugNoBound
      pub use frame::prelude::TypeInfo
      pub use frame::prelude::TypeInfo
      pub use frame::prelude::frame_system
      pub mod frame::primitives
      pub use frame::primitives::BlakeTwo256
      pub use frame::primitives::H160
      pub use frame::primitives::H256
      pub use frame::primitives::H512
      pub use frame::primitives::Hash
      pub use frame::primitives::Keccak256
      pub use frame::primitives::U256
      pub use frame::primitives::U512
      pub mod frame::runtime
      pub mod frame::runtime::apis
      pub use frame::runtime::apis::<<frame_system_rpc_runtime_api::*>>
      pub use frame::runtime::apis::<<sp_api::*>>
      pub use frame::runtime::apis::<<sp_block_builder::*>>
      pub use frame::runtime::apis::<<sp_consensus_aura::*>>
      pub use frame::runtime::apis::<<sp_consensus_grandpa::*>>
      pub use frame::runtime::apis::<<sp_offchain::*>>
      pub use frame::runtime::apis::<<sp_session::runtime_api::*>>
      pub use frame::runtime::apis::<<sp_transaction_pool::runtime_api::*>>
      pub use frame::runtime::apis::ApplyExtrinsicResult
      pub use frame::runtime::apis::CheckInherentsResult
      pub use frame::runtime::apis::InherentData
      pub use frame::runtime::apis::OpaqueMetadata
      pub use frame::runtime::apis::impl_runtime_apis
      pub use frame::runtime::apis::sp_api
      pub mod frame::runtime::prelude
      pub use frame::runtime::prelude::<<frame_executive::*>>
      pub use frame::runtime::prelude::ConstBool
      pub use frame::runtime::prelude::ConstI128
      pub use frame::runtime::prelude::ConstI16
      pub use frame::runtime::prelude::ConstI32
      pub use frame::runtime::prelude::ConstI64
      pub use frame::runtime::prelude::ConstI8
      pub use frame::runtime::prelude::ConstU128
      pub use frame::runtime::prelude::ConstU16
      pub use frame::runtime::prelude::ConstU32
      pub use frame::runtime::prelude::ConstU64
      pub use frame::runtime::prelude::ConstU8
      pub use frame::runtime::prelude::NativeVersion
      pub use frame::runtime::prelude::RuntimeVersion
      pub use frame::runtime::prelude::construct_runtime
      pub use frame::runtime::prelude::create_runtime_str
      pub use frame::runtime::prelude::derive_impl
      pub use frame::runtime::prelude::frame_support
      pub use frame::runtime::prelude::ord_parameter_types
      pub use frame::runtime::prelude::parameter_types
      pub use frame::runtime::prelude::runtime_version
      pub mod frame::runtime::testing_prelude
      pub use frame::runtime::testing_prelude::BuildStorage
      pub use frame::runtime::testing_prelude::Storage
      pub mod frame::runtime::types_common
      pub type frame::runtime::types_common::AccountId = <<frame::runtime::types_common::Signature as sp_runtime::traits::Verify>::Signer as sp_runtime::traits::IdentifyAccount>::AccountId
      pub type frame::runtime::types_common::BlockNumber = u32
      pub type frame::runtime::types_common::BlockOf<T, Extra> = sp_runtime::generic::block::Block<sp_runtime::generic::header::Header<frame::runtime::types_common::BlockNumber, sp_runtime::traits::BlakeTwo256>, sp_runtime::generic::unchecked_extrinsic::UncheckedExtrinsic<sp_runtime::multiaddress::MultiAddress<frame::runtime::types_common::AccountId, ()>, <T as frame_system::pallet::Config>::RuntimeCall, frame::runtime::types_common::Signature, Extra>>
      pub type frame::runtime::types_common::OpaqueBlock = sp_runtime::generic::block::Block<sp_runtime::generic::header::Header<frame::runtime::types_common::BlockNumber, sp_runtime::traits::BlakeTwo256>, sp_runtime::OpaqueExtrinsic>
      pub type frame::runtime::types_common::Signature = sp_runtime::MultiSignature
      pub type frame::runtime::types_common::SystemSignedExtensionsOf<T> = (frame_system::extensions::check_non_zero_sender::CheckNonZeroSender<T>, frame_system::extensions::check_spec_version::CheckSpecVersion<T>, frame_system::extensions::check_tx_version::CheckTxVersion<T>, frame_system::extensions::check_genesis::CheckGenesis<T>, frame_system::extensions::check_mortality::CheckMortality<T>, frame_system::extensions::check_nonce::CheckNonce<T>, frame_system::extensions::check_weight::CheckWeight<T>)
      pub mod frame::testing_prelude
      pub use frame::testing_prelude::<<frame_executive::*>>
      pub use frame::testing_prelude::<<frame_system::mocking::*>>
      pub use frame::testing_prelude::BuildStorage
      pub use frame::testing_prelude::ConstBool
      pub use frame::testing_prelude::ConstI128
      pub use frame::testing_prelude::ConstI16
      pub use frame::testing_prelude::ConstI32
      pub use frame::testing_prelude::ConstI64
      pub use frame::testing_prelude::ConstI8
      pub use frame::testing_prelude::ConstU128
      pub use frame::testing_prelude::ConstU16
      pub use frame::testing_prelude::ConstU32
      pub use frame::testing_prelude::ConstU64
      pub use frame::testing_prelude::ConstU8
      pub use frame::testing_prelude::NativeVersion
      pub use frame::testing_prelude::RuntimeVersion
      pub use frame::testing_prelude::Storage
      pub use frame::testing_prelude::TestState
      pub use frame::testing_prelude::assert_err
      pub use frame::testing_prelude::assert_err_ignore_postinfo
      pub use frame::testing_prelude::assert_error_encoded_size
      pub use frame::testing_prelude::assert_noop
      pub use frame::testing_prelude::assert_ok
      pub use frame::testing_prelude::assert_storage_noop
      pub use frame::testing_prelude::construct_runtime
      pub use frame::testing_prelude::create_runtime_str
      pub use frame::testing_prelude::derive_impl
      pub use frame::testing_prelude::frame_support
      pub use frame::testing_prelude::frame_system
      pub use frame::testing_prelude::if_std
      pub use frame::testing_prelude::ord_parameter_types
      pub use frame::testing_prelude::parameter_types
      pub use frame::testing_prelude::runtime_version
      pub use frame::testing_prelude::storage_alias
      pub mod frame::traits
      pub use frame::traits::<<frame_support::traits::*>>
      pub use frame::traits::<<sp_runtime::traits::*>>
      ```
      
      ---
      
      The road to full stabilization is
      
      - [ ] https://github.com/paritytech/polkadot-sdk/issues/127
      
      
      - [ ] have a more intentional version bump, as opposed to the current bi
      weekly force-major-bump
      - [ ] revise the internal API of `frame`, especially what goes into the
      `prelude`s.
      - [ ] migrate all internal pallets and runtime to use `frame`
      
      ---------
      
      Co-authored-by: default avatarkianenigma <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      43415ef5
  10. Oct 26, 2023
    • Dastan's avatar
      Expose collection attributes from `Inspect` trait (#1914) · 0bcebac4
      Dastan authored
      # Description
      
      - What does this PR do?
      
      While working with `pallet_nfts` through `nonfungibles_v2` traits
      `Inspect, Mutate`, I found out that once you have set the collection
      attribute with `<Nfts as Mutate>::set_collection_attribute()`, it's not
      possible to read it with `<Nfts as Inspect>::collection_attribute()`
      since they use different `namespace` values. When setting the attribute,
      `AttributeNamespace::Pallet` is used, while
      `AttributeNamespace::CollectionOwner` is used when reading.
      
      more context:
      https://github.com/freeverseio/laos/issues/7#issuecomment-1766137370
      
      This PR makes `item` an optional parameter in
      `Inspect::system_attribute()`, to be able to read collection attributes.
      
      - Why are these changes needed?
      
      To be able to read collection level attributes when reading attributes
      of the collection. It will be possible to read collection attributes by
      passing `None` for `item`
      
      - How were these changes implemented and what do they affect?
      
      `NftsApi` is also affected and `NftsApi::system_attribute()` now accepts
      optional `item` parameter.
      
      ## Breaking change
      
      Because of the change in the `NftsApi::system_attribute()` method's
      `item` param, parachains who integrated the `NftsApi` need to update
      their API code and frontend integrations accordingly. AssetHubs are
      unaffected since the NftsApi wasn't released on those parachains yet.
      0bcebac4
  11. Oct 24, 2023
  12. Oct 23, 2023
  13. Oct 18, 2023
  14. Oct 17, 2023
  15. Oct 16, 2023
  16. Oct 13, 2023
  17. Oct 07, 2023
    • Muharem Ismailov's avatar
      Treasury spends various asset kinds (#1333) · cb944dc5
      Muharem Ismailov authored
      
      
      ### Summary 
      
      This PR introduces new dispatchables to the treasury pallet, allowing
      spends of various asset types. The enhanced features of the treasury
      pallet, in conjunction with the asset-rate pallet, are set up and
      enabled for Westend and Rococo.
      
      ### Westend and Rococo runtimes.
      
      Polkadot/Kusams/Rococo Treasury can accept proposals for `spends` of
      various asset kinds by specifying the asset's location and ID.
      
      #### Treasury Instance New Dispatchables:
      - `spend(AssetKind, AssetBalance, Beneficiary, Option<ValidFrom>)` -
      propose and approve a spend;
      - `payout(SpendIndex)` - payout an approved spend or retry a failed
      payout
      - `check_payment(SpendIndex)` - check the status of a payout;
      - `void_spend(SpendIndex)` - void previously approved spend;
      > existing spend dispatchable renamed to spend_local
      
      in this context, the `AssetKind` parameter contains the asset's location
      and it's corresponding `asset_id`, for example:
      `USDT` on `AssetHub`,
      ``` rust
      location = MultiLocation(0, X1(Parachain(1000)))
      asset_id = MultiLocation(0, X2(PalletInstance(50), GeneralIndex(1984)))
      ```
      
      the `Beneficiary` parameter is a `MultiLocation` in the context of the
      asset's location, for example
      ``` rust
      // the Fellowship salary pallet's location / account
      FellowshipSalaryPallet = MultiLocation(1, X2(Parachain(1001), PalletInstance(64)))
      // or custom `AccountId`
      Alice = MultiLocation(0, AccountId32(network: None, id: [1,...]))
      ```
      
      the `AssetBalance` represents the amount of the `AssetKind` to be
      transferred to the `Beneficiary`. For permission checks, the asset
      amount is converted to the native amount and compared against the
      maximum spendable amount determined by the commanding spend origin.
      
      the `spend` dispatchable allows for batching spends with different
      `ValidFrom` arguments, enabling milestone-based spending. If the
      expectations tied to an approved spend are not met, it is possible to
      void the spend later using the `void_spend` dispatchable.
      
      Asset Rate Pallet provides the conversion rate from the `AssetKind` to
      the native balance.
      
      #### Asset Rate Instance Dispatchables:
      - `create(AssetKind, Rate)` - initialize a conversion rate to the native
      balance for the given asset
      - `update(AssetKind, Rate)` - update the conversion rate to the native
      balance for the given asset
      - `remove(AssetKind)` - remove an existing conversion rate to the native
      balance for the given asset
      
      the pallet's dispatchables can be executed by the Root or Treasurer
      origins.
      
      ### Treasury Pallet
      
      Treasury Pallet can accept proposals for `spends` of various asset kinds
      and pay them out through the implementation of the `Pay` trait.
      
      New Dispatchables:
      - `spend(Config::AssetKind, AssetBalance, Config::Beneficiary,
      Option<ValidFrom>)` - propose and approve a spend;
      - `payout(SpendIndex)` - payout an approved spend or retry a failed
      payout;
      - `check_payment(SpendIndex)` - check the status of a payout;
      - `void_spend(SpendIndex)` - void previously approved spend;
      > existing spend dispatchable renamed to spend_local
      
      The parameters' types of the `spend` dispatchable exposed via the
      pallet's `Config` and allows to propose and accept a spend of a certain
      amount.
      
      An approved spend can be claimed via the `payout` within the
      `Config::SpendPeriod`. Clients provide an implementation of the `Pay`
      trait which can pay an asset of the `AssetKind` to the `Beneficiary` in
      `AssetBalance` units.
      
      The implementation of the Pay trait might not have an immediate final
      payment status, for example if implemented over `XCM` and the actual
      transfer happens on a remote chain.
      
      The `check_status` dispatchable can be executed to update the spend's
      payment state and retry the `payout` if the payment has failed.
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: command-bot <>
      cb944dc5
  18. Oct 03, 2023
  19. Oct 01, 2023
  20. Sep 29, 2023
    • Muharem Ismailov's avatar
      frame-support: `RuntimeDebug\Eq\PartialEq` impls for `Imbalance` (#1717) · 7d4f8296
      Muharem Ismailov authored
      Derive `RuntimeDebug\Eq\PartialEq` but do not bound any generics.
      
      This achieved by using their equivalent no bound versions:
      `EqNoBound\PartialEqNoBound\RuntimeDebugNoBound`.
      
      Deriving with `Debug`, `Eq`, and `PartialEq` for the `Debt` and `Credit`
      type aliases of `Imbalance` is not feasible due to the `OnDrop` and
      `OppositeOnDrop` generic types lacking implementations of the same
      traits.
      
      This absence posed challenges in testing and any scenarios that demanded
      the traits implementations for the type.
      7d4f8296
    • Ankan's avatar
      [NPoS] Fix for Reward Deficit in the pool (#1255) · f820dc0a
      Ankan authored
      closes https://github.com/paritytech/polkadot-sdk/issues/158.
      partially addresses
      https://github.com/paritytech/polkadot-sdk/issues/226.
      
      Instead of fragile calculation of current balance by looking at `free
      balance - ED`, Nomination Pool now freezes ED in the pool reward account
      to restrict an account from going below minimum balance. This also has a
      nice side effect that if ED changes, we know how much is the imbalance
      in ED frozen in the pool and the current required ED. A pool operator
      can diligently top up the pool with the deficit in ED or vice versa,
      withdraw the excess they transferred to the pool.
      
      ## Notable changes
      - New call `adjust_pool_deposit`: Allows to top up the deficit or
      withdraw the excess deposited funds to the pool.
      - Uses Fungible trait (instead of Currency trait). Since NP was not
      doing any locking/reserving previously, no migration is needed for this.
      - One time migration of freezing ED from each of the existing pools (not
      very PoV friendly but fine for relay chain).
      f820dc0a
  21. Sep 27, 2023
  22. Sep 22, 2023
  23. Sep 17, 2023
  24. Sep 13, 2023
    • Liam Aharon's avatar
      Stabilize `VersionedMigration` (#1503) · 72de70c7
      Liam Aharon authored
      `VersionedMigration` has become somewhat widely used for handling
      version bumps in migrations the last few months.
      
      It is currently behind the `experimental` feature flag, requiring every
      pallet that writes a new migration with version bumps to set up the
      `experimental` flag in their own Cargo.tomls, and also for every runtime
      using these pallets to explicitly enable the `experimental` flag for
      each pallet.
      
      This is becoming quite verbose, and I can only see the number of pallets
      requiring the experimental flag increasing for no other reason than
      using what has become a commonly used feature.
      
      Additionally, I'm writing migration docs and would like to avoid
      stepping through how to use the `experimental` feature to get
      `VersionedMigration` working.
      
      Since the feature has been used in production for some time now without
      any reported issues, is becoming commonly used and ready to advertise in
      docs, I feel this is a good time to make it non-experimental.
      72de70c7
  25. Sep 08, 2023
  26. Sep 05, 2023
  27. Aug 31, 2023
  28. Aug 30, 2023
  29. Aug 29, 2023