[PROPOSAL XX] Signaling Proposal For Cosmos hub improvement - Permissioned CosmWasm

This proposal replaces proposal 893. Proposal 893 incorrectly has an IPFS hash in the description field. The actual proposal text is as follows, also viewable at https://ipfs.io/ipfs/QmUxGC9G5Xx2XttCEThptaJuM3Gpn6xZJdXMRuu81Jguhf Permissioned CosmWasm Implementation on the Cosmos Hub The impending Cosmos Hub fork is opening new paths forward for $ATOM. As there is little need for both chains to be conservative and minimal in nature, now is the perfect time to introduce a permissioned implementation of CosmWasm on the $ATOM platform. Permissioned Approach We suggest a permissioned approach over a permissionless one for the following reasons: • Minimizes risk of potential exploits • Discourages spam or wasteful contracts by governance-gating every single one • Each proposal would involve uploading a single contract for review and approval It’s important to note that the goal is not to compete with Neutron or any other chain, but rather to use the CosmWasm module for functionalities that would otherwise be impossible, cumbersome, or impractical to implement through other means. Enhancing Governance and Restaking The Cosmos Hub aims to become a leader in…

Excerpt (1190 of 2202 characters). Read the whole post on the forum ↗

As seen on Twitter:

“Permissioned CW on the Hub, not to compete with Neutron or Osmo but to build up the infrastructure. Gov tooling, security infra, mesh, DAOs…”

The end.

Full support.

We may well vote yes, but we will condemn lazy proposal posts that use GPT.

Have some respect for the Hub.

I have no reason to vote no with this. Support.

Could be a nice collaboration effort with Confio since the Hub provided them with a good chunk of funding this year in proposal 103?

Ultimately, I agree with the sentiment that the primary (and most vocal) opposition to this idea is now forking off, and the Hub can now choose it’s destiny and not be tied to the very strict and conservative view on it’s uses if it wants. Maybe said opposition wants their cake and to eat it, too, but that’s another issue entirely.

That said, I believe this has to be tied to very specific use cases. Permissioned implementation will show what the Hub views as acceptable through a voting process, but I think it’s important we have a goal in mind for what makes the most sense on the Hub directly that can’t simply be done on Neutron or elsewhere.

Edit: and we have to be very explicit that this cannot undermine anything that Neutron is capable of. It’s important we maintain a healthy relationship with them and work to make the partnership good for both.

the fork is maybe the better thing that can happen. Fully support

I would keep most of the use cases that are being advertised here on Neutron, except for Mesh Security, which doesn’t work on a consumer chain, since it needs the ability to slash delegators. Using Neutron strengthens Neutron, and by extension the Cosmos Hub. Having two platforms for general purpose CosmWasm use is fragmentation. Sort of like how Google used to have everyone using Gmail chat, then they launched 8 different messenger apps and now nobody uses any of them. The Hub does not currently have the BD muscle to build adoption for a smart contract platform, which is not easy given that there are more smart contract platforms than there are applications. So currently it makes more sense to consolidate our strength behind the platform we have, and not risk splitting our strength. Imagine if Vitalik decided he could do better after Uniswap had already launched, and built his own DEX on Ethereum. IMO it would have hurt Uniswap, DeFi, and Ethereum if they had fragmented and competed with their own platform’s users like that. So for projects like @Noam 's AAT, Atom Wars, Timewave covenants etc. I think the Hub is better off doing them on Neutron to build momentum there.…

Excerpt (1197 of 2109 characters). Read the whole post on the forum ↗

Hard NO. The fact that the community decided to reduce the inflation of ATOM doesn’t mean that we are now going to allow everybody to run crappy code on the Hub. Get a grip. If you want to run your code, you can run it on Neutron. Why do you want to run it on the Hub? Because you think that adds value to it?

It doesn’t, ok. Running crappy code on a blockchain and breaking it does not add value.

Governance Smart Contracts

I’m assuming this refers to DAOs coming to the Hub and potentially creating their tokens here. Considering the wider Cosmos is moving to TokenFactory instead of CW20 tokens, would you then also propose the Hub add the TokenFactory module?

Thank you for your suggestions. Edited. Can we connect more to write up a more professional looking prop?

There’s no reason to “only vote yes for permissioned cw on the hub with stipulations of what we upload”

That’s what the permissioned part is for.

We’ll have an absurdly long governance forum and 2 week voting period for any type of code uploading that you can freely be for/against to your hearts content.

