BTC

BTC is treated as a UTXO-profile chain, so the explanatory surface is intentionally different from an EVM chain. The dominant descriptive questions are: how much confirmed block-space demand is present, how competitive are fees, and does block production look smooth or strained? That is why the page leans on transaction count, median fee, and block-time pacing rather than gas-utilization or failed-transaction fields, which do not carry the same semantics on Bitcoin.

Methodologically, this matters because the same top-line word such as “busy” can arise through different observables on different architectures. On Bitcoin, a hotter state often manifests as stronger competition for limited block space and less roomy confirmation conditions, whereas on Ethereum the same intuition may show up through gas usage and execution fees. The chain profile prevents false cross-chain equivalence by changing which metrics are even allowed to speak for Demand, Friction, and Capacity.

In product terms, BTC Demand tends to lean on confirmed throughput; Friction on fee pressure; Capacity on timing/throughput proxies such as average block time. The page is therefore not saying “Bitcoin has no capacity model”; it is saying the capacity model is proxied through the variables that actually make sense for a UTXO settlement network.

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 CONGESTED 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.803. 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: 2e91ef8edb16. Current window: 7.