In the last couple of years the entire framework spanning across something like 30 repositories from chain integration to build tools was developed by 8–10 software engineers, supported by marketing, HR and operations colleagues. Together with our funding partners ICF, Neutron, AADAO and Axelar, we were able to secure the funding for H1 2025. Thank you for making that possible! This bought everyone involved valuable time to adapt to what is coming.

In the meantime, Interchain Labs decided to not host a CosmWasm maintenance team in-house. However, they collaborate with Neutron by funding CosmWasm maintenance efforts embedded into the Neutron team. Also Thorchain and Axelar signaled interest to contribute to CosmWasm’s ongoing maintenance.

From July onwards, the Confio team members Darek and Pino will be the first developers working on CosmWasm full time. Darek was focussed on MultiTest before and Pino is the maintaner of wasmd. They used the last couple of weeks collaborating with the rest of the team to gain knowledge of the entire stack. Darek and Pino become owners of the CosmWasm GitHub organization. The primary point of contact to them is the existing CosmWasm Telegram channel which is open for messaging again.

To reduce the maintenance burden for Darek and Pino, the Sylvia framework will be moved out of the CosmWasm organisation and is continued by the original author Bart as well as the long time Sylvia maintainer Jan.

Security wise, the Cosmos bug bounty program on HackerOne keeps the CosmWasm scope such that security issues can be reported there. The security contact at Confio will be removed.

What’s next for CosmWasm is not for Confio to decide anymore. Users need to come together and collaborate on priorities, roadmaps and funding. There are many things that could be done or would be great to have. But keeping up with Cosmos SDK and IBC updates, following the evolving Wasm standard as well as adapting to the Wasmer Singlepass license change are certainly on the agenda.

Over the years, many people suggested to release CosmWasm under a restrictive license. But this is something we never agreed with. Not only would it be a legal nightmare, harm the network effects and risk ICF funding. It would also be against the spirit of decentralized user owned systems and free innovation. Defending the Apache 2 license was a tool to create a meaningful piece of software that has the potential to outlive its original creators.

Confio brough CosmWasm into existence and made it grow 6 years old. As it moves forward past its 3.0 release, we’re proud of what’s been built — and excited to see where the community takes it next.

Confio ends CosmWasm maintenance was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

When we announced the purchase of 25% of Confio shares by Neutron last December, everything felt done. All parties were on the same page and we wanted to use the opportunity to get in an additional shareholder who deeply cares about Confio’s work and destiny.

However, it turned out the execution was not as straightforward as anticipated. Taxation questions, token valuation, as well as the complications around a multi-level shareholder structure in an international context delayed things for multiple months. Over time, circumstances and motivations changed. In hindsight, this is a good thing as we realized that we can collaborate well without being shareholders. A partnership built on trust, meaningful conversations and appreciation for each other’s work emerged. As a result, Simon from Confio and Avril from Neutron agreed on July 11th to not execute the planned share deal.

Looking ahead

Co-Founder and long-time CosmWasm maintainer Simon Warta remains committed to permanent leadership and development of the company.

Instead of looking for other buyers or investors, the founding team is on a path toward self-ownership for Confio. The company should exist in its own right, independent of who founded it originally. We want corporate governance to be decoupled from economic ownership, allowing profits to remain within the company. Following famous examples like Bosch or Patagonia, Confio aims to be self-owned and not for sale. This will be a multi-year endeavour. The first step has been completed by adjusting the articles of the company as well as an initial buyback of 13 % of the GmbH shares.

So, whilst we may not become joint shareholders, Confio and Neutron share a commitment to continue working together on exciting projects such as CosmWasm and the tooling ecosystem around it.

Confio remains in the hands of its founders and aims for self-ownership was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

While severity is a global measurement across all users of CosmWasm, this is certainly more important to fix for permissionless chains than chains that only accept codes from pre-approved entities. So, while being non-critical, we recommended permissionless chains to perform an upgrade in the week of the release.

What this patch does is two things:

1. Increase the gas for breaking operations (loop, br, call, return, …) from 170 to 1610
2. Reduce the gas for everything else from 170 to 115

