-
Notifications
You must be signed in to change notification settings - Fork 810
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ChargeAssetTxPayment
Should Handle Fee Withdrawal Better When an Account Does Not Exist in System
#86
Labels
I5-enhancement
An additional feature request.
T1-FRAME
This PR/Issue is related to core FRAME, the framework.
Comments
this now should be possible with swap credit implementation |
@muharem can we close this now with swap credit in the runtimes? |
jonathanudd
pushed a commit
to jonathanudd/polkadot-sdk
that referenced
this issue
Apr 10, 2024
@joepetrowski yes, this can be closed |
|
Reopening for the |
10 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
I5-enhancement
An additional feature request.
T1-FRAME
This PR/Issue is related to core FRAME, the framework.
Right now, when an asset is converted to the native asset for fee payment, it must create the account for the transaction's execution. This means, if the account doesn't already exist, it actually converts the existential deposit plus the fee in order to have enough balance.
At the end of the transation, in
post_dispatch
, the ED plus any fee refund are converted back into the asset selected by the user.This requires the user to have a liquid balance of the asset much greater than the potential transaction fee. It would be better to handle this by only withdrawing the amount needed for the fee.
To consider though: Asset Conversion does not obviate the need for sufficiency. An account should only exist without the ED if an asset it holds is sufficient. If paying in that asset, one could argue that if it cannot be converted to the ED of the native asset, then the minimum balance of the asset class is too low. However, the user could be paying via asset conversion with another, non-sufficient asset.
The text was updated successfully, but these errors were encountered: