Casatrick

Follow-up to my post on why Polymarket is moving crypto market settlement to TWAP starting August 7 - this one's the actual implementation.

Chainlink doesn't publish the exact sampling boundaries or weighting methodology for the custom TWAP feed, so you can't independently derive the resolution price from scratch. What you can do: store every raw tick you observe (not pre-averaged data), compute your own TWAP over the same window Polymarket uses, and reconcile it against the published resolution price with a defined drift tolerance.

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, not after.

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

For months, these fast crypto up/down markets on Polymarket resolved on a single price snapshot at the exact expiry second. That's a bigger problem than it sounds: if you can nudge the price for even one instant, you can flip the outcome, regardless of what the asset was actually doing the rest of the time. Reports tie roughly $7.6M in losses to exactly this kind of manipulation.

Starting August 7, that changes. Resolution moves to a time-weighted average price (TWAP) - a 30-60 second window depending on the market's length - so a brief spike can no longer decide a multi-million dollar market. Moving a TWAP means sustaining a price move the whole window, while other traders can (and will) trade against you the entire time. Much higher cost, much higher risk, much lower payoff.

been messing with an idea from futures trading - checking three timeframes agree before trusting a signal (slow trend, medium momentum, fast timing) - and seeing what survives when you try to use it on Polymarket's BTC markets instead.

short answer: most of it doesn't. futures strategies assume you're holding one position you can adjust for hours. Polymarket's Up/Down markets just resolve and close on a timer, so all the trailing-stop/DCA stuff has nowhere to go.

but the actual "do these three timeframes agree" check? that part works fine as a signal. wrote up how here: [substack link]

A prediction-market price isn't a price. It's a probability the crowd agreed on a moment ago. The second real news arrives, that number is stale - for the few minutes it takes everyone else to finish the same math a bot can run in milliseconds.

The formula is Bayes' theorem, written in 1763. Quant desks use the odds form:

posterior odds = prior odds × likelihood ratio

Example: market at 30¢, likelihood ratio of 3 (news three times more consistent with the outcome happening) → 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.

Four steps to turn this into a bot: let the market price be your prior, price the evidence not the emotion, only trade a real gap after fees, and respect that the edge decays fast as the crowd catches up.

every trade on there is public - wallet address, what they bought, price, size, when. so I grabbed one wallet's entire history (65,000+ trades, no I did not enjoy the API pagination) and tried to figure out: what's this person's actual strategy.

turns out they don't have one strategy. they have two, and it took segmenting the data by price and how close the market was to closing to even see it:

late in the market, cheap tokens (under 35¢) → they just buy the cheap side. wins like 1 in 5 times. but the payoff is big enough that it's still profitable overall. basically a structured lottery ticket.

anytime, price 50¢+ → they follow the actual crypto price oracle. wins ~78% of the time, smaller payout each time.

two totally different behaviors, same wallet, invisible until you split the data the right way.

ok so every explanation of Polymarket arbitrage sounds the same: YES + NO prices should add up to $1.00, when they don't, buy both sides, redeem the gap. simple, correct, and also kind of beside the point

because that gap isn't a secret. every bot scanning the order book sees it at basically the same moment you do. detection was never the hard problem

the hard problem is the 2-3 seconds after you see it. the first execution to actually hit the book starts eating the exact liquidity the gap depended on existing. miss that window and you're not doing arbitrage anymore, you're just handing free money to whoever got there first

most naive bots go: poll the book → compute the gap → decide → submit order, as separate sequential steps. each one adds latency, and on a window that closes in a few seconds, THAT sequence is the actual bottleneck, not the math behind the strategy

better approach: checking whether there's enough depth to fill has to happen inline with the decision to trade, not as a separate validation step afterward. by the time you check separately, the liquidity might already be gone

also worth saying: this only gets harder over time. arbitrage windows aren't some fixed resource sitting there waiting, more capital chasing the same gaps means smaller, faster-closing windows. execution speed matters more than strategy cleverness at this point, which most writeups don't really talk about

if you're looking into a Polymarket arbitrage bot, the right question isn't "can it find mispricing," literally all of them can. it's how fast it goes from seeing the signal to submitting the order, and whether it's checking real-time depth or a stale snapshot

Most trading bot writeups cover the edge calculation and stop there. Position sizing is what actually determines whether a real edge turns into real returns.

