Two transactions from one signer, tip in the first, sent as one atomic bundle. Both are signed with the same blockhash so they expire together.

Nozomi is a fully custom proprietary client written by HPC and HFT engineers designed to land transactions as fast as possible.

How It Works

Nozomi runs custom hardware and staked connections across the cluster, forwarding your transaction to current and upcoming leaders and automatically optimizing the delivery path for each leader. You do not need to select endpoints based on the leader schedule. Nozomi handles routing for you. Your job is to submit fast (see Regions & Endpoints) and tip enough to win your slot (see Tipping).

Nozomi does not simulate your transactions; it routes them for the fastest possible delivery. If a transaction is not landing the way you expect, start with Troubleshooting.

Who Should Use It

• Sniper Bots — Snipe tokens and mints before the competition.

• DeFi Apps — Create a better UX so user transactions do not stall or fail.

• Traders — Land with speed and precision to capture the most opportunities.

• Liquidators — Be first to a liquidation transaction.

• Jito Bundle Users — Get through the block engine faster and more efficiently.

• Algorithmic Traders — Get predictability with your bots in all market conditions.

Getting started is self-service: create an account and generate your API key in the dashboard.

Join our for announcements and updates. For help, reach the team in Discord or through live chat in the dashboard.

Nozomi provides a native QUIC client for submitting transactions:

github.com/temporalxyz/nozomi-quic-client →

When to Use It

QUIC is not faster than the HTTP endpoints when you keep a warm connection open. Over a persistent, reused TCP connection, Batch Send over a direct http:// endpoint is the lowest-latency path (see Regions & Endpoints → Choosing a submission method).

QUIC is useful for a specific case: workloads that cannot hold a single connection open and have to re-establish a connection frequently. QUIC's connection setup (including session resumption) is cheaper than repeatedly completing a fresh TCP + TLS handshake, so you pay less latency per reconnect.

Use QUIC when:

• You cannot maintain one long-lived, warm connection to a region.

• Your process is short-lived, serverless, or otherwise reconnects often.

• Network conditions force frequent reconnection.

If you can keep a connection open, prefer Batch Send or API v2 over a direct http:// endpoint instead, and use to keep it warm.

• The transport you choose does not change your priority in Nozomi's queue: priority is driven by your , not by QUIC vs HTTP.

• Like API v2 and Batch Send, QUIC submission does not return a transaction signature. Compute and track the signature client-side before submitting.

How do I get access?

Nozomi is self-service: create an account and generate an API key in the dashboard. Sign up →

Support & Community

Join our Discord for announcements and updates.

Need help? You can reach the team:

• In our Discord.

• Through live chat in the dashboard (dashboard.nozomi.temporal.xyz).

Rate Limits

Each API key has a rate limit enforced per key, per region, per second. Because it is per region, sending the same transaction to multiple regions does not count against your limit in a single region. Fanning out is the first thing to try if you are hitting the limit.

New keys start with a default of 5 requests/second. A 429 response means you exceeded your per-key, per-region rate, or your traffic was flagged as spam.

When you hit 429:

1. Fan out across regions. Limits are per region, so sending the same signed transaction to several regional endpoints multiplies your effective throughput. See .

2. Use one key and stop client-side retries. Nozomi retries server-side; resubmitting the same transaction burns your limit and hurts your priority. Do not spread traffic across multiple keys.

3. Then request an increase (below).

Request a higher rate limit from your key in the dashboard (dashboard.nozomi.temporal.xyz). Requests are reviewed based on your landing rate, success rate, and overall transaction quality, not purchased. Keeping those healthy is what qualifies you for a higher limit.

Nozomi prioritizes transactions based on your tip and your historical success and landing rates. Consistently landing successful transactions keeps your priority high; a high failure rate lowers it.

To keep your priority high:

• Don't send transactions you expect to fail: check account state before submitting.

• Avoid stale blockhashes.

• Let Nozomi handle retries instead of resubmitting client-side.

