Skip to main content
Pharos
PHAROS

Methodology

How Pharos grades stablecoins: transparent scoring across safety, peg stability, liquidity, yield, and contagion risk. Treat this page like a reference manual, not a marketing explainer.

Reader Guide

Reader mode keeps summaries up front. Switch to Analyst for formulas, caveats, and worked examples.

View

Page rhythm: summary, quick facts, worked example, technical notes.

Pricing Pipeline

Pricing Pipeline Methodology

v4.1Version history →

Version increments when price sources, consensus algorithm, enrichment passes, or validation rules change.

Every score Pharos computes starts with a price. The pricing pipeline collects quotes from more than a dozen live voices, requires fully pairwise agreement inside each cluster, and publishes the highest-confidence result with explicit source-freshness semantics.

Source diversity. Kraken and Bitstamp extend the direct venue set. Fresh RedStone prices need timestamped multi-venue breakdowns. The protocol-level DEX bridge now spans Fluid, Balancer, Raydium, Orca, Meteora, PancakeSwap, Aerodrome Slipstream, and Velodrome Slipstream. DEX bridge identity is canonical-only at runtime, so addressed unknown tokens are dropped instead of being reinterpreted by symbol, promoted protocol DEX prices only enter consensus when they are corroborated or no non-DEX voices exist, and direct-API quote legs prefer tracked live stablecoin prices instead of unconditional $1 symbol assumptions.

Pool challenge. A pool challenge guard downgrades confidence and replaces the price with a protocol-aware TVL-weighted median only when large DEX pools from at least two independent protocols diverge from soft consensus, with divergence evaluated from one TVL-weighted median per protocol so a single rogue pool cannot make an otherwise agreeing protocol count as corroborating disagreement, including DEX-inclusive soft clusters unless an exempt hard source is present. Dead blocked DEX slugs such as Bunni are excluded upstream and never qualify as challenger or DEX-bridge inputs.

Overrides & FX. Protocol-level redemption prices override market data for wrapper assets. Chainlink refreshes supported FX and commodity reference rates, and the dated secondary FX mirror can temporarily carry the wider fiat reference stack when Frankfurter is unavailable, with ExchangeRate-API as a tertiary daily fallback if both primary FX paths are down. If those live FX fetches still fail but the last published daily references remain within cadence, Pharos carries those dated references forward as a healthy refresh. Even cached-fallback FX runs keep probing the independent OXR, Chainlink, and metals paths, so a recovered intraday subset can promote the lane back to live without waiting for the full Frankfurter stack.

Freshness tracking. The live payload distinguishes true upstream observation timestamps from locally stamped fetch-time freshness via priceObservedAtMode, so a hard single-source print only becomes depeg-authoritative when its freshness is source-native rather than inferred from local collection time. The source registry now also records each provider's freshness kind, maximum trusted age, and whether it truly supports upstream timestamps.

Native-peg corroboration. For supported non-USD fiat assets with a reliable native-market quote, the pipeline now derives a fresh native quote × FX reference USD mark during post-enrichment. That lane can correct materially divergent weak or mixed-source live USD publications, fill a missing live price for supported assets, and still veto or resolve downstream depeg mutations when the direct native pair disagrees with a derived USD price / FX reference move. It remains a fresh validation lane rather than a replay-safe primary consensus voice, so it does not become cached continuity on later runs.

Historical replay parity. Supported non-USD fiat backfills now prefer direct CoinGecko native-fiat history and compare that series to the native 1.0 peg before falling back to USD-denominated market history. That removes long synthetic depeg streaks created only by replay-time USD / FX mismatch.

Enrichment & confidence. A 5-pass enrichment pipeline fills gaps for long-tail coins. Each asset is tagged with a confidence level so downstream systems can react to data quality, and severe fixed-peg downside publication now requires corroboration unless it comes from an explicit protocol redemption or pool-challenge replacement mark. When a confirmed severe depeg briefly loses corroboration, the pipeline preserves trusted continuity from fresh replay-safe price_cache rows instead of letting the asset flap to N/A. DefiLlama contract fallbacks must now pass the same peg-aware plausibility gates before they can resolve an asset, and DexScreener symbol search is reserved for addressless assets rather than downgrading exact-token candidates to symbol-only identity.

Update cadence

15m refresh

Sources

14+ live voices

Output

Price + confidence tag per asset

Preconditions & Failure Modes

Minimum data

At least 1 source must return a price; consensus requires 2+ for high confidence

Circuit breakers

Each source has its own breaker: opens after 3 failures, probes every 30 min

Failure behavior

Degraded sources are excluded from consensus; enrichment pipeline fills remaining gaps; stale cache used as last resort

Worked example: USDC price consensus across 7 sources

Sources: CoinGecko=1.0001 (w2), DL-list=0.9999 (w1), Pyth=1.0002 (w2), Binance=1.0001 (w2), Kraken=1.0000 (w2), Coinbase=0.9998 (w2), Curve=1.0003 (w3)

Peg ref=1.0, threshold=50 bps. All 7 within 50 bps of each other → single cluster of 7.

Published price = cluster median = 1.0001. Internal selected source for provenance = Curve (highest-weight member).

Result: price 1.0001, confidence “high”, source label from the full agreeing cluster.

Technical details: source weights, consensus algorithm, overrides, enrichment, and validation

Aggregators

CG (w2), DL-list (w1)

Exchanges

BN (w2), KR (w2), CB (w2), BS (w1)

Oracles

Pyth (w2), RS (w1)

On-chain

Curve (w3), DEX agg (w1), protocol DEX (w2-w3), GT (w1)

N-Source Consensus

Pairwise clusters; publish cluster median, keep best member for provenance

Pool Challenge

Soft-only → replace with protocol-aware weighted medians

Authoritative Overrides

Protocol redemption (cUSD, iUSD) after market probes

Enrichment Pipeline

5-pass fallback with Jupiter before DexScreener

Price Validation + Confidence

high / single-source / low / fallback

Source Weights

SourceWeightTypeNotes
CoinGecko2AggregatorPrimary market data via /simple/price
CoinGecko ticker2Exchange tickerCurated ticker corroboration path for tracked exchange pairs
DefiLlama (list)1AggregatorIndependent stablecoins list price via stablecoins.llama.fi
Pyth Network2OracleHermes endpoint with confidence intervals
Binance2CEXSingle batch call for all spot tickers
Kraken2CEXExplicit pair mapping with alias-safe response handling
Bitstamp1CEXLower-weight corroboration via the all-tickers endpoint
Coinbase2CEXPer-symbol spot prices
RedStone1OraclePer-venue breakdown; requires at least 2 venues and 60% agreement
Curve on-chain3On-chainStableSwap implied prices via get_dy()
Curve oracle3On-chainAdditional primary-consensus voice for crvusd-curve
DEX pools1On-chainAggregate DEX voice, but withheld when overlapping protocol-level DEX bridge data exists
Protocol DEX APIs2-3On-chain / pool-state APIOne aggregated source per protocol from Fluid, Balancer, Raydium, Orca, Meteora, PancakeSwap, Aerodrome Slipstream, and Velodrome Slipstream; only promoted when corroborated or when no non-DEX voice exists
GeckoTerminal1On-chainPool-level cross-check for weak CG / DL-list soft-source outcomes (≥$10K TVL)

Consensus Algorithm

