-
Notifications
You must be signed in to change notification settings - Fork 378
Conversation
…gav-xcm-v3-and-bridges-plus-assets`
* Fix for FungiblesAdapter - trait changes: Contains -> AssetChecking * Fix for missing weight for `fn unpaid_execution()` * Used NonLocalMint for all NonZeroIssuance * Fix
@bkontur https://gitlab.parity.io/parity/mirrors/cumulus/-/jobs/2989180 was started for your command Comment |
@bkontur https://gitlab.parity.io/parity/mirrors/cumulus/-/jobs/2989185 was started for your command Comment |
@bkontur https://gitlab.parity.io/parity/mirrors/cumulus/-/jobs/2989186 was started for your command Comment |
@bkontur https://gitlab.parity.io/parity/mirrors/cumulus/-/jobs/2989187 was started for your command Comment |
@bkontur Command was rescheduled and failed to finish (check for task id 6-9cc4ab57-ad64-4f36-adb6-f730fac246cf in the logs); execution will not automatically be restarted further. |
@bkontur Command was rescheduled and failed to finish (check for task id 7-13f27ea6-3924-4ce7-b175-de2d46c4f49b in the logs); execution will not automatically be restarted further. |
…allet_xcm_benchmarks::generic
@bkontur Command |
@bkontur Command |
@bkontur Command |
…s pallet_bridge_transfer
@bkontur Command |
…ts pallet_bridge_transfer
…ets pallet_bridge_transfer
for IsTrustedBridgedReserveLocationForConcreteAsset<UniversalLocation, Reserves> | ||
{ | ||
fn contains(asset: &MultiAsset, origin: &MultiLocation) -> bool { | ||
let universal_source = UniversalLocation::get(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The beginning (~40 lines) of both IsTrustedBridgedReserveLocationForConcreteAsset::contains
and IsAllowedReserveBasedTransferForConcreteAssetToBridgedLocation::contains
is almost the same (ensure_is_remote(UniversalLocation::get(), _); let asset_location = ...
). Maybe it could be extracted to a separate function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, I also realized that but I didnt come back to that,
I will check that
); | ||
|
||
// call bridge | ||
// TODO: check-parameter - should we handle `sender_cost` somehow ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not an issue, just wanted to understand and clarify - maybe I'm missing something. IIUC, apart from the bundled assets, the sender pays for the:
- execution at the target chain in target tokens. This fee is configured at the source chain (here, where this code is executed). If the actual XCM weight is lower than the configured, the excess fee goes to the
sovereign-account-of-this-chain-at-the-target-chain
, right? - regular transaction cost for the
transfer_asset_via_bridge
call at the source (this) chain.
The XcmpQueue
at asset hubs is configured to have zero fee for sending messages to sibling chain (type PriceForSiblingDelivery = ();
). So even if we'll start handling sender_cost
here, it won't change anything, given current configuration, right?
Also - this means that we are controlling the whole fee (transport + execution) using this single constant AND the fee is only withdrawn when the message gets dispatched at the target chain. So it'll pass through 3 queues (Polkadot.AsssetHub -> Polkadot.BridgeHub, Polkadot.BridgeHub -> Kusama.BridgeHub, Kusama.BridgeHub -> Kusama.AssetHub) before dispatch and only then we'll charge sender. If one of queues is stalled, this would allow senders to keep filling up queues for free (except regular tx fee).
Just wanted to bring attention to that, because my understanding was that we'll be taking two fees. Execution using regular XCM BuyExecution
mechanism and some constant "transport" fee when the message gets sent. The latter one will evolve to some non-constant value later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you, Slava, I will fix this as we talked yesterday
bot rebase |
Rebased |
closing in favour of #2762 (for rococo/wococo we will provide new solution base on this new PR) |
PR introduces:
(even if pallet is configured in runtimes and deployed live, there is no way to initiate transfer unless HRMPs to bridge-hubs are opened)
fn universal_origin(_: &Junction) -> Weight {
Note: do not merge until #2642 is merged or remove TrailingSetTopicAsId from here and fix test