This is due to the additional metering operations that will be performed for breaking operations. To put it simply, a mispricing had been fixed to readjust for the target of 1 Teragas/second.

This fix has been well prepared, benchmarked, tested and backported to the 1.5, 2.0 and 2.1 release series of CosmWasm.

A couple of hours after the release, two teams reached out wondering why the gas usage did not change after the release or why patched and unpatched nodes are still in consensus — very strange. We checked a few obvious things like ensuring gas_used is part of consensus in CometBFT or the gas changes are high enough to be visible in Cosmos SDK gas. Even for the very experienced team at Confio there was no obvious way to debug.

After some time we received the crucial hint from Sergey Golyshkin (Neutron team): the gas is part of the contract compile step and may only be applied during code upload. This was it! All compiled contracts in the cache folder ~/.myd/wasm/wasm/cache continued to run with the old gas pricing instead of the new one. As a result the patch was only applied for new codes or after re-compilation. The second happens whenever the module cache is invalidated, e.g. by spinning up a new node from snapshot without the cache directory, by manually deleting the folder or by invalidating it in the cosmwasm-vm codebase. This is why we labeled the patch as incomplete, not wrong. It was good but there was this missing detail.

Once understood, we quickly released a set of follow-up patches the same day which invalidated all old caches such that no matter what cache the nodes have, they now all run on the same logic.

But why?

The patch we released worked and behaved perfectly fine in various levels of testing, such as unit and integration tests in the cosmwasm repo as well as in Go land in wasmvm and wasmd. What all those tests have in common is that their caches do not live longer than the test itself. They started fresh where a node in the wild does not.

We do not maintain testnets anymore. While being part of our proposal to the ICF for 2024 was to run and maintain a Vanilla CosmWasm testnet, this has not been prioritized. Applying the patch there first might have sped up the discovering, but it would not be a guarantee for success as such networks typically have a small amount of traffic.

In Open Source, security patches are usually released to the general public in one go to give everyone equal access to a patch. Applying the patch to a public testnet first would provide significant advantage for an attacker to analyze the patch and craft an attack. Running a private testnet might help but is something not in scope right now. Also having to maintain a shadow stack in private repos including cosmwasm-vm, wasmvm and wasmd and have a completely separate CI for this is a lot of work — maybe worth it, I don’t know.

Lessons learned

• Getting caching right is hard. We solved similar problems in the past before and will solve it here again, but there is a cost to pay for enhanced execution speed.
• Wasmer metering is baked in at compile time
• There is a class of issues you just don’t find in isolated unit tests. Higher level tests are not only needed to find uncovered code but also to find such things.

To wrap up, yeah, it was bad. But the problem was fully understood and patched the same day it popped up. It will only lead to a more robust solution from here. So time to continue building.

The incomplete gas patch and why it caused consensus failures was originally published in CosmWasm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Shiny new things

Major releases are for breaking, but we also have a few nice additions that make CosmWasm more complete and convenient for its users.

Error messages in replies

Whenever an error is coming from a smart contract, we know it is deterministic. In those cases, we now skip redacting the error in wasmd and preserve the full text in the reply (SubMsgResult::Err). While this is great for debugging and logging, developers should not make assumptions about the text contents of those errors, which might be changed by the other contract.

Grpc query

The Grpc query is a protobuf-in protobuf-out replacement for Stargate query. This way, responses can be processed more efficiently and use a well-specified encoding. As before, chains have to specify which queries they want to allow.

Submessage payloads

A SubMsg can now get a binary payload that is returned untouched in the reply. This allows you to pass context from the original call to the replay without having to store it to state.

Message responses

A SubMsgResponse now has msg_responses next to data. In there the message execution results are stored as a list of protobuf Anys. This is needed for getting the data on chains running Cosmos SDK 0.50.

Optional acknowledgments

In ibc_packet_receive/IbcReceiveResponse, the acknowledgment is now optional. This advanced feature allows contracts not to write them. Some exotic protocols might want to never create acknowledgments. But this change primarily prepares for asynchonous acknowledgments where the acknowledgment is created later than the receive call (not yet implemented).

memo field in IbcMsg::Transfer

