Not sure I agree with this. IMO width is the same as depth on a DEX. The fact that a given denom is being swapped automatically for fees will create liquidity for it on a DEX. You might see a brief period of high slippage, but then someone will step in to arbitrage, bringing the necessary depth.
Liquidity is a schelling point, and swapping fees from the Hub will create that schelling point. It would be incredibly foolish not to use that for the advantage of the AEZ.
Doesn’t this assume that this (again, currently nonexistent) dex will have pools for each fee asset someone would seek to be using as fees on the hub? And that there’s a module that would allow for these swaps?
This puts a ton of business model assumptions and success assumptions on a product which, and I cannot stress this enough, does not currently exist. It kinda feels like Emeris all over again.
I understand that this may change with time, but it seems as though this might be a ways off. This proposal offers a solution that’s ready today. It makes sense to implement it to drive value today, and when an appropriate consumer chain dex does arise, either roll a custom module or work with Osmosis to negotiate an outcome that may look something like this:
Great points. It immediately benefits ATOM holders and the Osmosis community who funded it. And down the road when Duality has the liquidity, Hub governance can propose a change.
And someone mentioned the idea of retooling so it allows for both Duality and Osmosis, defaulting to Duality unless they have no liquidity.
It might also make sense to approve a proposal to implement as is, but with an expiration of the module in 18 months, for example. Osmosis would benefit now and Duality would know what liquidity it needed to attract to have a shot at taking over in 18 months. Win, win, win.
I expect that my fellow ATOM stakers will be able to zoom out and see the “grow the pie” value proposition of leading the way in coalescing the Cosmos around this already built module as the available standard implementation for chains to accomplish fee abstraction. We’re in the depths of the bear winter, lets take advantage of this time to polish on the interchain UX by deploying what’s been built!
Removing the friction point in the ‘new user journey’ of having to worry about native gas of each chain is a MASSIVE upgrade. I believe widespread adoption of Fee Abstraction would be an evolutionary leap in the improvement in the UX of new Cosmonauts as they embark on their exploration of the interchain ecosystem, regardless of which network on-boarded them.
If a module is developed to leverage liquidity within the AEZ for fee abstraction the Hub can migrate and champion it instead…but please, for the love of all things, can we not let pride, envy, or greed get in the way of advancing progressing towards a vision where users don’t even realize they’re not on a unified L1?
At least not until they go beyond the frontier and out into the harsh unknown at the absolute fringes of the Internet of Blockchains.
Lastly, I don’t think that it is possible to over emphasize the fact that this has already been developed and is ready to be deployed to solve a very real UX pain point!
I don’t see the need for urgency here. The UX issue has existed for years and will not hurt if it exists for a few more months.
Duality will exist. The module for the Hub will exist. Just give it about 3-6 months.
I would like people to see the bigger picture instead of thinking short term. What is the value prop for any consumer chain joining the AEZ ? If it is just ‘security’, that is a very poor offering and we are never going to be in a position to negotiate a good deal for the Hub while onboarding new consumer chains.
The main prop of AEZ should be that any chain joining the AEZ will have the full support of the Hub and its existing consumer chains
I expect Duality to launch in the next few months. Once it launches, how is it going to compete with the existing DEXs without the support of the Hub ? The best way to bring traffic to Duality is to ensure that this fee conversion happens within Duality. If Duality cannot even capture the conversions within the AEZ, it will be another dead chain with no traffic like the majority of the existing Cosmos chains
There is no rush here. It will be many months before any significant volume will happen in the AEZ. I doubt an interim solution is worth the trouble for the current low volumes.
Well, just to reiterate, if no suitable consumer chain DEX exists if and when this goes live, then Osmosis of course would be a great choice.
As for the “pools for each fee asset”, I’m not sure I understand. Uniswap v1, at launch, had pools for every asset, whether it existed or not. You would just supply liquidity for whatever asset pair you wanted, even if you had created both tokens a minute ago. Not sure what existing popular DEX designs look like today, but it doesn’t seem like a big hurdle.
I don’t think there are any Dexes that exist in Cosmos currently that handle listing this way. Of all of them, Osmosis is the most permissionless, but there are still a couple of minor dependencies I believe. I’m not sure how duality, for example, plans to handle this though.
At any rate, I agree that even with a couple extra hoops to jump though it wouldn’t be too big of a hurdle to create 20-30 pools with the various fee assets.
I understand the discussion about supporting the AEZ but id rather implement a solution now and have 6 month of on chain data instead of waiting for another DEX or Aggregator to go online and redevelop the module.
Made one more edit to the proposal to indicate that part of the reason for getting this module on the Hub ASAP is that it will make the onboarding UX much much easier for users coming over with ETH or USDC from Ethereum due to the upcoming metamask integration. This needs to be done before the integration goes live to make it as simple as possible for people to onboard using these assets.
There are a number of parameters that are configurable by governance (interchain query frequency, asset transfer frequency) but the choice of dex isn’t one of them.
For now, the Hub would have to roll a new module to switch the dex over to an AEZ dex or another dex (or chat w/ OGP and Notional about how best to accommodate this, potentially via an aggregation / multi-dex solution?)