cw-plus: reference CosmWasm contracts and specifications

Reference contracts, with the caution above them

cw-plus describes itself with one line: real-life smart contracts under open-source licenses.

And then there is the caution, which comes before anything else in the README. None of these contracts have been audited, and no liability is assumed for the use of this code. The smart contracts in the repository are provided as is, without any warranty or liability, just to help you start your own projects, and the README points at the security policy for more details.

That is an unusual and welcome thing to find in a smart contract repository, because the opposite is more common. The contracts here are examples, and the repository says so in the first paragraph, which means the artefact to take from it is the code rather than a deployed instance.

The stated purpose follows: it is a collection of specification and contracts designed for use in real-life scenarios, designed as examples of how to solve real-world use cases and to provide a reusable basis to build many custom contracts.

So the value is in the second half of that sentence. A reusable basis. The specifications are the standard interfaces, and the example contracts are the implementations of them that you can read, fork and specialise.

The licence is Apache-2.0, the primary language is Rust, and the default branch is main. The releases are v1.1.2 in November 2023, v2.0.0-rc.0 in March 2024 and v2.0.0 on 2024-03-26, and the last push to the repository was on 2026-06-26. There is a NOTICE file beside the LICENSE, which is the expected arrangement for an Apache-2.0 project that carries third party code.

The four specifications and the eight contracts

The README has two tables, one for the specification crates and one for the contracts, and each row links to crates.io, to the docs and to a coverage badge.

The specifications are cw1, cw3, cw4 and cw20. cw1 is the addressing and capability interface, and it is the one everything else depends on. cw3 covers multisig and verification schemes, and it is what a wallet contract is built on. cw4 is the staking interface. cw20 is the token interface, the one everybody has heard of. Each one is published on crates.io with the generated API documentation on docs.rs, and each carries the same codecov badge pointing at the repository's coverage graph.

The contracts are the implementations. There are eight of them: cw1-subkeys, cw1-whitelist, cw3-fixed-multisig, cw3-flex-multisig, cw4-group, cw4-stake, cw20-base and cw20-ics20. Each one has a downloadable compiled artifact attached to a release, the release v0.13.4 for all eight, so you can inspect the actual wasm rather than only reading the Rust.

Two names in that list carry most of the design.

cw20-base is the base token contract, and in the workspace manifest it is declared with the library feature enabled, which is the CosmWasm convention for a contract that is also usable as a library. The same pattern is applied to cw1-whitelist, cw3-fixed-multisig and cw3-flex-multisig. What that means in practice is that you can depend on cw20-base as a normal Rust crate, inherit its message handling and storage, and add your own messages to it, rather than copying its source into your own repository and maintaining the copy.

cw20-ics20 is the interchain token contract, the ICS-20 specification for tokens that move between chains. And the two multisig contracts are a pair rather than a pair of alternatives: one with a fixed set of signers and one with a flexible threshold that can change over time.

The ecosystem has been split into separate repositories

The README carries three notes about code that used to be here and is not any more, and they explain the shape of the current repository.

First, cw2 and controllers have been moved to the cw-minus repository and can be followed there. Second, cw721 and cw721-base have been moved to the new cw-nfts repository, which is the NFT standard and its base contract. Third, most of the cw20-* contracts besides cw20-base have been moved to the new cw-tokens repository.

So cw-plus is now the part of the CosmWasm contract library that holds the core interfaces and a handful of reference implementations, and the specialised standards live in their own repositories where they can be versioned and adopted on their own schedule.

There is also a note that matters for anybody following the project: they are not running public testnets any more. The link to the testnet instructions is still in the README, but the sentence says the project is not running them.

For an adopter the practical consequence is that a cw20 token implementation is not in this repository any more except for the base contract, and the cw721 NFTs are somewhere else entirely. If you are starting a token or an NFT, you are working with cw-tokens and cw-nfts, and this repository is where you find the specification and the base contract to build on.

The workspace, and a release profile aimed at reproducible wasm

The Cargo manifest shows the structure and, in the release profile, the priorities.

The workspace is two globs:

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

resolver = "2"

So packages/ holds the specification crates and contracts/ holds the contract implementations, and the workspace version is 2.0.0. The dependency list is short and pinned to the CosmWasm ecosystem: cosmwasm-schema and cosmwasm-std at 2.0.2, and cw2, cw-controllers, cw-multi-test, cw-storage-plus and cw-utils all at 2.0.0, with schemars for the JSON schema generation, thiserror for errors and serde for serialisation.

The release profile is the interesting part:

[profile.release]
rpath = false
lto = true
overflow-checks = true
opt-level = 3

Overflow checks are left on in release. That is unusual, because the usual advice for a wasm contract is to turn them off for speed, and they cost a runtime check on every arithmetic operation. The reason to keep them is that a contract that overflows is a contract that loses funds, and the gas cost is small compared with the cost of the bug.

Link time optimisation is on, rpath is off, and debug info and debug assertions are disabled, which is what you want in a small artefact.

And then there is a per-package profile for each of the eight contracts, setting codegen-units to 1 and incremental to false. A single codegen unit means the compiler optimises the whole crate as one unit, which is slower to compile and produces smaller and faster wasm. Incremental compilation off means the build is not caching state between runs, which is what you want when the artefact has to be reproducible.

Those two settings, repeated for every contract, are a small piece of evidence that the wasm artefacts are meant to be reproducible, and reproducibility is a property a smart contract repository should care about.

The files around the code, and the security policy

The repository has more than a Cargo manifest, and the extra files describe how the project is meant to be used.

CONTRACTS.md is the catalogue of the contracts, PATTERNS.md collects the design patterns the implementations follow, and MIGRATING.md records how to move between versions, which is what you read when the workspace version moves from 1.x to 2.0.0. CHANGELOG.md and CONTRIBUTING.md are the usual two, and SECURITY.md is the one the README points at from the caution at the top.

That last file matters more than its size suggests. The README's caution tells you that the contracts are unaudited and that no liability is assumed, and it points at the security policy for the details. So the project has a documented way to report a problem with its code, which is a different thing from a claim that the code is safe, and the distinction is the honest one for a repository of unaudited examples.

The NOTICE file is the other one to know about. With an Apache-2.0 licence and code that grew from other projects, the NOTICE file records what has to be attributed if you redistribute the artefacts, and it is the file to read before you ship a contract built on these crates.

Then there are the directories: contracts/, packages/, scripts/ and .github/, plus a .taskcmd file, which is the configuration for the task runner the project uses to automate the repetitive steps across the workspace. For a repository with this many crates and contracts, automating the version bumps, the schema regeneration and the release artefacts is the difference between a project that can be upgraded and one that cannot.

Where cw-plus is the wrong tool

There are clear cases where this repository is the wrong place to start, and the first one is about what the contracts are.

They are examples. The README says they are provided as is, without warranty or liability, and that they are there to help you start your own projects. A contract holding value needs an audit of the specific code that will hold it, and an audit of an example is not an audit of your contract. So the sensible use is to read the code, understand the pattern, and write your own, possibly inheriting from the base contract through the library feature.

The second limit is the scope. The token contracts other than cw20-base, the NFT contracts and the controllers are not here any more, and each of those has its own repository and its own release cadence. If what you need is a cw20 token, you may spend more time assembling the right set of crates from cw-tokens than reading anything in this repository.

The third is the operational side. These are contracts, not applications. There is no deployment tool, no indexer and no monitoring, and the README says the project does not run public testnets, so there is no shared environment to deploy to while you develop.

The alternative approach is to start from the specification alone and implement it, which for cw20 means writing your own token contract from the interface definition. The difference in approach is that implementing from the specification gives you code you fully understand and no inherited behaviour you did not write, while inheriting from cw20-base saves the work of handling the standard messages and the storage layout, at the cost of depending on a crate whose code you have to read anyway. The base contract is worth reading either way, because it is the reference implementation of the standard.

Editorial conclusion

cw-plus suits a CosmWasm developer who wants a working reference implementation of a standard rather than the specification alone, and who reads the source rather than treating the contract as a black box. It does not suit a team that wants to deploy an audited contract, since the README says plainly that nothing here has been audited and that no liability is assumed, and it does not suit a project that needs the parts of the ecosystem that have been split out into separate repositories. Check three things before you build on it: that the specification you need is still in this repository, since cw2 and controllers moved to cw-minus, cw721 moved to cw-nfts and most of the other cw20 contracts moved to cw-tokens, that you read SECURITY.md before deploying anything to a chain with real value, and that you can rebuild the wasm yourself, since the workspace sets a release profile with link time optimisation and overflow checks enabled and a single codegen unit for each contract. The last push to the repository was on 2026-06-26 and the newest release is v2.0.0.

Frequently asked questions

Official sources

1. CosmWasm/cw-plus on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases