Skip to content

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
RegionEndpointProvider
Frankfurtfra.blocksprint.io:5000Teraswitch
Frankfurt 2fra2.blocksprint.io:5000Vultr
Frankfurt 3fra3.blocksprint.io:5000Cherry Servers
Amsterdamams.blocksprint.io:5000Cherry Servers
Amsterdam 2ams2.blocksprint.io:5000Teraswitch
Amsterdam 3ams3.blocksprint.io:5000Vultr
New Yorknyc.blocksprint.io:5000Teraswitch
Singaporesgp.blocksprint.io:5000Teraswitch
Tokyojp.blocksprint.io:5000Teraswitch
Londonlon.blocksprint.io:5000Teraswitch

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:

OffsetBytesFieldDescription
01key_lenu8 — length of the API key in bytes
1key_lenapi_keyYour BlockSprint API key in ASCII (e.g. YOUR_API_KEY) — sent verbatim, do NOT hash it
1 + key_len…tx_bytesThe 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 ​

ConstraintValue
key_len minimum16
key_len maximum128
Max datagram size~1.3 KB (1 + key_len + ≤ 1232 tx bytes)
Transactions per datagram1
ResponseNone — 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 getSignatureStatuses yourself.
  • 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 ​

rust
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")?;
python
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 ​

FeatureUDP BinarysendTransaction (HTTP)
ProtocolUDP datagramHTTP/JSON-RPC
HandshakeNoneTLS + HTTP
ResponseNone (fire-and-forget)Yes (signature returned)
Round-tripBest-effort, no ACK~Full RTT
Tip requiredYes (same rules)Yes
EncodingRaw wire bytesBase64 in JSON
Use caseLatency-critical bots tracking own sigsGeneral use