How to get a Solana RPC endpoint for stablecoins (2026 guide)

TL;DR

At Solana’s current stablecoin throughput — $650 billion processed in February 2026 alone — a lightweight payment verifier polling for transaction confirmation hits the public RPC’s 100-requests-per-10-second ceiling within seconds of going live. Solana’s 400ms slot times and sub-second finality have made it the settlement layer institutions actually use, but that same throughput makes reliable endpoint access a hard production requirement, not a configuration detail. This guide covers every option for getting a production-ready Solana RPC endpoint, what commitment levels mean for payment UX, and what compliance infrastructure you need before handling real stablecoin settlement volume.

What is a Solana RPC endpoint

A Solana RPC endpoint is an HTTP or WebSocket server that exposes Solana’s JSON-RPC API — the interface through which every application reads chain state and submits transactions. Unlike EVM chains, which share the standardized eth_* method namespace, Solana uses its own method set (getBalance, getTransaction, sendTransaction, simulateTransaction, and more than 30 others) built around Solana-native data structures: base58-encoded public keys, lamport values, commitment levels, and slot numbers rather than block numbers. Every payment processor, wallet, and settlement system that touches Solana communicates exclusively through this API.

Operations that depend on the endpoint in a stablecoin context include:

• USDC and USDT balance reads via getTokenAccountsByOwner to resolve associated token accounts for any wallet
• Transfer confirmation using getTransaction with finalized commitment to verify stablecoin payments have cleared
• Transaction broadcasting via sendTransaction to submit signed payment instructions on-chain
• Transaction simulation via simulateTransaction to validate payment flows before committing fees
• Slot monitoring via getSlot for payment latency profiling
• Historical settlement lookups via getSignaturesForAddress to reconstruct payment records
• Account state reads via getAccountInfo for token mint validation and compliance checks

You can review the full list of supported JSON-RPC methods in the Solana developer documentation.

For stablecoin settlement specifically, endpoint quality determines confirmation latency directly: an endpoint with stale slot data or degraded connectivity causes your application to report a transaction as pending minutes after it finalized on-chain, creating a reconciliation problem that scales with your payment volume.

How Solana RPC differs from EVM chains

Solana’s RPC model is structurally different from Ethereum and every EVM-compatible chain. EVM developers need to unlearn several assumptions before building payment infrastructure on Solana.

There are no block numbers. Solana uses slots (approximately 400ms each) and epochs (432,000 slots) as its primary time units. Transaction lookups use signature hashes in base58 encoding, not hex transaction hashes. There is no eth_getLogs equivalent. Event monitoring on Solana is done through getSignaturesForAddress, getProgramAccounts, or real-time streams via the Geyser plugin (gRPC). All account addresses are base58-encoded public keys, not 0x-prefixed hex.

Solana also has no mempool in the EVM sense. Transactions are submitted directly to the current slot leader via the Gulf Stream protocol, which means pre-broadcast visibility is not available through standard RPC. For payment processors, this changes how you confirm: instead of waiting for a fixed block count, you poll or subscribe against commitment levels (processed, confirmed, or finalized), each representing a different point in the validator consensus lifecycle.

Finality on Solana is commitment-based. The finalized state is reached in approximately 32 slots (~13 seconds), while confirmed is available in roughly 2 seconds. This is structurally different from Ethereum’s probabilistic finality and from L2 settlement windows that depend on L1 inclusion.

EVM tooling — ethers.js, viem, Hardhat, Foundry — does not work with Solana. The chain’s SDK ecosystem is entirely separate: @solana/kit (the modern tree-shakeable functional API), @solana/web3.js (the older class-based library still in wide use), and @solana/spl-token for SPL token operations including USDC and USDT transfers.

Solana RPC endpoint options

Public vs private Solana RPC endpoints

Solana’s public endpoints were designed for validator testing and developer exploration — not for the payment flows now running at $650B per month on the network. At 100 requests per 10 seconds per IP, a single confirmation poller handling concurrent stablecoin settlements will exhaust the limit before the second batch of confirmations lands.

Official public endpoints:

• Mainnet: https://api.mainnet.solana.com
• Testnet: https://api.testnet.solana.com
• Devnet: https://api.devnet.solana.com

