Kakashi postmortem: the strategy worked, the exchange didn't
A Polymarket copy-trader on EC2 that mirrors high-conviction positions from top wallets. Paper trading validated it. Then an exchange-side CLOB order version mismatch rejected every live order.
A Polymarket copy-trading bot deployed to EC2. It tracks top wallets and mirrors high-conviction positions through a risk-gate stack.
Copy-trade flow
- Top-wallet tracker: Polymarket leaderboard and position ingest.
- Conviction filter: signal only when a bet is at least 10% of that wallet’s 7-day volume.
- Risk gate stack: confidence thresholds, exposure caps.
- CLOB execution: order placement against Polymarket’s book.
Postmortem
| Validated | Paper trading confirmed the copy-strategy edge end to end on EC2. |
| Blocked | An exchange-side CLOB order version mismatch rejected live orders. A bug on their end, not the strategy’s. |
| Status | Infrastructure intact and redeployable. Live trading waits on the exchange fix. |
From the original write-up (May 2026)
A multi-signal prediction market system with wallet intelligence and risk-gated CLOB execution. The core mission: identify mispriced prediction markets and execute with confidence-weighted position sizing and hard risk controls.
The signal pipeline
- Market inputs: ingests Kraken OHLCV, Polymarket order books, top-wallet on-chain activity, and macro/event context in real time via WebSocket.
- Feature layer: engineers signals: Bollinger Bands, RSI, momentum, token normalization, wallet conviction ranking, volatility, and edge calculations.
- Decision layer: routes signals across concurrent strategies (directional, market-making, wallet-following, arbitrage, event forecasting).
- Risk gate stack: validates confidence threshold, edge minimum, exposure cap, and position guards before any order is approved.
- Executor (CLOB): creates, routes, and posts orders with stateful retries and fill handling.
- Operator feedback: Discord alerts, process monitor, trade logs, win/loss dashboards, and analytics state via PostgreSQL.
Risk gate stack
Every order passes through a multi-layer gate before execution. If any layer fails, the order is blocked and logged. The system never silently skips a check.
| Layer | Component | Function |
|---|---|---|
| Layer 1 | Confidence threshold | Blocks any signal below 60% model confidence. |
| Layer 2 | Edge minimum | Requires at least 3% edge over market implied probability. |
| Layer 3 | Exposure cap | Hard cap on total portfolio exposure. No exceptions. |
| Layer 4 | Deduplication guard | Prevents double-entry on the same market across strategies. |
| Layer 5 | Inventory guard | Tracks open positions and blocks conflicting directional exposure. |
| Layer 6 | Timeout exit | Forces position closure if hold time exceeds configured maximum. |
Logic highlight: confidence-weighted sizing
Position size scales with signal confidence and edge. High-conviction signals get larger allocation; weak signals get minimum size or are blocked entirely.
def calculate_position_size(confidence: float, edge: float, portfolio: dict) -> float:
"""
Scales position size based on signal quality.
Never exceeds portfolio exposure cap regardless of confidence.
"""
base_size = portfolio["base_position_size"]
max_size = portfolio["max_position_size"]
quality_multiplier = (confidence - 0.60) * edge * 10
raw_size = base_size * (1 + quality_multiplier)
return min(raw_size, max_size)
Tech stack
- Execution: Polymarket CLOB API, Kraken WebSocket API.
- Orchestration: Python asyncio, multi-strategy concurrent runners.
- State management: Redis (real-time order book, deduplication), PostgreSQL (trade logs, analytics).
- Risk controls: custom risk gate engine with 6 validation layers.
- Infrastructure: Docker, environment-based config, unless-stopped restart policy.
- Observability: Discord webhooks (live alerts), structured logging, win/loss dashboards.
Need something like this?
Tell me what you do by hand today. I'll reply within two working days with whether I can help and what I'd build first.