Top 5 Solana RPC providers for high-frequency trading and market making in 2026

Solana processes 3,000–5,000 real-world transactions per second under normal conditions, with Firedancer adoption and the Alpenglow consensus upgrade targeting sub-150ms finality later in 2026. For high-frequency trading bots and market makers, that speed is both an opportunity and a pressure. When the chain produces a new block every 400 milliseconds, a node that trails the tip by three slots doesn’t just slow you down — it means your quotes are built on stale data and your cancels arrive late.

This isn’t the infrastructure problem most articles describe. The standard “pick a fast RPC” framing misses the fundamental split that defines every serious Solana trading operation: reads and writes require different infrastructure, often from different providers. Your Yellowstone gRPC stream feeds your pricing engine with fresh account state. Your transaction submission path — whether that’s Warp, Jito bundles, or stake-weighted QoS — determines whether your orders actually land in the blocks you’re targeting. A provider that excels at one half may be mediocre at the other. Getting both right is what separates a bot with a 95%+ landing rate from one that hemorrhages fills during congestion events.

This guide covers the RPC methods and infrastructure requirements that matter for HFT and market making on Solana in 2026, then evaluates the providers that have built specifically for this workload — and those that can serve it adequately with the right configuration.

High-frequency trading and market making on Solana: RPC requirements

The operational profile of a Solana market maker differs from most RPC use cases in ways that matter for infrastructure selection.

Latency requirements are severe but asymmetric. On the read side, you need fresh account state within one to two slots of the chain tip — roughly 400–800ms total staleness budget including your own processing time. On the write side, what matters isn’t raw latency to the RPC; it’s time-to-leader: how quickly your signed transaction reaches the current slot leader’s TPU port. A provider with 40ms RPC response time that routes through general gossip will consistently underperform a provider with 80ms response time that forwards directly to the leader via a staked connection.

Throughput requirements for active market makers are higher than most published benchmarks suggest. A single-pair maker running 400ms rebalancing cycles generates roughly 150 getProgramAccounts or getMultipleAccounts calls per minute for state reads, plus continuous WebSocket subscriptions, plus burst sendTransaction calls during quote updates. Multi-pair operations multiply this linearly. The practical minimum for a production market maker is 200–400 RPS with sustained throughput — shared nodes at consumer-tier plans will rate-limit you during exactly the volatility windows when you need them most.

Key RPC methods for this use case:

• getLatestBlockhash — Called before every transaction to build a valid, non-expired transaction. At 400ms block times, blockhashes expire quickly. Landing rate drops sharply if you’re using a stale hash. Call this with commitment: "processed" for the freshest reference, and cache it for no more than 30–40 slots. Providers that lag at this method will cause silent transaction failures.
• sendTransaction — The most consequential method in any trading stack. Standard JSON-RPC sendTransaction submits through gossip, which is lossy under congestion. The provider’s peering, stake-weighted QoS (SWQoS) configuration, and optional Jito/bloXroute relay integration determine whether your transaction reaches the leader or gets dropped. Every provider in this comparison handles it differently — this is the axis that matters most.
• getProgramAccounts — Used to read the full order book state from DEX programs (Openbook, Phoenix, Raydium). One of the heaviest RPC calls on the network. Many providers rate-limit or method-weight this aggressively; Helius prices it at 10 credits, others at 1. For market makers polling open orders on a multi-program setup, this can dominate your request budget. Monitor actual cost per call, not the sticker RPS limit.
• getMultipleAccounts — More efficient than batched getAccountInfo calls for reading price oracles (Pyth accounts) and several DEX state accounts in a single request. Prefer this over repeated getAccountInfo for any workload that reads more than two accounts per cycle.
• simulateTransaction — Critical for preflight validation. Run simulations before submitting high-value transactions to catch compute budget overflows and permission errors without burning the blockhash. The simulation and submission should ideally come from the same endpoint to avoid commitment-level drift between the two calls.
• getSignatureStatuses — Used to confirm landing after submission. Combined with a slot-lag check, this tells you whether your transaction landed, expired, or is still in flight. Call with searchTransactionHistory: false on the hot path — you want confirmation status, not ledger lookup.
• accountSubscribe (WebSocket) — Used for lightweight monitoring of specific accounts (your wallet, a small set of oracle or position accounts). Does not replace Yellowstone gRPC for high-frequency event streams, but is appropriate for monitoring accounts that change infrequently.
• Yellowstone gRPC (Geyser plugin) — Not a standard JSON-RPC method, but the dominant streaming interface for production market making. Replaces polling with a direct push stream of account updates, slot notifications, and transaction events at roughly 10× lower overhead than WebSocket JSON-RPC. Essential for quote engines that need sub-slot reaction time to price changes. Available from Chainstack, Helius (LaserStream), Triton One (Dragon’s Mouth), and Quicknode (add-on).

