Merge branch 'main' into migrate-get-balance-e2e

.github/workflows/e2e-compatibility-workflow-call.yaml

@@ -57,7 +57,7 @@ jobs:
           CHAIN_A_TAG: '${{ matrix.chain-a }}'
           CHAIN_B_TAG: '${{ matrix.chain-b }}'
           CHAIN_BINARY: 'simd'
-          RELAYER_TYPE: '${{ matrix.relayer-type }}'
+          RELAYER_ID: '${{ matrix.relayer-type }}'
       - name: Upload Diagnostics
         uses: actions/upload-artifact@v3
         # we only want to upload logs on test failures.

.github/workflows/e2e-test-workflow-call.yml

@@ -166,7 +166,7 @@ jobs:
       CHAIN_B_TAG: '${{ inputs.chain-b-tag }}'
       RELAYER_IMAGE: '${{ inputs.relayer-image }}'
       RELAYER_TAG: '${{ inputs.relayer-tag }}'
-      RELAYER_TYPE: '${{ inputs.relayer-type }}'
+      RELAYER_ID: '${{ inputs.relayer-type }}'
       CHAIN_BINARY: '${{ inputs.chain-binary }}'
       CHAIN_UPGRADE_TAG: '${{ inputs.chain-upgrade-tag }}'
       CHAIN_UPGRADE_PLAN: '${{ inputs.upgrade-plan-name }}'

.github/workflows/e2e-upgrade.yaml

@@ -13,7 +13,7 @@ on:
 
 jobs:
   upgrade-v5-hermes:
-    uses: cosmos/ibc-go/.github/workflows/e2e-test-workflow-call.yml@main
+    uses: .github/workflows/e2e-test-workflow-call.yml
     with:
       chain-image: ghcr.io/cosmos/ibc-go-simd
       chain-binary: simd
@@ -27,7 +27,7 @@ jobs:
       relayer-type: hermes
 
   upgrade-v7-hermes:
-    uses: cosmos/ibc-go/.github/workflows/e2e-test-workflow-call.yml@main
+    uses: .github/workflows/e2e-test-workflow-call.yml
     with:
       chain-image: ghcr.io/cosmos/ibc-go-simd
       chain-binary: simd
@@ -41,7 +41,7 @@ jobs:
       relayer-type: hermes
 
   upgrade-v7_1-hermes:
-    uses: cosmos/ibc-go/.github/workflows/e2e-test-workflow-call.yml@main
+    uses: .github/workflows/e2e-test-workflow-call.yml
     with:
       chain-image: ghcr.io/cosmos/ibc-go-simd
       chain-binary: simd
@@ -55,7 +55,7 @@ jobs:
       relayer-type: hermes
 
   upgrade-v8-hermes:
-    uses: cosmos/ibc-go/.github/workflows/e2e-test-workflow-call.yml@main
+    uses: .github/workflows/e2e-test-workflow-call.yml
     with:
       chain-image: ghcr.io/cosmos/ibc-go-simd
       chain-binary: simd
@@ -69,7 +69,7 @@ jobs:
       relayer-type: hermes
 
   upgrade-v5-rly:
-    uses: cosmos/ibc-go/.github/workflows/e2e-test-workflow-call.yml@main
+    uses: .github/workflows/e2e-test-workflow-call.yml
     with:
       chain-image: ghcr.io/cosmos/ibc-go-simd
       chain-binary: simd
@@ -85,7 +85,7 @@ jobs:
       relayer-tag: latest
 
   upgrade-v7-rly:
-    uses: cosmos/ibc-go/.github/workflows/e2e-test-workflow-call.yml@main
+    uses: .github/workflows/e2e-test-workflow-call.yml
     with:
       chain-image: ghcr.io/cosmos/ibc-go-simd
       chain-binary: simd
@@ -101,7 +101,7 @@ jobs:
       relayer-tag: latest
 
   upgrade-v7_1-rly:
