Methodology

How gmcrypto.xyz evaluates cryptocurrency projects. Engine v2.3 — last updated June 2026.

1. Overview

gmcrypto.xyz produces a composite risk score (0–100) for each tracked cryptocurrency project by aggregating data from multiple independent sources across six weighted dimensions. The score is computed entirely by deterministic code. No language model or AI system influences the numerical score.

The framework is modelled on CertiK Skynet's six-category approach, adapted for a retail audience with a stronger emphasis on tokenomics and fundamentals relative to pure security analysis.

Each dimension produces a sub-score from 0 to 100. The composite score is the weighted average of all six sub-scores, renormalised over the dimensions we could actually assess (see §3). Higher scores indicate lower assessed risk.

v2.3 changes (June 2026): the scorer now distinguishes "data verified bad" from "data never fetched" — absent inputs contribute zero points and surface under Not Assessed on the page, never as red flags (the v2.2 unknown-aware change). Stablecoins are scored under a dedicated profile (§5) rather than as a degenerate case of the L1/DeFi-protocol scorer. Each risk_scores row carries a score_profile field so the page knows which dimension labels to render.

2. The Six Dimensions

Security and Tokenomics carry the highest combined weight (45%) because these dimensions can cause total loss of capital. A project with a perfect score in every other dimension but a critical security vulnerability or predatory token distribution still represents high risk. The weights are not dynamically adjusted.

3. Unknown-Aware Scoring (Coverage & Confidence)

Every signal in every dimension carries one of three severities:

positive— verified-good fact (e.g. "Audited by Trail of Bits", "Public source code repository available"). Adds points.

negative— verified-bad fact (e.g. "2 critical findings in audit", "FDV/MC ratio 12x — extreme dilution"). Deducts points. Surfaces under All Flags and in the risk matrix.

unknown — the source was never fetched, the row is empty, or the field is null. Contributes zero points. Surfaces under Not Assessed on the page, never in the red-flags list or the risk matrix.

This is the core integrity guarantee: the scorer never conflates "data we couldn't fetch" with "the data was bad". A project that scores low must do so because verifiable facts went against it, not because a fetcher failed.

Coverage

coverageis the fraction of total dimension weight (1.0) that we could actually assess. If Security, Tokenomics, Fundamentals, Team, Community, and Market all return real signals, coverage is 100%. If Team is unassessed (e.g. no manual roster and no GitHub data), Team's weight (0.15) drops out and coverage becomes 85%.

The composite is the weighted average over assessed dimensions only — a renormalisation, not a penalty: an unassessed dimension does not artificially drag the score down. The page shows the coverage % under the score so a thinly-covered project cannot be misread as a confident high grade.

When coverage < 40%, the scorer refuses to assert a composite. The grade returns INSUFFICIENT_DATAand the page renders "Insufficient data to score". Refusing to score is more honest than averaging too few signals into a confident-looking number.

Confidence

Within each assessed dimension, signalCoverage tracks how many of the expected signal slots actually fired. A Security dimension with an audit row but no contract verification data fires 3 of 4 expected slots, so signalCoverage = 0.75. The dimension-level coverage is the weighted mean across assessed dimensions, and the page shows it as confidence.

Coverage tells you which dimensions were assessed at all; confidence tells you how deeply each assessment got. Both are persisted on every risk_scores row alongside the composite.

Methodology hash

Every row also carries a methodology_hash— a stable 16-character SHA-256 over the scorer version, weights, grade boundaries, and coverage threshold. If the hash changes between two rows, you know the scoring math changed; if it's the same, any score delta is from data drift, not engine drift.

4. Scoring Logic — Standard Profile

The standard profile applies to L1s, L2s, DeFi protocols, infrastructure tokens, memecoins, gaming, RWA, and AI categories. Stablecoins use a separate profile (§5).

Each dimension starts from a baseline and accumulates points based on positive signals, with deductions for verified-bad ones. The final dimension score is clamped between 0 and 100.

Security (25%)

Baseline 50. Positives: audit from a recognised firm (+30), audit less than 12 months old (+10), no critical or high findings (+20), open-source code on GitHub (+15), active development (≥10 commits in 30d, +10), contract verification on-chain (+15). Deductions: critical findings (−20 each), high-severity findings (−10 each), honeypot flag (−50), hidden mint (−30), hidden owner (−20), contract NOT verified on-chain (−15).

