Upcoming Mops SNS Decentralization Sale

[singularity]

A great project. However, it seems like just a fundraise, then hype goes ice cold, then 51%. Better to just put such utilities under NNS control.

[nirvana369]

Besides the airdrop for those who have contributed to developing libraries and publishing them on Mops, if the project wants to grow and attract more developers, there should be a reward mechanism based on contributions (publishing libraries along with source code). I feel that the current token economic model is leaning more towards financial gain rather than fostering the essential values needed for the development of the project and the ecosystem as a whole. Meanwhile, the future of Wasm will bring better support with more improvements, such as modularization. I hope that even if token distribution doesn’t follow the decentralized direction as desired, DAO governance won’t significantly affect the libraries, otherwise, this could be the end instead of the beginning.

[Lorimer]

@infu

The MOPS token could be required to publish packages - this will make the services DoS resistant. Right now, if someone attack them, they will bring Motoko development to a halt for a while

That sounds like a great idea to me. Thanks @infu

@Seb

Just let the market figure out if the token has value or not.

You could apply that reasoning to any SNS launch. This has been the mentality applied by many on previous SNSs, and I think there’s plenty of evidence to suggest that by and large this doesn’t produce desirable results. In numerous cases quite the opposite.

@Leadership

One factor that enabled this was the relatively low cost of tokens on the open market due to people selling their tokens. This is often correlated with projects not demonstrating significant progress or transparency on milestone achievements, missing the opportunity to form an engaged community, and insufficiently communicating long-term tokenomics or business plans.

The reason that SNSs have to pass an initial launch proposal is precisely to check that the project meets a certain standard and some basic criteria.

@Seb

This can be figured out later

There’s no incentive for this to happen while the devs still have a treasury they can draw from. All the while those who invested will no doubt feel very bitter about this.

Who’s going to audit how those funds are spent. Many of the tools and utilities mentioned are offchain. Therefore they’re not owned by the DAO. How much of the funds raised will go towards building these sorts of things? Whatever the commitment is, who’s going to check that this is the case?

@Leadership

We do think that the recent events surface some weaknesses in how the SNS frameworks are currently used and how the DAO communities are engaged in discussions and decisions

A reason for investors to invest (and also to participate in governance) should already be established, or the project is too early for an SNS launch. That’s the way I see it, and that’s the way I’ll vote.

Why not take a look at working on @infu’s suggestion first.

@Leadership

Teams must consistently demonstrate that the project is evolving and that holding the token remains worthwhile

[ZenVoich]

Proposal to create Mops DAO is now live!

https://nns.ic0.app/proposal/?u=qoctq-giaaa-aaaaa-aaaea-cai&proposal=137503

SNS config changes:

• Max per user: 1,000 ICP → 2,500 ICP
• Transfer fee: 0.01 MOPS → 0.1 MOPS

[Lorimer]

Proposal 137503 Observations | LORIMER

VOTE: NO

TLDR: Doesn’t meet well-established minimum standards for a compliant SNS launch.

The SNS yaml has been changed in the last 7 days, and only announced after submitting the proposal. This violates well-established SNS launch syndication requirements.

@bjoernek

The syndication (once all parameters are fixed) should last at least two weeks.

A reason for investors to invest (and also to participate in governance) has not been established. There is no reason for investors to hold onto their tokens, so nothing will protect this DAO from governance capture and centralisation. I see this launch as an abuse of the SNS system (as described in my comments above).

I value Mops, and the work that has gone into it. However it does not meet the standards that should be expected by an SNS (one that is fit for purpose, with product-market fit that gives the governance token value).

---

If you found this analysis helpful, you may wish to consider following LORIMER

[Phasma]

That’s a solid analysis. I completely agree.

[Gwojda]

Fully agree with you, also voted no on my side

[tiago89]

@ZenVoich

I love the Mops project, but I really believe the current setup gives worse guarantees than you centrally controling it

When I read the proposal today, it immediately worried me this would be risking a takeover, then I read the majority of the posts in this thread warning you about a future takeover.

The posts of @infu are very good on highlighting the risks you are taking:

@infu

With your current settings and giving 71% to the swap, it means someone can buy a lot with a script and then take the rest of the treasury out. (NF usually protects from that, but there is no NF here)

@infu

I’m not sure if Caffeine uses Mops directly, but imagine tens of thousands of apps relying on it. If someone gains control over the Mops canisters, they could change a library and potentially launch a supply chain attack - draining DEXes, escalating privileges, or worse.

