Everything is important here:

• Team - the professionalism (what we can detect externally), the quality of communications determines the longevity of the project and the response to your requests

• Concept - how well the project is described in the documentation / FAQ / website. Does it meet all the criteria I will tell you about next

• Coin - how good the tokenomics is, the level of investment and the quality of investors (do most projects not dump 90+%)

• Code - is it open, are there main repositories and what is the activity. And most importantly: are there audits and are errors / vulnerabilities fixed

• Practice - how good the functionality is, does it work, is it full.

1. First I ask in Discord: is there information about them on LinkedIn or similar service, tokenomics of the future or existing token and is the code open. The answer from them determines the quality of communication.
   After studying the concept, I sometimes ask another question. For example, in one of the last projects, I found out that they have a centralized backend (they didn't write about it directly in the documentation).
   If the reaction is indirect (evading), absent or off-topic - the risk of poor communication when closely interacting with the project or its closure / lack of success

2. I look at social media: X (activity and check for bots in Moni / Tweetscout, and also who subscribes to them: if there are large funds or projects - good)
   In the same section, I report whether the team is open: do they respond and how politely. Because sometimes they are silent or write off-topic

3. I study other social networks: LinkedIn, blog, Telegram, etc. This is not the main thing, but if there is an active community there - better
   If social networks are inactive and do not answer questions, the risk of project suspension and poor feedback at critical stages increases. If there are many bots in X - the risk of inflated parameters = poor quality (not guaranteed, as boosting can be tasks with rewards)

Most often, this is documentation, white paper (less often) and FAQ.

• Is there demand analysis in them: if not - the risk that the project does not understand the market = cannot make a good product. Or they are making a product that there will be no demand for.

• Competitor analysis: pros and cons of projects or at least their list. Allows you to understand that the founders are monitoring the market = reduces the risk of creating a weak product

• Technical information - if there is none or little, it means they are hiding something (for example, the project is centralized = works on one server). At least the architecture with a detailed description of how everything is arranged should be

• Lack of user documentation (instructions) increases the risk of low demand and low user retention, especially in complex products

• Information about fees and other prices - if not, there is a risk of unexpected charges.

• And in general, how detailed the project description is, is everything clear (at least with explanations of neural networks)

Not all projects have tokenomics, as there is no token and it is not planned yet / very early stage. But I consider this section critical, as weak tokenomics increases the risk of price drop.

In analytics:

1. Is there a tokenomics?

2. Is the distribution normal: maximum 10% to the team (extreme - 15%), maximum 10% to investors (extreme - 15%)

3. How much is allocated to the community at once and is there a ready product that can generate demand for the token / good market makers? If not - risk of weak price (even investors may not wait for a good fix on unlocks)

4. Are there no sharp spikes during unlocks (unlocks of 10% of all tokens a year after TGE = almost guaranteed price drop if there is no strong demand due to utility)
   Acceptable risk - < 0.9% of all tokens per month

5. Utility: are they spelled out and how good are they. Buybacks with a good product, paid features and other utilities can support the token.
   If not spelled out or, for example, only staking with DAO - risk of weak support.

6. Capital: is there public capital of the team / investments. They can support the price.

Also, I'm looking at investments:

• Amount

• And who invested. There are some funds where the absolute majority of projects have fallen by -90% and more. Don't you agree that this is strange?

• Is it open?

• Are there repositories of the main programs of the project? For example, blockchain nodes, smart contract processor...

• Is development active: are there periodic updates?

• Are audits published? How long ago? If there have been significant updates recently but audits are old - risk of new vulnerabilities or errors.
  If everything is fine, have all the issues described in the audits been resolved?

• The more "no" answers to these questions, the higher the risk of poor project quality. The code may be good, but it's hard to assess.

1. Does the functionality work at all?

2. How complete and clear is it? Sometimes there is some functionality in the documentation, but it is missing in the interface.

3. Does it match the description in the documentation (concept)? For example, are there no additional fees.

If there are "no" answers - risk of poor project quality.

This article describes the approach. In specific cases, the accents and risks may differ - that's why I always look at projects in context.

Everything is important here:

• Team - the professionalism (what we can detect externally), the quality of communications determines the longevity of the project and the response to your requests

• Concept - how well the project is described in the documentation / FAQ / website. Does it meet all the criteria I will tell you about next

• Coin - how good the tokenomics is, the level of investment and the quality of investors (do most projects not dump 90+%)

• Code - is it open, are there main repositories and what is the activity. And most importantly: are there audits and are errors / vulnerabilities fixed

• Practice - how good the functionality is, does it work, is it full.

1. First I ask in Discord: is there information about them on LinkedIn or similar service, tokenomics of the future or existing token and is the code open. The answer from them determines the quality of communication.
   After studying the concept, I sometimes ask another question. For example, in one of the last projects, I found out that they have a centralized backend (they didn't write about it directly in the documentation).
   If the reaction is indirect (evading), absent or off-topic - the risk of poor communication when closely interacting with the project or its closure / lack of success

2. I look at social media: X (activity and check for bots in Moni / Tweetscout, and also who subscribes to them: if there are large funds or projects - good)
   In the same section, I report whether the team is open: do they respond and how politely. Because sometimes they are silent or write off-topic

3. I study other social networks: LinkedIn, blog, Telegram, etc. This is not the main thing, but if there is an active community there - better
   If social networks are inactive and do not answer questions, the risk of project suspension and poor feedback at critical stages increases. If there are many bots in X - the risk of inflated parameters = poor quality (not guaranteed, as boosting can be tasks with rewards)

Most often, this is documentation, white paper (less often) and FAQ.

• Is there demand analysis in them: if not - the risk that the project does not understand the market = cannot make a good product. Or they are making a product that there will be no demand for.

• Competitor analysis: pros and cons of projects or at least their list. Allows you to understand that the founders are monitoring the market = reduces the risk of creating a weak product

• Technical information - if there is none or little, it means they are hiding something (for example, the project is centralized = works on one server). At least the architecture with a detailed description of how everything is arranged should be

• Lack of user documentation (instructions) increases the risk of low demand and low user retention, especially in complex products

• Information about fees and other prices - if not, there is a risk of unexpected charges.

• And in general, how detailed the project description is, is everything clear (at least with explanations of neural networks)

Not all projects have tokenomics, as there is no token and it is not planned yet / very early stage. But I consider this section critical, as weak tokenomics increases the risk of price drop.

In analytics:

1. Is there a tokenomics?

2. Is the distribution normal: maximum 10% to the team (extreme - 15%), maximum 10% to investors (extreme - 15%)

3. How much is allocated to the community at once and is there a ready product that can generate demand for the token / good market makers? If not - risk of weak price (even investors may not wait for a good fix on unlocks)

4. Are there no sharp spikes during unlocks (unlocks of 10% of all tokens a year after TGE = almost guaranteed price drop if there is no strong demand due to utility)
   Acceptable risk - < 0.9% of all tokens per month

5. Utility: are they spelled out and how good are they. Buybacks with a good product, paid features and other utilities can support the token.
   If not spelled out or, for example, only staking with DAO - risk of weak support.

6. Capital: is there public capital of the team / investments. They can support the price.

Also, I'm looking at investments:

• Amount

• And who invested. There are some funds where the absolute majority of projects have fallen by -90% and more. Don't you agree that this is strange?

• Is it open?

• Are there repositories of the main programs of the project? For example, blockchain nodes, smart contract processor...

• Is development active: are there periodic updates?

• Are audits published? How long ago? If there have been significant updates recently but audits are old - risk of new vulnerabilities or errors.
  If everything is fine, have all the issues described in the audits been resolved?

• The more "no" answers to these questions, the higher the risk of poor project quality. The code may be good, but it's hard to assess.

1. Does the functionality work at all?

2. How complete and clear is it? Sometimes there is some functionality in the documentation, but it is missing in the interface.

3. Does it match the description in the documentation (concept)? For example, are there no additional fees.

If there are "no" answers - risk of poor project quality.

This article describes the approach. In specific cases, the accents and risks may differ - that's why I always look at projects in context.