Infrastructure requirements:

Dedicated nodes are not optional for production HFT. On shared infrastructure, a neighbouring tenant running a heavy getProgramAccounts scan can spike your P99 latency by 200–400ms. For strategies where your edge is 50–150ms of arrival time advantage, this tail-latency instability makes the economics of shared nodes untenable. The decision point is not about average performance — it’s about worst-case behavior when the network is congested and every millisecond counts.

Geographic proximity to the validator cluster your leader schedule runs through is a genuine performance variable. Solana validators are concentrated in a small number of data centers in US East, EU, and select APAC regions. A Trader Node or dedicated node co-located in the same facility as your highest-traffic leaders will deliver materially better time-to-leader than a node in the wrong region, regardless of provider.

For transaction submission specifically, the three meaningful paths in 2026 are:

1. Stake-weighted QoS (SWQoS): A validator-level protocol that grants priority queuing to transactions arriving from staked RPC nodes. Providers who maintain stake partnerships with validators can forward your sendTransaction on a fast lane that commodity public endpoints cannot access. Under network congestion, non-SWQoS transactions are frequently dropped before they reach the leader.
2. Jito bundles: Atomic multi-transaction submission via Jito’s block engine, which controls roughly 40–45% of stake in 2026. Enables MEV-competitive execution and pre-confirmation guarantees for bundle-eligible strategies. Available natively on Quicknode (Lil’JIT) and Helius (Sender), and via Chainstack’s Warp transaction path using bloXroute.
3. bloXroute relay: An alternative relay network that bypasses gossip and forwards transactions directly to the current leader. Powers Chainstack’s Warp Transactions product. Claimed 382ms speed advantage over standard RPC transmission, with up to 99% landing rates in favourable conditions.

Chainstack for high-frequency trading and market making on Solana

Chainstack’s Solana product has matured considerably in the past 12 months. The two components that matter most for HFT workloads are Solana Trader Nodes and Warp Transactions.

Trader Nodes are regionally bound, latency-optimised RPC endpoints tuned specifically for trading workloads. Unlike Global Nodes — which geo-balance requests across regions — Trader Nodes are pinned to a single location you choose, minimising jitter from regional failover. They support the full JSON-RPC interface plus Yellowstone gRPC streaming, and ship with Jito ShredStream enabled by default since early 2026. ShredStream means your node receives block shreds directly from Jito validators as they propagate, before the full block assembles — the earliest possible signal for latency-sensitive strategies. The Geyser plugin on Chainstack Trader Nodes enables real-time account update streaming, which is the foundation for a responsive quote engine.

Warp Transactions handle the other half of the problem. When you call sendTransaction through a Chainstack Trader Node with Warp enabled, the transaction is intercepted and routed through the bloXroute relay network directly to the current slot leader, bypassing gossip entirely. This requires no changes to your transaction construction — no tip instructions, no memo fields. You switch an endpoint, and every sendTransaction call automatically uses the fast path. Chainstack reports landing rates of up to 99%, with 83% of transactions landing in the first block. In production, this metric depends heavily on tip amounts and network conditions, but the architecture — validator-direct submission — is the correct approach.

Pricing for Trader Nodes is transparent: standard RPC calls cost 1 RU, archive calls cost 2 RU, and sendTransaction via Warp is billed at $0.15 per transaction on top of the subscription plan. For high-volume operations, the Unlimited Node add-on at flat-fee RPS tiers (25–500 RPS) removes per-request billing entirely, which significantly simplifies cost modelling for HFT workloads. Chainstack plans relevant to trading teams: Growth ($49/mo, 20M RU, 250 RPS), Pro ($199/mo, 80M RU, 400 RPS), Business ($499/mo, 200M RU, 600 RPS), and Enterprise ($990/mo, 400M RU, unlimited RPS).

