Merge branch 'main' into carlos/#1359-bump-package-to-v4

.github/CODEOWNERS

@@ -16,10 +16,15 @@
 /modules/core/ @colin-axner @fedekunze @AdityaSripal 
 /proto/ibc/core/ @colin-axner @fedekunze @AdityaSripal 
 
+## CODEOWNERS for core/02-client
+
+/modules/core/02-client @seantking @damiannolan
+/proto/ibc/core/client @seantking @damiannolan
+
 # CODEOWNERS for the light-clients
 
-/modules/light-clients/ @colin-axner @fedekunze @AdityaSripal 
-/proto/ibc/lightclients/ @colin-axner @fedekunze @AdityaSripal 
+/modules/light-clients/ @colin-axner @fedekunze @AdityaSripal @seantking @damiannolan
+/proto/ibc/lightclients/ @colin-axner @fedekunze @AdityaSripal @seantking @damiannolan
 
 # CODEOWNERS for ICS 20
 

.github/workflows/codeql-analysis.yml

@@ -40,7 +40,7 @@ jobs:
     steps:
     - name: Checkout repository
       uses: actions/checkout@v3
-    - uses: technote-space/get-diff-action@v6.0.1
+    - uses: technote-space/get-diff-action@v6.1.0
       with:
         PATTERNS: |
           **/**.go

.github/workflows/test.yml

@@ -41,7 +41,7 @@ jobs:
       - uses: actions/setup-go@v3
         with:
           go-version: 1.17
-      - uses: technote-space/get-diff-action@v6.0.1
+      - uses: technote-space/get-diff-action@v6.1.0
         id: git_diff
         with:
           PATTERNS: |
@@ -96,7 +96,7 @@ jobs:
       - uses: actions/setup-go@v3
         with:
           go-version: 1.17
-      - uses: technote-space/get-diff-action@v6.0.1
+      - uses: technote-space/get-diff-action@v6.1.0
         with:
           PATTERNS: |
             **/**.go
@@ -120,7 +120,7 @@ jobs:
     needs: tests
     steps:
       - uses: actions/checkout@v3