The long-awaited memo field is here, adding the possibility to pass arbitrary text along the ICS-20 token send. This is also required for packet forward middleware, IBC hooks, or the upcoming ADR-8 implementation. Please note that chains with wasmvm 1.x ignore this field if set.

Good to know

Changes you might want to be aware of:

• The CosmWasm gas values were reduced by a factor of 1000. This does not affect the measurements in Cosmos SDK gas, which is used in almost all interfaces.
• CosmosMsg::Stargate was renamed to CosmosMsg::Any without changing semantics.
• The JSON serialization of u128/i128 changed from string to numbers. Use Uint128/Int128 instead to keep the string representation.
• MockApi now uses and requires bech32 as the human-readable address format in order to simplify the testing flow. Use api.addr_make(“some name”) to create testing addresses.
• A new default “std” feature in cosmwasm-std must be enabled. Otherwise, a no_std build is attempted. But at this point no_std support is not yet fully implemented.

Removed

Time to say goodbye to things not relevant anymore today:

• The cosmwasm-storage crate. Use cw-storage-plus for types storage access or cosmwasm-std for raw access.
• Addr and String/&str cannot be compared directly anymore for safety reasons. It’s recommended to convert both sides to an Addr first.
• Mixed type arithmetics were removed (especially multiply Decimal with Uint*). The functions Uint{128,256}::mul_floor or Uint{128,256}::mul_ceil can be used instead.

Compatibility and upgrading

Existing contracts compiled with cosmwasm-std ^1.0.0 continue to run as before on chains with wasmvm 2.0. Contracts compiled with cosmwasm-std ^2.0.0 do run on chains with wasmvm 1.x or 2.0. This way, it does not matter in which order you upgrade the chain or contracts.

If you enable the cosmwasm_2_0 feature of cosmwasm-std, the contract will require 2.0 features on the chain and unlock some of the new features above.

A migration guide for contract developers is here: MIGRATING.md.

Integration on-chain

CosmWasm 2.0 will be shipped as part of wasmd 0.51. The integration work for the Wasm Light Client in IBC-Go has started already.

A migration guide for wasmvm users is here: MIGRATING.md.

Acknowledgments

We’d like to take the opportunity to thank everyone who contributed to this major release with ideas, feature requests, user stories, and code. Many people inside of Confio contributed to the release one way or another but the majority of the work was done by Chris — thank you!

As part of the Interchain Stack, the ongoing maintenance and some well-defined features are funded by the Interchain Foundation in 2024. If you have specific needs that you want to see in upcoming CosmWasm releases, consider becoming a CosmWasm Subscriber and help us make the next major release possible.

CosmWasm 2.0 was originally published in CosmWasm on Medium, where people are continuing the conversation by highlighting and responding to this story.

As part of the planned roll-out of CosmWasm 2.0, it’s time to commit to end-of-life dates for the current versions to allow everyone to plan accordingly.

To make upgrading to 2.0 as convenient as possible, we turn version 1.5 into a Long Term Support (LTS) version. This means we will support it for one year from this announcement until the end of January 2025. This includes security patches and other important fixes. No changes in the feature set are to be expected. Upgrades in the 1.5.x version range aim to be as easy to deploy as possible, trying to achieve non-consensus-breaking behavior in the majority of cases.

With 1.5 being well established on major networks, we don’t see a reason not to upgrade 1.4 -> 1.5. However, this is up to the chains, and we will support 1.4 for 6 more months until the end of July 2024.

To summarize this and our previous announcement, we have

• 1.5 (LTS): End of January 2025
• 1.4: End of July 2024
• 1.3: End of March 2024
• 0.x, 1.0–1.2: Unmaintained

We hope this plan works well for the majority of users. If not, let us know so that we can improve in the future.

CosmWasm 1.5 becomes Long Term Support (LTS) version was originally published in CosmWasm on Medium, where people are continuing the conversation by highlighting and responding to this story.

CosmWasm contracts use the BaseAccount type and ADR-028 module account addresses, ie. addresses in their own namespace. This ensure that no other keypair or module uses those addresses. An address collision is practically not possible since the sha256 algorithm is considered collision-resistant and we do not truncate the 32-byte output.

