Skip to main content

Sending Transactions

Optimizing transactions on the Solana network is key to ensuring the highest success rate. In the guide below, we'll cover some common strategies and resources you can use.

Stake-weighted Quality of Service (SWQoS)​

Syndica supports Stake-weighted Quality of Service (SWQoS), a powerful feature that improves transaction success rates by routing your transactions through staked validator infrastructure. SWQoS is enabled by default on Scale and HyperScale plans.

What is SWQoS?​

Stake-weighted QoS allows block producers (leaders) to identify and prioritize transactions that are proxied through staked validators. This provides an additional layer of Sybil resistance and ensures that transactions from higher-quality (higher-stake) validators receive better treatment than those from low-stake or no-stake sources.

Under this model, validators with stake have the right to transmit a proportional percentage of packets to the leader. For example, a validator with 1% stake can transmit up to 1% of the packets, preventing malicious actors with little or no stake from flooding the network and drowning out legitimate transactions.

How Syndica uses SWQoS​

When you use Syndica's Scale or HyperScale plans, all sendTransaction calls are automatically routed through Syndica's staked relay infrastructure, giving your transactions prioritized treatment by block producers on Solana.

Key benefits:

  • Increased landing rate: Higher percentage of transactions successfully included in blocks
  • Lower slot latency: Faster time from transaction submission to on-chain confirmation, measured in slots
  • Particularly effective during periods of high network congestion
Plan-specific details
  • Scale plan: SWQoS enabled by default for all sendTransaction calls
  • Standard plan: SWQoS not included
  • HyperScale plan: SWQoS enabled with customizable configuration

For sendTransaction rate limits by plan, see Rate Limits.

Why transactions fail​

Solana transactions can fail for various reasons. Understanding these common failure modes can help you optimize your transaction submission strategy:

  • Transaction expiration: Solana transactions include a blockhash that expires after a short time (approximately 150 blocks or ~80 seconds). If a transaction isn't processed before its blockhash expires, it will be rejected.

  • Network congestion: During periods of high activity, the network may be processing more transactions than it can handle. This can cause transactions to be dropped before they reach a leader.

  • Priority fees: Transactions without sufficient priority fees may be deprioritized or dropped in favor of higher-paying transactions, especially during congestion.

  • Transaction parameters: Configuration options like skipPreflight, preflightCommitment, and maxRetries can affect the overall success rate. Adjusting these parameters involves trade-offs, and different values may be appropriate for different use cases.

  • RPC infrastructure: For a transaction to succeed, it must be forwarded to an RPC node that is synchronized with the latest state of the blockchain. Therefore the performance, reliability and scalability of the node infrastructure which a dApp uses to submit transactions is critical. With Syndica's SWQoS on Scale and HyperScale plans, your transactions benefit from prioritized routing through staked validator infrastructure.

Helpful resources​

FAQ and Troubleshooting​

What makes Syndica's RPC faster than running my own node?

Requests pass through a global edge with regional caches for frequently accessed Solana data, reducing trips to validators. Cache misses are handled by a managed validator cluster with redundancy and automatic failover. This design typically results in lower and more consistent latency than operating a single node.

How do I know if I'm hitting rate limits?

Rate limit responses return HTTP 429 status codes. You can monitor your usage in the RPC Analytics dashboard. See Observability to learn how to inspect logs and metrics when diagnosing throttling, review Rate Limits and plans/pricing for plan-specific limits, or configure custom rate limits per API key.

Which authentication method should I use?

Both methods work identically—choose based on your use case:

  • URL-embedded is simpler for testing with tools like cURL or Postman.
  • Header-embedded keeps your key out of URL paths, which may be preferable for logging and monitoring systems.

What You Can Do Next​