Network scorer methodology

The in-house scorer prices networks no third-party calculator covers (points programs, thin emissions, cash networks) into a comparable risk-adjusted USD/day, with every estimate explicitly flagged.

Why it exists

WhatToMine, NiceHash and Vast asks cover mature markets. The registry (src/scoring/registry.ts) covers everything else: pre-TGE points programs, freshly listed emissions plays, bandwidth networks. The point of the in-house registry is exactly that no third party computes an EV for these.

Tiers

The tier follows the token state (src/scoring/score.ts):

The three gross models

Gross revenue, before risk adjustment, comes from one of three models (src/scoring/types.ts):

1. cash_measured

gross = usdPerDay, a measured payout. No model, no discount. This is the anchor everything else is compared against.

2. emissions (liquidity-adjusted)

For listed tokens emitting to node operators:

dailySellUsd = networkTokensPerDay * sellFraction * priceUsd
realizable   = 1 / (1 + 4 * dailySellUsd / liquidityUsd)
gross        = tokensPerDayPerUnit * priceUsd * realizable

The realizable fraction (src/scoring/liquidity.ts) answers: how much of the spot price is actually capturable when the whole network's daily sell pressure hits the available DEX depth. Ratio 0 gives 1.0, ratio 0.05 gives ~0.83, ratio 0.5 gives ~0.33. Below 50% realizable the entry is flagged "liquidite trop fine pour la pression vendeuse".

Pricing path, in order of preference:

1. Contract address + chain via DexScreener token-pairs/v1/{chainId}/{tokenAddress}, filtered on baseToken.address, deepest pair wins. Address pricing is mandatory policy after the XTM incident: symbol search for "XTM" returned Xtime on MultiversX at $0.80 while real Tari XTM traded at ~$0.0005, a 1600x mispricing. A fake Solana "BLESS" pool showing $679M liquidity is the same trap.
2. Address without chain via the legacy latest/dex/tokens/{address} endpoint.
3. Symbol search, collision-prone, kept only for tokens whose address is not yet known; flagged in the output ("prix par symbole: collision possible, ajouter l'adresse").
4. Manual CEX price (cexPriceUsd) when no DEX pair exists at all (example: Tari XTM, CEX-only as of 2026-07-25). The entry records the spot price, source, and lastVerified date, which is echoed in the flags so staleness stays visible. 24h CEX volume, when known, serves as a crude depth proxy for the realizable fraction; without it, a default 30% realizable is assumed. Tier is capped at C.
5. Nothing found: flag "prix DEX introuvable", tier forced to D, gross 0.

3. points_ev (pre-TGE, calibrated on comparables)

For unlisted points programs:

gross = (comparableUsdAtTge * pTge * earlyMultiplier) / expectedFarmDays

• comparableUsdAtTge: per-node payout of comparable networks at TGE. The registry calibrates on measured history: Grass S1 ~108 tokens/user average, Grass S2 ~$6 for a heavy farmer (July 2026), Nodepay -99% post-TGE as the bear comparable, Teneo S0 = 2000 USDC across all users.
• pTge: probability a TGE or claim actually happens and pays.
• expectedFarmDays: farming duration to earn that payout.
• earlyMultiplier: above 1 when joining early in a program, below 1 when entering late behind millions of installs.

Each points_ev result is flagged with its parameters, e.g. EV model (p=0.7, comp=$80).

Risk multipliers

The gross is then multiplied by:

riskMult = (1 - banToS) * (1 - death) * (1 - vestingHaircut * 0.5) * (kyc ? 0.9 : 1)
riskAdjUsdDay = gross * riskMult

• banToS: probability of a ban or zeroed allocation for automated farming. At 0.3 and above the entry is flagged "ban ToS eleve", which the planner turns into an explicit 1 device/1 IP warning.
• death: probability the network dies before paying.
• vestingHaircut: value lost to locks and vesting, counted at half weight.
• kyc: a flat 10% haircut plus a "KYC" flag.

scoreAll scores the whole registry concurrently and sorts by riskAdjUsdDay descending.

Contention and opportunity cost

Every entry declares what scarce resource it contends for: gpu, cpu, ip_slot, or none. This is what makes scores comparable to the oracle:

• a GPU-contending network (Inference.net node, Nosana host, WOMBO w.ai) must beat the cash baseline of renting or inferring on the same GPU before it deserves the primary slot; the planner enforces exactly that comparison;
• ip_slot networks compete only for the limited residential IP slots (ipSlots in config);
• none networks (browser extensions, negligible compute) stack for free.

The score CLI takes --gpu-baseline to make the opportunity-cost comparison explicit against a known cash number (e.g. 2.9 $/day for a rented 4090).

Registry and review queue

The registry is a hand-maintained TypeScript list of NetworkEntry records: identity, kind (pow, depin_points, inference, bandwidth), token state, contention, needs, pricing reference, gross model, risks, and notes. It is versioned and reviewed like code.

New candidates flow in from the watcher: every NEW_COIN detection appends a ReviewQueueEntry to data/review-queue.jsonl with status to_review and a pre-filled NetworkEntry skeleton (kind pow, token state defaulted to listed_thin pending a DEX liquidity check). Nothing enters the scored registry without a human pass over that draft.

Honest-numbers policy

Every number that is not a measured payout is a seed, and the code says so: registry comments mark each figure as an estimate with the intended refinement path (log actual epoch payouts on a reference node, read on-chain distribution flows, run a host for a week). Score outputs carry flags exposing the pricing path, the realizable percentage, EV parameters, and manual-price verification dates. Tier A is reserved for measured cash; everything else is explicitly modeled, discounted, and labeled. If a number looks precise in the output, the flags tell you exactly how much to trust it.