DEV Community: Blockchain Rust Engineer

Building a Polymarket Arbitrage Bot: 5 Strategies, One Signal-Ranking Problem

Blockchain Rust Engineer — Wed, 22 Jul 2026 13:53:41 +0000

Most "Polymarket arbitrage bot" writeups stop at explaining what arbitrage is. The actual engineering problem starts after that - once you have five strategies running in parallel, all watching the same markets, and need to decide which signal to act on when two or three of them fire at once. That's the part worth documenting.

The five strategies, briefly

Intra-market arbitrage exploits the fact that YES + NO token prices should sum to $1.00. When they don't, buying both sides and redeeming the complete set locks a profit independent of outcome. Combinatorial arbitrage is the same mechanic extended to multi-outcome markets. Both of these are close to structurally risk-free - you're buying a guaranteed redemption, not predicting anything.

Cross-platform arbitrage compares Polymarket's implied probability against spot prices on exchanges like Binance and bets on convergence. Endgame arbitrage targets near-resolution markets where one side already trades above ~93%. Momentum/mean-reversion applies Z-score, RSI, and VWAP divergence to Polymarket's price series across multiple timeframes. These three are directional, not risk-free, and treating them the same as the first two is a modeling mistake I see a lot of amateur implementations make.

The actual hard problem: signal ranking

Running five detection strategies concurrently means a single market can trigger multiple, sometimes conflicting, signals in the same scan cycle. A naive implementation executes whichever signal fires first - which is a bug waiting to compound, because "first" has nothing to do with "best."

The fix is a weighted composite score per signal:

def score_signal(signal):
    return (
        signal.expected_profit_pct * WEIGHT_PROFIT +
        signal.confidence * WEIGHT_CONFIDENCE +
        STRATEGY_PRIORITY[signal.strategy_type] * WEIGHT_STRATEGY +
        signal.urgency * WEIGHT_URGENCY +
        signal.risk_reward_ratio * WEIGHT_RISK_REWARD
    )

ranked = sorted(signals, key=score_signal, reverse=True)
executable = [s for s in ranked if s.score > EXECUTION_THRESHOLD]

TRATEGY_PRIORITY is where the risk-profile distinction actually gets encoded - intra-market and combinatorial get weighted up, cross-platform and momentum get weighted down, by design, not by accident. Getting this weighting wrong is the difference between a bot that behaves like an arbitrage system and one that quietly turns into a directional trading system without anyone deciding that on purpose.

Why this matters if you're building or evaluating one

A lot of "arbitrage bot" marketing glosses over the fact that these are five different risk categories bundled under one label. If you're building your own, the signal-ranking layer is where real engineering judgment lives - it's a genuinely harder problem than detecting any single strategy in isolation, and it's the part that separates a working system from a collection of independent scripts.

Full open-source implementation, including the strategy detection and scoring logic: github.com/casatrick/polymarket-arbitrage-bot-python

Longer technical breakdown of each strategy: casatrick.substack.com

Screening Polymarket Markets: Liquidity and Resolution Risk

Blockchain Rust Engineer — Tue, 21 Jul 2026 13:30:36 +0000

Most of what I've written about building a Polymarket bot so far assumes you're already trading a specific market - execution timing, position sizing. Neither of those matters if you're trading the wrong markets to begin with. Before any of that logic runs, you need a filter that decides which markets are even worth putting a bot in front of.

Why market selection matters more than it looks

Polymarket lists hundreds of markets at any given time, and the majority of them aren't worth trading algorithmically. Some have almost no depth. Some are structurally ambiguous and carry real resolution risk. Running your edge calculation and execution logic against a market that fails on either of these fronts isn't a minor inefficiency - it's where a lot of "my bot has a working model but still loses money" complaints actually originate.

Filter one: liquidity depth

The execution and sizing logic I've covered in previous posts assumes there's enough resting liquidity near the market price to fill your intended position without excessive slippage. That assumption fails silently on thin markets.