In Cosmos SDK however, with MsgCreateVestingAccount a feature was added long time ago that allows a non-owner of an address to set the account type of the address (to_address). This allows for address squatting, which is something we need to protect against. In CWA-2022-005 it is explained how address squatting can lead to Denial-of-service scenarios. The advisory also explains our mitigation strategy which aims to only accept BaseAccounts and prune other account types.

How to prune an account

In an ideal world, we could just call something like auth.deleteAccount(address) and delegate the logic of deleting an account to the SDK. However, such functionality does not exist. So we need to implement account pruning ourselves. Here we considered the following:

1. BaseAccount can be used for contracts. They don’t need to be pruned and their balance is preserved.
2. All types of vesting accounts are not supported as contract accounts. If we just deleted the vesting account, the bank balance would suddenly be unlocked.
3. Since the creation of vesting accounts on contract addresses is nothing that’s done in the regular use case of a blockchain, we need to assume that the vesting accounts are created and funded by an attacker.
4. Due to 2.+3. we decided to take away the funds by default, which can be done in multiple ways: (a) Burn, (b) Send to the community pool, or (c) Send to configured address.
5. Since a chain can have a large number of denoms, we only take away the original vesting denom and leave the rest untouched. This avoids a DoS attack by pruning becoming very expensive in terms of gas.
6. Account pruning should always succeed in order to avoid new DoS scenarios.

What’s the right™ way of taking away funds?

In Cosmos SDK we have supply tracking in the bank module as a feature for many years. This allows you to always read the available supply and both token issuance and burns are tracked. This burning approach is arguably superior to just sending the tokens to an account that has no keypair (such as 0x0 on Ethereum). For this reason, burning tokens has been chosen in the implementation that fixes CWA-2022–005.

It has come to our attention that some users consider burning inappropriate for their appchain and their tokenomics. What can be done here is to implement accountPruner in the wasm Keeper of wasmd with a custom implementation. This gives full flexibility to adapt the logic of the default VestingCoinBurner.

Feature request: Add token destination argument to NewVestingCoinBurner

In order for users to not worry about the full implementation of VestingCoinBurner we can make the token destination (point 4. from above) configurable in NewVestingCoinBurner. There an additional destination argument can be used to easily switch between 4.a, 4.b, 4.c.

If this functionality is still not flexible enough, accountPruner should be implemented differently, taking point 6 and CWA-2022-005 (address squatting) into account.

Changing the default

One reason for keeping the current behavior (burn tokens) by default is that it’s simple and clean, correctly keeping track of the supply. Another reason is that there are at least two other ways to burn tokens by an attacker, changing the total supply along the way:

1. Send tokens to a contract, which then uses BankMsg::Burn in CosmWasm. This is what the sink contract does here.
2. Use the new MsgBurn (Cosmos SDK 0.51+).

So for the time being we don’t see how a change of the default behaviour would be beneficial to the majority of users.

Conclusion

We are well aware that those multiple layers of mitigation strategies are confusing, hard to audit and reason about. But as long as this problem is not solved at its root (a non-owner being able to set an account type), we cannot avoid that.

We are happy to receive any feedback on the points discussed above in order to find the best solution for everyone.

Dev Note #5: Specifying how to handle funds when pruning a vesting account was originally published in CosmWasm on Medium, where people are continuing the conversation by highlighting and responding to this story.

For four years now, Confio created and maintained the CosmWasm smart contracting engine. A lot has been achieved in the meantime from safe and secure contracting framework over rich cryptography APIs and tight chain integration to a community of dozens of chains powered by CosmWasm. The technology became an integral part of Cosmos, and this has recently been acknowledged by the ICF, including CosmWasm into the Interchain Stack. Confio also built custom software around CosmWasm, such as the Proof of Engagement consensus system for the Tgrade blockchain, a lending protocol on top of Osmosis (which was not launched), the first version of the decentralized exchange WYND, and most recently, the shared security solution Mesh Security for Osmosis. However, with the commitments of the Cosmos Hub proposal 103, the ICF, and contributions of various supportive chains in 2023, we could focus on the core components of CosmWasm. The feature releases 1.2, 1.3, 1.4, and 2.0, Cosmos SDK 0.47 and 0.50 support, various security patches, and improved tooling were made possible that way.

