Receive callback on ics-20 ack/timeout

[alpe]

Example:
Contract A on chain X sends an ics-20 transfer to chain Y. On ack/timeout the contract gets a callback when the ack/timeout is processed back to chain X.

Ideally this should work with other IBC app level messages, too.

Some useful data for the contract would be:

• packet sequence
• packet type: ics-20,...
• operation: timeout or ack
• success or failure
• the contract may want to loop some metadata

Not sure if raw packet or ack data should be added.

I assume that we may need a new ibc message to return to handle this scenario differently than classic ics20 messages. Probably with a new entrypoint for the callback.

The IBC part can be implemented in wasmd with some additional middleware. There needs to be some way to prevent random ics-20 messages to call the contract callback.

This is inspired by adr-8

[alpe]

I was thinking today, that a popular ibc use case is nice start but a more generic approach would bring us in a much better position.
We should aim to support any custom or official protocol and let the contract handle the data on ack/ timeout itself. There can be support in the stdlib for data convertions like ics-20 but that would be a nice to have step.
A new endpoint for contracts would make sense so that they can receive the callback.
The ibc-go callback provides the following data:

• packet channeltypes.Packet,
• acknowledgement []byte,
• relayer sdk.AccAddress,

The next question would be: how a contract can opt in to receive callbacks for certain packages?

Analogue to the ics-29 fees message, we could have a "un-/registerIBCCallback" Msg that can contain the package ID. Another option would be a "wildcard" for a sourcePortID, sourceChannelID pair. Or we support both

[webmaster128]

Can this be closed if we do #1938?

[alpe]

yes, I had opened this to support ADR-8 use cases