[PROPOSAL][DRAFT] Enable permissioned wasm applications on the hub

I am planning to submit a signaling proposal aimed at introducing permissioned smart contracts on the Cosmos Hub, a significant step toward cultivating a diverse ecosystem of decentralized applications (dApps). This initiative is strategically designed to position the Cosmos Hub as a thriving center, attracting the best dApps to apply via proposals. The ultimate goal is to transform the Cosmos Hub into the “Apple Store” of trusted dApps, offering an unparalleled platform for users from all connected IBC chains to experience and harness the full potential of the Cosmos. The Cosmos Hub, true to its namesake, was conceived as the core of activity in the IBC world, envisioned to ensure seamless interoperability among interconnected chains. This remarkable technology led to the rise of multiple chains, many of which adopted the wasm technology developed by the Confio team to further boost development. Nevertheless, there remained a pressing need to ensure a steady revenue flow back into the Cosmos Hub as IBC does not generate income, prompting the creation of the Inter-Chain Security (ICS) to serve this purpose. Currently, incentives for using ICS are limited, mostly the…

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

So we all know how this went the last time. What has changed since then?

As I recall, a few of the cited reasons for “no” were:

1. Performance overhead for validators- not sure if this has been improved. I believe Jacob was talking about this on the last proposal.
2. Possibility of chain halts- I know this has been addressed in the ICS context by @jtremback and whether or not this is a real concern like it was previously. How frequent are chain halts on CW chains? Is it even that huge of a deal?
3. Broadly, “Security”- I suppose this is always a concern, but permissioned contracts are only as secure as the devs who write them and the auditor who audits them.

I’m not against it since it gives hub many options and the fact they’d be permissioned like Osmosis and others eliminates some of the concern, but i’m sure there are some who will never be convinced of this being a good thing.

One thing I think needs to be discussed before this would go live is a constitution or agreement about exactly WHAT can be deployed as a contract. For example, would governance/dao tooling be more palatable than something that is on the finance side, possibly manages funds, etc…?

Seems like we are going in circles. Just today, two props on the forum that have been recently rejected. The marketing DAO and this one. Interestingly enough, I am actually pro this. But after 4 years of full time Cosmos, I have come to learn that the chain doesn’t support this idea. Basically, a lot of the citizens are currently concerned with the idea of having AEZ expanded at any cost (which is what’s happening) without looking at other directions of development. As a validator, I believe that we should strive to work together, more so as an ecosystem. Seems to me pointless to try and change the course of development at this point. Anyhoo. Just to point out, I am actually pro this. But don’t see this happening

I fully support this initiative to enable permissioned smart contracts on the Cosmos Hub. It will augment the Hub’s sovereignty by relying less on ICS chains. It will also accommodate mesh security, which in its current shape requires CW. We could envision enabling Mesh as an SDK module but that’s clearly not the right way to implement it and the end implementation would likely be less flexible.

Permissioned CW can also position the Hub as the governance center of the Interchain by bringing tools like DAO DAO that if properly marketed, can attract dozens of DAOs to operate and coordinate directly on the Hub…

I fully support this proposal. The previously mentioned reasons for voting “no” spanned numerous reasons that have nearly all been debunked or overly exaggerated, imo: • Validator Performance Overhead is negligible to the point of irrelevance. The cost-benefit analysis tips more towards the benefits due to ease of upgrading features without coordinating chain-halting governance upgrades. This will also save time and is much more efficient. • Chain Halts : Understand that every chain upgrade brings an opportunity for a halt, the risk isn’t unique to the implementation of Cosmwasm. It’s part of the natural risk associated with any upgrade in a blockchain environment. There have been a plethora of rolling upgrades, “planned” halts, and governance chain upgrades (halts) to fix vulnerabilities within the last few months alone for items that were NOT even related to cosmwasm. The statements of “cosmwasm is a substantial threat to a chain halt” is disingenuous fear mongering, at best, directed at the people who don’t actually run chains. The issue is people are conflating permissionless cw with permissioned cw. The nature of the latter, being governance-gated, drastically…

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

