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

[okwme]

Change log

2022-04-27 formatting changes
2022-04-25 LAST CALL
2022-04-07 Initial proposal for comment

Include CosmWasm in Rho Upgrade

Summary

Signaling proposal to include CosmWasm on the Cosmos Hub in v8-Rho upgrade targeting Q2 2022. Further details and discussion at [PROPOSAL #69][REJECTED] Include CosmWasm in Rho Upgrade.

Details

This is a signaling proposal to include CosmWasm in the v8-Rho upgrade. The Cosmos Hub team at Interchain GmbH has done technical feasibility research by speaking with CosmWasm core contributors and validators to understand the burden of integration and believe it is technically feasible with resources in Interchain GmbH and Lido as well as regular advice meetings from Confio.

The instance of CosmWasm included on the Cosmos Hub will be governance gated and use Cosmos SDK v0.46.x. The governance feature set created by Confio, funded by Prop 25, works so that all of the wasmd Message types can be executed by the chain’s governance module. These messages all otherwise have configurations so that they can be executed by one account, any account, or no accounts. Each message type should be set to “no account” so that it is only possible to execute messages with Governance. One alternative possibility that needs further review is whether to allow “one account” and designate it as the new governance module account to take advantage of the new features in the governance module coming in v8-Rho.

CosmWasm on the hub comes with benefits and drawbacks that deserve serious attention. A summary and background of the topic has been posted to [PROPOSAL #69][REJECTED] Include CosmWasm in Rho Upgrade where further discussion is taking place. Please visit and take these into consideration when voting.

Governance Votes

The following items summarize the voting options and what it means for this proposal:

YES - You approve this signaling proposal to include CosmWasm on the Cosmos Hub in v8-Rho upgrade targeting Q2 2022.

NO - You disapprove of this signaling proposal in its current form (please indicate why in the Cosmos Forum)

NO WITH VETO - You are strongly opposed to this change and will exit the network if passed.

ABSTAIN - You are impartial to the outcome of the proposal.

[okwme]

Hello,

I’m the author of this proposal, Billy Rennekamp. I’m the Cosmos Hub Product Lead at Interchain GmbH. My job is to help coordinate and integrate the various contributions to the gaia binary that runs the Cosmos Hub so that it is ready for Upgrade Proposals. This is done with an engineering team at Interchain GmbH as well as support from various Core Contributor organizations like Informal Systems, Iqlusion, Strangelove, Regen, Confio and others. It would be a waste of my time (and others) if significant work is performed preparing an upgrade that includes CosmWasm if the community ends up rejecting the Upgrade Proposal because of its inclusion. To ensure that developer resources are well allocated I’m requesting a signal proposal to determine whether CosmWasm be included in v8-Rho.

Please note: I am not including a signaling proposal for other items on the Cosmos Hub Roadmap at this time because I have not detected as much need for discussion around the inclusion of those features. All features are voted on with the actual upgrade proposal. However, in order to not overload the Cosmos governance system with votes on every decision, I am approaching proposals with an optimistic point of view—meaning I won’t ask for input on items where no large discrepancy of opinion is detected. That said, please review the roadmap regularly and feel free to open signaling proposals or discussion around any item that might deserve to be officially recognized before a final upgrade proposal.

Historical context to this proposal includes a document produced by Cosmos co-founder Jae Kwon called “The Shape of Cosmos” that included a section about CosmWasm and the need for “Hub Minimalism”. The primary point is that CosmWasm introduces complexity risks that should be avoided due to the importance of the Cosmos Hub stay online producing blocks. I believe these risks are adequately addressed by governance gating CosmWasm.

More recently I hosted a Fireside Chat where the topic of CosmWasm on the Hub was discussed at length with CosmWasm creator Ethay Frey, IBC protocol architect Chris Goes, long-time Cosmos core contributor Zaki Manian, Lido representatives Andrei and Kay, and Interchain Funding Manager Sam Hart. A recording of that session is unfortunately no longer available as twitter takes down spaces 30 days after publication.

A summary from my memory of the session (which I encourage others who attended to further add detail) is:

• Ethan Frey, Confio
  • His point was that the team had not really added the capacity to own cosmwasm (especially since they seem to want to fork/be independent of our releases).
  • And there was no clear plan on how to use cosmwasm besides Lido contracts and maybe copying over daodao from Juno
  • I suggested that if a serious chain wants cosmwasm, they should have capacity internally that knows how to integrate/debug it. And they should have a plan that involved of deploying multiple contracts to utilize it
  • Osmosis is working with multiple teams to add features. Stargaze as well. Nym has built out many contracts there (using vanilla wasmd and doing all app dev in Rust). Juno obviously built a large community like Archway plans.
  • Adding cosmwasm should go along with an in house team dedicated to build contracts, or agreements with multiple external projects to deploy on your chain.
  • I heard no other use case on the roadmap besides Lido.
  • Basically, build up a bit more plan/capacity first
• Chris Goes, Anoma
  • Clarified that the proposal it is not necessary to use CosmWasm to facilitate IBC client updates although there may be some overlap in use of lower level WASM components.
  • Generally encouraged the Hub to be less risk averse in adopting new technology and features
• Zaki Manian, Iqlusion
  • Pro-CosmWasm for enabling easier deployment of functionality on the Hub.
  • He views cosmwasm as key to establish ATOM at the center of the Cosmos liquid staking world and it would block deployment of the iqlusion liquid staking module if cosmwasm wasn’t available
• Andrei and Kai, Lido / P2P
  • Strongly in favor as Lido has hopes of deploying Liquid Staking contracts to the Cosmos Hub and making the Cosmos Hub the center of activity for Liquid Staking of ATOM as well as other IBC staking assets
• Sam Hart, Interchain GmbH
  • potential to decouple aspects of hub dev from integration team
  • new IBC app dev is increasingly going to happen there, which we will likely want exposure to
  • I want to centralize stack dev on the hub and cosmwasm is now part of the typical stack

I am also in favor of having CosmWasm on the hub but it’s worth outlining the benefits and the drawbacks. It is ultimately up to the ATOM holders to decide which Gaia binaries are used to operate the network—and by extension what code is included in those binaries. What follows is my summary of the benefits and drawbacks.

Benefits

1. Lowering the Burden on Validators and Maintainers for New Cosmos Hub Features

The most important reason to include CosmWasm on the hub, in my opinion, is that it lowers the barrier to contributing code and features to the Cosmos Hub. Currently, new features come in the form of Cosmos SDK modules and most of these modules are created and maintained by Cosmos SDK contributors at Regen network and other Core Contributor organizations. Other modules are created and maintained by other Cosmos Core Contributors like the IBC router middleware by Strangelove Ventures, IBC and Interchain Accounts by the IBC team at Interchain GmbH, the Liquidity Module by B-Harvest and the upcoming Liquid Staking modules by Iqlusion Inc. Today it is the job of the Cosmos Hub team at Interchain GmbH to review, test, and integrate these modules before releasing a new version of Gaia and then coordinating the network upgrade via validator communication with assistance from Cosmos Core Contributor team https://hypha.coop.

A software release and upgrade includes launching and running a public testnet to simulate the upgrade proposal with a validator set from the Cosmos Hub and chain state that mimics the live Cosmos Hub. Finally, all validators of the Cosmos Hub need to prepare for the upgrade and take measures to update their nodes at the right height or configure Cosmovisor to run the upgrade process automatically. Improvements to the release process of the Cosmos Hub executed by the Cosmos Hub team at Interchain GmbH, Cosmovisor, other Cosmos Hub Core contributors, and validators has greatly reduced the work involved in this process, however it is still a significant amount of work for all parties involved.

With CosmWasm on the hub, it’s possible for anyone who writes a smart contract to add functionality to the Cosmos Hub. CosmWasm on the Hub should be governance gated, as previously mentioned, and means that no code will make its way onto the hub that doesn’t go through a governance proposal. This means that it won’t be possible for malicious or spammy code to be uploaded to the Cosmos Hub without the approval of ATOM holders. But it also means the elimination of large coordination tasks between Cosmos Core Contributor organizations and all validator and node operators aside from the time it takes to vote.

2. Lowering the Barrier for Contributions

With CosmWasm expanding as a popular format for designing and creating decentralized applications we’ve seen standards emerge like CW20 (fungible tokens), CW721 (non-fungible tokens), and standard deployments of DAOs like DAODAO. All of these contracts, as well as the growing number of functionalities, would become possible to deploy to the hub. Of course, community discussion about what actually belongs on the hub should still take place, however, the question of inclusion is about Cosmos Hub as a product and not an engineering one.

It will also make it possible for smaller features that may not deserve an entire upgrade to make their way onto the hub. For instance a convenience app, like profit splitting, could be simply created and deployed to the hub. Or, a simple OTC app that holds some tokens and exchanges them for exactly some other amount of tokens. These could be created as Cosmos SDK golang modules but having more than one way to deploy functionality will lower the barrier to the types of functionalities that can make their way to the hub (again these will nonetheless be rigorously considered via governance before being deployed).

Drawbacks

1. Burden of upkeep

As CosmWasm creator Ethan Frey pointed out in the Twitter spaces, it is a not-insignificant amount of work to maintain compatibility with CosmWasm. While Confio, funded by the Interchain Foundation, maintains and improves CosmWasm as a public good, they take a conservative approach to following the Cosmos SDK release cycle. The Cosmos Hub could eventually rely solely on version maintained by Confio, but in order to use Cosmos SDK v0.46 in the Rho upgrade (with the Groups Module, updates to Gov, and other fixes and improvements), a fork of CosmWasm must be made compatible with v0.46. Notional labs has already created one and Lido has been using it as a starting point to begin testing CosmWasm with Liquid Staking. Lido, and the P2P team (long time Cosmos validators and contributors) have agreed to update and maintain CosmWasm for v0.46 compatibility in light of their desire to see CosmWasm on the hub. Thanks to this commitment and the longer term ability to use the Confio maintained version, I don’t think it’s an insurmountable burden and on behalf of the Cosmos Hub team at Interchain GmbH, I think it is technically feasible to include CosmWasm in the Rho upgrade.

2. Short term compatibility concerns

CosmWasm does not run on Windows machines and has only experimental support with ARM architecture. There are much fewer downloads of the gaia binary for Windows and ARM architecture than for AMD linux and darwin as seen in this analysis. However it’s not yet confirmed how large of an impact or overhead this would have on current validators or node operators at wallets, exchanges, block explorers, data providers or other integrators. I’ve posted in the validator verified discord and in separate chats with validators and node operators and have not yet found any that would be significantly impacted by this. I’ll continue to update this post with results as they come in.

[zaki_iqlusion]

For me, the most important thing here is that I want the Hub to be a major venue by which synethic assets from users of the iqlusion liquid staking module are issued. Lido wants to be the first operator to issue from the Hub. If we deploy the liquid staking module without having cosmoswasm available, there is a strong possibility that some other chain will take over the asset issuer role.

Interchain staking is making great progress but using interchain staking for issuance requires a lot of complex engineering around interchain queries that Quicksilver is taking on. It’s good to have multiple paths to success instead of betting on one technical direction.

[pacha]

Hi,
what is the exact actor model for this smart contract proposal? Is the implementation synchronous like EVM? Or is it mixed synchronousa on a given blockchain and asynchronous across different blockchain (IBC)?
Thank you

[okwme]

This is a governance gated instance of CosmWasm. Meaning that it works the exact same as other instances of CosmWasm (access to IBC) but the deployment of contracts must pass through a governance vote before being deployed.

It is synchronous within the Cosmos Hub but asynchronous over IBC (as all IBC is async).

[Tricky]

Why does this need to be on the hub, and not another zone?

Why do you think the benefits outweigh the risks?

@okwme

[0xBoneSoup]

Oppose CosmWasm & liquid staking cosmwasm contract on the CosmosHub. Cosmos hub should stay minimal, credible neutral , and not complete with other cosmos zones like juno, quicksilver, pstake etc.
IMO devs should start a separate cosmwasm zones that utilize upcoming replicated interchain security instead of deploy cosmwasm on the hub.

[jacobgadikian]

responding in detail per instructions in prop 69

Interchain Explorer by Cosmostation

Notional’s Vote: No

Interchain Explorer by Cosmostation

Generalized bloat

Jacob Gadikian

osmo blippies

Scrt Blippies

that said

Zaki isn’t wrong here. Queries will take time. ICS will take time. They’ll both take money. They’ll take engagement from the icf in the Gaia validator set. There are honestly things that could have been done to speed queries and ics, teams like notional contributing across the stack of:

• gaia
• cosmos-sdk
• tm-db
• ibc-go
• cosmwasm

Notional may be the largest unfunded team (I am not sure of this) but we aren’t the only one.

Huobi is packing an icf delegation on the hub, as are a number of zombie validators. ICF can do that if they’d like to. But when non-objective or out of date factors are chosen as primary criteria for delegations:

• validators could rightfully feel concerned that things are being pushed back, to politicize funding by icf
• if the largest code contributors outside of the (paid) cosmos hub team aren’t given delegations from the icf, this meaningfully harms the hub’s security. Those who write the code know it best and are in the best position to help with problems should they arise.
• oof, sign nda to contribute to open source?
  • oof
    • oof (do I need to go deeper here? I hope not.)

there is zero case for any argument that anyone can contribute to the hub on equal footing if not on the super-secret discord server

I guess I’d rather wait.

why not veto?

Gaia does not have a constitution and nothing enshrines her minimalism and I’m good with her evolving per her governance. I voted for gdex, but that was probably a mistake.

why not abstain?

The technical case against wasm on the hub is pretty strong right now.

Billy, you should have checked with Osmosis validators on this one. Osmo RAM usage nearly doubled and it has zero contracts. Juno gets blippies (less than scrt) osmo gets blippies, but did not till cw. Terra gets blippies. Secret gets blippies. Your discussion of the downsides is incomplete. And how 'bout “hrm literally no one uses mulslc outside of routers in production unless trying to shimmy things into an alpine linux docker image, so why is cw using it?”

Blippies are those simultaneous missed blocks. To me the blippies are pretty clearly cw related.

why not yes?

If the logic of “should have more than one implementation path” is correct, then why not yes?

the cw implementation path is too risky right now.

why is cw good?

Very impressive contract standard and a lot of fun to work with. DaoDao. advanced ibc features. And more. This is not a knock on cw. Mainly, on complexity. Maybe on "I would prefer the hub be for the development of ibc instead of a particular contract standard.

What does Notional consider ideal?

Please imagine that the diagram below has 200 ica-compatible freestanding chains on it, and 100 consumers of Gaia’s security.

Yes, this would take more time.

What specific items could have even swayed the outcome of our vote on 69?

They’re listed in the transaction:

• purge muslc
• build the whole stack from source each time instead of baking in binaries
• make resource usage when using wasm non-entropic (things happen once wasm is added that are tough to explain)
• full arm support

Just like in the ICS case, and the ICQ case all of these items will take time.

Notional has been working on all of the above.

point by point

• Ethan Frey, Confio

  • His point was that the team had not really added the capacity to own cosmwasm (especially since they seem to want to fork/be independent of our releases). ← cw ecosystem needs to grow and icf (at least from our perspective) isn’t very active in facitlitating that growth, even in the gaia validator set
  • And there was no clear plan on how to use cosmwasm besides Lido contracts and maybe copying over daodao from Juno ← daodao is highly compelling
  • I suggested that if a serious chain wants cosmwasm, they should have capacity internally that knows how to integrate/debug it. And they should have a plan that involved of deploying multiple contracts to utilize it. ← scarcity of engineers is real
  • Osmosis is working with multiple teams to add features. Stargaze as well. Nym has built out many contracts there (using vanilla wasmd and doing all app dev in Rust). Juno obviously built a large community like Archway plans. ← chain bloat
  • Adding cosmwasm should go along with an in house team dedicated to build contracts, or agreements with multiple external projects to deploy on your chain. ← chain bloat
  • I heard no other use case on the roadmap besides Lido. ← if the prop had been scope restricted to cw+lido, then we would only need to deal with conspiracy theories, which I don’t indulge
  • Basically, build up a bit more plan/capacity first ← correct

• Chris Goes, Anoma

  • Clarified that the proposal it is not necessary to use CosmWasm to facilitate IBC client updates although there may be some overlap in use of lower level WASM components. ← correct
  • Generally encouraged the Hub to be less risk averse in adopting new technology and features ← prefer scope limitation to ibc features, then unbounded features via ics

• Zaki Manian, Iqlusion

  • Pro-CosmWasm for enabling easier deployment of functionality on the Hub. ← prefer features by ics, but nonetheless correct
  • He views cosmwasm as key to establish ATOM at the center of the Cosmos liquid staking world and it would block deployment of the iqlusion liquid staking module if cosmwasm wasn’t available **<- Iqlusion is a very rigorous engineering org. I bet their module is nice. Prefer via ics. **

• Andrei and Kai, Lido / P2P

  • Strongly in favor as Lido has hopes of deploying Liquid Staking contracts to the Cosmos Hub and making the Cosmos Hub the center of activity for Liquid Staking of ATOM as well as other IBC staking assets ← too fast, via ics is better, but correct

• Sam Hart, Interchain GmbH

  • potential to decouple aspects of hub dev from integration team ← chain bloat
  • new IBC app dev is increasingly going to happen there, which we will likely want exposure to ← this is a very bloated vision that goes outside the scope I’d like to see
  • I want to centralize stack dev on the hub and cosmwasm is now part of the typical stack ← correct, but doing on ics is safer/better

Jacob what are blippies

kingnodes

update: no with veto

I read through the proposal again and it contains a stipulation that it’s not reflected in the code anywhere: that those who vote no with veto intend to exit the network. This is lore, not code. It should not be anywhere near a governance proposal.

Notional will veto prop 69 and stay in order to help Gaia assess her dietary needs.

Notional now endorses the veto position, because we wish to operate chains according to their code. Jacob just read through the governance module, and there is no mechanism that will remove a validator from consensus after a no with veto nor is there discussion in the code of the “intend to exit the network” that billy mentions.

We advocate no with veto plus memo stating no intent to exit.

On technical merits alone this prop is just a no to us.

But after looking at the gov code, this prop is a clear no with veto, we feel that serves our delegators most effectively.

comparison of description text

Our amended vote

Interchain Explorer by Cosmostation

Notional’s political platform on the hub, and hub roadmap

Notional

If you think those items would be favorable to the security of the network and atom value accrual, the correct electoral signal is to delegate to notional.

That is how we know that our ideas are gaining traction.

Please feel free to participate in the effort to popularize our roadmap and platform and to let other NoWithVeto validators know that we can stay right here, and make the Gaia that we want to see.

We endorse governance by code.

[AFDudley]

This is far from my preferred medium of communication, so I’m apologizing for any errors in advance.

1. Lowering the Burden on Validators and Maintainers for New Cosmos Hub Features

We should achieve this desirable goal by fixing the module system in CosmosSDK, adding a new module to the hub strictly speaking makes this problem worse. (which Billy touches on in later points.)

A software release and upgrade includes launching and running a public testnet to simulate the upgrade proposal with a validator set from the Cosmos Hub and chain state that mimics the live Cosmos Hub.

This is a good process, if it’s clunky someone should do the boring work of making it work better, not completely throw it away.

Finally, all validators of the Cosmos Hub need to prepare for the upgrade and take measures to update their nodes at the right height or configure Cosmovisor to run the upgrade process automatically.

Again, the solution here is to automate updates, not just jump ship to some new sexy thing.

With CosmWasm on the hub, it’s possible for anyone who writes a smart contract to add functionality to the Cosmos Hub.

I can’t stress enough how bad this sounds, absolute nightmare, completely regressive, gives up the hub’s strongest selling point IMO.

Of course, community discussion about what actually belongs on the hub should still take place, however, the question of inclusion is about Cosmos Hub as a product and not an engineering one.

I’m not a hub maximalist and I’m pretty sure I’m arguing against my own short term economic self interest in favor of having a cogent consistent model because that in the long run will be best. All that to say, this isn’t really a product question at all, it’s an existential question, “why even bother with the hub if it just turns into a shittier version of ethereum?” The hub really must have the absolute minimum amount of functionality.

Cosmwasm should be deployed on other chains. The hub should facilitate routing, service discovery, and some minimal amount of settlement.

Years ago, when people started talking to me about liquid staking I knew it was a turning point, I still get quite sad thinking about those conversations. The abstract idea of liquid staking is basically a rejection of Proof of Stake economic security, but no one seems to care about that. I mention that here because adding cosmwasm to the hub uses the same theoretical model for justification. Instead of positively asserting the safety of a change, folks are sticking a thumb in the air and saying, “seems like it will be safe enough”. This is being said in spite of human history and the human experience, we know once we start relaxing these formal constraints on safety the system will over time drift towards being less safe, the community has made it clear this is what they want to do. As someone employed by the community to execute its wishes, I’m happy to build all the footguns people want. As someone who has thought about these sorts of systems intensely for well over a decade at this point, I deeply saddened to see what appear to me to be an unprompted shift in design thinking. The execution problems the project has had in the past, ultimately, are mild. The price performance of ATOM seems inline with taking a safe approach and is probably in some sense out-performing. I completely empathize with Chris Goes wanting to be less safe, but I think there are better ways to “quickly” accrue value to ATOM holders that don’t require fattening the hub.

[jacobgadikian]

Harsh but fair.

I feel like prop 69 should have actually dealt with scope. I am comfortable with evolution via governance and I figure a veto on 69 is therefore a bad idea: while there is a hub minimalist community, there is no defining document for the hub.

I think Gaia needs that, because that can make future decisions easier.

But if you look at the code what we can see is that the governance module is pretty much gone and that validators are expected to follow governance decisions.

There are no:

• protections for users
• scope restriction policies
• statements of purpose
• limitations on what gov can and cannot do

I think that all four of these items would be useful. Currently all of these items live in different peoples minds and that is why we have such variability on them. So I would say that over the next year, some thing that can really focus and refine the efforts of communities in cosmos, is constitutions the layout at minimum does four points above but possibly more as well.

I would like to give a few examples of recent events in governance that leave me to believe that we need guidance, official themes, or constitutions.

• the Juno whale
• osmo prop 188 and 199
• gaia prop 69

None of these situations were the same, but all of them dealt with the confusing nature of governance as it is.

Earlier I would have advocated for accountable individuals, but I am now more in favor of distributed teams, each funded by gov, with gov being the community at large.

Given that there is no policy on Gaia on scope restriction, I don’t know why I feel funny about the notion of making her a smart contract platform but I do

[zaki_iqlusion]

The clear purpose of deploying CosmWasm on the Hub is to enable the issuance of synthetic assets built on top of the iqlusion liquid staking mechanism.

We have the following goals here.

1. Synchronous access to the state of staked atoms, current issuance rate, staking rewards etc provided by cosmwasm on the Hub.

2. A competitive marketplace of synethetic asset creators. Iqlusion has been working with Lido on an initial release but we hope for additional issuers to the join the community.

Cosmwasm on the Hub strikes a solid balance here.

Adoption of liquid staking for ATOM is critical to align ATOM tokenomics with the rest of the Cosmos ecosystem, reducing amount of issuance that needs to be there to reward takers and provide new ways for ATOM stakers to stack rewards with liquidity mining etc.

Iqlusion has been supporting both the Lido design and the asynchronous interchain security based design of Quicksilver as issuers but there are substantial timeline and opportunity cost risks if the Hub choses to only asynchronous designs for issuance.

Quicksilver’s work will open a new possibility space but it’s a mistake for ATOM to act as if that work is both complete and successful prematurely. Once Quicksilver’s work is complete, additional work will be need to make interchain queries accessible via cosmwasm to achieve that comparable to results to Cosmwasm on Hub with synchronous access to the staking data.

[David_Lightning_Cap]

Hey Zaki, I have a few questions I’m hoping you (or anyone else qualified to answer) could elaborate on:

1. If a validator is slashed for improper activity, what happens to their synthetic ATOM if its being used to LP (or something else) on another chain?

2. Is the thought process that liquid staking opens up more opportunity for ATOM yield generation, therefore we can decrease issuance rate at a later date, or is there some baked in function with liquid staking that will lead to an issuance drop?

3. If liquid staking doesn’t go live until interchain queries are in production via Quicksilver (or elsewhere), does that impact something else further downstream in the Hub roadmap? Outside of additional yield opportunities for us ATOM holders/stakers in the short term.

4. We all know and appreciate that a ton of work has been done to get it to this point, and a rejection of this proposal would be discouraging to the teams that have been dedicated to seeing this go live. This is a delicate situation overall.

[AFDudley]

@zaki_iqlusion

Adoption of liquid staking for ATOM is critical to align ATOM tokenomics with the rest of the Cosmos ecosystem, reducing amount of issuance that needs to be there to reward takers and provide new ways for ATOM stakers to stack rewards with liquidity mining etc.

I get that people feel this way. Ultimately, it’s not a technical question, it depends entirely on how people feel about these various risks. I have 2 major points:

1. This is obviously against a hub minimalist model.
2. This effort could have been spent changing the development/governance process so that these functions could have been applied in a more secure way.

I’m too cynical at this point to question why 2 wasn’t done, in spite of its clear benefits.

This isn’t the worst possible solution and it’s better than doing nothing. But once this stops the howling wolves, who is going to spend the political clout (and money) to keep this safe? (My guess is no one.)

[AFDudley]

Yeah, I strongly agree with this.

A document doesn’t exist because making it would be contentious and not having one dramatically increases the agility of the chain’s narrative.

I’m not an expert in markets, but it seems like we can maintain some philosophical purity on the engineering side while still satiating The Narrative. That’s pure conjecture on my part, so I understand why that particular risk is so unappealing.

[sandbeach123]

Without being a formal programmer, I voted against because I prefer a minimalistic hub. For me Cosmos Hub provides stability for the Cosmos Ecosystem.
My gut tells me that goal is easier to achieve without any formal entity or commitment force such as projects, websites, companies, big bucks, roadmaps, etc.
If by evolving Cosmos Hub in a more complex network will make the creation of new chains more difficult, I prefer to keep it as it is. IMHO.

[jacobgadikian]

Another update from me:

docs: clarify language about censor threshold as one third + 1

Unfortunately there are now folks saying that Notional’s veto of 69 is related to another network’s snapshot.

Nope. I just do not want syncretic governance in cosmos.

[zxf557]

Adding WASM to the hub is harmful to the purpose of the hub

[Anonymouse]

Not in favor of this proposal. I am not qualified enough to comment on the security risk element of it. Others have done it very well above. But this proposal does not sit with me for two reasons:

• Hub value prop and ATOM value accrual: I think this proposal removes the credible neutrality the hub has maintained and adding the security risk element makes the Hub a less suitable candidate for a ICS provider chain. The way I see it shared security and further IBC innovation is the major source of future ATOM value accrual and having CosmWasm on the Hub creates the risk of the Hub not being an adequate security provider.

• Liquid staking: I think it has been said above that Liquid staking is the explicit aim of this proposal. While I think liquid staking is inevitable for ATOM, the Lido iteration is a less than ideal solution. I think its very centralized and having this tailor made proposal for them is not right. I think there are much better liquid staking solutions out there. So CosmWasm is not equal to liquid staking, far from it. And I would guess that a liquid staking protocol would work better as a sovereign chain than on the Hub.

I like the slim vs fat Gaia comparison made by others here. Slim Gaia in many ways seems to do much better. The Hub was supposed to be a chain that facilitated the creation of an interchain ecosystem (and shared security is the first step), not compete with it. This proposal opens the doors to hub becoming a clunky smart contract chain like Ethereum. It is Liquid staking today and something else tomorrow; none of this needs to be on the Hub. App specific chains with high degrees of interoperability facilitated by the hub is in the best interest of all ATOM holders and in many ways what separated the Hub from other big Layer 1s. Its a 100% No with Veto from my side.

[vshvsh]

Vasiliy from Lido (also from P2P Validator). I think that this proposal should be voted for, however unlikely that does sound now. The arguments for are:

• it gets a new way to deploy code to Cosmos Hub for developers
• it allows us and everyone else build a liquid staking solution for Cosmos Hub (and later for the whole Cosmos ecosystem) that is under Hub’s governance

Arguments against are:

• cosmwasm will increase technical risks for Cosmos Hub
• slim hub is better hub
• interchain security will make this upgrade unneeded
• “we don’t like Lido”

Well, right now there’s nothin on Cosmos Hub that would make it a better hub than the competition. There’s no useful things happening on Hub beyond providing fiat off/on ramp (which is important, but Terra or Crypto.com do it just as well); if you look at the map of zones, Cosmos Hub only drives about 16% of IBC volume for the last 30 days.

It’s increasingly visible that hubbinness in the IBC ecosystems comes from utility. A slim zone with no utility will not be a hub, however good their validator set (not a moat; can be replicated) is or however credibly neutral (which I don’t think Hub is - governance is quite opinionated) they are.

I see three ways Cosmos Hub can provide utility within its self-chosen domain of interchain services: being a primary bridge of non-cosmos assets into cosmos ecosystem; hosting a liquid staking service under its governance; provide interchain security. Now the bridge part looks like it’s lost for good. The interchain security is not live yet, and not clear that it’s going to have enough demand, esp. after the modular blockchain ecosystems gear up in production.

Lido doesn’t want to launch a separate zone for liquid staking, because we think that liquid staking should be accountable to the protocol it builds for, whenever possible. The alternative to Lido on Cosmos Hub is not a better liquid staking solution on Cosmos Hub: it’s either threshold signatures-based liquids staking like Persistence, or a sovereign liquid staking zone like Quicksilver - both of which significantly limit the agency of Cosmos Hub’s governance over liquid staking.

Waiting for interchain security to deploy a cosmwasm and/or liquid staking zone under cosmos hub governance will mean an unpredictable delay of delivery time for Lido. We would really love to work under Cosmos Hub governance, but I’m not sure it will even make sense to try with these timelines. These markets are very dynamic, and moving first might be enough to make it very hard to compete. I also do not believe there will be an alternative team that will be incentive-aligned to launch under Cosmos Hub: financial incentives are heavily skewed into launching your own zone with your own token. That was clearly demonstrated in recent launches.

Blockchain ecosystems are fast-moving, and Cosmos Hub governance is keeping on postponing its market fit. Now it’s postponed to interchain security which is supposed to bring a lot of utility zones under Cosmos Hub umbrella. Voting against cosmwasm on the Hub has clear reasons, but it’s essentially banking all of the future of the chain on interchain security. I do not think it’s prudent. Until you have a market fit, you have to experiment.

[kopeboy]

I’m against liquid staking in general because it removes the security given by the stake and unbonding delay in the first place, adds intermediares that can accumulate power without responsibility, and opens a fast exit door for mercenaries and vandals. Especially if you add “smart” contract execution for the whole chain (not sure if I understood this part correctly).

“Opportunity makes the thief”:

1. develop a shiny but sneaky contract that attacks the network in any way (or adds an attack vector)
2. accumulate ATOM
3. vote for the “upgrade” with your big stake (you can even bribe off-chain)
4. slowly unstake ATOM and swap it for stkATOM derivative, while creating hype about the new features
5. sell the stkATOM and launch the attack, leaving the cost to the other ignorant stakeholders

This would be doable until there is fiat money and central bankers allowing for immediate creation of capital out of thin air, or there are a lot of derivaties around.

I’m a noob in this ecosystem but I know something about economy, governance, human behaviour.
I would appreciate you pointing any flaws in my reasoning, thank you.