Write tests for different sdk.Messages (TrySendTx)

[seantking]

Summary

At present, we are only testing if bank msg send can be executed as part of the TrySendTx flow. See here.

At a minimum, we should write unit tests that cover the execution of all the SDK messages required as part of our initial user stories/use cases.

Required messages (likely to be updated):

• Staking module
  • Delegate
  • BeginRedelegate (ibc/testing only includes a single validator)
  • Undelegate
• ics20 transfer

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[seantking]

@charleenfei can you share the user stories once you have written them (happy to help with this). We need to ensure that the teams planning to use this at launch are covered (what SDK messages are they planning to execute?).

[seantking]

@colin-axner Am I correct in assuming that some of these tests will eventually need to live outside of the ibc-go repo. If say we want to test the groups module, or liquidity pools (likely something that we should test for) we'll need to do this in the interchain-accounts repo I suppose.

[charleenfei]

@charleenfei can you share the user stories once you have written them (happy to help with this). We need to ensure that the teams planning to use this at launch are covered (what SDK messages are they planning to execute?).

I still need to follow up directly with these teams to get a latest update on these stories, but as it is so far, a sample first three:

Injective X Band Chain
Currently, Injective sends an IBC tx to Band Chain via their custom IBC oracle module, which is a data request. When this IBC packet is executed on Band Chain, validators on Band Chain fetch prices for 10 different markets. A random selection of validators will post this selection on-chain. Once a minimum quorum has been reached, an IBC packet is sent to Injective. The roundtrip latency of this flow is around 30 sec when things go well (no packet timeouts or delays in validation).
However, Injective wants to minimise as much as possible the latency between real world price updates and price updates on Injective. They can simplify this two transaction flow to a single transaction using interchain accounts, in a use case where Injective opens an interchain account on Band Chain which would be able to pay for a continuous set of update transactions and maintain a standing request for the prices of markets, which would simplify the transaction flow to a single transaction, and introduce a simple flow to update the standing request if necessary.

Umee X Hub
Users on Hub would send their ATOM to Umee. In return, the user gets equivalent amount of Mi (sp?) tokens (token would be a form of liquid staking token), which could then be staked on the Hub, in some other liquidity pool, etc, in addition to other business logic which Umee could perform on behalf of the users in return for the ATOM.

Umee then stakes these ATOM tokens on the Hub on behalf of Umee (ATOMs get inflation rewards, etc). Without ICA, Umee would have to use validator controlled multisig, because for this flow Umee needs an account on the Hub which can be controlled externally in a decentralised way. This ICA registered on the Hub would then receive the staking rewards for the ATOM, figure out distribution back to Umee chain, and send back to the corresponding existing account on Umee.

Hub Custodial Services
The problem the cosmos ecosystem faces is fragmentation of services. A new chain goes live, they need to talk to custodial solutions and exchanges to integrate. Many exchanges and custodial solutions don't want to integrate 10s of chains unless paid in advance.

An alternative is offering the custodial service through the Hub. When a new chain goes live, through IBC the tokens are transferred to the Hub and custodial services can use the tokens from X chain that have been passed through the Hub. This means that the custodial service would just have to integrate with one chain, rather with X.

Using ICA, a service could be built in which a user sends tokens to an interchain account address on chain X, which corresponds to the registered ICA account of chain X on the Hub. This account would handle the token transfer to the Hub and then further on to the custodial wallet.

[colin-axner]

@colin-axner Am I correct in assuming that some of these tests will eventually need to live outside of the ibc-go repo. If say we want to test the groups module, or liquidity pools (likely something that we should test for) we'll need to do this in the interchain-accounts repo I suppose.

I'm ok with using messages from the SDK, but we don't want to be dependent on other SDK modules (otherwise updating SDK versions will become difficult). Based on how the code is structured, I'm not too worried on testing all messages. Testing that the messages are executed and perform expected functionality is something that can live at the integration test level above the relayers