What v2.2 removed: the prior −40 penalty for "no audit on file" was an absence penalty — it fired on every project we hadn't curated yet. v2.2 replaces it with an unknownsignal (no points, no flag). A genuinely unaudited project now scores lower than an audited one (because it lacks the +30 firm bonus and +20 clean bonus) but no longer suffers a punishment that conflates "we don't have data" with "the data is bad".

Tokenomics (20%)

Points for: team plus insider allocation below 30% (+25), vesting period over 24 months (+20), cliff period exists (+10), FDV-to-market-cap ratio below 3× (+15), circulating-to-total supply above 50% (+15), no hidden minting function (+15). Deductions: team allocation above 40% (−30), no vesting (−25), FDV/MC above 10× (−20), upcoming cliff unlock within 30 days (−15).

Fundamentals (20%)

Fundamentals scoring is category-aware. Measuring Bitcoin by TVL is like measuring a bank by its Instagram followers. Each project type is evaluated by the metrics that actually apply to it.

TVL and protocol revenue are only penalised for projects where they are expected (DeFi protocols). Infrastructure tokens, platform chains, and store-of-value assets receive bonus points when these metrics are present but are never deducted for their absence.

Team (15%)

Team scoring uses two profiles based on project category. Stablecoins use a separate scorer (§5).

Named team(default for L1, L2, DeFi, etc.): baseline 50. Positives: verified members (+30), LinkedIn presence (+10), prior successful projects (+20), tier-1 VC backing identified in the roster (+5). Deductions: unverified members (−10), scam/failed history in any member's background (−50). When no manual roster exists, GitHub contributor data serves as a proxy (contributors_90d ≥ 10 → +20, ≥ 5 → +15, ≥ 2 → +8; sustained 90d commits ≥ 100 → +10; total stars ≥ 5,000 → +10).

What v2.2 removed:the prior −40 penalty for "no known team members" was an absence penalty — it fired on every project without a curated team roster, conflating "we haven't curated this" with "the team is anonymous". v2.2 replaces it with an unknownsignal. Projects with no curated roster now score from the GitHub backfill alone; if that's also missing, the dimension is marked unassessed and drops out of the composite.

Community-led (Bitcoin, Dogecoin, and memecoins with pseudonymous origins): scored on contributor breadth (GitHub contributors 90d: +25–30), community trust (GitHub stars: +15–20), and network maturity (market cap: +15–25). No penalty for pseudonymous founder or absent LinkedIn profiles — this is a defining characteristic of community-governed networks, not a red flag.

Community (10%)

Points for: more than 10 active GitHub contributors in the past 90 days (+25), commits in the last 30 days (+20), real social engagement ratio above 2% (+20), technical community discussions present (+15), developer ecosystem (+20). Deductions: no GitHub activity for 90+ days (−30), bot-heavy social presence (−20), no developer community (−15).

Market (10%)

Points for: listed on 3+ reputable exchanges (+25), 30-day volatility within 2× of BTC volatility (+20), liquidity depth above $500K (+20), top-10 holder concentration below 40% (+20), market cap above $50M (+15). Deductions: single exchange listing (−20), top-10 holders above 60% (−25), micro-cap below $5M (−15).

5. Scoring Logic — Stablecoin Profile

Scoring a stablecoin on the L1/DeFi-protocol dimensions is a category error: FDV/MC, TVL, and named-team-with-LinkedIn don't describe what makes a stablecoin safe. A stablecoin's risk surface is about backing, peg integrity,issuer trust, and regulatory standing — not the metrics that matter for a smart-contract protocol.

v2.3 routes projects with category='stablecoin' through a dedicated scorer. The same six dim_* columns are reused, but the meaning is different. The page reads score_profile='stablecoin' from the row and renders matching labels.

The stablecoin scorer reads from a curated profile file (lib/analyst/data/stablecoin-profiles.ts) keyed on the project slug. Each profile contains: peg mechanism, collateral ratio, reserves breakdown, issuer name and type, attestation cadence and firm, regulatory standing, jurisdictions, smart-contract flags, and a list of historical incidents. Every field is set to null when not verifiable from public disclosures — the unknown-aware machinery from §3 handles missing fields identically across both profiles.

Why this matters in practice: USDC scores higher than USDT under v2.3 (rather than both arriving at the same pass-through value as in v2.2 and earlier) because USDC has monthly Big-4 attestations, full MiCA compliance, and no historical incidents — exactly the differentiation the product needs to communicate. Decentralised stablecoins (DAI, GHO, crvUSD, LUSD) are not penalised for lacking centralised attestations; on-chain transparent reserves score equivalently.

6. Grade Scale

The composite score maps to a letter grade for quick reference:

