I think you may want to consider reversing the order here. The intent behind babel fees from my understanding is to leverage future conversion guarantees, DEXes, and other avenues for guaranteeing liquidity/conversion to ADA rather than to provide it's own mechanism.

We know these mechanisms will exist on chain from third parties so there is little reason for the foundational infrastructure itself to attempt to solve the problem as well. Instead it can leverage the existing solutions (once smart contracts are live) and allow competition and market forces to push for improvements and drive down prices.

Additionally note that babel fees are in the paper phase at the moment. This means we won't see them on-chain for at least a year or two and the ecosystem may look vastly different than it does now so our assumptions as to how exchanges and liquidity systems operate may have changed significantly (based on the change we've seen in the last year or so).

I may be off-base here. If so, I'd appreciate someone chiming in to correct me.

I think you may want to consider reversing the order here. The intent behind babel fees from my understanding is to leverage future conversion guarantees, DEXes, and other avenues for guaranteeing liquidity/conversion to ADA rather than to provide it's own mechanism.

We know these mechanisms will exist on chain from third parties so there is little reason for the foundational infrastructure itself to attempt to solve the problem as well. Instead it can leverage the existing solutions (once smart contracts are live) and allow competition and market forces to push for improvements and drive down prices.

It may be possible depending on how the negative values in EUTxO are implemented. The main issue is that as described in the blog post it currently relies on the assumption that transactions are only filled if the block producers can find a way to fill them. This would still likely be relying on conversion guarantees, DEXes, and other avenues for guaranteeing liquidity/conversion. Essentially this means if the block producers can't or won't exchange the tokens themselves, they'll have to use an on chain solution or the protocol will have to be extended so that non block producers can fill the requests. While this change can be done it would be very much non-trivial as it would likely require running an entire second network for negotiating order filling in between block production.

The issues with using this for running a DEX or liquidity system outside of just implementing it so that using it for DEXes would be feasible are that it'd create a lot of unnecessary transactions on-chain (which is inherent to on-chain DEXes) and depending how the system is implemented, it may put significant unnecessary load on the block producers. You'd probably want to run it on a state channel or side chain however both introduce new problems. The state channels would pose issues as joining may end up too expensive and side chains have significantly weaker security guarantees which would place using such a DEX somewhere in-between on chain and using a CEX in terms of security guarantees.

Additionally note that babel fees are in the paper phase at the moment. This means we won't see them on-chain for at least a year or two and the ecosystem may look vastly different than it does now so our assumptions as to how exchanges and liquidity systems operate may have changed significantly (based on the change we've seen in the last year or so).

TLDR: Maybe. We do not know remotely enough about how the system is implemented to know whether it would be feasible or even possible yet. When a paper on the topic is published, we should know enough to reason about the potential however as it stands it could be anywhere between completely feasible and impossible.

I may be off-base here. If so, I'd appreciate someone chiming in to correct me.