Skip to content
Snippets Groups Projects
  1. Jan 16, 2025
    • chloefeal's avatar
      chore: fix typos (#6999) · e056586b
      chloefeal authored
      ✄
      -----------------------------------------------------------------------------
      
      Thank you for your Pull Request! 🙏 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
      
      Hello, I fix some typos in logs and comments. Thank you very much.
      
      
      ## 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 re...
  2. Jan 07, 2025
  3. Jan 06, 2025
  4. Dec 20, 2024
    • Xavier Lau's avatar
      Reorder dependencies' keys (#6967) · a843d15e
      Xavier Lau authored
      
      It doesn't make sense to only reorder the features array.
      
      For example:
      
      This makes it hard for me to compare the dependencies and features,
      especially some crates have a really really long dependencies list.
      ```toml​
      [dependencies]
      c = "*"
      a = "*"
      b = "*"
      
      [features]
      std = [
        "a",
        "b",
        "c",
      ]
      ```
      
      This makes my life easier.
      ```toml​
      [dependencies]
      a = "*"
      b = "*"
      c = "*"
      
      [features]
      std = [
        "a",
        "b",
        "c",
      ]
      ```
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Co-authored-by: command-bot <>
  5. Dec 12, 2024
  6. Dec 11, 2024
    • Alexander Theißen's avatar
      snowbridge: Update alloy-core (#6808) · da2dd9b7
      Alexander Theißen authored
      I am planning to use `alloy_core` to implement precompile support in
      `pallet_revive`. I noticed that it is already used by snowbridge. In
      order to unify the dependencies I did the following:
      
      1. Switch to the `alloy-core` umbrella crate so that we have less
      individual dependencies to update.
      2. Bump the latest version and fixup the resulting compile errors.
  7. Dec 10, 2024
    • Ron's avatar
      XCMv5: Fix for compatibility with V4 (#6503) · fe4846f5
      Ron authored
      ## Description
      
      Our smoke tests transfer `WETH` from Sepolia to Westend-AssetHub breaks,
      try to reregister `WETH` on AH but fails as following:
      
      
      https://bridgehub-westend.subscan.io/xcm_message/westend-4796d6b3600aca32ef63b9953acf6a456cfd2fbe
      
      https://assethub-westend.subscan.io/extrinsic/9731267-0?event=9731267-2
      
      The reason is that the transact call encoded on BH to register the asset
      
      https://github.com/paritytech/polkadot-sdk/blob/a77940ba
      
      /bridges/snowbridge/primitives/router/src/inbound/mod.rs#L282-L289
      ```
      0x3500020209079edaa8020300fff9976782d46cc05630d1f6ebab18b2324d6b1400ce796ae65569a670d0c1cc1ac12515a3ce21b5fbf729d63d7b289baad070139d01000000000000000000000000000000
      ```
      
      the `asset_id` which is the xcm location can't be decoded on AH in V5
      
      Issue initial post in
      https://matrix.to/#/!qUtSTcfMJzBdPmpFKa:parity.io/$RNMAxIIOKGtBAqkgwiFuQf4eNaYpmOK-Pfw4d6vv1aU?via=parity.io&via=matrix.org&via=web3.foundation
      
      ---------
      
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
    • Joseph Zhao's avatar
      Remove AccountKeyring everywhere (#5899) · 311ea438
      Joseph Zhao authored
      
      Close: #5858
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
    • Branislav Kontur's avatar
      Bridges - revert-back congestion mechanism (#6781) · 8f4b99cf
      Branislav Kontur authored
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/5551
      
      ## Description
      
      With [permissionless lanes
      PR#4949](https://github.com/paritytech/polkadot-sdk/pull/4949), the
      congestion mechanism based on sending
      `Transact(report_bridge_status(is_congested))` from
      `pallet-xcm-bridge-hub` to `pallet-xcm-bridge-hub-router` was replaced
      with a congestion mechanism that relied on monitoring XCMP queues.
      However, this approach could cause issues, such as suspending the entire
      XCMP queue instead of isolating the affected bridge. This PR reverts
      back to using `report_bridge_status` as before.
      
      ## TODO
      - [x] benchmarks
      - [x] prdoc
      
      ## Follow-up
      
      https://github.com/paritytech/polkadot-sdk/pull/6231
      
      ---------
      
      Co-authored-by: default avatarGitHub Action <action@github.com>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
    • Francisco Aguirre's avatar
      Add fallback_max_weight to snowbridge Transact (#6792) · 4fc92486
      Francisco Aguirre authored
      
      We removed the `require_weight_at_most` field and later changed it to
      `fallback_max_weight`.
      This was to have a fallback when sending a message to v4 chains, which
      happens in the small time window when chains are upgrading.
      We originally put no fallback for a message in snowbridge's inbound
      queue but we should have one.
      This PR adds it.
      
      ---------
      
      Co-authored-by: default avatarGitHub Action <action@github.com>
  8. Dec 09, 2024
    • Adrian Catangiu's avatar
      xcm-executor: take transport fee from transferred assets if necessary (#4834) · e79fd2bb
      Adrian Catangiu authored
      
      # Description
      
      Sending XCM messages to other chains requires paying a "transport fee".
      This can be paid either:
      - from `origin` local account if `jit_withdraw = true`,
      - taken from Holding register otherwise.
      
      This currently works for following hops/scenarios:
      1. On destination no transport fee needed (only sending costs, not
      receiving),
      2. Local/originating chain: just set JIT=true and fee will be paid from
      signed account,
      3. Intermediary hops - only if intermediary is acting as reserve between
      two untrusted chains (aka only for `DepositReserveAsset` instruction) -
      this was fixed in https://github.com/paritytech/polkadot-sdk/pull/3142
      
      But now we're seeing more complex asset transfers that are mixing
      reserve transfers with teleports depending on the involved chains.
      
      # Example
      
      E.g. transferring DOT between Relay and parachain, but through AH (using
      AH instead of the Relay chain as parachain's DOT reserve).
      
      In the `Parachain --1--> AssetHub --2--> Relay` scenario, DOT has to be
      reserve-withdrawn in leg `1`, then teleported in leg `2`.
      On the intermediary hop (AssetHub), `InitiateTeleport` fails to send
      onward message because of missing transport fees. We also can't rely on
      `jit_withdraw` because the original origin is lost on the way, and even
      if it weren't we can't rely on the user having funded accounts on each
      hop along the way.
      
      # Solution/Changes
      
      - Charge the transport fee in the executor from the transferred assets
      (if available),
      - Only charge from transferred assets if JIT_WITHDRAW was not set,
      - Only charge from transferred assets if unless using XCMv5 `PayFees`
      where we do not have this problem.
      
      # Testing
      
      Added regression tests in emulated transfers.
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/4832
      Fixes https://github.com/paritytech/polkadot-sdk/issues/6637
      
      ---------
      
      Signed-off-by: default avatarAdrian Catangiu <adrian@parity.io>
      Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
  9. Dec 08, 2024
  10. Dec 05, 2024
    • Francisco Aguirre's avatar
      Added fallback_max_weight to Transact for sending messages to V4 chains (#6643) · f31c70aa
      Francisco Aguirre authored
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/6585
      
      Removing the `require_weight_at_most` parameter in V5 Transact had only
      one problem. Converting a message from V5 to V4 to send to chains that
      didn't upgrade yet. The conversion would not know what weight to give to
      the Transact, since V4 and below require it.
      
      To fix this, I added back the weight in the form of an `Option<Weight>`
      called `fallback_max_weight`. This can be set to `None` if you don't
      intend to deal with a chain that hasn't upgraded yet. If you set it to
      `Some(_)`, the behaviour is the same. The plan is to totally remove this
      in V6 since there will be a good conversion path from V6 to V5.
      
      ---------
      
      Co-authored-by: default avatarGitHub Action <action@github.com>
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
  11. Dec 03, 2024
  12. Nov 28, 2024
  13. Nov 20, 2024
    • Branislav Kontur's avatar
      Bridges testing improvements (#6536) · bd0d0cde
      Branislav Kontur authored
      
      This PR includes:  
      - Refactored integrity tests to support standalone deployment of
      `pallet-bridge-messages`.
      - Refactored the `open_and_close_bridge_works` test case to support
      multiple scenarios, such as:
        1. A local chain opening a bridge.  
        2. Sibling parachains opening a bridge.  
        3. The relay chain opening a bridge.  
      - Previously, we added instance support for `pallet-bridge-relayer` but
      overlooked updating the `DeliveryConfirmationPaymentsAdapter`.
      
      ---------
      
      Co-authored-by: default avatarGitHub Action <action@github.com>
  14. Nov 14, 2024
    • georgepisaltu's avatar
      Follow up work on `TransactionExtension` - fix weights and clean up `UncheckedExtrinsic` (#6418) · ae4b68b3
      georgepisaltu authored
      
      Follow up to https://github.com/paritytech/polkadot-sdk/pull/3685
      Partially fixes https://github.com/paritytech/polkadot-sdk/issues/6403
      
      The main PR introduced bare support for the new extension version byte
      as well as extension weights and benchmarking.
      
      This PR:
      - Removes the redundant extension version byte from the signed v4
      extrinsic, previously unused and defaulted to 0.
      - Adds the extension version byte to the inherited implication passed to
      `General` transactions.
      - Whitelists the `pallet_authorship::Author`, `frame_system::Digest` and
      `pallet_transaction_payment::NextFeeMultiplier` storage items as they
      are read multiple times by extensions for each transaction, but are hot
      in memory and currently overestimate the weight.
      - Whitelists the benchmark caller for `CheckEra` and `CheckGenesis` as
      the reads are performed for every transaction and overestimate the
      weight.
      - Updates the umbrella frame weight template to work with the system
      extension changes.
      - Plans on re-running the benchmarks at least for the `frame_system`
      extensions.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <george.pisaltu@parity.io>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatargui <gui.thiolliere@gmail.com>
  15. Nov 13, 2024
    • Branislav Kontur's avatar
      Fixed bridges zombienet tests because of removed NetworkId::Rococo/Westend from xcm::v5 (#6465) · bff395f8
      Branislav Kontur authored
      Closes: https://github.com/paritytech/polkadot-sdk/issues/6449
    • thiolliere's avatar
      [Tx ext stage 2: 1/4] Add `TransactionSource` as argument in... · 8e3d9296
      thiolliere authored
      [Tx ext stage 2: 1/4] Add `TransactionSource` as argument in `TransactionExtension::validate` (#6323)
      
      ## Meta 
      
      This PR is part of 4 PR:
      * https://github.com/paritytech/polkadot-sdk/pull/6323
      * https://github.com/paritytech/polkadot-sdk/pull/6324
      * https://github.com/paritytech/polkadot-sdk/pull/6325
      * https://github.com/paritytech/polkadot-sdk/pull/6326
      
      ## Description
      
      One goal of transaction extension is to get rid or unsigned
      transactions.
      But unsigned transaction validation has access to the
      `TransactionSource`.
      
      The source is used for unsigned transactions that the node trust and
      don't want to pay upfront.
      Instead of using transaction source we could do: the transaction is
      valid if it is signed by the block author, conceptually it should work,
      but it doesn't look so easy.
      
      This PR add `TransactionSource` to the validate function for transaction
      extensions
  16. Nov 06, 2024
    • Francisco Aguirre's avatar
      XCM v5 (#4826) · 85521e87
      Francisco Aguirre authored
      # Context
      
      This PR aims to introduce XCMv5, for now it's in progress and will be
      updated over time.
      This branch will serve as a milestone branch for merging in all features
      we want to add to XCM, roughly outlined
      [here](https://github.com/polkadot-fellows/xcm-format/issues/60).
      More features could be added.
      
      ## TODO
      - [x] Migrate foreign assets from v3 to v4
      - [x] Setup v5 skeleton
      - [x] Remove XCMv2
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5390
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5585
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5420
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5876
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5971
      - [x] https://github.com/paritytech/polkadot-sdk/pull/6148
      - [x] https://github.com/paritytech/polkadot-sdk/pull/6228
      
      Fixes #3434 
      Fixes https://github.com/paritytech/polkadot-sdk/issues/4190
      Fixes https://github.com/paritytech/polkadot-sdk/issues/5209
      Fixes https://github.com/paritytech/polkadot-sdk/iss...
  17. Nov 05, 2024
  18. Oct 24, 2024
  19. Oct 18, 2024
    • georgepisaltu's avatar
      FRAME: Reintroduce `TransactionExtension` as a replacement for `SignedExtension` (#3685) · b76e91ac
      georgepisaltu authored
      Original PR https://github.com/paritytech/polkadot-sdk/pull/2280
      reverted in https://github.com/paritytech/polkadot-sdk/pull/3665
      
      This PR reintroduces the reverted functionality with additional changes,
      related effort
      [here](https://github.com/paritytech/polkadot-sdk/pull/3623).
      Description is copied over from the original PR
      
      First part of [Extrinsic
      Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415)
      
      Introduces a new trait `TransactionExtension` to replace
      `SignedExtension`. Introduce the idea of transactions which obey the
      runtime's extensions and have according Extension data (né Extra data)
      yet do not have hard-coded signatures.
      
      Deprecate the terminology of "Unsigned" when used for
      transactions/extrinsics owing to there now being "proper" unsigned
      transactions which obey the extension framework and "old-style" unsigned
      which do not. Instead we have __*General*__ for the former and
      __*Bare*__ for ...
  20. Oct 17, 2024
    • drewstone's avatar
      Import vec to bridges/primitives/header-chain (#6031) · 31dfc9f6
      drewstone authored
      # Description
      
      I'm unable to build a bridge library due to the errors below, so I am
      adding the explicit import to `sp_std::vec`.
      
      ## Integration
      
      Projects using it can update their dependency. We are using the branch
      `stable2407` (mixed them up in my branch).
      
      ## Errors
      ```
      error: cannot find macro `vec` in this scope
        --> /Users/drew/.cargo/git/checkouts/polkadot-sdk-cff69157b985ed76/88c32501/bridges/primitives/header-chain/src/justification/verification/mod.rs:99:19
         |
      99 |         let mut route = vec![];
         |                         ^^^
         |
      help: consider importing one of these items
         |
      23 + use scale_info::prelude::vec;
         |
      23 + use sp_std::vec;
         |
      
      error: cannot find macro `vec` in this scope
         --> /Users/drew/.cargo/git/checkouts/polkadot-sdk-cff69157b985ed76/88c32501/bridges/primitives/header-chain/src/justification/verification/optimizer.rs:135:36
          |
      135 |         duplicate_votes_ancestries_idxs: vec![],
          |                                          ^^^
          |
      help: consider importing one of these items
          |
      19  + use scale_info::prelude::vec;
          |
      19  + use sp_std::vec;
          |
      
      error: cannot find macro `vec` in this scope
         --> /Users/drew/.cargo/git/checkouts/polkadot-sdk-cff69157b985ed76/88c32501/bridges/primitives/header-chain/src/justification/verification/optimizer.rs:134:21
          |
      134 |         extra_precommits: vec![],
          |                           ^^^
          |
      help: consider importing one of these items
          |
      19  + use scale_info::prelude::vec;
          |
      19  + use sp_std::vec;
          |
      
      error: cannot find macro `vec` in this scope
        --> /Users/drew/.cargo/git/checkouts/polkadot-sdk-cff69157b985ed76/88c32501
      
      /bridges/primitives/header-chain/src/justification/verification/equivocation.rs:89:27
         |
      89 |         let mut equivocations = vec![];
         |                                 ^^^
         |
      help: consider importing one of these items
         |
      19 + use scale_info::prelude::vec;
         |
      19 + use sp_std::vec;
      ```
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Co-authored-by: default avatarSerban Iorga <serban@parity.io>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
  21. Oct 10, 2024
    • Francisco Aguirre's avatar
      Remove redundant XCMs from dry run's forwarded xcms (#5913) · 4a70b2cf
      Francisco Aguirre authored
      # Description
      
      This PR addresses
      https://github.com/paritytech/polkadot-sdk/issues/5878.
      
      After dry running an xcm on asset hub, we had redundant xcms showing up
      in the `forwarded_xcms` field of the dry run effects returned.
      These were caused by two things:
      - The `UpwardMessageSender` router always added an element even if there
      were no messages.
      - The two routers on asset hub westend related to bridging (to rococo
      and sepolia) getting the message from their queues when their queues is
      actually the same xcmp queue that was already contemplated.
      
      In order to fix this, we check for no messages in UMP and clear the
      implementation of `InspectMessageQueues` for these bridging routers.
      Keep in mind that the bridged message is still sent, as normal via the
      xcmp-queue to Bridge Hub.
      To keep on dry-running the journey of the message, the next hop to
      dry-run is Bridge Hub.
      That'll be tackled in a different PR.
      
      Added a test in `bridge-hub-westend-integration-tests` and
      `bridge-hub-rococo-integration-tests` that show that dry-running a
      transfer across the bridge from asset hub results in one and only one
      message sent to bridge hub.
      
      ## TODO
      - [x] Functionality
      - [x] Test
      
      ---------
      
      Co-authored-by: command-bot <>
  22. Oct 09, 2024
  23. Oct 08, 2024
  24. Oct 07, 2024
  25. Oct 05, 2024
  26. Oct 04, 2024
  27. Oct 03, 2024
  28. Sep 26, 2024
  29. 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...
    • Clara van Staden's avatar
      Fix border condition in Snowbridge free consensus Updates (#5671) · 1790e427
      Clara van Staden authored
      
      # Description
      
      A fix for a border condition introduced with new feature
      https://github.com/paritytech/polkadot-sdk/pull/5201. A malicious
      relayer could spam the Ethereum client with sync committee updates that
      have already been imported for the period. This PR adds a storage item
      to track the last imported sync committee period, so that subsequent
      irrelevant updates are not free.
      
      Original PR: https://github.com/Snowfork/polkadot-sdk/pull/172
      
      ## Integration
      
      Downstream projects are not affected. Relayers will not be able to spam
      the Ethereum client with irrelevant sync committee updates for free.
      
      ## Review Notes
      
      Adds a storage item to track the last free sync committee update period,
      so that duplicate imports are not free.
      
      ---------
      
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
    • 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 <>
  30. 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>