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`

We currently use a bit of a hack in `.cargo/config` to make sure that
clippy isn't too annoying by specifying the list of lints.

There is now a stable way to define lints for a workspace. The only down
side is that every crate seems to have to opt into this so there's a
*few* files modified in this PR.

Dependencies:

- [x] PR that upgrades CI to use rust 1.74 is merged.

---------

Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: Branislav Kontur <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>

Co-authored-by: command-bot <>

So far the `bridge-hub-test-utils` contained a tests set for testing
BridgeHub runtime that is bridging with the remote **parachain**. But we
have https://github.com/paritytech/polkadot-sdk/pull/2540 coming, which
would add Rococo <> Bulletin chain bridge (where Bulletin = standalone
chain that is using GRANDPA finality). Then it'll be expanded to
Polkadot BH as well.

So this PR adds the same set of tests to the `bridge-hub-test-utils`,
but for the case when remote chain is the chain with GRANDPA finality.
There's a lot of changes in this PR - I'll describe some:
- I've added `BasicParachainRuntime` trait to decrease number of lines
we need to add to `where` clause. Could revert, but imo it is useful;
- `cumulus/parachains/runtimes/bridge-hubs/test-utils/src/test_data` is
a submodule for generating test data for the test sets.
`from_parachain.rs` is used in tests for the case when remote chain is a
parachain, `from_grandpa_chain.rs` - for the bridges with remote GRANDPA
chains. `mod.rs` has some code, shared by both types of tests;
- `cumulus/parachains/runtimes/bridge-hubs/test-utils/src/test_data` is
a submodule with all test cases. The `mod.rs` has tests, suitable for
all cases. There's also `wth_parachain.rs` and `with_grandpa_chain.rs`
with the same meaning as above;
- I've merged the "core" code of two previous tests -
`relayed_incoming_message_works` and `complex_relay_extrinsic_works`
into one single `relayed_incoming_message_works` test. So now we are
always constructing extrinsics and are dispatching them using executive
module (meaning all signed extensions are also tested).

New test set is used here:
https://github.com/paritytech/polkadot-sdk/pull/2540. Once this PR is
merged, I'll merge that other PR with master to remove duplicate
changes.

I'm also planning to cleanup generic constraints + remove some
unnecessary assumptions about used chains in a follow-up PRs. But for
now I think this PR has enough changes, so don't want to complicate it
even more.

---

Breaking changes for the code that have used those tests before:
- the `construct_and_apply_extrinsic` callback now accepts the
`RuntimeCall` instead of the `pallet_utility::Call`;
- the `construct_and_apply_extrinsic` now may be called multiple times
for the single test, so make sure the `frame_system::CheckNonce` is
correctly constructed;
- all previous tests have been moved from
`bridge_hub_test_utils::test_cases` to
`bridge_hub_test_utils::test_cases::from_parachain` module;
- there are several changes in test arguments - please refer to
https://github.com/paritytech/polkadot-sdk/compare/sv-tests-for-bridge-with-remote-grandpa-chain?expand=1#diff-79a28d4d3e1749050341c2424f00c4c139825b1a20937767f83e58b95166735c
for details.

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]>

We were not filtering for sibling parachains, but for sibling anything

---------

Co-authored-by: Branislav Kontur <[email protected]>
Co-authored-by: command-bot <>

## Summary

This pull request proposes a solution for improved control of the
versioned XCM flow over the bridge (across different consensus chains)
and resolves the situation where the sending chain/consensus has already
migrated to a higher XCM version than the receiving chain/consensus.

## Problem/Motivation

The current flow over the bridge involves a transfer from AssetHubRococo
(AHR) to BridgeHubRococo (BHR) to BridgeHubWestend (BHW) and finally to
AssetHubWestend (AHW), beginning with a reserve-backed transfer on AHR.

In this process:
1. AHR sends XCM `ExportMessage` through `XcmpQueue`, incorporating XCM
version checks using the `WrapVersion` feature, influenced by
`pallet_xcm::SupportedVersion` (managed by
`pallet_xcm::force_xcm_version` or version discovery).

2. BHR handles the `ExportMessage` instruction, utilizing the latest XCM
version. The `HaulBlobExporter` converts the inner XCM to
[`VersionedXcm::from`](https://github.com/paritytech/polkadot-sdk/blob/63ac2471/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465-L467),
also using the latest XCM version.

However, challenges arise:
- Incompatibility when BHW uses a different version than BHR. For
instance, if BHR migrates to **XCMv4** while BHW remains on **XCMv3**,
BHR's `VersionedXcm::from` uses `VersionedXcm::V4` variant, causing
encoding issues for BHW.
  ```
	/// Just a simulation of possible error, which could happen on BHW
	/// (this code is based on actual master without XCMv4)
	let encoded = hex_literal::hex!("0400");
	println!("{:?}", VersionedXcm::<()>::decode(&mut &encoded[..]));

