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.

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 JavaScript page, or with the shell below from base64-encoded signed transactions.

# tx1.b64 and tx2.b64 hold the base64 of each signed transaction; tx1 carries the tip.
: > bundle.bin
for f in tx1.b64 tx2.b64; do
  base64 -d "$f" > tx.bin
  len=$(stat -c %s tx.bin)
  printf "$(printf '\\x%02x\\x%02x' $((len >> 8)) $((len & 255)))" >> bundle.bin
  cat tx.bin >> bundle.bin
done

curl -X POST \
  "https://nozomi.temporal.xyz/api/sendBundle?c=YOUR_API_KEY" \
  -H "Content-Type: application/octet-stream" \
  --data-binary @bundle.bin

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

REST Endpoint

curl https://api.nozomi.temporal.xyz/tip_floor

WebSocket

wscat -c wss://api.nozomi.temporal.xyz/tip_stream

Schema

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.

Overview

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.

How Tips Are Used

Your tip is the primary lever. Nozomi orders the transactions it holds by tip, and Nozomi uses your tip to bid on your behalf with the block builders it routes through (such as Jito and Harmonic). On a block-builder path, your tip is what drives your ordering. When two transactions tip the same amount, the one that arrived first wins, so latency still matters.

Your priority fee matters on its own when your transaction lands through a path that is not a block builder. Whether it helps depends on your strategy and where your flow tends to land, so it is worth testing rather than assuming it does.

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 is what wins you position in that auction.

• Start with 100% of your bid in the Nozomi tip.

• Only add a priority fee if you observe it improving landing for your specific strategy.

• If you do set a priority fee, it is evaluated per compute unit (compute unit price × compute unit limit), so over-requesting compute units dilutes it. Set a compute unit limit that reflects what your transaction actually uses.

Check the current (/tip_floor) to see what tips are landing right now. Those percentiles are landed tips across all users, not a landing-probability curve. The tip you actually need scales with how contended the accounts you touch are.

Nozomi automatically retries your transaction against a recent blockhash until it is either confirmed or the blockhash expires. Higher-tipped transactions are retried more aggressively. You do not need to implement retry logic on your end. Client-side resubmission of the same transaction wastes your rate limit and lowers your .

Send your tip to any one of the addresses below. Rotate to a different random address for each transaction: this avoids write lock contention on a single account and improves landing rates. Distributing across fee-payer accounts helps too, since a shared fee-payer serializes the same way a shared tip account does.

If you reference tip addresses through an address lookup table, every address in that table must be a recognized Nozomi tip account; an unrecognized address will not be credited as a tip.

Dedicated (private) tip addresses are not self-serve. They are reserved for high-volume clients and partnerships and are provisioned case by case on request. Reach out through the dashboard with your expected volume and use case. Once approved, they appear in your dashboard.

At low or moderate volume, dedicated addresses do not improve landing: rotating the public addresses above already avoids write-lock contention. They matter only at high submission rates, and they let Nozomi attribute your flow for analytics.

Default Nozomi keys are optimized for speed and are not sandwich-protected. For protection, Nozomi offers a separate MEV Protect key that routes your transactions only through a whitelist of trusted validators, keeping them away from adversarial validators.

• It is available on request: ask through the dashboard's live chat.

• There is a tradeoff: routing through a smaller validator set is slower and carries a higher chance of expiration. The protection level is tunable: more protection means more latency.

• Protection is reduced, not eliminated.

For additional protection on swaps, regardless of which key you use:

• Set a strict slippage tolerance.

• Calculate and enforce minAmountOut in your transaction instructions.

If you were using an MEV Protect key and still believe you were sandwiched, report it to support with the transaction signatures so it can be investigated.

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

Request

The body must be base64. API v2 does not accept raw binary transaction bytes. If you want to submit raw binary, use , which works for a single transaction too.

Returns an empty body with 200 OK on success. Does not return a transaction signature. Compute and track the signature client-side before submitting, then verify landing on-chain or in the dashboard.

Use API v2 when you don't need the transaction signature returned in the response, and want the lowest possible submission latency. Ideal for browser-based applications and high-frequency backends.

If you need a transaction signature in the response, use instead.

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

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.

Nozomi provides a native QUIC client for submitting transactions:

QUIC is not faster than the HTTP endpoints when you keep a warm connection open. Over a persistent, reused TCP connection, over a direct http:// endpoint is the lowest-latency path (see ).

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.

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

Members may be legacy, v0 or v1 transactions in any mix; each is checked against its own version's limit.

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 ).

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.

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.

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.

Rejections specific to the new transaction format (-32005..-32009 on JSON-RPC, 400/503 on the binary APIs) are listed on the page. -32006, "not active on this cluster", means the SIMD-0296 feature gate is not live yet.

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.

Nozomi accepts the new Solana transaction format defined by SIMD-0296 and serialized per SIMD-0385, alongside legacy and v0 transactions. Every submission method recognises it, nothing changes in how you authenticate, tip, or choose an endpoint.

Availability

Nozomi admits v1 transactions only while the SIMD-0296 feature gate is active on mainnet. Before activation every v1 submission is rejected with a specific error (see below), so you can ship v1 support ahead of time and let the network turn it on. Nozomi checks the feature gate itself; there is nothing to enable on your key.

How Nozomi tells v1 apart

A v1 transaction starts with the byte 0x81, followed by the signature count. Its signatures sit at the end of the serialized bytes rather than the front. Nozomi reads the version from the first byte, validates the envelope, and treats the transaction like any other from then on: same tip rules, same priority, same delivery.

Encoding

Use base64 everywhere. JSON-RPC requires "encoding": "base64" for every transaction, and for v1 in particular base58 is not supported beyond legacy sizes. API v2 takes the base64 body as before; Batch Send and Send Bundle take raw bytes.

Size limits

v1 transactions may use the full 4,096 bytes the format allows on every method. Legacy and v0 transactions keep their 1,232-byte limit. A transaction over 1,232 bytes must be base64 or raw binary; base58 cannot carry it.

JSON-RPC returns these as error.code in a 200 response. API v2, Batch Send and Send Bundle return the HTTP status with a one-line body.

Everything else behaves as for legacy transactions: 401 for a bad key, 429 for rate limits, 400 for a missing or insufficient tip.

The v1 types live in the solana-message 4.x and solana-transaction 4.x crates, serialized with wincode. This example self-transfers one lamport and tips Nozomi, then posts through API v2.

Points that differ from legacy transactions:

• The compute unit limit and priority fee are fields of TransactionConfig, not ComputeBudget instructions.

• Serialize with wincode, not bincode.

• The signature is the last 64 bytes of the serialized transaction, not the first.

Other SDKs will expose the same format as they add SIMD-0385 support. Nozomi only sees the bytes, so any correctly serialized v1 transaction is accepted.

A single Batch Send or Send Bundle body may mix legacy, v0 and v1 members; each is checked on its own. Nozomi never rewrites your transaction, so a v1 transaction is delivered to the leader exactly as you signed it.

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 . The difference is the guarantee: Batch Send forwards each transaction independently, while Send Bundle delivers the whole group to block builders as one unit.