Comparing Two Tokens Honestly: A Written Procedure

Comparing two tokens honestly means normalising six fields before comparing anything: stage, window, venue set, route accounting, depth convention and data source. Once those match, compare derived ratios rather than headline totals. If a field cannot be equalised, the correct output is a narrower comparison with the gap stated, not a confident number.

The premise: the comparison is the easy part

Putting two numbers side by side takes no skill. Establishing that they are the same kind of number takes about ten minutes and is the entire job. Most published token comparisons skip that ten minutes, which is why they so often reverse themselves when someone checks a different data source.

The failure is systematic rather than random. Conventions do not differ arbitrarily between tokens; they differ with how a token is traded. A heavily routed token is systematically favoured by per-leg counting. A token whose data provider uses a rolling window is systematically steadier than one on a fixed window. These biases correlate with exactly the properties people are trying to compare.

Systematic bias is worse than noise for a specific reason. Noise cancels out when you look at enough cases, so a noisy comparison is unreliable but not directionally wrong. A bias that tracks the property under examination does not cancel; it accumulates, and the more comparisons you run the more confident the wrong conclusion becomes. That is why the normalisation cannot be skipped on the grounds that it probably does not matter much.

The procedure below is written to be run in ten minutes with nothing but a token page, a calculator and, occasionally, an explorer. It is not a research method. It is the minimum that makes a comparison mean what it appears to mean, and every step exists because skipping it produces a specific, repeatable error.

Six fields that have to be equalised

Each of the six changes the reported figure without any change in underlying activity. Together they routinely account for differences of several times.

• Stage. Launchpad curve, freshly seeded pool, or established pair. The price mechanics differ, so the same figure means different things. This is the field that most often makes a comparison impossible rather than merely difficult.
• Window and its rule. Rolling or fixed, and where the boundary sits. A fixed-window figure read shortly after a reset covers minutes rather than a day.
• Venue set. One pool, every pool for the pair, or a curve plus a pool during a migration. Providers differ, particularly around transitions.
• Route accounting. Per leg or per intent. Systematically favours whichever token aggregators route through more often.
• Depth convention. Both sides summed or one side only; single pool or all pools; total deposited value or depth near the current price.
• Data source. Use one provider for both sides. Mixing providers imports two sets of the five conventions above simultaneously.

The procedure, step by step

Run this in order. Steps one to five are the normalisation; step six is the arithmetic; step seven is the honest write-up that makes the result usable by someone else.

1. Fix the stage on both sides. Curve, fresh pool or established pair. If the two tokens are at different stages, stop and decide whether a narrower comparison on average trade size alone is what you actually want.
2. Fix the window and its rule. Rolling or fixed, and if fixed, how long ago it reset. Re-read both at a comparable point if the rules differ.
3. Fix the venue set. Write down what each figure covers. If a token migrated recently, check whether the provider restarted the series, continued it, or is reporting both.
4. Record the route accounting convention. If the provider does not state it, mark the field unresolved and treat differences under roughly a factor of two as inconclusive.
5. Record depth on one convention. Both sides summed or one side only, applied identically to both tokens. For a curve, record that no comparable denominator exists.
6. Compute three ratios per token. Turnover, average trade size, volume per wallet. All three from the same window as the volume figure.
7. Compare the profiles and state the limits. Put the ratios side by side, then write one sentence naming every field that could not be equalised.

Step seven is the one people drop, and it is the one that makes the output trustworthy. A comparison that names its own unresolved fields can be checked and improved. One that does not is an assertion.

The normalisation sheet

The desk fills this in before running any comparison. It is deliberately boring, and it is where the work happens.

Notice that most of the fallback column says narrow the comparison rather than estimate a correction. Estimating corrections for undisclosed conventions produces numbers with invented precision. Narrowing the claim produces a smaller true statement, which is more useful.

When a field genuinely cannot be settled from a dashboard, the reserve balances and the individual swap transactions are on chain and can be read directly. An explorer view of the accounts involved settles depth conventions immediately, and the transaction structure that determines per-leg versus per-intent counting is described in the Solana developer docs.

Worked comparison of an illustrative pair

What the comparison does not say is which token is better, or which has more interest behind it. Neither question is answerable from these figures, and answering them anyway is the specific failure this procedure exists to prevent.

When the two sides refuse to normalise