Fixed sizing treats every trade the same regardless of edge size. Full Kelly sizes proportional to edge - but it also amplifies your model's own error if your probability estimate is even slightly overconfident.

What I run in production: fractional Kelly, around 25-50% of full Kelly. Trades some theoretical growth rate for meaningfully lower variance, which matters more in practice than the textbook formula suggests.

Most discussion around trading bots centers on the pricing model - signal quality, edge calculation. Less discussed: execution latency on thin-liquidity markets.

Core issue - on shallow-depth markets, the orderbook can shift meaningfully between when you poll it and when your order lands. One order can eat the liquidity you priced against, and you execute at a price your model never evaluated.

Fix: validation step right before submission - re-pull the live book, diff against your pricing snapshot, abort or resize if drift exceeds tolerance. Small addition, protects the edge you actually calculated.

ok so most people's first Polymarket bot just fires a market order and calls it done, and that works fine on big liquid markets like elections but falls apart on Polymarket's thousands of long-tail markets with thin books and wide spreads

a naive market order on one of those can fill 5-10 cents away from the price you saw a second ago, which for a binary contract priced in cents is a huge effective cost

so what actually needs to happen: pull the order book before sizing anything, compare your model's probability against the market's implied probability to find your actual edge, size the position with a fractional-Kelly approach capped by a hard max-exposure-per-market limit, and check remaining depth before you fill instead of chasing with a market order

