URD ATLAS
StatusTrack RecordThresholdsGlossaryFAQAPI DocsMethodology
Account
ChainsStatusTrack RecordThresholdsGlossaryFAQAPI DocsMethodology
Account
© 2026 Urd Atlas.
AboutTermsPrivacy
No price data · No forecasts · No recommendations
Historical record

Track Record

A public log of every regime label and confidence score this product has published, day by day. What you see here is what was actually published — not reconstructed, not adjusted, not a backtest.

Published days
544
since inception
Archive rows
544
visible rows
First published
2024-12-01
Latest published
2026-05-28
What is this page? →Interpretation boundary →Methodology →
On this page
Archive summaryFiltersRegime mixTimelineConfidenceTransitionsFull table
Since inception

Public archive summary

The interactive views below focus on 30d and 90d windows for quick analysis. This summary shows the longer publication record behind the product.

₿
Bitcoin
BTC
544
Published days
First 2024-12-01
Latest 2026-05-28
Filters
All chainsBitcoinEthereumArbitrumBase
30d90d
Export CSV →

What is the Track Record page?

A plain-language and technical explanation of what you are looking at.
×
Basic

The Track Record page shows you the history of what this site actually published about each blockchain — day by day, going back through the available data. Every row in the table is a real published label from a real date. Nothing has been adjusted or reconstructed after the fact.

Think of it like an archive of daily weather reports. You can go back and see what the "forecast" said on any given day. You can see whether a network spent most of the last three months in a STABLE state or was frequently HEATING. You can see whether the labels were well-supported by data or whether confidence was often low.

This matters because it lets you judge the product honestly. If you see that Ethereum was labelled HEATING for three weeks before fees visibly spiked, that is useful context. If you see that confidence was consistently Degraded during a period when the labels looked strong, you know to treat those labels more cautiously.

The page does not tell you what to do with this history. It shows you what was published, clearly and without editorialising.

Advanced

The Track Record page renders the canonical published history bundles for each chain — specifically the meta/<chain>/last90d.json artifacts. These are immutable published outputs of the regime classification pipeline, not recomputed or retroactively adjusted values. Each row corresponds to a single daily meta artifact identified by its as-of date, methodology_version, and determinism hash where applicable.

The page serves three analytical functions. First, it provides a regime frequency distribution over the selected window, which characterises the base-rate of each state for a given chain and period. This is the appropriate denominator for evaluating how unusual any current regime reading is. Second, the regime timeline and confidence history visualisations expose persistence and transition structure — how long regimes lasted, how often they flipped, and whether confidence was systematically lower in certain regimes. Third, the transition matrix quantifies the empirical regime transition probability distribution under the current methodology, which is directly relevant for any regime-conditional strategy development.

Cross-chain regime mix

What the stacked bars show and how to read them.
×
Basic

The stacked bars give you a quick visual summary of how the last 90 days of published labels break down across regime types. Each coloured segment represents a portion of the total published days.

A long green segment means the network spent most of that period in a STABLE state. A long yellow segment means it was frequently HEATING. The lengths of the segments are proportional to how many published days fell into each regime — they are not a forecast of what comes next.

The most useful thing to notice is the proportion of degraded days. If a large share of the published window is grey (UNKNOWN/DEGRADED), it means the data quality was insufficient to support a named label for much of that period. That context matters when you are trying to use historical labels to understand a chain's typical behaviour.

This is a descriptive summary — it tells you what was published, not what was happening in markets or prices.

Advanced

The regime mix bars are a frequency distribution of published regime labels over the selected window, expressed as a proportion of total published rows. Each segment width is count(regime) / total_rows for that chain and window. The "other" bucket captures any non-canonical labels that survived the pipeline without mapping to a standard vocabulary member — in a well-functioning pipeline this should be near zero.

Reading the frequency distribution analytically: the regime mix is the empirical base rate of each state under the current methodology. If STABLE accounts for 70% of published days on Ethereum over 90 days, that is the empirical prior probability of seeing STABLE on any randomly selected day in that window. This is directly useful for calibrating how unusual a current HEATING or CONGESTED reading is relative to recent history.

