def reconcile_twap(my_twap, published_twap, tolerance_pct=0.05):
    drift_pct = abs(my_twap - published_twap) / published_twap
    return "ok" if drift_pct <= tolerance_pct else "drift_detected"

The script also handles a failure mode that didn't exist under the old single-tick resolution - feed gaps mid-window. If the last tick goes stale beyond a threshold, that needs to be caught before it matters for a live position.

Testnet TWAP feeds are live now. Mainnet and RTDS launch August 7, giving a three-day live-fire testing window before settlement actually depends on it.

Full code + walkthrough: [Dev.to link]

I wanted to see whether that idea - checking multiple timeframes before trusting a signal - could be adapted into a Polymarket bot’s decision process, without pretending the whole trading style it comes from transfers cleanly. It doesn’t. But the core idea does, once you strip out everything that assumes a continuous, leveraged position.

Multi-timeframe trend alignment is a well-known structure in futures and perpetuals trading: use a higher timeframe to establish direction, a medium timeframe to confirm the current move isn’t exhausted, and a lower timeframe to time the actual entry. A common version of this looks something like:

• Higher timeframe (1h): is price above or below its 200-period EMA? That’s the broad trend.

• Medium timeframe (15m): has RSI pulled back into oversold/overbought territory and started recovering? That confirms there’s room left in the move.

• Lower timeframe (3m): has a fast momentum oscillator (like Stochastic RSI) just crossed, signaling the pullback is ending?

Only when all three line up does the signal count. It’s a filter designed to reject a lot of setups, not fire on every wiggle.

Why you can’t just port the whole strategy

The full version of this kind of system usually pairs the signal with continuous position management: scaling into the trade with DCA layers if price moves against you, trailing a stop once it moves in your favor, letting a “runner” position stay open for hours to capture an extended trend.

None of that applies to a Polymarket BTC market. Every 5m, 15m, and 1h Up/Down contract is a discrete, expiring bet - it resolves to $0 or $1 at a fixed timestamp and then the window is gone. There’s no position to trail past expiry, no averaging into a bet that’s still “open” the way a futures position is, and no leverage to size against. Trying to import DCA layers or a trailing stop into that structure doesn’t just fail to help - it doesn’t map onto anything that exists in a binary, expiring market.

What does map cleanly is the filter itself: the yes/no question of “is this move aligned across timeframes, or is it noise.” That’s just a signal - and a signal is exactly what a Polymarket bot needs before it decides which side of a window to bet on.

Building it as a signal instead of a strategy

In a config-driven bot, this becomes one more sig_* column sitting alongside the ones you’re probably already computing - order-book imbalance, oracle-vs-window-open divergence, z-scores. Trend alignment just adds a filter for whether the broader context supports the signal you’re about to act on.

def trend_aligned(

price,

ema_200_1h,

rsi_15m,

stoch_rsi_3m,

stoch_rsi_3m_prev,

long_rsi_threshold=40,

short_rsi_threshold=60,

):

Returns 'up', 'down', or None if timeframes don't agree.
Adapted as a directional filter, not a full position strategy - no DCA layers, no trailing stop, since Polymarket markets resolve at a fixed expiry rather than staying open.

bullish_trend = price > ema_200_1h

bearish_trend = price < ema_200_1h

pullback_recovering = (

rsi_15m < long_rsi_threshold

and stoch_rsi_3m > stoch_rsi_3m_prev

)

rally_fading = (

rsi_15m > short_rsi_threshold

and stoch_rsi_3m < stoch_rsi_3m_prev

)

if bullish_trend and pullback_recovering:

return “up”

if bearish_trend and rally_fading:

return “down”

return None

This doesn't decide the trade on its own. It's a gate: if trend_aligned() returns None, the bot doesn't act, regardless of what any other signal says. If it returns a direction, that direction still has to clear the same net-edge check as any other signal before a position is opened.

def combined_decision(trend_signal, model_probability, execution_price, fee, slippage, buffer):

if trend_signal is None:

return None # no timeframe agreement, skip

gross_edge = model_probability - execution_price

net_edge = gross_edge - fee - slippage - buffer

if net_edge <= 0:

