Large trade tracking on prediction markets: what a record can prove

Correction (July 16, 2026): the original opening described a specific buy, its timestamp, price move, time to resolution, and profit, with no saved provider response or reproducible database query behind it. Its price-impact chart was a simulated path. We retracted the event and removed the chart.

The earlier version also overstated how complete and fast the feed is, what its scores mean, and whether watching large trades is profitable or predictive. None of those claims had a captured availability history or a measured outcome cohort, so we withdrew them instead of softening them into new estimates.

The charts that remain use made-up numbers to explain mechanics. Each caption says it is illustrative, and none shows a real market, wallet, or trade.

No fixed dollar amount makes a trade informative. Read size beside the market's liquidity, order-book depth, price, direction, and the trader's existing exposure. A large trade can be inventory management, a hedge, a position transfer, or a directional view, and the record alone cannot tell you which.

The chart below groups sizes with made-up dollar values. It is not a sample of real trades, a threshold recommendation, or evidence that larger trades predict outcomes.

Start with the fields a record establishes: provider, market, outcome, side, price, size, wallet, transaction hash when available, and provider timestamp. Then check the market's resolution rules and current order book, each at its own retrieval time.

Size relative to liquidity suggests possible price impact. It does not show that the trader knows anything. Wallet history adds context only when its identity, scope, and accounting basis are explicit. A grade or historical win rate describes past results, not why the wallet placed this trade.

Timing is descriptive too. A trade shortly before a public event may deserve a look, but timing alone cannot establish advance knowledge or cause, or show that the record arrived without delay.

The 0xinsider large-trade feed is a projection of what we ingest, not an exhaustive blockchain ledger. Provider outages, delayed messages, missing or invalid fields, market-identity joins, and product thresholds all change which trades appear. A trade missing from the feed may still have happened.

The primary parser for Polymarket's RTDS stream admits a row only with a finite price strictly between 0 and 1, a finite positive size, a positive, representable unix-seconds timestamp no more than 5 minutes in the future, a typed wallet, a canonical 0x-prefixed 32-byte condition ID, a BUY or SELL side, and an explicit binary outcome. A nonbinary outcome index is rejected instead of guessed from the text. Missing or invalid fields emit skip telemetry instead of passing as healthy data.

The liveness check is stricter: a valid replay older than 5 minutes can still be stored but does not refresh the watchdog. The provider transaction hash is optional, and our internal event identity handles replays without posing as provider provenance.

Use the feed to find trades worth checking. Before you make a claim about one, save the provider or chain response, the transaction hash, the retrieval time, the market contract, and any query behind the context. A feed timestamp is the stored event time; it does not prove how fast the trade reached you.

A review score is a fixed formula over trade fields and stored trader context: trade size, the trader's win rate, a bonus when a high-win-rate trader buys a cheap side, and a recency term, scaled to a public value. It is not the probability that the trade wins, proof that the wallet is skilled, or a forecast of return.

Use the score to decide what to check first, then inspect the trade, the market, the wallet, how fresh the inputs are, and when they were retrieved. A missing or stale input changes what the score means even when the number looks normal.

A hot-markets view adds up the trades the product has ingested. It shows which markets rank highest under that window and formula. It cannot show the total money flowing into a market, whether the wallets act independently, or that news is coming.

Treat a rising rank as a reason to open the trades behind it and the market's current state. The heatmap below uses invented names and counts to show the layout only; it is not a dated snapshot.

Without Pro, the large-trade feed is delayed; with Pro it is live. The pricing page owns the exact delay and lookback, which can change, so this article does not repeat them.

The delay does not make the feed complete, and it does not tell you how far a price moved in the meantime.

Delayed records still work for looking back, as long as you keep their source and scope. Showing that speed changes an outcome would take a measured cohort with entry rules, comparison prices, fees, and missing-data handling. This article has no such cohort and makes no claim about lost edge or profit.

The curve below is illustrative, not a measured relationship between delay and return.

0xinsider runs fixed scoring tracks over the records it has. Each track stores the inputs it fired on for later review: combinations of wallet age, trade size, the price paid, clustering, or a position split into slices. A flag is not a finding of insider trading, coordination, identity, intent, or illegality.

Check the stored track and its inputs before repeating a flag. Missing trades or a thin wallet history change the context, and several wallets can be one person. The old severity field is unused, so this guide does not map scores to FLAG or WATCH levels.

Treat a large trade as a lead to check, not a trade to copy. Confirm the market and its resolution rules, check current liquidity and price, keep provider time separate from retrieval time, and save the source response before making any factual claim.

To test a rule, write down the filter, time window, missing-data policy, price source, fees, and outcome rule before you look at results. Apply the same rules to every record, and count failures as missing data instead of dropping them.

The spike chart below uses made-up multipliers to compare a trade with a wallet's usual size. It does not show real wallet behavior or prove that a jump in size means anything.