Optimizing Performance
In Syncro Sender by P2P.ORG, tips and priority fees 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
ComputeUnitPriceviaComputeBudgetInstructionfor 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-Afterheaders on 429 responses
What's next?
Updated about 4 hours ago