1. Feb 06, 2024
  2. Jan 31, 2024
    • Oliver Tale-Yazdi's avatar
      [FRAME] Make `core-fellowship` ans `salary` work for swapped members (#3156) · 07e55006
      Oliver Tale-Yazdi authored
      Fixup for https://github.com/paritytech/polkadot-sdk/pull/2587 to make
      the `core-fellowship` crate work with swapped members.
      
      Adds a `MemberSwappedHandler` to the `ranked-collective` pallet that are
      implemented by `core-fellowship+salary`.
      There is are exhaustive tests
      [here](https://github.com/paritytech/polkadot-sdk/blob/72aa7ac17a0e5b16faab5d2992aa2db2e01b05d0/substrate/frame/core-fellowship/src/tests/integration.rs#L338)
      and
      [here](https://github.com/paritytech/polkadot-sdk/blob/ab3cdb05a5ebc1ff841f8dda67edef0ea40bbba5/substrate/frame/salary/src/tests/integration.rs#L224
      
      )
      to check that adding member `1` is equivalent to adding member `0` and
      then swapping.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      07e55006
    • 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 <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      Co-authored-by: default avatargupnik <[email protected]>
      bb8ddc46
  3. Jan 30, 2024
  4. Jan 24, 2024
  5. Jan 22, 2024
  6. Jan 12, 2024
  7. Jan 10, 2024
    • joe petrowski's avatar
      Unique Usernames in Identity Pallet (#2651) · d1f678c0
      joe petrowski authored
      
      
      This PR allows _username authorities_ to issue unique usernames that
      correspond with an account. It also provides two-way lookup, that is
      from `AccountId` to a single, "primary" `Username` (alongside
      `Registration`) and multiple unique `Username`s to an `AccountId`.
      
      Key features:
      
      - Username Authorities added (and removed) via privileged origin.
      - Authorities have a `suffix` and an `allocation`. They can grant up to
      `allocation` usernames. Their `suffix` will be appended to the usernames
      that they issue. A suffix may be up to 7 characters long.
      - Users can ask an authority to grant them a username. This will take
      the form `myusername.suffix`. The entire name (including suffix) must be
      less than or equal to 32 alphanumeric characters.
      - Users can approve a username for themselves in one of two ways (that
      is, authorities cannot grant them arbitrarily):
      - Pre-sign the entire username (including suffix) with a secret key that
      corresponds to their `AccountId` (for keyed accounts, obviously); or
      - Accept the username after it has been granted by an authority (it will
      be queued until accepted) (for non-keyed accounts like pure proxies or
      multisigs).
      - The system does not require any funds or deposits. Users without an
      identity will be given a default one (presumably all fields set to
      `None`). If they update this info, they will need to place the normal
      storage deposit.
      - If a user does not have any username, their first one will be set as
      `Primary`, and their `AccountId` will map to that one. If they get
      subsequent usernames, they can choose which one to be their primary via
      `set_primary_username`.
      - There are some state cleanup functions to remove expired usernames
      that have not been accepted and dangling usernames whose owners have
      called `clear_identity`.
      
      TODO:
      
      - [x] Add migration to runtimes
      - [x] Probably do off-chain migration into People Chain genesis
      - [x] Address a few TODO questions in code (please review)
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarGonçalo Pestana <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      d1f678c0
  8. Jan 06, 2024
  9. Dec 21, 2023
  10. Dec 20, 2023
  11. Dec 19, 2023
  12. Dec 15, 2023
  13. Dec 12, 2023
    • Ross Bulat's avatar
      Staking: Add `deprecate_controller_batch` AdminOrigin call (#2589) · 048a9c27
      Ross Bulat authored
      
      
      Partially Addresses #2500
      
      Adds a `deprecate_controller_batch` call to the staking pallet that is
      callable by `Root` and `StakingAdmin`. To be used for controller account
      deprecation and removed thereafter. Adds
      `MaxControllersDeprecationBatch` pallet constant that defines max
      possible deprecations per call.
      
      - [x] Add `deprecate_controller_batch` call, and
      `MaxControllersInDeprecationBatch` constant.
      - [x] Add tests, benchmark, weights. Tests that weight is only consumed
      if unique pair.
      - [x] Adds `StakingAdmin` origin to staking's `AdminOrigin` type in
      westend runtime.
      - [x] Determined that worst case 5,900 deprecations does fit into
      `maxBlock` `proofSize` and `refTime` in both normal and operational
      thresholds, meaning we can deprecate all controllers for each network in
      one call.
      
      ## Block Weights
      
      By querying `consts.system.blockWeights` we can see that the
      `deprecate_controller_batch` weights fit within the `normal` threshold
      on Polkadot.
      
      #### `controller_deprecation_batch` where i = 5900:
      #### Ref time: 69,933,325,300
      #### Proof size: 21,040,390
      
      ### Polkadot 
      
      ```
      // consts.query.blockWeights
      
      maxBlock: {
              refTime: 2,000,000,000,000
              proofSize: 18,446,744,073,709,551,615
      }
      normal: {
       maxExtrinsic: {
      	refTime: 1,479,873,955,000
      	proofSize: 13,650,590,614,545,068,195
       }
       maxTotal: {
      	refTime: 1,500,000,000,000
      	proofSize: 13,835,058,055,282,163,711
       }
      }
      ```
      
      ### Kusama
      
      ```
      // consts.query.blockWeights
      
        maxBlock: {
          refTime: 2,000,000,000,000
          proofSize: 18,446,744,073,709,551,615
        }
          normal: {
            maxExtrinsic: {
              refTime: 1,479,875,294,000
              proofSize: 13,650,590,614,545,068,195
            }
            maxTotal: {
              refTime: 1,500,000,000,000
              proofSize: 13,835,058,055,282,163,711
            }
      }
      ```
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarGonçalo Pestana <[email protected]>
      048a9c27
  14. Dec 11, 2023
  15. Dec 08, 2023
    • Sam Johnson's avatar
      Tasks: general system for recognizing and executing service work (#1343) · ac3f14d2
      Sam Johnson authored
      `polkadot-sdk` version of original tasks PR located here:
      https://github.com/paritytech/substrate/pull/14329
      
      Fixes #206
      
      ## Status
      - [x] Generic `Task` trait
      - [x] `RuntimeTask` aggregated enum, compatible with
      `construct_runtime!`
      - [x] Casting between `Task` and `RuntimeTask` without needing `dyn` or
      `Box`
      - [x] Tasks Example pallet
      - [x] Runtime tests for Tasks example pallet
      - [x] Parsing for task-related macros
      - [x] Retrofit parsing to make macros optional
      - [x] Expansion for task-related macros
      - [x] Adds support for args in tasks
      - [x] Retrofit tasks example pallet to use macros instead of manual
      syntax
      - [x] Weights
      - [x] Cleanup
      - [x] UI tests
      - [x] Docs
      
      ## Target Syntax
      Adapted from
      https://github.com/paritytech/polkadot-sdk/issues/206#issue-1865172283
      
      
      
      ```rust
      // NOTE: this enum is optional and is auto-generated by the other macros if not present
      #[pallet::task]
      pub enum Task<T: Config> {
          AddNumberIntoTotal {
              i: u32,
          }
      }
      
      /// Some running total.
      #[pallet::storage]
      pub(super) type Total<T: Config<I>, I: 'static = ()> =
      StorageValue<_, (u32, u32), ValueQuery>;
      
      /// Numbers to be added into the total.
      #[pallet::storage]
      pub(super) type Numbers<T: Config<I>, I: 'static = ()> =
      StorageMap<_, Twox64Concat, u32, u32, OptionQuery>;
      
      #[pallet::tasks_experimental]
      impl<T: Config<I>, I: 'static> Pallet<T, I> {
      	/// Add a pair of numbers into the totals and remove them.
      	#[pallet::task_list(Numbers::<T, I>::iter_keys())]
      	#[pallet::task_condition(|i| Numbers::<T, I>::contains_key(i))]
      	#[pallet::task_index(0)]
      	pub fn add_number_into_total(i: u32) -> DispatchResult {
      		let v = Numbers::<T, I>::take(i).ok_or(Error::<T, I>::NotFound)?;
      		Total::<T, I>::mutate(|(total_keys, total_values)| {
      			*total_keys += i;
      			*total_values += v;
      		});
      		Ok(())
      	}
      }
      ```
      
      ---------
      
      Co-authored-by: default avatarNikhil Gupta <[email protected]>
      Co-authored-by: default avatarkianenigma <[email protected]>
      Co-authored-by: Nikhil Gupta <>
      Co-authored-by: default avatarGavin Wood <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatargupnik <[email protected]>
      ac3f14d2
  16. Dec 05, 2023
  17. Nov 29, 2023
    • PG Herveou's avatar
      Contracts: use compiled rust tests (#2347) · 2135fa87
      PG Herveou authored
      see #2189
      
      This PR does the following:
      - Bring the user api functions into a new pallet-contracts-uapi (They
      are currently defined in ink!
      [here])(https://github.com/paritytech/ink/blob/master/crates/env/src/engine/on_chain/ext.rs
      
      )
      - Add older api versions and unstable to the user api trait.
      - Remove pallet-contracts-primitives and bring the types it defined in
      uapi / pallet-contracts
      - Add the infrastructure to build fixtures from Rust files and test it
      works by replacing `dummy.wat` and `call.wat`
      - Move all the doc from wasm/runtime.rs to pallet-contracts-uapi.
      
      This will be done in a follow up:
      - convert the rest of the test from .wat to rust
      - bring risc-v uapi up to date with wasm
      - finalize the uapi host fns, making sure everything is codegen from the
      source host fns in pallet-contracts
      
      ---------
      
      Co-authored-by: default avatarAlexander Theißen <[email protected]>
      2135fa87
  18. Nov 17, 2023
  19. Nov 14, 2023
  20. 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
  21. Nov 03, 2023
    • georgepisaltu's avatar
      Identity pallet improvements (#2048) · 21fbc00d
      georgepisaltu authored
      This PR is a follow up to #1661 
      
      - [x] rename the `simple` module to `legacy`
      - [x] fix benchmarks to disregard the number of additional fields
      - [x] change the storage deposits to charge per encoded byte of the
      identity information instance, removing the need for `fn
      additional(&self) -> usize` in `IdentityInformationProvider`
      - [x] ~add an extrinsic to rejig deposits to account for the change
      above~
      - [ ] ~ensure through proper configuration that the new byte-based
      deposit is always lower than whatever is reserved now~
      - [x] remove `IdentityFields` from the `set_fields` extrinsic signature,
      as per [this
      discussion](https://github.com/paritytech/polkadot-sdk/pull/1661#discussion_r1371703403)
      
      > ensure through proper configuration that the new byte-based deposit is
      always lower than whatever is reserved now
      
      Not sure this is needed anymore. If the new deposits are higher than
      what is currently on chain and users don't have enough funds to reserve
      what is needed, the extrinisc fails and they're basically grandfathered
      and frozen until they add more funds and/or make a change to their
      identity. This behavior seems fine to me. Original idea
      [here](https://github.com/paritytech/polkadot-sdk/pull/1661#issuecomment-1779606319).
      
      > add an extrinsic to rejig deposits to account for the change above
      
      This was initially implemented but now removed from this PR in favor of
      the implementation detailed
      [here](https://github.com/paritytech/polkadot-sdk/pull/2088
      
      ).
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: default avatarjoepetrowski <[email protected]>
      21fbc00d
  22. Nov 01, 2023
    • Ankan's avatar
      [NPoS] Paging reward payouts in order to scale rewardable nominators (#1189) · 00b85c51
      Ankan authored
      helps https://github.com/paritytech/polkadot-sdk/issues/439.
      closes https://github.com/paritytech/polkadot-sdk/issues/473.
      
      PR link in the older substrate repository:
      https://github.com/paritytech/substrate/pull/13498.
      
      # Context
      Rewards payout is processed today in a single block and limited to
      `MaxNominatorRewardedPerValidator`. This number is currently 512 on both
      Kusama and Polkadot.
      
      This PR tries to scale the nominators payout to an unlimited count in a
      multi-block fashion. Exposures are stored in pages, with each page
      capped to a certain number (`MaxExposurePageSize`). Starting out, this
      number would be the same as `MaxNominatorRewardedPerValidator`, but
      eventually, this number can be lowered through new runtime upgrades to
      limit the rewardeable nominators per dispatched call instruction.
      
      The changes in the PR are backward compatible.
      
      ## How payouts would work like after this change
      Staking exposes two calls, 1) the existing `payout_stakers` and 2)
      `payout_stakers_by_page`.
      
      ### payout_stakers
      This remains backward compatible with no signature change. If for a
      given era a validator has multiple pages, they can call `payout_stakers`
      multiple times. The pages are executed in an ascending sequence and the
      runtime takes care of preventing double claims.
      
      ### payout_stakers_by_page
      Very similar to `payout_stakers` but also accepts an extra param
      `page_index`. An account can choose to payout rewards only for an
      explicitly passed `page_index`.
      
      **Lets look at an example scenario**
      Given an active validator on Kusama had 1100 nominators,
      `MaxExposurePageSize` set to 512 for Era e. In order to pay out rewards
      to all nominators, the caller would need to call `payout_stakers` 3
      times.
      
      - `payout_stakers(origin, stash, e)` => will pay the first 512
      nominators.
      - `payout_stakers(origin, stash, e)` => will pay the second set of 512
      nominators.
      - `payout_stakers(origin, stash, e)` => will pay the last set of 76
      nominators.
      ...
      - `payout_stakers(origin, stash, e)` => calling it the 4th time would
      return an error `InvalidPage`.
      
      The above calls can also be replaced by `payout_stakers_by_page` and
      passing a `page_index` explicitly.
      
      ## Commission note
      Validator commission is paid out in chunks across all the pages where
      each commission chunk is proportional to the total stake of the current
      page. This implies higher the total stake of a page, higher will be the
      commission. If all the pages of a validator's single era are paid out,
      the sum of commission paid to the validator across all pages should be
      equal to what the commission would have been if we had a non-paged
      exposure.
      
      ### Migration Note
      Strictly speaking, we did not need to bump our storage version since
      there is no migration of storage in this PR. But it is still useful to
      mark a storage upgrade for the following reasons:
      
      - New storage items are introduced in this PR while some older storage
      items are deprecated.
      - For the next `HistoryDepth` eras, the exposure would be incrementally
      migrated to its corresponding paged storage item.
      - Runtimes using staking pallet would strictly need to wait at least
      `HistoryDepth` eras with current upgraded version (14) for the migration
      to complete. At some era `E` such that `E >
      era_at_which_V14_gets_into_effect + HistoryDepth`, we will upgrade to
      version X which will remove the deprecated storage items.
      In other words, it is a strict requirement that E<sub>x</sub> -
      E<sub>14</sub> > `HistoryDepth`, where
      E<sub>x</sub> = Era at which deprecated storages are removed from
      runtime,
      E<sub>14</sub> = Era at which runtime is upgraded to version 14.
      - For Polkadot and Kusama, there is a [tracker
      ticket](https://github.com/paritytech/polkadot-sdk/issues/433) to clean
      up the deprecated storage items.
      
      ### Storage Changes
      
      #### Added
      - ErasStakersOverview
      - ClaimedRewards
      - ErasStakersPaged
      
      #### Deprecated
      The following can be cleaned up after 84 eras which is tracked
      [here](https://github.com/paritytech/polkadot-sdk/issues/433).
      
      - ErasStakers.
      - ErasStakersClipped.
      - StakingLedger.claimed_rewards, renamed to
      StakingLedger.legacy_claimed_rewards.
      
      ### Config Changes
      - Renamed MaxNominatorRewardedPerValidator to MaxExposurePageSize.
      
      ### TODO
      - [x] Tracker ticket for cleaning up the old code after 84 eras.
      - [x] Add companion.
      - [x] Redo benchmarks before merge.
      - [x] Add Changelog for pallet_staking.
      - [x] Pallet should be configurable to enable/disable paged rewards.
      - [x] Commission payouts are distributed across pages.
      - [x] Review documentation thoroughly.
      - [x] Rename `MaxNominatorRewardedPerValidator` ->
      `MaxExposurePageSize`.
      - [x] NMap for `ErasStakersPaged`.
      - [x] Deprecate ErasStakers.
      - [x] Integrity tests.
      
      ### Followup issues
      [Runtime api for deprecated ErasStakers storage
      item](https://github.com/paritytech/polkadot-sdk/issues/426
      
      )
      
      ---------
      
      Co-authored-by: default avatarJavier Viola <[email protected]>
      Co-authored-by: default avatarRoss Bulat <[email protected]>
      Co-authored-by: command-bot <>
      00b85c51
  23. 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
  24. Oct 30, 2023
  25. 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
  26. Oct 24, 2023
    • georgepisaltu's avatar
      Make `IdentityInfo` generic in `pallet-identity` (#1661) · 91851951
      georgepisaltu authored
      Fixes #179 
      
      # Description
      
      This PR makes the structure containing identity information used in
      `pallet-identity` generic through the pallet `Config`. Additionally, the
      old structure is now available in a separate module called `simple`
      (pending rename) and is compatible with the new interface.
      
      Another change in this PR is that while the `additional` field in
      `IdentityInfo` stays for backwards compatibility reasons, the associated
      costs are stil present in the pallet through the `additional` function
      in the `IdentityInformationProvider` interface. This function is marked
      as deprecated as it is only a temporary solution to the backwards
      compatibility problem we had. In short, we could have removed the
      additional fields in the struct and done a migration, but we chose to
      wait and do it off-chain through the genesis of the system parachain.
      After we move the identity pallet to the parachain, additional fields
      will be migrated into the existing fields and the `additional` key-value
      store will be removed. Until that happens, this interface will provide
      the necessary information to properly account for the associated costs.
      
      Additionally, this PR fixes an unrelated issue; the `IdentityField` enum
      used to represent the fields as bitflags couldn't store more than 8
      fields, even though it was marked as `#[repr(u64)]`. This was because of
      the `derive` implementation of `TypeInfo`, which assumed `u8` semantics.
      The custom implementation of this trait in
      https://github.com/paritytech/polkadot-sdk/commit/0105cc0396b7a53d0b290f48b1225847f6d17321
      
      
      fixes the issue.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: default avatarSam Johnson <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      91851951
    • Kian Paimani's avatar
      Ensure correct variant count in `Runtime[Hold/Freeze]Reason` (#1900) · 35eb133b
      Kian Paimani authored
      closes https://github.com/paritytech/polkadot-sdk/issues/1882
      
      
      
      ## Breaking Changes
      
      This PR introduces a new item to `pallet_balances::Config`:
      
      ```diff
      trait Config {
      ++    type RuntimeFreezeReasons;
      }
      ```
      
      This value is only used to check it against `type MaxFreeze`. A similar
      check has been added for `MaxHolds` against `RuntimeHoldReasons`, which
      is already given to `pallet_balances`.
      
      In all contexts, you should pass the real `RuntimeFreezeReasons`
      generated by `construct_runtime` to `type RuntimeFreezeReasons`. Passing
      `()` would also work, but it would imply that the runtime uses no
      freezes at all.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      35eb133b
  27. Oct 09, 2023
    • David Emett's avatar
      Mixnet integration (#1346) · a808a3a0
      David Emett authored
      See #1345, <https://github.com/paritytech/substrate/pull/14207
      
      >.
      
      This adds all the necessary mixnet components, and puts them together in
      the "kitchen-sink" node/runtime. The components added are:
      
      - A pallet (`frame/mixnet`). This is responsible for determining the
      current mixnet session and phase, and the mixnodes to use in each
      session. It provides a function that validators can call to register a
      mixnode for the next session. The logic of this pallet is very similar
      to that of the `im-online` pallet.
      - A service (`client/mixnet`). This implements the core mixnet logic,
      building on the `mixnet` crate. The service communicates with other
      nodes using notifications sent over the "mixnet" protocol.
      - An RPC interface. This currently only supports sending transactions
      over the mixnet.
      
      ---------
      
      Co-authored-by: default avatarDavid Emett <[email protected]>
      Co-authored-by: default avatarJavier Viola <[email protected]>
      a808a3a0
  28. 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
  29. Sep 29, 2023
    • 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
  30. Sep 28, 2023
    • Xavier Lau's avatar
      Add `MaxTipAmount` for pallet-tips (#1709) · de71fecc
      Xavier Lau authored
      Last week we experienced a governance attack.
      Surprisingly, there was no upper limit on the tip amount.
      
      Due to the mechanism of pallet-fragment-election, the council members
      will be refreshed immediately. Attacker is easy to control the council
      and give a large tip amount.
      de71fecc
  31. Sep 27, 2023
  32. Sep 18, 2023
    • Gonçalo Pestana's avatar
      Implements a variable deposit base calculation for EPM signed submissions (#1547) · 614aa31b
      Gonçalo Pestana authored
      **Note**: This is a lift-and-shift PR from the old substrate and
      polkadot repos, both PRs have been reviewed and audited
      (https://github.com/paritytech/substrate/pull/13983,
      https://github.com/paritytech/polkadot/pull/7140)
      
      ---
      
      This PR implements a generic `BaseDeposit` calculation for signed
      submissions, based on the size of the submission queue.
      
      It adds a new associated type to EPM's config, `type SignedDepositBase`,
      that implements `Convert<usize, BalanceOf<T>>`, which is used to
      calculate the base deposit for signed submissions based on the size of
      the signed submissions queue.
      
      `struct GeometricDepositBase<Balance, Fixed, Inc>` implements the
      convert trait so that the deposit value increases as a geometric
      progression. The deposit base is calculated by `deposit_base =
      fixed_deposit_base * (1 + increase_factor)^n`, where `n` is the term of
      the progression (i.e. the number of signed submissions in the queue).
      `Fixed` and `Inc` generic params are getters for `Balance` and
      `IncreaseFactor` to compute the geometric progression. If
      `IncreaseFactor = 0`, then the signed deposit is constant and equal to
      `Fixed` regardless of the size of the queue.
      
      ### Runtime configs
      
      In Kusama, the progression with 10% increase without changing the
      current signed fixed deposit is: (term == size of the queue)
      
      Term 1: `1,333,333,332,000`
      Term 2: `1,333,333,332,000 * 1.10 = 1,466,666,665,200`
      Term 3: `1,333,333,332,000 * 1.10^2 = 1,613,333,331,200`
      Term 4: `1,333,333,332,000 * 1.10^3 = 1,774,666,664,320`
      Term 5: `1,333,333,332,000 * 1.10^4 = 1,952,133,330,752`
      Term 6: `1,333,333,332,000 * 1.10^5 = 2,147,346,663,827.20`
      Term 7: `1,333,333,332,000 * 1.10^6 = 2,362,081,330,210.92`
      Term 8: `1,333,333,332,000 * 1.10^7 = 2,598,289,463,231.01`
      Term 9: `1,333,333,332,000 * 1.10^8 = 2,858,118,409,554.11`
      Term 10: `1,333,333,332,000 * 1.10^9 = 3,143,930,250,509.52`
      
      Westend:
      
      Term 1: `2,000,000,000,000`
      Term 2: `2,000,000,000,000 * 1.10 = 2,200,000,000,000`
      Term 3: `2,000,000,000,000 * 1.10^2 = 2,420,000,000,000`
      Term 4: `2,000,000,000,000 * 1.10^3 = 2,662,000,000,000`
      Term 5: `2,000,000,000,000 * 1.10^4 = 2,928,200,000,000`
      Term 6: `2,000,000,000,000 * 1.10^5 = 3,221,020,000,000`
      Term 7: `2,000,000,000,000 * 1.10^6 = 3,543,122,000,000`
      Term 8: `2,000,000,000,000 * 1.10^7 = 3,897,434,200,000`
      Term 9: `2,000,000,000,000 * 1.10^8 = 4,287,177,620,000`
      Term 10: `2,000,000,000,000 * 1.10^9 = 4,715,895,382,000`
      
      and in Polkadot, the deposit increase is disabled in the current state
      of the PR, as the increase factor is 0% -- so nothing changes from the
      current behaviour.
      
      Closes https://github.com/paritytech-secops/srlabs_findings/issues/189
      614aa31b
  33. Sep 17, 2023
  34. Aug 25, 2023
  35. Aug 24, 2023
    • Gavin Wood's avatar
      Frame: Agile Coretime Broker pallet (RFC-1) (#14568) · 46bd466e
      Gavin Wood authored
      
      
      * Add Broker pallet
      
      * Flesh out CorePart
      
      * Repotting and fleshing out
      
      * more drafting
      
      * process timeslice
      
      * Test Fungibles completed
      
      * Auctions
      
      * Price morphing
      
      * First tests
      
      * Tidying up config/status
      
      * Docs
      
      * Timeslice todying
      
      * More Timeslice tidying
      
      * Tests]
      
      * Repotting.
      
      * Tests
      
      * Tests
      
      * System InstaPool cores and payout
      
      * Better Relay Test framework
      
      * Tests and instapool fixes
      
      * Support NFT interface
      
      * Proper renewals
      
      * Better events, results
      
      * Test transfer
      
      * Renewal test
      
      * Repot some impls and make dispatchables.
      
      * Better weight
      
      * Test migration
      
      * Document events
      
      * Introduce durations
      
      * Core count
      
      * Allow reassignment
      
      * Better naming
      
      * Error docs
      
      * Docs
      
      * Formatting
      
      * Advance notice period is in RC blocks, not timeslices
      
      * Docs
      
      * Formatting
      
      * Docs
      
      * Missing file
      
      * Added some events
      
      * Events for all dispatchables
      
      * Remove benchmark
      
      * Fix
      
      * Adds benchmark for configure and some basic setup
      
      * Adds benchmark for reserve and unreserve
      
      * Adds a couple of more benchmarks
      
      * Docs
      
      * Event
      
      * Fix
      
      * Adds benchmark for purchase
      
      * Dedup
      
      * Add some weight breakdowns
      
      * Repotting
      
      * Adds more benchmarks
      
      * Renaming and one more event
      
      * Sale event
      
      * Better price API and docs
      
      * Avoid possibility of clobbering renewal record
      
      * Avoid possibility of clobbering renewal record
      
      * Fixes a few benchmarks
      
      * Another test
      
      * More tests
      
      * Drop history test
      
      * Rename and CORE_MASK_BITS constant
      
      * Update frame/broker/src/dispatchable_impls.rs
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Update frame/broker/src/dispatchable_impls.rs
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Update frame/broker/src/dispatchable_impls.rs
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Update frame/broker/src/utility_impls.rs
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Update frame/broker/src/dispatchable_impls.rs
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Update frame/broker/src/mock.rs
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Addresses few review comments
      
      * Addresses few review comments
      
      * Addresses few review comments
      
      * Merge
      
      * Merge
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      * Integrates broker in kitchensink
      
      * Minor update
      
      * Fixes typo
      
      * Moves balance back to u64
      
      * Fixes kitchensink build
      
      * Fixes worst case for assign
      
      * Adds benchmark for process_core_count
      
      * Adds a couple of more benchmarks
      
      * Adds an assert for partition
      
      * Uses max_timeslices as input in claim_revenue benchmark
      
      * Adds benchmark for drop_renewal
      
      * Adds benchmark for process_core_schedule
      
      * Adds benchmark for process_pool
      
      * Adds assertion for transfer
      
      * Fixes benchmark for broker in kitchensink
      
      * Adds todo for process_revenue benchmark
      
      * Minor update
      
      * Fix for pool revenue history
      
      * remove TODOs
      
      * Fix tests
      
      * Document CoretimeInterface
      
      * rename part to mask
      
      * Fixes
      
      * Grumble
      
      * ".git/.scripts/commands/bench/bench.sh" --subcommand=pallet --runtime=dev --target_dir=substrate --pallet=pallet_broker
      
      * Adds benchmark for drop_history and fixes worst case for claim_revenue
      
      * Adds drop_history in WeightInfo
      
      * ".git/.scripts/commands/bench/bench.sh" --subcommand=pallet --runtime=dev --target_dir=substrate --pallet=pallet_broker
      
      * Minor fix for Quick Benchmark CI
      
      * Fixes
      
      * Docs
      
      * Headers
      
      * Expose a couple of APIs for benchmarking (#14688)
      
      * Expose a couple of APIs for benchmarking
      
      * Adds doc
      
      * Minor fix in CoretimeInterface impl for kitchensik
      
      * Minor
      
      * Cap renewal price
      
      * Adds a few tests
      
      * Adds more tests
      
      * Minor updates
      
      * Adds a test for an edge case
      
      * Fixes feature propagation
      
      * Fixes feature propagation
      
      * Adds doc fix
      
      * Syntax nits
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Reuse Bit assign functions
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Bitwise tests
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * adapt_price: Edge case for sold == target
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Add sanity checking to ConfigRecord
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Add deny(missing_docs) where possible
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * partition: forbid pivot_offset == 0
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Sort features
      
      zepter format features
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Import Zero from new location
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Clippy: remove redundant clone
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * try to fix build
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      * Fix CI
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarNikhil Gupta <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: command-bot <>
      46bd466e
    • juangirini's avatar
      Restructure `frame_benchmarking` macro related exports (#14787) · bc2b3d9d
      juangirini authored
      
      
      * make reexports private
      
      * make reexports private 2
      
      * make reexports private for runtime-benchmarking
      
      * make reexports private for try-runtime
      
      * fix for try-runtime
      
      * make reexports private for tests
      
      * fmt
      
      * make reexports private for tests
      
      * make reexports private for experimental
      
      * fix beefy
      
      * fix ui test
      
      * fix ui test
      
      * fix benches
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      * fix contracts use
      
      * wip
      
      * wip
      
      * do not reexport sp_api::metadata_ir
      
      * fix CI checks
      
      * fix support tests
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      * Update frame/support/src/lib.rs
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      
      * import codec directly
      
      * fmt
      
      * wip
      
      * wip
      
      * remove benchmarking private exports
      
      * fix zepter warning
      
      * fix imports
      
      * partially fix node-cli tests
      
      * fix node-cli tests
      
      * fix node-cli build
      
      * fix zepter warning
      
      * fix test
      
      * fix ui test
      
      * fix ci
      
      * remove unnecessary imports
      
      * add import back
      
      * add import back
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      bc2b3d9d