During all the market highs and lows since 2020, Confio was founded and managed by its 3 co-founders. We went through a lot of pain trying to open bank accounts, employ our team members in an international remote-only setup, looking for funding opportunities, and never stop shipping. Today, Simon Warta (Co-Founder and CosmWasm maintainer) is running the company.

Building infrastructure for such a long period of time is great, especially when the technology is appreciated and used by a broad community. But it also brings challenges when it comes to figuring out what is important, what is nice to have, and what is not needed. CosmWasm does what we envisioned it to do in 2020, but what’s next? How do we bring it to more chains and make existing integrations more powerful? At some point during this year, we started looking for some more direction and for both Confio and CosmWasm to try to find answers to those questions.

This brought us in contact with the team behind Neutron, a blockchain heavily relying on CosmWasm. In the conversations, we found a shared vision for CosmWasm: building Interchain smart contracts. We knew CosmWasm is the best tool for building IBC apps and it can only succeed if it is available on as many chains as possible. This creates the network effects in terms of connectivity but also education and tooling. It became clear that CosmWasm needs to remain free software. Together with Neutron, we are discussing the core roadmap and are exploring complementary offerings around services and tooling.

To strengthen the collaboration between Confio and Neutron, we worked out an acquisition of 25% of Confio’s shares. This enriches the conversation amongst shareholders by providing the perspective of a CosmWasm user and gives Neutron a significant voice in Confio’s direction. The management and team in Confio remain unaffected.

With this partnership, Confio preserves its independence and continues to serve all the chains that currently rely on it and hundreds more to come. We continue to work with our close partners, such as the ICF, Osmosis, Terra, Stargaze, Nym, DoraHacks, and we always welcome more. Together, we build a better CosmWasm for everyone.

Strategic partnership between Confio and Neutron brings CosmWasm to the next level. was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Telescope 1.0 and bigint

