The `query_weight_to_asset_fee` function was trying to convert versions
by using `try_as`, this function [doesn't convert from a versioned to a
concrete
type](https://github.com/paritytech/polkadot-sdk/blob/0156ca8f/polkadot/xcm/src/lib.rs#L131).
This would cause all calls with a lower version to fail.

The correct function to use is the good old
[try_into](https://github.com/paritytech/polkadot-sdk/blob/0156ca8f

/polkadot/xcm/src/lib.rs#L184).
Now those calls work :)

---------

Co-authored-by: command-bot <>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: GitHub Action <action@github.com>

Before this was done for every imported transaction. When a lot of
transactions got imported, the import notification channel was filled.
The underlying problem was that the `status` call is read locking the
`validated_pool` which will be write locked by the internal submitting
logic. Thus, the submitting and status reading was interferring which
each other.

---------

Co-authored-by: GitHub Action <action@github.com>

Step in https://github.com/paritytech/polkadot-sdk/issues/3268

This PR adds the ability for these pallets to specify their source of
the block number. This is useful when these pallets are migrated from
the relay chain to a parachain and vice versa.

This change is backwards compatible:
1. If the `BlockNumberProvider` continues to use the system pallet's
block number
2. When a pallet deployed on the relay chain is moved to a parachain,
but still uses the relay chain's block number

However, we would need migrations if the deployed pallets are upgraded
on an existing parachain, and the `BlockNumberProvider` uses the relay
chain block number.

---------

Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

Move spawning of the slot-based collator into the `run` function. Also
the tasks are being spawned as blocking task and not just as normal
tasks.

---------

Co-authored-by: GitHub Action <action@github.com>

This PR includes:  
- Refactored integrity tests to support standalone deployment of
`pallet-bridge-messages`.
- Refactored the `open_and_close_bridge_works` test case to support
multiple scenarios, such as:
  1. A local chain opening a bridge.  
  2. Sibling parachains opening a bridge.  
  3. The relay chain opening a bridge.  
- Previously, we added instance support for `pallet-bridge-relayer` but
overlooked updating the `DeliveryConfirmationPaymentsAdapter`.

---------

Co-authored-by: GitHub Action <action@github.com>

Aims to implement Stage 3 of Validator Disbling as outlined here:
https://github.com/paritytech/polkadot-sdk/issues/4359

Features:
- [x] New Disabling Strategy (Staking level)
- [x] Re-enabling logic (Session level)
- [x] More generic disabling decision output
- [x] New Disabling Events

Testing & Security:
- [x] Unit tests
- [x] Mock tests
- [x] Try-runtime checks
- [x] Try-runtime tested on westend snap
- [x] Try-runtime CI tests
- [ ] Re-enabling Zombienet Test (?)
- [ ] SRLabs Audit

Closes #4745 
Closes #2418

---------

Co-authored-by: ordian <write@reusable.software>
Co-authored-by: Ankan <10196091+Ank4n@users.noreply.github.com>
Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io>

This PR update the pallet to use the EVM 18 decimal balance in contracts
call and host functions instead of the native balance.

It also updates the js example to add the piggy-bank solidity contract
that expose the problem

---------

Co-authored-by: GitHub Action <action@github.com>

Follow up to https://github.com/paritytech/polkadot-sdk/pull/3685
Partially fixes https://github.com/paritytech/polkadot-sdk/issues/6403

The main PR introduced bare support for the new extension version byte
as well as extension weights and benchmarking.

This PR:
- Removes the redundant extension version byte from the signed v4
extrinsic, previously unused and defaulted to 0.
- Adds the extension version byte to the inherited implication passed to
`General` transactions.
- Whitelists the `pallet_authorship::Author`, `frame_system::Digest` and
`pallet_transaction_payment::NextFeeMultiplier` storage items as they
are read multiple times by extensions for each transaction, but are hot
in memory and currently overestimate the weight.
- Whitelists the benchmark caller for `CheckEra` and `CheckGenesis` as
the reads are performed for every transaction and overestimate the
weight.
- Updates the umbrella frame weight...

Added `ExecuteWithOrigin` instruction according to the old XCM RFC 38:
https://github.com/polkadot-fellows/xcm-format/pull/38.

This instruction allows you to descend or clear while going back again.

## TODO
- [x] Implementation
- [x] Unit tests
- [x] Integration tests
- [x] Benchmarks
- [x] PRDoc

## Future work

Modify `WithComputedOrigin` barrier to allow, for example, fees to be
paid with a descendant origin using this instruction.

---------

Signed-off-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Andrii <ndk@parity.io>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Joseph Zhao <65984904+programskillforverification@users.noreply.github.com>
Co-authored-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Co-authored-by: command-bot <>

- Fix bare_eth_transact so that it estimate more precisely the
transaction fee
- Add some context to the build.rs to make it easier to troubleshoot
errors
- Add TransactionBuilder for the RPC tests.
- Improve error message, proxy rpc error from the node and handle
reverted error message
- Add logs in ReceiptInfo

---------

Co-authored-by: GitHub Action <action@github.com>

Based on https://github.com/paritytech/polkadot-sdk/pull/3331
Related to https://github.com/paritytech/polkadot-sdk/issues/3268

Implements migrations with customizable block number to relay height
number translation function.

Adds block to relay height migration code for rococo and westend.

---------

Co-authored-by: DavidK <davidk@parity.io>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

Closes #2082

change send xcm to use `xcm::executor::FeeManager` to determine if the
sender should be charged.

I had to change the `FeeManager` of the penpal config to ensure the same
test behaviour as before. For the other tests, I'm using the
`FeeManager` from the `xcm::executor::FeeManager` as this one is used to
check if the fee can be waived on the charge fees method.

---------

Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: GitHub Action <action@github.com>

# Description

This seems to be an old artifact of the long closed
https://github.com/paritytech/substrate/issues/6827 that I noticed when
working on related code earlier.

## Integration

`NetworkStarter` was removed, simply remove its usage:
```diff
-let (network, system_rpc_tx, tx_handler_controller, start_network, sync_service) =
+let (network, system_rpc_tx, tx_handler_controller, sync_service) =
    build_network(BuildNetworkParams {
...
-start_network.start_network();
```

## Review Notes

Changes are trivial, the only reason for this to not be accepted is if
it is desired to not start network automatically for whatever reason, in
which case the description of network starter needs to change.

# Checklist

* [x] My PR includes a detailed description as outlined in the
"Description" and its two subsections above.
* [ ] My PR follows the [labeling requirements](

https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md#Process
) of this project (at minimum one label for `T` required)
* External contributors: ask maintainers to put the right label on your
PR.

---------

Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Bastian Köcher <git@kchr.de>

This PR introduces usage of `build_struct_json_patch` macro in all
runtimes (also guides) within the code base.

It also fixes macro to support _field init shorthand_, and _Struct
Update_ syntax which were missing in original implementation.

Follow up of #5700 and #5813

# Description

This is a continuation of
https://github.com/paritytech/polkadot-sdk/pull/5666 that finally fixes
https://github.com/paritytech/polkadot-sdk/issues/5333.

This should allow developers to create custom syncing strategies or even
the whole syncing engine if they so desire. It also moved syncing engine
creation and addition of corresponding protocol outside
`build_network_advanced` method, which is something Bastian expressed as
desired in
https://github.com/paritytech/polkadot-sdk/issues/5#issuecomment-1700816458

Here I replaced strategy-specific types and methods in `SyncingStrategy`
trait with generic ones. Specifically `SyncingAction` is now used by all
strategies instead of strategy-specific types with conversions.
`StrategyKey` was an enum with a fixed set of options and now replaced
with an opaque type that strategies create privately and send to upper
layers as an opaque type. Requests and responses are now handled in a
generic way regardl...

# Context

This PR aims to introduce XCMv5, for now it's in progress and will be
updated over time.
This branch will serve as a milestone branch for merging in all features
we want to add to XCM, roughly outlined
[here](https://github.com/polkadot-fellows/xcm-format/issues/60).
More features could be added.

## TODO
- [x] Migrate foreign assets from v3 to v4
- [x] Setup v5 skeleton
- [x] Remove XCMv2
- [x] https://github.com/paritytech/polkadot-sdk/pull/5390
- [x] https://github.com/paritytech/polkadot-sdk/pull/5585
- [x] https://github.com/paritytech/polkadot-sdk/pull/5420
- [x] https://github.com/paritytech/polkadot-sdk/pull/5876
- [x] https://github.com/paritytech/polkadot-sdk/pull/5971
- [x] https://github.com/paritytech/polkadot-sdk/pull/6148
- [x] https://github.com/paritytech/polkadot-sdk/pull/6228

Fixes #3434 
Fixes https://github.com/paritytech/polkadot-sdk/issues/4190
Fixes https://github.com/paritytech/polkadot-sdk/issues/5209
Fixes https://github.com/paritytech/polkadot-sdk/issues/5241
Fixes https://github.com/paritytech/polkadot-sdk/issues/4284

---------

Signed-off-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Andrii <ndk@parity.io>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Joseph Zhao <65984904+programskillforverification@users.noreply.github.com>
Co-authored-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Co-authored-by: command-bot <>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Serban Iorga <serban@parity.io>

Remove `sp_runtime::RuntimeString` and replace with `Cow<'static, str>` or `String` depending on use case (#5693)

# Description

As described in https://github.com/paritytech/polkadot-sdk/issues/4001
`RuntimeVersion` was not encoded consistently using serde. Turned out it
was a remnant of old times and no longer actually needed. As such I
removed it completely in this PR and replaced with `Cow<'static, str>`
for spec/impl names and `String` for error cases.

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

## Integration

For downstream projects the upgrade will primarily consist of following
two changes:
```diff
#[sp_version::runtime_version]
pub const VERSION: RuntimeVersion = RuntimeVersion {
-	spec_name: create_runtime_str!("statemine"),
-	impl_name: create_runtime_str!("statemine"),
+	spec_name: alloc::borrow::Cow::Borrowed("statemine"),
+	impl_name: alloc::borrow::Cow::Borrowed("statemine"),
```
```diff
		fn dispatch_benchmark(
			config: frame_benchmarking::BenchmarkConfig
-		) -> Result<Vec<frame_benchmarking::BenchmarkBatch>, sp_runtime::RuntimeString> {
+		) -> Result<Vec<frame_benchmarking::BenchmarkBatch>, alloc::string::String> {
```

SCALE encoding/decoding remains the same as before, but serde encoding
in runtime has changed from bytes to string (it was like this in `std`
environment already), which most projects shouldn't have issues with. I
consider the impact of serde encoding here low due to the type only
being used in runtime version struct and mostly limited to runtime
internals, where serde encoding/decoding of this data structure is quite
unlikely (though we did hit exactly this edge-case ourselves


).

## Review Notes

Most of the changes are trivial and mechanical, the only non-trivial
change is in
`substrate/primitives/version/proc-macro/src/decl_runtime_version.rs`
where macro call expectation in `sp_version::runtime_version`
implementation was replaced with function call expectation.

# Checklist

* [x] My PR includes a detailed description as outlined in the
"Description" and its two subsections above.
* [ ] My PR follows the [labeling requirements](

https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md#Process
) of this project (at minimum one label for `T` required)
* External contributors: ask maintainers to put the right label on your
PR.
* [ ] I have made corresponding changes to the documentation (if
applicable)

---------

Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Guillaume Thiolliere <guillaume.thiolliere@parity.io>
Co-authored-by: Bastian Köcher <info@kchr.de>

Resolves https://github.com/paritytech/polkadot-sdk/issues/6179

Remove references of now defunct Wococo network.

The XCM `NetworkId::Wococo` will also be removed with [XCMv5
PR](https://github.com/paritytech/polkadot-sdk/pull/4826)

Replace `GlobalConsensusEthereumConvertsFor` with
`EthereumLocationsConverterFor` that allows `Location` to `AccountId`
conversion for the Ethereum network root as before, but also for
Ethereum contracts and accounts.

The new converter only matches explicit `parents: 2` Ethereum locations,
meaning it should be used only on/by parachains.

The logline in question doesn't indeed present any interest for a node
operator (I mean, there is not much he can do about that warning), but
in a heavy transaction load situation, when each of 5000 transactions in
txpool produces a warning, it's really annoying. Still, it's useful for
a developer, so I propose to log it at the `debug` level.

This PR removes the `transfer` syscall and changes balance transfers to
make the existential deposit (ED) fully transparent for contracts.

The `transfer` API is removed since there is no corresponding EVM opcode
and transferring via a call introduces barely any overhead.

We make the ED transparent to contracts by transferring the ED from the
call origin to nonexistent accounts. Without this change, transfers to
nonexistant accounts will transfer the supplied value minus the ED from
the contracts viewpoint, and consequentially fail if the supplied value
lies below the ED. Changing this behavior removes the need for contract
code to handle this rather annoying corner case and aligns better with
the EVM. The EVM charges a similar deposit from the gas meter, so
transferring the ED from the call origin is practically the same as the
call origin pays for gas.

---------

Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: PG Herveou <pgherveou@gmail.com>

# Description

Closes #5940  

## Integration

Node devs that rely on templates' nodes binaries for minimal or
parachain would need to follow the updated templates' README.mds again
to find how to build the nodes' binaries.

## Review Notes

Conditional compilation of virtual workspaces would compile the
`members` list as if we passed `--workspace` flag to `cargo build` ,
except when adding a `default-members` list which will be used for any
cargo command executed in the virtual workspace root. To build the full
members list needs passing `--workspace` flag.

Other options investigated:
- feature guard the `node` crate by defining a feature in the `node`
crate, but it feels too complex since all code needs to be feature
guarded. I haven't tried it but technically speaking it might work. I
think though it looks awkward and my opinion is that the alternative is
better.
- defining features in the virtual workspace's Cargo.toml doesn't work
(thought that I might create a feature that will have a dependency on
the `node` crate and then not passing the feature to cargo build results
in ignoring the `node` crate)
- skipping compilation by using an environment variable, read in the
build script, that will exit compilation abruptly if not set, but I
couldn't make it work.
- exclude the crate from the members list and build it specifically by
passing `--package minimal-template-node` flag to the `cargo build`
command. This has the disadvantage of not allowing IDEs based on rust
analyzer to index/compile the node crate.

My conclusion is that any option would require two commands to build the
template, one with the node and one without, and both must be included
in the README or templates usage documentation. If it comes which ones
to pick I am in favor of the `default-members` option, which requires
minimal intervention and expresses how cargo commands are executed on
top of the workspace members, and what's left out from regular usage.

### Testing

Testing was conducted as described bellow:

- [x] zombienet with `minimal-template-node` , `parachain-template-node`
and `polkadot-omni-node`. Things work as expected.
- [x] no chopsticks testing was conducted - feels a bit out of scope for
OmniNode related docs and overall testing when promoting it over the
templates' nodes.
- [x] testing the changes for the sync templates workflow (ignore the
added comment from the Cargo.tomls, it was removed here on this branch:
[99bff3e2](https://github.com/paritytech/polkadot-sdk/pull/5954/commits/99bff3e2

)):
[minimal](https://github.com/paritytech-stg/polkadot-sdk-minimal-template/pull/22/files#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R9),
[parachain](https://github.com/paritytech-stg/polkadot-sdk-parachain-template/pull/19/files#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R9),
[solochain](https://github.com/paritytech-stg/polkadot-sdk-solochain-template/pull/17/files#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R9).
The links correspond to PRs opened by a bot after manually starting the
sync-templates workflow on `paritytech-stg` org to test the end result
of the `Cargo.toml` changes.

---------

Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

Various fixes for the release of eth-rpc & ah-westend-runtime

- Bump asset-hub westend spec version
- Fix the status of the Receipt to properly report failed transactions
- Fix value conversion between native and eth decimal representation

---------

Co-authored-by: GitHub Action <action@github.com>

The goal of this PR is to have the treasury pallet work on a parachain
which does not produce blocks on a regular schedule, thus can use the
relay chain as a block provider.

Because blocks are not produced regularly, we cannot make the assumption
that block number increases monotonically, and thus have new logic to
handle multiple spend periods passing between blocks.

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Muharem <ismailov.m.h@gmail.com>

# Benchmark Overhead Command for Parachains

This implements the `benchmark overhead` command for parachains. Full
context is available at:
https://github.com/paritytech/polkadot-sdk/issues/5303. Previous attempt
was this https://github.com/paritytech/polkadot-sdk/pull/5283, but here
we have integration into frame-omni-bencher and improved tooling.

## Changes Overview

Users are now able to use `frame-omni-bencher` to generate
`extrinsic_weight.rs` and `block_weight.rs` files for their runtime. The
core logic for generating these remains untouched; this PR provides
mostly machinery to make it work for parachains at all.

Similar to the pallet benchmarks, we gain the option to benchmark based
on just a runtime:

```
frame-omni-bencher v1 benchmark overhead --runtime {{runtime}}
```

or with a spec:

```
frame-omni-bencher v1 benchmark overhead --chain {{spec}} --genesis-builder spec
```

In this case, the genesis state is generated from the runtime presets.
However, it is also possible to use `--chain` and genesis builder `spec`
to generate the genesis state from the chain spec.

Additionally, we use metadata to perform some checks based on the
pallets the runtime exposes:

- If we see the `ParaInherent` pallet, we assume that we are dealing
with a relay chain. This means that we don't need proof recording during
import (since there is no storage weight).
- If we detect the `ParachainSystem` pallet, we assume that we are
dealing with a parachain and take corresponding actions like patching a
para id into the genesis state.

On the inherent side, I am currently supplying the standard inherents
every parachain needs.

In the current state, `frame-omni-bencher` supports all system chains.
In follow-up PRs, we could add additional inherents to increase
compatibility.

Since we are building a block during the benchmark, we also need to
build an extrinsic. By default, I am leveraging subxt to build the xt
dynamically. If a chain is not compatible with the `SubstrateConfig`
that comes with `subxt`, it can provide a custom extrinsic builder to
benchmarking-cli. This requires either a custom bencher implementation
or an integration into the parachains node.

Also cumulus-test-runtime has been migrated to provide genesis configs.

## Chain Compatibility
The current version here is compatible with the system chains and common
substrate chains. The way to go for others would be to customize the
frame-omni-bencher by providing a custom extrinsicbuilder. I did an
example implementation that works for mythical:
https://github.com/skunert/mythical-bencher

## Follow-Ups
- After #6040 is finished, we should integrate this here to make the
tooling truly useful. In the current form, the state is fairly small and
not representative.

## How to Review
I recommend starting from
[here](https://github.com/paritytech/polkadot-sdk/pull/5891/files#diff-50830ff756b3ac3403b7739d66c9e3a5185dbea550669ca71b28d19c7a2a54ecR264),
this method is the main entry point for omni-bencher and `polkadot`
binary.

TBD:
- [x] PRDoc

---------

Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>

This PR refactors `pallet-identity` to decouple usernames from
identities.

Main changes in this PR:
- Separate usernames from identities in storage, allowing for correct
deposit accounting
- Introduce the option for username authorities to put up a deposit to
issue a username
- Allow authorities to remove usernames by declaring the intent to do
so, then removing the username after the grace period expires
- Refactor the authority storage to be keyed by suffix rather than owner
account.
- Introduce the concept of a system provider for a username, different
from a governance allocation, allowing for usernames set by the system
and not a specific authority
- Implement multi-block migration to enable all of the changes described
above

---------

Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Co-authored-by: Ankan <10196091+Ank4n@users.noreply.github.com>

Redo of https://github.com/paritytech/polkadot-sdk/pull/5953

---------

Co-authored-by: Alexander Theißen <alex.theissen@me.com>
Co-authored-by: GitHub Action <action@github.com>

Resolves https://github.com/paritytech/polkadot-sdk/issues/6200

Also sets the feature on the rococo-parachain. Will be useful for
zombienet testing

on top of https://github.com/paritytech/polkadot-sdk/pull/5423

This PR implements the plumbing work required for
https://github.com/paritytech/polkadot-sdk/issues/5047 . I also added
additional helper methods gated by feature "test" in primitives.

TODO:
- [x] PRDoc

---------

Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Co-authored-by: GitHub Action <action@github.com>

`ForeignCreatorsSovereignAccountOf` is used by `ForeignCreators` filter
to convert location to `AccountId`, _after_ `ForeignCreators::IsForeign`
filter passes for an (asset, location) pair.

The `IsForeign` filter is the actual differentiator, so if a location
passes it, we should support converting it to an `AccountId`.

As such, this commit replaces `ForeignCreatorsSovereignAccountOf`
converter with the more general `LocationToAccountId` converter.

Signed-off-by: Adrian Catangiu <adrian@parity.io>

Fixes #5576

This allows contracts to be used with an AccountId32 through normal
extrinsics and not only through the eth compat layer. It works by adding
a new extrinsic `map_account` that lets people register their
AccountId32.

---------

Co-authored-by: command-bot <>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Cyrill Leutwiler <cyrill@parity.io>

This PR adds `build_struct_json_patch` which helps to generate a JSON
used for preset.

Here is doc and example:

https://github.com/paritytech/polkadot-sdk/blob/d868b858/substrate/frame/support/src/generate_genesis_config.rs#L168-L266

And real-world usage:

https://github.com/paritytech/polkadot-sdk/blob/d868b858

/cumulus/parachains/runtimes/assets/asset-hub-rococo/src/genesis_config_presets.rs#L37-L61

Closes #5700

---------

Co-authored-by: Sebastian Kunert <skunert49@gmail.com>

provides low-level documentation on how the omni-node is meant to work.
This is meant to act as reusable material for other teams (e.g.
Papermoon and W3F) to use and integrate into the high level Polkadot
documentation.

Broadly speaking, for omni-node to have great rust-docs, we need to
focus on the following crates, all of which got a bit of love in this
PR:

1. `sp-genesis-builder`
2. `polkadot-omni-node`
3. `polkadot-omni-node-lib`
4. `frame-omni-bencher`

On top of this, we have now: 

* `polkadot_sdk_docs::guides` contains two new steps demonstrating the
most basic version of composing your pallet, putting it into a runtime,
and putting that runtime into omni-node
* `polkadot_sdk_docs::reference_docs::omni_node` to explain in more
detail how omni-node differs from the old-school node.
* `polkadot_sdk_docs::reference_docs::frame_weight_benchmarking` to
finally have a minimal reference about weights and benchmarking.
* It provides tests for some of the steps in
https://github.com/paritytech/polkadot-sdk/issues/5568


closes https://github.com/paritytech/polkadot-sdk/issues/5568
closes https://github.com/paritytech/polkadot-sdk/issues/4781

Next steps

- [x] Ensure the README of the parachain template is up-to-date.
@iulianbarbu


- [ ] Readme for `polkadot-omni-node` and similar is updated. For now,
use `cargo-readme` and copy over the rust-docs.

To build the branch locally and run this:
https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/meta_contributing/index.html#how-to-develop-locally

---------

Co-authored-by: Iulian Barbu <14218860+iulianbarbu@users.noreply.github.com>
Co-authored-by: Sebastian Kunert <skunert49@gmail.com>
Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>

Add pallet-revive to Westend runtime, and configure the runtime to
accept Ethereum signed transaction

A follow-up to https://github.com/paritytech/polkadot-sdk/pull/5599.
Assets in a pool with the native one are returned from
`query_acceptable_payment_assets`. Now those assets can be used in
`query_weight_to_asset_fee` to get the correct amount that needs to be
paid.

---------

Co-authored-by: command-bot <>

I noticed that hardware benchmarks are being run even though we pass the
--no-hardware-benchmarks cli flag. After some debugging, the cause is an
incorrect usage of the `then_some` method.

From [std
docs](https://doc.rust-lang.org/std/primitive.bool.html#method.then_some):

> Arguments passed to then_some are eagerly evaluated; if you are
passing the result of a function call, it is recommended to use
[then](https://doc.rust-lang.org/std/primitive.bool.html#method.then),
which is lazily evaluated.

```rust
let mut a = 0;
let mut function_with_side_effects = || { a += 1; };

true.then_some(function_with_side_effects());
false.then_some(function_with_side_effects());

// `a` is incremented twice because the value passed to `then_some` is
// evaluated eagerly.
assert_eq!(a, 2);
```

This PR fixes all the similar usages of the `then_some` method across
the codebase.

polkadot address: 138eUqXvUYT3o4GdbnWQfGRzM8yDWh5Q2eFrFULL7RAXzdWD

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

This PR backports regular version bumps and prdocs reordering from the
current stable release back to master

Fixed in Polkadot and Kusama in
https://github.com/polkadot-fellows/runtimes/pull/434 and this PR just
adds to testnets.

We can handle a maximum of 28 assignments inside one XCM, while it's
possible to have 80 (if a region is interlaced 79 times).
This can be chunked on the coretime chain side but currently the
scheduler on the relay makes assumptions that means we can't send more
than one chunk for a given core.

This just truncates the additional assignments until we can extend the
relay to support this. This means that the first 27 assignments are
taken, the final 28th is used to pad with idle to complete the mask (the
relay also assumes that every schedule is complete). Any other
assignments are dropped.

---------

Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

Changed returned type of API methods from `Result<bool,
xcm_runtime_apis::trusted_query::Error>` to a typed one `type
XcmTrustedQueryResult = Result<bool,
xcm_runtime_apis::trusted_query::Error>;`
Follow-up of
[PR-6039](https://github.com/paritytech/polkadot-sdk/pull/6039)

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Adrian Catangiu <adrian@parity.io>