No. Nozomi does not simulate transactions. It routes them for the fastest possible delivery.

See the page. The most common causes are a tip below the minimum, over-requested compute units, client-side retry loops, and a low landing/success history.

Default keys are speed-optimized and are not sandwich-protected. A separate MEV Protect key is available on request. See . As a backstop on any key, set a strict slippage tolerance and enforce minAmountOut.

No. Nozomi does not offer a shredstream feed, and there is no Jito-style bundle-subscribe / gRPC subscription feed. The low-latency product is transaction submission, including atomic bundle submission via . For tip data, use the .

The dashboard (dashboard.nozomi.temporal.xyz) is the self-service surface: create or import API keys, request rate-limit increases, view per-transaction tip / success analytics, and manage tip accounts.

• Sign in with Google or with email and password.

• Teams are supported. You can invite other people to your team from the dashboard.

Every Nozomi transaction must include a tip: a standard Solana system transfer instruction to one of the Nozomi tip addresses. The default minimum tip is 0.001 SOL.

Transactions that tip below the minimum are silently dropped: you will not receive an error. If you are seeing transactions disappear with no response, check your tip amount first. A lower per-account minimum can be arranged for qualifying high-volume flows; reach out through the dashboard.

You only pay when your transaction lands. The tip is an instruction inside your transaction, so if the transaction fails, the tip is never charged. This means you can intentionally fail a transaction if, for example, you detect that someone else already captured the opportunity you were targeting.

A faster alternative to JSON-RPC that eliminates JSON parsing overhead and CORS preflight latency. Recommended for browser clients and performance-sensitive backends.

The standard way to send transactions through Nozomi. Compatible with any Solana client: just replace your RPC URL with the Nozomi endpoint.

The body is the binary bundle: each signed transaction prefixed with its length as a big-endian u16. Build it with the encoder from the page, or with the shell below from base64-encoded signed transactions.

200 with an empty body means the whole bundle was accepted. Any other status means nothing was sent; the body says why (see ).

Most "Nozomi isn't landing my transactions" reports come down to a handful of causes. Work through this page before opening a ticket.

Transaction Outcomes

A low success rate with a healthy landing rate is an on-chain problem (slippage, competition, program logic), not a delivery problem.

What wins you a slot:

• Your tip. Nozomi orders transactions by tip and uses it to bid with the block builders it routes through (such as Jito and Harmonic), so on a block-builder path your tip drives ordering. When tips are equal, earlier arrival wins.

• Your priority fee. This matters on its own when you land through a path that is not a block builder. Whether it helps depends on your strategy, so test it rather than assuming.

When multiple transactions touch the same writable account, they compete in an auction over that conflicting state. More than one can still land in the same slot; your tip wins you position in that auction.

See for how to tune your bid.

• Durable nonces. Block builders may deprioritize durable-nonce transactions because they are associated with spam, so they can hurt landing on some paths (not always). Benchmark your flow with and without durable nonces to see which lands better. See .

• Tip below the minimum. Transactions tipping under the minimum are silently dropped: no error is returned. See .

• Over-requested compute units. If you set a priority fee, it is measured per compute unit, so requesting more compute units than your transaction uses dilutes it. Set a compute unit limit that reflects actual usage.

When you compare two setups, make sure the test is actually valid:

• Do not race two paths with the same durable nonce or the identical signed transaction: only one can land, so the comparison is meaningless.

• Allow a warm-up period on a newly issued key: your priority builds as your landing rate is observed.

• Send each transaction once per key. Fan the same signed transaction out to multiple regions (limits are per-region) rather than duplicating it on one endpoint. See .

A transient invalid instruction data response is usually safe to retry. If it persists, send support the transaction signature.

If you have ruled out the above, open a ticket with example transaction signatures and the slot/epoch you expected them to land in. That lets support trace the delivery path.

How Do I Keep the Connection Alive?

To keep your TCP connection to our server alive and avoid reconnecting, periodically send a request to the /ping endpoint.

Strategy