I think that at this point, there are more benefits as opposed to risks with implementing permissioned Cosmwasm. I feel like it’s the right time.

Even if is permissioned wasm, set rule first.

A small constitution?

Will it funded by the hub or what?

Why people will build in a permissioned if they can build in neutron?

in my point a view, this draft proposition need to be work much more with more detail with a plan.

Create a dao about permission wasm in the hub?

I think what would help is providing real examples of what contracts would make sense on the hub. Some may point to Neutron, Duality, etc. as a better candidate for certain contracts, but what would make sense directly on the hub that can’t be accomplished on a consumer chain?

The main one seems to be the CW implementation of mesh security, though there have also been talks about consumer chains themselves being able to join a mesh.

I think something like DAO DAO directly on the hub would make sense. Various working groups like AADAO who serve the hub would then have their own on-chain organizations.

Outside of governance-related things or DAO’s, I struggle to imagine what would make sense directly on the hub, but many out there probably have some ideas.

i mostly agree with this now cw has been battle tested and is well funded for the years ahead.

if i could give some humble advices:

-permissioned is not enough. as we can see on osmosis, closed source code is now uploaded to the chain, even if permissioned. do we want that?
i believe this proposal has to be more restrictive than just “permissioned cw”.

-since Range has just got a grant from AADAO, it would be nice (and reassuring?) to associate them with this eventual integration process, alongside teams maintaining the SDK/the consensus engine/the testnets builds

if i’m being mistaken on some points, happy to be corrected.

o/

fully support this idea. moving to the right direction

We need to decide in what direction we want Hub to proceed.

Are we going to be security providers or do we want to do everything? We can do certain things doesn’t mean we should do those things.

What is the purpose of a neutron then? kick them out they are useless.

the hub should do everything. Have L2 on it. have consumer zones. Be the IBC hub for those zones

I have a different point of view. Whatever HUB does it should be covered from all aspects. We always make uninformed decisions. We have just launched ICS we should be aiming to make it successful not just for the chains but also for all the stakeholders mainly the validators (their losses multiplied because of ICS).

But we want to do everything too quickly to handle.

clock is tiking, maybe the best way for the validator is to increase the tax ( temporaly).

when the ATOM go up, this issue will be solved. Important to grow the Atom value first imo

Hub needs to lead the interchain.
Stop saying low taxes, no friction…
If a consumer chain wants to aligne with the hub, more taxes to he hub and its validators had to be recuired

15% for stride rise to 30%
25% neutron rise to 50% for exemple.

With a default IBC fee token in ATOM in the AEZ

From my perspective as a developer working on the Hub: Permissioned CosmWasm is just another programming language.

I agree that we should use it if we need it to enable some functionality, but I do not agree that the Hub should become a catch-all platform to launch new CosmWasm projects. That is what Neutron is for.

As it happens, we will need CosmWasm to enable some upcoming functionality: Mesh Security.

Mesh Security will be great for the Hub, and will enable the Hub to secure projects that are not a good fit for Replicated Security. You can read more about my views on this here.

Once Mesh Security is ready, there will be a proposal to enable it on the Hub, including installing CosmWasm so that it can run. But the fact that it uses CosmWasm is an implementation detail.

IMO, if there is something that uses CosmWasm that people want to see on the Hub, they should make a proposal for that specific thing, and mention that it will run on CosmWasm. Until then, I don’t see the rush to install it and then not run anything on it.

People from all chains would submit their best dapps to be on the Cosmos ‘Hub’.

They can build on Neutron, but why not on the hub where Atom Holders own the chain?

Atom holders only own a tiny minority of Neutron so having permissioned smart contracts on the hub itself is a way to filter the best development upwards towards the hub (from all chains - ICS and Mesh), making it an actual hub.

Neutron early backers and founders holding such a large token share means the Hub putting serious contracts like DAODAO for governance on it is kind of risky. Not to mention they can always leave ICS in the future if better rewards exist elsewhere for their token-holders.

