The Reality of Bots on Polymarket

The Reality of Bots on Polymarket

A practical note on states, fills, workers, and why bots are infrastructure rather than automatic edge.

The popular version of bot building is "write a signal, call the API, make money." The real version is slower and more technical. You spend most of your time on state reconciliation, execution discipline, failure recovery, and deciding which code is allowed to block.

That was one of the clearest lessons from the Polymarket work. The useful part was not discovering a magic strategy. It was learning what a bot has to become before it deserves to trade real money.

The signal is only one component in a live system.

A production-minded bot has to:

• read market data continuously,
• maintain explicit states,
• distinguish open orders from filled inventory,
• react to fills from WebSockets instead of assuming intent equals execution,
• recover from partial fills, stale acknowledgements, and local or exchange disagreement.

In the 15-minute system that meant keeping FLAT, ENTRY_WORKING, OPEN, and EXITING synchronized with actual exchange events, not with the branch of code that wanted something to happen.

The HFT branch made this separation more explicit.

The hot loop listened, updated state, built features, and decided. The blocking API work was pushed into a queue-backed worker so order placement could happen outside the critical path. That is a small architectural idea with huge operational consequences:

• the decision loop stays responsive,
• API jitter does not freeze the market loop,
• failures become easier to isolate,
• latency budgets stop being destroyed by avoidable blocking calls.

This is also why the project evolved toward Rust on the hot path and Python for orchestration, ETL, and ML. The split was not aesthetic. It matched the runtime constraints.

Real bots need guardrails before they need ambition.

Some of the practical rails in the project were simple but important:

• price safety bands such as 0.10 to 0.90,
• pre-flight connectivity checks before enabling live actions,
• circuit-breaker style logic when latency or state quality degraded,
• minimum size rules in the 15-minute system,
• explicit cancellation and reconciliation instead of assuming clean exits.

None of this looks glamorous in a screenshot. All of it matters more than a clever tweet-sized entry rule.

One of the healthiest resets came from comparing research metrics with executable outcomes.

In the HFT stack, an adverse-selection classifier could look strong on standard ML metrics while still failing to produce attractive maker-style PnL once latency, queue position, and actual fills were considered. That gap is exactly why bot building has to be described as systems engineering, not just model building.

The same pattern appeared in the 15-minute work. Once fees, slippage, and live timing were included honestly, the market looked much closer to efficient than early backtests suggested.

Bots are still extremely valuable when they sit on top of a real edge or a disciplined research process.

• They enforce repeatability.
• They capture detailed logs.
• They expose hidden assumptions quickly.
• They let you test operational hypotheses that manual trading never tests well.

What they do not do is create edge just because they are automated.

The strongest takeaway from Polymarket was not "bots work" or "bots do not work." It was that a serious bot is an execution system with data plumbing, state discipline, and risk controls attached. If the underlying edge is weak, the bot will reveal that faster. If the process is strong, the bot makes it measurable.