⚠️ Solana’s public mainnet endpoint enforces a hard rate limit of 100 requests per 10 seconds per IP and 40 requests per 10 seconds per single RPC method. WebSocket subscriptions are not available on public endpoints without authentication. The Solana docs themselves recommend using professional RPC providers for any production application.

Feature	Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development and testing	Production payment flows
Rate limit	100 req / 10s per IP	No aggressive throttling
WebSocket support	Not available	Full subscription support
Archive access	Not available	Available
Geyser/gRPC streaming	Not available	Provider-dependent

📖 For a detailed comparison of Solana RPC providers, see Best Solana RPC providers for fast and reliable production in 2026.

Solana’s throughput is what attracts institutional stablecoin issuers — and it is exactly that throughput that makes a shared public endpoint the wrong foundation for any production settlement workload.

Full node vs archive Solana node

For stablecoin infrastructure, the line between a full node and an archive node determines whether your compliance team can reconstruct historical settlement records — or only verify the last 48 hours of transactions.

Full node access	Archive node access
Current USDC and USDT balances and token account state	Complete payment history for any wallet since genesis
Transaction confirmation at any commitment level	Historical getTransaction calls beyond the default retention window
Real-time slot monitoring and leader schedule lookups	Settlement audit trails required by MiCA and fintech compliance frameworks
simulateTransaction for pre-flight payment validation	Backfilling payment records for treasury analytics and reconciliation
Live getSignaturesForAddress for recent activity	Full reconstruction of SPL token transfer history on demand

Chainstack supports Solana archive nodes — giving payment processors and compliance teams access to the complete Solana ledger history without running their own archival infrastructure.

HTTPS vs WebSocket

At high stablecoin payment volume, the choice between HTTPS and WebSocket is not aesthetic — it determines whether your confirmation pipeline scales or gets throttled one request at a time. HTTP polling at 400ms slots means your application makes 150 requests per minute per payment it is watching. At $650B in monthly volume, that adds up fast.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Balance checks, one-off confirmations, batch settlement lookups	Real-time payment event subscriptions, slot monitoring, finality tracking
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

WebSocket subscriptions — accountSubscribe, signatureSubscribe, slotSubscribe — are the right transport for payment confirmation pipelines that need sub-second notification when a transaction reaches finalized commitment. Public endpoints do not expose WebSocket streaming; that is a managed-provider feature only.

Why Solana became the settlement layer for stablecoins

No other chain comes close to Solana’s stablecoin throughput in 2026. Monthly USDC transfer volume on Solana hit $880 billion in February 2026, a 300% year-over-year increase. The network processed $650B in total stablecoin transactions that same month. Solana’s stablecoin market cap reached $14 billion by the end of January 2026, up from $5 billion at the end of 2024. Getting a reliable Solana RPC endpoint for stablecoin infrastructure starts with understanding why this volume makes the public endpoint unviable long before you hit production scale.

What drives institutional adoption is the combination of throughput and finality. Visa launched USDC settlement on Solana for U.S. banks in late 2025 with seven-day availability and near-instant finality, reaching an annualized run rate of more than $3.5 billion by November 2025. Circle (USDC issuer), Sygnum Bank, Anchorage Digital, and Ernst & Young all run stablecoin infrastructure on Solana. Western Union is launching a USD-backed stablecoin targeting Solana settlement flows in 2026. Jupiter launched JupUSD in January 2026 in partnership with BlackRock and Ethena Labs, generating $11 million in volume within its first month.

For developers building payment infrastructure, this volume concentration matters. The ecosystem tooling, liquidity depth, and institutional counterparty relationships are all on Solana. The RPC endpoint is the foundation — it determines whether your settlement flow keeps pace with 400ms slots or introduces artificial latency at the confirmation layer.

Chainstack’s stablecoin infrastructure is used by the same institutions driving this volume. The infrastructure requirements they have shaped what production-grade Solana RPC looks like in 2026.

Finality guarantees and what they mean for payment UX

Solana exposes three commitment levels that every payment developer must understand before designing a confirmation flow:

