Trader Skill Scoring on Prediction Markets: A Practical Guide
Trader Skill Scoring on Prediction Markets: A Practical Guide
Trader Skill Scoring on Prediction Markets: A Practical Guide
How to build a trader skill score on Polymarket, Kalshi and Limitless: metrics, luck baselines, validation and cross-venue data pitfalls for quants and developers.
Trader Skill Scoring on Prediction Markets: A Practical Guide
A trader skill score is a single number that estimates how much of a trader’s record comes from repeatable judgment rather than luck. It does this by measuring results against a baseline, adjusting for the size and quality of the sample, and then checking the score on data it has never seen. Profit and win rate alone cannot do this. This guide shows how to build such a score from prediction market trades, how to test it, and where cross-venue data breaks it.
Assymetrixdata.assymetrix.comSee Trader Skill Across MarketsAssymetrix tracks Trader Skill Scores alongside cross-venue prediction market data from Polymarket, Kalshi, and Limitless through one API.Explore the Data API
TL;DR
Win rate counts how often a trader is right. It ignores how much is won or lost, so it is a weak proxy for skill on its own.
A usable skill score compares a trader’s results to a no-skill baseline, such as the market price at the time of entry, and shrinks the score when the sample is small.
Combine outcome-based measures (profit factor, Brier-style calibration) with entry-price measures (did the trader beat the price that followed?).
Validate with a time split: score traders on one period, then check whether the top group still outperforms in the next.
Across Polymarket, Kalshi and Limitless, the hard part is identity and market matching, not the math.
Table of Contents
What a skill score measures that profit and win rate do not
The building blocks: metrics worth computing
Separating skill from luck
A worked score design
Validating the score over time
The cross-venue data problem
Structuring the pipeline
Our perspective
Where Assymetrix fits
Sources
What a skill score measures that profit and win rate do not
Profit tells you what happened. A skill score tries to tell you what is likely to happen next, which is a harder question.
Start with win rate. TradingView defines it as winning trades divided by total closed trades, and notes that it captures frequency rather than magnitude. A trader who wins 80% of the time can still lose money. TradersPost makes the same point: profitability also depends on average win, average loss, position sizing and loss control, so a few large losses can wipe out many small wins.
Prediction markets sharpen this problem. A contract resolves to 0 or 1, and the price is itself a probability. Buying a 92-cent contract wins often and pays little. Buying a 6-cent contract loses often and pays a lot. Two traders can have identical win rates and opposite skill, depending on the prices they paid.
A good score therefore answers three questions:
Did the trader’s outcomes beat what the prices implied? (outcome edge)
Did the market move toward the trader after entry? (price edge)
How much evidence is there? (confidence)
The building blocks: metrics worth computing
No single metric is the score. The score is a weighted, sample-adjusted blend of several. These are the ones that carry real information.
Realized profit factor and average P&L
TradersPost defines profit factor as gross profit divided by gross loss. Above 1.0, winning returns exceed losing returns; below 1.0, losses exceed gains, before other costs or assumptions. Pair it with average P&L per trade and per dollar risked. On a binary market, normalize by capital at risk (the entry price for a long position), not by contract count, or low-priced longshot trades will distort the comparison.
Calibration and Brier score
If a trader’s entries imply a probability (for example, you treat the trader’s average entry as a stated belief), the Brier score measures how close those probabilities are to outcomes. The scores library documentation describes it as the most commonly used verification metric for probabilistic forecasts of binary events, computed as the squared difference between the forecast and the 0 or 1 outcome. Lower is better.
The raw Brier score is not a skill score until you compare it with a reference. We cover the audit side in reproducible Brier audits for prediction markets and explain why the choice of rule matters in three proper scoring rules.
Edge versus the entry price
The cleanest baseline in a prediction market is the price itself. If you bought YES at 0.40 and the contract resolves YES, you beat the market’s implied 40%. But one result proves little. Over hundreds of trades, compare the average outcome with the average entry price:
Mean outcome (fraction of positions that resolved in the trader’s favor, probability-weighted) minus mean implied probability gives a raw edge.
Closing line value, the difference between entry price and the price just before resolution or a fixed horizon later, gives an edge measure that does not wait for resolution.
Closing line value matters because it converges faster than outcomes. A trader who consistently buys before prices rise shows information after 50 trades that outcome-based measures might need 500 to show.
Concentration and consistency
A trader with one enormous winner in a political market is not the same as a trader with 300 small, steady gains. Compute the share of total profit from the top 1 and top 5 positions, the number of distinct markets and categories traded, and the fraction of months with positive P&L. These do not measure skill directly, but they flag scores built on a single event.
Our breakdown of five trader reputation metrics mapped to API fields lists how each of these maps to fields you can query.
Separating skill from luck
The central statistical issue is that with enough traders, some will look brilliant by chance. A leaderboard sorted by profit is mostly a list of lucky and large.
Use a no-skill baseline
One simple formulation, described by TradersWeek, measures forecast performance against a contemporaneous no-skill baseline: subtract the baseline’s correct calls from both the forecaster’s correct calls and total calls, then divide. A result of zero or below shows no demonstrated skill beyond luck; positive values indicate some skill.
In a prediction market, the natural baseline is not a coin flip but the market price. A trader who buys only favorites at 0.90 should win about 90% of the time with zero skill. The baseline for each trade is its entry price, and the score asks whether outcomes exceed it.
Shrink small samples
A trader with five trades and five wins has a 100% win rate and almost no information. Treat observed edge as a noisy estimate and pull it toward the population average, with the pull getting weaker as trade count grows. Two common approaches:
Empirical Bayes shrinkage. Estimate the spread of true skill across all traders, then compute each trader’s posterior estimate. Thin histories land near the average; long histories keep their edge.
Lower confidence bound. Rank by the lower end of a confidence interval on edge per trade, so a trader must prove it.
Either beats a minimum trade count cutoff, which creates a cliff where trader number 29 is invisible and trader number 30 is a star.
Count independent bets, not trades
A trader who adds to a position in 40 small fills has made one bet, not 40. Collapse fills into positions by market and side, then count positions. Further, correlated markets (several contracts on the same election night) are one bet in practice. Cluster by event before computing standard errors.
Penalize multiple comparisons
If you screen 100,000 wallets, expect many to show a 3-sigma streak by chance alone. Apply a false discovery rate adjustment, or better, rely on out-of-sample testing, covered next.
A worked score design
Here is a concrete structure you can implement and tune. The weights are starting points, not constants.
Component | What it captures | Computation sketch | Starting weight |
|---|---|---|---|
Outcome edge | Beat the implied probability | Mean (outcome − entry price) per position, shrunk | 35% |
Price edge | Information ahead of the market | Mean move from entry to a fixed horizon, in the trader’s direction | 30% |
Calibration | Quality of implied beliefs | Brier skill versus an entry-price reference | 15% |
Profit quality | Return per capital at risk | Profit factor, capped to limit outliers | 10% |
Consistency | Not one lucky event | Share of profit outside top 5 positions; active months | 10% |
Then apply three adjustments:
Shrink each component by independent position count.
Cap any single event’s contribution to the total.
Report the score with an uncertainty band, never a bare number.
Trader cohorts help you interpret results. Scoring a trader against peers in the same category and size band is fairer than scoring against everyone. See our guide to trader cohort analysis across 900 million indexed events for how to build those groups.
Validating the score over time
A score earns trust only if it predicts. The validation protocol is simple and should be written down before you look at results.
Split by time. Score every trader using data up to a cutoff date. Freeze the scores.
Form groups. Rank traders and cut them into deciles using only the frozen scores.
Measure the future. Compute realized edge for each decile in the following period.
Check monotonicity. If the score works, the top decile should beat the middle, which should beat the bottom. A flat result means the score measured luck.
Repeat with rolling windows. One split can be lucky too. Use several cutoffs and report the spread.
Watch for leakage. Resolution timestamps, late-arriving trades and market settlements all create look-ahead bias if you compute a trader’s score using information not available at the cutoff. Backtests that ignore fees and fill quality overstate results; our five backtesting rules for prediction market engineers and the guide to execution-aware backtests cover these traps in detail. If you want a general primer on testing a rule set before trusting it, this walkthrough on backtesting trading strategies is a good complement.
For a hands-on route, replaying historical data before committing capital is covered in paper trading prediction markets.
Using scores to find potentially informed traders
Once validated, a score can flag wallets or accounts whose positions deserve attention. Treat the output as a signal for investigation, not proof of inside knowledge. Informed-looking behavior includes consistent positive closing line value, early entries ahead of news, and concentration in a narrow set of markets. Each can also arise from legitimate research or from a single good thesis.
To turn flagged behavior into something actionable, see smart money alerts for prediction market developers, and for rules around replicating other traders, copy trading prediction markets with canonical data.
The cross-venue data problem
The math above is the easy half. The harder half is assembling clean trade histories across Polymarket, Kalshi and Limitless.
Identity differs by venue
Polymarket trades settle on a blockchain, so wallet activity is public and can be tied to an address. Kalshi is a CFTC-regulated exchange operating on a conventional account model, and individual accounts are not exposed the same way. The consequence is that a per-trader score is naturally built on wallets for on-chain venues, while for others you may only have anonymous, market-level trade data. Do not claim a wallet on one venue and an account on another are the same person unless you have evidence. A single trader can also split activity over many wallets, which fragments history and makes a score look thinner than it is.
Markets must be matched before they can be compared
A “Will X win?” contract on one venue may differ from the same-sounding contract on another in resolution source, settlement time, rounding rule and what happens on a tie or cancellation. Without a canonical market identifier, you will mix non-equivalent contracts and corrupt the baseline. Our guide to canonical IDs for cross-venue data walks through the matching problem.
Prices need normalizing
Venues quote probabilities, cents and fees differently. Normalize to a common representation (a price between 0 and 1 for the YES side), record fees per fill, and keep the raw value so you can audit conversions. Compute edge net of fees, or the score will favor traders who trade often at a cost they never see.
Timestamps and partial histories
Clock differences, block confirmation times and delayed settlement records shift the order of events. For price edge at a fixed horizon, a few seconds of drift matters in fast markets. Also expect missing history: wallets that began before your data window will look new. Flag them as left-censored rather than scoring them as newcomers.
Structuring the pipeline
A pipeline for trader performance analytics across venues usually follows five stages:
Ingest. Pull trades, orders, market metadata and resolutions from each venue, storing raw payloads unchanged.
Normalize. Map venues to one schema: canonical market ID, side, price in 0 to 1, size, fee, timestamp in UTC.
Resolve. Attach outcomes, with the resolution time, so every position is either open, resolved or voided.
Aggregate. Collapse fills into positions, positions into events, then compute per-trader features.
Score and validate. Produce scores with uncertainty, store them with the data cutoff, and run the time-split test on each refresh.
Two habits save a great deal of rework. Version every score by data cutoff and formula, so a leaderboard can be reproduced later. And keep the position table as the single source of truth; every metric should be derived from it.
If you would rather not maintain three ingestion paths, the prediction market data API guide for REST and WebSocket describes how one integration covers them. For Python users, the Python prediction market data guide shows how to load the data into dataframes, and Polymarket on-chain analytics covers the wallet side.
Our perspective
We see the same failure repeatedly: a team builds a leaderboard sorted by profit, sees familiar big names at the top, and concludes the score works. It has only measured size and variance.
Our view is that a skill score is a statistical claim and should be treated like one. It needs a baseline, a sample-size correction, and a held-out test. We also believe the score should be venue-neutral. A trader’s behavior on Polymarket, Kalshi and Limitless should be measured on the same footing, with the same market matching rules, so a difference in score reflects the trader and not the plumbing.
That is why we build the data layer first. Normalized schemas and canonical market IDs come before any ranking. Trader Skill Scores and Smart Money tracking are only as reliable as the history underneath them, and we would rather publish a score with an honest uncertainty band than a clean number that falls apart out of sample.
— Dean
Where Assymetrix fits
If you are building a scoring model, the slow part is rarely the formula. It is assembling a consistent, matched history across venues. The Assymetrix Data API provides cross-venue prediction market data for Polymarket, Kalshi and Limitless through a single integration, with historical depth you can use for the time-split validation described above. For ready-made signals built on that data, see the prediction market intelligence layer.
FAQ
What is a trader skill score?
It is a number that estimates how much of a trader’s performance reflects repeatable skill instead of luck. It compares results to a no-skill baseline, adjusts for sample size and is checked on later data. A raw profit total or win rate does not do this.
Is win rate a good measure of a prediction market trader?
On its own, no. TradingView notes that win rate shows how often trades succeed, not how large the wins and losses are. In prediction markets, entry price changes what a win means, so you need price-adjusted measures as well.
How many trades are needed before a score is reliable?
There is no universal number. Independent positions matter more than fills, and noisy edge estimates need shrinkage toward the population average. Rather than a hard cutoff, publish the score with an uncertainty band that narrows as the position count grows.
Can the same score work across Polymarket, Kalshi and Limitless?
Yes, if markets are matched to canonical identifiers and prices and fees are normalized first. The limit is identity: wallet-level history is public on-chain, but other venues may not expose individual accounts in the same way, so the per-trader view can differ by venue.
How do I know my score is not just measuring luck?
Freeze scores at a cutoff date, rank traders into deciles, and measure realized edge in the next period. If the top decile does not outperform the rest out of sample, the score is capturing noise. Repeat across several cutoffs.
Sources
Trader Skill Scoring on Prediction Markets: A Practical Guide
A trader skill score is a single number that estimates how much of a trader’s record comes from repeatable judgment rather than luck. It does this by measuring results against a baseline, adjusting for the size and quality of the sample, and then checking the score on data it has never seen. Profit and win rate alone cannot do this. This guide shows how to build such a score from prediction market trades, how to test it, and where cross-venue data breaks it.
Assymetrixdata.assymetrix.comSee Trader Skill Across MarketsAssymetrix tracks Trader Skill Scores alongside cross-venue prediction market data from Polymarket, Kalshi, and Limitless through one API.Explore the Data API
TL;DR
Win rate counts how often a trader is right. It ignores how much is won or lost, so it is a weak proxy for skill on its own.
A usable skill score compares a trader’s results to a no-skill baseline, such as the market price at the time of entry, and shrinks the score when the sample is small.
Combine outcome-based measures (profit factor, Brier-style calibration) with entry-price measures (did the trader beat the price that followed?).
Validate with a time split: score traders on one period, then check whether the top group still outperforms in the next.
Across Polymarket, Kalshi and Limitless, the hard part is identity and market matching, not the math.
Table of Contents
What a skill score measures that profit and win rate do not
The building blocks: metrics worth computing
Separating skill from luck
A worked score design
Validating the score over time
The cross-venue data problem
Structuring the pipeline
Our perspective
Where Assymetrix fits
Sources
What a skill score measures that profit and win rate do not
Profit tells you what happened. A skill score tries to tell you what is likely to happen next, which is a harder question.
Start with win rate. TradingView defines it as winning trades divided by total closed trades, and notes that it captures frequency rather than magnitude. A trader who wins 80% of the time can still lose money. TradersPost makes the same point: profitability also depends on average win, average loss, position sizing and loss control, so a few large losses can wipe out many small wins.
Prediction markets sharpen this problem. A contract resolves to 0 or 1, and the price is itself a probability. Buying a 92-cent contract wins often and pays little. Buying a 6-cent contract loses often and pays a lot. Two traders can have identical win rates and opposite skill, depending on the prices they paid.
A good score therefore answers three questions:
Did the trader’s outcomes beat what the prices implied? (outcome edge)
Did the market move toward the trader after entry? (price edge)
How much evidence is there? (confidence)
The building blocks: metrics worth computing
No single metric is the score. The score is a weighted, sample-adjusted blend of several. These are the ones that carry real information.
Realized profit factor and average P&L
TradersPost defines profit factor as gross profit divided by gross loss. Above 1.0, winning returns exceed losing returns; below 1.0, losses exceed gains, before other costs or assumptions. Pair it with average P&L per trade and per dollar risked. On a binary market, normalize by capital at risk (the entry price for a long position), not by contract count, or low-priced longshot trades will distort the comparison.
Calibration and Brier score
If a trader’s entries imply a probability (for example, you treat the trader’s average entry as a stated belief), the Brier score measures how close those probabilities are to outcomes. The scores library documentation describes it as the most commonly used verification metric for probabilistic forecasts of binary events, computed as the squared difference between the forecast and the 0 or 1 outcome. Lower is better.
The raw Brier score is not a skill score until you compare it with a reference. We cover the audit side in reproducible Brier audits for prediction markets and explain why the choice of rule matters in three proper scoring rules.
Edge versus the entry price
The cleanest baseline in a prediction market is the price itself. If you bought YES at 0.40 and the contract resolves YES, you beat the market’s implied 40%. But one result proves little. Over hundreds of trades, compare the average outcome with the average entry price:
Mean outcome (fraction of positions that resolved in the trader’s favor, probability-weighted) minus mean implied probability gives a raw edge.
Closing line value, the difference between entry price and the price just before resolution or a fixed horizon later, gives an edge measure that does not wait for resolution.
Closing line value matters because it converges faster than outcomes. A trader who consistently buys before prices rise shows information after 50 trades that outcome-based measures might need 500 to show.
Concentration and consistency
A trader with one enormous winner in a political market is not the same as a trader with 300 small, steady gains. Compute the share of total profit from the top 1 and top 5 positions, the number of distinct markets and categories traded, and the fraction of months with positive P&L. These do not measure skill directly, but they flag scores built on a single event.
Our breakdown of five trader reputation metrics mapped to API fields lists how each of these maps to fields you can query.
Separating skill from luck
The central statistical issue is that with enough traders, some will look brilliant by chance. A leaderboard sorted by profit is mostly a list of lucky and large.
Use a no-skill baseline
One simple formulation, described by TradersWeek, measures forecast performance against a contemporaneous no-skill baseline: subtract the baseline’s correct calls from both the forecaster’s correct calls and total calls, then divide. A result of zero or below shows no demonstrated skill beyond luck; positive values indicate some skill.
In a prediction market, the natural baseline is not a coin flip but the market price. A trader who buys only favorites at 0.90 should win about 90% of the time with zero skill. The baseline for each trade is its entry price, and the score asks whether outcomes exceed it.
Shrink small samples
A trader with five trades and five wins has a 100% win rate and almost no information. Treat observed edge as a noisy estimate and pull it toward the population average, with the pull getting weaker as trade count grows. Two common approaches:
Empirical Bayes shrinkage. Estimate the spread of true skill across all traders, then compute each trader’s posterior estimate. Thin histories land near the average; long histories keep their edge.
Lower confidence bound. Rank by the lower end of a confidence interval on edge per trade, so a trader must prove it.
Either beats a minimum trade count cutoff, which creates a cliff where trader number 29 is invisible and trader number 30 is a star.
Count independent bets, not trades
A trader who adds to a position in 40 small fills has made one bet, not 40. Collapse fills into positions by market and side, then count positions. Further, correlated markets (several contracts on the same election night) are one bet in practice. Cluster by event before computing standard errors.
Penalize multiple comparisons
If you screen 100,000 wallets, expect many to show a 3-sigma streak by chance alone. Apply a false discovery rate adjustment, or better, rely on out-of-sample testing, covered next.
A worked score design
Here is a concrete structure you can implement and tune. The weights are starting points, not constants.
Component | What it captures | Computation sketch | Starting weight |
|---|---|---|---|
Outcome edge | Beat the implied probability | Mean (outcome − entry price) per position, shrunk | 35% |
Price edge | Information ahead of the market | Mean move from entry to a fixed horizon, in the trader’s direction | 30% |
Calibration | Quality of implied beliefs | Brier skill versus an entry-price reference | 15% |
Profit quality | Return per capital at risk | Profit factor, capped to limit outliers | 10% |
Consistency | Not one lucky event | Share of profit outside top 5 positions; active months | 10% |
Then apply three adjustments:
Shrink each component by independent position count.
Cap any single event’s contribution to the total.
Report the score with an uncertainty band, never a bare number.
Trader cohorts help you interpret results. Scoring a trader against peers in the same category and size band is fairer than scoring against everyone. See our guide to trader cohort analysis across 900 million indexed events for how to build those groups.
Validating the score over time
A score earns trust only if it predicts. The validation protocol is simple and should be written down before you look at results.
Split by time. Score every trader using data up to a cutoff date. Freeze the scores.
Form groups. Rank traders and cut them into deciles using only the frozen scores.
Measure the future. Compute realized edge for each decile in the following period.
Check monotonicity. If the score works, the top decile should beat the middle, which should beat the bottom. A flat result means the score measured luck.
Repeat with rolling windows. One split can be lucky too. Use several cutoffs and report the spread.
Watch for leakage. Resolution timestamps, late-arriving trades and market settlements all create look-ahead bias if you compute a trader’s score using information not available at the cutoff. Backtests that ignore fees and fill quality overstate results; our five backtesting rules for prediction market engineers and the guide to execution-aware backtests cover these traps in detail. If you want a general primer on testing a rule set before trusting it, this walkthrough on backtesting trading strategies is a good complement.
For a hands-on route, replaying historical data before committing capital is covered in paper trading prediction markets.
Using scores to find potentially informed traders
Once validated, a score can flag wallets or accounts whose positions deserve attention. Treat the output as a signal for investigation, not proof of inside knowledge. Informed-looking behavior includes consistent positive closing line value, early entries ahead of news, and concentration in a narrow set of markets. Each can also arise from legitimate research or from a single good thesis.
To turn flagged behavior into something actionable, see smart money alerts for prediction market developers, and for rules around replicating other traders, copy trading prediction markets with canonical data.
The cross-venue data problem
The math above is the easy half. The harder half is assembling clean trade histories across Polymarket, Kalshi and Limitless.
Identity differs by venue
Polymarket trades settle on a blockchain, so wallet activity is public and can be tied to an address. Kalshi is a CFTC-regulated exchange operating on a conventional account model, and individual accounts are not exposed the same way. The consequence is that a per-trader score is naturally built on wallets for on-chain venues, while for others you may only have anonymous, market-level trade data. Do not claim a wallet on one venue and an account on another are the same person unless you have evidence. A single trader can also split activity over many wallets, which fragments history and makes a score look thinner than it is.
Markets must be matched before they can be compared
A “Will X win?” contract on one venue may differ from the same-sounding contract on another in resolution source, settlement time, rounding rule and what happens on a tie or cancellation. Without a canonical market identifier, you will mix non-equivalent contracts and corrupt the baseline. Our guide to canonical IDs for cross-venue data walks through the matching problem.
Prices need normalizing
Venues quote probabilities, cents and fees differently. Normalize to a common representation (a price between 0 and 1 for the YES side), record fees per fill, and keep the raw value so you can audit conversions. Compute edge net of fees, or the score will favor traders who trade often at a cost they never see.
Timestamps and partial histories
Clock differences, block confirmation times and delayed settlement records shift the order of events. For price edge at a fixed horizon, a few seconds of drift matters in fast markets. Also expect missing history: wallets that began before your data window will look new. Flag them as left-censored rather than scoring them as newcomers.
Structuring the pipeline
A pipeline for trader performance analytics across venues usually follows five stages:
Ingest. Pull trades, orders, market metadata and resolutions from each venue, storing raw payloads unchanged.
Normalize. Map venues to one schema: canonical market ID, side, price in 0 to 1, size, fee, timestamp in UTC.
Resolve. Attach outcomes, with the resolution time, so every position is either open, resolved or voided.
Aggregate. Collapse fills into positions, positions into events, then compute per-trader features.
Score and validate. Produce scores with uncertainty, store them with the data cutoff, and run the time-split test on each refresh.
Two habits save a great deal of rework. Version every score by data cutoff and formula, so a leaderboard can be reproduced later. And keep the position table as the single source of truth; every metric should be derived from it.
If you would rather not maintain three ingestion paths, the prediction market data API guide for REST and WebSocket describes how one integration covers them. For Python users, the Python prediction market data guide shows how to load the data into dataframes, and Polymarket on-chain analytics covers the wallet side.
Our perspective
We see the same failure repeatedly: a team builds a leaderboard sorted by profit, sees familiar big names at the top, and concludes the score works. It has only measured size and variance.
Our view is that a skill score is a statistical claim and should be treated like one. It needs a baseline, a sample-size correction, and a held-out test. We also believe the score should be venue-neutral. A trader’s behavior on Polymarket, Kalshi and Limitless should be measured on the same footing, with the same market matching rules, so a difference in score reflects the trader and not the plumbing.
That is why we build the data layer first. Normalized schemas and canonical market IDs come before any ranking. Trader Skill Scores and Smart Money tracking are only as reliable as the history underneath them, and we would rather publish a score with an honest uncertainty band than a clean number that falls apart out of sample.
— Dean
Where Assymetrix fits
If you are building a scoring model, the slow part is rarely the formula. It is assembling a consistent, matched history across venues. The Assymetrix Data API provides cross-venue prediction market data for Polymarket, Kalshi and Limitless through a single integration, with historical depth you can use for the time-split validation described above. For ready-made signals built on that data, see the prediction market intelligence layer.
FAQ
What is a trader skill score?
It is a number that estimates how much of a trader’s performance reflects repeatable skill instead of luck. It compares results to a no-skill baseline, adjusts for sample size and is checked on later data. A raw profit total or win rate does not do this.
Is win rate a good measure of a prediction market trader?
On its own, no. TradingView notes that win rate shows how often trades succeed, not how large the wins and losses are. In prediction markets, entry price changes what a win means, so you need price-adjusted measures as well.
How many trades are needed before a score is reliable?
There is no universal number. Independent positions matter more than fills, and noisy edge estimates need shrinkage toward the population average. Rather than a hard cutoff, publish the score with an uncertainty band that narrows as the position count grows.
Can the same score work across Polymarket, Kalshi and Limitless?
Yes, if markets are matched to canonical identifiers and prices and fees are normalized first. The limit is identity: wallet-level history is public on-chain, but other venues may not expose individual accounts in the same way, so the per-trader view can differ by venue.
How do I know my score is not just measuring luck?
Freeze scores at a cutoff date, rank traders into deciles, and measure realized edge in the next period. If the top decile does not outperform the rest out of sample, the score is capturing noise. Repeat across several cutoffs.
Sources
Other Blog
