How to get a Stellar RPC endpoint (2026 guide)

TL;DR

Point your Soroban SDK at Stellar mainnet and there’s no free official endpoint to copy-paste. The Stellar Development Foundation runs a public Horizon instance for classic account and payment data, but it does not run a public JSON-RPC endpoint for mainnet. That gap is easy to miss because testnet works fine out of the box, and then mainnet deployment stalls on “where do I even point this.” This guide covers Horizon vs Stellar RPC, what Chainstack actually serves, and how to deploy a private Stellar RPC endpoint in minutes.

What is a Stellar RPC endpoint

Stellar splits its API surface into two separate services, and this matters for anyone coming from Ethereum-style tooling. Horizon is a RESTful API in front of Stellar Core for classic operations: accounts, payments, offers, trustlines. Stellar RPC (formerly Soroban RPC) is a JSON-RPC 2.0 interface introduced for the Soroban smart contract platform, and it also serves general ledger and transaction data. A Chainstack Stellar endpoint speaks Stellar RPC over JSON-RPC only; Horizon is a separate service and isn’t served on the same endpoint.

What developers actually do against a Stellar RPC endpoint:

• Read ledger, account, and contract state (getLedgerEntries, getLatestLedger)
• Simulate a Soroban contract invocation before spending fees on it (simulateTransaction)
• Submit signed transactions to the network (sendTransaction) and poll for results (getTransaction)
• Query recent ledgers and transaction history within the node’s retention window (getLedgers, getTransactions)
• Read contract events for indexing and monitoring (getEvents)

You can review the full list of supported JSON-RPC methods in the Stellar RPC API reference.

A slow or unreliable RPC endpoint doesn’t just delay a page load on Stellar. simulateTransaction calls happen before every Soroban invocation to compute fees and resource limits, so a flaky endpoint means failed simulations, wrong fee estimates, and transactions that get rejected on submission instead of failing fast in the UI.

How Stellar RPC differs from EVM chains

Stellar isn’t EVM-compatible, and the differences go beyond syntax. There’s no eth_call / eth_sendRawTransaction pair; the closest equivalents are simulateTransaction and sendTransaction, and simulation is not optional the way eth_estimateGas is. Soroban requires a simulation pass to compute the resource footprint (CPU instructions, ledger reads/writes, transaction size) before a contract invocation can be submitted at all. Accounts aren’t identified by a 20-byte hex address; they use StrKey-encoded public keys (G... for accounts, C... for contracts). Finality isn’t probabilistic block confirmations either. Stellar Consensus Protocol (a Federated Byzantine Agreement construction, not proof-of-stake or proof-of-work) closes ledgers in roughly 5 seconds with no reorg risk once a ledger closes. And there is no eth_getLogs-style unlimited historical query: getEvents and getLedgers are bounded by the node’s ledger retention window, not by an arbitrary block-range cap.

None of the standard EVM tooling applies here, not ethers.js, viem, Hardhat, or Foundry. You’ll use the @stellar/stellar-sdk (JavaScript) or stellar-sdk (Python) packages, both of which speak Stellar RPC natively.

Stellar RPC endpoint options

Public vs private Stellar RPC endpoints

Horizon has an official, SDF-run public instance you can hit right now. Stellar RPC does not, and that asymmetry is the first thing that trips up developers moving from testnet, where SDF does run a public RPC node, to mainnet, where it doesn’t.

Official public endpoints:

• Horizon Mainnet: https://horizon.stellar.org
• Horizon Testnet: https://horizon-testnet.stellar.org
• Stellar RPC Testnet: https://soroban-testnet.stellar.org
• Stellar RPC Mainnet: no official SDF-run public endpoint

⚠️ There is no SDF-operated public JSON-RPC endpoint for Stellar mainnet. To get JSON-RPC access to mainnet ledger data or Soroban contracts, you either self-host stellar-rpc against your own Stellar Core validator, or use a managed provider. The Stellar RPC providers page lists the ecosystem options for exactly this reason.

Dimension	Public (Horizon)	Private (Chainstack)
Access	Free and open, rate-limited per IP	Restricted access, dedicated to your project
Resources	Shared infrastructure	Shared (Global Nodes) or dedicated resources
Best use case	Reading classic Horizon data for dashboards	Soroban contract calls, transaction submission, production apps
Mainnet JSON-RPC	Not available from SDF	Available
Ledger retention window	~7 days by default on self-hosted stellar-rpc	Deeper retention on Chainstack Global Nodes
Rate limit	Horizon defaults to 3,600 requests/hour per IP	No aggressive per-IP throttling

The gap isn’t reliability in the usual “public endpoints get throttled” sense. It’s that the endpoint you need for mainnet Soroban development simply doesn’t exist for free, and the Stellar docs themselves point developers at professional RPC providers to fill it.

