> For the complete documentation index, see [llms.txt](https://use.temporal.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://use.temporal.xyz/nozomi/tipping-and-faq.md). # 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 | | -------------------------------- | --------------------------------------------------------------------------------- | | Block builder (Jito or Harmonic) | Tip is forwarded to the third-party block builder your transaction routes through | | Staked connections | Tip pays for Nozomi's staked connections | ## 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](/nozomi/tip-stream.md) (`/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](/nozomi/faq.md#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. | # | Address | | -- | --------------------------------------------- | | 1 | `TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq` | | 2 | `noz3jAjPiHuBPqiSPkkugaJDkJscPuRhYnSpbi8UvC4` | | 3 | `noz3str9KXfpKknefHji8L1mPgimezaiUyCHYMDv1GE` | | 4 | `noz6uoYCDijhu1V7cutCpwxNiSovEwLdRHPwmgCGDNo` | | 5 | `noz9EPNcT7WH6Sou3sr3GGjHQYVkN3DNirpbvDkv9YJ` | | 6 | `nozc5yT15LazbLTFVZzoNZCwjh3yUtW86LoUyqsBu4L` | | 7 | `nozFrhfnNGoyqwVuwPAW4aaGqempx4PU6g6D9CJMv7Z` | | 8 | `nozievPk7HyK1Rqy1MPJwVQ7qQg2QoJGyP71oeDwbsu` | | 9 | `noznbgwYnBLDHu8wcQVCEw6kDrXkPdKkydGJGNXGvL7` | | 10 | `nozNVWs5N8mgzuD3qigrCG2UoKxZttxzZ85pvAQVrbP` | | 11 | `nozpEGbwx4BcGp6pvEdAh1JoC2CQGZdU6HbNP1v2p6P` | | 12 | `nozrhjhkCr3zXT3BiT4WCodYCUFeQvcdUkM7MqhKqge` | | 13 | `nozrwQtWhEdrA6W8dkbt9gnUaMs52PdAv5byipnadq3` | | 14 | `nozUacTVWub3cL4mJmGCYjKZTnE9RbdY5AP46iQgbPJ` | | 15 | `nozWCyTPppJjRuw2fpzDhhWbW355fzosWSzrrMYB1Qk` | | 16 | `nozWNju6dY353eMkMqURqwQEoM3SFgEKC6psLCSfUne` | | 17 | `nozxNBgWohjR75vdspfxR5H9ceC7XXH99xpxhVGt3Bb` | ## 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://use.temporal.xyz/nozomi/tipping-and-faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.