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.
Thank you Notional.
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.
tl;dr:
Or
While this is an amazing module that Iâm sure plenty of chains will enjoy, Iâd prefer the volume and swaps to go through a DEX aggregator for DEXs within the AEZ.
AADAO could/should give a grant out for someone to build this, or negotiate with Osmosis over the license of this module to make it so volume isnât just given to Osmosis.
That said, there is no DEX with the liquidity and depth of Osmosis at the present time.
That saidâŚweâre talking about literal dust at the present moment and Iâm sure we could wait until a module just for AEZ is built out and for DEXs in AEZ to gain liquidity.
I am open to adding FA module if there is really that big of a demand to autoswap all the AEZ dust into ATOM in the meantime though.
Seems ok in general. The licensing is a bit of a stick in the wheels there.
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 changed the on-chain date for this to August 02 to allow for a bit more discussion time! Want to make sure everyone who was in Paris has time to read through this and give feedback.
In favor of implementing this.
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 is somethings we can agree on. lets try something with duality or neutron.
can you promise to make a new proposal if some solution is possible within the AEZ in future.
I think that specifics of the moduleâs settings (like what DEX it uses) will be configurable by governance, right @RoboMcGobo ?
i donât think so
âSomeone else would also have to build a brand new module from scratch since the fee abstraction module is only licensed for use with Osmosisâ
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?)
This is live now! Thank you to everyone who gave feedback on this!
While the proposal is up for voting, Iâm happy to continue answering questions or clarifying any aspect of the proposal.
Is this module a made for Cosmos Hub only kind of module? Or itâs general for all chains to implement it?
What would happen to the module if it was rejected by the governance?
The module is extensible to any cosmos SDK chain. This will be implemented on other chains, regardless of what happens with the Cosmos Hub vote.