-      - uses: technote-space/get-diff-action@v6.0.1
+      - uses: technote-space/get-diff-action@v6.1.0
         with:
           PATTERNS: |
             **/**.go

CHANGELOG.md

@@ -57,6 +57,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
 * (modules/core/04-channel) [\#1232](https://github.com/cosmos/ibc-go/pull/1232) Updating params on `NewPacketId` and moving to bottom of file.
 * (app/29-fee) [\#1305](https://github.com/cosmos/ibc-go/pull/1305) Change version string for fee module to `ics29-1`
 * (app/29-fee) [\#1341](https://github.com/cosmos/ibc-go/pull/1341) Check if the fee module is locked and if the fee module is enabled before refunding all fees
+* (testing/simapp) [\#1397](https://github.com/cosmos/ibc-go/pull/1397) Adding mock module to maccperms and adding check to ensure mock module is not a blocked account address. 
 
 ### Features
 

docs/.vuepress/config.js

@@ -145,9 +145,9 @@ module.exports = {
               path: "/apps",
               children: [
                 {
-                    title: "Overview",
-                    directory: false,
-                    path: "/apps/interchain-accounts/overview.html"
+                  title: "Overview",
+                  directory: false,
+                  path: "/apps/interchain-accounts/overview.html"
                 }, 
                 {
                   title: "Authentication Modules",
@@ -160,9 +160,9 @@ module.exports = {
                   path: "/apps/interchain-accounts/active-channels.html"
                 },
                 {
-                    title: "Integration",
-                    directory: false,
-                    path: "/apps/interchain-accounts/integration.html"
+                  title: "Integration",
+                  directory: false,
+                  path: "/apps/interchain-accounts/integration.html"
                 },
                 {
                   title: "Parameters",
@@ -176,6 +176,48 @@ module.exports = {
                 },
             ]
             },
+            {
+              title: "Transfer",
+              directory: true,
+              path: "/apps",
+              children: [
+                {
+                  title: "Overview",
+                  directory: false,
+                  path: "/apps/transfer/overview.html"
+                }, 
+                {
+                  title: "State",
+                  directory: false,
+                  path: "/apps/transfer/state.html"
+                },
+                {
+                  title: "State Transitions",
+                  directory: false,
+                  path: "/apps/transfer/state-transitions.html"
+                },
+                {
+                  title: "Messages",
+                  directory: false,
+                  path: "/apps/transfer/messages.html"
+                },
+                {
+                  title: "Events",
+                  directory: false,
+                  path: "/apps/transfer/events.html"
+                },
+                {
+                  title: "Metrics",
+                  directory: false,
+                  path: "/apps/transfer/metrics.html"
+                },
+                {
+                  title: "Params",
+                  directory: false,
+                  path: "/apps/transfer/params.html"
+                },
+            ]
+            },
           ]
         },
         {
@@ -187,11 +229,16 @@ module.exports = {
               path: "/middleware",
               children: [
                 {
-                    title: "Overview",
-                    directory: false,
-                    path: "/middleware/ics29-fee/overview.html"
+                  title: "Overview",
+                  directory: false,
+                  path: "/middleware/ics29-fee/overview.html"
                 }, 
-            ]
+                {
+                  title: "Integration",
+                  directory: false,
+                  path: "/middleware/ics29-fee/integration.html"
+                },
+              ]
             },
           ]
         },

modules/apps/transfer/spec/05_events.md → docs/apps/transfer/events.md

@@ -4,7 +4,7 @@ order: 5
 
 # Events
 
-## MsgTransfer
+## `MsgTransfer`
 
 | Type         | Attribute Key | Attribute Value |
 |--------------|---------------|-----------------|
@@ -13,28 +13,31 @@ order: 5
 | message      | action        | transfer        |
 | message      | module        | transfer        |
 
-## OnRecvPacket callback
+## `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}    |
 | denomination_trace    | trace_hash    | {hex_hash}      |
 
-## OnAcknowledgePacket callback
+## `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 | acknowledgement | {ack.String()}    |
 | fungible_token_packet | success | error | {ack.Response}    |
 
-## OnTimeoutPacket callback
+## `OnTimeoutPacket` callback
 
 | Type                  | Attribute Key   | Attribute Value |
 |-----------------------|-----------------|-----------------|

docs/apps/transfer/messages.md

@@ -0,0 +1,36 @@
+<!--
+order: 4
+-->
+
+# Messages
+
+## `MsgTransfer`
+
+A fungible token cross chain transfer is achieved by using the `MsgTransfer`:
+
+```go
+type MsgTransfer struct {
+  SourcePort        string
+  SourceChannel     string
+  Token             sdk.Coin
+  Sender            string
+  Receiver          string
+  TimeoutHeight     ibcexported.Height
+  TimeoutTimestamp  uint64
+}
+```
+
+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](../../../docs/architecture/adr-001-coin-source-tracing.md).
+- `Sender` is empty.
+- `Receiver` is empty.
+- `TimeoutHeight` and `TimeoutTimestamp` are both zero.
+
+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.

modules/apps/transfer/spec/06_metrics.md → docs/apps/transfer/metrics.md

@@ -4,7 +4,7 @@ order: 6
 
 # Metrics
 
-The transfer IBC application module exposes the following set of [metrics](https://github.com/cosmos/cosmos-sdk/blob/master/docs/core/telemetry.md).
+The IBC transfer application module exposes the following set of [metrics](https://github.com/cosmos/cosmos-sdk/blob/main/docs/core/telemetry.md).
 
 | Metric                          | Description                                                                               | Unit            | Type    |
 |:--------------------------------|:------------------------------------------------------------------------------------------|:----------------|:--------|

modules/apps/transfer/spec/01_concepts.md → docs/apps/transfer/overview.md

@@ -2,19 +2,27 @@
 order: 1
 -->
 
-# Concepts
+# Overview
 
-## Acknowledgements
+Learn about what the token Transfer module is {synopsis}
+
+## What is the Transfer module?
+
+Transfer is the Cosmos SDK implementation of the [ICS-20](https://github.com/cosmos/ibc/tree/master/spec/app/ics-020-fungible-token-transfer) protocol, which enables cross-chain fungible token transfers.
+
+## Concepts
+
+### Acknowledgements
 
 ICS20 uses the recommended acknowledgement format as specified by [ICS 04](https://github.com/cosmos/ibc/tree/master/spec/core/ics-004-channel-and-packet-semantics#acknowledgement-envelope).
 
 A successful receive of a transfer packet will result in a Result Acknowledgement being written
-with the value `[]byte(byte(1))` in the `Response` field.
+with the value `[]byte{byte(1)}` in the `Response` field.
 
 An unsuccessful receive of a transfer packet will result in an Error Acknowledgement being written
 with the error message in the `Response` field.
 
-## Denomination Trace
+### Denomination trace
 
 The denomination trace corresponds to the information that allows a token to be traced back to its
 origin chain. It contains a sequence of port and channel identifiers ordered from the most recent to
@@ -31,14 +39,13 @@ acting as the "source zone". When the token is sent back to the chain it previou
 prefix is removed. This is a backwards movement in the token's timeline and the sender chain is
 acting as the "sink zone".
 
-It is strongly recommended to read the full details of [ADR 001: Coin Source Tracing](https://github.com/cosmos/ibc-go/blob/main/docs/architecture/adr-001-coin-source-tracing.md) to understand the implications and context of the IBC token representations.
+It is strongly recommended to read the full details of [ADR 001: Coin Source Tracing](../../architecture/adr-001-coin-source-tracing.md) to understand the implications and context of the IBC token representations.
 
-### UX suggestions for clients
+## UX suggestions for clients
 
-For clients (wallets, exchanges, applications, block explorers, etc) that want to display the source of the token, it is recommended to use the following
-alternatives for each of the cases below:
+For clients (wallets, exchanges, applications, block explorers, etc) that want to display the source of the token, it is recommended to use the following alternatives for each of the cases below:
 
-#### Direct connection
+### Direct connection
 
 If the denomination trace contains a single identifier prefix pair (as in the example above), then
 the easiest way to retrieve the chain and light client identifier is to map the trace information
@@ -53,25 +60,25 @@ A general pseudo algorithm would look like the following:
    token.
 3. Query the client state using the identifiers pair. Note that this query will return a `"Not
    Found"` response if the current chain is not connected to this channel.
-4. Retrieve the the client identifier or chain identifier from the client state (eg: on
+4. Retrieve the client identifier or chain identifier from the client state (eg: on
    Tendermint clients) and store it locally.
 
-Using the gRPC gataway client service the steps above would be, with a given IBC token `ibc/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2` stored on `chainB`:
+Using the gRPC gateway client service the steps above would be, with a given IBC token `ibc/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2` stored on `chainB`:
 
-1. `GET /ibc_transfer/v1beta1/denom_traces/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2` -> `{"path": "transfer/channelToA", "base_denom": "uatom"}`
-2. `GET /ibc/channel/v1beta1/channels/channelToA/ports/transfer/client_state"` -> `{"client_id": "clientA", "chain-id": "chainA", ...}`
-3. `GET /ibc/channel/v1beta1/channels/channelToA/ports/transfer"` -> `{"channel_id": "channelToA", port_id": "transfer", counterparty: {"channel_id": "channelToB", port_id": "transfer"}, ...}`
-4. `GET /ibc/channel/v1beta1/channels/channelToB/ports/transfer/client_state" -> {"client_id": "clientB", "chain-id": "chainB", ...}`
+1. `GET /ibc/apps/transfer/v1/denom_traces/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2` -> `{"path": "transfer/channelToA", "base_denom": "uatom"}`
+2. `GET /ibc/apps/transfer/v1/channels/channelToA/ports/transfer/client_state"` -> `{"client_id": "clientA", "chain-id": "chainA", ...}`
+3. `GET /ibc/apps/transfer/v1/channels/channelToA/ports/transfer"` -> `{"channel_id": "channelToA", port_id": "transfer", counterparty: {"channel_id": "channelToB", port_id": "transfer"}, ...}`
+4. `GET /ibc/apps/transfer/v1/channels/channelToB/ports/transfer/client_state" -> {"client_id": "clientB", "chain-id": "chainB", ...}`
 
 Then, the token transfer chain path for the `uatom` denomination would be: `chainA` -> `chainB`.
 
 ### Multiple hops
 
 The multiple channel hops case applies when the token has passed through multiple chains between the original source and final destination chains.
 
-The IBC protocol doesn't know the topology of the overall network (i.e connections between chains and identifier names between them). For this reason, in the the multiple hops case, a particular chain in the timeline of the individual transfers can't query the chain and client identifiers of the other chains.
+The IBC protocol doesn't know the topology of the overall network (i.e connections between chains and identifier names between them). For this reason, in the multiple hops case, a particular chain in the timeline of the individual transfers can't query the chain and client identifiers of the other chains.
 
-Take for example the following sequence of transfers `A -> B -> C` for an IBC token, with a final prefix path (trace info) of `transfer/channelChainC/transfer/channelChainB`. What the paragraph above means is that is that even in the case that chain `C` is directly connected to chain `A`, querying the port and channel identifiers that chain `B` uses to connect to chain `A` (eg: `transfer/channelChainA`) can be completely different from the one that chain `C` uses to connect to chain `A` (eg: `transfer/channelToChainA`).
+Take for example the following sequence of transfers `A -> B -> C` for an IBC token, with a final prefix path (trace info) of `transfer/channelChainC/transfer/channelChainB`. What the paragraph above means is that even in the case that chain `C` is directly connected to chain `A`, querying the port and channel identifiers that chain `B` uses to connect to chain `A` (eg: `transfer/channelChainA`) can be completely different from the one that chain `C` uses to connect to chain `A` (eg: `transfer/channelToChainA`).
 
 Thus the proposed solution for clients that the IBC team recommends are the following:
 
@@ -94,24 +101,23 @@ Thus the proposed solution for clients that the IBC team recommends are the foll
 The only viable alternative for clients (at the time of writing) to tokens with multiple connection hops, is to connect to all chains directly and perform relevant queries to each of them in the sequence.
 :::
 
-## Locked Funds
+## Locked funds
 
-In some [exceptional cases](https://github.com/cosmos/ibc-go/blob/main/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md#exceptional-cases), a client state associated with a given channel cannot be updated. This causes that funds from fungible tokens in that channel will be permanently locked and thus can no longer be transferred.
+In some [exceptional cases](../../architecture/adr-026-ibc-client-recovery-mechanisms.md#exceptional-cases), a client state associated with a given channel cannot be updated. This causes that funds from fungible tokens in that channel will be permanently locked and thus can no longer be transferred.
 
 To mitigate this, a client update governance proposal can be submitted to update the frozen client
 with a new valid header. Once the proposal passes the client state will be unfrozen and the funds
 from the associated channels will then be unlocked. This mechanism only applies to clients that
 allow updates via governance, such as Tendermint clients.
 
 In addition to this, it's important to mention that a token must be sent back along the exact route
-that it took originally un order to return it to its original form on the source chain (eg: the
+that it took originally in order to return it to its original form on the source chain (eg: the
 Cosmos Hub for the `uatom`). Sending a token back to the same chain across a different channel will
 **not** move the token back across its timeline. If a channel in the chain history closes before the
 token can be sent back across that channel, then the token will not be returnable to its original
 form.
 
-
-## Security Considerations
+## Security considerations
 
 For safety, no other module must be capable of minting tokens with the `ibc/` prefix. The IBC
 transfer module needs a subset of the denomination space that only it can create tokens in.

docs/apps/transfer/params.md

@@ -0,0 +1,24 @@
+<!--
+order: 7
+-->
+
+# Parameters
+
+The IBC transfer application module contains the following parameters:
+
+| Key              | Type | Default Value |
+|------------------|------|---------------|
+| `SendEnabled`    | bool | `true`        |
+| `ReceiveEnabled` | bool | `true`        |
+
+## `SendEnabled`
+
+The transfers enabled parameter controls send cross-chain transfer capabilities for all fungible tokens.
+
+To prevent a single token from being transferred from the chain, set the `SendEnabled` parameter to `true` and then set the bank module's [`SendEnabled` parameter](https://github.com/cosmos/cosmos-sdk/blob/main/x/bank/spec/05_params.md#sendenabled) for the denomination to `false`.
+
+## `ReceiveEnabled`
+
+The transfers enabled parameter controls receive cross-chain transfer capabilities for all fungible tokens.
+
+To prevent a single token from being transferred to the chain, set the `ReceiveEnabled` parameter to `true` and then set the bank module's [`SendEnabled` parameter](https://github.com/cosmos/cosmos-sdk/blob/main/x/bank/spec/05_params.md#sendenabled) for the denomination to `false`.