The consensus engine clusters all available source prices for an asset and picks the most reliable result:

  1. Collect all source prices with non-failed circuit breakers
  2. Find the largest fully pairwise cluster of sources that agree within 50 bps (fixed pegs) or 500 bps (NAV tokens)
  3. Break equal-size clusters by total weight, then tighter spread, then peg proximity when available
  4. If the winning cluster has 2+ members, publish its median price and separately keep the best cluster member for provenance
  5. Choose that internal selected source by weight, then trust tier, then peg proximity, then source key
  6. If no cluster of 2+ forms, fixed pegs stay on fixed-peg rules and fall back to the best trusted single source
  7. Pool challenge: if all agreeing sources are challenge-eligible (CG, DL-list, DEX average, or promoted protocol DEX sources without a hard-source corroborator), check each large priced DEX pool (≥$100K TVL) from the published challenger snapshot built from the full retained pool set. If any diverges ≥500 bps from the weak result, downgrade to low, and only replace the price when at least two independent protocol-level medians corroborate that divergence — on-chain liquidity is a more honest signal when aggregators share upstream data, but a single protocol or a single rogue pool can still be wrong
agree(a,b) = |a.price − b.price| / midpoint(a,b) × 10000 ≤ thresholdBps

Authoritative Price Overrides

For wrapper-style assets whose executable value is set by direct protocol redemption, or by an instantly redeemable tracked base asset, rather than by secondary-market liquidity, the pipeline switches to an authoritative redemption-based mark:

  • cUSD (Cap): getBurnAmount() — cUSD → USDC redemption rate
  • iUSD (infiniFi): receiptToAsset() — iUSD → USDC redemption rate
  • USDai: inherits tracked PYUSD pricing because base USDAI is treated as an instantly redeemable PYUSD wrapper
  • crvUSD (Curve): PriceAggregator.price() enters primary consensus as a live market voice, not a protocol override

These overrides set priceSource = "protocol-redeem" and priceConfidence = "high" when the quote validates against peg bounds, and they are applied after the GeckoTerminal probe so later market checks cannot overwrite them.

Enrichment Pipeline (5-pass fallback)

Assets still missing prices after primary consensus go through a staged enrichment pipeline:

  1. Pass 1: Canonical tracked contract identity → DefiLlama coins API, but only prices that pass peg-aware validation can resolve the asset
  2. Pass 1b: Tracked alternate deployment fallback only (no synthetic same-address cross-chain probing; same validation gate as pass 1)
  3. Pass 2: CoinMarketCap batch listings (slug first; symbol fallback only when the tracked symbol is unique, rate-limited to 1 call/hour)
  4. Pass 3: Jupiter Price API for tracked Solana mints (liquidity-gated)
  5. Pass 4: DexScreener exact token-address pools first; unique-symbol search is reserved for addressless assets and stays filtered by >$50K liquidity, capped at 10 actual requests per run while the pass walks the full prioritized missing set so skipped non-unique rows do not crowd out later valid candidates

Confidence Levels

LevelConditionDownstream effect
high≥2 sources agree within thresholdPublished as the agreeing cluster median; full trust for depeg detection and scoring
single-sourceOnly 1 source returned a priceDepeg detection requires pending confirmation
lowSources disagree beyond threshold, or pool challenge firedPool challenge: TVL-weighted pool price used; otherwise closest to peg reference; depeg requires confirmation
fallbackAll primary sources down; enrichment or cache usedDepeg mutations blocked; stale banner shown on frontend

Price Validation

Every price is validated before entering the replay cache. Validation is context-aware with four modes:

  • Authoritative primary: can admit deep downside for fixed pegs, but publication still requires corroboration unless the mark is protocol redemption or a pool-challenge replacement
  • Fallback enrichment: rejects isolated bad prints below a lower bound
  • DEX observation: requires consistent $50K post-confidence TVL floor
  • Historical backfill: validates against per-timestamp peg references

Commodity tokens (gold, silver) scale references by commodityOunces for gram- and 1/1000-ounce assets. NAV tokens use broad positive-price checks. Replay-safe cache storage is limited to strong, replayable prices and now expires after 6 hours.

Stability Index Methodology

v3.2Version history →

Version increments when PSI formula, caps, bands, component definitions, or other score-affecting input semantics change.

The Pharos Stability Index (PSI) is a market-level 0–100 health score for the stablecoin ecosystem. It is recomputed every 30 minutes from live depeg conditions and stress signals, then aggregated into daily history snapshots.

Update cadence

30m refresh

Score range

0-100 market health

Main use

Bands: BEDROCK to MELTDOWN

Preconditions & Failure Modes

Minimum data

Scorer accepts empty depeg sets, but the cron requires total market cap > 0 and an available active-depeg input query

Required sources

Market-cap totals + active depeg inputs (current stablecoins price, or recent replay-safe price_cache fallback for already-open depegs; DEWS breadth optional)

Failure behavior

Returns null when market-cap input is missing/<=0; the cron also skips publication when active-depeg inputs are unavailable, and the API serves the last valid value

Historical replay

Backfills score any depeg overlapping the UTC day, canonicalize legacy depeg IDs into the current PSI universe, use same-day supply_history prices when they capture the move, cap replayed daily deviation at the event peak, and keep peak event deviation as a start-day floor only when the depeg stayed open through the UTC close and the daily snapshot misses the move

Worked example (verified against computeStabilityIndex)

Inputs: bps=-120, depegMcap=$2B, totalMcap=$200B, age=10d, trend=+1.2, stressBreadth=1.5

severity=1.141, breadth=4.243, score=100-1.141-4.243-1.5+1.2=94.316→94.3

Result: PSI 94.3 (BEDROCK).

Technical details: formula, component math, depeg handling, and condition bands

Scoring Formula

Score = 100 − severity − breadth − stressBreadth + trend

The final value is clamped to [0, 100] and rounded to one decimal.

Severity

0–68

Breadth

0–17

Stress Breadth

0–5

Trend

−5 to +5

Compute PSI

100 − penalties + trend

Condition Band

BEDROCK through MELTDOWN

Components

ComponentRangeFormulaPurpose
Severity0–68min(68, Σ(abs(bps)/100 × share × log2(1+mcap/1B) × 60 × factor))Magnitude-weighted depeg damage with extra emphasis on mega-cap instability
Breadth0–17min(17, Σ(sqrt(mcap/1B) × 3 × factor))How widely depegs are spreading across unique coins
Stress Breadth0–5min(5, dewsStressBreadth)Early-warning pressure from DEWS stress signals before full depegs
Trend−5 to +5clamp(-5, 5, mcap7dChangePct)7-day stablecoin market-cap momentum (supports or offsets penalties)

Depeg Handling Rules

  • Per-coin deduplication: active events are grouped by coin; each coin contributes once using the worst current deviation.
  • Historical rebuild parity:completed-day backfills score any depeg overlapping the UTC day, canonicalize legacy depeg IDs into the current PSI universe, replay same-day deviation from `supply_history.price` when possible, never exceed the event's recorded `peak_deviation_bps`, and keep `peak_deviation_bps` as a start-day floor only when the event remained active through the UTC close and a daily snapshot misses the move. Replay days whose restored daily price is back inside the configured threshold drop out entirely, and restore jobs also repair replay-critical daily price coverage, including PSI-only shadow assets, before the PSI rebuild is rerun.
  • Age-aware depreciation: fresh depegs get full weight for 30 days, then decay linearly to a 25% floor over 120 days.
factor = ageDays ≤ 30 ? 1.0 : max(0.25, 1.0 − (ageDays − 30)/120)

Condition Bands

