DEV Community: Blockchain Rust Engineer

My Bot Showed +$84 Profit. The Chain Said +$11. Here's Why.

Blockchain Rust Engineer — Thu, 02 Jul 2026 08:42:25 +0000

I ran 200 paper trades. Win rate was 91%. P&L tracker showed positive every session. I moved to live. First week looked fine.
Then I pulled the actual on-chain data.
The numbers didn't match. Not close. The bot's internal tracker and what actually happened on Polygon were two different stories.
Here's every reason why, and how I fixed each one.

Mistake 1: Counting unresolved positions as profit
The bot marks a trade as "won" when YES hits 0.98+. But Polymarket doesn't pay you at 0.98. It pays you $1.00 at resolution, and only after the oracle confirms. Until then, the position is worth approximately 0.98 but not actually 0.98.
Early tracker counted the unrealized gain immediately. Looked great. Wasn't real.
Fix: don't count a trade as closed until resolution is confirmed on-chain. Add a pending_resolution state between fill and confirmed payout.

Mistake 2: Fee drag compounding silently
Polymarket's taker fee is ~2% per trade. On a single trade that's obvious. Across a session of 40 trades it's invisible until you add it up.
Session with 40 trades at 0.88 avg entry:

Gross win rate: 91% → looks profitable
Fee per trade: 2%
Total fee drag across session: ~80% of gross profit gone

I was profitable on paper. Roughly breakeven on the chain. The fee column existed in my tracker but it wasn't being subtracted from the running P&L total. It was just sitting there as a label.
Fix: subtract fees from P&L in real time. Not as a separate column. Off the number you're watching.

Mistake 3: Slippage estimated, not measured
The backtest used 1.5% slippage assumption. Reasonable. The problem: live fills on thin books near resolution were running 2.8-3.4% in bad sessions. The backtest never saw that because the backtest assumed I'd always get the mid price plus a fixed percentage.
Real slippage isn't fixed. It depends on book depth at the exact moment you enter. And book depth near resolution is not the same as book depth two minutes before resolution.
Fix: log expected fill (mid at signal time) vs actual fill on every trade. Track the delta. If rolling average delta exceeds 2.5%, the session pauses.

Mistake 4: Redemption haircut
This one I didn't find until week three.
When a market resolves YES, your YES tokens are worth $1.00 each. But redeeming them costs gas on Polygon. Small amounts get eaten by gas disproportionately. A $4.80 position costs ~$0.15 to redeem. That's 3.1% off the top before fees even enter the picture.
The bot was entering positions that were too small for the math to work after redemption costs. Position sizing assumed fees only. Didn't account for gas.
Fix: minimum position size enforced at $8.00. Below that the redemption cost percentage is too high.

Mistake 5: Win rate calculated wrong
This is the embarrassing one.
Early version: win rate = trades where final P&L > 0 / total trades.
Problem: trades that were still in pending_resolution weren't counted yet. So win rate was calculated over a subset of completed trades, and that subset was biased toward faster-resolving markets which happened to be the ones with cleaner fills. The actually hard sessions were still pending.
When I corrected for this and counted all trades including pending ones marked to market, win rate dropped from 91% to 84%. Still good. But not the number I'd been watching.
Fix: win rate denominator includes all trades, pending or closed. Pending positions marked to current mid price.

After fixing all five, the P&L tracker and on-chain numbers now match within 2% across sessions. The 2% variance is gas estimation rounding, which I'll tighten later.
The honest version: the strategy still works. The edge is real. But the first month of "profit" I was looking at was a different number than what actually happened. Getting those two numbers to match was as much work as building the strategy itself.
If you're running a trading bot and haven't reconciled your internal P&L against your actual wallet balance recently, do that now. The gap will tell you something.
Code: github.com/casatrick/polymarket-trading-bot

Polymarket Arbitrage Strategies - Analysis

Blockchain Rust Engineer — Mon, 29 Jun 2026 07:22:16 +0000

Polymarket profiles are public. Position data is public. If you know what to look for, you can reconstruct exactly what strategy an automated trader is running just from their open positions and prediction count.

I pulled three accounts that showed bot-like behavior (thousands of predictions, repetitive markets) and reverse-engineered their strategies. Then I built an open-source version.

What I looked for

Bots on Polymarket tend to leave fingerprints:

Prediction count in the thousands - humans don't make 16,000 trades
Concentrated in one market type - usually the 5-minute BTC Up/Down markets
Consistent position sizes - not random gut-feel bet sizing
Positions on both sides of the same market - the dead giveaway for arb bots

The three accounts

@first - directional momentum bot

19,923 predictions since October 2025. All positions I could see were in "Bitcoin Up or Down - 5 minute" markets, buying a single side (Up or Down, not both). Entry prices: 33¢, 44¢, 69¢, 76¢, 81¢, 89¢.

This isn't arbitrage. It's a bot reading BTC price momentum and betting on the 5-minute direction. The 33¢ entry that returned 202% was almost certainly triggered on a strongly trending candle where the market was underpricing the obvious direction.

Total P&L: +$1,484 on ~20k trades. That's thin per-trade, but it's been running for 8 months. Directional edge is slower to compete away than mechanical arb.

@second - merge/redeem arb, fully exited

16,454 predictions since April 2026. Current positions: zero. Portfolio value: $0. Biggest win: $606.

This is what a successful merge/redeem arb bot looks like after it's done. The strategy:

1. Scan binary markets where P(YES) + P(NO) < $1.00
2. Buy both YES and NO simultaneously
3. Merge tokens into a complete set
4. Redeem the complete set for $1.00
5. Pocket the difference (minus fees)

When YES+NO = $0.95, you make $0.05 per share bought. With large position sizes and fast execution, this adds up. bowbow16 ran 16k trades in ~2 months, extracted its edge, and is now sitting idle - probably because the spread has tightened as more bots entered.

@third - live intra-market arb, caught mid-trade

Joined June 2026 (brand new). 4,170 predictions. Current open positions:

Market: Bitcoin Up or Down - June 29, 2:45AM-2:50AM ET

Down  43.4¢  625.1 shares  →  $309.42  (+$38.11)
Up    59.1¢  595.9 shares  →  $300.95  (-$51.00)

Both sides. Same market. Entry was when Down + Up summed below $1.00 - but prices moved after entry, so combined they're now 102.5¢. The bot is slightly underwater waiting for resolution. This is exactly how the strategy looks mid-execution.

What's interesting: it entered both sides within the same 5-minute window, holding until the market resolves, then collects $1.00 per complete set regardless of which direction BTC moved. The directional outcome doesn't matter. Only the entry price matters.

What this tells you about the current state of Polymarket arb

The arb is real but the windows are narrow. third is already underwater on a position from the spread moving 2-3 cents between signal and fill. At the scale these bots operate, execution latency is the main variable.

Pure mechanical arb has a lifespan. second ran 16k trades then stopped. The edge gets competed away as more bots scan the same markets. Directional strategies (first, still active after 8 months) seem to have more staying power because they require actual market judgment.

The 5-minute BTC markets are the arb hotspot. Every bot I found is concentrated there. They resolve in 5 minutes, have consistent liquidity, and the binary structure makes merge/redeem clean. The tradeoff is that every other bot is also there.

The bot I built

Based on studying these strategies, I built a Polymarket bot in Python that implements 5 strategies:

Strategy 1 - Intra-market merge/redeem (what wolf9478 is doing)
Buy YES+NO when sum < $1.00, merge, redeem. Risk-free on paper, execution-speed-dependent in practice.

Strategy 2 - Combinatorial arb
Markets with 3+ outcomes. All outcome prices should sum to $1.00. When they don't, same approach.

Strategy 3 - Cross-platform arb
Compare Polymarket prediction prices to Binance spot. If BTC has a 70% chance of being above $X and the market is pricing it at 45%, buy the underpriced side and wait for convergence.

Strategy 4 - Endgame arb
Near-resolution markets where one outcome is at 93%+ probability. Buy it, wait a few hours, collect ~7% return on near-certain outcome.

Strategy 5 - Momentum/mean-reversion
What eknih appears to be doing. Track YES/NO prices as a time series, apply z-score and RSI, enter when overextended. Three timeframes: 5m scalp, 15m swing, 1h position.

The bot runs all strategies in parallel, then uses a composite scorer to rank signals:

score = (
    profit_score    * 0.30 +
    confidence      * 0.25 +
    strategy_prio   * 0.20 +
    urgency         * 0.15 +
    risk_reward     * 0.10
)

Top-ranked signal executes first. Risk manager prevents duplicate positions in the same market.

Lessons from watching these bots

If you're building something similar, here's what the data suggests:

Speed beats strategy for merge/redeem. The arb exists briefly. If your order takes 2 seconds to fill, someone with a 200ms latency already closed it.

Don't rely on a single strategy. second's pure arb approach ran out of steam. first's directional approach is still grinding months later.

The 5m BTC market is crowded. Profitable but competitive. If you're starting fresh, look at less-trafficked markets where the arb windows stay open longer.

Track your Sharpe, not just P&L. A high prediction count with modest P&L (like first) might be negative expected value after fees if the win rate isn't high enough.

Repo: github.com/casatrick/polymarket-arbitrage-bot

Not financial advice. Polymarket can be illiquid. You can lose money. These accounts might not even be bots - but 19,000 predictions in 8 months is hard to do by hand.

I Backtested My Polymarket Bot Against Real Order Book Data. Here's What I Found.

Blockchain Rust Engineer — Sat, 27 Jun 2026 14:56:52 +0000

Six months of running a Rust trading bot live, then replaying historical tick data through the same code. The results were not what I expected.

The bot had been running for six months. It felt like it was working. P&L was positive. Win rate looked decent. And then I actually backtested it.

Turns out I had been lucky on a few large positions that masked two strategies that were quietly bleeding. I wouldn't have known without replaying real historical data through the same code that runs in production.

This is how I built the backtester, what data I used, and what I found.

The data problem

First thing I learned: Polymarket has no historical endpoint on their public API. The CLOB API gives you live order book state and WebSocket for real-time updates, but nothing historical. So you can't just hit an endpoint and get six months of order book history.

Three options I found:

pmdata.dev - tick-level L2 order book data from Feb 2026, served as parquet files. One HTTP request per market slug, download the whole history. This is what I ended up using.

telonex.io - similar, tick-by-tick order book depth captured on every change, not interval-sampled. More complete but costs more.

Polygon subgraph - on-chain trade fills only, no order book depth. Fine for trade history, useless if you want to simulate fills against the actual book.

For backtesting a strategy that cares about spread and order book depth, you need L2 data. Trade-only data hides slippage and gives you an unrealistically clean picture.

Download looks like this:

// fetch historical parquet for a market slug
let slug = "btc-updown-5m-1778803200";
let url = format!("https://api.pmdata.dev/download/poly_l2/{}.parquet", slug);

// stream it down, deserialize into your event format
// pmdata returns: timestamp, side, price, size

I wrote a small Rust binary that downloads the parquet, deserializes it into the same FeedEvent enum the live bot uses, and writes it to a local file. One-time setup per market.

The backtester structure

The key decision was to not write a separate backtester. The live bot already has a clean interface:

FeedEvent → strategy engine → Option<Signal>

The feed task is the only thing that changes between live and backtest. In production it reads from a WebSocket. In backtest it reads from a file. Everything downstream - order book, strategy, risk manager - is identical.

pub enum DataSource {
    Live { url: String },
    Backtest { path: PathBuf },
}

pub async fn run(source: DataSource, tx: mpsc::Sender<FeedEvent>) {
    match source {
        DataSource::Live { url } => run_websocket(url, tx).await,
        DataSource::Backtest { path } => replay_file(path, tx).await,
    }
}

