---
# System prepended metadata

title: Polkadot Release Analysis v1.1.0

---

# Polkadot Release Analysis v1.1.0



:warning: ***The following report is not an exhaustive list of changes included in the release, but a set of changes that we felt deserved to be highlighted due to their impact on the Polkadot ecosystem builders.*** 

***Please do not stop reading the [release notes v1.1.0](https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-v1.1.0). This report is complementary to the changelogs, not a replacement.*** 

***Highlights are categorized into High Impact, Medium Impact, and Low Impact for ease of navigation.***
***Also there is a section related to all note worthy changes related to tooling integration.***

[Help us improve the release analysis by filling out this 6 question survey.](https://forms.gle/mdneyTfvYDtXftaX9)


# Summary

In the following report we are featuring some of the changes included in the [polkadot node release 1.1.0](https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-v1.1.0). All the runtime changes that are part of this release will be included in the corresponding [runtime release](https://github.com/polkadot-fellows/runtimes/releases) done by the fellowship.

Next to every PR name you can find the code base related to these changes. The notation is as follows
- [S]: Changes related to Substrate
- [P]: Changes related to Polkadot
- [C]: Changes related to Cumulus
- [S/P/C]: Changes related to a combination of the noted code bases.
    


## Runtime Migrations
    
- [`pallet-contracts` to v13](https://github.com/paritytech/substrate/blob/9a888e548edfe696c3addb2339b0c50abdb71efd/frame/contracts/src/migration/v13.rs) in [substrate#14079](https://github.com/paritytech/substrate/pull/14079)
- [`pallet-contracts` to v14](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/contracts/src/migration/v14.rs) in [substrate#14020](#Contracts-migrate-to-fungible-traits)
- [`pallet-contracts` to v15](https://github.com/paritytech/substrate/blob/63ae66a592f6a95c4df101a8c69f3d138e7ae91f/frame/contracts/src/migration/v15.rs) in [substrate#14589](https://github.com/paritytech/substrate/pull/14589)

    
## :hammer_and_wrench: Tooling Section

* Sidecar - [v17.2.0](https://github.com/paritytech/substrate-api-sidecar/releases/tag/v17.2.0)
* Txwrapper - [v7.0.1](https://github.com/paritytech/txwrapper-core/releases/tag/v7.0.1)
* PolkadotJS - [v10.9.1](https://github.com/polkadot-js/api/releases/tag/v10.9.1)
* AssetTransferApi - [v0.1.0](https://github.com/paritytech/asset-transfer-api/releases/tag/v0.1.0)
    
    

---

# ❗️ High Impact

### [S] Frame: Agile Coretime Broker pallet (RFC-1)
PR:  https://github.com/paritytech/substrate/pull/14568

**Why is this important?**
    
This pallet is the brokerage tool for managing Polkadot Core scheduling. It is the implementation of [polkadot-fellows/RFCs#1](https://github.com/polkadot-fellows/RFCs/pull/1). 

**How does this impact the Polkadot builders?**
    
As we prepare to migrate from slot auctions to core scheduling, it is recommended to start to become familiar with how Polkadot Core scheduling works.
    
The best way to start is by reading [RFC-0001 Agile Coretime](https://github.com/polkadot-fellows/RFCs/pull/1).
    
---

# ⚠️ Medium Impact
    
### [C] Asynchronous-backing compatible Aura, not plugged in
PR:  https://github.com/paritytech/cumulus/pull/2573


    
**Why is this important?**
    
This PR is part of a series of PRs to prepare Cumulus collators for more advanced parachain protocol features such as [asynchronous backing](https://polkadot-blockchain-academy.github.io/pba-book/polkadot/async-backing-shallow/page.html), [elastic scaling](https://polkadot-blockchain-academy.github.io/pba-book/polkadot/blockspace/page.html?highlight=elastic%20scaling#elastic-scaling-planned-upgrade), and [blockspace regions](https://forum.polkadot.network/t/unifying-bulk-and-mid-term-blockspace-with-strided-regions/2228). This PR in particular preps AURA for asynchronous backing compatibility according to what was laid out in issue [#2476](https://github.com/paritytech/cumulus/issues/2476). It is meant to be backwards compatible to the already existing collation logic and it is still dependent on some updates on how the Polkadot node receives collation in order for it to go fully live.
    
**How does this impact the Polkadot builders?**
    
If you're not familiar with asynchronous backing, elastic scaling, and blockspace regions, it is a good time to start familiarizing yourself with these more advanced parachain protocol features so that you're ahead of the curve when these changes land in Cumulus and Polkadot.
    
Related Issue: [#841](https://github.com/paritytech/cumulus/issues/841)
    
---

### [S] Contracts Add deposit for dependencies
PR:  https://github.com/paritytech/substrate/pull/14079


    
**Why is this important?**
    
As a part of this PR, some changes have been made in [pallet-contracts](https://marketplace.substrate.io/pallets/pallet-contracts) to prevent a contract to be removed when it's invoked via `delegate_call`. 
    
This PR introduces the following changes:

1. Two new runtime functions:

`add_delegate_dependency`: ensures that the delegated contract is not removed while it is still in use and also charges a fraction of the code deposit, which is configured in `CodeHashLockupDepositPercent`.

`remove_delegate_dependency`: This is the counterpart of the above function and refunds the deposit that was charged by `add_delegate_dependency`.
    
2. Two new configuration fields:
    
`type MaxDelegateDependencies: Get<u32>;`
    
`type CodeHashLockupDepositPercent: Get<Perbill>;`

    
**How to use?**

 If you are using this pallet, you have to add these two new type parameters in the runtime otherwise compilation would fail.
To avoid compilation failure:

```rust
pub CodeHashLockupDepositPercent: Perbill = Perbill::from_percent(30); 
impl pallet_contracts::Config for Runtime {
  // .. snip
  type MaxDelegateDependencies = ConstU32<32>;
  type CodeHashLockupDepositPercent = CodeHashLockupDepositPercent;
} 
```

For more details, please check the PR description.


Cumulus Companion: [#2913](https://github.com/paritytech/cumulus/pull/2913)

---
    
### [S] Pallets: Asset Rate - Rename AssetId to AssetKind, Introduce AssetKindFactory Trait
PR:  https://github.com/paritytech/substrate/pull/14514

    
**Why is this important?**
    
[Asset Rate Pallet](https://paritytech.github.io/substrate/master/pallet_asset_rate/index.html#asset-rate-pallet) provides means of setting conversion rates for some asset to native balance. As a part of this PR, `AssetId` type parameter has been renamed to `AssetKind` to avoid naming collisions. This type parameter presents types for asset kinds for which the conversion rate to native balance is set.

Apart from this change, `AssetKindFactory` trait has also been introduced specifically for benchmarks.
    
**How does this impact the Polkadot builders?**
    
If you are using this pallet, you have to add these two new type parameters in the runtime otherwise compilation would fail.

To avoid compilation failure:

```rust
impl pallet_asset_rate::Config for Runtime {
  // .. snip
  type AssetKind = u32;
  #[cfg(feature = "runtime-benchmarks")]
  type BenchmarkHelper = ();
} 
```

For more details, please check the PR description.

---

### [S] change HashFor to HashingFor
PR:  https://github.com/paritytech/substrate/pull/14483

    
    
**Why is this change interesting for builders?**

At the moment, [Header](https://github.com/paritytech/substrate/blob/948fbd2fd1233dc26dbb9f9bbc1d2cca2c03945d/primitives/runtime/src/traits.rs#L1173-L1176) trait has two types:

```rust
        /// Header hash type
	type Hash: HashOutput;
	/// Hashing algorithm
	type Hashing: Hash<Output = Self::Hash>;
```

For extracting the hashing type for a block, we are using 
```rust
pub type HashFor<B> = <<B as Block>::Header as Header>::Hashing;
```
To avoid confusion and improve this naming, `HashFor` has been replaced with `HashingFor`.

For more details, please check the PR description.

Related Issue: [#10386](https://github.com/paritytech/substrate/issues/10386)
Cumulus Companion: [#2828](https://github.com/paritytech/cumulus/pull/2828)
Polkadot Companion: [#7465](https://github.com/paritytech/polkadot/pull/7465)

---

### [S] Don't use fixed nominator count for report_equivocation weight calculation
PR:  https://github.com/paritytech/substrate/pull/14471
    
    
**Why is this change interesting for builders?**

Substrate [Babe pallet](https://paritytech.github.io/substrate/master/pallet_babe/index.html) and [Grandpa pallet](https://paritytech.github.io/substrate/master/pallet_grandpa/index.html) both have an extrinsic `report_equivocation` to report authority equivocation/misbehavior.
    
As a part of this PR, a new config type `MaxNominators` has been introduced in both pallets. This new type will be used for weight calculation so that weights can be calculated on the basis of the runtime configured maximum number of nominators per validator, rather than using a constant value. 
    
**How does this impact the Polkadot builders?**
    
If you are using Babe or Grandpa pallet, you have to add this new type parameter in runtime otherwise compilation would fail.

To avoid compilation failure:

```rust
impl pallet_babe::Config for Runtime {
  // .. snip
  type MaxNominators = ConstU32<0>;
} 
    
impl pallet_grandpa::Config for Runtime {
  // .. snip
  type MaxNominators = ConstU32<0>;
} 
```


Polkadot Companion: [#7432](https://github.com/paritytech/polkadot/pull/7432)
  
---

### [S] Cross-contract calling: simple debugger
PR:  https://github.com/paritytech/substrate/pull/14678
    
    
**Why is this change interesting for builders?**

As a part of this PR, a simple debugger has been introduced in [pallet-contracts](https://paritytech.github.io/substrate/master/pallet_contracts/index.html).
This will help to debug complex multi-contract execution traces. This PR is well documented. For more details, please read PR description.

A new config type `Debug` has been introduced with `unsafe-debug` feature. However this feature flag has been removed as a part of this [#14789](https://github.com/paritytech/substrate/pull/14789)
    
**How does this impact the Polkadot builders?**
    
If you are using pallet-contracts, you have to add this new type parameter in runtime otherwise compilation would fail.

To avoid compilation failure:

```rust
impl pallet_contracts::Config for Runtime {
  // .. snip
  type Debug = ();
} 

```


Cumulus Companion: [#3035](https://github.com/paritytech/cumulus/pull/3035)
    
---
    
### [S] Contracts: migrate to fungible traits
PR:  https://github.com/paritytech/substrate/pull/14020
    
**Why is this important?**
    
Following [substrate#12951](https://github.com/paritytech/substrate/pull/12951) this PR include changes to adapt for holds, moving away from reserves, which [**requires a migration**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/contracts/src/migration/v14.rs) aside from what is described in the following section.
    
**How does this impact the Polkadot builders?**

The modifications done to pallet-contracts are the following:
    
- Inclusion of the overarching hold reasons
```rust
#[pallet::composite_enum]
pub enum HoldReason {
	/// The Pallet has reserved it for storing code on-chain.
	CodeUploadDepositReserve,
}
```
    
- `deposit_held` and `uploader` fields added to `CodeStored` event, now being fired instead of `pallet_balances::Event::Reserved`. In the same way, `deposit_released` and `remover` fields have been added to `CodeRemoved` event which is fired instead of `pallet_balances::Event::Unreserved`.
    
- `ExistenceRequirement` enum is replaced by `Preservation` enum
```diff
- /// Simple boolean for whether an account needs to be kept in existence.
- #[derive(Copy, Clone, RuntimeDebug, Eq, PartialEq)]
- pub enum ExistenceRequirement {
-     /// Operation must not result in the account going out of existence.
-     ///
-     /// Note this implies that if the account never existed in the first place, then the operation
-     /// may legitimately leave the account unchanged and still non-existent.
-     KeepAlive,
-    /// Operation may result in account going out of existence.
-    AllowDeath,
- }
    
+ /// The mode by which we describe whether an operation should keep an account alive.
+ #[derive(Copy, Clone, RuntimeDebug, Eq, PartialEq)]
+ pub enum Preservation {
+    /// We don't care if the account gets killed by this operation.
+    Expendable,
+    /// The account may not be killed, but we don't care if the balance gets dusted.
+    Protect,
+    /// The account may not be killed and our provider reference must remain (in the context of
+    /// tokens, this means that the account may not be dusted).
+    Preserve,
+ }    
```
    
- Users of `pallet-contracts` need to satisfy the new type required in its `Config`
```rust
impl pallet_contracts::Config for Runtime {
	...
	type RuntimeHoldReason = RuntimeHoldReason;
	...
}
```

- And so does `construct_runtime` need `pallet_contracts::HoldReason`

```rust
construct_runtime!(
	pub enum Runtime where
		...
        {
		...
		// Smart Contracts.
		Contracts: pallet_contracts::{Pallet, Call, Storage, Event<T>, HoldReason} = ...,
		...
	}
)
```    
    
---
    
### [P] 98.6% OF DEVELOPERS CANNOT REVIEW THIS PR!
PR:  https://github.com/paritytech/polkadot/pull/7337

    
**Why is this important?**
    
Polkadot node functionality has been separated in three different binaries, `polkadot` and the two new ones `polkadot-prepare-worker` and `polkadot-execute-worker` binary, which are not intended for any user interaction and are only run by the node software itself. The auxiliary binaries are actually only required if the node runs as a validator.

If you are a validator please consider the following.
    
- The binaries are free to be placed anywhere in the filesystem as long as the location allows for binary execution and all three are in the same directory.
- New `--workers-path` command line option is provided for those requiring to place the auxiliary binaries into a different location. That option also allows users to specify the binary itself, in which case it will be used for both preparation and execution jobs, but it is only intended for testing and development.
    
- When the node starts, if the location of the auxiliary binaries is not specified explicitly with --workers-path, it searches for them in the directory where the main binary resides and then in /usr/libexec. If not found, it falls back to executing them from $PATH.
    
- These new executables need to be at the same version than the polkadot binary.

Users running more sophisticated configurations may need some handwork to make things run.
    
Cumulus Companion: [#2929](https://github.com/paritytech/cumulus/pull/2929)
    
---

### [S] Set `StateBackend::Transaction` to `PrefixedMemoryDB`
PR:  https://github.com/paritytech/substrate/pull/14612

    
**Why is this important?**
    
This PR has a number of refactors including the removal of `Transaction` associated type from `sp_state_machine::Backend`. The transactin is then fixed to `PrefixedMemoryDB`. Another change is moving the "storage transaction cache" into `OverlayedChanges`. For the reasoning behind these changes please refer to the PR description.
    
**How does this impact the Polkadot builders?**
    
The following are the downstream changes:
    
- Everywhere where things like `TransactionFor` or `StateBackend::Transaction` was used in where bounds or similar can just be removed to make the code compile again.
- `BlockImportParams` was also changed to only take one generic argument, the block type and not anymore the transaction type as the second generic parameter.
- `DefaultImportQueue` is also only taking one generic argument after this PR, the block type.

Related Issue: [#27](https://github.com/paritytech/polkadot-sdk/issues/27)
Polkadot Companion: [#7536](https://github.com/paritytech/polkadot/pull/7536)
Cumulus Companion: [#2923](https://github.com/paritytech/cumulus/pull/2923)

---

# ℹ️ Low Impact

### [S] add doc-only substrate entry point crate
PR:  https://github.com/paritytech/substrate/pull/14581


    
**Why is this important?**
    
This PR is meant to be an entry point crate for Substrate documentation:
- https://paritytech.github.io/substrate/master/substrate

**How does this impact the Polkadot builders?**

In this PR, there has been a separation of concerns, to use Substrate node features you must now explicitly specify `node-cli` in your command:
```shell
cargo run -p node-cli --features try-runtime ...
```

---

### [P] Put HRMP Channel Management on General Admin Track
PR:  https://github.com/paritytech/polkadot/pull/7477


    
**Why is this important?**
    
This PR makes it so that the `GeneralAdmin` track now has permissions over HRMP channel management.

**How does this impact the Polkadot builders?**

This creates a `ChannelManager` for HRMP channel management and therefore streamlines the HRMP channel flow by having a more "relaxed" track specifically for HRMP channel operations.

**Why is this change interesting for builders?**
    
This PR is one example of how `OpenGov` is already an improvement over `Gov v1`.
    
**How to use**
    
You will need to make the following change to your runtime config:
    
```rust
impl parachains_hrmp::Config for Runtime {
	// .. snip
	type ChannelManager = frame_system::EnsureRoot<AccountId>;
	
}
```

---
    
### [S] Refactor the asset-conversion-tx-payment pallet
PR:  https://github.com/paritytech/substrate/pull/14558


    
**Why is this important?**

The `SwapNative` trait in `fungibles` has been moved to the asset-conversion pallet along with its methods and renamed to `Swap`.

Some code duplication has been removed.
    
And methods inside the `Swap` trait now accept a `path` param which is a `Vec<MultiAssetId>` where `path[0]` is one asset and `path[1]` is the second asset in the swap.
    
Check the PR for further details.
    
---
    
### [S] Introduce Pallet `paged-list`
PR:  https://github.com/paritytech/substrate/pull/14120

    
**Why is this important?**

This pallet is a thin wrapper around [`paged_list::StoragePagedList`](https://paritytech.github.io/substrate/master/pallet_paged_list/struct.StoragePagedList.html). In fact, this pallet contains no `Calls`, `Errors` or `Events`!
    
The paginated storage list in this pallet is meant to replace `StorageValue<Vec<V>>` in situations where only **iteration** and **appending** is needed. There are a few places where this is the case. 
    
The motivating force here is that a paginated structure reduces the (runtime) memory usage when storage transactions need to be rolled back.
    
You can read more here:
- https://paritytech.github.io/substrate/master/pallet_paged_list

**How to use**

You can see an example of using the `PagedList` pallet in the fuzzer that [is in this PR](https://github.com/paritytech/substrate/blob/511f31ed490c620a6fcee08284fff563cf37b160/frame/paged-list/fuzzer/src/paged_list.rs).

---
    
### [S] changes to nfts pallet for xcm integration 
PR: https://github.com/paritytech/substrate/pull/14395

    
    
**Why is this change interesting for builders?**
    
Substrate [NFT pallet](https://paritytech.github.io/substrate/master/pallet_nfts/index.html) has a storage [NextCollectionId](https://github.com/paritytech/substrate/blob/033d4e86cc7eff0066cd376b9375f815761d653c/frame/nfts/src/lib.rs#L344C11-L344C27), which gets calculated and stored, when a new collection is created. 
    
If we want to integrate NFT pallet with XCM, we would need to represent a `CollectionId` as a `MultiLocation`, which is not possible with current structure. To make this possible, a new function `create_collection_with_id` has been introduced  to allow for non incremental collection ids.
    
Related Issue: [#14349](https://github.com/paritytech/substrate/issues/14349)
    
---

### [S] Encryption support for the statement store 
PR: https://github.com/paritytech/substrate/pull/14440

    
**Why is this change interesting for builders?**
    
[Statement store](https://lib.rs/crates/sp-statement-store) is an off-chain data-store for signed statements accessible via RPC and OCW.
    
As a part of this PR a simple encryption scheme has been implemented that uses ed25519 key exchange and [AEAD](https://github.com/RustCrypto/AEADs/) for the statement store.
    
Related Issue: [#3](https://github.com/paritytech/labs/issues/3)
Cumulus Companion: [#2876](https://github.com/paritytech/cumulus/pull/2876)

---

### [S] [FRAME Core] New pallets: safe-mode and tx-pause 
PR: https://github.com/paritytech/substrate/pull/12092

    
**Why is this change interesting for builders?**
    
As a part of this release, two new pallets [safe-mode](https://paritytech.github.io/substrate/master/pallet_safe_mode/index.html) and [tx-pause](https://paritytech.github.io/substrate/master/pallet_tx_pause/index.html) have been introduced. Both pallets can be used in emergency situation in different way. 
    
`SafeMode` pallet put the chain in safe-mode by providing a big STOP button and only allows those calls which are whitelisted.

`TxPause` pallet can be used to pause specific calls.
    
Both pallets have a config type `WhitelistedCalls` where we can configue those calls which can bypass the safe-mode pallet and cannot be paused by the tx-pause pallet.

This PR is very well documented which includes a brief description. For more details, please go through PR description and related issues.
    
Related Issue: [#302](https://github.com/paritytech/polkadot-sdk/issues/302), [#274](https://github.com/paritytech/polkadot-sdk/issues/274)
    
---

### [S] grandpa: avoid importing unnecessary justifications 
PR: https://github.com/paritytech/substrate/pull/14423

    
**Why is this change interesting for builders?**
    
At the moment, block import process is slow because we process two types of justifications. One is GRANDPA justification and another one is served by peer for every block. If block import includes GRANDPA justification, it will always be processed. On the other hand, if it is a peer served  justification, it has to go through two levels. First the verification will happen and after that it will be imported. This is applicable for every block which can lead to a significant slowdown in block import speed. 

This PR fixes this issue and will allow only import GRANDPA justifications every 512 blocks.

Related Issue: [#13](https://github.com/paritytech/polkadot-sdk/issues/13)
Polkadot Companion: [#7484](https://github.com/paritytech/polkadot/pull/7484)
    
---
    
### [S] Get rid of `Peerset` compatibility layer
PR:  https://github.com/paritytech/substrate/pull/14337

    
**Why is this important?**
    
This PR gets rid of `Peerset` completely. `PeerStore` and `ProtocolController` replaces `Peerset`.

This PR also fixes a bug in `Protocol` with peer counting: `self.peers` contains only peers on the default (sync) protocol The entries are not removed when peers are disconnected on non-default protocols.

Polkadot Companion: [#7355](https://github.com/paritytech/polkadot/pull/7355)
Cumulus Companion: [#2739](https://github.com/paritytech/cumulus/pull/2739)
    
---
    
### [S] chainHead_storage: Iterate over keys
PR:  https://github.com/paritytech/substrate/pull/14628

    
**Why is this important?**

This PR adds support for iterating over key-values and key-hashes for `chainHead_unstable_storage`.

Related Issue: [#14548](https://github.com/paritytech/substrate/issues/14548)
    
---

### [P/C] Rename polkadot-parachain to polkadot-parachain-primitives
PR:  https://github.com/paritytech/polkadot-sdk/pull/1334

    
**Why is this important?**

`polkadot-parachain` defines primitive types for creating or validating a parachain. As a part of this PR, `polkadot-parachain` has been renamed  to `polkadot-parachain-primitives`. 

If you are a parachain builder, you may be using this. To avoid compilation error, please rename this.

For more details, please check the PR.

---
        
### [S] Asset conversion `get_pool_id` fix (`Ord` does not count with `is_native` flag)
PR:  https://github.com/paritytech/substrate/pull/14572

    
**Why is this important?**

This PR brings several changes to `asset-conversion` pallet, not only fixing `get_pool_id` for `is_native` but also a new definition to the `BenchmarkHelper` type:

```diff
- type BenchmarkHelper: BenchmarkHelper<Self::AssetId>;
+ type BenchmarkHelper: BenchmarkHelper<Self::AssetId, Self::MultiAssetId>;      
```    
A new field within the `PoolCreated` event
```diff

pub enum Event<T: Config> {
	/// A successful call of the `CretaPool` extrinsic will create this event.
	PoolCreated {
	    /// The account that created the pool.
		creator: T::AccountId,
		/// The pool id associated with the pool. Note that the order of the assets may not be
		/// the same as the order specified in the create pool extrinsic.
		pool_id: PoolIdOf<T>,
+		/// The account ID of the pool.
+		pool_account: T::AccountId,
		/// The id of the liquidity tokens that will be minted when assets are added to this
		/// pool.
		lp_token: T::PoolAssetId,
    },
    
    ...
}    
    
```

And a new error has been added

```diff
pub enum Error<T> {
	/// Provided assets are equal.
	EqualAssets,
	/// Provided asset is not supported for pool.
+	UnsupportedAsset,
    ...
}
```    

Along with improvements to `MultiAssetIdConverter`.    
    
Cumulus Companion: [#2860](https://github.com/paritytech/cumulus/pull/2860)
    
---
    
### [S] contracts: Expose environment types for offchain tooling
PR:  https://github.com/paritytech/substrate/pull/14750

    
**Why is this important?**

This PR exposes all runtime configurable types passed between pallet contracts and deployed contracts. This is useful to check whether before a contract is uploaded/instantiated, if its types match the types from the node (pallet contracts). Since these types are configurable, they can vary between chains that are using pallet contracts and therefore this PR makes it so the type metadata can be consumed by offchain tooling.

Cumulus Companion: [#3036](https://github.com/paritytech/cumulus/pull/3036)
Related Issue: [#1167](https://github.com/paritytech/cargo-contract/issues/1167)
    
---
    
### [S] pallet-aura: add feature-flagged explicit slot duration type
PR:  https://github.com/paritytech/substrate/pull/14649

    
**Why is this important?**
    
This PR adds a feature flagged exlicit slot duration type for AURA that should be enabled for runtimes which plan to upgrade to asynchronous backing. The feature flag is there for backwards compatibility. 

---

### [S] [NPoS] Implements dynamic number of nominators
PR:  https://github.com/paritytech/substrate/pull/12970

    
**Why is this important?**

This PR refactors the implementation of the `ElectionDataProvider` bounds and implements a dynamic nomination quota per voter, based on the account's balance and an arbitrary curve. 
    
An implementor of `NominationsQuota` returns the maximum number of votes per nominator. FixedNominationsQuota implements an instance of a fixed number of nominations, similar to the current implementation when set to 16.
    
Also, two new events have been added to `pallet-staking`:


- `SnapshotVotersSizeExceeded`: emitted when the election snapshot was exhausted due to the voters size limit.
- `SnapshotTargetsSizeExceeded`: emitted when the election snapshot was exhausted due to the targets size limit.

    
A new runtime API is also implemented to allow clients to query the nominations quota for a given balance.

Polkadot Companion: [#6807](https://github.com/paritytech/polkadot/pull/6807)
    
---

### [S] Contracts remove deposit accounts
PR:  https://github.com/paritytech/substrate/pull/14589

    
**Why is this important?**
    
 Move contracts' _reserved_ balance from the `deposit_account` to be _held_ in the contract's account instead. Since `Currency` trait has been [deprecated](https://github.com/paritytech/substrate/pull/12951), deposits need to be handled by the `frame_support::traits::fungible` traits instead. This PR inclused a migration to tackle this. 

The deposit account is not needed anymore and we can get rid of it.
   
Cumulus Companion: [#2973](https://github.com/paritytech/cumulus/pull/2973)    

### [P] Rename squatted crates
PR:  https://github.com/paritytech/polkadot-sdk/pull/1241

    
**Why is this important?**

As a part of this PR, `staging-` prefix has been added to below squatted crates so that they can be published to crates.io. 

* Polkadot
    1. kusama-runtime
    2. xcm
    3. xcm-executor
    4. xcm-builder
    6. staking-miner

If you are a parachain builder, you may be using this. To avoid compilation error, please rename this.


### [C] Asynchronous backing PR
PR:  https://github.com/paritytech/cumulus/pull/2300

    
**Why is this important?**

In case you are not familiar with what [Asynchronous backing](https://github.com/paritytech/polkadot/issues/3779) is, please read the related issue - [polkadot#3779](https://github.com/paritytech/polkadot/issues/3779).

This PR includes the Cumulus companion to asynchronous backing. Being the major change of this PR introducing `ConsensusHook` to `pallet_parachain_system::Config`. 

Following an configuration example of said change:

```rust

/// Maximum number of blocks simultaneously accepted by the Runtime, not yet included
/// into the relay chain.
const UNINCLUDED_SEGMENT_CAPACITY: u32 = 1;
/// How many parachain blocks are processed by the relay chain per parent. Limits the
/// number of blocks authored per slot.
const BLOCK_PROCESSING_VELOCITY: u32 = 1;
/// Relay chain slot duration, in milliseconds.
const RELAY_CHAIN_SLOT_DURATION_MILLIS: u32 = 6000;

// Above values have been taken from parachain template

impl cumulus_pallet_parachain_system::Config for Runtime {
  // .. snip
  type ConsensusHook = cumulus_pallet_aura_ext::FixedVelocityConsensusHook<
		Runtime,
		RELAY_CHAIN_SLOT_DURATION_MILLIS,
		BLOCK_PROCESSING_VELOCITY,
		UNINCLUDED_SEGMENT_CAPACITY,
	>;
} 

```



Related Issue: [#3779](https://github.com/paritytech/polkadot/issues/3779)
Related PR: [#5022](https://github.com/paritytech/polkadot/pull/5022)

---

### [C] Allow integrated relay chain light client
PR:  https://github.com/paritytech/cumulus/pull/2270

**Why is this important?**

This change enables experimental support for running an embedded light client along the parachain node. With this addition parachain nodes have now three execution modes to run the relay chain:

- Embedded polkadot full node
- External polkadot node
- Embedded light-client

To activate this capability, the new flag has been added `--relay-chain-light-client` and the light client will take the chain spec that is passed via relay chain args to the collator.

```bash
polkadot-parachain \
	--chain parachain-chainspec.json \
	--tmp \
	--relay-chain-light-client \
	-- \
	--chain relaychain-chainspec.json
```

---