DEV Community: Rust Engineer

How Kelly Criterion Transformed My Polymarket Trading Bot

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

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

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

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.