Tracking depth changes over time without fooling yourself

The short answer

Record raw balances and derive everything else later. Sample at an interval chosen by the question rather than by convenience. Record the venue set and the gaps as explicitly as the data itself. Those three rules prevent most of the ways a depth series ends up describing the collection method instead of the market.

The reason discipline matters here more than in a one-off reading is that errors in a series compound. A single bad depth calculation is wrong once. A sampling interval that hides liquidity events makes every derived statistic wrong in the same direction, consistently enough to look like a finding.

What a good series buys is the ability to answer questions no snapshot can touch: whether depth is trending, whether it recovers after events, whether providers stay through quiet periods, and whether a change was a step or a drift.

The fields worth recording

The record for each sample should be small enough to collect reliably and complete enough to rebuild any later derivation. In practice that means eight fields.

• Slot and timestamp. Both, not one. Slots order events precisely and are the unit the node interface returns, as the Solana developer documentation sets out; timestamps make a series readable by humans and comparable with off-chain records.
• Reserve A and reserve B, raw. Unconverted, undenominated, exactly as the accounts report them. Every ratio and every ladder can be rebuilt from these.
• Token decimals. Recorded once per pair, but recorded, because a series that has to guess decimals later is a series of meaningless ratios.
• LP token supply. The field that distinguishes trading from liquidity events, and therefore the single most valuable column in the table.
• Fee parameter. Rarely changes, occasionally does, and a series that assumes it is constant will mis-attribute the resulting drift.
• Range distribution summary. On concentrated venues, at minimum the liquidity available in the intervals near the current price, which for a bin-based venue means the occupied bins described in Meteora's protocol documentation. Without it, depth cannot be computed at all.
• Pool address and venue. Explicit rather than implied by the file name, so a series can be merged, split and audited later.
• Collection status. Whether the sample succeeded, failed or timed out. A failed sample is data; a missing row is a mystery.

Notice what is absent. No price, no value locked, no depth figure, no yield. All four are derivable, all four encode assumptions, and storing them alongside raw balances guarantees that some later reader trusts the derived column and inherits an assumption they never saw.

Choosing an interval

The interval should be short enough that the two events you need to distinguish cannot land in the same bucket. That is the whole rule, and it is question-specific rather than universal.

For separating a redemption from a range exit, the binding constraint is that LP supply must be observed on both sides of the instruction. For catching migration, the constraint is that pool creation and the depth transfer often happen within a very short span, so a five-minute interval can compress the entire event into one row. For provider retention over weeks, hourly sampling is ample and finer sampling mostly produces storage costs.

There is also a floor set by the infrastructure. Public endpoints rate limit, and a sampler that is being throttled produces irregular intervals while appearing to run normally. Recording the actual sample time rather than the intended one is what makes that visible; a series indexed by intended time will look regular and be wrong.

Four intervals compared

The practical answer for most desks is two series rather than one: a coarse series kept indefinitely for level and trend, and a fine series kept briefly and triggered around events. That combination costs far less than sampling everything finely and answers nearly as much.

What to derive, and when

Derivation happens at read time, from raw fields, with the assumptions written next to the calculation. Four derived quantities carry most of the value.

The normalised ratio. Reserves adjusted for decimals, which is the quoted price. Trivial once decimals are recorded and impossible to reconstruct reliably if they are not.

The reserve product. A proxy for pool size that is invariant under trading and moves under liquidity events and fee accrual. Comparing product across two samples is the cheapest liquidity-event detector available.

Depth at chosen distances. The ladder, computed per side. On classic pools this is closed form; on concentrated venues it walks the recorded interval distribution. This is the column that answers trading questions.

Share-weighted change. For anyone holding a position, the change in what their share is worth, which requires LP supply at both ends and is otherwise easy to get wrong by ignoring dilution from other deposits.

Deriving at read time also means a mistake is fixable. A depth formula that turns out to mishandle a venue's fee convention can be corrected and the whole history recomputed, which is impossible if only the derived output was ever stored.

