## Motivation

`pallet-xcm` is the main user-facing interface for XCM functionality,
including assets manipulation functions like `teleportAssets()` and
`reserve_transfer_assets()` calls.

While `teleportAsset()` works both ways, `reserve_transfer_assets()`
works only for sending reserve-based assets to a remote destination and
beneficiary when the reserve is the _local chain_.

## Solution

This PR enhances `pallet_xcm::(limited_)reserve_withdraw_assets` to
support transfers when reserves are other chains.
This will allow complete, **bi-directional** reserve-based asset
transfers user stories using `pallet-xcm`.

Enables following scenarios:
- transferring assets with local reserve (was previously supported iff
asset used as fee also had local reserve - now it works in all cases),
- transferring assets with reserve on destination,
- transferring assets with reserve on remote/third-party chain (iff
assets and fees have same remote reserve),
- transferring assets with reserve different than the reserve of the
asset to be used as fees - meaning can be used to transfer random asset
with local/dest reserve while using DOT for fees on all involved chains,
even if DOT local/dest reserve doesn't match asset reserve,
- transferring assets with any type of local/dest reserve while using
fees which can be teleported between involved chains.

All of the above is done by pallet inner logic without the user having
to specify which scenario/reserves/teleports/etc. The correct scenario
and corresponding XCM programs are identified, and respectively, built
automatically based on runtime configuration of trusted teleporters and
trusted reserves.

#### Current limitations:
- while `fees` and "non-fee" `assets` CAN have different reserves (or
fees CAN be teleported), the remaining "non-fee" `assets` CANNOT, among
themselves, have different reserve locations (this is also implicitly
enforced by `MAX_ASSETS_FOR_TRANSFER=2`, but this can be safely
increased in the future).
- `fees` and "non-fee" `assets` CANNOT have **different remote**
reserves (this could also be supported in the future, but adds even more
complexity while possibly not being worth it - we'll see what the future
holds).

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

---------

Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Branislav Kontur <[email protected]>

We are introducing a new set of `XcmController` traits (final name yet
to be determined).
These traits are implemented by `pallet-xcm` and allows other pallets,
such as `pallet_contracts`, to rely on these traits instead of tight
coupling them to `pallet-xcm`.

Using only the existing Xcm traits would mean duplicating the logic from
`pallet-xcm` in these other pallets, which we aim to avoid. Our
objective is to ensure that when these APIs are called from
`pallet-contracts`, they produce the exact same outcomes as if called
directly from `pallet-xcm`.

The other benefits is that we can also expose return values to
`pallet-contracts` instead of just calling `pallet-xcm` dispatchable and
getting a `DispatchResult` back.

See traits integration in this PR
https://github.com/paritytech/polkadot-sdk/pull/1248, where the traits
are used as follow to define and implement `pallet-contracts` Config.
```rs
// Contracts config:
pub trait Config: frame_system::Config {
  // ...

  /// A type that exposes XCM APIs, allowing contracts to interact with other parachains, and
  /// execute XCM programs.
  type Xcm: xcm_executor::traits::Controller<
	  OriginFor<Self>,
	  <Self as frame_system::Config>::RuntimeCall,
	  BlockNumberFor<Self>,
  >;
}

// implementation
impl pallet_contracts::Config for Runtime {
        // ...

	type Xcm = pallet_xcm::Pallet<Self>;
}
```

---------

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

This PR changes the registration order of the `MessageQueue` pallet so
that it is registered last.

