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

How Prioritization Works

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.

Tuning your bid

• 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 Stream (/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.

Retries

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

{% hint style="info" %} Test with and without durable nonces. Block builders may deprioritize durable-nonce transactions because they are associated with spam, so a durable nonce can hurt landing on some paths. It does not always. If your strategy uses durable nonces, benchmark your flow with and without them to see which lands better for you. {% endhint %}

Tip Addresses

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.

Private Tip Addresses

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.

Front-Running Protection

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.