• processed — The transaction has been received and processed by the current slot leader. It can still be rolled back if the slot is not confirmed by the validator supermajority. Using processed for payment confirmation is equivalent to treating a wire transfer as settled the moment you press send: you know it left the account, but consensus hasn’t cleared it yet.
• confirmed — A supermajority of validators has voted on the slot containing the transaction. This takes approximately 2 seconds after broadcast and is appropriate for low-value instant-payment use cases where brief rollback risk is acceptable. Most consumer-facing stablecoin apps display confirmation at confirmed.
• finalized — The transaction is in a block that has received maximum confirmation and cannot be rolled back under any non-catastrophic network condition. This takes approximately 32 slots (~13 seconds from broadcast). MiCA-regulated payment infrastructure, cross-border B2B settlement, and treasury management systems must settle at finalized only.

The consequence for payment UX is direct: if your frontend shows “payment complete” at processed and the transaction rolls back, you have a silent failure that is difficult to diagnose and creates reconciliation debt. Build your confirmation pipeline to target confirmed for UX display and trigger downstream settlement actions only at finalized.

Your RPC endpoint is the source of these commitment signals. An endpoint with stale slot tracking or connection issues delays finalized notifications — which means your payment processor introduces latency the network itself never created. This is the hidden cost of underpowered RPC infrastructure for stablecoin settlement.

Compliance requirements for on-chain payment infrastructure

As stablecoin payment volume crosses institutional thresholds, regulatory requirements follow. Three frameworks are directly relevant to Solana payment infrastructure in 2026.

• MiCA (EU) requires payment systems handling crypto-asset transfers to maintain audit trails that allow transaction reconstruction on request. On Solana, this means archive node access — you cannot reconstruct a complete payment record from a full node once the transaction ages out of the recent-history window (approximately 2 days). Archive access is a compliance infrastructure requirement, not an optional upgrade.
• GENIUS Act (US) imposes reserve transparency and settlement traceability requirements on stablecoin issuers. For technical teams, this translates to: every payment event must be attributable to an on-chain transaction with a permanent record. Chainstack’s SOC 2 Type II and ISO 27001 certified infrastructure gives regulated teams the third-party verification that audit frameworks require.
• DORA (EU) mandates that regulated financial entities using third-party blockchain infrastructure maintain documented risk assessments of their node providers and demonstrate failover capability. Dual-provider RPC configurations with documented SLAs are the minimum viable compliance posture for EU-regulated payment processors building on Solana.

For teams using Chainstack’s blockchain infrastructure for fintech, the SOC 2 Type II and ISO 27001 certification, 99.99%+ uptime SLA, and multi-region node infrastructure cover the three most common compliance checkboxes that auditors ask about.

Multi-region payment node topology

A single-region RPC endpoint is a single-region payment failure. At the throughput levels Solana payment processors operate, the topology matters as much as the provider choice.

The three-tier configuration that production stablecoin infrastructure uses:

Tier 1 — Primary Dedicated Nodes. A dedicated node in the region closest to your application servers. For global payment processors, this typically means one node per major region. Dedicated Nodes give you consistent performance unaffected by other users’ traffic patterns — no shared-tenant contention during volume spikes.

Tier 2 — Regional Global Nodes fallback. Chainstack’s geo-balanced Global Nodes serve as automatic fallback if your dedicated node encounters issues. The failover is handled by your application’s endpoint retry logic — not by restarting infrastructure.

Tier 3 — Secondary provider. No production payment system should depend on a single infrastructure provider. Configure a second provider endpoint as tertiary fallback, with automatic promotion logic if both primary and secondary fail simultaneously.

For payment confirmation pipelines specifically, add slot lag monitoring to your Tier 1 node. If slot lag exceeds 5 slots behind the chain head, trigger failover before payment confirmations begin to delay. Set reconnect logic on WebSocket subscriptions with exponential backoff — Solana’s periodic validator rotation means connection drops are expected, not exceptional.

How to get a private Solana RPC endpoint with Chainstack

Deploying a private Solana RPC node on Chainstack takes under two minutes:

1. Log in to the Chainstack console (or create an account)
2. Create a new project
3. Select Solana as your blockchain protocol
4. Choose network: Mainnet or Testnet
5. Deploy the node
6. Open Access/Credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into production code