Full node vs archive Stellar node

Chainstack does not currently offer archive nodes for Stellar; every Stellar deployment on Chainstack runs in full mode. This isn’t a downgrade for most workloads: Soroban contract calls, simulateTransaction, account state reads, and payment monitoring all operate against recent ledger state, which full mode serves completely.

What full mode gives you access to:

• Current account balances, trustlines, and contract storage
• Transaction simulation and submission
• Recent ledger and transaction history within the node’s retention window

Every Stellar node on Chainstack reports its actual window through getHealth (the oldestLedger and latestLedger fields) rather than a fixed advertised depth, and the window is meaningfully deeper than the ~7-day default most self-hosted stellar-rpc deployments ship with. Billing doesn’t change with the window either: every Stellar request is billed as a full-node request at 1 RU, since there’s no archive tier to price separately. If your use case genuinely needs history back to genesis, for full compliance audits or chain analytics spanning years, that’s a job for Stellar’s Hubble data lake rather than an RPC node, archive or otherwise.

HTTPS vs WebSockets

Stellar RPC on Chainstack is HTTPS-only. There is no WebSocket endpoint, and this isn’t a Chainstack-specific limitation: the upstream stellar-rpc server itself doesn’t expose one. Every read and write is a JSON-RPC POST request, including polling for transaction results after sendTransaction.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	N/A on Stellar RPC
Best for	All Stellar RPC calls — reads, simulation, submission, polling	Not applicable
Latency	Standard	N/A
Connection overhead	Per request	N/A

If your application needs push-style updates, Horizon (the separate REST service) supports Server-Sent Events streaming for classic operations like payments and transactions. That’s a different API surface than the JSON-RPC endpoint this guide covers, though, and Chainstack Stellar nodes don’t serve Horizon.

How to get a private Stellar RPC endpoint with Chainstack

Deploying a Stellar node on Chainstack takes the same six steps as any other protocol; there’s no separate signup flow for non-EVM chains.

1. Log in to the Chainstack console (or create an account).
2. Create a new project
3. Select Stellar as your blockchain protocol
4. Choose network: Stellar Mainnet or Testnet
5. Deploy the node
6. Open Access and credentials and copy your HTTPS endpoint

By default this deploys on Global Nodes: geo-balanced, shared infrastructure across Chainstack’s network. If you need single-tenant resources, a specific region, or control over retention depth, Dedicated Nodes are available for Stellar in London, Ashburn, Tokyo, Los Angeles, Frankfurt, Singapore, and New York.

Here’s the connection, matching the official tooling:

// npm install @stellar/stellar-sdk
import { rpc } from "@stellar/stellar-sdk";

const server = new rpc.Server("YOUR_CHAINSTACK_ENDPOINT");

const health = await server.getHealth();
console.log("status:", health.status, "| oldest:", health.oldestLedger, "| latest:", health.latestLedger);

const ledger = await server.getLatestLedger();
console.log("sequence:", ledger.sequence, "| protocol:", ledger.protocolVersion);

📖 For the full integration guide, see the Chainstack Stellar tooling documentation.

You can also access Chainstack Stellar RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. For the full agent stack (MCP, the Chainstack skill, llms.txt, and WebMCP), see the Chainstack Agents page.

Need testnet XLM to fund a test account? Stellar’s own Friendbot funds any testnet public key for free, and it’s the standard way to get started before you have real accounts to work with.

Using Chainlist

Chainlist is EVM-only and does not apply to Stellar; there’s no chain ID or wallet RPC list to add Stellar to.

Chainstack pricing for Stellar RPC

Because every Stellar request bills at a flat 1 RU with no archive multiplier, forecasting cost is arithmetic, not guesswork. Check the full Chainstack pricing page for current plan details and overage rates.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	$0/mo	3,000,000 RU	25 RPS	$20
Growth	$49/mo	20,000,000 RU	250 RPS	$15
Pro	$199/mo	80,000,000 RU	400 RPS	$12.5
Business	$499/mo	200,000,000 RU	600 RPS	$10
Enterprise	from $990/mo	400,000,000 RU	Unlimited	$5

For high-volume production traffic, the Unlimited Node add-on switches to flat-fee pricing instead of per-request billing. If you need single-tenant infrastructure, Dedicated Nodes for Stellar start from roughly $0.50/hour compute plus storage: a mainnet Dedicated Node with 500 GB storage runs about $547/month, and a testnet node with 250 GB runs about $453/month.

How to estimate monthly cost

