Putting this here because I don’t want another top level thread and thought it would be a good place to keep the discussion going:
It came up on the neurotic podcast(@icpjesse @Kyle_Langham) that ICDevs was against having a token for any app that hadn’t been in existence for two years and I thought it was worth clarifying that position in a couple of ways.
-
At this point, the dev board hasn’t decided anything and the dev board is ultimately who will decide and each vote will likely be decided independently.
-
The position that I have (@afat) and the recommendation I’m currently likely to make is more nuanced than presented on the podcast.
2A. I am very much in favor of projects tokenizing and raising funds as soon as they need them and feel they can make a case to investors.
2B. I am very much in favor of DFINITY releasing the amazing work they’ve done on SNS token, governance, swap, and lifeline/upgrade canisters and I hope they will release Motoko reference implementations as well.(And I think they are best positioned to build solid secure canisters so I hope they keep up doing so…the commune should step up and build better/diverse uis to these canisters)
2C. I’m in favor of as many projects as want to implement these on application subnets and begin a grand experiment with on-chain governance as soon as possible.
2D. I’d recommend approving applications to move to the SNS subnet with “official” integration at the NNS level after that application has been actively governing >$100M worth of tokens for >2 years. We just have too much to learn about how this is all going to work for the NNS to get married to these ecosystems without dating for a while. A good case can be made for different numbers for different kinds of projects, but the guiding principle is to make sure the post-issuance governance is functional and properly decentralized.*
2E. If the SNS/NNS integration does go forward I’d recommend running any UI in an alternate url than NNS.ic0.app to avoid blocking NNS users from accessing their current investments in the case that the SNS domain is blocked by regulators. (Discussed at Proposal: Host the SNS at an alternative domain to avoid existential risk to existing NNS stakes)
This course of action would be more conservative, but would also give us a reason to lean on veering subnet migrations in place which is a key future security feature anyway. Instead of approving the issuance of tokens, the NNS would be voting to migrate known projects with already issued tokens to the SNS subnet. The is a light regulatory risk that SNS token approves could be held accountable for activating a non-compliant securities issuance. If the token exists already we are just voting to change some routing tables.
My biggest concerns are:
I would hate to end up in a position where ICDevs has to abstain or must reject due to regulatory reasons.
I don’t want blowback for inevitable Luna style blow up being easily tied to $ICP and depressing the price more than necessary.
“More than necessary” is probably a key phrase here. What I like some clear(er) communication on is why NNS gateting and integration is “necessary” at this time. It may be a great idea and I think we’ll have NNS integration in the future for mature projects, but I’d like a better understanding of why it is necessary at this time.
*I have skin in the game on this with my position at ORIGYN. The concern of a screw-up at Origyn being tied by the press to my/the board’s other significant investments in ICP is too great to launch on the NNS/SNS integration until we have a good understanding of how our governance of OGY will burn in. Separating “infant and toddler” tokens from the NNS makes an anti-ICP narrative harder to craft.(admitted they will try anyway).