[PROPOSAL #69][REJECTED] Include CosmWasm in Rho Upgrade

Just wrote a post titled " IBC Will Not Make Cosmos a Hub; That’s Great News".

The core idea is that Cosmos Hub most likely will not be a hub due to the dynamic competition of the app-chain world. Therefore, we need to prepare for a future where Cosmos can only compete on innovations. This includes the integration of CosmWasm, whether it is in the Pho Upgrade or in a future one.

The full post is here: IBC Will Not Make Cosmos a Hub; That's Great News | Polkachu



Let’s assume this passed and gets included in the rho upgrade. What’s the estimated timeline for lido to deploy the contract and launch it fully? @vshvsh
I feel like if we can provide an estimated eta like 3 months than people will feel the gain more real.

Also anyone can estimate timeline on copying daodao?

Thanks Billy for the thoughtful initial writeup and everyone else for the discussion. I have a few thoughts on this. My general feeling right now is to vote No, but I will try to provide some analysis around what I think would be needed for a Yes.

I could imagine a VM going on the Hub, but I would expect it at least to (1) have a dedicated team of trained experts in that VM and its integrations, focused specifically on its deployment on the Hub, (2) have them engage in or oversee a focused security review, (3) have them provide clear reasoning why it should be directly on the Hub vs on an interchain secured consumer chain, and (4) have them integrated into the governance gated deployment process. I don’t think we will have that by Q2 2022. We do want to have a team like that to support CosmWasm consumer chains anyways, so we are working on building it up. So I guess it’s a question of timing.

That said, my general preference is for the Hub to lean towards minimalism. A big part of why we’re building Interchain Security is to enable the Hub to extend its functionality in a principled way, using the age-old principle of process isolation to scale computation. Ideally, I think VMs like CosmWasm should run on consumer chains secured by the Hub, rather than on the Hub itself.

Of course, it will take additional engineering effort to achieve this. Process isolation comes with additional overhead - it makes communication more complicated. Instead of a local function call, you’re doing RPC. The code has to handle more failure modes and edge cases. The IBC programming model is still quite young, and we don’t have an IBC query system yet (though it’s being worked on), which is needed for consumer chains to be able to read data from the Hub and vice-versa. Interchain Security also isn’t ready yet, and won’t be by the Rho upgrade (though it should be by later this year!). So again, this proposal is really a problem of timing.

The sense of urgency seems to be coming primarily from liquid staking. In my understanding, liquid staking is important at least because it allows the Hub to natively provide what centralized exchanges are already providing (ie. ATOM derivatives), and thus push back against centralization of voting power in the exchanges. The flip side is of course a new centralization of voting power in the liquid staking providers. In general we should probably be looking at additional ways to decentralize voting power, but liquid staking might be able to help. It does have its own risks, so we need to be careful, and set some kinds of limits, and nurture competition between providers.

The core liquid staking module provides a simple primitive that others can use to build proper staking derivative products. But without CosmWasm on the Hub or Interchain Security, such products will have to be built on external chains, which introduces its own security concerns. Ideally, the core ATOM staking derivatives are secured by the ATOM validator set. In my understanding, Quicksilver and Lido both plan to build ATOM staking derivative products secured by the ATOM validators. Quicksilver plans to build a consumer chain, but they may launch a sovereign chain first (whether or not the native liquid staking module is live) and then convert to a consumer chain once interchain security is available. Lido plans to use CosmWasm on the Hub, but ideally with Interchain Security they could use CosmWasm on a consumer chain. Of course building staking derivatives with CosmWasm directly on the Hub will at first be easier than building it using a consumer chain, as mentioned above (the difference between native function calls and RPC). But as the IBC programming model matures, this should become increasingly seamless, and probably preferable.

In any case, I think this means the launch of the liquid staking module needs to be accompanied by CosmWasm on the Hub or by Interchain Security so that staking derivative products are secured by Hub validators. Whether or not external chains should be able to provide staking derivatives using the native liquid staking primitive is another question. But if CosmWasm is rejected from Rho, it may not make sense to include liquid staking in Rho either. I’m not sure if that dependency is totally clear in the discussion.

So it’s basically a question of how urgent liquid staking is. My general bias is towards moving slowly and deliberately and trying to follow consistent principles, but I recognize that can have significant tradeoffs in the product market process. That said, past features developed for the Hub (Gravity DeX, Gravity Bridge), have had their own product market issues. CosmWasm has the potential to be much more successful in positioning the Hub more competitively until (or even when) Interchain Staking is live (beyond just liquid staking), but it may also compromise the Hub’s reputational position of being more minimalist and thus more stable, reliable, etc. I understand some feel the utility of that minimalism has yet to prove itself, because it can inhibit the Hub from competing on the shorter time horizons of hot money flows. But the whole point is to build for the long-term, to be an anchor in a thrashing sea. And with recent growth in development teams focused on the Cosmos Hub across core Cosmos organizations, velocity on the long-term roadmap is picking up.

Lastly, some meta comments on governance. While there has been plenty of general discussion about CosmWasm on the Hub in various channels, it seems there was not a significant amount of explicit consensus building done off-chain before this went live - this forum post had little activity until the proposal was on-chain. Ideally, by the time a proposal goes on chain, stakeholders are generally aligned about a positive outcome. Maybe some kind of pre-voting mechanism on the forum would help. Of course it won’t always be possible to build consensus before going on-chain, especially when there are strong conflicting views. And the present case is unfortunately further complicated by Jae (who has not played any kind of meaningful role in Cosmos development for years) effectively bribing people with the Gnoland airdrop to vote a particular way, which showcases current weaknesses in the governance system. Hopefully in the future we can move towards some kind of privacy preserving voting system and in general work on better governance norms and mechanisms to mitigate these kinds of attacks.

In the end, it seems like this proposal has spurred a lot of healthy debate and it’s exciting to see so many people engaged who care about defining the future of the Hub. Looking forward to continuing to build and evolve this thing with all of you, regardless of this proposal’s outcome :slight_smile:


Great write up thanks! Sounds like you’re advocating for a permissionless cosmwasm on the Hub? Do you think that’s necessary if we deploy a permissionless cosmwasm as a consumer chain ? The plan is to leverage interchain security to bring smart contracting to the Hub.

There are significant risks to delaying liquid staking arriving on the Hub.

The biggest risk is that DeFi yields must compete with ATOM staking yield. It make ATOM a bad asset to use in DeFi in the medium term. This dynamic creates a risk that ATOM will be made obsolete in DeFi.

It opens up a significant competitive risk for ATOM and I don’t think ATOM can make up for that risk by playing the long game.

1 Like

That’s fair, but does this just means that if liquid staking launches before cosmwasm/ or interchain security then we just have to bear the risk of the initial staking derivatives being built on chains not secured by ATOM ?

And the present case is unfortunately further complicated by Jae (who has not played any kind of meaningful role in Cosmos development for years) effectively bribing people with the Gnoland airdrop to vote a particular way, @ebuchman

No peace, Ethan? That’s unfortunate.

You call it a bribe, I call it leaving.

We all have a right to exit and self-associate, and a sentiment proposal that offers the option is a great place for it. A sentiment proposal, supported by the very organization you’re foundation council member of. (The one that I founded; the one you repeatedly requested me to leave due to “conflicts of interest”, while you, you’re the one still steeped in conflicts of interests!). The same sentiment proposal where the NO with VETO option was imbued with connotations it should not have; that if you vote NO with VETO you plan to leave Cosmos and exit. I merely leaned into the bullshit and countered a pre-existing bias that you are responsible for.

You of all people should be celebrating the freedom of expression and self association demonstrated by this proposal and the airdrop, but you chose to label it as unfortunate bribing instead, and then you lied about what I’ve been doing for the past two years. Ok.

So first, you and Jack start #doubledare within All in Bits, Inc, while I’m CEO, to exclude me from conversations about removing a key component from the cosmos-sdk. You were fine to exclude me then in secret, and now you’re shaming me for coordinating an exit in the open, and giving everyone a chance to join? And after repeatedly telling me to leave the ICF, and coordinating social engineering against me even at AIB (because you and Zaki were responsible for the stated reason why engineers left – lack of funding clarity), you have an issue with me slashing people who vote to destroy the hub.

Ever since you started contributing to Tendermint, even Eris Industries back then, your ex-employer, now called Monax, tried to stop me from publishing Tendermint Core in Apache2.0. Then at the suggestion of someone I once trusted, who also stated to me that they saved George Soros once (a fnancial terrorist and globalist, I have later learned), I invited you as a late co-founder. And then I added you to the Cosmos Whitepaper, though IBC and the network of zones was entirely my idea, and invited you to the Swiss foundation that I set up, because we needed more seats, not because I thought that was the best way to do it. I never imagined you’d try to take over the whole damn thing.

Ethan Buchman, for the first time, I demand that you resign from the ICF. You’re intelligent, yes, but a hypocrite. I doubt that you will leave, but no matter, because 5/20/2022 is independence day.

This is cringe. Can we just debate the merits of the proposal and find a compromise instead of slinging dirt at each other?


Hey Ethan, we are relatively new to the Cosmos ecosystem (<1 year). Based on our observation in the past year, it seems that a “hub” cannot retain a competitive advantage in a feature without the risk of being forked into an independent chain.

We love the concept of Interchain Security and all the work that your team has been doing. That said, we believe that high-value chains would prefer to own their security (e.g., running a validator set), and low-value chains will be indifferent in outsourcing the security to Cosmos Hub or a competitor (say, Saga).

We are unclear how it would play out one way or another. Our “Yes” vote on Prop 69 calls for the preparation of a possible future that Cosmos is not a “hub”.

We do not have a clear take on whether CosmWasm needs to be permissioned or permissionless. Either way seems fine, and permissioned might be more prudent to start with for Cosmos.

How about we talk about how best to coordinate exit by defining the procedure in a constitution? It would involve a sentiment proposal with two opposing sides.

Also, it makes no sense that a new OS is needed for the hub to enable liquid staking. Replicated security allows for functionality to exist on other chains, still validated by ATOM. There’s no lack of options on how to do it without WASM on the hub, and implementing this should be the highest priority of the ICF.

I don’t get this exit rhetoric. Exit the hub? Like ok, dump your Atom and forge your path, man. If that path is something that resonates with people, i’m sure you’ll have some followers. I think I speak for many Cosmonauts when I say that it would be great for many of you OG’s to find some common ground and leave the past where it is.

To this point, the hub really hasn’t felt very “hubby” to me outside of being a fiat gateway to Cosmos, and the criticism of Atom’s tokenomics/utility/value accrual in the ecosystem have rang more true as time goes on. Zaki brings up a good point about Atom losing ground in the interchain as time goes on and it inflates to infinity. Josh Lee said it best: “the biggest threat to the hub is not instability, it’s irrelevance.”

At this point, the proposal is DOA. So what’s next? In theory, CW on the hub could be excellent if it’s done the right way, so how do we get there in a way that alleviates concerns if this is shelved and proposed later?

1 Like

Everyone voting YES on 69 is ignoring one simple point.

You can get what you want without putting CosmWASM, basically an operating system, on the hub.

So your point is just a red herring that pro CosmWASMers are pushing, to manipulate the public into making the hub irrelevant through bloat and failure.

Forks will ensure transparency and accountability succeed in keeping our systems simple and secure. Long live Cosmos and gno.land, the gnomes of the greater resistance!

Bribing is what @zmanian offered an employee of AIB after he left; he asked for a “larger bribe” (his words) in return for silence in the public toward me. That’s extortion and bribery, & I should have acted on it back then, but I stayed silent then. I can’t stay silent anymore.

So @zmanian, extortionist, protected an employee who confessed to me that she stole Bitcoins from her ex for revenge. And knowing this, blamed me for failures because I didn’t promote this person to Google Apps owner, despite max admin privileges.

When she left the company she accused me vaguely of “harassment”; a public crucifixion in the age of wokeness. For what, for saying that we ought to be doing the work of God and making excellent software! These are social engineers manipulating the public against their enemies.

The entire @cosmos ecosystem has a right to know what happened, in light of continued FUD. I would not be able to sleep at night knowing that the community is being led to doom by clowns. Long live Cosmos and the gnomes of the greater resistance!

From purely financial perspective, Ethereum got to $400 billion valuation with a crappy virtual machine and many hacks. Solana got to nearly $100 billion in FDV despite multiple chain failures. While I understand the desire to split off smart contracts to another chain/s for very understandable “reputational” reasons, industry comparisons show that bad reputation doesn’t necessarily mean bad valuation (see Ethereum, Solana). Functionality clearly trumps bad reputation when it comes to value accrual. It is in the financial interest of ATOM holders for there to be smart contract capability on the hub. Maybe there could be a way to limit which smart contract get deployed and leave that to governance. New smart contracts that get deployed have to be evaluated both for their risk and reward before get deployed on the hub. Maybe Cosmos differentiates itself from Ethereum in that it has very strict requirements before it allows a smart contract to be deployed on the Hub. This allows the Hub to have the capability for needed features without necessarily sacrificing reputation.

CosmWasm needs to be added for ATOM to be relevant and the hub to accrue value which is very important. It is really pointless to make “I don’t care about money” arguments. If you don’t care about economics, you don’t care about your own survival. And nobody is investing in ATOM for charity. Obviously money can’t be the only consideration but it is a consideration that can’t be dismissed outright.


I’ve read a bit about cosmswam. I feel there are some benefits but also quite a few drawbacks to including it in cosmoshub. I feel it’ll just be more of the burden to creators and developers of the chain. They will not only have to work on there own program but cosmswam too. Some things they want to do just don’t fit what this is chain is trying to do in the future and for that my vote will be “no”. I can go into more detail if need be. I also don’t know if this is necessary but this is my address to my wallet.

1 Like

You’re not addressing the risk that is present. The Hub, as an IBC token zone, has very different security characteristics than the more self-contained Ethereum. Yikes.

Every chain in Cosmos can be an IBC token zone. By that logic no IBC token zone should have smart contracts… or… the smart contract chains shouldn’t be IBC chains. Essentially you are saying there is a tradeoff between interoperability and programmability. Can you elaborate on what the risks are?

Thank you all for the thoughtful discussion. Amidst all the drama and confusion around this proposal it has become apparent to me that the Hub needs an equivalent to the Swiss direct democracy handbook if it is to flourish.

The challenge here is to provide clear and succinct answers to every question that a reasonable Cosmonaut might have regarding a proposal, regardless of their level of education or knowledge.

Here is my attempt at an MVP of a Swiss booklet for prop 69 . My hope is that we move towards a Cosmos in which we publish such a booklet for every upgrade proposal well in advance of the vote (as well as perhaps a shortened version for param change proposals).

Thanks to @hxrts for the extensive discussions and for encouraging me to write this up. All feedback welcome and appreciated :slight_smile:


Your attempt is excellent sacha, thank you so much!.. :slightly_smiling_face:

I also completely agree with your idea of having a similar handbook for every upgrade proposal in advance of the voting period.


I spent some time to read this thread. I am web developer myself. It is still hard to fully understand the situation here.

especially the CosmWASM risk over benefit, still hard to make a decision for me. Well, I guess I will vote no for now.

At least, I tried my best to understand and made my own decision .

Thanks for the hard work though. I am developer myself. I hope my vote does not hurt any feeling.