Questions and concerns about DFINITY Foundation working "beyond core protocol"

Hi there ICP community,

Jan Camenisch (CTO of DFINITY, @Jan ) and I want to address (and ask for clarity) on some concerns we have heard about recently in the community .

We want to open up a dialogue to understand a bit more.


  1. DFINITY is spending too much time and resources outside core protocol
  2. The DFINITY Foundation is not good at UX and should not work on frontend things like NNS Frontend dapp
  3. DFINITY should give more grants to the ecosystem rather than hire more.”
  4. SNS is too rigid. It does not work for my use case”

Where we agree

We agree wholeheartedly that the Internet Computer can only succeed with a vibrant developer and entrepreneur community. DFINITY is dedicated to supporting the community as much as it can. We also agree that currently the relative core strength of the DFINITY foundation is cryptography, systems engineering, and distributed systems compared to frontend engineering.

“DFINITY should give more grants to the ecosystem rather than hire more.”

We also agree that giving more grants to help the ecosystem is good. DFINITY developer grants are indeed accelerating in volume and teams and will also be used more strategically to target specific needs raised by the community including as libraries for dapps.

Where we would like to provide some context

“DFINITY is spending too much time and resources outside core protocol”

  1. We think the perception here is understandable (we created it!), but not quite right - many projects that people think DFINITY is working on are a tiny minority compared to cryptography or distributed systems work. As stated at the latest global R&D meeting, we will provide more frequent updates on the roadmap and hopefully in a format that gives better insight in what the teams are working on in what order of priority, but here are some numbers on the number of people and priorities from July 2022:

  • Note that items with a heart symbol are by request from the community and that priorities may change depending on input from the community and shifts in the blockchain market conditions.
  1. NNS Frontend Dapp and II are more than application level concerns - NNS and the II authentication are an integral part of the Internet Computer and in particular it is essential that these components be highly secure, that is why it makes sense that the cryptography and security relative strength of DFINITY be invested at making these bulletproof.

“The DFINITY Foundation is not good at UX and should not work on frontend things like NNS Frontend dapp”

  1. The NNS Frontend dapp development was slow because of migration, not lack of UX skills - We have seen this pop up a few times and it is also understandable. We agree partially with some of the conclusions, but not for the same reasons. Allow me to explain:
    A lot of the “DFINITY is not good at UX” perception came from the fact that the NNS Frontend Dapp was sluggish dapp (and it had wonky user experience). It is fair to say that the user experience of the dapp was not great in the months after Genesis and that the foundation possibly wrongly did not prioritize its enhancement enough during that time. However, I do not think the community understood why. There was a perception that DFINITY needed more design help for the dapp. But the truth was that the limiting factor is that the dapp had to be rewritten/re-architected entirely from one framework (Flutter) to another (Svelte) while still functioning as a safe governance and staking mechanism for many, many people. This migration took longer than expected… but once it finished, it became easier to dedicate energy to improving the user experience.

  2. We agree that NNS Frontend Dapp is not optimized (yet) so that entrepreneurs could ship “NNS frontend Dapp with a different UX”… but more work has happened here than folks may be aware of - Some entrepreneurs have mentioned that they would like to take the code of something like the NNS Frontend Dapp and modify the UX so they can offer the security/safety of the dapp, but their own UX. This is a worthwhile goal! When I ask folks what is stopping them from doing this, some people tell me the NNS Frontend Dapp is not architected for such clean modularity (“keep the security, change the UX”) other than trivial CSS/HTML changes. What folks may not be aware of is that the NNS Frontend Dapp team did create a few libraries for the purpose of making it easy for the dapp to be adopted by others (in particular nns.js): GitHub - dfinity/ic-js: Libraries for interfacing with the Internet Computer. . It is apparent there may not significant attention drawn to these efforts (we should fix this)… but if these efforts do not address people’s intent, let us know so we can iterate.

Where we would like to understand more

