Quick decision guide: What to look for in a Solana RPC provider for signed transactions
When your dApp or bot submits signed transactions to Solana, the RPC provider you choose directly affects reliability, latency, and security. Before comparing providers, clarify your workload:
- Low-frequency transactions (e.g., a wallet UI submitting a few transactions per user action) can often use a shared public RPC endpoint, but you must handle rate limits and potential downtime.
- High-frequency or automated transactions (e.g., trading bots, NFT minting tools, payment processors) need a dedicated node or a managed RPC with high throughput and low latency.
- Compliance or security-sensitive applications should prefer providers that support API key authentication and do not log or expose transaction payloads unnecessarily.
For most production use cases, a managed RPC provider with API key support is the right balance between cost and reliability. OnFinality offers both shared and dedicated Solana RPC endpoints, with HTTP and WebSocket support. You can evaluate your needs against our RPC pricing and supported networks.
Why signed transactions need special RPC consideration
Solana transactions are signed offline or in the client, then sent to the network via an RPC endpoint. The RPC provider never sees your private key, but it does see the full transaction payload, including the signer's public key and the instructions. This means:
- Privacy: The provider can observe your transaction patterns, but cannot alter them without invalidating the signature.
- Reliability: If the RPC endpoint drops the transaction or returns an error, you must handle retries and fallbacks.
- Security: API keys are used to authenticate requests. If a key leaks, an attacker could spam the endpoint or, in some cases, access sensitive account data.
Therefore, choosing a provider that supports secure API key management and offers robust transaction submission endpoints is essential.
How to evaluate Solana RPC providers for transaction submission
When comparing providers, focus on these criteria:
| Criterion | What to check | Why it matters |
|---|---|---|
| Throughput and rate limits | Requests per second (RPS) allowed on shared vs. dedicated plans | High-frequency transaction submission can hit rate limits, causing dropped transactions. |
| Latency | Geographic distribution and network path to Solana validators | Lower latency reduces the chance of blockhash expiration and improves user experience. |
| Reliability and uptime | Historical uptime, redundancy, and failover mechanisms | Downtime during a critical transaction window can be costly. |
| API key management | Support for multiple keys, rotation, and scoping | Keys should be revocable and not shared across environments. |
| WebSocket support | Availability of wss:// endpoints for real-time account updates |
Useful for monitoring transaction status and account changes. |
| Archive data | Access to historical state and transactions | Needed for analytics or debugging past transactions. |
| Pricing model | Pay-as-you-go vs. subscription, cost per request | Predictable costs are important for high-volume applications. |
OnFinality, for example, provides dedicated Solana nodes that can be configured for high throughput, and our shared RPC includes API key authentication. You can see the full list of supported networks and endpoints on our Solana network page.
Setting up a Solana RPC endpoint with API key authentication
To use a managed RPC provider like OnFinality, you typically create an account, generate an API key, and then use that key in your requests. Here's a conceptual example of how to send a signed transaction to a Solana RPC endpoint using curl:
curl -X POST https://solana.api.onfinality.io/public \
-H "Content-Type: application/json" \
-H "x-api-key: YOUR_API_KEY" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "sendTransaction",
"params": [
"base58-encoded-signed-transaction",
{
"encoding": "base58",
"preflightCommitment": "confirmed"
}
]
}'
Note: The public endpoint shown is for testing; for production, you should use a dedicated endpoint with your API key. Always keep your API key secret and never expose it in client-side code.
Best practices for managing Solana RPC API keys
API keys are the gateway to your RPC usage. Follow these practices to keep them secure:
- Use environment variables: Store keys in server-side environment variables, not in frontend code or public repositories.
- Rotate keys regularly: If you suspect a leak, rotate the key immediately.
- Scope keys to specific endpoints: Some providers allow you to restrict keys to certain networks or methods.
- Monitor usage: Set up alerts for unusual spikes in requests, which could indicate a compromised key.
- Use separate keys for development and production: This limits blast radius if a dev key leaks.
Common pitfalls when sending signed transactions via RPC
Even with a reliable provider, you may encounter issues. Here are common failure modes and how to address them:
-
Blockhash too old: Solana transactions must reference a recent blockhash. If your RPC is slow or you delay sending, the blockhash may expire. Use
getLatestBlockhashand send promptly. - Nonce mismatch: If you use a durable nonce, ensure it is still valid. Nonces can be advanced by other transactions.
- Rate limiting: Shared RPC endpoints may throttle you. Implement exponential backoff and retries.
-
Transaction simulation failure: Use
simulateTransactionbefore sending to catch errors without paying fees. - Network congestion: During high traffic, transactions may be dropped. Consider using priority fees and retrying with a higher fee.
Comparing OnFinality with other Solana RPC providers
When evaluating providers, consider the full picture. OnFinality offers:
- Managed shared RPC with API key authentication and WebSocket support.
- Dedicated Solana nodes for high-throughput workloads, giving you full control over rate limits and configuration.
- Transparent pricing based on usage, with no hidden costs.
Other providers may offer similar features, but you should compare their rate limits, latency, and pricing against your specific needs. Always test with your actual transaction patterns.
Key Takeaways
- Signed transactions require an RPC provider that is reliable, low-latency, and secure.
- API keys are essential for managing access, but they must be kept secret and rotated regularly.
- Evaluate providers based on throughput, latency, reliability, and API key management.
- Use best practices like environment variables and monitoring to protect your keys.
- Test your transaction flow with simulation and handle common errors like expired blockhashes.
Frequently Asked Questions
Can I send signed transactions using a public Solana RPC endpoint?
Yes, you can send signed transactions to public endpoints, but they often have rate limits and may be less reliable. For production, use a managed provider with API key authentication.
How do I get an API key for Solana RPC?
Sign up for an RPC provider like OnFinality, create a project, and generate an API key. Then include it in your request headers.
What is the difference between a shared and a dedicated Solana RPC?
A shared RPC is used by many clients and may have rate limits. A dedicated RPC is reserved for your use, offering higher throughput and more consistent performance.
How do I handle transaction expiration on Solana?
Fetch a recent blockhash before sending and submit promptly. If you get a "blockhash not found" error, fetch a new blockhash and retry.
Are API keys secure for sending signed transactions?
API keys authenticate your requests but do not expose your private keys. However, if a key leaks, an attacker could use your quota or access data. Keep keys secret and rotate them regularly.
What should I do if my transaction is dropped?
Check the error message. If it's a rate limit, wait and retry. If it's a blockhash issue, fetch a new blockhash. If it's a simulation error, fix the transaction logic.
For more detailed guidance on selecting an RPC provider, see our guide on choosing an RPC provider. To explore Solana-specific options, visit our Solana network page.
Related resources
Originally published at OnFinality.
Top comments (0)