Giters

cosmos / gaia

Cosmos Hub

Home Page:https://hub.cosmos.network

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

UX: IBC forwarding for transactions

p-offtermatt opened this issue · comments

commented

Problem

A painpoint for consumer chains (and in general, chains in the ecosystem) seems to be getting atom tokens on their chain.
ATOM is traded on centralized exchanges, so it is a great asset to allow new users to interact with your chain.

Today, using atom to interact with an application on another chain has this user flow:

  1. The user finds an application they would like to interact with on the appchain
  2. The user buys atom on a CEX to interact with the application
  3. The user sends atom to their own wallet address on the Cosmos Hub
  4. The user bridges the funds over to the application chain
  5. The user can finally interact with the application

By building some sort of auto-forwarding mechanism, we could make 4) happen without extra user input.

Possible solutions

Memo field

We could use the memo field of transactions.
The user flow would be to send their atom from the CEX to their wallet and provide their remote appchain address as part of the memo.
A new module would auto-forward messages with a certain memo to addresses on the remote chain.

Special accounts

Similar to the last solution, but we set up accounts that automatically transfer funds sent to them to a remote chain.
This would avoid having to use the memo field, and seems like slightly easier UX for users.

Closing criteria

We have decided whether we want to implement this feature, and if yes, an epic has been created to outline the steps needed for the implementation.

commented

This is pretty straight forward to implement with CosmWasm's MsgExecuteContract. You can send funds along with an execute message. A contract on the Hub then receives those and internally emits MsgTransfers to forward the newly received token to a different place in the Interchain. Happy to build that for you if interested.

commented

By the way, the other way around is annoying as well. I can't send ATOM from Osmosis to a CEX directly because I can never trust those guys to be able to handle incoming MsgTransfers for depositing.

commented

This is pretty straight forward to implement with CosmWasm's MsgExecuteContract. You can send funds along with an execute message. A contract on the Hub then receives those and internally emits MsgTransfers to forward the newly received token to a different place in the Interchain. Happy to build that for you if interested.

That sounds awesome! One challenge is that I wouldn't assume CEXs let you do anything except for standard transfers with a memo field. In the design you have in mind, it seems we would need the CEX to issue a MsgExecuteContract, if I got that right?

commented

seems we would need the CEX to issue a MsgExecuteContract, if I got that right?

Right. However UX wise it would even be better if CEXs integrate it that way (pretty much USDC style):

  1. Select ATOM withdrawal
  2. Select chain from a list of well known supported chains
  3. Insert destination address and check for chain-prefix mismatch

The CEX might need to call a contract, but at least they still only need to interact with one RPC and pay fees in ATOM. Adding more and more networks would be very easy.

Now one could argue that the CEX can send a MsgTransfer directly. A CosmWasm based solution has the following benefits:

  • In-state audit log of each transfer
  • Retry in case of a timeout1
  • Maintaining the channel configuration in the contract (i.e. send to "osmosis", not "channel-141")
  • Use PFM route when needed
  • Set and subsidize IBC fees as needed2

1 Requires IBC callbacks shipped in CosmWasm 2.1
2 Native ICS-29 support planned for CosmWasm 2.2 later this year

commented

Yeah, these are great reasons to prefer CosmWasm, I agree. However, seems it would need a bit more work from the CEXs to integrate this and I'm not entirely sure how willing they are to do this work.

I like the memo/account-based forwarding solution because it requires absolutely no new integration from the CEX other than them sending transfers which they already do.

I think the simple forwarding solution is pretty easy to do, but it does have much worse UX, so it seems like a tradeoff. Long-term, having both might be the way - CEXs that do the work of integrating the CosmWasm forwarder have much better UX, but users can still use whatever basic forwarding method we use even with CEXs that don't.