The proposal to incorporate permissioned CosmWasm into the $ATOM hub has its pros and cons. While the idea of focusing on governance improvements and MESH SECURITY is good, we need to be cautious about the complexities and security risks it might bring. To play it safe, it’s suggested to keep smart contracts limited to governance enhancement purposes, aligning with the vision we shared in our permissionless B2B2C network essay.

Considering the $ATOM hub’s central role in the broader Cosmos ecosystem, highlighted in the mentioned post, we should encourage innovation in interchain governance and Governance as a Service (GaaS). However, to maintain control, it’s crucial to set clear boundaries for CosmWasm usage, ensuring it stays within the intended scope. Moreover, requiring a supermajority vote for new contract deployments, rather than relying on regular governance factors, adds an extra layer of security and ensures broad community consensus before implementing new features. These suggestions aim to strike a balance between fostering innovation and maintaining security, in line with the strategic vision for the $ATOM hub.

Just posting here to say I am 100% in agreement with Jehan on this topic.

I’m pretty supportive of CW on the Cosmos Hub. That said I do think it’s useful to think critically about the why so my question would be :

What can you do with CW directly on the Cosmos Hub that can’t be done by deploying it on Neutron ?

For a specific example, why couldn’t the Mesh Security implementation be deployed on Neutron ?

jtremback:

In conclusion, I am cautiously supportive of this proposal in principle, with the understanding that CW on the Hub should not be used for a million random DeFi apps, and not even necessarily for the Hub’s own DeFi apps as long as we have Neutron.

Agree on this, but it is difficult to implement.

Golden-Ratio-Staking:

There’s no reason to “only vote yes for permissioned cw on the hub with stipulations of what we upload”

That’s what the permissioned part is for.

You are right that technically there is no difference in the deployed code, but norms and precedents do matter. That’s the whole point of signaling proposals, which is what this will be until the code lands in an upgrade. Matters of policy that are more nuanced than “run this code” can also be specified.

Are you opposed to having stipulations about what the feature is for?

As I originally stated:

“Permissioned CW on the Hub, not to compete with Neutron or Osmo but to build up the infrastructure. Gov tooling, security infra, mesh, DAOs…”

I don’t forsee any scope creep or doing anything stupid like becoming an app store (that already failed)

Let’s not complicate this with a framework, stipulations, and red tape…when the literal point of permissioned cw handles it for us.

I don’t need to explain this to you though. I know you know how this works.

When you say “permissioned”, what are the permissioning rules? If the permissioning rule is the current governance rule of Cosmos Hub, I would say they are not good enough. 50% is quite the low threshold. I would say super majority 67% is needed for this. Is this possible to do if this were to be implemented? I am very concerned about scope creep and frivolous interpretations of the mandates specified here. You just want to push your proposal without specifying any rules which essentially makes this an unpermissioned CW instance like Neutron. If I were to put CW on the Hub, I would actually want red tape: • First, I would explicitly state the mandate and scope of coding activity allowed. • Then I would mandate that signaling proposals be run through a review committee first to block out proposals that aren’t aligned with the stated objectives. • Then the code needs to be run on Neutron or another CW environment and tested in real world environments for a certain amount of time (Polkadot has the Kusama testing chain) • And then at then end, I would want 67% approval for the code to be put on after the extensive testing is completed and functionality works without bugs.…

Excerpt (1196 of 1562 characters). Read the whole post on the forum ↗

Yeah, I respectfully disagree with everything you proposed.

Sounds like a surefire way to continue losing the plot and stagnation.

Guess we’ll see what happens.

The most often used and important things are pretty stagnant. A toll booth doesn’t move a whole lot, does it? Yet it finances the local government. I don’t understand why people want to make ATOM into something it is not. Why do you want to make it into Ethereum? If people want to run smart contracts, there is other chains to do that (Ethereum, Solana, Avalanche, etc). If ATOM became a smart contract chain, then it will then be competing in a crowded field against better competitors. ATOM is neither faster nor more decentralized than an Avalanche or Solana or nowadays SUI, Aptos, etc. That is not a narrative/selling pitch that is a winner for ATOM. If somebody wants to deploy WASM smart contract somewhere, they are far more likely to do it on Solana which has a much higher throughput and thus guarantees lower transaction fees than ATOM would. Case in point - where is the Neutron revenue? If there was really that much demand for smart contracts in Cosmos, Cosmos Hub validators wouldn’t be complaining that Neutron is a money loser for them. Cosmos’ unique offering is sovereignty (building chains from scratch) and interoperability. That’s what it needs to focus on. With that focus…

