How to build your own dashboard on Polymarket data

The short way

Decide first whether your dashboard is about what happened or about what is true right now, because the two are different pipelines and only one of them is cheap.

What happened. Polymarket settles on Polygon, so every fill is a decoded on-chain event and the natural query language is SQL. Polymarket dashboards on Dune is the shortest path in this catalogue, and the shortcut inside the shortcut is that you do not start from a blank query: public dashboards can be opened, read and forked on the free view-only plan, so the first version of your chart is usually somebody else's definition that you then argue with.

Dune's curated prediction-market tables are what those queries sit on. polymarket_polygon.market_trades is public, partitioned by month, and carries one row per trade event with price, shares, amount in USD, fee, the maker and taker addresses and both sides of the match.

-- Daily taker-side volume on one market. Time bound first: the table is partitioned
-- on block_month, and an unbounded scan is the usual reason a fork times out.
SELECT date_trunc('day', block_time) AS day,
       sum(amount)                   AS usd_volume,
       sum(shares)                   AS shares,
       count(*)                      AS fills
FROM polymarket_polygon.market_trades
WHERE block_time >= NOW() - INTERVAL '90' DAY
  AND condition_id = YOUR_CONDITION_ID
  AND is_taker_side
GROUP BY 1
ORDER BY 1

is_taker_side is not a refinement. A CLOB match writes both legs, so the filter is the difference between your number and the venue's.

What is true right now. The chain is post-trade, so the current book is not in it. That half comes from the Polymarket CLOB API, and the identifiers that join the two halves together come from the Gamma API — the condition id for the market, the token id for each outcome. Get those first; everything downstream is keyed by them.

What the options are

Polymarket dashboards on Dune is a layer rather than a product: Dune publishes the platform, and each dashboard belongs to whoever wrote it. What you get that no hosted screen gives you is the query — when a number looks wrong you can read what it measured instead of emailing support. What you have to watch is the access line. Of the curated Polymarket tables, trades, market details, hourly prices and the wallet lookup are public; holdings, lifecycle actions, hourly candles, the combo tables and the cross-venue unified schema all require an Enterprise entitlement, and stay visible in the explorer while refusing to run. A forked dashboard that errors for you and not for its author is usually this, not your SQL.

The Gamma API is the catalogue half of Polymarket and needs no key and no account: events and their child markets, series, tags, sports fixtures and search, each record carrying the slug, the condition id, the outcome token ids, the dates and the resolution rules text. It carries no order book and no price history. The rate limit is not published, which is a reason to implement backoff rather than evidence there is none.

The CLOB API is the other half and is where prices actually come from: the book for an outcome token, best bid and ask, midpoint, spread and last trade price, keyless to read, plus a public market WebSocket channel carrying book snapshots and price changes. Nothing on the read side needs a wallet. Its own documentation is clear that historical books are not retained — you can rebuild a price series, not the depth that produced it.

Polymarket Analytics is worth ten minutes before you build anything, because the chart may exist: market pages with volume, open interest and full price history, wallet pages with positions and realised P&L, and a leaderboard over addresses, free to browse with no account. Two things to carry away rather than assume. It is not published by Polymarket — its own terms say it is not affiliated with or endorsed by any prediction market — and its free data is licensed for individual non-commercial use with scraping prohibited, so it is a reference to read, not a feed to build a product on. The programmatic surface is a separate paid API under a different brand on an api. subdomain.

Artemis answers the one tile the others make hardest: the venue-level daily number, on the same framework across thirteen event venues, with the ingestion path and the known gaps written down. Two of its definitions decide whether your top-line figure means anything. Its daily volume is contract notional on dollar-face venues, not the premium actually exchanged, which its documentation puts at roughly half of notional and carries in a separate field. And perpetual-style contracts sit in their own fields and must not be summed with event-contract volume. Reading the charts is free; the REST API, the MCP server and the data share sit on the enterprise tier.

Where this breaks

