Measuring a Volume Campaign

Measuring a volume campaign starts before the campaign does. Without a baseline captured in the same buckets, from the same data source, under the same definitions, nothing recorded afterwards can be attributed to the activity rather than to the market. The metrics worth reporting are unique funding sources, venue distribution, depth reaction, holder change and trade-size distribution, each with a stated window.

Most reports fail at the first step rather than the last. They begin after the activity has run, pick whichever chart shows movement, and compare a rolling figure to an unstated earlier period. The result is unfalsifiable. This note sets out a protocol that produces a number someone else could check, including the uncomfortable case where the honest answer is that nothing measurable changed.

Define the objective before measuring anything

An objective is measurable only if it could turn out to be false. "More visibility" is not an objective. "Median hourly transaction count in the pair rises above the ninetieth percentile of the previous fourteen days, and stays there for six hours after the activity ends" is an objective, because a specific observation would refute it. Write the sentence before anything runs and do not edit it afterwards.

Writing it that way forces two decisions most people avoid. It forces you to name the one metric that matters, rather than collecting whichever metric later looks best. And it forces you to name a threshold, which exposes whether the expected effect is large enough to distinguish from ordinary variation at all. Many objectives collapse at this point, which is a useful outcome.

Objectives also need a scope. A campaign that runs on one pair cannot be evaluated on a token's aggregate figures across every venue, because activity elsewhere will contaminate the reading. Decide whether you are measuring a pool, a pair across pools, or a token everywhere, and note that the three answers behave differently, as the note on where Solana volume comes from sets out.

Take a baseline before activity starts

A baseline is a recording of every metric you intend to report, taken over a pre-activity period, in the bucket length you will use later, from the source you will use later. It is the single most skipped step and the single most expensive one to skip, because no amount of subsequent analysis can reconstruct a comparison that was never defined.

Length matters. A baseline shorter than the planned activity cannot distinguish an effect from a quiet stretch that happened to precede it. A baseline that spans a listing, a broad market move or a holiday weekend carries that event into the comparison. Choose a period long enough to contain the market's ordinary variation, then look at the variance inside it before you accept it as a reference.

Store raw values, not summaries. A stored average cannot be re-bucketed later; a stored series can. Keep the per-bucket series, the source name, the exact query or endpoint used, and the timestamp of capture. If the source revises historical data, which several do, your stored copy is the only record of what the figure said at the time you read it.

Baselines should also record what is not volume. Holder count, the number of distinct funding sources active in the pair, and pool reserves at the moment of capture all belong in the baseline. These are the fields that make a later report readable, because they let a reader see whether a change in activity coincided with any change in the market's actual composition.

The metrics that survive scrutiny

The headline volume figure is the weakest metric in any report, because in a campaign the activity itself produces the transactions. Volume rising is a restatement of the input. The metrics below are harder to produce artificially, and each one answers a question the volume total cannot.

Unique funding sources

Count the distinct accounts that funded the wallets trading in the window, not the wallets themselves. Address creation is cheap, so a wallet count measures address generation. A funding graph collapses addresses that share an origin into a single participant, giving a coarse but far more honest estimate of how many independent parties are present. The method and its limits are set out in the note on organic versus manufactured volume.

Distribution across venues

Record the share of activity by venue and by pool, not just the total. Activity concentrated in a single pool has a different meaning from the same total spread across several, because a router only reaches for a second venue when the first becomes expensive at the size being traded. A shift in venue distribution during a window is evidence about size, not just about frequency. This metric is also the one most sensitive to what produced the flow: a multi-DEX Solana volume bot and a single-venue script can post the same total while producing venue distributions that look nothing alike, so capture the split before you interpret the total.

Depth reaction

Measure pool reserves, and depth at a fixed order size, at the start and end of the window. Depth is a stock; volume is a flow. If reserves are unchanged after the activity, no liquidity was added or removed, whatever the flow figure says. If reserves fell, someone withdrew, and that fact belongs in the report regardless of how the volume line looks.

Holder change

