CosmWasm: WebAssembly smart contracts for the Cosmos SDK

The framework underneath Cosmos ecosystem contracts

CosmWasm describes itself in one line as WebAssembly smart contracts for the Cosmos SDK, and that phrase contains the whole scope. It is not a blockchain and it is not a general purpose smart contract runtime for every chain in existence. It is the part that lets a Cosmos SDK based chain execute contracts that were compiled to WebAssembly, written in Rust.

The topic tags on the repository, cosmos-sdk, rust, smart-contracts and webassembly, tell you the same thing from the other side. The addressable audience is contract authors targeting that ecosystem and the engineers who run the execution environment on the chain side.

The project is hosted at cosmwasm.com, the licence is Apache-2.0, and the repository is not archived with the last push on 2026-10-09. The published releases show the shape of a mature component that many chains depend on: v2.3.6 and v2.2.11 were both published on 2026-10-09, and v3.0.11 a day earlier on 2026-10-08.

What sits in the repository root reflects the maturity too. Alongside the usual Cargo.toml and Cargo.lock there is a CHANGELOG.md and a separate CHANGELOG-pre-1.0.0.md, a MIGRATING.md, a SEMANTICS.md that pins down what the execution environment guarantees, an IBC.md for the interchain communication side, a SECURITY.md, a NOTICE file and a deny.toml for dependency policy.

The crate table is the documentation you actually need

The README's centrepiece is a table of the eleven Rust crates maintained in the repository, and it has a Usage column that tells you immediately which one you are allowed to depend on.

For contract development, the table lists cosmwasm-check, cosmwasm-schema, cosmwasm-std and cw-schema. cosmwasm-std is the standard library every contract author uses, cosmwasm-schema and cw-schema relate to generating and consuming JSON schemas, and cosmwasm-check is listed for contract development, and the name suggests a tool you run against a compiled contract to see whether it will pass the chain's checks.

For host environments, there is exactly one entry, cosmwasm-vm, and that is the crate for the engineers building the chain side, since the host is what executes the WebAssembly.

Everything else, namely cosmwasm-core, cosmwasm-crypto, cosmwasm-derive, cosmwasm-schema-derive, cosmwasm-vm-derive and cw-schema-derive, is marked internal use only. That is the most practically useful line in the table, because it tells a contract author that the derive macros and the core types are not part of the stable surface they should be building on.

Each row also links to the crate's page on crates.io, to its documentation on docs.rs and to a coverage badge, so the whole dependency decision can be made from the README without leaving it.

The coverage badges are not uniform, and that is informative

The coverage column deserves a closer look, because the numbers vary a lot and the pattern matches the usage categories.

cosmwasm-check carries 98%, 100% and 100% across the three figures shown in its badge. cosmwasm-crypto shows 81%, 84% and 92%, and cosmwasm-derive shows 84%, 85% and 94%. cosmwasm-schema is lower at 61%, 47% and 65%, and cosmwasm-core, marked internal use only, shows dashes for all three rather than a number.

Two things follow from that. The dashes are not a failure, they are a statement that no coverage figure is published for that crate, so a reader should not treat an absent number as a poor one. And the crates at the top of the table, the ones you depend on from the outside, are the ones with the most attention behind them, while the schema crate with the lowest numbers is still the one you will lean on when you publish a contract interface.

The three figures in each badge are separate measurements rather than a single headline number, and the repository does not explain in the README what each one covers. Whether that matters to you depends on how much weight you put on a coverage percentage as evidence, but it is worth knowing that the numbers exist and that they are not uniform before you infer anything from a single crate.

The workspace excludes the contracts directory on purpose

The root Cargo.toml is short and tells you how the repository is organised.

[workspace]
members = ["packages/*"]
exclude = ["contracts"]

resolver = "2"

[workspace.package]
version = "3.1.0-dev"
edition = "2021"
license = "Apache-2.0"
repository = "https://github.com/CosmWasm/cosmwasm"

