Where Are Polymarket's Servers? London, Latency & Geo-Blocks

Polymarket’s documentation lists its primary servers in eu-west-2, the London region, and eu-west-1 as the closest non-georestricted region.

Which AWS region hosts Polymarket’s CLOB?

The published region codes correspond to London for eu-west-2 and Ireland for eu-west-1. London is an infrastructure fact, not a hosting recommendation here. Geographic restrictions and physical-location eligibility still apply to trading access.

API endpoints and streaming connections

Matching takes place off-chain and settlement exchanges pUSD and outcome tokens on Polygon. A response from a REST endpoint measures that request’s path, not the complete time to obtain a fill. Discovery, matching, streaming and settlement should be measured separately.

Geographic restrictions and eligibility

The current restrictions distinguish fully blocked regions, regulatory close-only regions and frontend-only close-only regions. Ireland is frontend close-only while its API is not restricted in the published table; the United Kingdom is close-only on both interfaces. These interface distinctions are not permission to change a trader’s stated location.

The geographic check is available at https://polymarket.com/api/geoblock. Its result describes the requesting IP; it does not establish the operator’s physical eligibility. Read the official geographic restrictions for the current country and region classifications. U.S. traders use a separate, CFTC-regulated exchange with its own API, covered in our Polymarket US API and geoblock check guide.

Dublin for latency

Dublin is the closest non-georestricted region to Polymarket’s London servers. QuantVPS reports under 1ms latency for its Dublin offering; actual application latency also depends on routing, data processing and the measured endpoint. Compare the Dublin VPS option for hosting a Polymarket bot.

Polymarket decides eligibility by your physical location. Check that you're allowed to trade where you are. Check Polymarket’s geographic restrictions.

Measure the complete execution path

Measure DNS and connection setup, request round trips, stream update age and order acknowledgement separately. Retain timestamped samples over several sessions rather than claiming a universal value from a single request. Connection reuse and application processing can matter alongside distance. For what those delays cost in practice, see how latency affects Polymarket bots.

Do not compare locations using an unsupported table of fixed ping values. A host advertised near an infrastructure region does not establish queue priority, a guaranteed fill or a measured profit improvement. Reconcile fills and outstanding orders after any outage.

Test an endpoint rather than assuming an origin ping

A domain's network response and a completed API request measure different things. An edge service can terminate a connection before the request reaches the relevant application. Timing a public book request therefore gives more useful application evidence than presenting a simple ping as the matching engine's latency. Even that request does not measure the time to fill an order.

Use the same endpoint, market and connection policy for every candidate host. Keep the response status and body-validity check beside the elapsed time. An error page that arrives quickly should not be included as a successful book measurement. Separate the first connection from later requests that reuse an established session.

Sample across several sessions and include slower observations, not only the lowest value. A hypothetical host with a lower median but repeated stalls may be less useful for a workload than one with more consistent responses. Report the endpoint and test conditions alongside any measured result so the comparison can be repeated.

Reference feeds and the RTDS migration

The current real-time data guide points existing RTDS integrations to PolyBolt. Its current reference-price socket is wss://ws-live-v2.polymarket.com/ws and reference-price subscriptions require authentication. An older RTDS URL should not be treated as the current endpoint simply because it appears in an old example.

Keep reference prices separate from prediction-market books. A crypto reference update does not establish an executable outcome-token price. When moving an existing integration, review the authentication, subscription and snapshot flow rather than replacing only the hostname. Test the change in a read-only monitor before it affects a live decision process.

Rate limits and recovery

The current endpoint table gives CLOB /book 1,500 requests per ten seconds and Gamma /markets 300 per ten seconds. Order submission has its own endpoint limits and separate signer budgets. Cloudflare throttling can delay requests, so a queued response should not be mistaken for a live market snapshot.

Observe remaining-budget and tier headers, back off after a limit response and rebuild state after reconnecting. Current SDKs support public data and secure trading separately. Older claims of a universal 100-requests-per-minute limit do not describe the documented endpoint table.

For strategy and paper-trading context, see automated trading on Polymarket.

Plan for process and connection failures

Keep a timestamped health record for discovery, books and account reconciliation. A successful Gamma request does not show that the market stream or authenticated order path is healthy. On reconnect, obtain a fresh state and confirm outstanding orders before continuing. Reserve request capacity for recovery instead of consuming it entirely with new signals.

The Polymarket setup guide explains the implementation and paper testing. An algo VPS provides a host for a continuously running workload. Choose resources around measured processing, logging and recovery needs.

Comparing London, Dublin and Amsterdam

London is the documented primary region, while Dublin corresponds to the closest non-georestricted region listed by Polymarket. Amsterdam is another possible measurement location, but the current documentation does not establish a fixed ping or universal execution advantage for it. Do not assign it a region code based on an old comparison table.

Compare actual application responses under the same conditions and review each location's current interface restrictions. A short route does not override those classifications or the operator's physical eligibility. The Dublin discussion remains a latency choice for an eligible workload, not a way to obtain trading permission.

Testing the Dublin route to Polymarket

Test round-trip times to Polymarket's API from the server you plan to use, at the hours you trade, rather than relying on one published number. Plan for reconnects and rate limits, which can cost a bot more than a millisecond of distance. QuantVPS hosts its Polymarket VPS in Dublin, the closest non-georestricted region Polymarket's docs list (eu-west-1, Ireland), with under 1ms to Polymarket's order book.

FAQs

Is London the recommended hosting location here?

No. London is the documented primary region. The Dublin discussion above concerns latency and remains subject to the official geographic restrictions.

How can I test whether my location is geo-blocked on Polymarket?

Review the current official geographic restrictions and call the documented geoblock endpoint from the intended connection. Its response describes that IP’s treatment, not the operator’s physical-location eligibility. Check the rules for your actual location before trading.

What latency is good enough for a Polymarket application?

There is no universal threshold that establishes an advantage. Measure the complete data-to-decision path and test whether the strategy remains valid at its observed delays. A read-only monitor and a time-sensitive execution process can have different requirements.

Does the documented region guarantee a particular fill speed?

No. Routing, application processing, order type and available liquidity affect the execution path. A regional location or a quick public request cannot establish a guaranteed fill or trading result.