Institutional trading desks and regulated fintech teams have an additional requirement that Helius and Triton One don’t cover: compliance documentation as a procurement gate. Chainstack’s SOC 2 Type II certification is backed by SLAs with financial penalties — not symbolic service credits — at 99.99% uptime. RBAC via SAML/OIDC SSO, encrypted private endpoints, and a single contract covering 70+ chains compress the vendor management overhead that institutional teams typically face. For trading desks where legal and compliance teams are in the approval chain, this matters as much as latency.

See Chainstack Enterprise for enterprise-specific terms and SLA details.

SOC 2 Type II certification is available and documented, which matters for teams operating in regulated environments or seeking institutional counterparty relationships.

Code example — Yellowstone gRPC stream on a Chainstack Trader Node:

import grpc
import solana_storage_pb2
import solana_storage_pb2_grpc

CHAINSTACK_GRPC = "your-trader-node-grpc-endpoint:10000"
X_TOKEN = "your-chainstack-api-key"

def subscribe_to_accounts(account_pubkeys: list[str]):
    metadata = [("x-token", X_TOKEN)]
    channel = grpc.secure_channel(CHAINSTACK_GRPC, grpc.ssl_channel_credentials())
    stub = solana_storage_pb2_grpc.GeyserStub(channel)

    request = solana_storage_pb2.SubscribeRequest(
        accounts={
            "market_accounts": solana_storage_pb2.SubscribeRequestFilterAccounts(
                account=account_pubkeys
            )
        }
    )

    for update in stub.Subscribe(request, metadata=metadata):
        if update.HasField("account"):
            slot = update.account.slot
            pubkey = update.account.account.pubkey
            data = update.account.account.data
            # feed into your pricing engine here
            process_account_update(slot, pubkey, data)

if __name__ == "__main__":
    # Subscribe to a Pyth oracle and a Phoenix market account
    subscribe_to_accounts([
        "H6ARHf6YXhGYeQfUzQNGk6rDNnLBQKrenN712K4AQJEG",  # Pyth SOL/USD
        "4DoNfFBfF7UokCC2FQzriy7yHK6DY6NVdYpuekQ5pRgg",  # Phoenix SOL/USDC market
    ])

Note: Yellowstone gRPC is available on Trader Nodes and Dedicated Nodes on Growth plan and above. The Geyser stream pushes updates as they occur at the validator layer — no polling required.

Need to test on Devnet first? Grab testnet SOL from the Chainstack Solana faucet.

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

Deploy your Solana Trader Node on Chainstack →

Provider comparison for Solana HFT and market making

Quicknode

Quicknode has one of the most developed Solana trading stacks among multi-chain providers. Their SWQoS implementation routes transactions via Quicknode’s own staked validator connections when priority fees are set at recommended or higher — this is built into the standard sendTransaction path, requiring no add-on for basic stake-weighted routing. Their Lil’JIT add-on enables native Jito bundle submission directly from a Quicknode endpoint, giving trading desks access to Jito’s 40–45% stake share without managing separate Jito API keys. Yellowstone gRPC is available as a marketplace add-on on port 10000.

Pricing is credit-based and method-weighted, which creates cost uncertainty for HFT workloads. getProgramAccounts carries higher credit weights than basic reads, so teams with order-book-heavy strategies should model actual costs against real call patterns before committing. The Growth tier starts at $49/month; enterprise pricing is custom. Standard shared plan caps sit at 400 RPS, which is a genuine constraint for multi-pair market makers. Dedicated Nodes are available from the Pro plan and resolve the RPS ceiling. Quicknode holds SOC 2 Type II, SOC 1, and ISO 27001 — the strongest compliance portfolio in this comparison.

Limitations: No flat-rate unlimited tier; credit-based billing with method weighting requires careful cost modelling before production launch. Jito bundle access requires the Lil’JIT add-on at extra cost.

Fit for Solana HFT and market making:

