Adding Real-Time WebSocket Prices to My Polymarket Rust Bot (And What I Found When I Stopped Polling)

A mentor once told me: "Polling is just missing data with extra steps."

I didn't understand that until I charted my bot's detection timestamps against actual price movements.

My Rust bot was polling clob.polymarket.com/midpoints every 30 seconds. That means on average I was seeing a price change 15 seconds after it happened. At 101ms order-to-fill, I'd already solved execution latency. But I was blind for 15 seconds before that window even opened.

This article covers how I replaced the polling loop with a WebSocket subscription - what changed, what I measured, and the uncomfortable thing I found when I did.

Background: Where We Left Off

If you've been following this series (architecture, Kelly sizing, last-60-second capture, dashboard, Rust rewrite):

The bot targets Polymarket's 5-minute and 15-minute binary crypto markets. The strategy: find markets briefly mispriced relative to spot momentum, enter at a discount to fair value, hold to resolution. Rust brought order placement down to 101ms. The remaining problem is detection lag - how quickly does the bot notice that an opportunity exists?

With a 30-second polling interval, the average detection lag was:

E[detection_lag] = poll_interval / 2 = 15 seconds

On a 5-minute market with a mispricing window of ~2.7 seconds (from the Rust article), a 15-second average detection lag means I was almost certainly missing the window entirely on most signals, then trading into a market that had already partially corrected.

The Rust rewrite made me faster. WebSocket makes me earlier.

How Polymarket's WebSocket Feed Works

Polymarket exposes a WebSocket endpoint at wss://ws-subscriptions-clob.polymarket.com/ws/market. It uses a subscription model: you connect, send a subscription message with asset IDs, and receive price update events in real time.

The message format for a price update looks like:

{
  "asset_id": "71321045679252212594626385532706912750332728571942532289631379312455583992563",
  "market": "0x...",
  "price": "0.74",
  "side": "BUY",
  "size": "50",
  "timestamp": "1718823600123"
}

You receive an event every time there's a trade or a meaningful orderbook change on that asset. For active BTC/ETH markets this is roughly 2-8 events per second during US trading hours, and near-zero overnight.

Critically: the timestamp is server-side, not the time you receive it. That distinction matters when you start measuring actual detection lag.

The Rust Implementation

I already had tokio-tungstenite in Cargo.toml from the previous rewrite. The subscription layer is a standalone async task that feeds price updates into a tokio::sync::watch channel. The scanner reads from the channel instead of making HTTP requests.

# Cargo.toml additions
tokio-tungstenite = { version = "0.24", features = ["native-tls"] }
futures-util = "0.3"

The WebSocket Client

// src/feed/websocket.rs

use futures_util::{SinkExt, StreamExt};
use serde::Deserialize;
use std::collections::HashMap;
use std::sync::Arc;
use tokio::sync::watch;
use tokio_tungstenite::{connect_async, tungstenite::Message};

const WS_URL: &str = "wss://ws-subscriptions-clob.polymarket.com/ws/market";

#[derive(Debug, Deserialize, Clone)]
pub struct PriceEvent {
    pub asset_id: String,
    pub price: String,
    pub side: String,
    pub size: String,
    pub timestamp: String,
}

pub struct PriceFeed {
    // asset_id → latest price
    pub receiver: watch::Receiver<HashMap<String, f64>>,
}

pub async fn start_feed(asset_ids: Vec<String>) -> anyhow::Result<PriceFeed> {
    let (tx, rx) = watch::channel(HashMap::new());
    let ids = asset_ids.clone();

    tokio::spawn(async move {
        loop {
            match run_feed(ids.clone(), tx.clone()).await {
                Ok(_) => tracing::info!("WebSocket feed closed cleanly, reconnecting"),
                Err(e) => tracing::warn!("WebSocket feed error: {e}, reconnecting in 2s"),
            }
            tokio::time::sleep(tokio::time::Duration::from_secs(2)).await;
        }
    });

    Ok(PriceFeed { receiver: rx })
}

