19Cross-Region Crypto Networks

Crypto liquidity is spread over a few cloud regions, and a firm that trades across them needs its messages to cross oceans. In April 2026 a round trip from Tokyo to Frankfurt over the cloud provider’s own backbone, by VPC peering, took a median $224.3\,\mathrm{m}\mathrm{s}$; over the same provider’s Direct Connect joined to a specialised network, $136.5\,\mathrm{m}\mathrm{s}$. Light in straight glass along the geodesic would need $91.3\,\mathrm{m}\mathrm{s}$. The provider’s backbone is built for “resilience and scale”, its blog says, and it takes the long way; the specialist takes a shorter one; and the firm that cannot choose sends the same message down both and keeps the first to arrive.

Chapters 16 to 18 worked inside one region. This chapter connects the regions: the hubs and their distances, the backbone and the internet against private lines and specialised providers, and route racing, with the duplicate orders it creates and what a venue’s rules do with them. The published figures are cited and dated; the racing is a labelled simulation.

19.1 The hubs: Tokyo, Singapore, Hong Kong, London, Virginia

The hubs are chapter 17’s: Tokyo, where AWS’s ap-northeast-1 region hosts Binance and BitMEX and Hyperliquid’s validators; Singapore, Bybit’s region; Hong Kong; London and Frankfurt in Europe; Northern Virginia in the United States. The provider publishes only the regions’ names and their numbers of zones (four in Tokyo, six in Northern Virginia, three in the others here), so the chapter places each at its city, and Northern Virginia at Ashburn, an assumption flagged in the site table.

The table’s pattern is the chapter’s subject. To Singapore and Virginia both networks run 26 to 41% above straight glass. To Europe the backbone runs 2.2 to 3.1 times the floor, the specialist 1.5 times. Neither publishes its path; the inflation says the backbone goes a long way round and the specialist a shorter one. The best European route from Tokyo, $124.3\,\mathrm{m}\mathrm{s}$ to Stockholm, is still more than twice the vacuum floor.

19.2 Cloud backbone, public internet and private lines

Three kinds of path join two regions. The public internet, where each hop’s operator chooses the next by business policy and BGP carries reachability, not delay: short paths are a side effect. The provider’s backbone, engineered for capacity and resilience, and in AWS’s own blog not the lowest latency. And private lines: dark fibre or wavelengths (chapter 13) and radio (chapter 14), bought directly or from a network that specialises in low latency and connects to the provider’s regions through its interconnection product, as the blog’s specialist does.

19.3 Specialised low-latency providers and virtual-server hosts

Between Tokyo and Europe the specialist of the blog saves 70 to 121 milliseconds of round trip over the backbone. For a strategy that trades a Tokyo venue against a European one, that is the difference between seeing the other market’s prices a tenth of a second late and seeing them in time to matter. The specialist is a financial extranet (chapter 15) for cloud regions: private lines between the hubs, delivered into the provider’s regions through its interconnection product.

The instance lottery of chapter 17 applies at both ends: the fastest cross-region route is wasted on a machine that sits far from the venue in its own region.

19.4 Racing the same message down several routes

The model races three one-way routes from Tokyo to Singapore: the specialist and the backbone at half their published round trips (32.7 and $34.0\,\mathrm{m}\mathrm{s}$), each with an assumed 99th percentile 15% above its median, and an internet route at $35\,\mathrm{m}\mathrm{s}$ with a heavier tail (an assumption). A Gaussian copula ties them with correlation $\rho$, a common cause such as a shared cable or congestion.

def first_arrival(routes, rho, n=200_000, seed=0):
    """Correlated lognormal draws (one column per route) and the row-wise first arrival."""
    rng = np.random.default_rng(seed)
    k = len(routes)
    common = rng.normal(size=(n, 1))
    own = rng.normal(size=(k, n)).T          # route i keeps its draws whatever k
    z = math.sqrt(rho) * common + math.sqrt(1 - rho) * own
    draws = np.column_stack([r.median_us * np.exp(z[:, i] * math.log(r.p99_us / r.median_us) / Z)
                             for i, r in enumerate(routes)])
    return draws.min(axis=1), draws


def percentile_gain(routes, rho, q=99, n=200_000, seed=0):
    first, draws = first_arrival(routes, rho, n, seed)
    best_single = min(float(np.percentile(draws[:, i], q)) for i in range(draws.shape[1]))
    return best_single - float(np.percentile(first, q))

Racing pays in the tail, and only while the routes fail independently. With independent routes the second route saves $1623\,\text{µ}\mathrm{s}$ at the 99th percentile and the third another $518\,\text{µ}\mathrm{s}$; at $\rho = 0.5$, 771 and 90; at 0.9, 53 and nothing. At an assumed 10 USD a month per microsecond of 99th percentile, the third route is worth 5 182 USD a month if the routes are independent, 902 at $\rho = 0.5$ and nothing at 0.9: the price above which racing it does not pay.

What arrives second is a problem. The venue receives the same order several times; the idempotency key must make it act once. Binance’s spot interface is typical of the rule to check: a client order identifier must be unique among open orders, and a copy is rejected as a duplicate only while the first order is open. Once the first copy has filled, a late copy with the same identifier is a new order.

The model makes the danger concrete: three copies of an order that fills on arrival are three executions; one that takes a millisecond to fill still produces 1.57 unwanted executions on average; eight milliseconds, 0.07. Racing is therefore safe for messages that are idempotent at the venue (a cancel, a query, market data) or under a rule that remembers identifiers after the order has ended, and dangerous for taking orders under an open-only rule. One Quant Book 13’s idempotent processing is what the venue must do; this chapter’s lesson is to read the venue’s rule before racing.

19.5 Tutorial: hubs and races

19.6 Build: the route racer

19.7 Exercises

19.8 Problem: Three Routes to Singapore

19.9 Interview questions