Levandor

Short-Term Market Accuracy

5 min read

Ranks traders by accuracy on fast-resolving short-term crypto Up/Down markets (btc-updown-5m, btc-updown-15m, bitcoin-up-or-down-<date>). Markets matched by slug LIKE '%updown%' OR '%up-or-down%'. Separate analysis from copy-trade-algorithm — that one covers all categories, this one is scoped to short-window crypto.

why it works at all

~15,321 resolved short-term markets have recoverable outcomes from the existing pm_market_resolutions cache (Gamma-backed), joined to pm_trades slugs. The earlier worry that historical short-term markets had aged out of Gamma only applied to live Gamma metadata queries — the cached resolutions table already had them. No new backfill needed.

what was built

  • CLI command short-term-accuracy
  • Module crates/polymarket-fetch/src/short_term_accuracy.rs
  • Table pm_short_term_trader_accuracy

Per-wallet it computes: hit_rate, Wilson lower bound, edge over price, edge_lower, edge_z, ROI, Brier, and a split-half persistence check.

bug: survivorship bias from joining on traded outcome

Recurring bug class in this project

First implementation joined pm_trades to pm_market_resolutions on the traded outcome_index. So a market’s winner was only known if a watched wallet had traded the winning side. Markets where the wallet only traded the losing side had no derivable winner and were silently dropped instead of counted as losses. That inflates hit rates — one wallet showed a fake 98.9% that was really 55.6%.

Fix: determine each market’s winning outcome authoritatively from the full pm_market_resolutions data (DISTINCT ON condition_id, max payout), independent of what was traded.

Same class as the earlier pm_positions resolution-inference bug (winners get redeemed and disappear from snapshots). Pattern: never infer a market outcome from a trader-side artifact — always pull it authoritatively.

metric: rank by edge, not hit_rate

Raw hit_rate is the wrong ranking metric — it almost perfectly tracks the average price a wallet pays. A wallet that habitually buys $0.70 favorites wins ~70% by construction. The skill metric is:

edge = hit_rate - avg_entry_price        # equivalently mean of (won_i - price_i)

The confidence lower bound on edge must use the Wilson bound (wilson_lower - avg_entry_price), not a Wald SE. The Wald SE collapses to zero at hit_rate = 1, which lets single-lucky-win wallets top the ranking.

findings

Stated honestly — the verdicts below are mixed.

league-wide persistence: suggestive, unproven

Cross-wallet persistence of the edge ranking: real Spearman 0.34 between first-half and second-half edge across 21 high-volume wallets. The price-based no-edge null has mean ~-0.02, std ~0.25 → simulated p-value 0.08. Not statistically significant — underpowered with only 21 wallets. The “good wallets stay good” claim is suggestive but unproven.

individual wallets: real edge

9 of 21 high-volume wallets have edge_z > 2. Standout 0x75cc3b...3ce1:

  • edge +8.7 percentage points over price across 3,397 markets
  • edge_z = +11.3
  • split-half stable: first-half edge +0.089, second-half +0.085

That per-wallet edge is statistically overwhelming and self-consistent across the wallet’s own history.

the edge is real and copyable (corrected)

Correction — earlier reading of the slug timestamp was wrong

An earlier version of this note called the high-edge wallets “post-resolution settlement snipers” with an edge that probably can’t be copied. That was based on assuming the unix timestamp in market slugs (e.g. btc-updown-15m-1769462100) is the market’s end/resolution time. It is not — it is the market’s start/open time.

Proof: bucket winning-side BUY trades by position through the market window and plot the price paid. The winning token sits at ~0.74 by the end of the window, and reaches ~1.00 right after it — it trades at ~$0.55.

So:

  • The high-edge wallets trade in-window on live, undecided markets, not after resolution. 0x75cc3b enters ~15% into the window.
  • The +8.7pp edge over price is a real in-window edge and is copyable. The book drifts only ~3-4 cents per 10% of window, so a copy placed seconds-to-a-minute behind keeps most of the edge.
  • Mechanism: a Binance → Polymarket latency arbitrage. Polymarket’s BTC Up/Down order book lags real BTC spot on Binance; bots reading Binance fast buy the cheap correct side before Polymarket’s book reprices. A public open-source implementation exists: github.com/learningworship/polymarket-latency-bot.

infrastructure: where the latency race actually is

Polymarket’s order matching is off-chain. A centralized Polymarket operator runs the CLOB and matches orders on its own servers; Polygon only does on-chain settlement of already-matched, EIP-712-signed trades.

Consequences for anyone thinking about colocation:

  • Colocating near Polygon validators does not help. There is no “Jito for Polymarket” that matters — Jito / Polygon-MEV infra is about block inclusion, which is not the race here.
  • The race is network latency to Polymarket’s CLOB API, which runs on AWS eu-west-2 (London).
  • Colocation = AWS eu-west-2, or Dublin / London Equinix (<0.5-5ms). US-East is ~130ms — too slow.
  • Polymarket offers KYC’d co-location in eu-west-2 and a low-latency RTDS market-data stream for market makers.

Next step

The project owner wants to build this as a latency bot. Next: measure the actual Binance → Polymarket repricing lag to size the opportunity and the colocation requirement. The lag-probe harness now does this measurement — pending an overnight capture during real volatility.

Strategy thesis superseded (2026-05-25)

The “Binance → Polymarket latency arb” framing above is the wrong characterization of where this cohort’s money comes from. A reverse-engineering pass on 0x75cc3b’s 43,734 trades (cross-validated on 8 others) found the edge is late-window 5m longshot reversion + momentum-chase, signal source = book state + time-in-window, NOT BTC vs book lag. The naive lag-arb model failed M0 backtesting at 46% win rate. The per-wallet edge_z = +11.3 finding here is still real — the mechanism was misidentified. See top-trader-edge for the corrected thesis and bot v2 redesign.

  • polymarket-fetch — schema, CLI, trades pipeline this builds on
  • copy-trade-algorithm — sibling analysis, all-category; same survivorship-bias class hit there
  • top-trader-edge — corrected strategy thesis: edge is late-window book mispricing, not latency arb

Graph View