In Part 1 I shared the technical challenges and initial solutions while forking the stack-x0 directional strategy.
After a week of live running (paper + small real capital), here’s what actually happened, what I improved, and the painful lessons learned.
Live Performance Snapshot (First 7 Days)
- Markets traded: ~1,200+ (mostly 5m BTC/ETH + some 15m)
- Win rate: ~58–62% (close to expected)
- Average notional per trade: ~$28
- Total PnL: Positive but modest (exact number not shared for obvious reasons)
- Max drawdown: -4.2% (survived comfortably)
The strategy printed steadily with a few red days. No blow-ups.
Key Optimizations I Made
1. Better Conviction Filter
Problem: Too many marginal 50–55¢ entries on weak signals led to unnecessary losses.
Solution:
- Added a combined signal: CEX lead strength + short-term momentum
- Only enter if signal score > threshold (tunable)
- Dynamic sizing: stronger signal → larger position (within $15–$60 range)
This improved win rate by ~4–5% in testing.
2. Smarter Caching & Refresh Strategy
Problem: Even with caching, some slots had stale data during high volatility.
Solution:
- Hybrid approach: aggressive WebSocket updates for active slots only
- Background refresh every 8–12 seconds for non-critical data
- Added staleness detection — skip trade if data is older than 3 seconds
Execution latency dropped noticeably.
3. Drawdown-Aware Position Sizing
Problem: Consecutive losses in volatile periods hurt more than expected.
Solution:
- Implemented a simple equity curve-based multiplier
- If daily PnL < -2%, reduce all position sizes by 30–50%
- Auto-pause new entries if drawdown hits -5%
This made the bot feel much more robust.
4. Redemption & Capital Efficiency
Problem: Capital was locked in many small winning positions waiting for manual resolution.
Solution:
- Fully automated redemption listener
- Batch redemptions every few minutes
- Added a small “sweep” job that redeems any resolved positions older than 30 minutes
Capital turnover improved significantly.
Hard Lessons Learned
Fees are everything
On thin edges (50–70¢ range), taker fees can eat most of the expected value if volume/rebates aren’t optimized. I had to adjust minimum edge after fees.Regime awareness matters
The strategy performs differently in low vs high volatility. I added basic vol filters (skip or reduce size in extreme regimes).Overlapping slots are dangerous
Without strict concurrent limits, exposure can spike quickly. I capped total active notional to 15–25% of account.Paper vs Real is still different
Even with good simulation, real slippage, partial fills, and network latency showed up. Always run small real size early.
Current Bot Architecture Highlights
- Language: TypeScript + Node.js
- Key libs: Polymarket SDK, WebSocket client, Redis for state
- Deployment: Small VPS with monitoring (Prometheus + Grafana)
- Safety layers: Multiple circuit breakers + daily PnL limits
The bot now runs mostly autonomously with daily manual review.
What’s Next
- Multi-asset weighting (more SOL/XRP when signals are strong)
- Basic ML for signal strength prediction (very light, just to test)
- Rebate optimization & volume tier climbing
- Open-sourcing a cleaned version of the core after more validation
This directional mid-slot style continues to feel durable. It’s not the flashiest bot on Polymarket, but it’s one that can keep running without constant babysitting.
If you’re building something similar, I’d love to hear what optimizations worked (or failed) for you.
Part 1: Building the Bot – Technical Challenges
If you have more questions, please feel free to contact me at any time: https://t.me/FatherSon97
Top comments (0)