17Where the Crypto Venues Live

Many of the largest crypto venues run their matching engines in or next to a public cloud region rather than in an exchange’s own data centre, and for several of them the cloud provider says so. An AWS blog of June 2026 puts Binance in Tokyo, Bybit in Singapore, Coinbase in the United States and Deribit in London; research reported by CoinDesk in March 2026 puts Hyperliquid’s validators in AWS’s Tokyo region, alongside Binance and KuCoin infrastructure; BitMEX moved its platform from AWS’s Irish region to Tokyo because more than 200 milliseconds separated it from the firms that traded it. A firm that wants to be close launches machines in the venue’s region, measures, and keeps the few that happen to sit nearest the venue’s servers.

Chapter 16 described the cloud; this chapter is about finding a venue in it. What is publicly known about where the venues are; how to find out when it is not published (the provider’s address ranges, the round trips from known places); the lottery of launching machines until one lands close; and the re-measurement that notices when the venue moves. Everything that is not a venue’s or a provider’s own statement is a labelled simulation.

17.1 The publicly known locations

The box is short because the sources are few. Venues rarely publish their region in their own documentation; the providers mention them in blogs and case studies; researchers infer them from measurements. A region is also only a start: chapter 16 showed that inside it the zone matters by hundreds of microseconds, and the venue’s zone identifier is published even more rarely.

Anycast and edge networks are why looking up a venue’s public address often says nothing about its matching engine. Hyperliquid’s API, in the report above, is reached through the provider’s edge network, while its validators sit in one region; a user in Europe resolves the same name as a user in Tokyo, reaches a nearby edge, and still waits for the round trip to Tokyo behind it.

17.2 How to discover a location

A provider that publishes its address ranges gives the first clue. AWS publishes a file, ip-ranges.json, listing each prefix with its region and the service that uses it. Matching a venue’s endpoint addresses against it by longest prefix says which region an address belongs to, or that it belongs to the edge network, in which case it says nothing about the origin.

def load_ranges(path=DATA / "ip_ranges_fixture.json"):
    with open(path) as f:
        doc = json.load(f)
    out = [(ipaddress.ip_network(p["ip_prefix"]), p["region"], p["service"]) for p in doc["prefixes"]]
    out += [(ipaddress.ip_network(p["ipv6_prefix"]), p["region"], p["service"]) for p in doc.get("ipv6_prefixes", [])]
    return out


def match(ranges, address):
    """Longest-prefix match of an address against the published ranges."""
    ip = ipaddress.ip_address(address)
    hits = [(n, r, s) for n, r, s in ranges if n.version == ip.version and ip in n]
    if not hits:
        return None
    n, r, s = max(hits, key=lambda h: h[0].prefixlen)
    return str(n), r, s

The bound is exact; the estimate is not. In the chapter’s example, probes in Hong Kong, Singapore, Sydney and Mumbai measure round trips of 36.5, 67.4, 98.8 and $85.5\,\mathrm{m}\mathrm{s}$ to a server hidden in Tokyo (a labelled simulation, with paths 30% longer than the geodesics and some noise). Triangulation with the right route factor, 1.3, puts the server within $23\,\mathrm{k}\mathrm{m}$ of the truth; with 1.2 or 1.4 it misses by more than $540\,\mathrm{k}\mathrm{m}$. Triangulation from other cities finds the region; inside the region the firm must measure from inside.

def triangulate(probes, lat0, lon0, span_deg=6.0, step_deg=0.1, n_g=1.462, factor=1.3,
                overhead_us=0.0):
    """probes: [(lat, lon, rtt_us)]. A round trip bounds the distance (light in glass) and
    estimates it as bound / factor; least squares on a grid around (lat0, lon0)."""
    best = None
    grid = np.arange(-span_deg, span_deg + 1e-9, step_deg)
    for dlat in grid:
        for dlon in grid:
            lat, lon = lat0 + dlat, lon0 + dlon
            res, ok = 0.0, True
            for plat, plon, rtt in probes:
                d = gm.haversine_m(plat, plon, lat, lon) / 1e3
                bound = distance_bound_km(rtt, n_g, overhead_us)
                if d > bound:
                    ok = False
                    break
                res += (d - bound / factor) ** 2
            if ok and (best is None or res < best[0]):
                best = (res, lat, lon)
    if best is None:
        raise ValueError("no point satisfies every probe's light-time bound")
    return best[1], best[2], math.sqrt(best[0] / len(probes))

17.3 The instance lottery

Inside one zone, where a new machine lands decides its distance from the venue’s servers: the same rack, the same row, another hall. The provider does not say, so the firm draws. AWS’s blog of June 2026 reports that placement groups, adapter tuning and kernel bypass “can achieve sub-150 µs intra-Region latencies”, and chapter 16’s measurement puts a typical round trip within a zone at $270\,\text{µ}\mathrm{s}$. The model takes those two figures as the median and the best 1% of launches, with lognormal round trips between them: an assumption, labelled.

The curve is the order statistics of Proposition 17.5: one launch expects $279\,\text{µ}\mathrm{s}$, ten 185, forty 157, a hundred and sixty $138\,\text{µ}\mathrm{s}$. Whether the next launch is worth it depends on what a microsecond is worth. At an assumed 100 USD a month per microsecond and a launch that costs a day of a 16-vCPU instance (17.14 USD at chapter 16’s price), the best is 77 launches, worth about 11 700 USD a month net of their cost (Figure 17.3).

def _draw(lot, size, rng):
    sigma = math.log(lot.median_us / lot.p01_us) / Z
    return lot.median_us * np.exp(rng.normal(0.0, sigma, size))


def expected_best(lot, n, sims=20000, seed=0):
    rng = np.random.default_rng(seed)
    return float(_draw(lot, (sims, n), rng).min(axis=1).mean())


def best_n(lot, value_per_us_month, launch_cost, n_max=200, sims=4000, seed=0):
    """n maximising the monthly value of the round trip saved, net of the launches' cost."""
    base = expected_best(lot, 1, sims, seed)
    best = (1, 0.0)
    for n in range(1, n_max + 1):
        net = value_per_us_month * (base - expected_best(lot, n, sims, seed)) - launch_cost * n
        if net > best[1]:
            best = (n, net)
    return best

17.4 Continuous re-measurement

The lottery’s winners do not stay winners. The venue may move within the region or to another region, as BitMEX did; the provider may migrate machines; maintenance may reshuffle a zone. A firm that measured once will notice only when its fills get worse. The chapter’s check is Book 7’s CUSUM test on the daily median round trip from each kept machine: the cumulative sum of standardised recursive residuals, flagged when it leaves its 5% boundary.

The CUSUM test is slow by design: it was built to detect a change in the mean without crying wolf, and here it needs twelve days to be sure of a shift of four standard deviations. A firm that races will add a faster alarm (a jump in the median beyond a fixed threshold, confirmed the next day) and use the CUSUM test to confirm; the lottery then starts again.

17.5 Tutorial: find the venue, win the lottery

17.6 Build: the venue finder

17.7 Exercises

17.8 Problem: Launch Forty, Keep One

17.9 Interview questions