def is_liquid_enough(orderbook, intended_position_size, min_depth_ratio=3.0):
    """
    Checks whether top-of-book depth supports the intended position
    without excessive price impact.
    """
    top_of_book_depth = sum(level['size'] for level in orderbook['bids'][:3])
    return top_of_book_depth >= (intended_position_size * min_depth_ratio)

This ties directly back to the staleness problem from execution: if depth is under roughly 3x your intended position, you're not just risking a stale fill - you shouldn't be sizing a full position into that market in the first place, regardless of how good your edge calculation looks.

Filter two: resolution risk

This one is specific to prediction markets and doesn't have a clean equivalent in traditional trading. Every Polymarket market resolves based on a defined resolution source and criteria - and not all of them are equally unambiguous.

Markets with vague resolution criteria (subjective wording, dependent on a source that could plausibly be interpreted multiple ways) carry a real risk that has nothing to do with your probability model: the market could resolve in a way that doesn't match the "obvious" outcome, or get disputed and delayed. A perfectly calculated edge is worthless if the resolution itself is contested.

Practical screening questions worth encoding into your filter:

Does the resolution source come from a single, unambiguous, verifiable feed, or does it depend on subjective judgment?
Has this market (or its category) had prior resolution disputes on Polymarket's UMA oracle?
Is the resolution date clearly defined, or is there room for the window itself to be ambiguous?

def resolution_risk_score(market_metadata):
    """
    Simple scoring heuristic - lower is safer.
    Replace with your own calibrated weights based on historical dispute data.
    """
    score = 0
    if market_metadata.get('has_prior_disputes'):
        score += 3
    if market_metadata.get('resolution_source_type') == 'subjective':
        score += 2
    if not market_metadata.get('clear_resolution_date'):
        score += 1
    return score

Putting the filter together

The combined screen isn't complicated - it's just a step most bot builders skip because it's less interesting than the pricing model:

def should_trade_market(market, orderbook, intended_size):
    if not is_liquid_enough(orderbook, intended_size):
        return False
    if resolution_risk_score(market['metadata']) > RISK_THRESHOLD:
        return False
    return True

Run this before your edge calculation even fires, not after. There's no point spending compute or API calls pricing a market your risk logic would reject anyway.

The pattern connecting all three pieces

Execution timing, position sizing, and market selection are really the same underlying discipline applied at three different stages: don't trust a snapshot that might not reflect reality by the time you act on it. Execution timing is about book staleness. Sizing is about model confidence. Market selection is about whether the market itself is even a fair, tradeable proposition before you engage either of the other two systems.

I build this kind of infrastructure - execution logic, sizing, and market screening - for prediction market bots, along with provably fair systems for casino platforms. If you're working through similar filtering logic, happy to compare notes.

The Execution Layer Most Trading Bot Tutorials Skip

Blockchain Rust Engineer — Fri, 17 Jul 2026 07:54:47 +0000

I've spent the last several months building execution infrastructure for prediction market bots,mostly on Polymarket alongside RNG and fairness systems for casino-style games. Two very different domains, but they share a failure mode most devs don't think about until it costs them money: the gap between deciding to trade and actually executing.
Most tutorials on trading bots stop at the pricing model. Poll the orderbook, calculate implied probability, compare against your own model, fire an order when edge clears some threshold. That's the part everyone writes about. It's also the part that matters least once you're running on thin-liquidity markets.

Where the standard approach breaks
Here's the loop almost every intro-level bot uses:

def trading_loop():
    book = fetch_orderbook(market_id)
    implied_prob = calculate_implied_probability(book)
    my_prob = model.predict(market_id)
    edge = my_prob - implied_prob

    if edge > EDGE_THRESHOLD:
        place_order(market_id, size=position_size(edge))

This works fine on markets with real depth. It quietly fails on markets with shallow top-of-book liquidity which describes a large chunk of Polymarket listings outside the flagship markets.
The problem isn't the math. It's timing. Between the moment you fetch the book and the moment your order actually reaches the exchange, the book can change. On a thin market, a single order of moderate size can consume most of the visible liquidity in that window. Your edge variable was calculated against a book state that may no longer exist by the time place_order executes.
You end up filling at a price your model never actually evaluated. The math was right. The timing wasn't.