RangeBandMeaning
90–100BEDROCKNear-ideal market stability
75–89STEADYNormal conditions with minor stress
60–74TREMORMeaningful instability emerging
40–59FRACTUREBroad, significant market stress
20–39CRISISContagion-level instability
0–19MELTDOWNSystemic peg failure conditions

Safety Scores Grading Methodology

v6.95Version history →

Version increments when weights, thresholds, or dimension definitions change.

Pharos synthesizes multiple data signals into a single transparent grade per stablecoin. The overall score is computed in two steps: first, a weighted average of four base dimensions (exit liquidity, resilience, decentralization, dependency risk), then a peg stability multiplier that penalizes coins with poor pegs while barely affecting well-pegged ones. The exit-liquidity dimension blends raw DEX liquidity with redemption-backstop quality when a direct exit path exists. When some base dimensions lack data (NR), their weight is redistributed proportionally among rated ones.

Model shape

4 dimensions + peg multiplier

Grade output

A+ to F, with NR

Key caveat

No exit signal = 10% penalty

Preconditions & Failure Modes

Minimum data

At least 2 rated non-peg dimensions

Required sources

Peg summary, DEX liquidity/redemption data, and dependency/metadata inputs

Failure behavior

NR if peg is missing on non-NAV coins; pure NAV tokens stay neutral when peg tracking is genuinely not applicable, while configured NAV wrappers can inherit peg risk from a referenced base stablecoin; 0.9 penalty applies when exit liquidity is NR (no DEX data and no redemption backstop signal available)

Worked example (verified against computeOverallGrade)

Inputs: DEX 30, Redemption 88, Exit 56, Res 70, Decen 60, Dep 75, Peg 92

base=(56*0.30+70*0.20+60*0.15+75*0.25)/0.90=65.06

final=round(base*(92/100)^0.40)=round(65.06*0.9672)=63

Result: Score 63 (grade C+).

Interactive calculator: explore how weights and thresholds shape the grade

Interactive: Try your own inputs

Scores below use the same formula, weights, and thresholds as production. In practice each dimension is derived from on-chain data, not chosen directly — use this to explore how the grading math works, not to predict a specific coin's grade.

Computed grade:C58 / 100(base 58.9, peg multiplier applied)
Technical details: full pipeline, dimension formulas, thresholds, and caveats

Exit Liquidity

30%

Resilience

20%

Decentralization

15%

Dep. Risk

25%

↓

Weighted Average

base score

↓

× Peg Multiplier

(pegScore / 100)0.40

↓

× No-Liquidity Penalty

0.9× if no DEX or redemption signal

↓

Final Grade

A+ through F

Base Dimensions (weighted average)

DimensionWeightSourceDescription
Exit Liquidity30%DEX liquidity + redemption backstopBest-path model: exit quality = best available path (DEX or redemption) + diversification bonus for having both
Resilience20%Collateral, custody2-factor solvency measure; blacklist capability reported descriptively only
Decentralization15%Governance type, chain riskGovernance structure with chain-risk penalty
Dependency Risk25%Upstream grades, collateral weightsInherited risk from upstream stablecoins, weighted by exposure

Redemption Backstop and Effective Exit

The standalone Liquidity Score remains a pure DEX market-depth metric. Safety Scores use an effective exit score for the Liquidity dimension, built on a best-path model: exit quality equals the best available exit path, with a modest diversification bonus for having a second viable path.

effectiveExit = min(100, max(dex, redemption) + min(dex, redemption) × 0.10)

If only DEX liquidity exists, it is used directly. If only a redemption backstop exists, its score is used directly — route family caps (offchain-issuer ≤ 65, queue-redeem ≤ 70) and component scoring remain the guardrails against inflation.

Redemption backstops are scored across access, settlement, execution certainty, capacity, output-asset quality, and cost. Low-confidence redemption routes stay visible on the site but do not uplift the Safety Score liquidity dimension, stale DEX inputs are not used for effective exit, and stale live reserve metadata ages out instead of staying resolved indefinitely.

Peg Stability Multiplier

After computing the base score, peg stability is applied as a power-curve multiplier: final = base × (pegScore / 100)0.40. Coins with strong pegs (90+) are barely affected (~4% penalty), while coins with broken pegs are sharply penalized (e.g. pegScore 10 → 60% penalty). Pure NAV fund-share tokens with no configured peg reference keep pegScore = NR and receive multiplier 1.0, while configured NAV wrappers can inherit peg risk from a referenced base stablecoin. Severe active depegs are also hard-capped: ≥ 2500 bps (25%+) caps the overall score at F, ≥ 1000 bps (10%+) caps at D.

No-Liquidity-Data Penalty

A further 0.9× multiplier is applied when a coin has no exit-liquidity signal at all — neither DEX liquidity nor redemption-backstop coverage. Weights are redistributed across available dimensions; this 0.9× multiplier is then applied to the final score to correct for the missing liquidity data by applying a flat 10% penalty.

Resilience Scoring

Average of two equally-weighted sub-factors (50% each): Collateral Quality and Custody Model. Chain infrastructure is scored exclusively in the Decentralization dimension. Blacklist capability is reported descriptively but does not affect the Resilience score.

Sub-factorWhat it measuresScoring
Collateral QualityReserve composition riskWeighted avg of curated reserve slices: Very Low (100), Low (75), Medium (50), High (25), Very High (5). Falls back to enum scoring for coins without curated reserves.
Custody ModelWho holds the collateral?Fully on‑chain (100), Top‑tier custodian (80), Regulated custodian (55), Unregulated custodian (30), Sanctioned custodian (5), CEX / off‑exchange custody (0)

Collateral quality is derived from reserve compositions when available — curated metadata by default, or a fresh authoritative independent live reserve snapshot for coins covered by the live reserve sync. For report-card scoring, that live snapshot must also carry scoring-eligible freshness evidence: either a verified timestamp path or an explicit on-chain latest-state not-applicable freshness mode. Direct one-bucket on-chain reserve proofs such as Liquity v1 can qualify when the adapter is classified as independent, but weak probe families do not qualify just because they are on-chain. Detail-only static-validated and weak-live-probe feeds remain visible on reserve surfaces, but they never override curated collateral scoring. Each reserve slice is classified into one of five risk tiers and the score is their weighted average. Direct ETH and canonical WETH slices share the same Very Low tier, while ETH liquid staking tokens remain Low. For coins without usable reserve compositions, a coarser enum-based fallback is used. Explicit overrides exist for coins where defaults are incorrect (e.g., protocols on Solana, coins with CEX custody).

Decentralization Scoring

Base score from governance quality tier, then a chain-risk penalty for protocols on less decentralized chains — governance decentralization is undermined when the underlying chain has centralisation concerns:

  • Immutable code— 100 (no admin keys, no upgrade path — e.g. LUSD, BOLD). Exempt from chain-risk penalty
  • DAO governance— 85 (e.g. DAI)
  • Multisig— 55 (e.g. GHO, FRAX)
  • Regulated entity— 40 (named regulator, license, and independent audit — e.g. USDC, USDT)
  • Single entity— 20 (unregulated or unverified issuer)
  • Wrapper— 10 (inherits upstream governance)

Chain-risk penalty (DAO and multisig governance — exempt for immutable-code, wrapper, regulated-entity, single-entity):

  • Combined score ≥80 — no penalty
  • Combined score ≥60 — −10
  • Combined score ≥40 — −25
  • Combined score ≥20 — −40
  • Combined score <20 — −60

Example: hyUSD (DAO governance, Solana, combined score 45) = 85 − 25 = 60. USDB (multisig, Blast L2, combined score 66) = 55 − 10 = 45.

Dependency Risk Scoring

