Update contract READMEs

Author: maurolacy

contracts/cw20-base/README.md

@@ -41,7 +41,7 @@ Basically, you just need to write your handle function and import
 `cw20_base::contract::handle_transfer`, etc and dispatch to them.
 This allows you to use custom `HandleMsg` and `QueryMsg` with your additional
 calls, but then use the underlying implementation for the standard cw20
-messages you want to support. The same with `QueryMsg`. You *could* reuse `init`
+messages you want to support. The same with `QueryMsg`. You *could* reuse `instantiate`
 as it, but it is likely you will want to change it. And it is rather simple.
 
 Look at [`cw20-staking`](../cw20-staking/README.md) for an example of how to "inherit"

contracts/cw3-fixed-multisig/README.md

@@ -1,7 +1,7 @@
 # CW3 Fixed Multisig
 
 This is a simple implementation of the [cw3 spec](../../packages/cw3/README.md).
-It is a multisig with a fixed set of addresses created upon initialization.
+It is a multisig with a fixed set of addresses created upon instatiation.
 Each address may have the same weight (K of N), or some may have extra voting
 power. This works much like the native Cosmos SDK multisig, except that rather
 than aggregating the signatures off chain and submitting the final result,
@@ -13,7 +13,7 @@ as updating the multisig set, different voting rules for the same group
 with different permissions, and even allow token-weighted voting. All through
 the same client interface.
 
-## Init
+## Instantiation
 
 To create the multisig, you must pass in a set of `HumanAddr` with a weight
 for each one, as well as a required weight to pass a proposal. To create
@@ -23,7 +23,7 @@ Note that 0 *is an allowed weight*. This doesn't give any voting rights, but
 it does allow that key to submit proposals that can later be approved by the
 voters. Any address not in the voter set cannot submit a proposal.
 
-## Handle Process
+## Execution Process
 
 First, a registered voter must submit a proposal. This also includes the
 first "Yes" vote on the proposal by the proposer. The proposer can set

contracts/cw3-flex-multisig/README.md

@@ -21,7 +21,7 @@ Cosmos SDK multisig, is that it aggregates the signatures on chain, with
 visible proposals (like `x/gov` in the Cosmos SDK), rather than requiring
 signers to share signatures off chain.
 
-## Init
+## Instantiation
 
 The first step to create such a multisig is to instantiate a cw4 contract
 with the desired member set. For now, this only is supported by
@@ -31,8 +31,8 @@ with the desired member set. For now, this only is supported by
 If you create a `cw4-group` contract and want a multisig to be able
 to modify its own group, do the following in multiple transactions:
 
-  * init cw4-group, with your personal key as admin
-  * init a multisig pointing to the group
+  * instantiate cw4-group, with your personal key as admin
+  * instantiate a multisig pointing to the group
   * `AddHook{multisig}` on the group contract
   * `UpdateAdmin{multisig}` on the group contract
 
@@ -43,7 +43,7 @@ self-deploying contract on-chain). (TODO: document better).
 When creating the multisig, you must set the required weight to pass a vote
 as well as the max/default voting period. (TODO: allow more threshold types)
 
-## Handle Process
+## Execution Process
 
 First, a registered voter must submit a proposal. This also includes the
 first "Yes" vote on the proposal by the proposer. The proposer can set

contracts/cw4-stake/README.md

@@ -21,15 +21,15 @@ be used for voting, nor claimed by the original owner. Only after the period
 can you get your tokens back. This liquidity loss is the "skin in the game"
 provided by staking to this contract.
 
-## Init
+## Instantiation
 
 **TODO**
 
 To create it, you must pass in a list of members, as well as an optional
 `admin`, if you wish it to be mutable.
 
 ```rust
-pub struct InitMsg {
+pub struct InstantiateMsg {
     /// denom of the token to stake
     pub stake: String,
     pub tokens_per_weight: u64,

contracts/cw721-base/README.md

@@ -16,10 +16,10 @@ Implements:
 The `HandleMsg` and `QueryMsg` implementations follow the [CW721 spec](../../packages/cw721/README.md) and are described there.
 Beyond that, we make a few additions:
 
-* `InitMsg` takes name and symbol (for metadata), as well as a **Minter** address. This is a special address that has full 
+* `InstantiateMsg` takes name and symbol (for metadata), as well as a **Minter** address. This is a special address that has full 
 power to mint new NFTs (but not modify existing ones)
 * `HandleMsg::Mint{token_id, owner, name, description, image}` - creates a new token with given owner and metadata. It can only be called by
-the Minter set in `init`.
+the Minter set in `instantiate`.
 * `QueryMsg::Minter{}` - returns the minter address for this contract.
 
 It requires all tokens to have defined metadata in the standard format (with no extensions). For generic NFTs this may
@@ -60,7 +60,7 @@ Basically, you just need to write your handle function and import
 This allows you to use custom `HandleMsg` and `QueryMsg` with your additional
 calls, but then use the underlying implementation for the standard cw721
 messages you want to support. The same with `QueryMsg`. You will most
-likely want to write a custom, domain-specific `init`.
+likely want to write a custom, domain-specific `instantiate`.
 
 **TODO: add example when written**