The fix: validate right before you commit
The solution isn't a better model. It's an execution guard, a cheap re-check immediately before order submission:

def trading_loop():
    book = fetch_orderbook(market_id)
    implied_prob = calculate_implied_probability(book)
    my_prob = model.predict(market_id)
    edge = my_prob - implied_prob

    if edge > EDGE_THRESHOLD:
        size = position_size(edge)

        # re-check right before committing
        live_book = fetch_orderbook(market_id)
        drift = calculate_drift(book, live_book)

        if drift > DRIFT_TOLERANCE:
            log_and_skip(market_id, reason="book moved past tolerance")
            return

        place_order(market_id, size=size)

One extra API call per decision. That's the entire cost. In exchange, you stop executing against stale prices, which in my experience matters more on illiquid markets than any amount of additional model refinement.

A rule of thumb that's held up in practice
If top-of-book depth is under roughly 3x your intended position size, treat staleness as your primary risk - not model accuracy. Below that ratio, the market can move meaningfully in the time it takes your order to travel, regardless of how good your pricing signal is.
This isn't unique to prediction markets. The same principle shows up in RNG-based casino games when you're validating outcomes server-side - the state you generate a result against needs to match the state you commit it against, or you open the door to timing-based exploits. Different domain, same root problem: don't trust a snapshot you took before the world had a chance to change.

Where this actually matters
If you're building automated execution on prediction markets, or on any exchange with thin order books, I'd put the execution validation layer ahead of further model tuning on your priority list. A highly accurate model with no staleness protection will still bleed edge on illiquid fills. A modest model with tight execution controls tends to outperform it in the markets that matter.
I build this kind of infrastructure-trading bot execution logic, market-making systems, and provably fair RNG architecture for casino platforms for a living. If you're working on something similar and want a second opinion on your architecture, or need this built from scratch, feel free to reach out.
Here is open-source version:Github

How I'm Getting Organic Traffic Building a Polymarket Bot in Public (No Growth Hacks)

Blockchain Rust Engineer — Wed, 15 Jul 2026 06:06:39 +0000

I've been posting about building a Polymarket trading bot as I go, mostly because I was stuck and wanted to think out loud. A few things I noticed that I didn't expect:
The broken version gets more engagement than the working one. A post about my bot losing money to slippage on a thin market outperformed a clean-architecture writeup by a wide margin. People comment on mistakes they recognize, not on things that already work.
Rewriting per platform beats copy-pasting, even when it's more work. Same core article, different framing: HN gets the technical argument with zero self-promo, dev.to gets the code, Twitter gets one sharp claim instead of a summary. Identical copies performed worse everywhere I tried it.
Code-to-engagement ratio is real here specifically. Posts with actual runnable snippets got bookmarked and shared. Posts that were mostly explanation got read once and forgotten.
I don't have this fully figured out - some of it might just be posting often enough that it compounds, not some traffic secret. Sharing what's worked so far, not a playbook.

Building a Polymarket Trading Bot: Order Book Monitoring, Slippage Handling, and Position Sizing in Python

Blockchain Rust Engineer — Mon, 13 Jul 2026 08:05:14 +0000

Why naive orders lose money on Polymarket
Most people's first Polymarket bot places a market order and calls it done. That works fine on liquid, high-volume markets like major elections But Polymarket has thousands of long-tail markets with thin order books and wide bid-ask spreads. On those markets, a naive market order can fill at a price 5-10 cents away from the quote you saw a second ago, which for a binary contract priced in cents is a massive effective cost.
Polymarket splits its API into two separate services worth knowing up front: the Gamma API (gamma-api.polymarket.com) for public, read-only market discovery, and the CLOB API (clob.polymarket.com) for order books, prices, and actual trading. Market data reads require no authentication; placing orders does.

Basic bot skeleton: discovering a market and reading the book

import httpx
from py_clob_client.client import ClobClient
from py_clob_client.clob_types import BookParams