Two-phase computation ensures upstream scores are available before dependent coins are graded. Phase 1 grades independent coins (centralized & decentralized), then Phase 2 grades CeFi-Dependent coins using Phase 1 results.

  • Non-dependent coins— score 95 (no upstream risk)
  • With mapped dependencies— blended score: each upstream's grade is weighted by its collateral fraction, and the self-backed portion (non-stablecoin collateral) scores vary by governance type (decentralized 90, centralized-dependent 75, centralized 95). A −10 penalty applies if any upstream dependency scores below 75
  • Unmapped dependencies— falls back to 70 when dependencies aren't mapped or scores are unavailable

Dependency type ceilings— each dependency is classified as wrapper, mechanism-critical, or collateral(default). Wrappers (e.g., syrupUSDC → USDC) are thin layers around the upstream — their score is capped at upstream − 3. Mechanism-critical dependencies (e.g., DAI → USDC via PSM) are essential to the peg — score is capped at the upstream's score. Collateral dependencies use the blended formula with no ceiling.

Self-backed scores vary by governance type: centralized-dependent coins score 75 (systemic coupling risk), decentralized coins 90, and centralized coins 95. Centralized-dependent coins score lower because their peg mechanisms depend on upstream stablecoin infrastructure even for non-stablecoin collateral.

Grade Thresholds

GradeScore Range
A+87–100
A83–86
A−80–82
B+75–79
B70–74
B−65–69
C+60–64
C55–59
C−50–54
D40–49
F0–39
NRNot enough data

Key Design Decisions

  • NR (Not Rated)is used when fewer than 2 base dimensions have data — no misleading partial grades
  • Weight is redistributed proportionally among rated base dimensions when some are NR
  • Peg stability acts as a multiplier, not a base dimension — maintaining a peg is table stakes, not a differentiator
  • Cemetery (defunct) coins receive a permanent F
  • Decentralization score is structural, not a value judgment
  • Blacklist capability is reported descriptively only and does not affect the Resilience score. Explicit mutable-contract overrides still surface as “possible”, but reserve-side stablecoin, custodied-wrapper, issuer-seizable tokenized collateral, and custody/CEX clues can now also resolve to “possible” when exposure is below the inherited threshold. Stablecoins where a majority of reserves (by weight) are backed by directly blacklistable collateral, custodied BTC wrappers, tokenized gold, issuer-seizable tokenized shares/RWAs, or already-blacklistable upstream assets are flagged as “inherited” blacklist risk

Dependency Ceilings

When a stablecoin depends on another (wrapper, mechanism, or collateral relationship), its dependency risk score is capped relative to its upstream:

  • Wrapper dependency: capped at upstream score minus 3 points
  • Mechanism dependency: capped at upstream score
  • Collateral dependency: blended into dependency risk dimension via weighted average

If any upstream dependency scores below 75, a 10-point penalty is applied. These ceilings prevent a wrapped token from outscoring its underlying asset.

Limitations

  • Peg stability only reflects price data — can't detect coins “stable” because nobody trades them
  • Decentralization is structural, not a value judgment
  • Dependency map is manually maintained — may not capture every collateral relationship

Liquidity Score

v5.3Version history →

Version increments when liquidity formula weights, source inclusion rules, or TVL normalization logic changes.

Composite 0–100 score measuring DEX liquidity depth per stablecoin, updated every 30 minutes. Aggregates pool data across all major DEXes and chains.

Dead or explicitly blocked DEX slugs such as Bunni are excluded upstream from crawl intake, retained pools, challenger snapshots, and DEX-implied price publication instead of being treated as low-quality live venues.

Dedicated protocol-native sources (Fluid, Balancer, Raydium, Orca, Meteora, PancakeSwap V3, Aerodrome Slipstream, and Velodrome Slipstream) are treated as primary-grade inputs and enter scoring before staged or fallback discovery sources are merged.

Discovery coverage is less page-fragile now: CoinGecko Onchain and GeckoTerminal token crawls read multiple bounded pages, and fallback enrichment can activate for weak partial coverage instead of waiting for a strict zero-pool outcome.

Matching is chain-aware: `chain + address` resolves first, and symbol fallback is only allowed when it is unique on that chain for addressless tokens. If an upstream token already supplies an unknown address, it is dropped instead of being remapped by symbol. Pool dedupe uses exact ids plus conservative derived identity keys, so legitimate same-pair pools are not collapsed just because their token set matches. Balancer direct pools now key exact identity off the API's real pool `address`, not the 32-byte vault pool id.

Direct-source precedence is also measurement-aware now. A protocol-native pool only replaces an overlapping DeFiLlama row when it has measured non-zero 24h volume, which means Slipstream pool-state rows can expand Base and Optimism coverage without displacing stronger overlapping DL rows when volume telemetry is absent. Exact pool ids from protocol-native sources still stay reserved for later staged-source dedupe even when the direct row itself is too small to score, so discovery feeds cannot re-add the same address with incompatible TVL semantics.

Discovery rows also need authoritative confirmation when they claim a protocol family that already has a clean protocol-native fetch on that chain. In practice, GT/CG/DS staging cannot invent new Balancer, Fluid, Raydium, Orca, Meteora, PancakeSwap, Aerodrome, or Velodrome pools after the native source succeeded; if that native fetch is degraded or unavailable, the scorer fails open and still allows staged recovery rows through.

When protocol-native sources expose pool inventory, Balancer, Raydium, Orca, Meteora, PancakeSwap V3, and the Slipstream integrations now contribute measured balances and fee detail instead of neutral placeholders. Balancer weighted pools are normalized against target token weights before the balance ratio is computed. Fluid reads reserves and fee detail from the official DexReservesResolver on Ethereum, Arbitrum, Base, and Polygon, while Aerodrome and Velodrome Slipstream read pool state from the on-chain Sugar view contracts on Base and Optimism.

Repeated sightings of the same physical pool across direct API, staged, and fallback sources are collapsed before DEX price aggregation. A separate challenger snapshot preserves the full retained pool set for depeg checks, instead of relying on the visible top-pools subset. Balancer stablecoin pools also get a narrow stable-pair identity fallback when DeFiLlama omits the subtype in `balancer-v3`, preventing direct-API stable pools from being double-counted as faux weighted rows.

Orderbook fallback rows now validate observable ticker quality directly. CoinGecko deprecated `trust_score`, so Pharos filters those tickers by freshness flags, finite USD price/volume, exchange identity, and USD-equivalent quote assets instead of relying on a legacy badge.

PancakeSwap V3 volume now uses a bounded trailing-hour window from the official subgraph's `poolHourDatas.volumeUSD` buckets instead of the latest `poolDayDatas` row, so intraday volume no longer decays toward zero between UTC day rollovers.

After bad pools are filtered and secondary-source TVL caps are applied, every exported aggregate and score input is rebuilt from the retained pool set. That keeps filtered or downscaled pools from lingering in the final score through stale pre-filter totals.

Coverage confidence is measurement-aware. Instead of a fixed score by source family, Pharos now weights how much retained TVL has measured balances and prices, how broad the protocol mix is, and how much of the row depends on synthetic or freshness-decayed fallback liquidity.

Update cadence

30m refresh

Signal mix

5 weighted liquidity components

Output

0-100 DEX depth score

Preconditions & Failure Modes

Minimum data

No hard minimum in scorer; missing stability history defaults to neutral 50 sub-scores

Required sources

Pool TVL/volume/chain data plus mechanism and pair-quality metadata

Failure behavior

If liquidity score is null/missing, report-card liquidity dimension is NR