• Write-path quality (SWQoS + Jito): Excellent — built-in SWQoS via stake pool, Lil’JIT for Jito bundles
• gRPC streaming: Strong — Yellowstone gRPC available as an add-on, solid performance
• Dedicated throughput: Strong — dedicated nodes resolve RPS ceilings on Pro and above
• Pricing transparency: Moderate — method-weighted credits require workload modelling
• Compliance: Excellent — SOC 2 Type II + SOC 1 + ISO 27001

Helius

Helius is Solana-native and built around the assumption that trading and data workloads are the primary use case. Their validator stake is real and substantial — they operate one of the largest Solana validators, which feeds directly into their SWQoS routing for sendTransaction. The Sender product is their managed submission path: it submits your transaction in parallel across Jito and Helius relay infrastructure across seven global regions, with tip-only billing (you only pay the Jito tip, not an additional per-send fee on top). This architecture is cleanly designed for market makers who need high landing rates with predictable submission economics.

LaserStream is Helius’s branded Yellowstone gRPC service. It delivers filtered, structured account update streams via gRPC and is gated to Business ($499/month) and Professional plans on mainnet. Enhanced WebSocket subscriptions are available from the Developer tier. For read workloads, most standard methods cost 1 credit per call, making Helius one of the more cost-efficient options for read-heavy market making — but getProgramAccounts is priced at 10 credits, which affects full order-book scans significantly.

Limitations: No multi-chain coverage — Helius supports Solana only. LaserStream mainnet gRPC requires Business tier or above. No public SOC 2 certification, which excludes Helius from some institutional procurement processes.

Fit for Solana HFT and market making:

• Write-path quality (SWQoS + Jito): Excellent — native validator stake, Sender parallel submission across 7 regions
• gRPC streaming: Excellent — LaserStream is purpose-built for real-time trading data
• Dedicated throughput: Strong — dedicated nodes and staked connection tiers available
• Pricing transparency: Strong — 1 credit/call for most reads; getProgramAccounts weight is the notable exception
• Compliance: Limited — no public compliance certifications

Triton One

Triton One created Yellowstone — the gRPC streaming standard that every other provider in this comparison implements. They power Openbook, Pyth, and Wormhole at scale. Dragon’s Mouth (live gRPC stream), Old Faithful (full historical ledger from genesis), Steamboat (custom getProgramAccounts indexes), and Jet (transaction relay with SWQoS) are all Triton-authored, open-source, and running in production. Every Triton customer now sends through staked connections at no extra cost — a pricing change that makes Triton the most builder-friendly option for SWQoS access specifically.

Triton switched to a bandwidth + compute complexity pricing model in early 2026, replacing opaque credit tiers with charges based on actual data moved and work done. Standard RPC is priced at $10 per million calls; historical ledger access is $25 per million calls, plus bandwidth. This model is the most honest in the market for teams with data-heavy workloads — you see what you’re actually consuming. Dedicated nodes start at approximately $2,900/month for typical trading configurations, which puts Triton out of scope for early-stage operations but positions it as the infrastructure benchmark for professional desks.

Limitations: No parsed APIs, no higher-level developer tooling. Triton assumes users want raw RPC access and will build the rest of the stack themselves. No public SOC 2 certification — a disqualifier for regulated deployments. Pricing is appropriate for institutional scale; not competitive for teams under ~$3K/month infrastructure budgets.

Fit for Solana HFT and market making:

• Write-path quality (SWQoS + Jito): Excellent — SWQoS included for all customers, Jet relay, Cascade Marketplace
• gRPC streaming: Excellent — Dragon’s Mouth is the reference implementation
• Dedicated throughput: Excellent — purpose-built bare-metal, 20+ data centres near validator clusters
• Pricing transparency: Strong — bandwidth + complexity model is genuinely transparent
• Compliance: Limited — no public certifications

Alchemy

Alchemy added meaningful Solana capabilities in 2025 following the DexterLab acquisition and has positioned itself as a credible option for multi-chain teams who want a single infrastructure vendor. Global average Solana latency sits at 40–60ms, and the free tier provides 30 million compute units per month. The developer experience is strong — detailed metering, replay tooling, and consistent JSON-RPC behaviour across chains.