Regime Timeline

How to read the sequential label history.
×
Basic

The regime timeline shows each published day as a coloured block, ordered from oldest to newest. Each block's colour represents the regime label for that day — green for STABLE, yellow for HEATING, red for CONGESTED, grey for UNKNOWN/DEGRADED.

The most important thing to look for is runs of the same colour. A long stretch of green blocks means the network was consistently STABLE across many published days — that is persistence. A rapid mix of different colours suggests the network was transitioning frequently, or that data quality was variable.

Persistence matters because a regime that lasts for three weeks is much more meaningful than one that appears for a single day and then disappears. The timeline lets you see this pattern directly without having to read through a table of dates.

Advanced

The regime timeline is a sequential visualisation of published label assignments, ordered ascending by as-of date. Its primary analytical utility is in exposing regime persistence and transition timing — properties that are invisible in aggregate frequency distributions but structurally important for understanding how the classification behaves in practice.

Two properties are worth inspecting analytically. First, run length: how many consecutive days a given regime label persisted before transitioning. Long runs in a single regime indicate structural stability in the underlying metric space; short alternating runs may indicate the chain is near a classification boundary, where small metric movements flip the label without implying a genuine regime change. Second, the timing of transitions relative to confidence trajectory: if a transition from STABLE to HEATING coincides with a visible improvement in confidence score, it is more likely to reflect a genuine evidence shift than a noise-driven boundary crossing.

Grey blocks (UNKNOWN/DEGRADED) in the timeline should be read as data voids, not as genuine regime labels. Their presence disrupts run-length inference for the adjacent named regimes — a run of STABLE days interrupted by a grey block does not necessarily imply a genuine transition to a new state; it may simply reflect a temporary data quality failure.

Confidence History

How the evidence strength behind published labels changed over time.
×
Basic

The confidence history chart shows how strong the data support was for each published label, day by day. The confidence score runs from 0 to 1 — higher is better supported.

The three horizontal bands help you read the chart quickly:

  • Above 0.70 — Good. The label is well-supported. Read it normally.
  • Between 0.40 and 0.70 — Caution. The label is published but with reduced certainty. The scorecard scores were pulled toward neutral on these days.
  • Below 0.40 — Degraded. The label is UNKNOWN/DEGRADED. The data was not sufficient to support a named regime.

Periods where the line stays consistently above 0.70 mean the historical labels in that window are the most reliable. Periods where it dips below 0.40 frequently mean you should treat the labels from those periods with extra caution.

Advanced

The confidence history chart exposes the temporal trajectory of the evidence-strength scalar over the selected window. It is the appropriate quality-weighting layer for any analysis that uses the historical regime labels — labels from high-confidence periods are more epistemically trustworthy than those from low-confidence periods, even if the labels themselves are identical.

Three structural patterns are analytically informative. Persistent low confidence across a chain for an extended period typically indicates a systematic data availability problem — either AWS source data was incomplete, or a metric space change affected coverage. Sudden drops in confidence that recover quickly may indicate transient data quality events. Confidence that is systematically lower for one chain than others in the same period may reflect chain-specific reporting delays or metric coverage differences.

For backtesting purposes, the confidence score is a necessary weighting factor. A naive backtest that treats all regime labels equally regardless of their confidence score will overweight UNKNOWN/DEGRADED periods (where no useful signal exists) and underweight high-confidence periods (where the signal is strongest). The correct approach is to condition the backtest on confidence band — ideally restricting analysis to rows where confidence exceeds the publication floor of 0.40, or better, restricting to the Good band (≥ 0.70) for highest-quality signal extraction.

Transition Matrix

How often the published regime changed from one state to another.
×
Basic

The transition matrix shows how often the published regime moved from one state to another on consecutive days. Each cell tells you: given that yesterday's label was X, how often did today's label become Y?

For example, if the STABLE → HEATING cell shows a count of 8, it means that out of all the days where the network was published as STABLE, it transitioned to HEATING on 8 consecutive days within the selected window.

The diagonal — cells where the regime stayed the same — tells you how often each regime was persistent. A large number in the STABLE → STABLE cell means STABLE was a sticky state: once the network entered it, it tended to stay there for multiple days.

