You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
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
Use cases
Proposal
For Admin Use
The text was updated successfully, but these errors were encountered: