There has been some confusion in the governance forums over whether every instance of a smart contract would need to be voted on by the DAO.
If this were true, every time someone wanted to make, for example, an ApolloDAO multisig wallet for themselves, the DAO would have to vote. That would be absurd. Fortunately, Osmosis CosmWasm permissioning happens at the uploading of the contract. Specific instantiations of that code -- such as creating a multisig wallet -- are permissionless by default.
CosmWasm Contract Deployment and Execution: CW3 Multisig
1. Upload (permissioned): these are the base contracts that have no state or contract address. It is just code that cannot be executed until a specific instantiation is made.
Ex. Upload the cw3-multisig contract (done via Prop 303 last August)
2. Instantiation (permissionless): this creates an instance of the code with an initial state and contract address. That is, it uses part or all of the uploaded code to do something.
Ex. In the case of the multisig, anyone can use the uploaded cw3 contract to create a new multisig wallet for themselves: for example this “Osmosis Demo” multisig wallet
3. Execution (permissionless): call the contract in whatever ways are allowed by the contract instantiation.
Ex. There are many instiations of the multisig: not just the “Osmosis Demo” wallet mentioned above, but any wallet created with the CW3 code. A user can then use any instantiation they have permissions for (e.g. one they created): they can Query, Execute, Transfer coins, etc.
(Other CW contracts on Osmosis work similarly -- tokens, vaults, lending, NFTs, etc. -- and can be permissionlessly instantiated and then interacted with according to the parameters set up in those instantiations.)
Additionally, Osmosis governance can whitelist specific team addresses to be able to upload contracts permissionlessly. This will prevent Osmosis governance and developer teams from getting bogged down in governing each contract, while still giving Osmosis the benefits of permissioned smart contracting – a more curated Defi experience with relatively integrated UX, and one that does not fill up the chain with unwanted contracts and transactions.
--For example, the Mars Protocol may have to upload 7-8 contracts initially. Permissioning a Mars team address will reduce the unnecessary friction of voting on every contract separately. And in general, the whitelist vote will be a vote of confidence in their team.
--Similarly, a whitelisted team address for putting contracts onto Osmosis would allow ION DAO to use their governance votes to upload the $IBCX contracts to the chain directly.
Under this permissioning system, Osmosis governance will largely be considering teams rather than each individual contract. It will therefore be wise to require permissioned uploaders to adhere to strict standards. Exactly what these should look like will need to be discussed and voted upon. As a backup, of course, governance has the ability to rescind this permission at any time and, if necessary, to remove problem contracts from the chain.
A final note: none of these phases of deployment and execution have anything to do with contract upgrades. CosmWasm contracts can be set to be immutable or to have an admin key. Again, it is during the initial upload permissioning that governance would need to decide if the contract should have an admin key or not and to whom to give the upgrade powers: governance or a trusted address.
For more information on CosmWasm for Osmosis, check out the ever-expanding Osmosis CosmWasm Development docs. There has been some confusion in the governance forums over whether every instance of a smart contract would need to be voted on by the DAO.