Why two dashboards show different volume for the same market

Two screens, one market, one week, and one number is twice the other. The instinct is to decide which dashboard is broken. Usually neither is: each has answered a different question under the same one-word label, and neither printed the question.

There are four choices behind every volume figure in this category, and they compound. This page lists them, shows how far apart the published numbers actually get, and ends with the questions that tell you which choice a screen made. The SQL half of one of them — the taker-side filter on Polymarket's trade table — is already written up in how to build a dashboard on Polymarket data, and is not repeated here.

How it works

Choice one: the unit

Take one contract bought at 30 cents. It has three honest volumes: one contract; one dollar of face value, because that is what it pays if right; and 30 cents of cash, because that is what changed hands.

Artemis, whose methodology page is the most complete public account of cross-venue aggregates, draws exactly that line. Its headline spot_volume is a contract count, which on one-dollar-face venues "equals USD notional", and the page states that this is "notional, not the price-weighted premium (cash actually traded, ≈ half of notional)", carried separately as volume_usd. Paradigm's December 2025 analysis uses the same two families under different names: notional volume is the "number of contracts traded", cash flow volume is "the amount of USD exchanged at time of trade".

The word "notional" does not survive a change of vendor. Dune's Kalshi trade table describes its amount_usd column as the "USD notional of the trade (taker price × count_fp)" — which is the quantity Artemis calls premium. So a Kalshi market read through Artemis and through a Dune query can both report "USD notional" for the same day and differ by roughly a factor of two, with neither vendor wrong about its own column.

Then there is which price. A Kalshi trade carries a Yes price and a No price that sum to a dollar, and Dune's table records both alongside the side the taker was on. Dune multiplies by the taker's price. A trade where the taker bought No at 30 cents is 30 cents a contract by that rule and 70 cents by a rule that always multiplies by the Yes price. Polyrama converts Kalshi's contract counts into dollars by multiplying by price so the two venues sort on one scale, and says so — which is the right thing to look for, whichever price a product picks.

And some contracts are not a dollar at all. Artemis flags CME and Nadex: contract faces vary by product family, so their counts are contracts and not dollars, and "should not be compared 1:1 with the $1-face venues".

Choice two: one side of the trade, or both

Every trade has a buyer and a seller, and a data source can record it from either or from both.

Paradigm's note is the clearest published account of what that does on Polymarket. The exchange emits an OrderFilled event for each maker and a second one for the taker, so the common method of summing them "double counts both the number of contracts traded and USD cash flow": in its example, "a simple sale of YES tokens for $4.13 gets recorded as $8.26 worth of volume". Its conclusion is that volume "should be measured using a one-sided volume metric, such as taker-side volume or maker-side volume". Dune's trade table keeps both rows and flags the taker leg, and its own documentation calls the unfiltered sum "technically correct volume, but not directly comparable to DEX volume".

This is not only an on-chain problem. Artemis documents ForecastEx's end-of-day file as listing a YES and a NO row per contract "carrying the same pair-level figures", and takes the maximum across those rows before summing — which it calls "a double-count-safe aggregation". Add the rows of a regulated venue's own published file and you have doubled the venue's number without touching a chain.

And a leaderboard is two-sided by construction. A wallet's volume is its own side of each trade, which is the correct figure for that wallet. Paradigm notes that in a conventional swap "the maker and taker experience the same amount of volume", so adding up the volume column across every address on a leaderboard counts each swap once for each party. A platform total assembled from per-wallet totals is the both-sides figure, whatever it is labelled. The wider limits of that screen are in what wallet tracking shows.

Choice three: which events count as trading

Polymarket's matching engine does not only pair a buyer with a seller. Dune's documentation lists three kinds of match in the one trade table: complementary matching, where one trader buys from another; MINT matching, where "the system mints new outcome tokens when there aren't enough sell orders"; and MERGE matching, where it "matches YES and NO shares to unlock collateral". Paradigm counts eight trade types, four of them splits and merges, and in those "the maker and the taker can experience different amounts of volume". Paradigm is explicitly not opinionated about which side to measure there, only that adding the two together is double counting.

Tsang and Yang's paper on the 2024 presidential markets goes further and argues that mint and burn flows are not turnover at all in the ordinary sense. Their decomposition separates exchange-equivalent turnover from net inflow of new collateral, and they show both simple methods failing in opposite directions: summing only OrdersMatched events "typically understates" activity because it omits the minting and burning inside many transactions, while summing OrderFilled counts the exchange component "once through the seller's fill and again through the buyer's fill".

Some activity is outside the trade table entirely. Dune keeps splits, merges, redemptions and neg-risk conversions that a user performs directly in a separate table, one row per user-level action, and states that the splits and merges inside a fill are "excluded by construction" there because they already live in the trade table. Tsang and Yang treat a conversion as "unilateral rather than counterparty-matched", so it generates no turnover in their measure, and keep it out of net inflow too as "a position-management and arbitrage tool". A dashboard that counts conversions or direct splits as volume is adding activity the other two do not count.

And whole product lines sit in their own tables. Polymarket's multi-leg Combos, trading since 29 May 2026, are in a separate combo_trades table on Dune rather than in market_trades, per its Polymarket overview. Artemis keeps perpetual futures on Kalshi and Polymarket in perp_ fields that must "never" be summed with event-contract volume, and carries two Gemini figures because the tick-by-tick one includes intraday crypto contracts and repeated combo prints that "Gemini's own displayed volume excludes, so it runs a multiple of the headline".

