Transports & Connections

This page covers the ways to send transactions to 0block and how to manage connections for low-latency, high-throughput submission.

Available now

HTTP/1.1 JSON-RPC

Today, 0block accepts standard Solana JSON-RPC over HTTP/1.1 on the root path:

POST https://{region}.0block.io/
Content-Type: application/json
X-API-Key: <YOUR_API_KEY>

• Method: only sendTransaction is routed; see Send Transaction for the full request schema.
• Encodings: the signed transaction in params[0] may be base64 (default) or base58. 0block honors an explicit params[1].encoding hint and otherwise auto-detects (base64, then base58).
• Auth: pass your API key with the X-API-Key header or the ?api-key= query parameter.

Connections & keep-alive

Gate latency is dominated by network round-trips, so how you manage connections matters:

• Reuse persistent connections. Keep a long-lived HTTP connection (keep-alive) instead of opening a new one per submission — this avoids repeated TCP and TLS handshakes on the hot path.
• Pool connections. For concurrent submission, maintain a small pool of warm connections rather than serializing through one.
• Keep connections warm. Periodically issue a lightweight GET /health (see Health) on idle connections to keep them open and confirm the region is reachable.
• Pick the nearest region. Choose the closest regional endpoint to minimize round-trip time.

Coming soon

• Raw binary body submission — POST the signed transaction bytes directly, skipping the JSON-RPC envelope to shave serialization overhead off the hot path.
• Batch send — submit multiple transactions in a single request via JSON-RPC batch arrays. (Tracked on the gateway roadmap.)
• WebSocket submission — fire-and-forget binary frames over a persistent WebSocket for sustained, high-rate submission without per-request HTTP overhead.
• QUIC — submit over QUIC, aligning with Solana's native validator transport.

Want early access to any of these? Reach out on Discord.