For HFT and market making specifically, Alchemy trails Helius and Triton on Solana-native features. Native Jito bundle submission is not available on Alchemy (teams must use separate Jito API credentials). SWQoS routing is not documented as a first-party feature. gRPC streaming support on Solana is less prominent in their documentation than on Helius or Triton. The 300 RPS shared ceiling can constrain multi-pair operations. For teams already on Alchemy for EVM work who need Solana as a secondary chain, the consolidated billing and familiar developer experience make sense. For teams where Solana trading is the primary workload, the Solana-native providers deliver more per dollar.

Alchemy holds SOC 2 Type II certification.

Limitations: No native Jito bundle submission. SWQoS configuration is not publicly documented for Solana. 300 RPS shared ceiling. Solana-specific feature velocity is slower than Helius and Triton.

Fit for Solana HFT and market making:

• Write-path quality (SWQoS + Jito): Moderate — no native Jito; SWQoS not publicly documented for Solana
• gRPC streaming: Moderate — available but less mature than Solana-native providers
• Dedicated throughput: Moderate — no dedicated node option on standard plans
• Pricing transparency: Strong — compute-unit pricing is well-documented
• Compliance: Strong — SOC 2 Type II

Real-world performance benchmark

Solana is tracked on the Chainstack performance dashboard. The dashboard provides real-time and historical latency data across providers and regions.

For HFT workloads, the most relevant method-level metrics to review are sendTransaction round-trip time (a proxy for write-path responsiveness), getAccountInfo P50 and P99 (read-path baseline), and getProgramAccounts P99 (the stress-test method for order-book strategies). Prioritise P99 over P50 when evaluating for market making — your strategy’s worst-case execution quality matters more than its average.

Getting started with Solana trading on Chainstack

1. Create a Chainstack account or log in to the console
2. Create a new project or select an existing one
3. Navigate to Solana → Mainnet and deploy a Trader Node, selecting the region nearest to your execution environment (US East is typically best for validator proximity)
4. Enable Warp Transactions on the node settings panel — this activates bloXroute relay for all sendTransaction calls
5. Copy your HTTPS endpoint for JSON-RPC and your gRPC endpoint for Yellowstone streaming
6. For the Geyser plugin, configure your subscription filters in your bot to subscribe to the specific program accounts and oracle accounts your strategy watches

For detailed setup documentation on Yellowstone gRPC configuration, Warp Transactions, and SWQoS behaviour on Chainstack nodes, see the Solana tooling documentation on Chainstack Docs.

Minimal working example — sendTransaction with getLatestBlockhash refresh:

import asyncio
from solders.keypair import Keypair
from solders.pubkey import Pubkey
from solders.transaction import VersionedTransaction
from solana.rpc.async_api import AsyncClient
from solana.rpc.commitment import Processed

RPC_URL = "https://your-chainstack-trader-node-endpoint"

async def send_with_fresh_blockhash(client: AsyncClient, tx_instructions, signer: Keypair):
    # Always fetch a fresh blockhash immediately before signing
    bh_resp = await client.get_latest_blockhash(commitment=Processed)
    recent_blockhash = bh_resp.value.blockhash

    # Build and sign transaction with fresh reference
    msg = build_message(tx_instructions, recent_blockhash, signer.pubkey())
    signed_tx = VersionedTransaction(msg, [signer])

    # sendTransaction goes through Warp when enabled on the endpoint
    result = await client.send_raw_transaction(
        bytes(signed_tx),
        opts={"skip_preflight": False, "max_retries": 0}
    )
    return result.value  # transaction signature

async def main():
    async with AsyncClient(RPC_URL) as client:
        signer = Keypair.from_base58_string("YOUR_PRIVATE_KEY")
        sig = await send_with_fresh_blockhash(client, [...], signer)
        print(f"Submitted: {sig}")

asyncio.run(main())

Note: Set max_retries: 0 on sendTransaction when using Warp. Retry logic should be handled at the application layer with fresh blockhash fetches — automatic retries can resubmit with expired blockhashes, which fail silently.

Need devnet SOL for testing? Grab some from the Chainstack Solana faucet.

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

Explore Solana trading infrastructure on Chainstack →

Conclusion

