QUIC Transaction Submission

NextBlock supports low-latency transaction submission over raw QUIC. Instead of sending base64 inside gRPC, you keep one QUIC connection open and write the signed transaction bytes directly to a unidirectional stream.

This path is designed for advanced traders who already have signed Solana transaction bytes and want the lowest-latency submission path with the smallest possible transport overhead.

When To Use QUIC

Use QUIC if:

• you already have fully signed Solana transaction bytes

• you want the lowest possible submission latency

• you do not need the extra submission options available on HTTP or gRPC

Use HTTP or gRPC instead if you need:

• front-running protection

• revert-on-fail

• disable-retries

• snipe mode

• atomic bundle submission

Available Endpoints

Choose the region closest to your bot or signer. All QUIC endpoints listen on port 11100.

• Frankfurt: frankfurt.nextblock.io:11100

• New York: ny.nextblock.io:11100

• Vilnius: vilnius.nextblock.io:11100

• Tokyo: tokyo.nextblock.io:11100

• Singapore: singapore.nextblock.io:11100

• Dublin: dublin.nextblock.io:11100

• London: london.nextblock.io:11100

• Salt Lake City: slc.nextblock.io:11100

• Amsterdam: amsterdam.nextblock.io:11100

How It Works

1. Open a QUIC connection to a regional endpoint with ALPN nb-tx/1.

2. Open one bidirectional stream and send your API key as raw UTF-8 bytes.

3. Close your write side, then read a single-byte auth response.

4. If the response is 0x00, the connection is authenticated and ready.

5. For each transaction, open a new unidirectional stream and write the raw serialized transaction bytes.

Important Notes

• Transactions must fit within Solana's normal transaction size limit of 1232 bytes.

• Submission is fire-and-forget. After the bytes are written, there is no per-transaction response stream.

• QUIC submission does not support the extra gRPC submission flags such as front-running protection, revert-on-fail, disable-retries, or snipe mode. You only send the raw signed transaction bytes.

• QUIC also does not support the atomic batch submission endpoint.

• Invalid or rate-limited transactions may be dropped server-side without a response.

• Keep one connection open and reuse it for many transactions instead of reconnecting for every send.

Language Examples

• Rust QUIC example

• Go QUIC example

• Python QUIC example

• TypeScript QUIC example