Skip to content
  1. Dec 21, 2023
  2. Dec 20, 2023
    • joe petrowski's avatar
      Fix Coretime Master (#2765) · d84e135b
      joe petrowski authored
      Should have merged master into #2682 before merging.
      d84e135b
    • Dónal Murray's avatar
      Fix clippy lints behind feature gates and add new CI step all features (#2569) · d68868f6
      Dónal Murray authored
      
      
      Many clippy lints usually enforced by `-Dcomplexity` and `-Dcorrectness`
      are not caught by CI as they are gated by `features`, like
      `runtime-benchmarks`, while the clippy CI job runs with only the default
      features for all targets.
      
      This PR also adds a CI step to run clippy with `--all-features` to
      ensure the code quality is maintained behind feature gates from now on.
      
      To improve local development, clippy lints are downgraded to warnings,
      but they still will result in an error at CI due to the `-Dwarnings`
      rustflag.
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      d68868f6
    • joe petrowski's avatar
      Add Authorize Upgrade Pattern to Frame System (#2682) · 280aa0b5
      joe petrowski authored
      Adds the `authorize_upgrade` -> `enact_authorized_upgrade` pattern to
      `frame-system`. This will be useful for upgrading bridged chains that
      are under the governance of Polkadot without passing entire runtime Wasm
      blobs over a bridge.
      
      Notes:
      
      - Changed `enact_authorized_upgrade` to `apply_authorized_upgrade`.
      Personal opinion, "apply" more accurately expresses what it's doing. Can
      change back if outvoted.
      - Remove `check_version` in favor of two extrinsics, so as to make
      _checked_ the default.
      - Left calls in `parachain-system` and marked as deprecated to prevent
      breaking the API. They just call into the `frame-system` functions.
      - Updated `frame-system` benchmarks to v2 syntax.
      
      ---------
      
      Co-authored-by: command-bot <>
      280aa0b5
    • Muharem Ismailov's avatar
      pallet-asset-conversion: Decoupling Native Currency Dependancy (#2031) · 4f832ea8
      Muharem Ismailov authored
      closes https://github.com/paritytech/polkadot-sdk/issues/1842
      
      Decoupling Pallet from the Concept of Native Currency
      
      Currently, the pallet is intrinsically linked with the concept of native
      currency, requiring users to provide implementations of the
      `fungible::*` and `fungibles::*` traits to interact with native and non
      native assets. This incapsulates some non-related to the pallet
      complexity and makes it less adaptable in contexts where the native
      currency concept is absent.
      
      With this PR, the dependence on `fungible::*` for liquidity-supplying
      assets has been removed. Instead, the native and non-native currencies'
      handling is now overseen by a single type that implements the
      `fungibles::*` traits. To simplify this integration, types have been
      introduced to facilitate the creation of a union between `fungible::*`
      and `fungibles::*` implementations, producing a unified `fungibles::*`
      type.
      
      One of the reasons driving these changes is the ambition to create a
      more user-friendly API for the `SwapCredit` implementation. Given that
      it interacts with two distinct credit types from `fungible` and
      `fungibles`, a unified type was introduced. Clients now manage potential
      conversion failures for those credit types. In certain contexts, it's
      vital to guarantee that operations are fail-safe, like in this impl -
      [PR](https://github.com/paritytech/polkadot-sdk/pull/1845), place in
      [code](https://github.com/paritytech/polkadot-sdk/blob/20b85a5f
      
      /cumulus/primitives/utility/src/lib.rs#L429).
      
      Additional Updates:
      - abstracted the pool ID and its account derivation logic via trait
      bounds, along with common implementation offerings;
      - removed `inc_providers` on a pool creation for the pool account;
      - benchmarks:
      -- swap complexity is N, not const;
      -- removed `From<u128> + Into<u128>` bound from `T::Balance`;
      -- removed swap/liquidity/.. amount constants, resolve them dynamically
      based on pallet configuration;
      -- migrated to v2 API;
      - `OnUnbalanced` handler for the pool creation fee, replacing direct
      transfers to a specified account ID;
      - renamed `MultiAssetId` to `AssetKind` aligning with naming across
      frame crates;
      
      related PRs:
      - (depends) https://github.com/paritytech/polkadot-sdk/pull/1677
      - (caused) https://github.com/paritytech/polkadot-sdk/pull/2033
      - (caused) https://github.com/paritytech/polkadot-sdk/pull/1876
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      4f832ea8
  3. Dec 19, 2023
    • Muharem Ismailov's avatar
      pallet-asset-conversion: Swap Credit (#1677) · 5ce04514
      Muharem Ismailov authored
      
      
      Introduces a swap implementation that allows the exchange of a credit
      (aka Negative Imbalance) of one asset for a credit of another asset.
      
      This is particularly useful when a credit swap is required but may not
      have sufficient value to meet the ED constraint, hence cannot be
      deposited to temp account before. An example use case is when XCM fees
      are paid using an asset held in the XCM executor registry and has to be
      swapped for native currency.
      
      Additional Updates:
      - encapsulates the existing `Swap` trait impl within a transactional
      context, since partial storage mutation is possible when an error
      occurs;
      - supplied `Currency` and `Assets` impls must be implemented over the
      same `Balance` type, the `AssetBalance` generic type is dropped. This
      helps to avoid numerous type conversion and overflow cases. If those
      types are different it should be handled outside of the pallet;
      - `Box` asset kind on a pallet level, unbox on a runtime level - here
      [why](https://substrate.stackexchange.com/questions/10039/boxed-argument-of-a-dispatchable/10103#10103);
      - `path` uses `Vec` now, instead of `BoundedVec` since it is never used
      in PoV;
      - removes the `Transfer` event due to it's redundancy with the events
      emitted by `fungible/s` implementations;
      - modifies the `SwapExecuted` event type;
      
      related issue: 
      - https://github.com/paritytech/polkadot-sdk/issues/105
      
      related PRs:
      - (required for) https://github.com/paritytech/polkadot-sdk/pull/1845
      - (caused) https://github.com/paritytech/polkadot-sdk/pull/1717
      
      // DONE make the pallet work only with `fungibles` trait and make it
      free from the concept of a `native` asset -
      https://github.com/paritytech/polkadot-sdk/issues/1842
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      5ce04514
    • joe petrowski's avatar
      Rococo/Westend Coretime Runtime · 2e70dd3b
      joe petrowski authored
      
      
      New runtimes for the Coretime Chain (a.k.a. "Broker Chain") described in
      RFC-1.
      
      Replaces https://github.com/paritytech/cumulus/pull/2889
      
      
      - [x] Add Agile Coretime pallet
      https://github.com/paritytech/substrate/pull/14568
      - [x] Generate chain specs for local and testnets
      - [x] Deploy parachain on Rococo - Done:
      [rococo-coretime-rpc.polkadot.io](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-coretime-rpc.polkadot.io#/explorer)
      
      DevOps issue for Aura keygen:
      https://github.com/paritytech/devops/issues/2725
      
      Edit (Dónal): This PR is mainly for Rococo, the Westend runtime is a
      shell with no `Broker` pallet. The Rococo runtime has the broker calls
      filtered for initial deployment.
      
      ---------
      
      Co-authored-by: default avatarDónal Murray <[email protected]>
      Co-authored-by: default avatar0xmovses <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarMarcin S. <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      2e70dd3b
    • Muharem Ismailov's avatar
      `UnionOf` types for merged `fungible` and `fungibles` implementations (#2033) · 0b74812c
      Muharem Ismailov authored
      Introduces `UnionOf` types, crafted to merge `fungible` and `fungibles`
      implementations or two `fungibles` implementations into a single type
      implementing `fungibles`.
      
      This also addresses an issue where `ItemOf` initiates a double drop for
      an imbalance type, leading to inaccurate total issuance accounting.
      
      Find the application of these types in this PR -
      [link](https://github.com/paritytech/polkadot-sdk/pull/2031), places in
      code -
      [1](https://github.com/paritytech/polkadot-sdk/blob/4ec7496f/cumulus/parachains/runtimes/assets/asset-hub-kusama/src/lib.rs#L327),
      [2](https://github.com/paritytech/polkadot-sdk/blob/4ec7496f
      
      /cumulus/parachains/runtimes/assets/asset-hub-kusama/src/lib.rs#L343).
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarjoepetrowski <[email protected]>
      0b74812c
  4. Dec 18, 2023
  5. Dec 15, 2023
  6. Dec 14, 2023
    • Svyatoslav Nikolsky's avatar
      Add Rococo People <> Rococo Bulletin bridge support to Rococo Bridge Hub (#2540) · 097308e3
      Svyatoslav Nikolsky authored
      This PR adds [Rococo
      People](https://github.com/paritytech/polkadot-sdk/pull/2281) <> [Rococo
      Bulletin](https://github.com/zdave-parity/polkadot-bulletin-chain) to
      the Rococo Bridge Hub code. There's a couple of things left to do here:
      - [x] add remaining tests - it'd need some refactoring in the
      `bridge-hub-test-utils` - will do in a separate PR;
      - [x] actually run benchmarks for new messaging pallet (do we have bot
      nowadays?).
      
      The reason why I'm opening it before this ^^^ is ready, is that I'd like
      to hear others opinion on how to deal with hacks with that bridge.
      Initially I was assuming that Rococo Bulletin will be the 1:1 copy of
      the Polkadot Bulletin (to avoid maintaining multiple
      runtimes/releases/...), so you can see many `PolkadotBulletin` mentions
      in this PR, even though we are going to bridge with the parallel chain
      (`RococoBulletin`). That's because e.g. pallet names from
      `construct_runtime` are affecting runtime storage keys and bridges are
      using runtime storage proofs => it is important to use names that the
      Bulletin chain expects.
      
      But in the end, this hack won't work - we can't use Polkadot Bulletin
      runtime to bridge with Rococo Bridge Hub, because Polkadot Bulletin
      expects Polkadot Bridge hub to use `1002` parachain id and Rococo Bridge
      Hub seats on the `1013`. This also affects storage keys using in
      bridging, so I had to add the [`rococo`
      feature](https://github.com/svyatonik/polkadot-bulletin-chain/blob/add-bridge-pallets/runtime/Cargo.toml#L198)
      to the Bulletin chain. So now we can actually alter its runtime and
      adapt it for Rococo.
      
      So the question here is - what's better for us here
      - to leave everything as is (seems hacky and non-trivial);
      - change Bulletin chain runtime when `rococo` feature is used - e.g. use
      proper names there (`WithPolkadotGrandpa` -> `WithRococoGrandpa`, ...)
      - add another set of pallets to the Bulletin chain runtime to bridge
      with Rococo and never use them in production. Similar to hack that we
      had in Rococo/Wococo
      
      cc @acatangiu @bkontur @serban300 
      
      also cc @joepetrowski
      
       as the main "client" of this bridge
      
      ---
      
      A couple words on how this bridge is different from the Rococo <>
      Westend bridge:
      - it is a bridge with a chain that uses GRANDPA finality, not the
      parachain finality (hence the tests needs to be changed);
      - it is a fee-free bridge. So
      `AllowExplicitUnpaidExecutionFrom<Equals<SiblingPeople>>` + we are not
      paying any rewards to relayers (apart from compensating transaction
      costs).
      
      ---------
      
      Signed-off-by: default avatardependabot[bot] <[email protected]>
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      Co-authored-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatarEgor_P <[email protected]>
      Co-authored-by: command-bot <>
      097308e3
    • Francisco Aguirre's avatar
      Add FungibleAdapter (#2684) · 10a91f82
      Francisco Aguirre authored
      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 <>
      10a91f82
    • Egor_P's avatar
      [Backport] txn version bump from 1.5.0 (#2709) · 3e4e8c0b
      Egor_P authored
      This PR backports `transaction_version` bump from `1.5.0` release back
      to `master`
      3e4e8c0b
  7. Dec 13, 2023
    • Squirrel's avatar
      Set clippy lints in workspace (requires rust 1.74) (#2390) · be8e6268
      Squirrel authored
      
      
      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: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      be8e6268
    • Branislav Kontur's avatar
      Updated benchmarks related to the Rococo/Westend bridge (#2639) · 4c4407a8
      Branislav Kontur authored
      Co-authored-by: command-bot <>
      4c4407a8
    • Svyatoslav Nikolsky's avatar
      Tests for BridgeHub(s) <> remote GRANDPA chain (#2692) · 9ecb2d33
      Svyatoslav Nikolsky authored
      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.
      9ecb2d33
    • Alexandru Gheorghe's avatar
      Approve multiple candidates with a single signature (#1191) · a84dd0db
      Alexandru Gheorghe authored
      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: default avatarAlexandru Gheorghe <[email protected]>
      a84dd0db
  8. Dec 12, 2023
    • Francisco Aguirre's avatar
      Fix ParentOrSiblings (#2428) · 313b2c4b
      Francisco Aguirre authored
      
      
      We were not filtering for sibling parachains, but for sibling anything
      
      ---------
      
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: command-bot <>
      313b2c4b
    • Branislav Kontur's avatar
      Ensure xcm versions over bridge (on sending chains) (#2481) · 575b8f8d
      Branislav Kontur authored
      ## 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 <>
      575b8f8d
    • Chevdor's avatar
      Changelogs local generation (#1411) · 42a3afba
      Chevdor authored
      
      
      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: default avatarEgorPopelyaev <[email protected]>
      42a3afba
  9. Dec 08, 2023
    • Muharem Ismailov's avatar
      Westend: Fellowship Treasury (#2532) · da40d97a
      Muharem Ismailov authored
      
      
      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: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarjoepetrowski <[email protected]>
      da40d97a
  10. Dec 07, 2023
    • Dónal Murray's avatar
      Remove `testnets-common` (#2620) · 814b938d
      Dónal Murray authored
      `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.
      814b938d
  11. Dec 06, 2023
    • Svyatoslav Nikolsky's avatar
      Added AllSiblingSystemParachains matcher to be used at a parachain level (#2422) · 0b3d0677
      Svyatoslav Nikolsky authored
      
      
      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: default avatarjoe petrowski <[email protected]>
      0b3d0677
    • Branislav Kontur's avatar
      Bridges subtree update (#2602) · be500fc2
      Branislav Kontur authored
      ## 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
      be500fc2
    • Adrian Catangiu's avatar
      pallet-xcm: add new flexible `transfer_assets()` call/extrinsic (#2388) · e7651cf4
      Adrian Catangiu authored
      # 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 <>
      e7651cf4
  12. Dec 05, 2023
  13. Dec 04, 2023
    • Serban Iorga's avatar
      Cleanup XCMP `QueueConfigData` (#2142) · 1266de39
      Serban Iorga authored
      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
      1266de39
  14. Dec 01, 2023
  15. Nov 30, 2023
    • dependabot[bot]'s avatar
      Bump the known_good_semver group with 2 updates (#2570) · 6742aba0
      dependabot[bot] authored
      
      
      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: default avatardependabot[bot] <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      6742aba0
  16. Nov 29, 2023
    • PG Herveou's avatar
      Contracts: use compiled rust tests (#2347) · 2135fa87
      PG Herveou authored
      
      
      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: default avatarAlexander Theißen <[email protected]>
      2135fa87
    • Tom Mi's avatar
      add Rotko common good parachain nodes (#2533) · 19f665f2
      Tom Mi authored
      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"
      )
      ```
      19f665f2
    • Dónal Murray's avatar
      Remove system parachains Polkadot and Kusama runtimes (#1737) · 63ac2471
      Dónal Murray authored
      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.
      63ac2471
    • Liam Aharon's avatar
      Remove `dmp_queue` pallet from Westend SP runtimes (#2516) · a9aa2d1f
      Liam Aharon authored
      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">
      a9aa2d1f
  17. Nov 28, 2023
  18. Nov 27, 2023
    • Adrian Catangiu's avatar
      4298bc60
    • Chevdor's avatar
      New runtime `spec_version` format + backport of the bump to 1.4.0 (#2468) · 4f8048b9
      Chevdor authored
      
      
      ## 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: default avatarBastian Köcher <[email protected]>
      4f8048b9
  19. Nov 24, 2023