Leaderboard of PREDICTION MARKETS (Polymarket, on Polygon) by traded USD volume in a
recent window — which questions people are actually betting on right now, ranked. Use
for "hottest / most traded prediction markets", "biggest Polymarket markets today",
"what is Polymarket trading today", and — with query or category — "the biggest
BITCOIN markets this week", "most traded election markets today".
NOT a wallet ranking (use polymarket_top_traders),
NOT the individual trades of one market (use polymarket_market_trades), NOT a market
you already know by name (use polymarket_find_markets), and NOT token/DEX trading —
trending_tokens and top_traders_by_token cover swaps of ERC-20 tokens, an entirely
different market.
Every figure here is computed from the market's own settled on-chain orders.
READ THE FIRST ROW BEFORE ANYTHING ELSE. Every response starts with one row where
Row_Type='scope'; the ranked markets follow as Row_Type='market'. Every row carries
Window_Start / Window_End (the period ranked, ending now), Last_Indexed_Time (the
time of the newest order recorded so far, across all markets) and Data_Lag_Minutes
(how far that is behind the clock), and the scope row's Note spells them out. Orders
reach this data some minutes after they happen - usually well under half an hour,
occasionally several hours. So a response with ONLY the scope row is not by itself
"no trading": if Last_Indexed_Time is earlier than Window_Start, the window's orders
have simply not arrived yet - say so and widen window_hours, never report the markets
as quiet. If Last_Indexed_Time falls inside the window, nothing matched. On a short
window a Data_Lag_Minutes that is a sizable share of the window also means its totals
are understated.
Each market row returns: the question id (the key every other polymarket_* tool
takes), its title, order count, USD volume, outcome shares traded, volume-weighted
average price, distinct trading wallets, number of outcomes, the trading fees charged
on the market in the window, Trade_Collateral_Symbol + Trade_Collateral_Token (the
collateral token the market's orders settle in), and the first/last trade time in the
window. The collateral a market was REGISTERED with (Registered_Collateral_* in
polymarket_market_info / polymarket_market_odds) can be a different token; compare
the token addresses, not just the symbols - two different contracts can both be
called USDC.
PRICE IS A PROBABILITY. Every outcome trades between 0 and 1 and is the market's
implied chance of that outcome. Avg_Price here is blended across ALL outcomes of the
market, so on a two-outcome market it sits near 0.5 by construction — it is a
volume-weighted average cost, NOT the market's odds. For the odds of each outcome use
polymarket_market_odds.
VOLUME IS NOT PROFIT. These are gross USD amounts that changed hands; no profit,
loss or open position is computed anywhere in this tool.
A matched trade leaves order records for the resting orders it filled and one for
the order that took the liquidity. The two classes do NOT mirror each other one to
one - a match can pair orders on opposite outcomes at complementary prices - so
counting both is NOT a fixed multiple of the resting-order figure: it is not "double",
and the ratio moves from market to market and window to window. By default only the
resting-order side is counted - order_side='maker' - and that is the basis to use for
market volume. Use order_side='taker' to rank by the liquidity-taking side instead,
or 'both' only if you deliberately want every order record. All three are real
orders; this is a choice of which side to measure, not a filter for bad data.
FEES_USD DOES NOT MOVE WITH order_side. The trading fee is charged to the side that
takes liquidity, in the market's collateral currency, and the resting orders it
matched are not charged for the same fill — so unlike volume, a fee is never counted
twice and never needs a side chosen for it. It is the market's whole fee for the
window EXCEPT for the identity-less orders described below, which are excluded from
this ranking and therefore from this total as well. Fees are a recent
feature of these markets: a market that traded before they existed shows 0, and that
is a real 0, not missing data. Fees_Usd is revenue taken by the venue, not a cost that
has been subtracted from Volume_Usd.
RANK A SUBJECT WITH query AND/OR category. query matches the market title as a
substring; category picks one of sports / crypto / esports / politics / weather /
stocks / mentions / entertainment / other. Setting both applies both conditions.
"Top bitcoin markets over 7 days" is then a single call — do NOT pull a large limit
and filter the titles yourself. polymarket_find_markets is the tool for BROWSING a
subject (it orders by creation time and knows about open vs resolved); this tool is
the one that orders by money. A filter narrows the RESULT, not the work: query is
free, but category has to consult market registrations as well, which makes it
several times slower than the same call without it. Keep the window small when you
set a category.
ORDERS WITH NO MARKET IDENTITY ARE EXCLUDED, AND THE LOSS IS NOT ALWAYS SMALL. Some
order records carry no question id; they all share the empty one, so ranking them
would produce a single nameless entry aggregating unrelated markets, which on a
window reaching into mid-2026 would outrank every real market. They are dropped
instead. On recent windows that costs almost nothing, but the further back the
window reaches into 2026 the larger the share of such orders becomes, and on some
individual markets it was most of their volume — so a market can be ranked well
below its true size or pushed off the list entirely. Prefer recent windows for
ranking, and read a specific market's real total with polymarket_market_odds, which
counts those orders through the outcome asset id.
COST SCALES WITH THE WINDOW, NOT WITH limit — this ranking has to look at every
market, so a 7-day window is several times the work of the 24-hour default however
small a limit you ask for. Keep window_hours as small as the question allows, and
expect a window that ends far in the past to cost more than a recent one of the same
length. May time out on very wide windows — retry with a smaller window_hours.
