v8.5.1

This release fixes a panic that occurred during instantiation of the interchain accounts host keeper when populating the list of all module safe queries and port definitions were not found. The solution implemented is to use the cosmos/gogoproto registry instead of including the entire merged global files registry. Please check the v8.5.1 changelog for more details. Big thanks to @damiannolan for resolving this issue!

---

To learn more about ibc-go versioning, please read our RELEASES.md.

IMPORTANT: Please read the migration guides for any versions of ibc-go that you might be going through when upgrading to this version. For example: if you upgrade from the IBC module contained in the Cosmos SDK 0.42.0 to SDK v0.50.9 and ibc-go v8.5.1, please follow:

1. The migration from SDK 0.41.x or 0.42.x to the IBC module in the ibc-go repository based on the SDK v0.44.x.
2. The migration from ibc-go v1 to v2.
3. The migration from ibc-go v2 to v3.
4. The migration from ibc-go v3 to v4.
5. The migration from ibc-go v4 to v5.
6. The migration from ibc-go v5 to v6.
7. The migration from ibc-go v6 to v7.
8. The migration from ibc-go v7 to v7.1.
9. The migration from ibc-go v7.2 to v7.3.
10. The migration from ibc-go v7 to v8.
11. The migration from ibc-go v8 to v8.1.

v8.5.0

We present here a summary of the most relevant changes, please see the v8.5.0 changelog for more details. Please note that this release, as indicated in our release versioning policy, is state machine breaking and requires a coordinated upgrade.

dependencies

• Cosmos SDK has been bumped to v0.50.9.
• ics23 has been bumped to v0.11.0.

core/03-connection

• We have removed from the connection handshake the verification step that guaranteed that the client state and consensus state stored by the light client on the counterparty is a correct representation of the chain and its consensus state. Please check cosmos/ibc#1121 for more details and rationale.

---

To learn more about ibc-go versioning, please read our RELEASES.md.

IMPORTANT: Please read the migration guides for any versions of ibc-go that you might be going through when upgrading to this version. For example: if you upgrade from the IBC module contained in the Cosmos SDK 0.42.0 to SDK v0.50.9 and ibc-go v8.5.0, please follow:

1. The migration from SDK 0.41.x or 0.42.x to the IBC module in the ibc-go repository based on the SDK v0.44.x.
2. The migration from ibc-go v1 to v2.
3. The migration from ibc-go v2 to v3.
4. The migration from ibc-go v3 to v4.
5. The migration from ibc-go v4 to v5.
6. The migration from ibc-go v5 to v6.
7. The migration from ibc-go v6 to v7.
8. The migration from ibc-go v7 to v7.1.
9. The migration from ibc-go v7.2 to v7.3.
10. The migration from ibc-go v7 to v8.
11. The migration from ibc-go v8 to v8.1.

v7.8.0

We present here a summary of the most relevant changes, please see the v7.8.0 changelog for more details. Please note that this release, as indicated in our release versioning policy, is state machine breaking and requires a coordinated upgrade.

core/03-connection

• We have removed from the connection handshake the verification step that guaranteed that the client state and consensus state stored by the light client on the counterparty is a correct representation of the chain and its consensus state. Please check cosmos/ibc#1121 for more details and rationale.

---

To learn more about ibc-go versioning, please read our RELEASES.md.

IMPORTANT: Please read the migration guides for any versions of ibc-go that you might be going through when upgrading to this version. For example: if you upgrade from the IBC module contained in the Cosmos SDK 0.42.0 to SDK v0.47.13 and ibc-go v7.8.0, please follow:

1. The migration from SDK 0.41.x or 0.42.x to the IBC module in the ibc-go repository based on the SDK v0.44.x.
2. The migration from ibc-go v1 to v2.
3. The migration from ibc-go v2 to v3.
4. The migration from ibc-go v3 to v4.
5. The migration from ibc-go v4 to v5.
6. The migration from ibc-go v5 to v6.
7. The migration from ibc-go v6 to v7.
8. The migration from ibc-go v7 to v7.1.
9. The migration from ibc-go v7.2 to v7.3.

