Will this crypto project
survive?

Every tab 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 (the newest cohort is the one exception: every project in it is still alive, so all of them score 100%). This is what Search, Screener, Compare, and the Score tab all show.

In the Manual Score Calculator (Score tab), the composite score is computed from the five metrics you enter and the founding year, using the same bands and cohort tables as the database. Below the score it also shows the raw cohort-wide survival rate for that year, for context only: the share of all projects that made their first GitHub commit in the same year and were still active at the data collection date (May 2026). Every project born in the same year shares that rate, so it is not the score itself. For example, if 45% of projects that first committed in 2021 are still active, that 45% is displayed as context for any 2021 project, while its composite score depends on the metrics you entered.

Both are historical baselines, not predictions. They tell you how similar projects have fared over time, not whether this specific project will survive.

A project is considered active if it had at least one GitHub commit within approximately 365 days of the data collection date (May 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.

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.

A project counts as active if it made at least one GitHub commit within about 365 days of the data collection date (May 2026). Every project founded in 2026 made its first commit less than a year before collection, so all of them are, by construction, still active. Every survival rate for that cohort is therefore 100%: the cohort-wide rate, each of the five dimension scores, and so the composite score too. This applies in every tab: the Score tab, Search, Screener, and Compare all show 100% for any 2026 project, and no ranking is possible inside that cohort because every project ties. It's a data artifact, not a real signal of quality or durability.

Treat any 2026 score with caution: the number reflects dataset recency, not project strength. To compare 2026 projects with each other, use their raw metrics (contributors, commits, stars, forks, open issues) rather than the score. In Screener, all 2026 projects tie at 100%, so they sit at the top of any score sort and pass any minimum-score filter; use the first-commit year filter to exclude them.

The same mechanism partly affects the previous cohort: any project of 2025 whose first commit fell within 365 days of collection is active by construction, so its rate is slightly overstated. Older cohorts are not affected.

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.

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 (7% of the dataset) fall into this category.

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 Compute Composite Score to get the project's composite score.

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.

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.

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.

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.

Projects founded after the data collection date (May 2026) are not in the dataset yet: the Score tab reports such a year as not in our dataset until the data is refreshed.

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.

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, use the Compare with another project button under the score result. It fills the first empty slot in the Compare tab with your manual score (shown as "Manual score (year)"); then search for a second project to compare against. Its composite score is the same value shown in the Score tab.

Screener 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, Screener also surfaces market cap, TVL, TVL/market-cap ratio, market-cap/revenue ratio, 24h volume, and five years of protocol revenue from CoinMarketCap and DeFi Llama, and lets you filter or sort on any combination of these. The Search tab shows market cap, TVL, and current revenue for the selected project.

Yes. Set the Market Cap filter to a bucket other than "All caps," or set a TVL, Market cap / Revenue, Volume, Revenue streak, or Revenue growth streak filter, and rows without that data will drop out of the results. Market cap, TVL, revenue, 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. When CoinGecko has no market cap for a project, the DeFi Llama figure is used instead and flagged with a † symbol. Results can be sorted on any filterable field and exported to XLSX with the Download button below the table.

Each row links to the pages the data comes from: the Llama ID column opens the project's DeFi Llama page (protocol page, or chain page for L1/L2 rows; for a protocol with several versions, the parent page, whose TVL and revenue are the combined total) and the CoinGecko column opens its CoinGecko coin page. Both URLs are also included in the XLSX exports.

The CoinGecko id is matched automatically from the project name or token symbol. When it was inferred from the symbol alone, hover the link to see a reminder to check that it is the right coin, since several tokens can share a symbol.

Each project is matched automatically to a DeFi Llama protocol (or chain), in this order: token symbol and name, exact name, GitHub organization, website domain, then the words of the name. A step is accepted only when it points to a single protocol; when several candidates remain, the next step is tried. A match on the words of the name is rejected when the token symbol or the CoinGecko id contradicts the protocol's (for example Uniswap Finance, UNFI, is not Uniswap, UNI). Projects still unmatched are tried again once CoinGecko has supplied their id, name and symbol, starting with the CoinGecko id. Versions of the same protocol (v2/v3, Lending/Savings...) count as one.

Combined figures. As on DeFi Llama, a protocol with several versions shows the total of all of them: TVL is the sum of the versions, and revenue is taken from the parent protocol or, when DeFi Llama has no series for it, added up across the versions. The Llama ID column then links to the parent page. Market cap is the token's, so it is not added up.

Protocols without TVL. Some protocols, such as oracles, have no TVL on DeFi Llama. They can still be matched through their CoinGecko id or exact name: TVL shows “—”, but revenue and market cap are available.

If a project shows no DeFi Llama data, it is either absent from DeFi Llama, or its name, organization or domain points to several unrelated protocols and the tool prefers to show nothing rather than guess. Rows added manually keep the version you picked for TVL and link.

The Trade-off tab ranks projects by the best compromise between valuation, growth, current revenue, consistency, size and quality, rather than by a single metric. Each row shows the global Trade-off score (0–100), the six block scores, MCap / Revenue, TVL / MCap, 24h volume and 12-month revenue. Click a row to open the project in the Search tab.

The same score is available as a sortable, filterable Trade-off column in the Screener and in the Screener's XLSX export.

Fifteen numeric criteria are grouped into six blocks: Valuation (MCap / Revenue, TVL / MCap), Growth (year-on-year revenue growth, annualized current-year (YTD) growth, growth streak), Current revenue (run-rate, 12-month revenue), Consistency (revenue streak), Size & liquidity (market cap, TVL, 24h volume / market cap) and Quality & maturity (GitHub score, first-commit year).

Each criterion is converted into a percentile score (0–100) among active projects that have both a market cap and revenue data, so outliers do not distort the scale. A lower MCap / Revenue is better; for most other criteria higher is better. A block score is the weighted average of its available criteria (missing values are skipped and the remaining weights re-normalized), and the global score is the weighted average of the six blocks. By default the blocks weigh 30% valuation, 25% growth, 15% current revenue, 5% consistency, 10% size & liquidity and 15% quality & maturity.

Each slider sets the relative weight of a criterion. The percentage next to each block shows its share of the total, and the weights do not need to add up to 100. Set a weight to 0 to ignore a criterion. The ↑/↓ button flips a criterion's direction (for example, set Market cap to “lower = better” if you prefer small caps). Set all to half puts every weight at the middle of the slider range (equal weighting), Reset defaults restores the original settings, and your settings are saved in this browser.

The TVL / MCap cap limits extreme ratios (e.g. 326x) so that a data anomaly does not dominate that criterion. Under Advanced, the growth malus and the minimum number of growth rates deduct points from the Growth block when a project has too few computable year-on-year rates.

Market caps, TVL and revenue are loaded in batches after the page opens. The ranking is recomputed live as data arrives, and scores carry a “~” until every source has finished loading. Once loading is complete the ranking is final and does not depend on the order in which the data arrived. The XLSX export is only available for the final ranking.

A project is scored only if it has both a market cap and revenue data (positive 12-month revenue). Other projects show “—” (or “…” while data is still loading). Inactive projects (no recent GitHub commit) can receive a score in the Screener but are not part of the Trade-off ranking nor of the reference group used for the percentiles. A criterion a project lacks (for example TVL or early-year revenue) is skipped rather than counted as zero.

Yes. The Download ranking as XLSX button exports the full ranking, not only the rows currently displayed: the six block scores, the value of each criterion, the 24h volume, and a second sheet listing the weights, directions and parameters used. The Screener's XLSX export also includes the Trade-off score and its block scores.

It lets you build a basket of cryptos and see a purely theoretical outcome: if each one caught up with a share of its category leader, how much would your capital be worth, and how should it be split to reach the multiple you target? Projects that are in the database also show their survival score.

Multiple = leader share × leader valuation ÷ the crypto’s current valuation, never below the minimum multiple (×1 by default). The leader share is 50 % unless you change it, globally or for one crypto. Valuation means the fully diluted valuation (FDV) by default, which accounts for tokens not yet in circulation; untick the option to use the market cap instead.

If a crypto already exceeds its target, its multiple falls to the minimum multiple; if it has no larger leader, it stays at ×1. You can also type a custom multiple on any crypto’s card to override the calculation.

The tool reads the CoinGecko categories the crypto belongs to and takes the top coin of each one. Candidates are ordered from the smallest category (the most specific) to the largest, up to 15, and the first one with a larger valuation is selected, i.e. the closest leader above you.

You can pick another leader in the card’s drop-down. If none is found, the card says why: either the crypto is already the leader of its categories (as Bitcoin is, with a dedicated message), or no larger leader exists among them, or CoinGecko has no category data for it. In every case you can enter a custom multiple. If detection failed because of the network, a Retry leader detection button appears. The Retry leader detection button next to Refresh prices re-runs detection only for the cryptos that have no leader yet, one after another (their number is shown on the button); the others keep their leader, including those you picked by hand. Their cards switch to a queued state right away, and the button shows progress.

Two profiles are blended. The safety profile favours large projects with a good survival score; the growth profile favours the highest multiples. In automatic mode, the tool finds the smallest tilt toward growth that reaches your goal. If your goal is out of reach, it shows the most ambitious allocation and the best multiple possible, and suggests adding cryptos that are smaller than their leader.

No single position can exceed the maximum per position (by default the larger of 40 % and 1/n). The Weighted survival score indicator averages the survival score of the positions that have one, weighted by their share of the allocation.

Main settings: currency, leader share, FDV or market cap, safety weighting by survival score, capital and goal.

Advanced parameters: maximum per position, minimum multiple (below ×1 to model a decline), survival-score influence from 0 to 100 %, and the growth/safety mix (automatic from the goal, or manual).

Per crypto: the reference leader, its own leader share and a custom multiple. Reset parameters restores the defaults and keeps your cryptos.

CoinGecko’s free API limits the number of calls per minute. The tool spaces its calls about 2.5 seconds apart and retries automatically if the limit is hit. The status line under the search box shows what is happening (loading prices, detecting a leader, waiting) with a countdown and the number of requests queued.

Refresh prices reloads every price in one go and is disabled for 30 seconds afterwards to protect the limit; Retry leader detection shares this pause: clicking one puts the other on hold too. The countdown is shown on the button, and while detection runs the button shows its progress and the estimated time left. In the other tabs, every CoinGecko wait appears in a small banner at the bottom of the screen with its countdown. If a refresh fails, the previous prices stay on screen with the time they date from. Categories are loaded once and kept for 24 hours.

Your cryptos and settings are saved in your browser only, on this device, so they are still there next time. Clear all removes the cryptos. Export Excel downloads the current allocation table: name, symbol, share, amount, multiple, projected value and survival score.

These labels are thresholds applied to the project's composite score, the same value shown in the Search gauge and in the Score tab:

• 🟢 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 (shown for context in the Score tab) would suggest on its own. A THRIVING label reflects this project's specific GitHub footprint, not a guarantee that it will keep growing. The exception is the newest cohort (2026), where every project scores 100% and is therefore labeled THRIVING because none has had time to go inactive.

The composite score describes how projects with a similar GitHub footprint (same founding year, similar activity bands) have fared historically. It doesn't check whether a project is still committing today. Four of the five inputs (total commits, contributors, stars, forks) are cumulative counts, so a project that built up a large footprint before going quiet can still land in high-survival bands.

In general, though, a dead project scores lower: it typically sits in low-survival bands on its own dimensions (commits, contributors, stars, forks, issues) rather than benefiting from its cohort's overall track record. This holds in the Score tab, Search, Screener, and Compare alike.

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 May 2026.

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.

The current dataset was collected in May 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.

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.