1 of 24

Temporal Docs

Nozomi

Introduction

Land transactions faster and more consistently.

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.

Regions & Endpoints

Regional endpoint URLs for all Nozomi APIs.

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

Method

Path

Response

Type

URL

Notes

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.

Method

Overhead

Returns signature?

Notes

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.

Region

Direct

Cloudflare

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

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.

Tipping

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

Delivery path

What happens

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.

Address

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.

JSON-RPC

Standard Solana JSON-RPC transaction submission through Nozomi.

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

Request

Field

Value

Method

POST

Path

Important: Solana defaults to base58 encoding. You must explicitly set "encoding": "base64" or you will get malformed transaction errors.

Returns the transaction signature as a JSON-RPC result on success.

Use JSON-RPC when you want a drop-in replacement for your existing Solana RPC. It returns a transaction signature and works with standard Solana client libraries.

For lower latency in browser clients or performance-sensitive backends, consider instead.

Rust

Use full service RPC for fetching latest blockhash. Nozomi only supports sendTransaction.

use solana_client::rpc_client::RpcClient;
use solana_sdk::{message::Instruction, pubkey, pubkey::Pubkey, signature::Keypair, signer::Signer, transaction::Transaction};

const NOZOMI_ENDPOINT: &str = "https://nozomi.temporal.xyz/?c=<YOUR_API_KEY>";
const NOZOMI_TIP: Pubkey = pubkey!("TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq");
const MIN_TIP_AMOUNT: u64 = 1_000_000;

const SOLANA_RPC_ENDPOINT: &str = "https://api.mainnet-beta.solana.com";

fn send_nozomi_txn(ixns: &mut Vec<Instruction>, signer: &Keypair, nozomi_rpc_client: &RpcClient, solana_rpc_client: &RpcClient) {
    let tip_ix = solana_system_interface::instruction::transfer(&signer.pubkey(), &NOZOMI_TIP, MIN_TIP_AMOUNT);
    ixns.push(tip_ix);

    let blockhash = solana_rpc_client.get_latest_blockhash().unwrap();
    let tx = Transaction::new_signed_with_payer(ixns, Some(&signer.pubkey()), &[signer], blockhash);

    nozomi_rpc_client.send_transaction(&tx).unwrap();
}

fn build_ixns() -> Vec<Instruction> {
    // your instruction building logic here..
    vec![]
}

fn main() {
    let nozomi_rpc_client = RpcClient::new(NOZOMI_ENDPOINT.to_string());

    let solana_rpc_client = RpcClient::new(SOLANA_RPC_ENDPOINT.to_string());

    let keypair = Keypair::new();

    let mut ixns = build_ixns();

    send_nozomi_txn(&mut ixns, &keypair, &nozomi_rpc_client, &solana_rpc_client);
}

Python

Use full service RPC for fetching latest blockhash.. Nozomi only supports sendTransaction.

import asyncio

from typing import List

from solders.pubkey import Pubkey
from solders.keypair import Keypair
from solders.signature import Signature
from solders.instruction import Instruction
from solana.transaction import Transaction
from solders.system_program import transfer, TransferParams

from solana.rpc.async_api import AsyncClient

NOZOMI_ENDPOINT = "https://nozomi.temporal.xyz/?c=<YOUR_API_KEY>"
NOZOMI_TIP = Pubkey.from_string("TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq")
MIN_TIP_AMOUNT = 1_000_000

SOLANA_RPC_ENDPOINT = "https://api.mainnet-beta.solana.com"

async def send_nozomi_txn(ixns: List[Instruction], signer: Keypair, nozomi_rpc_client: AsyncClient, solana_rpc_client: AsyncClient) -> Signature:
    tip_ixn = transfer(TransferParams(
        from_pubkey=signer.pubkey(),
        to_pubkey=NOZOMI_TIP,
        lamports=MIN_TIP_AMOUNT
    ))
    ixns.append(tip_ixn)

    blockhash = (await solana_rpc_client.get_latest_blockhash()).value.blockhash
    txn = Transaction()

    for ixn in ixns:
        txn.add(ixn)

    # solanapy does not expose an encoding option via TxOpts
    return (await nozomi_rpc_client.send_transaction(txn, signer, recent_blockhash=blockhash)).value

