A Polymarket history that knows what each on-chain event means

The problem

A Polymarket trade follows the creation of a market and the minting of its outcome tokens. After the trade, holders can merge, convert or redeem those tokens. The money behind the tokens can pass through several contracts and contract versions on the way.

To study or score a wallet's trading, you must tie each of those steps to its market and its money. A pipeline can store a row without an error and still book it to the wrong flow. Every profit figure built on that row is wrong too.

What we built

Mihir's earlier pipeline indexed into sharded PostgreSQL schemas. A separate pass then moved the data into ClickHouse.

Titus Intelligence reads Polygon through Envio's HyperSync with its own decoders. Its workers decode, enrich and store each event in one pass. They attach the market, price, side and role to each trade before they write it to ClickHouse.

A master process fixes a chain head for each run. It runs the stages in dependency order: administrative events, the links between tokens and markets, the older pool-based markets, then the order-book exchange's history. The master derives the token-to-market links itself. Each of the other stages gets its own fleet of short-lived workers, coordinated through Redis.

Recent blocks hold far more activity than early blocks. Titus Intelligence therefore cuts work into chunks by event density, not by equal block ranges.

Interpreting events at ingestion puts the hardest rules in the first stage. A decoding fix then has to reach the rows already stored, by ingesting again or by a repair that rewrites them. Mihir accepted that cost so that every later stage, profit and loss and wallet scoring among them, reads events that are already interpreted.

What was hard

Validating the first full run showed that contract versions, collateral changes and token decimal rules changed what some transfers meant. Many stored rows were wrong. Repairing them in place would have meant patch work for each fault, so Mihir chose a fresh ingest of the whole history, and after more fixes, a second one. Before the previous dataset was dropped, a row-by-row comparison against the new one ran. The comparison attributed every difference to a named, expected cause.

Three further faults produced the rules the workers follow now:

• A worker could mark a block range as covered under a newer event list even when its running image lacked some of those events. Workers now check the events they can fetch against what their assignment claims, and refuse the job when they fall short.
• A worker that lost its assignment could have kept writing. Each assignment now carries an ownership generation. A worker advances its progress only after the database write is durable.
• HyperSync does not serve one kind of Polygon system transaction, so the dataset was missing a token mint. The repair tool decodes the mint from receipts that two independent RPC providers agree on. It decodes through the worker's own code and refuses to overwrite any existing row.

The result

The dataset runs in production. Since October 2026 a live worker extends it from finalized Polygon blocks only, so a chain reorganization cannot undo anything the worker writes. The worker records its position only after every table's write has landed. The older pool-based markets stay out of live ingestion, so their history ends where the full ingest did.

The project's validator checks the whole history, including token supply, market bindings and money that has to net to zero. Its run of October 15, 2026, over every block up to 95,563,481, passed 113 of its 114 check families. The one open item is a residual of about 0.21 USDC.e, tracked as an issue.

The next parts are the query API and the stage that turns those events into positions, profit and loss and wallet scores.