The npm packages @cosmjs/* version 0.32.0 upgraded their protobuf types to comjs-types 0.9.0. Those types are now generated using Telescope 1.0. This brings stronger type safety around non-nullable message fields, changes all usages of Long to bigint and removes the runtime dependency protobufjs. When upgrading CosmJS, please also upgrade comjs-types to 0.9.0 and adapt the codebase to use bigint. Shoutout to the entire Cosmology team for all the improvements to the code generation, which is critical for working with the Cosmos SDK.

Timeout height for transactions

sign/signAndBroadcast/signAndBroadcastSync and related functions now have an additional parameter to specify the timeout height. After this height, a signed transaction will be considered invalid by the chain. This can be used to ensure your transaction is either committed in a reasonable time or will never be executed. Kudos to Jan from Skip for this addition!

MsgTransfer memo support

The SigningStargateClient.sendIbcTokens API already contains a transaction memo. Creating support for the MsgTransfer memo in the same API would be too convoluted. In order to give used access to the full functionality, the wrapper function sendIbcTokens was now deprecated. Better use signAndBroadcast together with a MsgTransferEncodeObject instead from now on.

CometBFT 0.38 support

The package @cosmjs/tendermint-rpc now has a new Comet38Client in addition to Tendermint34Client and Tendermint37Client , supporting chains running on Comet BFT 0.38. This is the version needed for Cosmos SDK 0.50 chains. The function connectComet does the auto-detection of the backend and returns a CometClient union type, which means any of the three available clients.

Cosmos SDK 0.50 support

Building on the CometBFT 0.38 auto-detection, we now test CosmJS against Cosmos SDK 0.50, and it works well overall. There are a few caveats we found, like rawLog fields is unset now (use events instead), and a few Amino JSON messages do not yet work. But overall, it is working without changes to in the application needed order than the CosmJS upgrade. Please note that support for new features is not yet included but existing functionality will just work.

Other notable changes

• Amino JSON signing for MsgInstantiateContract2 was fixed
• Numeric values in key/value pairs during txSearch were fixed
• All gasWanted/gasUsed fields were changed from number to bigint

The full CHANGELOG is available here.

CosmJS 0.32 supports SDK 0.50 was originally published in CosmWasm on Medium, where people are continuing the conversation by highlighting and responding to this story.

CosmWasm 1.5 has been released, bringing support for floating points to the virtual machine and various additional math additions to the standard library.

Floats

In CosmWasm < 1.5, all float operations in the Wasm blob were denied. The reason for that is that floating point operations have certain ways of being non-deterministic. In Wasm, this particularly affects the binary representation of NaN, which can be different depending on the CPU, operating system, and other system conditions. Luckily Wasmer has a NaN normalization feature, which allows us to avoid this problem.

When the Wasm file was uploaded to the chain, it was scanned for float operations. Once a single operation was found, the upload was rejected. While this is the safe approach, it caused a lot of trouble for developers who used dependencies that make use of floats. In many cases, those instructions were never executed but prevented the upload. Finding the source of such operations can easily cost days and weeks of development time, leading to a frustrating experience. The other scenario is code that actively relies on floats. While finance math and cryptography typically don’t use floats, there are interesting use cases that can be explored with floats available, such as:

• bonding curves
• non-linear voting power
• games
• generative art

In ComsWasm 1.5, we not only enabled NaN normalization. We created a massive test suite that executes all known float operations over many different inputs and ensured to get the same hash across a variety of systems. This gives us the confidence that using floats in CosmWasm is safe.

This does not mean that floats are encouraged to be used for everything. Especially finance math should stick to decimals as you want to avoid 0.1 + 0.2 being 0.30000000000000004 in your app. Also, json-serde-wasm does not have float support right now, making floats in JSON messages unusable. This might change in the future, but you also might want to avoid doing that in order to not lose precision when communicating between different systems like Wasm contract <-> JavaScript client.

Standard library additions

The changes here affect cosmwasm-std and are available to all contract developers, no matter which version of CosmWasm runs on the chain.

More signed integers math

In 1.3, we introduced signed integers and now added a bunch of additional APIs for those, such as:

• abs/unsigned_abs
• checked_multiply_ratio and full_mul
• is_negative
• Various From and TryFrom implementations between signed and unsigned integer types

JSON encoders and decoders

Historically the struct to binary encoding in CosmWasm has always been JSON. But we are preparing for a future in which other encodings are usable as well, e.g. for more compact storage encoding. For this reason, encoding becomes more explicit:

• to_json_{vec,binary} replaces the old to_{vec,binary}
• from_json replaces the old from_{slice,binary}
• to_json_string was added for cases in which you need a String and don’t want to handle Binary -> String conversion errors that can never happen in valid JSON.

Signed decimals

SignedDecimal and SignedDecimal256 now complement Decimal and Decimal256 and allow storing negative values. Pretty straightforward.

For more details, check out the CHANGELOG. CosmWasm 1.5 will be embedded in the upcoming wasmd 0.44. All cosmwasm-std improvements can safely be used on chains running older versions of CosmWasm.

CosmWasm 1.5 was originally published in CosmWasm on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is CosmWasm 1.x?

When speaking about CosmWasm 1.x, we refer to a full stack of software, including:

• Rust crates cosmwasm-* 1.x
  (especially cosmwasm-std and cosmwasm-vm)
• Go project wasmvm 1.x

Support for 1.0 and 1.1 ends now

With the release of this article, we end support for CosmWasm 1.0 and 1.1, which were released in May and September 2022. The last patches they got fixed the stack overflow bug called Cherry.

Support for 1.2 ends on December 31st, 2023

CosmWasm 1.2 was released in January 2023 and superseded by 1.3 in July. It will remain supported until the end of the calendar year.

Support for 1.3 ends on March 31st, 2024

CosmWasm 1.3 was released in July 2023 and superseded by 1.4 in September. It will remain supported until the end of Q1 2024.

Other version

CosmWasm 1.4 and beyond is going to receive patches depending on their urgency. No guarantees are made for how long which versions will be supported. We try to find a healthy balance between convenience for chain development teams and the feasibility of backporting patches.

EOL for CosmWasm 1.0–1.3 was originally published in CosmWasm on Medium, where people are continuing the conversation by highlighting and responding to this story.