def build_ixns() -> List[Instruction]:
    # your instruction building logic here..
    return []

async def main():
    nozomi_rpc_client = AsyncClient(NOZOMI_ENDPOINT)

    solana_rpc_client = AsyncClient(SOLANA_RPC_ENDPOINT)

    # replace with actual keypair loading logic
    signer = Keypair()

    ixns = build_ixns()

    signature = await send_nozomi_txn(ixns, signer, nozomi_rpc_client, solana_rpc_client)

    print(f"Transaction sent with signature: {signature}")

if __name__ == "__main__":
    asyncio.run(main())

JavaScript

Use full service RPC for fetching latest blockhash. Nozomi only supports sendTransaction.

import { Connection, PublicKey, Keypair, SystemProgram, TransactionMessage, VersionedTransaction } from "@solana/web3.js";

const NOZOMI_ENDPOINT = "https://nozomi.temporal.xyz/?c=<YOUR_API_KEY>";
const NOZOMI_TIP = new PublicKey("TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq");
const MIN_TIP_AMOUNT = 1_000_000;

const SOLANA_RPC_ENDPOINT = "https://api.mainnet-beta.solana.com";

async function sendNozomiTxn(ixns, signer, nozomiRpcClient, solanaRpcClient) {
    const tipIxn = SystemProgram.transfer({
        fromPubkey: signer.publicKey,
        toPubkey: NOZOMI_TIP,
        lamports: MIN_TIP_AMOUNT
    });
    ixns.push(tipIxn);

    const { blockhash } = await solanaRpcClient.getLatestBlockhash();

    const messageV0 = new TransactionMessage({
        payerKey: signer.publicKey,
        recentBlockhash: blockhash,
        instructions: ixns,
    }).compileToV0Message();

    const versionedTxn = new VersionedTransaction(messageV0);

    versionedTxn.sign([signer]);

    return await nozomiRpcClient.sendTransaction(versionedTxn);
}

function buildIxns() {
    // your instruction building logic here..
    return [];
}

async function main() {
    const nozomiRpcClient = new Connection(NOZOMI_ENDPOINT);

    const solanaRpcClient = new Connection(SOLANA_RPC_ENDPOINT);

    // replace with actual keypair loading logic
    const signer = Keypair.generate();

    const ixns = buildIxns();

    const signature = await sendNozomiTxn(ixns, signer, nozomiRpcClient, solanaRpcClient);

    console.log(`Transaction sent with signature: ${signature}`);
}

main().catch(err => {
    console.error(err);
});

TypeScript

Use full service RPC for fetching latest blockhash. Nozomi only supports sendTransaction.

import { Connection, PublicKey, Keypair, TransactionInstruction, SystemProgram, TransactionMessage, VersionedTransaction, TransactionSignature } from "@solana/web3.js";

const NOZOMI_ENDPOINT = "https://nozomi.temporal.xyz/?c=<YOUR_API_KEY>";
const NOZOMI_TIP = new PublicKey("TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq");
const MIN_TIP_AMOUNT = 1_000_000;

const SOLANA_RPC_ENDPOINT = "https://api.mainnet-beta.solana.com";

async function sendNozomiTxn(ixns: TransactionInstruction[], signer: Keypair, nozomiRpcClient: Connection, solanaRpcClient: Connection): Promise<TransactionSignature> {
    const tipIxn = SystemProgram.transfer({
        fromPubkey: signer.publicKey,
        toPubkey: NOZOMI_TIP,
        lamports: MIN_TIP_AMOUNT
    });
    ixns.push(tipIxn);

    const { blockhash } = await solanaRpcClient.getLatestBlockhash();

    const messageV0 = new TransactionMessage({
        payerKey: signer.publicKey,
        recentBlockhash: blockhash,
        instructions: ixns,
    }).compileToV0Message();

    const versionedTxn = new VersionedTransaction(messageV0);

    versionedTxn.sign([signer]);

    return await nozomiRpcClient.sendTransaction(versionedTxn);
}

function buildIxns(): TransactionInstruction[] {
    // your instruction building logic here..
    return [];
}