async fn run_feed(
    asset_ids: Vec<String>,
    tx: watch::Sender<HashMap<String, f64>>,
) -> anyhow::Result<()> {
    let (mut ws, _) = connect_async(WS_URL).await?;
    tracing::info!("WebSocket connected");

    // Subscribe to all target asset IDs
    let sub_msg = serde_json::json!({
        "auth": {},
        "type": "Market",
        "assets_ids": asset_ids,
        "markets": []
    });
    ws.send(Message::Text(sub_msg.to_string())).await?;

    let mut prices: HashMap<String, f64> = HashMap::new();

    while let Some(msg) = ws.next().await {
        let msg = msg?;
        let text = match msg {
            Message::Text(t) => t,
            Message::Ping(p) => {
                ws.send(Message::Pong(p)).await?;
                continue;
            }
            Message::Close(_) => break,
            _ => continue,
        };

        // Polymarket sends arrays of events
        let events: Vec<PriceEvent> = match serde_json::from_str(&text) {
            Ok(e) => e,
            Err(_) => continue, // heartbeat or non-price message
        };

        for event in events {
            if let Ok(price) = event.price.parse::<f64>() {
                prices.insert(event.asset_id.clone(), price);
            }
        }

        // Notify all scanner tasks of the updated price map
        let _ = tx.send(prices.clone());
    }

    Ok(())
}

Connecting the Scanner

The scanner now reads from the watch channel instead of hitting the HTTP endpoint:

// src/scanner.rs (updated)

use crate::feed::websocket::PriceFeed;
use crate::strategy::signal::generate_signal;
use crate::types::{Market, Signal};

pub struct MarketScanner {
    feed: PriceFeed,
}

impl MarketScanner {
    pub fn new(feed: PriceFeed) -> Self {
        Self { feed }
    }

    pub async fn scan_tick(&self, markets: &[Market]) -> Vec<Signal> {
        // Clone the current price snapshot — zero network I/O
        let prices = self.feed.receiver.borrow().clone();
        let open_positions = 0; // simplified

        markets
            .iter()
            .filter_map(|market| {
                let price = *prices.get(&market.yes_token_id)?;
                let updated = Market {
                    current_price: price,
                    ..market.clone()
                };
                generate_signal(&updated, open_positions)
            })
            .collect()
    }
}

The Main Loop

With polling eliminated, the main loop can run much faster - there's no throttle reason:

// src/main.rs (scan loop)

let mut interval = tokio::time::interval(tokio::time::Duration::from_millis(500));

loop {
    interval.tick().await;

    let signals = scanner.scan_tick(&active_markets).await;

    for signal in signals {
        tracing::info!(
            "Signal: {} {} @ {:.0}¢ — {}",
            signal.direction,
            signal.market.asset,
            signal.entry_price * 100.0,
            signal.reason
        );

        if !paper_mode {
            let _ = trader.place_order(&signal).await;
        } else {
            paper_engine.record(&signal);
        }
    }
}

I'm scanning every 500ms. With 20 markets, that's 40 signal evaluations per second - all from in-memory data, zero network round-trips.

Benchmarking: What Actually Changed

I ran both versions simultaneously for 10 days in paper mode, logging the delta between Polymarket's server-side event timestamp and my bot's signal detection timestamp.

Average detection lag dropped from 14.8 seconds to 310 milliseconds. That's not a 10% improvement. It's a 48× improvement.

The "signals detected" doubling surprised me. With polling, a mispricing that lasted less than 30 seconds was statistically invisible - the poll might hit before or after it. With WebSocket I catch mispricing windows as short as 500ms.

The false positive drop (38% → 11%) is the number I care about most. A "false positive" in my definition is a signal where by the time I place the order, the market has already moved more than 1.5¢ against the signal. With polling I was frequently detecting a price level that had already corrected. With WebSocket the price is fresh within ~300ms.

The Uncomfortable Finding

Here's what I didn't expect.

With the polling bot, my paper P&L looked reasonable. Win rate 73%, positive EV. I attributed most losses to execution slippage - entering 1.1¢ late (the figure from the Rust article).

When I switched to WebSocket and detection lag dropped to 310ms, I expected P&L to improve proportionally.

It did not.

Win rate went from 73% to 71%. Slightly worse, on a larger sample.

I spent a week trying to understand this. Here's what I think is happening:

Fast detection finds signals that weren't real mispricings. With 15-second polling, by the time I saw a "70¢" price, it had survived for at least a few seconds. Short-lived noise - a large order temporarily moving the book - had time to self-correct before I saw it. With 300ms detection, I'm catching transient price impacts from single large orders that aren't actually indicative of sustained mispricing.

The mispricing window model may be wrong. I assumed mispricings were directional and persistent for ~2.7 seconds. The WebSocket data suggests many price events are mean-reverting within 500ms. I was modeling a persistent opportunity; the reality is a noisy, fast-reverting one.

