We are working on integrating CosmWasm into the Cosmos Hub. It will go live in the v18 release, after the release of ICS 2.0. Before then, I wanted to start a discussion about possible guidelines for the use of CosmWasm, since it is something that has come up in the community.
Please note- Informal Systems will integrate and deploy CosmWasm in Gaia v18 whether or not these guidelines (or any guidelines) are approved in a signaling proposal. I just wanted to get a discussion going before then.
Proposed Cosmos Hub CosmWasm guidelines
- What should not go on the Hub: CosmWasm should not turn the Hub into an “app store”, or try to attract general purpose CW contracts, defi, etc.
- Making a smart contract platform successful takes a lot of BD work and it is what Neutron is good at. Having the Hub compete with Neutron would muddy the waters and dilute the narrative. Additionally, the Hub would not even be successful at this, not having the BD organization for it. Neutron is the Hub’s CosmWasm platform.
- Analogy: In the 2010’s, Google cannibalized their lead in messenger apps with incessant new product launches and rebrands and lost the market completely.
- Examples of what should not go on the Hub:
- A new lending protocol
- A dog themed memecoin
- An AMM
- What should go on the Hub: CosmWasm is a great tool for programming a chain’s core logic, Stargaze does this. This will be very helpful for teams to build on the Hub more quickly and flexibly
- A CosmWasm contract should only be deployed on the Hub if it adds an important piece of core functionality to the Hub, and it cannot be deployed on Neutron while preserving the same functionality.
- Examples of what could go on the Hub:
- A DAO which is tied tightly into the Hub’s governance, for example having the ability to modify parameters, deploy funds from the community pool, or direct inflation. These things would be unnecessarily complicated to do on a consumer chain.
- An upgrade to ICS which needs the ability to slash validators or delegators for infractions on other chains (AKA Mesh Security). This would not be secure on a consumer chain.
- An IBC client for Rust-based blockchains. This needs deep integration into the IBC system and by definition doesn’t make sense on a consumer chain which is itself connected over IBC.
5 Likes
This has been discussed ad nauseam.
But to summarize again, even as stated in the prop:
Infrastructure good…apps that compete with ICS chains bad.
If it’s a lending protocol, DEX, NFT thing, or ponzi…put it Neutron and not the hub.
The end.
9 Likes
I have to agree with @Golden-Ratio-Staking here.
This has good intentions, but it will probably cause more issues than it solves. It’s not even enforceable outside of a separate governance vote anyways. A DEX or something that belongs on Neutron will easily be voted down. Unless there’s some sort of enforceable mechanism outside of governance, this may make permissioned CW harder to work with than ICS V1. This constitution won’t stop any proposals from going live, so I don’t see how putting this on chain will change anything. I’d love to hear examples and be convinced though.
If anything, a covenant between Neutron & the Hub to work together is enough. That would make more sense rather than always putting the responsibility solely on the hub to maintain agreements.
Make ICS as permissionless as possible, and just like how Neutron always asks the Hub to trust their efforts, they or any other CW consumer chain should trust the efforts of the Hub. It’s not in the business of being a fat L1.
3 Likes
Yea, just wanted to start a discussion. It’s totally possible that no signaling prop is needed and would just be a distraction. I also agree with the points about the non-enforceability of signaling props in general. Thanks for your opinions @Tricky @Golden-Ratio-Staking. CosmWasm is coming!
6 Likes
I also have to agree with the sentiment of @Golden-Ratio-Staking here. This feels like more complexity and discussion of the same thing which leads down the road of overcomplicating with unneeded/un-enforceable prop.
We’re all on board with the roadmap - we just want to see it implemented with some speed so we can keep the development track on course for all the things the hub is trying to bring to market. Appreciate you bringing it onto the forum to discuss and chat through - but I’d say the prop is likely not necessary at this point.
I will keep repeating over and over. We need a special proposal type “Interchain Service” that requires 80% threshold to pass (instead of 50% for regular). And proposals of that type can only be initiated by an expert “Interchain Service” owner group (Tremblack, Buchman, Zaki, seb3point0 from interop, Sam Hart).
I really want to institutionalize an iron grip over the Cosmos Hub CosmWasm permissioning functionality because the last thing we want on the Hub is garbage being put forth by randos. I really don’t want to waste my time policing the CosmWasm apps on the Hub and it is not the job of the wider community to do this.
The way this should be done is you have an expert panel making the case for the interchain service functionality to the community and then the community approving it or vetoing it. This should not be done the opposite way - the community proposing stuff and then approving it or vetoing it itself.
The whole point of Cosmos is for things to be done with separate chains (appchains). Many members of the ATOM community who are only concerned with number go up routinely forget what the Cosmos vision is and how it should work. As such putting new functionality on the Hub which will get drastically easier after CosmWasm is installed should be very difficult. In fact it should be just as difficult as it is today where you have a full development cycle and need expert knowledge to merge new code into the Hub’s core code. The community really shouldn’t be formally initiating what goes on the Hub. The community can make demands, discuss and ask for stuff but ultimately there needs to be a filter and that filter is the expert panel.
In reality, if you want number go up for ATOM, then you need to really lock down the risk associated with the Hub’s smart contract functionality and that can only be done if “interchain service” apps are proposed only by the top experts in the field (tremblack and co).
1 Like