Add metadata field to transfer packet data (#842)

Author: AdityaSripal

CHANGELOG.md

@@ -58,3 +58,4 @@ Ref: https://keepachangelog.com/en/1.0.0/
 - [\#804](https://github.com/cosmos/ibc/pull/804) Increment upgrade sequence at the start of a new handshake rather than the end of a completed handshake
 - [\#806](https://github.com/cosmos/ibc/pull/806) Adds previous version to UpgradeInit and UpgradeTry callback arguments
 - [\#807](https://github.com/cosmos/ibc/pull/807) Upgrade keys will now prefix the channel path to align with the rest of ICS4 keys
+- [\#842](https://github.com/cosmos/ibc/pull/842) Adds metadata field to FungibleTokenPacketData

spec/app/ics-020-fungible-token-transfer/README.md

@@ -42,9 +42,14 @@ interface FungibleTokenPacketData {
   amount: uint256
   sender: string
   receiver: string
+  metadata: bytes
 }
 ```
 
+Note: Since earlier versions of this specification did not include a `metadata` field, implementations must ensure that the new packet data is still compatible with chains that expect the old packet data. A legacy implementation MUST be able to unmarshal a new packet data with a `nil` metadata into the legacy `FungibleTokenPacketData` struct. Similarly, an implementation supporting `metadata` must be able to unmarshal a legacy packet data into the current struct with the metadata field set to `nil`.
+
+The `metadata` field is not used within transfer, however it may be used either for external off-chain users (i.e. a memo) or for middleware wrapping transfer that can parse and execute custom logic on the basis of the passed in metadata. Chains should ensure that there is some length limit on the entire packet data to ensure that the packet does not become a DOS vector. However, these do not need to be protocol-defined limits. If the receiver cannot accept a packet because of length limitations, this will lead to a timeout on the sender side.
+
 As tokens are sent across chains using the ICS 20 protocol, they begin to accrue a record of channels for which they have been transferred across. This information is encoded into the `denom` field. 
 
 The ics20 token denominations are represented the form `{ics20Port}/{ics20Channel}/{denom}`, where `ics20Port` and `ics20Channel` are an ics20 port and channel on the current chain for which the funds exist. The prefixed port and channel pair indicate which channel the funds were previously sent through. If `{denom}` contains `/`, then it must also be in the ics20 form which indicates that this token has a multi-hop record. Note that this requires that the `/` (slash character) is prohibited in non-IBC token denomination names.