# Why two dashboards show different volume for the same market

Volume is several quantities under one name - contracts or dollars, one side or both, swaps or also mints and merges, and whose day. How to tell which.

*https://predictionmarkets.tools/guides/why-two-dashboards-disagree-on-volume · background to Prediction Market Analytics & Dashboards*

**Answer:** Because volume is not one quantity. A dashboard may count contracts, dollars at the one-dollar face value, or the price actually paid, which runs about half of face; one side of each trade or both; ordinary swaps alone or also mints, merges, conversions and parlays; and a UTC day, a trailing 24 hours or a month. A December 2025 Paradigm analysis found most Polymarket dashboards counting both sides. Two figures can disagree and both follow their own definition.

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](https://predictionmarkets.tools/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](https://www.artemis.ai/docs/prediction-markets/overview) 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](https://www.paradigm.xyz/writing/polymarket-volume-is-being-double-counted)
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`)"](https://docs.dune.com/data-catalog/curated/prediction-markets/kalshi/market_trades)
— which is the quantity Artemis calls premium. So a Kalshi market read through
[Artemis](https://predictionmarkets.tools/tools/artemis-prediction-markets) 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](https://predictionmarkets.tools/tools/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"](https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/market_trades).

**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](https://predictionmarkets.tools/guides/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](https://arxiv.org/abs/2603.03136) 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](https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/market_actions),
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](https://docs.dune.com/data-catalog/curated/prediction-markets/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](https://github.com/Polymarket/polymarket-subgraph/blob/main/orderbook-subgraph/src/ExchangeMapping.ts)
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](https://predictionmarkets.tools/tools/polymarket-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](https://predictionmarkets.tools/tools/dune-polymarket-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](https://predictionmarkets.tools/tools/polysights)' landing page, or every derived number on
  [Lychee](https://predictionmarkets.tools/tools/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](https://predictionmarkets.tools/tools/artemis-prediction-markets)
methodology page names each field and each venue's source; a
[Dune dashboard](https://predictionmarkets.tools/tools/dune-polymarket-dashboards) 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](https://predictionmarkets.tools/categories/analytics-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.

## Tools this bears on

- [Artemis prediction-market metrics](https://predictionmarkets.tools/tools/artemis-prediction-markets.md) — Daily volume, open interest and fees across thirteen event venues, with methodology.
- [Polymarket dashboards on Dune](https://predictionmarkets.tools/tools/dune-polymarket-dashboards.md) — Community SQL dashboards over Polymarket's on-chain record, free to read and fork.
- [Polyrama](https://predictionmarkets.tools/tools/polyrama.md) — Polymarket and Kalshi in one terminal, with wallet analytics and a REST API.
- [Polymarket Gamma API](https://predictionmarkets.tools/tools/polymarket-gamma-api.md) — Polymarket's read-only catalogue of events, markets, series and tags.

## FAQ

### Is Polymarket's volume inflated?

The double counting Paradigm described in December 2025 was in dashboards built by summing every fill event on the chain, which records most trades once from each side. The note does not address the figure Polymarket displays, and it says explicitly that it is unrelated to wash trading. Dune's documentation says its taker-side filter matches Polymarket's published methodology.

### Why does the same Kalshi market show two different dollar volumes?

Kalshi reports contracts, and a dollar figure is a conversion someone chose. Artemis counts each contract at its one-dollar face value; Dune multiplies the count by the price the taker paid, which at typical prices is roughly half as much. Both vendors call their figure notional.

### Can I compare Polymarket and Kalshi volume directly?

Only in the same unit, counted on one side, over the same window. Artemis's position is that on one-dollar-face venues a contract count equals face-value notional and is comparable across Kalshi and Polymarket. A Polymarket cash figure beside a Kalshi face figure is out by roughly a factor of two before anything else differs.

### Why do my daily totals not add up to the monthly figure?

Either the two use different day boundaries, or the definition depends on the window. Tsang and Yang's exchange-equivalent turnover pairs mints against burns inside the window, so a longer window generally raises it, and the authors state that their daily and monthly figures are not directly comparable.

## Sources

1. [Polymarket Volume Is Being Double-Counted](https://www.paradigm.xyz/writing/polymarket-volume-is-being-double-counted) — Paradigm (Storm Slivkoff), 2025-12-08
2. [The Anatomy of a Blockchain Prediction Market, Polymarket in the 2024 U.S. Presidential Election (arXiv 2603.03136, v2)](https://arxiv.org/abs/2603.03136) — Kwok Ping Tsang and Zichao Yang, arXiv, 2026-05-07
3. [polymarket_polygon.market_trades](https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/market_trades) — Dune, read 2026-09-26
4. [polymarket_polygon.market_actions](https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/market_actions) — Dune, read 2026-09-26
5. [kalshi.market_trades](https://docs.dune.com/data-catalog/curated/prediction-markets/kalshi/market_trades) — Dune, read 2026-09-26
6. [Polymarket, curated datasets](https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/overview) — Dune, read 2026-09-26
7. [Prediction markets metrics, overview](https://www.artemis.ai/docs/prediction-markets/overview) — Artemis, read 2026-09-26
8. [Polymarket orderbook subgraph, ExchangeMapping.ts](https://github.com/Polymarket/polymarket-subgraph/blob/main/orderbook-subgraph/src/ExchangeMapping.ts) — Polymarket, read 2026-09-26

*Last updated 2026-09-26. A reference page, corrected in place — not a dated post.*