Skip to content
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

Optimize the payment logic of handling fees #2667

Closed
StrawberryFlavor opened this issue Dec 8, 2023 · 1 comment · Fixed by #2679
Closed

Optimize the payment logic of handling fees #2667

StrawberryFlavor opened this issue Dec 8, 2023 · 1 comment · Fixed by #2679

Comments

@StrawberryFlavor
Copy link
Member

StrawberryFlavor commented Dec 8, 2023

The account balance is only $usdc and $aca

  1. all $aca is used for earning.Bonded, the account Available balance is insufficient
  2. use $usdc to swap on dex

This transaction will fail. The possible reason is that when operating evm token, a certain nativeToken is required for Reserved

Transfer 1 $aca to this address, and usetransactionPayment.withFeePath to specify $usdc
This transaction was successful, verifying the conjecture:

  1. $usdc can be used as handling fee
  2. In the handling fee logic, the reserved nature of evm tokens is not taken into account.

image
image

@xlc
Copy link
Member

xlc commented Dec 12, 2023

So the issue is that transactionPayment.withFeePath is only used for the initial tx fee, but not the additional EVM storage fee.
I think the best way is to have a new storage that is set on ensure_can_charge_fee_with_call and cleared on post_dispatch and update native_then_alternative_or_default to use this new path before the alternative path.

In this way, with_fee_path / with_fee_currency / with_fee_aggregated_path can be used to override EVM storage fee asset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants