A network dashboard is easiest to read when you know what each number measures and when it was collected. On BlakeStack, network statistics come from our Bitcoin BLAKE2b Knots node. The price chart comes from a separate exchange feed. Those sources have different update times and different limits.
Start with freshness, then read the chain tip, hashrate estimate, difficulty, block interval and mempool together. A change in one number rarely explains the whole network by itself.
Check observation freshness first
An observation records what our node reported at a particular time. It is separate from the timestamp of the latest block. A node can keep reporting a fresh view while no new block is found; the last block getting older does not automatically mean collection has failed.
BlakeStack marks network data stale after five minutes without a new observation, or when collection fails. A syncing node is shown separately. If you see a stale reading, interpret its values as the last recorded view and check the observation time before using them for a current comparison.
The sources and methodology describes this behavior. In the API, the corresponding information is in meta.status and meta.sampled_at.
Read height and recent blocks as a chain view
Block height identifies the position of the latest observed tip. It does not tell you how long a particular transaction has waited or prove that another service follows the same chain. For chain identification, check the BLAKE2b checkpoint described in our methodology.
Recent blocks show the canonical headers stored by BlakeStack. A reorganization can replace blocks at some heights. Identify a block by its hash when comparing records, and recheck the current canonical view if your analysis depends on it.
An unavailable field is not necessarily zero. Our initial collection can include headers without complete transaction, size or fee statistics. A dash preserves that distinction.
Treat hashrate as an estimate
The node's getnetworkhashps RPC estimates hashes per second from recent chain work and block timestamps. BlakeStack requests a window of up to 120 BLAKE2b blocks. The versioned Knots RPC implementation shows the calculation and default block window.
This is not a meter attached to every miner. Faster or slower blocks can move the estimate even without an equivalent instantaneous change in connected equipment. Nearby observations use overlapping sets of blocks, so many samples are not many independent measurements.
Read the unit as well as the value. One PH/s is one quadrillion hashes per second. A pool's own hashrate and a network estimate also describe different scopes; compare their windows and sources before using them together.
Keep difficulty in its BLAKE2b units
Difficulty expresses the proof-of-work target in the network's difficulty units. The value on BlakeStack is difficulty_blake2b. It is not the SHA256d difficulty displayed by a BTC explorer, and comparing the two numeric values does not establish relative mining power.
Knots 29.4.2 replaced the old difficulty fields where they no longer applied; its release notes describe that change. A large value shown in scientific notation is still a difficulty number, not a hashrate unit.
On the history page, difficulty is averaged inside each displayed time bucket. A bucket spanning a target change can therefore show a mean between the recorded values. Use individual observations when the precise transition matters.
Understand the average block interval
BlakeStack calculates the elapsed timestamp between the endpoints of up to 121 consecutive stored headers and divides it by the number of height intervals. There are 120 intervals between 121 consecutive blocks. If the required heights are missing or elapsed time is non-positive, the average is unavailable.
For a simple example, three consecutive headers spanning 1,200 seconds have two intervals and a mean interval of 600 seconds. Dividing by three would count the starting block as an extra interval.
Header timestamps are supplied by miners and can be irregular. This average is not a precise stopwatch of when BlakeStack received each block. Short windows are particularly noisy; a slow recent block is not enough to establish a lasting trend.
Read the mempool as a local observation
The mempool contains unconfirmed transactions visible to our node. Other nodes can see different transactions because their connections, relay policies and recent activity differ. A zero count means our node reported an empty mempool at that sample time, rather than proving nobody is trying to transact.
Transaction count and virtual size describe different things. A few large transactions can occupy more space than many small ones. Mempool size alone does not promise a confirmation time or determine a fee for your particular transaction.
Use history and reports for a specific question
The history page lets you select a UTC period, inspect coverage and download CSV or JSON. Dense views use time-bucket means. Null hashrate estimates are excluded from the mean, and empty buckets are omitted. Check sample counts alongside a smooth-looking chart: an average can hide missing samples inside a bucket.
Recorded hashrate history starts with our own collection. Earlier block headers do not supply earlier recorded hashrate observations, and exchange price history does not fill that gap.
For a worked example, the first observation report covers parts of 7–8 October 2026. It archives 2,572 node observations and 161 canonical block headers, with a mean recorded hashrate estimate of 45.06 PH/s. Its exact window, raw observations and timestamp limitations remain attached to the figures. Those numbers describe that captured period, not today's network.
A history URL fixes a query, while a dated report preserves its dataset. Use the report archive for a reproducible citation; use live history when you want newly collected observations and the current canonical view.
Keep the exchange chart separate
The headline price and chart follow the NeoxEX BTCB2_USDC market, displayed as XBT/USDC. This is one venue's USDC quote, not a USD conversion or a network statistic. Its freshness is evaluated independently of node collection.
When you next open the dashboard, check the two sources' timestamps, choose a meaningful window and ask whether the available observations support your question. That habit is more useful than treating every movement in a chart as a network event.