async function main() {
    const nozomiRpcClient = new Connection(NOZOMI_ENDPOINT);

    const solanaRpcClient = new Connection(SOLANA_RPC_ENDPOINT);

    // replace with actual keypair loading logic
    const signer = Keypair.generate();

    const ixns = buildIxns();

    const signature = await sendNozomiTxn(ixns, signer, nozomiRpcClient, solanaRpcClient);

    console.log(`Transaction sent with signature: ${signature}`);
}

main().catch(err => {
    console.error(err);
});

cURL

Please specify base64 encoding, Solana recognizes base58 as default. If you do not specify, you might get malformed transaction error

API v2

High-performance transaction submission with reduced overhead.

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

Request

Field

Value

Method

POST

Path

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.

Advantage

Detail

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.

Rust

Use full service RPC for fetching latest blockhash.

Python

Use full service RPC for fetching latest blockhash.

import aiohttp
import asyncio
import base64

from typing import List

from solders.pubkey import Pubkey
from solders.keypair import Keypair
from solders.instruction import Instruction
from solders.transaction import Transaction
from solders.system_program import transfer, TransferParams
from solders.hash import Hash

from solana.rpc.async_api import AsyncClient

NOZOMI_ENDPOINT = "https://nozomi.temporal.xyz/api/sendTransaction2?c=<YOUR_API_KEY>"
NOZOMI_TIP = Pubkey.from_string("TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq")
MIN_TIP_AMOUNT = 1_000_000

SOLANA_RPC_ENDPOINT = "https://api.mainnet-beta.solana.com"

async def send_nozomi_txn(
    ixns: List[Instruction],
    signer: Keypair,
    nozomi_endpoint: str,
    solana_rpc_client: AsyncClient
) -> None:
    tip_ixn = transfer(TransferParams(
        from_pubkey=signer.pubkey(),
        to_pubkey=NOZOMI_TIP,
        lamports=MIN_TIP_AMOUNT
    ))
    ixns.append(tip_ixn)

    blockhash_resp = await solana_rpc_client.get_latest_blockhash()
    blockhash = blockhash_resp.value.blockhash

    txn = Transaction.new_signed_with_payer(
        ixns,
        signer.pubkey(),
        [signer],
        blockhash
    )

    txn_bytes = bytes(txn)
    txn_base64 = base64.b64encode(txn_bytes).decode('utf-8')

    async with aiohttp.ClientSession() as session:
        async with session.post(
            nozomi_endpoint,
            headers={"Content-Type": "text/plain"},
            data=txn_base64
        ) as response:
            # api v2 does not return a signature, just check for success
            if response.status >= 200 and response.status < 300:
                print("Transaction sent successfully")
            else:
                error_text = await response.text()
                raise Exception(f"Transaction failed with status {response.status}: {error_text}")

def build_ixns() -> List[Instruction]:
    # your instruction building logic here..
    return []

async def main():
    solana_rpc_client = AsyncClient(SOLANA_RPC_ENDPOINT)

    # replace with actual keypair loading logic
    signer = Keypair()

    ixns = build_ixns()

    await send_nozomi_txn(ixns, signer, NOZOMI_ENDPOINT, solana_rpc_client)

if __name__ == "__main__":
    asyncio.run(main())

JavaScript

Use full service RPC for fetching latest blockhash.

import { Connection, PublicKey, Keypair, SystemProgram, TransactionMessage, VersionedTransaction } from "@solana/web3.js";

const NOZOMI_ENDPOINT = "https://nozomi.temporal.xyz/api/sendTransaction2?c=<YOUR_API_KEY>";
const NOZOMI_TIP = new PublicKey("TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq");
const MIN_TIP_AMOUNT = 1_000_000;

const SOLANA_RPC_ENDPOINT = "https://api.mainnet-beta.solana.com";

async function sendNozomiTxn(ixns, signer, nozomiEndpoint, solanaRpcClient) {
    const tipIxn = SystemProgram.transfer({
        fromPubkey: signer.publicKey,
        toPubkey: NOZOMI_TIP,
        lamports: MIN_TIP_AMOUNT
    });
    ixns.push(tipIxn);

    const { blockhash } = await solanaRpcClient.getLatestBlockhash();

    const messageV0 = new TransactionMessage({
        payerKey: signer.publicKey,
        recentBlockhash: blockhash,
        instructions: ixns,
    }).compileToV0Message();

    const versionedTxn = new VersionedTransaction(messageV0);
    versionedTxn.sign([signer]);

    const txnBytes = versionedTxn.serialize();
    const txnBase64 = Buffer.from(txnBytes).toString('base64');

    const response = await fetch(nozomiEndpoint, {
        method: 'POST',
        headers: {
            'Content-Type': 'text/plain',
        },
        body: txnBase64
    });

    if (!response.ok) {
        const errorText = await response.text();
        throw new Error(`Transaction failed with status ${response.status}: ${errorText}`);
    }

    // api v2 does not return a signature, just check for success
    console.log('Transaction sent successfully');
}

