How We Rank Polymarket Wallets

Transparent, reproducible, and easy to understand.

Ranking metric

Wallets are ranked by the aggregate current USD value of their active positions across the active markets currently indexed by our system.

We deliberately do not rank by:

  • realized P&L
  • win rate
  • trading volume
  • number of trades
  • an opaque smart-money score

Definition of an active position

A position counts as active when:

  • position size is at least 0.01 tokens, and
  • its current USD value is at least $1.00, and
  • it is not redeemable (the market has not resolved).

Redeemable / resolved positions are excluded. These thresholds are configurable and may be adjusted as we observe real API data.

What counts as a whale: the bar is per category

A whale position is an active position at or above its category's whale bar. The bar starts at the default $2,500.00 and is derived per category by stepping down the ladder $2,500.00 → $1,250.00 → $625.00 → $312.50 → $250.00 until the category holds at least 25 whale positions, and never below the last rung. A category keeps the bar it had while it still holds that many, so the bar does not drift between runs.

The consequence is deliberate and disclosed: “whale” is not comparable across categories — a $600 position can be a whale in one category and not in another. Every question row names the bar it was ranked against in the hint of its category, and every category page states its own bar.

Effective bars in the currently published run: Crypto $2,500.00 Culture $2,500.00 Economy $2,500.00 Elections $2,500.00 Finance $2,500.00 Geopolitics $2,500.00 Politics $2,500.00 Science $2,500.00 Sports $2,500.00 Tech $2,500.00 Weather $2,500.00 AI $1,250.00 Business $1,250.00 Other $250.00

What we store: whale positions

Every fetched position counts towards a wallet's total and towards every ranking. We only store positions at or above the whale bar of their own category (default $2,500.00, lower wherever a category steps its bar down), so the dataset scales with the capital instead of with the number of holders. Wallet pages therefore list that wallet's whale positions; the number of smaller active positions we counted but do not list is shown on the page itself. Measured on a live sample of six questions (66,723 positions, $28.9M of capital): a $2,500 floor keeps 0.79 % of the rows and 94.9 % of the capital; a second, independent sample gave 0.58 % / 94.2 %. The largest samples so far are the whole indexed universe (up to 1,208,611 fetched rows over 656 questions, at the bars the derivation stepped to): 0.24 % of the rows — 1.7 % of the active ones — holding 88.5 % of the active capital. The exact share depends on the sample; every sample agrees that a fraction of a percent of the rows carries the large majority of the capital.

Coverage: how complete is a question's holder list?

Polymarket returns positions one page per outcome token — a binary question has two of them — and we follow at most 20 pages of 500 rows per outcome. That is up to 10000 position rows for a single outcome, and a question with several outcomes can hold several times that. When an outcome has more position rows than that, we hold a prefix of its holder list.

Every question row states its own coverage in the hint on its question: complete together with the number of position rows we held, or truncated at the page cap together with the number of rows we held when we stopped — and coverage unknown for a row published before we recorded coverage at all. The two exceptional states — truncated at the page cap and coverage unknown — additionally stay visibly marked in the row, without a hover, because they are exactly what makes the row's other numbers lower bounds; a complete row carries no marker, since there is nothing to warn about. A truncated question is still ranked, still stored and still shown — what changes is that the page does not claim to be complete: its capital and holder counts are lower bounds, and the real holder list upstream is longer.

The number we publish is the count of position rows we actually hold for that question, not an estimate of how many exist.

How to read the bars

Two columns of a question row carry a small bar: Whale Capital and Whale Holders. A bar encodes direction only:

  • green is the outcome named “Yes”, red the one named “No” — the colour comes from the name, never from the position of an outcome in the row (the stored split is ordered by value, so the leading side is not automatically Yes). One neutral grey bar covers every other outcome shape: a question with a single outcome, with three or more, or with two named candidates (e.g. two companies) has no Yes/No pair to colour, so the bar says “no pair” and the split itself stays in the hint.
  • The bar is never scaled to the size of the numbers behind it — a $1M question and a $2 one with the same split draw the same bar. The number shown next to it carries the magnitude; the numbers per outcome sit in the hint.
  • Whale Capital splits a question's whale capital across its outcomes; Whale Holders splits its whale wallets. A wallet holding both sides of the same question counts on both, so the per-outcome counts can add up to more than the row's own holder count.
  • The two outcome columns (Outcomes USD and Outcomes N) show one number per outcome with the same colours on the outcome's label instead of two more bars; their hint carries the row total, which is what the former “Total Capital” and “Positions” columns used to show.
  • A number we do not have is never shown as 0: the cell shows “—” and its hint names the reason — not recorded for this run (the value is ours to publish and no pass wrote it), no quotes upstream (the pass looked for a binary quote pair and there was none) or no ask recorded for these outcomes (we hold a quote entry for the question, but no usable ask in it). A recorded zero stays a zero, because that is a measurement.

The Ask column quotes what each outcome costs to enter, as the published run's discovery pass saw it — it is not a live price, so every row names the pass it came from.

History: what we keep over time

Every 24 successful passes we write one dated snapshot of the whale positions we hold — wallet, question, outcome, size, average price, current price, current USD value, category and the effective whale bar each row was measured against. A pass that fails or ends partial writes no snapshot, and neither does a pass that finds a newer successful run already published: the history only ever holds states the site actually showed. Snapshots are keyed by date, so two consecutive days can be compared; a repeated date replaces that day rather than doubling it.

Sub-whale positions are not part of the history: that is what keeps the series small enough to keep for years (see “What we store”).

Data source

Polymarket public market data. We discover currently-open markets, fetch their positions, normalize the records, and aggregate position values by wallet locally. The browser never contacts Polymarket directly.

Coverage

The leaderboard reflects the markets currently indexed by our system (657 questions indexed in the published sync run). It is not a claim of perfect global coverage.

Freshness

Every number on this site comes from a single, immutable published artifact — one versioned pass, never a pass that is still running or that failed, published at 2026-10-10 19:10:16 UTC (run #1), indexing 657 questions, with 0 question(s) failed. Each page names the artifact its figures came from.

Data is refreshed periodically, never on a request. The cadence we state is the median spacing of the last 24 published passes: ≈ every 60.8667 minutes — a measurement taken from the published artifacts themselves, not a configured interval the app cannot verify. This is not real-time: a pass that fails or exceeds the configured failure rate (5%) is not published, so the previous published artifact stays visible, and every figure on the site names the artifact it came from.