Count the addresses holding a non-zero balance at baseline and at the end of the decay window, and separately count how many of the new holders were funded from a source already present at baseline. A rise in holders composed entirely of addresses funded from one origin is a different event from a rise composed of unrelated addresses, even though both show the same number.

Trade-size distribution

Report the median, the upper quartile and the largest single fill, not the mean. Means are dominated by outliers and hide the shape entirely. Distribution is where structure becomes visible: tight clustering around a narrow band of sizes describes a different market from a wide spread, and neither is visible in a total. The related decomposition appears in the note on the anatomy of Solana trading volume.

Choosing measurement windows that match the activity

A window is a claim about what period the number describes, and mismatched windows are the most common way an honest analyst reaches a wrong conclusion. If the activity ran for four hours, a daily figure dilutes it into eighteen hours of unrelated market and four of signal. If the activity ran for three days, a five-minute bucket produces noise nobody can read.

The workable rule is to pick a bucket short enough that the activity spans several of them and long enough that a single large fill does not dominate one. That gives you a shape rather than a point, and shape is what distinguishes a burst from a sustained change. Use the same bucket for baseline, activity and decay; changing bucket length between phases makes the comparison meaningless.

Three windows belong in every report. The baseline window, ending before the activity starts. The intervention window, matching the activity exactly, in a stated timezone. The decay window, running afterwards for at least as long as the activity itself. The third one carries most of the information, because anything that persists past the activity is the only part not directly produced by it.

Timezone and window type must both be stated. A rolling twenty-four hour figure and a calendar-day figure describe the same market and disagree constantly, particularly right after a burst, when a rolling figure keeps the burst visible long after it has stopped. A report that names neither cannot be reconciled with any other report, including a later reading of itself.

The protocol, end to end

The sequence below is deliberately mechanical. Every step exists because skipping it produces a specific, common error, and the order matters: three of the seven steps must happen before any activity runs, which is why retrospective measurement is always weaker than planned measurement.

1. Write the objective as a falsifiable sentenceOne outcome, one metric, one threshold, one window. If no observable result would count as failure, stop here and rewrite it, because nothing that follows can be checked.
2. Freeze the definitions and the data sourcePick one source per metric, write down its counting conventions, and commit for the whole exercise. Record the endpoint or query used so the same figure can be re-pulled later by someone else.
3. Capture the baselineRecord every metric over the pre-activity period in the bucket length you will use throughout, and store the raw series rather than an average. Note anything unusual inside the baseline period itself.
4. Record the intervention window preciselyLog exact start and end timestamps with a timezone, and log every other event in the same period: listings, announcements, unlocks, broad market moves. Confounders you did not write down cannot be subtracted later.
5. Measure during the activity in matched bucketsSame source, same bucket, same definitions as the baseline. Resist adding a new metric mid-window because it looks interesting; add it to the next exercise instead, with its own baseline.
6. Measure the decay window after the activity stopsContinue for at least as long as the activity ran. This is the part almost every report omits, and it is the only part that speaks to durability rather than to the activity itself.
7. Report baseline and post-campaign values side by sideOne table, both values for every metric, source and window named per row, confounders listed underneath. Report the metrics that did not move with the same prominence as the ones that did.

A reporting table template

The table below is the deliverable, not an example of one. Every row is a metric worth reporting; the two right-hand columns are deliberately empty because filling them with plausible-looking figures would be inventing the very thing the protocol exists to measure. You fill them from your own capture, or the row stays empty and the report says so.

Two conventions make the completed table useful to a reader who was not present. Name the source in the row rather than once at the top, because different metrics usually come from different places. And keep the window column populated even when it repeats, so that no reader has to infer which figures are comparable with which.

Common measurement mistakes