modules/light-clients/08-wasm/v0.4.1+ibc-go-v8.4-wasmvm-v2.0

This release amends the release of 08-wasm v0.4.0 with ibc-go v8.3 to bump the version of ibc-go to v8.4 as v8.3 was redacted. No additional commits have been made.

In order to use this release, please follow the steps to import git commit ccd4dc2.

modules/light-clients/08-wasm/v0.3.1+ibc-go-v7.4-wasmvm-v1.5

This release amends the release of 08-wasm v0.3.0 with ibc-go v7.3 to bump the version of ibc-go to v7.4 as v7.3 was redacted. No additional commits have been made.

In order to use this release, please follow the steps to import git commit 13c071f.

v8.4.0

We present here a summary of the most relevant changes, please see the v8.4.0 changelog for more details. Please note that this release, as indicated in our release versioning policy, is state machine breaking and requires a coordinated upgrade.

core/04-channel

• An extra check has been added to the ChannelUpgradeConfirm handler to make sure that the upgrades are compatible and thus prevent that an upgrade completes with channel ends in incompatible state. We have retracted v8.2.x and v8.3.x and all chains planning to use channel upgradability are strongly recommended to upgrade to this version. Thank you very much to @siburu and @bluele for responsibly reporting this bug through our bug bounty program.

apps/transfer

• If the Amount of the Token field in MsgTransfer is set to the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1), then the whole balance of the corresponding denomination will be transferred. The helper function UnboundedSpendLimit in the types package of the transfer module provides the sentinel value that can be used.

---

To learn more about ibc-go versioning, please read our RELEASES.md.

IMPORTANT: Please read the migration guides for any versions of ibc-go that you might be going through when upgrading to this version. For example: if you upgrade from the IBC module contained in the Cosmos SDK 0.42.0 to SDK v0.50.7 and ibc-go v8.4.0, please follow:

1. The migration from SDK 0.41.x or 0.42.x to the IBC module in the ibc-go repository based on the SDK v0.44.x.
2. The migration from ibc-go v1 to v2.
3. The migration from ibc-go v2 to v3.
4. The migration from ibc-go v3 to v4.
5. The migration from ibc-go v4 to v5.
6. The migration from ibc-go v5 to v6.
7. The migration from ibc-go v6 to v7.
8. The migration from ibc-go v7 to v7.1.
9. The migration from ibc-go v7.2 to v7.3.
10. The migration from ibc-go v7 to v8.
11. The migration from ibc-go v8 to v8.1.

v7.7.0

We present here a summary of the most relevant changes, please see the v7.7.0 changelog for more details. Please note that this release, as indicated in our release versioning policy, is state machine breaking and requires a coordinated upgrade.

dependencies

• Cosmos SDK has been bumped to v0.47.13.

apps/transfer

• If the Amount of the Token field in MsgTransfer is set to the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1), then the whole balance of the corresponding denomination will be transferred. The helper function UnboundedSpendLimit in the types package of the transfer module provides the sentinel value that can be used.

---

To learn more about ibc-go versioning, please read our RELEASES.md.

IMPORTANT: Please read the migration guides for any versions of ibc-go that you might be going through when upgrading to this version. For example: if you upgrade from the IBC module contained in the Cosmos SDK 0.42.0 to SDK v0.47.13 and ibc-go v7.7.0, please follow:

1. The migration from SDK 0.41.x or 0.42.x to the IBC module in the ibc-go repository based on the SDK v0.44.x.
2. The migration from ibc-go v1 to v2.
3. The migration from ibc-go v2 to v3.
4. The migration from ibc-go v3 to v4.
5. The migration from ibc-go v4 to v5.
6. The migration from ibc-go v5 to v6.
7. The migration from ibc-go v6 to v7.
8. The migration from ibc-go v7 to v7.1.
9. The migration from ibc-go v7.2 to v7.3.

modules/light-clients/08-wasm/v0.4.0+ibc-go-v8.3-wasmvm-v2.0

Highlights 🌟

We present here a summary of the most relevant changes, please see the changelog for more details.

