docs: ics27 v6 documentation updates

docs/.vuepress/config.js

@@ -203,29 +203,29 @@ module.exports = {
                   path: "/apps/interchain-accounts/overview.html",
                 },
                 {
-                  title: "Authentication Modules",
+                  title: "Integration",
                   directory: false,
-                  path: "/apps/interchain-accounts/auth-modules.html",
+                  path: "/apps/interchain-accounts/integration.html",
                 },
                 {
-                  title: "Active Channels",
+                  title: "Messages",
                   directory: false,
-                  path: "/apps/interchain-accounts/active-channels.html",
+                  path: "/apps/interchain-accounts/messages.html",
                 },
                 {
-                  title: "Integration",
+                  title: "Parameters",
                   directory: false,
-                  path: "/apps/interchain-accounts/integration.html",
+                  path: "/apps/interchain-accounts/parameters.html",
                 },
                 {
-                  title: "Parameters",
+                  title: "Active Channels",
                   directory: false,
-                  path: "/apps/interchain-accounts/parameters.html",
+                  path: "/apps/interchain-accounts/active-channels.html",
                 },
                 {
-                  title: "Transactions",
+                  title: "Authentication Modules",
                   directory: false,
-                  path: "/apps/interchain-accounts/transactions.html",
+                  path: "/apps/interchain-accounts/auth-modules.html",
                 },
               ],
             },

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

@@ -1,5 +1,5 @@
 <!--
-order: 3
+order: 5
 -->
 
 # Understanding Active Channels 
