A research note that cites a level takes on an obligation the note itself rarely acknowledges: the level has to still be there when someone checks. For price series that obligation is usually met, because exchange prints are final and the conventions for stamping them are old. For on-chain series it frequently is not, because a same-day reading is assembled from blocks that may still be reorganised, from an indexer that may still be backfilling, and from a methodology that may still be revised.
The control you want is a published finality window per metric: how many hours of this series remain provisional. I have to be direct about this. I cannot confirm that the panel publishes one. What the On-Chain tab shows is a health score of 84 labelled Very Strong, four component bars reading Hash Rate 100, Active Addr. 36, Tx Volume 100 and Miner Rev. 100, and a line naming the inputs. There is a Refresh control in the module header, which tells you when the display was pulled and not when the underlying data stopped moving. If the control you need is not on the surface you are reading from, the discipline has to be yours, and the rest of this is what that discipline looks like.
What the panel states and what it does not
Inventory first, because a research control starts with knowing what you have been handed. Stated on the tab: a composite on-chain score, a qualitative label, four named inputs, and a normalised bar per input. Not stated on the tab: an as-of timestamp, a block height or height range per metric, which chains are covered and in what proportion, the indexer's lag, and whether any of the four series is subject to restatement.
Every one of those absences is a question your compliance and research process would answer for a market data feed without thinking about it. There is a How It Works control on the panel and it is worth reading before anything gets quoted, but whatever it documents, the display itself carries none of the above, and a number lifted off a display carries the display's silence with it.
Three ways a same-day on-chain number changes under you
They have different causes, different time constants and different fixes, so treat them separately.
The first is chain-level non-finality. On chains with probabilistic settlement, a recent block is never formally final, only progressively less likely to be reorganised, and any metric computed over the last few blocks inherits that. On chains with an explicit finality gadget, blocks become final after a fixed number of consensus rounds, which gives you a hard boundary but also a real window before it during which a figure can change. Either way, the last stretch of the series is a different object from the rest of it, and the length of that stretch is a property of the chain, not of the vendor.
The second is indexer lag and backfill. Even after finality, the pipeline that turns blocks into metrics can be behind, can drop and re-ingest a range, or can complete a partial day later. This is usually the largest source of same-day revision and the least visible one, because the number does not look provisional. It looks like a number.
The third is methodology and label revision. A filter changes, an address cluster is reassigned, a chain is added to the coverage set, and the historical series moves with no market event behind it. This one is the most dangerous for attribution, because it can restate a period you have already reported on.
Measuring your own stabilisation window
Since the window is not published, measure it. The procedure is dull and it works.
Capture the panel's readings on a fixed schedule, several times a day, and keep every vintage rather than overwriting. Each stored row is metric, value, capture time, and the age of the underlying period being described. After a few weeks you can plot revision magnitude against age: for a given data date, how far does the reading move between its first appearance and its value a day later, three days later, a week later.
The age at which the revision magnitude drops inside your materiality threshold is your stabilisation window, and it is the number you were looking for. Do this per metric rather than per panel. A hash rate series, an address count and a revenue series come through different pipelines and there is no reason for them to settle at the same speed, and a composite settles no faster than its slowest input, which is a point worth making explicitly to anyone who wants to quote the headline score early.
One design note. Store the vintages in a table nobody can update in place, and store the capture time from your own clock rather than from anything on the page. The value of the exercise comes entirely from the fact that old readings are still recoverable, and a pipeline that upserts destroys exactly the evidence you are collecting.
What a note may cite, by the age of the data
Turn the measured window into a rule with three tiers, and make it a rule rather than a guideline, because the pressure to cite a fresh number is highest exactly when the number is least settled.
Inside the stabilisation window, a note may describe direction and may not cite a level. "On-chain activity has been strengthening through the week" is defensible. "The on-chain composite is at 84" with a same-day stamp is a hostage. If a level must appear inside the window, mark it provisional in the sentence itself, not in a footnote.
Outside the stabilisation window but inside your revision-history horizon, levels may be cited with an as-of stamp and a vintage reference. This is the normal case for weekly research.
For anything that feeds performance attribution, a client report or a track record, use only series that have passed your restatement check, which means the value has been stable across at least two consecutive vintages beyond the window. Attribution is the place where a silently revised input is most expensive, because the number has already been used to explain something to somebody.
The citation line, and what to do when it moves anyway
The line itself should be boring and complete: metric name, value, the data period it describes, the capture timestamp from your own clock, the vintage identifier, and the provisional flag if applicable. Six fields, one line, in every note that quotes an on-chain level. The cost of writing it is a few seconds and the benefit is that a challenge six months later is answered by a lookup rather than by a memory.
When a cited number does move after publication, and eventually one will, the handling is a policy question you should settle before it happens rather than during. Decide now whether a revision above your materiality threshold triggers a correction notice, who owns that decision, and where the corrected value is recorded. A desk that has that written down treats a revision as a process working. A desk that does not treats it as an incident, and the difference is visible to clients.