| Youtube | https://www.youtube.com/@casatrick |
| Medium | https://casatrick.medium.com/ |
| Dev.to | https://dev.to/casatrick |
CW: prediction markets / algo trading
Late-entry bot for Polymarket BTC markets. With 45s left and YES at 0.88, the market still prices in 12% reversal chance. Often mispriced.
Enters only when:
- YES prob > 85%
- Spread < 2%
- Slippage avg < 3%
Fees eat ~2%/trade. At 3% slippage, edge is gone entirely.
Paper trading + backtest before real capital. Always.
github.com/casatrick/polymarket-trading-bot
#polymarket #algotrading #buildinpublic
.
Spent some time this week improving reliability on my Polymarket bot.
No new features.
No strategy changes.
Just better monitoring, connection recovery, and a lot more logging.
Not the most exciting commits, but probably the ones that matter most once something runs 24/7.
Polymarket trading bot in Rust, 6 months in:
~800µs decision loop on a $20 VPS
- ws parse: 12µs
- order book delta update: 4µs
- strategy: 18µs
- REST order: 620µs (always the bottleneck)
python was 48ms. 60x improvement, zero GC pauses.
lesson that cost me 2 weeks: never hold tokio::Mutex across .await. pass ownership through channels.
also: never f64 for prices. rust_decimal.
github.com/casatrick/polymarket-trading-bot
Built a Polymarket trading bot in Rust.
The honest version: the borrow checker fought me for two weeks. The result: 800μs decision loop, no GC pauses, zero data races caught at compile time.
Worth it? For latency-sensitive work, yes.
Full writeup: https://dev.to/casatrick/building-a-low-latency-trading-bot-in-rust-from-48ms-to-800us-4n1i
Replaced 30s polling with WebSocket in my Polymarket
trading bot.
Detection lag: 14.8s → 310ms (48× faster)
False positives: 38% → 11%
Win rate: 73% → 71% ↓
Faster detection found signals that weren't real -
single large orders that mean-revert in <500ms.
My thresholds were calibrated for stale data.
Speed and signal quality are completely separate
problems.
Spent some time cleaning up my Polymarket bot today.
One thing I've noticed is that a lot of complexity comes from trying to keep API usage under control rather than making requests faster.
A WebSocket feed + a decent local cache solves way more problems than another round of optimization on the REST side.
Wish I had realized that sooner.
