docs: documentation for v8.3.x

docs/docusaurus.config.js

@@ -49,14 +49,14 @@ const config = {
           // Exclude template markdown files from the docs
           exclude: ["**/*.template.md"],
           // Select the latest version
-          lastVersion: "v8.2.x",
+          lastVersion: "v8.3.x",
           // Assign banners to specific versions
           versions: {
             current: {
               path: "main",
               banner: "unreleased",
             },
-            "v8.2.x": {
+            "v8.3.x": {
               path: "v8",
               banner: "none",
             },

docs/versioned_docs/version-v8.2.x/02-apps/01-transfer/08-authorizations.md → docs/versioned_docs/version-v8.3.x/02-apps/01-transfer/08-authorizations.md

@@ -22,7 +22,7 @@ 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 packet data keys that are allowed to send 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 `memo` field will be allowed.
+- 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:
 

docs/versioned_docs/version-v8.2.x/02-apps/02-interchain-accounts/04-integration.md → docs/versioned_docs/version-v8.3.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 v8.3.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
@@ -91,6 +93,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-v8.2.x/02-apps/02-interchain-accounts/05-messages.md → docs/versioned_docs/version-v8.3.x/02-apps/02-interchain-accounts/05-messages.md

@@ -72,6 +72,80 @@ 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/eecfa5c09a4c38a5c9f2cc2a322d2286f45911da/proto/ibc/applications/interchain_accounts/host/v1/tx.proto#L41-L51) 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.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
+/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/DenomMetadataByQueryString
+/cosmos.bank.v1beta1.Query/DenomsMetadata
+/cosmos.bank.v1beta1.Query/DenomOwners
+/cosmos.bank.v1beta1.Query/SendEnabled
+/cosmos.circuit.v1.Query/Account
+/cosmos.circuit.v1.Query/Accounts
+/cosmos.circuit.v1.Query/DisabledList
+/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
+```
+
+And the query available from ibc-go is:
+
+```plaintext
+/ibc.core.client.v1.Query/VerifyMembership
+```
+
+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-v8.2.x/02-apps/02-interchain-accounts/09-active-channels.md → docs/versioned_docs/version-v8.3.x/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. Since ibc-go v8.3.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.
 

docs/versioned_docs/version-v8.2.x/02-apps/02-interchain-accounts/10-legacy/02-integration.md → docs/versioned_docs/version-v8.3.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 v8.3.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-v8.2.x/02-apps/02-interchain-accounts/10-legacy/03-keeper-api.md → docs/versioned_docs/version-v8.3.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 v8.3.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 v8.3.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,5 +1,5 @@
 [
-  "v8.2.x",
+  "v8.3.x",
   "v7.5.x",
   "v6.3.x",
   "v5.4.x",