Merge branch 'main' into fix/e2e-test

docs/versioned_docs/version-v7.4.x/02-apps/01-transfer/08-authorizations.md → docs/versioned_docs/version-v7.5.x/02-apps/01-transfer/08-authorizations.md

@@ -24,6 +24,8 @@ It takes:
 
 - an `AllowList` list that specifies the list of addresses that are allowed to receive funds. If this list is empty, then all addresses are allowed to receive funds from the `TransferAuthorization`.
 
+- an `AllowedPacketData` list that specifies the list of memo strings that are allowed to be included in the memo field of the packet. If this list is empty, then only an empty memo is allowed (a `memo` field with non-empty content will be denied). If this list includes a single element equal to `"*"`, then any content in the `memo` field will be allowed.
+
 Setting a `TransferAuthorization` is expected to fail if:
 
 - the spend limit is nil

docs/versioned_docs/version-v7.4.x/02-apps/02-interchain-accounts/04-integration.md → docs/versioned_docs/version-v7.5.x/02-apps/02-interchain-accounts/04-integration.md

@@ -20,6 +20,8 @@ Interchain Account authentication modules (both custom or generic, such as the `
 
 ![ica-v6.png](./images/ica-v6.png)
 
+> Please note that since ibc-go v7.5.0 it is mandatory to register the gRPC query router after the creation of the host submodule's keeper; otherwise, nodes will not start. The query router is used to execute on the host query messages encoded in the ICA packet data. Please check the sample integration code below for more details.
+
 ## Example integration
 
 ```go
@@ -84,13 +86,14 @@ app.ICAControllerKeeper = icacontrollerkeeper.NewKeeper(
     app.IBCKeeper.ChannelKeeper, // may be replaced with middleware such as ics29 fee
     app.IBCKeeper.ChannelKeeper, &app.IBCKeeper.PortKeeper,
     scopedICAControllerKeeper, app.MsgServiceRouter(),
-)
+)   
 app.ICAHostKeeper = icahostkeeper.NewKeeper(
     appCodec, keys[icahosttypes.StoreKey], app.GetSubspace(icahosttypes.SubModuleName),
     app.IBCKeeper.ChannelKeeper, // may be replaced with middleware such as ics29 fee
     app.IBCKeeper.ChannelKeeper, &app.IBCKeeper.PortKeeper,
     app.AccountKeeper, scopedICAHostKeeper, app.MsgServiceRouter(),
 )
+app.ICAHostKeeper.WithQueryRouter(app.GRPCQueryRouter())
 
 // Create Interchain Accounts AppModule
 icaModule := ica.NewAppModule(&app.ICAControllerKeeper, &app.ICAHostKeeper)

docs/versioned_docs/version-v7.4.x/02-apps/02-interchain-accounts/05-messages.md → docs/versioned_docs/version-v7.5.x/02-apps/02-interchain-accounts/05-messages.md