1. Estimate your average requests per second during normal operation.
2. Multiply by seconds per month (~2.6M) to get baseline monthly RU.
3. Add a buffer for simulation traffic. Every Soroban call typically fires a simulateTransaction before the actual sendTransaction, roughly doubling request volume per user action compared to a simple read-only dApp.
4. Match the total against the plan table above, including your peak RPS against the plan’s RPS ceiling, not just the monthly total.
5. Stellar’s own theoretical throughput ceiling has been climbing fast: Protocol 23’s parallel execution work targets up to 5,000 TPS in theory, per Stellar’s own roadmap posts. Live observed throughput today sits far below that (in the low hundreds of TPS per current network trackers), so budget for real, measured usage rather than the theoretical ceiling if your app scales quickly.

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in env/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation
• simulateTransaction results validated before submission: a stale simulation against a resource-limit or fee change will cause sendTransaction to fail
• Retention window checked against your query range before deploying: oldestLedger from getHealth tells you what’s actually queryable right now, not what the retention window is configured for
• SDK version pinned: @stellar/stellar-sdk and Soroban’s XDR encoding have moved fast across protocol upgrades

Troubleshooting common Stellar RPC issues

Issue	How to Fix
429 Too Many Requests on a public endpoint	Move to a managed endpoint. Public Horizon and testnet RPC are rate-limited per IP and not meant for production traffic
Trying to connect to a “public mainnet RPC” that doesn’t exist	There isn’t one from SDF. Self-host stellar-rpc or use a managed provider like Chainstack
getLedgers / getEvents return an out-of-range error	The requested ledger is older than oldestLedger from getHealth; you’re outside the node’s retention window
sendTransaction fails after a successful simulateTransaction	Ledger state moved between simulation and submission (fees, sequence number, resource limits). Re-simulate immediately before submitting
Connecting to a Chainstack Stellar endpoint and getting Horizon-shaped errors	Chainstack serves Stellar RPC (JSON-RPC), not Horizon (REST). Check you’re calling JSON-RPC methods, not Horizon’s REST paths
WebSocket connection refused	Stellar RPC has no WebSocket endpoint anywhere, on Chainstack or upstream. Poll with getTransaction / getLedgers instead

Conclusion

The failure mode this guide is really about isn’t a rate limit. It’s the moment a developer, having tested everything against the public testnet RPC, tries to point the same code at mainnet and finds there’s nothing to point it at. Horizon’s public mainnet instance masks the gap, because it works fine and looks like “the” Stellar endpoint. It isn’t; it’s a different service that doesn’t touch Soroban contracts at all.

The pattern that works: build against a real endpoint from day one, even on testnet, so mainnet is a config change and not a rewrite. Self-hosting stellar-rpc is viable if you’re already running Stellar Core infrastructure; for everyone else, a managed endpoint is the non-negotiable production requirement, because there’s no free fallback to reach for when the self-hosted node falls behind or the public Horizon rate limit hits during a traffic spike.

Chainstack’s free tier covers Stellar mainnet and testnet RPC to build and test against, and Dedicated Nodes are there when you need single-tenant infrastructure for production.

FAQ

Is Stellar RPC the same as Soroban RPC? Yes. Stellar RPC was renamed from Soroban RPC in late 2024 to reflect that it serves general ledger and transaction data, not just smart contract calls. Any tooling or docs referencing “Soroban RPC” are describing the same service.

Can I use ethers.js or viem to talk to Stellar? No. Stellar isn’t EVM-compatible, so EVM client libraries don’t work. Use the official @stellar/stellar-sdk (JavaScript/TypeScript) or stellar-sdk (Python), both of which implement the Stellar RPC JSON-RPC methods directly.

Why does my public Horizon endpoint work but I can’t find a public mainnet RPC endpoint? Because they’re different services run by different policies. The Stellar Development Foundation operates a public Horizon instance for both networks, but only operates a public Stellar RPC instance for testnet. Mainnet JSON-RPC access requires self-hosting or a managed provider.

Does Chainstack support archive nodes for Stellar? Not currently. Stellar deployments on Chainstack run in full mode with a retention window reported live through getHealth. Most application workloads (contract calls, payments, recent history) don’t need archive depth; long-range historical analytics is better served by Stellar’s Hubble data lake.

Is there a WebSocket endpoint for real-time Stellar updates? No. Stellar RPC is HTTPS-only, on Chainstack and upstream. Poll getTransaction for submission results and getLedgers for new ledger data.

How do I monitor a production Stellar RPC integration? Track request latency and error rate on simulateTransaction and sendTransaction specifically, since those gate every Soroban contract interaction. A spike in simulation failures usually means a resource-limit or fee-model change on the network, not a client bug.

Additional resources

• Chainstack Stellar tooling documentation
• Stellar RPC API reference — full JSON-RPC method list
• Stellar developer documentation — official docs home, Soroban guides, SDKs
• Chainstack introduces Stellar support — announcement post
• stellar/stellar-rpc on GitHub — source for the RPC server Chainstack runs