• In v0.3.0+ibc-go-v8.3-wasmvm-v2.0 we added a new MerklePath type and used it for the Path field of the VerifyMembershipMsg and VerifyNonMembershipMsg structs of the contract API. This change was API breaking for light contracts and it required a migration for existing contracts to correctly handle deserialization of the KeyPath field (which had changed from []string to [][]byte). In this release we are making an extra change to explicitly break the contract API JSON message field name: the path field of the JSON-encoded VerifyMembershipMsg and VerifyNonMembershipMsg messages has been renamed to merkle_path, so that light client contracts would not silently unmarshal a key as a base64 encoded string value (and instead fail to unmarshal the message entirely).

All previous releases of the 08-wasm compatible with ibc-go v8.3 and wasmvm v2.0 have been retracted and we strongly recommend contract developers to update their JSON API message structure for the SudoMsg payloads VerifyMembershipMsg and VerifyNonMembershipMsg.

For chains on v8.3 or above in the v8 line that have not deployed a light client contract yet, we strongly recommend to upgrade to this release first and then deploy the updated contract. Otherwise, chains will need to migrate the contract later on.

Migration 🦆

Please check out the migration docs to upgrade to this release from v0.3.x compatible with ibc-go v8.3.x.

In order to use this release, please follow the steps to import git commit 44562d7.

modules/light-clients/08-wasm/v0.3.0+ibc-go-v7.3-wasmvm-v1.5

Highlights 🌟

We present here a summary of the most relevant changes, please see the changelog for more details.

• In v0.2.0+ibc-go-v7.3-wasmvm-v1.5 we added a new MerklePath type and used it for the Path field of the VerifyMembershipMsg and VerifyNonMembershipMsg structs of the contract API. This change was API breaking for light contracts and it required a migration for existing contracts to correctly handle deserialization of the KeyPath field (which had changed from []string to [][]byte). In this release we are making an extra change to explicitly break the contract API JSON message field name: the path field of the JSON-encoded VerifyMembershipMsg and VerifyNonMembershipMsg messages has been ranamed to merkle_path, so that light client contracts would not silently unmarshal a key as a base64 encoded string value (and instead fail to unmarshal the message entirely).

All previous releases of the 08-wasm compatible with ibc-go v7.3 and wasmvm v1.5 have been retracted and we strongly recommend contract developers to update their JSON API message structure for the SudoMsg payloads VerifyMembershipMsg and VerifyNonMembershipMsg.

For chains on v7.3 or above in the v7 line that have not deployed a light client contract yet, we strongly recommend to upgrade to this release first and then deploy the updated contract. Otherwise, chains will need to migrate the contract later on.

Migration 🦆

Please check out the migration docs to upgrade to this release from v0.2.x compatible with ibc-go v7.3.x.

In order to use this release, please follow the steps to import git commit 86f7c39.

modules/light-clients/08-wasm/v0.3.0+ibc-go-v8.3-wasmvm-v2.0

Highlights 🌟

We present here a summary of the most relevant changes, please see the changelog for the full set of changes included in this release.

• Update of wasmvm to v2.1.0.
• Add a new MerklePath type that replaces the usage of ibc-go's MerklePath for the Path field of the VerifyMembershipMsg and VerifyNonMembershipMsg structs of the contract API. Please note that this change is API breaking for light contracts and it requires a migration for existing contracts to correctly handle deserialization of the KeyPath field which has changed from []string to [][]byte. In JSON message structures this change is reflected as the KeyPath being marshalled as a list of base64 encoded byte strings. This change supports proving values stored under keys which contain non-utf8 encoded symbols. See the migration documentation for more details. For chains on v8.3 or above in the v8 line that have not deployed a light client contract yet, we strongly recommend to upgrade to this release first and then deploy the updated contract. Otherwise, chains will need to migrate the contract later on.
• Add an implementation of the ConsensusHost interface for custom self client/consensus state validation.

Migration 🦆

Please check out the migration docs to upgrade to this release from v0.2.x compatible with ibc-go v8.3.x.

In order to use this release, please follow the steps to import git commit bb71eef.

Contributors ❤️

Special thanks to all external contributors that pushed code for this release:

• @kien6034