The server supports persistent connections with a keep-alive timeout of 65 seconds. This means:

• If your connection is idle for more than 65 seconds, it will be closed.

• To keep it open, send any request before that timeout expires.

In normal operation you do not need to tear down and re-establish the connection. Keep one warm connection open and reuse it for every submission.

We recommend using the /ping endpoint:

GET /ping

This endpoint is lightweight, fast, and designed specifically to maintain your connection.

Send a request to /ping every 60 seconds to keep the connection alive reliably.

• This is not a health check; it's just a way to prevent idle disconnects.

• Avoid pinging more often than needed.

• Reusing one warm connection is the lowest-latency setup. If your workload genuinely cannot keep a connection open and has to reconnect frequently, the reconnects more cheaply.

Submit multiple raw Solana transactions in a single request using a compact binary format. Reduces per-request overhead when you have multiple transactions ready to send.

Request

The body is a concatenation of length-prefixed transactions. No JSON, no separators.

Each length prefix is a big-endian u16 indicating the size of the following transaction bytes.

Returns an empty body with 200 OK when all transactions are accepted.

All error responses are plain text with a descriptive message.

sendBatch is stream-processed: transactions are forwarded as they are parsed. If transaction N fails, transactions 1 through N-1 may already be accepted. There is no rollback.

Always track transaction signatures client-side before submitting so you can reconcile partial success.

Batch Send is the lowest-overhead submission path (compact binary, no JSON, no per-transaction wrapper), which makes it the fastest option even for a single transaction. Use it when you want the lowest latency, and especially when you have multiple transactions ready to submit and want to minimize HTTP round trips.

Because responses carry no transaction signature, compute and track signatures client-side before submitting, then verify landing on-chain or in the dashboard.

For a drop-in Solana RPC replacement that returns a signature, use instead. For the lowest latency overall, send batches over a direct http:// endpoint on a warm connection (see ).

Authentication

All requests require your API key passed as a query parameter:

?c=<YOUR_API_KEY>

Don't have an API key yet? Create one in the dashboard. Sign up →

There is no IP whitelisting. Access is controlled entirely by the API key. A 401 response always means the key is missing or invalid, never that your IP is blocked.

API Paths

Auto-routed is recommended for most users. It will always route your request to the closest regional server.

Example: https://nozomi.temporal.xyz/api/sendTransaction2?c=<YOUR_API_KEY>

Nozomi offers several ways to submit. They differ in overhead, not in queue priority: your decides priority regardless of method.

For the absolute lowest latency, use Batch Send over a direct http:// endpoint on a warm, reused connection (see Best Practices below).

Pin to a specific datacenter for lowest latency if you are co-located. Each region is available as a direct connection or through Cloudflare.

Direct endpoints support both http:// and https://. Cloudflare endpoints support https:// only.

All servers run custom hardware modifications.

Direct endpoints connect straight to the Nozomi server with no intermediary. This gives the lowest possible latency for servers and co-located infrastructure. Direct endpoints also let you connect over plain http://, which is the fastest option, because https:// (TLS) has to encrypt every transaction you send, adding latency to each request. Use http:// for lowest latency; use https:// only when you need encryption in transit.

Cloudflare endpoints route through Cloudflare's network before reaching Nozomi. Residential ISPs often have better backbone connectivity to Cloudflare's edge than to individual datacenters, which can make proxied endpoints faster for users on home or mobile connections. Cloudflare also handles TLS termination at the edge, reducing handshake latency.

Use direct if you are running from a datacenter or VPS with good peering. Use Cloudflare if you are on a residential connection, have variable network quality, or are building a browser-based application.

For latency-critical workloads:

• Use Batch Send over a direct http:// endpoint. Plain HTTP avoids per-transaction TLS encryption; batch avoids JSON and per-request overhead.

• Co-locate near your target region and pin to it. Latency introduced before your request reaches Nozomi (your client → the region) can decide races that Nozomi cannot fix downstream.

