Glossary

A longer moving average used to show slower background trend. It is useful because a chain can look very active over a few days while still being ordinary relative to the last month.

MA30 is the product's slower context line. It is most informative when used with raw daily and MA7 values: daily shows immediate movement, MA7 shows short trend, MA30 shows slower baseline. That layering is one of the core pedagogical ideas of the product.

A short moving average used to smooth recent day-to-day noise. It helps show whether the latest direction is still building over roughly the last week instead of reacting to one jagged daily point.

The frontend should read MA7 directly from derived artifacts rather than recomputing it locally. In interpretation terms, MA7 is the product's short-horizon trend smoother and is especially useful when compared with MA30 and raw daily values to separate fresh movement from background volatility.

This flag tells you whether the confidence layer was incomplete or unavailable for the row. If true, the product should not pretend it knows more than it does.

When true, the UI should avoid presenting the classification as fully supported. The correct design response is visible uncertainty, not UI-side invention or silent substitution.

Confidence tells you how much evidence supports the currently published classification. It is not a prediction score and it is not the probability that the regime is 'true'. A higher value means the current label is backed by more complete data and a clearer internal signal structure.

In the current backend, confidence_score is the geometric mean of data_quality_score and label_confidence_score: sqrt(data_quality_score × label_confidence_score). That means confidence only stays high when both inputs are strong. It should be read as evidence sufficiency for the present classification, not as forecast skill, expected return, or directional conviction.

A machine-readable reminder of what the confidence score is supposed to mean. It helps keep the UI honest about the interpretation.

The current semantics string identifies the score as a combination of data quality and label stability. This is important because it prevents the product from drifting into a misleading interpretation such as probability of future success or price direction.

How much of the latest row's required input data is actually present. A value near 1 means the latest day has the fields the chain is expected to provide.

This is computed from chain-specific required metrics, not from every possible field in the dataset. It answers 'does the latest row contain the inputs this chain needs for classification?' rather than 'is every column in the file populated?'.

This score asks a simpler question than full confidence: 'Do we have enough complete and recent data to evaluate the chain properly right now?' It is the data sufficiency side of confidence, before the model asks whether the regime itself is internally clear.

The backend computes data_quality_score from five weighted components: current_row_coverage (30%), recent_metric_coverage (20%), recent_density (20%), history_depth (15%), and freshness_asof (15%). The score is clipped to 0..1. This is about data completeness and freshness only; it does not yet judge whether the regime label is sharp or ambiguous.

How fresh the row is relative to the chain's normal publishing lag. A chain can still be usable when not perfectly fresh, but confidence should decline when lag becomes unusually large.

Freshness is chain-aware. The backend compares lag against PUBLISH_LAG_DAYS_POLICY for the chain, then applies a soft-to-hard penalty curve. This matters because Base and Arbitrum are allowed more lag than Bitcoin or Ethereum, so the same calendar lag should not automatically mean the same freshness score across chains.

How much historical depth is available for the current computation. More history usually makes baselines, percentiles, and unusualness estimates more trustworthy.

In the current backend this is capped at 1.0 once roughly 90 distinct days are available. The score is not trying to reward infinite history forever; it is trying to avoid giving full confidence to a regime that was inferred from a very short local sample.

This score measures how clearly the current scorecard and driver evidence support the label that was chosen. It is the signal-clarity side of confidence.

For non-STABLE labels, label confidence mainly depends on scorecard margin and driver support. For STABLE, the model also rewards neutrality, because a stable label should look genuinely close to the chain's own middle ground rather than merely lacking extreme readings. UNKNOWN/DEGRADED maps to zero label confidence.

How many actual published days exist in the recent trailing window relative to how many days should ideally be there. It is a direct check for holes in the recent series.

The backend measures recent_density as observed distinct days divided by expected recent days. This is why missing runs or broken daily continuity immediately push data quality down, even if the rows that do exist look individually complete.

The average row-level coverage across the recent trailing window. It tells you whether the last several weeks look consistently complete, not just whether the latest row is complete.

The backend computes recent_metric_coverage as the average of row coverage over the recent trailing window used by the confidence routine. This catches situations where today's row looks complete but the surrounding days are patchy, which would make trends less trustworthy.

The average time between blocks. Faster or slower block times are not automatically good or bad; what matters is whether they become unusually unstable relative to the chain's own history.

The current model does not treat raw block time as a simple 'higher is worse' signal. Instead it derives blocktime_instability and feeds that into Capacity pressure. The idea is that unusual disruption in block cadence can be more informative than the raw level by itself, especially across chains with different normal block schedules.

