UDP
The lowest-overhead way to submit a transaction to BlockSprint: one UDP datagram, no handshake, no response. Designed for latency-sensitive clients that track their own transaction signatures.
Endpoints
udp://<region>.blocksprint.io:5000| Region | Endpoint | Provider |
|---|---|---|
| Frankfurt | fra.blocksprint.io:5000 | Teraswitch |
| Frankfurt 2 | fra2.blocksprint.io:5000 | Vultr |
| Frankfurt 3 | fra3.blocksprint.io:5000 | Cherry Servers |
| Amsterdam | ams.blocksprint.io:5000 | Cherry Servers |
| Amsterdam 2 | ams2.blocksprint.io:5000 | Teraswitch |
| Amsterdam 3 | ams3.blocksprint.io:5000 | Vultr |
| New York | nyc.blocksprint.io:5000 | Teraswitch |
| Singapore | sgp.blocksprint.io:5000 | Teraswitch |
| Tokyo | jp.blocksprint.io:5000 | Teraswitch |
| London | lon.blocksprint.io:5000 | Teraswitch |
INFO
Frankfurt and Amsterdam each have three servers. If your application runs in or near Frankfurt or Amsterdam, always send each transaction to all three servers in that region (fra, fra2 and fra3, or ams, ams2 and ams3), with a different nonce for each server.
Packet Layout
One UDP datagram per transaction:
| Offset | Bytes | Field | Description |
|---|---|---|---|
0 | 1 | key_len | u8 — length of the API key in bytes |
1 | key_len | api_key | Your BlockSprint API key in ASCII (e.g. YOUR_API_KEY) — sent verbatim, do NOT hash it |
1 + key_len | … | tx_bytes | The serialized Solana transaction wire bytes (the same bytes you'd base64-encode for sendTransaction) |
┌────────┬─────────────────────┬──────────────────────────────┐
│ key_len│ api_key (ASCII) │ tx wire bytes (serialized) │
│ u8 │ key_len bytes │ up to ~1.2 KB │
└────────┴─────────────────────┴──────────────────────────────┘Constraints
| Constraint | Value |
|---|---|
key_len minimum | 16 |
key_len maximum | 128 |
| Max datagram size | ~1.3 KB (1 + key_len + ≤ 1232 tx bytes) |
| Transactions per datagram | 1 |
| Response | None — datagrams are fire-and-forget |
The whole datagram should fit under the path MTU (typically 1500 bytes). Plan for ~1232 bytes of transaction payload to stay safely under that.
INFO
Transaction V1 uses the same packet layout. Serialize it with a V1-capable SDK (in Rust, wincode rather than bincode) and set the compute-unit limit and the loaded-accounts data size limit in its transaction config. Keep the whole datagram within about 1,400 bytes. Send larger V1 transactions (up to 4,096 bytes) via QUIC or sendTransaction.
Behavior
- No response. A sent packet does NOT mean on-chain confirmation. Record the signature client-side and poll
getSignatureStatusesyourself. - Same enforcement as HTTP/QUIC. Auth failures, tip-check failures, and rate-limit drops are silent — packets are dropped without an error. If a transaction does not land, check your API key, tip and rate limit, or contact support with the signature.
- Same tip rules. Your transaction must include a tip transfer of at least 0.001 SOL to one of the tip addresses. See Tipping & Rate Limits.
- One transaction per datagram. Bundles are not supported over UDP — use sendBundle for atomic multi-tx submission.
Quick Example
use std::net::UdpSocket;
let api_key = "YOUR_API_KEY";
let tx_bytes: Vec<u8> = bincode::serialize(&signed_tx)?; // wire bytes (V1: wincode::serialize)
let mut pkt = Vec::with_capacity(1 + api_key.len() + tx_bytes.len());
pkt.push(api_key.len() as u8); // key_len
pkt.extend_from_slice(api_key.as_bytes()); // key (ASCII)
pkt.extend_from_slice(&tx_bytes); // tx
let sock = UdpSocket::bind("0.0.0.0:0")?;
sock.send_to(&pkt, "fra.blocksprint.io:5000")?;import socket
api_key = b"YOUR_API_KEY"
pkt = bytes([len(api_key)]) + api_key + tx_bytes # tx_bytes = serialized tx
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(pkt, ("fra.blocksprint.io", 5000))Full per-language guides:
Comparison with sendTransaction
| Feature | UDP Binary | sendTransaction (HTTP) |
|---|---|---|
| Protocol | UDP datagram | HTTP/JSON-RPC |
| Handshake | None | TLS + HTTP |
| Response | None (fire-and-forget) | Yes (signature returned) |
| Round-trip | Best-effort, no ACK | ~Full RTT |
| Tip required | Yes (same rules) | Yes |
| Encoding | Raw wire bytes | Base64 in JSON |
| Use case | Latency-critical bots tracking own sigs | General use |