Excerpt (1198 of 2101 characters). Read the whole post on the forum ↗

I’m not reading all that, respectfully.

Even if you read it, you won’t understand it. Don’t worry, I am not writing it for you.

I have a feeling that people think if you put WASM on the Hub that you will get all this Ethereum like explosion of activity. All the ETH Solidity developers would show up on ATOM and do their thing here and number will go up. That is totally misguided thinking. • Cosmos WASM is not the Ethereum Virtual Machine. It is a completely different smart contract development environment and the Ethereum smart contract developers can’t easily transition to it. No one will ditch their EVM to come to CosmWasm, at least not in the desired size and volume for number to go up. • The only developers that you can steal using WASM are from Solana. Except that Solana has a faster chain, bigger throughput and cheaper fees. At this point, if anybody is stealing WASM developers it is Solana stealing the Cosmos developers (or for that matter the Polkadot developers). With Solana being the main competitor for WASM developers, putting WASM on the Hub is pointless. You are not competing against Ethereum’s high transaction fees, you are competing against Solana’s low transaction fees. Neutron showed you that clearly. I am not sure what much more needs to be proven. The people asking for WASM on the…

Excerpt (1199 of 1313 characters). Read the whole post on the forum ↗

Respectfully, permissioned CW on the Hub doesn’t come with expected explosion od dapp activity. It comes with expectation of 100x improving Hub’s governance which is becoming one of the Hub’s main selling points as Sunny stated multiple times. Yes, no, abstain and veto are not sufficient options for thriving political economy which the Hub has the possibility of becoming more than any other Blockchain in existence today. CW makes that possible.

All that I am disagreeing with the other poster is that the permissioning process should be hard instead of easy. When you create an institution, you need to define its scope and limit its ability to operate outside of its scope. Because the people running the institution may not understand or twist and change the scope later on. One of the first thing that a newly created institution does is flex its muscles to prove who is boss and often does that in a way that pushes makes the institution operate outside of its scope. I am operating under the assumption that the moment this is approved, a whole of bunch of unknown new characters will show up and start putting up shit on the Hub that nobody here is even contemplating. I don’t assume a peaceful existence of the Hub, I am assuming political infighting and constant attacks. What we are deploying here needs to operate under challenging circumstances. Since we are talking about governance here, defining precisely and limiting the scope of an institution (in this case the ability to provision functionality to the Hub) is of utmost importance. I understand many 25 year old folks here just wanna hack away and then put code on the Hub…

Excerpt (1198 of 1622 characters). Read the whole post on the forum ↗

“Are you saying you want to bypass the governance module for putting up permissioned code? I don’t like that one bit.”

How and where am I saying this? I’m saying we need to upgrade gov tooling with additional options, mainly with the option to negotiate, not to replace the existing one.

YES!

Best,
Ertemann
Lavender.Five Nodes

ICA on the hub to manage Neutrons ?need cw ?

Bumping this. This was recently (haphazardly) put on chain.

We should re-open the discussion and check the temperature of it.

The proposal text from IPFS sums up the most recent effort well in that Permissioned CW makes more sense than permissionless on the Hub.

Based on hub minimalism, I would have opposed it in the past, but it is true that now app chains similar to the status of hub are pouring in and hub is losing their position.
I think that if the hub continues in its current state, one day it will give up all the infrastructure it has built to competitors and go bankrupt. It is right time for change.

If this function is added, it will not affect the network speed and security. I think it will be good.

After all, an Cosmos Hub is like a child without mobility

I agree to equip him with a pair of flexible wings

It’s not about making him compete, but making him smarter and able to go further.

Worth noting that even with a permissioned instance of CW on the Hub, that doesn’t mean “Hub minimalism” as a concept goes away. The Hub shouldn’t be bringing contracts on chain that can be abstracted elsewhere (ie. anything deFi send it to a consumer chain).

I see no scenario where the hub would want to put anything on it that is a security risk or competes with ICS chains. Instead, we should be thinking of how this could complement and serve ICS chains and the rest of Cosmos.

I personally think DAO DAO would be a great flagship implementation for the hub to improve governance tooling and interaction with DAO’s across Cosmos, but especially with consumer chains. Could also form subDAO’s underneath AADAO for accountability, or create another DAO to compete or complement it.

The point, more than anything is that it greatly increases options for developers. Any contracts that want to get on the Hub would have to go through governance, so ultimately it’s still up to the voice of the hub community what direction it can take itself.

A bit of romanticism from my side, but this proposal represents what the hub always says it’s proud of: its community.