import { address, createSolanaRpc } from "@solana/kit";

// createSolanaRpc accepts your HTTPS Chainstack endpoint directly
const rpc = createSolanaRpc("YOUR_CHAINSTACK_ENDPOINT");

// getBalance returns the value in lamports as a bigint — divide by 1e9 for SOL
const balance = await rpc
  .getBalance(address("23dQfKhhsZ9RA5AAn12KGk21MB784PmTB3gfKRwdBNHr"))
  .send();

console.log(balance.value); // bigint — e.g. 5000000000n for 5 SOL

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

You can also access Chainstack Solana RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Chainlist is EVM-only and does not list Solana endpoints — it is not relevant for Solana infrastructure.

Chainstack pricing for Solana RPC

Chainstack’s billing model is request-unit (RU) based: each RPC call consumes one RU for full-node requests and two RUs for archive-node requests. For stablecoin infrastructure, this makes cost forecasting straightforward — multiply your daily request volume by your blend of full-node and archive calls, and you have your monthly spend before committing to a plan. See the full Chainstack pricing page for plan details and current overage rates.

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

Advanced options relevant to Solana stablecoin infrastructure:

• Archive Node add-on — Archive requests cost 2 RU versus 1 RU for full-node calls. Required for compliance-grade historical settlement lookups and any regulatory audit trail.
• Unlimited Node add-on — From $149/month at 25 RPS to $3,199/month at 500 RPS. Flat-rate billing with no request limits. Right for automated payment processors where per-request costs create unpredictable invoices during volume spikes.
• Dedicated Nodes — From $0.50/hour plus storage. Isolated infrastructure with no shared-tenant performance variance — the right call for any production payment processor.
• Warp Transactions — $0.15 per transaction for optimized transaction routing that improves landing rate. Essential for time-sensitive USDC and USDT settlement flows where transaction expiry is a risk.

How to estimate monthly cost

1. Estimate your average daily RPC request volume across all endpoints
2. Split between balance reads and confirmation polls (1 RU each) versus archive-based historical lookups (2 RU each)
3. Multiply daily total by 30 to get monthly RU consumption
4. Map to the plan whose RU ceiling covers your baseline with meaningful buffer
5. Solana stablecoin traffic is not flat — payment volume spikes around market events, month-end treasury settlements, and institutional batch windows. Budget for 2–3x your baseline, or move to an Unlimited Node for predictable billing regardless of traffic shape.

Production readiness checklist

• Primary plus fallback RPC provider configured
• Request timeout policy set (5 seconds is appropriate for Solana given 400ms slots)
• Retry logic with exponential backoff implemented
• Credentials stored in env or secret manager — never hardcoded
• Monitoring for latency, error rate, and throttling in place
• Alerts set for sustained degradation (five or more consecutive slot-lag events)
• Commitment level set to finalized for all downstream settlement triggers — never processed for payment confirmation
• WebSocket reconnect logic implemented with missed-event backfill from HTTPS on reconnect
• Archive node access confirmed and tested before your first compliance audit
• Warp Transactions enabled for any time-sensitive settlement flows

Troubleshooting common Solana RPC issues

Error / Issue	Cause	How to Fix
429 Too Many Requests	Public endpoint rate limit reached (100 req / 10s per IP)	Move to a Chainstack managed endpoint — public RPC is not viable for payment confirmation volume
Transaction shows processed but never reaches confirmed	Slot fork or dropped validator vote	Never use processed as a settlement signal; subscribe to signatureNotification at confirmed or finalized commitment
getTransaction returns null	Transaction has aged out of the full-node retention window (~2 days)	Switch to a Chainstack archive node — full nodes do not retain complete ledger history
WebSocket disconnects mid-session	Periodic validator rotation causes connection drops during leader transitions	Implement reconnect with exponential backoff; backfill missed events via HTTPS getSignaturesForAddress immediately on reconnect
Stale slot data — getSlot returns an outdated value	Shared endpoint lag behind chain head	Monitor slot lag; trigger failover if more than 5 slots behind; use a Dedicated Node to isolate from shared-tenant congestion
sendTransaction returns success but transaction never lands	Transaction expired — signed with a recent blockhash that has a ~150-slot TTL (~60 seconds)	Fetch a fresh blockhash with getLatestBlockhash immediately before signing; submit within the TTL window; use Warp Transactions for higher landing rate
getProgramAccounts times out	Method is computationally expensive on large programs; shared endpoints often throttle it	Use a Dedicated Node or Unlimited Node — this method is frequently rate-limited on shared infrastructure

