Open colin-axner opened 1 year ago
i think this is a pretty common use case and would be great to have!
in addition, it would be great to be able to add data to the callbacks from the initiator, that the receiver gets from the callback. for example, this is my callback design:
/// Executed on the callback receiver upon message completion. When
/// being executed, the message will be tagged with "callback":
///
/// ```json
/// {"callback": {
/// "initiator": ...,
/// "initiator_msg": ...,
/// "result": ...,
/// }}
/// ```
#[cw_serde]
pub struct CallbackMessage {
/// Initaitor on the controller chain.
pub initiator: Addr,
/// Message sent by the initaitor.
pub initiator_msg: Binary,
/// Data from the host chain.
pub result: Callback,
}
a use i can imagine in this is outposts where you want to:
to do this, the outpost needs to get a callback on the ics20 completion, and the initiator needs to include information (initiator_data
) in the callback to the outpost in step (2) saying what action to take (list/swap/whatever).
Summary
The initial implementation of
GetSourceCallbacksAddress
andGetDestCallbacksAddress
requires the sender/receiver to be the same as the source/destinations addresses specified in the memo for ICS 20This issue is to document discussion on whether/how to change that.
One possible solution is adding an optional boolean to allow a non receiver for the destination callback
Same suggestion could be true for the sender
For Admin Use