Backport #7322 into `stable2412` from bkontur.

See the
[documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md)
on how to use this bot.

<!--
  # To be used by other automation, do not modify:
  original-pr-number: #${pull_number}
-->

Co-authored-by: Branislav Kontur <bkontur@gmail.com>

This is a partial backport of #6825 and #7205. Only the node-side minor
changes were ported. However, this creates forward compatibility of the
omni-node from 2412 with runtimes built after #6825.

Backport #6604 into `stable2412` from bkchr.

See the
[documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md)
on how to use this bot.

<!--
  # To be used by other automation, do not modify:
  original-pr-number: #${pull_number}
-->

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Bastian Köcher <info@kchr.de>

Backport #6855 into `stable2412` from alistair-singh.

See the
[documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md)
on how to use this bot.

<!--
  # To be used by other automation, do not modify:
  original-pr-number: #${pull_number}
-->

---------

Co-authored-by: Alistair Singh <alistair.singh7@gmail.com>
Co-authored-by: Adrian Catangiu <adrian@parity.io>

Backport #7050 into `stable2412` from skunert.

See the
[documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md)
on how to use this bot.

<!--
  # To be used by other automation, do not modify:
  original-pr-number: #${pull_number}
-->

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

Backport #6919 into `stable2412` from bkontur.

See the
[documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md)
on how to use this bot.

<!--
  # To be used by other automation, do not modify:
  original-pr-number: #${pull_number}
-->

Co-authored-by: Branislav Kontur <bkontur@gmail.com>

Backport #6505 into `stable2412` from seadanda.

See the
[documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md)
on how to use this bot.

<!--
  # To be used by other automation, do not modify:
  original-pr-number: #${pull_number}
-->

---------

Co-authored-by: Dónal Murray <donal.murray@parity.io>

Backport #6885 into `stable2412` from skunert.

See the
[documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md)
on how to use this bot.

<!--
  # To be used by other automation, do not modify:
  original-pr-number: #${pull_number}
-->

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

Backport #6646 into `stable2412` from iulianbarbu.

See the
[documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md)
on how to use this bot.

<!--
  # To be used by other automation, do not modify:
  original-pr-number: #${pull_number}
-->

Co-authored-by: Iulian Barbu <14218860+iulianbarbu@users.noreply.github.com>

Backporting #6814 to stable2412 so we can test the new XCM scenario of
doing a cross-chain transfer and a transact on the same step.

---------

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

Backporting #6566 to stable2412

Last feature we wanted for V5, changing `SetAssetClaimer` to be just one
of many possible "hints" that you can specify at the beginning of your
program to change its behaviour.

This makes it easier to add new hints in the future and have barriers
accept them.

---------

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

Backport #6781 into `stable2412` from bkontur.

See the
[documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md)
on how to use this bot.

<!--
  # To be used by other automation, do not modify:
  original-pr-number: #${pull_number}
-->

---------

Co-authored-by: Branislav Kontur <bkontur@gmail.com>

Backport #4834 into `stable2412` from acatangiu.

See the
[documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md)
on how to use this bot.

<!--
  # To be used by other automation, do not modify:
  original-pr-number: #${pull_number}
-->

---------

Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>

Backport of https://github.com/paritytech/polkadot-sdk/pull/6643 to
stable2412.

We need it before the release so we have a good story with chains that
haven't upgraded yet.

---------

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

This PR contains backports of:
- https://github.com/paritytech/polkadot-sdk/pull/6465
- https://github.com/paritytech/polkadot-sdk/pull/6536
- https://github.com/paritytech/polkadot-sdk/pull/6579
- https://github.com/paritytech/polkadot-sdk/pull/6645

(when those were merged, bot didn't create backport PRs to stable2412)

---------

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

This PR is a backport of #6418.

For context, `TransactionExtension`, introduced in #3685, is part of the
`stable2412` release, and this PR brings important fixes and quality of
life improvements. Doing the backport now allows us to not break the
interface later.

Opened against #6473 as the changes in the original PR were made on top
of the changes in this backport.

---------

Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
Co-authored-by: GitHub Action <action@github.com>

Backporting the new V5 `ExecuteWithOrigin` instruction to stable2412

---------

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>

# 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/iss...

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>