How Smart Money Moves Before Event Resolutions

Smart money in prediction markets is operationally defined as time-anchored directional price movement led by high-reputation or large wallets prior to public resolution events, quantified through an Information Leakage Score (ILS) fused with wallet-level features. The minimal live detector: compute deadline-ILS over the 48-hour pre-resolution window, join it with wallet reputation and last-minute ratio, and fire an alert when the composite score crosses a calibrated threshold.

Core signals to monitor:

• Pre-resolution concentrated buys or sells by wallets with documented accuracy histories

• Funding-chain clusters: multiple wallets sharing a common upstream USDC funder on Polygon (chainid=137)

• Cross-venue simultaneous positioning on Polymarket, Kalshi, and Limitless within the same event window

Minimal data sources: Polymarket Gamma and CLOB APIs, Kalshi trades and orderbook endpoints, Polygon on-chain traces via Etherscan and Bitquery.

One-line production rule: fire an alert when composite_score = 0.4*deadline_ILS + 0.3*wallet_reputation + 0.2*last_minute_ratio + 0.1*bet_pct_of_volume > 0.65.

Core entities in this detector: Assymetrix, Polymarket, Kalshi, Limitless, Polygon, Etherscan, Bitquery, and ForesightFlow.

Key Takeaways

Fusing deadline-ILS with wallet reputation and last-minute ratio into a composite score above 0.65 is the most reliable operational trigger for smart-money alerts in prediction markets.

Table of Contents

• What smart money signals actually look like in prediction markets

• How the Information Leakage Score is computed

• How venue microstructure changes signal interpretation

• What data feeds and API endpoints you need

• How to architect the end-to-end detection pipeline

• How to evaluate and backtest a smart-money detector

• Which event categories show the strongest signals

• How to tune thresholds and manage false positives

• Reproducible API calls and scoring code

• What detection does not prove, and where it fails

• Why fusing ILS with wallet features is the right architecture

• Assymetrix gives you the data layer this detector requires

• Sources

• FAQ

What smart money signals actually look like in prediction markets

Wallet-level signals cluster into six observable patterns. Each maps to a concrete telemetry field your ingestion pipeline must capture.

• Large wallet entries in the last 48 hours: wallets with prior accuracy rates above baseline entering positions sized above the market’s median trade. Telemetry: trade_size_usd, wallet_age, historical win rate from leaderboard data.

• Pre-resolution concentration in low-liquidity markets: share of market volume captured by a single wallet or cluster exceeds 15–20% within 6 hours of resolution. Telemetry: share_of_market_volume, time_to_resolution.

• One-sided taker imbalance: sustained directional taker flow (YES or NO) without a corresponding price reversion. Telemetry: taker_side, rolling imbalance ratio over 1-hour windows.

• Repeated high-accuracy wallets: wallets appearing in the top decile of a trader skill leaderboard across multiple resolved markets. Telemetry: wallet_address, historical precision per category.

• Fresh-wallet plus immediate large deposit: a wallet whose first on-chain activity coincides with its first large bet, especially when followed by dormancy after resolution. Per Bitquery’s on-chain funding trace examples, querying the earliest inbound USDC transfer and comparing it to first trade timestamp isolates this pattern reliably. Telemetry: time_since_funding, wallet_age.

• Cross-venue simultaneous positioning: the same wallet or cluster holds directionally consistent positions on Polymarket and Kalshi within a short window. Telemetry: market_id cross-referenced across venues, createdAt.

From a 161,638-contract dataset spanning Polymarket and Kalshi, 72% of contracts resolve NO, and YES contracts resolve faster by a median of 2.6 days. That asymmetry means YES-side large entries carry a disproportionate timing signal.

Pro Tip: When engineering bandwidth is limited, prioritize funding-source tracing and last-minute ratio first. Both are computable from a single Polygon trace query and a rolling trade-count window, and they catch the highest-confidence patterns before you build out the full wallet reputation layer.

How the Information Leakage Score is computed

The ForesightFlow ILS framework defines ILS as the fraction of a market’s terminal price move realized before a public news event:

ILS = (P_anchor - P_open) / (P_resolution - P_open)

Where P_open is the price at market open, P_anchor is the price at the news or deadline anchor, and P_resolution is the final resolution price. A value near 1.0 means the market fully priced the outcome before the public event. The deadline-ILS variant substitutes the contract deadline for the news anchor, handling markets that resolve on a fixed date rather than a discrete news event.

Scope conditions for interpretable ILS:

