Polymarket gives you real-time access to some of its data — order book changes, your own fills, sports scores, new-market signals — but not to the thing flow traders want most: the platform-wide trade tape and money flows. For those, the usual answers are subgraphs (complete but late), raw node streams (fast but expensive and undecoded) — or a purpose-built feed. Here is an honest map of the four routes and what each one actually delivers.
What Polymarket itself streams in real time
The official CLOB websocket is genuinely real-time, and for running your own orders it is exactly the right tool. Subscribe to a market and you get the order book snapshot, then live price_change, tick_size_change, and last_trade_price events. An authenticated user channel pushes your own orders and fills as they happen. Beyond the CLOB there are real-time feeds for sports game state and platform events like new-market creation.
Now the gaps. last_trade_price tells you that a trade printed in a market you subscribed to — not who traded, with whom, or their history; and you must subscribe market by market. The user channel streams your trades only. And money flows — deposits, transfers, redemptions — appear in no official feed at all. The full attributed tape (every fill with both wallets) simply is not on offer, at any latency.
Subgraphs and indexers: complete, but after the fact
The indexing route — Goldsky, Dune, and similar — works from the other end: read confirmed blocks, decode the events, load them into a queryable store. The completeness is excellent; the timing is the problem. Your query result is always confirmation time plus indexing delay behind reality: minutes for a healthy low-latency pipeline, hours for batch-oriented platforms like Dune. For analytics, backtests, and dashboards that is perfectly fine. For reacting to a trade, it is disqualifying — by the time an indexer can show you the panic sell that cost one wallet $62K, the order book has already healed.
Two structural caveats came up in practice. Indexing pipelines degrade — lag spikes and gaps were a recurring pain in Polymarket’s own subgraph era. And that era is over: with the April 2026 v2 contract migration, Polymarket stopped using subgraphs, and the old public endpoints now return incomplete or incorrect data — Goldsky’s recommended replacement is its paid pipeline product. The free-public-subgraph option quietly ceased to exist.
Node streams: real-time and mempool, at a price
The third route skips indexing entirely: subscribe to a node provider’s websocket — Alchemy is the usual choice — for contract logs as blocks land, and for pending transactions from the mempool before they land. This is the only route of the three that reaches pre-confirmation data, and latency-wise it is the real thing.
The costs are real too:
- You decode everything yourself. What arrives is raw logs and raw calldata. Turning that into “wallet X bought 500 NO shares at $0.95 from wallet Y” means reimplementing Polymarket’s contract layer — exchanges, proxies, the token registry — and keeping it current through migrations like April’s.
- Per-event pricing. Provider websockets bill by compute credits, per event delivered. Polymarket’s full event flow is a firehose; subscribing to all of it turns the credit meter into a second trading loss.
- Relay overhead. Your events route through the provider’s infrastructure — in practice up to ~100ms of added delay, plus best-effort mempool coverage.
The fourth route: a purpose-built stream
Polyflux is what you get when the node-stream route is done once, properly, and sold as a service: every trade, deposit, transfer, and resolution event on the platform, already decoded — wallets, amounts, prices, maker/taker roles — delivered from the mempool over one websocket, on a flat plan.
To keep the comparison honest, here is what it does not do: it does not stream order book depth (the official websocket is the right tool for that), it has no sports feeds, and it is a data feed, not a trading API — you still place orders through the CLOB. It covers exactly the two rows the other routes leave open: the attributed trade tape and money flows, in real time.
The comparison, in one table
| Official websockets | Subgraphs / indexers | Node streams (e.g. Alchemy) | Polyflux | |
|---|---|---|---|---|
| Order book changes | real-time | no | decode yourself | no |
| Your own orders & fills | real-time | late | decode yourself | real-time (in the tape) |
| New-market / sports signals | real-time | late | no / decode | no |
| All trades, with wallets | no | complete, but late | real-time, undecoded | real-time, decoded |
| Money flows (deposits, transfers) | no | partial, late | real-time, undecoded | real-time, decoded |
| Mempool (pre-confirmation) | no | no | yes | yes (~3s head start) |
| Cost model | free | free tier fading → paid pipelines | credits per event | flat plan |
Which one to use
Match the tool to the job. Building dashboards or research? An indexer — the delay does not matter, and SQL over history is a gift. Running your own orders? The official websockets — nothing beats a free, native, real-time channel for your own account. Reacting to other people’s flow — copy-trading, whale alerts, flow-based strategies? Then you need the attributed tape at blockchain level, and the only question is whether you build it or buy it.
Building it means a node (or a node provider), the decoding layer, and the maintenance treadmill — a treadmill that is real: anyone running their own decoders had to ship a contract-era migration in April. Buying it is the fourth column. The 24-hour trial is the quickest way to feel the difference between querying what happened and watching it happen.