CHIPs discussion phase: Use staked ATOM for gas on every Cosmos chain

Just wanted to write up an idea that me and @Noam brainstormed. Not sure if it’s been thought of before.

TLDR: Use your staked ATOM on any Cosmos chain to pay for gas. No transferring tokens over IBC for gas either. Just do stuff on other chains, and then your gas fees are deducted from your staked ATOM balance on the Hub.

Even as an experienced Cosmos user, managing gas on a lot of different chains can be a headache. You’ve got to transfer it over, make sure its in the right token, and then you can sometimes run out and be stuck if, for example, you staked or locked all your tokens.

An oft-requested feature for the Cosmos would be for users to only have to worry about one gas token, no matter what chain they are on. This is the UX in monolithic ecosystems such as Ethereum and Solana, and it is what users mostly prefer. There have been initiatives to encourage chains to use ATOM as gas token before, based on talking to chain’s dev teams and convincing or inducing them to add ATOM as a gas token option by upgrading their chain’s code. These efforts never really made a big impact since it is a very slow process to do this outreach. Also, even if a chain supports ATOM as a gas fee, users still have to transfer it over before they can use it, adding UX overhead.

What would really accelerate the usage of ATOM is if it was possible to use ATOM as a gas token on any Cosmos chain, without any integration or buy-in needed from the chain’s team. What would be even better is if you could do this without having to actually transfer the ATOM over to the other chains. And it would be great if you could do all this without even unstaking your ATOM.

Fortunately all of these things are possible using a combination of two Cosmos technologies: FeeGrant and Interchain Accounts.

FeeGrant
FeeGrant allows one account on a Cosmos chain to give a gas allowance to another account. The account receiving the grant can make transactions, with gas paid for by the granting account.

Interchain Accounts
Interchain Accounts (or ICA) allows one chain to control an account on another chain. For example, ICA could allow the Cosmos Hub to have its own account on Kujira.

How it could work
A new module (or smart contract) on the Cosmos Hub would establish an ICA account on every Cosmos chain of note, and load these accounts up with each chain’s gas token.

When a user opted into the universal ATOM gas system, the ICA accounts on the chains would issue feegrant transactions to the user’s accounts on each of the other chains. The total amount of feegrants could not exceed a user’s staked ATOM balance on the Hub.

When the user goes on one of the other chains, they can instantly make transactions without worrying about fees, since the feegrant covers it.

Periodically, the Cosmos Hub would query the other chains to see how much of the feegrant each user had used. The equivalent amount of ATOM would be deducted from the user’s staked ATOM balance on the Hub. If the feegrant on any of the chains was getting low, it would be added to, possibly by removing feegrant on a chain that the user did not transact on.

Challenges
The hardest part about this is deciding how much of a feegrant to do to each user on each chain. A user cannot be given feegrants exceeding the amount of their staked ATOM, since this could lead to the Hub losing money. If a user had 10 ATOM staked, perhaps they could be given feegrants of the equivalent of 0.1ATOM on 100 top chains. The challenge here is that a big part of the UX benefit is for the user not to worry about whether or not a given chain is covered, so it’s best if the grant happens without them having to initiate it. Rebalancing will also be necessary. Even if a user starts out with an even distribution across many top chains, as they use any given chain more than the others, feegrants on the unused chains will need to be decreased so that the heavily used chain’s feegrant can be increased.

UX for what happens if a chain that a user wants to use does not have a feegrant for them also needs to be handled. Technically, this is not complex. The Hub’s logic just needs to know that a given user needs a feegrant increase on a given chain. What’s tricky is to figure out where to do this in the UX.

Perhaps the feegrant can be automatically increased attempted transaction with an out of gas error is observed, and the user can then try the transaction again.

14 Likes

Love this idea, I’d advocate for some sort of accelerated mvp or pilot to prove out this idea. Solid grant idea.

The Cosmos Hub focusing on solving gas UX for cosmos users is a powerful idea. Seems like all the tools are here between feegrant and ICA, they just need to be stitched together. I am also curious what the UI/UX for someone opted in on this would look & feel like. Wallets would for sure be key integrators of this.

One idea for the initial allocations would be to predefine multiple different sets that could be opted into. Not sure how they could be broken down, but perhaps the users could help self identify the broad set of chains they are interested in having covered without much UX friction. Rebalancing mechanism needs a lot of thought too.

Overall, clever idea. Pumped to hear other folks give feedback on the idea.

3 Likes

for the GTM of Cosmos,this is useful

1 Like

I think it’s a good initiative for the hub, however, maybe I’m wrong but letting an ICA account manage stake on another channel still seems risky. I think it’s important to remember that Atom should remain a blocked capital, utility cases and modules should be limited to the bare minimum, maybe this sounds like a more conservative political idea, but in my opinion, these risks should be taken by a consumer chain.

