[Voting Period] Signaling Proposal: Add the Fee Abstraction Module to the Cosmos Hub

Signaling Proposal: Add the Fee Abstraction Module to the Cosmos Hub Summary This is a signaling proposal to add the Fee Abstraction Module to the Cosmos Hub. At a high level, the module will allow for transaction fees on the Cosmos Hub to be paid with any token by first swapping that token for ATOM on Osmosis. The function of the module will be outlined in more detail below. The fee abstraction module was developed by the team at Notional , and funded by the Osmosis Grants Program , as a method of solving fee abstraction issues that currently plague the Cosmos Ecosystem and hinder adoption from external ecosystems. The module solves for this by allowing fees to be paid in any asset on chains that implement it without requiring that chain to change its accepted fee assets. This proposal is merely a signaling proposal and will not result in any immediate changes to the Cosmos Hub if passed. The module will need to be added via a subsequent software upgrade requiring an independent vote. If this vote passes, the Notional team will assist the maintainers of the Cosmos Hub codebase with integration as needed and help solve any technical challenges that may be encountered in…

Excerpt (1197 of 7122 characters). Read the whole post on the forum ↗

hey

this module enforce the use of osmosis as fees tokens’ exchange platform, right?

if so, i’m against this proposal.

it would be better the hub funds and integrates a similar module functioning with a consumer chain exchange, hi Duality, and eventually reap the flow rewards inside the AEZ rather than let them go.

tom:

it would be better the hub funds and integrates a similar module functioning with a consumer chain exchange, hi Duality, and eventually reap the flow rewards inside the AEZ rather than let them go.

Duality won’t support the same variety of assets that Osmosis does for a very long time, if ever, so that solution would result in much less buy pressure on ATOM.

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. That might not be done for a very long time, if ever.

Duality won’t support the same variety of assets that Osmosis does for a very long time, if ever

how do you know that?

That might not be done for a very long time, if ever.

in how many time Notional has developed this module?

it’s a good short term solution for the hub, some people are currently pushing for an UX improvement, and i suppose that’s why this proposal is coming now, but it would be a very very bad long term decision imho.

also i guess if Osmosis licensed the module that way it’s because it’s somehow a good revenue vehicule.

The module was licensed because Osmosis Grants (and thereby the Osmosis community pool) paid for the module’s development.

Since the Osmosis community paid for this, we were sensitive to having the community fund the use of the module in a way that doesn’t return some value to that community. The revenue potential of the module isn’t known yet, as it hasn’t been deployed anywhere.

If this is a good short-term UX solution, why not implement it? There’s nothing stopping the Hub from rolling their own solution and switching to that in the future. But why not implement it now and drive additional value to the ATOM token until such a solution has been put in place?

good point!

even if it would be so much easier and time/funds saving if the license was less restrictive.

i’m a naive idealist who thought we were all fighting for open software in here.

imagine if all the things Atom community have funded these past years were licensed that way, i guess there would exist a lot less chains in the Cosmos space.

invest in both osmosis and hub and accept this prop its a win win

My initial understanding was that this covers all IBC transactions. If it is for just the AEZ, then this is a strict ‘No’ from me.

The Hub can no longer remain neutral. It should support the DEX that brings highest value to $ATOM. In Hub’s case, that DEX is Duality.

Use community pool to develop this same functionality in the Hub to use Duality to do the token swap. Short term pain for long term gain. Else we will be permanently giving Osmosis an edge over Duality.

The hub should do everything in its power to give the consumer chains an edge over every other chain in Cosmos. That should be the value prop for joining the AEZ - join the hub and get its full backing.

Duality does not exist right now.

Osmosis does, has liquidity, a wide array of assets, and a working fee abstraction module.

If the Hub wants to, it can switch to a different module, once one exists

This would have to be a no from me. Abstracting away the ownership of ATOM within the AEZ? This is a presented as a meme of growth but offers little to the hub except allowing people to not own any ATOM. Lets wait for Duality or someone formally aligned. Credible neutrality is dead. Long live the hub.

Hey Ranger!

The plan here is definitely not to abstract ownership of ATOM away within the AEZ. What this module does is quite the opposite.

It ensures that fees can be paid in any asset on the Hub, but at the same time does so in a way that ensures it gives ATOM an increased value proposition by having all non-ATOM fees be swapped to ATOM. This actually puts additional buy pressure onto the ATOM token without taking any existing value away from the Cosmos Hub which is pretty neat!

There may be a future in which we would want to have those swaps occur on Duality instead, after they build their dex and a similar module, and I’m very supportive of that! But this module would put buy pressure on ATOM as soon as it gets implemented without the need to wait. Given that the Hub could very easily switch to Duality for such swaps later on once it has grown, I don’t see the downside of implementing this module until that time.

The IBC Dilemma

Over the last few days, discussions have reignited about whether ATOM should be the default or base currency for all Inter-Blockchain…

Reading time: 4 min read

read this idea