• Total price move |P_resolution - P_open| must exceed a minimum threshold (typically 0.10 in probability units) to avoid noise amplification in near-flat markets.

• A reliable public-event timestamp or contract deadline must exist.

• Avoid edge-effect markets: contracts with fewer than 50 trades or less than $500 total volume produce unstable ILS estimates.

Numeric example: A political contract opens at 0.40, reaches 0.72 at the news anchor, and resolves at 0.95. ILS = (0.72 - 0.40) / (0.95 - 0.40) = 0.58.

Pitfalls: proxy timestamp bias (using trade time rather than block time inflates ILS), edge effects in thin markets, and survivorship bias when only resolved contracts are labeled. ForesightFlow notes that ILS alone frequently fails to separate informed flow from noise without high-quality news timestamps. Fuse it with wallet features before acting on any single ILS value.

How venue microstructure changes signal interpretation

Polymarket, Kalshi, and Limitless differ in ways that directly distort cross-venue comparisons if you normalize naively.

• Polymarket: pseudonymous CLOB on Polygon, deeper liquidity in political markets, wallet identity recoverable from on-chain traces. Taker side requires reconstruction from trade direction and price movement.

• Kalshi: centralized exchange with explicit taker_side field in the trades endpoint, smaller average trade sizes in many categories, and tighter orderbook depth in sports markets.

• Limitless: newer venue with lower aggregate volume; treat volume attribution with caution until calibration windows accumulate.

Per Decomposing Crowd Wisdom, large trades affect calibration and price impact differently on Kalshi versus Polymarket. A 70-cent political contract can map to materially different true probabilities across venues and horizons. Calibrate Kyle’s lambda (price impact per unit volume) separately per venue and per domain.

Normalization recipes:

• Volume-share weighting: normalize bet_pct_of_volume against each venue’s own rolling median, not a pooled cross-venue median.

• Trade-size scaling: fit a per-venue Kyle’s lambda on a 30-day rolling window; use it to convert raw trade size to an impact-adjusted signal.

• Horizon-conditional calibration: apply per-domain priors (political, sports, economic) within each venue before merging signals.

• Taker-side harmonization: on Polymarket, infer taker side from price direction and trade sequence; on Kalshi, consume the native taker_side field directly.

Pro Tip: Run a 14-day holdout test per venue before merging signals. Liquidity spikes around major political events on Polymarket can make informed flow look like noise if your lambda was calibrated on quieter sports markets.

What data feeds and API endpoints you need

The Polymarket and Kalshi API shapes differ enough that a unified ingestion layer is worth building early.

Required fields per trade record: timestamp, taker_side, trade_size_usd, wallet_address, market_id, createdAt, close_time. The Assymetrix Data API delivers these fields normalized across venues from a single endpoint, backed by approximately 1.5 terabytes of historical data.

How to architect the end-to-end detection pipeline

A production detector has seven components in sequence:

1. Trade stream ingestion: consume Polymarket CLOB and Kalshi trade websockets; buffer to a time-ordered queue.

2. Orderbook snapshot store: capture 1–5s snapshots; retain 7 days for reconstruction.

3. Wallet enrichment: on each new wallet address, trigger a Polygon trace query via Bitquery to recover first inbound USDC transfer and cluster membership.

4. Feature engine: compute rolling deadline-ILS, last-minute ratio, taker imbalance, and wallet reputation score per market.

5. Scoring service: apply the composite formula: 0.4*deadline_ILS + 0.3*wallet_reputation + 0.2*last_minute_ratio + 0.1*bet_pct_of_volume.

6. Alerting and triage queue: route scores above threshold to an analyst queue with a full evidence payload.

7. Dashboard: surface top-scoring markets, wallet cluster graphs, and funding traces.

Latency targets: anomaly score computed within 1 second of trade arrival; wallet enrichment within 5 seconds; alert delivery under 10 seconds for high-priority events. The enrichment step is the bottleneck — cache funding-chain results aggressively and refresh only on new wallet addresses.

Security controls: encrypt wallet histories and trade traces at rest (AES-256); enforce role-based access on the enrichment store; log all API key usage; retain only the minimum required wallet data for your operational window.

Pro Tip: *Pre-cache funding-chain lookups for wallets that have appeared in any prior market.

How to evaluate and backtest a smart-money detector

Treat those as orientation benchmarks, not guarantees.

Metrics to track:

• Precision and recall at your chosen threshold

• Median lead time in minutes before resolution

• Simulated P&L from positions taken on alerts