This is useful for understanding the rhythm of the network. If CONGESTED → STABLE transitions are common, it suggests congestion periods are typically short. If HEATING → CONGESTED is rare, it suggests HEATING rarely escalates to full congestion in the historical data.

Advanced

The transition matrix is an empirical first-order Markov transition count table over the published daily regime sequence, computed per chain and then aggregated across chains for the selected window. Each cell M[i][j] contains the count of consecutive day-pairs where the regime transitioned from state i to state j. The diagonal M[i][i] counts self-transitions (regime persistence).

Dividing each row by its row sum gives the empirical transition probability matrix — the maximum-likelihood estimator of the transition probability under a first-order Markov assumption. This is the appropriate object for any regime-conditional strategy development: if you want to know the historical probability that HEATING is followed by CONGESTED, normalise the HEATING row and read off the CONGESTED column.

Two methodological caveats apply. First, UNKNOWN/DEGRADED transitions contaminate the matrix in a non-trivial way. A STABLE → UNKNOWN/DEGRADED → HEATING sequence is recorded as two separate transitions (STABLE→DEGRADED and DEGRADED→HEATING), not as one STABLE→HEATING transition. If degraded periods are frequent, the transition matrix will overstate the centrality of UNKNOWN/DEGRADED as a hub state and understate direct transitions between named regimes. Filtering to high-confidence rows before computing the matrix is the appropriate correction. Second, the matrix pools transitions across all four chains when "all chains" is selected, which implicitly assumes chain homogeneity in transition dynamics — an assumption that may not hold, particularly between L1s and L2s.

Historical regime table

What each column in the table means and how to interpret the rows.
×
Basic

Each row in the table represents one published day for one chain. Here is what each column tells you:

  • Date — the calendar date the row represents.
  • Chain — which blockchain the row is for.
  • Regime — the published label for that day: STABLE, HEATING, CONGESTED, CHEAP, or UNKNOWN/DEGRADED.
  • Confidence — how well-supported the label was by the available data. 0 to 1, where higher is better.
  • Band— a shorthand for confidence: Good (≥ 0.70), Caution (0.40–0.69), or Degraded (< 0.40).
  • Lag — how many days old the data was relative to today when it was published. Usually 1 for Bitcoin and Ethereum, 7 for Arbitrum and Base.
  • As of — the exact date the data describes. This can differ slightly from the Date column in edge cases.
  • Methodology — the version of the model that produced this label. If methodology changed between rows, the labels are not directly comparable.
  • Published context — methodology version, updated-through, and named-row determinism hash where applicable.
Advanced

The table renders a chronologically ordered slice of the published meta history bundle. Each row is a daily Meta artifact identified publicly by chain, date, methodology_version, and named-row determinism hash where applicable. Historical corrections should be understood through public revision notices and dataset-level provenance, not through a single required integer field.

The methodology_version field is the critical comparability boundary. Rows with different methodology versions were produced under different classification rules and potentially different threshold parameters — naive comparison across a methodology version change boundary will conflate genuine network state changes with classification rule changes. The methodology changelog at documents all version transitions.

How archived rows are identified

Public provenance uses the fields actually present in the archive.
×
Basic

Archived rows are identified publicly by chain, date, and methodology_version. Named regime rows add regime.determinism_hash as the public integrity anchor.

This means you do not need a separate revision integer to verify that two people are looking at the same archived named regime row.

Advanced

Public provenance should be read through methodology_version, updated_through, dataset revision or publication batch context, and determinism_hash where applicable. This is the canonical public provenance model for archived Meta outputs.

For reproducibility auditing, record the public identity tuple for the row in question, retrieve the same published artifact, and verify the determinism hash for named regime rows.

Traceability
  • Fields: chain, date, methodology_version
  • Named rows: regime.determinism_hash
  • See also: /methodology/provenance

Interpretation boundary on this page

What this historical data is and is not.
×
Basic

Everything on this page is a record of what was actually published on each day. It is not a backtest, not a reconstruction, and not a trading signal.

A common mistake is to look at a period where a network was labelled HEATING and then look at what happened to prices afterwards and draw conclusions. This page does not support that kind of analysis because it deliberately does not include price data. Whether HEATING correlates with price movements is a separate research question that you would need to answer with your own price data.

What this page does support: understanding how often each network is in each state, how persistent those states tend to be, how the transition between states works, and whether the evidence quality was consistent or variable across the period you are looking at.

Advanced

The interpretation boundary on this page is an extension of the product-level boundary: no price data, no forecasts, no advisory outputs. In the context of historical regime data, this boundary has an additional specific implication — the track record must not be treated as a backtested strategy performance record.

The regime labels published here are descriptive outputs of the meta layer at each date. They do not constitute signals in the trading strategy sense because: (1) they were not generated with a particular return objective in mind; (2) they are point-in-time published outputs that were available with a 1-7 day lag, not forward prices; and (3) the classification rules were not optimised against any outcome variable. Using these labels as the basis of a claimed backtest without those caveats would be methodologically inappropriate.

The legitimate analytical uses of this data are: regime frequency analysis, persistence and transition characterisation, confidence quality assessment, methodology version impact analysis, and — combined with independently sourced price or flow data — exploratory correlation research with appropriate statistical caveats.

Stable rows
42
47% of window
Heating rows
20
22% of window
Congested rows
8
9% of window
Degraded rows
0
0% of window

These counts show how many published rows in the selected 90-day window fell into each regime bucket. They describe frequency of published labels, not whether one regime is better or worse than another.

Distribution

Cross-chain regime mix

More →

Stacked bars show how often each published regime appeared in the selected window. Longer segments mean more published days in that state.

Overall — all visible chains
Aggregate across the selected chain for the last 90 published daily rows
Total rows: 90
Stable42 (47%)
Heating20 (22%)
Congested8 (9%)
Unknown / Degraded0 (0%)
₿
Bitcoin
BTC
Rows: 90Full history →
Stable42 (47%)
Heating20 (22%)
Congested8 (9%)
Unknown / Degraded0 (0%)
Source: meta/bitcoin/last90d.json
Sequential view

Regime Timeline

More →

Each block is one published day. Look for long runs of the same colour — they show persistence. Frequent colour changes show instability or transitions.

This bar shows the sequence of published daily regime labels inside the selected window. It is a descriptive timeline of what the product published on each date. Long same-color stretches indicate regime persistence; short stretches indicate faster turnover.
STABLEHEATINGCONGESTEDCHEAPUNKNOWN/DEGRADED
2026-02-282026-05-28
Rows correspond to published chronological entries in the current view.
RegimeFromToRows
STABLE2026-02-282026-03-078
CHEAP2026-03-082026-03-081
STABLE2026-03-092026-03-124
CONGESTED2026-03-132026-03-131
STABLE2026-03-142026-03-152
CONGESTED2026-03-162026-03-183
STABLE2026-03-192026-03-213
CHEAP2026-03-222026-03-221
HEATING2026-03-232026-03-231
STABLE2026-03-242026-03-241
HEATING2026-03-252026-03-251
CHEAP2026-03-262026-03-272
HEATING2026-03-282026-03-292
CHEAP2026-03-302026-04-013
STABLE2026-04-022026-04-043
CHEAP2026-04-052026-04-051
STABLE2026-04-062026-04-061
HEATING2026-04-072026-04-082
CONGESTED2026-04-092026-04-091
STABLE2026-04-102026-04-112
CHEAP2026-04-122026-04-143
STABLE2026-04-152026-04-151
CHEAP2026-04-162026-04-161
HEATING2026-04-172026-04-171
CHEAP2026-04-182026-04-214
STABLE2026-04-222026-04-232
CHEAP2026-04-242026-04-263
STABLE2026-04-272026-04-271
CHEAP2026-04-282026-04-281
STABLE2026-04-292026-05-0810
HEATING2026-05-092026-05-113
STABLE2026-05-122026-05-121
HEATING2026-05-132026-05-164
STABLE2026-05-172026-05-182
HEATING2026-05-192026-05-202
STABLE2026-05-212026-05-211
HEATING2026-05-222026-05-254
CONGESTED2026-05-262026-05-283
Confidence over time