lessons learned after running this against real markets: poll less and cache more, log every trade you decided NOT to make (that's the data that tells you if your edge threshold is calibrated), and treat correlated markets as one combined position instead of separate bets

ok so, Polymarket bots and casino bots are NOT the same species and I think people keep building them like they are

casino: the odds don't care about you. spin the wheel, math is fixed.

Polymarket: the price moves because YOU traded, and because everyone else's beliefs are shifting in real time.

that's a completely different risk problem. breaking it down:

casino risk = bankroll sizing plus variance control, because the odds are fixed and known ahead of time

Polymarket risk = market impact, adverse selection, and correlated event exposure, because the price is reflexive and moves based on real world beliefs and information

so if your Polymarket bot's risk logic is just borrowed from a casino betting bot, it's probably underpricing tail risk without you realizing it

what actually works instead: size positions based on order book depth, watch for sudden directional flow that might mean someone knows more than you, cap exposure across markets tied to the same event, and weight downside risk more heavily since payouts are binary

the order book is basically empty for the first 2 minutes of a 5 minute BTC market

then the last 3 minutes happen and suddenly everyone shows up at once

my bot just sits there waiting. then moves fast when the window opens.

took me weeks of log data to figure out why my fill rate was low. it was not the price. it was the timing.

that is the whole post. that is the thing.

here's what i'm building: → market maker bots → trading automation tools → polymarket API integrations

you can check also strategies github: github.com/casatrick/polymarket-arbitrage-bot

so i've been deep in the polymarket rabbit hole for the past few weeks

for context: polymarket is a prediction market where you bet on real world events using USDC. binary markets have YES and NO tokens. in theory, YES + NO should always equal $1.00. when they don't — that's an arbitrage opportunity.

the strategy sounds dead simple:P(YES) = 0.47 P(NO) = 0.49 sum = 0.96 ← buy both, merge, redeem for $1.00, profit $0.04

buy both sides simultaneously → merge tokens into a complete set → redeem for exactly $1.00 → repeat

i built a bot to do this. python, polymarket's CLOB api, websocket for live prices.

but here's the thing nobody tells you:

polymarket runs on a Central Limit Order Book, not an AMM. the spread you see when your signal fires is not the spread you'll actually fill at. by the time both your orders land, another bot has already moved the price.

i know this because i watched it happen to someone else's bot in real time.

the accounts

polymarket profiles are fully public. position data, prediction counts, P&L - all visible. i started looking at accounts with suspicious trade volumes (thousands of predictions, not hundreds) and reverse engineering their strategies from the positions alone.

@first - 19,923 predictions since october 2025. still running. all in the "bitcoin up or down - 5 minute" markets, all single-sided bets (up or down, not both). this isn't arb. this is a momentum bot reading btc price direction. it's been alive for 8 months which is actually the most impressive thing about it - pure arb bots die faster when competition compresses the spread.

@second- 16,454 predictions since april 2026. current positions: zero. portfolio value: zero. this one ran the merge/redeem arb at scale and then fully exited when the edge dried up. 16k trades in ~2 months is a bot that ran hard and knew when to stop.

@third- brand new account, june 2026, 4,170 predictions. and today i could see this in their open positions:market: Bitcoin Up or Down - June 29, 2:45AM-2:50AM ET Down 43.4¢ × 625 shares → $309 (+$38) Up 59.1¢ × 596 shares → $301 (-$51)

both sides. same market. same 5 minute window.

that's the arb mid-execution. entry was when the combined price was below $1.00. but:43.4 + 59.1 = 102.5¢

it's underwater right now. one leg filled late, price moved, now it's sitting there waiting for the market to resolve so it can merge and redeem.

this is execution slippage. not in a backtest. in a live account i watched today.

what i actually learned

the arb math is trivial. anyone can write if YES + NO < 1.00: trade in ten minutes.

the hard part is the 200 milliseconds between your first order filling and your second order filling. that's the entire game. that's the moat. not the strategy - the infrastructure.

also: every bot is in the 5-minute BTC markets. every single one. if you're building something new, go look at the multi-outcome markets or longer resolution windows. less competition, wider spreads, slower bots can actually make money there.

the bot

i open sourced the whole thing: github.com/casatrick/polymarket-arbitrage-bot

five strategies:

intra-market merge/redeem (the core)

combinatorial arb (3+ outcome markets)

cross-platform arb (vs binance spot prices)

endgame arb (93%+ probability markets near resolution)

momentum/mean-reversion on the 5m btc feed

signal ranker picks the best trade each cycle. intra-market arb always wins priority because it's the closest thing to risk-free on-chain.

not financial advice. you can definitely lose money. polymarket can be illiquid. these are public profiles and the strategy analysis is inferred, not confirmed.

but if you're into this stuff and want to talk execution latency or CLOB mechanics drop something in the notes

My trading bot didn’t fail - it drifted away from reality

At first, everything looked correct.

The system was running. Trades were executing. Logs were clean. No errors. No crashes.

From the outside, it looked like a working trading bot.

But inside the system, something much worse was happening.

It wasn’t failing.

It was slowly becoming wrong.

There was no moment of failure.

Most software breaks loudly.

This didn’t.

There was no crash. No exception. No system outage. No obvious bug.

Instead, the system kept running while slowly diverging from reality.

That’s the most dangerous kind of failure.

The bot believed things that were no longer true.

Over time, the system started assuming:

positions were closed when they weren’t

trades had executed when they were only partially filled

wallet activity was fully captured when it wasn’t

market state was accurate when it was stale

Nothing looked wrong in isolation.

But the global state was incorrect.

The real problem was not logic.

The trading logic was fine. The execution flow was fine. The architecture was fine.

But the system had one fatal assumption:

It trusted its own memory more than external reality.

Reality is not continuous - it is fragmented.

In theory, the system received:

WebSocket updates

API responses

execution confirmations

In practice, it received:

delayed messages

missing events

duplicated updates

partial execution results

Reality arrived in pieces.

The system assembled the wrong picture.

The drift started small.

At first:

a single missing event

a slightly delayed update

a small mismatch in position tracking

Nothing critical.

But these small inconsistencies stacked over time.

Like a compass slowly rotating away from north.

You don’t notice it immediately.

You just end up somewhere else entirely.

The hardest part: nothing looked broken.

This is what made it dangerous.

No alerts. No crashes. No visible corruption.

Everything looked “healthy”.

But the bot was no longer aligned with the market.

It was trading a version of reality that no longer existed.

The system was optimizing the wrong world.

At one point, I realized something uncomfortable:

The bot was making decisions that were correct based on incorrect state.

So even when it “worked”, it was wrong.

That is the worst possible outcome in a trading system.

The real failure was state consistency.

Not strategy. Not execution speed. Not APIs.

It was this:

The system had no single source of truth.

The system didn’t break.

Detection lag went from 14.8 seconds to 310ms. That's a 48× improvement.

But win rate dropped 2 points.

Turns out speed and signal quality are completely separate problems. Getting faster just means you lose money faster if your signals aren't good enough.

Full breakdown on what changed, what didn't, and what I'm fixing next: https://dev.to/casatrick/adding-real-time-websocket-prices-to-my-polymarket-rust-bot