function buildIxns() {
    // your instruction building logic here..
    return [];
}

async function main() {
    const solanaRpcClient = new Connection(SOLANA_RPC_ENDPOINT);

    // replace with actual keypair loading logic
    const signer = Keypair.generate();

    const ixns = buildIxns();

    await sendNozomiTxn(ixns, signer, NOZOMI_ENDPOINT, solanaRpcClient);
}

main().catch(err => {
    console.error(err);
});

TypeScript

Use full service RPC for fetching latest blockhash.

cURL

Batch Send

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

Field

Value

Method

POST

Path

Constraint

Value

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.

Status

Meaning

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

JavaScript

function encodeBatch(rawTxs) {
  if (rawTxs.length === 0 || rawTxs.length > 16) {
    throw new Error("batch must contain 1-16 transactions");
  }

  let total = 0;
  for (const tx of rawTxs) {
    if (tx.length < 66 || tx.length > 1232) {
      throw new Error(`invalid tx size: ${tx.length}`);
    }
    total += 2 + tx.length;
  }

  const out = Buffer.allocUnsafe(total);
  let off = 0;
  for (const tx of rawTxs) {
    out.writeUInt16BE(tx.length, off);
    off += 2;
    Buffer.from(tx).copy(out, off);
    off += tx.length;
  }
  return out;
}

async function sendBatch(endpoint, apiKey, rawTxs) {
  const body = encodeBatch(rawTxs);
  const res = await fetch(
    `${endpoint}/api/sendBatch?c=${apiKey}`,
    {
      method: "POST",
      headers: { "Content-Type": "application/octet-stream" },
      body,
    }
  );

  if (!res.ok) {
    const text = await res.text();
    throw new Error(`sendBatch failed (${res.status}): ${text}`);
  }
}

cURL

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

QUIC Client

Low-overhead QUIC submission for workloads that cannot hold a persistent connection open.

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:

Tip Stream

Stream Nozomi Tip Floors by Percentile

REST Endpoint

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

WebSocket

Schema

TCP Keep-Alive

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.

Troubleshooting

Why a transaction didn't land, and how to diagnose it.

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

Outcome

Meaning

Landed

The transaction was included in a block.

Succeeded

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 .

Status

Meaning

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.

FAQ

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

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:

Fan out across regions. Limits are per region, so sending the same signed transaction to several regional endpoints multiplies your effective throughput. See .
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.
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. 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.

