Tx Payment: (tests check) drop ED requirements for tx payments with exchangeable asset #4455
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The CI pipeline was cancelled due to failure one of the required jobs. |
muharem
changed the title
muharem
changed the title
fellowship-merge-bot bot
pushed a commit
to polkadot-fellows/runtimes
that referenced
this pull request
May 19, 2024
…310) Drop the Existential Deposit (ED) requirement for the asset amount exchangeable for the fee asset (DOT/KSM) during transaction payments. Currently, every swap during transaction payment, processed with asset `A` for native asset, must be for an amount greater than the ED of a native asset if the user lacks a native asset account. Since fees are typically smaller, the current implementation necessitates additional swaps to meet the ED during `pre_dispatch`, with refunds for excess ED swap occurring during `post_dispatch`. Further details can be found [here](https://github.com/paritytech/polkadot-sdk/blob/115c2477eb287df55107cd95594100ba395ed239/substrate/frame/transaction-payment/asset-conversion-tx-payment/src/payment.rs#L115). This setup presents an issue where a user is unable to transfer their entire balance and close the account. Instead, the user must transfer slightly less of asset `A` to ensure there is enough not only for the fee payment but also some extra to meet the ED requirement for their native account during `pre_dispatch`. In some cases during `post_dispatch`, the user will have the excess ED swapped back to asset `A`, while in other cases, it may not be sufficient to meet the ED requirement for asset `A`, leading it being left in the user's 'temporary' native asset account. Example: https://assethub-polkadot.subscan.io/extrinsic/6204018-9?event=6204018-79 Given the importance of this scenario for CEX, I propose a solution that does not entail breaking changes to the pallets' API and open PR to the runtimes without waiting for new polkadot-sdk version. Additionally, I have opened a draft PR with these types in their respective pallets in FRAME, where they have been tested against existing tests for types implementing the same contract. PR - paritytech/polkadot-sdk#4455 Target implementation with breaking changes: paritytech/polkadot-sdk#4488 --------- Co-authored-by: joe petrowski <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Use Credit Swaps for transaction payments involving assets exchangeable for the native asset to bypass the need for Existential Deposit (ED).
This PR includes implementations of two types proposed to the runtimes, available here - link. These types are designed to avoid any breaking changes to the pallets and can be proposed to the runtime without requiring a library version upgrade.
The current version of the PR is intended to assess the correctness of the new types against the existing tests built for types implementing the same protocol.
I believe that with some breaking changes, the solution can be further improved, potentially eliminating the need for an implementation like
FungiblesAdapterof theOnChargeTransactiontrait. However, implementing such changes would require additional time and cannot be integrated for the next runtime release.Target implementation with breaking changes: #4488