return None # trend agrees, but no priced edge — still skip

return trend_signal

That second check matters more here than it does in the original strategy. Trend alignment tells you a direction is more likely to continue - it doesn't tell you the market is mispricing that likelihood. In a binary market, you only have an edge if the price you can actually execute at is cheaper than what your model thinks the true probability is. Agreement across timeframes without a priced edge is just a strong opinion, not a trade.

Where this fits against a phase/price-segmented approach

If you’ve built rules the way my own analysis toolkit does - separate strategies for different phase/price segments, like a late-market cheap-side mode and a mid-price oracle-following mode - trend alignment slots in as an additional filter layered on top of whichever segment-specific rule is already active, rather than replacing it. A late-phase, sub-35¢ signal that also has trend alignment behind it is a stronger version of that same setup, not a new strategy competing with it.

The honest limitation

Multi-timeframe trend alignment is built for markets where “trend” is a meaningful, persistent concept over hours. Five-minute BTC windows are short enough that a 1-hour trend filter may barely change over the life of several consecutive windows - meaning this signal will sometimes just quietly agree with itself across ten markets in a row, adding little new information beyond what a shorter-timeframe signal already told you. It’s most useful as a tie-breaker or confirmation layer, not as the primary source of edge. Worth testing against real data with the same phase/price segmentation discipline before trusting it in anything but paper mode.

I build and adapt trading systems like this for people trading on Polymarket - signal design, strategy discovery from wallet history, or full bot builds. Paper-trading validation before anything goes live, full source ownership, no black-box logic.

When a market says an outcome trades at 38 cents, it's telling you the crowd's probability for that outcome is about 38%. On Polymarket, the price and the probability are the same object. Every price on the order book is a snapshot of a belief - and unlike a stock chart, the correct way to update that belief when new information arrives isn't a matter of opinion. It's a matter of math.

That math is Bayes' theorem, written down in 1763:

P(H|E) = P(E|H) × P(H) / P(E)

Your prior P(H) is the current market price. The likelihood P(E|H) is how likely the news would be if the outcome were actually going to happen. P(E) is how likely the news was in general. The posterior P(H|E) is the updated probability - the number your bot is trying to find.

In practice, quant desks skip the clumsy denominator and work in odds instead:

posterior odds = prior odds × likelihood ratio

A market at 30¢ with prior odds ≈ 0.43 and a likelihood ratio of 3 (news three times more consistent with the outcome happening than not) updates to posterior odds of 1.29 - roughly 56% probability. That's a 26-point gap between market price and fair value, appearing the instant the news lands. A bot doesn't need the price to prove it right; it only needs to be positioned before the crowd finishes the same calculation.

Turning this into a bot, in four steps:

1. Let the market price be your prior - never substitute a gut feeling for the crowd's number

2. Price the evidence, not the emotion - assign an honest likelihood ratio to each piece of news

3. Update, compare, and only trade a real gap - most news isn't worth trading after fees

4. Respect that the edge decays as the crowd catches up - the entire opportunity lives in the window between news landing and the crowd repricing

Where this breaks: double-counting evidence already priced in, treating five outlets reporting the same leak as five separate confirmations instead of one, and feeding the formula miscalibrated likelihoods that produce confidently wrong posteriors.

Full open-source implementation (five parallel strategies, risk controls, signal ranking): github.com/casatrick/polymarket-arbitrage-bot-python

So I built a toolkit that takes any Polymarket wallet address and answers four questions: what did they trade, when and under what conditions, how much per trade, and - the hard one - UP or DOWN, and why. Then it turns those answers into a config-driven bot that replays the discovered rules. Not a copy-trading bot. It doesn't mirror the wallet in real time - it extracts the strategy and runs it independently, in paper mode by default.

Here's how it works, and the one finding that made this actually interesting instead of just a data-collection exercise.

The pipeline

collect → enrich → signals → analyse → report

Collect pulls full trade history for a wallet from Polymarket's Data API (handles 100k+ fills via cursor pagination), plus market metadata for everything they traded.

