---
# System prepended metadata

title: Polkadot Release Analysis v1.13.0

---

# Polkadot Release Analysis v1.13.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.13.0](https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-v1.13.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.***

# Summary

In the following report, we are featuring some of the changes included in the [polkadot node release v1.13.0](https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-v1.13.0). 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.
    
## Migrations in this release:
* [NominationPools to `DelegateStake` adapter](https://github.com/paritytech/polkadot-sdk/pull/3905)
    
## :hammer_and_wrench: Tooling Section

* Sidecar - [v19.0.1](https://github.com/paritytech/substrate-api-sidecar/releases/tag/v19.0.1)
* Txwrapper - [v7.5.0](https://github.com/paritytech/txwrapper-core/releases/tag/v7.5.0)
* PolkadotJS - [v11.2.1](https://github.com/polkadot-js/api/releases/tag/v11.2.1)
* AssetTransferApi - [v0.3.0](https://github.com/paritytech/asset-transfer-api/releases/tag/v0.3.0)

---

# ❗️ High Impact

### [S|P|C] Polkadot-SDK Umbrella Crate
PR:  https://github.com/paritytech/polkadot-sdk/pull/3935

**Why is this important?**
 This release  has come with the most awaited and very powerful feature: [Umbrella Crate](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/umbrella_crate/index.html).

The PR is well documented. However, We would still like to highlight the most important features of this crate.

1) `runtime` feature enables all `no-std` crates.
2) `node` feature enables all `std` crates.
3) We can use `zepter`, which checks  that the features of the umbrella are correctly configured.
4) Each crate can also be enabled selectively.



**How does this impact Polkadot builders?**
       After including this crate, `Cargo.toml` will become very small, less error-prone, and easy to maintain. 

**How to use?**

For `runtime`:
```rust
polkadot-sdk = {  git = "https://github.com/paritytech/polkadot-sdk.git", features = ["runtime"], default-features = false }
```
For `node`: 

```rust
polkadot-sdk = {  git = "https://github.com/paritytech/polkadot-sdk.git", features = ["node"], default-features = false }
```

After adding in `Cargo.toml`, you need to add `use polkadot_sdk::*;` to import all dependencies. 

Related Link: [umbrella_crate.rs](https://github.com/paritytech/polkadot-sdk/blob/polkadot-v1.13.0/docs/sdk/src/reference_docs/umbrella_crate.rs)
    
### [S] Refactor Nomination Pool to support multiple staking strategies 
PR: https://github.com/paritytech/polkadot-sdk/pull/3905

**Why is this important?**

At the moment, [Nomination Pool](https://docs.rs/pallet-nomination-pools/latest/pallet_nomination_pools/) allows DOT holders to pool their DOT tokens together on-chain to nominate validators and earn rewards. It works by transferring tokens from the delegator to the pool account, and then staking from the pool account as a direct nominator. Before nomination pools, users were directly nominating validators and using their stake of DOT tokens to select validators.

As a part of this PR, a new staking strategy has been introduced. Now individual delegators can delegate the funds to the pool account while the tokens stay locked in delegator account itself. The pool can then delegate the stake to validators.

**How does this impact Polkadot builders?**

A new `StakingStrategy` config `StakeAdapter` has been added in [Nomination Pool](https://docs.rs/pallet-nomination-pools/latest/pallet_nomination_pools/). With this change, Polkadot builders will have the option to switch to the new staking strategy or stick with the old strategy. If you want to switch to the new strategy, it might require a migration of the storage.

**How to use?**

In Runtime,

* For switching to the new staking strategy
```rust
impl pallet_nomination_pools::Config for Runtime {
    // Other config
    type StakeAdapter =
		pallet_nomination_pools::adapter::DelegateStake<Self, Staking, DelegatedStaking>;

}
```
You also need to import `pallet_delegated_staking` in the runtime.

* If you don't want to switch to the new strategy
```rust
type StakeAdapter = pallet_nomination_pools::adapter::TransferStake<Self, Staking>;
```

This PR is well documented. For more details, please refer to PR description and the following links.

Related Links:
* https://hackmd.io/@ak0n/454-np-governance
* [#454](https://github.com/paritytech/polkadot-sdk/issues/454)
* [#2680](https://github.com/paritytech/polkadot-sdk/pull/2680)

---

# ⚠️ Medium Impact
    
### [S|P|C] Implement CheckMetadataHash extension 
PR:  https://github.com/paritytech/polkadot-sdk/pull/4274

**Why is this important?**

For clients to interact with the chains in the Polkadot Ecosystem, Polkadot-SDK based chains expose metadata about the runtime so that they know how transactions are composed and encoded. This is usually required by wallets, exchanges, custody providers, etc. when they interact with the chains. The metadata is a crucial piece of the transaction and needs to be verified.

At the moment, verification is based on centralized authentication system by trusted authority. This PR makes this verification trustless. As a part of this PR, the new `CheckMetadataHash` signed extension has been introduced, which can be added in runtime.
    
**How does this impact Polkadot builders?**

The metadata hash generation should be enabled only when it is required. Because it adds more overhead, which increases compile time.

Please refer to this [guide](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/guides/enable_metadata_hash/index.html) to enable metadata hash. 

Related Issue: [#291](https://github.com/paritytech/polkadot-sdk/issues/291)

### [S] Append overlay optimization.
PR: https://github.com/paritytech/polkadot-sdk/pull/1223

**Why is this important?**

[OverlayedChanges](https://paritytech.github.io/polkadot-sdk/master/sp_state_machine/struct.OverlayedChanges.html) are the set of changes that are applied to the storage backend when executing transactions. As a part of this PR, `storage::append` performance has been improved by reducing cloning and copying of data. Before this PR, `storage::append` was working by appending new data to old storage items after cloning them. After this PR, the new data is kept in a separate field, and cloning is avoided. This allows for improved performance and better transaction throughput.

Related Issue: [#30](https://github.com/paritytech/polkadot-sdk/issues/30)

---

# ℹ️ Low Impact

### [C] Remove parameterized-consensus-hook feature 
PR: https://github.com/paritytech/polkadot-sdk/pull/4380

**Why is this important?**

As a part of [Asynchronous backing PR](https://github.com/paritytech/cumulus/pull/2300), `parameterized-consensus-hook` feature was introduced to enable `ConsensusHook` which is a pluggable component to allow a chain to manage its asynchronous backing backlog.

`parameterized-consensus-hook` feature is obsolete now and has been removed as a part of this PR.

**How does this impact Polkadot builders?**

After this PR, all Polkadot-SDK based parachains would need to supply a `ConsensusHook`.  To understand more about the implications of this change, please refer to [this section](https://github.com/paritytech/polkadot-sdk/pull/4380#issuecomment-2095639593) of PR. 

**How to use?**

```diff

- cumulus-pallet-parachain-system = {  git = "https://github.com/paritytech/polkadot-sdk", default-features = false, features = [
- 	"parameterized-consensus-hook",
- ] }
+ cumulus-pallet-parachain-system = { git = "https://github.com/paritytech/polkadot-sdk", default-features = false }

```

### [S] Adds `MaxRank` Config in `pallet-core-fellowship` 
PR: https://github.com/paritytech/polkadot-sdk/pull/3393

**Why is this important?**

[Core-Fellowship](https://paritytech.github.io/polkadot-sdk/master/src/pallet_core_fellowship/lib.rs.html) pallet contains logic specific to the salary, registers activity/passivity and promotion. As a part of this PR, a new Config `MaxRank` has been added to represent the highest possible rank. Before this PR, the maximum ranked member count was set to 9 as constant.

**How does this impact Polkadot builders?**

If you are using [Core-Fellowship](https://paritytech.github.io/polkadot-sdk/master/src/pallet_core_fellowship/lib.rs.html) pallet for any separate instances of fellowship(s) for your chain ecosystem or use-case scenario, this is a breaking change.

To avoid this breaking change, please implement following changes in your change:

In your runtime:

```rust

impl pallet_core_fellowship::Config for Runtime {
    
    .....
    type MaxRank = ConstU32<9>;
    
}
```

Related Issue: [#3315](https://github.com/paritytech/polkadot-sdk/issues/3315)

### [S] [Pools] Refactors and Runtime APIs for DelegateStake
PR: https://github.com/paritytech/polkadot-sdk/pull/4537

**Why is this important?**

As mentioned above in the analysis of [PR 3905](https://github.com/paritytech/polkadot-sdk/pull/3905), a new staking strategy has been introduced in [Nomination Pools](https://docs.rs/pallet-nomination-pools/latest/pallet_nomination_pools/) to delegate (instead of transfer) fund from delegator to pool account.
As a part of this PR, following runtime apis have been introduced to support integration with dapps and wallets:

```rust
fn pool_pending_slash(pool_id: PoolId) -> Balance;// Returns the pending slash for a given pool.
fn member_pending_slash(member: AccountId) -> Balance;// Returns the pending slash for a given pool member.
fn pool_needs_delegate_migration(pool_id: PoolId) -> bool;// Returns true if the pool with `pool_id` needs migration.
fn member_needs_delegate_migration(member: AccountId) -> bool;// Returns true if the delegated funds of the pool `member` needs migration.
```

**How does this impact Polkadot builders?**

Apart from the new runtime apis, some refactoring has also been done as a part of this PR. Please refer to PR description for more details. If you have included Nomination pool runtime apis in your runtime, you will need to add the following code in your runtime:

```rust

impl pallet_nomination_pools_runtime_api::NominationPoolsApi<Block, AccountId, Balance> for Runtime {
    
        /// existing apis
    
        fn pool_pending_slash(pool_id: pallet_nomination_pools::PoolId) -> Balance {
			NominationPools::api_pool_pending_slash(pool_id)
		}

		fn member_pending_slash(member: AccountId) -> Balance {
			NominationPools::api_member_pending_slash(member)
		}

		fn pool_needs_delegate_migration(pool_id: pallet_nomination_pools::PoolId) -> bool {
			NominationPools::api_pool_needs_delegate_migration(pool_id)
		}

		fn member_needs_delegate_migration(member: AccountId) -> bool {
			NominationPools::api_member_needs_delegate_migration(member)
		}
}
```

### [S] Add READ_ONLY flag to contract call function
PR: https://github.com/paritytech/polkadot-sdk/pull/4418

**Why is this important?**

Ethereum has [STATICCALL](https://eips.ethereum.org/EIPS/eip-214) for smart contract security which can be used to call another contract (or itself) while disallowing any modifications to the state during the call.

As a part of this PR, same strategy has been followed by adding the `READ_ONLY` flag in the `call` function in the Contracts pallet.

For more details, please refer PR description.

### [S] [Identity] Remove double encoding username signature payload
PR: https://github.com/paritytech/polkadot-sdk/pull/4646

**Why is this important?**

[Identity-Pallet](https://paritytech.github.io/polkadot-sdk/master/pallet_identity/index.html) provides the concept of on-chain identity that allows identities to be added and managed on-chain. The pallet includes functionality for Identity Registration, Identity Verification, Identity Management, and Sub-identities. 

At the moment, for registering a `username`, an additional step is involved for encoding. As a part of this PR, this step has been removed.

Let's take an example of one of Identity-Pallet tests:

```diff
- let encoded_username = Encode::encode(&username_to_sign.to_vec());
- let signature =
- 			MultiSignature::Sr25519(sr25519_sign(0.into(), &public, &encoded_username).unwrap());
+ let signature = MultiSignature::Sr25519(
+			sr25519_sign(0.into(), &public, &username_to_sign[..]).unwrap(),
+		);
```

For more details, please refer to PR description.


### [S] Bridge: added force_set_pallet_state call to pallet-bridge-grandpa
PR: https://github.com/paritytech/polkadot-sdk/pull/4465

**Why is this important?**

[pallet-bridge-grandpa](https://docs.rs/pallet-bridge-grandpa/latest/pallet_bridge_grandpa/) is one of the components for building bridges. This is On-Chain GRANDPA Light Client. As a part of this PR, a new extrinsic `force_set_pallet_state` has been added to this pallet. This new extrinsic is only callable by the root origins (governance or sudo). It could be used in scenarios where an update of authorities set or finalized header are needed.

Related Issue: [#2963](https://github.com/paritytech/parity-bridges-common/issues/2963)

### [C] Make all storage items in parachain-system public
PR: https://github.com/paritytech/polkadot-sdk/pull/4645

**Why is this important?**

[cumulus-pallet-parachain-system](https://paritytech.github.io/polkadot-sdk/master/cumulus_pallet_parachain_system/index.html) is a base pallet for Cumulus-based parachains. As a part of this PR, all storage items of this pallet have been made public. Now these storage items can be accessed from other pallets or from runtime itself. For example: latest validation code, latest relay chain block number associated with the last parachain block, can be accessed from another pallet. 


---