Worked example (verified against computeLiquidityScore)

Inputs: effectiveTVL=$10M, TVL=$20M, marketCap=$100M, volume24h=$1M, qualityTVL=$12M, durability=70, pools=8

depthRatio=10M/100M=10%, tvlDepth=35×log10(0.10/0.0007)=75

vtRatio=1M/20M=5%, volume=38×(log10(0.05)+3)=65

retention=12M/20M=60%, quality=(0.60−0.15)/0.65×100=69

diversity=min(100,8×5)=40

score=round(0.30×75+0.20×65+0.20×69+0.20×70+0.10×40)=67

Result: Liquidity score 67.

Technical details: component weights, TVL scaling, and quality adjustments

TVL Depth

30%

Vol. Activity

20%

Pool Quality

20%

Durability

20%

Pair Diversity

10%

↓

Liquidity Score

0–100

Components

ComponentWeightHow it works
TVL Depth30%Effective TVL relative to market cap (log-scale): 35×log10(depthRatio/0.0007). ~0.5%→30, ~1.5%→47, ~6%→67, ~14%→80, ~25%+→90+. Falls back to absolute TVL scale when market cap is unavailable.
Volume Activity20%Log-scale V/T ratio: 38×(log10(vtRatio)+3). ~0.3%→18, ~3.5%→59, ~19%→86, ~32%+→100
Pool Quality20%Venue quality retention: qualityAdjustedTvl/totalTvl, rescaled from the realistic 15–80% range to 0–100. Measures mechanism multiplier × balance health; pair quality is captured in TVL Depth via effectiveTvl.
Durability20%TVL stability (35%), volume consistency (25%), pool maturity (25%), organic fee fraction with sqrt curve (15%)
Pair Diversity10%Pool count with diminishing returns: min(100, poolCount × 5)

Pool Quality Adjustments

  • Balance health— continuous ratio (not binary threshold): pools with imbalanced reserves score lower
  • Pair quality— co-token scored by Pharos governance classification (CeFi→1.0, DeFi→0.9, CeFi-Dep→0.8) plus static map for volatile assets (WETH→0.65, WBTC→0.6)
  • Metapool dedup— uses TVL excluding base pool to prevent double-counting across Curve metapools
  • Retained-pool recomputation— HHI, depth, volume, and balance/organic/durability inputs are all recomputed from the same retained pool set before the UI truncates to the top 10 displayed pools

Mint/Burn Flow Scoring

v5.1Version history →

Version increments when flow scoring logic, tracked event semantics, or ingestion attribution policies change.

Pharos tracks on-chain mint and burn events for major stablecoins via Alchemy JSON-RPC (Transfer mints/burns plus USDT Issue/Redeem). These raw events are aggregated into hourly buckets and exposed as two separate signals: raw net flow for current direction, and a baseline-relative pressure score for context. Counted flow excludes bridge transfers, review-required burns, and atomic roundtrips.

Data source

On-chain mint + burn events

Primary score

Pressure Shift vs 30D

Main outputs

Net flow, gauge, and FtQ

Preconditions & Failure Modes

Minimum data

Pressure Shift vs 30D requires at least 7 days of flow history per coin

Required sources

24h mint/burn totals plus 30-day baseline aggregates

Failure behavior

Pressure shift can be null (NR); gauge is null when no weighted inputs contribute; FtQ needs ±$100M dual threshold

Counted rows

Economic-flow aggregates count standard rows only, which in practice means non-bridge mints plus effective burns

Worked example (verified against computeFlowIntensity)

Inputs: currentNet=-$0.2M, baselineNet=-$7.5M, baselineAbs=$40M

denominator=max(40M*0.3,1M)=12M; z=(-0.2M-(-7.5M))/12M=0.608

pressureShift=clamp(-100,100,z*50)=30.4

Result: still burning today, but much lighter than its baseline.

Technical details: two-signal pipeline, pressure formula, and gauge bands

Mints

Transfer from 0x0

Burns

Transfer to 0x0

↓

Hourly Buckets

Trailing 30 closed daily Ethereum buckets

↓

Net Flow 24h

Current mint minus burn direction

Pressure Shift vs 30D

-100 worsening · 0 baseline · +100 improving

↓

Bank Run Gauge

market-cap weighted

Flight-to-Quality

dual threshold

Net Flow 24h

Net Flow answers the first question directly: is a coin minting or burning right now? It is the raw 24-hour mint volume minus burn volume.

  • Minting— `netFlow24hUsd > 0`
  • Burning— `netFlow24hUsd < 0`
  • Flat— `netFlow24hUsd = 0` with activity
  • No activity— no 24h mint/burn events in the window
  • Invariant— minting vs burning always comes from raw net flow, never from the pressure score sign

Pressure Shift vs 30D

This is the existing Flow Intensity formula under clearer naming. It measures how far current 24-hour flow pressure deviates from the coin's own trailing 30 fully closed daily Ethereum baseline.

denominator = max(baselineDailyAbs × 0.3, $1M)
z = (currentDailyNet − baselineDailyNet) / denominator
pressureShift = clamp(-100, 100, z × 50)

  • Baseline period— trailing 30 fully closed UTC days of Ethereum daily net flows and absolute volumes, excluding the current partial day
  • Minimum data— requires 7 days of history; returns null (NR) otherwise
  • Activity gate— windows with no 24h mint/burn activity or less than $50K absolute 24h flow are marked NR and excluded from gauge weighting
  • Ingestion safety— sync state advances only to the shared safe coverage frontier when some event definitions or block timestamps are incomplete
  • Floor— denominator is floored at $1M to prevent noise in low-volume coins
  • Interpretation— above +10 = improving vs baseline, between -10 and +10 = stable vs baseline, below -10 = worsening

Bank Run Gauge

Market-cap-weighted composite of all tracked coins' pressure-shift values, producing a single ecosystem-wide Ethereum flow-pressure reading. The gauge score maps to one of seven condition bands:

BandScore RangeMeaning
CRISIS−100 to −70Severe below-baseline redemption pressure across major coins
STRESS−70 to −40Worsening coordinated pressure versus normal conditions
CAUTIOUS−40 to −10Mild but broad pressure deterioration
NEUTRAL−10 to 10Close to 30D norms across the market
HEALTHY10 to 40Improving aggregate pressure versus baseline
CONFIDENT40 to 70Strong positive pressure shift across major coins
SURGE70 to 100Exceptional improvement versus recent norms

Returns null only when all tracked coins are NR (for example, insufficient history or no 24h mint/burn activity). Coins with null pressure-shift values are skipped from the market-cap-weighted composite.

Flight-to-Quality Detection

Detects capital rotation from risky to safe-haven stablecoins — a pattern typically seen during market stress when holders move funds from algorithmic or less-established coins into fully-backed centralized stablecoins.

  • Safe classification— centralized governance with real-world-asset backing (USDT, USDC, FDUSD, PYUSD)
  • Dual threshold— active when risky coins have >$100M net outflows AND safe coins have >$100M net inflows simultaneously over 24h
  • Intensity scaling— min(100, |riskyOutflows| / $1B × 100), reflecting the magnitude of the rotation

Yield Intelligence

v7.2Version history →

Version increments when APY source resolution, source arbitration, history semantics, PYS scoring logic, or eligibility rules for discovered yield sources change.

