Skip to content

Releases: srdtrk/cw-ica-controller

v0.20.0

13 Aug 04:03
9d3f98b
Compare
Choose a tag to compare

Description

This release upgrades the CosmWasm to version 2.1, with backward compatibility with wasmvm version 1.4+. Please note that future releases will remove support for wasmvm v1.x.

This release is particularly beneficial for contracts utilizing cw-ica-controller that require the CosmWasm v2 API, while maintaining compatibility with wasmvm v1.4+.

What's Changed

  • chore: v0.6.1 release chores by @srdtrk in #132
  • deps: bumped cosmwasm to v2.1 by @srdtrk in #133
  • docs: use dual MIT or Apache license by @srdtrk in #134
  • deps: using 'cw-ownable v2.0.0' and bumped crate version to 'v0.20.0' by @srdtrk in #135

Full Changelog: v0.6.1...v0.20.0

v0.6.1

21 Jul 04:55
0c52793
Compare
Choose a tag to compare

Description

This release introduces support for QueryRequest::Wasm for interchain account queries. All wasm queries are supported except for WasmQuery::CodeInfo due to the response size. This feature requires the counterparty chain to be on wasmd v0.52+.

All Changes

  • chore: v0.6.0 release chores by @srdtrk in #124
  • imp(e2e): regenerated message definitions and query clients using go-codegen v0.2.5 by @srdtrk in #125
  • fix(e2e): diagnostics uploads by @srdtrk in #127
  • feat: allow wasm queries by @srdtrk in #131

Full Diff: v0.6.0...v0.6.1

v0.6.0

18 Jun 18:27
5a65b07
Compare
Choose a tag to compare

Description

This release's flagship feature is the support for interchain account queries! Now you can send cosmwasm_std::QueryRequests to be executed in the host (counterparty) chain as long as the counterparty chain is on ibc-go v7.5+. Read more in the documentation or README.md. This release also contains other API and state breaking changes such as:

  • Removal of support for proto3json encoding.
  • Dropping support for CosmWasm v1.3 (since it reached EOL)

See the full CHANGELOG for more.

v0.5.0

05 Feb 18:52
bc30f22
Compare
Choose a tag to compare

Description

In this release;

  • I added support for UNORDERED ICA channels which is supported if the counterparty chain is using ibc-go v8.1+.
  • A added a ExecuteMsg::CloseChannel which is supported in all versions.
  • The channel can now be reopened with different parameters such as ordering using ExecuteMsg::CreateChannel. (This means you can upgrade your ordered channel to unordered by simply closing the channel and then creating a new channel.)

v0.4.2

28 Jan 12:19
ed62894
Compare
Choose a tag to compare

Description

This release add inline docs to the enum variant injected by the proc macro introduced in v0.4.1. This is because external contracts using the macro will experience compiler errors if they have #![deny(missing_docs)]. (#66)

v0.4.1

27 Jan 15:25
ef7cd26
Compare
Choose a tag to compare

Description

This release only concerns external importers of the contract.
Added a new proc macro helper that injects the callback msg to the ExecuteMsg of the external contract. (#61)

Inspired by dao-dao-macros.

v0.4.0

26 Jan 23:49
7318eba
Compare
Choose a tag to compare

Description

In this release, I've focused on solidifying the API and maintenance. Underlying chain's CosmWasm requirement is raised to v1.3+ since v1.2 has reached end of life. This means I've added support for a CosmWasm v1.3 specific CosmosMsg which is DistributionMsg::FundCommunityPool in ExecuteMsg::SendCosmosMsgs.

Other notable changes include:

  • InstantiateMsg's channel_open_init_options field is now required. (#53)
  • CallbackCounter is removed. (#44)
  • Relayers cannot initiate opening channels anymore. (It must be initiated by the contract upon instantiation and by ExecuteMsg:CreateChannel) (#53)

See CHANGELOG.md for a full list of changes.

v0.3.0

30 Dec 10:53
7de3ddd
Compare
Choose a tag to compare

Description

In this release, I've added support for sending an array of cosmwasm_std::CosmosMsg to the contract for it to be converted to an ICA transaction. In CosmWasm contracts, CosmosMsgs are used to execute transactions on the chain that the contract is deployed on. In this contract, we use CosmosMsgs to execute transactions on the counterparty chain. This is done by converting the CosmosMsgs to an ICA tx based on the encoding of the channel. The ICA tx is then sent to the host chain.

Applications

As a sidenote, I've submitted an application to the Injective hackathon that uses this project as a dependency. My build is an NFT collection where each NFT controls an account on the counterparty chain, this is the demo video. Please upvote the build if you can (you can login to dorahacks through github)

Other Changes

This admin management of this contract is now using cw-ownable from cw-plus-plus.

v0.2.0

09 Nov 17:53
2fdc401
Compare
Choose a tag to compare

Description

In this release, this contract became usable in production since all the logic needed for testing was moved to a secondary testing contract. This is not to say that this contract should be used in production since it is not yet audited.

Changes:

  • External contract callbacks were added: Now contracts can be registered during instantiation to receive callbacks upon channel creation and packet lifecycle events.
  • Removed the predefined action execute message: This was for testing and is now moved to our new testing ica-owner contract.
  • Library feature was removed: Now, external contracts that want to use this contract as a library don't need to import it with the library feature. They just need to disable the default features.

v0.1.3

28 Oct 16:43
7ece8a6
Compare
Choose a tag to compare

This release gives the contract the ability to initiate the channel creation itself, instead of giving this responsibility to the relayer. The channel creation now begins automatically with InstantiateMsg if the required optional parameters are provided.

In case the channel creation handshake which started from InstantiateMsg cannot be completed, or the channel times out. You can retry creating a channel with the ExecuteMsg::CreateChannel. See README.md for more details.

Thanks to @CyberHoward for this idea.