sunnya97:

Duality does not exist right now.

Osmosis does, has liquidity, a wide array of assets, and a working fee abstraction module.

If the Hub wants to, it can switch to a different module, once one exists

Osmosis is THE DEX currently, obviously. at a point it’s fair to wonder why this restrictive licensing even exists.

anyway

has someone made some projections/expectations/stats about the swap fees revenues this module on the hub could generate for Osmosis?

I don’t perceive any issues in aligning with osmosis initially for a specific duration. In the future, the hub could potentially utilise fee abstraction to facilitate more advantageous terms with a consumer chain.

Ranger_Ranger:

Credible neutrality is dead. Long live the hub.

Credible neutrality never existed, but I think that’s another conversation another time.

I don’t see this as being about being credibly neutral but instead about solving a very real UX issue, without any friction.

liquidity lives on a gradient, and for let’s say at least the next year, I believe that there’s going to need to be a blend, and by the way that blend may exist forever.

I also believe that osmosis brings enormous talent and creativity. Furthermore, the hub team brings enormous talent and creativity.

Therefore, it’s my belief that it’s really not that hard to use the reality of the liquidity gradient, in some places swaps are better, due to the presence or lack of liquidity, or the existence were not existence of a pool.

We probably shouldn’t look at this as something that is either osmosis or duality or astroport, forever. We should probably look at this as a really really great way to start dealing with the tough UX issue of ‘oh my God I don’t have XYZ asset to pay the fee.’

tom:

at a point it’s fair to wonder why this restrictive licensing even exists.

Oh that’s really quite simple, osmosis invested in the development of this module.

I do think it’s quite sensible to negotiate.

Seems ok in principle to me.

I also don’t have a problem using Osmosis if there is no consumer chain DEX by the time this makes it onto the Hub, but I will say that we should strongly prefer a consumer chain DEX once there is one, even if it is small and has lower volume than Osmosis. Due to the application (using dust for TX fees), slippage will not be as big of a deal, and helping bootstrap a consumer chain DEX will be better for ATOM than getting slightly better deals on tiny TX fees.

jacobgadikian:

Oh that’s really quite simple, osmosis invested in the development of this module.

I do think it’s quite sensible to negotiate.

does that mean since the hub’s community invested heavily in Notional, Notional should be licensed in a way they work only for the hub?
(kidding. kind of.)

Agree re: vertical pool depth, but I think the concern is more in diversity of assets (i.e., horizontal depth). There will certainly be a fair number of assets supported by Osmosis that won’t be supported by a consumer chain dex in significant depth, especially at the outset of that consumer dex’s lifecycle.

Maybe a mid-long term solution is to have the module allow for both, have a preference for the consumer dex and default to Osmosis for other unsupported assets

Though this would have to be something that could be negotiated down the line between the relevant communities.

Im struggling to see any benefit to adding this to the hub when the only thing to do on the hub is stake ATOM. You cant stake ATOM without ATOM.

This removes ATOM as the currency you keep your on chain value in, and turns it into to keep on an as needed basis. Transaction fees are minimal across Cosmos. If people cant keep 1 ATOM. NGMI

RoboMcGobo:

Agree re: vertical pool depth, but I think the concern is more in diversity of assets (i.e., horizontal depth). There will certainly be a fair number of assets supported by Osmosis that won’t be supported by a consumer chain dex in significant depth, especially at the outset of that consumer dex’s lifecycle.

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.

jtremback: 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. 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: RoboMcGobo: Maybe a mid-long term solution is to have the module allow for both, have a preference for the consumer dex and default to Osmosis for other unsupported…

Excerpt (1195 of 1317 characters). Read the whole post on the forum ↗

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…

Excerpt (1199 of 1397 characters). Read the whole post on the forum ↗

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…

Excerpt (1195 of 1262 characters). Read the whole post on the forum ↗

tl;dr:

• Use FA module until a DEX aggregator/Duality centric module is created to keep volume/swaps in AEZ (if it is even planned to)

Or

• AADAO fund buildout via grants program since we just have dust and not that much liquidity to quibble over right now anyways.

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.

RoboMcGobo:

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?

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.

jtremback:

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.

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.

I think this is reasonable.

We would love to have a similar module when Duality is live but until it is, I think if it would drive more activity to the Hub it’s worth an integration.

Also worth doing a similar thing with Astroport.

If this is deemed a valuable feature overtime we can do some more analysis on how much value each chain gives in fees and MEV and customize the routing algorithm accordingly.

with a mean time of 4 blocks by IBC transfer,
with 4 transfer to be done in the example
with a block time of >5sec

=> we need >20 seconds to get the 0.00001 ATOM of alternative asset to return to the wallet

This will cost 3 Tx per transfert => 12 Tx
In definitive, this will cost more to the relayers than the real value of the swaps done

Hi @David_Crosnest ! Thank you for sharing this concern.

