[FR] Implement a Fee Splitting and Burning mechanism to burn KMD and support the Komodo blockchain

[shamardy]

A feature was proposed to introduce a KMD burn program using a part of the DEX fee, in order to support the Komodo blockchain and create a deflationary pressure. This feature would consist of the following steps:

• Convert 25% of the DEX fee to KMD if the fee is not paid in KMD. We can convert all of the DEX fee or only the part that is to be burned to KMD.
• The amount of KMD that to be burned can be burned using an OP_RETURN output, which would make them unspendable and allow us to store some metadata in the transaction if needed.

For the proof of concept, we would implement the feature only for the fee paid in KMD, as this is the simplest way to do it. After that, we would research a way to convert the fee or the part to be burned from any other coin to KMD and burn the part to be burned.

The checklist for the proof of concept would be:

• [ ] Add a new output to the DEX fee transaction that is an OP_RETURN with 25% of the fee burned in KMD. (Onur)
• [ ] Validate the new output by the maker as part of the taker fee validation step. (Onur)
• [ ] Implement this feature for the trading protocol upgrade. (Artem)

Burning mechanism in EVM TPU on defi framework side

• [ ] https://github.com/KomodoPlatform/komodo-defi-framework/pull/2129#discussion_r1695417301 (provide burn_fee support in eth_swap_v2.rs payment methods)

[onur-ozkan]

A feature was proposed to introduce a KMD burn program using a part of the DEX fee, in order to support the Komodo blockchain and create a deflationary pressure. This feature would consist of the following steps:

Convert 25% of the DEX fee to KMD if the fee is not paid in KMD. We can convert all of the DEX fee or only the part that is to be burned to KMD.

The amount of KMD that to be burned can be burned using an OP_RETURN output, which would make them unspendable and allow us to store some metadata in the transaction if needed.

Once #2006 is merged, this issue will be closed. It's worth to move these to a separate issue. I have a strong opinion that we should have the global fee handler implementation before going for something like this (otherwise swap algorithms will become quite fragile with the complex calculations splitted all over the core swap implementations).