DEV Community: Aditya Bajaj

What order books actually look like right before a Polymarket market resolves

Aditya Bajaj — Wed, 08 Jul 2026 14:08:24 +0000

Something interesting happens in the final seconds before a Polymarket market settles, and almost nobody talks about it because almost nobody has the data to look at it. We do, so here's what that moment actually looks like from the order book, not just the price chart.

The setup

A market chart in its last minutes usually looks calm. Price sitting close to its final outcome, maybe 95 cents if the answer is basically known, maybe still bouncing around 50 if it's genuinely uncertain until the very end. That's the surface. The order book underneath tells a different story.

Why liquidity thins right when you'd want it most

As a market approaches resolution, market makers who've been providing depth on both sides have less reason to keep doing it. The information edge that made providing liquidity profitable earlier is gone, the outcome is either known or about to be known, so there's no more edge to capture by quoting a two sided market. The rational move for a market maker is to pull back right before that moment, not add more depth.

That means the exact window where a lot of traders want to make a final move, confirming a position, or trying to squeeze out value from last minute certainty, is often the window with the least real depth behind the price. The chart says the price is 95 cents. The book might say there's almost nothing sitting there at that price if you actually wanted to trade real size.

Why this catches people off guard

If you've only ever looked at price, this looks like a stable, settled market right up until it resolves. If you look at depth, you see the liquidity has often already left before the price chart shows anything unusual. The price can stay flat while the depth behind it evaporates, because price and liquidity are not the same signal, and a chart only shows you one of them.

Anyone trying to enter or exit a position in that final window, assuming the quoted price reflects what they can actually trade at, is working off incomplete information. The number on the chart was real a few minutes ago. It might not be real anymore by the time they try to act on it.

Why this matters beyond curiosity

If you're building any strategy that involves the resolution window specifically, trying to capture value right before a market settles, this is the exact behavior you need to account for. A backtest built on price alone will assume you could always trade at the quoted price. The order book will usually tell you otherwise, right at the moment it matters most.

This is one of the clearest examples of why depth history, not just price history, is the thing worth having if you actually want to understand how a market behaves, not just what it looks like on a chart.

resolvedmarkets.com

Why we picked ClickHouse over TimescaleDB (and why it actually matters)

Aditya Bajaj — Sat, 04 Jul 2026 11:59:57 +0000

Here's the short version. We store hundreds of millions of order book snapshots. Every one has a timestamp down to the millisecond. People run queries like "show me every price change on this market between 2pm and 2:05pm on a specific day." We needed a database built for exactly that job, not one that could sort of do it.

What the actual difference is
TimescaleDB is Postgres with extra tricks for time series data. Under the hood it is still a row based database. That means when it saves a snapshot, it saves the whole row together, timestamp, bid price, ask price, depth, all of it, as one chunk.

ClickHouse works the opposite way. It is column based. It saves all the timestamps together, all the bid prices together, all the ask prices together, and so on. Sounds like a small difference. It is not.

Why that matters for us specifically

Picture what a typical query on our data actually looks like. Someone wants every ask price for one market over a two hour window. They do not care about ninety percent of the other columns in that row.

With a row based system, the database still has to read the whole row to get that one column, then throw away everything else. With a column based system like ClickHouse, it only touches the column you actually asked for. When you are scanning millions of rows for one or two fields, that difference in how much data gets read turns into a massive difference in how fast the answer comes back.

The other reason: how fast we write data in

We are not just storing a little bit of data slowly. We are capturing full order book depth at millisecond resolution, across a hundred plus markets, all the time. That is a constant, heavy stream of writes.

Postgres, and TimescaleDB by extension, was built assuming you write data one transaction at a time with strict guarantees around it. That is great for things like bank transactions. It is not built for a firehose of market ticks arriving nonstop. ClickHouse was built from the ground up for exactly that kind of high volume ingestion, without the overhead Postgres carries for transactional safety we do not actually need here.

What we gave up

Nothing is free. ClickHouse is not great at the kind of thing Postgres is great at, updating individual rows, complex joins across many tables, strict transactional guarantees. If your use case is smaller data with lots of updates and complex relationships, TimescaleDB or plain Postgres is probably the better call. Ours is not that. Ours is enormous, mostly append only, and read in bulk. That is ClickHouse's exact use case.

The real test

We run ClickHouse Cloud so we are not managing the infrastructure ourselves on top of everything else. For a dataset our size, growing by millions of snapshots a day, this was the tool built for the job instead of the tool we happened to already know.

Full docs at resolvedmarkets.com/docs/mcp if you want to see the kind of queries this setup actually handles.

Why Polymarket data infrastructure is harder than it looks (and how we solved it)

Aditya Bajaj — Wed, 01 Jul 2026 14:56:53 +0000

Polymarket does not expose historical order book depth through any public API. If you want to backtest a strategy, or build an agent that reasons about prediction markets, you are stuck with whatever you can scrape off the current state of the book. No history, no depth arrays, nothing.

Here is what that problem actually looks like from an infrastructure angle, and how we ended up solving it.

The data problem

Order book depth is not a small dataset. Capturing every bid and ask level, at every change, across a hundred plus markets, adds up fast. We are storing this at millisecond resolution, which means for any single market you are not looking at one row per minute, you are looking at potentially dozens of rows per second during active trading.

We chose ClickHouse for this specifically because it handles high cardinality time series data at this volume without falling over. Right now that is 1B+ tick level snapshots across crypto, sports, economics, weather, social, equities, and Hyperliquid perpetual futures. A standard Postgres setup would choke on query latency at this scale once you start doing range scans across millions of rows per market.

The access problem

Once you have the data, the harder question is how people actually want to use it, because that varies a lot by who is asking.

Someone building a trading bot wants a REST API they can hit programmatically. Someone watching markets live wants a WebSocket stream, not polling. Someone building an AI agent wants to just ask questions in plain language and get structured answers back, which is where MCP comes in.

We built an MCP server specifically for that last group. If you are running Claude or another agent and want it to reason about historical market data directly, instead of writing custom API integration code, you can connect it and query market history conversationally. Setup docs are here: resolvedmarkets.com/docs/mcp.

What this actually enables

The interesting part is not the data itself, it is what becomes possible once the data exists. You can now check whether a price move was backed by real depth or a thin order getting picked off. You can backtest whether a strategy would have actually filled at the price a chart implies, versus what the book actually showed at that timestamp. You can build an agent that pulls historical snapshots and reasons about market microstructure without you writing the query logic by hand.

None of this is possible with top of book price data alone, which is all that is publicly available right now.

Try it

Free tier gives you BTC data with 24 hours of history, enough to see if the resolution and structure actually work for what you are building. Full docs and MCP setup at resolvedmarkets.com.