When we hear folks say “SNS design is too rigid. It does not work for my use case”, we usually think two things:

  1. Yes, we can always add more flexibility post-launch. Why do people think the SNS will not change?
  2. The code is public. Folks can launch their own versions suited to their needs.

That is why we are looking for ways to understand the community more here. Also, while building this first version of the SNS, we were constantly talking to teams that aim to use the SNS to ensure a product-market fit.

Below are some thoughts and questions we want to hear more from:

  1. Our intent is that the initial default SNS system be quite limited and rigid… then expand over time as the patterns emerge. Limiting scope and ensuring that that limited scope works end to end was intentional as to be able to release a first version as quickly as possible. Such a release also allows us to learn from usage and iterate to improve. We are honestly not quite sure why folks focus on the initial launch over the future iterations? Did our communications imply SNS will never change? If so, that was our mistake.

  2. We have this nagging suspicion that the IC community sometimes speaks as if the SNS codebase is rather closed and prohibits innovation. But the SNS code is public so developers can learn from it, fork it, and build according to other needs. If we created this perception, then we need to rectify it. Did we imply or say in our communication that people should not be forking the code? Is the problem that it is feasible, but too painful to do this? We want to learn so we can improve.

  3. We are also not sure why people sometimes speak as if SNS was the ONLY way to tokenize assets. Any entrepreneur can make their own smart contracts. Also, we highly appreciate anyone who builds their own governance and tokenization canisters, be it based on the ones we provide or totally from scratch, so that we can all learn from different approaches and explore different ways. At the end of the day, that is how a flourishing ecosystem is built and how progress is made. So, is the concern here that SNS would have some structural advantages that say “Diego’s homegrown tokenized dapps” would not? We definitely see three points of structural advantages the SNS has… Are these what folks are concerned about?

  • Access to community fund
  • Having its own subnet
  • Press and promotions with DFINITY as a vocal promoter

Please tell us in this thread what you think. Thank you!


For my part, I was under the impression that this was being developed as a protocol-level feature, much like the NNS itself. I think there are many in the community who already see this as the “trusted” solution for governance on the IC. I don’t think it’s an overstatement to say that most viewed the SNS as the ERC-20 of the IC.

Again, just speaking for myself, I was a bit shocked to learn that deploying an SNS in a decentralized manner required an NNS proposal. To me, that seemed to counter Dom’s vision of a developer in a coffee shop (implying no real funding or backing) raising funds for their application.

That being said; @Jan reached out on Twitter to let me know that this requirement was driven by a technical constraint and is not something that is desired long term. That made sense, but I still fear that larger well known teams that are permitted to launch through the NNS will have a significant advantage over smaller developers.

Edit: I just want to add that I appreciate you and DFINITY for asking these questions. I think this is a very complex environment and it’s good to have open discussions like this.


I know it’s not related to the SNS related questions, but one bit of feedback is the road map is missing the two proposed features which were approved 3 and 6 months ago (55651 & 38985) and that the community is currently trying to communicate is very important to them via the ongoing proposal 72189.

I’m guessing they’re included in the “…” but I don’t think that gives the right message to the nns/governance community, it basically suggests those features didn’t even make the “later” list.


Based on the fact that almost every R&D work took longer than expected… took the BTC integration as an example, how many time you postponed the plan? As a community member that don’t fully understand the code, I just feel that seems that the Dfinity team is not so believable because they postponed the plan again again and again and don’t provide the R&D changed real-time details, how can the community members could believe based on that?

Do you think about that the team could:1) drive more other engineers to do some work? 2) Provided more real-time R&D details so maybe more engineers from the community could get involved in?


I probably need a longer post, but I’ll offer that there is a bit of a “suck the air out of the room” issue. You guys have to deliver to a high standard, so when you say your going to do something everyone assume you will do it well and thus we don’t need to do it so let’s do one of the other 1_000_000 things that need to be done.. I don’t have a solution for it, but it is an observable phenomenon.

