I feel pretty strongly that for projects to be approved on the SNS there should be a set of minimum transparency and accountability standards we all subscribe to. If projects do not meet these standards, they should not be approved on the SNS – for that, let them go list on Daoabunga.
I do not want to turn the SNS into the SEC policing people but there should be a set of standards below which we should not go. The goal here is not to ban projects that we don’t deem good enough but rather to get accurate and transparent information out there on each project.
Turning back to 2017, a tidal wave of ICOs were used by teams to defraud and steal from investors. Apps claiming to dApps / DAOs were in fact fully centralized and developer teams ran off with the money. Apps with absolutely no need for a token launched a token and then their token crashed into oblivion.
Looking to the SNS, I think we should standardize some basic information in a white paper such for each project looking to launch. Thing like:
Legal Structure
For profit? Non-profit? Neither? A combination? Jurisdiction?
Product
How exactly does the product work? In DSCVR’s case, it is fairly obvious. Regardless, it could be clearly stated how the product is used by its customers.
A clear problem statement and solution statement.
Traction
Some basic metrics should be posted and audited on traction on the dApp. In DSCVR’s case, there should be information on daily active users, number of upvotes over time etc. In general, there should be some basic information on which brands are actively using their product and some KPIs on how they are tracking performance.
The SNS should not be a place where pre-launch teams go to raise capital. The process of decentralization means there should already be a high degree of project market fit and some number of users and love and use your product.
Business Model + Tokenomics
If the dApp operates purely on a token model, and no revenues are generated from selling a product, there should be very clear guidance on how the tokenomics work. The ICP token, for example, has a combination of inflationary and deflationary forces. When the deflationary forces overwhelm the inflationary forces, presumably that would accrue value to the token. Here the basic question remains: Why should your token increase in value with increased usage?
If there is a classic for-profit revenue model that co-exists alongside the token, that should be clearly explained.
We should know the token distribution model among the team to know that it is properly decentralized and that the DAO is functioning properly
Team
We should know exactly who the folks are behind each project that launches on the SNS. Investors should be able to make a determination if the team is competent enough to do the job
Tech Stack
The dApp should clearly state whether it is operating an open or closed source model and what its intentions are going forward. We still don’t have a Github for the IC so we will be relying on the team to not rug pull us and take down their Github account if it is public during the SNS
We should know what parts of the stack are IC and what parts are Web2 and what parts are other chains
If the best product in the world wanted to SNS but did not provide basic and clear information like the above in some sort of white paper I’d still be against allowing it to DAO’ify on the SNS.
It is my understanding that OpenChat is going to be the first dApp to tokenize on the IC. @lara I urge you to incorporate this feedback and provide it to the OpenChat team so they can set an example for all projects going forward. I would also urge Dfinity to provide templates and clear examples to teams so they can be successful out the gate.
I agree. I would prefer to see a minimum standard of transparency and accountability on these types of details for any project that intends to pursue SNS.
@dfisher thanks for tagging me!
I happily forwarded this to the OpenChat team and think they already planned most of this.
We also work on SNS documentation and plan to include some tips on what projects might want to consider / prepare in addition to the technical work.
I think it is great that the community defines what they expect from an SNS project!
One thing that is missing here is “what will be governed”? To me, this is the most nebulous part of this. Is it just canister management? Is there some other governance mechanism? Why do I want your token? Does it give me power over the protocol? Is it a utility token? What is the utility? Are you going to pay/reward people for doing something? If so, what?
In my experience, this is the hardest thing to really figure out.
Most folks “figure it out later,” but if you want a high standard on the SNS, then there likely won’t be room for that. If the bar is very high then very few will cross it.
Has openchat started talking about what their token will be used for? I’d suggest that if someone is looking to launch on the SNS in a couple of months they need to be talking about that now.
Also as a note, anyone will be able to launch an SNS token in application mode and this is going to be very confusing. Anything we can do to help the vocabulary around that now will be helpful.
I agree SNS needs high standards.
SNS needs to be a place for potential projects on IC to be evaluated through standards to call call for investment capital and at the same time keep SNS’s reputation as well as protect investors.
Hey!
I’m one of the OpenChat devs.
We are putting together a few documents (tokenomics, roadmap, architecture, team, etc.) which should satisfy all of the requirements for a ‘high standard’ SNS launch.
Thanks for this list though, we will use it to make sure we’re covering everything!
I am sure there are a lot of use cases, but from what I have in mind, canister management is enough. If I am building a large dapp, it will be best if I use other IC services/dapps/components. I will take (testimonial; comment; video player; dex swap; chat; ads) widgets from other projects. I will also probably need to rely on forwarding users to other pages/ opening popups and expecting them to come back.
So I’ve made something big, but it has pieces governed by a lot of parties and is live, updates. This is great if nobody decides to go bad. But someone could mess with testimonials & comments and put links to competing products. Put ads in the video player I use. Thus forwarding users elsewhere. One such business - really happening now is buying Chrome extensions and turning them into trojan horses.
If we use CF to govern these widgets, indexes, external site flows, etc, the community will have control and someone using them will be able to integrate projects into their app and not worry too much.
Not sure if that’s the plan, but that’s what I would like to use it for in the beginning.
If Openchat creates a widget, which I can insert into my site and is CF governed, I will use it, otherwise, I wont.
With CF a scenario like Opensea - where the community feeds a site with traffic + assets and that site decides to not give back to the community and make IPO isn’t possible.
I really think some sort of Term Sheet should a prerequisite for all SNS projects. The investor should have a very clear idea of the project, and where their money is going
,
Lets learn from the mistakes of ICO 2017 and set the gold standard for tokenization on the IC
Thanks @Sal_Paradise. I am in touch with the OpenChat team who will be providing a draft of their disclosures in the next couple weeks. I think at that point it makes sense to put together a small WG to discuss feedback to give them.