neutro1286×665 11.9 KB

A detailed implementation proposal would follow, assuming governance passes this signal proposal.

I’ve spent a few days thinking about this and I tend to agree. Having closed source contracts, while in some cases might be useful - should be avoided, at least in the short to medium term.

Having a situtation where a closed source contract runs away with peoples funds would not be a good look for the hub. However the only way this can really be prevented is by education and informing validators and delegators before and during voting periods on indivudal proposals.

Anoter signal proposal could be passed to show intent from the community to disuade closed source projects from even attempting to get their dapp listed on the hub.

The hub needs to do what is in its best interests, which is to adapt and evolve.

ICS is great, but it’s not unique and might not be the best way to make a ‘hub’ on the interchain.

For that, we need to ensure other chains see it as a hub, and having an ‘Apple store’ of trusted dapps at the center is the best way towards that goal.

Neutron is just one of many smart contract chains, and sadly atom holders don’t even have a significant stake in its success.

However having permissioned dapps on the hub opens a new world of possibilities to interface with permissionless dapps on these other chains. It really levels up the potential, which will draw in new users from outside the Cosmos as a whole.

What is the module or contract that you want to see deployed that requires CosmWasm?

This isn’t about any one dapp being deployed to the hub. It’s more of a proclamation by the ATOM community that we envision a paradigm shift whereby the Cosmos Hub reclaims its title as hub of the interchain.

The best way to acheive this is to enable permissioned wasm so that developers and chains know they can submit their best dapps to the “Apple store” of the interchain, a place where only the highest quality and trusted applications live.

It’s also not a good idea to combine the submission of a dapp with the proposal to enable wasm. Voting should be done on one thing at a time, and while the community might agree on deploying permissioned wasm as a whole, they might not agree with the dapp that is being bundled with it.

Last year, Prop 69 to add CosmWasm was rejected. I think a big part of the reason was that there wasn’t a good argument for adding it. No killer app.

While I personally support CosmWasm being on the Hub, I wouldn’t want to see a prop similar to prop 69, with no killer app, being rejected. This would set a precedent of CosmWasm having been rejected not only once, but twice. I’d be worried that this would then make it hard to get it approved when we need it for mesh security.

So I share your goals, but I think politically, it might be better to first have a vote on whether the community supports CosmWasm to run Mesh Security, then move on to opening it up to a larger set of applications.

I’m personally of the opinion that the main reason prop 69 failed was because one of the founders of Cosmos (Jae Kwon) offered an airdrop to users that voted No/No with Veto.

DAO DAO on the Hub would make a lot of sense imo

I am in support of CosmWasm on the Hub in order to have mesh security, which I believe is important because it strengthens replicated security and enables the Hub to form meaningful relationships and alignment with other non-AEZ chains.

However, I would vote no on the proposal in its current form (despite my support for CosmWasm on the Hub for Mesh Security) on the basis of it not including a risk analysis, implementation details, scope, and other important details that need to be considered for any technical change on the Hub.

I’m also opposed to the idea of the Hub as an “app store”, and would like to see an explicitly stated scope for CosmWasm at the outset.

Hey,

Makes me wonder: are there research/fundings currently for go implementation of mesh security?

Aren’t RS v2/v3 going quite in the same direction than what mesh aims to do?

Good morning. This shall be a longish reply, I’ve been lurking in an attempt to ensure that I had a fully fleshed out POV. Thanks to @Golden-Ratio-Staking @CosmosChain @jtremback @tknox35 and @tom for sharing their perspectives here. tknox35: One thing I think needs to be discussed before this would go live is a constitution or agreement about exactly WHAT can be deployed as a contract. For example, would governance/dao tooling be more palatable than something that is on the finance side, possibly manages funds, etc…? Actually this is precisely what I want to comment on. Noes: • I do not want CW defi apps on the hub. • I do not want closed source anything on the hub ever. But I do want to be specific, BSL and other source available licenses are totally cool with me. I want to praise Larry for championing this cause throughout Cosmos, his approach has proven to be extremely rational. • I do not want the hub to undermine Neutron. • I do not want the hub to be an application platform. • I do not care about roll-ups originating on the hub. They can originate on a consumer chain. • I do not want cgo type conversion messes on the hub or anywhere in…

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