The members glob is packages/*, which is where the eleven crates live, and the contracts directory is excluded from the workspace entirely. That exclusion is a deliberate signal. The contracts directory holds the example contracts used for testing, and keeping them out of the workspace means they are not built as part of the crate set and do not constrain the dependency versions the published crates resolve to.

The dependencies section makes the same point in a different way. Every internal crate is wired up with a path dependency rather than a version from crates.io, so the crates in this repository always build against each other:

[workspace.dependencies]
cosmwasm-core = { path = "packages/core" }
cosmwasm-crypto = { path = "packages/crypto" }
cosmwasm-derive = { path = "packages/derive" }
cosmwasm-std = { path = "packages/std", default-features = false }
cosmwasm-vm = { path = "packages/vm" }
cw-schema = { path = "packages/cw-schema" }
cosmwasm-check = { path = "packages/check" }
schemars = "0.8.4"
serde = { version = "1.0.192", default-features = false, features = ["alloc", "derive"] }
serde_json = "1.0.140"
thiserror = "1.0.26"

Note that cosmwasm-std is pulled in with default-features = false, which is the pattern for a library meant to be used in a no_std context, and the external dependency set is deliberately small: schemars for schema derivation, serde and serde_json for serialisation, and thiserror for error types. The edition is 2021 and the workspace version reads 3.1.0-dev, which tells you the main line is already in development toward 3.1.

Three release lines move at once

The three most recent tags, v2.3.6, v2.2.11 and v3.0.11, were published within about a day of each other in October 2026, and that is the shape of a project carrying parallel maintenance branches rather than a single line of releases.

For a chain team this is a decision with a cost. You do not want to be on the 2.2 line when the ecosystem has moved to 2.3, and you do not necessarily want to jump to 3.0 either, because a major version is where breaking changes live. The practical questions are which line receives the fixes you need, and how long each line will exist.

The repository gives you the tools to answer the second question rather than guessing. MIGRATING.md is the document for changes between versions, SEMANTICS.md describes the execution guarantees the environment provides, and the CHANGELOG.md and CHANGELOG-pre-1.0.0.md together record the whole history, with the pre-1.0 file kept separately for the era when the API was still moving fast. IBC.md covers the interchain communication part of the story for anyone building a contract that talks across chains.

The version numbers in the crates themselves are the ones that matter for a contract. cosmwasm-std and cosmwasm-schema are the crates a contract author depends on, and their versions move with the release train, so the version of the standard library you build against is effectively the version of the chain's host you need.

Contract side or host side: pick the crate that matches your job

The Usage column in the crate table draws a line that is worth making explicit, because it is the choice that determines how you should read this repository.

If you are writing a contract, your dependency is cosmwasm-std, and cosmwasm-schema or cw-schema if you publish a JSON schema for your messages, and cosmwasm-check if you want to validate a compiled contract against the chain's requirements before you submit it. Your relationship with the framework is that of an application programmer: you write Rust, compile to WebAssembly, and the chain runs it.

If you are building the chain side, your dependency is cosmwasm-vm, the host environment crate, and the internal crates are the machinery underneath it. The difference in approach is substantial. The contract side never runs the WebAssembly itself, it produces a module and trusts the host, whereas the host side is what decides how a module is instantiated, what memory it may use, how it is called, and what the execution environment guarantees, which is what SEMANTICS.md exists to describe.

A third option sits between the two. cosmwasm-check is listed under contract development rather than host environments, which suggests it is aimed at the author who wants to know whether a contract will pass before deploying, using the same rules the host applies. That is a useful tool, and it is the kind of thing that saves a failed deploy.

Editorial conclusion

Adopt CosmWasm if you are writing a contract for a Cosmos SDK based chain and want the typed Rust surface, the schema tooling and a host implementation that already exists, and if you are ready to track a release line deliberately. Do not adopt it as a general smart contract platform outside the Cosmos ecosystem, and do not expect the crate set to be uniform in quality, since the coverage figures in the README differ sharply between them. Verify first which of the three published release lines you should pin, read MIGRATING.md and SEMANTICS.md before upgrading across a major version, and check that your chain's host runs the cosmwasm-vm version you have built your contract against.

Frequently asked questions

Official sources

1. CosmWasm/cosmwasm on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases