CW3 multisigs

Blockchain actions are generally authenticated by using a single cryptographic signature, either from a hot wallet (something on a computer with an internet connection, aka software wallet) or a cold wallet (something on a device like a Ledger or Trezor, aka a hardware wallet). Hot wallets are very convenient, but run the risk of compromise of the key due to user error, wallet bugs, system compromise, etc. Cold wallets are more secure, but ultimately leave all decision making power in the hands of a single person.

If you're using blockchain for maintaining your own, personal funds, this often makes sense. But for companies and projects that want to maintain a treasury or control the administration of their smart contracts, trusting a single person is dangerous. Users can be hacked through social engineering, themselves be nefarious, or fall victim to the five-dollar-wrench attack. To combat that, many projects use multiple signatures--aka multisig--to control their treasuries and secure their contracts.

One approach to multisig is to use something like Cosmos native multisig. Many chains include some kind of native mechanism for this. However, in practice, this is often cumbersome to work with. In Cosmos in particular, this usually requires working with command line tools and sharing messages manually for signing.

Another common approach, and the one we tend towards, is using a CW3 multisig.

What is CW3

CW3 is the third CosmWasm standard, documented in the cw-plus repo. It defines a standard for a contract, which you can think of as an API. It also provides concrete implementations, which are generally what people end up using.

CW3 is a smart contract implementation of multiple signatures. All activities occur on the blockchain, and do not require passing and signing messages separately. Additionally, it's relatively easy to provide a nice web interface for it. As long as your chain supports CosmWasm, it's our recommended choice.

You can check out the ExecuteMsg and QueryMsg of CW3 to see more details of how it works.

Signer count

Each CW3 has a configuration of who can sign and how many signatures are needed for a proposal to pass. The most common, and simplest, are configurations like "3 of 5", meaning that there are 5 signers allowed on a contract and 3 of them are required to pass a proposal. Contracts can be as customized as you'd like though. You can have rules like "I need to have 1 vote from group A and two votes from group B," or any other configuration you can think of.

In practice, all wallets we've set up have been one of these simple approaches. 2 of 3 is considered the minimal multisig, and 3 of 5 is probably the most common.

Fixed vs flex

The cw-plus repo contains two basic approaches to setting up a CW3:

  1. Fixed: when you create the contract, you give it a hard-coded list of members and their voting power. After that, they can never be changed.
  2. Flex: first you create a CW4 contract, which maintains a group of users, and then create a CW3-flex that refers to that CW4.

Both contracts have their place, but we've been leaning towards flex. Our cosmos-rs CLI tool provides a cw3 subcommand that does the following:

  • Creates a new CW4
  • Creates a new CW3-flex that refers to that CW4
  • Updates the CW4 to use the new CW3-flex as its admin

In this way, the members of the contract can self-manage adding and removing members as needed.

Proposal process

The process for a proposal is:

  1. One of the members creates a new proposal. This will include a title and description, as well as a list of messages. You can do anything from sending coins to executing smart contract messages.
  2. Other members can vote yes, no, or abstain on the proposal.
  3. If enough people vote yes, the proposal is passed. At that point, anyone (even non-members) can execute the proposal.

Web interface

Manually interacting with a CW3 contract is tedious. You need to query the list of proposals, query each proposal for its vote status, and manually construct messages for proposing, voting, and executing. Instead, it's common to use a web interface. We've set up our own website for doing this: FP Block Cosmos GUI.