DEV Community: Jonathan Peterson

I tapped into a public WebSocket feed and found a consistent pricing gap on Polymarket hiding in plain sight.

Jonathan Peterson — Sat, 28 Mar 2026 10:20:36 +0000

Check it out: https://github.com/JonathanPetersonn/oracle-lag-sniper

Here’s the setup:

Two live data streams running side by side:

One from the Chainlink oracle that settles Polymarket’s 15-minute crypto markets
One from the Polymarket order book itself

And the difference between them is where things get interesting.

The oracle updates almost instantly.
The order book takes ~55 seconds to catch up.

That means for nearly a full minute, tokens are trading on stale information — even though the “true” settlement price is already publicly available.

Anyone can access that feed. It’s not hidden.
It just consistently runs ahead of the market it decides.

At first, it feels like a bug.

It’s not.

It’s just a rare case where a market inefficiency is clean, measurable, and sitting out in the open.

So I built a bot to act on it — about 1,400 lines of Python.

The strategy itself is almost boring:

On every oracle tick, check three conditions:

price moved > 0.07% from market open  
time remaining > 5 minutes  
token price < $0.62

If all three are true → buy.

Then wait for settlement: either $1 payout or a loss.

Simple logic. The real challenge was making it actually work in real time.

This isn’t a script you run once — it’s a system that has to stay alive.

You need one process that:

Maintains a live WebSocket with sub-second updates
Tracks 16 overlapping markets
Evaluates signals on every tick
Places orders without blocking the feed
Sends Telegram alerts
Persists state for crash recovery
Monitors itself for failures

All at once.

Since it’s almost entirely IO-bound, asyncio was the natural fit.

Seven concurrent tasks, one event loop:

tasks = [
    oracle.run(shutdown),
    market_lifecycle_loop(...),
    signal_evaluation_loop(...),
    telegram.run(shutdown),
    state_persist_loop(...),
    redeem_loop(...),
    sanity_check_loop(...),
]
await asyncio.gather(*tasks)

No threads. No locks. Just coordinated async tasks.

The hardest bug I hit wasn’t logic — it was silence.

Zombie WebSocket connections.

Everything looked healthy:

Connection open
Ping/pong working
No exceptions

But price data had stopped flowing.

The bot just… idled. Quietly. Indefinitely.

Timeouts didn’t catch it because heartbeat frames were still coming in.

The fix was subtle: track the timestamp of the last real price update using a monotonic clock. If that goes stale, kill the connection and force a reconnect.

That one took multiple evenings to track down.

Another painful lesson: silent failures outside the core system.

I once ran the bot for 20 minutes thinking everything was perfect — only to realize all Telegram notifications were failing due to a wrong chat ID.

No errors. No warnings. Just missing visibility.

Now the bot validates everything upfront:

Calls Telegram getMe
Sends a test message
Verifies API keys

If anything is wrong, it fails immediately:

ERROR: Telegram chat_id=123456 is invalid.  
Tip: send a message to your bot, then use getUpdates to find your chat_id.

On the data side:

8,876 resolved markets
146,000 price points
5,017 trades triggered
61.4% win rate across BTC, ETH, XRP, SOL

I tried hard to break it:

Out-of-sample date splits
Parameter sweeps
Doubled fees
Day-by-day analysis

It held up every time.

But let’s keep expectations grounded.

Liquidity is thin.
Execution won’t be perfect.
Other bots are already competing.
And this edge will compress as it gets discovered.

This isn’t a magic money machine.

It’s a small, repeatable inefficiency — and a good example of what happens when public data moves faster than the market built on top of it.

I’ve open-sourced the whole thing:

Bot
Backtests
Data
Live demo mode (no API keys needed)

https://github.com/JonathanPetersonn/oracle-lag-sniper

If you’ve built similar real-time asyncio systems, I’d love to hear how you approached it.

This pattern — many long-lived, stateful tasks sharing a single event loop — feels common, but surprisingly under-documented in the wild.

I connected to a public WebSocket feed and found mispriced tokens on Polymarket

Jonathan Peterson — Wed, 18 Mar 2026 22:35:32 +0000

Open two WebSocket connections. One to the Chainlink oracle that settles Polymarket 15 minute crypto markets. One to the Polymarket order book.

