Skip to content
Snippets Groups Projects
  1. Oct 02, 2024
  2. Sep 30, 2024
  3. Sep 26, 2024
  4. Sep 25, 2024
    • Adrian Catangiu's avatar
      xcm-executor: validate destinations for ReserveWithdraw and Teleport transfers (#5660) · b5ac7a9d
      Adrian Catangiu authored
      
      This change adds the required validation for stronger UX guarantees when
      using `InitiateReserveWithdraw` or `InitiateTeleport` XCM instructions.
      Execution of the instructions will fail if the local chain is not
      configured to trust the "destination" or "reserve" chain as a
      reserve/trusted-teleporter for the provided "assets".
      
      With this change, misuse of `InitiateReserveWithdraw`/`InitiateTeleport`
      fails on origin with no overall side-effects, rather than failing on
      destination (with side-effects to origin's assets issuance).
      
      The commit also makes the same validations for pallet-xcm transfers, and
      adds regression tests.
      
      ---------
      
      Signed-off-by: default avatarAdrian Catangiu <adrian@parity.io>
      Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
      b5ac7a9d
    • Liam Aharon's avatar
      MBM `try-runtime` support (#4251) · cc6a5130
      Liam Aharon authored
      
      # MBM try-runtime support
      
      This MR adds support to the try-runtime trait such that the
      try-runtime-CLI will be able to support MBM testing
      [here](https://github.com/paritytech/try-runtime-cli/pull/90). It mainly
      adds two feature-gated hooks to the `SteppedMigration` hook to
      facilitate testing. These hooks are named `pre_upgrade` and
      `post_upgrade` and have the same signature and implications as for
      single-block migrations.
      
      ## Integration
      
      To make use of this in your Multi-Block-Migration, just implement the
      two new hooks and test pre- and post-conditions in them:
      
      ```rust
      #[cfg(feature = "try-runtime")]
      fn pre_upgrade() -> Result<Vec<u8>, frame_support::sp_runtime::TryRuntimeError> {
      	// ...
      }
      
      #[cfg(feature = "try-runtime")]
      fn post_upgrade(prev: Vec<u8>) -> Result<(), frame_support::sp_runtime::TryRuntimeError> {
          // ...
      }
      ```
      
      You may return an error or panic in these functions to indicate failure.
      This will then show up in the try-runtime-CLI and can be used in CI for
      testing.
      
      Changes:
      - Adds `try-runtime` gated methods `pre_upgrade` and `post_upgrade` on
      `SteppedMigration`
      - Adds `try-runtime` gated methods `nth_pre_upgrade` and
      `nth_post_upgrade` on `SteppedMigrations`
      - Modifies `pallet_migrations` implementation to run pre_upgrade and
      post_upgrade steps at the appropriate times, and panic in the event of
      migration failure.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Signed-off-by: default avatargeorgepisaltu <george.pisaltu@parity.io>
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarclaravanstaden <claravanstaden64@gmail.com>
      Co-authored-by: default avatarggwpez <ggwpez@users.noreply.github.com>
      Co-authored-by: default avatargeorgepisaltu <george.pisaltu@parity.io>
      cc6a5130
  5. Sep 24, 2024
    • Branislav Kontur's avatar
      Bridges lane id agnostic for backwards compatibility (#5649) · 710e74dd
      Branislav Kontur authored
      This PR primarily fixes the issue with
      `zombienet-bridges-0001-asset-transfer-works` (see:
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7404903).
      
      The PR looks large, but most of the changes involve splitting `LaneId`
      into `LegacyLaneId` and `HashedLaneId`. All pallets now use `LaneId` as
      a generic parameter.
      
      The actual bridging pallets are now backward compatible and work with
      actual **substrate-relay v1.6.10**, which does not even known anything
      about permissionless lanes or the new pallet changes.
      
      
      
      ## Important
      
      - [x] added migration for `pallet_bridge_relayers` and
      `RewardsAccountParams` change order of params, which generates different
      accounts
      
      ## Deployment follow ups
      - [ ] fix monitoring for
      `at_{}_relay_{}_reward_for_msgs_from_{}_on_lane_{}`
      - [ ] check sovereign reward accounts - because of changed
      `RewardsAccountParams`
      - [ ] deploy another messages instances for permissionless lanes - on
      BHs or AHs?
      - [ ] return bac...
      710e74dd
    • Adrian Catangiu's avatar
      snowbridge: improve destination fee handling to avoid trapping fees dust (#5563) · 62534e53
      Adrian Catangiu authored
      On messages Ethereum -> Polkadot Asset Hub: whether they are a token
      transfer or a `Transact` for registering new token, make sure to handle
      unspent fees, rather than trapping them.
      
      This PR deposits them to Snowbridge's sovereign account on Asset Hub.
      
      ---------
      
      Co-authored-by: command-bot <>
      62534e53
  6. Sep 23, 2024
    • Alin Dima's avatar
      elastic scaling: add core selector to cumulus (#5372) · b9eb68bc
      Alin Dima authored
      Partially implements
      https://github.com/paritytech/polkadot-sdk/issues/5048
      
      - adds a core selection runtime API to cumulus and a generic way of
      configuring it for a parachain
      - modifies the slot based collator to utilise the claim queue and the
      generic core selection
      
      What's left to be implemented (in a follow-up PR):
      - add the UMP signal for core selection into the parachain-system pallet
      
      View the RFC for more context:
      https://github.com/polkadot-fellows/RFCs/pull/103
      
      ---------
      
      Co-authored-by: command-bot <>
      b9eb68bc
  7. Sep 22, 2024
    • Branislav Kontur's avatar
      Moved presets to the testnet runtimes (#5327) · 8735c663
      Branislav Kontur authored
      
      It is a first step for switching to the `frame-omni-bencher` for CI.
      
      This PR includes several changes related to generating chain specs plus:
      
      - [x] pallet `assigned_slots` fix missing `#[serde(skip)]` for phantom
      - [x] pallet `paras_inherent` benchmark fix - cherry-picked from
      https://github.com/paritytech/polkadot-sdk/pull/5688
      - [x] migrates `get_preset` to the relevant runtimes
      - [x] fixes Rococo genesis presets - does not work
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7317249
      - [x] fixes Rococo benchmarks for CI 
      - [x] migrate westend genesis
      - [x] remove wococo stuff
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/5680
      
      ## Follow-ups
      - Fix for frame-omni-bencher
      https://github.com/paritytech/polkadot-sdk/pull/5655
      - Enable new short-benchmarking CI -
      https://github.com/paritytech/polkadot-sdk/pull/5706
      - Remove gitlab pipelines for short benchmarking
      - refactor all Cumulus runtimes to use `get_preset` -
      https://github.com/paritytech/polkadot-sdk/issues/5704
      - https://github.com/paritytech/polkadot-sdk/issues/5705
      - https://github.com/paritytech/polkadot-sdk/issues/5700
      - [ ] Backport to the stable
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarordian <noreply@reusable.software>
      8735c663
  8. Sep 20, 2024
  9. Sep 16, 2024
    • Przemek Rzad's avatar
      Ensure correct product name in license headers (#5702) · 9064fb4d
      Przemek Rzad authored
      - This will ensure that a correct product name
      (Polkadot/Cumulus/Substrate) is referenced in license headers.
      - Closes https://github.com/paritytech/license-scanner/issues/49
      9064fb4d
    • Muharem Ismailov's avatar
      Asset Hub: auto incremented asset id for trust backed assets (#5687) · 22bdc3e5
      Muharem Ismailov authored
      Setup auto incremented asset id to `50_000_000` for trust backed assets.
      
      In order to align with Polkadot/Kusama Asset Hub -
      https://github.com/polkadot-fellows/runtimes/pull/414
      The next closes existing assets IDs in Rococo is `69_696_969`, in
      Westend is `88_228_866`.
      
      ### Migration
      **Stakeholders**: all clients providing asset creation functionality on
      Westend/Rococo Asset Hub
      
      This change does not break the API but introduces a new constraint. It
      implements an auto-incremented ID strategy for Trust-Backed Assets (50
      pallet instance indexes on both networks), starting at ID 50,000,000.
      Each new asset must be created with an ID that is one greater than the
      last asset created. The next ID can be fetched from the `NextAssetId`
      storage item of the assets pallet. An empty `NextAssetId` storage item
      indicates no constraint on the next asset ID and can serve as a feature
      flag for this release.
      22bdc3e5
  10. Sep 13, 2024
    • Ron's avatar
      Transfer Polkadot-native assets to Ethereum (#5546) · fb7300ce
      Ron authored
      # Description
      
      Adding support for send polkadot native assets(PNA) to Ethereum network
      through snowbridge. Asset with location in view of AH Including:
      
      - Relay token `(1,Here)`
      - Native asset `(0,[PalletInstance(instance),GenereIndex(index)])`
      managed by Assets Pallet
      - Native asset of Parachain `(1,[Parachain(paraId)])` managed by Foreign
      Assets Pallet
      
      The original PR in https://github.com/Snowfork/polkadot-sdk/pull/128
      which has been internally reviewed by Snowbridge team.
      
      # Notes
      
      - This feature depends on the companion solidity change in
      https://github.com/Snowfork/snowbridge/pull/1155. Currently register PNA
      is only allowed from
      [sudo](https://github.com/Snowfork/polkadot-sdk/blob/46cb3528
      
      /bridges/snowbridge/pallets/system/src/lib.rs#L621),
      so it's actually not enabled. Will require another runtime upgrade to
      make the call permissionless together with upgrading the Gateway
      contract.
      
      - To make things easy multi-hop transfer(i.e. sending PNA from Ethereum
      through AH to Destination chain) is not support ed in this PR. For this
      case user can switch to 2-phases transfer instead.
      
      ---------
      
      Co-authored-by: default avatarClara van Staden <claravanstaden64@gmail.com>
      Co-authored-by: default avatarAlistair Singh <alistair.singh7@gmail.com>
      Co-authored-by: default avatarVincent Geddes <117534+vgeddes@users.noreply.github.com>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      fb7300ce
  11. Sep 12, 2024
  12. Sep 10, 2024
  13. Sep 04, 2024
    • Muharem Ismailov's avatar
      Collective: dynamic deposit based on number of proposals (#3151) · cc3b7bbd
      Muharem Ismailov authored
      Introduce a dynamic proposal deposit mechanism influenced by the total
      number of active proposals, with the option to set the deposit to none.
      
      The potential cost (e.g., balance hold) for proposal submission and
      storage is determined by the implementation of the `Consideration`
      trait. The footprint is defined as `proposal_count`, representing the
      total number of active proposals in the system, excluding the one
      currently being proposed. This cost may vary based on the proposal
      count. The pallet also offers various types to define a cost strategy
      based on the number of proposals.
      
      Two new calls are introduced:
      - kill(origin, proposal_hash): the cancellation of a proposal,
      accompanied by the burning of the associated cost/consideration ticket.
      - release_proposal_cost(origin, proposal_hash): the release of the cost
      for a non-active proposal.
      
      Additionally change: 
      - benchmarks have been upgraded to benchmarks::v2 for collective pallet;
      - `ensur...
      cc3b7bbd
  14. Sep 02, 2024
    • Clara van Staden's avatar
      Snowbridge free consensus updates (#5201) · c8015b2e
      Clara van Staden authored
      
      Allow free Snowbridge consensus updates, if the header interval is
      larger than the configured value (set to 32, so once a epoch).
      
      This PR also moves the Rococo Snowbridge pallet config into its own
      module.
      
      Original PR: https://github.com/Snowfork/polkadot-sdk/pull/159
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      c8015b2e
    • Branislav Kontur's avatar
      [bridges-v2] Permissionless lanes (#4949) · 22100999
      Branislav Kontur authored
      Relates to:
      https://github.com/paritytech/parity-bridges-common/issues/2451
      Closes: https://github.com/paritytech/parity-bridges-common/issues/2500
      
      ## Summary
      
      Now, the bridging pallet supports only static lanes, which means lanes
      that are hard-coded in the runtime files. This PR fixes that and adds
      support for dynamic, also known as permissionless, lanes. This means
      that allowed origins (relay chain, sibling parachains) can open and
      close bridges (through BridgeHubs) with another bridged (substrate-like)
      consensus using just `xcm::Transact` and `OriginKind::Xcm`.
      
      _This PR is based on the migrated code from the Bridges V2
      [branch](https://github.com/paritytech/polkadot-sdk/pull/4427) from the
      old `parity-bridges-common`
      [repo](https://github.com/paritytech/parity-bridges-common/tree/bridges-v2)._
      
      ## Explanation
      
      Please read
      [bridges/modules/xcm-bridge-hub/src/lib.rs](https://github.com/paritytech/polkadot-sdk/blob/149b0ac2
      
      /bridges/modules/xcm-bridge-hub/src/lib.rs#L17-L136)
      to understand how managing bridges works. The basic concepts around
      `BridgeId` and `LaneId` are also explained there.
      
      
      ## TODO
      
      - [x] search and fix for comment: `// TODO:(bridges-v2) - most of that
      stuff was introduced with free header execution:
      https://github.com/paritytech/polkadot-sdk/pull/4102` - more info in the
      comment
      [bellow](https://github.com/paritytech/polkadot-sdk/pull/4427#issuecomment-2126625043)
      - [x] TODO: there's only one impl of `EnsureOrigin<Success = Location>`
      
      ## TODO - not blocking review
      
      **benchmarking:**
      - [x] regenerate all relevant weights for BH/AH runtimes
      - [ ] regenerate default weights for bridging pallets e.g.
      `modules/messages/src/weights.rs`
      - [ ] add benchmarks for `xcm-bridge-hub` pallet
      https://github.com/paritytech/polkadot-sdk/issues/5550
      
      **testing:**
      - [ ] add xcm-emulator tests for Rococo/Penpal to Westend/Penpal with
      full opening channel and sending/receiving `xcm::Transact`
      
      **migrations:**
      - [x] add migrations for BridgeHubRococo/Westend
      https://github.com/paritytech/parity-bridges-common/issues/2794 (to be
      reusable for P/K bridge)
        - [x] check also storage migration, if needed for pallets
        - [ ] migration for XCM type (optional)
        - [x] migration for static lanes to the dynamic (reuse for fellows)
      
      **investigation:**
      - [ ] revisit
      https://github.com/paritytech/parity-bridges-common/issues/2380
      - [ ] check congestion around `LocalXcmChannelManager` and
      `OutboundLanesCongestedSignals` impls -
      https://github.com/paritytech/polkadot-sdk/issues/5551
        - to be reusable for polkadot-fellows
      - return `report_bridge_status` was remove, so we need to `XcmpQueue`
      alternative?
      
      ---------
      
      Signed-off-by: default avatarBranislav Kontur <bkontur@gmail.com>
      Co-authored-by: default avatarSvyatoslav Nikolsky <svyatonik@gmail.com>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      22100999
    • Francisco Aguirre's avatar
      Swaps for XCM delivery fees (#5131) · 5291412e
      Francisco Aguirre authored
      # Context
      
      Fees can already be paid in other assets locally thanks to the Trader
      implementations we have.
      This doesn't work when sending messages because delivery fees go through
      a different mechanism altogether.
      The idea is to fix this leveraging the `AssetExchanger` config item
      that's able to turn the asset the user wants to pay fees in into the
      asset the router expects for delivery fees.
      
      # Main addition
      
      An adapter was needed to use `pallet-asset-conversion` for exchanging
      assets in XCM.
      This was created in
      https://github.com/paritytech/polkadot-sdk/pull/5130.
      
      The XCM executor was modified to use `AssetExchanger` (when available)
      to swap assets to pay for delivery fees.
      
      ## Limitations
      
      We can only pay for delivery fees in different assets in intermediate
      hops. We can't pay in different assets locally. The first hop will
      always need the native token of the chain (or whatever is specified in
      the `XcmRouter`).
      This is a byproduct of using the `BuyExecution` instruction to know
      which asset should be used for delivery fee payment.
      Since this instruction is not present when executing an XCM locally, we
      are left with this limitation.
      To illustrate this limitation, I'll show two scenarios. All chains
      involved have pools.
      
      ### Scenario 1
      
      Parachain A --> Parachain B
      
      Here, parachain A can use any asset in a pool with its native asset to
      pay for local execution fees.
      However, as of now we can't use those for local delivery fees.
      This means transfers from A to B need some amount of A's native token to
      pay for delivery fees.
      
      ### Scenario 2
      
      Parachain A --> Parachain C --> Parachain B
      
      Here, Parachain C's remote delivery fees can be paid with any asset in a
      pool with its native asset.
      This allows a reserve asset transfer between A and B with C as the
      reserve to only need A's native token at the starting hop.
      After that, it could all be pool assets.
      
      ## Future work
      
      The fact that delivery fees go through a totally different mechanism
      results in a lot of bugs and pain points.
      Unfortunately, this is not so easy to solve in a backwards compatible
      manner.
      Delivery fees will be integrated into the language in future XCM
      versions, following
      https://github.com/polkadot-fellows/xcm-format/pull/53.
      
      Old PR: https://github.com/paritytech/polkadot-sdk/pull/4375.
      5291412e
  15. Aug 30, 2024
  16. Aug 28, 2024
    • A Ahmad's avatar
      IBP Coretime Polkadot bootnodes (#5499) · ef3a0d8f
      A Ahmad authored
      ✄
      -----------------------------------------------------------------------------
      
      Thank you for your Pull Request! :pray:
      
       Please make sure it follows the
      contribution guidelines outlined in [this
      
      document](https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md)
      and fill out the
      sections below. Once you're ready to submit your PR for review, please
      delete this section and leave only the text under
      the "Description" heading.
      
      # Description
      
      *A concise description of what your PR is doing, and what potential
      issue it is solving. Use [Github semantic
      
      linking](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
      to link the PR to an issue that must be closed once this is merged.*
      
      ## Integration
      
      *In depth notes about how this PR should be integrated by downstream
      projects. This part is mandatory, and should be
      reviewed by reviewers, if the PR does NOT have the `R0-Silent` label. In
      case of a `R0-Silent`, it can be ignored.*
      
      ## Review Notes
      
      *In depth notes about the **implementation** details of your PR. This
      should be the main guide for reviewers to
      understand your approach and effectively review it. If too long, use
      
      [`<details>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details)*.
      
      *Imagine that someone who is depending on the old code wants to
      integrate your new code and the only information that
      they get is this section. It helps to include example usage and default
      value here, with a `diff` code-block to show
      possibly integration.*
      
      *Include your leftover TODOs, if any, here.*
      
      # Checklist
      
      * [ ] My PR includes a detailed description as outlined in the
      "Description" and its two subsections above.
      * [ ] My PR follows the [labeling requirements](
      
      https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md#Process
      ) of this project (at minimum one label for `T` required)
      * External contributors: ask maintainers to put the right label on your
      PR.
      * [ ] I have made corresponding changes to the documentation (if
      applicable)
      * [ ] I have added tests that prove my fix is effective or that my
      feature works (if applicable)
      
      You can remove the "Checklist" section once all have been checked. Thank
      you for your contribution!
      
      ✄
      -----------------------------------------------------------------------------
      
      Co-authored-by: default avatarDónal Murray <donal.murray@parity.io>
      ef3a0d8f
  17. Aug 26, 2024
  18. Aug 23, 2024
    • Branislav Kontur's avatar
      [bridges] Prune messages from confirmation tx body, not from the on_idle (#5006) · e4ffba6e
      Branislav Kontur authored
      
      (Please, do not merge until SA, reverted and restored of
      https://github.com/paritytech/polkadot-sdk/pull/4944)
      
      Original PR with more context:
      https://github.com/paritytech/parity-bridges-common/pull/2211
      Relates to:
      https://github.com/paritytech/parity-bridges-common/issues/2210
      
      ## TODO
      
      - [x] fresh weighs for `pallet_bridge_messages`
      - [x] add `try_state` for `pallet_bridge_messages` which checks for
      unpruned messages - relates to the
      [comment](https://github.com/paritytech/parity-bridges-common/pull/2211#issuecomment-1643224831)
      - [x] ~prepare migration, that prunes leftovers, which would be pruned
      eventually from `on_idle` the
      [comment](https://github.com/paritytech/parity-bridges-common/pull/2211#issuecomment-1643224831)~
      can be done also by `set_storage` / `kill_storage` or with
      `OnRuntimeUpgrade` implementatino when `do_try_state_for_outbound_lanes`
      detects problem.
      
      ## Open question
      
      - [ ] Do we really need `oldest_unpruned_nonce` afterwards?
      - after the runtime upgrade and when `do_try_state_for_outbound_lanes`
      pass, we won't need any migrations here
          - we won't even need `do_try_state_for_outbound_lanes`
      - please check comments bellow:
      https://github.com/paritytech/polkadot-sdk/pull/4944#discussion_r1666737961
      
      ---------
      
      Signed-off-by: default avatarBranislav Kontur <bkontur@gmail.com>
      Co-authored-by: default avatarSerban Iorga <serban@parity.io>
      Co-authored-by: default avatarSvyatoslav Nikolsky <svyatonik@gmail.com>
      Co-authored-by: command-bot <>
      e4ffba6e
  19. Aug 22, 2024
    • Dónal Murray's avatar
      Add the Polkadot Coretime chain-spec (#5436) · dce789dd
      Dónal Murray authored
      Add the Polkadot Coretime chain-spec to the directory with the other
      system chain-specs.
      
      This is the chain-spec used at genesis and for which the genesis head
      data was generated.
      
      It is also included in the assets for fellowship [release
      v1.3.0](https://github.com/polkadot-fellows/runtimes/releases/tag/v1.3.0)
      dce789dd
  20. Aug 15, 2024
  21. Aug 14, 2024
    • Adrian Catangiu's avatar
      [tests] dedup test code, add more tests, improve naming and docs (#5338) · e4f8a6de
      Adrian Catangiu authored
      This is mostly tests cleanup:
      - uses helper macro for generating teleport tests,
      - adds missing treasury tests,
      - improves naming and docs for transfer tests.
      
      - [x] does not need a PRDOC
      
      ---------
      
      Co-authored-by: command-bot <>
      e4f8a6de
    • Francisco Aguirre's avatar
      Migrate foreign assets v3::Location to v4::Location (#4129) · be74fe92
      Francisco Aguirre authored
      
      In the move from XCMv3 to XCMv4, the `AssetId` for `ForeignAssets` in
      `asset-hub-rococo` and `asset-hub-westend` was left as `v3::Location` to
      be later migrated to `v4::Location`.
      
      This is that migration PR.
      
      Because the encoding of `v3::Location` and `v4::Location` is the same,
      we don't need to do any data migration, the keys will still be
      decodable.
      The [original idea by
      Jan](https://github.com/paritytech/polkadot/pull/7236) was to make the
      v4 changes in v3 since the ABI (the encoding/decoding) didn't change.
      Corroborated the ABI is the same iterating over all storage, the code is
      on [another
      branch](https://github.com/paritytech/polkadot-sdk/blob/cisco-assert-v3-v4-encodings-equal/cumulus/parachains/runtimes/assets/migrations/src/foreign_assets_to_v4/mod.rs).
      
      We will need a data migration when we want to update from `v4::Location`
      to `v5::Location` because of [the accepted RFC changing the NetworkId
      enum](https://github.com/polkadot-fellows/RFCs/pull/108).
      I'll configure MBMs (Multi-Block Migrations) then and make the actual
      migration.
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/4128
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: command-bot <>
      be74fe92
  22. Aug 12, 2024
  23. Aug 09, 2024
  24. Aug 07, 2024
  25. Aug 05, 2024
    • Sergej Sakac's avatar
      Coretime auto-renew (#4424) · f170af61
      Sergej Sakac authored
      
      This PR adds functionality that allows tasks to enable auto-renewal.
      Each task eligible for renewal can enable auto-renewal.
      
      A new storage value is added to track all the cores with auto-renewal
      enabled and the associated task running on the core. The `BoundedVec` is
      sorted by `CoreIndex` to make disabling auto-renewal more efficient.
      
      Cores are renewed at the start of a new bulk sale. If auto-renewal
      fails(e.g. due to the sovereign account of the task not holding
      sufficient balance), an event will be emitted, and the renewal will
      continue for the other cores.
      
      The two added extrinsics are:
      - `enable_auto_renew`: Extrinsic for enabling auto renewal.
      - `disable_auto_renew`: Extrinsic for disabling auto renewal.
      
      TODOs:
      - [x] Write benchmarks for the newly added extrinsics.
      
      Closes: #4351
      
      ---------
      
      Co-authored-by: default avatarDónal Murray <donalm@seadanda.dev>
      f170af61
  26. Jul 30, 2024
  27. Jul 29, 2024
  28. Jul 26, 2024
    • Kian Paimani's avatar
      Replace homepage in all TOML files (#5118) · d3d1542c
      Kian Paimani authored
      A bit of a controversial move, but a good preparation for even further
      reducing the traffic on outdated content of `substrate.io`. Current
      status:
      
      <img width="728" alt="Screenshot 2024-07-15 at 11 32 48"
      src="https://github.com/user-attachments/assets/df33b164-0ce7-4ac4-bc97-a64485f12571">
      
      Previously, I was in favor of changing the domain of the rust-docs to
      something like `polkadot-sdk.parity.io` or similar, but I think the
      current format is pretty standard and has a higher chance of staying put
      over the course of time:
      
      `<org-name>.github.io/<repo-name>` ->
      `https://paritytech.github.io/polkadot-sdk/`
      
      part of https://github.com/paritytech/eng-automation/issues/10
      d3d1542c
    • Sergej Sakac's avatar
      Fix region nonfungible implementation (#5067) · c39cc333
      Sergej Sakac authored
      
      The problem with the current implementation is that minting will cause
      the region coremask to be set to `Coremask::complete` regardless of the
      actual coremask.
      
      This PR fixes that.
      
      More details about the nonfungible implementation can be found here:
      https://github.com/paritytech/polkadot-sdk/pull/3455
      
      ---------
      
      Co-authored-by: default avatarDónal Murray <donalm@seadanda.dev>
      Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      c39cc333
    • Joseph Zhao's avatar
      Backport xcmpayment-fee tests from polkadot-fellows repo (#5100) · 7eb946c7
      Joseph Zhao authored
      # Description
      This is continue of the work to backport
      `emulated-integration-tests-common`, if you want to understand the full
      context start with reading
      [#4930](https://github.com/paritytech/polkadot-sdk/pull/4930)
      7eb946c7
  29. Jul 25, 2024
    • Dónal Murray's avatar
      Add people polkadot genesis chainspec (#5124) · d6f7f495
      Dónal Murray authored
      Published as part of the fellowship
      [v1.2.6](https://github.com/polkadot-fellows/runtimes/releases/tag/v1.2.6)
      release and originally intentionally left out of the repo as the
      hardcoded system chains will soon be removed from the
      `polkadot-parachain`.
      
      After a conversation in
      https://github.com/paritytech/polkadot-sdk/issues/5112 it was pointed
      out by @josepot that there should be a single authoritative source for
      these chainspecs. Since this is already the place for these it will
      serve until something more fitting can be worked out.
      d6f7f495