Swap alt fee tokens into the native token prior to fee burn #4328
Comments
Should we add an additional fee multiplier to fees paid in the non-native asset to account for the additional work of swapping? |
|
I don't think so, since that cost isn't really attributable to a psecific transaction. I'm also not sure it's necessary. In this V0 design, there's no connection between the different prices, all of which are fixed -- so the values of the different fee tokens could float around and cause pricing disparities. To address this, I think that the fixed fees for alternative gas tokens should be significantly higher (10x). This way, users can come into the chain and use it, but they're incentivized to use the native fee token which will protect their privacy. |
|
The issue here is primarily that we don't currently have any plumbing set up to move the values of the fees around and then swap them, and doing that will require some design work. Maybe we don't get to doing this pre-mainnet. |
|
Sounds like we need to discuss & clarify which part of this ticket is in scope for V1 - @hdevalence when you say "maybe we don't get to doing this pre-mainnet", do you mean this ticket generally? Will burning the alt fee tokens cause issues for users? |
|
@aubrika what does it mean if this ticket is tagged as |
## Describe your changes Moves fee handling out of the Transaction's ActionHandler and into the component, which accumulates fees (in any token), and adds hooks to the DEX thatadd chain-submitted swaps for any non-native fee tokens into the native token. These are then accumulated back into the fee component. The base fee and tip are tracked separately through this whole process, in order to support the intended behaviour (the base fee is burned to account for the _chain_'s resource use, the tip is sent to the proposer to encourage them to include transactions in fee priority order). However, tip handling is not currently implemented, so both are burned. Later, the funding/distribution components should extract the tip and send it to the proposer's funding streams. However, until a robust fee market develops, this form of proposer incentivization can be deferred. The accounting will be there for it when it arises. ## Issue ticket number and link #4328 ## Checklist before requesting a review - [x] If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: > consensus-breaking but not state-breaking, no migrations necessary --------- Co-authored-by: Erwan Or <erwanor@penumbralabs.xyz>
As described in #4320, the initial implementation of multi-asset fee support burns the alt fee tokens. This is incorrect, since the chain should only be minting/burning native assets. The correct behavior is that the fees paid in alt fee tokens should be converted to the native token. However, since the DEX is batched, we need some plumbing to collect fee amounts, include them in batch swaps, and then handle the resulting fee payments. This overlaps with work we'd thought about (but haven't done, and deferred) as part of #3666 and we should think about them at the same time.
The text was updated successfully, but these errors were encountered: