Endpoints
Three regional Sender endpoints. Pick the closest one to your servers.
// updated 2026-06-04
Sender runs in three regions. Connect to one endpoint - the one closest to your servers.
Pick the region closest to your application server, not your end users. Don't broadcast the same transaction to all three regions.
Regional endpoints
Code: FRA
http://fra.landing.fast
Code: AMS
http://ams.landing.fast
Code: TYO
http://tyo.landing.fast
Single endpoint, not broadcast
Pick one regional endpoint per application instance. Don't broadcast the same transaction to all three.
Once Sender forwards your transaction, it goes to the active Solana leader through SWQoS plus Jito Bundle Engine in parallel - that's already two parallel paths. Adding a third regional copy doesn't help landing rate; it just multiplies network load and tip risk (only one path can land, the others are wasted).
Which region should I pick?
The right choice is whatever's geographically closest to your application server (not your end users):
- EU servers → Frankfurt or Amsterdam.
- APAC servers → Tokyo.
- US East → Frankfurt is usually fastest for trans-Atlantic. If you have NA latency-sensitive paths, contact us about adding NA capacity.
Routing best practices
- One region per app instance. Stick with it. Re-evaluate only if your infrastructure region changes.
- Measure before committing. Latency from your specific datacenter may differ from textbook geography. Send a few
getVersion-equivalent test calls to each candidate and pick the lowest RTT. - No HTTPS yet. All endpoints serve plain HTTP. HTTPS support is on the roadmap.
See also
First request in 5 minutes.
JSON-RPC, Plaintext, Binary.
Minimum tip and tip addresses.