Methodology

How PolyMath's tools work, what they do not do, and how we measure their accuracy. Written in plain language. If any of this is unclear or inaccurate, email emergent@gmail.com and we will fix it.

1. Calculators (Kelly, EV, Arbitrage, Parlay)

These are deterministic math tools. You enter numbers, we apply a published formula, you get a number back. There is no model, no learning, no opinion. The formulas:

  • Kelly Criterion: f* = (b·p − q) / b, where b = net decimal odds, p = your probability, q = 1 − p. John Kelly, Bell Labs, 1956.
  • Expected Value: EV per $1 = (your_prob / market_price) − 1 for a YES buy.
  • Arbitrage: detects when YES_price + NO_price < 1 (same-market arb) or when two venues disagree (cross-venue arb). Allocation sizes each leg to equalize payout.
  • Parlay: combined probability = product of independent probabilities. Combined payout = product of payout multiples. Assumes independence (an assumption that is often wrong in practice; see FAQ on the parlay page).

Every calculator is client-side JavaScript. Your inputs never leave your browser.

2. Portfolio Tracker

Portfolio Tracker stores position data in your browser's localStorage. Nothing is sent to a PolyMath server. Live-price refresh hits the Polymarket Gamma API directly. CSV export runs in-browser. Premium users can optionally enable Supabase sync; that is the only path where position data leaves your device, and it is opt-in.

3. Calibration Tracker

Calibration Trackerbuilds a reliability diagram from your prediction history. You log predictions with the probability you assigned. When markets resolve, the tracker records outcomes. Every 30+ logged predictions per probability bucket, you see whether your “70% confident” predictions are actually right ~70% of the time.

Calibration is the single most important skill in probabilistic forecasting. We put real effort into this page because the Kelly Criterion assumes calibration — if your probability estimates are off, full Kelly will ruin you faster than any other sizing rule.

4. Drift Radar (TimesFM)

Drift Radar runs Google Research's TimesFM 2.5, a 200M-parameter time-series foundation model, zero-shot on the historical YES-price series of a Polymarket contract. The model returns a probabilistic forecast of the price path to the market's resolution date at the 10th, 50th, and 90th percentile.

What the forecast means

The forecast is a statistical extrapolation of price behavior. It is not a prediction of whether the underlying event will happen. TimesFM was pre-trained on 100 billion real-world time-series data points (retail sales, energy demand, weather, etc.) — none of them prediction markets. When it forecasts a Polymarket price, it is applying learned patterns from other time series to this one. Treat the output as a statistical baseline, not an oracle.

How we compute

  1. Pull hourly-bar price history for the market from Polymarket's CLOB API.
  2. Require ≥ 30 hours of history. Refuse to forecast below this threshold.
  3. Pass the tail (up to 16,384 points) into TimesFM zero-shot with quantile head enabled.
  4. Horizon = hours until market resolution, capped at 1000.
  5. Clamp outputs to [0.01, 0.99] to prevent model overflow artifacts.
  6. Detect regime breaks (recent 6h volatility > 4σ of prior 7 days). Flag forecast quality if found.

Known limitations

  • The model does not see news, tweets, or external events. A major news event will not be reflected until it appears in price.
  • The model does not understand event semantics. It cannot tell a close election from a crypto market from a sports game.
  • New markets with < 30 hours of history are excluded.
  • Multi-outcome markets (3+ possible resolutions) are not supported in v1.
  • Kalshi is not yet supported. Only Polymarket.

Why we chose TimesFM over an LLM

TimesFM is a transformer trained specifically on time-series. LLMs (GPT, Claude, Gemini) treat numbers as tokens and are known to be poor at raw numerical extrapolation. For forecasting a price path, a time-series foundation model has the right inductive bias. We do not use LLMs for numerical forecasts anywhere on PolyMath.

5. AI Analyzer

AI Analyzeruses Google Gemini to summarize a market's description, recent news references, and price behavior into a short human-readable analysis. This is a language-model tool and does not produce numerical forecasts. For numerical forecasts, use Drift Radar. Free tier: 1 analysis per day. Pro: unlimited.

6. Data sources

  • Polymarket Gamma API (gamma-api.polymarket.com) for market metadata, volumes, prices. Public, unauthenticated, 60-second cache.
  • Polymarket CLOB API (clob.polymarket.com) for hourly price history. Used by Drift Radar.
  • Kalshi public API for Kalshi market data where shown. Public, unauthenticated.
  • Your browser localStorage for portfolio and calibration-tracker data. Never leaves your device unless you opt into Pro sync.

7. Accuracy tracking policy

For every drift forecast we produce, we store the forecast alongside the market's eventual resolution. We publish aggregate accuracy metrics (mean absolute error, coverage of [p10, p90]) on this page once we have ≥ 50 resolved forecasts. Our acceptance threshold before we recommend any forecast-driven decision is MAE < 0.15 at T−24h from resolution.

If the aggregate accuracy drops below threshold, we remove the drift recommendations from the UI and disclose it here. We will not hide underperformance.

8. What we are not

  • We are not a broker. We do not accept, hold, or route trades.
  • We are not registered investment advisers. Nothing on PolyMath is investment advice.
  • We are not affiliated with Polymarket, Kalshi, or any other prediction market. We consume their public APIs; they do not sponsor or endorse us.
  • Drift Radar does not forecast events. It forecasts price series. That distinction is load-bearing, both legally and intellectually.
  • Prediction-market trading involves substantial risk including total loss of capital. You are solely responsible for every decision you make.