Sometimes the fields cannot be equalised. A token is mid-migration and providers disagree about the venue set. A provider will not state its route convention. One token trades across four pools and the other in one. These are common, and there are three legitimate responses.

The first is to narrow the claim. Instead of comparing total activity, compare average trade size, which is robust to venue set and to depth convention because both inputs come from the same trade stream. The comparison is smaller and it is true.

The second is to recompute from primary data. Reserve balances and transaction histories are on chain, so depth and trade counts can be rebuilt directly rather than accepted from a dashboard. This is slower and settles most convention disputes outright.

The third is to abandon the comparison and say why. This is underrated. A written note that two tokens cannot be compared on volume because one is mid-migration is a more useful output than a number with a hidden factor of three inside it.

Compare profiles, not headlines

A profile is three derived ratios read together. It resists most of the distortions that headline volume is subject to, because each ratio has a denominator that carries some of the context the headline dropped.

Turnover carries the depth context. Average trade size carries the size-distribution context. Volume per wallet carries the concentration context. Together they place a token in a three-dimensional space, and two tokens can be compared by where they sit in that space rather than by a single ordering.

The profile also degrades gracefully. If depth cannot be established, drop turnover and compare on the other two; the comparison narrows rather than breaking. A headline total has no such property: it is either comparable or it is not, and you usually cannot tell which from looking at it.

One further property makes profiles worth the extra minute. Because each ratio has a different denominator, the three of them respond differently to the same distortion. A per-leg counting convention inflates volume, which raises turnover and volume per wallet while leaving average trade size roughly intact, since the count inflates alongside the total. A stale liquidity figure moves turnover alone. When the three ratios disagree about how unusual a token is, the pattern of disagreement often identifies which convention is responsible.

What measured means when volume is produced

There is a case this procedure handles less well, and it is worth naming rather than hiding. When flow is deliberately produced, the figures that appear on a dashboard are the output of a configuration, and the configuration is knowable to whoever set it and invisible to everyone else. From outside you see 9,600 trades at an average of 25; from inside, someone set a wallet count, an interval and a size band that produced them.

This asymmetry is why the definition of measurement matters. Reading a stated methodology for how volume campaigns are measured is instructive precisely because it makes the distinction visible: a campaign reports what it dispatched and what settled on chain, which is a statement about production, not about interest. Nothing in such a report claims that the resulting figure represents demand, and nothing in a dashboard column does either. The claim only appears when a reader adds it.

The launch-stage case is where the asymmetry is widest, because curve venues have the shallowest effective depth and the lowest per-trade cost. A volume bot for Pump.fun launches operates on exactly the variables the six-field procedure is trying to reconstruct, and knowing which variables are configurable is what allows you to read a profile as a set of settings rather than as an observation about a market. The structural reasons launch-stage venues behave this way are covered in curve volume versus pool volume.

Writing the comparison down

A comparison that lives in your head cannot be checked. The desk writes every one in the same shape, which takes four lines and makes the result reusable.

1. Line one: what was compared. Two tokens, one provider, one window rule, one venue set per token, stated explicitly.
2. Line two: the three ratios for each. Turnover, average trade size, volume per wallet, with the depth convention named.
3. Line three: the description. One sentence per token describing the flow, containing no ranking words and no motive.
4. Line four: the unresolved fields. Anything that could not be equalised, and what it would take to settle it.

Four lines, and someone else can reproduce or refute the whole thing. That is the standard a comparison should meet before it is quoted anywhere, and it is not a high bar.

Three errors the procedure prevents

Three specific mistakes account for most bad volume comparisons, and each is blocked by a different step above.

Ranking across stages. Blocked by step one. A screener sorted by volume mixes curve tokens and established pairs into one ordering, and the ordering is not measuring one thing.

Reading a reporting artefact as an event. Blocked by step three. Discontinuities at migration are usually venue-set changes rather than changes in activity, and they look exactly like collapses or spikes in a chart.

Treating a large figure as evidence of interest. Blocked by step six and by the write-up. Once the profile is in front of you, the question of what produced the flow is visibly separate from the question of how much flow there was, and the second one never answers the first.

The catalogue of the comparisons that go wrong most often, with a specific correction for each, is in five comparisons that mislead. The terms used throughout are defined in the glossary.

Questions this page gets asked