# Discover a market via the public Gamma API
resp = httpx.get("https://gamma-api.polymarket.com/markets", params={
    "limit": 1,
    "active": True,
    "order": "volume24hr",
    "ascending": False,
})
market = resp.json()[0]

condition_id = market["conditionId"]
clob_token_ids = market["clobTokenIds"]
yes_token_id = clob_token_ids[0]
no_token_id = clob_token_ids[1]

print(f"Market: {market['question']}")
print(f"Yes token: {yes_token_id}")

#Read-only CLOB client — no private key needed just to read the book
client = ClobClient("https://clob.polymarket.com")

book = client.get_order_book(yes_token_id)
mid = client.get_midpoint(yes_token_id)

Implied probability vs. your model's probability
Polymarket prices are already implied probabilities - a Yes price of $0.65 means the market is pricing that outcome at 65%. Your edge, if any, comes from your model disagreeing with that price:

def calculate_edge(model_probability: float, market_price: float) -> float:
    """Positive edge means your model thinks the outcome is more likely
    than the market is pricing it."""
    return model_probability - market_price

model_prob = 0.72          # your model's estimate
market_price = float(mid)  # current market midpoint
edge = calculate_edge(model_prob, market_price)

MIN_EDGE_THRESHOLD = 0.05  # don't trade on noise-level edges
should_enter = abs(edge) > MIN_EDGE_THRESHOLD

Risk logic: position sizing based on edge %
A fractional-Kelly approach scaled down for prediction-market-specific risk (binary payout, model uncertainty) works better than full Kelly, which tends to oversize on overconfident models:


def position_size(bankroll: float, edge: float, market_price: float, 
                   kelly_fraction: float = 0.25, max_position_pct: float = 0.05) -> float:
    """Fractional Kelly sizing, capped by a hard max-exposure-per-market limit."""
    if market_price <= 0 or market_price >= 1:
        return 0.0

    # Simplified binary Kelly: edge / odds against you
    odds = (1 - market_price) / market_price
    kelly_pct = edge / odds if odds > 0 else 0

    sized_pct = max(0, kelly_pct * kelly_fraction)
    capped_pct = min(sized_pct, max_position_pct)  # hard cap per market

    return bankroll * capped_pct

The max_position_pct cap matters more than the Kelly fraction itself - it's your hard stop against a single mispriced model wrecking the account.

Handling partial fills and slippage

Thin order books mean your order may only partially fill at your target price. Rather than chasing the fill with a market order (which is how slippage compounds), check remaining depth before adding size:

def get_fillable_size(book, target_price: float, side: str = "BUY") -> float:
    """Sum size available at or better than target_price."""
    levels = book.asks if side == "BUY" else book.bids
    fillable = 0.0
    for level in levels:
        price = float(level.price)
        if (side == "BUY" and price <= target_price) or 
           (side == "SELL" and price >= target_price):
            fillable += float(level.size)
        else:
            break
    return fillable

fillable = get_fillable_size(book, target_price=market_price + 0.01)
order_size = min(position_size(bankroll=1000, edge=edge, market_price=market_price), fillable)

if order_size < MIN_ORDER_SIZE:
    # not enough liquidity at an acceptable price  skip or use a limit order and wait
    pass

If fillable liquidity is far below your intended size, the honest move is a resting limit order rather than forcing a market order through a thin book.

What I'd do differently
A few lessons that only became obvious after running this against real markets:

