# 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](https://docs.nextblock.io/api/examples/rust/quic)
* [Go QUIC example](https://docs.nextblock.io/api/examples/golang/quic)
* [Python QUIC example](https://docs.nextblock.io/api/examples/python/quic)
* [TypeScript QUIC example](https://docs.nextblock.io/api/examples/javascript/quic)