Ask “where should I host my Polymarket bot?” and every vendor answers with a city and a millisecond figure. Both halves are usually wrong: the city, because there is a restriction layer that comes first, and the milliseconds, because most numbers in circulation were never measured. This guide does it properly, and it is written for bots and API strategies rather than for manual traders.
The short version
- The fastest location is London, eu-west-2, where Polymarket’s primary servers sit. It is reachable only through their KYC/KYB colocation programme, so no VPS provider sells it, us included.
- For everyone else it’s Dublin or Amsterdam. They finished about one millisecond apart on the order path in concurrent testing: Amsterdam takes the live feed at ~10 ms, Dublin takes the warm order round-trip at ~21 ms. Pick by strategy, or run both for cross-country failover.
- Both are for bot and API trading. Ireland and the Netherlands are two of only four jurisdictions Polymarket lists where the website is close-only while the trading API stays unrestricted.
- A
blocked: trueresponse is expected on both, and does not mean your bot is blocked. That endpoint runs on polymarket.com and reports the website’s status, not the API’s. - Location is necessary, not sufficient. Two providers in the same city can route very differently, so the only answer that counts comes from a 20-minute probe on the box you’ll actually trade from.
For Polymarket US, the regulated venue, nobody has credible public measurements yet, including us, and we will publish ours when our New York location launches rather than guess today.
What changed in July 2026
Ireland moved into Polymarket’s frontend-restricted group. The polymarket.com website is now close-only from Irish IPs, while the trading API is not restricted. That’s the single most important update to this guide, and it’s the reason the tier distinction below matters more than it used to.
One correction while we’re here. An earlier version of this page described Amsterdam as banned. That was wrong, and we’ve removed it: we operate there, we trade the API from it, and it posts the fastest Polymarket feed we’ve measured.
The latency ranking, and what you can actually buy
1. London, eu-west-2, the theoretical floor
Polymarket’s API reference states it plainly: primary servers are in eu-west-2, which is AWS London. That single documented fact explains something this guide previously treated as an awkward coincidence. Independent probes on Glassnode’s HyperLatency dashboard consistently show London as the fastest location on the board at roughly 12 ms p50. It’s fastest because that’s where the venue is.
Polymarket also offers direct colocation in eu-west-2 to users who complete a KYC/KYB form. That is the lowest-latency arrangement available to anyone, and it is worth saying clearly: we don’t sell it, and neither does any other VPS provider. It’s a relationship with the venue, not a hosting product.
How the colocation path works, step by step
- Decide whether it’s actually for you. KYB means “know your business,” so this path is built for firms and verified entities rather than individual retail traders. If you’re running one bot on a $50 box, the paperwork alone will cost more than the milliseconds are worth to you.
- Complete Polymarket’s KYC/KYB form. It’s linked directly from their API documentation.
- Wait for their review. Approval, eligibility, timelines and terms are entirely Polymarket’s to decide. So is how this interacts with jurisdictional restrictions, which is a question to put to them during the process rather than to assume from any blog, this one included.
- Provision in eu-west-2 once you’re approved. In practice that means running your bot in the same cloud region as their primary servers, which puts you on AWS London pricing rather than VPS pricing. We ran that comparison in TradoxVPS versus AWS for Polymarket, and the gap is substantial before you add data transfer.
- Measure it anyway. Same rule as everywhere else on this page: colocation is a claim until your own probe confirms it. Run the 20-minute probe from the new box and compare.
Two cautions, because this is where people get hurt. First, the United Kingdom is close-only on both the frontend and the API in Polymarket’s published groups, meaning standard access there can close positions but cannot open new ones. Polymarket nonetheless names eu-west-2 as their primary region and offers colocation in it, which tells you the KYB arrangement is governed by something other than the retail jurisdiction rules. A KYB-verified colocation arrangement is a different relationship with the venue than a retail account, and only Polymarket can tell you how the two interact for your entity. Second, “eu-west-2” is a cloud region identifier, not the city of London. A London VPS, ours included, sits near that region but is not inside it and is not part of their colocation programme. If you’re a verified firm exploring this, ask Polymarket directly what infrastructure qualifies. Don’t infer permission from this paragraph, and don’t let any provider tell you a London box gets you the same thing.
2. Dublin, eu-west-1, the closest non-restricted region
The same Polymarket documentation names eu-west-1 as the closest non-georestricted region to their primary servers. That is Ireland, and it is the strongest available endorsement of Dublin for anyone not going down the colocation route: it comes from the venue rather than from a hosting company’s marketing page.
In our four-provider benchmark, Dublin measured ~13-15 ms median to the live feed and ~21-23 ms warm order round-trips. Details below.
3. Amsterdam, effectively tied
Running the same probe concurrently from both cities, Amsterdam landed within about a millisecond of Dublin on the order path and ahead of it on the live feed. On the evidence these are two good answers to the same question, not a winner and a runner-up.
| Path | Dublin | Amsterdam | Edge |
|---|---|---|---|
| Live market feed (WS p50) | ~14 ms | ~10 ms | Amsterdam |
| Order round-trip (warm p50) | ~21 ms | ~22 ms | Dublin, barely |
| DNS resolution | sub-1 ms | sub-1 ms | tie, local caching resolver in both images |
Pick by strategy, not by the leaderboard. Feed-reactive bots, copy trading and news racing among them, benefit from Amsterdam’s feed advantage. Order-heavy bots, quoting and market making, benefit from Dublin’s order path. Run both and you get two jurisdictions and cross-country failover, which after this July is worth more than a millisecond.
Both are bot and API only, for the reason in the next section.
Filter one: restrictions before speed, and there are four states, not two
Polymarket enforces geographic restrictions at the platform level, and their own documentation splits them into groups that matter enormously to a bot developer. Most location guides flatten this into “banned” or “fine.” As of July 2026 there are four states a jurisdiction can be in, and the difference between the middle two decides whether your bot runs:
Unrestricted. Not named on any list. Full access on both the website and the API. Much of Europe outside the named lists sits here.
Close-only on the frontend, API unrestricted. The website can only close positions, while the trading API is not restricted. Only four jurisdictions are in this group: Ireland, Japan, Malta (sports only) and the Netherlands. A bot talking to the CLOB directly is unaffected. A person clicking around the website is.
Close-only on the frontend and the API. Existing positions can be closed, new ones cannot be opened, by either route. This is the largest group and it includes the United States, the United Kingdom, Germany, France, Italy, Belgium, Australia, Brazil, Poland, Russia, Singapore, Slovakia, Taiwan and Thailand, plus four Canadian provinces. A bot hosted here can wind a book down and nothing else.
Blocked completely. No new orders and no closing of existing positions, on either route. This is the OFAC-sanctioned list: Iran, Syria, Cuba, North Korea, and the Crimea, Donetsk and Luhansk regions of Ukraine.
Two things follow, and they’re the reason this page exists.
For a bot, the second group is not a blocker. Treating it as one is how competitors eliminate perfectly good locations, and how customers get told to migrate for no reason. There is a neat confirmation of this in Polymarket’s own documentation: it names eu-west-1 as the “closest non-georestricted region” to their primary servers, and eu-west-1 is Ireland, whose only restriction is on the frontend. The venue itself treats Ireland as unrestricted for API purposes.
For manual trading, the second group is decisive, and no VPS anywhere fixes it, because the restriction follows the jurisdiction rather than the machine. Our bot versus manual trading guide sorts which lane you’re in, and after this July that question decides which countries are open to you at all.
A note on the unrestricted group, since it’s the obvious follow-up question: yes, a fully unrestricted country would give a bot the same API access plus a working website. The reason Dublin and Amsterdam still win is distance and peering, not permissions. Polymarket’s primary region is eu-west-2, Ireland is the adjacent region their docs name, and Amsterdam sits on one of the world’s largest internet exchanges. A box in a further-flung unrestricted country is legally fine and measurably slower.
Two sources are worth trusting: Polymarket’s Geographic Restrictions help page and the geoblock reference in their API docs. Do not trust any third-party list as your final check, including this page. Restrictions expand, tiers move, and only the official pages update when the rules do. Verify before provisioning and again at every renewal.
Two things we won’t help with. Polymarket prohibits VPNs and similar tools for bypassing restrictions, and flagged accounts can be frozen. Multi-account setups violate the Terms of Service wherever they’re hosted, so a provider advertising headroom for “100+ accounts” is selling you an account-termination risk. If you’re weighing a VPN against a VPS at all, our VPS versus VPN comparison explains why they solve different problems. Note the contrast with the colocation path above: that one is Polymarket’s own verified programme, which is the opposite of circumvention.
The geoblock endpoint will say you’re blocked. Here’s why that’s expected.
This is the single most common false alarm we see from customers on Dublin and Amsterdam boxes, so it’s worth walking through properly.
Polymarket publishes an endpoint for checking eligibility. Their docs write it as GET https://polymarket.com/api/geoblock, which is HTTP notation rather than something you type. On your own box it’s one line:
Windows Server, Command Prompt:
curl https://polymarket.com/api/geoblock
Windows Server, PowerShell:
Invoke-RestMethod https://polymarket.com/api/geoblock
(In PowerShell, curl is an alias for Invoke-WebRequest and wraps the output in an object, so use Invoke-RestMethod for clean JSON, or call curl.exe explicitly.)
Ubuntu:
curl https://polymarket.com/api/geoblock
From a Dublin box you’ll get something like this:
{"blocked":true,"ip":"198.51.100.24","country":"IE","region":"L"}
And from Amsterdam:
{"blocked":true,"ip":"203.0.113.42","country":"NL","region":"FL"}
The addresses above are documentation placeholders; yours will be your own server’s. Both responses are expected, and neither means your bot is blocked.
The reason is in the endpoint’s own address: it lives on polymarket.com, the website, not on the API servers. It reports frontend eligibility. In a frontend-restricted country the website is close-only, so blocked: true is the correct and honest answer to the question that endpoint is actually asking. It simply isn’t the question a bot developer is asking.
What this means in practice, as of July 2026: bots are running normally from both Dublin and Amsterdam. The CLOB accepts orders from both. We trade from both ourselves and we check them from our own boxes rather than relying on documentation, because tiers are set by Polymarket and regulators and they can move, as Ireland’s did this month. If that changes for either location, this page changes with it.
We learned the practical version of this from a support ticket. A customer on a Dublin box ran that check, saw the response, concluded his server was banned, and asked to be moved to a different IP. Nothing needed moving. A different address in the same country returns exactly the same thing, and his bot had never stopped working.
The only test that answers the bot developer’s question is a real order attempt against the CLOB from the box you actually trade on. An accepted order is ground truth. A geoblock response is a status report about a website.
Filter two: the origin is documented, your path is still to an edge
Nearly every location guide asserts which cloud region Polymarket “lives in,” usually citing other vendors who assert it too. Our confession: two different pages on this very site once named two different AWS regions, which tells you how those claims get made.
The situation is clearer now, and in both directions. The origin region is documented, eu-west-2, by Polymarket themselves, so that part is no longer folklore. But when we measured, our probes terminated at Cloudflare CDN edges, not at that origin. Polymarket’s API rides a global anycast network, so unless you’re colocated in eu-west-2, your bot’s latency is its path to the nearest healthy edge plus whatever happens behind it. Both facts are true at once, and together they explain the shape of every measurement on this page:
- Colocation in eu-west-2 is the only way to skip the edge hop, and it requires KYB.
- Everyone else is measuring edge paths, which is why Dublin and Amsterdam land within a millisecond of each other on orders while sitting hundreds of kilometres apart.
- Edge latency can be measured by anyone in 20 minutes, which is why this guide’s claims come with a reproducible probe rather than a citation chain of vendor blogs.
- Endpoints evolve. docs.polymarket.com is the source of truth for what your bot connects to, and if you haven’t migrated yet, our CLOB v2 migration guide covers what changed.
What we actually measured
Four providers, one purchased box each, one public script, one week, raw JSON downloadable. The full study is the Polymarket VPS benchmark report. The location-relevant medians:
| Path (from Dublin) | Our box | What it means for a bot |
|---|---|---|
| Live market feed | ~13-15 ms median | How stale your view of the book is |
| Order round-trip (warm) | ~21-23 ms median | Submit to acknowledged, the execution path |
| Order p99 across the field | 37.0-55.3 ms (ours: 37.0, max 40.9) | Where bot-vs-bot races are decided |
| Venue API root, p99 | 250-650 ms on every provider | The venue’s own bad moments, design for them |
Three honest readings. First, these numbers are excellent in absolute terms, and they are twenty-plus milliseconds, not 0.5 ms. We benchmarked the sub-millisecond claim out of existence ourselves, and any provider still advertising it for a CDN-fronted API has never measured. Second, between well-placed boxes the medians converge and the tails decide: a 37 ms worst case beats a 55 ms worst case in every contested fill, which is why we publish percentiles rather than averages. Third, the venue’s own p99 reaching 250-650 ms on all four providers is a design constraint no location fixes, including colocation. Your bot has to tolerate the venue’s slow moments, and our prediction market arbitrage guide covers how to size for the one-leg case.
The same-city trap: location is necessary, not sufficient
The most useful finding in our benchmark wasn’t about Polymarket at all. Probing Binance, the signal source for crypto-lag strategies, our Dublin box hit a far CDN edge at ~313 ms while three competitor boxes in the same city saw ~208 ms. Same location, different provider routing, a 100 ms gap on a path that matters to a whole strategy class. We published our own weakness, it’s on the routing roadmap, and it gets re-verified next benchmark. That’s what measurement-first looks like when the number goes against you.
The lesson generalizes: “Dublin” is not a number, and neither is “Amsterdam.” Two providers in one city can route differently per destination, so the city gets your bot into the right neighborhood and nothing more. Probe the box you’ll actually trade from, against every venue your strategy touches. Our guide on how server location impacts execution speed has the longer version.
US traders and Polymarket US
The United States is close-only on both the frontend and the API, so a US-hosted bot can close positions but cannot open new ones. US probes also read roughly 100 ms p50 to the international book’s API, so US locations fail both filters at once: restricted and far. The regulated route is Polymarket US, the CFTC-licensed exchange built on the QCEX acquisition, with KYC and fiat rails. On its infrastructure: we haven’t measured Polymarket US endpoints, so we won’t tell you “New York, sub-1 ms, us-east-1.” Those are guesses wearing precision. Our New York location will launch the way everything here launches now: probes first, numbers published, then marketing.
Today our US presence is Chicago, built for the CME and Kalshi side, and we quote no Chicago milliseconds until the probe runs there. If you’re weighing venues, see Polymarket versus Kalshi and the Kalshi bot VPS guide.
What about Frankfurt, Singapore, everywhere else?
We operate four locations, two of them Polymarket-relevant and measured. For everywhere else: we won’t quote milliseconds for cities we haven’t measured, and you shouldn’t accept them from anyone who hasn’t either. A comparison table with precise figures for six cities and no method is decoration.
Frankfurt is now answerable without measuring it. Germany is close-only on both the frontend and the API, so a bot hosted there could close positions and never open one. That is a jurisdiction answer, not a latency answer, and no amount of German peering changes it. The same reasoning rules out London, Paris, Milan, Brussels, Warsaw, Singapore and Sydney for opening new positions.
For any candidate city the evaluation is the same two filters in that order: its group on Polymarket’s own pages first, then a probe from a real box there. Our general framework lives in how to choose the best VPS location for your trading strategy.
How to choose a location for your Polymarket bot, in five steps
- Decide whether the colocation path applies to you. If you’re a verified firm and the milliseconds justify cloud pricing plus paperwork, start with Polymarket’s KYC/KYB form. If you’re an individual running bots, skip to step 2 without feeling like you’ve settled.
- Check the tier, not just the list. Look up your candidate jurisdiction on Polymarket’s restrictions page and API geoblock reference, today’s version rather than a blog’s memory of it. Blocked eliminates the city. Frontend-restricted is fine for an API bot and fatal for manual trading.
- Shortlist by geography. Dublin and Amsterdam are our measured picks, and Polymarket’s own docs name eu-west-1 as the closest non-restricted region. They aren’t the only conceivable choices.
- Get a real box and probe it. Ours comes with a free 3-day demo so this step costs nothing. Run the 20-minute probe for medians and p99 to Polymarket’s feed and order path, plus every signal venue your bot reads. Compare against our published baselines and PassMark benchmarks.
- Decide on evidence. If our box loses your probe, buy the winner, and tell us, because that’s a routing ticket we want.
One scoping note. Location is decisive for time-competitive automation, and nearly irrelevant for manual trading or daily-cadence strategies. After July 2026 that distinction does double duty: it decides whether latency matters to you and which jurisdictions are open to you at all. The bot versus manual lane map sorts it, and the bot setup guide, recommended specs and 24/7 uptime guide take over from there. Still on a desktop? Start with local PC versus VPS for Polymarket bots.
Frequently Asked Questions
Ranked by achievable latency: London (eu-west-2) is where Polymarket’s primary servers are and where they offer direct colocation, but only to KYC/KYB-verified users, so it isn’t a VPS anyone sells. For everyone else it’s Dublin or Amsterdam, which are two of only four jurisdictions Polymarket lists where the website is close-only but the trading API stays unrestricted. Polymarket’s own docs name eu-west-1, Ireland, as the closest non-restricted region, and in our concurrent tests Dublin took the warm order round-trip at ~21 ms while Amsterdam took the live feed at ~10 ms. Pick by strategy, or run both for failover. The final answer always comes from a probe on your actual box.
blocked: true on my Dublin or Amsterdam VPS? Because that endpoint reports the website’s status, not the API’s. It runs on polymarket.com, and in a frontend-restricted country like Ireland or the Netherlands the website genuinely is close-only, so blocked: true is the correct answer to the question it’s asking. Your bot’s orders go to the CLOB API, which is a different system, and Ireland and the Netherlands are two of only four jurisdictions where Polymarket lists the API as unrestricted while the frontend is close-only. A real order attempt from your box is the only test that answers the question you care about, and a different IP in the same country will return exactly the same response.
Yes, if you can complete their KYC/KYB process. Polymarket’s API documentation links a verification form, and approved users can colocate directly in eu-west-2, their primary region, for the lowest possible latency. It’s aimed at firms rather than individuals, it puts you on cloud pricing rather than VPS pricing, and approval, terms and eligibility are entirely Polymarket’s call. No hosting provider, us included, can sell you this or promise you’ll qualify.
No. The UK is close-only on both the frontend and the API in Polymarket’s published groups, so a London VPS gets you a very fast connection to a venue that will let your bot close positions and never open one. It’s also worth being precise about what eu-west-2 means: it’s a cloud region identifier, not the city, so a London VPS sits near that region but isn’t inside it and isn’t part of Polymarket’s colocation programme. If you’re a verified firm, ask Polymarket what infrastructure qualifies. Any provider selling you a London box “next to Polymarket” is selling you the worst of both.
No, and we trade from it. The Netherlands sits in the frontend-restricted group, so the website is close-only while the trading API is not restricted and an API bot runs there normally. In concurrent benchmarks Amsterdam posted the fastest live Polymarket feed of any location we operate. Frankfurt and other cities we haven’t measured, and we won’t quote numbers for them.
Polymarket publishes four groups. Unrestricted countries have full access on both the website and the API. Ireland, Japan, Malta (sports only) and the Netherlands are close-only on the website while the API stays unrestricted, which is why they suit bots. A much longer list including the US, UK, Germany, France, Italy, Canada, Australia, Singapore and Brazil is close-only on both the website and the API, so a bot there can only close positions. The OFAC-sanctioned list, Iran, Syria, Cuba, North Korea and three Ukrainian regions, is blocked completely, with no closing either. Check the current groups before you provision, because they move.
No, and this is the most common location myth. Orders match on Polymarket’s off-chain CLOB, and Polygon handles settlement afterwards. Your latency-sensitive path is to the CLOB API and WebSocket, which is exactly what the probe measures.
Twenty minutes. Take a trial box, run the published probe against Polymarket’s feed and order path plus your signal venues, read the medians and the p99, and compare against published baselines. Cross-check the magnitude against an independent monitor. If a vendor’s number sits an order of magnitude below the fastest independent probe on Earth, the number is copy, not measurement. Any location claim that can’t survive that test, ours included, wasn’t a claim, it was marketing. Our latency checker is the fastest way to start.
Restriction groups and infrastructure details reflect Polymarket’s official pages as of July 2026. Those pages, not this one, are authoritative, and they change: Ireland’s status changed in July while this guide was live, and we’ve corrected it here rather than quietly. Tiers are set by Polymarket and regulators, not by any hosting provider, and they can move again. Colocation eligibility, terms and approval are Polymarket’s alone to determine. Verify before provisioning and at renewal. We do not assist with VPN circumvention or multi-account setups, both of which violate Polymarket’s Terms of Service. We operate TradoxVPS and provide infrastructure, not legal or financial advice.
