Verification checklist
- Record the page or API last-updated time and subtract the latest RPC block timestamp to get page lag.
- Read the subgraph or adapter sync-head block, convert it to a timestamp, and get index lag.
- If index lag exceeds the metric’s claimed sampling interval, do not call the figure live on-chain; write “as of block N”.
- Store chain ID, RPC class, block hash and the raw query; do not splice another refresh into the same row.
1. Dashboard time is a product clock; block time is the ledger clock
In crypto project research, the screenshot that persuades is rarely the white paper. It is a board with a “Live” badge. The time string on that page usually comes from a front-end cache, a CDN, or an aggregator field such as last_updated on CoinGecko’s coin endpoint. That field answers: when did this product last write to its store. It does not answer: what is the timestamp of the latest block this chain’s nodes accepted.
The ledger clock is the timestamp from eth_getBlockByNumber with latest (or the chain’s equivalent). A one-minute gap can still be usable. A six-hour gap, written up as “current TVL”, wraps an expired snapshot as a live observation. My rule is: any claim of “current on-chain” must carry an RPC block number. “Current” without a block is copy.
2. A worked example: one “as of now”, three numbers six hours apart
Suppose a researcher screenshots a TVL board at 13:00 Beijing time. The page says it just updated; the figure is $1.20 billion. In the same minute, the underlying subgraph’s _meta.block timestamp corresponds to 07:00. A public RPC latest block timestamp is 13:00. Recomputing TVL at the subgraph head yields $0.98 billion. The table is hypothetical.
| Clock | Where it is read | Time | TVL | Lag versus RPC |
|---|---|---|---|---|
| Page clock | last-updated | 13:00 | $1.20bn | 0 min (product claim) |
| Index clock | subgraph sync head | 07:00 | $0.98bn | 360 min |
| Ledger clock | RPC latest block | 13:00 | not shown on the board | 0 min (baseline) |
The gap between 1.20 and 0.98 is not “the market rallied 22%”. The index may still be sitting on the morning print while the page keeps a fresh-looking label. Writing 1.20 into a note without a block height lets a reader treat a six-hour-old state as now. The correct sentence is: as of block N (07:00) TVL was $0.98bn; the board showed $1.20bn at 13:00; the index lagged 360 minutes; that display is not live on-chain state.
3. Read three clocks so a cache is not mistaken for consensus
Layer one is the page or official API update field, with its timezone written down. Layer two is the index head: Graph-style subgraphs expose block.number and block.timestamp via the GraphQL _meta query; adapter boards described in DefiLlama’s docs need their stated refresh interval, not a CSS pulse. Layer three subtracts from the RPC latest timestamp: page lag = dashboard time − block time; index lag = block time − sync-head time. Sign must be explicit: a trailing index is positive; a page clock ahead of the block is suspicious (often an uncalibrated laptop clock).
Checking only the page clock is not enough. A CDN can serve six-hour-old JSON with a new Date header. Without the sync-head block you cannot tell whether deposits and withdrawals in those six hours entered the number. Note whether the RPC is self-hosted, paid, or a public rate-limited endpoint: public latest can lag a few blocks or sit on a short fork. Recording the endpoint class stops node lag being written up as protocol failure.
4. A screen: lag must not exceed the metric’s own sampling interval
Acceptable staleness is not the same for a second-level funding rate, a 15-minute TVL adapter and a daily market-cap close. The teaching screen is: index lag ≤ the source’s publicly claimed sampling interval. If the docs say the adapter runs every 15 minutes and _meta shows a 360-minute trail, 15/360≈0.04, far from the same order of magnitude. Mark that TVL as failing a live check and demote it to a historical snapshot.
0.04 is not a regulatory standard. It is only a reproducible ratio for “are claimed frequency and measured frequency in the same ballpark?” It does not cover missed vault types, double-counted bridged TVL, or a lagging price oracle. Those are methodology issues for a separate check. Passing the clock check also does not prove the figure is right; it only proves you measured that moment’s index rather than an anonymous cached page.
5. Keep a record another researcher can replay
A minimum record includes Beijing (or UTC) time of the screenshot or request, board URL, raw last-updated text, chain ID, RPC block number and hash, sync-head block and timestamp, metric name and unit, both lags in minutes, and whether they exceed the claimed interval. For GraphQL, store the query string; for REST, store the time field in the response rather than typing “now” into a sheet.
Reconcile in a fixed order: RPC block, then index head, then page label. Any remainder the sampling interval cannot explain belongs in unexplained lag. Unexplained is not an accusation of fabrication; it is a ban on writing the remainder into a “verified live on-chain metric”. If a paid node or a paid analytics seat is required to read latest stably, record that source grade so one jittery public RPC cannot dismiss the whole table.
6. “Current” without a block number is copy
The scarce skill in crypto research is not a sharper crop of a dashboard. It is refusing to let product copy stand in for the ledger. A useful sentence is not “TVL is now X”. It is “RPC block N at T1; the index head lags D minutes; the board shows X with page clock T0”. Until D is measured, using X to narrate “capital just moved” turns cache delay into a market view.
This is a research framework with hypothetical calculations, not a quality opinion on any data vendor or protocol, and not investment advice.