Regions

Overview

Aleatoric Data operates independent infrastructure in two geographic regions. Each region runs a dedicated Hyperliquid full validator node on bare-metal-class compute with NVMe storage and the full transport stack (gRPC, JSON-RPC, Unified Stream, WebSocket). Regions share no state, no load balancers, and no cross-region dependencies.

Available Regions

Region	Azure Location	Compute	Storage	Status
US (East US 2)	Virginia, USA	F16s_v2 (16 vCPU)	1 TB NVMe SSD	Active
JP (Japan East)	Tokyo, Japan	F16s_v2 (16 vCPU)	1 TB NVMe SSD	Active

Region Selection

Choose the region that minimizes network round-trip time to your infrastructure and matches your entitled access. As a guideline:

Your Location	Recommended Region	Expected RTT
North America	US East	< 20 ms
South America	US East	80 - 140 ms
Western Europe	US East	70 - 100 ms
East Asia / APAC	Japan East	< 30 ms
Australia	Japan East	100 - 130 ms

For latency-sensitive strategies, co-locate in the same Azure region as the target endpoint. Both regions are on Azure’s backbone with direct peering to major IX points.

Per-Region Architecture

Each region independently runs:

• Validator node — Full Hyperliquid validator participating in P2P gossip and consensus, synced via port :4001
• Secure regional access layer — TLS termination, API key authentication, and per-key rate limiting
• gRPC bridge — Protocol Buffers over HTTP/2 with microsecond-precision timestamps
• JSON-RPC proxy — Standard EVM-compatible eth_* methods proxied to the local node’s :3001/evm endpoint
• Unified Stream sidecar — Pre-decoded SSE event fanout with ABI decoding, cascade detection, and consensus pulse analysis
• Disk-Sync WebSocket — Raw hex replica command feed for enterprise clients
• Health monitoring — Independent /healthz endpoint per region, no-auth

Rate Limit Independence

API keys are valid across all regions. Rate limits are enforced independently per region — a request to US and a request to JP each consume from separate token buckets. This means a Pro client with 200 req/s capacity effectively has 200 req/s in each region.

Failover

Regions operate independently. If one region experiences degradation:

1. Monitor health endpoints for early detection
2. Switch to the alternate region’s endpoints
3. All API keys work in both regions — no reconfiguration needed

DNS-based automatic failover is not currently implemented. Clients should implement region fallback logic in their connection layer. Both SDKs (Python and TypeScript) accept a region parameter for programmatic switching.

Next Steps

• Endpoints — Full endpoint reference with hostnames and ports
• Architecture — How the data path works end-to-end
• Rate Limits — Per-tier, per-region enforcement