Some pod cast recently mentioned the Heisenberg principal…something something if you observe something you change it…When dfinity says they will do something they change who else works on it and raise expectation for it’s delivery. Dfinity can’t launch an experimental product because too much is kn the line and people feel this inherently. We should have 10+ independent dao and instead have 2 and one announced because dfinity announced the SNS. :person_shrugging: What do you do.


I think DFINITY needs to keep providing explanations like this in response to community concerns, keep asking for feedback, keep iterating, and most of all, keep pressing forward. The foundation is doing a fantastic job and setting a good example. It’s impossible to make everyone happy.


This issue I have is these heart symbol ‘the community requested this’ features. Were all of those put up for NNS vote? If not, why? And who is deciding what community requested features to prioritize? Bc I know we (Psychedelic) have requested features, I know Jordan Last has suggested many important features/improvements, DSCVR, and others, and a lot of those don’t seem to be on your list. ‘Anybody with a twitter account’ should not be the bar for who is allowed to influence the entire roadmap of the protocol, that right should be earned. And I don’t think the foundation should have unilateral authority to decide which community suggested features get prioritized. That should be the decision of the community/NNS.

So here’s one suggestion. Make that process transparent. Each community requested feature should include WHO is requesting it (the most prominent 1 or 2 projects or people in the space requesting it), along with an explanation of why and how urgently they need it for their use case. And then let the community/NNS decide and prioritize which ones to work on.

It’s not so much what the foundation is working on that’s the issue. The issue is more so how the foundation is deciding to work on these things and how the foundation is making these important roadmap decisions in a silo and then hiding behind hand-wavy NNS votes or excuses like ‘the community requested it!’ to justify it. That needs to stop.


It seems like you are describing how forum deliberation and NNS Governance Motion proposals are supposed to be used. Why not try it? Write up your most pressing feature and post it in the forum under Governance. Deliberate for a week or two. Submit to the NNS as a governance proposal. Then you’ll know what the community and governing body thinks.


That doesn’t really solve the issue I talked about. I want to see it done for all the heart symbol denoted features that the foundation themselves shared and are apparently already decided to be on the protocol roadmap. Each of those should be written up, and who (top 2-3 projects/people/advocates for the feature) should be known and each of them should write a short description (1-2 paragraphs is enough) of why they want it. and then lets vote on it/discuss it and/or rank all of those currently listed with hearts from highest priority to lowest priority/don’t work on it. adding new features into the conversation at this point would just complicate things. they’ve already got their plate full. lets try to clear some room first.

1 Like

It’s nice Dfinity is listening to the community and working on suggestions. It makes the community feel heard and acknowledged and motivates them to build and participate.

That said, Dfinity is a centralized entity with its own views on what is important. Dfinity makes no pretenses to be decentralized. It’s the IC whose goal is to be decentralized.

I’m not sure why Dfinity needs to do anything the community suggests if it disagrees with those suggestions.

One day once the IC is a smashing success there’ll be many foundations with competing goals and resources. The IC will compete with AWS.

Again to me making suggestions to Dfinity is great! It shows care and dedication. But it seems a bit odd to demand those suggestions be acted on.


That’s fine if they want to do that. But then they should just communicate that and stop wasting peoples time with the on-chain governance/NNS stuff. Like what was the point of putting those 25 roadmap items up for NNS vote when the protocol just launched? That obviously sends a signal to the community that the foundation wants the NNS in control of the roadmap. But then all their actions since then seem to indicate that isn’t the case and the foundation is just going to do whatever it decides it wants to do. So again, if they want to do that that’s fine, that’s how most other protocol foundations operate. But lets remember they are the ones who made a big deal about on-chain governance and how differentiated they are because of the NNS, and they are the ones who started out by putting roadmap items up for NNS vote. So if things have changed since then, the least the foundation could do is communicate that to the community.


I think that’s fair criticism with respect to putting up the roadmap on the NNS.

That said, it seems clear Dfinity does want to solicit feedback and involve the community. It wants people to feel acknowledged and to learn and grow and improve. They know they will make mistakes and want the feedback. But again, ultimately, management will make the decisions they believe are best for the future of the IC.