Zen, if you allow the majority to be “economically” controllable, then any bad actor with more economic power will for sure “grow” their voting power and “silently” let pass a package update and execute a Supply Attack. This is too dangerous to the ecosystem!

I have voted NO and would urge others to vote the same. Only because this setup is not ready.

What I would prefer to see is the distribution of power to be:

• 30% to SNS Sale
• 20% to Team
• 20% to the Package Contributors
• 20% to a group of trustworthy long-term Package Users (Like infu, Dfinity, other dev teams that use Mops, etc.)
• 10% to CodeGov or Co-Delta teams (striking a deal of audit support on reviewing the proposal updates, packages, etc.)

This distributes tokens to people who will vote in the project’s best interest. You can even assign these neurons with a max dissolve delay of 5 or 8 years, making it more attractive to sell voting rewards than to sell the neurons themselves. (Even if you later reduce the reward policy to 2 years, these neurons will retain their 8-year dissolve delay.)

Please @ZenVoich , it’s not too late to prevent this current setup. Can you please reconsider? Apologies for not having seen this earlier.

Regards,
Tiago

[ZenVoich]

@tiago89

if you allow the majority to be “economically” controllable, then any bad actor with more economic power will for sure “grow” their voting power

The same means there are will be good actors too, who can “grow” or “keep” their voting power.

@tiago89

Please @ZenVoich , it’s not too late to prevent this current setup. Can you please reconsider? Apologies for not having seen this earlier.

Let’s see how the community votes. I think just one DFINITY vote could change the outcome.

BTW, DFINITY could be the biggest good actor, grow and keep voting power… or simply vote “No”)

[DanGTZ]

I totally agree with @tiago89 and @Lorimer on their comments:

There is no value or utility given to the token, making it cheap for any bad actor to take over the library and harm the entire IC ecosystem. On the other hand, there is no incentive for a good actor to lock their capital in this SNS. Who would do this just to protect the IC ecosystem? The only good actor that might have such an interest is DFINITY.

To fix this problem, I don’t think giving the team a bigger share is the only solution. Instead, there should be real token utility built in from day one of the SNS, this shouldn’t be figured out later.

[dfxjesse]

I have been using mops for a long time now and it’s great, I remember being around when we had to use vessel to install packages, and that sucked so bad, you had to install some weird binary and browse github repos and copy urls to get your package.

Mops makes developing production motoko apps on ICP 100x easier. I don’t know a motoko dev who is not using it. I think this is a critical piece of ICP infrastructure and I’m guessing @ZenVoich needs some funding to keep maintaining it. I think that in itself is a good use case for the SNS. Will you make 100x return on your money by investing in it ? Probably not. Will you support a developer that is building a key Motoko public good? Yes.

I see this like building roads in a country, no one invests into roads, but we all need them and rely them for the greater economy, mops is the same, it directly benefits ICP motoko development - and maybe the dapps that get built from that, can bring in the 100x return. But if we neglect the roads we hurt everyones business.

If you don’t think the SNS should be used for things like this, then I think at least we should be offering alternative solutions for developers to get funding to build critical infrastructure (outside of Dfinity grants), and maybe it should come from the NNS directly, but we don’t have that system yet.

[ZenVoich]

@dfxjesse thanks for supportive words)

In addition to the concerns raised in this thread I see a small % of community participation in voting, which makes less sense to launch SNS.
Therefore I’ll consider aborting the SNS launch. Postpone the governance question for at least a year. Keep working on Mops with grants support proposed by DFINITY, and which DFINITY has provided in the past.

[wpb]

@ZenVoich

Therefore I’ll consider aborting the SNS launch. Postpone the governance question for at least a year. Keep working on Mops with grants support proposed by DFINITY, and which DFINITY has provided in the past.

@ZenVoich will you please clarify what you intended to say here? Are you still considering postponing the SNS or have you already decided that that’s what you want to do? I can reach out to folks in Synapse and CodeGov to let them know, but you really need to make sure folks at DFINITY see this message before they vote. I can’t tell if you are in discussions with them on this topic from what you have posted. It’s important that this proposal is rejected if you have decided to postpone.

@cryptoschindler @Lomesh-dfn1 @bjoern @bjoernek @lara

[ZenVoich]

@wpb

It’s important that this proposal is rejected if you have decided to postpone.

Removing NNS root controller should be enough to abort the SNS, even if the proposal is adopted