• Measuring only after the factReconstructing history after the outcome is known lets the analyst choose the comparison period that flatters the result, whether or not that is the intention.
• Changing the data source mid-exerciseTwo sources count sides, routes and failures differently, so a switch produces a step change in the numbers that has nothing to do with the market.
• Comparing a rolling window to a calendar windowThe difference between the two is an artefact of the window definitions and can easily exceed the effect being measured.
• Counting failed transactions as activityA reverted transaction moved no value. Attempts belong in a landing-rate metric with their own denominator, never inside a volume total.
• Using unique wallets as a participant countAddress creation is cheap, so the figure measures address generation. Group by funding source before treating any wallet count as a count of people.
• Attributing every price move to the campaignBroad market moves, unlocks, listings and unrelated news all occur inside the window. If they were not logged at the time, they cannot be separated afterwards.
• Reporting a single headline figureA total without a distribution hides whether it came from many participants or from a few cycling the same balance, which is the whole question.
• Stopping measurement when the activity stopsThe decay window carries the only evidence about durability, and omitting it turns a report into a description of the input.
• Publishing only the favourable metricsSelective reporting is the mechanism by which an honest process produces a dishonest document, and it is usually unconscious rather than deliberate.

The through-line in all nine is the same: each one substitutes a number that is easy to produce for a number that is hard to produce. Resisting that substitution is most of the discipline. A report that is boring, narrow and reproducible is worth more than a broad one that cannot be checked by anybody who was not in the room when it was written.

Where tooling replaces spreadsheets

The protocol above is doable by hand for one pair over a short window. It stops being doable when the exercise involves several venues, thousands of transactions and a funding-graph pass across every wallet that touched the pair. At that point the work belongs in scripts against an indexer or a node, with the captured series stored in a file rather than in a browser tab. A public explorer such as Solscan remains useful for spot-checking individual transactions against whatever your pipeline produced.

Execution is a separate concern from measurement, and it has its own tooling. Readers who want to see what a multi-venue execution console looks like as a product can examine one example of Solana volume automation, a third-party service on a separate site, unaffiliated with this desk. What you will find there is an interface for configuring and running activity across Solana venues, not a measurement system.

That distinction is the reason this section exists at the end rather than the beginning. Whatever you run, and whoever runs it, the protocol above is what tells you what it did. Apply it to your own activity exactly as written: objective first, baseline before anything starts, matched windows, decay window, both columns of the table filled in from your own capture rather than from anyone's description of expected results.

Building the measurement side yourself is not a large project. A transaction fetcher, a parser that reads balance changes rather than logs, a funding-graph pass and a bucketing function cover almost all of it. Everything the protocol asks for comes from public chain data, which means every figure in a completed report is checkable by a reader who has the same access you do and no special relationship with anybody.

Method questions the desk receives

Can a campaign be measured after it has already run?

Only weakly. Most on-chain metrics can be reconstructed historically, but the definitions, source and bucket boundaries get chosen after the outcome is known, which is precisely the freedom a protocol exists to remove. Retrospective work describes what happened; it does not attribute it to anything.

How long should the baseline period be?

Long enough to contain the market's ordinary variation, and at least as long as the planned activity. Look at the variance inside the baseline before accepting it. If the baseline period itself swings more than the effect you expect to see, the exercise cannot resolve that effect and should be redesigned.

Why funding sources instead of unique wallets?

Because a wallet count measures address generation, which is nearly free. Grouping addresses by the account that funded them produces a coarser figure that is much harder to inflate. It is an estimate with known limits, and those limits should be stated in the report rather than hidden behind a precise-looking number.

Does volume rising prove that a campaign worked?

No, and this is the central trap. If the activity produced the transactions, then a rise in volume restates the input. The informative metrics are the ones the activity does not directly control: holder composition, depth, venue distribution, and what remains in the decay window after everything stops.

What belongs in the report when nothing changed?

The same table, with the unchanged rows shown at full prominence and the confounders listed underneath. A null result measured properly is a genuine finding and is more useful than a favourable result produced by a process nobody can repeat.

Who should hold the measurement data?

Whoever will be asked to defend the conclusion. Keep the raw series, the queries used and the capture timestamps in one place, separate from any interface that might revise history. If a figure cannot be re-derived from stored inputs six months later, it should not appear in the report.