DEV Community: Samuel EF. Tinnerholm

How I caught Polymarket front-running a Trump headline by 7 hours, using only a public order-book API

Samuel EF. Tinnerholm — Sun, 24 May 2026 20:15:18 +0000

TL;DR — On May 23, 2026, Donald Trump posted on Truth Social at 21:50 UTC that a US–Iran ceasefire was "largely negotiated." By the time the post hit, the Polymarket book for "Will the ceasefire continue through May 24?" had already done 85% of the price discovery. The first big move came at 14:18 UTC — 7 hours and 32 minutes before the post. I pulled 36 hours of L2 order book snapshots, lined them up against every wire-service headline I could find, and put together the timeline. All the data, code, and charts are in a public GitHub repo. This post walks through how I did it.

I've been playing with the PMXT historical order book API for prediction markets. The pitch is simple: pull tick-level L2 book snapshots for any Polymarket market, at any moment in its history, in four lines of Python.

I wanted to try it on a real news event. The May 23 Iran ceasefire announcement was timestamped (5:50 PM EDT, via TIME, CNBC, Al Jazeera, and WaPo), so I'd know exactly where to look. I also had a hunch — Polymarket has been increasingly cited as a leading indicator for geopolitical news, and I wanted to see whether the order book actually reflects that or whether the "prediction markets are efficient" narrative oversells the truth.

The answer turned out more interesting than I expected.

Step 1 — Pulling the data

The whole fetch is four substantive lines of code.

from pmxt import Polymarket

poly = Polymarket(pmxt_api_key="pmxt_...")
book = poly.fetch_order_book(
    "0xd7540d64e03b1894ececcbb54c02b88d9c5c0e854ba66ec4e1ece20477994ac5",
    params={"since": 1779492000000, "outcome": "yes"},
)
print(f"{book.dt}: {len(book.bids)} bids, {len(book.asks)} asks")

The first argument is the Polymarket conditionId for the market — a 64-character hex string you can grab from the market's URL on polymarket.com (or market.contract_address if you've already done a fetch_market(slug=…) lookup). The since parameter is a Unix millisecond timestamp — any moment in the market's history. The outcome filter tells the reconstruction which side of the binary outcome to return ("yes" or "no").

That returns a full L2 snapshot — every resting bid and ask, with price and size, as the book existed at that moment. Sub-cent ticks (Polymarket uses a 0.001 tick), 30–60 levels per side typically.

To get a full time series, you just loop the call with timestamps spaced however densely you want. I went with 3-minute cadence over a 36-hour window (May 23 06:00 UTC → May 24 18:00 UTC) to cover the day of the news cycle plus a baseline period before and after. That works out to 721 requests per market.

I had to be careful about rate limits — PMXT caps you at 100 req/min, and my naive parallel fetcher blew past that the first time and started getting 429s back. The fix was a simple paced loop at 85 req/min plus a per-call 15-second timeout (one call hung forever and froze the whole script before I added the timeout). The full fetcher with streaming progress is in scripts/fetch.py.

I also pulled four other related markets — two more ceasefire deadlines (May 27, May 31), plus two regime-fall markets as controls. About 30 minutes of total fetch time at the polite cadence.

Step 2 — Looking at the headline market

First thing I plotted was the simple thing: depth heatmap of the May-24 ceasefire market over the 36-hour window.

The mid-price line climbs from ~78¢ to ~97¢ over the window. The green bid wall and red ask wall on either side of it show the resting depth at each moment. Color intensity encodes log-depth (brighter = more contracts resting at that price).

Two things popped out immediately:

The price moves in two distinct phases. A choppy morning where YES sits in the 70s, then a sharp climb starting mid-afternoon UTC that pushes it to the 90s by evening.
The biggest single price move comes before — not after — the time I was expecting the news to land.

Trump's post was at 21:50 UTC. The market hit 95¢ by 21:00. The post moved it from 95 to ~98 — barely a wiggle.

That made me curious. Where did the rest of the move come from?

Step 3 — Cumulative price discovery

To make the asymmetry obvious, I converted price into "percent of total move priced in" — what fraction of the eventual ~25¢ rally had completed at each moment.

The annotation marks 82% — by Trump's Truth Social post, the market was 82% of the way to its eventual price. The post contributed the remaining ~15%. Put another way:

Pre-news move: +22¢ over the day
Post-news move: +3¢ over the next ~6 hours
Ratio: for every 1¢ the market moved AFTER Trump's post, it had already moved ~7¢ BEFORE it.

The negative red region at the start is interesting too — the market briefly drifted slightly AGAINST the eventual move during the morning (an early Trump "United States of the Middle East?" post had been hawkish, so the market was actually short before reversing).

