Polybot is my most complex technical undertaking.

I will dive into the specifics behind the latency, systems and data engineering approach as a whole - this blog post will discuss the engineering rather than the monetary status. My strategy/approach to these markets is proprietary, and therefore I will not get into it.

A big battle I have dealt with and continue to deal with is latency engineering and optimisation. I was naive to think when I undertook this system that building in Rust would be enough to combat a lot of the latency issues other bots on the network deal with. I have made great progress on this front through kernel scheduling, keeping a warm connection and logging every single element of the order path to isolate any bottlenecks, including a slight amendment to the SDK code my system uses to track latency for the full round-trip order path where possible. Dublin -> London ping is roughly 10ms, and my maker post bids sit right around the 20-30ms mark round trip (so about as low as possible) on the low end, with an occasional tail spike which I am actively monitoring day to day, with the goal to reduce that down to p99 on the latency numbers. As mentioned, this entire element of the system is a work in progress and something I actively monitor. I also have the option to geolocate to Polymarket infrastructure through KYC application; however, currently Dublin to London has not been a bottleneck for the system and, with ambiguity around price and geographic restrictions on prediction markets, I have currently decided against it.

The part that I'm most proud of is the systems engineering of the bot. All key components are separated, with a coherent architectural design that has allowed expansion when it has been called upon, including daemons in the form of signal-instructed watchers, self-optimising scoring algorithms based on real-time market data and a full data ingestion pipeline including a simulator for testing different strategies against real market conditions. Strict Rust protocol rules were set out from the start and followed throughout, as stated explicitly below:

Non-Negotiable: After every module and before every phase transition:

  • cargo fmt --check passes
  • cargo clippy -- -D warnings passes with zero warnings
  • cargo test passes with zero failures
  • Zero .unwrap() in production code; .expect() with message permitted in init-only paths
  • Zero panic! in production paths
  • Zero String errors — all errors are BotError variants
  • Every public function has at least one test
  • No TODO, FIXME, or HACK left in code
  • No #[allow(unused)] or #[allow(dead_code)]
  • Ask yourself: would a staff engineer approve this in review? If the answer is anything other than yes, fix it now.

Rust Rules

  • All errors use the BotError enum. Add variants as needed, never stringify.
  • No floating-point == comparisons. Use >, < with epsilon, or MicroPrice integer representation.
  • All matches on enums are exhaustive. No wildcard _ on state machine or gate results.
  • No unsafe unless required for FFI (unlikely). Each block gets a // SAFETY: proof.
  • No pub on items that don't need it. Minimise API surface.
  • Functions over 40 lines get broken up. Each function does one thing.
  • Comments explain why, not what.
  • Pin exact dependency versions in Cargo.toml.

A system that touches real capital must be strict in regard to what is acceptable, and in a system that is pushing 100k lines (including data analysis scripts etc.), lack of diligence compounds in a way that makes life harder in the long run.

Finally, the data engineering that has driven this system from start to finish has been instrumental in deriving ideas and stress-testing strategies. A walk-forward approach has been taken when it comes to backtesting, with a focus on granularity of data. Early on, I was burned taking alpha from a data set that didn't have the correct granularity to warrant decision-making, and real capital was lost because of this; however, learning valuable lessons is worth the cost. Since then it has been paramount to treat a data set only as authoritative if it matches real market conditions AND if we are deriving the thesis based on walking through the data from the start to the finish. Anyone can engineer profitability if the data is tested to produce positive figures; profitability must be proven under strict and stringent conditions.

Alongside the philosophy that drove the data analysis, I also developed my understanding of Python as a tool. I see Python as more of a tool for research and analysis due to its rich libraries, but for me that's where its utility ends. I chose Rust for the system because Python's built-in garbage collection and automatic memory allocation make it unsuitable as the primary driver for complex multi-threaded systems like this one. Python still has its place, and for data engineering and analysis it is probably the best language out there.

Polybot was another system where the majority of the syntax was implemented via AI tools such as Claude Code, including my own Cortex system, further proving that AI is more than capable of being steered in the right direction under strict direction and guardrails to produce highly complex systems.

I anticipate prediction markets becoming much larger than they are now with the projected growth exploding between now and 2030. Polybot creates a rock-solid foundation to be expanded on in future as more markets become available and my system can cover more ground also. I plan to continue development, monitoring and optimisation for the foreseeable future.

It is mainly a work in progress, with a strong foundation that proves systems-level competence.