Pharos tracks yield-bearing stablecoins and computes a risk-adjusted ranking via the Pharos Yield Score (PYS). Core rankings publish hourly using a source-aware APY resolution strategy, while slower supplemental-source families refresh on a separate four-hour lane. Alternative sources are retained when multiple valid yield paths exist, address-first identity is used before symbol fallback, curated exact-pool overrides can cover named non-stablecoin venues, confidence-weighted arbitration selects the primary row, and published lending suggestions exclude Resolv / USR-linked venues so broken wrapper ecosystems do not surface as recommended base-asset routes. Published lending-opportunity rows now also require observable venue TVL and a size floor of at least 0.1% of the tracked stablecoin's current supply before they can become the live recommendation. PYS is now benchmark-aware: it keeps raw APY as the base term, adds a modest slice of row-level benchmark spread, and only then applies the safety and consistency penalties.

Update cadence

1h publish / 4h supplemental

APY priority

Confidence-weighted across deterministic, curated, and fallback sources

Output

PYS (0-100)

Preconditions & Failure Modes

Minimum data

Need one resolved APY source; deterministic exchange-rate sources additionally need prior source-specific history

Required sources

Direct on-chain reads, curated DeFiLlama pools, curated protocol-native APIs, rate-derived benchmark inputs, or 7-45d price history

Failure behavior

No resolved source skips coin update; PYS returns 0 when apy30d <= 0 or the benchmark-adjusted effective yield is non-positive (safety defaults to 40 / NR if live report-card hydration is missing), while degraded benchmark or safety inputs are surfaced in provenance

Worked example (verified against computePYS)

Inputs: apy30d=8.4, benchmarkRate=4.25, safetyScore=72, apyVarianceScore=0.18, scalingFactor=8

benchmarkSpread=8.4-4.25=4.15; effectiveYield=max(0,8.4+0.25*4.15)=9.44; riskPenalty=max(0.5,(101-72)/20)=1.45; adjustedPenalty=1.45^1.75=1.92; yieldEfficiency=9.44/1.92=4.92; sustainability=1-0.18=0.82

PYS=min(100, round(4.92*0.82*8))=32

Result: PYS 32.

Technical details: APY source resolution, confidence arbitration, PYS formula, NAV handling, and limits

Tier 1

On-chain reads

Tier 2

Curated venues

Tier 3 / 4

Fallbacks

Effective Yield

APY + 25% benchmark spread

Yield Efficiency

Effective yield ÷ curved risk penalty

Sustainability

penalises variance

PYS Score

0–100

APY Resolution and Source Arbitration

  • Tier 1 — Direct on-chain reads: reads protocol state directly, either as an exchange-rate delta (e.g. sUSDe) or a conservative reward-only estimator (e.g. LUSD B.Protocol Stability Pool, LQTY only)
  • Tier 2 — DeFiLlama pools: matches the coin to a DeFiLlama yield pool via static mapping, chain-scoped wrapper rules, and address-first fallback matching, while explicitly preserving wrapper pools that upstream marks as non-stablecoin when they are configured as relevant yield sources and allowing exact-pool curated overrides for assets such as XAUT. Wrapper-over-native venues such as BOLD/yBOLD stay classified as native yield rather than governance-set when the wrapper is just packaging the protocol's own Stability Pool return
  • Tier 2.5 — Protocol-native venues: ingests curated protocol-owned APIs and protocol-specific on-chain venue readers when the canonical savings path is not representable as a reliable DeFiLlama pool; these rows stay in the curated tier rather than inheriting Tier 1 deterministic precedence reserved for native wrapper readers
  • Tier 3 — Price-derived: for NAV tokens only, derives APY from 7-45 day price appreciation in `supply_history`
  • Tier 4 — Rate-derived: for dividend-distributing and Treasury-tracking tokens, derives APY from the selected benchmark registry entry net of known fee spreads, using USD by default, 3-month compounded €STR for EUR pegs, and 3-month compounded SARON for Swiss-franc pegs

Deterministic and curated paths can all contribute rows, then a confidence-weighted arbitration layer chooses the best row. Divergent discovered or fallback sources can be demoted or rejected when a canonical source disagrees materially. Protocol-native supplemental lending venues such as Aave V3 do not outrank stronger native wrapper yields purely because they query protocol state directly, and Resolv / USR-linked lending-opportunity venues are excluded from publication entirely. Published lending-opportunity rows also need observable venue TVL and must clear the higher of the absolute TVL floor or 0.1% of the tracked stablecoin's current supply.

Yield-bearing coverage is now explicitly inventoried per asset. If no reliable runtime source exists, the asset is marked as an intentional gap rather than silently disappearing from audit coverage.

Deterministic rows keep their own source identity (`onchain:<stablecoinId>`) rather than sharing a pool UUID with curated sources, so source-aware history and previous-rate lookups stay isolated when both paths coexist.

Trailing APY metrics are computed from source-specific history rather than a mixed coin-level series, so source switches no longer contaminate the displayed 7d/30d averages.

Read-time data-stale warnings are also cadence-aware: hourly families attach only after three missed sync-yield-data intervals (about 3 hours at the current publisher), while price-derived rows wait 36 hours because they are backed by daily supply_history snapshots rather than hourly source observations.

Pharos Yield Score (PYS)

benchmarkSpread = apy30d − benchmarkRate
effectiveYield = max(0, apy30d + benchmarkSpread × 0.25)
riskPenalty = max(0.5, (101 − safetyScore) / 20)
yieldEfficiency = effectiveYield / (riskPenalty ^ 1.75)
sustainability = max(0.3, 1.0 − apyVarianceScore)
PYS = min(100, yieldEfficiency × sustainability × scalingFactor)

  • Effective yieldkeeps raw APY as the anchor, then adds 25% of the row's benchmark spread so tighter local-currency cash hurdles can lift the score without turning PYS into a pure excess-yield ranker
  • Yield efficiencyrewards higher APY relative to the coin's risk profile — the raw safety penalty is raised to a fixed power so weaker safety grades need much more effective yield to compete
  • Sustainability multiplier penalizes volatile yields (high variance over 30 days), favouring consistent returns
  • Scaling factoris a global constant that normalises scores into a readable 0–100 range after the steeper safety curve is applied

NAV Token Handling

NAV-appreciating tokens (e.g. sDAI, wUSDM, BUIDL) are not covered by the report card framework's safety grading — they receive a default safety baseline of 40 (NR). Their PYS is therefore derived primarily from APY magnitude and variance rather than a full safety assessment. As the grading framework expands to cover NAV tokens, their PYS will become more nuanced.

Limitations

  • Trailing averages require sufficient history — newly tracked coins may show unstable scores until 7 days of data accumulate
  • Some DeFiLlama and protocol-native surfaces still depend on upstream asset metadata completeness; the resolver now drops ambiguous candidates rather than guessing across duplicate symbols
  • The LUSD B.Protocol Stability Pool row is conservative by design: it includes projected LQTY incentives only and excludes ETH liquidation gains
  • Price-derived APY (Tier 3) can be noisy for low-liquidity NAV tokens

PegScore and Depeg Early Warning Score (DEWS)

v5.9Version history →

Version increments when depeg thresholds, confirmation policy, peg-score formula terms, or DEWS signal composition or score-affecting input semantics change.

PegScore observes the past and present by scoring realized peg behavior, while DEWS is forward-looking and tries to anticipate future depeg risk before it fully manifests.

Depeg Tracker combines live event detection, secondary-source confirmation rules for large-cap assets, low-confidence primary prices, and extreme moves, plus a per-coin peg score that penalizes time off peg, event severity, active depegs, and unstable event spread. Pending depeg confirmation checks same-direction off-chain sources (CoinGecko or DefiLlama), supported native-peg quotes, Binance tickers, trusted aggregate DEX prices, and large challenger pools before promoting or rejecting candidates.