Watch them side by side.

The oracle updates in under a second. The order book takes 55 seconds to reflect the same move. For almost a full minute tokens are sitting there priced on stale data.

The settlement source is public. Anyone can connect. And it consistently runs almost a minute ahead of the market it settles.

That felt like a bug at first. It is not. It is just how markets work. But usually you cannot measure it this cleanly.

So I wrote about 1,400 lines of Python to trade on it.

The core logic is pretty simple. On every oracle price tick, check three things:

price moved > 0.07% from market open
time remaining > 5 minutes
token price < $0.62

All three true? Buy the cheap side. Wait for settlement. Collect $1 or lose your stake.

The interesting part was not the strategy. It was making this actually run reliably.

You need a single process that holds open a WebSocket receiving sub second updates, tracks 16 overlapping markets, evaluates signals on every tick, places orders without blocking the price feed, sends Telegram notifications, persists state for crash recovery, and monitors its own health. All at the same time.

asyncio was the obvious choice. Almost zero CPU work, everything is IO bound. Seven concurrent tasks in one event loop:

tasks = [
    oracle.run(shutdown),
    market_lifecycle_loop(...),
    signal_evaluation_loop(...),
    telegram.run(shutdown),
    state_persist_loop(...),
    redeem_loop(...),
    sanity_check_loop(...),
]
await asyncio.gather(*tasks)

No threads. No locks. No multiprocessing.

The nastiest bug I hit was zombie WebSocket connections. Connection stays alive, ping pong works, no exceptions thrown. But price data silently stops flowing. Your bot just sits there doing absolutely nothing and looks healthy the whole time.

A recv timeout does not help because heartbeat frames still arrive. I ended up tracking the last real price timestamp on monotonic clock and checking it on every timeout. If real data has not arrived in too long, kill the connection and force reconnect.

I lost multiple evenings to this before I figured it out.

Another thing that burned me. Start the bot. Logs look perfect. Run it for 20 minutes. Then discover the Telegram chat id was wrong and every notification silently failed. You had no idea anything was off.

Now the bot verifies every external credential before entering the main loop. Hits Telegram getMe, sends a test message, checks Polymarket API keys. If something is wrong you see it in the first 2 seconds:

ERROR: Telegram chat_id=123456 is invalid.
Tip: send any message to @your_bot first, then use getUpdates to find your chat_id.

The backtest ran across 8,876 resolved markets and 146,000 price points. 5,017 trades flagged. 61.4% win rate across BTC, ETH, XRP and SOL.

I tried 7 different ways to break it. Date split, parameter grid search, doubled fees, daily breakdown. None of them killed it.

But let me be real. The book is thin, fills will be harder than the backtest assumes, and the lag will shrink over time. This is not a retirement plan.

The whole thing is open source. Demo mode connects to live data and paper trades without any API keys.

https://github.com/JonathanPetersonn/oracle-lag-sniper

If you have built similar real time asyncio systems I genuinely want to know how you structured them. This "many concurrent long lived tasks sharing state" pattern feels common but I could not find good open source references when I was building this.

Building a Real-Time Oracle Latency Bot for Polymarket with Python and asyncio

Jonathan Peterson — Sat, 14 Mar 2026 09:45:50 +0000

I recently open sourced a trading bot that exploits a timing gap on Polymarket 15 minute crypto markets. I am not going to rehash the strategy here (there is a full writeup in the repo if you are curious), but I do want to talk about the engineering side because I ran into some fun problems.

What the bot actually needs to do

So here is the list of things happening at the same time:

Hold open a WebSocket to a price oracle that pushes updates every fraction of a second
Keep track of like 16 overlapping 15 minute markets at once
Check trading signals on every single price tick
Place orders, watch for fills, handle settlement
Never drop a price update, even while placing an order
If it crashes, pick up where it left off

And all of this runs in one process.

Why I went with asyncio

My first thought was threads. But then I actually looked at what the bot does and almost all of it is just waiting. Waiting for WebSocket frames, waiting for HTTP responses, waiting on timers. There is basically no CPU work happening.

asyncio fits this perfectly. One event loop, no locks, no thread safety headaches.

The main loop kicks off about 7 tasks that all run at the same time:

