This pull request appears to expose arbitrage and spam opportunities, as it proposes to modify the Substrate frame DEX pallet to allow users to use an exotic asset for transaction fees instead of the chain's native token, and any transaction fee overpayments made in the exotic token may be refunded in the native token instead if the native token balance of the originating account falls below the existential deposit.
Let's suppose that prior to a user making a transaction where they choose for the transaction fee to be made with an asset other than the chain's native token they deliberately open a futures market perpetual long trading position on that exotic asset without using a stop-loss and using a sacrificial amount of their capital that they borrow against with high leverage from a lending market so that it gets liquidated when the value of their loaned amount goes below the maintenance margin rate level due to liquidation bots of the DEX wiping out their risky position (using flash loans from lending markets rather than by holding up-front capital).
This way they could significantly push down the market rate of that exotic asset (and possibly also the market rate of the native token to a lesser degree if it was more liquid) since they chose to use an exotic asset that has low liquidity (large bid-ask spread, less market depth).
Once the market value of that exotic asset is lowered significant they could initiate a transaction where they choose for their transaction fees to be made with that exotic asset.
Before the transaction is executed the payment of the transaction fees needs to be secured using the withdraw_fee extrinsic, where the fee already includes the user-included tip, and where the priority of the transaction is based on the amount of tip the user is willing to pay per unit of either weight or length, depending which one is more limiting (see the get_priority extrinsic of the transaction-payment frame).
So if the transaction fee is to be paid using an exotic asset whose market price has been lowered significantly through their market manipulation strategy and they are also allowed to pay the tip in that exotic asset rather than the native token (assuming the native token has much higher liquidity and more difficult to manipulate) then they could perform flash transactions with a very high priority at a very low cost and use a small weight or length.
For example, if they wanted to make a transaction with a large value of tokens then they might be able to lower the market value of the exotic asset that they choose to pay the associated transaction fee with just for the instant when the transaction fee is calculated to reduce the transaction fee so that its amount (plus the sacrificial amount that may have been liquidated to lower that exotic asset's market value) becomes lower than the what the transaction fee would have been in the native token.
Additionally, recall that the purpose of transaction fees is to "prevent individual users from consuming too many resources and that Polkadot uses a weight-based fee model as opposed to a gas-metering model where fees are charged prior to transaction execution and once the fee is paid nodes will execute the transaction". So in this instance where a user may be able to manipulate the transaction fee to be significantly lower than normal by using an exotic asset to pay the transaction fees instead of the native token, they may therefore be able to afford to pay a large tip so the transaction would have a higher priority. If they did this to a batch of similar transactions they could spam and saturate the network with that type of transaction and consume all resources.
This problem could be exacerbated if a future pull request proposed to allow the use of exotic assets instead of native tokens for staking purposes too, instead of just for transaction payments. For example, if we allowed miners/validators/collator nodes to stake in exotic assets rather than just native assets, then since their MinerTxPriority is influenced by their stake, then it may be a concern if its easy for them to manipulate the market value of that illiquid exotic asset that they choose to stake with.
If for example they were able to afford the native token fees but they chose to pay transaction fees in the exotic asset instead so they'd be able to reduce the transaction fee significantly to say 10% of the what they would otherwise have had to pay using the native token, then they could still afford to choose to overpay the transaction fee by a factor of say 10x the required transaction fee amount using the exotic asset whose market value they had manipulated to be lower, such that if that account still maintained the existential deposit balance after the transaction was executed and when the actual fee was calculated by the correct_and_deposit_fee extrinsic, the correct_and_deposit_fee extrinsic would refund all the overpaid fee amount in the native token that may not have been affected by their market manipulation (or in the exotic asset that by that stage may have finished being liquidated and easily returned back to its pre-liquidation market value with a capital injection), such that the user could actually profit from the refund of each fee that they overpaid.
If the amount to be refunded remained in the exotic asset rather than the native token then it may overcome this possible arbitrage opportunity and protect the treasury itself and miners/validators/collator nodes from liquidity risk (assuming the treasury or miners/validators/collator nodes are those that hold the transaction fees that are withdrawn using the withdraw_fee extrinsic).
If the refund were to be in the native token then it may be sensible for the withdraw_fee extrinsic to use an oracle or similar to check and rate the legitimacy of the exotic asset and its creators and its recent and historic liquidity and only allow it to be used if its rating was above a pre-defined trust threshold.
Note: The get_priority extrinsic uses a scaling factor.
If they don't get a refund because their native token account balance fell below the existential deposit, then instead of penalising them by not refunding them at all, then we could instead forward their refund to the treasury and allow them to claim those tokens in future from that account if and when it has a sufficient existential deposit.
However, if we did this, and we also allowed transaction fees in exotic assets instead of native tokens, and we only provided native tokens as a refund, then over time the treasury may end up borrowing against a large amount of illiquid exotic tokens that they were holding and waiting for users to claim against, and then if a large amount of users who all significantly overpaid were to claim a refund back at the same time in native tokens for their overpayment in the exotic tokens when the market value of those exotic tokens was easily manipulated to capitulate, then the treasury could be at risk.
Question: If the user overpays their transaction fee but the account balance of the originating wallet falls below the existential deposit amount then should the refund be burnt, or ownership transferred to the treasury, or held by the treasury in the native token or in the exotic asset with ownership claimable by the originating wallet in future, and should any transaction fees and refunds that occur be made in the native token or in the exotic asset to reduce the risk of spam?