I have two more notes on this proposal: • like informal did in prop 791, I shall loosely define spam and veto this as spam cause I don’t like it. Because what is spam other than stuff people don’t like? Please note that it will suddenly not become spam if it is scope restricted to mesh only and includes source availability restrictions. Interesting how that works. • I apologize to anyone who may feel offended by “fat Gaia” terminology. I will continue to use such terminology unless of course I am provided with an even more effective metaphor: I will formally use the fat Gaia terminology for the duration of discussions on CosmWasm on the hub as I believe that metaphor to be highly effective in promoting an understanding of feature bloat. I have been unable to find equally effective metaphors. To @lexa I understand your objections to this terminology, and if you are able to suggest better terminology, I will adopt it after market testing it. This would include eliminating all usage of the fat Gaia metaphor in perpetuity and from past posts. The trouble is I have not found something that people understand as readily as that metaphor. Thus this is a request…

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

Hi Jacob, thanks for engaging! I think the Cosmos Hub has for too long been afraid to compete to be the center of actual activity. You mention Neutron (one of many potential ICS chains that could provide unrestricted applications), which has only given atom holders 12% of the token share, which leaves founders (23%) + early backers/vcs (11%) to have 34%. By agreeing to not have features that ICS chains can do puts the Hub in a situation where it is dependant on what ICS can generate, which with fees etc might be insignificant for a long time period. I’m not even suggesting the Hub becomes a place for unrestricted dApps, just those that ATOM delegators determine are good enough to embrace into the Hub. These top tier applications can then be marketed to investors in other chains, while right now there is no real way to associate Cosmos the brand with these techniogical achiements since they exist on so many different chains derived from the Hub. The Hub needs liquidity directly onchain to become the actual hub. Remember, ICS chains can always eventually leave ICS and become sovereign, and if ATOM holders don’t own a significant share of the tokens then what was the point?…

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

I appreciate the shout out and wordsmithing session!

I have to admit that you’re probably not going to find a more marketable figure of speech. In our industry with our audience (which is severely lacking in women, who tend to be the ones most exposed to fat-shaming and diet culture although certainly not the only ones affected), I can understand that the marketability of that phrase outweighs the discomfort I pointed out. I get it, even though it makes me wince.

For an analogy for ‘feature bloat’ that avoids gender (‘Gaia’ as a woman) or fat-shaming, my mind goes to a congested transit system or bus (anyone taking public transit at rush hour in the summer may sympathize).

I think of all the features on the Hub as individuals who are trying to make their way in the nexus that the Hub provides - they’re active and they have their own motivations and goals that sometimes come at the benefit or expense of the Hub itself.

Crowded bus? Crowded Hub?

image700×375 69.6 KB

Thank you so much for the suggestion .

I think we’re not quite there with crowded bus, but I wanted to recognize that you had a totally legitimate criticism, and hopefully figure out a better way to communicate this.

It’s not precisely a crowded bus or a fat person.

During proposal 69, I had a less complete understanding of the issue.

Have you ever looked at the type conversions in WASM VM by any chance?

While previously I would have cited resource consumption as the primary issue, it’s the type conversions and the use of CGO, which I now believe is the primary issue, driving problems with both gas metering and resource consumption.

CosmosChain: Finally, I think using no with veto on legitimate proposals can lead to a chilling effect on new ideas This is because people might fear the risk of losing their funds, so would not risk proposing certain ideas. I agree with you and that is why I believe that we should remove the abstain and veto options. Veto should not be removed from every gov proposal, just every gov proposal type except for software upgrade and client update proposals. The reality is that we would not represent our delegators as if effectively as possible, if we did not adopt the prevailing definition of veto, which is, per 791 – sth I don’t like. That’s actually why I do believe we need to just remove those options. Generally, abstain at this point is more of a virtue signaling mechanism for non-participatory validators. CosmosChain: The hub has already encountered this dilemma before… is the hub a hub if IBC doesn’t necessitate a hub? Is the hub just one of many hubs if it’s not the center of the entire interchain, IBC included. A trusted dApp store at the center of the interchain would make the hub the ‘hub’, where all activity and transactions would flow through.…

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