@@ -9,7 +9,7 @@ The Interchain Accounts module uses [ORDERED channels](https://github.com/cosmos
 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. Future versions of the ICS-27 protocol and the Interchain Accounts module will likely use a new 
 channel type that provides ordering of packets without the channel closing on timing out, thus removing the need for `Active Channels` entirely.  
 
-When an Interchain Account is registered using the `RegisterInterchainAccount` API, a new channel is created on a particular port. During the `OnChanOpenAck` and `OnChanOpenConfirm` steps (controller & host chain) the `Active Channel` for this interchain account
+When an Interchain Account is registered using `MsgRegisterInterchainAccount`, a new channel is created on a particular port. During the `OnChanOpenAck` and `OnChanOpenConfirm` steps (controller & host chain) the `Active Channel` for this interchain account
 is stored in state.
 
 It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programatically by sending a new `MsgChannelOpenInit` message like so:

docs/apps/interchain-accounts/auth-modules.md

@@ -1,9 +1,13 @@
 <!--
-order: 2
+order: 6
 -->
 
 # Building an authentication module
 
+### Deprecation Notice
+
+**This document is deprecated and will be removed in future releases**.
+
 Authentication modules play the role of the `Base Application` as described in [ICS30 IBC Middleware](https://github.com/cosmos/ibc/tree/master/spec/app/ics-030-middleware), and enable application developers to perform custom logic when working with the Interchain Accounts controller API. {synopsis}
 
 The controller submodule is used for account registration and packet sending. 
@@ -145,6 +149,8 @@ func (im IBCModule) OnRecvPacket(
 }
 ```
 
+### Legacy API
+
 ## `RegisterInterchainAccount`
 
 The authentication module can begin registering interchain accounts by calling `RegisterInterchainAccount`:

docs/apps/interchain-accounts/integration.md

@@ -1,5 +1,5 @@
 <!--
-order: 3
+order: 2
 -->
 
 # Integration

docs/apps/interchain-accounts/messages.md

@@ -0,0 +1,74 @@
+<!--
+order: 3
+-->
+
+# Messages
+
+## `MsgRegisterInterchainAccount`
+
+An Interchain Accounts channel handshake can be initated using `MsgRegisterInterchainAccount`:
+
+```go
+type MsgRegisterInterchainAccount struct {
+  Owner        string
+  ConnectionID string
+  Version      string
+}
+```
+
+This message is expected to fail if:
+
+- `Owner` is an empty string.
+- `ConnectionID` 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)).
+
+This message will construct a new `MsgChannelOpenInit` on chain and route it to the core IBC message server to initiate the opening step of the channel handshake.
+
+The controller module will generate a new port identifier and claim the associated port capability. The caller is expected to provide an appropriate application version string. For example, this may be an ICS27 JSON encoded `Metadata` type or an ICS29 JSON encoded `Metadata` type with a nested application version. 
+If the `Version` string omitted the application will construct a default version string in the `OnChanOpenInit` handshake callback.
+
+```go
+type MsgRegisterInterchainAccountResponse struct {
+  ChannelID string
+}
+```
+
+The `ChannelID` is return in the message response.
+
+
+## `MsgSendTx`
+
+An Interchain Accounts transaction can be executed on a remote host chain by sending a `MsgSendTx` from the corresponding controller chain:
+
+```go
+type MsgSendTx struct {
+  Owner           string
+  ConnectionID    string
+  PacketData      InterchainAccountPacketData 
+  RelativeTimeout uint64
+}
+```
+
+This message is expected to fail if:
+
+- `Owner` is an empty string.
+- `ConnectionID` 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)).
+- `PacketData` contains an `UNSPECIFIED` type enum, the length of `Data` bytes is zero or the `Memo` field exceeds `256` characters in length.
+- `RelativeTimeout` is zero.
+
+This message will create a new IBC packet with the provided `PacketData` and send it via the channel associated with the `Owner` and `ConnectionID`.
+The `PacketData` is expected to contain a list of serialized `[]sdk.Msg` in the form of `CosmosTx`. Please note the signer field of each `sdk.Msg` must be the interchain account address. 
+When the packet is relayed to the host chain, the `PacketData` is unmarshalled and the messages are authenticated and executed.
+
+```go
+type MsgSendTxResponse struct {
+  Sequence uint64
+}
+```
+
+The packet `Sequence` is returned in the message response.
+
+### 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/core/store.html#cachemultistore) architecture provided by the [`Context`](https://docs.cosmos.network/main/core/context.html) type. 
+
+This provides atomic execution of transactions when using Interchain Accounts, where state changes are only committed if all `Msg`s succeed.

docs/apps/interchain-accounts/overview.md

@@ -4,35 +4,28 @@ order: 1
 
 # Overview
 
-Learn about what the Interchain Accounts module is, and how to build custom modules that utilize Interchain Accounts functionality {synopsis}
-
+Learn about what the Interchain Accounts module is {synopsis}
 
 ## What is the Interchain Accounts module?
 
-Interchain Accounts is the Cosmos SDK implementation of the ICS-27 protocol, which enables cross-chain account management built upon IBC. Chains using the Interchain Accounts module can programmatically create accounts on other chains and control these accounts via IBC transactions. 
-
-Interchain Accounts exposes a simple-to-use API which means IBC application developers do not require an in-depth knowledge of the underlying low-level details of IBC or the ICS-27 protocol. 
+Interchain Accounts is the Cosmos SDK implementation of the ICS-27 protocol, which enables cross-chain account management built upon IBC.
 
-Developers looking to build upon Interchain Accounts must write custom logic in their own IBC application module, called authentication modules.
+- How does an interchain account differ from a regular account?
 
-- How is an interchain account different than a regular account?
-
-Regular accounts use a private key to sign transactions on-chain. Interchain Accounts are instead controlled programmatically by separate chains via IBC transactions. Interchain Accounts are implemented as sub-accounts of the interchain accounts module account. 
+Regular accounts use a private key to sign transactions. Interchain Accounts are instead controlled programmatically by counterparty chains via IBC packets.
 
 ## Concepts 
 
-`Host Chain`: The chain where the interchain account is registered. The host chain listens for IBC packets from a controller chain which should contain instructions (e.g. cosmos SDK messages) for which the interchain account will execute.
-
-`Controller Chain`: The chain registering and controlling an account on a host chain. The controller chain sends IBC packets to the host chain to control the account. A controller chain must have at least one interchain accounts authentication module in order to act as a controller chain. 
+`Host Chain`: The chain where the interchain account is registered. The host chain listens for IBC packets from a controller chain which should contain instructions (e.g. Cosmos SDK messages) for which the interchain account will execute.
 
-`Authentication Module`: A custom IBC application module on the controller chain that uses the Interchain Accounts module API to build custom logic for the creation & management of interchain accounts. For a controller chain to utilize the interchain accounts module functionality, an authentication module is required.
+`Controller Chain`: The chain registering and controlling an account on a host chain. The controller chain sends IBC packets to the host chain to control the account.
 
-`Interchain Account`: An account on a host chain. An interchain account has all the capabilities of a normal account. However, rather than signing transactions with a private key, a controller chain's authentication module will send IBC packets to the host chain which signals what transactions the interchain account should execute.
+`Interchain Account`: An account on a host chain created using the ICS-27 protocol. An interchain account has all the capabilities of a normal account. However, rather than signing transactions with a private key, a controller chain will send IBC packets to the host chain which signals what transactions the interchain account should execute.
 
 ## SDK Security Model
 
 SDK modules on a chain are assumed to be trustworthy.  For example, there are no checks to prevent an untrustworthy module from accessing the bank keeper.
 
-The implementation of ICS27 on ibc-go uses this assumption in its security considerations. The implementation assumes the authentication module will not try to open channels on owner addresses it does not control. 
+The implementation of ICS-27 in ibc-go uses this assumption in its security considerations.
 
-The implementation assumes other IBC application modules will not bind to ports within the ICS27 namespace. 
+The implementation assumes other IBC application modules will not bind to ports within the ICS-27 namespace. 

docs/apps/interchain-accounts/parameters.md

@@ -48,7 +48,7 @@ For example, a Cosmos SDK based chain that elects to provide hosted Interchain A
     "allow_messages": ["/cosmos.staking.v1beta1.MsgDelegate", "/cosmos.gov.v1beta1.MsgVote"]
 }
 ```
-There is also a special wildcard `"*"` message type which allows any type of message to be executed by the interchain account. This must be the only message in the `allow_messages` array.
+There is also a special wildcard `"*"` value which allows any type of message to be executed by the interchain account. This must be the only value in the `allow_messages` array.
 
 ```
 "params": {