Poll less, cache more. Hammering the Gamma API on a tight loop for markets that update every few minutes wastes rate limit budget you'll need when a market is actually moving fast. Poll frequency should scale with time-to-resolution and recent volume, not run on a flat interval.
Log every rejected trade, not just executed ones. The trades your bot decided not to make (edge below threshold, insufficient liquidity) are the dataset that tells you whether your edge threshold is even calibrated correctly.
Treat correlated markets as one position, not many. If your model has edge on "Fed cuts in March" and "Fed cuts in Q1," those aren't independent bets size them as a combined exposure or you'll be more leveraged to one underlying event than your risk logic assumes.
The order book snapshot is already stale by the time you act on it. For anything beyond casual trading, a WebSocket feed (wss://ws-subscriptions-clob.polymarket.com/ws/market) beats polling - the latency difference is the gap between getting filled at your price and getting picked off.
Originally explored in more depth here: Github full description

Why Polymarket Bots Need Different Risk Logic Than Casino RNG Games

Blockchain Rust Engineer — Fri, 10 Jul 2026 07:01:12 +0000

If you're building a Polymarket trading bot, don't copy the risk logic from a casino or RNG betting bot. It's a category error that will bite you the first time a market gets volatile.
The short version: casino odds are exogenous and fixed. Polymarket odds are endogenous and reflexive - your own order can move the price you're trying to predict. That changes what "risk" even means.
Casino RNG risk model (what most bot tutorials teach)
risk = f(bankroll, known_probability, variance)
Kelly criterion, fixed stop-losses, and volatility smoothing all assume a known, stable probability distribution. That assumption holds for roulette. It does not hold for Polymarket.
Why that model breaks on Polymarket

No stable ground-truth distribution - prices shift the instant new information lands (news, on-chain signals, polls). A static-distribution risk model misprices tail risk immediately.
Adverse selection - you can get picked off by a counterparty with a faster or better information edge. No RNG-based model accounts for this.
Market impact and slippage - casino games have no order book; Polymarket does. A large order on a thin contract can move price 5 to 10 percent or more.
Correlated exposure - Polymarket positions often cluster around related real-world events like elections or macro releases, so per-market variance limits miss portfolio-level risk.

A better risk model, roughly
risk = f(order_book_depth, info_event_triggers, order_flow_signal, correlated_market_caps, tail_weighting)
Where order_book_depth drives market-impact-aware sizing, info_event_triggers handle dynamic re-pricing on news, order_flow_signal flags possible adverse selection, correlated_market_caps limit exposure across linked markets, and tail_weighting accounts for the fact that binary payoffs need asymmetric downside protection.
Concretely: before sizing a position, check depth-at-price on the order book instead of just applying a flat percentage of bankroll. Flag abnormal directional flow as a possible informed counterparty. Cap aggregate exposure across markets tied to the same underlying event.
Takeaway
A casino bot manages variance against a known distribution. A Polymarket bot manages exposure in a live, reflexive, information-driven market. If your risk logic doesn't start from market microstructure and information asymmetry, it's not really risk logic for this market - it's risk logic for a different one.
For more deep knowledge please take a look at Github

My Polymarket Bot Has a Volatility Filter Now. Here Is Why I Built It Last.

Blockchain Rust Engineer — Wed, 08 Jul 2026 05:04:55 +0000

I built the execution engine first. Then the order management. Then the inventory controls. Then the WebSocket integration. Then the Rust rewrite. Then the dashboard. Then the risk manager.The volatility filter came after all of that.Which is embarrassing because the volatility filter is the thing that decides whether any of those other systems should be running at all.Here is what happened. A few weeks ago I had a session where the bot ran perfectly by every technical measure I track. No errors. No missed fills. No crashes. PM2 stayed green all night. I woke up to a loss.I pulled the logs from MongoDB and mapped every fill against price movement during that session. The bot had been trading BTC 5 minute markets during a four hour flat range. Almost zero movement. Markets kept opening and closing with thin volume. Fills were coming in one sided. Inventory was accumulating on the buy side with no clean exit.The strategy needs volatility to work. Market making on a prediction market only generates edge when probability is moving fast enough that both sides of the book attract real counterparties. In a dead range probability barely moves. The book looks fine from the outside. The fills just never balance.The bot had no way to know this. It kept trading because that is what it was built to do.The fix was a volatility check before every market entry. Here is the core logic:

function isVolatileEnough(candles: Candle[]): boolean {
  const recent = candles.slice(-5)
  const high = Math.max(...recent.map(c => c.high))
  const low = Math.min(...recent.map(c => c.low))
  const range = (high - low) / low

  return range > VOLATILITY_THRESHOLD // 0.003 for BTC 5m
}

If movement across the last 5 candles is below 0.3 percent the market gets skipped. The bot waits for the next one and checks again.
Getting the threshold right took about a week of backtesting against three months of trade logs. Too sensitive and it skips too many good markets. Too loose and it still enters dead conditions. At 0.003 it filters out roughly 30 percent of markets I was previously trading. P&L improved in the first week.
The second thing I added was a session drawdown limit:

if (sessionPnL < -MAX_SESSION_LOSS) {
  logger.warn('Session drawdown limit hit. Stopping.')
  await cancelAllOrders()
  process.exit(0)
}

If cumulative session loss crosses the limit the bot cancels everything and stops. No grinding through bad conditions trying to recover with the same strategy that is clearly not working.
Both changes reduced total trade count by about 30 percent. That felt wrong at first. More trades had always meant more opportunity. What I learned is that more trades in bad conditions is just more ways to lose. The bot does not need to be active every minute. It needs to be active in the right minutes.
The numbers after two weeks with the filter running:

Total trades down 31 percent
Fill rate up 18 percent
Weekly P&L up across every session
Zero sessions with one sided inventory blowout

I should have built this before the WebSocket integration. Before the Rust rewrite. Before half the things I spent weeks on. None of those optimizations matter when the bot is trading in conditions where the strategy has no edge.
Build the filter that decides when to trade before you optimize how fast you trade.
Full strategy explanation at github.com/casatrick

What Happens to My Polymarket Bot When a BTC Market Resolves Unexpectedly

Blockchain Rust Engineer — Mon, 06 Jul 2026 06:10:06 +0000

What Happens to My Polymarket Bot When a BTC Market Resolves Unexpectedly
This one caught me off guard.
I was running my bot on BTC 5 minute and 15 minute markets on Polymarket. These are fast markets. A new one opens every few minutes. Price goes above or below a level, market resolves, next one starts. The cycle is constant and at first it felt perfect for a market maker. High frequency, steady volume, predictable structure.
Then I learned the hard way that fast markets resolve fast. Faster than I expected. And my bot was not ready for it.
Here is what happened. I had open orders on both sides of a 5 minute BTC market. The market was still showing time remaining on my dashboard. But BTC moved hard in one direction, the resolution condition was met, and the market closed early. My buy side had already filled. My sell side had not. The market resolved before I could balance the position.
The bot kept trying to repost orders on a closed market. The logs started throwing errors I had never seen before. The filled position was now locked at resolution value. The hedge I thought I had was gone.
The damage on that single market was small. But these markets run back to back all day. If this happens once it will happen again. I had to fix it fast.
Here is what I changed.
First I added a resolution time buffer. On 5 minute markets I now stop posting new orders in the last 60 seconds before expected resolution. On 15 minute markets I stop in the last 90 seconds. The spread in those final moments gets weird anyway as the probability collapses toward zero or one. Not worth the risk.
Second I added a pre-order status check. Before every order cycle the bot now calls the API and confirms the market is still active and accepting orders. If anything looks off it skips that market and waits for the next one to open. This added maybe 20 milliseconds to each cycle. Worth it.
Third I added inventory tracking per market expiry. The bot now knows when each market is expected to close and will not let inventory accumulate beyond a certain level as that time approaches. If it is holding tokens and resolution is coming soon it backs off and lets existing positions settle rather than adding more.
Fourth I added automatic market rotation. When a 5 minute market closes the bot now waits for the next one to open and validates it before jumping in. It used to try to switch immediately and sometimes caught the edge of a closing market by mistake. The small delay fixed that.
BTC 5 minute and 15 minute markets are genuinely good for market making when the bot handles the lifecycle correctly. The volume is there. The fills come in. The spreads are workable. But the speed that makes them attractive is the same speed that will burn you if your order management does not account for how quickly they turn over.
My bot runs these markets cleanly now. It took one bad resolution to get there.
All my code is open source at github.com/casatrick if you want to follow along.

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