How do you choose a Stellar RPC provider for Soroban apps?

Stellar RPC provider decision checklist

Before you compare vendors, define what your application needs from Stellar RPC. This checklist covers the decisions most teams face.

• Confirm which networks you need: Mainnet, Testnet, or Futurenet. Some providers only expose one or two.
• Decide whether you need archive data. If your app shows ledger history, check whether the provider supports the getLedgers archive method.
• Estimate your traffic. A shared public endpoint may be fine for development, but production Soroban apps often need a private endpoint or a dedicated node.
• Test with real requests. Call the same JSON-RPC methods you will use in production, not just a health check.
• Review rate limits and fair-use policies. Public endpoints often have tighter limits than dedicated options.
• Check SDK compatibility. The Stellar SDKs (stellar-sdk, soroban-client) should work with the provider endpoint without custom wrappers.
• Plan for failover. Multiple endpoints or a provider with redundant routing reduces the chance of a single point of failure.
• Compare pricing against your expected volume, including any archive or WebSocket extras.

If you are also comparing general RPC provider tradeoffs, see how to choose an RPC provider. For a full list of supported chains and endpoint types, check the supported RPC networks page.

What is Stellar RPC?

Stellar RPC is a JSON-RPC API that gives applications real-time access to Stellar network data. It was originally introduced as Soroban RPC to support Soroban smart contracts, and it was renamed to Stellar RPC in late 2024. Today it is the standard way to:

• Query the current ledger and network state
• Read ledger entries for accounts, contracts, and assets
• Submit transactions and track their status
• Fetch smart contract events and simulations

Stellar RPC is intentionally lighter than Horizon. It exposes a small set of methods and keeps a bounded window of recent history, about seven days by default. It is not a replacement for Horizon, nor is it an indexer for historical data. This distinction matters when you evaluate providers, because archive support is a separate capability from normal RPC access.

The official Stellar RPC documentation and the stellar-rpc GitHub repository are good references when you want to understand the protocol itself. When you are comparing hosted options, however, the following criteria matter more than the underlying server implementation.

What to compare between Stellar RPC providers

Use this table as a starting point when you evaluate Stellar RPC providers.

Many of the same criteria apply to any chain, but Stellar has a few unique angles. First, because RPC is the main interface for Soroban contracts, your provider choice directly affects how reliably you can send contract calls and track transactions. Second, the distinction between normal RPC and archive RPC is still new for Stellar, so not every provider supports getLedgers yet. The Stellar network page shows mainnet RPC, archive support, and dedicated nodes as available options from OnFinality, which matches the feature set many production teams need.

Example: Query the latest ledger with cURL

The quickest way to test a Stellar RPC provider is to call getLatestLedger. The request follows the JSON-RPC 2.0 format:

curl -X POST https://stellar.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getLatestLedger","params":[]}'

A successful response looks like this:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "hash": "8e8d0b...",
    "seq": 1283922,
    "ledgerCloseTime": 1699999999,
    "protocolVersion": 22
  }
}

The seq field tells you the latest ledger sequence number, and protocolVersion tells you which Stellar protocol version the node is running. If the request fails, the provider may be down, behind on syncing, or blocking requests from your region. Try the same request against your own node or a second provider to narrow down the cause.

For transaction-heavy applications, you will also use methods like sendTransaction, getTransaction, getLedgerEntries, and getEvents. Test these methods before you commit, because provider implementations can differ in how they handle parameter encoding and response formats.

Common pitfalls when using a Stellar RPC provider

Because Stellar RPC is still a relatively new layer on top of Stellar Core, developers often run into the same issues.

Treating RPC as an indexer. RPC keeps a bounded window of history. If your app needs to display past transactions or balances, you need a separate indexing solution or a provider with archive support. For full ledger history, ask whether the provider supports the getLedgers method.