This is necessary so that the
[on_initialize](https://github.com/Snowfork/snowbridge/blob/df8d5da8/parachain/pallets/outbound-queue/src/lib.rs#L267)
hooks for Snowbridge can run before `MessageQueue` delivers messages
using its own `on_initialize`.

Generally, I think this is preferable regardless of Snowbridge's
particular requirements. Other pallets may want to do housekeeping
before MessageQueue starts delivering messages.

I'm hoping this PR, if accepted, can be included in the same release as
https://github.com/paritytech/polkadot-sdk/pull/1246. As otherwise,
changing the order of pallet registration is an ABI-breaking change.

`bridge-hub-westend-runtime` was added to cumulus/parachains, but wasn't
hooked up to xcm-emulator to run tests against it.

This commit addresses that ^.

Signed-off-by: Adrian Catangiu <[email protected]>

Otherwise the return code is not correctly propagated (ref
https://github.com/ggwpez/zepter/pull/48).

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>

This PR prepares chains specs for _native-runtime-free_  world.

This PR has following changes:
- `substrate`:
  - adds support for:
- JSON based `GenesisConfig` to `ChainSpec` allowing interaction with
runtime `GenesisBuilder` API.
- interacting with arbitrary runtime wasm blob to[
`chain-spec-builder`](https://github.com/paritytech/substrate/blob/3ef576eaeb3f42610e85daecc464961cf1295570/bin/utils/chain-spec-builder/src/lib.rs#L46)
command line util,
- removes
[`code`](https://github.com/paritytech/substrate/blob/3ef576eaeb3f42610e85daecc464961cf1295570/frame/system/src/lib.rs#L660)
from `system_pallet`
  - adds `code` to the `ChainSpec`
- deprecates
[`ChainSpec::from_genesis`](https://github.com/paritytech/substrate/blob/3ef576eaeb3f42610e85daecc464961cf1295570/client/chain-spec/src/chain_spec.rs#L263),
but also changes the signature of this method extending it with `code`
argument.
[`ChainSpec::builder()`](https://github.com/paritytech/substrate/blob/20bee680ed098be7239cf7a6b804cd4de267983e/client/chain-spec/src/chain_spec.rs#L507)
should be used instead.
- `polkadot`:
- all references to `RuntimeGenesisConfig` in `node/service` are
removed,
- all
`(kusama|polkadot|versi|rococo|wococo)_(staging|dev)_genesis_config`
functions now return the JSON patch for default runtime `GenesisConfig`,
  - `ChainSpecBuilder` is used, `ChainSpec::from_genesis` is removed,

- `cumulus`:
  - `ChainSpecBuilder` is used, `ChainSpec::from_genesis` is removed,
- _JSON_ patch configuration used instead of `RuntimeGenesisConfig
struct` in all chain specs.
  
---------

Co-authored-by: command-bot <>
Co-authored-by: Javier Viola <[email protected]>
Co-authored-by: Davide Galassi <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Kevin Krone <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>

Right now governance could only control byte-fee component of Rococo <>
Westend message fees (paid at Asset Hubs). This PR changes it a bit:
1) governance now allowed to control both fee components - byte fee and
base fee;
2) base fee now includes cost of "default" delivery and confirmation
transactions, in addition to `ExportMessage` instruction cost.

(imported from https://github.com/paritytech/cumulus/pull/2157)

## Changes

This MR refactores the XCMP, Parachains System and DMP pallets to use
the [MessageQueue](https://github.com/paritytech/substrate/pull/12485)
for delayed execution of incoming messages. The DMP pallet is entirely
replaced by the MQ and thereby removed. This allows for PoV-bounded
execution and resolves a number of issues that stem from the current
work-around.

All System Parachains adopt this change.  
The most important changes are in `primitives/core/src/lib.rs`,
`parachains/common/src/process_xcm_message.rs`,
`pallets/parachain-system/src/lib.rs`, `pallets/xcmp-queue/src/lib.rs`
and the runtime configs.

### DMP Queue Pallet

The pallet got removed and its logic refactored into parachain-system.
Overweight message management can be done directly through the MQ
pallet.

Final undeployment migrations are provided by
`cumulus_pallet_dmp_queue::UndeployDmpQueue` and `DeleteDmpQueue` that
can be configured with an aux config trait like:

```rust
parameter_types! {
	pub const DmpQueuePalletName: &'static str = \"DmpQueue\" < CHANGE ME;
	pub const RelayOrigin: AggregateMessageOrigin = AggregateMessageOrigin::Parent;
}

impl cumulus_pallet_dmp_queue::MigrationConfig for Runtime {
	type PalletName = DmpQueuePalletName;
	type DmpHandler = frame_support::traits::EnqueueWithOrigin<MessageQueue, RelayOrigin>;
	type DbWeight = <Runtime as frame_system::Config>::DbWeight;
}

// And adding them to your Migrations tuple:
pub type Migrations = (
	...
	cumulus_pallet_dmp_queue::UndeployDmpQueue<Runtime>,
	cumulus_pallet_dmp_queue::DeleteDmpQueue<Runtime>,
);
```

### XCMP Queue pallet

Removed all dispatch queue functionality. Incoming XCMP messages are now
either: Immediately handled if they are Signals, enqueued into the MQ
pallet otherwise.

New config items for the XCMP queue pallet:
```rust
/// The actual queue implementation that retains the messages for later processing.
type XcmpQueue: EnqueueMessage<ParaId>;

/// How a XCM over HRMP from a sibling parachain should be processed.
type XcmpProcessor: ProcessMessage<Origin = ParaId>;

/// The maximal number of suspended XCMP channels at the same time.
#[pallet::constant]
type MaxInboundSuspended: Get<u32>;
```

How to configure those:

```rust
// Use the MessageQueue pallet to store messages for later processing. The `TransformOrigin` is needed since
// the MQ pallet itself operators on `AggregateMessageOrigin` but we want to enqueue `ParaId`s.
type XcmpQueue = TransformOrigin<MessageQueue, AggregateMessageOrigin, ParaId, ParaIdToSibling>;

// Process XCMP messages from siblings. This is type-safe to only accept `ParaId`s. They will be dispatched
// with origin `Junction::Sibling(…)`.
type XcmpProcessor = ProcessFromSibling<
	ProcessXcmMessage<
		AggregateMessageOrigin,
		xcm_executor::XcmExecutor<xcm_config::XcmConfig>,
		RuntimeCall,
	>,
>;

// Not really important what to choose here. Just something larger than the maximal number of channels.
type MaxInboundSuspended = sp_core::ConstU32<1_000>;
```

The `InboundXcmpStatus` storage item was replaced by
`InboundXcmpSuspended` since it now only tracks inbound queue suspension
and no message indices anymore.

Now only sends the most recent channel `Signals`, as all prio ones are
out-dated anyway.

### Parachain System pallet

For `DMP` messages instead of forwarding them to the `DMP` pallet, it
now pushes them to the configured `DmpQueue`. The message processing
which was triggered in `set_validation_data` is now being done by the MQ
pallet `on_initialize`.

XCMP messages are still handed off to the `XcmpMessageHandler`
(XCMP-Queue pallet) - no change here.

New config items for the parachain system pallet:
```rust
/// Queues inbound downward messages for delayed processing. 
///
/// Analogous to the `XcmpQueue` of the XCMP queue pallet.
type DmpQueue: EnqueueMessage<AggregateMessageOrigin>;
``` 

How to configure:
```rust
/// Use the MQ pallet to store DMP messages for delayed processing.
type DmpQueue = MessageQueue;
``` 

## Message Flow

The flow of messages on the parachain side. Messages come in from the
left via the `Validation Data` and finally end up at the `Xcm Executor`
on the right.

![Untitled
(1)](https://github.com/paritytech/cumulus/assets/10380170/6cf8b377-88c9-4aed-96df-baace266e04d)

## Further changes

- Bumped the default suspension, drop and resume thresholds in
`QueueConfigData::default()`.
- `XcmpQueue::{suspend_xcm_execution, resume_xcm_execution}` errors when
they would be a noop.
- Properly validate the `QueueConfigData` before setting it.
- Marked weight files as auto-generated so they wont auto-expand in the
MR files view.
- Move the `hypothetical` asserts to `frame_support` under the name
`experimental_hypothetically`

Questions:
- [ ] What about the ugly `#[cfg(feature = \"runtime-benchmarks\")]` in
the runtimes? Not sure how to best fix. Just having them like this makes
tests fail that rely on the real message processor when the feature is
enabled.
- [ ] Need a good weight for `MessageQueueServiceWeight`. The scheduler
already takes 80% so I put it to 10% but that is quite low.

TODO:
- [x] Remove c&p code after
https://github.com/paritytech/polkadot/pull/6271
- [x] Use `HandleMessage` once it is public in Substrate
- [x] fix `runtime-benchmarks` feature
https://github.com/paritytech/polkadot/pull/6966
- [x] Benchmarks
- [x] Tests
- [ ] Migrate `InboundXcmpStatus` to `InboundXcmpSuspended`
- [x] Possibly cleanup Migrations (DMP+XCMP)
- [x] optional: create `TransformProcessMessageOrigin` in Substrate and
replace `ProcessFromSibling`
- [ ] Rerun weights on ref HW

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>
Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: Kian Paimani <[email protected]>
Co-authored-by: command-bot <>

## Summary

Asset bridging support for AssetHub**Rococo** <-> AssetHub**Wococo** was
added [here](https://github.com/paritytech/polkadot-sdk/pull/1215), so
now we aim to bridge AssetHub**Rococo** and AssetHub**Westend**. (And
perhaps retire AssetHubWococo and the Wococo chains).

## Solution

**bridge-hub-westend-runtime**
- added new runtime as a copy of `bridge-hub-rococo-runtime`
- added support for bridging to `BridgeHubRococo`
- added tests and benchmarks

**bridge-hub-rococo-runtime**
- added support for bridging to `BridgeHubWestend`
- added tests and benchmarks
- internal refactoring by splitting bridge configuration per network,
e.g., `bridge_to_whatevernetwork_config.rs`.

**asset-hub-rococo-runtime**
- added support for asset bridging to `AssetHubWestend` (allows to
receive only WNDs)
- added new xcm router for `Westend`
- added tests and benchmarks

**asset-hub-westend-runtime**
- added support for asset bridging to `AssetHubRococo` (allows to
receive only ROCs)
- added new xcm router for `Rococo`
- added tests and benchmarks

## Deployment

All changes will be deployed as a part of
https://github.com/paritytech/polkadot-sdk/issues/1988.

## TODO

- [x] benchmarks for all pallet instances
- [x] integration tests
- [x] local run scripts


Relates to:
https://github.com/paritytech/parity-bridges-common/issues/2602
Relates to: https://github.com/paritytech/polkadot-sdk/issues/1988

---------

Co-authored-by: command-bot <>
Co-authored-by: Adrian Catangiu <[email protected]>
Co-authored-by: joe petrowski <[email protected]>

Co-authored-by: Sergejs Kostjucenko <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>

Closes https://github.com/paritytech/release-engineering/issues/6

Adds a new Github Workflow which on a new release being created, builds
and attaches all runtimes managed in this repository in two flavours:
- `dev-debug-build`: Built with the `try-runtime` feature and has
logging enabled
- `on-chain-release`: Built with the regular old `on-chain-release`
feature

The new Github Workflow could be extended in the future by the
@paritytech/release-engineering team to fully automate the release
process if they choose to, similar to how it is fully automated in the
Fellowship repo
(https://github.com/polkadot-fellows/runtimes/blob/main/.github/workflows/release.yml).

The `on-chain-release` did not exist for parachains, so I added it. 

---

Tested on my fork: 
- https://github.com/liamaharon/polkadot-sdk/actions/runs/6663773523
- https://github.com/liamaharon/polkadot-sdk/releases/tag/test-6

---------

Co-authored-by: Chevdor <[email protected]>
Co-authored-by: Dónal Murray <[email protected]>

the min slot duration should be 0 only if the `experimental` feature is
enabled. otherwise, the runtime will panic on a division by 0.

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

# Description

- What does this PR do?

While working with `pallet_nfts` through `nonfungibles_v2` traits
`Inspect, Mutate`, I found out that once you have set the collection
attribute with `<Nfts as Mutate>::set_collection_attribute()`, it's not
possible to read it with `<Nfts as Inspect>::collection_attribute()`
since they use different `namespace` values. When setting the attribute,
`AttributeNamespace::Pallet` is used, while
`AttributeNamespace::CollectionOwner` is used when reading.

more context:
https://github.com/freeverseio/laos/issues/7#issuecomment-1766137370

This PR makes `item` an optional parameter in
`Inspect::system_attribute()`, to be able to read collection attributes.

- Why are these changes needed?

To be able to read collection level attributes when reading attributes
of the collection. It will be possible to read collection attributes by
passing `None` for `item`

- How were these changes implemented and what do they affect?

`NftsApi` is also affected and `NftsApi::system_attribute()` now accepts
optional `item` parameter.

## Breaking change

Because of the change in the `NftsApi::system_attribute()` method's
`item` param, parachains who integrated the `NftsApi` need to update
their API code and frontend integrations accordingly. AssetHubs are
unaffected since the NftsApi wasn't released on those parachains yet.

[testnet] Align testnet system parachain runtimes using `RelayTreasuryLocation` and `SystemParachains` in the same way (#2023)

This PR addresses several issues:
- simplify referencing `RelayTreasuryLocation` without needing
additional `RelayTreasury` struct
- fix for referencing `SystemParachains` from parachain with `parents:
1` instead of `parents: 0`
- removed hard-coded constants and fix tests for `asset-hub-rococo`
which was merged to master after
https://github.com/paritytech/polkadot-sdk/pull/1726

---------

Co-authored-by: command-bot <>

Adds a config file that allows to run `zepter` without any arguments in
the workspace to address all issues.
A secondary workflow for the CI is provided as `zepter run check`. Both
the formatting and linting are now in one check for efficiancy.

The latest version also detects some more things that `featalign` was
already showing.

Error message [in the
CI](https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/3916205)
now looks like this:
```pre
...
crate 'test-parachains' (/Users/vados/Documents/work/polkadot-sdk/polkadot/parachain/test-parachains/Cargo.toml)
  feature 'std'
    must propagate to:
      parity-scale-codec
Found 55 issues (run with --fix to fix).
Error: Command 'lint propagate-feature' failed with exit code 1

Polkadot-SDK uses the Zepter CLI to detect abnormalities in the feature configuration.
It looks like one more more checks failed; please check the console output. You can try to automatically address them by running `zepter`.
Otherwise please ask directly in the Merge Request, GitHub Discussions or on Matrix Chat, thank you.

For more information, see:
  - https://github.com/paritytech/polkadot-sdk/issues/1831
  - https://github.com/ggwpez/zepter
```

TODO:
- [x] Check that CI fails correctly

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>

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

## Breaking Changes

This PR introduces a new item to `pallet_balances::Config`:

```diff
trait Config {
++    type RuntimeFreezeReasons;
}
```

This value is only used to check it against `type MaxFreeze`. A similar
check has been added for `MaxHolds` against `RuntimeHoldReasons`, which
is already given to `pallet_balances`.

In all contexts, you should pass the real `RuntimeFreezeReasons`
generated by `construct_runtime` to `type RuntimeFreezeReasons`. Passing
`()` would also work, but it would imply that the runtime uses no
freezes at all.

---------

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

This PR does not introduce any functional changes to the existing code,
it merely addresses several minor refactors:
- Moving bridging pallets to separate files.
- Improving the readability and naming of weight files for bridging
pallets and bridging pallet instances.

The reason for this refactor is to facilitate easier plugin integration
for the upcoming bridge between Rococo and Westend.

---------

Co-authored-by: command-bot <>

## Problem

This PR addresses the issue with testnet AssetHub builds, which was
discovered during the execution of `bot bench`.

https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4038738
```
     Compiling asset-hub-rococo-runtime-wasm v1.0.0 (/builds/parity/mirrors/polkadot-sdk/target/production/wbuild/asset-hub-rococo-runtime)
  warning: Linking globals named 'Core_version': symbol multiply defined!
  error: failed to load bitcode of module "rococo_runtime-8799ee884447805a.rococo_runtime.0bc572b8-cgu.0.rcgu.o": 
  warning: `asset-hub-rococo-runtime-wasm` (lib) generated 1 warning
  error: could not compile `asset-hub-rococo-runtime-wasm` (lib) due to previous error; 1 warning emitted
```

https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4038739
```
Compiling asset-hub-westend-runtime-wasm v1.0.0 (/builds/parity/mirrors/polkadot-sdk/target/production/wbuild/asset-hub-westend-runtime)
  warning: Linking globals named 'Core_version': symbol multiply defined!
  error: failed to load bitcode of module "westend_runtime-86d7844430f97d5c.westend_runtime.b7678d03-cgu.0.rcgu.o": 
  warning: `asset-hub-westend-runtime-wasm` (lib) generated 1 warning
  error: could not compile `asset-hub-westend-runtime-wasm` (lib) due to previous error; 1 warning emitted
```

## Solution

- Removed dependencies on `rococo-runtime` and `westend-runtime`
introduced by [this
PR](https://github.com/paritytech/polkadot-sdk/pull/1234/files#diff-a86375df98e04ca3cce1ea35c40257a222e2d5087f5f528ff33307678b78dc2dR534-R550).
- Replaced `<rococo_runtime::Treasury as PalletInfoAccess>::index()`
with `rococo_runtime_constants::TREASURY_PALLET_ID`.
- Added `check_treasury_pallet_id` to the relay runtimes to ensure that
the constant is aligned with the pallet id.
- Added "Rococo Treasury" to the waived locations (that will not be
charged fees in the executor) for `BridgeHubRococo` (to be aligned with
AssetHubs).

## References

[Full element discussion
here](https://matrix.to/#/!JUeaZUiYbdrvzvtwSL:parity.io/$2PnjYMsWRjR7M3oOfGuRI0XkjdoqJLtRcAPVcDLuLVg?via=parity.io&via=web3.foundation).

---------

Co-authored-by: command-bot <>

The `xcm` crate was renamed to `staging-xcm` to be able to publish it to
crates.io as someone as squatted `xcm`. The problem with this rename is
that the `TypeInfo` includes the crate name which ultimately lands in
the metadata. The metadata is consumed by downstream users like
`polkadot-js` or people building on top of `polkadot-js`. These people
are using the entire `path` to find the type in the type registry. Thus,
their code would break as the type path would now be [`staging_xcm`,
`VersionedXcm`] instead of [`xcm`, `VersionedXcm`]. This pull request
fixes this by renaming the path segment `staging_xcm` to `xcm`.

This requires: https://github.com/paritytech/scale-info/pull/197

---------

Co-authored-by: Francisco Aguirre <[email protected]>

Combination of paritytech/polkadot#7005, its addon PR
paritytech/polkadot#7585 and its companion paritytech/cumulus#2433.

This PR introduces a new XcmFeesToAccount struct which implements the
`FeeManager` trait, and assigns this struct as the `FeeManager` in the
XCM config for all runtimes.

The struct simply deposits all fees handled by the XCM executor to a
specified account. In all runtimes, the specified account is configured
as the treasury account.

XCM __delivery__ fees are now being introduced (unless the root origin
is sending a message to a system parachain on behalf of the originating
chain).

# Note for reviewers

Most file changes are tests that had to be modified to account for the
new fees.
Main changes are in:
- cumulus/pallets/xcmp-queue/src/lib.rs <- To make it track the delivery
fees exponential factor
- polkadot/xcm/xcm-builder/src/fee_handling.rs <- Added. Has the
FeeManager implementation
- All runtime xcm_config files <- To add the FeeManager to the XCM
configuration

# Important note

After this change, instructions that create and send a new XCM (Query*,
Report*, ExportMessage, InitiateReserveWithdraw, InitiateTeleport,
DepositReserveAsset, TransferReserveAsset, LockAsset and RequestUnlock)
will require the corresponding origin account in the origin register to
pay for transport delivery fees, and the onward message will fail to be
sent if the origin account does not have the required amount. This
delivery fee is on top of what we already collect as tx fees in
pallet-xcm and XCM BuyExecution fees!

Wallet UIs that want to expose the new delivery fee can do so using the
formula:

```
delivery_fee_factor * (base_fee + encoded_msg_len * per_byte_fee)
```

where the delivery fee factor can be obtained from the corresponding
pallet based on which transport you are using (UMP, HRMP or bridges),
the base fee is a constant, the encoded message length from the message
itself and the per byte fee is the same as the configured per byte fee
for txs (i.e. `TransactionByteFee`).

---------

Co-authored-by: Branislav Kontur <[email protected]>
Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: Giles Cope <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>
Co-authored-by: Kian Paimani <[email protected]>

Adds descriptions needed for publishing to crates.io.

cumulus: add asset-hub-rococo runtime based on asset-hub-kusama and add asset-bridging support to it (#1215)

This commit adds Rococo Asset Hub dedicated runtime so we can test new
features here, before merging them in Kusama Asset Hub.
Also adds one such feature: asset transfer over bridge (Rococo AssetHub
<> Wococo AssetHub)

- clone `asset-hub-kusama-runtime` -> `asset-hub-rococo-runtime`
- make it use Rococo primitives, names, assets, constants, etc
- add asset-transfer-over-bridge support to Rococo AssetHub <> Wococo
AssetHub

Fixes #1128

---------

Co-authored-by: Branislav Kontur <[email protected]>
Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>

Remove `publish = false` to publish the crate

Slightly less verbose use of fungible(s).

---------

Co-authored-by: Liam Aharon <[email protected]>

## Summary

This PR introduces several enhancements.

The current implementation of `NetworkExportTable` lacks remote location
filtering support beyond `NetworkId` lookup. To provide more control and
granularity, it's essential to allow configuration for bridging to
different consensus `NetworkId` while restricting access e.g. to
particular remote parachains.

Additionally, the `StartsWith` and `Equals` and
`StartsWithExplicitGlobalConsensus` helper functions, which are in
active use, are moved to the `xcm-builder` and `frame_support` modules
for better code organization.

Adds a new `LocationWithAssetFilters` filter to enable location-based
and asset-related filtering. This filter is useful for configuring the
`pallet_xcm` filter for
[XcmTeleportFilter](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L212)
and
[XcmReserveTransferFilter](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L216)
to restrict specific assets.

Furthermore, the `BridgeMessage` fields are not accessible outside of
`xcm-builder`, limiting the ability to create custom logic dependent on
it.

---------

Co-authored-by: Francisco Aguirre <[email protected]>

Make System Parachain trusted Teleporters of each other.

Migration of https://github.com/paritytech/cumulus/pull/2842

---------

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

[xcm] Use `Weight::MAX` for `reserve_asset_deposited`, `receive_teleported_asset` benchmarks (#1726)

# Description

## Summary

Previously, the `pallet_xcm::do_reserve_transfer_assets` and
`pallet_xcm::do_teleport_assets` functions relied on weight estimation
for remote chain execution, which was based on guesswork derived from
the local chain. This approach led to complications for runtimes that
did not provide or support specific [XCM
configurations](https://github.com/paritytech/polkadot-sdk/blob/7cbe0c76/polkadot/xcm/xcm-executor/src/config.rs#L43-L47)
for `IsReserve` or `IsTeleporter`. Consequently, such runtimes had to
resort to implementing hard-coded weights for XCM instructions like
`reserve_asset_deposited` or `receive_teleported_asset` to support
extrinsics such as `pallet_xcm::reserve_transfer_assets` and
`pallet_xcm::teleport_assets`, which depended on remote weight
estimation.

The issue of remote weight estimation was addressed and resolved by
[Pull Request
#1645](https://github.com/paritytech/polkadot-sdk/pull/1645), which
removed the need for remote weight estimation.

## Solution

As a continuation of this improvement, the current PR proposes further
cleanup by removing unnecessary hard-coded values and rectifying
benchmark results with `Weight::MAX` that previously used
`T::BlockWeights::get().max_block` as an override for unsupported XCM
instructions like `ReserveAssetDeposited` and `ReceiveTeleportedAsset`.


## Questions

- [x] Can we remove now also `Hardcoded till the XCM pallet is fixed`
for `deposit_asset`? E.g. for AssetHubKusama
[here](https://github.com/paritytech/polkadot-sdk/blob/7cbe0c76/cumulus/parachains/runtimes/assets/asset-hub-kusama/src/weights/xcm/mod.rs#L129-L134)
- [x] Are comments like
[this](https://github.com/paritytech/polkadot-sdk/blob/7cbe0c76/polkadot/runtime/kusama/src/weights/xcm/mod.rs#L94)
`// Kusama doesn't support ReserveAssetDeposited, so this benchmark has
a default weight` still relevant? Shouldnt be removed/changed?


## TODO

- [x] `bench bot` regenerate xcm weights for all runtimes
- [x] remove hard-coded stuff from system parachain weight files
- [ ] when merged, open `polkadot-fellow/runtimes` PR

## References

Fixes #1132
Closes #1132
Old polkadot repo [PR](https://github.com/paritytech/polkadot/pull/7546)

---------

Co-authored-by: command-bot <>

### Summary 

This PR introduces new dispatchables to the treasury pallet, allowing
spends of various asset types. The enhanced features of the treasury
pallet, in conjunction with the asset-rate pallet, are set up and
enabled for Westend and Rococo.

### Westend and Rococo runtimes.

Polkadot/Kusams/Rococo Treasury can accept proposals for `spends` of
various asset kinds by specifying the asset's location and ID.

#### Treasury Instance New Dispatchables:
- `spend(AssetKind, AssetBalance, Beneficiary, Option<ValidFrom>)` -
propose and approve a spend;
- `payout(SpendIndex)` - payout an approved spend or retry a failed
payout
- `check_payment(SpendIndex)` - check the status of a payout;
- `void_spend(SpendIndex)` - void previously approved spend;
> existing spend dispatchable renamed to spend_local

in this context, the `AssetKind` parameter contains the asset's location
and it's corresponding `asset_id`, for example:
`USDT` on `AssetHub`,
``` rust
location = MultiLocation(0, X1(Parachain(1000)))
asset_id = MultiLocation(0, X2(PalletInstance(50), GeneralIndex(1984)))
```

the `Beneficiary` parameter is a `MultiLocation` in the context of the
asset's location, for example
``` rust
// the Fellowship salary pallet's location / account
FellowshipSalaryPallet = MultiLocation(1, X2(Parachain(1001), PalletInstance(64)))
// or custom `AccountId`
Alice = MultiLocation(0, AccountId32(network: None, id: [1,...]))
```

the `AssetBalance` represents the amount of the `AssetKind` to be
transferred to the `Beneficiary`. For permission checks, the asset
amount is converted to the native amount and compared against the
maximum spendable amount determined by the commanding spend origin.

the `spend` dispatchable allows for batching spends with different
`ValidFrom` arguments, enabling milestone-based spending. If the
expectations tied to an approved spend are not met, it is possible to
void the spend later using the `void_spend` dispatchable.

Asset Rate Pallet provides the conversion rate from the `AssetKind` to
the native balance.

#### Asset Rate Instance Dispatchables:
- `create(AssetKind, Rate)` - initialize a conversion rate to the native
balance for the given asset
- `update(AssetKind, Rate)` - update the conversion rate to the native
balance for the given asset
- `remove(AssetKind)` - remove an existing conversion rate to the native
balance for the given asset

the pallet's dispatchables can be executed by the Root or Treasurer
origins.

### Treasury Pallet

Treasury Pallet can accept proposals for `spends` of various asset kinds
and pay them out through the implementation of the `Pay` trait.

New Dispatchables:
- `spend(Config::AssetKind, AssetBalance, Config::Beneficiary,
Option<ValidFrom>)` - propose and approve a spend;
- `payout(SpendIndex)` - payout an approved spend or retry a failed
payout;
- `check_payment(SpendIndex)` - check the status of a payout;
- `void_spend(SpendIndex)` - void previously approved spend;
> existing spend dispatchable renamed to spend_local

The parameters' types of the `spend` dispatchable exposed via the
pallet's `Config` and allows to propose and accept a spend of a certain
amount.

An approved spend can be claimed via the `payout` within the
`Config::SpendPeriod`. Clients provide an implementation of the `Pay`
trait which can pay an asset of the `AssetKind` to the `Beneficiary` in
`AssetBalance` units.

The implementation of the Pay trait might not have an immediate final
payment status, for example if implemented over `XCM` and the actual
transfer happens on a remote chain.

The `check_status` dispatchable can be executed to update the spend's
payment state and retry the `payout` if the payment has failed.

---------

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

Applied changes from the [User Update
Guide](https://docs.google.com/document/d/1WQijD3bZTCsudOyPcDvugv659nCa2hEp2b_8eRU0h-Q),
diverging in the node side where service.rs is different for
`polkadot-parachain` than in the parachain template.

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

Makes SPs first class citizens along with the relay chains in the
context of our CI runtime upgrade checks.

## Code changes

- Sets missing current storage version in `uniques` pallet
- Adds multisig V1 migration to run where it was missing
- Removes executed migration whos pre/post hooks were failing from
collectives runtime
- Initializes storage versions for SP pallets added after genesis
- Originally I was going to wait for
https://github.com/paritytech/polkadot-sdk/pull/1297 to be merged so
this wouldn't need to be done manually, but it doesn't seem like it'll
be merged any time soon so I've decided to set them manually to unblock
this

## CI changes

- Removed dependency of `westend` runtime upgrades being complete prior
to other ones running. I assume it is supposed to cache the
`try-runtime` build for a performance benefit, but it seems it wasn't
working. Maybe someone from the CI team can look into this or explain
why it needs to be there?

- Adds check-runtime-migration jobs for Parity asset-hubs, bridge-hubs
and contract chains

- Updated VARIABLES to accomodate the `kusama-runtime` package being
renamed to `staging-kusama-runtime` in
https://github.com/paritytech/polkadot-sdk/pull/1241

- Added `EXTRA_ARGS` variable to `check-runtime-migration`, and set
`--no-weight-warnings` to the relay chain runtime upgrade checks (relay
chains don't have weight restrictions).

This pull request is removing the Kusama and Polkadot runtime crates. As
still some crates dependent on the runtime crates, this pull request is
doing some more changes.

- It removes the `hostperfcheck` CLI command. This CLI command could
compare the current node against the standard hardware by doing some
checks. Later we added the hardware benchmark feature to Substrate. This
hardware benchmark is running on every node startup and prints a warning
if the current node is too slow. This makes this CLI command a duplicate
that was also depending on the kusama runtime.

- The pull request is removing the emulated integration tests that were
requiring the Kusama or Polkadot runtime crates.

This PR implements [`GenesisBuilder`
API](https://github.com/paritytech/polkadot-sdk/blob/a414ea75

/substrate/primitives/genesis-builder/src/lib.rs#L38)
for all the runtimes in polkadot repo.

Step towards: paritytech/polkadot-sdk#25

---------

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

The Ambassador Program on Polkadot Collectives Parachain

The Polkadot Ambassador Program has existed for a while; more
information can be found
[here](https://wiki.polkadot.network/docs/ambassadors).
In this PR, the program is being brought on chain.

### On Chain Structure
The on-chain program consists of nine ranks, divided into four
categories ([full
list](https://github.com/paritytech/cumulus/blob/c238fb26b75569a11abb57437fd14acd26e05f18/parachains/runtimes/collectives/collectives-polkadot/src/ambassador/mod.rs#L52)):
- Ambassadors (1-2 tiers)
- Senior Ambassadors (3-4 tiers)
- Head Ambassadors (5-7 tiers)
- Master Ambassadors (8-9 tiers)

Each rank has a corresponding `Origin` (e.g., `HeadAmbassadorsTier5` -
[full
list](https://github.com/paritytech/cumulus/blob/c238fb26b75569a11abb57437fd14acd26e05f18/parachains/runtimes/collectives/collectives-polkadot/src/ambassador/origins.rs#L35)),
which represents the collective voice of members of that rank and above.

### Referendum

The `AmbassadorReferenda` instance of [referenda
pallet](https://docs.rs/pallet-referenda/latest/pallet_referenda/)
consists of [nine
tracks](https://github.com/paritytech/cumulus/blob/c238fb26b75569a11abb57437fd14acd26e05f18/parachains/runtimes/collectives/collectives-polkadot/src/ambassador/tracks.rs#L51),
each corresponding to an `Origin`. A referendum taken on `senior
ambassador tier 4` track invites all members from rank 4 or above to
vote and commands `SeniorAmbassadors` `Origin`. Every member gets one
vote plus an additional vote for every excess rank. The referendum
proposal can be submitted by any member of a senior rank or above.

### Membership Management

Initial members will be brought on chain via migration, with subsequent
member management handled through the `AmbassadorCollective` instance of
[ranked collective
pallet](https://docs.rs/pallet-ranked-collective/latest/pallet_ranked_collective/).
Both `Root` and `FellowshipAdmin` `Origins`, commanded via public
Polkadot referendum, can promote or demote members to and from any rank.
Members themselves also have the power to promote or demote via its
referendum, with a senior member vote by the rank two above the new /
current rank - [full
configuration](https://github.com/paritytech/cumulus/blob/9ab6aa47063d7e8b67ddc10d9c136037f99c03a3/parachains/runtimes/collectives/collectives-polkadot/src/ambassador/mod.rs#L67).

### Content Management

The program's on-chain content is managed via the collectives content
pallet, allowing for setting its charter and making announcements. The
voice of head ambassadors have the authority to set the charter, while
announcements can be made by any senior rank member or through a
referendum among all members.

### Additional Functionality

The `AmbassadorCore` instance of [core fellowship
pallet](https://docs.rs/pallet-core-fellowship/latest/pallet_core_fellowship/)
decorates the ranked collectives pallet with features like salary
determination, activity/passivity registration, and the handling of
promotion and demotion periods. While the usage of this pallet is
optional in the first version, future updates will make it the exclusive
method for induction/promotion.

Periodic salaries in USDt, payable on Asset Hub, are introduced through
the [salary
pallet](https://docs.rs/pallet-salary/latest/pallet_salary/). This
requires induction into the ambassador core pallet.

Please for more information on the pallets' functionality refer to their
documentations.

### Next Steps:
- Migrate to seed the program members
- Mint ambassador NFT badges on Asset Hub when promoting
- Treasury pallet instance for the Ambassador Program

---------

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

Partially fixes #103 

This PR removes instances of "free for all" collation in the `glutton`,
`shell`, and `seedling` runtimes and replaces them with Aura instances.
Aura is configured without a session manager, so the initial authority
set cannot be changed later on.

---------

Signed-off-by: georgepisaltu <[email protected]>

## Summary 
The term "common good parachain" has been abandoned in favor of "system
parachain" - e.g. [Joe's speech at
Decoded2023](https://youtu.be/CSO-ERHK2gY?t=456). This pull request
tries to fix and align code with this vision.

## Impact

The important change is implementation of `trait IsSystem` for `Id`
[here](https://github.com/paritytech/polkadot-sdk/pull/1406/files#diff-0b7b4f5b962a18ce980354592b55ab2a27b5a2e9f6f8089ec803ca73853e8583R225-R229)
where we changed condition from `< 1000` to `<= 1999`, which means that
all parachain IDs bellow 1999 (included) are considered as "system
parachain" IDs. This change has a direct impact on the following
components:

####
[ChildSystemParachainAsSuperuser](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/origin_conversion.rs#L72-L88)
This origin converter is used for allowing to process XCM `Transact`
from "system parachain" on the relay chain - e.g. see [configuration for
Kusama](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/runtime/kusama/src/xcm_config.rs#L92-L101).
Only configured for Kusama, Westend, Rococo runtimes.

**No need for this feature anymore.** See
[comment](https://github.com/paritytech/polkadot-sdk/pull/1406#issuecomment-1708218715).

####
[IsChildSystemParachain](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/barriers.rs#L310-L317)
`IsChildSystemParachain` is used with `AllowExplicitUnpaidExecutionFrom`
barrier for checking XCM programs (they have to start with
`UnpaidExecution` instruction).
Only configured for Kusama, Westend, Rococo runtimes.

**Overall the impact is low or mostly ok because it only allows unpaid
execution for "system parachains" (e.g. AssetHub, BridgeHub...) on the
relay chain.**

####
[SiblingSystemParachainAsSuperuser](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/origin_conversion.rs#L94-L114)

Not used anywhere in `polkadot-sdk` repo.


## Unresolved Questions
- [ ] constants `LOWEST_USER_ID` and `LOWEST_PUBLIC_ID` seem to express
the same thing now, do we want to keep them both or deprecated one of
them? If so, which one?
- [x] determine impact for `ChildSystemParachainAsSuperuser`

## TODO

- [ ] when merged here, open PR to the `polkadot-fellows`

## Related Material
https://youtu.be/CSO-ERHK2gY?t=456

https://forum.polkadot.network/t/polkadot-protocol-and-common-good-parachains/866
https://wiki.polkadot.network/docs/learn-system-chains