Blind Dev article

How I evaluate project investment risk

A central risk-framework article: idea, product, tokenomics, team, market, and personal limits.

Based on Blind Dev personal experience and source posts; verify current details before applying.

Not investment advice. This article describes methodology and risks.

Historical publication from 2026-01-19. English translation of the Russian original, with editorial caveats. Features, prices, model impressions and offers describe the source period, not a current verification. Not investment advice.

In crypto, it is easy to believe that the main task is finding the “right” project. In practice, it is more important not to miss a risk that later shows up as unlocks, a vulnerability, weak team communication or a lack of demand.

I am a blind web3 programmer, so I do not rely on visual cues or attractive charts. My approach is to divide a project into blocks and check where it could fail.

This is the checklist I use to decide whether a project deserves my time and money. It is not a coin-picking guide or a price forecast. It covers team, concept, coin, code and practice.

All of them matter:

• Team: observable professionalism and communication affect longevity and responses to your questions.
• Concept: how well the documentation, FAQ and website explain the project.
• Coin: tokenomics, funding and investor quality, including whether most of their projects have fallen by 90% or more.
• Code: openness, core repositories, development activity, audits and fixes.
• Practice: whether the functionality works and is complete.

Team

I start by asking in Discord whether the team has LinkedIn profiles or similar information, whether tokenomics exist for a future or current token, and whether the code is open. The answer is itself a communication test.

After studying the concept, I sometimes ask another question. In one project, this revealed a centralized backend that the documentation had not stated directly.

An evasive, missing or irrelevant response raises concerns about communication during deeper involvement, or about the project’s prospects and continuity.

I examine X activity, check for bots through Moni or TweetScout, and look at who follows the account. Major funds or projects following it are a positive signal in this framework, not proof of quality. I note how openly and accurately the team answers questions; sometimes they stay silent or answer something else.

I also look at LinkedIn, the blog, Telegram and other social channels. These are secondary, but an active community helps. Inactive accounts and unanswered questions suggest a risk of stalled work and weak feedback when it matters. Many bots may mean inflated metrics, although reward-based tasks can also account for them.

Concept

Usually this means documentation, a white paper where available, and an FAQ.

• Is there demand analysis? Without it, the team may not understand the market or may be building something nobody needs.
• Is there competitor analysis: strengths and weaknesses, or at least a list? It helps show that the founders follow the market.
• Is there technical information? Missing detail can hide important dependencies, such as a centralized service running on one server. At minimum, I want a detailed architecture explanation.
• Are there user instructions? Missing guidance raises the risk of weak demand and poor retention, especially for complex products.
• Are fees and other prices disclosed? Otherwise, unexpected charges become a risk.
• Overall, is the description detailed and understandable, even if I need AI to explain parts of it?

Coin

Some projects have no tokenomics because no token exists or is planned, or they are very early. I still consider this section critical: weak tokenomics increases the risk of price declines.

My original checklist asks:

• Is tokenomics published?
• Is allocation reasonable? My historical preference was no more than 10% for the team, with 15% as an outer limit, and the same limits for investors.
• How much is released to the community at once? Is there a finished product capable of generating token demand, or capable market makers? Otherwise, even investors may struggle to exit at reasonable prices when tokens unlock.
• Are unlocks abrupt? The original text described releasing 10% of all tokens a year after TGE as an almost guaranteed price decline without strong utility-driven demand. This is the author’s risk heuristic, not a deterministic market rule.
• My historical acceptable-risk threshold was less than 0.9% of all tokens unlocking per month. It is not a universal safe threshold.
• Is utility specified, and is it meaningful? Buybacks tied to a good product, paid features and other uses may support a token. Missing utility, or only staking and DAO governance, means weaker support in this framework.
• Is there publicly known team capital or investment? It may be used to support the price, but that is not a promise that it will be.

I also examine the amount invested and who invested. Some funds have a large majority of projects down 90% or more; I consider that a reason to investigate, rather than treating their name as an automatic endorsement.

Code

• Is it open?
• Are the repositories for the project’s core programs available, such as blockchain nodes or smart-contract-related components?
• Is development active, with periodic updates?
• Are audits published, and how old are they? Major recent changes after an old audit introduce the possibility of new bugs or vulnerabilities.
• Have all problems described in the audits been resolved?

The more “no” answers, the higher the quality risk in my assessment. The code may still be good, but it is difficult to evaluate.

Practice

• Does the functionality work at all?
• Is it complete and understandable? Sometimes features appear in documentation but not in the interface.
• Does it match the documentation, including fees?

“No” answers are warning signs about product quality.

Conclusion

This framework does not guarantee that a project will succeed. It helps filter out projects whose foundations already contain substantial risks.

In short, I ask five questions:

1. Does the team’s communication and transparency justify trust?
2. Does the team understand the market and competitors, and disclose important design details?
3. Can the token avoid persistent price pressure from unlocks and weak utility?
4. Is the code transparent, audited, and updated to address findings?
5. Does reality match the description: a working product without hidden fees or limitations?

The weight of these factors varies by case. Context matters. But the more “no” answers I find, the less sense it makes to argue with the market and hope that this time things will work out.

Source

Original Russian publication. Channel footer and original visual formatting are omitted.