• Keep one warm connection open and reuse it. Establishing a new connection per transaction pays the handshake cost every time. See . If your workload genuinely cannot hold a connection open, consider the .

For the highest landing probability, send the same transaction to multiple regional endpoints simultaneously. Rate limits are applied per region, so sending the same transaction to multiple regions will not count against your rate limit. It effectively multiplies your throughput and adds redundancy.

Nozomi also cross-forwards internally between regional servers, so the Regions view in the dashboard reflects where your transactions landed, not the endpoints you submitted to.

Use a single API key and send each transaction once per key (per region). Splitting traffic across multiple keys, or rotating keys with a delay, does not improve landing. It raises your failure/spam rate and can hurt your . If you need more throughput, request a higher rate limit (see ).

If you are integrating Nozomi into a browser-based application:

• Send each transaction to both a direct and a Cloudflare endpoint at the same time. Network conditions vary across users: some will be faster through Cloudflare, others through a direct connection. Sending to both ensures the fastest path wins.

• Use API v2 or Batch Send with Content-Type: text/plain or application/octet-stream to skip the CORS preflight OPTIONS request. Standard JSON-RPC with Content-Type: application/json triggers a preflight that adds 50–100ms of latency.

Submit a group of 1–4 signed transactions as one atomic unit. Either every transaction in the bundle lands in the same slot, in the order you sent them, or none of them lands. Use it when one transaction only makes sense if another one landed first: a setup step followed by a swap, a swap followed by your own backrun, or a position change followed by a cleanup.

Bundles use the same compact binary framing as Batch Send. The difference is the guarantee: Batch Send forwards each transaction independently, while Send Bundle delivers the whole group to block builders as one unit.

Request

Send Bundle is available on every , over http:// and https://.

The body is a concatenation of length-prefixed transactions. No JSON, no base64, no outer count, no separators. Order matters: transactions land in the order they appear in the body.

Each length prefix is a big-endian u16 giving the size of the following signed transaction bytes. A zero length, a truncated final transaction, or trailing bytes rejects the whole request.

At least one transaction in the bundle must pay a of at least your account's minimum (default 0.001 SOL) and never less than 1,001 lamports. The other transactions may be untipped. Tip exemptions do not apply to bundles.

The tip can be in any member, but it is common to put it in the first. Because the tip is an instruction inside your own transaction, you only pay it when the bundle lands. Rotate tip addresses between bundles as you would for single transactions.

Returns an empty body with 200 OK when the whole bundle is accepted and queued for delivery. Landing is determined asynchronously; compute and track your signatures client-side before submitting, then confirm on-chain or in the dashboard.

Unlike Batch Send, a bundle is validated in full before anything is queued. There is no partial acceptance: any error below means nothing from that request was sent.

All error bodies are plain text.

• Block builders only. Bundles are delivered to block-builder paths (such as Jito and Harmonic), which are the paths that can guarantee atomic inclusion. They do not go over staked connections or direct-to-leader paths.

• Nozomi appends its own fee transaction. You may see one extra small transaction from Nozomi immediately after your members in the block. Your transactions are delivered byte-for-byte as you signed them.

• Once per builder by default. A bundle is submitted once to each eligible block builder. If your strategy needs repeated resubmission until the blockhash expires, ask support to configure it for your key.

• Sign every member with the same recent blockhash so they expire together. Durable-nonce members are accepted, including bundles where every member uses a durable nonce; see the note on durable nonces in .

• Put transactions in the body in the order they must execute.

• Keep each member's compute-unit limit close to what it uses. Bundles compete for block space as a unit.

• Do not include a transaction that may already have landed on its own. If it confirms before the bundle is delivered, the bundle is dropped.

Use Send Bundle when correctness depends on ordering or all-or-nothing execution across several transactions. If you simply have several independent transactions to submit, use : it is lower overhead, has no per-bundle size cap, and lands each transaction on whichever path is fastest.

From a browser, application/octet-stream skips the CORS preflight OPTIONS request, the same as Batch Send.