-    uses: cosmos/ibc-go/.github/workflows/e2e-test-workflow-call.yml@main
+    uses: .github/workflows/e2e-test-workflow-call.yml
     with:
       chain-image: ghcr.io/cosmos/ibc-go-simd
       chain-binary: simd
@@ -117,7 +117,7 @@ jobs:
       relayer-tag: latest
 
   upgrade-v8-rly:
-    uses: cosmos/ibc-go/.github/workflows/e2e-test-workflow-call.yml@main
+    uses: .github/workflows/e2e-test-workflow-call.yml
     with:
       chain-image: ghcr.io/cosmos/ibc-go-simd
       chain-binary: simd

Dockerfile

@@ -4,7 +4,6 @@ ARG IBC_GO_VERSION
 RUN set -eux; apk add --no-cache git libusb-dev linux-headers gcc musl-dev make;
 
 ENV GOPATH=""
-ENV GOMODULE="on"
 
 # ensure the ibc go version is being specified for this image.
 RUN test -n "${IBC_GO_VERSION}"

README.md

@@ -92,7 +92,7 @@ To report a security vulnerability, see our [Coordinated Vulnerability Disclosur
 
 The following audits have been performed on the `ibc-go` source code:
 
-- [ICS27 Interchain Accounts](https://github.com/cosmos/ibc-go/tree/main/docs/apps/interchain-accounts/audits) by Trail of Bits
+- [ICS27 Interchain Accounts](https://github.com/cosmos/ibc-go/blob/main/docs/audits/Trail%20of%20Bits%20audit%20-%20Final%20Report.pdf) by Trail of Bits
 
 ## Quick Navigation
 

docs/dev/release-management.md

@@ -69,15 +69,8 @@ Additionally, for the first point release of a new major or minor release branch
 - Update the table of supported release lines (and End of Life dates) in [`RELEASES.md`](../../RELEASES.md): add the new release line and remove any release lines that might have become discontinued.
 - Update the [list of supported release lines in README.md](../../RELEASES.md#releases), if necessary.
 - Update the [e2e compatibility test matrices](https://github.com/cosmos/ibc-go/tree/main/.github/compatibility-test-matrices): add the tag for the new release and remove any tags that might not be recommended anymore.
-<<<<<<< HEAD
 - Update the manual [e2e `simd`](https://github.com/cosmos/ibc-go/blob/main/.github/workflows/e2e-manual-simd.yaml) test workflow:
     - Remove any tags that might not be recommended anymore.
-=======
-- Update the manual [e2e `simd`](https://github.com/cosmos/ibc-go/blob/main/.github/workflows/e2e-manual-simd.yaml) and [e2e `icad`](https://github.com/cosmos/ibc-go/blob/main/.github/workflows/e2e-manual-icad.yaml) test workflows:
-    - Add the new release and the new `icad` tag.
-    - Remove any tags that might not be recommended anymore.
-
->>>>>>> main
 
 - Bump ibc-go version in [cosmos/interchain-accounts-demo repository](https://github.com/cosmos/interchain-accounts-demo) and create a tag.
 - [ ] Update docs site:

docs/docs/01-ibc/01-overview.md

@@ -140,7 +140,7 @@ Proofs are passed from core IBC to light-clients as bytes. It is up to light cli
 [ICS-24 Host State Machine Requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements).
 - The proof format that all implementations must be able to produce and verify is defined in [ICS-23 Proofs](https://github.com/cosmos/ics23) implementation.
 
-### [Capabilities](https://github.com/cosmos/cosmos-sdk/blob/main/docs/develop/advanced/10-ocap.md)
+### [Capabilities](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/advanced/10-ocap.md)
 
 IBC is intended to work in execution environments where modules do not necessarily trust each
 other. Thus, IBC must authenticate module actions on ports and channels so that only modules with the

docs/docs/01-ibc/05-upgrades/03-genesis-restart.md

@@ -24,7 +24,7 @@ Genesis restarts still require the usage of an IBC upgrade proposal in order to
 
 ### Step-by-Step Upgrade Process for SDK Chains
 
-If the IBC-connected chain is conducting an upgrade that will break counterparty clients, it must ensure that the upgrade is first supported by IBC using the [IBC Client Breaking Upgrade List](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/upgrades/quick-guide.md#ibc-client-breaking-upgrades) and then execute the upgrade process described below in order to prevent counterparty clients from breaking.
+If the IBC-connected chain is conducting an upgrade that will break counterparty clients, it must ensure that the upgrade is first supported by IBC using the [IBC Client Breaking Upgrade List](./01-quick-guide.md#ibc-client-breaking-upgrades) and then execute the upgrade process described below in order to prevent counterparty clients from breaking.
 
 1. Create a governance proposal with the [`MsgIBCSoftwareUpgrade`](https://buf.build/cosmos/ibc/docs/main:ibc.core.client.v1#ibc.core.client.v1.MsgIBCSoftwareUpgrade) which contains an `UpgradePlan` and a new IBC `ClientState` in the `UpgradedClientState` field. Note that the `UpgradePlan` must specify an upgrade height **only** (no upgrade time), and the `ClientState` should only include the fields common to all valid clients and zero out any client-customizable fields (such as `TrustingPeriod`).
 2. Vote on and pass the governance proposal.
@@ -43,7 +43,7 @@ Once the chain reaches the upgrade height and halts, a relayer can upgrade the c
 
 ### Step-by-Step Upgrade Process for Relayers Upgrading Counterparty Clients
 
-These steps are identical to the regular [IBC client breaking upgrade process](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/upgrades/quick-guide.md#step-by-step-upgrade-process-for-relayers-upgrading-counterparty-clients).
+These steps are identical to the regular [IBC client breaking upgrade process](./01-quick-guide.md#step-by-step-upgrade-process-for-relayers-upgrading-counterparty-clients).
 
 ## Non-IBC Client Breaking Upgrades
 

docs/docs/01-ibc/06-proposals.md

@@ -29,8 +29,8 @@ last update. This may occur if relayers stop submitting headers to update the cl
 
 An unplanned upgrade by the counterparty chain may also result in expired clients. If the counterparty
 chain undergoes an unplanned upgrade, there may be no commitment to that upgrade signed by the validator
-set before the chain-id changes. In this situation, the validator set of the last valid update for the
-light client is never expected to produce another valid header since the chain-id has changed, which will
+set before the chain ID changes. In this situation, the validator set of the last valid update for the
+light client is never expected to produce another valid header since the chain ID has changed, which will
 ultimately lead the on-chain light client to become expired.
 
 In the case that a highly valued light client is frozen, expired, or rendered non-updateable, a
@@ -61,7 +61,7 @@ See also the relevant documentation: [ADR-026, IBC client recovery mechanisms](/
 
 ### Step 1
 
-Check if the client is attached to the expected `chain-id`. For example, for an expired Tendermint client representing the Akash chain the client state looks like this on querying the client state:
+Check if the client is attached to the expected `chain_id`. For example, for an expired Tendermint client representing the Akash chain the client state looks like this on querying the client state:
 
 ```text
 {
@@ -74,12 +74,12 @@ Check if the client is attached to the expected `chain-id`. For example, for an
 }
 ```
 
-The client is attached to the expected Akash `chain-id`. Note that although the parameters (`allow_update_after_expiry` and `allow_update_after_misbehaviour`) exist to signal intent, these parameters have been deprecated and will not enforce any checks on the revival of client. See ADR-026 for more context on this deprecation.
+The client is attached to the expected Akash `chain_id`. Note that although the parameters (`allow_update_after_expiry` and `allow_update_after_misbehaviour`) exist to signal intent, these parameters have been deprecated and will not enforce any checks on the revival of client. See ADR-026 for more context on this deprecation.
 
 ### Step 2
 
 Anyone can submit the governance proposal to recover the client by executing the following via CLI.
-If the chain is on an ibc-go version older than v8, please see the [relevant documentation](https://ibc.cosmos.network/v7.3.0/ibc/proposals.html).
+If the chain is on an ibc-go version older than v8, please see the [relevant documentation](https://ibc.cosmos.network/v7.3.x/ibc/proposals.html).
 
 - From ibc-go v8 onwards
 
@@ -94,8 +94,8 @@ If the chain is on an ibc-go version older than v8, please see the [relevant doc
     "messages": [
       {
         "@type": "/ibc.core.client.v1.MsgRecoverClient",
-        "subject_client_id": "expired_client_id_string",
-        "substitute_client_id": "active_client_id_string",
+        "subject_client_id": "<expired-client-id>",
+        "substitute_client_id": "<active-client-id>",
         "signer": "<gov-address>"
       }
     ],

docs/docs/01-ibc/07-relayer.md

@@ -12,7 +12,7 @@ slug: /ibc/relayer
 ## Pre-requisite readings
 
 - [IBC Overview](01-overview.md)
-- [Events](https://github.com/cosmos/cosmos-sdk/blob/main/docs/develop/advanced/08-events.md)
+- [Events](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/advanced/08-events.md)
 
 :::
 

docs/docs/02-apps/01-transfer/06-metrics.md

@@ -8,7 +8,7 @@ slug: /apps/transfer/metrics
 
 # Metrics
 
-The IBC transfer application module exposes the following set of [metrics](https://github.com/cosmos/cosmos-sdk/blob/main/docs/develop/advanced/09-telemetry.md).
+The IBC transfer application module exposes the following set of [metrics](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/advanced/09-telemetry.md).
 
 | Metric                          | Description                                                                               | Unit            | Type    |
 |:--------------------------------|:------------------------------------------------------------------------------------------|:----------------|:--------|

docs/docs/04-middleware/01-ics29-fee/04-fee-distribution.md

@@ -59,7 +59,7 @@ type MsgRegisterCounterpartyPayee struct {
 >
 > - `PortId` 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).
 > - `ChannelId` 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)).
-> - `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/develop/beginner/03-accounts.md#addresses)).
+> - `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/beginner/03-accounts.md#addresses)).
 > - `CounterpartyPayee` is empty.
 
 See below for an example CLI command:
@@ -104,8 +104,8 @@ type MsgRegisterPayee struct {
 >
 > - `PortId` 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).
 > - `ChannelId` 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)).
-> - `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/develop/beginner/03-accounts.md#addresses)).
-> - `Payee` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/develop/beginner/03-accounts.md#addresses)).
+> - `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/beginner/03-accounts.md#addresses)).
+> - `Payee` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/beginner/03-accounts.md#addresses)).
 
 See below for an example CLI command:
 

docs/docs/05-migrations/02-sdk-to-v1.md

@@ -173,7 +173,7 @@ The solo machine has replaced the FrozenSequence uint64 field with a IsFrozen bo
 
 Application developers need to update their `OnRecvPacket` callback logic.
 
-The `OnRecvPacket` callback has been modified to only return the acknowledgement. The acknowledgement returned must implement the `Acknowledgement` interface. The acknowledgement should indicate if it represents a successful processing of a packet by returning true on `Success()` and false in all other cases. A return value of false on `Success()` will result in all state changes which occurred in the callback being discarded. More information can be found in the [documentation](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/apps.md#receiving-packets).
+The `OnRecvPacket` callback has been modified to only return the acknowledgement. The acknowledgement returned must implement the `Acknowledgement` interface. The acknowledgement should indicate if it represents a successful processing of a packet by returning true on `Success()` and false in all other cases. A return value of false on `Success()` will result in all state changes which occurred in the callback being discarded. More information can be found in the [documentation](../01-ibc/03-apps/01-apps.md#receiving-packets).
 
 The `OnRecvPacket`, `OnAcknowledgementPacket`, and `OnTimeoutPacket` callbacks are now passed the `sdk.AccAddress` of the relayer who relayed the IBC packet. Applications may use or ignore this information.
 

docs/docs/05-migrations/05-v3-to-v4.md

@@ -47,7 +47,7 @@ Take a look at the following diff for an [example setup](https://github.com/cosm
 
 ### Migration to fix support for base denoms with slashes
 
-As part of [v1.5.0](https://github.com/cosmos/ibc-go/releases/tag/v1.5.0), [v2.3.0](https://github.com/cosmos/ibc-go/releases/tag/v2.3.0) and [v3.1.0](https://github.com/cosmos/ibc-go/releases/tag/v3.1.0) some [migration handler code sample was documented](https://github.com/cosmos/ibc-go/blob/main/docs/migrations/support-denoms-with-slashes.md#upgrade-proposal) that needs to run in order to correct the trace information of coins transferred using ICS20 whose base denom contains slashes.
+As part of [v1.5.0](https://github.com/cosmos/ibc-go/releases/tag/v1.5.0), [v2.3.0](https://github.com/cosmos/ibc-go/releases/tag/v2.3.0) and [v3.1.0](https://github.com/cosmos/ibc-go/releases/tag/v3.1.0) some [migration handler code sample was documented](./01-support-denoms-with-slashes.md#upgrade-proposal) that needs to run in order to correct the trace information of coins transferred using ICS20 whose base denom contains slashes.
 
 Based on feedback from the community we add now an improved solution to run the same migration that does not require copying a large piece of code over from the migration document, but instead requires only adding a one-line upgrade handler.
 

docs/versioned_docs/version-v4.4.x/01-ibc/01-overview.md

@@ -140,7 +140,7 @@ Proofs are passed from core IBC to light-clients as bytes. It is up to light cli
 [ICS-24 Host State Machine Requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements). 
 - The proof format that all implementations must be able to produce and verify is defined in [ICS-23 Proofs](https://github.com/confio/ics23) implementation.
 
-### [Capabilities](https://github.com/cosmos/cosmos-sdk/blob/main/docs/develop/advanced/10-ocap.md)
+### [Capabilities](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/advanced/10-ocap.md)
 
 IBC is intended to work in execution environments where modules do not necessarily trust each
 other. Thus, IBC must authenticate module actions on ports and channels so that only modules with the

docs/versioned_docs/version-v4.4.x/01-ibc/05-upgrades/01-quick-guide.md

@@ -36,7 +36,7 @@ Note: Since upgrades are only implemented for Tendermint clients, this doc only
 
 If the IBC-connected chain is conducting an upgrade that will break counterparty clients, it must ensure that the upgrade is first supported by IBC using the list above and then execute the upgrade process described below in order to prevent counterparty clients from breaking.
 
-1. Create a 02-client [`UpgradeProposal`](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/proto-docs.md#upgradeproposal) with an `UpgradePlan` and a new IBC ClientState in the `UpgradedClientState` field. Note that the `UpgradePlan` must specify an upgrade height **only** (no upgrade time), and the `ClientState` should only include the fields common to all valid clients and zero out any client-customizable fields (such as TrustingPeriod).
+1. Create a 02-client [`UpgradeProposal`](https://github.com/cosmos/ibc-go/blob/v4.4.2/proto/ibc/core/client/v1/client.proto#L58-L77) with an `UpgradePlan` and a new IBC ClientState in the `UpgradedClientState` field. Note that the `UpgradePlan` must specify an upgrade height **only** (no upgrade time), and the `ClientState` should only include the fields common to all valid clients and zero out any client-customizable fields (such as TrustingPeriod).
 2. Vote on and pass the `UpgradeProposal`
 
 Upon the `UpgradeProposal` passing, the upgrade module will commit the UpgradedClient under the key: `upgrade/UpgradedIBCState/{upgradeHeight}/upgradedClient`. On the block right before the upgrade height, the upgrade module will also commit an initial consensus state for the next chain under the key: `upgrade/UpgradedIBCState/{upgradeHeight}/upgradedConsState`.