v9.0.0

This release main additions are:

ICS20 v2

ICS20 v2 introduces two key features:

Multi-token transfers with a single packet

A new field tokens has been added to MsgTransfer and it can hold up to 100 tokens. The existing token field has been marked deprecated and will be removed in a future release.

Native packet forwarding and unwinding

Forwarding enables transferring tokens to a final destination through a set of intermediary chains, specified by the source port/channel identifiers. Native tokens or IBC vouchers on any chain can be forwarded through intermediary chains to reach their final destination. The multi-hop transfer route is specified in the new hops field in MsgTransfer as source port ID/channel ID pairs.

With unwinding it is possible to automatically return IBC vouchers back to their origin chain. For example, if a token was sent from A (origin) to C through B, unwinding means returning it from C back to A through B over the same channels they were initially sent over, so that the tokens recover their original denomination on chain A. Unwinding can be used by simply setting the new unwind boolean in MsgTransfer to true (multiple tokens can be unwound together if the all share the same denomination trace path, i.e. the set of destination port/channel identifiers where tokens have been received).

For more information, please read the transfer application documentation and the v9.0.0 launch blog post. To use the features of ICS20 v2, chains must upgrade the transfer channel version from ics20-1 to ics20-2 using channel upgradability. Please read the channel upgrades section of the documentation or follow this tutorial (it upgrades a channel to wire up fee middleware, but a similar process needs to be followed to upgrade a channel version). Please follow also the ICS20 v2 section of the migration documentation.

Protobuf encoding of packet data

ICS20 v2 introduces a new packet data type FungibleTokenPacketDataV2 that contains the forwarding information. If the transfer channel version is ics20-2 then the type FungibleTokenPacketDataV2 will be used to construct the packet data and it will be encoded using Protobuf (instead of JSON, which is used to encode packet data of type FungibleTokenPacketData when the channel version is ics20-1).

ICS20 v2 has been audited by Atredis Partners and the report is available here.

02-client routing refactor

We have refactored the routing at the 02-client layer by decoupling it from the encoding structures used by light clients (i.e. the implementation of the ClientState interface). The different light client implementations of the ClientState interface are not used anymore to route requests to the right light client at the 02-client layer. Instead, a light client module is registered for every light client type (tendermint, solomachine, etc.) and 02-client routes the requests to the right light client module based on the client ID. Light client developers must implement the newly introduced LightClientModule interface and are encouraged to move the logic implemented in the functions of their light client's implementation of the ClientState interface to the equivalent function in the LightClientModule interface. Please refer to the migration docs to see the equivalence between ClientState interface functions that have been removed and the functions in the LightClientModule interface, and check the light client developer guide for more information.

For more details about the features introduced in this release, please read the v9.0.0 announcement blog post.

Contributors ❤️

Special thanks to all external contributors that pushed code, improved documentation, testing or CI since our last major release:

• @vishal-kanna
• @chandiniv1
• @NisTun
• @healthyyyoung
• @hakuno2000
• @TropicalDog17
• @cratiu222
• @neitdung
• @lichdu29
• @lfgtwo
• @winniehere
• @lido333
• @jgscr
• @tiendn
• @Taztingo
• @trungnt1811
• @tianyeyouyou
• @tuantran1702
• @jjjike2021
• @MukulKolpe
• @GNaD13
• @argentpapa
• @tcpdumppy
• @BabyHalimao
• @suiyuan1314
• @polymaer
• @kien6034
• @ma68584703
• @icarus012832
• @hoank101
• @seay404
• @goofylfg
• @hoank101
• @careworry
• @akaladarshi
• @hoangdv2429
• @AtomicInnovation321
• @GNaD13
• @AdventureSeeker987
• @omahs
• @tungle-notional
• @zoereco
• @expertdicer
• @levisyin
• @keienWang
• @natebeauregard
• @phamminh0811
• @Halimao
• @sontrinh16
• @Frierened
• @vuittont60
• @bodhi-crypo
• @joaolago1113
• @yihuang
• @nnsW3
• @anhductn2001
• @sontrinh16
• @lukema95
• @ukema95
• @Ursulafe
• @0xstepit
• @mattverse
• @tbruyelle
• @shuoer86
• @muku314115
• @trinitys7

Migration 🦆

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 v9.0.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.
12. The migration from ibc-go v8 to v9.

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.