Conclusion

The failure mode looks like this: your payment processor is live, USDC transfers are confirming, and then a stablecoin volume spike — a month-end treasury batch, a market event, a Visa settlement run — drives your request rate past the public endpoint’s ceiling. The 429 errors arrive silently. Your confirmation poller stalls. Transactions that finalized on-chain 13 seconds ago are still showing as pending in your UI. Your support queue fills with reports of “stuck payments.” The chain never had a problem — your endpoint did, and diagnosing the difference costs time you do not have during a live settlement window.

The pattern that works: deploy a Dedicated Node or Unlimited Node as your primary, use WebSocket signatureSubscribe for real-time finality tracking, and configure a second provider as automatic fallback. Set finalized as the commitment gate for any downstream settlement action. Add archive access before your compliance team requests it.

FAQ

What commitment level should I use for USDC payment confirmation on Solana? Use confirmed for displaying “payment received” in your UI — it arrives approximately 2 seconds after broadcast and has very low rollback probability in practice. Use finalized (~13 seconds) before triggering any irreversible downstream action: releasing inventory, crediting fiat accounts, or recording settlement in your ledger. Never use processed as a settlement signal in a payment system — it can roll back.

Can I use the public Solana RPC endpoint for a production payment processor? No. The public mainnet endpoint at https://api.mainnet.solana.com is rate-limited to 100 requests per 10 seconds per IP and 40 requests per 10 seconds for any single RPC method. A payment processor handling even modest concurrent settlement volume hits these limits immediately. The Solana documentation explicitly recommends professional RPC providers for production applications.

Do I need archive node access for stablecoin compliance infrastructure? Yes, if you are subject to MiCA, DORA, or any regulatory framework requiring transaction audit trails. Solana full nodes retain approximately 2 days of transaction data. Any compliance framework that requires you to reconstruct historical payment records — or respond to regulatory requests for transaction history — requires archive access. Chainstack’s archive nodes cover the complete Solana ledger.

What is the difference between WebSocket and HTTPS for Solana payment confirmation? HTTPS requires your application to poll for transaction status — at 400ms slots, polling every second means you might miss a confirmation or add artificial latency to the settlement signal. WebSocket signatureSubscribe pushes the notification to your application the moment the transaction reaches your target commitment level. For real-time payment UX, WebSocket is the right transport. Public endpoints do not support WebSocket — it requires a managed provider.

How do I handle getTransaction returning null for a historical payment lookup? This occurs when the transaction has aged out of the full-node retention window (approximately 2 days on Solana). You need an archive node to retrieve it. If your compliance or customer support flow requires looking up older transactions, migrate to archive access before the first time a regulatory request arrives for a 90-day-old payment record. Chainstack’s archive nodes give you access to the full Solana ledger on demand.

Which SDK should I use for Solana stablecoin infrastructure in 2026? Use @solana/kit for new builds — it is the current recommended SDK from Anza, replacing @solana/web3.js. It uses a tree-shakeable functional API that produces smaller bundles and provides native TypeScript types for all Solana data structures. For SPL token operations (USDC and USDT transfers), you also need @solana/spl-token. The Chainstack Solana tooling docs include setup examples for both libraries.

Additional resources

• Solana: Transferring SPL tokens in TypeScript — Chainstack tutorial for sending USDC and USDT using @solana/web3.js and @solana/spl-token
• Chainstack Solana tooling documentation — SDK setup, connection examples, and method reference
• Stablecoins on Solana in 2026: Growth, adoption, and usage — Chainstack Blog
• More Solana tutorials and articles on the Chainstack Blog
• Solana JSON-RPC API reference — Official method documentation
• Solana RPC infrastructure directory — Official list of recommended production providers