tasks = [
    oracle.run(shutdown),           # WebSocket price feed
    market_lifecycle_loop(...),     # market tracking
    signal_evaluation_loop(...),    # trade signals
    telegram.run(shutdown),         # notifications
    state_persist_loop(...),        # crash recovery
    redeem_loop(...),               # auto redeem winners
    sanity_check_loop(...),         # API health checks
]
await asyncio.gather(*tasks)

They are all independent. The oracle task fires up first and then the market and signal loops wait a few seconds before starting so the price buffer has some data in it.

Detecting zombie connections

This one took me a while to figure out. The WebSocket connection stays alive, ping pong works fine, everything looks healthy. But no actual price data is coming through. The upstream just quietly stops sending.

A simple recv() timeout does not catch this because you still get heartbeat frames. The connection is technically alive, just useless.

So I track the last time a real price came in using monotonic clock and check it on every timeout:

while not shutdown_event.is_set():
    try:
        raw = await asyncio.wait_for(ws.recv(), timeout=30)
    except TimeoutError:
        since_last = time.monotonic() - self._last_price_ts
        if since_last > self.STALL_TIMEOUT:
            # connected but no real data, force reconnect
            break
        continue

Sounds obvious in hindsight but I spent an embarrassing amount of time debugging "why did the bot just sit there doing nothing for 20 minutes" before I added this.

Two oracle backends, same interface

The bot can pull prices from two different sources:

ChainlinkOracle connects directly to Chainlink Data Streams. HMAC auth, raw binary price reports. This is the "real" source.

PolymarketOracle uses Polymarket public RTDS relay. No authentication, JSON messages. Free and good enough for demo mode and live trading.

Both write into the same OracleBuffer. The signal evaluation loop has no idea which one is running and does not care. You switch between them with one env var.

One quirk with the RTDS source: it needs you to send a PING string every 5 seconds. Not a WebSocket level ping, an actual text message that says PING. So I spin up a separate task just for that:

ping_task = asyncio.create_task(self._ping_loop(ws, shutdown_event))
try:
    # main recv loop
finally:
    ping_task.cancel()

Verifying credentials before anything starts

This was born out of pure frustration. I would start the bot, everything looks great, logs are clean. Then 10 minutes later I realize my Telegram token was wrong because a notification silently failed and I had no idea.

Now the bot hits the Telegram API with getMe and sends a test message before it even enters the main loop. Same thing for Polymarket API keys. If something is off you know immediately:

ERROR: Telegram chat_id=123456 is invalid. Response: Forbidden: bots can't send messages to bots
Tip: send any message to @your_bot first, then use getUpdates to find your chat_id.

Tiny change but it saved me so much time after that.

The bisect trick for the price buffer

Prices are stored in a per asset circular buffer (just a deque with maxlen). The signal loop constantly needs to look up "what was the oracle price when this market opened?" which means searching by timestamp.

The obvious tool is bisect_right but it does not work on a deque because there is no __getitem__ on the timestamp component. I could copy to a list every time but that felt gross on a hot path.

Instead I wrote a tiny wrapper:

class _DequeTimestampKey:
    __slots__ = ("_buf",)
    def __init__(self, buf):
        self._buf = buf
    def __len__(self):
        return len(self._buf)
    def __getitem__(self, idx):
        return self._buf[idx][0]  # timestamp component

O(log n) lookups, zero allocations. Probably my favorite 10 lines in the whole codebase.

Crash recovery

State gets dumped to a JSON file every 30 seconds. Open positions, risk counters, daily P&L, kill switch status. When the bot restarts it reads that file and picks up where it left off. Any markets that expired while it was down get resolved on the next cycle.

Nothing fancy but it means I can restart the bot mid session without losing track of anything.

How it performed

61.4% win rate over 5,017 backtested trades, consistent across BTC, ETH, XRP, and SOL. The backtest includes 7 falsification tests and a 60/40 in sample / out of sample split by date.

Full source is here: https://github.com/JonathanPetersonn/oracle-lag-sniper

I would genuinely love to hear how other people have structured similar systems. The "bunch of long lived concurrent tasks sharing state" pattern comes up a lot but I have not found many open source projects that do it well to learn from.