Six weeks ago our automated trading system was executing orders on Polymarket with roughly 300ms of latency on every single trade. Last week we got that down to 1.16ms.

That's not a typo. 258 times faster. And it changed how we think about where infrastructure actually matters.

Here's the full story.

**Why we were at 300ms in the first place**

Polymarket is a US-based platform and geoblocks certain regions. Our server was sitting in a data center in France cheap, powerful, reliable but completely blocked by Polymarket's infrastructure.

The workaround we were running for months: route every single API call through a SOCKS5 proxy server we operate in São Paulo, Brazil. The trade execution path looked like this:

    France server → São Paulo proxy → Polymarket (US)

Every order, every market data request, every position check all of it bouncing across the Atlantic twice. The 300ms wasn't our server being slow. It was physics. Speed of light across that distance, twice, adds up fast.

It worked. But it was fragile, added cost, and 300ms is a long time when you're trading 5-minute binary markets.

**Why Dublin**

Ireland isn't geoblocked by Polymarket. Simple as that. AWS has a full region there (eu-west-1) and the round-trip to Polymarket's infrastructure from Dublin is under 2ms on a good day.

The new path:

    Dublin server → Polymarket (direct)

No proxy. No transatlantic bounce. Just a clean connection from a data center that's geographically and legally in the clear.

**The migration itself was messier than expected**

Moving a live trading system with real capital in it is not something you do casually. A few things we had to solve:

The old server runs our web gateway, database connections, and user-facing API none of that moved. Only the trading engine moved. So we needed the two servers to communicate reliably. We set up a WireGuard tunnel between Dublin and France. Latency on that tunnel: 24ms. That's the new overhead the old overhead was \~280ms of proxy routing.

We also discovered our systemd service configuration had a dependency declaration that kept trying to start the old engine locally even after we stopped it. Every time we restarted the web server, it would silently spin up the France engine in the background. Took about an hour to track down and kill cleanly with a systemd override.

The actual cutover took about 60 seconds of downtime. We stopped the France engine, did a final data sync, started Dublin, confirmed the tunnel was live, and flipped the gateway config.

**What 1.16ms actually buys you**

In prediction markets specifically, this matters more than in traditional markets. Here's why:

Polymarket's 5-minute binary contracts move fast. The "edge" in these markets the gap between where the odds are priced and where they should be can be 3-10%. But that edge exists for seconds, not minutes. If your order arrives 300ms after you detected the opportunity, the book has already moved.

At 1.16ms, you're executing so close to real-time that the price you analyzed is almost certainly still the price you get. The strategy hasn't changed. The logic hasn't changed. The same signal fires the same trade. But the fill quality is fundamentally different.

We also did some analysis on our historical trades. Filtering execution to active market hours and having clean latency contributed to our win rate improving from 52.3% to 58.3% on the same strategy, same parameters. We can't isolate exactly how much of that is latency vs other changes we made simultaneously, but the correlation is real.

**What we didn't expect to break**

The proxy server in São Paulo is still running. We can't turn it off yet because there's a dormant per-user execution path in the codebase that still references it. Cleaning that up is on the list but it's not urgent it's not active, just present.

The bigger surprise was realizing how much mental overhead the proxy added. Every time something was slow or an order failed, the first question was always "is this the proxy?" Now that question doesn't exist. When something breaks, you're debugging actual trading logic, not network infrastructure.

**The cost math**

France server: \~$10/month São Paulo proxy: \~$5/month (still running, will eventually go away) Dublin t3.small: \~$15/month

We added $15/month to the infra bill and got 258x better execution latency. That math is not hard.

Happy to answer questions about the WireGuard setup, the systemd debugging, or the Polymarket geoblocking situation in general. The latency improvement was the headline but the migration itself had enough interesting failure modes to be worth talking about.

We moved our trading server from France to Dublin and execution latency dropped 258x. Here's what that actually means for prediction market trading.