closes https://github.com/polkadot-fellows/help-center/issues/1

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: Oliver Tale-Yazdi <[email protected]>

Moves `pallet_mmr` back behind `pallet_session` to address
polkadot-fellows/runtimes#160.

Opening draft for CI - should be merged or closed depending on outcome
of w3f/polkadot-spec#718.

---------

Co-authored-by: Adrian Catangiu <[email protected]>

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: Keith Yeung <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: command-bot <>

## 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: Richard Melkonian <[email protected]>
Co-authored-by: command-bot <>

Clean up all the old syntax.

---------

Co-authored-by: command-bot <>
Co-authored-by: gupnik <[email protected]>
Co-authored-by: Nikhil Gupta <[email protected]>
Co-authored-by: Maksym H <[email protected]>

Backport of https://github.com/paritytech/polkadot-sdk/pull/1863 to
master

Extend candidate sanitation in paras_inherent by removing backing votes
from disabled validators. Check
https://github.com/paritytech/polkadot-sdk/issues/1592 for more details.

This change is related to the disabling strategy implementation
(https://github.com/paritytech/polkadot-sdk/pull/2226).

---------

Co-authored-by: ordian <[email protected]>
Co-authored-by: ordian <[email protected]>
Co-authored-by: Maciej <[email protected]>

Order:

- [x] Start People Chain
- [RPC
node](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-people-rpc.polkadot.io#/explorer)
- [x] Upgrade Rococo Relay (`EnsureRoot` -> `EnsureSigned`) (v1,006,002)
- Done
[here](https://rococo.subscan.io/extrinsic/0xef07e0f9dbb2b9e829305f132e6ce45d291239286e409177e20895e6687daa6c)
- [x] Migrate all identities
- Done, see extrinsics from [this
account](https://rococo.subscan.io/account/5FyNYrBwndvBttTkGUqGGCRAXtBH4Mh8xELDaxaFywTsjDKb)
- [x] Upgrade Rococo People (remove call filter) (v1,006,002)
- Authorized
[here](https://rococo.subscan.io/extrinsic/0xedf6a80229bd411b7ed8d3a489a767b0f773bed5c49239987a294c293a35b98b)

With added:

- [x] Upgrade Rococo People to fix `poke_deposit` bug (v1,006,001)
- Authorized
[here](https://rococo.subscan.io/extrinsic/0xd1dc3cd6e8274bd0196f8d9f13ed09f6e9c76e6a40f9786a1629f4cb22cf948d)

Note:

It's also possible to remove the Identity Migrator pallet from both the
Relay Chain and the parachain at this time. I will leave them in for now
to preserve the test cases until we run them on Kusama/Polkadot. We will
also want a follow up to remove all Identity-related state from the
Relay Chain.

# 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: Keith Yeung <[email protected]>

Co-authored-by: command-bot <>

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: Liam Aharon <[email protected]>
Co-authored-by: Gonçalo Pestana <[email protected]>
Co-authored-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Dónal Murray <[email protected]>

Related to https://github.com/paritytech/polkadot-sdk/issues/2787

Adding BEEFY support to the kitchensink chain in order to be able to
extend the current warp sync zombienet tests with BEEFY enabled

And have proper benchmarks.

---------

Co-authored-by: eskimor <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: joe petrowski <[email protected]>

Rococo and Westend runtimes for the "People Chain". This chain contains
the Identity pallet with plans to migrate all related data from the
Relay Chain.

Changes `IdentityInfo` to:

- Remove `additional_fields`.
- Add `github` and `discord` as first class fields. From scraping chain
data, these were the only two additional fields used (for the Fellowship
and Ambassador Program, respectively).
- Rename `riot` to `matrix`.

Note: This will use the script in
https://github.com/paritytech/polkadot-sdk/pull/2025 to generate the
genesis state.

TODO:

- [x] https://github.com/paritytech/polkadot-sdk/pull/1814 and
integration of the Identity Migrator pallet for migration.
- [x] Tests: https://github.com/paritytech/polkadot-sdk/pull/2373

---------

Co-authored-by: Muharem <[email protected]>
Co-authored-by: Michal Kucharczyk <[email protected]>
Co-authored-by: Dónal Murray <[email protected]>
Co-authored-by: Richard Melkonian <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>

Also fixes: https://github.com/paritytech/polkadot-sdk/issues/1417

- [x] CoreIndex -> AssignmentProvider mapping will be able to change any
time.
- [x] Implement
- [x] Provide Migrations
- [x] Add and fix tests
- [x] Implement bulk assigner logic
- [x] bulk assigner tests
- [x] Port over current assigner to use bulk designer (+ share on-demand
with bulk): top-level assigner has core ranges: legacy, bulk
- [x] Adjust migrations to reflect new assigner structure
- [x] Move migration code to Assignment code directly and make it
recursive (make it possible to skip releases) -> follow up ticket.
- [x] Test migrations
- [x] Add migration PR to runtimes repo -> follow up ticket.
- [x] Wire up with actual UMP messages
- [x] Write PR docs

---------

Co-authored-by: eskimor <[email protected]>
Co-authored-by: Bradley Olson <[email protected]>
Co-authored-by: BradleyOlson64 <[email protected]>
Co-authored-by: Anton Vilhelm Ásgeirsson <[email protected]>
Co-authored-by: antonva <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Marcin S. <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: command-bot <>

Adds the `authorize_upgrade` -> `enact_authorized_upgrade` pattern to
`frame-system`. This will be useful for upgrading bridged chains that
are under the governance of Polkadot without passing entire runtime Wasm
blobs over a bridge.

Notes:

- Changed `enact_authorized_upgrade` to `apply_authorized_upgrade`.
Personal opinion, "apply" more accurately expresses what it's doing. Can
change back if outvoted.
- Remove `check_version` in favor of two extrinsics, so as to make
_checked_ the default.
- Left calls in `parachain-system` and marked as deprecated to prevent
breaking the API. They just call into the `frame-system` functions.
- Updated `frame-system` benchmarks to v2 syntax.

---------

Co-authored-by: command-bot <>

In the move from the old `Currency` traits to the new `fungible/s`
family of traits, we already had the `FungiblesAdapter` and
`NonFungiblesAdapter` for multiple fungible and non fungible assets
respectively. However, for handling only one fungible asset, we were
missing a `FungibleAdapter`, and so used the old `CurrencyAdapter`
instead. This PR aims to fill in that gap, and provide the new adapter
for more updated examples.

I marked the old `CurrencyAdapter` as deprecated as part of this PR, and
I'll change it to the new `FungibleAdapter` in a following PR.
The two stages are separated so as to not bloat this PR with some name
fixes in tests.

---------

Co-authored-by: command-bot <>

This PR backports `transaction_version` bump from `1.5.0` release back
to `master`

Initial implementation for the plan discussed here: https://github.com/paritytech/polkadot-sdk/issues/701
Built on top of https://github.com/paritytech/polkadot-sdk/pull/1178
v0: https://github.com/paritytech/polkadot/pull/7554,

## Overall idea

When approval-voting checks a candidate and is ready to advertise the
approval, defer it in a per-relay chain block until we either have
MAX_APPROVAL_COALESCE_COUNT candidates to sign or a candidate has stayed
MAX_APPROVALS_COALESCE_TICKS in the queue, in both cases we sign what
candidates we have available.

This should allow us to reduce the number of approvals messages we have
to create/send/verify. The parameters are configurable, so we should
find some values that balance:

- Security of the network: Delaying broadcasting of an approval
shouldn't but the finality at risk and to make sure that never happens
we won't delay sending a vote if we are past 2/3 from the no-show time.
- Scalability of the network: MAX_APPROVAL_COALESCE_COUNT = 1 &
MAX_APPROVALS_COALESCE_TICKS =0, is what we have now and we know from
the measurements we did on versi, it bottlenecks
approval-distribution/approval-voting when increase significantly the
number of validators and parachains
- Block storage: In case of disputes we have to import this votes on
chain and that increase the necessary storage with
MAX_APPROVAL_COALESCE_COUNT * CandidateHash per vote. Given that
disputes are not the normal way of the network functioning and we will
limit MAX_APPROVAL_COALESCE_COUNT in the single digits numbers, this
should be good enough. Alternatively, we could try to create a better
way to store this on-chain through indirection, if that's needed.

## Other fixes:
- Fixed the fact that we were sending random assignments to
non-validators, that was wrong because those won't do anything with it
and they won't gossip it either because they do not have a grid topology
set, so we would waste the random assignments.
- Added metrics to be able to debug potential no-shows and
mis-processing of approvals/assignments.

## TODO:
- [x] Get feedback, that this is moving in the right direction. @ordian
@sandreim @eskimor

 @burdges, let me know what you think.
- [x] More and more testing.
- [x]  Test in versi.
- [x] Make MAX_APPROVAL_COALESCE_COUNT &
MAX_APPROVAL_COALESCE_WAIT_MILLIS a parachain host configuration.
- [x] Make sure the backwards compatibility works correctly
- [x] Make sure this direction is compatible with other streams of work:
https://github.com/paritytech/polkadot-sdk/issues/635 &
https://github.com/paritytech/polkadot-sdk/issues/742
- [x] Final versi burn-in before merging

---------

Signed-off-by: Alexandru Gheorghe <[email protected]>

This PR introduces a script and some templates to use the prdoc involved
in a release and build:
- the changelog
- a simple draft of audience documentation

Since the prdoc presence was enforced in the middle of the version
1.5.0, not all PRs did come with a `prdoc` file.
This PR creates all the missing `prdoc` files with some minimum content
allowing to properly generate the changelog.
The generated content is **not** suitable for the audience
documentation.

The audience documentation will be possible with the next version, when
all PR come with a proper `prdoc`.

## Assumptions

- the prdoc files for release `vX.Y.Z` have been moved under
`prdoc/X.Y.Z`
- the changelog requires for now for the prdoc files to contain author +
topic. Thos fields are optional.

The build script can  be called as:
```
VERSION=X.Y.Z ./scripts/release/build-changelogs.sh
```

Related:
-  #1408

---------

Co-authored-by: EgorPopelyaev <[email protected]>

This PR makes the block number provider configurable through the Config
trait in pallet-vesting, this gives parachains the option to use the
relay chain block number provider from ParachainSystem.

---------

Co-authored-by: Bastian Köcher <[email protected]>

Closes: https://github.com/paritytech/polkadot-sdk/issues/2641

# Motivation (+testing)

### Enable easy `ForeignAssets` transfers using `pallet-xcm` 

We had just previously added capabilities to teleport fees during
reserve-based transfers, but what about reserve-transferring fees when
needing to teleport some non-fee asset?

This PR aligns everything under either explicit reserve-transfer,
explicit teleport, or this new flexible `transfer_assets()` which can
mix and match as needed with fewer artificial constraints imposed to the
user.

This will enable, for example, a (non-system) parachain to teleport
their `ForeignAssets` assets to AssetHub while using DOT to pay fees.
(the assets are teleported - as foreign assets should from their owner
chain - while DOT used for fees can only be reserve-based transferred
between said parachain and AssetHub).

Added `xcm-emulator` tests for this scenario ^.

# Description

Reverts `(limited_)reserve_transfer_assets` to only allow reserve-based
transfers for all `assets` including fees.

Similarly `(limited_)teleport_assets` only allows teleports for all
`assets` including fees.
    
For complex combinations of asset transfers where assets and fees may
have different reserves or different reserve/teleport trust
configurations, users can use the newly added `transfer_assets()`
extrinsic which is more flexible in allowing more complex scenarios.

`assets` (excluding `fees`) must have same reserve location or otherwise
be teleportable to `dest`.
No limitations imposed on `fees`.

- for local reserve: transfer assets to sovereign account of destination
chain and forward a notification XCM to `dest` to mint and deposit
reserve-based assets to `beneficiary`.
- for destination reserve: burn local assets and forward a notification
to `dest` chain to withdraw the reserve assets from this chain's
sovereign account and deposit them to `beneficiary`.
- for remote reserve: burn local assets, forward XCM to reserve chain to
move reserves from this chain's SA to `dest` chain's SA, and forward
another XCM to `dest` to mint and deposit reserve-based assets to
`beneficiary`.
- for teleports: burn local assets and forward XCM to `dest` chain to
mint/teleport assets and deposit them to `beneficiary`.

## Review notes

Only around 500 lines are prod code (see `pallet_xcm/src/lib.rs`), the
rest of the PR is new tests and improving existing tests.

---------

Co-authored-by: command-bot <>

Follow up to fix a bug from #1814 discovered in XCM emulator testing.

I mistakenly thought that checking out an asset would withdraw it from
the sender. This actually withdraws the asset before checking out.

---------

Co-authored-by: Adrian Catangiu <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>

The `BlockNumber` and `Hash` are fixed types any way.

Co-authored-by: ordian <[email protected]>
Co-authored-by: Vladimir Istyufeev <[email protected]>

## Overview

This PR aligns the `spec_version` formatting to the [recent
changes](https://github.com/polkadot-fellows/runtimes/pull/26/files#diff-efa4caeb17487ecb13d8f5eb7863c3241d84afa2e73fbf25909a2ca89df0f362R142)
made for the Polkadot/Kusama runtimes.

It also backports the latest version `v1.4.0` bumps as `1_004_000`.

## Details

During the switch from `v0.9` to `v1.x`, the format of the
`spec_version` was modified from: `(M)m_ppp` for a runtime considered on
version `M.m.pp`. For instance `0.9.42` had a `spec_version` of `9420`.

With the transition to `v1.x`, the format was changed to a bigger number
(still `u32`) formatted as `MM_mm_ppp` where `1.2.3` would be stored as
`01_02_003`.

This PR aligns the format with that has been introduced in the
fellowship repo: `MMM_mmm_ppp`.

---------

Co-authored-by: Bastian Köcher <[email protected]>

Missed in https://github.com/paritytech/polkadot-sdk/pull/1672

The goal of this PR is to migrate Identity deposits from the Relay Chain
to a system parachain.

The problem I want to solve is that `IdentityOf` and `SubsOf` both store
an amount that's held in reserve as a storage deposit. When migrating to
a parachain, we can take a snapshot of the actual `IdentityInfo` and
sub-account mappings, but should migrate (off chain) the `deposit`s to
zero, since the chain (and by extension, accounts) won't have any funds
at genesis.

The good news is that we expect parachain deposits to be significantly
lower (possibly 100x) on the parachain. That is, a deposit of 21 DOT on
the Relay Chain would need 0.21 DOT on a parachain. This PR proposes to
migrate the deposits in the following way:

1. Introduces a new pallet with two extrinsics: 
- `reap_identity`: Has a configurable `ReapOrigin`, which would be set
to `EnsureSigned` on the Relay Chain (i.e. callable by anyone) and
`EnsureRoot` on the parachain (we don't want identities reaped from
there).
- `poke_deposit`: Checks what deposit the pallet holds (at genesis,
zero) and attempts to update the amount based on the calculated deposit
for storage data.
2. `reap_identity` clears all storage data for a `target` account and
unreserves their deposit.
3. A `ReapIdentityHandler` teleports the necessary DOT to the parachain
and calls `poke_deposit`. Since the parachain deposit is much lower, and
was just unreserved, we know we have enough.

One awkwardness I ran into was that the XCMv3 instruction set does not
provide a way for the system to teleport assets without a fee being
deducted on reception. Users shouldn't have to pay a fee for the system
to migrate their info to a more efficient location. So I wrote my own
program and did the `InitiateTeleport` accounting on my own to send a
program with `UnpaidExecution`. Have discussed an
`InitiateUnpaidTeleport` instruction with @franciscoaguirre

 . Obviously
any chain executing this would have to pass a `Barrier` for free
execution.

TODO:

- [x] Confirm People Chain ParaId
- [x] Confirm People Chain deposit rates (determined in
https://github.com/paritytech/polkadot-sdk/pull/2281)
- [x] Add pallet to Westend

---------

Co-authored-by: Bastian Köcher <[email protected]>

Adds a `NodeFeatures` bitfield value to the runtime `HostConfiguration`,
with the purpose of coordinating the enabling of node-side features,
such as: https://github.com/paritytech/polkadot-sdk/issues/628 and
https://github.com/paritytech/polkadot-sdk/issues/598.
These are features that require all validators enable them at the same
time, assuming all/most nodes have upgraded their node versions.

This PR doesn't add any feature yet. These are coming in future PRs.

Also adds a runtime API for querying the state of the client features
and an extrinsic for setting/unsetting a feature by its index in the bitfield.

Note: originally part of:
https://github.com/paritytech/polkadot-sdk/pull/1644, but posted as
standalone to be reused by other PRs until the initial PR is merged

## Motivation

`pallet-xcm` is the main user-facing interface for XCM functionality,
including assets manipulation functions like `teleportAssets()` and
`reserve_transfer_assets()` calls.

While `teleportAsset()` works both ways, `reserve_transfer_assets()`
works only for sending reserve-based assets to a remote destination and
beneficiary when the reserve is the _local chain_.

## Solution

This PR enhances `pallet_xcm::(limited_)reserve_withdraw_assets` to
support transfers when reserves are other chains.
This will allow complete, **bi-directional** reserve-based asset
transfers user stories using `pallet-xcm`.

Enables following scenarios:
- transferring assets with local reserve (was previously supported iff
asset used as fee also had local reserve - now it works in all cases),
- transferring assets with reserve on destination,
- transferring assets with reserve on remote/third-party chain (iff
assets and fees have same remote reserve),
- transferring assets with reserve different than the reserve of the
asset to be used as fees - meaning can be used to transfer random asset
with local/dest reserve while using DOT for fees on all involved chains,
even if DOT local/dest reserve doesn't match asset reserve,
- transferring assets with any type of local/dest reserve while using
fees which can be teleported between involved chains.

All of the above is done by pallet inner logic without the user having
to specify which scenario/reserves/teleports/etc. The correct scenario
and corresponding XCM programs are identified, and respectively, built
automatically based on runtime configuration of trusted teleporters and
trusted reserves.

#### Current limitations:
- while `fees` and "non-fee" `assets` CAN have different reserves (or
fees CAN be teleported), the remaining "non-fee" `assets` CANNOT, among
themselves, have different reserve locations (this is also implicitly
enforced by `MAX_ASSETS_FOR_TRANSFER=2`, but this can be safely
increased in the future).
- `fees` and "non-fee" `assets` CANNOT have **different remote**
reserves (this could also be supported in the future, but adds even more
complexity while possibly not being worth it - we'll see what the future
holds).

Fixes https://github.com/paritytech/polkadot-sdk/issues/1584
Fixes https://github.com/paritytech/polkadot-sdk/issues/2055

---------

Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Branislav Kontur <[email protected]>

Remove the `GRANDPA_AUTHORITIES_KEY` key and its usage. Apparently this
was used in the early days to communicate the grandpa authorities to the
node. However, we have now a runtime api that does this for us. So, this
pull request is moving from the custom managed storage item to a FRAME
managed storage item.

This pr also includes a migration for doing the switch on a running
chain.

---------

Co-authored-by: Davide Galassi <[email protected]>

We are introducing a new set of `XcmController` traits (final name yet
to be determined).
These traits are implemented by `pallet-xcm` and allows other pallets,
such as `pallet_contracts`, to rely on these traits instead of tight
coupling them to `pallet-xcm`.

Using only the existing Xcm traits would mean duplicating the logic from
`pallet-xcm` in these other pallets, which we aim to avoid. Our
objective is to ensure that when these APIs are called from
`pallet-contracts`, they produce the exact same outcomes as if called
directly from `pallet-xcm`.

The other benefits is that we can also expose return values to
`pallet-contracts` instead of just calling `pallet-xcm` dispatchable and
getting a `DispatchResult` back.

See traits integration in this PR
https://github.com/paritytech/polkadot-sdk/pull/1248, where the traits
are used as follow to define and implement `pallet-contracts` Config.
```rs
// Contracts config:
pub trait Config: frame_system::Config {
  // ...

  /// A type that exposes XCM APIs, allowing contracts to interact with other parachains, and
  /// execute XCM programs.
  type Xcm: xcm_executor::traits::Controller<
	  OriginFor<Self>,
	  <Self as frame_system::Config>::RuntimeCall,
	  BlockNumberFor<Self>,
  >;
}

// implementation
impl pallet_contracts::Config for Runtime {
        // ...

	type Xcm = pallet_xcm::Pallet<Self>;
}
```

---------

Co-authored-by: Alexander Theißen <[email protected]>
Co-authored-by: command-bot <>

As suggested by @ggwpez
(https://github.com/paritytech/polkadot-sdk/pull/2142#discussion_r1388145872),
remove the `VersionChecked` prefix from version checked migrations (but
leave `VersionUnchecked` prefixes)

---------

Co-authored-by: command-bot <>

One for local networks with `fast-runtime` feature activated (1 minute
sessions) and one without the feature activated that will be the default
that runs with 1 hour long sessions.

Changes:
- Adds a new call `remove_key` to the sudo pallet to permanently remove
the sudo key.
- Remove some clones and general maintenance

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: command-bot <>

This PR exposes a `force_remove_vesting` through a ROOT call. 
See linked
[issue](https://github.com/paritytech/polkadot-sdk/issues/269)

---------

Co-authored-by: georgepisaltu <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: Dónal Murray <[email protected]>

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: georgepisaltu <[email protected]>
Co-authored-by: joepetrowski <[email protected]>

# 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: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Oliver Tale-Yazdi <[email protected]>