7. Risk Matrix

Each project page includes a 3×3 risk matrix mapping individual risk factors to a likelihood-by-impact grid. The axes are defined as follows:

Likelihood (horizontal): derived from the dimension score and its trend direction. A score above 70 and stable or improving maps to Low. A score between 40 and 70, or declining, maps to Medium. Below 40 or rapidly declining maps to High.

Impact(vertical): based on the dimension's weight and the nature of the risk. Security and Tokenomics are High impact (can cause total loss). Fundamentals and Team are Medium impact. Community and Market are Low impact.

The matrix is populated with specific risk statements drawn from the data. It is a visual summary, not a separate calculation. The underlying scores and data are always accessible through the dimension breakdown panel.

8. AI Briefing

Each project page includes a 200–400 word AI-generated analysis. This briefing is produced by Anthropic's Claude language model (Sonnet class). The briefing is generated from structured data only. The model does not browse the web, fetch live data, or access information outside of what our pipeline has already collected and verified.

What the AI briefing does

Summarises the project's risk profile in plain English. Highlights specific red flags from the structured data. Presents bull and bear cases with three factors each. Lists data gaps where information could not be verified. Includes a fixed disclaimer on every output.

What the AI briefing does not do

It does not influence the numerical risk score (the score is computed by deterministic code before the briefing is generated). It does not recommend buying or selling any asset. It does not fabricate data. It does not access real-time market information beyond what is in the structured payload. If information is missing, the model is instructed to say so explicitly.

Briefing refresh policy

Briefings are cached for 24 hours. A new briefing is generated automatically if the composite risk score changes by 5 or more points, or if the previous briefing is older than 24 hours. Users can manually trigger a refresh from the project page.

9. Data Sources and Update Frequencies

All automated data is timestamped in the database. The project page displays the last-updated time for each data type. If data is older than its expected refresh interval plus a 2-hour buffer, a staleness warning is shown.

10. Limitations

Composite scores collapse nuance. A single number cannot capture the full risk profile of a project. Two projects with the same composite score can have very different risk profiles. Always examine the sub-scores and the risk matrix, not just the headline number.

Data freshness varies. CoinGecko price data is refreshed daily in the current phase. DefiLlama TVL updates roughly hourly at source but is fetched daily by our pipeline. Etherscan data is near-real-time at source but fetched daily. There can be a lag of up to 26 hours between a real-world event and its reflection in the score.

Some dimensions rely on manual curation. Team verification, audit status, and tokenomics allocation data are partially curated by hand. These may be incomplete, outdated, or incorrect. We update them as we discover new information.

The scoring weights are calibrated, not proven. The dimension weights (25/20/20/15/10/10) are based on the CertiK Skynet framework adapted for a retail fundamentals product. They have not been backtested against a large dataset of historical rug-pull projects versus survivors. We plan to perform this calibration as the tracked project set grows.

GitHub activity is an imperfect proxy for development quality. Commit counts and contributor numbers can be inflated by trivial changes, bot activity, or documentation-only updates. We filter known bots but cannot catch all cases. Low GitHub activity does not necessarily mean a project is abandoned; some projects have stable codebases that require minimal changes.

AI-generated briefings can contain errors. Although the model operates only on structured data (not free-form web content), language models can misinterpret data, draw incorrect conclusions, or phrase things in misleading ways. The briefing is a starting point for your own research, not a substitute for it.

Coverage is limited. We currently track a small number of pre-indexed projects. On-demand analysis is available for any CoinGecko-listed project but with reduced depth (no manual team verification, limited GitHub mapping, no curated tokenomics).

11. Disclaimers

gmcrypto.xyz provides AI-generated analysis and risk scores for informational purposes only. Nothing on this site constitutes financial advice, investment advice, trading advice, or any other kind of professional advice.

The risk scores, AI briefings, and all other content are provided “as is” without warranty of any kind. We do not guarantee accuracy, completeness, timeliness, or reliability of any data or analysis.

Cryptocurrency investments carry significant risk, including the risk of total loss. Past performance is not indicative of future results. Always do your own research before making any investment decisions.

gmcrypto.xyz is not a registered investment advisor, broker-dealer, or rating agency in any jurisdiction. The scores and analysis should not be interpreted as credit ratings or investment ratings under any regulatory framework.

12. Report an Error

If you believe any data is incorrect, a risk score is miscalculated, or a project's information is outdated, please contact us. We take data accuracy seriously and will investigate all reports.

Email: hello@gmcrypto.xyz

We aim to respond to data error reports within 48 hours.