diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js index a5841915b3b..f459a997da6 100644 --- a/docs/.vuepress/config.js +++ b/docs/.vuepress/config.js @@ -267,11 +267,6 @@ module.exports = { directory: false, path: "/middleware/ics29-fee/integration.html", }, - { - title: "End Users", - directory: false, - path: "/middleware/ics29-fee/end-users.html", - }, { title: "Fee Messages", directory: false, @@ -287,6 +282,11 @@ module.exports = { directory: false, path: "/middleware/ics29-fee/events.html", }, + { + title: "End Users", + directory: false, + path: "/middleware/ics29-fee/end-users.html", + }, ], }, ], diff --git a/docs/assets/fee-mw/feeflow.png b/docs/assets/fee-mw/feeflow.png new file mode 100644 index 00000000000..ba02071f4d8 Binary files /dev/null and b/docs/assets/fee-mw/feeflow.png differ diff --git a/docs/assets/fee-mw/msgpaypacket.png b/docs/assets/fee-mw/msgpaypacket.png new file mode 100644 index 00000000000..1bd5deb01fd Binary files /dev/null and b/docs/assets/fee-mw/msgpaypacket.png differ diff --git a/docs/assets/fee-mw/paypacketfeeasync.png b/docs/assets/fee-mw/paypacketfeeasync.png new file mode 100644 index 00000000000..27c486a6f82 Binary files /dev/null and b/docs/assets/fee-mw/paypacketfeeasync.png differ diff --git a/docs/assets/fee-mw/registerrelayeraddr.png b/docs/assets/fee-mw/registerrelayeraddr.png new file mode 100644 index 00000000000..29b01da9a7c Binary files /dev/null and b/docs/assets/fee-mw/registerrelayeraddr.png differ diff --git a/docs/middleware/ics29-fee/end-users.md b/docs/middleware/ics29-fee/end-users.md index 08857d21a37..0a2514e7722 100644 --- a/docs/middleware/ics29-fee/end-users.md +++ b/docs/middleware/ics29-fee/end-users.md @@ -8,7 +8,7 @@ Learn how to incentivize IBC packets using the ICS29 Fee Middleware module. {syn ## Pre-requisite readings -* [Fee Middleware](overview.md) {prereq} +- [Fee Middleware](overview.md) {prereq} ## Summary @@ -17,7 +17,6 @@ Different types of end users: - CLI users who want to manually incentivize IBC packets - Client developers - The Fee Middleware module allows end users to add a 'tip' to each IBC packet which will incentivize relayer operators to relay packets between chains. gRPC endpoints are exposed for client developers as well as a simple CLI for manually incentivizing IBC packets. ## CLI Users @@ -26,6 +25,6 @@ For an in depth guide on how to use the ICS29 Fee Middleware module using the CL ## Client developers -Client developers can read more about the relevant ICS29 message types in the [Escrowing and paying out fees section](../ics29-fee/msgs.md). +Client developers can read more about the relevant ICS29 message types in the [Fee messages section](../ics29-fee/msgs.md). [CosmJS](https://github.com/cosmos/cosmjs) is a useful client library for signing and broadcasting Cosmos SDK messages. diff --git a/docs/middleware/ics29-fee/events.md b/docs/middleware/ics29-fee/events.md index 04ab5b34cee..e0d2ccd471c 100644 --- a/docs/middleware/ics29-fee/events.md +++ b/docs/middleware/ics29-fee/events.md @@ -4,10 +4,12 @@ order: 5 # Events +An overview of all events related to ICS-29 {synopsis} + ## `MsgPayPacketFee`, `MsgPayPacketFeeAsync` | Type | Attribute Key | Attribute Value | -|-------------------------|-----------------|-----------------| +| ----------------------- | --------------- | --------------- | | incentivized_ibc_packet | port_id | {portID} | | incentivized_ibc_packet | channel_id | {channelID} | | incentivized_ibc_packet | packet_sequence | {sequence} | @@ -19,16 +21,16 @@ order: 5 ## `RegisterPayee` | Type | Attribute Key | Attribute Value | -|----------------|------------|--------------------| -| register_payee | relayer | {relayer} | -| register_payee | payee | {payee} | -| register_payee | channel_id | {channelID} | -| message | module | fee-ibc | +| -------------- | ------------- | --------------- | +| register_payee | relayer | {relayer} | +| register_payee | payee | {payee} | +| register_payee | channel_id | {channelID} | +| message | module | fee-ibc | ## `RegisterCounterpartyPayee` | Type | Attribute Key | Attribute Value | -|-----------------------------|--------------------|---------------------| +| --------------------------- | ------------------ | ------------------- | | register_counterparty_payee | relayer | {relayer} | | register_counterparty_payee | counterparty_payee | {counterpartyPayee} | | register_counterparty_payee | channel_id | {channelID} | diff --git a/docs/middleware/ics29-fee/fee-distribution.md b/docs/middleware/ics29-fee/fee-distribution.md index 9cf3a821a21..79f03792566 100644 --- a/docs/middleware/ics29-fee/fee-distribution.md +++ b/docs/middleware/ics29-fee/fee-distribution.md @@ -8,7 +8,7 @@ Learn about payee registration for the distribution of packet fees. The followin ## Pre-requisite readings -* [Fee Middleware](overview.md) {prereq} +- [Fee Middleware](overview.md) {prereq} Packet fees are divided into 3 distinct amounts in order to compensate relayer operators for packet relaying on fee enabled IBC channels. @@ -16,18 +16,22 @@ Packet fees are divided into 3 distinct amounts in order to compensate relayer o - `AckFee`: The sum of all packet acknowledgement fees distributed to a payee for successful execution of `MsgAcknowledgement`. - `TimeoutFee`: The sum of all packet timeout fees distributed to a payee for successful execution of `MsgTimeout`. -## Register a payee address for forward relaying +## Register a counterparty payee address for forward relaying + +As mentioned in [ICS29 Concepts](../ics29-fee/overview.md#concepts), the forward relayer describes the actor who performs the submission of `MsgRecvPacket` on the destination chain. +Fee distribution for incentivized packet relays takes place on the packet source chain. + +> Relayer operators are expected to register a counterparty payee address, in order to be compensated accordingly with `RecvFee`s upon completion of a packet lifecycle. -As mentioned in [ICS29 Concepts](../ics29-fee/overview.md#concepts), the forward relayer describes the actor who performs the submission of `MsgRecvPacket` on the destination chain. -Fee distribution for incentivized packet relays takes place on the packet source chain. -Relayer operators are expected to register a counterparty payee address, in order to be compensated accordingly with `RecvFee`s upon completion of a packet lifecycle. The counterparty payee address registered on the destination chain is encoded into the packet acknowledgement and communicated as such to the source chain for fee distribution. -If a counterparty payee is not registered for the forward relayer on the destination chain, the escrowed fees will be refunded upon fee distribution. +**If a counterparty payee is not registered for the forward relayer on the destination chain, the escrowed fees will be refunded upon fee distribution.** + +### Relayer operator actions? -A transaction must be submitted to the destination chain including a `CounterpartyPayee` address of an account on the source chain. +A transaction must be submitted **to the destination chain** including a `CounterpartyPayee` address of an account on the source chain. The transaction must be signed by the `Relayer`. -Note: If a module account address is used as the `CounterpartyPayee` it is recommended to [turn off invariant checks](https://github.com/cosmos/ibc-go/blob/71d7480c923f4227453e8a80f51be01ae7ee845e/testing/simapp/app.go#L659) for that module. +Note: If a module account address is used as the `CounterpartyPayee` it is recommended to [turn off invariant checks](https://github.com/cosmos/ibc-go/blob/71d7480c923f4227453e8a80f51be01ae7ee845e/testing/simapp/app.go#L659) for that module. ```go type MsgRegisterCounterpartyPayee struct { @@ -42,27 +46,34 @@ type MsgRegisterCounterpartyPayee struct { } ``` -This message is expected to fail if: - -- `PortId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators). -- `ChannelId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators)). -- `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)). -- `CounterpartyPayee` is empty. +> This message is expected to fail if: +> +> - `PortId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators). +> - `ChannelId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators)). +> - `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)). +> - `CounterpartyPayee` is empty. See below for an example CLI command: -``` -simd tx ibc-fee register-counterparty-payee transfer channel-0 cosmos1rsp837a4kvtgp2m4uqzdge0zzu6efqgucm0qdh osmo1v5y0tz01llxzf4c2afml8s3awue0ymju22wxx2 --from cosmos1rsp837a4kvtgp2m4uqzdge0zzu6efqgucm0qdh +```bash +simd tx ibc-fee register-counterparty-payee transfer channel-0 \ +cosmos1rsp837a4kvtgp2m4uqzdge0zzu6efqgucm0qdh \ +osmo1v5y0tz01llxzf4c2afml8s3awue0ymju22wxx2 \ +--from cosmos1rsp837a4kvtgp2m4uqzdge0zzu6efqgucm0qdh ``` -## Register a payee address for reverse and timeout relaying +## Register an alternative payee address for reverse and timeout relaying -As mentioned in [ICS29 Concepts](../ics29-fee/overview.md#concepts), the reverse relayer describes the actor who performs the submission of `MsgAcknowledgement` on the source chain. +As mentioned in [ICS29 Concepts](../ics29-fee/overview.md#concepts), the reverse relayer describes the actor who performs the submission of `MsgAcknowledgement` on the source chain. Similarly the timeout relayer describes the actor who performs the submission of `MsgTimeout` (or `MsgTimeoutOnClose`) on the source chain. -Relayer operators may choose to register an optional payee address, in order to be compensated accordingly with `AckFee`s and `TimeoutFee`s upon completion of a packet life cycle. + +> Relayer operators **may choose** to register an optional payee address, in order to be compensated accordingly with `AckFee`s and `TimeoutFee`s upon completion of a packet life cycle. + If a payee is not registered for the reverse or timeout relayer on the source chain, then fee distribution assumes the default behaviour, where fees are paid out to the relayer account which delivers `MsgAcknowledgement` or `MsgTimeout`/`MsgTimeoutOnClose`. -A transaction must be submitted to the source chain including a `Payee` address of an account on the source chain. +### Relayer operator actions + +A transaction must be submitted **to the source chain** including a `Payee` address of an account on the source chain. The transaction must be signed by the `Relayer`. Note: If a module account address is used as the `Payee` it is recommended to [turn off invariant checks](https://github.com/cosmos/ibc-go/blob/71d7480c923f4227453e8a80f51be01ae7ee845e/testing/simapp/app.go#L659) for that module. @@ -80,15 +91,18 @@ type MsgRegisterPayee struct { } ``` -This message is expected to fail if: - -- `PortId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators). -- `ChannelId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators)). -- `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)). -- `Payee` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)). +> This message is expected to fail if: +> +> - `PortId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators). +> - `ChannelId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators)). +> - `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)). +> - `Payee` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)). See below for an example CLI command: -``` -simd tx ibc-fee register-payee transfer channel-0 cosmos1rsp837a4kvtgp2m4uqzdge0zzu6efqgucm0qdh cosmos153lf4zntqt33a4v0sm5cytrxyqn78q7kz8j8x5 --from cosmos1rsp837a4kvtgp2m4uqzdge0zzu6efqgucm0qdh +```bash +simd tx ibc-fee register-payee transfer channel-0 \ +cosmos1rsp837a4kvtgp2m4uqzdge0zzu6efqgucm0qdh \ +cosmos153lf4zntqt33a4v0sm5cytrxyqn78q7kz8j8x5 \ +--from cosmos1rsp837a4kvtgp2m4uqzdge0zzu6efqgucm0qdh ``` diff --git a/docs/middleware/ics29-fee/msgs.md b/docs/middleware/ics29-fee/msgs.md index 7ab81cd9552..0003d5982ee 100644 --- a/docs/middleware/ics29-fee/msgs.md +++ b/docs/middleware/ics29-fee/msgs.md @@ -2,71 +2,89 @@ order: 3 --> -# Escrowing fees +# Fee messages + +Learn about the different ways to pay for fees, how the fees are paid out and what happens when not enough escrowed fees are available for payout {synopsis} + +## Escrowing fees The fee middleware module exposes two different ways to pay fees for relaying IBC packets: -1. `MsgPayPacketFee`, which enables the escrowing of fees for a packet at the next sequence send and should be combined into one `MultiMsgTx` with the message that will be paid for. - - Note that the `Relayers` field has been set up to allow for an optional whitelist of relayers permitted to receive this fee, however, this feature has not yet been enabled at this time. - - ``` - type MsgPayPacketFee struct{ - // fee encapsulates the recv, ack and timeout fees associated with an IBC packet - Fee Fee - // the source port unique identifier - SourcePortId string - // the source channel unique identifer - SourceChannelId string - // account address to refund fee if necessary - Signer string - // optional list of relayers permitted to the receive packet fee - Relayers []string - } - ``` - - The `Fee` message contained in this synchronous fee payment method configures different fees which will be paid out for `MsgRecvPacket`, `MsgAcknowledgement`, and `MsgTimeout`/`MsgTimeoutOnClose`. - - ``` - type Fee struct { - RecvFee types.Coins - AckFee types.Coins - TimeoutFee types.Coin` - } - ``` +1. `MsgPayPacketFee`, which enables the escrowing of fees for a packet at the next sequence send and should be combined into one `MultiMsgTx` with the message that will be paid for. + + Note that the `Relayers` field has been set up to allow for an optional whitelist of relayers permitted to receive this fee, however, this feature has not yet been enabled at this time. + + ```go + type MsgPayPacketFee struct{ + // fee encapsulates the recv, ack and timeout fees associated with an IBC packet + Fee Fee + // the source port unique identifier + SourcePortId string + // the source channel unique identifer + SourceChannelId string + // account address to refund fee if necessary + Signer string + // optional list of relayers permitted to the receive packet fee + Relayers []string + } + ``` + + The `Fee` message contained in this synchronous fee payment method configures different fees which will be paid out for `MsgRecvPacket`, `MsgAcknowledgement`, and `MsgTimeout`/`MsgTimeoutOnClose`. + + ```go + type Fee struct { + RecvFee types.Coins + AckFee types.Coins + TimeoutFee types.Coins + } + ``` + +The diagram below shows the `MultiMsgTx` with the `MsgTransfer` coming from a token transfer message, along with `MsgPayPacketFee`. + +![MsgPayPacketFee](../../assets/fee-mw/msgpaypacket.png) 2. `MsgPayPacketFeeAsync`, which enables the asynchronous escrowing of fees for a specified packet: - Note that a packet can be 'topped up' multiple times with additional fees of any coin denomination by broadcasting multiple `MsgPayPacketFeeAsync` messages. - - ``` - type MsgPayPacketFeeAsync struct { - // unique packet identifier comprised of the channel ID, port ID and sequence - PacketId channeltypes.PacketId - // the packet fee associated with a particular IBC packet - PacketFee PacketFee - } - ``` - - where the `PacketFee` also specifies the `Fee` to be paid as well as the refund address for fees which are not paid out - ``` - type PacketFee struct { - Fee Fee - RefundAddress string - Relayers []]string - } - ``` + Note that a packet can be 'topped up' multiple times with additional fees of any coin denomination by broadcasting multiple `MsgPayPacketFeeAsync` messages. + + ```go + type MsgPayPacketFeeAsync struct { + // unique packet identifier comprised of the channel ID, port ID and sequence + PacketId channeltypes.PacketId + // the packet fee associated with a particular IBC packet + PacketFee PacketFee + } + ``` + + where the `PacketFee` also specifies the `Fee` to be paid as well as the refund address for fees which are not paid out + + ```go + type PacketFee struct { + Fee Fee + RefundAddress string + Relayers []string + } + ``` + +The diagram below shows how multiple `MsgPayPacketFeeAsync` can be broadcasted asynchronously. Escrowing of the fee associated with a packet can be carried out by any party because ICS-29 does not dictate a particular fee payer. In fact, chains can choose to simply not expose this fee payment to end users at all and rely on a different module account or even the community pool as the source of relayer incentives. + +![MsgPayPacketFeeAsync](../../assets/fee-mw/paypacketfeeasync.png) Please see our [wiki](https://github.com/cosmos/ibc-go/wiki/Fee-enabled-fungible-token-transfers) for example flows on how to use these messages to incentivise a token transfer channel using a CLI. -# Paying out the escrowed fees - -In the case of a successful transaction, `RecvFee` will be paid out to the designated counterparty payee address which has been registered on the receiver chain and sent back with the `MsgAcknowledgement`, `AckFee` will be paid out to the relayer address which has submitted the `MsgAcknowledgement` on the sending chain (or the registered payee in case one has been registered for the relayer address), and `TimeoutFee` will be reimbursed to the account which escrowed the fee. In cases of timeout transactions, `RecvFee` and `AckFee` will be reimbursed. +## Paying out the escrowed fees + +Following diagram takes a look at the packet flow for an incentivized token transfer and investigates the several scenario's for paying out the escrowed fees. We assume that the relayers have registered their counterparty address, detailed in the [Fee distribution section](../ics29-fee/fee-distribution.md). + +![packet-flow-fee](../../assets/fee-mw/feeflow.png) + +- In the case of a successful transaction, `RecvFee` will be paid out to the designated counterparty payee address which has been registered on the receiver chain and sent back with the `MsgAcknowledgement`, `AckFee` will be paid out to the relayer address which has submitted the `MsgAcknowledgement` on the sending chain (or the registered payee in case one has been registered for the relayer address), and `TimeoutFee` will be reimbursed to the account which escrowed the fee. +- In case of a timeout transaction, `RecvFee` and `AckFee` will be reimbursed. The `TimeoutFee` will be paid to the `Timeout Relayer` (who submits the timeout message to the source chain). -Please note that fee payments are built on the assumption that sender chains are the source of incentives — the chain that sends the packets is the same chain where fee payments will occur -- please see the [relayer operator section](../ics29-fee/fee-distribution.md) to understand the flow for registering payee and counterparty payee (fee receiving) addresses. +> Please note that fee payments are built on the assumption that sender chains are the source of incentives — the chain that sends the packets is the same chain where fee payments will occur -- please see the [Fee distribution section](../ics29-fee/fee-distribution.md) to understand the flow for registering payee and counterparty payee (fee receiving) addresses. -# A locked fee middleware module +## A locked fee middleware module -The fee middleware module can become locked if the situation arises that the escrow account for the fees does not have sufficient funds to pay out the fees which have been escrowed for each packet. This situation indicates a severe bug. In this case, the fee module will be locked until manual intervention fixes the issue. +The fee middleware module can become locked if the situation arises that the escrow account for the fees does not have sufficient funds to pay out the fees which have been escrowed for each packet. _This situation indicates a severe bug._ In this case, the fee module will be locked until manual intervention fixes the issue. -A locked fee module will simply skip fee logic and continue on to the underlying packet flow. A channel with a locked fee module will temporarily function as a fee disabled channel, and the locking of a fee module will not affect the continued flow of packets over the channel. +> A locked fee module will simply skip fee logic and continue on to the underlying packet flow. A channel with a locked fee module will temporarily function as a fee disabled channel, and the locking of a fee module will not affect the continued flow of packets over the channel. diff --git a/docs/middleware/ics29-fee/overview.md b/docs/middleware/ics29-fee/overview.md index e23261c712e..bf1e9ba6dc4 100644 --- a/docs/middleware/ics29-fee/overview.md +++ b/docs/middleware/ics29-fee/overview.md @@ -8,17 +8,29 @@ Learn about what the Fee Middleware module is, and how to build custom modules t ## What is the Fee Middleware module? -IBC does not depend on relayer operators for transaction verification. However, the relayer infrastructure ensures liveness of the Interchain network — operators listen for packets sent through channels opened between chains, and perform the vital service of ferrying these packets (and proof of the transaction on the sending chain/receipt on the receiving chain) to the clients on each side of the channel. +IBC does not depend on relayer operators for transaction verification. However, the relayer infrastructure ensures liveness of the Interchain network — operators listen for packets sent through channels opened between chains, and perform the vital service of ferrying these packets (and proof of the transaction on the sending chain/receipt on the receiving chain) to the clients on each side of the channel. -Though relaying is permissionless and completely decentralized and accessible, it does come with operational costs. Running full nodes to query transaction proofs and paying for transaction fees associated with IBC packets are two of the primary cost burdens which have driven the overall discussion on a general, in-protocol incentivization mechanism for relayers. +Though relaying is permissionless and completely decentralized and accessible, it does come with operational costs. Running full nodes to query transaction proofs and paying for transaction fees associated with IBC packets are two of the primary cost burdens which have driven the overall discussion on **a general, in-protocol incentivization mechanism for relayers**. -Initially, a [simple proposal](https://github.com/cosmos/ibc/pull/577/files) was created to incentivize relaying on ICS20 token transfers on the destination chain. However, the proposal was specific to ICS20 token transfers and would have to be reimplemented in this format on every other IBC application module. +Initially, a [simple proposal](https://github.com/cosmos/ibc/pull/577/files) was created to incentivize relaying on ICS20 token transfers on the destination chain. However, the proposal was specific to ICS20 token transfers and would have to be reimplemented in this format on every other IBC application module. After much discussion, the proposal was expanded to a [general incentivisation design](https://github.com/cosmos/ibc/tree/master/spec/app/ics-029-fee-payment) that can be adopted by any ICS application protocol as [middleware](../../ibc/middleware/develop.md). -## Concepts +## Concepts -ICS29 fee payments in this middleware design are built on the assumption that sender chains are the source of incentives — the chain on which packets are sent is the same chain that fee distribution to relayer operators takes place. Therefore, the middleware enables the registering of addresses associated with each party involved in relaying the packet on the source chain, and the escrowing of fees by any party which will be paid out to each party on completion of the packet lifecycle. This registration process can be automated on start up of relayer infrastructure. +ICS29 fee payments in this middleware design are built on the assumption that sender chains are the source of incentives — the chain on which packets are incentivized is the chain that distributes fees to relayer operators. However, as part of the IBC packet flow, messages have to be submitted on both sender and destination chains. This introduces the requirement of a mapping of relayer operator's addresses on both chains. + +> To achieve the stated requirements, the **fee middleware module has two main groups of functionality**: + +- Registering of relayer addresses associated with each party involved in relaying the packet on the source chain. This registration process can be automated on start up of relayer infrastructure and happens only once, not every packet flow. + + This is described in the [Fee distribution section](../ics29-fee/fee-distribution.md). + +- Escrowing fees by any party which will be paid out to each rightful party on completion of the packet lifecycle. + + This is described in the [Fee messages section](../ics29-fee/msgs.md). + +We complete the introduction by giving a list of definitions of relevant terminolgy. `Forward relayer`: The relayer that submits the `MsgRecvPacket` message for a given packet (on the destination chain).