Cw3 spec

[ethanfrey]

Closes #79

Defines a spec we can implement for various voting contracts. Happy for reviews on this interface.

There are at least 3 different cases we want to cover in this spec:

• K of N immutible multisig. One key proposes a set of messages, after K-1 others approve it, it can be executed with the multisig address.
• K of N flexible, mutable multisig. Like above, but with multiple contracts. One contract stores the group, which is referenced from multiple multisig contracts (which in turn implement cw3). One cw3 contracts is able to update the group content (maybe needing 67% vote). Other cw3 contracts may hold tokens, staking rights, etc with various execution thresholds, all controlled by one group.

Maybe this can fit in as an extension of this interface:

• Token weighted voting. People lock tokens in a contract for voting rights. There is a vote threshold to execute messages. The voting set is dynamic. We may also want to support clear YES/NO votes and quora not absolute thresholds

[ethanfrey]

@webmaster128 happy if you want to take an early look at the README and comment. I will be defining types for this.

[webmaster128]

Some initial thoughs. But looks good overall

[webmaster128]

Above in

• K of N immutible multisig. One key proposes a set of messages,
  after K-1 others approve it, it can be executed with the
  multisig address.

you assume that the Propose is the first approval. But I'd say it can be a valid case that the composer/proposer is not one of the signers but some type of moderator.

[ethanfrey]

Should I specify that Propose does not include a yes vote from the sender if applicable?
Specify that it does only if the proposer is in the valid voter set?
Or leave it unspecified?

I'd like to specify this, as then wallets know if they need to propose and vote, or just propose.

[webmaster128]

I think it is clean to make propose and vote two messages. It would be nice if they could be sent in one tranaction, but then we can't rely on execution data. However, this would work with client-side generated IDs.

[ethanfrey]

I defined it as the first in the README

[webmaster128]

All those schemas are only generated for T = Empty, so T cannot be used together with the schema files. If we want to stick with the custom T in CosmosMsg, I think we should remove the schemas here. Then only the implementations generate schemas, which either set T or actually use Empty.

(the same is true for the schemas in cosmwasm-std (packages/std/schema), which are kind of pointless)

[ethanfrey]

These work for generic queriers that don't support custom messages, and are actually the basis of most generic clients.

I would expect some custom contracts to add more and then we have custom clients that know that, but those would be chain-specific naturally, and this is the only set of schemas that would work over all contracts and all chains.