The fills are on-chain but the matching is not. Polymarket runs a central limit order book off chain and settles the result on Polygon, so what you are querying is the settlement record, not the order flow. A resting order, a cancel, a book that widened for ten minutes and a quote that was never hit leave no trace anywhere in the data — they never became a transaction. Three consequences follow. Depth cannot be reconstructed from trades, so "liquidity" on a chain-derived dashboard is always a proxy. The trade table carries mint and merge matching alongside ordinary buyer-to-seller fills, because the system creates outcome tokens when there are not enough sellers and unwinds matched pairs back into collateral, so a row is not reliably a transfer between two traders. And indexed data is not a tape: Dune documents roughly an hour's refresh on these tables, which is fine for a daily chart and wrong for anything that claims to be live.

One wallet is not one person, and one person is not one wallet. Polymarket trades through proxy wallets, and Dune's own lookup table exists precisely because the address doing the trading is not the address that owns it: it maps Safe and Magic proxy wallets to owner addresses with creation and first-funding metadata. That mapping collapses some duplicates and creates none of the identity a leaderboard implies — an owner can hold many proxies, and a proxy can be operated by more than one person. What wallet tracking shows, and what it cannot is that argument in full, and it is the page to read before you put a rank on a screen. If the ranking itself is what you wanted, five products already publish one and differ mainly in whether they publish the rule behind the label: the comparison is there.

A dollar amount is a token transfer until you decompose it. The collateral leg of a fill is a stablecoin transfer and the position leg is an ERC-1155 transfer, and neither on its own is a position. What you want is shares and price, held apart: the curated trade table gives you shares, price and amount as separate columns precisely because summing dollars answers a different question from summing contracts. Sum dollars and you have notional, not the cash that changed hands — the same distinction Artemis carries in two separate fields, with premium at roughly half of notional across a typical book. Anyone reading raw transfers instead of a decoded table has to do that decomposition themselves, per matching type, including the split and merge legs where collateral moves with no counterparty on the other side. What a trade actually costs is the fee half of the same arithmetic.

Holdings are the gated column, and the free derivation is lossy. The daily (day, address, token_id) holdings table is an Enterprise entitlement, as are the lifecycle actions — splits, merges, redemptions and neg-risk converts. On the public tables you can only derive a position by accumulating trades, and that misses every one of those actions plus any direct token transfer between wallets. The published holdings table also drops rows by design: zero balances disappear the day a wallet exits, and from the day after a decision, concluded losers and sub-cent winner dust are excluded. A position chart that does not account for either will show holdings that quietly stop existing.

And the structural one: this method does not extend to the other venue. Kalshi is a regulated exchange with no public chain behind it. Dune does carry Kalshi market details, per-fill trades and hourly candles — sourced from Kalshi's own public reporting rather than from any chain, and gated to Enterprise — plus two public legacy tables of daily aggregates where a single date and ticker can produce several rows at different price levels. What is nowhere, at any price, is a per-account position record, because a regulated exchange reports positions to its regulator rather than publishing them. So a dashboard built the way this page describes is a Polymarket dashboard. The wallet column, the holder table, the leaderboard and the flow chart have no counterpart on the other venue, and a cross-venue version of this project is a different project with a different data budget.

If you outgrow this

If the question turns out to be about depth rather than fills, PolyOrderbooks sells recorded one-second L2 books — Polymarket crypto markets only, on a rolling lookback of three days free and up to 120 days paid, materialised uniform from a sparse capture rather than read every second.

If you would rather own the files than query somebody's warehouse, Prediction Market Analysis is a pre-collected Parquet archive of both venues' trades that loads into whatever you already run, at the cost of being a snapshot with no versioned vintage.

If the dashboard has to cover more than one venue, that is a purchase rather than a query: tools that cover more than one venue is the listing and Adjacent vs DepthFeed vs Predexon is the head to head. Every one of them flattens a difference to fit two venues into one schema, and the difference being flattened here is the one the section above is about.

And if you need the chain data without a vendor between you and it, Polymarket publishes its own subgraph repository — separate indexes for activity, open interest, P&L and the order book — which you can deploy against your own Polygon node. That trades a credit allowance for an indexer to operate, a node to pay for and a schema to keep up with when the exchange contracts move, which is the whole reason the curated tables exist.