I'm getting better fills on worse signals. Higher fill rate + lower win rate = same (or worse) EV. Speed without signal quality is just faster losses.

This isn't a failure of the WebSocket approach. It's a signal (no pun intended) that my strategy logic needs to adapt to real-time data. A signal threshold calibrated for 15-second-old prices may not be appropriate for 300ms-old prices.

What I'm Changing in Signal Logic

Three adjustments I'm testing:

1. Minimum duration filter. Before acting on a price event, require that the price has held for at least 800ms without reverting. This filters out single-order transient impacts.

// strategy/signal.rs - added duration filter
pub struct PriceHistory {
    pub price: f64,
    pub first_seen: std::time::Instant,
}

pub fn generate_signal(
    market: &Market,
    history: &HashMap<String, PriceHistory>,
    open_positions: usize,
) -> Option<Signal> {
    let h = history.get(&market.yes_token_id)?;

    // Require price to have held for 800ms before acting
    if h.first_seen.elapsed().as_millis() < 800 {
        return None;
    }

    // ... rest of signal logic unchanged
}

2. Volume confirmation. Only enter if the price event was accompanied by a meaningful size field (actual trades, not just quote changes).

3. Recalibrate thresholds. My 70¢–83¢ high-confidence entry band was derived from backtest data where prices were effectively 15-second averages. Real-time prices are noisier. I may need tighter bands to achieve the same signal quality.

I don't have enough data to confirm these changes yet. That's the honest position.

Infrastructure Note: Reconnection Handling

One thing nobody mentions in WebSocket tutorials: connections drop. Polymarket's WS server drops idle connections after roughly 60 seconds. Under network instability I've seen disconnects every 3–5 minutes.

The loop { run_feed(...).await; sleep(2s) } pattern in the code above handles this. On disconnect, the watch channel retains its last value - the scanner keeps working with slightly stale data rather than panicking. When the connection restores (usually within 2 seconds), prices update immediately.

During a reconnect window, I suppress new order placement:

// In the main loop, check feed freshness
if last_updated.elapsed() > Duration::from_secs(5) {
    tracing::warn!("Feed stale — skipping signal evaluation");
    continue;
}

A 5-second stale window is acceptable for a 5-minute market. For a 60-second market it would not be.

What This Changes About the System

The full latency profile now looks like:

Total time from market event to fill: 15 seconds → 506ms.

That's the headline number. But as the P&L data shows, a fast reaction is only valuable if the thing you're reacting to is real.

Should You Add WebSocket to Your Bot?

Yes, if:

• Your polling interval is longer than your target mispricing window
• You're on a 5-minute or 15-minute market where seconds matter
• You've already solved execution latency (otherwise WebSocket detection + slow execution = no net gain)
• You're using Rust, Go, or another language with clean async/await - Python's websockets library introduces its own latency issues under load

Not yet, if:

• You're still validating strategy logic — polling is simpler to debug
• You're on 240-minute or 1440-minute markets where 15-second detection lag is irrelevant
• You haven't profiled your execution path yet (detection without execution is theater)

What's Next

Two things, in the order I'm actually working on them:

1. Duration-filtered signals. I need to validate whether the 800ms hold requirement actually improves win rate. Running A/B paper tests now - should have data in two weeks.

2. Chainlink oracle cross-validation. Before placing any order, compare Polymarket's implied probability against Chainlink's on-chain price feed. If the oracle shows the underlying asset has already crossed the resolution threshold, that's a stale market masquerading as a mispricing. That's the next article.

Conclusion

Replacing the 30-second polling loop with a WebSocket subscription dropped detection lag from 14.8 seconds to 310 milliseconds. Signals detected per day doubled. False positives fell from 38% to 11%.

Win rate dropped 2 points.

The lesson: detection speed and signal quality are orthogonal. Getting faster tells you sooner that a price moved. It doesn't tell you whether that price movement is a genuine mispricing or noise. My signal logic was calibrated for 15-second-old data. Real-time data requires a recalibrated threshold - and I'm still figuring out what that looks like.

Profile before you optimize. Validate your signal before you speed up detection. And when results surprise you, that's usually the data telling you something true.

This is part 7 of my Polymarket Trading Bot series.

All trading described is paper trading unless otherwise stated. This is not financial advice. Prediction market trading carries real risk of loss.