It is not fair to paint the picture in black and white and say it’s either all or nothing, ie it’s either the community decides what Dfinity works on or Dfinity management decides what they work on.

The reality is that at the end of the day Dfinity management will decide but they deeply care about incorporating everyone’s views. But of course, only to the extent they agree.

In theory it is possible for Dfinity to be so out of touch they don’t listen to the community at all and their views diverge entirely from the community in spite of best efforts to listen. I really do not think that is the case and it would not be fair to say so. All you can hope for is that your suggestions are internalized, considered, and given serious thought. That is a sign of respect and based on this post from Diego it is exactly the message that has been sent.


For the time being it seems that only DFINITY has resource to develop, for example almost all the ICP tokens of Foundation are held by DFINITY, so the decentralized road should be lead by DFINITY. I was wondering if DFINITY has any plan to drive the Internet computer to be decentralized including distribute ICP tokens to other teams in the future?

I believe in the short and medium time, we can only rely on DFINITY rather than other teams, so DFINITY need to do the core R&D things is not what they have and need to do.


Is it safe to say that the foundation takes notice of community driven proposals, but reserves the full right to unilaterally act for or against the implementation of those proposals?

Let’s take for example the proposal to reset governance rewards weights to 1. The first time that proposal was sent to the NNS by @skilesare it was rejected by DFINITY and the community.

Had the community passed that proposal, DFINITY still could have rejected implementing it, as the act of updating the code and submitting a change to the local replica technically still is an “off-chain action”.

As it’s own entity, it makes sense that DFINITY reserves the right to ignore any action suggested by the community or the NNS.

Therefore, it would be beneficial for the community to be given the ability to submit changes to the local replica topic that would actually directly update various parts of the IC.

However, to this date I don’t believe that the community has the permissions or ability to update the various canister replica code (NNS, II, ledger, core IC) .

Until the community receives the ability to propose direct code changes to the replica, the IC (not just DFINITY) remains under centralized control.


I think these are two entirely different things that should not be mistaken for each other:

  1. DFINITY asks NNS to vote on things it wants to work on.
  2. A non-DFINITY organization (or person) asks NNS to vote on things it wants DFINITY to work on.

If we think NNS is a form of governance, is it democratic or totalitarian? Should it have overarching power to decide what/how a person or organization operates?

@harrison Do you want anyone other than you to submit a NNS proposal to decide what you work on?

Most likely you don’t. And yet, you think DFINITY given its unique position in this ecosystem should be subject to this commandment. I’d like to hear your reasons. Thanks!


They certainly have communicated on the progress (and obstacles along the way) in this thread: Direct Integration with Bitcoin. I think they are earnest and believable.


I don’t disagree with your point, but I do think DFINITY may have contributed to this. For example, here is a statement from Jan when I asked how the foundation plans to handle community proposals:

“… mandate to work on a topic…” is pretty strong language. It makes no promises of when that proposal will be implemented, but it does tell the community that directing DFINITY’s work through motion proposals is acceptable.


I really do support Dfinity taking some resources to build the application layer while the community is still growing and it is not big enough. Right now, there are just a few (all in early stage) products: SNS, Identity,Token Standard,etc. They serve as kickstarters for new projects. If someone thinks SNS does not fit, great, create your own DAO solution. This is very helpful to the ecosystem.


Ah that makes sense. Yes, this is a technical requirement for decentralization in short term (I admit I am not an expert on why it is a requirement since I am not in the weeds here), and my understanding is that they intend to remove this long term.

To be honest, I have heard this brought up few times and the fact that Jan and I did NOT list this in our top 3 community concerns shows it was not top of mind for me, so I have definitely learned my lesson.

Thank you. This is certainly a process.


Fwiw folks, my intent is to mostly stick to the rule of thumb of “asking clarifying questions” whenever I do not agree or understand something. The goal of this thread is for us to understand (not to change minds).

So please know any questions I ask are with that intent (they are not pseudo-clever socratic devices for pointing holes… they are to clarify what I do not understand).