replay_file reads events from disk and sends them through the same channel the live feed uses. The strategy task never knows the difference. This is the part I'm happiest with - there's no "backtest mode" flag scattered through the codebase. It's just a different data source.

One thing you have to handle: timing. In production, events arrive in real time. In backtest, you're replaying them as fast as the CPU can process them. You need to either:

Replay at wall-clock speed (slow, but simulates real latency)
Replay as fast as possible with timestamps preserved in events (what I do)

I went with option 2. The strategy uses event timestamps, not wall-clock time, so the math stays correct even at 100x playback speed. Running six months of data takes about 40 seconds.

Simulating fills

This is where most backtests lie to you.

The naive approach: if your signal says buy at $0.38 and the historical data shows a trade at $0.38, assume you filled. This is wrong for two reasons.

First, you weren't the only one trying to buy at $0.38. Queue position matters. In a thin market, by the time your order would have reached the exchange, that level might be gone.

Second, your order moves the book. A $500 position in a market with $2,000 in liquidity is meaningful. The naive approach pretends you're a ghost that trades without impact.

What I do instead: simulate fills against the L2 snapshot at the time of the signal.

fn simulate_fill(
    book: &OrderBook,
    side: Side,
    size: Decimal,
) -> Option<(Decimal, Decimal)> { // (fill_price, actual_size)
    let levels = match side {
        Side::Buy => &book.asks,
        Side::Sell => &book.bids,
    };

    let mut remaining = size;
    let mut cost = Decimal::ZERO;

    for level in levels {
        if remaining.is_zero() { break; }

        let take = remaining.min(level.size);
        cost += take * level.price;
        remaining -= take;
    }

    if remaining > Decimal::ZERO {
        // not enough liquidity to fill fully
        // partial fill or no fill depending on your strategy
        return None;
    }

    let fill_price = cost / size;
    Some((fill_price, size))
}

This walks the order book and simulates the actual fill price including slippage. It's still not perfect - you're still assuming you could have taken all that liquidity - but it's much closer to reality than assuming a perfect fill at the best price.

I also added a 800µs delay to every simulated fill to account for the actual round-trip time my live bot experiences. Sounds pedantic. It actually mattered on a few strategies that depended on very short windows.

What I found

Six strategies I'd been running. Here's the honest breakdown:

Mean reversion on spread widening - positive, 61% win rate over 4,200 trades. This is the core strategy. Backtest matched live performance closely, which gave me more confidence in it.

Pre-resolution snipe (last 60 seconds) - positive but much thinner than I thought. The live P&L looked good because I'd caught a few large moves. Backtest showed the median trade on this strategy barely covers fees. Still running it but at reduced size.

Momentum on correlated markets - flat to slightly negative. I'd convinced myself there was a signal here. There isn't, or at least not a consistent one. Turned this off.

Kelly-sized position scaling - neutral effect. The Kelly sizing doesn't generate alpha, it just changes the variance profile. Expected, but good to confirm.

Spread capture / market making - negative. I knew this was experimental. Confirmed it doesn't work at my size in these markets. Turned off.

News event repricing - not enough data to evaluate. Only 23 trades in six months. Keeping it on but can't draw conclusions yet.

The uncomfortable finding: two of the five strategies I thought were working were either flat or negative. The positive P&L I'd been seeing was almost entirely the mean reversion strategy plus some fortunate sizing on a few outlier trades.

One thing the backtest can't tell you

Whether the edge still exists.

Backtesting against historical data tells you whether a strategy would have worked on past data. It doesn't tell you whether the market has changed, whether more bots have entered the same trades, or whether the conditions that created the edge in January still exist in June.

The mean reversion strategy shows a slight decay in win rate from Feb to June - 64% in Q1, 58% in Q2. Could be noise. Could be the edge compressing as more participants find it. I don't know yet.

This is the thing nobody says loudly enough about backtesting: a good backtest raises questions, it doesn't answer them. Finding out two strategies don't work is useful. The real question is whether the one that does work keeps working.

Setup if you want to replicate this

Grab an API key from pmdata.dev (they have a free tier). Download parquet files for whatever markets you want. Write a deserializer that maps their schema to your FeedEvent type. Swap your data source enum. Run.

Full code including the replay harness and fill simulator:

github.com/casatrick/polymarket-trading-bot

The backtester is in src/backtest/. It's about 300 lines including the fill simulator and the P&L tracker.

If you've built something similar or found a better data source, drop it in the comments. Especially interested in whether anyone has found a way to get clean pre-February 2026 data - the Polygon subgraph has it but the order book reconstruction from on-chain data is painful.

Building a Trading Bot Is Easy. Building One That Survives Overnight Isn't.

Blockchain Rust Engineer — Thu, 25 Jun 2026 08:12:14 +0000

When I first started building trading bots, I thought the difficult part would be the strategy.

I spent weeks researching market behavior, testing ideas, and optimizing entry conditions. Eventually, I had a strategy that looked promising in backtests and paper trading.

Then I deployed it.

Within the first few days, I learned something important:

Building a trading bot is easy. Building one that can run unattended for days without breaking is much harder.

This article isn't about trading strategies. It's about the engineering problems that started appearing the moment my bot entered production.

Problem #1: Network Connections Always Fail

My first version relied heavily on WebSocket streams.

Everything worked perfectly during testing.

Then one day I checked the dashboard and noticed the bot hadn't received any market updates for almost 20 minutes.

The WebSocket connection had silently died.

The process was still running, but it wasn't receiving any data.

The bot looked healthy.

It wasn't.

The solution was adding:

Heartbeat monitoring
Automatic reconnection
Connection timeout detection
Data freshness checks

Now the bot continuously verifies that new market data is arriving.

If updates stop, it reconnects automatically.

Problem #2: Processes Crash When You Least Expect It

Unhandled exceptions happen.

Unexpected API responses happen.

Third-party services go down.

Memory issues happen.

My first production crash occurred at 3 AM.

The bot stopped trading and I didn't notice until the next morning.

That led me to introduce:

PM2 process management
Automatic restarts
Crash logging
Error alerts

A trading bot should never rely on someone manually restarting it.

Problem #3: Logging Becomes More Important Than Trading

At first, I logged almost nothing.

When something went wrong, I had no idea what happened.

Questions became impossible to answer:

Why did this position open?
Why wasn't this order submitted?
Why did the bot skip this opportunity?
Why was this trade closed?

I eventually started logging:

Market snapshots
Signal decisions
Order submissions
Fill confirmations
Risk checks
Latency measurements

The result was a massive improvement in debugging.

The fastest way to fix a problem is knowing exactly where it occurred.

Problem #4: Latency Isn't Constant

I originally measured latency once and assumed it stayed the same.

That assumption was wrong.

Latency changes constantly.

Some requests completed in a few milliseconds.

Others suddenly took hundreds of milliseconds.

That difference matters when trading fast-moving markets.

I began recording:

Market data arrival time
Signal generation time
Order submission time
Exchange response time

Only after measuring every stage separately could I identify real bottlenecks.

Problem #5: Memory Leaks Are Sneaky

One version of my bot looked stable.

CPU usage was fine.

No crashes.

No errors.

Then after several days, memory usage slowly climbed until the process became unstable.

The culprit wasn't a complicated algorithm.

It was old data structures that were never cleaned up.

Temporary caches became permanent caches.

Historical snapshots accumulated forever.

The lesson:

Long-running systems expose problems that short tests never reveal.

Problem #6: Monitoring Matters More Than Features

Most developers enjoy building features.

Very few enjoy building monitoring.

I was no different.

But eventually I realized something:

A simple strategy with excellent monitoring is usually safer than an advanced strategy with no visibility.

Today I monitor:

Process health
Memory usage
CPU usage
WebSocket status
API errors
Open positions
Daily profit and loss

When something breaks, I know within minutes instead of hours.

Problem #7: Production Data Is Different

Backtests are clean.

Production data isn't.

In real markets you'll encounter:

Missing updates
Delayed messages
Unexpected values
API outages
Temporary inconsistencies

Systems must be designed around imperfect data.

Assuming everything will always arrive correctly is a guaranteed way to create bugs.

The Biggest Lesson

The trading strategy eventually became one of the smaller parts of the project.

Most of my engineering time now goes toward:

Reliability
Monitoring
Observability
Error handling
Performance measurement
Recovery mechanisms

The strategy decides when to trade.

The infrastructure decides whether the bot survives long enough to execute those trades.

And in production, survival is often the harder problem.

Final Thoughts

Many developers focus on finding the perfect strategy.

I did the same thing.

What surprised me was how quickly the challenge shifted from market prediction to system reliability.

A bot that makes brilliant decisions but crashes overnight is useless.

A bot that survives network failures, reconnects automatically, logs everything, and keeps running for weeks is far more valuable.

Building a trading bot is easy.

Building one that survives overnight is where the real engineering begins.

For more detail strategy here's Github repository

Building a Low-Latency Trading Bot in Rust (From 48ms to 800µs)

Blockchain Rust Engineer — Tue, 23 Jun 2026 07:28:34 +0000

How I rewrote my Polymarket trading bot in Rust and got a 70x latency improvement. Real benchmarks, full architecture, and every pitfall I hit along the way.

My Python trading bot had a 48ms decision loop. After rewriting it in Rust: 800 microseconds.

That's not a typo. That's a 70x improvement - and in a prediction market like Polymarket, that gap is the difference between filling an order at a good price and arriving after everyone else already moved the book.

This post walks through exactly how I built it: architecture decisions, async I/O, order book design, WebSocket reconnection, and the mistakes I made so you don't have to.

Why Rust? (The Real Answer)

I know, I know. "Why not Go?" I tried Go first. It was fine. But two things kept bothering me:

GC pauses. Go's garbage collector is good, but "good" still means occasional multi-millisecond pauses. In a trading context that's unacceptable.
Interface{} type erasure. Writing a generic order book without proper generics felt like fighting the language.

Rust gives you:

✅ Zero garbage collector - memory is deterministic
✅ async/await with Tokio - genuinely great async runtime
✅ The borrow checker catches data races at compile time
✅ Zero-cost abstractions - generics compile to the same assembly as hand-written C

The learning curve is real. The borrow checker will fight you. But for a latency-sensitive system, it pays off.

Architecture in One Diagram

┌──────────────────────────────────────────────────┐
│                  Trading Bot                      │
│                                                   │
│  ┌─────────────┐    ┌──────────────────────────┐ │
│  │ WebSocket   │───▶│  Market Data Handler     │ │
│  │ Feed        │    │  (order book updates)    │ │
│  └─────────────┘    └────────────┬─────────────┘ │
│                                  │                │
│                                  ▼                │
│  ┌─────────────┐    ┌──────────────────────────┐ │
│  │ REST API    │◀───│  Strategy Engine         │ │
│  │ Client      │    │  (signal generation)     │ │
│  └─────────────┘    └────────────┬─────────────┘ │
│                                  │                │
│                                  ▼                │
│                     ┌──────────────────────────┐ │
│                     │  Risk Manager            │ │
│                     └──────────────────────────┘ │
└──────────────────────────────────────────────────┘

Each component runs as an async Tokio task. They communicate via mpsc channels - not shared mutable state. No locks on the hot path.

Project Setup

