Polybot

Venue lanes

The Polymarket lane is built as a full chain of market discovery, routing, context synthesis, bundle assembly, strategy evaluation, prefiltering, LLM validation, bot orchestration, and execution. In the runtime graph that shows up as indexer -> router -> correlation -> poly_signal_bundle -> poly_strategy_runner -> poly_prefilter -> poly_llm_arbiter -> bot -> trading.

The MT5 lane mirrors that discipline with its own venue-native flow: mt5 -> mt5_ingest -> mt5_signal_bundle -> mt5_strategy_runner -> mt5_prefilter -> mt5_llm_arbiter -> mt5_execution, with mt5_risk_manager running alongside execution to manage open-ticket exposure and venue risk.

The bundle

The interesting part is the bundle layer. Polybot does not trade from one signal source. It builds a richer packet that combines venue-native state with external evidence:

• News from Google News, Finnhub, SEC EDGAR, Yahoo Finance, Newsfilter, and RSS
• Social context from X/Twitter, Reddit, and StockTwits
• Market structure and technical context from rates, spreads, OHLCV-derived indicators, and multi-timeframe signals
• Whale, orderbook, and realtime context on the Polymarket side
• Driver decomposition, calendar events, and feed-health context on the MT5 side

That means a surfaced idea is not just "price moved" or "Twitter is loud". It is a synthesized bundle of market state, headlines, social discussion, technicals, and venue-specific metadata.

Strategies, arbiter, and execution

Polybot runs strategy modules before it ever asks for execution. On the Polymarket side that includes modules such as barbell, divergence, public-data arbitrage, frenzy fade, limit patience, safe-zone yield, lottery guardrails, and rules-based arbitrage. On the MT5 side the stack includes trend, trend-strength, mean reversion, news spike, and BTC technical strategies.

Those strategy outputs do not place trades directly. They feed a prefilter plus an LLM arbiter that validates entity relevance, sentiment, directional agreement, uncertainty, and risk flags before recommending whether a signal should be surfaced or dropped. The arbiter is backed by Gemini with OpenRouter fallback, and it also emits richer operator guidance such as side selection, intent advice, confidence decomposition, and sizing hints.

Memory, telemetry, and operator control

A big part of the system is what happens after a decision. Polybot keeps venue-aware learning memory with case ledgers, immutable facts, retrieval traces, enforcement records, and cross-venue memory-health views. That gives the arbiter a compact memory capsule so it can reason about whether similar setups worked before and whether past mistakes should suppress or reshape a trade.

Execution is profile-scoped and can run in approval-required or autonomous mode. Telegram, dashboard APIs, the CLI, and the daemon all sit on top of the same state model so approvals, positions, bankroll tracking, and runtime settings stay synchronized.

Under the hood, state_store.db and events.db act as the operational spine for positions, approvals, bankroll, profiles, and telemetry. Heartbeats, health checks, and watchdog-style monitoring loops keep the graph observable, which is what makes Polybot feel less like a script and more like an operating system for multi-venue trading.

Technical stack

Yes, ZeroMQ is part of the stack, and it is important to how Polybot feels live. The system uses a ZeroMQ IPC event bus for sub-millisecond service-to-service delivery, with the daemon persisting those events into SQLite and the dashboard subscribing to the event stream before fanning it out over WebSockets to the browser.

The practical stack is Python, aiohttp, ZeroMQ, SQLite, orjson, WebSockets, Gemini/OpenRouter, Telegram, Polymarket APIs, and the MetaTrader 5 bridge, with a React dashboard on top of the runtime.