Confidence History

More →

Confidence score plotted day by day. Low confidence periods show when the evidence base was insufficient for a strong label.

Confidence History
Evidence support for the published daily label over time.
Avg: 0.79 · Latest: 0.585 · usable with caution
This chart does not show whether a past label later proved correct. It shows how much published evidence supported the label on each day. The dashed line at 0.40 is the canonical floor below which the state should be read as UNKNOWN/DEGRADED.
0.70 stronger support0.40 degraded floor0.000.250.500.751.00May 28May 6Apr 13Mar 22Feb 28
How to read the bands: above 0.70 means stronger published support; 0.40–0.70 means usable but read cautiously; below 0.40 means evidence is too weak for a normal-confidence published state.
Source: meta.confidence.confidence_score
Regime transitions

Transition Matrix

More →

How often does each regime transition to each other regime? Rows are the "from" state, columns are the "to" state.

Regime Transition Matrix
Row = from regime · Column = to regime · Count of day-to-day published label transitions
A large diagonal value means the same regime tended to persist from one published day to the next. A larger off-diagonal value means the product more often switched from one regime into another specific regime. This is descriptive only.
STABLEHEATINGCONGESTEDCHEAPUNKNOWN/DEGRADED
From ↓ / To →STABLEHEATINGCONGESTEDCHEAPUNKNOWN/​DEGRADEDTotal
STABLE27627—42
HEATING41123—20
CONGESTED3—4——7
CHEAP73—10—20
UNKNOWN/​DEGRADED——————
Diagonal (italic): product stayed in the same published regime on consecutive days.
Off-diagonal: specific regime switches, e.g. STABLE → HEATING or HEATING → CONGESTED.
Total transitions: 89
Row-level data

Historical table

More →
Export CSV →
DateChainRegimeConfidenceBandLagAs ofVersionRevision
2026-05-28₿BTCCONGESTED0.896Good1d2026-05-281.110018764
2026-05-27
Displayed rows: 90 · Source: meta/bitcoin/last90d.json
Related
Chains
Current regime for each network
Status
Pipeline and freshness health
Methodology
How labels are computed
Glossary
Definitions for every term
Data contract and traceability
History bundles: data/published/v1/meta/bitcoin/last90d.json
30d / 90d refers to published daily rows per visible chain, not calendar months of recomputed history.
Since-inception coverage is taken from the per-chain published manifest, while the interactive visual layer reads the canonical 30d / 90d history bundles for speed.
Public provenance model: date · updated_through · methodology_version · dataset revision · regime.determinism_hash

A critical interpretive caveat: historical confidence scores are evidence-strength measures attached to the published label on each date — they are not posterior probabilities of persistence, and they should not be interpreted as such. A row with confidence 0.85 does not mean the regime had an 85% probability of continuing; it means the published evidence on that date strongly supported the assigned label. The distinction matters for anyone attempting to build probabilistic models over this data.

Traceability
  • Source: meta/<chain>/last90d.json
  • Fields: status.label · confidence.confidence_score · methodology_version · regime.determinism_hash

A high UNKNOWN/DEGRADED frequency is a data-quality diagnostic signal, not just a missing-data artefact. It indicates that the confidence gate fired frequently — meaning the underlying evidence surface was persistently thin, inconsistent, or incompletely covered. This can arise from AWS data availability issues, chain-specific reporting delays, or genuine instability in the metric space during that period. In either case, the presence of many degraded rows should reduce the interpretive weight placed on the non-degraded labels in the same window.

Traceability
  • Segment width: count(label) / total_rows
  • Source: status.label per published daily row
  • Window: last 90 published rows per chain
Traceability
  • Source: status.label per row, ordered by date ascending
  • Confidence overlay from confidence.confidence_score
Traceability
  • Source: confidence.confidence_score per row
  • Bands: Good ≥ 0.70 · Caution 0.40–0.69 · Degraded < 0.40
Traceability
  • Built from consecutive day pairs ordered by date ascending, per chain
  • Source: status.label per published row
  • UNKNOWN/DEGRADED treated as a distinct state in transition counting
