ETH L1

ETH L1 exposes a richer execution surface than BTC because the underlying state machine prices computational work in gas units. That lets the descriptive layer distinguish among throughput, fee burden, and utilization more explicitly. Demand can therefore be read from usage metrics such as transaction count; Friction from fee/failure burden; and Capacity from utilization and block-pacing fields. The point is not that these are independent latent variables in a strict econometric sense, but that the published decomposition preserves explanatory resolution that would be lost in one blended number.

The advanced way to read ETH is as a constrained execution system: a chain can carry high activity while still having moderate Friction if execution remains roomy, or it can show only moderate activity while Friction and Capacity already look tight because the execution environment is saturated. That distinction follows directly from Ethereum’s gas mechanism and transaction model rather than from frontend storytelling.

This is why the page keeps chain profile, scorecard, drivers, and charts separate. The profile defines which metrics are meaningful; the scorecard compresses them into axis scores; the drivers reveal which fields currently dominate; and the charts show the time-series shape underneath. The website stays descriptive at every step: it does not convert execution pressure into return expectations.

This reading order mirrors the structure of the published data contract. Freshness and confidence are gating variables; regime is the compressed state output; scorecard is the axis-level decomposition; drivers are the ranked evidence rows; charts are the time-series visualization layer. In methodological terms, the page is arranged from contract-level validity checks to semantic compression to granular evidence.

The advanced reason for this order is to avoid a common analytical error: over-weighting the visual salience of a recent line move before establishing whether the visible row is timely, publish-eligible, and semantically well-supported. The charts contextualize the state; they do not define it.

The browser does not infer regime. It reads the canonical published label from meta.status.label, where the upstream pipeline has already combined axis conditions, chain profile rules, and the confidence gate. In other words, the visible label is an audited output of the meta layer, not a UI heuristic.

The regime vocabulary is a finite state set: STABLE, HEATING, CONGESTED, CHEAP, and UNKNOWN/DEGRADED. These states are meant to compress the chain’s location in a three-axis space defined by Demand, Friction, and Capacity, with the final label then constrained by publish-confidence eligibility. The confidence threshold is therefore part of the state machine: if confidence is below the canonical gate, the UI must treat the row as UNKNOWN/DEGRADED even when the raw axis pattern might otherwise resemble a named state.

The correct technical interpretation is: regime is a deterministic classification over the published meta payload, not a probability of future returns and not a recommendation class. The current label STABLE is a descriptive compression of the present chain state conditional on methodology version, chain profile, window, and confidence gate.

Confidence is a published meta-layer quantity in confidence.confidence_score. The UI never rebuilds it. It is used in two roles at once: first as an evidentiary score for how strongly the current descriptive row is supported, and second as a governance gate for whether the visible regime may remain a named state or must degrade to UNKNOWN/DEGRADED under the canonical threshold contract.

In the patched meta files, confidence is conceptually a synthesis of row usability and label support. The payload may expose component views such as data_quality_score and label_confidence_score; in the current row they are 1.000 and 0.434. The key question confidence answers is: “given the currently published row, how much descriptive weight should be placed on the label?”.

Technically, this is not a confidence interval, not a posterior probability, and not a forecast probability. It is a bounded support score on [0,1]. The current product contract uses a hard publish gate at 0.40: values below that threshold force degraded semantics, while values above it permit named states. The UI bands (Good / Caution / Degraded) are presentation tiers layered on top of the scalar. They do not replace the underlying number.

As-of is the temporal anchor of the visible row. The page surfaces the latest published date from the canonical meta bundle; it does not infer freshness from chart endpoints or browser time. In a reproducible system, every descriptive statement must be traceable to a concrete observation date, and as-of is that date-level binding.

The advanced reason this matters is that a regime label is only meaningful conditional on its information set. A label computed on one date and viewed later may be equally well-defined, but it is not equally current. This is why the product separates temporal recency (as-of and lag) from evidentiary support (confidence): they answer different questions and should not be collapsed into one omnibus quality number.

In practice, as-of is the date to use when reconciling the visible page against dataset manifests, daily published files, and any downstream audit. If a reader cannot pin the visible state to a concrete observation date, the state is not operationally traceable.

Lag is an operational freshness statistic measured in days from the latest published observation to “today” in the product’s UTC framing. It is not a reliability score and not a confidence penalty by itself. A low-lag row may still be weakly supported; a higher-lag row may still be internally coherent. The UI separates these concepts because conflating them would hide whether the issue is timeliness or evidentiary strength.

Formally, lag answers a scheduling question: how far is the visible row behind the current calendar? It should be read relative to the chain’s publish-lag policy, not in isolation. For BTC/ETH a 1-day lag is normal; for Base/Arbitrum a materially larger expected lag is part of the product contract. So the advanced user should interpret lag as a deviation from chain-specific publication cadence, not as a universal freshness threshold.

The reason lag belongs on the page is auditability. It makes it explicit whether the state is operationally current enough for the user’s purpose. It does not tell you that the label is wrong; it tells you whether the label is temporally up to date.

regime.determinism_hash is published for auditability: it is a hash over the input data and parameter context used to produce the regime/meta output. The UI does not derive it. Its presence is a reproducibility guarantee that the visible classification is tied to a specific upstream computational state rather than to local browser logic.

In a deterministic publishing pipeline, identical inputs under identical parameters should generate identical outputs. The hash is therefore not a user-facing score; it is a compact fingerprint of computational identity. If the hash changes while the displayed date, chain, and methodology context appear unchanged, a technical reader immediately knows that some relevant input or parameterization changed upstream.

The accompanying window-days field matters because regime and scorecard are windowed objects. A 7-day classification and a 30-day classification can be equally deterministic yet refer to different state definitions. So the proper advanced reading is the tuple (methodology version, chain profile, window, determinism hash), not the hash alone. Current hash: baa30e066fc9. Current window: 7.