Step 4 — Was there a public news item that could explain the pre-news rally?

This is where the analysis got serious. If a wire-service headline hit at 14:18 UTC, the "front-running" story is just normal market reaction time. So I built a timeline of every public Iran-related signal I could find for May 23.

I cross-referenced WaPo, CNN, Axios (which had two scoops that day), CBS, ABC News, Al Jazeera, Reuters, TIME, Pakistan ISPR, Iran MFA, and Trump's own Truth Social feed. I plotted them against the price.

The yellow vertical line is 14:18 UTC — the first big Polymarket move (+7¢ in 29 minutes). The red line is Trump's 21:50 UTC post. Every other public news item is plotted as a thin dotted vertical line, with timestamps in the legend in the upper-left.

The earliest positive news item I could find for the day was Marco Rubio in New Delhi at 14:23 UTC saying "good news in the next few hours, at least in regard to the straits." That hit the wires 5 minutes after the Polymarket move.

Every other positive signal — Pakistan's ISPR statement (14:55 UTC), the Axios "50/50" exclusive (15:29 UTC), the Washington Times "draft within 24 hours" scoop (17:30 UTC) — came 37 minutes to 3+ hours after the price had already moved.

The only event timestamped before 14:18 UTC was a US CENTCOM tweet at 13:33 UTC about a blockade milestone — which is hawkish, not bullish for ceasefire continuation. It can't explain why YES rallied.

Step 5 — Was it just one market, or replicated?

A single market jumping at 14:18 could be one trader getting lucky on a hunch. To distinguish luck from informed trading, I checked whether the move replicated across other ceasefire markets (different deadlines, but the same underlying news).

Three different markets — "Will the ceasefire continue through May 24?", "…through May 27?", and "…through May 31?" — all started rallying within minutes of each other at 14:18 UTC. Same direction. Same time. Magnitudes scaled to duration (the shorter-dated market ends higher because it's more confident in a short-term ceasefire).

That's a much harder pattern to chalk up to luck. It's coordinated, multi-market buying ahead of an unannounced event.

Step 6 — Order book microstructure

The price chart shows what happened. The order book microstructure shows how it happened.

I computed the order-book imbalance — (bid_depth - ask_depth) / (bid_depth + ask_depth) — for each snapshot, and shaded the normal range (mean ± 1σ during the pre-13:00 UTC baseline).

imbalance = (bid_depth_total - ask_depth_total) / (bid_depth_total + ask_depth_total)

The bid-side imbalance breaks clearly above the baseline band during the 14:00–17:00 UTC window — the yellow-shaded "pre-news breakout window." This is what informed accumulation looks like in the order book: buyers stacking the bid side aggressively before a known catalyst, ahead of where they think the price is going.

I also looked at the absolute depth on each side over the same window:

Both sides oscillate around 100–200K contracts pre-news, then go crazy after the announcement — the ask side spikes to 400K+ in several intervals as people try to take profit or trade against the new high price. Pre-news, the relative ratio is what matters; post-news, sheer volatility takes over.

What I conclude (and what I don't)

The defensible reading: the Polymarket book priced ~85% of the news before the news broke. That's an empirical observation, traceable in the data I committed to the repo, with the timestamps and identifiers anyone can re-verify.

There are two ways to interpret it:

(1) Someone knew the announcement was coming and bought ahead. The replication across three markets and the bid-side imbalance breakout make this consistent with the observable pattern. But "knew" is doing a lot of work in that sentence — knew through what? Reuters terminal? Diplomatic chat group? A leak from one of the negotiating teams? I have no way to tell.

(2) Prediction markets aggregate private information so efficiently that headline news is stale on arrival. The Munir-Tehran trip, the Rubio India agenda, the Gulf-leader phone calls, the Vance-Witkoff-Kushner draft — these were all being discussed in private channels through the day. Polymarket may simply have been faster at synthesizing the signal than CNN.

Both readings are bullish for the value of prediction-market data as an information source. Whichever you believe, the practical lesson is the same: if you wait for the headline, you're trading against people who didn't.

Caveats

One news cycle, one set of markets. I'm not claiming this is the typical pattern. To make that claim I'd need to run the same analysis across dozens of events and check the base rates.
My news timeline might be incomplete. I read 50+ sources but I can't claim exhaustive coverage of every Reuters/Bloomberg terminal headline. If there was a positive Iran-related wire at 14:15 UTC that I missed, the "front-running" story collapses.
Sampling cadence. 3-minute snapshots are coarse. Finer-grained data (10s or even per-trade) might surface even earlier signals or change the timing claims. Worth re-running.
"Insider trading" requires intent and material non-public information — both legal terms. I'm not making that claim. I'm describing what's visible in the book.

Try it yourself

Everything is in the repo: github.com/realfishsam/polymarket-iran-may-23.

git clone https://github.com/realfishsam/polymarket-iran-may-23
cd polymarket-iran-may-23
pip install -r scripts/requirements.txt

# Re-render the charts from the committed data
python3 scripts/render_heatmaps.py
python3 scripts/render_overlay.py
python3 scripts/render_supporting.py
python3 scripts/analyze.py

# Or pull fresh data with your own PMXT key
export PMXT_API_KEY=pmxt_...
python3 scripts/fetch.py

data/*.csv — the book snapshots in tidy long format (snapshot_ts_ms, side, price, size). One file per market, ~30K rows each.
data/raw/*.ndjson — the raw streaming output from the fetcher
charts/*.png — every chart in this post, pre-rendered
scripts/ — fetch, analyze, render

If you find a public news item I missed that would explain the 14:18 UTC move, open an issue.

Stack

PMXT — historical order book API for Polymarket / Kalshi
Python 3.10
pandas, numpy, scipy
matplotlib (with a custom dark theme — code in scripts/render_heatmaps.py)

Cover chart and all visualizations in this post are CC-BY 4.0. Code is MIT. Polymarket is the data source; PMXT is the API that makes it queryable.

DomeAPI Alternative: How to Migrate Your Bots to pmxt

Samuel EF. Tinnerholm — Sat, 21 Feb 2026 08:39:03 +0000

Migrating from DomeAPI to pmxt

This guide helps you migrate your Polymarket integration from DomeAPI to pmxt.

Why migrate?

DomeAPI is shutting down March 31, 2025. Polymarket acquired DomeAPI and is discontinuing the service. If you rely on DomeAPI for market data or trading, you need to migrate before that date.

	DomeAPI	pmxt
Authentication	API key (paid tiers)	No API key for market data
Exchanges	Polymarket, Kalshi	Polymarket, Kalshi, Limitless, Probable, Baozi, Myriad
Trading	Order router (linked wallet)	Native (your private key, direct on-chain)
License	Proprietary service	Open source (MIT)
Rate limits	Tiered (10-300 QPS)	Exchange-native

Installation

Before (DomeAPI):

# TypeScript
npm install @dome-api/sdk

# Python
pip install dome-api-sdk

After (pmxt):

# TypeScript
npm install pmxtjs

# Python
pip install pmxt

Client initialization

Before (DomeAPI):

// TypeScript
import { DomeClient } from '@dome-api/sdk';
const dome = new DomeClient({ apiKey: 'your-api-key-here' });

# Python
from dome_api_sdk import DomeClient
dome = DomeClient({"api_key": "your-api-key-here"})

After (pmxt):

// TypeScript
import pmxt from 'pmxtjs';
const poly = new pmxt.Polymarket();
const kalshi = new pmxt.Kalshi();

# Python
import pmxt
poly = pmxt.Polymarket()
kalshi = pmxt.Kalshi()

No API key required for market data. The pmxt server starts automatically on first use.

Method mapping

Market price

Before (DomeAPI):

const price = await dome.polymarket.markets.getMarketPrice({ token_id: '...' });

price = dome.polymarket.markets.get_market_price({"token_id": "..."})

After (pmxt):

const markets = await poly.fetchMarkets({ query: 'Trump' });
const price = markets[0].yes?.price; // 0.0 to 1.0

markets = poly.fetch_markets(query='Trump')
price = markets[0].yes.price  # 0.0 to 1.0

Note: DomeAPI returns price as a raw value. pmxt prices are always 0.0-1.0 (probability). Multiply by 100 for percentage.

Markets search

Before (DomeAPI REST):

GET https://api.domeapi.io/v1/polymarket/markets
  ?search=Trump
  &status=open
  &min_volume=10000
  &limit=20
  &pagination_key=<cursor>

After (pmxt):

const markets = await poly.fetchMarkets({
  query: 'Trump',
  status: 'active',
  limit: 20,
  offset: 0,   // offset-based, not cursor-based
});

markets = poly.fetch_markets(
    query='Trump',
    status='active',
    limit=20,
    offset=0,
)

Pagination change: DomeAPI uses cursor-based pagination (pagination_key). pmxt uses offset-based pagination (offset).

Filter by slug/condition_id:

// DomeAPI: filter by market_slug or condition_id query params
// pmxt: use the slug param
const markets = await poly.fetchMarkets({ slug: 'will-trump-win-the-2024-election' });

Events

Before (DomeAPI):

GET https://api.domeapi.io/v1/polymarket/events
  ?search=Fed+Chair
  &status=open

After (pmxt):

const events = await poly.fetchEvents({ query: 'Fed Chair' });
const market = events[0].markets.match('Kevin Warsh');
console.log(market.yes?.price);

events = poly.fetch_events(query='Fed Chair')
market = events[0].markets.match('Kevin Warsh')
print(market.yes.price)

Candlesticks (OHLCV)

Before (DomeAPI):

GET https://api.domeapi.io/v1/polymarket/candlestick
  ?condition_id=<condition_id>
  &interval=1h
  &start_ts=<unix_seconds>
  &end_ts=<unix_seconds>

After (pmxt):

The key difference: pmxt takes an outcome_id, not a condition_id. Use outcome.outcomeId (TypeScript) or outcome.outcome_id (Python).

const markets = await poly.fetchMarkets({ query: 'Trump' });
const outcomeId = markets[0].outcomes[0].outcomeId; // NOT market.marketId

const candles = await poly.fetchOHLCV(outcomeId, {
  resolution: '1h',                  // '1m' | '5m' | '15m' | '1h' | '6h' | '1d'
  start: new Date('2025-01-01'),     // Date object (not unix seconds)
  end: new Date('2025-02-01'),
  limit: 100,
});

// candle.timestamp is Unix milliseconds (DomeAPI may differ)

markets = poly.fetch_markets(query='Trump')
outcome_id = markets[0].outcomes[0].outcome_id  # NOT market.market_id

candles = poly.fetch_ohlcv(
    outcome_id,
    resolution='1h',
    start='2025-01-01',
    end='2025-02-01',
    limit=100,
)
# candle.timestamp is Unix milliseconds

Interval name changes:

DomeAPI	pmxt
`1m`	`1m`
`5m`	`5m`
`15m`	`15m`
`1h`	`1h`
`6h`	`6h`
`1d`	`1d`

Order book

Before (DomeAPI):

GET https://api.domeapi.io/v1/polymarket/orderbook-history
  ?token_id=<token_id>
  &start_ts=...
  &end_ts=...

DomeAPI provides historical orderbook snapshots. pmxt provides the current live order book.

After (pmxt):

const markets = await poly.fetchMarkets({ query: 'Trump' });
const outcomeId = markets[0].outcomes[0].outcomeId;

const book = await poly.fetchOrderBook(outcomeId);
console.log('Best bid:', book.bids[0].price);
console.log('Best ask:', book.asks[0].price);

markets = poly.fetch_markets(query='Trump')
outcome_id = markets[0].outcomes[0].outcome_id

book = poly.fetch_order_book(outcome_id)
print('Best bid:', book.bids[0].price)
print('Best ask:', book.asks[0].price)

Calculate execution price (new in pmxt, not in DomeAPI):

const price = poly.getExecutionPrice(book, 'buy', 100); // avg price for 100 shares

price = poly.get_execution_price(book, 'buy', 100)

Trade history

Before (DomeAPI):

GET https://api.domeapi.io/v1/polymarket/trade-history
  ?token_id=<token_id>
  &start_ts=<unix_seconds>
  &end_ts=<unix_seconds>

After (pmxt):

const trades = await poly.fetchTrades(outcomeId, {
  start: new Date('2025-01-01'),
  end: new Date('2025-02-01'),
  limit: 100,
});

trades = poly.fetch_trades(
    outcome_id,
    start='2025-01-01',
    end='2025-02-01',
    limit=100,
)

Time format change: DomeAPI uses Unix seconds. pmxt uses Date objects (TypeScript) or ISO strings (Python). Returned timestamps are Unix milliseconds in both.

Positions

Before (DomeAPI):

GET https://api.domeapi.io/v1/polymarket/positions
  ?wallet=<address>

DomeAPI fetches positions for any wallet address publicly.

After (pmxt):

// Requires authentication - fetches YOUR positions
const positions = await poly.fetchPositions();
positions.forEach(pos => {
  console.log(`${pos.outcomeLabel}: ${pos.size} @ $${pos.entryPrice}`);
  console.log(`Unrealized P&L: $${pos.unrealizedPnL}`);
});

positions = poly.fetch_positions()
for pos in positions:
    print(f"{pos.outcome_label}: {pos.size} @ ${pos.entry_price}")
    print(f"Unrealized P&L: ${pos.unrealized_pnl:.2f}")

pmxt does not support looking up arbitrary wallet positions by address. It only returns your own positions via authenticated requests.

Wallet P&L

DomeAPI provides wallet/pnl for realized P&L by wallet address. pmxt does not have a direct equivalent - use fetchPositions() which includes unrealized_pnl and realized_pnl fields for your own account.

Real-time data (WebSocket)

Before (DomeAPI):

// DomeAPI WebSocket for Polymarket order data
const ws = dome.polymarket.websocket.subscribe({ token_id: '...' });

After (pmxt):

const outcomeId = markets[0].outcomes[0].outcomeId;

// Stream order book updates
for await (const book of poly.watchOrderBook(outcomeId)) {
  console.log('Best bid:', book.bids[0].price);
}

// Stream trades
for await (const trade of poly.watchTrades(outcomeId)) {
  console.log('Trade:', trade.price, trade.amount);
}

# Python (async generator)
async for book in poly.watch_order_book(outcome_id):
    print('Best bid:', book.bids[0].price)

Trading (new in pmxt)

DomeAPI has an "Order Router" that requires linking your wallet. pmxt trades directly using your private key.

Setup (Polymarket)

const exchange = new pmxt.Polymarket({
  privateKey: process.env.POLYMARKET_PRIVATE_KEY,
  funderAddress: process.env.POLYMARKET_PROXY_ADDRESS, // optional
});

import os
exchange = pmxt.Polymarket(
    private_key=os.getenv('POLYMARKET_PRIVATE_KEY'),
    proxy_address=os.getenv('POLYMARKET_PROXY_ADDRESS'),  # optional
)

Place an order

const markets = await exchange.fetchMarkets({ query: 'Trump' });
const order = await exchange.createOrder({
  marketId: markets[0].marketId,
  outcomeId: markets[0].yes?.outcomeId,
  side: 'buy',
  type: 'limit',
  amount: 10,   // contracts
  price: 0.55,  // 0.0-1.0
});

markets = exchange.fetch_markets(query='Trump')
order = exchange.create_order(
    outcome=markets[0].yes,  # shorthand
    side='buy',
    type='limit',
    amount=10,
    price=0.55,
)

Data model changes

Market ID and Outcome ID

DomeAPI	pmxt
`condition_id`	`market.marketId` / `market.market_id`
`token_id`	`outcome.outcomeId` / `outcome.outcome_id`
`market_slug`	`market.url` (full URL)

Outcome structure

Before (DomeAPI):

{
  "side_a": { "id": "...", "label": "Yes" },
  "side_b": { "id": "...", "label": "No" }
}

After (pmxt):

market.outcomes        // all outcomes as array
market.yes             // shorthand for binary Yes outcome
market.no              // shorthand for binary No outcome
market.outcomes[0].outcomeId
market.outcomes[0].label
market.outcomes[0].price  // 0.0 to 1.0

Price scale

DomeAPI	pmxt
Varies (check docs)	Always 0.0 to 1.0 (multiply by 100 for %)

Timestamp format

DomeAPI	pmxt
Unix seconds (some endpoints)	Unix milliseconds (all endpoints)

# Convert pmxt timestamp to datetime
from datetime import datetime
dt = datetime.fromtimestamp(candle.timestamp / 1000)

Pagination

DomeAPI	pmxt
Cursor-based (`pagination_key`)	Offset-based (`limit` + `offset`)

Feature gaps

Some DomeAPI features have no direct pmxt equivalent:

DomeAPI feature	pmxt alternative
Wallet positions by address	`fetch_positions()` (own account only)
Wallet P&L by address	`fetch_positions()` unrealized/realized P&L
Sports cross-platform matching	Not available
Binance / Chainlink price feeds	Not available
Activity feed by wallet	Not available
Historical orderbook snapshots	`watch_order_book()` for live data

Multi-exchange support (new in pmxt)

pmxt gives you the same API across all supported exchanges:

const poly = new pmxt.Polymarket();
const kalshi = new pmxt.Kalshi();
const limitless = new pmxt.Limitless();

// Same methods on all exchanges
const polyMarkets = await poly.fetchMarkets({ query: 'Fed Chair' });
const kalshiMarkets = await kalshi.fetchMarkets({ query: 'Fed Chair' });

Quick reference

Task	DomeAPI	pmxt (TypeScript)	pmxt (Python)
Get market price	`getMarketPrice({ token_id })`	`fetchMarkets({ query })` then `.yes.price`	`fetch_markets(query=...)` then `.yes.price`
Search markets	`GET /polymarket/markets?search=`	`fetchMarkets({ query })`	`fetch_markets(query=...)`
Get OHLCV	`GET /polymarket/candlestick?condition_id=`	`fetchOHLCV(outcomeId, { resolution })`	`fetch_ohlcv(outcome_id, resolution=...)`
Get order book	`GET /polymarket/orderbook-history?token_id=`	`fetchOrderBook(outcomeId)`	`fetch_order_book(outcome_id)`
Get trades	`GET /polymarket/trade-history?token_id=`	`fetchTrades(outcomeId, params)`	`fetch_trades(outcome_id, ...)`
Real-time book	WebSocket subscribe	`watchOrderBook(outcomeId)`	`watch_order_book(outcome_id)`
Place order	Order Router API	`createOrder(params)`	`create_order(...)`
Get positions	`GET /polymarket/positions?wallet=`	`fetchPositions()`	`fetch_positions()`
Get balance	N/A	`fetchBalance()`	`fetch_balance()`

domeapi.io free and open source alternative

Samuel EF. Tinnerholm — Fri, 13 Feb 2026 15:51:45 +0000

If you are building trading bots or analytics for prediction markets (Polymarket, Kalshi, etc.), you generally have two infrastructure choices: a commercial SaaS wrapper or an open-source library.

DomeApi is the leading commercial solution. It’s a robust "Stripe-like" SaaS that handles node management and data normalization for a fee. It is excellent for enterprise teams that need SLAs and managed infrastructure.

pmxt is the free, open-source alternative. It is a Python library designed for developers who prefer local execution, zero fees, and full control over their order flow.
Feature, DomeApi.io, pmxt (Open Source) Model, Commercial SaaS (B2B), Open Source Library (MIT) Cost, Paid / Credit-based, Free Execution, Via 3rd-party API, Local / Direct-to-Exchange Privacy, Middleman sees trades, Private (You own the keys) Best For, "Startups, Apps", "Traders, Researchers, Devs"
Why use pmxt?
For many individual developers and algorithmic traders, a SaaS layer adds unnecessary latency and cost. pmxt is modeled after ccxt, unifying the fragmented APIs of various prediction markets into a single, consistent class structure.

Zero Latency Overhead: You connect directly to the exchange APIs (Polymarket, Kalshi, etc.) from your own machine or server.

No Rate Limits (from us): You are only bound by the exchange's own limits.

Unified Interface: Switch between exchanges without rewriting your entire codebase.

Code Example
Here is how to fetch markets and place a trade using pmxt:
`
import pmxt

api = pmxt.Exchange()

1. Search for the broad Event

events = api.fetch_events(query='Who will Trump nominate as Fed Chair?')
fed_event = events[0] # first event (by volume)

2. Filter for the specific Market within that event

warsh = api.filter_markets(fed_event.markets, 'Kevin Warsh')[0] # first market match

print(f"Price: {warsh.yes.price}")
`

Get Started
If you need a reliable, free alternative to commercial prediction market APIs, check out the repo.

Documentation: https://pmxt.dev/docs
GitHub: https://github.com/pmxt-dev/pmxt

How I Built a "Risk-Free" Arbitrage Bot for Polymarket & Kalshi

Samuel EF. Tinnerholm — Fri, 16 Jan 2026 15:34:23 +0000

TL;DR:

I found a consistent 2-5% price spread between the two biggest prediction markets. To capture it, I had to solve the nightmare of API fragmentation. Here is the open-source bot I built to automate it.

The Opportunity: Synthetic Arbitrage

If you look closely at prediction markets, you’ll often find the same event trading at different prices on different platforms.

If you buy YES on Kalshi (35¢) and NO on Polymarket (63¢), your total cost is 98¢. When the event resolves, one side must pay out $1.00. That is a guaranteed $0.02 profit regardless of the outcome.

It sounds small, but if you can automate this and rotate capital weekly, that 2% compounds into a massive APY.

The Problem: API Hell

The math is easy. The engineering is hard. Polymarket is a crypto-native platform (Polygon/EVM) using a CLOB (Central Limit Order Book). Kalshi is a US-regulated exchange with a completely different REST API structure.

Trying to normalize these two data streams in real-time to find spreads is a headache, and simply not worth it.

I didn't want to write 500 lines of boilerplate code every time I wanted to test a strategy. So, I used pmxt, a unified wrapper inspired by CCXT, but for prediction markets.

The Build
Here is the core logic of the bot. You can find the full source code here.

The Build

1. Unifying the Markets

First, we need to fetch markets from both platforms and treat them as identical objects. pmxt abstracts away the messy JSON structures so we can focus on the price.

import pmxt from 'pmxtjs';

// Initialize the unified clients
this.polymarket = new pmxt.polymarket({ privateKey: config.privateKey });
this.kalshi = new pmxt.kalshi({ apiKey: config.apiKey, apiSecret: config.secret });

async fetchMarkets() {
    // We pass the "slug" for the event we want to arb (e.g., Fed Rates)
    const [polyMarkets, kalshiMarkets] = await Promise.all([
        this.polymarket.getMarketsBySlug(this.config.polymarketId),
        this.kalshi.getMarketsBySlug(this.config.kalshiId)
    ]);

    return { polyMarkets, kalshiMarkets };
}

2. Finding the Spread

This is where the magic happens. We look for the "inversion": where Price(YES_Poly) + Price(NO_Kalshi) < $1.00.

// Inside the poll() loop
const allOpportunities = findArbitrageOpportunities(matches, minProfitCents)
    .filter(opp => {
        // Filter out dead markets with no bids/asks
        const polyYes = opp.polymarketOutcome.yesPrice;
        const kalshiNo = opp.kalshiOutcome.noPrice;

        return polyYes > 0.01 && kalshiNo > 0.01;
    })
    .sort((a, b) => b.profit - a.profit); // Rank by highest ROI

if (allOpportunities.length > 0) {
    const bestOpp = allOpportunities[0];
    await this.executeArbitrage(bestOpp);
}

3. Execution & Rotation

Many arbitrageurs make the mistake of holding until maturity (expiration). This kills your returns. waiting 3 months to realize 2% is bad capital efficiency.

Instead, my bot uses a Rotation Strategy. It enters when the spread widens (entry point) and exits immediately when the spread closes (or when a better opportunity appears).

shouldExitPosition(opportunities) {
    if (!this.currentPosition) return false;

    const currentOpp = opportunities.find(o => o.id === this.currentPosition.id);

    // 1. Exit if the arb is gone (take profit)
    if (!currentOpp || currentOpp.profit < this.config.minProfit) return true;

    // 2. ROTATION: Exit if a BETTER opportunity exists
    const bestOpp = getBestOpportunity(opportunities);
    if (bestOpp.profit > currentOpp.profit) {
        return true;
    }

    return false;
}

Results & Risks

The bot has successfully captured spreads ranging from 1.5% to 4.5% on high-volume events like Fed Rates and Election markets.
However, "Risk-Free" is a mathematical term, not a practical one.

Prices can move between your first and second API call. pmxt tries to minimize this latency, but it's non-zero.
You might get filled on Polymarket but stuck on Kalshi if volume dries up.
Unlike crypto DEXs, withdrawing fiat from regulated exchanges takes days, slowing down your velocity.

I built this to prove that prediction markets are mature enough for algorithmic trading. The tooling just needs to catch up.

The Library (pmxt) <-- Drop a star!

The Bot

If you find this useful, drop a star on the repo. It helps me justify spending weekends maintaining the API wrapper!

Stop Using Frameworks: Why pmxt Beats dr-manhattan and predmarket

Samuel EF. Tinnerholm — Thu, 15 Jan 2026 11:26:56 +0000

The prediction market ecosystem is exploding, and with it comes the inevitable race to build the standard infrastructure layer- the “CCXT” of prediction markets.

Developers are desperate for a unified API to trade across Polymarket, Kalshi, and Manifold without rewriting their entire codebase for every exchange. Three libraries have emerged to claim this throne: pmxt, dr-manhattan, and predmarket.

But if you look past the GitHub READMEs, the reality is stark. Two of these are hobbyist experiments disguised as products, and only one is actual infrastructure.

The “Vibe-Coded” Identity Crisis: dr-manhattan

dr-manhattan is the perfect example of "style over substance."

First, look at their website. It is pure “vibe-coding”: dark mode, neon gradients, and a flashy “Get Started” button. But instead of leading to a documentation portal or a proper setup guide, it just scrolls you down to a raw uv pip install -e git+... command. If you can’t even package your code properly on PyPI, why should I trust you to build a high-frequency trading framework? And that is exactly what dr-manhattan is: a framework, not a library. It suffers from a massive identity crisis. Instead of giving you clean connectors to exchanges, it forces you to inherit from its own Strategy base class and use its internal logic loops. It is bloated with opinionated code that has no place in a connectivity library like the ccxt for prediction markets.

Worst of all, it’s dishonest. Their branding claims they are the “#1 Open Source for Market-making,” yet the numbers tell a different story. As of early 2026, dr-manhattan sits at the bottom of the pile with ~60 GitHub stars, lagging behind predmarket (~70) and getting crushed by pmxt (100+).
It has no docs, it is not pip/npm installable, and it is trying to be a trading bot rather than a tool.

The Predmarket

Then there is predmarket. When they first launched, they were a strong addition to the ecosystem and a great starting point for developers. However, the project is no longer actively maintained. Without a website, documentation, or a proper package manager release, it has unfortunately become a relic. It remains a useful reference for hobbyists, but it is no longer a viable choice for active production environments.

The Adult in the Room: pmxt

Finally, we have pmxt. While dr-manhattan isstruggling with identity crises and predmarket not being actively maintained, pmxt is delivering the actual product. Its homepage slogan is simple and honest: "The ccxt for prediction markets," and it actually delivers on that promise.

It features a unified API that genuinely abstracts the differences between exchanges like Polymarket, Kalshi, and Manifold, effectively solving the fragmentation problem. It is standard, documented, and installable. It doesn’t force you to rewrite your bot to fit a specific framework; it simply connects you to the markets and gets out of your way.

Feature	pmxt	dr-manhattan	predmarket
Installable (pip/npm)	✓	X (Git clone only)	X
Documentation	✓	X	X
Architecture	Unopinionated Library	Opinionated Framework	Script Wrapper
Exchanges	Poly, Kalshi, Manifold	Poly, Kalshi, Niche Chains	Poly, Kalshi

If you want a framework that forces you to write code their way, use dr-manhattan. If you want a raw script to maintain yourself, use predmarket.

But if you want the standard infrastructure layer for prediction markets, use pmxt.

CCXT for Prediction Markets: Introducing PMXT

Samuel EF. Tinnerholm — Tue, 13 Jan 2026 16:06:27 +0000

If you’ve ever used CCXT for crypto trading, you know how powerful a unified API can be. Until now, prediction markets like PolyMarket and Kalshi lacked that standard.

Enter pmxt.

The “CCXT for prediction markets” is finally here. pmxt is a unified API for accessing real-time candles, orderbooks, and history across multiple exchanges.

Get Started Give the repo a star or install it now.

npm install pmxtjs
https://github.com/qoery-com/pmxt

Why You’re Overpaying for Crypto Data (And Why It’s Not Your Fault)

Samuel EF. Tinnerholm — Tue, 30 Dec 2025 05:02:42 +0000

If you’re building for DeFi, you are currently paying for data you don’t use.

The big incumbents (CoinMarketCap, CoinGecko, etc.) charge enterprise rates because they maintain expensive infrastructure to track Centralized Exchanges. They scrape Binance, scrub wash-trading, and normalize order books.

That’s great for them. But why are you paying for it?
If your users are swapping on Uniswap, paying a premium for Binance data is just burning runway.

Stop Paying for the Middleman
We built qoery to fix the pricing model for DeFi data.

They query CEXs. We query the blockchain directly (Uniswap v2/v3).
They charge for aggregation. We charge for raw access.
They cost hundreds a month. We start at $4.99.
We cut out the “CEX Tax” and passed 85% of the savings back to you.

See the difference yourself: qoery.com/compare

Stop subsidizing data you don’t need. Build with qoery.com.

Mintlify Ignored This Feature Request for 6 Months. Here's Our Solution.

Samuel EF. Tinnerholm — Sat, 22 Nov 2025 22:57:19 +0000

Mintlify users have been begging for pre-filled API playground fields for months. The GitHub discussion has people literally saying "I just lost two hours of my day banging my head against this issue." The problem? When you click "Try it" in Mintlify's playground, every field is empty, even though your OpenAPI spec has perfectly good example values sitting right there. Your developers have to manually type or copy-paste data just to test a single endpoint. It's 2025. This is insane.

So we built madrasly. Run

npx madrasly your-spec.json output-dir

and you get a fully interactive API playground with all fields pre-populated from your OpenAPI examples. Path parameters, query params, request bodies—everything just works. One command, zero configuration, and your developers can actually test your API without wanting to throw their laptop. Check out the live demo or grab it from GitHub. If Mintlify won't fix it, we will.

CLI tool: zipline/backtrader/vectorbt/backtesting.py --> Alpaca/IBKR in 10 seconds

Samuel EF. Tinnerholm — Tue, 01 Jul 2025 12:51:53 +0000

Introduction

Strategy development is hard enough, but then comes the deployment gap between backtesting and live trading. Built a strategy in VectorBT or backtesting.py? You face a complete rewrite for live trading.

Two days ago, I launched StrateQueue to solve this. The response has been incredible: 26 GitHub stars and 1,300 downloads in 48 hours from the quant community on Reddit.

The Problem

Every quant hits the same wall: your backtesting strategy works perfectly, but going live means starting over. The frameworks we love for research: VectorBT, backtesting.py, backtrader, and Zipline, aren't designed for real-time execution. You end up rewriting everything from scratch, introducing bugs, and losing weeks of development time. I've been through this cycle too many times.

The Solution

StrateQueue acts as a bridge between your existing backtesting code and live brokers. No rewrites, no framework changes, just point it at your strategy file and specify your broker. It handles the real-time data feeds, order management, and execution logic while your strategy code stays exactly the same. The whole deployment process takes under 10 seconds.

Demo

Quick-Start

pip install stratequeue
stratequeue deploy \
  --strategy examples/strategies/backtestingpy/sma.py \
  --symbol AAPL \
  --timeframe 1m

Contribution and Feedback

Looking for feedback from real traders on what features matter most. Contributors are welcomed, especially for optimization, advanced order types, and aiding in the development of a dashboard stratequeue webui. Happy to answer questions!

DOCS - GitHub