1 Like

I think we need to remove the lsm

I have no idea why anybody would want to more deeply in bed Israeli pagers into the ecosystem. It’s insane! The fact that people like me who worked on the LSM were not told that it was built by North Koreans is insane. I would have deleted every single line of code.

This is brilliant! I have been chatting about this with friends in ATOM OG Price chat, and one of them told me that we can’t really tax IBC since it’s open source, else other new tax less versions will pop up

I like the idea, that would bring back and accrue value to ATOM holders, stakers, developers, validators and I believe if ATOM is rich, whole cosmos will be richer!

This is very important, to limit points of interaction for users, the conversion of random Cosmos coins to ATOM for gas fee must be automatic definitely

I would love to see this idea come to fruition

I have no idea technically how this going to be implemented, but make this happen guys :slight_smile: !!!

Hello,

first: great UX improvement!

My question may sound simple: How would staked ATOM be involved here?
The reason I’m asking is that I haven’t read anything about the unstaking period so I am not fully clear on how this could be approached with staked ATOM other than involving the LSM ?

2 Likes

This has nothing to do with the LSM

4 Likes

This is a valid concern, but I don’t think it will be an issue. I’ll go into more detail on what happens to the staked ATOM. Let’s call the this module UniversalATOMGas for the sake of this discussion.

  • UniversalATOMGas lives on the Hub, and creates an ICA account on Kujira.
  • These ICA accounts give gas allowances to user accounts on these chains, in Kujira’s gas tokens.
  • A user uses this gas on Kujira, and UniversalATOMGas sees this with an interchain query, and deducts from their staked ATOM balance on the Hub.
  • The UniveralATOMGas module would need an integration with the staking module to accomplish this.

In my mind, a lot of the concern around doing stuff with staking is that someone can get around the unbonding period. For example one of the (justified) criticisms of the LSM is that an attacker could unload all their LSM shares on the market and then do an attack without caring if those shares got slashed, since they had already been sold.

In this case, a similar attack might be if an attacker was able to withdraw all their staked ATOM immediately with some gas fee shenanigans. For example, maybe they run a validator on Kujira, and they pay a huge gas fee to their own validator to get the money out. This does need to be avoided.

One good way to do this would simply to limit the amount of staked ATOM that can be used in this system to some small percentage of the total bonded ATOM. This seems like it would work well.

5 Likes

I’ve seen too many cases of people staking all of their assets, so they won’t have enough tokens to pay fees for (un|re)delegating if their validator gets jailed, so I think having this would be quite useful.
I’d suggest allowing the user to choose between paying with staked or liquid ATOM, but generally I am all in.

2 Likes

User not only need to be able to opt in but also control how much they’re willing to delegate to UniversalATOMGas. I wouldn’t risk my entire staked balance for this but there are situations where I need 1-2 cent worth of another chains gas token. It just happened to be recently when I went to add dATOM on Mars and needed Neutron, I had to go trade OSMO and then transfer via IBC, very frustrating and time consuming.
I think the proper way to handle this situation is for every chain to use the token/coin being used to pay for gas though. If I’m on Osmosis trying to trade TRX then it should automatically use the TRX I have if I don’t have OSMO.
The next best thing would be having a token called GAS that is chain agnostic, You mint it with any native token, every chain accepts it, and they can burn or trade it for their native token.

Having ICA accounts on every chain that constantly have to be replenished, tokens having to be transferred out of staking, gas paying gas to be used in a transaction with the users wallet, etc all sounds like 3x-4x more gas being used. The only way that works is if the person pays a premium to use it which in a pinch may be okay but will never see widespread usage.

I’d like the ability to fund my wallet with a few cent of every chain or the ones I choose in a single transaction without paying swap fees for every single one, then paying gas and wasting time to transfer them all. Or just a simple faucet for each chain that can be used once for free, I just used a chain recently that had one but can’t remember which one.

I’m just not a fan of messing with staked assets, I don’t even fully agree with having the LSM. I think there has to be a better solution than using staked ATOM.

4 Likes

I share the same view about LSM, not the biggest fan of exposing my stack to leverage or additional risk on top of smart contracts and wallet maintenance

Polaris is actually solving this issue

Also having another coin to make gas payments further dilutes and fragmentizes demand and/or focus from ATOM, so what Jehan is suggesting is best of two worlds - accrue value to ATOM through the technology we have in Cosmos

I like the idea to have opt in choice of how much ATOM we risk to gas payments, instead of exposing full stack, we can choose 5 to 10 to 20 ATOM that can be utilized for gas payments with further increase of the cap in future if necessary

2 Likes