Youssef:

We could envision enabling Mesh as an SDK module but that’s clearly not the right way to implement it and the end implementation would likely be less flexible

could you elaborate on this please?
was not aware you could speak on behalf of cosmos hub’s core dev about “implementation”.

by the way, what about chains which don’t plan to use CW VM? Should they be condamned for years to not be mesh secured?

if it’s technically possible, or if it needs research, we should fund this.
the hub should be open to multiple scenarios.

and regarding those potential scenarios, the feasibility of their implementation, maybe we should listen to devs more than bd folks.

(edit: not dunking i just feel its a rushed statement sorry )

https://twitter.com/jackzampolin/status/1644068839695745026

Hi Tom,

My comment on CW as an SDK module not being a good option comes from a direct conversation @jtremback and myself had a few months ago where he was telling me this exact thing.
Just saw you edited the post, I was about to say I didn’t appreciate the tone of your message but we’re good now

it’s fair, and probably right i don’t know. from what i see/saw there are different takes and perspectives about this,

maybe it’s not cool with ICS v1.5/2?

if there is some sort of consensus around “clearly not the right way” (i may have missed this) i would respect - again not dunking i felt it was a definitive non-option ?

happy to learn more overwise

(ps: je dois faire des phrases étranges en anglais aussi et ouai je suis sec parfois pas de méchanceté en tout cas)

I don’t think that waiting for some hypothetical and currently non existent Go implementation of Mesh Security is a great idea, because I don’t want to see the Hub stuck on a weird alternate version of Mesh that nobody else uses.

I personally don’t have strong feelings about the idea of doing other CosmWasm apps on the Hub one way or the other. It seems like it would be pretty easy to disable the uploading of contracts other than mesh security, but personally it seems like people could just vote against contract upload props if they don’t want them.

jtremback:

people could just vote against contract upload props if they don’t want them

people don’t care. people are degens. people made Anchor successful.

but i agree it should be that way

Good discussions here, I appreciate it. I don’t have strong opinion on Gaia’s roadmap and will stay neutral on the question if CosmWasm is valuable to the Hub or not. On the technical side of things, Confio is committed eliminate or mitigate roadblockers in case they still exist. 2 years ago, Terra started to hit hard on the software in a large scale deployment. A few smaller bugs such as memory leaks were found and fixed. Dozens of chains joined the party. Ongoing development made the software better every month since then. As Jacob is not getting tired of writing a lot of text arguing against the use of cgo, please note that I (the person working full time on this software for more than 3 years) disagree with it. Some brief thoughts here: • C interfaces (FFI) are a standard way to link various software components together. It works well for decades across a variety of languages. It comes with some cost wrt. maintenance but is also not scary by itself. Being able to reuse software adds value. While it might not be Go best practice, it certainly is Linux best practice. • We developed mature ways to efficiently transfer binary data over that interface, which in many cases…

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

IMHO I am against CW on the hub itself because it will open a lot of challenges as every app will try to be on the hub and it will prove very difficult for the hub to handle all the governance. If we go the non permissioned way it might be dangerous for the liveliness.

And now About ICS Chains. we could have stopped at one for now with LSD on the neutron or at least the could have used the duality model. or we can still improve on that.
Stake atom on hub and receive rewards as of now.
after this an additional signal to bond to certain ICS chain where you will get rewards and voting right for that ICS chain only.

The goal would be for every app to aspire to be accepted by the hub.

Regarding governance overload, I think ATOM delegators would love nothing better than to look into these projects and decide if they are worthy of the hub, but I do concede that eventually it would not be feasible.

That is why the hub could utilize some of the great tech that has since been developed, such as DAODAO.