Ignoring network differences. Mainnet, Testnet, and Futurenet have different configuration and data. A transaction that works on Testnet may fail on Mainnet if you hardcoded the network passphrase or a testnet contract address.

Relying on a public shared endpoint for production. Public endpoints are convenient for prototyping, but they are shared across many users and can be rate-limited or temporarily unavailable. Production apps should use authenticated endpoints or a dedicated node, depending on traffic.

Not checking archive support before building a history feature. The Stellar docs now list providers with "RPC Archive" capability. If you need ledger history, choose a provider that explicitly supports it rather than assuming all RPC providers do.

Submitting transactions without sufficient fee or simulation. Soroban contract calls often require simulation before submission. Make sure your provider lets you call simulateTransaction and that you are using the SDK version your provider expects.

Dedicated nodes vs shared Stellar RPC endpoints

Your traffic pattern determines whether a shared endpoint is enough. Development, small wallets, and low-frequency event listeners can often use a shared public or authenticated endpoint. High-throughput trading, indexing pipelines, or applications that need consistent latency should consider a dedicated node.

Dedicated nodes give you:

• Isolated request capacity
• More control over rate limits
• The ability to tune node configuration
• Fewer noisy-neighbor effects

OnFinality offers both an RPC API service and dedicated nodes. Dedicated Stellar nodes are useful when you want the operational control of running a node without managing the hardware yourself. If you are unsure which option fits your workload, contact the OnFinality team through the network page and describe your traffic profile.

How to get started with a Stellar RPC provider

If you are ready to try Stellar RPC, start with a simple workflow:

1. Pick a provider that supports the networks you need.
2. Use the public or free endpoint to run the getLatestLedger example above.
3. Write a small script that sends a transaction to Testnet and polls getTransaction.
4. Review the provider's pricing page and estimate your monthly request volume.
5. Once the app works, move to an authenticated endpoint or dedicated node.

OnFinality provides a managed Stellar RPC endpoint at https://stellar.api.onfinality.io/public for mainnet. Check the Stellar network page for the latest endpoint details and for information about testnet access. For pricing guidance, see the RPC pricing page.

The key is to validate with the same methods, payload sizes, and traffic patterns you expect in production. A provider that looks fast in a health check may still struggle with heavy getEvents traffic or large contract simulations.

Frequently Asked Questions

What is the difference between Stellar RPC and Horizon?

Stellar RPC is a lightweight JSON-RPC API focused on ledger state, smart contracts, and transaction submission. Horizon is a more feature-rich API that supports historical queries and indexing. RPC is not a drop-in replacement for Horizon.

Does Stellar RPC support Soroban smart contracts?

Yes. Stellar RPC was built to support Soroban contracts. It includes methods for simulating transactions, fetching contract events, and reading ledger entries.

Can I get historical ledger data from a Stellar RPC provider?

Normal Stellar RPC only retains a bounded window of recent history. Some providers now offer archive RPC support through the getLedgers method, which can return older ledger data.

Which networks do Stellar RPC providers support?

Most providers support Mainnet and Testnet, and a smaller number support Futurenet. Always confirm the provider's network list before you start development.

Is a public Stellar RPC endpoint good enough for production?

For low-traffic apps, it can be. For production-grade apps, you usually want an authenticated endpoint or a dedicated node to get predictable rate limits and reliability. Evaluate your traffic needs before deciding.

Key Takeaways

• Stellar RPC is the main JSON-RPC interface for Soroban smart contracts and ledger state, and it is not an indexer.
• When choosing a provider, compare network coverage, archive support, dedicated node availability, rate limits, and SDK compatibility.
• Test with real methods like getLedgerEntries, sendTransaction, and getEvents, not just getHealth.
• Archive support for getLedgers is a distinct capability that not every provider offers.
• Public shared endpoints are good for development; production apps should consider private endpoints or dedicated nodes.
• OnFinality lists Stellar RPC on its network page and offers both shared RPC and dedicated node options.