• False positive rate and precision at top-k alerts

Statistical tests: use binomial p-value testing to determine whether a wallet’s win rate exceeds chance given its trade count, as implemented in the polymarket-insider-detector. Apply Mann-Whitney U tests to compare lead-time distributions between flagged and unflagged markets. Use bootstrap confidence intervals for P&L estimates.

Baselines: random alert baseline, size-weighted random (proportional to market volume), and a simple moving-average price momentum baseline. A detector that cannot beat the momentum baseline on lead time is not capturing informed flow.

Backtest design: use time-forward cross-validation only. Align labels to resolution time, not trade time. The 161,638-contract dataset covering 242,640 traders and $3.19B in verified Polygon deposits provides sufficient provenance for multi-fold backtests across political, sports, and economic categories.

Which event categories show the strongest signals

Political markets show the strongest and most consistent wallet signals, but they require the most careful platform calibration given Polymarket’s depth asymmetry. Sports markets produce shorter-horizon signals with higher noise, demanding tighter calibration windows. Economic release markets show mixed signal strength that depends heavily on whether the release timestamp is precise.

How to tune thresholds and manage false positives

Triage checklist for each alert:

• Full trade list for the flagged wallet cluster in the 48-hour window

• Funding trace showing common upstream USDC funder

• ILS value and the three price points used to compute it

• Cross-venue position snapshot (Polymarket + Kalshi)

• Wallet historical accuracy and prior suspicion flags

Threshold guidelines:

1. High-precision monitoring (precision target >75%): set composite score threshold at 0.75+. Expect lower recall; use for automated downstream actions requiring human sign-off.

2. Exploratory scanning (recall target >60%): lower threshold to 0.50. Expect more false positives; route to a secondary review queue rather than primary alerts.

False positive handling: apply automated suppression windows (no repeat alert on the same market within 2 hours unless score increases by 0.10+). After resolution, label each alert as true positive or false positive and feed those labels back into a monthly weight retraining cycle. Keep a full evidence trail per alert for audit purposes.

Reproducible API calls and scoring code

Polymarket Gamma — fetch recent trades for a market:

GET https://gamma-api.polymarket.com/trades?market_id={id}&limit=500
Fields: timestamp, maker_address, taker_address, price, size, outcome

GET https://gamma-api.polymarket.com/trades?market_id={id}&limit=500
Fields: timestamp, maker_address, taker_address, price, size, outcome

Kalshi — fetch trades:

GET https://trading-api.kalshi.com/trade-api/v2/markets/{ticker}/trades
Fields: created_time, taker_side, count, yes_price, no_price

GET https://trading-api.kalshi.com/trade-api/v2/markets/{ticker}/trades
Fields: created_time, taker_side, count, yes_price, no_price

Assymetrix Data API — wallet trade history:

GET https://data.assymetrix.com/v1/wallet/{address}/trades?venues=polymarket,kalshi
Fields: timestamp, market_id, venue, taker_side, trade_size_usd, outcome

GET https://data.assymetrix.com/v1/wallet/{address}/trades?venues=polymarket,kalshi
Fields: timestamp, market_id, venue, taker_side, trade_size_usd, outcome

Bitquery — first inbound USDC transfer (GraphQL):

{ EVM(network: matic) {
    Transfers(where: {Transfer: {Receiver: {is: "WALLET_ADDRESS"},
      Currency: {SmartContract: {is: "USDC_CONTRACT"}}}},
      orderBy: {ascending: Block_Time}, limit: {count: 1}) {
      Block { Time } Transaction { Hash } Transfer { Sender Amount } }}}

{ EVM(network: matic) {
    Transfers(where: {Transfer: {Receiver: {is: "WALLET_ADDRESS"},
      Currency: {SmartContract: {is: "USDC_CONTRACT"}}}},
      orderBy: {ascending: Block_Time}, limit: {count: 1}) {
      Block { Time } Transaction { Hash } Transfer { Sender Amount } }}}

Composite scoring pseudo-code:

def composite_score(deadline_ils, wallet_rep, last_min_ratio, bet_pct):
    return (0.4 * deadline_ils + 0.3 * wallet_rep
            + 0.2 * last_min_ratio + 0.1 * bet_pct)

# Example: deadline_ils=0.70, wallet_rep=0.80, last_min_ratio=0.60, bet_pct=0.25
# score = 0.28 + 0.24 + 0.12 + 0.025 = 0.665 → ALERT (threshold 0.65)