Fees are batched in the module and only sent over once per hour to be swapped to prevent this exact issue. The value of the transactions involved to the relayer is negligible in comparison with the amount of fees that accumulate from an hour’s worth of transactions on the Hub.

Under this mechanism, fees in non-ATOM assets would be swapped to ATOM and then paid to Hub validators / stakers hourly. fees paid in ATOM that don’t require these transfers will continue to be paid out as normal.

Do you have a rough value of the numbers of asset accumulated per hours ?

What’s about the ICS retributions.
We “asked” the security to be provided against a given % of inflation/fees/…
Will this asset will be swapped as well ?
In the case of Stride, this will create a 50% of inflation selling pressure on the token and push the price to zero.

Re: your second point, definitely not!

ONLY fees paid out by users as Cosmos Hub transactions will be subject to the parameters of this module. Inflation or fees from other sources (such as ICS) will not be subject to this. Users would be free to use their ICS rewards to pay fees on the Hub (which is one of the benefits of this module), but only if they wanted to. It would not amount to a forced sale of any ICS revenues.

As far as the numbers, I don’t have this yet because the module isn’t live, but I think we could probably make reasonable estimates by taking the number of transactions that occur hourly on the Cosmos Hub, assigning a reasonable percentage of those transations that would be paid in other assets after the module gets full traction (10-25%?), and estimating the average ATOM those tx fees would cost to get the aggregate numbers.

OK,

10-25% ? I think you are very generous. in my opinion you can divide by 10 minimum

To have user using alternate currency for transaction, the UI/Wallet will need to push in the use of this assets.
The default currency will remain the main one by far.

knowing the amount of alternate tokens used right now must be part of the decision and I understand you don’t have this value.

I agree that ATOM will remain the primary fee asset. Am unsure of the exact percentage of alt-assets that will be used, but I also think it’s inaccurate to compare this to the number of alternate assets that are used now.

Thanks to this module, wallets and front ends will be much more amenable to having front end options to pay in other fees (especially Keplr, which already has this option available for other chains). Once a wallet opens this capability up, fees paid in non-ATOM assets will increase substantially.

Just seeking tax clarification here: The alternate asset swap is happening on the chains side not the consumers side correct? So that the disposal of the token is not a double (or possibly triple) tax reporting event for the consumer?

I.e. if spending Neutron on an Atom fee swaps the Neutron in my possession for Atom then pays the fees I will have a disposal an acquisition and a disposal per transaction for the IRS. Whereas if the Neutron is accepted as payment for the fee from the consumer there is only one taxable event, the disposal of the Neutron. Most Crypto-IRS software charges per event (usually 100 events, 1000 events etc, as pricing break points). If paying a fee utilizes 3 events for tax purposes this will add up fast for the consumer. And in effect becomes quite expensive. The tax calculation charge will likely greatly exceed the chains transaction cost, but is ultimately just as imperative to the consumer. Consideration of consumer costs should always be at the forefront of these types of discussion.

I’m not qualified to give you assurances or advice on tax status, but I can tell you that from the user / fee payor end it looks like this:

• User pays fee asset to the Cosmos Hub. At this point, the fee asset is 100% entirely out of the user’s ownership and control and will never be in that user’s ownership and control again, just as it happens with ATOM fee payments now. Accordingly, any subsequent swapping will also not be reflected as a transaction in that user’s wallet.
• The fee asset sits in the module for up to an hour, along with everyone else’s accumulated fee assets that have been paid to the chain before being sent to Osmosis
• Any path unwinding / fee swapping occurs and the resulting ATOM are sent back to the Cosmos Hub
• The ATOM is paid out to Cosmos Hub validators and their delegates as normal.

Based on that flow, I think it’s pretty clear what the tax results (or lack thereof) would be, but if this is a huge concern for you I would always advise consulting with a tax expert in your jurisdiction to ensure you have 100% clarity.

Thank you for the reply and clarification. As long as the swapping is occurring after the payment has been processed it should work as you stated as far as I understand it. Tax costs and tax calculation costs are always a huge concern for me, and should be for anyone engaging the chain. The onus of the extra taxable events should be on the chain then and not on the consumer as far as I can interpret the process as you’ve described it. That is ideal and significantly reduces the costs associated with engaging the chain for the consumer.

Yeah no problem!

I tend to agree with you that the tax issue here is pretty clear cut, but I don’t want to be on the hook for giving tax advice that ends up being wrong

That’s why i always tell people to consult with experts on these topics.

Glad I could help clarify though!

I think this proposal is the most useless proposal ever, even among those from notional…

problems

• unnecessary complexity of design
• risk associated with codebase on Osmosis, which cannot be controlled by Hub
• slippage risk on minor tokens
• credible neutrality of Cosmos Hub

very simple alternative

• periodic auction of non-atom gas fee basket

I have no idea why people are wasting time on this…

Always appreciate the colorful feedback from the B-Harvest / Crescent Dex team

Hey, do you have a design for this simple alternative? This auction stuff could be interesting.