On Solana in 2026, the infrastructure decision for market makers comes down to one question before any other: how does your provider route your sendTransaction calls when the network is congested? Shared gossip-path endpoints get dropped. SWQoS-enabled dedicated nodes don’t.

• Triton One: highest-capability infrastructure for professional desks; no SOC 2, custom procurement required, dedicated nodes from ~$2,900/month
• Helius: best Solana-native option for teams where Sender parallel submission and LaserStream gRPC fit the strategy; no multi-chain coverage, no compliance certs
• Chainstack: best balance of trading capability (Dedicated Nodes, Trader Nodes, Warp), flat-rate pricing, and SOC 2 Type II compliance for institutional requirements
• Quicknode: best option for multi-chain teams who need Solana alongside 80+ other networks, with native Lil’JIT Jito integration
• Alchemy: appropriate for teams already on Alchemy for EVM work where Solana trading is a secondary use case

Deploy your Solana RPC endpoint on Chainstack →

FAQ

Q: What transaction landing rate should I expect from a Solana market making bot in 2026?

A well-configured bot using SWQoS-enabled infrastructure and appropriate priority fees should target a 95%+ landing rate under normal conditions. Landing rates below 90% during non-congestion periods are a signal to investigate your submission path — you may be routing through gossip rather than a staked connection. During major congestion events like token launches or liquidation cascades, even optimised infrastructure sees degradation; Jito bundle submission and Warp relay help stabilise the worst-case tail.

Q: Do I need a dedicated node, or can I start on a shared Solana RPC?

Shared nodes are adequate for development and low-frequency strategies. For production market making, the noisy-neighbour problem on shared infrastructure creates unpredictable P99 latency spikes — particularly on getProgramAccounts queries — that are incompatible with consistent quoting. The upgrade to a Dedicated Node or Unlimited Node add-on tier becomes necessary once your strategy depends on sub-slot reaction time or when you’re running more than two pairs simultaneously.

Q: Can I use Jito bundles from Chainstack’s Trader Nodes?

Not natively from the Chainstack endpoint — Chainstack’s write-path enhancement is Warp (bloXroute relay), not Jito bundle submission. For strategies that require Jito’s atomic bundle execution, you can submit directly to Jito’s block engine API endpoints in parallel with your Chainstack-routed transactions. Quicknode’s Lil’JIT add-on and Helius’s Sender product offer native Jito integration within a single endpoint.

Q: How important is gRPC vs WebSocket for real-time market data on Solana?

Yellowstone gRPC is meaningfully superior for high-frequency market data. WebSocket JSON-RPC subscriptions add serialisation, JSON parsing, and gossip propagation overhead that gRPC bypasses with binary-encoded protocol buffers and direct validator-to-client push. In practice, gRPC streams deliver account updates 50–150ms earlier than equivalent WebSocket subscriptions under load. For strategies reacting to price changes in order-book programs, this is material edge.

Q: Which providers offer SOC 2 compliance for institutional clients on Solana?

Chainstack (SOC 2 Type II), Quicknode (SOC 2 Type II + SOC 1 + ISO 27001), and Alchemy (SOC 2 Type II) all hold public compliance certifications. Helius and Triton One do not publish SOC 2 certifications, which restricts their eligibility for institutional procurement processes where compliance documentation is a requirement.

Q: How does Chainstack’s Unlimited Node add-on compare to per-request billing for a market making operation?

For operations generating 5–20 million RPC calls per month, the Unlimited Node add-on at flat RPS tiers typically delivers a better effective rate than per-request billing, with zero overage risk. At Business plan ($499/month) with the Unlimited add-on, you get predictable costs and 600 RPS baseline — the combination that simplifies financial modelling for active trading desks. Warp transaction sends are still billed per use at $0.15/tx.

Additional resources

• How to get a Solana RPC endpoint in 2026
• Solana trading infrastructure 2026: MEV, nodes, latency
• Solana Trader Node documentation — Chainstack Docs
• Solana tooling documentation — Chainstack Docs
• Tutorials and guides for Solana on Chainstack
• More Solana tutorials and articles on the Chainstack blog
• Chainstack performance dashboard
• Chainstack pricing
• Chainstack Solana devnet faucet