When a live event is later contradicted across the peg by a low-confidence primary price, the detector now retires the stale live row immediately and routes the replacement move through pending confirmation instead of leaving the wrong direction active.

Pending incidents are no longer write-once snapshots. While a candidate is waiting for confirmation, Pharos now preserves the original first-seen timestamp, refreshes the current last-seen state, tracks the worst same-direction move, and resets the pending row cleanly if the market flips to the opposite side of the peg.

DEX cross-validation uses explicit trust gates: detection and pending confirmation only trust fresh DEX rows with at least $1M of aggregate source TVL, while the public DEX Price Check UI requires a lighter but still non-trivial floor of $250K. Aggregate DEX rows also need deeper corroboration before they can mutate live event state: recoveries/suppression now require at least two protocol-level DEX groups inside threshold, and ambiguous-primary recoveries are vetoed when a large challenger pool still shows the old depeg direction. For already-open depegs, same-direction aggregate DEX disagreement is advisory rather than a synthetic recovery signal, so events stay continuous until the normal recovery path confirms the coin is back inside threshold.

Thin non-USD fiat peg groups also fail closed when the live peg reference would have to rely on a 1–2 coin peer median or an empty peer set instead of cached FX. Once a live row is already open, a fresh non-cached multi-source primary cluster can retire it after recovery even if that source mix is still too soft to open brand-new events directly.

For supported fiat pairs with a clean native-market quote, depeg routing now also checks that direct native quote before trusting a derived USD-versus-FX move. That means BRZ-style BRL reference drift can no longer open, sustain, or confirm a live depeg when the fresh direct BRZ/BRL quote is already back near parity. Historical backfill now follows the same principle for supported non-USD fiat assets: when CoinGecko exposes a native fiat pair, replay prefers that native history and compares it directly to the native 1.0 peg before falling back to USD-plus-FX reconstruction. In that native-replay mode, Pharos now uses daily points plus a two-point confirmation window across 36 hours so thin hourly native prints do not manufacture long false historical depeg streaks.

Live depeg events still require at least $1M of current circulating supply. Below that floor, the detail page may still show the current price deviation from peg, but it labels live event coverage as limited instead of implying the coin held peg.

DEWS (Depeg Early Warning System) computes forward-looking stress every 30 minutes from market, liquidity, confidence, flow, and yield signals, with optional PSI-based amplification during systemic stress. Its divergence input now reuses the live depeg DEX trust floor, so fresh-but-thin DEX rows stay visible for analytics but do not affect the score unless they pass the same `$1M` aggregate-TVL gate.

Historical DEWS daily snapshots do not retain the underlying DEX trust metadata needed to replay that gate exactly. When operators remediate the old thin-DEX window, the repair path refreshes current rows and prunes unrecomputable daily history back to the Mar 9, 2026 trust-floor boundary before new snapshots are published under the stricter rule.

PegScore focus

History: realized peg behavior

DEWS focus

Forward stress probability

Refresh

Peg 15m / DEWS 30m

Preconditions & Failure Modes

Minimum data

PegScore requires >=7 tracking days; DEWS requires >=2 available signals (total weight >=0.30) plus fresh core source tables

Required sources

Peg events + tracking window inputs; DEWS consumes supply/liquidity/price plus optional flow/blacklist/yield signals

Failure behavior

PegScore can be null; DEWS returns null when signal coverage is below threshold, and the cron degrades/no-writes when core source reads fail or dex liquidity is stale

Worked examples (verified against computePegScore and computeDEWS)

PegScore input: 100-day tracking window, 1 event (2 days, 220 bps, inactive)

pegPct=98.0, severityScore=99.86, spread=0, activePenalty=0 → pegScore=99

DEWS input signals: supply=40, pool=55, liq=25, price=0, diverg=10 (others unavailable), psiScore=70

base=(0.25*40+0.2*55+0.15*25+0.15*0+0.15*10)/0.9=29.17; PSI amplifier=1.02 → DEWS=30

Result: PegScore 99 and DEWS 30 (WATCH).

Technical details: PegScore formula, DEWS signals, weights, and threat bands

PegScore

Composite 0–100 score measuring how faithfully a stablecoin holds its peg. The tracking window spans up to 4 years but is capped at the coin's actual age. PegScore now prefers a curated launch date when one is available and otherwise falls back to the earliest supply snapshot, so young coins are not diluted across history they didn't exist for. Requires at least 7 days of tracking data; returns null otherwise. Scores based on 7–30 days are marked as “Early score” to signal limited history.

PegScore Formula

pegScore = 0.5 × pegPct + 0.5 × severityScore − activeDepegPenalty − spreadPenalty

Time-at-Peg

50%

Event Severity

50%

↓

− Penalties

active depeg + spread

↓

PegScore

0–100

PegScore Components

ComponentWeightRangeHow it works
Time-at-Peg (pegPct)50%0–100Percentage of time spent at peg. Overlapping depeg intervals are merged to avoid double-counting
Event Severity50%0–100Penalizes magnitude, duration, and recency of each depeg event. Per-event penalty: max(durationPenalty, magnitudeFloor), where durationPenalty = (peakBps / 100) × (durationDays / 30) × recencyWeight, magnitudeFloor = (peakBps / 2000) × recencyWeight. The floor ensures even brief depegs carry a minimum penalty proportional to their severity. Recency weight = 1 / (1 + yearsAgo) so recent events count more. Duration capped at 90 days
Active Depeg Penaltysubtracted5–50Applied only if an ongoing depeg exists (no end date). Scales with severity: clamp(absBps / 50, 5, 50)
Spread Penaltysubtracted0–15Standard deviation of peak deviations across events, scaled. Penalizes erratic, unpredictable depeg behaviour. Only applies when ≥2 events exist

DEWS

DEWS is a per-coin, forward-looking stress score (0–100) estimating depeg probability. It is computed every 30 minutes from 8 sub-signals. Only signals with available data participate; weights are redistributed proportionally across available signals.

Bootstrap tolerance is one-time only. Missing optional tables can be ignored before the first successful publication, but once DEWS has published, stale or missing core liquidity inputs block fresh writes instead of being treated as startup noise.

Supply Velocity

0.25

Pool Balance Drift

0.20

Liquidity Erosion

0.15

Price Confidence

0.15

Cross-Source Div.

0.15

Blacklist Activity

0.10

Mint/Burn Flow

0.10

Yield Anomaly

0.05

↓

DEWS

Σ(W⋅S) / Σ(W) — 0–100

↓

CALM

0–15

WATCH

16–35

ALERT

36–55

WARN

56–75

DANGER

76–100

Score Formula

DEWS = round(clamp(0, 100, sum(W_i × S_i) / sum(W_i)))

At least 2 available signal sources (total weight ≥ 0.30) are required; otherwise DEWS returns null.

Sub-Signals & Weights

  • Supply Velocity (0.25)— rapid redemptions (bank run), measured from 1-day and 7-day supply contraction rates
  • Pool Balance Drift (0.20)— one-sided selling pressure in DEX pools, blending balance stress, pool stress, and worst-pool imbalance
  • Liquidity Erosion (0.15)— LPs fleeing, measured from 7-day changes in liquidity score and TVL
  • Price Confidence (0.15)— N-source consensus failures across CoinGecko, DefiLlama list, GeckoTerminal, Pyth, Binance, Coinbase, RedStone, Curve on-chain, and DEX prices; maps confidence levels (high/single-source/low/fallback) to stress values
  • Cross-Source Divergence (0.15)— fragmented pricing between multi-source consensus price, DEX price, and peg reference
  • Blacklist Activity (0.10)— issuer emergency freeze surges for USDC, USDT, PAXG, XAUT
  • Mint/Burn Flow (0.10)— redemption surge vs minting from on-chain Transfer event data; mature 30-day coverage stays available even when the latest 24-hour window is quiet, contributing zero flow stress instead of disappearing
  • Yield Anomaly (0.05)— warning-signal accumulation from yield spikes, divergence, TVL outflows, negative trends, and reward-heavy regimes