This is a derived signal showing how unusually unstable block timing has recently been. It focuses on irregularity rather than raw speed.

The backend uses a special instability scoring routine for avg_block_time_sec rather than treating the raw value as a standard monotonic signal. That makes this component a better fit for Capacity pressure, because erratic block production can indicate strain even when average block time alone is not obviously extreme.

The number of transactions observed on the chain for that day. It is one of the clearest direct activity measures: more transactions usually means more throughput demand, though not all transactions are economically equal.

tx_count_daily feeds the Demand axis. In the scorecard it is log-transformed before standardized scoring so very large absolute chains do not dominate purely because of scale. It should be interpreted alongside active addresses and tx_per_user rather than as a standalone demand truth.

This shows where today's value sits relative to roughly the last 90 days. For example, a value near 95 means the metric is higher than most days in that recent history; a value near 5 means it is lower than most days.

pct_90d is useful because it complements z_robust. z_robust measures standardized unusualness, while percentile gives a direct rank-based location in the recent distribution. Together they make it easier to see whether a metric is merely above average or genuinely near an edge of the recent sample.

Which high-level dimension the driver belongs to: demand, friction, or capacity. This tells you what kind of pressure the metric is describing.

The axis field is part of the published explanation payload and should be interpreted as the metric's role inside the scorecard/regime model, not just a cosmetic tag. It lets advanced users trace local signals back to the dimension-level classification logic.

The raw current value of the driver metric. This is the actual metric reading before it is translated into z-scores, percentiles, or scorecard scores.

Raw current values are crucial for traceability because they let advanced users move from explanation back to the underlying observed number. Correct interpretation depends on the metric's own unit definition, not on the driver wrapper itself.

The metric currently standing out enough to be listed as a driver of the published regime. Drivers are the pieces of evidence the model thinks are most relevant right now.

Drivers are filtered and ranked from candidate signals, with axis-specific weighting and label-consistency filtering. The result is a compact, published explanation layer showing which metrics most strongly support the classification.

This compares a shorter recent average with a slower longer average. Positive values usually mean the metric has been accelerating recently. Negative values usually mean it has been cooling or fading.

Momentum 7d vs 30d is the product's compact short-versus-long directional signal. It matters because many descriptive states should care not only about level but also about whether pressure is still building or easing. This is one of the core ingredients that separates a persistent trend from a one-day spike.

This tells you how unusual the metric currently looks relative to its own history. The larger the absolute value, the more exceptional the reading is. 'Robust' means the method tries to be less sensitive to outliers than a naive standard deviation approach.

z_robust is one of the main driver-sorting signals in the UI and in backend support logic. It is especially important because label confidence uses driver signal support. Very small absolute z-scores mean the metric is not standing far from its own baseline; large absolute z-scores mean the metric is contributing unusually strong evidence.

The directional reading attached to a driver, such as heating, cooling, or flat. It tells you whether the metric has recently been building, fading, or staying roughly unchanged.

Driver trend is part of the regime-engine signal summary and is used both for explanation and for label-consistency checks. For example, HEATING labels prefer drivers that are either high or still directionally heating rather than merely elevated in isolation.

The share of transactions that failed. Higher values suggest more execution friction or adverse conditions for users trying to get transactions through.

failed_tx_rate feeds the Friction axis directly. In a descriptive product like this, it is useful because it reflects realized user-side difficulty rather than theoretical pressure alone. It should usually be read together with fees and utilization rather than in isolation.

Fee burden proxy is a normalized fee measure: roughly speaking, how large the typical fee is relative to the typical transaction value. It is meant to reflect how 'heavy' fees feel, not just how high they are in absolute token terms.

The backend computes fee_burden_proxy as median_tx_fee_native divided by median_tx_value_native when both are available. It is then log-transformed and standardized into the Friction dimension. This is a better user-cost proxy than raw fee alone because it makes cost interpretable relative to typical economic activity size.

Gas utilization shows how full the chain's execution capacity was. Higher utilization usually means the chain was operating closer to its practical limit.

gas_utilization_pct is one of the core Capacity-pressure inputs. It is not exactly the same thing as congestion, but sustained high utilization is one of the clearest signs that the network is becoming tight relative to current demand.

The median fee paid per transaction in the chain's native token unit. Median is used instead of average because it is less distorted by a few extreme outliers.