Using this, the hub could have sub-daos specifically elected to filter out requests for ascension to the hub. Governance would have the final call and be able to dissolve these sub-daos at will.

The hub has historically been pretty conservative, which is wise. But I do feel permissioned wasm is mature and has proven itself to move forward with.

Having these top-tier applications on the hub opens the door to marketing the potential of Cosmos to everyone in the crypto industry, and reignite their interest.

It’s time to turn the tide on all this Cosmos fudding.

Just wanted to weigh in here really quickly. I do think there’s a future for CW on the Hub, but it requires a very clear description of what is and what isn’t in scope for the Hub to do.

If a proposal asking for CW is missing such a scope, I would vote against it.

Things I think that are very much in scope: Mesh Security & other Interchain infra services that can’t easily be built without CW. What could potentially be in scope: DAO DAO or similar DAO tooling, and other governance related software that can’t easily be built without CW.

What is not in scope? Pretty much everything else. I am wary of the Hub turning into an “Apple Store” tbh, especially when it comes to DeFi apps. I also don’t see how the Cosmos Ecosystem needs yet another L1 CW chain, especially when we have Neutron in the AEZ.

That being said. I would suggest we actually wait a bit longer with getting any sort of CW proposal online until we have a bit more clarity on the Hub’s long term vision, hopefully around the last quarter of this year when both Mesh Security starts taking shape and some of the research that’s funded by the AADAO wraps up.

It’s all about modular development, though. Do we want to see a permissioned module, that’s the question? Maybe it would be good to show, if any exist, permissioned modules that are already working. Could kinda help to make a decision IMHO

I would like to stress that point that right now some of the best tech is being developed outside ICS. And the Cosmos Hub cannot market these applications because they do not directly benefit ATOM holders.

One such example would be DAODAO, this is now on multiple chains and is the best DAO technology ever developed. By having this on the chain, it would directly benefit ATOM holders, whereby they could market this technology to other ecosystems like Ethereum… and blow their minds.

You might say, sure but why not just deploy it on an ICS smart contract chain? Well because these chains could leave ICS at any moment they want, and they didn’t drop a majority of their coins to ATOM holders in the first place.

The Cosmos Hub needs to focus on marketing, and this is one of the best ways I can see. Most people I talk to just think the Cosmos Hub has no real usecase because IBC didn’t bring a revenue, and ICS chains mainly just give a minority % of tokens if any, with currently miniscule fees - with no guarentee that they won’t leave later to mesh or other ICS providers.

jtremback: While I personally support CosmWasm being on the Hub, I wouldn’t want to see a prop similar to prop 69, with no killer app, being rejected. This would set a precedent of CosmWasm having been rejected not only once, but twice. I’d be worried that this would then make it hard to get it approved when we need it for mesh security. ala.tusz.am: However, I would vote no on the proposal in its current form (despite my support for CosmWasm on the Hub for Mesh Security) on the basis of it not including a risk analysis, implementation details, scope, and other important details that need to be considered for any technical change on the Hub. Noam: That being said. I would suggest we actually wait a bit longer with getting any sort of CW proposal online until we have a bit more clarity on the Hub’s long term vision, hopefully around the last quarter of this year when both Mesh Security starts taking shape and some of the research that’s funded by the AADAO wraps up. We agree with the above comments. Moreover, this seems a rushed proposal and it seems that it is the first time CosmosChain has posted on the forum. Therefore, we will vote no…

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

Thanks for participating in governance!

Regarding the first time posting on the forum, I spent 4-5 months pushing the idea of having smart contracts on the Hub nearly 3 years back. Although at the time the tech was no where near ready and battle-tested.

I mainly use other platforms though.

