Every VPS provider selling a Polymarket box has an opinion about which European city is fastest. Almost none of them have run the test twice.
We did, because we sell both. We run a Dublin VPS and an Amsterdam VPS, and rather than guess which one to point Polymarket traders at, we probed them against live Polymarket endpoints in the same window, then repeated the whole thing. What follows is the Dublin vs Amsterdam comparison we use ourselves to decide which Polymarket VPS a customer should be on.
The result was more useful than a winner. On the path most people obsess over, the two boxes traded places between runs. On the paths nobody advertises, the gap was consistent and large enough to actually matter.
The short version
- The order path was effectively a tie. Dublin led it in the first run, Amsterdam led it in the second, by a few milliseconds each time. If you pick a city based on a single run of order-path medians, you are picking noise.
- The live feed belonged to Amsterdam, at roughly 10 ms against Dublin’s 16, and that held across both runs.
- The tail told the opposite story. Dublin’s feed p99 was tighter, so Amsterdam is faster on the typical message while Dublin is steadier on the worst one.
- The settlement path was the biggest gap on the board, and almost nobody measures it. The Polygon RPC answered in about 7 ms from Amsterdam and about 24 ms from Dublin.
- Both are for bot and API trading. Ireland and the Netherlands are both in Polymarket’s frontend-restricted group: the website is close-only, the trading API is not restricted.
Dublin vs Amsterdam at a glance
| Measured path | Dublin VPS | Amsterdam VPS |
|---|---|---|
| Live feed, p50 | 16.20 ms | 10.09 ms |
| Live feed, p99 | 36.61 ms | 49.68 ms |
| Feed jitter | 11.04 ms | 6.44 ms |
| Order path, p50 (run 1 / run 2) | 22.03 / 26.53 ms | 26.37 / ~22 ms |
| Order path, p99 | 49.33 ms | 45.32 ms |
| Polygon RPC, warm | ~24 ms | ~7 ms |
| Best suited to | order-heavy bots | feed-reactive bots |
How we tested: the Polymarket VPS benchmark method
Choosing a Polymarket VPS on latency is only meaningful if the test is controlled, so here is exactly how this one was run. The method is the one we published in our Polymarket latency testing guide, and you can run the same script on any box you own, including ours on a free demo.
What matters about the setup, and what most provider comparisons get wrong:
Both boxes ran at the same time. Market activity inflates tails, so a Dublin run at 09:00 compared against an Amsterdam run at 14:00 is not a comparison, it is two unrelated measurements. Our boxes were probed concurrently in the same twenty-minute window, against the same live token.
Ten minutes each, not a ping. Six hundred seconds per run, enough samples for the percentiles to mean something. A one-off ping tells you nothing about the tail, and the tail is what costs you fills.
Warm connections, not cold ones. A real bot holds a pooled connection to the CLOB and a long-lived WebSocket. Measuring cold requests, which pay DNS and TCP and TLS on every call, overstates your real trading latency by the whole handshake. Every order-path number below is warm.
We ran it twice. This turned out to be the most important decision of the whole exercise.
Order path latency: Dublin and Amsterdam swapped places
This is the number everyone shops on. Post and cancel speed on a warm connection, measured to the CLOB.
| Run | Dublin p50 | Amsterdam p50 |
|---|---|---|
| First run | 22.03 ms | 26.37 ms |
| Second run | 26.53 ms | ~22 ms |
Read those two rows again. In the first run Dublin was ahead by about four milliseconds. In the second run Amsterdam was ahead by about four milliseconds. Same boxes, same script, same method.
We could have published either run on its own and told a clean story. “Dublin is 4 ms faster to the order book” would have been a perfectly good marketing line, and it would have been supported by real data that we really collected. It would also have been wrong, and we would only have known that because we ran it again.
The honest conclusion of the Dublin vs Amsterdam order-path comparison is that between two well-connected European boxes, the median is a coin flip. Both sit within a few milliseconds of each other, and most of that round-trip is not the distance between Dublin and Amsterdam at all. It is Polymarket’s own matching engine, which is identical for every customer of every provider, and its behaviour is documented in Polymarket’s API reference.
If you take one thing from this post: be suspicious of any provider comparison built on a single run. Including ours, if we had stopped after the first one.
Live feed latency: Amsterdam’s real advantage
The WebSocket market channel is how your bot sees the book move. For anything reactive, copy trading or news racing or taking on order-flow, this matters more than the order path, because you cannot act on a move you have not seen yet.
| Metric | Dublin | Amsterdam |
|---|---|---|
| Feed p50 | 16.20 ms | 10.09 ms |
| Feed jitter (stdev) | 11.04 ms | 6.44 ms |
Here the gap held across both runs, and it is larger than anything on the order path. Amsterdam saw the book roughly six milliseconds sooner, with noticeably less spread between messages.
Why the feed favours Amsterdam while the order path does not is a fair question, and the honest answer is that we are measuring edge paths rather than distance to an origin. Polymarket’s API is fronted by a global CDN, so your latency is the path to the nearest healthy edge plus whatever happens behind it. The WebSocket edge appears to sit closer to Amsterdam. We can measure that reliably. We cannot see inside it, and we are not going to pretend otherwise.
Tail latency (p99): Dublin’s counterpoint
Medians are the headline. Tails are what actually cost money, because the slow message always arrives at the worst moment.
| Metric | Dublin | Amsterdam |
|---|---|---|
| Feed p99 | 36.61 ms | 49.68 ms |
| Order p99 | 49.33 ms | 45.32 ms |
Dublin’s feed tail was tighter by about 13 ms. Amsterdam’s order tail was tighter by about 4 ms.
So the full picture is not “Amsterdam is faster.” It is that Amsterdam is faster on the typical feed message and Dublin is steadier on the worst one. For a market maker quoting continuously, a tight p99 is often worth more than a fast p50, because your risk is set by the worst case you have to survive rather than the average case you usually enjoy. For a copy bot chasing a wallet, the median is what decides whether you get in before the move.
That is the actual decision, and it depends on your strategy rather than on a leaderboard.
Settlement latency: the Polymarket path nobody measures
Here is the gap that surprised us, and the one you will not find in any competitor comparison.
| Path | Dublin | Amsterdam |
|---|---|---|
| Polygon RPC (warm) | ~24 ms | ~7 ms |
Roughly seventeen milliseconds, which is larger than every other difference in this post combined.
Polymarket matches orders off-chain on its CLOB, so this is not on your order hot path, and we are not going to inflate it into one. But if your bot checks allowances, reads on-chain state, or touches settlement inside any loop that matters, that gap is real and it favours Amsterdam heavily.
One caveat worth more than the number itself: the public Polygon RPC is rate-limited and unreliable, and during our testing it began rejecting requests outright. If your strategy makes chain calls, use a paid RPC endpoint and place it near your VPS. That single change will matter more to you than the difference between these two cities.
Polymarket restrictions: why both locations are bot-only
Neither Polymarket VPS is a good purchase if you trade by hand, and that is worth saying before any latency number matters.
As of July 2026, Polymarket lists both Ireland and the Netherlands in its frontend-restricted group. From either country, the polymarket.com website is close-only, meaning you can close existing positions but cannot open new ones. The trading API is not restricted in either. A bot talking to the CLOB directly runs normally from both. A person clicking around the website does not.
This catches people out in a specific way, so it is worth knowing before you panic. If you check Polymarket’s geoblock endpoint from either box, you will get blocked: true back. That endpoint runs on polymarket.com, not on the API servers, so it is reporting the website’s status. It is the correct answer to the question that endpoint asks, and it is not the question your bot cares about. A different IP in the same country returns exactly the same thing. The only test that answers the bot developer’s question is a real order attempt against the CLOB.
Restriction groups are set by Polymarket and by regulators rather than by any hosting provider, and they have moved more than once this year. Check Polymarket’s own geoblock reference before you provision, and again at renewal. If you are not sure which lane you are in, our bot versus manual trading guide sorts it out.
Dublin vs Amsterdam: which should you pick for your Polymarket bot?
Pick Amsterdam if your bot reacts to the feed. Copy trading, news racing, taking on book movement, anything where seeing the move first is the edge. You get the fastest feed median we have measured, the lowest feed jitter, and a large advantage on the settlement path if your strategy touches chain state. Our copy trading breakdown covers why detection speed dominates that strategy class.
Pick Dublin if your bot quotes and cancels continuously. Market making and order-heavy strategies, where the tail you have to survive matters more than the median you usually get. Dublin’s feed p99 was the tighter of the two, and Polymarket’s own documentation names eu-west-1, which is Ireland, as the closest non-restricted region to their primary servers.
Run both if you are trading real size. Two locations means two jurisdictions, and after Ireland’s status changed in July that is worth more than a millisecond in either direction. It also means you can put feed-reactive strategies on Amsterdam and order-heavy ones on Dublin instead of compromising on one box.
And an honest note to close the Dublin vs Amsterdam comparison: the differences here are small. Both boxes are excellent, both sit within a few milliseconds of each other on the paths that decide fills, and a well-written bot on either will beat a badly written bot on the other every single time. If your event loop blocks for fifty milliseconds on a database call, none of this matters. Our guides on recommended bot specs and running a bot 24/7 are where the larger wins are.
How to test Polymarket VPS latency yourself, in twenty minutes
Everything above is reproducible, and we would rather you checked than believed us.
- Take a box. Ours comes with a free 3-day demo so this step costs nothing.
- Run the script from our latency testing guide for a full ten minutes, from the VPS itself rather than from your home connection.
- Read the medians and the p99, plus the jitter. A fast median with a loose tail is worse than it looks.
- Run it more than once, at the same time of day. This is the whole point of this post.
- Compare against the numbers above, and against our published benchmarks.
If your box loses your own probe, buy the winner and tell us, because that is a routing ticket we want to see.
Frequently Asked Questions
It depends on which path your strategy depends on. In our concurrent testing, Amsterdam had the faster live WebSocket feed at about 10 ms against Dublin’s 16 ms, and it held that across both runs. The order path was effectively tied: Dublin led the first run by about 4 ms, Amsterdam led the second by about the same margin. Dublin had the tighter feed tail, Amsterdam the tighter order tail. Pick Amsterdam for feed-reactive strategies and Dublin for order-heavy ones.
Because a few milliseconds of difference between two well-connected European boxes is within normal run-to-run variance. Most of the order round-trip is Polymarket’s own matching engine, not the distance between the two cities, so small differences in the network portion move around between runs. This is exactly why we ran it twice, and why we would treat any single-run provider comparison, including one of ours, with suspicion.
No, and that is a Polymarket policy rather than a hosting limitation. Both Ireland and the Netherlands sit in Polymarket’s frontend-restricted group, so the website only allows closing existing positions from either country. The trading API is not restricted, which is why both locations work for bots and neither works for manual trading.
Because that endpoint runs on polymarket.com and reports the website’s status rather than the API’s. A blocked: true response from Ireland or the Netherlands is expected and does not mean the CLOB will reject your orders. Switching to a different IP in the same country returns the same result, because the restriction follows the jurisdiction rather than the address. The only meaningful test is a real order attempt from the box you trade on.
Only if your strategy touches on-chain state. Polymarket matches orders off-chain, so settlement is not on your order hot path. If your bot checks allowances or reads chain data inside a loop that matters, the roughly 7 ms from Amsterdam against roughly 24 ms from Dublin is a real advantage. Either way, use a paid RPC endpoint rather than the public one, which is rate-limited and dropped requests during our testing.
If you are trading meaningful size, yes. Two locations gives you two jurisdictions, which matters because Polymarket’s restriction groups have changed more than once this year, and it lets you match each strategy to the box that suits it rather than compromising on one. For a single small bot, either location alone is fine.
Take a demo box, run the benchmark script from our latency testing guide for a full ten minutes from the VPS itself, and read the medians together with the p99 and the jitter. Run it more than once at the same time of day. If your results disagree with ours, we want to hear about it.
Latency figures reflect our own measurements from our Dublin and Amsterdam VPS against live Polymarket endpoints in July 2026, using the public benchmark script linked above. Network performance varies with routing, market activity and configuration, so measure your own box before committing capital. Restriction groups are set by Polymarket and by regulators rather than by any hosting provider and can change; verify on Polymarket’s own pages before provisioning and at renewal. TradoxVPS provides infrastructure, not financial or trading advice.