The backend does not use median_tx_fee_native alone as the main friction feature. Instead it helps build fee_burden_proxy by normalizing fee against median transaction value when available. This matters because the same absolute fee can feel very different depending on the typical value being moved.

The median amount moved per transaction in the chain's native unit. It provides context for how large a typical transfer is, which helps when judging whether a fee is light or heavy relative to the value being moved.

This field becomes especially important when constructing fee_burden_proxy = median_tx_fee_native / median_tx_value_native. Without that normalization, raw fees can overstate friction in contexts where transaction values are also large.

Transactions per active address is a simple intensity measure: how much activity is occurring per active participant. It helps distinguish broad light usage from concentrated heavy usage.

The backend derives tx_per_user as tx_count_daily divided by unique_active_addresses, with zero denominators treated as missing. It is part of the Demand score because a chain where each active address is doing much more than usual can signal demand pressure even if absolute address count alone does not look extreme.

The number of distinct addresses active on the chain that day. It is a rough breadth-of-participation signal: how wide the usage looks, not just how many transactions occurred.

This metric complements tx_count_daily by adding breadth. A chain can have high transaction count concentrated in fewer actors or high breadth with lower per-address activity. The model therefore treats active addresses as a separate demand component rather than collapsing everything into one count.

The lag between the row's own as-of date and the latest source day used for that row. If this is 0, the row and its data date match. If it is larger than 0, the row is being judged using older underlying data.

This is the historically correct lag measure for Track Record-style views. It is different from lag versus today. Using lag_days_vs_asof_date avoids the misleading effect where old historical rows would automatically look stale simply because time has passed since publication.

How many days behind the latest published chain data is relative to today. This is useful for current freshness banners, but less useful for interpreting old historical rows.

This field remains useful for current page freshness and operational monitoring. It should not be confused with historical as-of lag. A row from months ago can have a large lag vs today even if it was perfectly fresh when it was published.

The most recent date fully covered by the currently published artifact. Think of it as the latest day the published bundle is actually speaking about.

updated_through is a high-priority as-of field for current page rendering. It matters because global publish time and row-level as-of date are not the same thing. The product should always be explicit about which date an interpretation refers to.

The timestamp when the current dataset manifest was published. This tells you when the release itself happened, which is different from the dates the underlying chain rows refer to.

This field distinguishes dataset publication time from per-chain updated_through or as-of dates. That distinction is critical for a descriptive historical product, because a dataset can be published today while still describing chain conditions from yesterday or earlier for some chains.

The version identifier for the currently published dataset manifest. It helps users and developers know which published release they are looking at.

Dataset version is a publish-level traceability field rather than a per-chain analytics field. It is useful for release management, auditing, and correlating visible output changes with specific published artifact versions.

The currently active methodology version for the published dataset. If this changes, users should assume that at least some explanation, calculation, threshold, or mapping may also have changed.

This is a governance-critical traceability field. It allows users to distinguish output changes caused by new chain conditions from output changes caused by methodological revision. In a transparent descriptive product, that distinction is essential.

CHEAP means the chain currently looks easy to use relative to its own history. That usually means friction is low and capacity pressure is low at the same time, so the network appears to have room to spare.

The ruleset assigns CHEAP when both Friction and Capacity are in low bands. This is important: the label is not 'fees are low' in isolation. It is a joint state where the chain looks inexpensive and unconstrained relative to its own historical behavior.

CONGESTED means the chain appears to be operating under real capacity pressure. Usage is high enough relative to available throughput that users are more likely to feel the network becoming crowded through higher fees, fuller blocks, slower execution, or more failures.

The ruleset assigns CONGESTED when Capacity is EXTREME_HIGH, or when Capacity is HIGH and Friction is also HIGH. This is intentionally stricter than 'demand is high'. The label is meant to describe a chain where demand is pressing against execution capacity, not merely a chain that is busy.

HEATING means demand looks stronger than usual and the recent direction still points upward. In plain language, activity appears to be building rather than merely producing a single isolated spike.

The regime engine assigns HEATING when Demand is in a high band and at least one relevant axis trend is also HEATING. That means the model is looking for both elevated level and positive short-versus-long momentum. It is therefore stronger than 'high today' but weaker than a fully congested state.

This is the published color hint for the regime badge. It helps users separate states visually, but the label itself is what matters.

The UI prefers the published status.color when present and only falls back to local color mapping if needed. Color is presentation, not methodology. It should never be interpreted as extra model output beyond the published regime label.