Err(Error { cause: None, desc: "Could not decode `VersionedXcm`, variant
doesn't exist" })
  ``` 
- Similar compatibility issues exist between AHR and AHW.

## Solution

This pull request introduces the following solutions:

1. **New trait `CheckVersion`** - added to the `xcm` module and exposing
`pallet_xcm::SupportedVersion`. This enhancement allows checking the
actual XCM version for desired destinations outside of the `pallet_xcm`
module.

2. **Version Check in `HaulBlobExporter`** uses `CheckVersion` to check
known/configured destination versions, ensuring compatibility. For
example, in the scenario mentioned, BHR can store the version `3` for
BHW. If BHR is on XCMv4, it will attempt to downgrade the message to
version `3` instead of using the latest version `4`.

3. **Version Check in `pallet-xcm-bridge-hub-router`** - this check
ensures compatibility with the real destination's XCM version,
preventing the unnecessary sending of messages to the local bridge hub
if versions are incompatible.

These additions aim to improve the control and compatibility of XCM
flows over the bridge and addressing issues related to version
mismatches.

## Possible alternative solution

_(More investigation is needed, and at the very least, it should extend
to XCMv4/5. If this proves to be a viable option, I can open an RFC for
XCM.)._

Add the `XcmVersion` attribute to the `ExportMessage` so that the
sending chain can determine, based on what is stored in
`pallet_xcm::SupportedVersion`, the version the destination is using.
This way, we may not need to handle the version in `HaulBlobExporter`.

```
ExportMessage {
	network: NetworkId,
	destination: InteriorMultiLocation,
	xcm: Xcm<()>
	destination_xcm_version: Version, // <- new attritbute
},
```

```
pub trait ExportXcm {
        fn validate(
		network: NetworkId,
		channel: u32,
		universal_source: &mut Option<InteriorMultiLocation>,
		destination: &mut Option<InteriorMultiLocation>,
		message: &mut Option<Xcm<()>>,
                destination_xcm_version: Version, , // <- new attritbute
	) -> SendResult<Self::Ticket>;
```

## Future Directions

This PR does not fix version discovery over bridge, further
investigation will be conducted here:
https://github.com/paritytech/polkadot-sdk/issues/2417.

## TODO

- [x] `pallet_xcm` mock for tests uses hard-coded XCM version `2` -
change to 3 or lastest?
- [x] fix `pallet-xcm-bridge-hub-router`
- [x] fix HaulBlobExporter with version determination
[here](https://github.com/paritytech/polkadot-sdk/blob/2183669d/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465)
- [x] add unit-tests to the runtimes
- [x] run benchmarks for `ExportMessage`
- [x] extend local run scripts about `force_xcm_version(dest, version)`
- [ ] when merged, prepare governance calls for Rococo/Westend
- [ ] add PRDoc

Part of: https://github.com/paritytech/parity-bridges-common/issues/2719

---------

Co-authored-by: command-bot <>

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]>

Treasury Pallet Instance for the Fellowship in Westend Collectives.

In this update, we present a Treasury Pallet Instance that is under the
control of the Fellowship body, with oversight from the Root and
Treasurer origins. Here's how it is governed:
- the Root origin have the authority to reject or approve spend
proposals, with no amount limit for approvals.
- the Treasurer origin have the authority to reject or approve spend
proposals, with approval limits of up to 10,000,000 DOT.
- Voice of all Fellows ranked at 3 or above can reject or approve spend
proposals, with a maximum approval limit of 10,000 DOT.
- Voice of Fellows ranked at 4 or above can also reject or approve spend
proposals, with a maximum approval limit of 10,000,000 DOT.

Additionally, we introduce the Asset Rate Pallet Instance to establish
conversion rates from asset A to B. This is used to determine if a
proposed spend amount involving a non-native asset is permissible by the
commanding origin. The rates can be set up by the Root, Treasurer
origins, or Voice of all Fellows.

---------

Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: joepetrowski <[email protected]>

`testnets-common` was introduced recently to start to separate testnet
parachain configurations from those of Polkadot and Kusama.

The `locks-review` and `polkadot-review` requirements are removed from
`parachains-common` in
https://github.com/paritytech/polkadot-sdk/pull/2564 and there are
[plans](https://github.com/paritytech/polkadot-sdk/pull/2564#discussion_r1410882115)
to move the Polkadot and Kusama contents of that package to the
fellowship, `testnets-common` is no longer needed.

This PR removes the crate and replaces uses of it in
`collectives-westend`, the only place it is currently used.

As suggested in this thread:
https://github.com/polkadot-fellows/runtimes/pull/87#discussion_r1400237122

We already have the `IsChildSystemParachain`, which may be used at relay
chain, but it can't be used at a parachain level. So let's use
`AllSiblingSystemParachains` for that. I was thinking about
`AllSystemParachains`, but it may cause wrong impression that it can be
used at a relay chain level.

---------

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

## Summary

This PR aligns Rococo/Westend bridge with latest Bridges repo
development:
- https://github.com/paritytech/parity-bridges-common/pull/2727
- https://github.com/paritytech/parity-bridges-common/pull/2728
- https://github.com/paritytech/parity-bridges-common/pull/2729




Part of: https://github.com/paritytech/parity-bridges-common/issues/2452

# 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 <>

Removes obsolete fields from the `QueueConfigData` structure. For the
remaining fields, if they use the old defaults, we replace them with the
new defaults.

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

Using taplo, fixes all our broken and inconsistent toml formatting and
adds CI to keep them tidy.

If people want we can customise the format rules as described here
https://taplo.tamasfe.dev/configuration/formatter-options.html

@ggwpez

, I suggest zepter is used only for checking features are
propagated, and leave formatting for taplo to avoid duplicate work and
conflicts.

TODO
- [x] Use `exclude = [...]` syntax in taplo file to ignore zombienet
tests instead of deleting the dir

---------

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

Bumps the known_good_semver group with 2 updates:
[serde](https://github.com/serde-rs/serde) and
[clap](https://github.com/clap-rs/clap).

Updates `serde` from 1.0.188 to 1.0.193
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/serde-rs/serde/releases">serde's
releases</a>.</em></p>
<blockquote>
<h2>v1.0.193</h2>
<ul>
<li>Fix field names used for the deserialization of
<code>RangeFrom</code> and <code>RangeTo</code> (<a
href="https://redirect.github.com/serde-rs/serde/issues/2653">#2653</a>,
<a
href="https://redirect.github.com/serde-rs/serde/issues/2654">#2654</a>,
<a
href="https://redirect.github.com/serde-rs/serde/issues/2655">#2655</a>,
thanks <a
href="https://github.com/emilbonnek"><code>@​emilbonnek</code></a>)</li>
</ul>
<h2>v1.0.192</h2>
<ul>
<li>Allow internal tag field in untagged variant (<a
href="https://redirect.github.com/serde-rs/serde/issues/2646">#2646</a>,
thanks <a
href="https://github.com/robsdedude"><code>@​robsdedude</code></a>)</li>
</ul>
<h2>v1.0.191</h2>
<ul>
<li>Documentation improvements</li>
</ul>
<h2>v1.0.190</h2>
<ul>
<li>Preserve NaN sign when deserializing f32 from f64 or vice versa (<a
href="https://redirect.github.com/serde-rs/serde/issues/2637">#2637</a>)</li>
</ul>
<h2>v1.0.189</h2>
<ul>
<li>Fix &quot;cannot infer type&quot; error when internally tagged enum
contains untagged variant (<a
href="https://redirect.github.com/serde-rs/serde/issues/2613">#2613</a>,
thanks <a href="https://github.com/ahl"><code>@​ahl</code></a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/serde-rs/serde/commit/44613c7d0190dbb5ecd2d5ec19c636f45b7488cc"><code>44613c7</code></a>
Release 1.0.193</li>
<li><a
href="https://github.com/serde-rs/serde/commit/c706281df3c8d50dba1763f19c856df2746eba6c"><code>c706281</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/serde/issues/2655">#2655</a>
from dtolnay/rangestartend</li>
<li><a
href="https://github.com/serde-rs/serde/commit/65d75b8fe3105f00ab2e01537d568d4587167582"><code>65d75b8</code></a>
Add RangeFrom and RangeTo tests</li>
<li><a
href="https://github.com/serde-rs/serde/commit/332b0cba40bcbcc7a6b23a9706277c54791a9856"><code>332b0cb</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/serde/issues/2654">#2654</a>
from dtolnay/rangestartend</li>
<li><a
href="https://github.com/serde-rs/serde/commit/8c4af412969086bc8f54fdc2a079d373632e0a03"><code>8c4af41</code></a>
Fix more RangeFrom / RangeEnd mixups</li>
<li><a
href="https://github.com/serde-rs/serde/commit/24a78f071b22ae491eec4127be696ac255b9b5d3"><code>24a78f0</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/serde/issues/2653">#2653</a>
from emilbonnek/fix/range-to-from-de-mixup</li>
<li><a
href="https://github.com/serde-rs/serde/commit/c91c33436d7aaef7472ebc18b734ddc9b5bd11fa"><code>c91c334</code></a>
Fix Range{From,To} deserialize mixup</li>
<li><a
href="https://github.com/serde-rs/serde/commit/2083f43a287cac8302009fda5bbe41518dd83209"><code>2083f43</code></a>
Update ui test suite to nightly-2023-11-19</li>
<li><a
href="https://github.com/serde-rs/serde/commit/4676abdc9e6bbbddfb33a00ce8d7e81e92f01120"><code>4676abd</code></a>
Release 1.0.192</li>
<li><a
href="https://github.com/serde-rs/serde/commit/35700eb23e21d8cb198ef4a422ddad13b855ce3b"><code>35700eb</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/serde/issues/2646">#2646</a>
from robsdedude/fix/2643/allow-tag-field-in-untagged</li>
<li>Additional commits viewable in <a
href="https://github.com/serde-rs/serde/compare/v1.0.188...v1.0.193">compare
view</a></li>
</ul>
</details>
<br />

Updates `clap` from 4.4.6 to 4.4.10
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/clap-rs/clap/releases">clap's
releases</a>.</em></p>
<blockquote>
<h2>v4.4.10</h2>
<h2>[4.4.10] - 2023-11-28</h2>
<h3>Documentation</h3>
<ul>
<li>Link out to changelog</li>
<li>Cross link derive's attribute reference to derive tutorial</li>
</ul>
<h2>v4.4.9</h2>
<h2>[4.4.9] - 2023-11-27</h2>
<h3>Fixes</h3>
<ul>
<li><em>(help)</em> Show correct <code>Command::about</code> under
flattened headings</li>
<li><em>(help)</em> Respect <code>hide</code> when flattening
subcommands</li>
</ul>
<h2>v4.4.8</h2>
<h2>[4.4.8] - 2023-11-10</h2>
<h3>Features</h3>
<ul>
<li>Add <code>Command::flatten_help</code> to allow <code>git stash
-h</code> like help for subcommands</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's
changelog</a>.</em></p>
<blockquote>
<h2>[4.4.10] - 2023-11-28</h2>
<h3>Documentation</h3>
<ul>
<li>Link out to changelog</li>
<li>Cross link derive's attribute reference to derive tutorial</li>
</ul>
<h2>[4.4.9] - 2023-11-27</h2>
<h3>Fixes</h3>
<ul>
<li><em>(help)</em> Show correct <code>Command::about</code> under
flattened headings</li>
<li><em>(help)</em> Respect <code>hide</code> when flattening
subcommands</li>
</ul>
<h2>[4.4.8] - 2023-11-10</h2>
<h3>Features</h3>
<ul>
<li>Add <code>Command::flatten_help</code> to allow <code>git stash
-h</code> like help for subcommands</li>
</ul>
<h2>[4.4.7] - 2023-10-24</h2>
<h3>Performance</h3>
<ul>
<li>Reduced code size</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/clap-rs/clap/commit/c0a1814d3c1d93c18faaedc95fd251846e47f4fe"><code>c0a1814</code></a>
chore: Release</li>
<li><a
href="https://github.com/clap-rs/clap/commit/c83e681e20b05f7e128088f47f8fcfc44e8ea166"><code>c83e681</code></a>
docs: Update changelog</li>
<li><a
href="https://github.com/clap-rs/clap/commit/91bcac4ca9d442786f554abeb7b1ed6d7a464a42"><code>91bcac4</code></a>
Merge pull request <a
href="https://redirect.github.com/clap-rs/clap/issues/5230">#5230</a>
from epage/migrate</li>
<li><a
href="https://github.com/clap-rs/clap/commit/030d87505d150345ddd425c1df21c034d2ae7748"><code>030d875</code></a>
docs: Link out to the changelog at the relevant tag</li>
<li><a
href="https://github.com/clap-rs/clap/commit/b661a9de04aebd1adaaafdbf7e470f07a8d8a36d"><code>b661a9d</code></a>
Merge pull request <a
href="https://redirect.github.com/clap-rs/clap/issues/5229">#5229</a>
from epage/derive</li>
<li><a
href="https://github.com/clap-rs/clap/commit/a08587b00e347492165ded1415bad6ab339e9f0b"><code>a08587b</code></a>
docs(derive): Link to tutorial sections for attributes</li>
<li><a
href="https://github.com/clap-rs/clap/commit/21b671f689bc0b8d790dc8c42902c22822bf6f82"><code>21b671f</code></a>
chore: Release</li>
<li><a
href="https://github.com/clap-rs/clap/commit/93ba76dbaaf9136313a4fe2978693cc39fa467dd"><code>93ba76d</code></a>
docs: Update changelog</li>
<li><a
href="https://github.com/clap-rs/clap/commit/c1c55b30d853446e2cab78664c0d22c1b77d4dfd"><code>c1c55b3</code></a>
Merge pull request <a
href="https://redirect.github.com/clap-rs/clap/issues/5228">#5228</a>
from epage/flat</li>
<li><a
href="https://github.com/clap-rs/clap/commit/b13f6d98622b80ba30e63c2c6e65d218cc8a4de3"><code>b13f6d9</code></a>
fix(help): Hide 'help' if only flattened subcommand</li>
<li>Additional commits viewable in <a
href="https://github.com/clap-rs/clap/compare/v4.4.6...v4.4.10">compare
view</a></li>
</ul>
</details>
<br />


Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions


</details>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

see #2189

This PR does the following:
- Bring the user api functions into a new pallet-contracts-uapi (They
are currently defined in ink!
[here])(https://github.com/paritytech/ink/blob/master/crates/env/src/engine/on_chain/ext.rs)
- Add older api versions and unstable to the user api trait.
- Remove pallet-contracts-primitives and bring the types it defined in
uapi / pallet-contracts
- Add the infrastructure to build fixtures from Rust files and test it
works by replacing `dummy.wat` and `call.wat`
- Move all the doc from wasm/runtime.rs to pallet-contracts-uapi.

This will be done in a follow up:
- convert the rest of the test from .wat to rust
- bring risc-v uapi up to date with wasm
- finalize the uapi host fns, making sure everything is codegen from the
source host fns in pallet-contracts

---------

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

rotko networks parachain bootnodes 
```
# array of commands for testing
parachains=(
  "./polkadot-parachain --chain asset-hub-polkadot --reserved-only --reserved-nodes /dns/mint14.rotko.net/tcp/33514/p2p/12D3KooWKkzLjYF6M5eEs7nYiqEtRqY8SGVouoCwo3nCWsRnThDW --no-hardware-benchmarks"
  "./polkadot-parachain --chain asset-hub-polkadot --reserved-only --reserved-nodes /dns/mint14.rotko.net/tcp/34514/ws/p2p/12D3KooWKkzLjYF6M5eEs7nYiqEtRqY8SGVouoCwo3nCWsRnThDW --no-hardware-benchmarks"
  "./polkadot-parachain --chain asset-hub-polkadot --reserved-only --reserved-nodes /dns/mint14.rotko.net/tcp/35514/wss/p2p/12D3KooWKkzLjYF6M5eEs7nYiqEtRqY8SGVouoCwo3nCWsRnThDW --no-hardware-benchmarks"
  "./polkadot-parachain --chain asset-hub-kusama --reserved-only --reserved-nodes /dns/mine14.rotko.net/tcp/33524/p2p/12D3KooWJUFnjR2PNbsJhudwPVaWCoZy1acPGKjM2cSuGj345BBu --no-hardware-benchmarks"
  "./polkadot-parachain --chain asset-hub-kusama --reserved-only --reserved-nodes /dns/mine14.rotko.net/tcp/34524/ws/p2p/12D3KooWJUFnjR2PNbsJhudwPVaWCoZy1acPGKjM2cSuGj345BBu --no-hardware-benchmarks"
  "./polkadot-parachain --chain asset-hub-kusama --reserved-only --reserved-nodes /dns/mine14.rotko.net/tcp/35524/wss/p2p/12D3KooWJUFnjR2PNbsJhudwPVaWCoZy1acPGKjM2cSuGj345BBu --no-hardware-benchmarks"
  "./polkadot-parachain --chain asset-hub-westend --reserved-only --reserved-nodes /dns/wmint14.rotko.net/tcp/33534/p2p/12D3KooWE4UDXqgtTcMCyUQ8S4uvaT8VMzzTBA6NWmKuYwTacWuN --no-hardware-benchmarks"
  "./polkadot-parachain --chain asset-hub-westend --reserved-only --reserved-nodes /dns/wmint14.rotko.net/tcp/34534/ws/p2p/12D3KooWE4UDXqgtTcMCyUQ8S4uvaT8VMzzTBA6NWmKuYwTacWuN --no-hardware-benchmarks"
  "./polkadot-parachain --chain asset-hub-westend --reserved-only --reserved-nodes /dns/wmint14.rotko.net/tcp/35534/wss/p2p/12D3KooWE4UDXqgtTcMCyUQ8S4uvaT8VMzzTBA6NWmKuYwTacWuN --no-hardware-benchmarks"
  "./polkadot-parachain --chain bridge-hub-polkadot --reserved-only --reserved-nodes /dns/pbr13.rotko.net/tcp/33543/p2p/12D3KooWMxZY7tDc2Rh454VaJJ7RexKAXVS6xSBEvTnXSGCnuGDw --no-hardware-benchmarks"
  "./polkadot-parachain --chain bridge-hub-polkadot --reserved-only --reserved-nodes /dns/pbr13.rotko.net/tcp/34543/ws/p2p/12D3KooWMxZY7tDc2Rh454VaJJ7RexKAXVS6xSBEvTnXSGCnuGDw --no-hardware-benchmarks"
  "./polkadot-parachain --chain bridge-hub-polkadot --reserved-only --reserved-nodes /dns/pbr13.rotko.net/tcp/35543/wss/p2p/12D3KooWMxZY7tDc2Rh454VaJJ7RexKAXVS6xSBEvTnXSGCnuGDw --no-hardware-benchmarks"
  "./polkadot-parachain --chain bridge-hub-kusama --reserved-only --reserved-nodes /dns/kbr13.rotko.net/tcp/33553/p2p/12D3KooWAmBp54mUEYtvsk2kxNEsDbAvdUMcaghxKXgUQxmPEQ66 --no-hardware-benchmarks"
  "./polkadot-parachain --chain bridge-hub-kusama --reserved-only --reserved-nodes /dns/kbr13.rotko.net/tcp/34553/ws/p2p/12D3KooWAmBp54mUEYtvsk2kxNEsDbAvdUMcaghxKXgUQxmPEQ66 --no-hardware-benchmarks"
  "./polkadot-parachain --chain bridge-hub-kusama --reserved-only --reserved-nodes /dns/kbr13.rotko.net/tcp/35553/wss/p2p/12D3KooWAmBp54mUEYtvsk2kxNEsDbAvdUMcaghxKXgUQxmPEQ66 --no-hardware-benchmarks"
  "./polkadot-parachain --chain bridge-hub-westend --reserved-only --reserved-nodes /dns/wbr13.rotko.net/tcp/33563/p2p/12D3KooWJyeRHpxZZbfBCNEgeUFzmRC5AMSAs2tJhjJS1k5hULkD --no-hardware-benchmarks"
  "./polkadot-parachain --chain bridge-hub-westend --reserved-only --reserved-nodes /dns/wbr13.rotko.net/tcp/34563/ws/p2p/12D3KooWJyeRHpxZZbfBCNEgeUFzmRC5AMSAs2tJhjJS1k5hULkD --no-hardware-benchmarks"
  "./polkadot-parachain --chain bridge-hub-westend --reserved-only --reserved-nodes /dns/wbr13.rotko.net/tcp/35563/wss/p2p/12D3KooWJyeRHpxZZbfBCNEgeUFzmRC5AMSAs2tJhjJS1k5hULkD --no-hardware-benchmarks"
  "./polkadot-parachain --chain collectives-polkadot --reserved-only --reserved-nodes /dns/pch13.rotko.net/tcp/33573/wss/p2p/12D3KooWRXudHoazPZ9osMfdY38e8CBxQLD4RhrVeHpRSNNpcDtH --no-hardware-benchmarks"
  "./polkadot-parachain --chain collectives-polkadot --reserved-only --reserved-nodes /dns/pch13.rotko.net/tcp/34573/wss/p2p/12D3KooWRXudHoazPZ9osMfdY38e8CBxQLD4RhrVeHpRSNNpcDtH --no-hardware-benchmarks"
  "./polkadot-parachain --chain collectives-polkadot --reserved-only --reserved-nodes /dns/pch13.rotko.net/tcp/35573/wss/p2p/12D3KooWRXudHoazPZ9osMfdY38e8CBxQLD4RhrVeHpRSNNpcDtH --no-hardware-benchmarks"
  "./polkadot-parachain --chain collectives-westend --reserved-only --reserved-nodes /dns/wch13.rotko.net/tcp/33593/p2p/12D3KooWPG85zhuSRoyptjLkFD4iJFistjiBmc15JgQ96B4fdXYr --no-hardware-benchmarks"
  "./polkadot-parachain --chain collectives-westend --reserved-only --reserved-nodes /dns/wch13.rotko.net/tcp/34593/ws/p2p/12D3KooWPG85zhuSRoyptjLkFD4iJFistjiBmc15JgQ96B4fdXYr --no-hardware-benchmarks"
  "./polkadot-parachain --chain collectives-westend --reserved-only --reserved-nodes /dns/wch13.rotko.net/tcp/35593/wss/p2p/12D3KooWPG85zhuSRoyptjLkFD4iJFistjiBmc15JgQ96B4fdXYr --no-hardware-benchmarks"
)
```

Since the Polkadot and Kusama runtimes are no longer in the repo, the
relevant systems parachains runtimes also need to be removed. More
context [here](https://github.com/paritytech/polkadot-sdk/issues/603)
and [here](https://github.com/paritytech/polkadot-sdk/pull/1731).

Removes the following:
- `asset-hub-kusama` and `asset-hub-polkadot`
- `bridge-hub-kusama` and `bridge-hub-polkadot`
- `collectives-polkadot`
- `glutton-kusama`

Partially solves #603 and adds to #1731.

Westend SP dmp queue pallet removal is complete.

<img width="1499" alt="Screenshot 2023-11-28 at 08 31 27"
src="https://github.com/paritytech/polkadot-sdk/assets/16665596/906246fb-3de9-4133-a827-431636a097ad">

<img width="1499" alt="Screenshot 2023-11-28 at 08 32 08"
src="https://github.com/paritytech/polkadot-sdk/assets/16665596/bde84891-b044-42c7-9a0b-59125cd24db1">

<img width="1499" alt="Screenshot 2023-11-28 at 08 31 45"
src="https://github.com/paritytech/polkadot-sdk/assets/16665596/38337484-0856-45c0-b9ff-8c785bc3c0e3">

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

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

This PR adds `derive_impl` on all `frame_system` config impls for mock
runtimes. The overridden configs are maintained as of now to ensure
minimal changes.

---------

Co-authored-by: Oliver Tale-Yazdi <[email protected]>

Just adds more tests.

## 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]>

DMP queue migration is complete and the pallet should be removed to fix
the check runtime upgrade CI.

<img width="1501" alt="Screenshot 2023-11-24 at 16 05 37"
src="https://github.com/paritytech/polkadot-sdk/assets/16665596/ee1da6bb-2756-4423-8085-1e4c73553ad5">

<img width="1501" alt="Screenshot 2023-11-24 at 16 06 44"
src="https://github.com/paritytech/polkadot-sdk/assets/16665596/03f3e88f-aed8-4eaa-aab6-7998f72258be">

On extrinsics/call, ensure local XCM execution is complete/successful.
Otherwise, fail the extrinsic so that state changes don't get committed
to the db.

Added regression tests that fail without the fix.

fixes #2237

---------

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

Collectives Westend is missing an `on-chain-release-build` feature flag.

This updates the tick runtime and polkadot-parachain collator to use
async backing.

Westend Collectives migration CI check can be fixed once we have
https://github.com/paritytech/try-runtime-cli/pull/58, will open another
PR once it is available.

- [x] Remove deprecated `DmpQueue` pallet from Rococo Contracts, the
migration is complete
- [x] Fix Asset Hub Rococo storage versions
- [x] Add migration check CI for Asset Hub Rococo and Westend Bridge Hub

This PR fixes two things:
- relax `force_default_xcm_version` for testnet system parachains (e.g.
BridgeHubWestend has now 2 and there is no way to change it to 3, so we
need to call `force_xcm_version(3)` for every parachain that it is
connected to, because we send XCMv3 messages)
- add `Storage` item to `PolkadotXcm` pallet definition (now we cannot
see storage items for `pallet_xcm` in PJS)


## TODO

- [ ] when merged open PR to `polkadot-fellows/runtimes` repo

Fix some incorrect doc-comments

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

Rococo<>Wococo bridge is replaced by Rococo<Westend bridge, so this PR
removes unneeded code.

- [x] update bridges subtree after
https://github.com/paritytech/parity-bridges-common/pull/2692

---------

Co-authored-by: command-bot <>
Co-authored-by: Svyatoslav Nikolsky <[email protected]>

Refunding surplus happens anyway on xcm_executor::post_process(),
automatically refunding surplus to original_origin at the end of
execution. Since SovereignPaidRemoteExporter doesn't ClearOrigin, it can
simply rely on the automatic mechanism.

Furthermore, RefundSurplus instruction refunds _surplus_. Surplus exists
only as a result of Transact, SetErrorHandler or SetAppendix
instructions, none of which being part of the
SovereignPaidRemoteExporter XCM program. So surplus is always zero here
anyway.

Add collectives and glutton parachain westend runtimes to prepare for
#1737.

The removal of system parachain native runtimes #1737 is blocked until
chainspecs and runtime APIs can be dealt with cleanly (merge of #1256
and follow up PRs).

In the meantime, these additions are ready to be merged to `master`, so
I have separated them out into this PR.

Also marked `bridge-hub-westend` as unimplemented in line with [this
issue](https://github.com/paritytech/parity-bridges-common/issues/2602).

TODO
- [x] add to `command-bot` benchmarks
- [x] add to `command-bot-scripts` benchmarks
- [x] generate weights

---------

Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: Muharem <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Branislav Kontur <[email protected]>

This PR introduces:
- XCM  host functions `xcm_send`, `xcm_execute`
- An Xcm trait into the config. that proxy these functions to to
`pallet_xcm`, or disable their usage by using `()`.
- A mock_network and xcm_test files to test the newly added xcm-related
functions.

---------

Co-authored-by: Keith Yeung <[email protected]>
Co-authored-by: Sasha Gryaznov <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Alexander Theißen <[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