def composite_score(deadline_ils, wallet_rep, last_min_ratio, bet_pct):
    return (0.4 * deadline_ils + 0.3 * wallet_rep
            + 0.2 * last_min_ratio + 0.1 * bet_pct)

# Example: deadline_ils=0.70, wallet_rep=0.80, last_min_ratio=0.60, bet_pct=0.25
# score = 0.28 + 0.24 + 0.12 + 0.025 = 0.665 → ALERT (threshold 0.65)

Pro Tip: Weight wallet_reputation at 0.30 or higher. In backtests, wallet historical accuracy is the single most stable predictor across categories. ILS alone is noisy without a high-quality timestamp.

What detection does not prove, and where it fails

Methodological caveats:

• ILS and composite scores are heuristics, not proof of insider trading or any legal violation.

• Proxy timestamp errors (using trade time rather than block confirmation time) systematically inflate ILS in high-latency markets.

• Edge markets (thin volume, few traders) produce unstable scores regardless of threshold.

• Survivorship bias: labeled datasets over-represent resolved contracts with clear outcomes; unresolved or disputed markets are underrepresented.

Legal and ethical boundaries:

• Wallet addresses are pseudonymous, not anonymous. Handle stored wallet histories under a minimal-data principle: retain only what your operational window requires.

• Do not publish wallet-level suspicion scores publicly without a responsible disclosure process.

• Never automate punitive or market-access-restricting actions based solely on an algorithmic score. Human review is required before any consequential action.

• This article is general operational guidance, not legal advice. Consult qualified counsel before deploying any system that flags or restricts participants.

Why fusing ILS with wallet features is the right architecture

The ILS-only approach breaks down in practice whenever news timestamps are imprecise or markets are thin. Wallet features, particularly funding-chain clusters and historical accuracy, provide a second independent signal that is orthogonal to price movement. Together, they reduce false positives without sacrificing lead time. The next concrete steps for any team building this system: deploy a minimal proof-of-concept on a single event category (political is the highest-signal starting point), run a 6-month time-forward backtest using the 161,638-contract dataset as provenance, integrate the Assymetrix Data API for cross-venue wallet enrichment, and iterate thresholds monthly using labeled post-resolution outcomes.

Assymetrix gives you the data layer this detector requires

The hardest part of building a smart-money detector is not the scoring formula. It is assembling clean, normalized, cross-venue trade history with wallet-level resolution at scale.

Assymetrix delivers exactly that. The Assymetrix Data API provides unified trade history across Polymarket, Kalshi, and Limitless, precomputed wallet enrichment, trader skill leaderboards, and Smart Money Alerts, all from a single integration point backed by approximately 1.5 terabytes of data. Streaming endpoints, bulk export, and Python client libraries are available for teams prototyping detectors now. Start with the Data API at Data and have your first wallet-enriched trade stream running within a day.

Sources

• Decomposing Crowd Wisdom: Domain‑Specific Calibration Dynamics in Prediction Markets (arXiv)

• VISUAL_DATA_SHEET.md (Polymarket + Kalshi dataset summary)

• Bitquery — Polymarket insider detection API examples (on‑chain funding traces)

• suislanchez / polymarket‑insider‑detector (GitHub)

FAQ

What is the Information Leakage Score in prediction markets?

ILS measures the fraction of a market’s terminal price move that occurs before a public news event or contract deadline. A value near 1.0 indicates the market priced the outcome before any public announcement, which is the core signal for informed-flow detection.

Which event category shows the strongest smart-money signals?

Political markets consistently show the strongest and most persistent wallet signals, with lead times of 24–48 hours before resolution. Sports markets produce shorter-horizon signals, and economic release markets depend heavily on release timestamp precision.

How do you reduce false positives in a smart-money detector?

Set a composite score threshold of 0.75 or higher for high-precision alerts, apply automated suppression windows to avoid repeat alerts on the same market within 2 hours, and require human review before any consequential action. Monthly retraining from labeled post-resolution outcomes steadily improves precision.

Can Assymetrix supply the wallet data needed to build this detector?

Yes. The Assymetrix Data API at data.assymetrix.com provides unified cross-venue trade history, wallet enrichment, and precomputed Smart Money Alerts across Polymarket, Kalshi, and Limitless from a single integration.

Does a high composite score prove insider trading?

No. A high score is a heuristic flag, not legal evidence. ILS and wallet features identify statistically unusual patterns; they do not establish intent, information source, or legal liability. Human review and qualified legal counsel are required before any consequential action.