The regime label is the product's compact description of the chain's current on-chain state. It is descriptive only. It does not predict what happens next and it does not tell the user what to do. Its job is to summarize whether the latest published evidence looks more like stable conditions, heating demand, congestion pressure, cheap conditions, or a degraded / low-confidence state.

The frontend treats status.label as the canonical published regime label and only falls back to regime.label if status.label is unavailable. In the backend, the label is produced by deterministic rules over Demand, Friction, and Capacity evidence, with a confidence gate that can force UNKNOWN/DEGRADED. The UI does not recompute the label. The correct interpretation is therefore 'published classification result', not 'UI opinion' or 'forecast'.

The one-liner is a short human-readable summary of the published regime. It is there to make the page readable at a glance before the user dives into the detail.

This text is pipeline-authored descriptive copy published alongside the regime label. The UI renders it directly and should not be treated as an independent inference layer. It compresses regime, confidence, and chain context into one short sentence.

STABLE means the chain does not currently show a strong enough combination of demand pressure, friction pressure, or cheap-capacity conditions to justify a more extreme label. It does not mean 'nothing is happening'. It means the chain still looks broadly within its normal historical operating range.

In the ruleset, STABLE is the default label when the evidence does not meet CONGESTED, CHEAP, or HEATING conditions and the confidence gate does not force UNKNOWN/DEGRADED. In practice this usually means scorecard dimensions are not far enough from neutral, or the directional evidence is not persistent enough, to support a stronger regime label.

UNKNOWN/DEGRADED means the product does not have enough trustworthy evidence to publish a stronger regime label confidently. The latest data may still be visible for traceability, but the classification itself should be treated as insufficiently supported.

This state is usually triggered by the confidence gate rather than by a separate market condition. In the current model, the published regime becomes UNKNOWN/DEGRADED when combined publish confidence falls below the configured threshold. It is therefore an evidence-quality state, not a fifth economic regime in the same sense as STABLE, HEATING, CONGESTED, or CHEAP.

A 0-100 score describing how tight the chain's capacity conditions look. Higher means the chain appears closer to practical throughput pressure. Lower means more room to spare.

Capacity is built from gas_utilization_pct and blocktime_instability. The product uses 'capacity' to mean pressure on usable execution capacity, not installed theoretical capacity. Like the other dimensions, the final score is pulled toward 50 when effective confidence is low.

Coverage factor tells you how many of an axis's expected components were actually available. A lower value means that axis had to be judged with fewer than the ideal supporting inputs.

Each scorecard dimension has an expected component count: Demand expects 3, Friction expects 2, Capacity expects 2. coverage_factor is used together with overall confidence to form effective_confidence for that axis. This is why a dimension can stay visible but become visibly less assertive when component coverage is incomplete.

A 0-100 score describing how hot the chain's demand side looks relative to its own history. Around 50 is neutral. Higher means more demand pressure. Lower means quieter conditions.

Demand is built from tx_count_daily, unique_active_addresses, and tx_per_user. The raw component scores are combined and then shrunk back toward 50 according to effective confidence. This means high demand scores require both strong signals and enough confidence to trust them.

Effective confidence is the amount of confidence that actually reaches a single scorecard axis after taking that axis's coverage into account.

The backend computes effective_confidence as base_confidence × coverage_factor for each dimension. The final displayed score is then moved back toward 50 using this value. That is why low effective confidence does not necessarily delete a score; instead it makes the score less extreme and therefore more conservative.

A 0-100 score describing how difficult or expensive the chain currently looks to use relative to its own history. Higher means more cost or execution friction. Lower means the chain looks easier to use.

Friction is built from fee_burden_proxy and failed_tx_rate. The important subtlety is that this is not just a fee level. It is a composite pressure view of cost and failure-like strain, expressed relative to the chain's own normal behavior and shrunk toward 50 when confidence is weak.

A built-in note explaining how to read the scorecard. The core idea is simple: scores are 0-100, 50 is neutral versus the chain's own history, and low confidence pulls scores back toward 50.

This note is important because it encodes the product's central score semantics: chain-relative normalization, 50 as neutral midpoint, and confidence-aware shrinkage. Those three ideas are what stop the scorecard from being mistaken for an absolute cross-chain ranking.

The qualitative band attached to a score, such as low, normal, or high. It makes the numeric score easier to read quickly.

Levels are not separate data; they are categorical interpretations of the underlying 0-100 score. The confidence logic also uses score-versus-level margin, because a label should be more trustworthy when the score sits well inside its assigned band rather than barely touching it.