@@ -71,6 +71,70 @@ type MsgSendTxResponse struct {
 
 The packet `Sequence` is returned in the message response.
 
+### Queries
+
+It is possible to use [`MsgModuleQuerySafe`](https://github.com/cosmos/ibc-go/blob/v7.5.0/proto/ibc/applications/interchain_accounts/host/v1/tx.proto#L32-L39) to execute a list of queries on the host chain. This message can be included in the list of encoded `sdk.Msg`s of `InterchainPacketData`. The host chain will return on the acknowledgment the responses for all the queries. Please note that only module safe queries can be executed ([deterministic queries that are safe to be called from within the state machine](https://docs.cosmos.network/main/build/building-modules/query-services#calling-queries-from-the-state-machine)). 
+
+The queries available from Cosmos SDK are:
+
+```plaintext
+/cosmos.staking.v1beta1.Query/Validators,
+/cosmos.staking.v1beta1.Query/Validator,
+/cosmos.staking.v1beta1.Query/ValidatorDelegations",
+/cosmos.staking.v1beta1.Query/ValidatorUnbondingDelegations
+/cosmos.staking.v1beta1.Query/Delegation
+/cosmos.staking.v1beta1.Query/UnbondingDelegation
+/cosmos.staking.v1beta1.Query/DelegatorDelegations
+/cosmos.staking.v1beta1.Query/DelegatorUnbondingDelegations
+/cosmos.staking.v1beta1.Query/Redelegations
+/cosmos.staking.v1beta1.Query/DelegatorValidators
+/cosmos.staking.v1beta1.Query/DelegatorValidator
+/cosmos.staking.v1beta1.Query/HistoricalInfo
+/cosmos.staking.v1beta1.Query/Pool
+/cosmos.staking.v1beta1.Query/Params
+/cosmos.bank.v1beta1.Query/Balance
+/cosmos.bank.v1beta1.Query/AllBalances
+/cosmos.bank.v1beta1.Query/SpendableBalances
+/cosmos.bank.v1beta1.Query/SpendableBalanceByDenom
+/cosmos.bank.v1beta1.Query/TotalSupply
+/cosmos.bank.v1beta1.Query/SupplyOf
+/cosmos.bank.v1beta1.Query/Params
+/cosmos.bank.v1beta1.Query/DenomMetadata
+/cosmos.bank.v1beta1.Query/DenomsMetadata
+/cosmos.bank.v1beta1.Query/DenomOwners
+/cosmos.bank.v1beta1.Query/SendEnabled
+/cosmos.auth.v1beta1.Query/Accounts
+/cosmos.auth.v1beta1.Query/Account
+/cosmos.auth.v1beta1.Query/AccountAddressByID
+/cosmos.auth.v1beta1.Query/Params
+/cosmos.auth.v1beta1.Query/ModuleAccounts
+/cosmos.auth.v1beta1.Query/ModuleAccountByName
+/cosmos.auth.v1beta1.Query/AccountInfo
+```
+
+The following code block shows an example of how `MsgModuleQuerySafe` can be used to query the account balance of an account on the host chain. The resulting packet data variable is used to set the `PacketData` of `MsgSendTx`.
+
+```go
+balanceQuery := banktypes.NewQueryBalanceRequest("cosmos1...", "uatom")
+queryBz, err := balanceQuery.Marshal()
+
+// signer of message must be the interchain account on the host
+queryMsg := icahosttypes.NewMsgModuleQuerySafe("cosmos2...", []*icahosttypes.QueryRequest{
+  {
+    Path: "/cosmos.bank.v1beta1.Query/Balance",
+    Data: queryBz,
+  },
+})
+
+bz, err := icatypes.SerializeCosmosTx(cdc, []proto.Message{queryMsg}, icatypes.EncodingProtobuf)
+
+packetData := icatypes.InterchainAccountPacketData{
+  Type: icatypes.EXECUTE_TX,
+  Data: bz,
+  Memo: "",
+}
+```
+
 ## Atomicity
 
 As the Interchain Accounts module supports the execution of multiple transactions using the Cosmos SDK `Msg` interface, it provides the same atomicity guarantees as Cosmos SDK-based applications, leveraging the [`CacheMultiStore`](https://docs.cosmos.network/main/learn/advanced/store#cachemultistore) architecture provided by the [`Context`](https://docs.cosmos.network/main/learn/advanced/context.html) type. 

docs/versioned_docs/version-v7.4.x/02-apps/02-interchain-accounts/09-active-channels.md → docs/versioned_docs/version-v7.5.x/02-apps/02-interchain-accounts/09-active-channels.md

@@ -7,7 +7,13 @@ slug: /apps/interchain-accounts/active-channels
 
 # Understanding Active Channels
 
-The Interchain Accounts module uses [ORDERED channels](https://github.com/cosmos/ibc/tree/master/spec/core/ics-004-channel-and-packet-semantics#ordering) to maintain the order of transactions when sending packets from a controller to a host chain. A limitation when using ORDERED channels is that when a packet times out the channel will be closed.
+The Interchain Accounts module uses either [ORDERED or UNORDERED](https://github.com/cosmos/ibc/tree/master/spec/core/ics-004-channel-and-packet-semantics#ordering) channels. 
+
+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. Since ibc-go v7.5.0, the default ordering for new ICA channels is `UNORDERED`, if no ordering is specified in `MsgRegisterInterchainAccount` (previously the default ordering was `ORDERED`).
+
+> A limitation when using ORDERED channels is that when a packet times out the channel will be closed.
 
 In the case of a channel closing, a controller chain needs to be able to regain access to the interchain account registered on this channel. `Active Channels` enable this functionality.
 

docs/versioned_docs/version-v7.4.x/02-apps/02-interchain-accounts/10-legacy/02-integration.md → docs/versioned_docs/version-v7.5.x/02-apps/02-interchain-accounts/10-legacy/02-integration.md

@@ -25,6 +25,7 @@ Interchain Account authentication modules are the base application of a middlewa
 ![ica-pre-v6.png](./images/ica-pre-v6.png)
 
 > Please note that since ibc-go v6 the channel capability is claimed by the controller submodule and therefore it is not required for authentication modules to claim the capability in the `OnChanOpenInit` callback. Therefore the custom authentication module does not need a scoped keeper anymore.
+> Please note that since ibc-go v7.5.0 it is mandatory to register the gRPC query router after the creation of the host submodule's keeper; otherwise, nodes will not start. The query router is used to execute on the host query messages encoded in the ICA packet data. Please check the sample integration code below for more details.
 
 ## Example integration
 
@@ -96,6 +97,7 @@ app.ICAHostKeeper = icahostkeeper.NewKeeper(
   app.IBCKeeper.ChannelKeeper, &app.IBCKeeper.PortKeeper,
   app.AccountKeeper, scopedICAHostKeeper, app.MsgServiceRouter(),
 )
+app.ICAHostKeeper.WithQueryRouter(app.GRPCQueryRouter())
 
 // Create Interchain Accounts AppModule
 icaModule := ica.NewAppModule(&app.ICAControllerKeeper, &app.ICAHostKeeper)

docs/versioned_docs/version-v7.4.x/02-apps/02-interchain-accounts/10-legacy/03-keeper-api.md → docs/versioned_docs/version-v7.5.x/02-apps/02-interchain-accounts/10-legacy/03-keeper-api.md

@@ -80,6 +80,8 @@ if err := keeper.icaControllerKeeper.RegisterInterchainAccount(ctx, controllerCo
 }
 ```
 
+> Since ibc-go v7.5.0 the default ordering of new ICA channels created when invoking `RegisterInterchainAccount` has changed from `ORDERED` to `UNORDERED`. If this default behaviour does not meet your use case, please use the function `RegisterInterchainAccountWithOrdering` (available since ibc-go v7.5.0), which takes an extra parameter that can be used to specify the ordering of the channel.
+
 ## `SendTx`
 
 The authentication module can attempt to send a packet by calling `SendTx`:

docs/versions.json

@@ -1,6 +1,6 @@
 [
   "v8.2.x",
-  "v7.4.x",
+  "v7.5.x",
   "v6.3.x",
   "v5.4.x",
   "v4.6.x"