Threat Bands

  • CALM (0–15)— no stress signals detected
  • WATCH (16–35)— mild stress on 1–2 indicators
  • ALERT (36–55)— multiple indicators elevated
  • WARNING (56–75) — strong stress signals, depeg plausible
  • DANGER (76–100)— all precursors firing

Edge Cases

  • NAV tokens are excluded entirely (price appreciates, not pegged)
  • Non-USD pegs: cross-source divergence is dampened by 0.7 (noisier FX pricing)
  • Small coins (<$50M): supply velocity is dampened via a logarithmic size factor
  • Missing DEX data: pool and liquidity signals marked unavailable, weight redistributed

Contagion Stress Test

The stress test simulates dependency failures to reveal systemic concentration risk across the stablecoin ecosystem.

Simulation action

Force one coin to grade D

Propagation channel

Dependency channel only

Primary output

Affected coins + supply at risk

Preconditions & Failure Modes

Minimum data

Target coin must have dependents and mapped dependency weights

Required sources

Current report-card scores plus dependency map inputs

Failure behavior

Only direct dependency-risk channel is recomputed (no peg/liquidity/confidence feedback loops)

Worked example (verified against scoreDependencyRisk path used by stress test)

Override upstream score to 40; dependent coin has 60% exposure and decentralized self-backed score 90

blended=0.6*40+0.4*90=60; weak-upstream penalty (score<75) applies -10

dependencyRisk score=50

Result: Dependency dimension falls to 50 before overall grade recomputation.

Technical details: simulation pipeline, scoreboard logic, and limitations

Select Target

pick a coin

↓

Override to D

force downgrade

↓

Recompute Dep. Risk

cascade upstream

↓

Impact Report

coins & $ at risk

Systemic Risk Scoreboard

On page load, the scoreboard pre-computes the five most damaging single-coin failure scenarios. For each targetable coin (one that has dependents), it simulates a downgrade to D, counts the number of affected coins, and sums their market cap as “supply at risk.” Results are sorted by supply at risk descending.

Stress Test

The interactive stress test overrides a target coin's overall score, then recomputes the Dependency Risk dimension for every coin that lists that target as an upstream dependency. This models the direct dependency channel only.

In reality, a major stablecoin failure would also impact peg stability, liquidity, and market confidence simultaneously — the stress test captures only the mechanical dependency impact.

Limitations

  • Collateral weights are researched estimates that may not reflect real-time ratios
  • The stress test models only the dependency risk channel, not second-order market effects

Blacklist Tracker Methodology

v3.7Version history →

Version increments when tracked contracts, event parsing rules, cursor semantics, or amount-enrichment logic change.

The Blacklist Tracker monitors issuer intervention events across USDC, USDT, PAXG, XAUT, PYUSD, and USD1 contracts, including blacklist, unblacklist, and destroy/wipe actions across EVM and Tron networks.

Methodology revisions document changes to event coverage, cross-chain decoding behavior, cursor safety policies, event-time amount attribution rules, and the separate freeze-ledger snapshot used for the public summary and quarterly chart, including the reconciled `kyc.rip` / `stables.rip` bootstrap for ETH USDC, ETH USDT, and TRON USDT.

Chain Health Score

v1.2Version history →

Version increments when factor weights, tier assignments, or sub-factor formulas change.

The Chain Health Score is a 0–100 composite that rates each blockchain’s stablecoin ecosystem across five weighted factors. It answers: how healthy, diverse, and resilient is the stablecoin mix on this chain?

Score range

0–100 (null when safety-score coverage < 50%)

Refresh cadence

Every stablecoins cache refresh (~10 min)

Dependencies

DefiLlama supply, Pharos Safety Scores, peg rates

Formula & Weights

Composite formula

healthScore =
      0.30 × quality
    + 0.20 × chainEnvironment
    + 0.20 × concentration
    + 0.20 × pegStability
    + 0.10 × backingDiversity
FactorWeightWhat it measures
Quality30%Supply-weighted average of Pharos Safety Scores for stablecoins on the chain. Unrated coins default to 40. Returns null if rated supply < 50% of total.
Chain Environment20%Rates the chain’s own infrastructure quality, decentralization, and censorship resistance via a resilience tier: Tier 1 (100) for battle-tested, highly decentralized L1s; Tier 2 (60) for established chains with moderate centralization; Tier 3 (20) for unproven or problematic chains.
Concentration20%100 × (1 − HHI) where HHI = Σ(market share)². A single stablecoin scores 0; perfectly even N coins score 100×(1−1/N).
Peg Stability20%Supply-weighted average of per-coin peg proximity: 100 − deviationBps/5. Coins without a price get a neutral 50.
Backing Diversity10%Normalized Shannon entropy across the two active backing types (RWA-backed and crypto-backed). 0 for monoculture, 100 for an even split.
Chain Resilience Tiers

The same stablecoin can have different security properties on different chains. A fully on-chain, censorship-resistant stablecoin on Ethereum mainnet may lose those guarantees on an L2 with a centralized sequencer. The chain environment factor captures this.

TierScoreCriteriaExamples
Tier 1100Highly decentralized, battle-tested, censorship-resistant L1Ethereum
Tier 260Established chains with moderate centralization (default for unlisted chains)Solana, BSC, Arbitrum, Tron, Base, Polygon
Tier 320Unproven, known centralization issues, or compromised securityPulseChain, Harmony, BitTorrent
Health Bands
BandScore RangeInterpretation
Robust80–100Strong, diversified stablecoin ecosystem on quality infrastructure
Healthy60–79Good ecosystem with room for improvement
Mixed40–59Moderate concerns — concentration, quality gaps, or chain risk
Fragile20–39Significant ecosystem weaknesses
Concentrated0–19Minimal diversity or critically weak infrastructure
Worked example: Ethereum vs PulseChain

Ethereum (Tier 1)

quality      = 72  (supply-weighted safety scores across ~190 coins)
    environment  = 100 (tier 1 — gold standard for decentralization)
    concentration= 66  (USDT ~48%, USDC ~33% → HHI ≈ 0.34)
    pegStability = 98  (most coins very close to peg)
    diversity    = 35  (overwhelmingly RWA-backed)

    health = 0.30×72 + 0.20×100 + 0.20×66 + 0.20×98 + 0.10×35
           = 21.6 + 20 + 13.2 + 19.6 + 3.5 = 77.9 → 78 (healthy)

PulseChain (Tier 3)

quality      = 72  (DAI + unrated coins defaulting to 40)
    environment  = 20  (tier 3 — unproven, centralized)
    concentration= 67  (DAI ~39%, rest ~12% each)
    pegStability = 98  (coins on peg)
    diversity    = 61  (mixed backing types)

    health = 0.30×72 + 0.20×20 + 0.20×67 + 0.20×98 + 0.10×61
           = 21.6 + 4 + 13.4 + 19.6 + 6.1 = 64.7 → 65 (healthy)

    → Chain environment alone creates a 16-point gap vs Ethereum.