A worked series, illustrative

Artefacts that look like findings

Four artefacts account for most false discoveries in depth series, and each has a specific fix.

Denomination drift. A series stored in converted value moves when the quote asset moves, producing liquidity changes that never happened. The fix is storing raw balances, which is why it is the first rule in this entry.

Silent gaps. A sampler that fails and does not record the failure leaves a hole that later code will interpolate across, and the cheapest way to catch one is spot-checking a suspicious row against the account history on a block explorer such as Solscan. The interpolated points look like measurements. Recording collection status turns the hole back into what it is, which is an absence of knowledge.

Venue set drift. Adding a pool to the collection halfway through a series shows a jump in pair depth that is entirely a collection event. Fixing the venue set at the start and recording changes as annotations prevents it.

Interval aliasing. When events are shorter than the sampling interval, the series shows their net effect rather than their sequence, and net effects can be zero when two large opposite events cancel. The fix is choosing the interval from the question, and stating in any output what the interval was.

Keeping a series readable

A series is written once and read months later, usually by someone who has forgotten the assumptions, frequently the same person. Three habits carry most of the readability.

Keep a manifest alongside the data recording the venue set, the interval, the collection window, the code version and any known incidents. This is the difference between a dataset and a folder of numbers, and it takes minutes to maintain.

Never edit historical rows. Corrections belong in a separate column or a separate file, so the original observation is preserved. A series that has been quietly cleaned cannot be audited, and an unauditable series should not be used to support a claim.

Write down the questions the series was built to answer, at the time it was built. This constrains later use honestly, because a series designed for hourly retention analysis will be reused for event analysis by someone who does not know it was never sampled finely enough. The measurement side of the activity half of a market has the same discipline problem, and reading how volume campaigns are measured makes the parallel obvious: the constraints on how volume campaigns are measured are the same constraints that apply to a depth series, arrived at from the other direction.

The sampling routine

1. Write the question first One sentence stating what the series must be able to distinguish. Every later choice, especially the interval, follows from this sentence and is arbitrary without it.
2. Fix and record the venue set Name every pool that counts as this pair. Changes to the set are events to be annotated, never silent edits to the collection.
3. Collect raw fields only Both reserves, LP supply, decimals, fee parameter, range summary, addresses, slot, timestamp and collection status. Nothing derived.
4. Record failures explicitly A failed sample gets a row. A series that cannot show where it was blind will be read as if it was never blind.
5. Derive at read time and version the derivation Compute ratios, products and ladders from raw fields, keeping the code that did it, so the history can be recomputed when the method improves.
6. Re-run the conclusion at a second interval Before publishing anything from the series, check that the finding survives a different sampling rate. If it does not, the finding was about the sampler.

The routine is deliberately mechanical. Judgement belongs in choosing the question and interpreting the result, not in the collection, and a collection that depends on judgement produces a series nobody can reproduce, including its author. Anyone comparing this against tooling on the flow side, such as the reporting behind Solana Volume Bot Pro, will find the same separation between raw records and derived reporting, because it is the only arrangement that survives a change of method.

What a series cannot do

It cannot explain. A series shows that depth halved at a recorded moment; the reason sits outside the data and usually outside the chain. Entries on this site name the live explanations and stop, rather than choosing the most narratively satisfying one.

It cannot predict. There is no path from a sequence of depth readings to a statement about future depth, future price or future provider behaviour. This desk publishes no forecasts, and a series presented as evidence for one has been misused.

It cannot establish frequency either, which is a subtler trap. A series covering pools that were chosen because they looked interesting describes that selection, not the population of Solana pools. Any statement of the form that some pattern happens a given proportion of the time requires a defined population and unbiased sampling, and where this desk lacks both, it prints unknown rather than a number.

It also cannot make a liquidity position safe. Better measurement improves the description of what a position is exposed to; it does not change the exposure. An LP position can still end up worth less than the two assets held alone, however carefully the pool behind it was sampled, and nothing in this entry is advice about whether to hold one.

Questions this entry gets asked