Use this page when you already know the field name and need the public meaning, unit semantics, verification class, and interpretation boundaries. For deeper system-level logic, use the Public Methodology Reference page.
Long field paths are shown in wrapping code blocks and cards rather than compact tables, so the page remains readable on laptop and mobile widths.
One date + chain row of normalized measurements such as transaction activity, fees, utilization, block cadence and chain-specific observational fields.
Use it for: inspecting the evidence beneath a classification or joining the underlying measurements directly.
MA7/MA30 transformations of the explicitly listed Gold metric set, plus source provenance back to Gold.
Use it for: analysis that needs smoothed features without rebuilding the same rolling calculations.
The daily regime, Demand/Friction/Capacity evidence, confidence, drivers, ruleset identifiers and determinism/provenance fields.
Use it for: the date + chain state row you integrate into an analytical system.
Human-readable window summaries generated from already published regime evidence.
Use it for: reporting and narrative context, not as a separate predictive model.
Each field card now states whether the field is a regime/scorecard input, a confidence input, observational context, a derived feature, or provenance. A field being delivered does not automatically mean it drives the regime label.
Every Gold field is derived from two raw tables per chain — blocks and transactions — sourced from the AWS Public Blockchain Dataset. Column names vary slightly across chains and over time; the pipeline resolves a prioritized list of known candidate names per concept (case-insensitive) before falling back to null rather than guessing.
Gold is the normalized daily observation layer. Null means unavailable/not applicable for that row; it must not be reinterpreted as zero.
tx_count_dailyConfirmed daily transaction count.
Why useful: Core activity volume and a primary Demand input.
Applies to: BTC · ETH · ARB · BASE
block_count_dailyNumber of blocks produced that day.
Why useful: Checks whether the daily block observation surface is sufficiently covered.
Applies to: BTC · ETH · ARB · BASE
value_transferred_nativeSum of transaction value moved that day, in the chain's native denomination.
Why useful: Adds transfer-volume context without changing the current regime label.
Applies to: Where source semantics are available
median_tx_value_nativeTypical same-day transaction value in native denomination.
Why useful: Shows the typical native-denominated transaction value; not a current regime driver.
Applies to: Where source semantics are available
median_tx_fee_nativeTypical same-day transaction fee in native denomination.
Why useful: Primary Friction evidence and the direct fee distribution used by current profiles.
Applies to: BTC · ETH · ARB · BASE
median_tx_fee_rate_sat_vbyteTypical Bitcoin transaction fee rate in satoshis per virtual byte.
Why useful: Lets Bitcoin users inspect fee-rate conditions independently of native fee amount.
Applies to: BTC only
(fee_BTC × 100,000,000) / virtual_size for valid transactions. Coinbase transactions are excluded when the source flag is available, and non-positive virtual sizes are ignored. The field is null for non-Bitcoin chains and does not yet drive the public regime label, scorecard, or confidence calculation while historical behaviour is being validated.median_tx_gas_usedTypical execution gas consumed by an Ethereum transaction that day.
Why useful: Provides Ethereum execution-intensity context beneath aggregate network state.
Applies to: ETH only
receipt_gas_used, with transaction-level gas_usedused only as a fallback when receipt gas is unavailable. Values are raw gas units, are null for non-Ethereum chains, and do not yet drive the public regime label, scorecard, or confidence calculation while historical behaviour is being validated.nonempty_calldata_shareShare of Ethereum transactions carrying non-empty calldata that day.
Why useful: Can corroborate an ETH HEATING classification when core Demand is already high.
Applies to: ETH only
input value is non-null and, after trimming, is neither an empty string nor 0x. The metric is published on a 0–1 scale, is null for non-Ethereum chains, and does not identify protocols, tokens, or user intent. Under eth_l1_v2, it is supplemental Demand evidence: it can support HEATING when core Demand is already HIGH/EXTREME_HIGH and calldata trend is HEATING. It is not a standalone Demand axis component in the public scorecard.contract_creation_tx_shareShare of Ethereum transactions that create a contract that day.
Why useful: Shows how much daily Ethereum activity consists of contract creation.
Applies to: ETH only
receipt_contract_address. It describes contract-deployment activity without identifying protocols, tokens, financial intent, or trading behaviour. Values are published on a 0–1 scale, are null for non-Ethereum chains, and do not yet drive the public regime label, scorecard, or confidence calculation while historical behaviour is being validated.eip1559_type2_tx_shareShare of Ethereum transactions using EIP-1559 dynamic-fee transaction type 2 that day.
Why useful: Tracks transaction-envelope adoption without inferring protocol or user intent.
Applies to: ETH only
transaction_type, with type as a schema-compatibility fallback. Numeric 2 and equivalent hex encodings such as 0x2 count as type 2. Values are published on a 0–1 scale, are null for non-Ethereum chains, and describe transaction-envelope adoption only; they do not identify protocols, tokens, financial intent, or trading behaviour. The field does not yet drive the public regime label, scorecard, or confidence calculation while historical behaviour is being validated.failed_tx_rateShare of transactions that did not succeed.
Why useful: Adds execution-failure burden to Ethereum Friction.
Applies to: ETH L1
median_tx_fee_native). Structurally not applicable for Bitcoin (no execution failures in the UTXO model) and currently presentation-hidden for Arbitrum and Base while L2 failure semantics are still being validated.gas_utilization_pctShare of a block's gas capacity actually used.
Why useful: Primary Ethereum Capacity proxy.
Applies to: ETH L1
capacity_util_pct.median_block_base_fee_per_gasTypical Ethereum protocol base fee per unit of gas across blocks produced that day.
Why useful: Shows the protocol-set Ethereum base gas price before priority fees.
Applies to: ETH only
base_fee_per_gas. It describes the protocol-set base price for gas before transaction-specific priority fees. Values are published in the raw chain unit from the source schema, are null for non-Ethereum chains, and do not yet drive the public regime label, scorecard, or confidence calculation while historical behaviour is being validated.block_gas_utilization_p9090th-percentile Ethereum block gas utilization for the day.
Why useful: Retains upper-tail Ethereum blockspace pressure that an average can hide.
Applies to: ETH only
gas_used / gas_limit ratio and reports the daily 90th percentile on a 0–1 scale. This complements the daily aggregate gas-utilization field by retaining upper-tail load information. It does not yet drive the public regime label, scorecard, or confidence calculation while historical behaviour is being validated.block_weight_utilization_pctAverage share of Bitcoin's maximum block weight used across blocks produced that day.
Why useful: Measures Bitcoin blockspace occupancy and contributes to Capacity pressure.
Applies to: BTC only
unique_active_addressesCount of distinct addresses that sent or received a transaction that day.
Why useful: Adds breadth of observed address activity; addresses are not equivalent to users.
Applies to: BTC classifier · ETH/L2 classifier + scorecard
tx_per_user (0.6); the BTC scorecard itself still usestx_count_daily as its sole Demand component. This counts addresses, not people or unique users.avg_block_time_secTypical daily inter-block interval behaviour.
Why useful: Feeds block-time instability and confirms expected block-cadence coverage.
Applies to: BTC · ETH · ARB · BASE
blocktime_instability evidence surface and is also a required data-quality field in current Confidence v3 profiles.These fields can appear in published Gold artifacts but are produced outside the canonical CANON_COLS aggregation surface. They are documented separately so the distinction remains explicit and auditable.
capacity_util_pctPublic L2 capacity-utilization observation used by the L2 methodology when available.
Why useful: Canonical public L2 Capacity field when available.
Applies to: ARB · BASE
l2_v1 profile. It is the canonical L2 Capacity input for regime classification, scorecard construction and Confidence v3 data-quality coverage. A null value means that observation is unavailable for the row; consumers should not reinterpret null as zero or spare capacity.arbitrum_l1_gas_used_dailyDaily L1 gas footprint associated with the Arbitrum data surface.
Why useful: Exposes Arbitrum L1 gas footprint as a delivered measurement without making it a regime driver.
Applies to: ARB only
base_l1_gas_used_dailyDaily L1 gas footprint associated with the Base data surface.
Why useful: Exposes Base L1 gas footprint as a delivered measurement without making it a regime driver.
Applies to: BASE only
Derived is deliberately simpler than Gold: it publishes reusable rolling features only for the metric set declared in each artifact's source metadata.
derived.metrics.<metric>__ma7Seven-day rolling mean of a published numeric Gold metric included by the Derived producer.
Why useful: Ready-to-join 7-day smoothing of a published Gold metric.
Applies to: Published Derived metric set
derived.metrics.<metric>__ma30Thirty-day rolling mean of the same published Gold metric.
Why useful: Ready-to-join 30-day smoothing for slower context and comparisons.
Applies to: Published Derived metric set
derived.source.gold_sha256SHA-256 link to the Gold input state used by the Derived artifact.
Why useful: Links a Derived artifact back to the exact Gold input state used to produce it.
Applies to: BTC · ETH · ARB · BASE
derived.source.metric_columnsExplicit list of Gold metrics included in that Derived build.
Why useful: States exactly which Gold columns were included in the Derived build.
Applies to: BTC · ETH · ARB · BASE
The same nine Gold metric fields are not used identically across chains. Each chain profile (BTC, ETH L1, L2) has its own Demand / Friction / Capacity component list, weights, and transform. This table mirrors PROFILE_COMPONENTS in the scoring engine directly, so documentation drift is caught by the field-dictionary sync gate.
| Chain profile | Demand | Friction | Capacity |
|---|---|---|---|
| Bitcoin / BTC |
|
|
|
| Ethereum L1 |
|
|
|
| Arbitrum / L2 |
|
|
|
| Base / L2 |
|
|
|
confidence.confidence_scoreTop-line confidence of the published analytical state.
Why useful: Helps downstream users decide how much weight to place on the published row.
Applies to: Meta
sqrt(data_quality_score × label_confidence_score). The gate threshold remains 0.40.confidence.methodology_versionSpecific confidence methodology used for the row.
Why useful: Identifies the exact confidence rules used for this row.
Applies to: Meta
confidence_v3_l2_capacity_required for current rows.confidence.data_quality_scoreProfile-aware data completeness and freshness score.
Why useful: Separates data sufficiency from label-evidence clarity.
Applies to: Meta
confidence.label_confidence_scoreLabel-specific evidence clarity score.
Why useful: Shows how clearly the evidence supports the candidate/published label.
Applies to: Meta
confidence.candidate_label.labelThe label supported by the evidence before the confidence gate is applied.
Why useful: Shows the pre-gate candidate when a stronger public label may be withheld.
Applies to: Meta
confidence.components.data_quality.required_metricsChain-specific metric list used for data-quality coverage.
Why useful: Makes the chain-specific confidence denominator inspectable.
Applies to: Meta
confidence.components.data_quality.structurally_not_applicableFields that do not belong in the chain-specific confidence denominator.
Why useful: Explains why non-applicable fields do not count as missing evidence.
Applies to: Meta
confidence.components.data_quality.optional_not_penalizedVisible fields that are not treated as required confidence inputs for the current chain profile.
Why useful: Shows which visible fields may be absent without reducing data quality.
Applies to: Meta
confidence.components.label_confidence.uses_score_rawWhether label confidence was evaluated from raw scorecard evidence.
Why useful: Confirms whether label confidence used raw rather than degraded display scores.
Applies to: Meta
confidence.components.label_confidence.usedComponent values used inside the label-specific confidence calculation.
Why useful: Exposes the label-specific components that entered confidence.
Applies to: Meta
status.one_linerReadable public explanation of the current status.
Why useful: Gives a concise human interpretation of the same published evidence.
Applies to: Meta
status.explanation_support.status_noteMachine-readable copy source for nuanced status explanation.
Why useful: Preserves machine-readable support for nuanced status copy.
Applies to: Meta
regime.labelPublished descriptive state.
Why useful: The daily network-state classification joined on date + chain.
Applies to: Meta
regime.determinism_hashCanonical public integrity anchor for named regime rows.
Why useful: Provides a canonical traceability anchor for a named regime row.
Applies to: Meta
schemaBrief artifact schema identifier.
Why useful: Identifies which Briefs schema a consumer is parsing.
Applies to: Briefs
brief_statusPublication state for a Briefs JSON artifact.
Why useful: Tells consumers whether a Briefs artifact was published normally.
Applies to: Briefs
window.updated_throughLatest date covered by the brief window.
Why useful: Prevents stale or differently lagged windows from being compared blindly.
Applies to: Briefs
regime_path.dominant_labelMost common regime label inside the brief window.
Why useful: Summarizes the most common descriptive state inside the brief window.
Applies to: Briefs
movement.typeReadable movement classification for the latest window.
Why useful: Summarizes whether the recent regime path is stable, shifting or degraded.
Applies to: Briefs
confidence.confidence_score is not a standalone judgement. It is the geometric mean of data quality and label confidence.
sqrt(data_quality_score × label_confidence_score)A row can therefore have perfect data quality and still have moderate confidence if the label evidence is thin, adjacent, or mixed.
confidence.components.data_quality.required_metrics lists the metrics that actually count toward coverage for this chain profile.
structurally_not_applicable fields are excluded from the denominator. optional_not_penalized fields remain visible but do not reduce confidence when absent.
A higher data_quality_score under Confidence v3 does not mean the model became more optimistic. It means the data-quality denominator now matches the evidence surface that is actually meaningful for that chain.
status.one_liner is the public readable explanation of the current state. For borderline stable rows it can now explicitly state that the scorecard shows adjacent pressure while the regime-axis evidence did not cross the threshold forHEATING, CHEAP, or CONGESTED.
The scorecard is a continuous descriptive surface. The regime label is a categorical thresholded state. They should be read together, but they are not identical. The status text is allowed to explain that distinction.
scorecard.dimensions.<axis>.score is the published confidence-degraded display score for an axis.
scorecard.dimensions.<axis>.scorePublished confidence-degraded display score for an axis.
Why useful: Continuous Demand/Friction/Capacity context after confidence degradation.
Applies to: Meta
score_raw and effective_confidence using the display-score formula below.scorecard.dimensions.<axis>.score_rawRaw score before confidence degradation.
Why useful: Preserves the pre-degradation axis score used in analytical interpretation.
Applies to: Meta
50 + (raw - 50) × effective_confidenceCustomers can fully verify the published display score from published row inputs. That does not mean the entire raw-score construction is fully reconstructable from public documentation alone.
regime.drivers[].z_robust is the driver-layer z-score published for a regime driver row. It is computed from 180-day raw daily values, not from the 7-day smoothed scorecard series.
Do not expect regime.drivers[].z_robust to numerically match a scorecard dimension score or the internal z-family behind that score. The driver z-score and the scorecard normalization use different input series, different windows, and different purposes.
Current BTC, Ethereum and L2 public Friction profiles use median_tx_fee_nativedirectly (with a log1p transform in the scorecard). Ethereum also includesfailed_tx_rate as a second Friction component.
fee_burden_proxy may still appear as a compatibility alias in some mapping metadata, but under the current production profiles it resolves tomedian_tx_fee_native; it is not the old fee/value ratio.
Consumers should interpret current Friction against the chain's own historical fee distribution, not as fee divided by transaction value. This keeps the Field Dictionary aligned with the current scorecard and regime engines.
For BTC capacity interpretation, the Capacity axis combines direct blockspace occupancy from block_weight_utilization_pct with blocktime_instability. Raw block time is not scored directionally, and BTC does not use gas utilization.
|block_time - median30(block_time)| / median30(block_time)The field is then smoothed before scoring.
BTC Capacity therefore combines blockspace occupancy with unusual block-time behaviour around the recent norm. High Capacity can veto CHEAP, but block-weight pressure alone does not create CONGESTED; simultaneous Friction pressure is also required by the BTC regime rule.
regime.label is a daily descriptive state, not a built-in multi-day stable segmentation layer.
Labels can change day to day in response to threshold crossings. This matters most for CONGESTED and CHEAP, which do not have a separate universal multi-day confirmation window. HEATING depends in part on a trend condition and therefore has a different stability profile. Customers who need multi-day regime stability should apply their own minimum-duration or smoothing rule.