Hey all, Disclaimer : I’m a core contributor to Neutron, the first consumer chain and a cosmwasm smart-contracting platform. The main arguments for introducing permissioned CW to the Hub seem to be the following: • Bring DeFi to the Hub and generate tx fee revenue • Enable smart-contract based governance on the Hub • Enable mesh security on the Hub I generally agree with the technical commentary on CosmWasm in this thread. CosmWasm is a well-built technology. However, generalized permissioned CW on the Hub is likely to lead to poor results: 1. DeFi adoption will likely be poor Building an ecosystem of DeFi applications is not as simple as enabling a vm and waiting for adoption to occur. • DeFi requires infrastructure (trading infra, oracles, cross-chain infra, developer tooling etc), business development efforts and active support to builders. The Hub is currently ill-equipped for this, and changing this would destroy the minimalist hub vision and reduce the stability/reliability of the platform due to the accelerated pace of network upgrade. • Permissioned CW is also a pain for developers as it makes maintenance and iteration of the deployed contracts a lot…

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

This proposal suggests a big change to the Cosmos Hub’s roadmap but is too broad and lacks a thorough analysis of risks and scope. Regardless of what the Hub’s vision is, it should be well thought out. Given the broad scope of this proposal and the many unanswered questions, I’m voting no. I don’t have strong views on whether we should put CosmWasm on the Hub. There is already lots of code on the Cosmos Hub, and CosmWasm can be just another tool to implement code - end users don’t really care about how features are implemented. In theory, you could implement the entire Cosmos SDK/Hub codebase in CosmWasm, and run a CosmWasm Hub client! So maybe it makes sense to put CosmWasm on the Hub to add specific features like mesh. But, this proposal doesn’t mention any features that require CosmWasm today. The intent of this proposal is to make the Hub a “dapp store” by adding CosmWasm. This is a valid vision for the Cosmos Hub: as others have pointed out, new dapps can attract users and make the Hub’s value proposition clear. Maybe ICS isn’t enough of a value proposition. In the short term, I would expect CosmWasm dapps on the Hub to attract attention to ATOM / the Cosmos Hub. And,…

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

If we get CosmWasm on the Hub, there must be a clearly agreed upon constitution about what is permitted via CW. It can be amended as time goes on, if features in the future become a value add to the Hub.

We need to quit putting up proposals before things are truly flushed out. From what I see, Apple Store was not what anyone wanted for the Hub. Let’s have a discussion on what a seperate, better worded proposal that is more aligned with the community’s vision for the Hub.

Let’s get a new proposal up that includes Mesh Security and expresses the strict nature of it being permissioned.

Is it a strange coincidence that everyone affiliated with an ics chain or a future, possible ics chain - are all against permissioned CW on the hub? Asking for a friend

conflict of interest

It’s really simple imo:

“What should be allowed on the hub’s Permissioned CW?”

Infrastructure Code = Good
App Store Apps that compete with the ICS Chains = Bad

The whole premise of competing with the ICS chains is silly…why would we charge rent to chains we’re actively trying to make fail by competing? It is absolute nonsense.

Most free market economists consider competition to be one of the fundamental signs of a free market, not to mention the role competition plays in the growth of product quality, turnover/liquidity, etc. Just saying

This is one of the reasons it crazy to me that we don’t have a competing proposal on-chain right now, giving better details into the permissible code types that the network approves of. It is a sign of good faith on the behalf of the Hub, to the consumer chains, that we will only permit infrastructure code, that will help to alleviate pain points in the AEZ, which they reside, for example. Especially one that includes the need for Mesh Security code.

These proposals are a social contract whether it’s a signaling prop or not, I have a hard time accepting the current state of this social contract. Let’s get a better one put on-chain so I and other people who wish for this proposal to not include items such as a “Apple Store” can vote yes.

A lot has been said. TL;DR is we have to start somewhere.

Torn here since

1. iterative development and growth of software is healthy,
2. decentralization is iterative, even L2 indexers do so, before they open up to be permissionless
3. some chains are well fit for Replicated Security, and some aren’t

We will vote YES on this.

Replicated Security and CW “App Store” seems like two entirely different things, one focuses on underlying bootstrapping of a chain, and another is user facing.

If there are other sentiments at play, let’s voice it out here or set it out in a Twitter Spaces discussion. Have someone like Chjango host (not sure what her handle is here). Happy to participate.