This wouldn’t add any demand to $ATOM IMO b/c it uses staked $ATOM that people don’t want to liquidate. The only time it would be useful would be in a pinch, it’s not like people would use it as their main gas option. People generally only use a few chains in IBC and usually keep the native token for the ones they use, this would be one of those tools for chains you rarely use or if you screwed up and staked 100% without leaving gas money. I could be completely off in my assessment though. If this is meant to be something people would choose to use for every transaction then I would need to hear how it would be cheaper than just having native tokens for common chains already in my wallet.

1 Like

This is an important point. The gas involved would be the cost of one feegrant transaction for a user on every covered chain to start. Since we’d want popular chains to be covered without the user having to take an action, this could add up. However, gas on Cosmos chains tends to be very cheap (<$0.01 per tx) and the UX benefit is pretty good, it might be worth it.

The other option would be to have the user visit a dashboard to initiate, and maybe autoselect the top 20 chains, plus let them select others. This is a little bit less of an elegant UX and requires the user to do some work so I don’t like it as much.

1 Like

This is fair. Given that chains are already trying to get their users to use their token for something else, there’s a good chance that a user would already have the token if they were using the chain at all. For example, bidding in STARS on Stargaze, etc., or just staking on that chain.

2 Likes

Hi @jtremback, thanks for initiating the discussion.

I see few issues that I would like to address, and potentially offer a solution:

  1. Using staked ATOM

I personally would not be comfortable with having any process (except slashing) able to take some ATOM from my stake. I see it like a savings account, and I prefer any debit to happen from my current account, where I keep less money, for day-to-day use.

I suppose I’m not the only one feeling this way, so my suggestion will be to take from the liquid ATOM (though I understand I would need a bit more care to keep it from being empty)

  1. Complexity of rebalancing, capital inefficiency

The above described process requires the Cosmos Hub module to send tokens to chains even if they are not actually used, so that it’s ready to pay for fees when needed. It’s largely inefficient and complex as there needs to be an on-chain process to identify where tokens need to be replenished, then need to swap tokens from one chain to another, etc.
Also, it requires the Cosmos Hub to initiate ICA on multiple chains.

My suggestion here is to do the opposite:

  • all chains who want to offer this service need to accept ATOM as gas, and create an ICA on the Hub
  • a user could register (via its favorite wallet) which accounts on which chains are allowed to use its liquid ATOM for gas
  • when the user wants to do a tx on chain A, the wallet includes a request for feegrant referring to its account on Cosmos Hub
  • Module on chain A, via ICA, requests to lock the number of ATOMs required for the tx from the account
  • Upon success, chain A has X blocks to run the tx, then submit proof the tx happened to the Hub
  • chain A uses ATOM it would hold in the Community Pool to pay for the gas, executes the tx, and submits the proof to the Hub
  • upon receiving proof, the Hub releases the ATOM (same amount as what was used for gas) to the ICA, which in turn can refund the CP of its chain whenever required

This way, we only need the chains to be advancing the fees, and take back exactly what was used. A chain could even subsidise some txs by taking back less than what was used (or even nothing) if it helps with their purpose.
It’s maximum efficiency, and the implementation is not too complex, but it does require wallets like Keplr, Leap, to integrate this feature.

The main drawback I see is that the user would need to ensure there’s always enough ATOM in its wallet to pay for fees (we should also make sure that the process always leaves a minimum amount of ATOM in the wallet). However, it also gives more control.

It brings value for ATOM, and aligns chains who will have ATOM in their Community Pool.

Do you see any issue with this solution?

Regards,
arlai

7 Likes

Improve user experience while simultaneously giving incentive to stake and creating more demand for ATOM? YES VOTE FROM US.

Jehan, thank you for all you’ve done for the Hub and for going out strong with another great idea.

I hope whatever team steps in for Informal continues to scour all of crypto to find clever ideas to implement on the Hub. MESSAGE!

1 Like

would not be comfortable with having any process (except slashing) able to take some ATOM from my stake. I see it like a savings account, and I prefer any debit to happen from my current account, where I keep less money, for day-to-day use.

Fully agree with this ;

I find arlai-mk design much more elegant in every ways.

3 Likes

First off: HELL YEAH

I agree with @arlai-mk regarding the use of a staked balance – I’d be somewhat uncomfortable with that as well.

His solution also seems indeed more efficient from the capital perspective, with a couple caveats:

  • might be a little complicated for the users if they need to enable each chain, vs a “blanket” activation of this universal gas system for all supported chains.
  • it would actually depend on the other chains upgrading to add this module and basically allowing the Hub to provide this service, whereas with @jtremback’s implementation they just need to support ICA and implementing the solution does not require their approval. This might lead to a fragmented support / delayed adoption, as some chains don’t upgrade often.
    Nevertheless it might be best that the Hub provides this as an opt-in service instead of just imposing it to everyone. That’s up for debate I guess.
2 Likes