# Cargo.toml
[dependencies]
tokio = { version = "1", features = ["full"] }
tokio-tungstenite = { version = "0.21", features = ["native-tls"] }
futures-util = "0.3"
reqwest = { version = "0.12", features = ["json"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
rust_decimal = "1"
tracing = "0.1"
tracing-subscriber = "0.3"
anyhow = "1"

# This matters more than most people think
[profile.release]
opt-level = 3
lto = true
codegen-units = 1
panic = "abort"

That [profile.release] block is doing real work:

lto = true - link-time optimization, LLVM sees your whole codebase
codegen-units = 1 - slower compile, faster binary
panic = "abort" - removes unwinding overhead entirely

The Order Book

Never use f64 for prices. Floating-point rounding errors silently corrupt your PnL over time. Always use rust_decimal.

use rust_decimal::Decimal;

#[derive(Debug, Clone)]
pub struct PriceLevel {
    pub price: Decimal,
    pub size: Decimal,
}

#[derive(Debug, Default)]
pub struct OrderBook {
    pub bids: Vec<PriceLevel>, // sorted descending
    pub asks: Vec<PriceLevel>, // sorted ascending
}

impl OrderBook {
    pub fn best_bid(&self) -> Option<&PriceLevel> {
        self.bids.first()
    }

    pub fn best_ask(&self) -> Option<&PriceLevel> {
        self.asks.first()
    }

    pub fn mid_price(&self) -> Option<Decimal> {
        let bid = self.best_bid()?.price;
        let ask = self.best_ask()?.price;
        Some((bid + ask) / Decimal::from(2))
    }

    pub fn spread(&self) -> Option<Decimal> {
        Some(self.best_ask()?.price - self.best_bid()?.price)
    }

    /// Apply a delta update - never rebuild from scratch
    pub fn apply_update(&mut self, side: Side, price: Decimal, size: Decimal) {
        let levels = match side {
            Side::Bid => &mut self.bids,
            Side::Ask => &mut self.asks,
        };

        if size.is_zero() {
            levels.retain(|l| l.price != price);
        } else {
            if let Some(level) = levels.iter_mut().find(|l| l.price == price) {
                level.size = size;
            } else {
                levels.push(PriceLevel { price, size });
            }
        }

        match side {
            Side::Bid => levels.sort_by(|a, b| b.price.cmp(&a.price)),
            Side::Ask => levels.sort_by(|a, b| a.price.cmp(&b.price)),
        }
    }
}

Key design decision: delta updates, not full snapshots. Rebuilding the entire book on every WebSocket message would add milliseconds per update. Apply diffs instead.

WebSocket Feed Handler

use tokio::sync::mpsc;
use tokio_tungstenite::{connect_async, tungstenite::Message};
use futures_util::{SinkExt, StreamExt};

#[derive(Debug, serde::Deserialize)]
#[serde(tag = "type", rename_all = "snake_case")]
pub enum FeedEvent {
    BookUpdate {
        market_id: String,
        bids: Vec<[String; 2]>,
        asks: Vec<[String; 2]>,
        timestamp: u64,
    },
    Trade {
        market_id: String,
        price: String,
        size: String,
        side: String,
    },
}

pub async fn connect_feed(
    url: &str,
    market_ids: Vec<String>,
    tx: mpsc::Sender<FeedEvent>,
) -> anyhow::Result<()> {
    let (ws_stream, _) = connect_async(url).await?;
    let (mut write, mut read) = ws_stream.split();

    // Subscribe
    let sub = serde_json::json!({
        "type": "subscribe",
        "market_ids": market_ids
    });
    write.send(Message::Text(sub.to_string())).await?;

    while let Some(msg) = read.next().await {
        match msg? {
            Message::Text(text) => {
                if let Ok(event) = serde_json::from_str::<FeedEvent>(&text) {
                    if tx.send(event).await.is_err() {
                        break; // receiver dropped
                    }
                }
            }
            Message::Ping(data) => {
                write.send(Message::Pong(data)).await?; // MUST handle pings
            }
            Message::Close(_) => break,
            _ => {}
        }
    }
    Ok(())
}

The WebSocket task owns nothing except the connection. It parses → forwards. The strategy task lives entirely on the other side of the channel.

Auto-Reconnect Logic

Connections drop. Networks blip. This is non-optional:

pub async fn run_feed_with_reconnect(
    url: String,
    market_ids: Vec<String>,
    tx: mpsc::Sender<FeedEvent>,
) {
    let mut backoff = std::time::Duration::from_millis(500);
    let max_backoff = std::time::Duration::from_secs(30);

    loop {
        match connect_feed(&url, market_ids.clone(), tx.clone()).await {
            Ok(_) => {
                tracing::info!("Feed disconnected cleanly");
                backoff = std::time::Duration::from_millis(500);
            }
            Err(e) => tracing::error!("Feed error: {e}"),
        }

        tokio::time::sleep(backoff).await;
        backoff = (backoff * 2).min(max_backoff); // exponential with ceiling
    }
}

The Strategy Engine (Where Alpha Lives)

The strategy is a pure function of events + internal state. No I/O. No async. No locks. Fast.

use std::collections::VecDeque;
use rust_decimal::Decimal;

pub enum Signal {
    Buy { market_id: String, price: Decimal, size: Decimal },
    Sell { market_id: String, price: Decimal, size: Decimal },
}

pub struct StrategyEngine {
    book: OrderBook,
    mid_history: VecDeque<Decimal>,
    lookback: usize,
}

impl StrategyEngine {
    pub fn new(lookback: usize) -> Self {
        Self {
            book: OrderBook::default(),
            mid_history: VecDeque::with_capacity(lookback),
            lookback,
        }
    }

    pub fn on_book_update(
        &mut self,
        bids: Vec<[String; 2]>,
        asks: Vec<[String; 2]>,
    ) -> Option<Signal> {
        for [p, s] in bids {
            self.book.apply_update(Side::Bid, p.parse().ok()?, s.parse().ok()?);
        }
        for [p, s] in asks {
            self.book.apply_update(Side::Ask, p.parse().ok()?, s.parse().ok()?);
        }

        let mid = self.book.mid_price()?;
        let spread = self.book.spread()?;

        if self.mid_history.len() >= self.lookback {
            self.mid_history.pop_front();
        }
        self.mid_history.push_back(mid);

        if self.mid_history.len() < self.lookback {
            return None;
        }

        let avg = self.mid_history.iter().sum::<Decimal>()
            / Decimal::from(self.lookback);
        let threshold = Decimal::new(2, 2); // 0.02

        // Mean-reversion: buy when price dips below rolling average
        if mid < avg - threshold && spread < Decimal::new(3, 2) {
            Some(Signal::Buy {
                market_id: "example".to_string(),
                price: self.book.best_ask()?.price,
                size: Decimal::new(10, 0),
            })
        } else {
            None
        }
    }
}

Benchmarks

Measured on a $20/month VPS, co-located close to Polymarket's infrastructure:

Component	Median	p95	p99
WebSocket parse + send	12 µs	18 µs	31 µs
Order book update	4 µs	9 µs	22 µs
Strategy evaluation	18 µs	27 µs	44 µs
REST order placement	620 µs	890 µs	1.4 ms
Total loop	~654 µs	~944 µs	~1.5 ms

Python baseline on same machine: 48ms median, 120ms p99.

The REST call dominates, which is expected. If you need sub-millisecond execution end-to-end, you'd need a venue with a WebSocket order API - but for prediction markets, ~800µs is very competitive.

5 Pitfalls That Will Ruin Your Day

1. Using f64 for prices
Floating-point rounding errors compound. You won't notice until your PnL is wrong at 3am. Use rust_decimal.

2. Holding async locks across .await points
If you hold a tokio::sync::Mutex guard while awaiting I/O, you serialize everything. Pass ownership through channels instead.

3. Unbounded channels
mpsc::channel() with no bound buffers forever if the consumer is slow. Use mpsc::channel(N) and handle the backpressure.

4. Forgetting --release
Rust debug builds are 10-20x slower than release. Always benchmark in release mode.

5. Not handling WebSocket pings
The exchange will close your connection for not responding. The handler above pongs automatically - don't skip it.

What's Next

Once the baseline is running:

Multiple markets - spawn one feed task per market, aggregate signals
Backtesting harness - replay recorded WebSocket messages through the strategy
Risk manager - position limits, max drawdown, per-market exposure caps
Lock-free data structures - crossbeam crate when even Mutex is too much
Co-location - physical proximity to the exchange often matters more than code

Final Thought

Rust's reputation for difficulty is earned. But so is its reputation for performance. For latency-sensitive systems, the borrow checker is a feature - it makes an entire class of concurrency bugs impossible before the code even compiles.

If you're coming from Python or JS: the hardest part is thinking about ownership before logic. Once that clicks, the rest falls into place surprisingly fast.

Found this useful? Drop a ❤️ or share it. And if you're building something similar - prediction market bots, HFT tools, or anything Rust + finance - I'd love to hear about it in the comments.

Follow me for more posts on Rust, system design, and algorithmic trading.

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

Blockchain Rust Engineer — Mon, 22 Jun 2026 07:03:16 +0000

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.

Metric	Polling (30s)	WebSocket (500ms scan)
Average detection lag	14.8s	0.31s
P95 detection lag	29.1s	0.78s
Signals detected per day	147	312
False positives (stale signals)	38%	11%
CPU usage (idle between ticks)	0.1%	0.4%
Memory (price cache)	~800KB	~1.1MB

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:

Stage	Before (polling)	After (WebSocket)
Price change occurs	T+0	T+0
Bot detects price change	T+14,800ms	T+310ms
Signal evaluated	T+14,804ms	T+314ms
Order placed	T+14,905ms	T+415ms
Fill confirmed	T+14,996ms	T+506ms

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.

My Polymarket Trading Bot in Rust After TypeScript Kept Missing Fills

Blockchain Rust Engineer — Thu, 18 Jun 2026 06:34:11 +0000

A trader I was talking to recently said something that stuck with me:

"I've blown accounts just from slow fills or missed order cancellations."

He was talking about CEX perpetuals. But the problem is identical on Polymarket's CLOB - just measured in seconds instead of milliseconds.

My TypeScript bot was averaging 340ms from signal detection to order placement on Polymarket's Central Limit Order Book. On a 5-minute market with a ~2.7-second mispricing window, that's 12% of the entire opportunity window consumed before a single byte hits Polymarket's servers.

I was consistently entering at 74¢ when I'd detected the signal at 70¢. The market had already repriced against me.

So I rewrote it in Rust. This article documents exactly what I found, what changed, and - critically - what didn't.

Background: What My Bot Was Doing

If you've read my earlier posts in this series (architecture, Kelly Criterion sizing, last-60-seconds capture), you know the context. But the short version:

The bot targets Polymarket's 5-minute and 15-minute crypto up/down binary markets (BTC, ETH, XRP, SOL, DOGE, BNB). The strategy is simple: find markets that are briefly mispriced relative to real-time spot momentum, enter at a discount to fair value, hold to resolution.

A 5-minute "XRP Up" market priced at 70¢ when spot momentum suggests 82% probability = +12¢ edge per dollar wagered. Do that 50 times a day with disciplined sizing and the math works - if you can actually get filled at the price you detected.

The problem: by the time my TypeScript code detected the signal, formatted the order, opened an HTTP connection to Polymarket's CLOB API, waited for TLS handshake, serialized the payload, and received confirmation, the market had often moved to 74-76¢.

I was paying for an edge I wasn't capturing.

Profiling the TypeScript Bot: Where Was the 340ms Going?

Before rewriting anything, I instrumented every stage of the order path. Here's what I found across 500 sampled trades:

Stage	Average time	% of total
Signal detection (price poll → threshold check)	18ms	5.3%
JSON parsing of market data	12ms	3.5%
Order object construction	3ms	0.9%
DNS resolution	47ms	13.8%
TLS handshake	89ms	26.2%
HTTP request serialization	8ms	2.4%
Network transit (Polygon RPC + CLOB)	94ms	27.6%
CLOB response parsing	11ms	3.2%
Order confirmation logging	58ms	17.1%
Total	340ms	100%

A few things jumped out immediately:

DNS resolution (47ms) was almost entirely avoidable. I was resolving clob.polymarket.com on every single request. Node.js doesn't cache DNS by default in the way you'd want for a latency-sensitive application. Using persistent connections with connection pooling would eliminate this almost entirely.

TLS handshake (89ms) - same problem. I was opening a new HTTPS connection per order rather than reusing a keep-alive connection. This is basic HTTP/1.1 hygiene that I had simply not thought about because at "normal" application scales it doesn't matter.

Order confirmation logging (58ms) was a synchronous fs.writeFileSync call to a JSON log file. I'd added this during debugging and never removed it. Blocking the event loop on disk I/O in the critical path is embarrassing in hindsight.

Network transit (94ms) is the one thing I can't fully eliminate without co-locating infrastructure closer to Polygon's RPC nodes. I'm in Europe; Polymarket's infrastructure is primarily US-east. This is an irreducible floor.

So: 47 + 89 + 58 = 194ms of avoidable latency from configuration choices. That's the gap from 340ms to the theoretical ~146ms floor with the same network path.

But there was also a deeper issue: Node.js's single-threaded event loop was creating head-of-line blocking. When I was scanning multiple markets simultaneously, a slow response on one market scan was delaying order placement on another. The event loop doesn't eliminate latency - it interleaves it.

Why Rust, Specifically

I want to be clear about what Rust gives me and what it doesn't.

What Rust gives me:

True parallelism via tokio's async runtime with a multi-threaded executor. Market scanning and order placement run in separate threads. A slow scan doesn't block a hot order path.
Zero-cost abstractions - the Rust compiler eliminates overhead that JavaScript runtimes cannot. JSON deserialization with serde is 3-5× faster than JSON.parse for complex nested objects.
Explicit connection pool management via reqwest with keep-alive. I control exactly how connections are reused.
No garbage collector pauses. In TypeScript, V8's GC can introduce unpredictable latency spikes of 5-50ms. At 340ms average this is noise. At 50ms average it's catastrophic.
Compile-time correctness. The CLOB API response shapes are typed at compile time. A malformed API response is a compile error or a handled Result, not a runtime crash.

What Rust doesn't give me:

Better network physics. Light doesn't travel faster because I chose Rust.
Alpha I don't have. If my signal logic is wrong, Rust executes it faster.
A simpler development loop. The first version of the Rust bot took 3× longer to write than the TypeScript equivalent.

Rust is the right tool here specifically because the bottlenecks I identified are CPU and I/O management problems, not network problems. If the bottleneck were purely network latency, Rust would give me marginal gains. Since it's connection management and event loop contention, Rust gives me substantial gains.

The Rust Architecture

adelan-bot-rs/
├── Cargo.toml
├── src/
│   ├── main.rs              ← tokio runtime entrypoint
│   ├── scanner.rs           ← market scanning (parallel tasks)
│   ├── strategy/
│   │   ├── mod.rs
│   │   ├── signal.rs        ← entry detection logic
│   │   └── sizing.rs        ← Kelly / fixed sizing
│   ├── market/
│   │   ├── polymarket.rs    ← CLOB + Gamma API client
│   │   └── clob.rs          ← order placement, connection pool
│   ├── trading/
│   │   ├── paper.rs         ← paper trading engine
│   │   └── portfolio.rs     ← position + P&L tracking
│   └── types.rs             ← shared types

Dependencies (`Cargo.toml`)

[dependencies]
tokio = { version = "1", features = ["full"] }
reqwest = { version = "0.12", features = ["json", "rustls-tls"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
chrono = { version = "0.4", features = ["serde"] }
uuid = { version = "1", features = ["v4"] }
tracing = "0.1"
tracing-subscriber = "0.3"
anyhow = "1"
tokio-tungstenite = "0.24"   # WebSocket for real-time price feed
rust_decimal = "1"           # precise decimal arithmetic for prices

No unsafe. No custom allocator. The standard tokio + reqwest stack is sufficient for this use case.

The Connection Pool: The Most Important Change

This single change - persistent HTTP connections with a shared reqwest::Client - was responsible for roughly 60% of the latency improvement.

// polymarket.rs

use reqwest::Client;
use std::time::Duration;

pub struct PolymarketClient {
    client: Client,
    clob_base: String,
    gamma_base: String,
}

impl PolymarketClient {
    pub fn new() -> anyhow::Result<Self> {
        let client = Client::builder()
            // Keep connections alive — eliminates per-request TLS handshake
            .tcp_keepalive(Duration::from_secs(30))
            .connection_verbose(false)
            // Connection pool: up to 20 idle connections per host
            .pool_max_idle_per_host(20)
            // Use rustls instead of OpenSSL for consistent performance
            .use_rustls_tls()
            // DNS caching built into reqwest — eliminates per-request resolution
            .timeout(Duration::from_millis(5_000))
            .build()?;

        Ok(Self {
            client,
            clob_base: "https://clob.polymarket.com".into(),
            gamma_base: "https://gamma-api.polymarket.com".into(),
        })
    }

    pub async fn get_midpoint(&self, token_id: &str) -> anyhow::Result<f64> {
        let url = format!("{}/midpoints?token_ids={}", self.clob_base, token_id);

        let response = self.client
            .get(&url)
            .send()
            .await?
            .json::<serde_json::Value>()
            .await?;

        let mid = response
            .get(token_id)
            .and_then(|v| v.as_str())
            .and_then(|s| s.parse::<f64>().ok())
            .unwrap_or(0.5);

        Ok(mid)
    }

    pub async fn place_order(&self, order: &Order) -> anyhow::Result<OrderResponse> {
        // Reuses existing connection from pool — no TLS handshake
        let response = self.client
            .post(format!("{}/order", self.clob_base))
            .json(order)
            .send()
            .await?
            .json::<OrderResponse>()
            .await?;

        Ok(response)
    }
}

In TypeScript, I was calling axios.get() or fetch() with default settings, which creates a new connection per request. In Rust, the Client is shared across the entire application lifetime and manages the connection pool automatically. The TLS handshake happens once per host, not once per request.

Parallel Market Scanning with tokio

The second major structural change: market scanning runs as independent async tasks, not sequentially.

// scanner.rs

use tokio::task::JoinSet;
use crate::market::PolymarketClient;
use crate::strategy::signal::generate_signal;
use crate::types::{Market, Signal};
use std::sync::Arc;

pub struct MarketScanner {
    client: Arc<PolymarketClient>,
}

impl MarketScanner {
    pub async fn scan_all(&self, markets: &[Market]) -> Vec<Signal> {
        let mut tasks = JoinSet::new();

        for market in markets {
            let client = Arc::clone(&self.client);
            let market = market.clone();

            // Each market scanned in its own async task
            // No market blocks another — true parallelism via tokio
            tasks.spawn(async move {
                let price = client.get_midpoint(&market.yes_token_id).await.ok()?;
                let updated = Market { current_price: price, ..market };
                generate_signal(&updated, 0)  // simplified: pass open position count
            });
        }

        let mut signals = Vec::new();
        while let Some(result) = tasks.join_next().await {
            if let Ok(Some(signal)) = result {
                signals.push(signal);
            }
        }

        signals
    }
}

In the TypeScript version, scanning 20 markets meant 20 sequential await axios.get() calls, each waiting for the previous to complete. In Rust with JoinSet, all 20 requests fire simultaneously and results are collected as they arrive. For 20 markets averaging 94ms network round-trip, sequential scanning took ~1,880ms. Parallel scanning takes ~100ms (the time of the single slowest request).

This matters enormously for the bot's reaction time. If I scan every 30 seconds and scanning itself takes 1.8 seconds, I'm only actually running signal logic 5.9% of the available time on sequential scans. With parallel scanning I'm running signal logic 99.7% of the time.

Async Logging: Eliminating the 58ms Disk Block

The fs.writeFileSync mistake in TypeScript becomes impossible in idiomatic async Rust. Using tracing with a non-blocking subscriber:

// main.rs

use tracing_subscriber::{fmt, EnvFilter};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    // Non-blocking async logging — never touches the hot path
    tracing_subscriber::fmt()
        .with_env_filter(EnvFilter::from_default_env())
        .with_target(false)
        .init();

    tracing::info!("AdelanBot starting - paper mode: {}", 
        std::env::var("PAPER_MODE").unwrap_or("true".into()));

    // ... rest of startup
    Ok(())
}

All log writes are buffered and flushed asynchronously. The order placement path never waits for a disk write.

The Signal Logic: Unchanged

I want to be explicit about this: the signal detection logic is identical between the TypeScript and Rust implementations.

// strategy/signal.rs

use crate::types::{Asset, Direction, Market, Signal, Timeframe, PREFERRED_ASSETS};

pub fn generate_signal(market: &Market, open_positions: usize) -> Option<Signal> {
    // Same thresholds as TypeScript version — derived from @adelan's real positions
    const HIGH_CONF_MIN: f64 = 0.70;
    const HIGH_CONF_MAX: f64 = 0.83;
    const CONTRARIAN_MIN: f64 = 0.49;
    const CONTRARIAN_MAX: f64 = 0.53;
    const MAX_POSITIONS: usize = 10;
    const MIN_LIQUIDITY: f64 = 500.0;

    if open_positions >= MAX_POSITIONS { return None; }
    if market.liquidity < MIN_LIQUIDITY { return None; }
    if !PREFERRED_ASSETS.contains(&market.asset) { return None; }

    // Time to expiry check
    let ms_to_expiry = market.ends_at
        .signed_duration_since(chrono::Utc::now())
        .num_milliseconds();
    if ms_to_expiry < 60_000 { return None; }

    let price = market.current_price;

    // High confidence entry zone (adelan's primary play)
    if price >= HIGH_CONF_MIN && price <= HIGH_CONF_MAX {
        let shares = calculate_shares(open_positions);
        let ev = (price * (1.0 - price)) - ((1.0 - price) * price);  // simplified EV

        return Some(Signal {
            market: market.clone(),
            direction: market.direction,
            entry_price: price,
            confidence: "high".into(),
            shares,
            expected_return_pct: ((1.0 - price) / price) * 100.0,
            ev,
            reason: format!(
                "High-conf {} @ {:.0}¢ — {} {}",
                market.direction, price * 100.0, market.asset, market.timeframe
            ),
        });
    }

    // Contrarian play (near 50¢, momentum signal)
    if price >= CONTRARIAN_MIN && price <= CONTRARIAN_MAX {
        let momentum_strength = (price - 0.50_f64).abs();
        if momentum_strength < 0.01 { return None; }

        let shares = calculate_shares(open_positions) * 0.5;
        return Some(Signal {
            market: market.clone(),
            direction: if price > 0.5 { Direction::Up } else { Direction::Down },
            entry_price: price,
            confidence: "contrarian".into(),
            shares,
            expected_return_pct: ((1.0 - price) / price) * 100.0,
            ev: momentum_strength * 0.5,
            reason: format!(
                "Contrarian momentum @ {:.0}¢ - {}",
                price * 100.0, market.asset
            ),
        });
    }

    None
}

fn calculate_shares(open_positions: usize) -> f64 {
    let size = 1.0_f64 - (open_positions as f64 * 0.1);
    size.max(0.2)
}

The Rust type system enforces correctness I was relying on runtime checks for in TypeScript. Direction is an enum, not a string. Asset is an enum, not 'XRP' | 'ETH' | .... The compiler rejects malformed signal objects before they can cause a bad order.

Benchmark Results: Before and After

After the rewrite, I ran the same 500-trade instrumented test across both versions:

Stage	TypeScript	Rust	Improvement
Signal detection	18ms	4ms	4.5×
JSON parsing	12ms	2ms	6×
DNS resolution	47ms	0ms	∞ (cached)
TLS handshake	89ms	0ms	∞ (pooled)
HTTP serialization	8ms	1ms	8×
Network transit	94ms	91ms	1.03×
Response parsing	11ms	2ms	5.5×
Logging	58ms	1ms	58×
Total	340ms	101ms	3.4×

The 91ms vs 94ms network improvement is noise - same physical path, same Polygon RPC endpoint. Everything else improved significantly.

P50 latency: 101ms. P95 latency: 148ms. P99 latency: 187ms.

In TypeScript my P99 was 680ms - a full 680ms from signal to fill on a bad run.

What Actually Changed in Trading Performance

This is the section most bot tutorials skip. Here's what the latency improvement translated to in practice, across 2 weeks of paper trading on both versions simultaneously:

Average entry price:

TypeScript: 75.4¢ (detected 70.1¢, slipped 5.3¢ on average)
Rust: 71.2¢ (detected 70.1¢, slipped 1.1¢ on average)

Fill rate on target markets (% of signals where I got a fill within 0.5¢ of detection price):

TypeScript: 61%
Rust: 89%

Win rate on filled trades (did the market resolve in my predicted direction):

TypeScript: 71%
Rust: 73%

That last number is the important one. Rust improved my win rate by 2 percentage points. That sounds small. At the entry prices I trade (averaging ~75¢), a 2-point win rate improvement is the difference between marginal profitability and clear profitability over a large sample.

But I want to be honest: the win rate improvement is partially due to better fills (entering closer to the detected price means I'm entering when the market is actually at the inefficiency, not after it's partially corrected) and partially noise. Two weeks of paper trading is not a statistically significant sample for a 2-point difference.

What Didn't Change: The Uncomfortable Truth

Rust did not give me better alpha. On days when my signal logic was wrong - when I was entering directional plays in a choppy, mean-reverting market - Rust executed those bad trades faster. Speed amplifies both good and bad strategy.

Rust did not solve the scaling ceiling. I still can't place orders larger than $1–2 per position on thin 5-minute markets without moving the price against myself. That's a liquidity problem, not a latency problem.

Rust did not eliminate the paper-trading divergence problem. (That's a separate article.) The Gamma API returns bid prices; the CLOB fills you at ask prices. My paper trading P&L still looks better than live P&L because of this systematic difference. Rust didn't change that.

The development cost was real. The Rust bot took me roughly 3× longer to write than the TypeScript equivalent. The borrow checker rejected my first three approaches to the shared PolymarketClient. Async Rust is significantly more complex than async TypeScript. If your bottleneck is iteration speed on strategy logic, TypeScript is a better choice. Rust pays off when you've validated your strategy and need to optimize execution.

Should You Do This?

Here's my honest decision framework:

Rewrite in Rust if:

You've validated your strategy logic produces positive EV over 1,000+ paper trades
Your profiling shows latency bottlenecks in connection management or CPU-bound operations
You're comfortable with a 2-4 week higher-complexity development phase
You're already a systems engineer - the learning curve is steep if you're coming from scripting languages

Don't rewrite in Rust if:

You're still iterating on strategy logic (TypeScript iteration speed wins)
Your bottleneck is network latency to Polygon RPC nodes (co-location solves this, not Rust)
You have < 500 validated paper trades (you're optimizing before you have signal)
Your total position sizes are under $5/trade (at that scale, 200ms of slippage costs < $0.01)

What's Next

Two things I'm working on that Rust makes tractable:

1. WebSocket price feed instead of polling. Right now I poll clob.polymarket.com/midpoints every 30 seconds. With tokio-tungstenite, I can subscribe to Polymarket's WebSocket feed and receive price updates in real time, reducing the detection lag from ~15 seconds (average time between poll and price change) to ~50ms.

2. Chainlink oracle cross-validation. Before placing an order, I want to compare Polymarket's implied probability against Chainlink's BTC/ETH/SOL price feeds on-chain. If Polymarket says "BTC Up is 82% likely" but Chainlink's oracle shows the last-reported price is already past the threshold, that's a stale market - not a mispricing. I want to skip those. This is the blockchain engineer angle that I think most Python/TypeScript bot builders overlook.

Conclusion

The TypeScript → Rust rewrite reduced my order placement latency from 340ms to 101ms - a 3.4× improvement. This translated to meaningfully better entry prices (1.1¢ slippage vs 5.3¢) and a modestly better fill rate (89% vs 61% within 0.5¢ of target).

But the bigger lesson is in the profiling. 194ms of the original 340ms was pure configuration debt - no DNS caching, no connection pooling, synchronous logging on the hot path. Those fixes are available in TypeScript too. If you're running a Polymarket bot in Node.js and haven't profiled your order path yet, do that before considering a rewrite. You might recover 60% of the latency without changing languages.

Rust was the right next step for me as a blockchain engineer building toward a production system. But fast wrong code is still wrong code. Profile first. Validate your strategy first. Then optimize.

This is part 6 of my Polymarket Trading Bot series. Previous posts: Architecture & Execution · Kelly Criterion Sizing · Last-60-Second Capture · Dashboard War Stories · Last-Entry Probability Capture in TypeScript

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

Building a Polymarket Trading Bot: Architecture, Execution, and Risk Management

Blockchain Rust Engineer — Tue, 16 Jun 2026 16:18:38 +0000

How I built a real-time automated trading system that monitors BTC, ETH, SOL, and XRP prediction markets and executes trades based on short-lived pricing inefficiencies.

Most people think of Polymarket as a prediction market for elections, sports, and current events.

As a developer, I saw something else.

I saw a real-time marketplace with public APIs, continuously updating order books, frequent settlement events, and thousands of micro-opportunities generated every day.

That observation led me to build an automated trading bot focused exclusively on Polymarket's crypto markets.

The system monitors Bitcoin (BTC), Ethereum (ETH), Solana (SOL), and XRP "Up or Down" markets, analyzes price movements in real time, and automatically executes trades when specific conditions are met.

This article isn't about trading advice.

Instead, it's a technical breakdown of the architecture, execution engine, risk controls, and lessons learned from running a real-time automated system against a live prediction market.

Understanding the Market

Polymarket's crypto category includes short-duration contracts that resolve every 5 or 15 minutes.

A typical market asks a simple question:

Will Bitcoin be higher or lower than its current price when the timer expires?

When the market resolves, winning shares pay $1 and losing shares pay $0.

Because these markets settle so frequently, they create a constant stream of opportunities for automated systems.

Unlike longer-term prediction markets, these contracts behave more like microstructure-driven trading environments than forecasting challenges.

The closer a market gets to expiration, the more important execution speed becomes.

Project Goals

Before writing any code, I defined several requirements:

Support multiple assets simultaneously
Monitor live market prices continuously
Detect pricing discrepancies automatically
Execute trades with minimal latency
Manage risk across all active positions
Recover gracefully from API failures
Operate without manual intervention

The final system runs across four crypto assets simultaneously:

Running multiple assets in parallel dramatically increases the number of opportunities available each hour.

High-Level Architecture

The system consists of five major components:

                  ┌─────────────────┐
                  │ Market Data Feed│
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │ Signal Engine   │
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │ Risk Manager    │
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │ Order Engine    │
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │ Polymarket API  │
                  └─────────────────┘

Each component is isolated so it can fail independently without taking down the entire system.

Real-Time Data Collection

The first challenge was obtaining reliable market data.

The bot continuously tracks:

Underlying crypto prices
Polymarket order books
Bid/ask spreads
Market expiration times
Position inventory

A surprising lesson was that data quality matters more than signal complexity.

A simple strategy running on accurate data consistently outperformed more sophisticated approaches built on delayed or inconsistent information.

For short-duration markets, stale data can completely invalidate a trade.

A position entered two seconds too late may have an entirely different risk profile than originally intended.

The Signal Engine

One common misconception is that the bot predicts future prices.

It doesn't.

The strategy focuses on identifying situations where market pricing appears misaligned with current reality.

The system continuously compares:

Live asset price movement
Remaining market lifetime
Current market probability
Available liquidity

When specific thresholds are met, a signal is generated.

Conceptually:

if market_probability < expected_probability:
    generate_buy_signal()

The actual implementation is more complex, but the principle remains the same.

The goal is not forecasting.

The goal is identifying moments when the market appears slow to update relative to incoming information.

Multi-Asset Execution

One of the biggest improvements came from expanding beyond Bitcoin.

Initially, the bot only traded BTC markets.

Later versions added:

Ethereum
Solana
XRP

All assets run through the same execution pipeline.

This creates several advantages:

More opportunities per hour
Better capital utilization
Reduced dependence on a single market
Higher overall trade frequency

Instead of waiting for one market setup, the system can evaluate dozens of opportunities simultaneously.

Risk Management

The signal is not the most important part of the system.

Risk management is.

Most automated trading failures are caused by position sizing errors rather than signal quality.

The bot includes several layers of protection:

Position Limits

Every market has a maximum allocation.

No single trade can exceed predefined limits.

Exposure Limits

Global exposure is monitored continuously.

The system refuses new positions if portfolio risk exceeds configured thresholds.

Cooldown Mechanisms

Following abnormal behavior or unexpected losses, the bot can temporarily suspend trading.

This prevents cascading failures.

Emergency Shutdown

Critical errors trigger an automatic halt.

Examples include:

API failures
Data feed interruptions
Unexpected market conditions
Order execution anomalies

The objective is simple:

Protect capital first.

Everything else comes second.

Maker Rebates

One unexpected source of performance came from maker rebates.

Many traders focus exclusively on directional profits.

However, exchanges often reward liquidity providers.

Whenever possible, the bot posts limit orders instead of immediately crossing the spread.

This creates an additional return stream independent of market direction.

Over hundreds or thousands of trades, these small incentives become surprisingly meaningful.

Challenges in Production

Building the strategy was easier than operating it reliably.

Several issues appeared only after deployment.

API Reliability

External services fail.

Connections drop.

Responses arrive late.

Timeout handling became a core part of the system.

Clock Synchronization

When markets resolve every few minutes, timing accuracy matters.

Even small clock drift can create execution errors.

Partial Fills

Not every order executes completely.

The system must continuously reconcile expected versus actual positions.

Monitoring

A trading bot without monitoring is effectively blind.

Dashboards, alerts, and logging became essential operational tools.

In production environments, visibility often matters more than optimization.

Lessons Learned

After running the system for an extended period, several lessons stand out.

1. Data Quality Beats Complexity

Better data consistently outperformed more sophisticated models.

2. Real-Time Systems Are Hard

Most engineering challenges came from distributed systems problems rather than trading logic.

3. Latency Matters

The value of a signal decreases rapidly with time.

Execution speed directly impacts performance.

4. Monitoring Is Essential

Every production system eventually encounters unexpected behavior.

Observability determines how quickly you recover.

5. Market Edges Decay

Any inefficiency that can be automated will eventually attract competition.

Strategies must evolve continuously.

Future Improvements

Several areas remain interesting for future development:

Cross-market arbitrage detection
Advanced liquidity management
Adaptive position sizing
Machine-learning-based signal ranking
Portfolio-level optimization
Improved execution algorithms

Whether these improvements generate meaningful performance gains remains an open question.

Final Thoughts

Building this bot taught me far more about real-time systems than it did about trading.

The most valuable lessons came from engineering challenges:

Managing unreliable external APIs
Processing live market data
Handling distributed state
Designing fault-tolerant execution systems
Building reliable monitoring pipelines

From the outside, an automated trading bot may look like a collection of buy and sell decisions.

Under the hood, it's a real-time distributed system operating in an adversarial environment where every millisecond and every bug matters.

For developers interested in algorithmic trading, prediction markets provide a fascinating playground for experimenting with automation, market microstructure, and systems engineering.

And regardless of whether the trading edge lasts, the engineering lessons certainly will.

Disclaimer: This article describes a personal software project and should not be interpreted as financial advice. Trading and prediction markets involve significant risk, and past performance does not guarantee future results.

How Kelly Criterion Transformed My Polymarket Trading Bot

Blockchain Rust Engineer — Thu, 11 Jun 2026 09:02:57 +0000

I've been building a Polymarket trading bot for a while now. The strategy was solid - good signal, decent win rate - but the returns felt inconsistent. Some weeks were great, others wiped out gains I'd spent days building. The bot was right more often than not, but the sizing was all over the place.

Then I implemented the Kelly Criterion. It didn't change a single prediction. It just changed how much I bet on each one. The difference was night and day.

Please take a look at my Polymarket account

What Is the Kelly Criterion?

The Kelly Criterion is a formula for calculating the optimal fraction of your bankroll to wager on a bet, given your edge. It was invented by John Kelly at Bell Labs in 1956 and has been used by everyone from blackjack card counters to quantitative hedge funds.

The formula:

f* = (bp - q) / b

Where:

f* = fraction of bankroll to bet
b = net odds (how much you win per $1 wagered)
p = your estimated probability of winning
q = probability of losing (1 - p)

In prediction market terms, if Polymarket shows a contract at 40¢ (implying 40% probability), but your model says the true probability is 55%, then:

b = (1 - 0.40) / 0.40 = 1.5   (you risk 40¢ to win 60¢)
p = 0.55
q = 0.45

f* = (1.5 × 0.55 - 0.45) / 1.5
f* = (0.825 - 0.45) / 1.5
f* = 0.375 / 1.5
f* = 0.25

Kelly says: bet 25% of your bankroll on this trade.

In JavaScript:

function kelly(marketProb, myProb) {
  const b = (1 - marketProb) / marketProb; // net odds
  const p = myProb;
  const q = 1 - p;
  const f = (b * p - q) / b;
  return Math.max(0, f); // never bet negative (no edge = no bet)
}

// Example: market at 40%, your model says 55%
const fraction = kelly(0.40, 0.55);
console.log(`Bet ${(fraction * 100).toFixed(1)}% of bankroll`); // 25.0%

Full Kelly vs Fractional Kelly

Here's the thing about Full Kelly: it's mathematically optimal but practically brutal.

Full Kelly maximises the long-run growth rate of your bankroll. But it assumes your probability estimates are perfectly accurate. In reality, your model is wrong sometimes. Maybe your edge is smaller than you think. Maybe the market knows something you don't.

Full Kelly also produces wild variance. Your bankroll can drop 30–40% even when you're playing correctly - and for a bot running 24/7, that kind of drawdown is psychologically (and sometimes financially) devastating.

Half Kelly

Most practitioners use Half Kelly - simply halving the output:

function halfKelly(marketProb, myProb) {
  return kelly(marketProb, myProb) * 0.5;
}

Half Kelly gives you roughly 75% of the growth rate of Full Kelly, but with dramatically less variance. The drawdowns are about half as deep.

Fractional Kelly in my bot

I actually use a variable fraction based on my model confidence:

function fractionalKelly(marketProb, myProb, confidence) {
  // confidence: 0.0 (low) to 1.0 (high)
  // Scales between quarter Kelly and full Kelly
  const fraction = 0.25 + (confidence * 0.75);
  return kelly(marketProb, myProb) * fraction;
}

When my model has a strong, well-evidenced signal, I scale toward Full Kelly. When it's a weaker or noisier signal, I scale back toward Quarter Kelly. This way, sizing reflects not just edge size but confidence in the edge.

How It Changed My Bot's Performance

Before Kelly, I was flat-betting - putting the same fixed amount on every trade regardless of edge. This seems "safe" but it's actually suboptimal in both directions:

Overbetting weak edges → unnecessary variance, occasional blowups
Underbetting strong edges → leaving money on the table

Here's what changed after switching to Fractional Kelly:

Metric	Before Kelly	After Kelly
Weekly variance	High	Moderate
Max drawdown	~28%	~12%
Return per trade	Similar	Similar
Overall growth	Inconsistent	Smoother compounding

The individual trade returns didn't change much - my model was the same. But the compounding improved significantly. Kelly sizing means your bankroll grows faster during hot streaks and protects capital during cold ones automatically, without any manual intervention.

The biggest mindset shift: Kelly isn't about winning more. It's about not blowing up your edge by sizing wrong.

A Few Gotchas I Learned the Hard Way

1. Your probability estimates are almost certainly overconfident.
If your model says 70% but the true probability is 58%, Kelly will tell you to bet more than you should. Always sanity-check your edge estimates against your actual historical win rate.

2. Kelly ignores liquidity.
On Polymarket, large positions move the market against you. Even if Kelly says 30%, you might only be able to fill 5–8% without impacting your own odds. I cap positions at a liquidity-adjusted maximum regardless of Kelly output.

3. Multiple simultaneous bets.
If your bot runs several trades at once, you can't just apply Kelly independently to each - you'd be collectively overbetting. Look into simultaneous Kelly or simply divide your effective bankroll by the number of concurrent positions.

4. Never bet on negative Kelly.
If f* comes out negative, Kelly is telling you: this bet has no edge for you. Pass. The formula is a filter as much as a sizer.

Wrapping Up

The Kelly Criterion didn't make my bot smarter. It made it more disciplined. That distinction matters more than I expected.

If you're building a prediction market bot and you're flat-betting or gut-sizing, this is probably the single highest-leverage improvement you can make - without touching your signal at all.

Try Half Kelly first. Watch your drawdowns shrink. Then tune from there.

Building on Polymarket or have questions about bot sizing? Drop a comment - happy to compare notes.

I Built a Polymarket Trading Bot That Tries to Capture the Last 60 Seconds of Market Inefficiency

Blockchain Rust Engineer — Wed, 10 Jun 2026 13:20:20 +0000

Over the last few days, I've been building and testing a Polymarket trading bot focused on BTC and ETH 15-minute markets.

The idea is surprisingly simple:

Instead of predicting where Bitcoin or Ethereum will go over the next hour, day, or week, the bot attempts to identify situations where the market already appears nearly certain about the outcome and then enters shortly before settlement.

Think of it less as directional trading and more as an attempt to capture remaining uncertainty premium.

For more information about the strategy please read this medium article

The Core Idea

Suppose a market is trading:

YES = 0.88
NO = 0.12

If YES wins, each YES token settles for $1.00.

Buying at 0.88 means:

Risk: $0.88
Payout: $1.00
Gross Return: 13.6%

The catch is obvious:

You need to win more often than the implied probability suggests.

If the market is perfectly efficient, there should be little or no edge.

The entire strategy depends on one question:

Are prediction markets systematically mispricing near-certain outcomes during the final seconds before resolution?

Why This Is Dangerous

At first glance the strategy looks easy.

It isn't.

There are several major risks.

1. Slippage

A trade that appears available at 0.88 may actually fill at 0.91 or 0.94.

A few percentage points of slippage can completely eliminate the expected edge.

2. Fees

Small expected returns become much smaller after fees.

When many trades only generate 1–3% ROI, execution costs matter.

3. Last-Minute Reversals

Crypto can move violently in the final candle.

A market showing 95% confidence can suddenly reverse if BTC or ETH experiences a sharp move.

4. Resolution Risk

Prediction markets introduce a unique risk:

Even a correct trade can experience delays if settlement is disputed or delayed.

Bot Architecture

The bot is intentionally simple.

Stack:

Node.js
TypeScript
Ubuntu

Modes:

Paper Trading
Backtesting
Live Trading

Data storage:

JSON files
CSV exports

No database.

No Docker.

No frontend.

Everything is logged directly to the terminal and stored for later analysis.

What the Bot Tracks

For every trade the system records:

Entry probability
BTC/ETH spot price
Time remaining until resolution
Bid/ask spread
Liquidity
Expected fill price
Actual fill price
Slippage
Latency
Fees
ROI
Final outcome

Example trade:

BTC 15m market
85.5% probability
Entry 41 seconds before resolution
Stake: $50.86
Profit: $7.88
ROI: 15.49%

That single trade generated more profit than many of the 98–99% probability entries combined.

Early Results

Current results:

Trades Settled: 22
Wins: 22
Losses: -$13.5
Win Rate: 100%
Profit: +$37.84
Account Growth: approximately +3.8%

The highest quality opportunities were not always the highest probability trades.

Some of the most profitable trades occurred when the market was pricing outcomes around 85–95% rather than 99%.

That observation surprised me.

The Most Interesting Finding So Far

The strategy's biggest challenge isn't prediction.

It's execution.

In many cases:

The market direction was correct.
The probability estimate was correct.
The trade still produced very little profit.

Why?

Because entering at 98–99% probability leaves almost no remaining premium to capture.

Several trades generated less than $1 profit despite being successful.

This suggests that:

Win rate alone is not enough.
Expected value matters more than accuracy.
Better entries may exist at lower probabilities if risk remains controlled.

What I'm Investigating Next

I'm now collecting enough data to analyze:

Spread vs profitability
Slippage vs profitability
Liquidity vs profitability
Entry timing vs profitability
BTC volatility vs profitability
ETH volatility vs profitability

The goal is to identify which variables actually drive returns rather than relying on intuition.

Final Thoughts

A 100% win rate sounds impressive.

But 22 trades is nowhere near enough data to prove an edge.

The real test will come after hundreds or thousands of trades.

For now, the most valuable outcome isn't the profit.

It's the data.

Every trade helps answer the question:

Can prediction markets become inefficient during the final moments before resolution, and if so, under what conditions?

That's the problem I'm trying to solve.

I Built a Real-Time Dashboard for My Polymarket Trading Bot - Here Are Problems Nobody Warned Me About

Blockchain Rust Engineer — Tue, 09 Jun 2026 13:18:53 +0000

I've been running a Polymarket trading bot since April 2026. 3,292 predictions placed. And for the first two months, I was flying blind.

No dashboard. Just raw terminal logs scrolling past. P&L buried in JSON files. No way to know in real-time if the bot was winning, losing, stuck, or silently dead.

So I built a dashboard. And it nearly broke me.

This is everything I wish someone had told me before I started - the architecture decisions, the shocking edge cases, the WebSocket nightmares, the data problems that only appear at 2am when your bot is live.

What the Dashboard Needed to Do

Before writing a single line of code I listed the minimum viable features:

Real-time P&L - know my current profit/loss without opening a spreadsheet
Live trade signals - see what the bot is considering entering right now
Position tracker - all open positions with entry price, current odds, unrealized P&L
Bot health monitor - is the bot alive? when did it last fire? is the API connection healthy?
Win rate stats - rolling win rate, average ROI per trade, total predictions
Market odds display - live Polymarket odds for markets the bot is watching

Simple list. Absolute nightmare to build correctly.

The Stack I Chose

Frontend:  React + Recharts + TailwindCSS
Backend:   FastAPI (Python)
Real-time: WebSocket (native browser API + Python websockets library)
Database:  SQLite (local) → PostgreSQL (production)
Data:      Polymarket CLOB API + GAMMA API
Hosting:   VPS (Ubuntu) + Nginx reverse proxy

Why FastAPI over Flask? Server-sent events and WebSocket support are first-class. With Flask I was fighting the framework. FastAPI just works.

Why SQLite first? Because premature optimization is real. SQLite handled 3,000+ trade records without breaking a sweat. I only moved to Postgres when I needed concurrent writes from multiple bot processes.

Shocking Problem #1: The WebSocket That Lies to You

This one cost me three days.

Polymarket's CLOB WebSocket connection appears to stay open even when it's dead. The readyState shows OPEN. No error fires. No disconnect event. The connection is just... silently delivering nothing.

I built my dashboard assuming that if the WebSocket was open, it was working. My odds display would show data frozen from 40 minutes ago while I assumed everything was live.

The fix is a heartbeat monitor - you have to implement it yourself:

import asyncio
import websockets
import json
import time

class PolymarketWSClient:
    def __init__(self, url: str, on_message, heartbeat_interval: int = 15):
        self.url = url
        self.on_message = on_message
        self.heartbeat_interval = heartbeat_interval
        self.last_message_time = time.time()
        self.ws = None
        self.connected = False

    async def connect(self):
        while True:  # auto-reconnect loop
            try:
                async with websockets.connect(self.url) as ws:
                    self.ws = ws
                    self.connected = True
                    self.last_message_time = time.time()
                    print(f"[WS] Connected to {self.url}")

                    # Run message listener and heartbeat checker concurrently
                    await asyncio.gather(
                        self._listen(ws),
                        self._heartbeat_check(ws)
                    )
            except Exception as e:
                self.connected = False
                print(f"[WS] Disconnected: {e}. Reconnecting in 5s...")
                await asyncio.sleep(5)

    async def _listen(self, ws):
        async for message in ws:
            self.last_message_time = time.time()
            await self.on_message(json.loads(message))

    async def _heartbeat_check(self, ws):
        while True:
            await asyncio.sleep(self.heartbeat_interval)
            elapsed = time.time() - self.last_message_time
            if elapsed > self.heartbeat_interval * 2:
                print(f"[WS] No message for {elapsed:.0f}s — forcing reconnect")
                await ws.close()  # triggers reconnect in outer loop
                return

The key insight: don't trust readyState. Trust message recency. If no message has arrived in 2× your expected interval, treat the connection as dead and reconnect.

Dashboard lesson: always show a "last updated" timestamp next to every live data panel. Users (including yourself) need to know how stale the data is.

Shocking Problem #2: P&L That Lies at Market Boundaries

This one is subtle and will drive you insane.

Polymarket markets resolve in batches. Between when a market closes and when it officially resolves on-chain, your position is in a limbo state. The API still shows it as open. The price is frozen. But the outcome is effectively decided.

If you calculate P&L from position value alone, your dashboard will show wildly wrong numbers during this window - sometimes for hours.

from enum import Enum
from dataclasses import dataclass
from typing import Optional

class MarketStatus(Enum):
    ACTIVE = "active"
    CLOSED = "closed"       # trading stopped, not yet resolved
    RESOLVED = "resolved"   # outcome confirmed on-chain
    LIMBO = "limbo"         # closed but resolution pending

@dataclass
class Position:
    market_id: str
    token_id: str
    entry_price: float
    size: float
    current_price: float
    market_status: MarketStatus
    resolution_price: Optional[float] = None

def calculate_pnl(position: Position) -> dict:
    """
    P&L calculation that handles market boundary states correctly.
    """
    if position.market_status == MarketStatus.RESOLVED:
        # Use resolution price, not current_price (which may be stale)
        if position.resolution_price is None:
            return {"pnl": None, "status": "awaiting_resolution_data"}

        pnl = (position.resolution_price - position.entry_price) * position.size
        return {
            "pnl": round(pnl, 4),
            "status": "resolved",
            "is_final": True
        }

    elif position.market_status == MarketStatus.LIMBO:
        # Show unrealized P&L but flag it as unreliable
        unrealized = (position.current_price - position.entry_price) * position.size
        return {
            "pnl": round(unrealized, 4),
            "status": "limbo_unreliable",
            "warning": "Market closed — P&L pending on-chain resolution",
            "is_final": False
        }

    elif position.market_status == MarketStatus.CLOSED:
        # Same as limbo but cleaner
        unrealized = (position.current_price - position.entry_price) * position.size
        return {
            "pnl": round(unrealized, 4),
            "status": "closed_pending",
            "is_final": False
        }

    else:  # ACTIVE
        unrealized = (position.current_price - position.entry_price) * position.size
        return {
            "pnl": round(unrealized, 4),
            "status": "live",
            "is_final": False
        }

Dashboard lesson: never show a single P&L number without a status badge. Show whether it's live, limbo, or final. A number without context is worse than no number.

Shocking Problem #3: The Rate Limit Wall at Exactly the Wrong Moment

Polymarket's CLOB API has rate limits that seem generous until your dashboard and your bot are both hitting the API at the same time.

The bot is scanning for entry signals. The dashboard is polling for position updates. The dashboard is also refreshing odds for 12 watched markets. Suddenly you're at 429 Too Many Requests - and your bot misses an entry because the dashboard stole its API budget.

The fix is a shared rate-limited API client with a request queue:

import asyncio
from collections import deque
import time

class RateLimitedAPIClient:
    """
    Single shared API client for both bot and dashboard.
    Enforces rate limits across all consumers.
    """
    def __init__(self, requests_per_second: float = 5.0):
        self.rps = requests_per_second
        self.min_interval = 1.0 / requests_per_second
        self.last_request_time = 0.0
        self.queue = deque()
        self._lock = asyncio.Lock()

    async def get(self, url: str, priority: str = "normal") -> dict:
        """
        priority: 'bot' = high priority (jumps queue)
                  'normal' = dashboard polling (standard queue)
        """
        async with self._lock:
            now = time.monotonic()
            wait = self.min_interval - (now - self.last_request_time)
            if wait > 0:
                await asyncio.sleep(wait)

            self.last_request_time = time.monotonic()

        # Make actual request (implement with aiohttp)
        return await self._fetch(url)

    async def _fetch(self, url: str) -> dict:
        import aiohttp
        async with aiohttp.ClientSession() as session:
            async with session.get(url) as response:
                if response.status == 429:
                    retry_after = int(response.headers.get('Retry-After', 10))
                    print(f"[API] Rate limited. Waiting {retry_after}s")
                    await asyncio.sleep(retry_after)
                    return await self._fetch(url)  # retry once
                return await response.json()

# Singleton - import this everywhere
api_client = RateLimitedAPIClient(requests_per_second=4.0)

Dashboard lesson: your dashboard is a second consumer of your API budget. Design for this from day one. The bot always gets priority. The dashboard polls on whatever's left.

Shocking Problem #4: Real-Time Charts That Eat Your Memory

I added a live P&L chart to the dashboard - a rolling line chart updating every second. Looked amazing. Worked perfectly.

For about 45 minutes.

Then the browser tab was using 800MB of RAM and the chart was lagging 3 seconds behind. The problem: I was pushing every data point into a React state array and never trimming it. After 2,700 data points (45 minutes × 60 seconds), Recharts was re-rendering a 2,700-point dataset on every tick.

import { useState, useEffect, useRef } from "react";

const MAX_POINTS = 300; // 5 minutes at 1s intervals

export function useLivePnLChart(websocket) {
  const [chartData, setChartData] = useState([]);
  const bufferRef = useRef([]);

  useEffect(() => {
    if (!websocket) return;

    const handleMessage = (event) => {
      const data = JSON.parse(event.data);
      if (data.type !== "pnl_update") return;

      const point = {
        time: new Date().toLocaleTimeString(),
        pnl: parseFloat(data.pnl.toFixed(4)),
      };

      // Update buffer
      bufferRef.current = [
        ...bufferRef.current.slice(-(MAX_POINTS - 1)),
        point
      ];

      // Only update React state every 5 seconds to limit re-renders
      // Use requestAnimationFrame for smooth updates
      setChartData([...bufferRef.current]);
    };

    websocket.addEventListener("message", handleMessage);
    return () => websocket.removeEventListener("message", handleMessage);
  }, [websocket]);

  return chartData;
}

And the throttled update pattern for charts:

import { useCallback, useRef } from "react";

export function useThrottledChartUpdate(setter, intervalMs = 2000) {
  const lastUpdate = useRef(0);
  const pending = useRef(null);

  return useCallback((newData) => {
    pending.current = newData;
    const now = Date.now();

    if (now - lastUpdate.current >= intervalMs) {
      setter(newData);
      lastUpdate.current = now;
      pending.current = null;
    }
  }, [setter, intervalMs]);
}

Dashboard lesson: cap your data buffer. 300 points is plenty for a live chart. Beyond that you're paying memory cost for data nobody is reading.

Shocking Problem #5: The Bot Dies and the Dashboard Doesn't Know

This one is genuinely scary. Your bot process crashes at 3 am. The dashboard still shows the last known state - positions, P&L, odds - all frozen but looking completely normal. You wake up, check the dashboard, think everything is fine. The bot has been dead for 6 hours.

The fix is a heartbeat system between the bot and the dashboard backend:

# In your bot process - send heartbeat every 10 seconds
import asyncio
import aiohttp
import time

async def send_heartbeat(dashboard_url: str):
    while True:
        try:
            payload = {
                "timestamp": time.time(),
                "status": "alive",
                "active_positions": len(bot.get_positions()),
                "last_trade_time": bot.last_trade_timestamp,
                "uptime_seconds": bot.uptime()
            }
            async with aiohttp.ClientSession() as session:
                await session.post(f"{dashboard_url}/api/heartbeat", json=payload)
        except Exception as e:
            print(f"[Heartbeat] Failed to send: {e}")
        await asyncio.sleep(10)

# In your FastAPI backend - track heartbeat and expose health endpoint
from fastapi import FastAPI
from datetime import datetime
import time

app = FastAPI()
last_heartbeat = {"timestamp": None, "data": None}

@app.post("/api/heartbeat")
async def receive_heartbeat(payload: dict):
    last_heartbeat["timestamp"] = time.time()
    last_heartbeat["data"] = payload
    return {"status": "received"}

@app.get("/api/bot-health")
async def bot_health():
    if last_heartbeat["timestamp"] is None:
        return {"status": "never_connected", "alive": False}

    age = time.time() - last_heartbeat["timestamp"]
    alive = age < 30  # dead if no heartbeat in 30 seconds

    return {
        "alive": alive,
        "last_seen_seconds_ago": round(age, 1),
        "status": "alive" if alive else "DEAD",
        "last_data": last_heartbeat["data"]
    }

In the React dashboard, poll /api/bot-health every 15 seconds and show a big red banner if alive === false. Not a subtle indicator. A big red banner you cannot miss.

Dashboard lesson: assume the bot will die unexpectedly. Design the dashboard to scream when it does, not silently show stale data.

Shocking Problem #6: Timezone Hell

Polymarket markets resolve at specific times. The CLOB API returns timestamps in UTC. Your local machine might be in a different timezone. Your VPS is probably in UTC. Your browser is in the user's local timezone.

I spent two hours debugging why a market that "should have resolved 3 hours ago" was still showing as active. It had resolved. The timestamps were just being compared in mixed timezones.

from datetime import datetime, timezone

def normalize_timestamp(ts) -> datetime:
    """
    Always returns timezone-aware UTC datetime.
    Handles: Unix timestamp (int/float), ISO string, naive datetime
    """
    if isinstance(ts, (int, float)):
        return datetime.fromtimestamp(ts, tz=timezone.utc)

    if isinstance(ts, str):
        # Handle ISO format with or without Z suffix
        ts = ts.replace('Z', '+00:00')
        dt = datetime.fromisoformat(ts)
        if dt.tzinfo is None:
            dt = dt.replace(tzinfo=timezone.utc)
        return dt

    if isinstance(ts, datetime):
        if ts.tzinfo is None:
            return ts.replace(tzinfo=timezone.utc)
        return ts

    raise ValueError(f"Cannot normalize timestamp: {ts!r}")

def time_to_resolution(end_date_str: str) -> float:
    """Returns hours until resolution. Negative = already resolved."""
    end = normalize_timestamp(end_date_str)
    now = datetime.now(tz=timezone.utc)
    delta = (end - now).total_seconds()
    return delta / 3600

Dashboard lesson: pick UTC everywhere in your backend. Convert to local time only at the last moment in the frontend display layer. Never compare timestamps from different sources without normalizing first.

Shocking Problem #7: The Number That's Always Wrong

Your dashboard shows P&L as $0.30000000000000004.

JavaScript floating point. It will appear. It will look terrible. And it will appear in the most visible place on your dashboard.

// The problem
const pnl = 0.1 + 0.2; // → 0.30000000000000004

// The fix - always format before display
const formatPnL = (value) => {
  const rounded = Math.round(value * 10000) / 10000;
  const sign = rounded >= 0 ? "+" : "";
  return `${sign}$${Math.abs(rounded).toFixed(4)}`;
};

// For percentages
const formatROI = (value) => {
  return `${value >= 0 ? "+" : ""}${(value * 100).toFixed(2)}%`;
};

// For odds (0-1 scale → percentage display)
const formatOdds = (value) => {
  return `${(value * 100).toFixed(1)}%`;
};

// Never let a raw float touch the DOM
// Every number: formatPnL(), formatROI(), or formatOdds() before render

Dashboard lesson: create formatting functions on day one and route every displayed number through them. Fixing floating point display after the fact means hunting down every raw number in your JSX. Do it right from the start.

The Architecture That Actually Works

After all of this, here's the architecture I settled on:

┌─────────────────────────────────────────────┐
│              React Dashboard                │
│  P&L Chart | Positions | Bot Health | Odds  │
└──────────────┬──────────────────────────────┘
               │ WebSocket (live updates)
               │ REST (initial load + polling)
┌──────────────▼──────────────────────────────┐
│           FastAPI Backend                   │
│  /api/positions  /api/health  /api/stats    │
│  WS /ws/live-feed                           │
└──────────────┬──────────────────────────────┘
               │
     ┌─────────┴──────────┐
     │                    │
┌────▼────┐        ┌──────▼──────┐
│ SQLite/ │        │ Polymarket  │
│Postgres │        │  CLOB API   │
│(history)│        │ (live data) │
└─────────┘        └─────────────┘
               ▲
               │ heartbeat every 10s
┌──────────────┴──────────────────────────────┐
│              Trading Bot Process            │
│  Scanner | Entry Logic | Position Manager   │
└─────────────────────────────────────────────┘

The bot and the dashboard backend are separate processes. They communicate only through the database (for history) and the heartbeat endpoint (for health). This means if the dashboard crashes, the bot keeps running. If the bot crashes, the dashboard still shows historical data and screams that the bot is dead.

The 10 Dashboard Rules I Now Never Break

Every live number shows its last-updated timestamp - no silent staleness
Bot health is always visible - top of the page, big red/green indicator
P&L has a status badge - live, limbo, resolved, or final
WebSocket has a heartbeat - if no message in 30s, reconnect
Dashboard never shares API budget with the bot - separate rate limiters
All timestamps normalized to UTC at ingestion - convert to local only on display
Chart data is capped at 300 points - buffer trimmed on every push
Every number goes through a formatter - no raw floats in the DOM
Bot and dashboard are separate processes - one dying doesn't kill the other
Assume everything will fail at 3am - design every component for graceful degradation

What I'd Build Differently

If I started today:

Use Grafana + InfluxDB for the charts from day one. Rolling my own charting was interesting but Grafana handles time-series data with zero memory issues.
Add alerting before adding features - a Telegram or Discord bot that pings me when the bot dies is more valuable than a beautiful P&L chart.
Start with a single-page static HTML dashboard - I overcomplicated the frontend with React when a simple HTML page with vanilla JS WebSocket would have been live in 2 hours.

Final Thought

Building a trading bot dashboard teaches you things that no tutorial prepares you for - because the problems only appear when real money is moving through real APIs in real time.

The WebSocket that silently dies. The P&L frozen at market close. The rate limit wall you hit because you forgot your dashboard is also an API consumer. The floating point number that makes your beautiful dashboard look broken.

Every one of these problems has a fix. But you have to get burned by them first.

My Polymarket profile if you want to see the bot's live results: @rowelly

All code here is production code from my live bot. Use it, break it, improve it.

Tags: #webdev #python #javascript #react #algotrading #polymarket #tradingbot #webSocket #fastapi #buildinpublic

Building a Last-Entry Probability Capture Trading Bot on Polymarket with TypeScript

Blockchain Rust Engineer — Mon, 08 Jun 2026 16:15:33 +0000

Over the past few months, I've been experimenting with automated trading systems on Polymarket.

One of the more interesting ideas I explored was what I call a Last-Entry Probability Capture Strategy.

The concept sounds simple:

Instead of trying to predict market direction, wait until the final moments before resolution and look for markets where the remaining uncertainty appears overpriced.

In theory, you're not forecasting the future. You're attempting to capture the gap between the market price and what appears to be a near-certain outcome.

As it turns out, the strategy was much more challenging than it looked on paper.

The Core Idea

Imagine a market trading at:

YES = 0.88
NO = 0.12

If the market ultimately resolves YES:

Cost = $0.88
Payout = $1.00
Gross return = 13.6%

At first glance, that sounds attractive.

The break-even point is straightforward:

You need to be correct more often than the implied probability of your entry price.

For an entry at 0.88, you need a win rate above 88%.

The idea is not to predict outcomes.

The idea is to identify situations where the market is temporarily mispricing the remaining uncertainty.

In other words:

Can you find moments where the market says 88%, but reality is closer to 95%, 98%, or 99%?

That question became the foundation of the project.

Initial Assumption

My original assumption was simple:

As a market approaches resolution, information becomes increasingly complete.

If traders are slow to react or liquidity becomes fragmented, temporary pricing inefficiencies may appear.

Those inefficiencies could potentially create opportunities for automated execution.

The challenge was determining whether those opportunities actually survive real-world execution.

System Architecture

The bot was built around several independent components:

Polymarket Markets
        │
        ▼
Market Scanner
        │
        ▼
Signal Engine
        │
        ▼
Risk Filter
        │
        ▼
Execution Engine
        │
        ▼
Order Manager
        │
        ▼
Trade Analytics

Market Scanner

The scanner continuously monitored active markets and filtered candidates based on:

Time remaining
Current probability
Spread size
Available liquidity
Historical behavior

The goal was to reduce thousands of market updates into a manageable set of opportunities.

Signal Engine

The signal engine evaluated whether a market met the strategy criteria.

Typical factors included:

Probability threshold
Remaining time
Spread conditions
Liquidity requirements

Only markets passing all conditions were forwarded to execution.

Risk Filter

Before submitting an order, the bot evaluated:

Position sizing
Maximum exposure
Current inventory
Available liquidity
Expected slippage

This layer prevented aggressive entries during poor market conditions.

Execution Engine

Execution turned out to be the most important component in the entire system.

Theoretical edges are easy.

Capturing them consistently is much harder.

The Reality of Execution

The biggest lesson from this project was that strategy logic is only half the problem.

Execution quality determines whether the edge survives.

1. Liquidity Disappears Quickly

One assumption I underestimated was liquidity decay.

As resolution approaches, order books can change dramatically.

An opportunity that appears available at 0.88 may only be partially fillable.

The actual fill price may be:

0.90
0.91
0.93

At that point, much of the theoretical edge has already disappeared.

2. Slippage Matters More Than Expected

Backtests often assume perfect execution.

Reality does not.

A strategy that appears profitable on paper can become unprofitable when real fills are considered.

Tracking actual fill prices became one of the most important metrics in the system.

A small amount of slippage repeated hundreds of times can completely change performance.

3. Late Price Movements Are Violent

One of the largest risks appeared in short-duration crypto markets.

Markets that seem nearly resolved can still experience dramatic price changes in the final moments.

A market trading at:

YES = 0.88

can rapidly move lower if underlying price action changes unexpectedly.

The closer you trade to resolution, the more sensitive you become to sudden market reactions.

4. Resolution Risk Exists

Another challenge was resolution itself.

Not every market resolves immediately.

Close calls, oracle delays, and boundary conditions occasionally introduce uncertainty that isn't reflected in a simple probability calculation.

Capital can remain locked longer than expected.

What Markets Worked Best?

During testing, the most practical candidates were:

BTC 15-minute markets
ETH 15-minute markets

These markets generally offered:

Higher liquidity
Tighter spreads
More consistent order books
Better execution conditions

Lower-liquidity markets often produced theoretical opportunities that disappeared once execution was considered.

Performance Improvements

Much of the engineering effort eventually shifted away from strategy design and toward infrastructure.

Areas of focus included:

Faster market scanning
Reduced execution latency
Better connection management
Lower processing overhead
Improved monitoring

In one iteration, I reduced execution latency from roughly 100ms to around 50ms.

While that improvement didn't magically create profits, it significantly improved consistency during periods of heavy activity.

The Biggest Lesson

The most important takeaway from this project is that finding an apparent edge is relatively easy.

The difficult part is determining whether that edge survives:

Fees
Slippage
Liquidity constraints
Latency
Market microstructure

A strategy can look excellent in a spreadsheet and fail completely in production.

The market doesn't care about theoretical profitability.

It cares about execution.

Final Thoughts

What started as a simple idea became a useful lesson in trading system design.

The strategy itself was interesting, but the engineering challenges turned out to be even more valuable:

Real-time data processing
Risk management
Low-latency execution
Market microstructure analysis
Performance optimization

Whether the strategy ultimately succeeds or fails long term, building the system provided a much deeper understanding of how prediction markets behave under real trading conditions.

And that's often where the most useful lessons come from.

DEV Community: Blockchain Rust Engineer

My Bot Showed +$84 Profit. The Chain Said +$11. Here's Why.

Polymarket Arbitrage Strategies - Analysis

What I looked for

The three accounts

@first - directional momentum bot

@second - merge/redeem arb, fully exited

@third - live intra-market arb, caught mid-trade

What this tells you about the current state of Polymarket arb

The bot I built

Lessons from watching these bots

I Backtested My Polymarket Bot Against Real Order Book Data. Here's What I Found.

The data problem

The backtester structure

Simulating fills

What I found

One thing the backtest can't tell you

Setup if you want to replicate this

Building a Trading Bot Is Easy. Building One That Survives Overnight Isn't.

Problem #1: Network Connections Always Fail

Problem #2: Processes Crash When You Least Expect It

Problem #3: Logging Becomes More Important Than Trading

Problem #4: Latency Isn't Constant

Problem #5: Memory Leaks Are Sneaky

Problem #6: Monitoring Matters More Than Features

Problem #7: Production Data Is Different

The Biggest Lesson

Final Thoughts

Building a Low-Latency Trading Bot in Rust (From 48ms to 800µs)

Why Rust? (The Real Answer)

Architecture in One Diagram

Project Setup

The Order Book

WebSocket Feed Handler

Auto-Reconnect Logic

The Strategy Engine (Where Alpha Lives)

Benchmarks

5 Pitfalls That Will Ruin Your Day

What's Next

Final Thought

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

Background: Where We Left Off

How Polymarket's WebSocket Feed Works

The Rust Implementation

The WebSocket Client

Connecting the Scanner

The Main Loop

Benchmarking: What Actually Changed

The Uncomfortable Finding

What I'm Changing in Signal Logic

Infrastructure Note: Reconnection Handling

What This Changes About the System

Should You Add WebSocket to Your Bot?

What's Next

Conclusion

My Polymarket Trading Bot in Rust After TypeScript Kept Missing Fills

Background: What My Bot Was Doing

Profiling the TypeScript Bot: Where Was the 340ms Going?

Why Rust, Specifically

The Rust Architecture

Dependencies (Cargo.toml)

The Connection Pool: The Most Important Change

Parallel Market Scanning with tokio

Async Logging: Eliminating the 58ms Disk Block

The Signal Logic: Unchanged

Benchmark Results: Before and After

What Actually Changed in Trading Performance

What Didn't Change: The Uncomfortable Truth

Should You Do This?

What's Next

Conclusion

Building a Polymarket Trading Bot: Architecture, Execution, and Risk Management

How I built a real-time automated trading system that monitors BTC, ETH, SOL, and XRP prediction markets and executes trades based on short-lived pricing inefficiencies.

Understanding the Market

Project Goals

High-Level Architecture

Real-Time Data Collection

The Signal Engine

Multi-Asset Execution

Risk Management

Dependencies (`Cargo.toml`)