/methodology/changelog

The lag field deserves careful handling. A lag of 1 means the published row describes yesterday's network state. A lag of 7 (normal for ARB/BASE) means the row describes the state from a week ago. For any time-series analysis over this data, the correct temporal coordinate is the as_of date (the observation date), not the publication date. Using the publication date as the time index will introduce a systematic lag bias into any event study or regime-conditional analysis.

Traceability
  • Source: meta/<chain>/last90d.json
  • Row identifier: (chain, date, methodology_version, determinism_hash where applicable)
  • Temporal coordinate for analysis: as_of date, not publication date
₿
BTC
CONGESTED
0.919
Good
2d
2026-05-27
1.1
98091580
2026-05-26₿BTCCONGESTED0.891Good3d2026-05-261.170176582
2026-05-25₿BTCHEATING0.973Good4d2026-05-251.193881070
2026-05-24₿BTCHEATING0.918Good5d2026-05-241.116763261
2026-05-23₿BTCHEATING0.963Good6d2026-05-231.170723059
2026-05-22₿BTCHEATING0.955Good7d2026-05-221.117903655
2026-05-21₿BTCSTABLE0.665Caution8d2026-05-211.192168962
2026-05-20₿BTCHEATING0.941Good9d2026-05-201.190787711
2026-05-19₿BTCHEATING0.916Good10d2026-05-191.155476675
2026-05-18₿BTCSTABLE0.491Caution11d2026-05-181.155191510
2026-05-17₿BTCSTABLE0.471Caution12d2026-05-171.181241805
2026-05-16₿BTCHEATING0.943Good13d2026-05-161.188280250
2026-05-15₿BTCHEATING0.934Good14d2026-05-151.169012870
2026-05-14₿BTCHEATING0.962Good15d2026-05-141.1105616
2026-05-13₿BTCHEATING0.936Good16d2026-05-131.161628066
2026-05-12₿BTCSTABLE0.517Caution17d2026-05-121.196665775
2026-05-11₿BTCHEATING0.984Good18d2026-05-111.175591891
2026-05-10₿BTCHEATING0.981Good19d2026-05-101.11323284
2026-05-09₿BTCHEATING0.982Good20d2026-05-091.149782334
2026-05-08₿BTCSTABLE0.492Caution21d2026-05-081.135341584
2026-05-07₿BTCSTABLE0.524Caution22d2026-05-071.198502879
2026-05-06₿BTCSTABLE0.538Caution23d2026-05-061.138044115
2026-05-05₿BTCSTABLE0.569Caution24d2026-05-051.120941844
2026-05-04₿BTCSTABLE0.568Caution25d2026-05-041.192933297
2026-05-03₿BTCSTABLE0.512Caution26d2026-05-031.14362110
2026-05-02₿BTCSTABLE0.589Caution27d2026-05-021.161372663
2026-05-01₿BTCSTABLE0.617Caution28d2026-05-011.190396647
2026-04-30₿BTCSTABLE0.639Caution29d2026-04-301.129059484
2026-04-29₿BTCSTABLE0.503Caution30d2026-04-291.155996637
2026-04-28₿BTCCHEAP0.912Good31d2026-04-281.141543647
2026-04-27₿BTCSTABLE0.610Caution32d2026-04-271.133333063
2026-04-26₿BTCCHEAP0.932Good33d2026-04-261.123756191
2026-04-25₿BTCCHEAP0.929Good34d2026-04-251.137143906
2026-04-24₿BTCCHEAP0.921Good35d2026-04-241.125155792
2026-04-23₿BTCSTABLE0.576Caution36d2026-04-231.141675718
2026-04-22₿BTCSTABLE0.460Caution37d2026-04-221.117906253
2026-04-21₿BTCCHEAP0.918Good38d2026-04-211.142770537
2026-04-20₿BTCCHEAP0.930Good39d2026-04-201.193269218
2026-04-19₿BTCCHEAP0.942Good40d2026-04-191.130917701
2026-04-18₿BTCCHEAP0.942Good41d2026-04-181.189911263
2026-04-17₿BTCHEATING0.918Good42d2026-04-171.154877837
2026-04-16₿BTCCHEAP0.945Good43d2026-04-161.181305476
2026-04-15₿BTCSTABLE0.630Caution44d2026-04-151.170804601
2026-04-14₿BTCCHEAP0.952Good45d2026-04-141.155783858
2026-04-13₿BTCCHEAP0.953Good46d2026-04-131.165947876
2026-04-12₿BTCCHEAP0.952Good47d2026-04-121.148486205
2026-04-11₿BTCSTABLE0.509Caution48d2026-04-111.191556705
2026-04-10₿BTCSTABLE0.522Caution49d2026-04-101.183672092
2026-04-09₿BTCCONGESTED0.806Good50d2026-04-091.184411388
2026-04-08₿BTCHEATING0.905Good51d2026-04-081.190439767
2026-04-07₿BTCHEATING0.901Good52d2026-04-071.17066134
2026-04-06₿BTCSTABLE0.507Caution53d2026-04-061.185011769
2026-04-05₿BTCCHEAP0.957Good54d2026-04-051.141832779
2026-04-04₿BTCSTABLE0.683Caution55d2026-04-041.190301433
2026-04-03₿BTCSTABLE0.671Caution56d2026-04-031.129992
2026-04-02₿BTCSTABLE0.580Caution57d2026-04-021.140309616
2026-04-01₿BTCCHEAP0.947Good58d2026-04-011.191010116
2026-03-31₿BTCCHEAP0.922Good59d2026-03-311.138244501
2026-03-30₿BTCCHEAP0.955Good60d2026-03-301.196337024
2026-03-29₿BTCHEATING0.961Good61d2026-03-291.11174542
2026-03-28₿BTCHEATING0.967Good62d2026-03-281.110517401
2026-03-27₿BTCCHEAP0.947Good63d2026-03-271.173573237
2026-03-26₿BTCCHEAP0.942Good64d2026-03-261.125417251
2026-03-25₿BTCHEATING0.925Good65d2026-03-251.166924702
2026-03-24₿BTCSTABLE0.726Good66d2026-03-241.168982062
2026-03-23₿BTCHEATING0.942Good67d2026-03-231.142479876
2026-03-22₿BTCCHEAP0.947Good68d2026-03-221.149982854
2026-03-21₿BTCSTABLE0.810Good69d2026-03-211.166720461
2026-03-20₿BTCSTABLE0.729Good70d2026-03-201.198437094
2026-03-19₿BTCSTABLE0.644Caution71d2026-03-191.154957608
2026-03-18₿BTCCONGESTED0.944Good72d2026-03-181.14188738
2026-03-17₿BTCCONGESTED0.923Good73d2026-03-171.130967935
2026-03-16₿BTCCONGESTED0.922Good74d2026-03-161.168952659
2026-03-15₿BTCSTABLE0.626Caution75d2026-03-151.148965062
2026-03-14₿BTCSTABLE0.658Caution76d2026-03-141.185815111
2026-03-13₿BTCCONGESTED0.890Good77d2026-03-131.11152129
2026-03-12₿BTCSTABLE0.776Good78d2026-03-121.167766852
2026-03-11₿BTCSTABLE0.820Good79d2026-03-111.119810606
2026-03-10₿BTCSTABLE0.805Good80d2026-03-101.16691501
2026-03-09₿BTCSTABLE0.803Good81d2026-03-091.158017853
2026-03-08₿BTCCHEAP0.914Good82d2026-03-081.176350553
2026-03-07₿BTCSTABLE0.754Good83d2026-03-071.184490133
2026-03-06₿BTCSTABLE0.852Good84d2026-03-061.165028299
2026-03-05₿BTCSTABLE0.730Good85d2026-03-051.188755566
2026-03-04₿BTCSTABLE0.726Good86d2026-03-041.12171855
2026-03-03₿BTCSTABLE0.798Good87d2026-03-031.198159661
2026-03-02₿BTCSTABLE0.743Good88d2026-03-021.122208141
2026-03-01₿BTCSTABLE0.592Caution89d2026-03-011.170272188
2026-02-28₿BTCSTABLE0.585Caution90d2026-02-281.17498398