Enrich joins external context onto every single trade at the moment it happened: Binance and Coinbase OHLCV, the Chainlink ETH/USD oracle price on Polygon, order book spread and imbalance from the Polymarket CLOB, and how close the trade was to market close (I bucket this into early, mid, late, urgent phases).

Signals computes candidate features on every row - momentum z-scores, oracle-vs-price agreement, spread percentage, timing phase.

Analyse runs statistical analysers across all of it - win rate, Sharpe, Brier score, sizing patterns, and the core piece: strategy discovery.

The interesting part: one rule doesn't work

My first assumption was that a trader has a strategy - pick a direction rule, measure how well it holds. That assumption was wrong, and testing it wrong is what made the real pattern visible.

Running this on a real wallet (~65k trades in ETH 5-minute Up/Down markets), a single global rule like "always follow the Chainlink oracle" doesn't hold. But segmenting by phase and price bucket reveals two genuinely different behaviors:

Mode 1 - cheap lottery. In the late/urgent phase, when a token is priced 0–35¢, the trader buys the cheaper side. Win rate is only ~20% - but the payoff structure makes it positive EV. This mode barely correlates with the Chainlink oracle at all (~19% agreement).

Mode 2 - oracle follow. At any phase, once a token is priced 50¢+, the trader follows Chainlink's price vs. the window-open price. Win rate here is ~78%, with a smaller payoff per win.

Two completely different behaviors, cleanly separated by price and timing, both consistently profitable in their own regime - but only visible once you stop assuming one global rule and start segmenting. There's a gap between 35-50¢ in mid-phase where no rule reaches significance, and the bot is built to skip that gap rather than force a signal that isn't there.

That's the actual deliverable: a strategy_config.json with a direction.strategies[] array, each entry a phase/price-scoped rule with its own logic, no hardcoded strategy in the bot itself. Re-run the analysis, restart the bot, get new behavior - nothing to redeploy.

The bot side

Phase 2 loads that config and runs a ~5-second scan loop: find active markets, match phase+price to a strategy mode, pull the mode-specific signal (oracle diff or cheap-side book price), run an EV/sizing check, execute paper or live. Daily loss limits and max-position caps sit underneath all of it, independent of which strategy mode is active.

What this isn't