The proposal comes from the community and is personally the reason for my first post on the forum.

We‘ve been wishing for better gov tooling for years. Now’s the chance to get it. I can honestly see no reason why we wouldn’t want this to pass, since this is not about competing with neutron. As somebody said above, let’s give the hub some wings.

Big yes.

A big yes for me, hub need to evolve

We voted No for now. Looking more into it we might change. One thing i want to mention, It would have been better if the prop was discussed before putting on chain. The last comment on this prop is 3 months old. It needed the fresh discussion.

We’ve discussed for years, there’s been a forum post for months with lots of dialogue and active participants.

For those who decided to not participate in the discussions, there is a 2 week voting period. Have the discussions you need to have. Plenty of time to digest information and make an informed decision.

How can we make sure that the permissioned wasm will only be used for the said purposes? I don’t think there is any way we can inforce that on a chain level. The only checks are the validators?

If this is the case, I am reluctant to say yes.

I don’t understand the question, to be honest. Obviously, everything is up for a vote, including the contracts that are deployed on it. Same as what Osmosis or any other permissioned CW chain does.

Its permissioned cw…code uploads go through governance.

The 2-4 week procedural forum discussions as well as the 2 week voting period is the answer.

The fork that comes sanctions an opinion. I think this is a childish and irresponsible approach to governance. (I’m obviously excluded, but that’s not the cause of my anger^^) I have been voting systematically for more than two years, on the hub, but also on all the channels in the ecosystem, because I KNOW that it is more important than the size of our wallets. Governance is the keystone of this technology. You can code whatever you want, just as accountants are not, and never will be, business leaders, it is not in the devs, however smart or minimalist their code may be, that resilience and strategic force are. Solid governance could have emerged from the hub over time, but this is not the case. For me, it is therefore time to take the plunge, raise the stakes, and put some more complex code back where it belongs: in governance. In the futur we should be able to code our governance, this is the next step, and thus take our place alongside the consensus of Bitcoin and Ethereum. Or you might as well sell your Atoms to buy Dot All my savings are in cryptos, and 80% of my cryptos are in IBC. It’s not a question of money: it’s a political choice. I have responsibilities…

Excerpt (1198 of 2221 characters). Read the whole post on the forum ↗

Thank you for reiterating the meaning of permissioned.

My skepticism is based on this argument

Golden-Ratio-Staking:

“Permissioned CW on the Hub, not to compete with Neutron or Osmo but to build up the infrastructure. Gov tooling, security infra, mesh, DAOs…”

Because we cannot implement this on code level, validators mainly, have to align each time to remember the basis of this prop and vote. That would never happen as it has never happened in the past, hence the hub will face all kind of proposals that will kill the purpose of ICS in general and neutron-like chains in specific.

CC @tknox35

This is hypothetical fear mongering.

The process will be no different than validators voting on modules and upgrades to the hub written in Go.

I’d like to reiterate my cautious support for this proposal. I think it strikes the right tone about the intention of CosmWasm to be a useful, permissioned tool for Hub development, and I think it’s time for us to put this debate behind us.

I have one caveat: The Informal Hub Team has a very full plate with ICS 2.0 Partial Set Security, the Babylon and Eigenlayer integrations, integration of Skip’s fee market, Atom Wars, and several other things.

If this proposal passes, we will probably not fast-track the deployment of this integration until a compelling use case is proposed, or we get through some of the more urgent items above.

On behalf of the PRO Delegators’ team we would like to inform the community that we will vote NO to this proposal. We previously shared our feedback to the proposal in this post: [PROPOSAL XX] Signaling Proposal For Cosmos hub improvement - Permissioned CosmWasm Hub Proposals The proposal to incorporate permissioned CosmWasm into the $ATOM hub has its pros and cons. While the idea of focusing on governance improvements and MESH SECURITY is good, we need to be cautious about the complexities and security risks it might bring. To play it safe, it’s suggested to keep smart contracts limited to governance enhancement purposes, aligning with the vision we shared in our permissionless B2B2C network essay. Considering the $ATOM hub’s central role in the broader Cosmos ecos… We clearly stated that we wouldn’t support CW implementation unless some strict boundaries were added to it. We proposed a supermajority requirement for each deployment as well as a strict limitation to governance. None of these have made it to the final version and therefore we will have to post a negative vote. Moreover, we would like to remind everyone that deploying smart contracts…

Excerpt (1192 of 1318 characters). Read the whole post on the forum ↗

StunZeed:

