> ## Documentation Index
> Fetch the complete documentation index at: https://docs.p2p.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Optimizing Performance

> In Syncro Sender by P2P.ORG,  and  serve different purposes. For best results, include both a tip and a priority fee in your transaction.

|                 | Tips                                    | Priority Fees                                             |
| --------------- | --------------------------------------- | --------------------------------------------------------- |
| **Purpose**     | Pay for Syncro Sender access            | Pay Solana validators for scheduling priority             |
| **Recipient**   | P2P.org tip accounts                    | Block-producing validator                                 |
| **Instruction** | `SystemProgram.transfer` to tip account | `ComputeBudgetInstruction.SetComputeUnitPrice`            |
| **Required?**   | Yes (both endpoints)                    | No, but strongly recommended for competitive transactions |

## HTTP keep-alive and connection management

Syncro Sender's server keep-alive timeout is **30 seconds**. Reuse connections to avoid TCP/TLS handshake overhead on every request.

## Retry strategy

Syncro Sender's multi-channel delivery means a single `sendTransaction` call already routes through multiple channels. This provides built-in redundancy without client-side retries for delivery.

### When to retry

| Response                         | Action                                              |
| -------------------------------- | --------------------------------------------------- |
| **HTTP 429** (rate limited)      | Wait for `Retry-After` seconds, then retry          |
| **HTTP 400** (bad request)       | Fix the request—do not retry                        |
| **HTTP 500** (server error)      | Retry with exponential backoff                      |
| **Success** (signature returned) | Transaction was submitted; monitor for confirmation |
| **Network error**                | Retry with backoff                                  |

### Safe to resubmit

Solana is idempotent on transaction signatures — submitting the same signed transaction multiple times is safe. The network will only process it once.

## Best practices checklist

* **Use `skipPreflight: true`** — preflight checks add latency; Syncro Sender handles delivery, not simulation
* **Use base64 encoding** — this is the default and recommended encoding for transaction data
* **Reuse HTTP connections** — enable keep-alive and connection pooling to reduce latency
* **Add a priority fee** — set `ComputeUnitPrice` via `ComputeBudgetInstruction` for validator scheduling priority
* **Include a sufficient tip** — required for both endpoints; ensure the tip meets the minimum
* **Use a separate RPC for reads** — fetch blockhashes, simulate, and confirm transactions on a standard RPC endpoint, if you are using the public endpoint
* **Handle rate limits gracefully** — respect `Retry-After` headers on 429 responses


## Related topics

- [Pricing, Rate Limits & Support](/docs/syncro-sender-pricing-rate-limits.md)