Worth being upfront about: this isn't a guaranteed-profit system, it's not real-time copy trading (it extracts rules, it doesn't mirror the wallet), and it's not a general ML platform - it's segmented statistical rule discovery. Fill history also isn't full intent - you see what someone traded, not what they considered and skipped. Historical validity isn't future validity either; paper trading before live is the whole point of the default config.

I build tooling like this for clients working on Polymarket - custom strategy extraction, market-making bots, or ongoing maintenance on an existing system. Full source, no black-box logic, paper-trading validation before anything goes live.

This reframes what actually matters in a well-built system. Detection is table stakes. Execution latency, order sizing against live depth, and how fast the bot can act on a signal it just generated are where real edge lives.

Most naive implementations separate detection and execution into sequential steps: poll the book, compute the gap, decide to trade, submit the order. Each step adds latency, and on a fast-closing arbitrage window, that sequential structure is the actual bottleneck, not the math. A more resilient structure treats depth-checking as inseparable from the trade decision itself, rather than a downstream validation step.

This matters more as more sophisticated capital enters prediction markets. Arbitrage opportunities aren't a fixed resource, they're a byproduct of market inefficiency, and more capital chasing the same gaps compresses both the size and duration of each window. Execution speed increasingly matters more than strategy novelty, which is a different competitive dynamic than most writeups about Polymarket arbitrage account for.

If you're building or evaluating a Polymarket arbitrage bot, the right question isn't whether it detects YES and NO mispricing. Every implementation does that. The right questions are how fast it goes from seeing the gap to submitting the order, how it sizes against real-time depth rather than a stale snapshot, and what it does when a partial fill leaves one leg exposed.

Full implementation, including the signal-scoring and execution logic across all five arbitrage and momentum strategies: github.com/casatrick/polymarket-arbitrage-bot-python

A Polymarket arbitrage bot scans prediction markets for pricing inefficiencies and executes trades to capture the resulting spread. That's the concept in one sentence, but arbitrage on Polymarket isn't one strategy, it's several distinct mechanisms, each exploiting a different kind of mispricing. Here's a breakdown of how each one works, based on an open-source implementation.

Intra-market arbitrage is the core mechanic. In a binary Polymarket market, YES and NO token prices should always sum to $1.00. When combined pricing falls below that after fees, buying both outcomes locks in a profit that doesn't depend on which outcome actually happens. Buy YES and NO, merge the tokens into a complete set, redeem for $1.00 per share. This is the closest thing to genuinely risk-free arbitrage available in prediction markets.

Combinatorial arbitrage extends the same logic to multi-outcome markets, like price-range or bracket-style markets with three or more possible outcomes. If all outcome prices sum to less than $1.00, buying every outcome and redeeming the complete set captures the deviation as guaranteed profit.

Cross-platform arbitrage is different. It compares Polymarket's implied probability against real-time spot prices from exchanges like Binance, and trades on the assumption that Polymarket's pricing will converge toward fair value. This is a directional, convergence bet rather than a locked-in profit, which makes it a fundamentally different risk category from the first two strategies.

Endgame arbitrage targets markets approaching resolution, where one outcome sometimes trades above 93% probability. Buying that outcome captures a small but near-certain return in a short, predictable window, capital-efficient specifically because time-to-resolution is short and the range of outcomes is narrow.

Momentum and mean-reversion is the one strategy here that isn't arbitrage in the strict sense. It applies standard technical indicators, Z-score, RSI, rate of change, VWAP divergence, to Polymarket's YES/NO price series across 5-minute, 15-minute, and 1-hour timeframes, the same toolkit used in equities and crypto momentum trading, adapted to prediction market price action.

Running five strategies in parallel means a single market can generate multiple competing signals simultaneously. A well-built bot scores every signal on a weighted composite, expected profit, confidence, strategy-type priority, urgency, and risk and reward ratio, then executes only the highest-ranked signals per cycle, weighting risk-free strategies like intra-market and combinatorial highest, and directional strategies like cross-platform and momentum lower by design.

Worth being precise on risk here. Not everything called Polymarket arbitrage carries the same risk profile. Intra-market and combinatorial arbitrage are structurally close to risk-free if executed correctly, since both outcomes are purchased for guaranteed redemption. Cross-platform and momentum strategies are directional bets that can lose money if the anticipated convergence or reversion doesn't happen. Treating all five as equally safe because they're grouped under one bot erases the actual distinction that makes the first two valuable in the first place.

Full strategy code and configuration reference: github.com/casatrick/polymarket-arbitrage-bot-python

The naive approach: fixed sizing

The simplest method is to size every position the same-a fixed dollar amount or a fixed percentage of your bankroll, regardless of how large the edge is. It’s easy to implement and easy to reason about. It’s also leaving money on the table on your best opportunities and overexposing you on your weakest ones, since a 2% edge and a 15% edge get treated identically.

Kelly Criterion: sizing by edge and odds

The Kelly Criterion sizes each bet as a function of your edge and the odds being offered, rather than treating every trade the same. The formula, adapted for a binary prediction market:

def kelly_fraction(my_prob, market_price):
"""
my_prob: your estimated probability of YES
market_price: current market price (implied probability)
Returns the fraction of bankroll to allocate
"""
b = (1 - market_price) / market_price # odds received
q = 1 - my_prob
f = my_prob - (q / b)
return max(f, 0) # never bet negative

In theory, full Kelly maximizes long-term bankroll growth. In practice, on prediction markets specifically, full Kelly is dangerous for a reason that doesn’t show up in the textbook version of the formula: your probability estimate has its own error bars, and Kelly sizing amplifies whatever confidence you feed it. If your model is even slightly overconfident, full Kelly will oversize positions and the variance will hurt more than the formula suggests.

What I actually run: fractional Kelly

In production, I size at roughly 25-50% of full Kelly, not full Kelly. This trades some theoretical growth rate for meaningfully lower variance
which matters more in practice than the math suggests, because your edge estimate is a model output, not a certainty. A half-Kelly position sized against a slightly wrong probability estimate is recoverable. A full-Kelly position sized against the same error can wipe out a disproportionate chunk of your bankroll on a single bad estimate.

def sized_position(my_prob, market_price, bankroll, kelly_multiplier=0.4):
full_kelly = kelly_fraction(my_prob, market_price)
fraction = full_kelly kelly_multiplier
return bankroll fraction


Where this connects to execution

This ties directly into the execution validation from my last post: your sizing calculation happens at decision time, using the book state at that moment. If the book drifts before your order lands, the sizing you calculated may no longer match the liquidity actually available at that price level. Worth checking that your position size doesn’t exceed what’s actually resting at your target price after your drift-tolerance check passes -otherwise you’re sized correctly for a book that no longer exists, which is the same underlying problem as the execution timing issue, just showing up in the sizing layer instead.

The practical takeaway

If you’re running a bot with a working edge calculation and proper execution validation but still seeing inconsistent results, sizing is the next place to look. Fixed sizing wastes your best opportunities. Full Kelly overexposes you to model error. Fractional Kelly, tuned conservatively, tends to be the more durable choice once you’re running real capital instead of backtests.

I build execution and risk infrastructure for prediction market bots and provably fair systems for casino platforms. If you’re working through sizing or risk logic on something similar, feel free to reach out.

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: fetch the orderbook, calculate implied probability from it, compare that against your model's own probability estimate, and if the edge clears a threshold, place an order sized to that 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 calculated edge was measured against a book state that may no longer exist by the time your order lands. 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. Right before placing the order, re-fetch the live orderbook, diff it against the snapshot you priced your edge against, and if the drift exceeds a set tolerance, skip the trade instead of executing blind. 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, either. 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, and if you're working on something similar and want a second opinion on your architecture, feel free to reach out.

The mistakes got more engagement than the wins. A post about my bot getting picked off on a low-liquidity market did better than any "here's my clean setup" post.

Rewriting the same core piece per platform, instead of copy-pasting it everywhere, made a real difference - even though it took more time than I wanted it to.

The casino-odds-vs-Polymarket-odds comparison worked well as a hook the first time I used it. I'm deliberately not reusing it as the default hook for every post, because it stops feeling like an insight and starts feeling like a formula.

Still don't fully know how much of this is genuine interest versus just posting consistently enough to get noticed. Not pretending to have a clean answer.

Polymarket splits its API into two services: the Gamma API for public, read-only market discovery, and the CLOB API for order books, prices, and trading. Reading market data requires no authentication; placing orders does.

The core workflow: discover a market and pull its order book, calculate your edge by comparing your model's probability against the market's implied probability, size the position using a fractional-Kelly approach capped by a hard maximum exposure per market, and check remaining order book depth before filling rather than chasing the price with a market order.

A few lessons that only became clear running this against real markets: poll less and cache more, since hammering the API on a flat interval wastes rate-limit budget you need when a market is actually moving. Log every trade your bot decided not to make, since that data set is what tells you whether your edge threshold is calibrated correctly. Treat correlated markets as a single combined position rather than independent bets. And treat any order book snapshot as already stale - a WebSocket feed beats polling for anything beyond casual use.
Full breakdown with working code: Github

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 games have a known, provable probability distribution. Risk management there is mostly bankroll sizing and variance control: Kelly criterion, stop-losses, volatility smoothing.

Polymarket doesn't work that way. Prices move the instant new information lands, because they represent live, collective beliefs, not a fixed distribution.

Four risks casino-style bots never model: no stable probability distribution, adverse selection from better-informed counterparties, market impact and slippage on thin order books, and correlated exposure across related real-world events.

What a Polymarket bot's risk logic actually needs: dynamic re-pricing triggers on new information, position sizing based on order book depth rather than flat bankroll percentage, adverse-selection detection through order flow monitoring, correlation-aware limits across linked markets, and asymmetric tail-risk weighting since payouts are binary.

A casino bot manages variance against a known distribution. A Polymarket bot manages exposure in a live, reflexive, information-driven market. Start your risk logic from market microstructure and information asymmetry, not from bankroll math borrowed from games of pure chance.

I spent a long time looking at price charts. Candlesticks, moving averages, support and resistance levels. The whole toolkit. It felt productive. It looked like analysis. It was mostly noise.

When I started building a market maker bot on Polymarket I had to stop looking at charts entirely. The bot does not care about price history. It cares about what is happening in the order book right now. That shift in focus changed how I think about markets completely.

A price chart tells you what already happened. The order book tells you what people are willing to do next. Those are completely different things. One is a record. The other is intent.

On Polymarket the order book is sparse compared to a crypto exchange. There are not thousands of market participants constantly posting and cancelling. There are a few. Sometimes very few. Which means when someone posts a large order on one side it is visible and it means something. You are not reading noise. You are reading a decision someone made with real money behind it.

The first thing I learned from watching the book closely is that spread tells you more than price. A wide spread means nobody is confident. A tight spread means someone knows something or is willing to take risk that others are not. On BTC 5 minute markets the spread at minute one versus minute four is completely different. Same market. Same underlying asset. Completely different book.

The second thing is that depth is a signal. When buy side depth builds up faster than sell side something is happening. The bot picks this up before any price movement is visible on a chart. By the time the chart shows a move the order book already showed the setup.

The third thing is that cancellations matter as much as orders. Someone posting and immediately pulling a large order is information. It means they changed their mind or they were testing liquidity. A book that keeps losing depth without fills is telling you something about where confidence is sitting.

None of this is visible on a price chart. All of it is visible in the order book if you are watching the right things.

I am not a quant. I did not come from finance. I came from software and casino game development. But building a bot that lives inside the order book forced me to understand markets at a level that years of chart watching never did.

If you are building anything on prediction markets start with the order book. Not the price. The book is where the actual information lives.
github.com/casatrick for the full explanation.

Binary prediction markets have a property most people ignore: YES + NO must equal $1.00 at settlement. One side pays $1.00 per share. The other pays $0.00. Doesn't matter which direction price goes.

So if you buy YES at 60¢ and NO at 32¢, combined cost is 92¢. At settlement you collect $1.00 on whichever side wins. You made 8¢ on a guaranteed basis. No directional bet.

That's the whole strategy. Buy both sides. Keep combined cost below $1.00. Hold to settlement.

The hard part isn't the concept. It's execution.

What their Trade Showed

After analyzing roughly 3,200 trades across 244 candles:

• Both sides bought on 94% of candles

• Median combined VWAP: $0.74

• Combined cost below $1.00 on 91% of candles

• Median clip size: ~15 shares

• ~68% of fills in the final 60 seconds

• Clip gap: ~3 seconds between trades

• Return on turnover: ~30.6%

The 3-second gap stood out. This isn't someone hammering the book. It's methodical accumulation - letting the market come to you, adding to whichever side gets cheaper, building toward a hedged position across the full candle.

How the Bot Works

Scans the CLOB every some miliseconds. When a signal fires, it clips. Fixed priority - first matching condition per tick wins.

Four clip types:

dip - first entry or cheap add when already hedged. Fires when cheaper side is at or below 55¢.

stack - adds to held leg while still one-sided. Same 55¢ cap.

late-tail - final 60 seconds, cheapest side at 32¢ or below. Convex upside if the underdog wins.

no-signal - nothing to do this tick.

Core discipline: once both legs exist, the combined VWAP guard is active. Bot won't add to either side if it pushes combined above $1.00. That guard is what keeps the locked spread positive.

The Fee Math Nobody Talks About

Polymarket crypto fee: Θ × shares × price × (1 - price), Θ = 0.07.

Fees are highest around 50¢. Lowest near 0¢ or 100¢.

Non-obvious implication: your cheapest clips near 30-35¢ also carry lower fees. Late-tail clips at 32¢ aren't just lottery tickets - they're the cleanest clips in fee terms. When they win, return is solid.

On top of that: redemption gas on Polygon. Small positions get disproportionately eaten. Anything below $8.00 effective position gets ugly after gas. Minimum position size is not optional.

What the Dashboard Shows

ARB combined - the number to watch. Below 1.00 means locked spread. Above 1.00 means you need price to move your way to recover.

Locked profit - matched pairs × (1 - combined). Guaranteed P&L assuming you hold to settlement. Goes up as you add hedged clips at good prices.

Arb-blocked clips - signals rejected by the combined-VWAP guard. High count means the market isn't giving you cheap prices on both sides. Good signal to skip the candle.

Candle win rate - % of candles with net positive P&L across all legs. More useful than clip win rate. A candle can have losing clips offset by a winning hedge.

What I'd Build independently

Settlement wait is the biggest friction. Gamma oracle takes at least 60 seconds after candle close. Capital locked during that window - not lost, but unavailable. In a high-frequency session this compounds fast.

Better approach: track oracle confirmation times historically, predict settlement duration per candle type, allocate capital accordingly instead of treating all settlements as identical wait times.

Maker/taker split also needs more work. Maker fills at bid+1¢ carry ~10% of taker fee. In a strategy where fee drag matters this much, posting more as maker and accepting slower fills could move the needle. Current version is mostly taker because the window is short. Worth testing properly.

Where This Fits

This isn't a direction bet. Not momentum, not mean reversion, not late-entry probability capture. Pure spread arbitrage on binary settlement mechanics.

The edge exists because 5-minute ETH candle order books aren't perfectly efficient. Prices drift. One side gets cheap while the other stays elevated. The bot exploits that drift across hundreds of candles.

Whether it stays exploitable depends on how many people run the same thing. For now, the math works.

My Another Strategies References: github.com/casatrick/polymarket-arbitrag-bot

The Polymarket CLOB API is surprisingly good for developers. It is well documented, free to use, and supports real limit orders on a proper order book. I built everything in Node.js, store all my trade data in MongoDB, and run the bot on a VPS with PM2 keeping it alive 24/7. Nothing fancy but it works.

What I learned most is that market making is not about predicting outcomes. You are not betting on YES or NO. You are just providing liquidity and getting paid the spread for doing it. On high volume markets during big events like elections or major news, the spreads widen and the opportunity gets better. On slow quiet markets, your orders just sit there and nothing happens.

I am still improving the bot every week. Better spread logic, smarter market selection, tighter risk controls. All my code is open source and available on my GitHub at github.com/casatrick if you want to follow along or build something yourself.

Ready for the third post anytime!

quick background since this is a first post: I'm a backend/systems engineer, been doing trading-adjacent and on-chain stuff for a while. shipped a prediction market protocol with pyth oracles a while back, built some on-chain agents with LLM intent parsing, worked on a low-latency trading terminal. this is the next thing in that line - a bot that trades polymarket, written in rust, that's been running for a few months now.

what it does, short version: connects to polymarket's websocket, keeps an order book in memory per market, runs a strategy against it, fires orders through their CLOB api. nothing fancy architecture-wise. channel-based, no shared state between tasks, feed task owns the websocket and does nothing else, strategy never touches the network directly. decision loop's around 800µs now. first version was python, 48ms. that gap is basically the whole reason this exists in rust.

why post this here specifically - prediction markets are weird right now. not quite defi, not quite tradfi, and most of what's out there is either toy examples or production stuff nobody talks about. figured I'd just be one of the people writing the real version in public instead of complaining there isn't more of it.

what I'll probably write about here:

the actual engineering stuff - order book, websocket reconnects, the time something broke and what I learned fixing it. I write some of this on substack and dev.to too but here I want to go deeper on the on-chain/oracle adjacent stuff specifically since that feels more relevant to whoever's reading this.

strategy comparisons, honestly written. been comparing momentum approaches, arb between polymarket and kalshi, convergence trades near resolution. most stuff treats these as the same thing. they're not, not even close, and it matters once you're dealing with real fills instead of a spreadsheet.

the unglamorous parts. capital sitting locked up, fees actually eating the edge, what happens when a resolution gets disputed, how much time this actually takes alongside a day job. the stuff that decides whether an edge is real or just looks real on paper.

not going to pretend this prints money because it doesn't, not really. modestly profitable after costs is the honest claim and that's a pretty different thing from what most trading bot content implies.

code's open if you want to look: github.com/casatrick/polymarket-trading-bot

more soon. if you're building anything near this - prediction markets, oracle stuff, on-chain agents - would genuinely like to hear about it.