Conditional Packets

[womensrights]

Summary

Conditional packets enable a user to send an IBC packet containing a list of packet data for different applications, e.g. transfer and ICA, and the aggregate packet should execute atomically. For example if there was a transfer and ICA aggregate packet, both the transfer and following ICA message should succeed, if the transfer fails the whole workflow should be aborted.

Problem Definition

• Every ICA use case in production (Stride, Nolus, Quasar, Quicksilver, Pstake) requires the ICA to have tokens sent to it before executing an ICA message. There are a lot of packet round trips that must be completed before an ICA user can start sending ICA messages - the channel handshake to register the ICA, a transfer and finally the ICA message.
• Due to this complexity, the use of ibc-hooks and the memo field has enabled the most straightforward and easiest path for the general use case of transfer + action. ibc-hooks has mainly been used for transfer + swap - almost half of all the memo field usage is due to ibc-hooks (~99% of IBC txs are transfer, and ~40% of those are using memo, so ~20% are transfers using ibc-hooks).
• Using ibc-hooks also requires a chain to be using cosmwasm, only a subset of IBC enabled chains use cosmwasm.
• In theory, you could do the same cross-chain swap workflows using transfer + ICA, or any general transfer + action case, but it is significantly less usable in the current form is possibly why it is not really used for this use case.
• A disadvantage of introducing this feature is that reversion logic can introduce security issues.

Use cases

• Cross-chain swaps via ICA, this will be particularly powerful in combination with the transfer send-all feature, as the swap amount does not need to be queried given the slippage fluctuation will effect the amount of token received after the swap.
• Improved workflow for liquid staking providers - currently providers send native tokens which will be staked to an ICA and mint the liquid staked representation for users. This requires sending tokens and staking messages which would be made possible in a single packet round trip.

Proposal

• This feature could be enabled generically, but it seems the majority of use cases would be covered by just enabling conditional transfer + ICA, therefore I would not recommend a generic solution, especially if it requires more effort
• There are then three instances to cover: 1) when the transfer fails, do not proceed to ICA message execution, 2) transfer succeeds, ICA fails, revert transfer logic, 3) happy path: transfer succeeds, ICA message successfully executes afterwards.

---

For Admin Use

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

[colin-axner]

For design consideration here:

Conceptually, when processing a packet which has conditional ordering, a full RecvPacket flow for a single packet data should occur before we process the next packet. This should be fine with the port router refactor. The tricky part will be if after the first packet there is a failure. We will need to introduce an interface to revert receives on packet data's which had succeeded earlier in the chain of packet data's. This interface should look similar to what is already implemented in transfer