Skip to content
Snippets Groups Projects
  1. Feb 26, 2025
    • clangenb's avatar
      add genesis presets for glutton westend (#7481) · cbc9b901
      clangenb authored
      
      Extracted from #7473.
      
      Part of: https://github.com/paritytech/polkadot-sdk/issues/5704.
      
      ---------
      
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
      cbc9b901
    • Branislav Kontur's avatar
      Authorize upgrade tests for testnet runtimes + `execute_as_governance` refactor (#7656) · e9be92d6
      Branislav Kontur authored
      
      Relates to: https://github.com/paritytech/polkadot-sdk/issues/7541 
      Relates to: https://github.com/paritytech/polkadot-sdk/issues/7566
      
      This PR contains improved test cases that rely on the governance
      location as preparation for AHM to capture the state as it is.
      It introduces `execute_as_governance_call`, which can be configured with
      various governance location setups instead of the hard-coded
      `Location::parent()`.
      
      Additionally, it adds a test for `authorize_upgrade` to all SP testnets.
      
      
      ## TODO
      - [x] rewrite all tests using
      `RuntimeHelper::<Runtime>::execute_as_governance` (because it is using
      hard-coded `Location::parent()`) to use
      `RuntimeHelper::<Runtime>::execute_as_governance_call`
      
      ## Follow-up
      - [ ] add similar test for westend-runtime
      - [ ] add test that ensure xcm-executor adds `ClearOrigin` before all
      side-effect sent to different chain
      
      ---------
      
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      e9be92d6
    • clangenb's avatar
      remove leftovers of the contracts-rococo parachain (#7638) · 51170495
      clangenb authored
      There were already previous efforts to remove the contracts-rococo
      chain, see #5471, which was done as a response to this comment
      https://github.com/paritytech/polkadot-sdk/pull/5288#discussion_r1711157476.
      
      This PR intends to fix the parts that were overlooked back then, and
      remove all traces of contracts-rococo as it is intended to be replaced
      by a new testnet including pallet-revive.
      51170495
  2. Feb 25, 2025
  3. Feb 24, 2025
    • Daniel Shiposha's avatar
      Fix DryRunApi client-facing XCM versions (#7438) · 963f0d73
      Daniel Shiposha authored
      
      # Description
      
      Fixes #7413
      
      ## Integration
      
      This PR updates the `DryRunApi`. The signature of the `dry_run_call` is
      changed, and the XCM version of the return values of `dry_run_xcm` now
      follows the version of the input XCM program.
      
      ## Review Notes
      
      * **The `DryRunApi` is modified**
      * **Added the `Router::clear_messages` to `dry_run_xcm` common
      implementation**
      * **Fixed the xcmp-queue's Router's clear_messages: channels details'
      first_index and last_index are reset when clearing**
      * **The MIN_XCM_VERSION is added**
      * The common implementation in the `pallet-xcm` is modified accordingly
      * The `DryRunApi` tests are modified to account for testing old XCM
      versions
      * The implementation from the `pallet-xcm` is used where it was not used
      (including the `DryRunApi` tests)
      * All the runtime implementations are modified according to the Runtime
      API change
      
      ---------
      
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      963f0d73
    • paritytech-cmd-bot-polkadot-sdk[bot]'s avatar
      Auto-update of all weights for 2025-02-21-1740149841 (#7668) · 16ed0296
      
      Auto-update of all weights for 2025-02-21-1740149841.
      
      Subweight results:
      - [now vs
      master](https://weights.tasty.limo/compare?repo=polkadot-sdk&threshold=5&path_pattern=.%2F**%2Fweights%2F**%2F*.rs%2C.%2F**%2Fweights.rs&method=asymptotic&ignore_errors=true&unit=time&old=master&new=update-weights-weekly-2025-02-21-1740149841)
      - [now vs polkadot-v1.15.6
      (2025-01-16)](https://weights.tasty.limo/compare?repo=polkadot-sdk&threshold=5&path_pattern=.%2F**%2Fweights%2F**%2F*.rs%2C.%2F**%2Fweights.rs&method=asymptotic&ignore_errors=true&unit=time&old=polkadot-v1.15.6&new=update-weights-weekly-2025-02-21-1740149841)
      - [now vs polkadot-v1.16.2
      (2024-11-14)](https://weights.tasty.limo/compare?repo=polkadot-sdk&threshold=5&path_pattern=.%2F**%2Fweights%2F**%2F*.rs%2C.%2F**%2Fweights.rs&method=asymptotic&ignore_errors=true&unit=time&old=polkadot-v1.16.2&new=update-weights-weekly-2025-02-21-1740149841)
      
      Co-authored-by: default avatargithub-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      16ed0296
  4. Feb 21, 2025
  5. Feb 20, 2025
    • PG Herveou's avatar
      [pallet-revive] tracing improvements (#7614) · 9e75647c
      PG Herveou authored
      
      Various pallet-revive improvements
      
      - add check for precompiles addresses,
      So we can easily identify which one are being called and not supported
      yet
      
      - fixes debug_call for revert call
      If a call revert we still want to get the traces for that call, that
      matches geth behaviors, diff tests will be added to the test suite for
      this
      
      - fixes traces for staticcall
      The call type was not always being reported properly.
      
      ---------
      
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarAlexander Theißen <alex.theissen@me.com>
      9e75647c
    • Alexander Theißen's avatar
      Update to Rust stable 1.84.1 (#7625) · e2d3da61
      Alexander Theißen authored
      Ref https://github.com/paritytech/ci_cd/issues/1107
      
      We mainly need that so that we can finally compile the `pallet_revive`
      fixtures on stable. I did my best to keep the commits focused on one
      thing to make review easier.
      
      All the changes are needed because rustc introduced more warnings or is
      more strict about existing ones. Most of the stuff could just be fixed
      and the commits should be pretty self explanatory. However, there are a
      few this that are notable:
      
      ## `non_local_definitions `
      
      A lot of runtimes to write `impl` blocks inside functions. This makes
      sense to reduce the amount of conditional compilation. I guess I could
      have moved them into a module instead. But I think allowing it here
      makes sense to avoid the code churn.
      
      ## `unexpected_cfgs`
      
      The FRAME macros emit code that references various features like `std`,
      `runtime-benchmarks` or `try-runtime`. If a create that uses those
      macros does not have those features we get this warning. Those were
      mostly when ...
      e2d3da61
    • Serban Iorga's avatar
      derive `DecodeWithMemTracking` for `RuntimeCall` (#7634) · e8d17cbe
      Serban Iorga authored
      Related to https://github.com/paritytech/polkadot-sdk/issues/7360
      e8d17cbe
  6. Feb 19, 2025
    • Dónal Murray's avatar
      Add sudo pallet to coretime-westend (#6960) · ececb4cb
      Dónal Murray authored
      
      Add the sudo pallet to coretime-westend, allowing use in
      development/testing. Previously the coretime-rococo runtime was used in
      situations like this, but since Rococo is now gone this can be used
      instead.
      
      No sudo key is added to Westend storage with this PR, since it's likely
      that any updates will continue to be done over XCM. If this is something
      that is wanted the key can be set via XCM.
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarMaksym H <1177472+mordamax@users.noreply.github.com>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      ececb4cb
    • Jonathan Brown's avatar
      [pallet-broker] add extrinsic to remove an assignment (#7080) · bd418487
      Jonathan Brown authored
      
      # Description
      
      #6929 requests more extrinsics for "managing the network's coretime
      allocations without needing to dabble with migration+runtime upgrade or
      set/kill storage patterns"
      
      This pull request implements the remove_assignment() extrinsic.
      
      
      ## Integration
      
      Downstream projects need to benchmark the weight for the
      remove_assignment() extrinsic.
      
      ---------
      
      Co-authored-by: default avatarJonathan Brown <jbrown@acuity.network>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarDónal Murray <donal.murray@parity.io>
      bd418487
    • Jonathan Brown's avatar
      [pallet-broker] add extrinsic to remove a lease (#7026) · 959d9187
      Jonathan Brown authored
      
      # Description
      
      #6929 requests more extrinsics for "managing the network's coretime
      allocations without needing to dabble with migration+runtime upgrade or
      set/kill storage patterns"
      
      This pull request implements the remove_lease() extrinsic.
      
      
      ## Integration
      
      Downstream projects need to benchmark the weight for the remove_lease()
      extrinsic.
      
      ## Review Notes
      
      Mentorship is requested to ensure this is implemented correctly.
      
      The lease is removed from state using the TaskId as a key. Is this
      sufficient. Does the extrinsic need to do anything else?
      
      ---------
      
      Co-authored-by: default avatarJonathan Brown <jbrown@acuity.network>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarDónal Murray <donalm@seadanda.dev>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarDónal Murray <donal.murray@parity.io>
      959d9187
    • Serban Iorga's avatar
      Derive `DecodeWithMemTracking` for cumulus pallets and for `polkadot-sdk` runtimes (#7627) · d60afc9f
      Serban Iorga authored
      Related to https://github.com/paritytech/polkadot-sdk/issues/7360
      
      Derive `DecodeWithMemTracking` for the structures in the cumulus pallets
      and for the structures in the `polkadot-sdk` runtimes.
      
      The PR contains no functional changes and no manual implementation. Just
      deriving `DecodeWithMemTracking`.
      d60afc9f
    • clangenb's avatar
      add genesis presets for coretime parachains (#7476) · e9b745a7
      clangenb authored
      
      Extracted from #7473.
      
      Part of: https://github.com/paritytech/polkadot-sdk/issues/5704.
      
      ---------
      
      Co-authored-by: default avatarGuillaume Thiolliere <guillaume.thiolliere@parity.io>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      e9b745a7
    • Branislav Kontur's avatar
      Make `pallet-bridge-rewards` generic over `RewardKind` (#7492) · ba7cb484
      Branislav Kontur authored
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/7272
      Relates to: https://github.com/paritytech/polkadot-sdk/pull/6578
      Relates to: https://github.com/paritytech/polkadot-sdk/issues/7274
      
      ## Description
      
      The PR enhances the `pallet-bridge-rewards` by making it generic over
      the `RewardKind` type (previously hardcoded as `RewardsAccountParams`).
      This modification allows the pallet to support multiple reward types
      (e.g., P/K bridge, Snowbridge), increasing its flexibility and
      applicability across various bridge scenarios.
      
      Other pallets can register rewards using `bp_relayers::RewardLedger`,
      which is implemented by the rewards pallet. The runtime can then be
      configured with different mechanisms for paying/claiming rewards via
      `bp_relayers::PaymentProcedure` (e.g., see the `pub struct
      BridgeRewardPayer;` implementation for BridgeHubWestend).
      
      ## Follow-up  
      The removed balances/rewards statistics from the complex relay (no
      longer used) will eventually be reintroduced or fixed in the standalone
      relayers via
      https://github.com/paritytech/parity-bridges-common/issues/3004#issuecomment-2401634589.
      
      ---------
      
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      Co-authored-by: default avatarSerban Iorga <serban@parity.io>
      ba7cb484
    • Branislav Kontur's avatar
      XCM: Deny barrier checks for nested XCMs with specific instructions to be... · bd7cf119
      Branislav Kontur authored
      XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain (#7200)
      
      Resolves (partially):
      https://github.com/paritytech/polkadot-sdk/issues/7148
      Depends on: https://github.com/paritytech/polkadot-sdk/pull/7169
      
      # Description
      
      This PR addresses partially #7148 (Problem 2) and ensures the proper
      checking of nested local instructions. It introduces a new barrier -
      `DenyRecursively` - to provide more refined control over instruction
      denial. The main change is the replacement of `DenyThenTry<Deny, Allow>`
      with `DenyThenTry<DenyRecursively<Deny>, Allow>` which handles both
      top-level and nested local instructions by applying allow condition
      after denial.
      
      For context and additional information, please refer to [_Problem 2 -
      Barrier vs nested XCM
      validation_](https://github.com/paritytech/polkadot-sdk/issues/7148).
      
      # TODO
      - [x] Evaluate PoC, more details at #7351:
          - **DenyNestedXcmInstructions**: Keep it as it is and be explicit:
              1. Name the Deny barriers for the top level.
      2. Name the Deny barrier for nested with `DenyInstructionsWithXcm`.
      - **DenyThenTry<DenyInstructionsWithXcm<Deny>, Allow>**: Alternatively,
      hard-code those three instructions in `DenyThenTry`, so we wouldn’t need
      `DenyInstructionsWithXcm`. However, this approach wouldn’t be as
      general.
      - **DenyInstructionsWithXcmFor**: Another possibility is to check
      `DenyInstructionsWithXcm::Inner` for the actual `message`, so we don’t
      need duplication for top-level and nested (not sure, maybe be explicit
      is good thing) - see _Problem2 - example_. Instead of this:
         ```
        DenyThenTry<
                      (
                                     // Deny for top level XCM program 
                                     DenyReserveTransferToRelayChain,
      // Dedicated barrier for nested XCM programs
                                     DenyInstructionsWithXcmFor<
      // Repeat all Deny filters here
      DenyReserveTransferToRelayChain,
                                      >
                      ),
         ```
        we could just use:
         ```
        DenyThenTry<
                      (
                                     // Dedicated barrier for XCM programs
                                     DenyInstructionsWithXcmFor<
      // Add all `Deny` filters here
      DenyReserveTransferToRelayChain,
                                                      ...
                                      >
                      ),
         ```
      - [POC
      Evaluation](https://github.com/paritytech/polkadot-sdk/pull/7200#discussion_r1939288792)
      - [x] Consider better name `DenyInstructionsWithXcm` =>
      `DenyRecursively`, more details at
      [here](https://github.com/paritytech/polkadot-sdk/pull/7200#discussion_r1958588973)
      - [x] Clean-up and docs
      - [x] Merge https://github.com/paritytech/polkadot-sdk/pull/7169 or
      rebase this branch on the top of `yrong:fix-for-deny-then-try`
      - [x] Set for the runtimes where we use `DenyThenTry<Deny, Allow>` =>
      `DenyThenTry<DenyRecursively<Deny>, Allow>`
      - [ ] Schedule sec.audit
      
      ---------
      
      Co-authored-by: default avatarRaymond Cheung <178801527+raymondkfcheung@users.noreply.github.com>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarron <yrong1997@gmail.com>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      Co-authored-by: default avatarClara van Staden <claravanstaden64@gmail.com>
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      bd7cf119
  7. Feb 18, 2025
  8. Feb 17, 2025
  9. Feb 14, 2025
    • Bastian Köcher's avatar
    • Oliver Tale-Yazdi's avatar
      [mq pallet] Custom next queue selectors (#6059) · 7aac8861
      Oliver Tale-Yazdi authored
      
      Changes:
      - Expose a `force_set_head` function from the `MessageQueue` pallet via
      a new trait: `ForceSetHead`. This can be used to force the MQ pallet to
      process this queue next.
      - The change only exposes an internal function through a trait, no audit
      is required.
      
      ## Context
      
      For the Asset Hub Migration (AHM) we need a mechanism to prioritize the
      inbound upward messages and the inbound downward messages on the AH. To
      achieve this, a minimal (and no breaking) change is done to the MQ
      pallet in the form of adding the `force_set_head` function.
      
      An example use of how to achieve prioritization is then demonstrated in
      `integration_test.rs::AhmPrioritizer`. Normally, all queues are
      scheduled round-robin like this:
      
      `| Relay | Para(1) | Para(2) | ... | Relay | ... `
      
      The prioritizer listens to changes to its queue and triggers if either:
      - The queue processed in the last block (to keep the general round-robin
      scheduling)
      - The queue did not process since `n` blocks (to prevent starvation if
      there are too many other queues)
      
      In either situation, it schedules the queue for a streak of three
      consecutive blocks, such that it would become:
      
      `| Relay | Relay | Relay | Para(1) | Para(2) | ... | Relay | Relay |
      Relay | ... `
      
      It basically transforms the round-robin into an elongated round robin.
      Although different strategies can be injected into the pallet at
      runtime, this one seems to strike a good balance between general service
      level and prioritization.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarmuharem <ismailov.m.h@gmail.com>
      7aac8861
  10. Feb 13, 2025
  11. Feb 12, 2025
  12. Feb 07, 2025
    • Przemek Rzad's avatar
      Ensure license headers match the Cargo manifest licenses (#5776) · 3726493d
      Przemek Rzad authored
      
      - Closes https://github.com/paritytech/license-scanner/issues/44
      - Silent because only comments are changed in the crates.
      
      ## What's inside
      
      First, we change the file traversal mechanism from shell globbing to
      walking through files which happens inside the `license-scanner` - so it
      has knowledge about directory structure and can correlate files with
      corresponding Cargo manifest.
      
      Next, added `MIT-0` and `Unlicense` to the allowed list of licenses.
      `Unlicense` appears only once across {Substrate,Cumulus,Polkadot} - in
      `penpal-runtime`.
      
      Finally, updated headers in files that do not match the corresponding
      manifest license.
      
      ---------
      
      Co-authored-by: Yuri Volkov's avatarcornholio <0@mcornholio.ru>
      3726493d
    • dharjeezy's avatar
      Update Pallet Referenda to support Block Number Provider (#6338) · f08bf1a1
      dharjeezy authored
      
      This PR introduces BlockNumberProvider config for the referenda pallet.
      closes part of https://github.com/paritytech/polkadot-sdk/issues/6297
      
      Polkadot address: 12GyGD3QhT4i2JJpNzvMf96sxxBLWymz4RdGCxRH5Rj5agKW
      
      ---------
      
      Co-authored-by: default avatarmuharem <ismailov.m.h@gmail.com>
      f08bf1a1
  13. Feb 06, 2025
    • PG Herveou's avatar
      [pallet-revive] tx fee fixes (#7463) · 917052e5
      PG Herveou authored
      
      Apply some fixes to properly estimate ethereum tx fees:
      
      - Set the `extension_weight` on the dispatch_info to properly calculate
      the fee with pallet_transaction_payment
      - Expose the gas_price through Runtime API, just in case we decide to
      tweak the value in future updates, it should be read from the chain
      rather than be a shared constant exposed by the crate
      - add a `evm_gas_to_fee` utility function to properly convert gas to
      substrate fee
      - Fix some minor gas encoding for edge cases
      
      ---------
      
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      917052e5
  14. Feb 05, 2025
  15. Feb 04, 2025
    • Alexander Theißen's avatar
      revive: Include immutable storage deposit into the contracts `storage_base_deposit` (#7230) · 4c28354b
      Alexander Theißen authored
      
      This PR is centered around a main fix regarding the base deposit and a
      bunch of drive by or related fixtures that make sense to resolve in one
      go. It could be broken down more but I am constantly rebasing this PR
      and would appreciate getting those fixes in as-one.
      
      **This adds a multi block migration to Westend AssetHub that wipes the
      pallet state clean. This is necessary because of the changes to the
      `ContractInfo` storage item. It will not delete the child storage
      though. This will leave a tiny bit of garbage behind but won't cause any
      problems. They will just be orphaned.**
      
      ## Record the deposit for immutable data into the `storage_base_deposit`
      
      The `storage_base_deposit` are all the deposit a contract has to pay for
      existing. It included the deposit for its own metadata and a deposit
      proportional (< 1.0x) to the size of its code. However, the immutable
      code size was not recorded there. This would lead to the situation where
      on terminate this portion wouldn't be refunded staying locked into the
      contract. It would also make the calculation of the deposit changes on
      `set_code_hash` more complicated when it updates the immutable data (to
      be done in #6985). Reason is because it didn't know how much was payed
      before since the storage prices could have changed in the mean time.
      
      In order for this solution to work I needed to delay the deposit
      calculation for a new contract for after the contract is done executing
      is constructor as only then we know the immutable data size. Before, we
      just charged this eagerly in `charge_instantiate` before we execute the
      constructor. Now, we merely send the ED as free balance before the
      constructor in order to create the account. After the constructor is
      done we calculate the contract base deposit and charge it. This will
      make `set_code_hash` much easier to implement.
      
      As a side effect it is now legal to call `set_immutable_data` multiple
      times per constructor (even though I see no reason to do so). It simply
      overrides the immutable data with the new value. The deposit accounting
      will be done after the constructor returns (as mentioned above) instead
      of when setting the immutable data.
      
      ## Don't pre-charge for reading immutable data
      
      I noticed that we were pre-charging weight for the max allowable
      immutable data when reading those values and then refunding after read.
      This is not necessary as we know its length without reading the storage
      as we store it out of band in contract metadata. This makes reading it
      free. Less pre-charging less problems.
      
      ## Remove delegate locking
      
      Fixes #7092
      
      This is also in the spirit of making #6985 easier to implement. The
      locking complicates `set_code_hash` as we might need to block settings
      the code hash when locks exist. Check #7092 for further rationale.
      
      ## Enforce "no terminate in constructor" eagerly
      
      We used to enforce this rule after the contract execution returned. Now
      we error out early in the host call. This makes it easier to be sure to
      argue that a contract info still exists (wasn't terminated) when a
      constructor successfully returns. All around this his just much simpler
      than dealing this check.
      
      ## Moved refcount functions to `CodeInfo`
      
      They never really made sense to exist on `Stack`. But now with the
      locking gone this makes even less sense. The refcount is stored inside
      `CodeInfo` to lets just move them there.
      
      ## Set `CodeHashLockupDepositPercent` for test runtime
      
      The test runtime was setting `CodeHashLockupDepositPercent` to zero.
      This was trivializing many code paths and excluded them from testing. I
      set it to `30%` which is our default value and fixed up all the tests
      that broke. This should give us confidence that the lockup doeposit
      collections properly works.
      
      ## Reworked the `MockExecutable` to have both a `deploy` and a `call`
      entry point
      
      This type used for testing could only have either entry points but not
      both. In order to fix the `immutable_data_set_overrides` I needed to a
      new function `add_both` to `MockExecutable` that allows to have both
      entry points. Make sure to make use of it in the future :)
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarPG Herveou <pgherveou@gmail.com>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      4c28354b
  16. Jan 29, 2025
  17. Jan 27, 2025
    • Ron's avatar
      xcm: fix for DenyThenTry Barrier (#7169) · b30aa319
      Ron authored
      
      Resolves (partially):
      https://github.com/paritytech/polkadot-sdk/issues/7148 (see _Problem 1 -
      `ShouldExecute` tuple implementation and `Deny` filter tuple_)
      
      This PR changes the behavior of `DenyThenTry` from the pattern
      `DenyIfAllMatch` to `DenyIfAnyMatch` for the tuple.
      
      I would expect the latter is the right behavior so make the fix in
      place, but we can also add a dedicated Impl with the legacy one
      untouched.
      
      ## TODO
      - [x] add unit-test for `DenyReserveTransferToRelayChain`
      - [x] add test and investigate/check `DenyThenTry` as discussed
      [here](https://github.com/paritytech/polkadot-sdk/pull/6838#discussion_r1914553990)
      and update documentation if needed
      
      ---------
      
      Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarClara van Staden <claravanstaden64@gmail.com>
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      b30aa319
  18. Jan 26, 2025
  19. Jan 24, 2025