Tx Payment: drop ED requirements for tx payments with exchangeable asset #4488
Conversation
…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 <25483142+joepetrowski@users.noreply.github.com>
muharem
added
the
T1-FRAME
|
The CI pipeline was cancelled due to failure one of the required jobs. |
| OUF::on_unbalanced(fee); | ||
| OUT::on_unbalanced(tip); |
There was a problem hiding this comment.
we can make this as in transaction payment pallet (OU::on_unbalanceds(vec![fee, tip])), if #4564 pr get merged
substrate/frame/transaction-payment/asset-conversion-tx-payment/src/lib.rs
Outdated
Show resolved
Hide resolved
substrate/frame/transaction-payment/asset-conversion-tx-payment/src/lib.rs
Show resolved
Hide resolved
| F::total_balance(asset_id.clone(), who).is_zero() | ||
| { | ||
| // Nothing to refund or the account was removed be the dispatched function. | ||
| (initial_asset_consumed, fee_paid) |
There was a problem hiding this comment.
It could also be that the account is still alive but just does not have any balances of that asset?
But its probably fine - otherwise it would need some more complicated logic to check that the refunded amount is above ED.
There was a problem hiding this comment.
right. also current implementation for only a native asset (pallet-transaction-payment) also follows this logic and asserts it with a test. there might be other reasons. for example if you transfer all and wanna your account to be removed, you do not wanna any refund back.
may be @kianenigma can add more to this.
There was a problem hiding this comment.
Do we want to keep the same assumption in the case where the asset is sufficient?
There was a problem hiding this comment.
@georgepisaltu which assumption? the transfer all and reap account is real use case.
There was a problem hiding this comment.
The assumption that the account was removed. I understand the reap account is a real use case, I was talking about @ggwpez 's situation where you maybe consumed all the asset. It would get messy with the ED calculation, but I think we don't care about that if the asset is sufficient and we have some of it to refund, right? I'm asking if the intended behavior is to ignore this "sufficient" case as with the current impl.
There was a problem hiding this comment.
Yes, system account or any other can be still alive.
The intended behavior is to have no refund if a dispatched call results the asset account to be removed, regardless of the asset type.
substrate/frame/transaction-payment/asset-conversion-tx-payment/src/payment.rs
Outdated
Show resolved
Hide resolved
substrate/frame/transaction-payment/asset-conversion-tx-payment/src/payment.rs
Show resolved
Hide resolved
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
substrate/frame/transaction-payment/asset-conversion-tx-payment/src/payment.rs
Outdated
Show resolved
Hide resolved
| F::total_balance(asset_id.clone(), who).is_zero() | ||
| { | ||
| // Nothing to refund or the account was removed be the dispatched function. | ||
| (initial_asset_consumed, fee_paid) |
There was a problem hiding this comment.
Do we want to keep the same assumption in the case where the asset is sufficient?
substrate/frame/transaction-payment/asset-conversion-tx-payment/src/tests.rs
Show resolved
Hide resolved
substrate/frame/transaction-payment/asset-conversion-tx-payment/src/tests.rs
Outdated
Show resolved
Hide resolved
Drop the Existential Deposit (ED) requirement for the asset amount exchangeable for the fee asset (eg. DOT/KSM) during transaction payments.
This achieved by using
SwapCreditimplementation of swap, which works with imbalances and does not require a temporary balance account within the transaction payment.Problem
Currently, every swap during transaction payment, processed with asset
Afor 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 duringpre_dispatch, with refunds for excess ED swap occurring duringpost_dispatch. Further details can be found here.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
Ato ensure there is enough not only for the fee payment but also some extra to meet the ED requirement for their native account duringpre_dispatch. In some cases duringpost_dispatch, the user will have the excess ED swapped back to assetA, while in other cases, it may not be sufficient to meet the ED requirement for assetA, leading it being left in the user's 'temporary' native asset account.