PolyBridge

Inspiration

Polymarket now lists contracts that pay \$1 if a stock closes above a stated price on a stated date. Listed options on the same stock price the same event, so two markets quote one probability. We wanted to know which of the two forecasts better, because a market maker who quotes these contracts, or a fund that reads them as a signal, needs to know which price to trust.

What it does

PolyBridge compares the two prices, tests trading ideas built on the gap with rules written before the data, and runs a trading system that acts on a signal only after it passes such a test. The options probability comes from a call spread around the contract's strike: $$\hat p_{\mathrm{opt}} = e^{rT}\,\frac{C(K_1) - C(K_2)}{K_2 - K_1}, \qquad \mathrm{Brier} = \frac{1}{N}\sum_{i=1}^{N} (p_i - y_i)^2$$ On 4,561 Polymarket stock contracts that no earlier test had used, the options price had squared forecast errors 11 percent smaller than the Polymarket price (Brier difference +0.0108, 95% interval +0.0064 to +0.0158). Measuring the options price at the exact timestamp of the Polymarket price leaves the gap at +0.0103, and it survives one moment per contract, equal weight per stock and date, and resampling whole calendar months.

How we built it

• Research pipeline (Python): every test has a method and a frozen contract list committed to git before any price or outcome was fetched, runs once, and reports date-clustered bootstrap intervals. Option quotes come from Massive, prediction-market data from Polymarket and Kalshi.
• Live engine (C++20 with pybind11 and simdjson): one C++ call parses each Polymarket websocket message, updates the order book and makes the trading decision in a median 3.4 microseconds on the live feed, excluding network time.
• Trading system (FastAPI and Next.js): each signal carries a label saying whether it passed a committed test, every order needs a person's approval, and the trading library blocks orders with stale quotes, wide spreads, thin books or broken position, exposure and loss limits. Orders route to a simulated broker or a Webull paper account.

Challenges Our first ladder test came back null, and every losing trade traced to a parser that read "by December 31" in a contract listed in March 2026 as December 2025. The fix is mechanical, but we found it after seeing the losses, so we report the registered null as the result and the corrected replay as exploratory. We also had to resist calling a forecast gap a trade: crossing the options spread costs about as much as the average gap, and none of our 14 weekend and cross-venue strategies passed its registered rule.

What we learned A more accurate price is not automatically a profitable trade. The gap shrinks to almost nothing where the Polymarket price is less than 30 seconds old, so the open question is whether it comes from slow updating or from risk and settlement differences. Writing the rules down first made that answer credible, and it is why PolyBridge enforces the same discipline on every order.

What's next Four tests committed in advance start on 5 October 2026: the accuracy comparison with prices recorded at the same moment, the corrected ladder rule on new ladders, touch tickets on new listings, and capacity from recorded order-book depth instead of past trades. The full paper, methods, data and run logs are in the repository. Our Massive "Trade the 8-K" study is a separate two-page report with its own notebook.

Built With

• c++
• elevenlabs
• fastapi
• gemini
• kalshi
• latex
• matplot
• next.js
• numpy
• openai
• polymarket
• pybind11
• python
• react
• simdjson