Polymarket Arbitrage Bots: Routing Two Venues From One Machine
The arbitrage itself is well understood. Polymarket and Kalshi list overlapping events, and because they are separate order books with separate liquidity, the same contract regularly prices differently on each. Buy the cheap side, sell the expensive side, collect the spread.
What almost nothing written about this covers is the infrastructure problem underneath it, which is where most implementations actually die: the two venues have opposite geographic requirements, and one machine has one IP address.
Two venues, two incompatible origins
Kalshi is a CFTC-regulated exchange for US residents. It accepts US origins and rejects everything else. That is the compliance boundary its licence depends on.
Polymarket’s international platform at polymarket.com is not offered to US users, and US traffic is refused at the edge. US users are directed to the separately regulated venue at polymarket.us. So the international book requires a non-US origin.
Read those two sentences together and the problem appears. To watch both books you need a US connection and a non-US connection, simultaneously, from the same process. No single IP satisfies both, because every IP is in exactly one country.
Why the VPS-per-venue answer fails
The obvious workaround is two machines: a US VPS for the Kalshi leg, an overseas VPS for the Polymarket leg. This is what most people try first, and it fails for a reason that has nothing to do with geography.
Both of those machines are datacenter hosts. Their IPs belong to hosting ASNs (AWS, Hetzner, DigitalOcean, Vultr), and both venues classify connections by ASN before they evaluate anything else. You have solved the country problem and walked straight into the network-class problem. Both legs get rejected, and you are now paying for two servers that cannot trade.
Adding a VPN to each box does not rescue it either. Most VPN exits are themselves datacenter-hosted, so the flag follows you, and shared VPN ranges get blocklisted as a unit.
One machine, two residential exits
The shape of the correct solution: run one process anywhere, hold two independent sticky sessions to residential seller nodes in two different countries, and route each venue’s traffic through its matching session.
Your bot’s own machine location stops mattering, because no venue ever sees it. Each exchange sees a connection originating from a residential ISP in the country it expects.
Note what the country values are doing. The "DE" above stands for whichever country you are genuinely eligible to trade from. The proxy is matching your infrastructure to your eligibility, not inventing a residency. Using it to trade where you are not eligible breaches both venues’ terms and is the specific behaviour their detection is built to catch.
Keeping the two legs independent
Give each venue its own session. It is tempting to share one tunnel and save a connection, but the failure mode is genuinely bad: if that single node degrades mid-trade you lose both legs at once, holding one side of a spread with no hedge. Two sessions mean a node failure takes down one venue, not your position.
The corollary is that your reconciliation loop needs to handle a leg being unavailable. If the Kalshi session drops while you are short on Polymarket, the safe action is to flatten the live leg rather than wait for the tunnel to recover.
Latency: measure, do not assume
Arbitrage is latency-sensitive, so it is fair to ask what a proxy hop costs. You should measure it in your own setup, but two things are worth knowing up front.
The dominant term is usually geographic distance between the exit node and the venue, not the proxy itself. A residential exit in the same metro as the exchange’s infrastructure will generally beat a datacenter box on the other side of an ocean. This is why node choice matters more than raw throughput: pick seller nodes close to each venue.
Connection setup is also the expensive part, not the per-request cost. Keep sessions warm and reuse them rather than reconnecting per call, and keep your WebSocket streams on the same session as your orders so the data feed and the execution path share one origin. Splitting them across two exits means your feed and your orders appear to come from different networks, which is exactly the pattern detection looks for.
Frequently Asked Questions
Why can’t one VPS run the whole bot?
One machine has one IP in one country, and the two venues require opposite origins. Two VPSes in two countries fixes the geography but not the network class. Both are datacenter ASNs and both get rejected on that basis.
Can one server really hold two exits at once?
Yes. Each session is an independent authenticated tunnel to a different seller node. You route per request by passing a different proxies dictionary, so a single process serves both venues concurrently with no shared state.
Does the proxy make the arbitrage unprofitable?
Measure it rather than assuming. The geographic distance from exit node to venue usually dominates, so co-locating your node choice with each exchange matters more than the hop itself. Reusing warm connections removes most of the remaining overhead.
Should both legs share one session?
No. One session per venue. A shared tunnel turns a single node failure into an unhedged position on both sides at once.
Does this let me trade somewhere I am not eligible?
No, and it is not intended to. Kalshi is US-resident only and Polymarket serves US users through its separately regulated venue. A proxy solves being eligible from the wrong location; misrepresenting residency breaches both platforms’ terms.
Hold a US exit and a non-US exit from one machine. Country-matched residential SOCKS5 sessions, paid per GB in crypto, credentials in minutes.