Raising this discussion again with some further viewpoints that have emerged since the last time it was raised here:
New discussion points
Curation vs Aggregation
Stargaze is also a focused appchain but is currently having a vote to enable permissionless CosmWasm (Mintscan)
Further discussion on that proposal here:
Not all Dapps on chain need to be promoted by each frontend and both Stargaze and Osmosis have a strong target grouping of Dapps that the chain would prefer which is potentially the downfall of chains that begin permissionlessly.
Barrier to entry
Similar to permissionless pool creation on Osmosis, permissionless does not necessarily mean without barriers. A fee for contract upload could be implemented which would minimise the numbers of contracts uploaded with little use case and ensure that testing is performed on the testnet. The downside to this in my opinion is that is disincentivises teams from fast iteration or even deploying on Osmosis compared to a totally free permissionless chain if they do not need the low latency of same chain interactions. The benefit to that is that people will only deploy on Osmosis if they believe that the benefits such as proximity to liquidity, integration with other dapps and frontends and any chain features that differentiate Osmosis from other chains are worthwhile. This should almost exclusively attract only dapps that want to be part of the liquidity and account hub that Osmosis is building towards.
Security
One main issue last time was that a chain halt may be caused by a malicious upload. Any barrier in place would still render this possible. Osmosis validators have responded incredibly well in the past to get the chain back up and running while fixing the error. If the chance of this is sufficiently low then perhaps it is best to allow these uploads to occur sooner in the chainās lifetime rather than later in order to improve CosmWasm as a whole.
The last time this subject came up it was abandoned due to the idea of a Canary chain being proposed.
A canary chain would have the same impact as another semi-independent permissionless chain rather than gaining benefits of contracts deploying on the same chain as Osmosis despite being a more elegant solution.
Draft Proposal: Full Writeup based on feedback to follow.
Every vote in favor is met with roughly 3 against.
Permissioned is still ok for me, since it is still just 1 proposal to whitelist a team, after which it is permissionless for them specifically.
In essence the canary chain should be a very active testnet I guess, since that should reflect the AS IS on the mainnet as well. In ERP-development it is quite normal to make a copy of a live environment to serve as a test-environment. Would that not work for Osmosis and test environments as well? That would offer us a very nice canary chain already.
I think the Stargaze folks have it right by shooting this proposal down. One major concern over there was that people could build markets that allow for bypassing royalties and hamstringing a major source of revenue for the chain.
Similarly, per a chat Iāve had with the White Whale team, permissionless wasm would allow for them to deploy their LPs and arb vaults on Osmosis, which could be used to completely bypass / frontrun the protorev module. Those LPs also wouldnāt be subject to taker fees. I imagine any protocol could do the same.
It doesnāt seem to make sense to me to allow for separate, third-party liquidity pools to deploy on Osmosis when liquidity is already fragmented, especially if they can be used to eliminate two sources of revenue for Osmosis (protorev and taker fees).
Similarly, per a chat Iāve had with the White Whale team, permissionless wasm would allow for them to deploy their LPs and arb vaults on Osmosis, which could be used to completely bypass / frontrun the protorev module
They wonāt be able to frontrun protorev, because protorev is built natively into the protocol, and as such is triggered automatically after every swap tx.
Those LPs also wouldnāt be subject to taker fees. I imagine any protocol could do the same.
This is true, but if they want to be integrated into the Osmosis swaps module and frontend widgets, they need to integrate with the pool manager module which charges taker fees.
Thus any volume into White Whale liquidity pools on Osmosis would be net new volume that wouldnāt be being automatically captured by Osmosis anyways.
Note that Osmosis will still profit from this through MEV revenues through POB.
Youād know better than I would here, and I tried to explain this to them as well, but they seemed pretty confident that the existence of a second set of pools on Osmosis could be used to circumvent protorev when arbing between those pools and the ones natively on Osmosis. Maybe they were referring to arbs that settle on the second pair of pools? If so, that kinda implicates your second point that these arbs wouldnāt have existed otherwise anyway.
Although I do somewhat disagree here. This assumes that volume and liquidity in these pools would be entirely net-new, and not vampired over from the main Osmosis pools. Given the steep learning curve on concentrated liquidity pools and the lack of widespread vault availability at this time, Iām not sure that this would be the case. The CL migration has already fragmented liquidity a ton, and this could serve to fragment it even further.
Questions for a Permissionless CosmWasm on Osmosis
A) What is the reason for the success of Osmosis since launch?
B) What key apps have deployed on permissionless L1 chains that would have deployed on Osmosis if it was permissionless instead of onboarding via a permissioned model?
C) What is the vision for Osmosis today and how will this change with a move to permissionless?
D) Why will (killer) apps choose to deploy permissionlessly on Osmosis instead of another permissionless L1 and which (killer) apps would likely choose to do so
E) How does permissionless CW further enable the current vision for Osmosis (smart accounts - asset chain, CEX competitor and and anything else included in the vision in answer to question āCā)
And 6) What more does it bring to the near-permissionless we have for whitelisted addresses?
We are already permissionless if you are whitelisted. So that minor tollgate is keeping us from being permissionless. I still see the conversations here which are more like āevery contract upload goes through governanceā versus āpermissionlessā.
But that is not the case where we actually are.
So what little edge do we gain by removing the whitelisting-tollgate?
Iām struggling to see how we are creating any significant advantages from moving to permissionless and we also create potential irreversible disadvantages and design choicesā¦ Iām not an expert, but I am against the move and havent seen much counter argument for why we should be permissionless.
Would love to hear more about why this could be such a great move, otherwise there is no need for discussion
I had the impression I had already posted in this thread but apparently not.
Iām against the proposal, there are no clear benefits that canāt be had with whitelisted addresses right now. As shown in the Stargaze proposal, this didnāt pass there as well.
