-
Notifications
You must be signed in to change notification settings - Fork 1
Conversation
So where did the fees go before this PR? To the AH sovereign account? And now it is going to the transfer beneficiary? |
// Deposit asset to beneficiary. | ||
DepositAsset { assets: Definite(asset.into()), beneficiary }, | ||
// Deposit both asset and fees to beneficiary. | ||
DepositAsset { assets: Wild(AllCounted(2u32)), beneficiary }, |
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.
Why AllCounted
instead of All
?
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.
Previously the remaining DOT was trapped in pallet-xcm. |
So basically there is no explicit calculation/configuration variable that we can set the ED to when transferring? We need to calculate the fee for sendToken with the ED taking into account? |
As I mentioned in notion page, since the ED is only 0.01 DOT on AssetHub, a tiny extra assetHubReserveTransferFee will just cover that. |
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.
+1
…t sending token to penpal
println!("key:{:?}", hex::encode(&key)); | ||
println!("value:{:?}", hex::encode(&value)); |
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.
Do we want to leave these in?
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.
Yeah, context in https://github.com/Snowfork/snowbridge/pull/1174/files#r1565989912
// Deposit asset to beneficiary. | ||
DepositAsset { assets: Definite(asset.into()), beneficiary }, | ||
// Deposit both asset and fees to beneficiary. | ||
DepositAsset { assets: Wild(All), beneficiary }, |
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.
This introduces a new failure mode and extra burden on integrations. The failure it is trying to fix is that it will create the account on the destination parachain. However this now places a burden on the destination parachain to store excess DOT in one of their pallets, if it is not configured to than the deposit will fail and assets will be trapped.
So we probably shouldn't do this on the destination chain portion. Only on asset hub.
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.
Good point 👍
@yrong In general, I am very conservative with changes to our XCM messages, as they can have undefined behavior, depending on the destination parachain.
I think as a practice, before we write any code we should write a short RFC document explaining the change, and detailing any potential changes in behavior that could be problematic.
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.
Its also hard to review, without seeing the complete messages that are forwarded to AssetHub and the final dest para,
So the RFC doc should include pseudocode describing the full messages.
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.
Yeah, that make sense.
Usually I check the xcm message from log of emulated test with log level specified(e.g. RUST_LOG=xcm=trace) but it's not easy for others to review/understand.
Sorry for that, let me add the document with the xcm messages forwarded.
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.
7e0ddaa for the fix.
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.
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.
Btw, the initial intention is just for deposit the excess DOT to beneficiary on destination chain, because it's always not good to leave the fees trapped somewhere instead of send it to the user.
Also it seems better to encourage the end user to send enough destination_fee
on Ethereum to ensure the xcm will be success on substrate, and we just let them know the extra fees will be finally refunded and no worry.
But consider the side effects above we only apply this change on asset hub and not do this on the destination chain portion.
Just the upper-stream for Snowfork#137 and more context there. --------- Co-authored-by: Clara van Staden <claravanstaden64@gmail.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
Closed in favor of paritytech#4175 |
Just the upper-stream for Snowfork#137 and more context there. --------- Co-authored-by: Clara van Staden <claravanstaden64@gmail.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
…#4175) Just the upper-stream for Snowfork#137 and more context there. --------- Co-authored-by: Clara van Staden <claravanstaden64@gmail.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
No description provided.