We‘ve been wishing for better gov tooling for years. Now’s the chance to get it. I can honestly see no reason why we wouldn’t want this to pass, since this is not about competing with neutron. As somebody said above, let’s give the hub some wings.

We would like to remind you that any of the governance improvement you seem to refer to can already be achieved using the existing x/gov and x/group modules. Moreover, we would be better off improving on these modules if a core component is ever needed to add new cool features rather than opening the pandora’s box.

That’s very nice, but nobody’s done that so far.
From what I know Devs like / prefer working with CW so I guess it’s more likely we get the changes we wish to see with CW.

Not that im in favor of permissionned CosmWasm, but if implemented correctly, its better than nothing, considering my max it out till it breaks views.

Then again, main point was noted above that it wont be implemented now even if passed due to business. Seems silly to reinstate a proposal on soft and describe it now, when moods might change when implementation time comes round.

No, I don’t think validators are all in the power to change things that are simply without governance. No boundaries are defined in this proposal and neither those boundaries are implemented in the code. Now people might be under peer pressure to say yes, but I am not. I will vote no, not because I don’t want WASM on Hub but because the proposal could prove to be a Trojan horse in the future. Define well, and vote again.

893 wasn’t the only thing missing details. Even if I agreed with your general principles (which I’m not sure I do), I think even a signalling proposal needs to be more clearly defined and structured than this. As a prompt for a forum discussion, this is a good start - as an actual governance proposal, not so much.

There was a nice spaces today on the Hub Twitter account that was very informative and included many stakeholders. If you’re on the fence, I suggest giving it a listen here: https://x.com/cosmoshub/status/1776248278885060744

I kind of agree with your theory, but it’s quite hard to implement those processes securely & transparently until you don’t have CosmWasm enabled imho. Neutron could be the right place to experiment with this and already has a bigger community pool than Cosmos Hub (150M$ vs 90M$ as of today) to incentivize development, so I wonder what’s the problem with deploying there. Maybe NTRN distribution wasn’t fair enough and its governance is currently not decentralized enough? Maybe the value of its CP could quickly decrease to the ATOM one level & below? For sure the Hub has higher & wider recognition, user base, market cap, status etc. and has a higher potential to make our ecosystem shine in the industry. To easily battle-test & review new features there are already a number of permissionless CosmWasm chains, starting from Juno since years ago, so you could even say what worked there can work on the Hub and anywhere in the Cosmos. Governance features enable exactly the kind of decision processes you just alluded to, and I guess many others would like them, especially if we want to attract existing or bigger organizations on-chain. If you look at “native” (non-smart-contract)…

Excerpt (1197 of 1808 characters). Read the whole post on the forum ↗

I agree. The hub needs to consolidate its fragmented powers

Like @jtremback, I’m cautiously in support of this proposal.

As with every product and engineering decision, this one has its trade-offs. On the downside, the Hub adds another dependency, increasing the complexity and error surface of the system, etc. However, I think the long-term benefits outweigh those if implemented correctly. The community understands this and is aligned here.

IMHO, the key question that needs to be discussed thoroughly is how permissioning CosmWasm in the Hub is supposed to work. Osmosis’ permissioned CosmWasm, probably the canonical permissioned CosmWasm implementation (also Stargaze’s), is not restrictive enough for the Hub’s use case.

I believe that the Hub needs to add more granularity to this permissioning, and not just whitelist contract deployers, but also specific contract codes and instantiation modes (i.e., instantiate only once).

Looking forward to these discussions when this proposal passes.

Looks like this prop will pass after Ethan endorsed it. When it gets implemented, it needs to come with its own proposal type “Permissioned Module” or something like that. That proposal type needs to pass with 80% of YES vote. I was originally thinking 67% but I am really paranoic about the Hub’s liveness and want really high bar for deployment of permissioned CosmWasm modules. So I think 80% is more appropriate. The only smart contract code that needs to be deployed is stuff that gets 99% support. There should be zero concerns about it by the ATOM stakeholders. I want to take a Goldman approach for this. At Goldman, everything is done with 100% consensus. If 1 person has issues, even 1 person, the project leader had to go and beat the pavement and go multiple times until this person’s issues got resolved and he got convinced that it is good to do. Obviously that is an expert group and I can’t expect 100% consensus in a distributed group, but we need to be as close to this 100% “consentual” agreement modus operandi in order to defend the Hub’s historic and extremely valuable LIVENESS property (which a lot of people seem to constantly forget in their “number go up” guttural…

Excerpt (1193 of 1694 characters). Read the whole post on the forum ↗