use solana_client::rpc_client::RpcClient; use solana_sdk::{message::Instruction, pubkey, pubkey::Pubkey, signature::Keypair, signer::Signer, transaction::Transaction}; use base64::{Engine as _, engine::general_purpose}; const NOZOMI_ENDPOINT: &str = "https://nozomi.temporal.xyz/api/sendTransaction2?c=<YOUR_API_KEY>"; const NOZOMI_TIP: Pubkey = pubkey!("TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq"); const MIN_TIP_AMOUNT: u64 = 1_000_000; const SOLANA_RPC_ENDPOINT: &str = "https://api.mainnet-beta.solana.com"; fn send_nozomi_txn( ixns: &mut Vec<Instruction>, signer: &Keypair, nozomi_endpoint: &str, solana_rpc_client: &RpcClient ) -> Result<(), Box<dyn std::error::Error>> { let tip_ixn = solana_system_interface::instruction::transfer( &signer.pubkey(), &NOZOMI_TIP, MIN_TIP_AMOUNT ); ixns.push(tip_ixn); let blockhash = solana_rpc_client.get_latest_blockhash()?; let txn = Transaction::new_signed_with_payer( ixns, Some(&signer.pubkey()), &[signer], blockhash ); let txn_bytes = bincode::serialize(&txn)?; let txn_base64 = general_purpose::STANDARD.encode(&txn_bytes); let client = reqwest::blocking::Client::new(); let response = client .post(nozomi_endpoint) .header("Content-Type", "text/plain") .body(txn_base64) .send()?; // api v2 does not return a signature, just check for success if response.status().is_success() { Ok(()) } else { Err(Box::new(response.error_for_status().unwrap_err())) } } fn build_ixns() -> Vec<Instruction> { // your instruction building logic here.. vec![] } fn main() { let solana_rpc_client = RpcClient::new(SOLANA_RPC_ENDPOINT.to_string()); // replace with actual keypair loading logic let signer = Keypair::new(); let mut ixns = build_ixns(); if send_nozomi_txn( &mut ixns, &signer, NOZOMI_ENDPOINT, &solana_rpc_client ).is_ok() { println!("Transaction sent successfully"); } }

import { Connection, PublicKey, Keypair, TransactionInstruction, SystemProgram, TransactionMessage, VersionedTransaction } from "@solana/web3.js"; const NOZOMI_ENDPOINT = "https://nozomi.temporal.xyz/api/sendTransaction2?c=<YOUR_API_KEY>"; const NOZOMI_TIP = new PublicKey("TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq"); const MIN_TIP_AMOUNT = 1_000_000; const SOLANA_RPC_ENDPOINT = "https://api.mainnet-beta.solana.com"; async function sendNozomiTxn( ixns: TransactionInstruction[], signer: Keypair, nozomiEndpoint: string, solanaRpcClient: Connection ): Promise<void> { const tipIxn = SystemProgram.transfer({ fromPubkey: signer.publicKey, toPubkey: NOZOMI_TIP, lamports: MIN_TIP_AMOUNT }); ixns.push(tipIxn); const { blockhash } = await solanaRpcClient.getLatestBlockhash(); const messageV0 = new TransactionMessage({ payerKey: signer.publicKey, recentBlockhash: blockhash, instructions: ixns, }).compileToV0Message(); const versionedTxn = new VersionedTransaction(messageV0); versionedTxn.sign([signer]); const txnBytes = versionedTxn.serialize(); const txnBase64 = Buffer.from(txnBytes).toString('base64'); const response = await fetch(nozomiEndpoint, { method: 'POST', headers: { 'Content-Type': 'text/plain', }, body: txnBase64 }); if (!response.ok) { const errorText = await response.text(); throw new Error(`Transaction failed with status ${response.status}: ${errorText}`); } // api v2 does not return a signature, just check for success console.log('Transaction sent successfully'); } function buildIxns(): TransactionInstruction[] { // your instruction building logic here.. return []; } async function main() { const solanaRpcClient = new Connection(SOLANA_RPC_ENDPOINT); // replace with actual keypair loading logic const signer = Keypair.generate(); const ixns = buildIxns(); await sendNozomiTxn(ixns, signer, NOZOMI_ENDPOINT, solanaRpcClient); } main().catch(err => { console.error(err); });

Temporal Docs

Nozomi

Introduction

How It Works

Who Should Use It

Regions & Endpoints

Authentication

API Paths

Tipping

Overview

How Tips Are Used

JSON-RPC

Request

Rust

Python

JavaScript

TypeScript

cURL

API v2

Request

Rust

Python

JavaScript

TypeScript

cURL

Batch Send

Request

JavaScript

cURL

QUIC Client

Tip Stream

REST Endpoint

WebSocket

Schema

TCP Keep-Alive

How Do I Keep the Connection Alive?

Strategy

Troubleshooting

Transaction Outcomes

FAQ

How do I get access?

Support & Community

Introduction

How It Works

Who Should Use It

cURL

cURL

Get Access

Community & Support

Python

cURL

Tip Stream

REST Endpoint

WebSocket

Schema

Regions & Endpoints

Authentication

API Paths

JSON-RPC

Request

Rust

TypeScript

QUIC Client

When to Use It

Notes

Request Body

Response

When to Use

JavaScript

Python

JavaScript

Base URLs

Choosing a Submission Method

Regional Endpoints

Direct vs Cloudflare

Best Practices

Lowest latency

Send to multiple regions

One key, not many

Frontend clients