The disagreement exists inside a single publisher's code. Polymarket's own orderbook subgraph adds to each outcome token's volume on every OrderFilled event, and to its exchange-wide total on every OrdersMatched event — the two event streams Tsang and Yang treat as their two naive methods. A product that reads that subgraph shows a different kind of number depending on which of the two entities it queries.

Choice four: whose day, and how long a window

Dune's timestamps are UTC and its hourly candles are UTC hour buckets. A figure labelled 24 hours, read in New York in the evening, covers a different span from yesterday's UTC bar, and the two agree only by coincidence. Artemis works on a daily grain; its methodology page, as read on 26 September 2026, does not state where its day starts.

Some definitions also depend on the length of the window, not just its position. Tsang and Yang's exchange-equivalent turnover pairs mints against burns inside the window, and they note that "lengthening T generally raises" it, because more mints find a later burn to match; they report their daily and monthly figures as "not directly comparable". Under that definition the month is not the sum of its days.

Freshness is the last piece. Dune's Polymarket and Kalshi tables refresh roughly hourly, and Artemis leaves the current period empty until it closes, so two screens read shortly after midnight UTC disagree about "today" for reasons that have nothing to do with definitions.

Where the number came from

Three kinds of source sit behind the figures in this category, and a screen rarely says which.

• The venue's own figure. The volume fields in Polymarket's Gamma API are the platform's numbers about its own markets, and the API does not explain how they are computed. Dune states that its taker-side filter matches Polymarket's published methodology. For a regulated venue, the official figure is its own publication — Gemini's CFTC Rule 16.01 market data file, ForecastEx's end-of-day prices file, CME's daily volume file, in Artemis's list.
• A reconstruction from events. Artemis indexes on-chain venues from raw fill events, with "no reliance on a venue-reported dashboard number"; Dune dashboards are the same thing in public SQL; Tsang and Yang built theirs from the settlement ledger.
• A vendor's own counter. A figure with no method attached, such as the volume-tracked total on Polysights' landing page, or every derived number on Lychee, whose card records that no methodology page exists.

Two things are not usually the cause. Fees sit in their own column in both Dune's trade tables and Artemis's framework, outside volume. And none of the above concerns wash trading: Paradigm states that its analysis "is unrelated to wash trading or other types of volume classification". A product that filters suspected wash trades has made a fifth choice on top of the four.

How far apart the numbers get

The published measurements give a scale, and it is not small.

• About two times, from sides alone. Paradigm reports that taker-side, maker-side and share-priced volume each come out "around half of the OrderFilled sum" month by month, and that among those one-sided cash measures the choice matters little once aggregated over days or months.
• About two times, from unit alone. Artemis puts cash actually traded at roughly half of face-value notional at typical prices. That gap stacks on top of the one above.
• Nearly two and a half times, from sides and event scope together. For the Trump market in October 2024, Tsang and Yang report 958.48 million US dollars under raw OrderFilled aggregation, 567.45 million of overall market activity, and 391.03 million of exchange-equivalent turnover. Their abstract adds that the overstatement holds across 249 markets and is largest in thin, young ones.

So a factor of four between two dashboards is not evidence that either made an error. It is what both-sides face value looks like next to one-sided cash.

What you can do about it

Ask any volume figure four questions before comparing it with another. A product that has done the work answers each in a sentence.

1. What unit? Contracts, face-value dollars, or cash — and if cash, multiplied by whose price.
2. How many sides? One side of each trade, or every fill event as emitted.
3. Which events? Ordinary swaps only, or also the mint and merge legs inside fills; direct splits, merges and conversions; combos; perpetuals.
4. Which window? A UTC day, a trailing 24 hours, a calendar month — and when was it last refreshed.

Then divide one figure by the other before deciding anything. A ratio near two is almost always sides or unit. A ratio near four is what the two produce together. A ratio of about two and a half on Polymarket data is the gap Tsang and Yang measured between raw fill events and exchange-equivalent turnover, where minting and burning are treated as issuance rather than trading. A ratio that drifts with the length of the window points at the window.

Use Paradigm's check on any Polymarket history chart. Its note gives a single tell: a chart showing monthly Polymarket volume of around 2.5 billion US dollars for October and November 2024 is a sign that it is summing every OrderFilled event. It takes ten seconds and needs no query.

Reconcile in contracts, one side, first. A one-sided contract count does not depend on any price convention — Paradigm calls it straightforward even for splits and merges, where it is "simply the number of contracts that are split or merged" — and Artemis treats it as comparable across one-dollar-face venues. If two sources agree there and disagree in dollars, the difference is a pricing convention, and you now know which one to look for.

Prefer a figure whose definition you can read. The Artemis methodology page names each field and each venue's source; a Dune dashboard lets you read the query that produced the chart. A figure from a product with no methodology page is a number without a unit, and the analytics and dashboards listing records which products publish one.

Never add across definitions. Do not sum a Kalshi face-value figure with a Polymarket cash figure, the YES and NO rows of an exchange's end-of-day file, perpetuals with event contracts, or CME and Nadex contract counts with anything in dollars. A cross-venue total built that way is not approximately right; it is a different quantity.

If you publish a figure of your own, print its definition next to it. One line — "one-sided taker volume in USD, UTC days, excluding direct splits, merges, conversions and combos" — is the whole of the fix, and it is the line missing from almost every screen in this category.