Why these numbers are lower than Dune's

Dune's Polymarket Overview dashboard (by datadashboards) shows higher volume than this chart. The difference is not a data gap on Allium's side.

Every Polymarket trade emits two OrderFilled events on-chain: one real maker-side event, and one taker-focused event where the taker is the exchange contract itself, a routing artifact rather than a second trade. Allium's data excludes the artifact. Dune's community query does not; it sums both events and applies a flat divide-by-two correction, which over- or under-corrects depending on how much of a given day's volume came through cross-exchange routing. That is why the gap between the two sources moves around day to day instead of sitting at a clean 2x.

This was identified in research Allium did with Paradigm: Polymarket volume is being double-counted.

Why Allium is simpler to build on

Dune's raw tables mirror on-chain events one for one. Computing Polymarket volume from them means combining five separate tables: the FPMM factory, V1 CTF Exchange, V1 NegRisk, and two later exchange deployments with different field layouts, then hand-writing different logic for each because Polymarket's contracts have changed their event shape more than once. Allium's polygon.predictions.trades table already combines all of that into one row per trade, in USD, with the double-count removed. The query behind this section is three lines:

select block_timestamp::date as day, sum(usd_collateral_amount) as volume
from polygon.predictions.trades
where project = 'polymarket'
group by day

Where this metric agrees with Dune, and where it doesn't

A second Dune dashboard, hildobby/polymarket, tracks this same metric. Checked against the week of March 9, 2026: Dune reports 366,650 active addresses, Allium reports approximately 369,548. Effectively identical.

That agreement is itself informative. The OrderFilled double-count described above inflates volume because it is a sum. It does not meaningfully inflate a distinct-address count, because deduplicating by address absorbs the duplicate event either way. Volume and address counts are affected differently by the same underlying bug, and a chart that only shows one of the two can hide that.

That dashboard's own volume chart shows the size of the problem when no correction is applied at all: for the week of November 11, 2024, it reports $512.1M against Allium's $225.1M, roughly double. Three separate charts in that dashboard handle the same double-count three different ways: one applies no correction, one divides by two in one query and not another, and one only fixed it going forward by splicing a live query onto a hand-frozen historical snapshot table. Two other charts on that dashboard have been broken for some time, failing on a Dune table that no longer exists or is no longer accessible. None of that is a criticism of the analyst; it is what happens when every query has to independently reconstruct a protocol's full event history with no shared, maintained layer underneath it.