Skip to main content
This page highlights some of the differences between IBC v2 and IBC classic relevant for the callbacks middleware and how to use the module with IBC v2. More details on middleware for IBC v2 can be found in the middleware section.

​
Interfaces

Some of the interface differences are:
  • The callbacks middleware for IBC v2 requires the Underlying Application to implement the new CallbacksCompatibleModuleV2 interface.
  • channeltypesv2.Payload is now used instead of channeltypes.Packet
  • With IBC classic, the OnRecvPacket callback returns the ack, whereas v2 returns the recvResult which is the status of the packet: unspecified, success, failue or asynchronous
  • api.WriteAcknowledgementWrapper is used instead of ICS4Wrapper.WriteAcknowledgement. It is only needed if the lower level application is going to write an asynchronous acknowledgement.

​
Contract Developers

The wasmd contract keeper enables cosmwasm developers to use the callbacks middleware. The cosmwasm documentation provides information for contract developers. The IBC v2 callbacks implementation uses a Payload but reconstructs an IBC classic Packet to preserve the cosmwasm contract keeper interface. Additionally contracts must now handle the IBC v2 ErrorAcknowledgement sentinel value in the case of a failure. The callbacks middleware can be used for transfer + action workflows, for example a transfer and swap on recieve. These workflows require knowledge of the ibc denom that has been recieved. To assist with parsing the ics20 packet, helper functions can be found in the solidity-ibc-eureka repository.

​
Integration

An example integration of the callbacks middleware in a transfer stack that is using IBC v2 can be found in the ibc-go integration section