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.
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.
tx_count_dailyConfirmed daily transaction count.
block_count_dailyNumber of blocks produced that day.
value_transferred_nativeSum of transaction value moved that day, in the chain's native denomination.
median_tx_value_nativeTypical same-day transaction value in native denomination.
median_tx_fee_nativeTypical same-day transaction fee in native denomination.
failed_tx_rateShare of transactions that did not succeed.
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.
capacity_util_pct.unique_active_addressesCount of distinct addresses that sent or received a transaction that day.
tx_per_userratio (weight 0.6). Not used for Bitcoin's Demand axis, where tx_count_dailyalone is the methodology's chosen activity signal.avg_block_time_secTypical daily inter-block interval behaviour.
blocktime_instability component where that component is used by the chain profile.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.
sqrt(data_quality_score × label_confidence_score). The gate threshold remains 0.40.confidence.methodology_versionSpecific confidence methodology used for the row.
confidence_v2_profile_evidence for Confidence v2 rows.confidence.data_quality_scoreProfile-aware data completeness and freshness score.
confidence.label_confidence_scoreLabel-specific evidence clarity score.
confidence.candidate_labelThe label supported by the evidence before the confidence gate is applied.
confidence.components.data_quality.required_metricsChain-specific metric list used for data-quality coverage.
confidence.components.data_quality.structurally_not_applicableFields that do not belong in the chain-specific confidence denominator.
confidence.components.data_quality.optional_not_penalizedVisible fields that are not treated as required confidence inputs for the current chain profile.
confidence.components.label_confidence.uses_score_rawWhether label confidence was evaluated from raw scorecard evidence.
confidence.components.label_confidence.usedComponent values used inside the label-specific confidence calculation.
status.one_linerReadable public explanation of the current status.
status.explanation_support.status_noteMachine-readable copy source for nuanced status explanation.
regime.labelPublished descriptive state.
regime.determinism_hashCanonical public integrity anchor for named regime rows.
schemaBrief artifact schema identifier.
brief_statusPublication state for a Briefs JSON artifact.
window.updated_throughLatest date covered by the brief window.
regime_path.dominant_labelMost common regime label inside the brief window.
movement.typeReadable movement classification for the latest window.
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 after Confidence v2 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>.scoreClass APublished confidence-degraded display score for an axis.
score_raw and effective_confidence using the display-score formula below.scorecard.dimensions.<axis>.score_rawClass CRaw score before confidence degradation.
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.
scorecard.dimensions.friction.components.fee_burden_proxy.current is not a native fee amount. It is the current value of an internal friction proxy.
median_tx_fee_native / median_tx_value_nativeIts unit is a dimensionless ratio, not a native-denominated fee. It measures fee burden relative to transaction value, not fee size in isolation.
A friction score can be elevated even when absolute fees are not unusually high in native terms, because the friction component is based on fee burden relative to transferred value. Customers should read this field as a burden proxy rather than as a direct fee amount.
For BTC capacity interpretation, the capacity axis does not score raw block time directionally and does not combine with gas utilization. For BTC, blocktime_instability is the only capacity component.
|block_time - median30(block_time)| / median30(block_time)The field is then smoothed before scoring.
This means the BTC capacity score is not a direct measure of slow blocks only. It is a measure of unusual block-time behaviour around the recent norm in either direction. Customers should read BTC capacity as a stress-or-instability proxy, not as a directional slow-block indicator.
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.