Who is proposing?
- Confio, creator of CosmWasm. This is Ethan Frey and Simon Warta.
What is this proposal for
- Validator-reviewed smart contract capability for the Cosmos Hub.
- Governance control over complete lifecycle of smart contracts on the Hub, including upgrades and freezing.
- Working example of staking derivatives, deployed to a testnet
This has been discussed on a few calls with some validators, but we see the addition of curated functionality via CosmWasm contracts an ideal way to allow the Hub to dynamically respond in a multi-chain ecosystem. Beyond adding a clear path for some long-requested single-chain features, like staking derivative, we provide a path for implementing “rented security” and relaying dynamic IBC packets (with protocols besides ICS20).
This allows upgrading functionality is a secure and responsive manner, and opens up participation of adding functionality to the Cosmos Hub to many more than the core Cosmos devs. The barrier of entry to uploading a new contract is much lower than adding Go code to the gaiad binary.
A detailed proposal, which is prepared for an official on-chain vote is attached. Earlier versions of this have circulated on Discord. This is a chance to collect feedback before a formal proposal.
This extract of the above PDF explains how governance control of a contract works.
TL;DR: It is all about adding governance control to all aspects of the CosmWasm contract lifecycle to make it compatible with the hub. Allowing governance to control code upload, contract instantiation, contract upgrades, and contract destruction (if needed).
There have been some questions as to how a contract lifecycle would work. This description here is for the proposal of
govd, where a governance vote is able to make each decision. In
wasmd, anyone can create contracts, and no one can modify it. Code for both would live in the same repo and you can mix-and-match which permissions belong to governance when setting up app.go and compiling the blockchain. This allows the hub to easily open up some functionality to be permissionless later on.
- Upload Code: Here you upload Wasm bytecode, which provides potential functionality to the hub (eg ability to run a DEX), but doesn’t actually provide any useable instances. At this phase, the contract code should undergo an audit (formal or informal) and the Cosmos validators should debate if this general functionality is a useful addition to the Hub. Upon a successful vote, this bytecode will be installed on the hub, awaiting activation.
- Instantiate Contract: Once the bytecode is uploaded (eg. an ERC20-like template), you need to make an instance to be able to use it. This will provide a token symbol and decimals, initial distribution, and a unique contract address. This stage requires a further governance vote, so they can decide if the requested use case makes sense. After agreeing to add ERC20-like functionality, we may also control who can issue such new tokens.
- Upgrading Contracts: If a bug is discovered in the code, or a feature upgrade is desired, we will first Upload some new code with the requested fixes (see above), and then can vote to migrate existing contracts from the older version to a newer version. During an upgrade, we can run a state migration to change any data as needed. Upgrading must be voted on for each contract, and requires agreement from governance. We will allow a single vote to upgrade many contracts at once, but still allow more granular control than upgrade every contract using a given code id.
- Disabling Contracts: If the hub decides a given contract is counter-productive to the goals of the Cosmos Hub, they should be able to disable it in an orderly way. This is an exceptional vote for governance, but will be possible if a majority agree. However, we need to do this in an orderly way not to destroy funds. For example, if there were a DEX on the hub, we can upgrade it to another contract that only has one supported message type “withdraw funds” and this lets users withdraw the funds they have locked in open trades. This would allow the Hub to freeze a DEX, but return all funds to users. You could also imagine a “brick” contract that deletes all data and returns error on any message. A migration to such a “brick” contract would be the same as destroying the contract.
Concrete example of contract lifetimes:
- A project wrote a simple batch-trading orderbook as a CosmWasm contract and proposed to add this to the Hub. After some discussion and audit, the Hub approves it. This Wasm code is now available under Code ID 3 on the blockchain.
- There are 3 proposals to add individual orderbooks for ATOM-PETH, ATOM-EEUR and EEUR-PETH. Each are approved and open up their own orderbook for trades.
- There is concern that the trades are taking up too much traffic on the hub due to arbitrage, and they decide to add a variable “Tobin Tax” on each trade that goes to the community fund. This requires a code upgrade.
- Developers modify the original contract with this new functionality and propose it to a vote. It is approved and now available as Code ID 4.
- At the same time, hearing some complaints, they prepare a liquidation contract that would freeze all trades and let users pull out their tokens tied up in open orders. This is also approved and available as Code ID 5.
- Hub governance decides that they only want trades that involve ATOM on the hub and decide to shut down the EEUR-PETH orderbook, by “upgrading” the contract to use Code ID 5. At this point all users may withdraw their funds, but no more trades may happen.
- In a separate governance vote, hub governance decides to implement the “Tobin Tax” on the ATOM-PETH and ATOM-EEUR. They upgrade those two orderbooks to use Code ID 4.
- In this final state, we have “improved” the experience of trading of the ATOM pairs and shut down the other trades, without anyone losing access to funds, or requiring a hard fork.
You can see the potential here for fine grained control of functionality on the hub, without requiring downtime or forking. All changes need to go through hub governance to ensure decisions are made after proper reflection.