With Babel fees one can pay for transactions in native tokens. Could this be extended to where someone could pay for the ADA part of the transaction fee and also provide a swap with a different native asset the of the swap requestors choice? This would mean the ledger itself could act as a DEX with the lowest possible overhead.

  • I suggest you read the guidelines for asking questions and consider re-writing the question to clarify what you are asking.
    – gRebel
    May 27 at 7:41
  • @gRebel I'm not sure how to word this better, any suggestions? May 27 at 12:08

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.

  • "guaranteeing liquidity/conversion to ADA" I'm wondering if it could be extended to letting there be liquidity/conversation to native tokens. That would always be more efficient than a dapp DEX because there would be no smart contract gas fee May 27 at 12:10
  • This is under the assumption that Babel fees won't require smart contracts. They are essentially a method of deferring that conversion until later. The pool owners and delegators can elect to either take the tokens as rewards or exercise what effectively amounts to a future between the tokens and ADA. I suspect the exercising deadline will be on the epoch edge and which tokens will be exercised or not will be decided by either the stake pool operator or during delegation. In this supposed implementation this just means that those contracts are executing later not that they aren't executing.
    – lambda
    May 27 at 12:23
  • The blog post states Babel fees do not use Smart Contracts, instead I believe you issue a UTXO with a negative value May 27 at 12:46
  • I just reread the article and you are correct. I would caution however that since the concept has yet to reach the paper phase, it will likely change significantly and I suspect we will see far more restrictions on it than we see now. WRT what we know however I believe the answer to your question is maybe but most likely no. It should not be used that way on the main net as that will cause many unnecessary transactions that will lead to ledger bloat. On a state channel or side chain you could possibly use it however it would have a lot of limitations.
    – lambda
    May 27 at 15:30
  • The short of it is we don't know enough yet and we won't have remotely close to enough information to accurately judge whether it will be feasible or even possible until a paper comes out. At the moment it is more a thought experiment than anything else and effectively anything is possible and nothing is possible until we see what changes it imposes on the ledger specification.
    – lambda
    May 27 at 15:33

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .