| GitHub Repo | URL | Token / Coin | Market cap | TVL | Llama ID | TVL / MCap | Vol 24h | Score | Status | Founded |
|---|
This section documents the design principles and statistical foundations of the survival model. It is intended for readers who want to understand how scores are constructed, not how to interpret them (see the FAQ for that).
The model is built on a deduplicated dataset of crypto and Web3 projects collected via the GitHub API as of early 2026. Survival probability is estimated through a cohort-based framework: rather than assigning arbitrary scores, the model measures the observed survival rate of comparable projects across time, activity levels, and market cycle conditions. All signals are derived exclusively from publicly available repository data.
A project's age exposes it to more failure opportunities. In crypto, survival is also shaped by external market regimes: bull markets inflate survival conditions, bear markets stress-test them. Bitcoin halving cycles create an additional ~4-year rhythm of liquidity expansion and contraction. Because cohort year determines which macro conditions a project was born into, these regime effects are captured implicitly through the cohort framework.
The cohort-wide survival rate is the observed survival rate of all projects that started in the same year, under comparable macro conditions. Every project sharing a founding year gets the same cohort rate by construction. This is the number shown by the Manual Score Calculator. It cannot rank projects against each other within a cohort; the Composite Score below covers the metric that does.
Each of the five GitHub dimensions (Contributors, Commits, Stars, Forks, Open Issues) is independently scored by placing the project into one of five equal-width activity bands derived from the full dataset distribution. Each band carries its own cohort-based survival probability.
When two projects are compared, the model evaluates each dimension individually. If the project with the higher overall score also leads on every individual dimension, the result is considered structurally consistent.
When a dimension inverts this relationship, meaning the project with the lower overall score outperforms on a specific factor, this is treated as a divergence signal. Such divergence does not invalidate the overall score. It indicates that the lower-ranked project holds a localized strength on that criterion, worth a closer look before drawing conclusions.
Because all projects sharing the same founding year receive the same cohort-wide survival rate by construction, that rate alone cannot discriminate between projects within a cohort. The model therefore also computes a composite score for each project: the arithmetic mean of its five available dimension probabilities (contributors, commits, stars, forks, open issues). Only projects with at least one available dimension score get a composite score.
This composite score is the headline score used across the rest of the tool: the gauge and badge in Search, the Score column in Explore, and the head-to-head comparison in Compare. The Cohort Benchmark panel also ranks on it, identifying the five projects within the founding-year cohort whose composite score sits immediately above the analyzed project and the five immediately below, plus a separate Similar group made up of the five projects with the smallest absolute difference in composite score. Projects with no dimension data are excluded from the benchmark.
Only the Manual Score Calculator still shows the raw cohort-wide rate instead. It's meant to reproduce that underlying cohort statistic directly, not to rank a hypothetical project against specific peers.
The Explore tab lists every project in the dataset as a filterable, sortable table. Each row's Score column is the same composite score described above, so projects can be ranked and filtered on a consistent, per-project basis across the full dataset instead of one cohort at a time.
Filters can be combined freely: composite score range, first-commit year, market cap bucket or exact range, TVL, TVL/market-cap ratio, and 24h volume. Market cap, TVL, and volume figures come from CoinMarketCap and DeFi Llama and refresh independently of the GitHub-derived scores, so a project can be missing commercial data ("No data") while still having a composite score, or the reverse. Results can be sorted on any filterable field and exported to XLSX.
The model describes historical patterns. It does not predict individual outcomes. A project can beat its cohort rate or fail despite a strong score. Scores are informational only and do not constitute financial advice.
Something doesn't look right? If you spot an inconsistency or want to understand the data better, reach out. We are happy to discuss. 💬 Contact
What does the score actually mean?
Most of the tool shows a composite score: the arithmetic mean of a project's five dimension probabilities (contributors, commits, stars, forks, open issues), each of which is itself a cohort-based survival probability for that dimension's activity band. It's specific to the individual project, not shared across its whole cohort. This is what Search, Explore, and Compare all show.
The Manual Score Calculator is the exception. It shows the raw cohort-wide survival rate: the share of all projects that made their first GitHub commit in the same year and are still active today. Every project born in the same year gets the same cohort rate there, by construction. For example, if 45% of projects that first committed in 2021 are still active, any 2021 project scored manually will show 45%.
Both are historical baselines, not predictions. They tell you how similar projects have fared over time, not whether this specific project will survive.
How is "alive" or "active" defined?
A project is considered active if it had at least one GitHub commit within approximately 365 days of the data collection date (early 2026). Projects with no recent commit activity are marked as inactive, regardless of whether their token is still trading or their website is still online.
What are the five GitHub dimensions and why were they chosen?
The five dimensions are: Contributors, Total Commits, Stars, Forks, and Open Issues. They were selected because they are publicly available via the GitHub API for nearly all repositories, making the dataset reproducible and comparable across thousands of projects.
Each metric is grouped into five equal-width activity bands based on the dataset distribution at time of collection (Band 1 = lowest activity, Band 5 = highest). Within each band, the survival rate of projects in the same founding-year cohort is computed and used as that dimension's contribution to the score.
Total Commits and Contributors are the strongest individual predictors of project longevity in the dataset. Stars and Forks are weaker signals — many active, serious projects have very low star counts.
Why do 2026 projects always score 100% in the Manual Score Calculator?
Projects founded in 2026 are too recent to have any survival history. None of them have had enough time to go inactive, so they all appear "alive" at data collection time. That gives a 100% cohort-wide survival rate, which is what the Manual Score Calculator shows for any 2026 project. It's a data artifact, not a real signal of quality or durability. Treat any 2026 cohort rate with caution: the number reflects dataset recency, not project strength.
Search, Explore, and Compare don't have this problem, since their composite score is built from each project's own dimension bands rather than the cohort's age. Two 2026 projects can and do get different composite scores depending on their actual GitHub activity.
How do I search for a project?
Use the Search tab and type the project's domain name (e.g. ethereum.org), its GitHub owner (e.g. aave), or its token symbol (e.g. UNI). You can also paste a full URL — the tool will extract the domain automatically. Results appear as you type; click or press Enter to select.
The dataset covers thousands of crypto and Web3 project domains. If a project does not appear in search results, it is not currently in the database.
My project is in the database but shows "No GitHub Data Available" — what does that mean?
This means the project's domain was identified as a crypto project, but no GitHub repository could be resolved for it at the time of data collection. This can happen because the project does not have a public GitHub repo, the repo was private, deleted, or the domain-to-GitHub link could not be determined automatically.
Without GitHub metrics, no survival score can be computed. Approximately 764 projects (16% of the dataset) fall into this category.
My project is not in the database at all. What can I do?
If the project is not indexed, you can still analyze it manually using the Score tab. You will need to gather five metrics from the project's GitHub repository:
1. Go to the project's GitHub repository.
2. Find the number of contributors (listed on the repository's main page under "Contributors").
3. Find the total commit count (click on the commit history link near the top of the file list).
4. Note the Stars and Forks counts shown at the top of the repository.
5. Count the Open Issues from the Issues tab.
6. Note the year of the first commit (the project's founding year).
Enter these values and the founding year into the Score tab and click Calculate Score to get an instant survival estimate.
What blockchains and ecosystems are covered?
The dataset spans projects across Ethereum (including EVM-compatible chains), Solana, Cosmos, Bitcoin, and several other ecosystems. The primary programming languages represented include TypeScript, Solidity, Rust, Go, Python, and C++.
Coverage is not exhaustive — the dataset was assembled from publicly available crypto project lists and may underrepresent newer or smaller ecosystems.
When should I use the Score tab instead of the Search tab?
Use the Score tab in any of these situations:
• The project is not in the database (not found in Search).
• The project appears in the database but has no GitHub data ("No GitHub Data Available").
• You want to run a hypothetical scenario — e.g., "what would the score be if this project had 50 contributors instead of 10?"
• You are evaluating a project that has not launched publicly yet but has a GitHub repository.
Where do I find a project's GitHub metrics if it's not in the database?
All five metrics are visible on any public GitHub repository page without needing an account:
• Stars & Forks: Top-right of the repository main page.
• Contributors: Right sidebar of the repository main page, under "Contributors". Click to see the full count.
• Open Issues: The "Issues" tab next to "Code" and "Pull requests" at the top. The badge shows the open count.
• Total Commits: Click the clock/commit icon near the top of the file list (e.g. "1,234 commits"). This shows the total count.
• Founding Year: Click into the commit history and scroll to the very oldest commit, or check the repository's creation date in the "About" section or via GitHub's API.
https://api.github.com/repos/OWNER/REPO returns created_at, stargazers_count, forks_count, and open_issues_count in one call. For commit count and contributors, use the /contributors and /commits endpoints.What founding year should I enter if the project has multiple repos?
Use the year of the earliest commit across all main repositories. For projects with a GitHub organization (e.g. github.com/ethereum), this is typically the year the core protocol or main product repository was created.
If you're unsure, use the year listed on the project's official website or whitepaper as a fallback. The founding year determines which cohort the project is compared against, so using the correct year matters for an accurate score.
What does the Compare tab show?
The Compare tab lets you place two projects side by side. It displays a radar chart showing how each project's five GitHub dimensions score relative to each other (as percentile scores within their bands), and shows each project's composite score for a direct comparison.
The comparison also highlights which project has the higher composite score and by how many points, along with founding year, language, and active status for each, plus a per-dimension breakdown that flags where a project's individual metrics diverge from its overall standing.
Can I compare a project from Search with one I scored manually?
The Compare tab currently supports searching and comparing projects that are in the database. If you have scored a project manually in the Score tab, you can use the Compare button that appears in the score result to pre-fill one slot in the Compare tab, then search for a second project to compare against.
What does the Explore tab show?
Explore is a filterable, sortable table of every project in the dataset. Its Score column is the same composite score shown in the Search tab's gauge (the arithmetic mean of a project's five dimension probabilities), so projects can be ranked and screened consistently across the whole dataset, not just within one founding-year cohort.
Alongside the GitHub-derived composite score, Explore also surfaces market cap, TVL, TVL/market-cap ratio, and 24h volume from CoinMarketCap and DeFi Llama, and lets you filter or sort on any combination of these.
Can I filter Explore to only show projects with commercial data?
Yes. Set the Market Cap filter to a bucket other than "All caps," or set a TVL or Volume range, and rows without that data will drop out of the results. Market cap, TVL, and volume come from CoinMarketCap and DeFi Llama on their own schedules, separate from the GitHub data collection, so a project can have a composite score with no market data, or market data with no GitHub score. Results can be sorted on any filterable field and exported to XLSX with the Download button below the table.
What do the THRIVING / STABLE / FRAGILE / HIGH RISK labels mean?
These labels are thresholds applied to the project's composite score, the same value shown in the Search gauge:
• 🟢 THRIVING — 75% or above. The project's own GitHub dimensions place it in high-survival activity bands.
• 🟡 STABLE — 50–74%. Most of its dimensions sit in above-average survival bands.
• 🟠 FRAGILE — 25–49%. Its dimensions are split between stronger and weaker survival bands, or clustered around the middle.
• 🔴 HIGH RISK — Below 25%. Most of its dimensions sit in low-survival activity bands.
Because the composite score is built from the project's own activity levels rather than only its birth year, this label can differ from what the same project's raw cohort-wide rate (only shown in the Manual Score Calculator) would suggest on its own. A THRIVING label reflects this project's specific GitHub footprint, not a guarantee that it will keep growing.
A project I know is dead scores very high in the Manual Score Calculator — why?
This is expected there. The Manual Score Calculator shows the cohort-wide survival rate, which says nothing about the individual project's current status. A project founded in 2010 will naturally score very high because most crypto projects from 2010 that made it to GitHub are still around; there were very few of them, and they tend to be well-established (Bitcoin, Litecoin, and so on).
In Search, Explore, and Compare, the same dead project will generally score much lower. Their composite score is built from its own current dimension bands (commits, contributors, stars, forks, issues) rather than its cohort's overall track record, and a project with no recent activity typically falls into low-survival bands on those dimensions.
Additionally, a project in our database could have been marked as "active" at the time of data collection even if it has since gone dormant. Data is from early 2026.
Is this tool financial advice?
No. This tool is strictly informational. Survival scores are based on historical GitHub activity patterns and do not account for tokenomics, team quality, funding, regulatory environment, market conditions, or any other factor relevant to investment decisions.
How often is the data updated?
The current dataset was collected in early 2026. The "alive" status reflects GitHub activity as of that collection date. Updates are planned periodically, but this is a beta product and update frequency may vary.
The data version is shown in the footer of this page.
How can I request a project to be added or report incorrect data?
Reach out to the CoinVentureLab team via the contact link in the Method tab, or directly at contact@coinventurelab.com. Include the project domain, its GitHub repository URL, and a brief description of the issue.