Prediction Market Wallet Analytics: A Practical Guide
Prediction Market Wallet Analytics: A Practical Guide
Prediction Market Wallet Analytics: A Practical Guide
How wallet analytics works in prediction markets: PnL, skill scoring, wallet clustering and cross-venue limits, with the data and API steps to build it.
Prediction Market Wallet Analytics: A Practical Guide
Prediction market wallet analytics is the practice of turning raw on-chain trades into per-address measurements: realized and unrealized PnL, entry timing, position sizing, and the clustering of addresses that probably belong to one entity. Done well, it separates traders with a repeatable edge from traders who got lucky on one market. Done badly, it produces leaderboards that reward variance. This guide covers the metrics that hold up, how clustering works, where the data comes from, and what breaks when you go cross-venue.
AssymetrixSee Wallet Signals Across MarketsAssymetrix brings Smart Money wallet tracking and Trader Skill Scores together with cross-venue prediction market data.Explore the data API
TL;DR
Wallet analytics only works on venues where activity is publicly attributable to an address, which today means on-chain venues such as Polymarket and Limitless, not account-based venues.
Raw PnL is a weak signal. Combine it with sample size, market diversity, entry price versus closing price, and drawdown before you call a wallet “skilled”.
Wallet clustering by funding source reduces double counting, but it produces probabilities, not proof. Treat clusters as hypotheses.
Build on a normalized data layer with canonical market IDs, so one wallet’s history reconciles across venues and resolutions.
Table of Contents
What wallet analytics measures
Why raw PnL misleads
Wallet clustering: grouping addresses into entities
Where the data comes from
A minimal pipeline, step by step
From scores to signals
Limits you should plan for
Our perspective
Build on unified data
Sources
What wallet analytics measures
A prediction market contract pays a fixed amount if an event resolves your way, so every trade is a bet at a stated probability. A wallet’s history is therefore a list of probabilistic forecasts with money attached. That makes it unusually clean data for evaluating forecasting skill, and it is the reason quants care about it.
The core measurements fall into four groups:
Performance: realized PnL, unrealized PnL on open positions, return on capital deployed, win rate by market count and by dollars.
Behavior: average holding period, how often the wallet adds to losing positions, share of volume taken as maker versus taker.
Timing: entry price versus the price at resolution or at a fixed horizon, and whether the wallet buys before or after large price moves.
Concentration: share of PnL from the single best market, category exposure, and number of distinct markets traded.
The last group matters most and is skipped most often. A wallet with 400% return from one election position is a different object from one with 40% across 300 uncorrelated markets. For a deeper treatment of the accounting, see our builder’s guide to wallet PnL analytics.
Why raw PnL misleads
Public leaderboards usually rank by profit or by volume. Both are poor skill proxies for three reasons.
Survivorship. With enough addresses trading, some will post extreme returns by chance. Ranking the top of a large population guarantees you will find lucky ones. Any figure quoted for “top wallets” should be read with the size of the population it was selected from in mind.
Capital size. Dollar profit favors large bankrolls. A wallet that turns $2,000 into $9,000 may be better at forecasting than one that turns $500,000 into $520,000.
Resolution timing. Positions held to expiry on near-certain outcomes inflate win rate. Buying at 96 cents and collecting a dollar is a win, but it says little about forecasting.
Metrics that hold up better
Metric | What it answers | Weakness |
|---|---|---|
Return on capital deployed | Efficiency, independent of bankroll | Sensitive to a few large trades |
Closing-line value (entry vs. later price) | Did the wallet buy before the market moved its way? | Needs reliable price history |
Brier-style score on entry prices | Calibration of implied forecasts | Needs enough resolved markets |
Max drawdown | Risk taken to earn the return | Needs a full time series |
Market count and diversity | Is the sample large enough? | Says nothing about quality alone |
Combining these into a single number is what we call a skill score. Whatever formula you pick, publish the minimum sample size below which a wallet is not scored. Under 30 resolved markets, we would not rank a wallet at all.
Wallet clustering: grouping addresses into entities
On-chain venues let anyone create addresses freely. One trader can split capital across many wallets, and one wallet can be a proxy for a trading firm. If you count each address as an independent trader, you overstate how many people agree on a position.
Clustering tries to merge addresses that likely share an owner. The common heuristics are:
Funding source. Wallets funded from the same upstream address, especially in a narrow time window, are candidates for one cluster. Open-source detection projects use exactly this idea, tracing USDC funding on Polygon to group wallets with shared funders.
Behavioral similarity. Identical position sizes, near-simultaneous entries in the same markets, and mirrored buy and sell sides.
Shared infrastructure. Common exchange deposit addresses are a trap here: thousands of unrelated users fund from the same exchange hot wallet, so you must exclude known exchange and bridge addresses before linking anything.
What clustering cannot tell you
A cluster is a statistical claim. Two wallets funded by the same exchange withdrawal are not necessarily related; two unrelated funding paths can still belong to one person. We recommend storing a confidence value with each link and letting downstream models decide the threshold. Never publish a cluster as an accusation. If your use case is surveillance of possible information advantage, treat the output as a lead for human review.
Where the data comes from
On-chain prediction markets expose trades and positions in several layers. A practical stack combines three:
Venue APIs for market metadata, order books and wallet-level positions. Polymarket’s public data service, for example, has a /positions endpoint that takes a wallet address and returns current holdings, alongside separate endpoints for closed positions and trades, with pagination limits you must respect.
Chain data for funding paths and transfers, which is what clustering needs and venue APIs rarely provide.
A historical store so you can recompute metrics as definitions change, rather than only seeing the present snapshot.
The pain is in the joins. Venues identify the same real-world question with different IDs, tick sizes and resolution conventions. Without a canonical market ID layer, a wallet that trades the same event on two venues looks like two unrelated histories. Our write-up on cross-venue data with canonical IDs explains the schema in detail.
A minimal pipeline, step by step
Collect trades per wallet. Pull full trade history, not only open positions. Closed positions without trades lose entry timing.
Normalize prices to probabilities. Store every trade as price in the 0 to 1 range, side, size in dollars, and timestamp in UTC.
Attach resolution outcomes. Join each market to its final result via a canonical ID, and flag voided or ambiguous markets so they do not distort scores.
Compute per-market PnL. Use average cost basis per wallet and market. Count fees explicitly.
Aggregate with sample controls. Compute return on capital, drawdown and diversity. Drop wallets under your sample threshold.
Cluster, then re-aggregate. Merge linked wallets into entities and recompute, so a split bankroll is scored as one trader.
Backtest the score. Rank wallets using data up to a cutoff date, then check whether the top group beats the rest out of sample. If it does not, the score is describing luck.
Step 7 is the one that separates analytics from decoration. For the quant side of this, our Polymarket on-chain analysis guide walks through the structure of the data.
From scores to signals
Once wallets are scored and clustered, you can build signals on top:
Smart Money flow: net dollar buying by high-score entities in a market over a window, versus the crowd. Our guide to tracking smart money wallets on Polymarket covers the selection rules.
Divergence: when top-scoring entities hold the opposite side of the current price drift.
Cross-venue gaps: the same event priced differently on two venues, which wallet data can help explain, for example whether one venue’s price is moved by a single large entity.
Treat any signal as an input to a model, not as a trade instruction. Copying wallets has costs: you enter after them, at a worse price, and thin books can erase the edge. Measure that slippage directly before you rely on a wallet-following strategy.
When you evaluate any third-party analytics tool or data source, check who runs it before you send it wallet addresses or API keys. A site trust check such as website trust scores for crypto sites is one way to screen unfamiliar domains quickly.
Limits you should plan for
Not every venue is wallet-addressable. Account-based, regulated venues such as Kalshi do not publish trader identities the way a public chain does. For those venues, analytics rests on market-level data such as prices, volume and order books, not on individual traders. Cross-venue wallet analytics therefore means on-chain venues for the wallet layer and all venues for the market layer.
Addresses are not people. Proxy contracts, custodial front ends and market-making bots all blur the picture. A wallet that trades a thousand times a day is probably software, and should be scored in a separate class from discretionary traders.
Holdings-based analysis has analogues elsewhere. Analysts in other markets use the same logic of reading balances against price, as in this look at Bitcoin treasury holdings versus market value. The lesson transfers: a holdings number only means something next to a price and a time.
Definitions drift. If you change how PnL handles fees or voided markets, historical scores change. Keep a versioned history.
Our perspective
We built Assymetrix as venue-neutral infrastructure, and wallet analytics is where that choice pays off. A single venue’s dashboard can tell you what happened on that venue. It cannot tell you whether a trader who looks sharp on one platform is also calibrated elsewhere, or whether two venues disagree because of one entity’s order flow.
Our view is that the hard problem is not the dashboard, it is the data layer: normalized schemas, canonical market IDs, and deep history, so that metrics can be recomputed and backtested. That is why our platform is built on roughly 1.5 terabytes of historical data covering nearly one billion rows of trading activity across Polymarket, Kalshi and Limitless. A skill score you cannot backtest is an opinion.
We also think restraint is a feature. Wallet clusters should carry confidence values, scores should carry sample sizes, and none of it should be presented as certainty.
— Dean
Build on unified data
If you are building wallet analytics, the slowest part is usually ingestion and normalization, not modeling. Our Data API gives developers, quants and AI agents one integration for cross-venue prediction market data, with Smart Money wallet tracking and Trader Skill Scores available in the intelligence layer. Pricing is not published on the site, so check the page for current tiers.
For Python workflows, start with the Python developer API guide. For research needing long history, the historical data access guide explains the backfill.
FAQ
What is wallet analytics in prediction markets?
It is the measurement of individual addresses’ trading history: PnL, timing, sizing and diversity. On public-chain venues every trade is attributable to an address, so you can score forecasting quality at the trader level. The output feeds leaderboards, signals and research.
How does wallet clustering work?
Most approaches link addresses that share a funding source or behave in lockstep, after excluding exchange and bridge addresses that many unrelated users share. The result is a probabilistic grouping of addresses into entities. Store a confidence with every link and treat clusters as hypotheses, not identities.
Can I run wallet analytics on Kalshi?
Not at the trader level in the same way. Kalshi is account-based, so individual traders are not publicly addressable like on-chain wallets. You can still analyze its prices, volume and order books, and compare them with wallet-derived signals from on-chain venues.
Is a high-PnL wallet worth following?
Not on PnL alone. Check sample size, market diversity, drawdown and whether the wallet’s entries beat later prices. Then measure your own slippage from entering after it trades, because that often removes the edge.
Sources
Prediction Market Wallet Analytics: A Practical Guide
Prediction market wallet analytics is the practice of turning raw on-chain trades into per-address measurements: realized and unrealized PnL, entry timing, position sizing, and the clustering of addresses that probably belong to one entity. Done well, it separates traders with a repeatable edge from traders who got lucky on one market. Done badly, it produces leaderboards that reward variance. This guide covers the metrics that hold up, how clustering works, where the data comes from, and what breaks when you go cross-venue.
AssymetrixSee Wallet Signals Across MarketsAssymetrix brings Smart Money wallet tracking and Trader Skill Scores together with cross-venue prediction market data.Explore the data API
TL;DR
Wallet analytics only works on venues where activity is publicly attributable to an address, which today means on-chain venues such as Polymarket and Limitless, not account-based venues.
Raw PnL is a weak signal. Combine it with sample size, market diversity, entry price versus closing price, and drawdown before you call a wallet “skilled”.
Wallet clustering by funding source reduces double counting, but it produces probabilities, not proof. Treat clusters as hypotheses.
Build on a normalized data layer with canonical market IDs, so one wallet’s history reconciles across venues and resolutions.
Table of Contents
What wallet analytics measures
Why raw PnL misleads
Wallet clustering: grouping addresses into entities
Where the data comes from
A minimal pipeline, step by step
From scores to signals
Limits you should plan for
Our perspective
Build on unified data
Sources
What wallet analytics measures
A prediction market contract pays a fixed amount if an event resolves your way, so every trade is a bet at a stated probability. A wallet’s history is therefore a list of probabilistic forecasts with money attached. That makes it unusually clean data for evaluating forecasting skill, and it is the reason quants care about it.
The core measurements fall into four groups:
Performance: realized PnL, unrealized PnL on open positions, return on capital deployed, win rate by market count and by dollars.
Behavior: average holding period, how often the wallet adds to losing positions, share of volume taken as maker versus taker.
Timing: entry price versus the price at resolution or at a fixed horizon, and whether the wallet buys before or after large price moves.
Concentration: share of PnL from the single best market, category exposure, and number of distinct markets traded.
The last group matters most and is skipped most often. A wallet with 400% return from one election position is a different object from one with 40% across 300 uncorrelated markets. For a deeper treatment of the accounting, see our builder’s guide to wallet PnL analytics.
Why raw PnL misleads
Public leaderboards usually rank by profit or by volume. Both are poor skill proxies for three reasons.
Survivorship. With enough addresses trading, some will post extreme returns by chance. Ranking the top of a large population guarantees you will find lucky ones. Any figure quoted for “top wallets” should be read with the size of the population it was selected from in mind.
Capital size. Dollar profit favors large bankrolls. A wallet that turns $2,000 into $9,000 may be better at forecasting than one that turns $500,000 into $520,000.
Resolution timing. Positions held to expiry on near-certain outcomes inflate win rate. Buying at 96 cents and collecting a dollar is a win, but it says little about forecasting.
Metrics that hold up better
Metric | What it answers | Weakness |
|---|---|---|
Return on capital deployed | Efficiency, independent of bankroll | Sensitive to a few large trades |
Closing-line value (entry vs. later price) | Did the wallet buy before the market moved its way? | Needs reliable price history |
Brier-style score on entry prices | Calibration of implied forecasts | Needs enough resolved markets |
Max drawdown | Risk taken to earn the return | Needs a full time series |
Market count and diversity | Is the sample large enough? | Says nothing about quality alone |
Combining these into a single number is what we call a skill score. Whatever formula you pick, publish the minimum sample size below which a wallet is not scored. Under 30 resolved markets, we would not rank a wallet at all.
Wallet clustering: grouping addresses into entities
On-chain venues let anyone create addresses freely. One trader can split capital across many wallets, and one wallet can be a proxy for a trading firm. If you count each address as an independent trader, you overstate how many people agree on a position.
Clustering tries to merge addresses that likely share an owner. The common heuristics are:
Funding source. Wallets funded from the same upstream address, especially in a narrow time window, are candidates for one cluster. Open-source detection projects use exactly this idea, tracing USDC funding on Polygon to group wallets with shared funders.
Behavioral similarity. Identical position sizes, near-simultaneous entries in the same markets, and mirrored buy and sell sides.
Shared infrastructure. Common exchange deposit addresses are a trap here: thousands of unrelated users fund from the same exchange hot wallet, so you must exclude known exchange and bridge addresses before linking anything.
What clustering cannot tell you
A cluster is a statistical claim. Two wallets funded by the same exchange withdrawal are not necessarily related; two unrelated funding paths can still belong to one person. We recommend storing a confidence value with each link and letting downstream models decide the threshold. Never publish a cluster as an accusation. If your use case is surveillance of possible information advantage, treat the output as a lead for human review.
Where the data comes from
On-chain prediction markets expose trades and positions in several layers. A practical stack combines three:
Venue APIs for market metadata, order books and wallet-level positions. Polymarket’s public data service, for example, has a /positions endpoint that takes a wallet address and returns current holdings, alongside separate endpoints for closed positions and trades, with pagination limits you must respect.
Chain data for funding paths and transfers, which is what clustering needs and venue APIs rarely provide.
A historical store so you can recompute metrics as definitions change, rather than only seeing the present snapshot.
The pain is in the joins. Venues identify the same real-world question with different IDs, tick sizes and resolution conventions. Without a canonical market ID layer, a wallet that trades the same event on two venues looks like two unrelated histories. Our write-up on cross-venue data with canonical IDs explains the schema in detail.
A minimal pipeline, step by step
Collect trades per wallet. Pull full trade history, not only open positions. Closed positions without trades lose entry timing.
Normalize prices to probabilities. Store every trade as price in the 0 to 1 range, side, size in dollars, and timestamp in UTC.
Attach resolution outcomes. Join each market to its final result via a canonical ID, and flag voided or ambiguous markets so they do not distort scores.
Compute per-market PnL. Use average cost basis per wallet and market. Count fees explicitly.
Aggregate with sample controls. Compute return on capital, drawdown and diversity. Drop wallets under your sample threshold.
Cluster, then re-aggregate. Merge linked wallets into entities and recompute, so a split bankroll is scored as one trader.
Backtest the score. Rank wallets using data up to a cutoff date, then check whether the top group beats the rest out of sample. If it does not, the score is describing luck.
Step 7 is the one that separates analytics from decoration. For the quant side of this, our Polymarket on-chain analysis guide walks through the structure of the data.
From scores to signals
Once wallets are scored and clustered, you can build signals on top:
Smart Money flow: net dollar buying by high-score entities in a market over a window, versus the crowd. Our guide to tracking smart money wallets on Polymarket covers the selection rules.
Divergence: when top-scoring entities hold the opposite side of the current price drift.
Cross-venue gaps: the same event priced differently on two venues, which wallet data can help explain, for example whether one venue’s price is moved by a single large entity.
Treat any signal as an input to a model, not as a trade instruction. Copying wallets has costs: you enter after them, at a worse price, and thin books can erase the edge. Measure that slippage directly before you rely on a wallet-following strategy.
When you evaluate any third-party analytics tool or data source, check who runs it before you send it wallet addresses or API keys. A site trust check such as website trust scores for crypto sites is one way to screen unfamiliar domains quickly.
Limits you should plan for
Not every venue is wallet-addressable. Account-based, regulated venues such as Kalshi do not publish trader identities the way a public chain does. For those venues, analytics rests on market-level data such as prices, volume and order books, not on individual traders. Cross-venue wallet analytics therefore means on-chain venues for the wallet layer and all venues for the market layer.
Addresses are not people. Proxy contracts, custodial front ends and market-making bots all blur the picture. A wallet that trades a thousand times a day is probably software, and should be scored in a separate class from discretionary traders.
Holdings-based analysis has analogues elsewhere. Analysts in other markets use the same logic of reading balances against price, as in this look at Bitcoin treasury holdings versus market value. The lesson transfers: a holdings number only means something next to a price and a time.
Definitions drift. If you change how PnL handles fees or voided markets, historical scores change. Keep a versioned history.
Our perspective
We built Assymetrix as venue-neutral infrastructure, and wallet analytics is where that choice pays off. A single venue’s dashboard can tell you what happened on that venue. It cannot tell you whether a trader who looks sharp on one platform is also calibrated elsewhere, or whether two venues disagree because of one entity’s order flow.
Our view is that the hard problem is not the dashboard, it is the data layer: normalized schemas, canonical market IDs, and deep history, so that metrics can be recomputed and backtested. That is why our platform is built on roughly 1.5 terabytes of historical data covering nearly one billion rows of trading activity across Polymarket, Kalshi and Limitless. A skill score you cannot backtest is an opinion.
We also think restraint is a feature. Wallet clusters should carry confidence values, scores should carry sample sizes, and none of it should be presented as certainty.
— Dean
Build on unified data
If you are building wallet analytics, the slowest part is usually ingestion and normalization, not modeling. Our Data API gives developers, quants and AI agents one integration for cross-venue prediction market data, with Smart Money wallet tracking and Trader Skill Scores available in the intelligence layer. Pricing is not published on the site, so check the page for current tiers.
For Python workflows, start with the Python developer API guide. For research needing long history, the historical data access guide explains the backfill.
FAQ
What is wallet analytics in prediction markets?
It is the measurement of individual addresses’ trading history: PnL, timing, sizing and diversity. On public-chain venues every trade is attributable to an address, so you can score forecasting quality at the trader level. The output feeds leaderboards, signals and research.
How does wallet clustering work?
Most approaches link addresses that share a funding source or behave in lockstep, after excluding exchange and bridge addresses that many unrelated users share. The result is a probabilistic grouping of addresses into entities. Store a confidence with every link and treat clusters as hypotheses, not identities.
Can I run wallet analytics on Kalshi?
Not at the trader level in the same way. Kalshi is account-based, so individual traders are not publicly addressable like on-chain wallets. You can still analyze its prices, volume and order books, and compare them with wallet-derived signals from on-chain venues.
Is a high-PnL wallet worth following?
Not on PnL alone. Check sample size, market diversity, drawdown and whether the wallet’s entries beat later prices. Then measure your own slippage from entering after it trades, because that often removes the edge.
Sources
Other Blog
