Merge branch 'main' into jim/move-denomtrace-to-internal

Author: DimitrisJim

CHANGELOG.md

@@ -55,6 +55,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
 * (core/04-channel) [\#6023](https://github.com/cosmos/ibc-go/pull/6023) Remove emission of non-hexlified event attributes `packet_data` and `packet_ack`.
 * (core) [\#6320](https://github.com/cosmos/ibc-go/pull/6320) Remove unnecessary `Proof` interface from `exported` package.
 * (core/05-port) [\#6341](https://github.com/cosmos/ibc-go/pull/6341) Modify `UnmarshalPacketData` interface to take in the context, portID, and channelID. This allows for packet data's to be unmarshaled based on the channel version.
+* (apps/27-interchain-accounts) [\#6433](https://github.com/cosmos/ibc-go/pull/6433) Use UNORDERED as the default ordering for new ICA channels.
 * (apps/transfer) [\#6440](https://github.com/cosmos/ibc-go/pull/6440) Remove `GetPrefixedDenom`.
 
 ### State Machine Breaking
@@ -69,6 +70,8 @@ Ref: https://keepachangelog.com/en/1.0.0/
 
 ### Features
 
+* (apps/transfer) [\#6492](https://github.com/cosmos/ibc-go/pull/6492) Added new `Tokens` field to `MsgTransfer` to enable sending of multiple denoms, and deprecated the `Token` field.
+
 ### Bug Fixes
 
 ## [v8.3.0](https://github.com/cosmos/ibc-go/releases/tag/v8.3.0) - 2024-05-16

docs/docs/02-apps/01-transfer/04-messages.md

@@ -15,26 +15,30 @@ A fungible token cross chain transfer is achieved by using the `MsgTransfer`:
 type MsgTransfer struct {
   SourcePort        string
   SourceChannel     string
+  // Deprecated: Use Tokens instead.
   Token             sdk.Coin
   Sender            string
   Receiver          string
   TimeoutHeight     ibcexported.Height
   TimeoutTimestamp  uint64
   Memo              string
+  Tokens            []sdk.Coin
 }
 ```
 
 This message is expected to fail if:
 
 - `SourcePort` 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).
 - `SourceChannel` 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)).
-- `Token` is invalid (denom is invalid or amount is negative)
-    - `Token.Amount` is not positive.
-    - `Token.Denom` is not a valid IBC denomination as per [ADR 001 - Coin Source Tracing](/architecture/adr-001-coin-source-tracing).
+- `Tokens` must not be empty.
+- Each `Coin` in `Tokens` must satisfy the following:
+    - `Amount` must be positive.
+    - `Denom` must be a valid IBC denomination, as defined in [ADR 001 - Coin Source Tracing](/architecture/adr-001-coin-source-tracing).
 - `Sender` is empty.
 - `Receiver` is empty.
 - `TimeoutHeight` and `TimeoutTimestamp` are both zero.
 
+Please note that the `Token` field is deprecated and users should now use `Tokens` instead. If `Token` is used then `Tokens` must be empty. Similarly, if `Tokens` is used then `Token` should be left empty.
 This message will send a fungible token to the counterparty chain represented by the counterparty Channel End connected to the Channel End with the identifiers `SourcePort` and `SourceChannel`.
 
 The denomination provided for transfer should correspond to the same denomination represented on this chain. The prefixes will be added as necessary upon by the receiving chain.

docs/docs/02-apps/01-transfer/05-events.md

@@ -5,7 +5,6 @@ sidebar_position: 5
 slug: /apps/transfer/events
 ---
 
-
 # Events
 
 ## `MsgTransfer`
@@ -14,41 +13,41 @@ slug: /apps/transfer/events
 |--------------|---------------|-----------------|
 | ibc_transfer | sender        | \{sender\}      |
 | ibc_transfer | receiver      | \{receiver\}    |
-| message      | action        | transfer        |
+| ibc_transfer | tokens        | \{jsonTokens\}  |
+| ibc_transfer | memo          | \{memo\}        |
 | message      | module        | transfer        |
 
 ## `OnRecvPacket` callback
 
-| Type                  | Attribute Key | Attribute Value |
-|-----------------------|---------------|-----------------|
-| fungible_token_packet | module        | transfer        |
-| fungible_token_packet | sender        | \{sender\}      | 
-| fungible_token_packet | receiver      | \{receiver\}    | 
-| fungible_token_packet | denom         | \{denom\}       | 
-| fungible_token_packet | amount        | \{amount\}      | 
-| fungible_token_packet | success       | \{ackSuccess\}  | 
-| fungible_token_packet | memo          | \{memo\}        | 
-| denomination_trace    | trace_hash    | \{hex_hash\}    | 
+| Type                  | Attribute Key | Attribute Value  |
+|-----------------------|---------------|------------------|
+| fungible_token_packet | sender        | \{sender\}       | 
+| fungible_token_packet | receiver      | \{receiver\}     | 
+| fungible_token_packet | tokens        | \{jsonTokens\}   |
+| fungible_token_packet | success       | \{ackSuccess\}   |
+| fungible_token_packet | error         | \{ackError\}     |
+| fungible_token_packet | memo          | \{memo\}         | 
+| denomination          | trace_hash    | \{hex_hash\}     |
+| denomination          | denom         | \{voucherDenom\} |
+| message               | module        | transfer         |
 
 ## `OnAcknowledgePacket` callback
 
-| Type                  | Attribute Key   | Attribute Value   |
-|-----------------------|-----------------|-------------------|
-| fungible_token_packet | module          | transfer          |
-| fungible_token_packet | sender          | \{sender\}        |
-| fungible_token_packet | receiver        | \{receiver\}      |
-| fungible_token_packet | denom           | \{denom\}         |
-| fungible_token_packet | amount          | \{amount\}        |
-| fungible_token_packet | memo            | \{memo\}          |
-| fungible_token_packet | acknowledgement | \{ack.String()\}  |
-| fungible_token_packet | success / error | \{ack.Response\}  |
+| Type                  | Attribute Key   | Attribute Value  |
+|-----------------------|-----------------|------------------|
+| fungible_token_packet | sender          | \{sender\}       |
+| fungible_token_packet | receiver        | \{receiver\}     |
+| fungible_token_packet | tokens          | \{jsonTokens\}   |
+| fungible_token_packet | memo            | \{memo\}         |
+| fungible_token_packet | acknowledgement | \{ack.String()\} |
+| fungible_token_packet | success / error | \{ack.Response\} |
+| message               | module          | transfer         |
 
 ## `OnTimeoutPacket` callback
 
-| Type                  | Attribute Key   | Attribute Value |
-|-----------------------|-----------------|-----------------|
-| fungible_token_packet | module          | transfer        |
-| fungible_token_packet | refund_receiver | \{receiver\}    |
-| fungible_token_packet | denom           | \{denom\}       |
-| fungible_token_packet | amount          | \{amount\}      |
-| fungible_token_packet | memo            | \{memo\}        |
+| Type    | Attribute Key   | Attribute Value |
+|---------|-----------------|-----------------|
+| timeout | refund_receiver | \{receiver\}    |
+| timeout | refund_tokens   | \{jsonTokens\}  |
+| timeout | memo            | \{memo\}        |
+| message | module          | transfer        |

docs/docs/02-apps/02-interchain-accounts/09-active-channels.md

@@ -11,7 +11,7 @@ The Interchain Accounts module uses either [ORDERED or UNORDERED](https://github
 
 When using `ORDERED` channels, the order of transactions when sending packets from a controller to a host chain is maintained.
 
-When using `UNORDERED` channels, there is no guarantee that the order of transactions when sending packets from the controller to the host chain is maintained.
+When using `UNORDERED` channels, there is no guarantee that the order of transactions when sending packets from the controller to the host chain is maintained. If no ordering is specified in `MsgRegisterInterchainAccount`, then the default ordering for new ICA channels is `UNORDERED`.
 
 > A limitation when using ORDERED channels is that when a packet times out the channel will be closed.
 

docs/docs/02-apps/02-interchain-accounts/10-legacy/03-keeper-api.md

@@ -19,14 +19,14 @@ The controller submodule keeper exposes two legacy functions that allow respecti
 The authentication module can begin registering interchain accounts by calling `RegisterInterchainAccount`:
 
 ```go
-if err := keeper.icaControllerKeeper.RegisterInterchainAccount(ctx, connectionID, owner.String(), version); err != nil {
+if err := keeper.icaControllerKeeper.RegisterInterchainAccount(ctx, connectionID, owner.String(), version, channeltypes.UNORDERED); err != nil {
   return err
 }
 
 return nil
 ```
 
-The `version` argument is used to support ICS-29 fee middleware for relayer incentivization of ICS-27 packets. Consumers of the `RegisterInterchainAccount` are expected to build the appropriate JSON encoded version string themselves and pass it accordingly. If an empty string is passed in the `version` argument, then the version will be initialized to a default value in the `OnChanOpenInit` callback of the controller's handler, so that channel handshake can proceed.
+The `version` argument is used to support ICS-29 fee middleware for relayer incentivization of ICS-27 packets. The `ordering` argument allows to specify the ordering of the channel that is created; if `NONE` is passed, then the default ordering will be `UNORDERED`. Consumers of the `RegisterInterchainAccount` are expected to build the appropriate JSON encoded version string themselves and pass it accordingly. If an empty string is passed in the `version` argument, then the version will be initialized to a default value in the `OnChanOpenInit` callback of the controller's handler, so that channel handshake can proceed.
 
 The following code snippet illustrates how to construct an appropriate interchain accounts `Metadata` and encode it as a JSON bytestring:
 
@@ -44,7 +44,7 @@ if err != nil {
   return err
 }
 
-if err := keeper.icaControllerKeeper.RegisterInterchainAccount(ctx, controllerConnectionID, owner.String(), string(appVersion)); err != nil {
+if err := keeper.icaControllerKeeper.RegisterInterchainAccount(ctx, controllerConnectionID, owner.String(), string(appVersion), channeltypes.UNORDERED); err != nil {
   return err
 }
 ```
@@ -75,7 +75,7 @@ if err != nil {
   return err
 }
 
-if err := keeper.icaControllerKeeper.RegisterInterchainAccount(ctx, controllerConnectionID, owner.String(), string(feeEnabledVersion)); err != nil {
+if err := keeper.icaControllerKeeper.RegisterInterchainAccount(ctx, controllerConnectionID, owner.String(), string(feeEnabledVersion), channeltypes.UNORDERED); err != nil {
   return err
 }
 ```

docs/docs/05-migrations/13-v8-to-v9.md

@@ -84,6 +84,17 @@ func NewKeeper(
 ) Keeper
 ```
 
+The legacy function `RegisterInterchainAccount` now takes an extra parameter to specify the ordering of new ICA channels:
+
+```diff
+func (k Keeper) RegisterInterchainAccount(
+  ctx sdk.Context,
+  connectionID, owner,
+  version string,
++ ordering channeltypes.Order
+) error {
+```
+
 ## Relayers
 
 - Renaming of event attribute keys in [#5603](https://github.com/cosmos/ibc-go/pull/5603).

modules/apps/27-interchain-accounts/controller/client/cli/tx.go

@@ -71,7 +71,7 @@ the associated capability.`),
 	}
 
 	cmd.Flags().String(flagVersion, "", "Controller chain channel version")
-	cmd.Flags().String(flagOrdering, channeltypes.ORDERED.String(), fmt.Sprintf("Channel ordering, can be one of: %s", strings.Join(connectiontypes.SupportedOrderings, ", ")))
+	cmd.Flags().String(flagOrdering, channeltypes.UNORDERED.String(), fmt.Sprintf("Channel ordering, can be one of: %s", strings.Join(connectiontypes.SupportedOrderings, ", ")))
 	flags.AddTxFlagsToCmd(cmd)
 
 	return cmd