Thank you for reiterating the meaning of permissioned.
My skepticism is based on this argument
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:
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 features on the Hub to enhance governance or else, can easily be achieved by pushing updates to the already existing modules.
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) features, Dotsama ecosystem is the leader in this space (committes, different voting tracks, conviction voting with longer bonding, predictions markets, etc.), but we could quickly catch-up and surpass them, since we already have many more active voters. Bringing community-enabled CosmWasm contracts on the Hub, could also start a process of standardization, making them more secure & widely supported.
(Sidenote: Juno is also governed in a similar way to which you were suggesting, and super-transparently, thanks to a Charter, a Council and Departments with elected members - disclosure: Iâm one of them).
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 spasms).
Seriously, if you have been investing in the Cosmos ecosystem over the last 5 years and you need ATOM to go up so desperately, you need to seriously review your investment strategy. We should not allow ânumber go upâ community spasms to ruin the Hubâs liveness. The technological property of LIVENESS is the Cosmos Hubâs most valuable and unique property. It is the oldest POS chain that has operated uninterrupted and it needs to remain as such. That feature trumps growth considerations.