SWQoS for everyone: why we retired Cascade Marketplace

We’ve got some big news to share! We’ve retired Cascade Marketplace and cancelled all standing bids as of February 28th. This doesn't mean we stopped providing staked sending; it just means we stopped charging for it.

Recent Anza improvements have significantly increased bandwidth for staked senders, letting us deliver Cascade-level transaction performance to far more users. So instead of running SWQoS as a paid product, we're making it the default for every Triton customer at no extra cost.

Our north star, driving everything we build, is the best possible service for every customer. This change is no different. Let's break it down.

How SWQoS works and why it's changing

SWQoS is a Solana innovation developed by Anza that protects validators from spam by prioritising transaction traffic without slowing the network. The Agave client splits a validator's bandwidth between senders with stake (2,000 connections) and without (500 connections). If your identity is backed by SOL, you get guaranteed bandwidth proportional to your stake. If it isn't, you share a fixed pool with every other anonymous sender: 200 TPS across up to 8 connections.

Cascade was Triton's stake-weighted bandwidth marketplace, which gave customers priority sending without running a validator themselves. You'd purchase bandwidth backed by staked identities, and your transactions would be routed through our optimised pipeline with that stake attached. We spent years perfecting it: minimal hops, optimised forwarders and load balancers. Meanwhile, across the industry and on Triton's own unstaked paths, transaction forwarding still went through standard RPCs.

Yellowstone Jet, the sending engine behind Cascade, has been open source since last year, but was only available as a standalone binary. We've now modularised it into a crate, making it much easier to integrate direct-to-leader sending into your own stack – no stake weight required. That was our first step toward making transaction landing faster and more reliable for everyone.

Anza's continuous improvements to Agave reinforced that direction, reducing how much stake is needed to achieve the best performance possible. With the upcoming Solana 4.0 release (planned for March), SWQoS will become a congestion-only backstop: the network will no longer split capacity between staked and unstaked traffic under normal conditions, and it will activate only when a block producer's TPU reaches 90% capacity. The planned 4.1 release continues the trend with deterministic token buckets and bandwidth redistribution.

At the same time, JitoBAM (60% of active stake), Harmonic (16%), and Firedancer are actively working on different ways to guard TPU without relying entirely on SWQoS, bringing us another step closer to a world where stake-weight gating is no longer the primary protection mechanism.

Our latency tests tell the same story. At p50, staked and unstaked sending perform nearly the same (see image below), and any remaining gaps are covered by Triton's staked fallback, now included for every subscription.

What this means for your transactions

This spring, we're transitioning all transaction traffic to our Jet instances. Here's what that means for you:

1. All transactions going straight through Jet. Every sendTransaction call on Triton will go through Jet, our sending service that tracks the leader schedule in real time, pre-connects to upcoming leaders over QUIC, and delivers your transactions with as few hops as possible.

2. Staked routing included by default. All customers, including those who never used Cascade, now automatically get stake-weighted routing. No extra configuration or action needed

3. Faster path for everyone, including Cascade users. We streamlined the pipeline by removing marketplace connections, stake-level routing, and Cascade vs non-Cascade filtering, giving your transactions an even simpler and faster path with no change in landing rates.

For latency-sensitive workloads

If you're running arb strategies, liquidation engines, or anything where milliseconds matter, consider integrating the Yellowstone Jet TPU client directly into your backend.

Note: pre-Agave 4.0, stake weight still makes a significant difference even though unstaked performance has improved a lot. After 4.0, we expect the gap to narrow, making Jet TPU a stronger choice for latency-sensitive workloads.

There's no intermediary in that path at all, and Jet handles QUIC handshakes, manages connection caching without lock contention, tracks leader schedules, and supports transaction callbacks, contact info overrides, blocklist/allowlist controls, and multi-step identity updates out of the box.

The library is open source, the docs are public, and the deep-dive walkthrough covers everything from setup to sending your first transaction. 

Yes, this means fewer billable calls on our end, but we're recommending it anyway, because the right answer for latency-sensitive workloads is the one that gets you closest to the leader.

Frequently asked questions

Will my landing rates or latency change if I used to be on Cascade? We've simplified the path your transactions take, so they now make fewer hops. Your landing rates stay the same, and latency should improve as we roll this out.

Will my landing improve if I wasn't on Cascade? Yes. We're gradually rolling out Jet routing for all customers. You should see faster transaction sending this month as the transition continues.

What is SWQoS? Stake-Weighted Quality of Service is a transaction traffic control mechanism that reserves capacity for packets coming from staked validators, in proportion to their stake. It protects the network from spam and ensures reliable delivery during congestion. With Anza's upcoming changes, the static 80/20 split becomes a dynamic fallback that only activates under load.

What was Cascade? Cascade was Triton's stake-weighted bandwidth marketplace. Customers purchased bandwidth backed by staked validator identities for priority transaction delivery. Its routing engine, Jet, is now the default for all Triton customers, with stake-weighted routing included at no extra cost.

What is Jet? Jet is our high-performance transaction relay engine. It tracks the Solana leader schedule in real time, pre-connects to upcoming leaders over QUIC, and sends transactions with minimal latency. We also released it as a standalone Rust TPU client crate, so teams can integrate the same battle-tested sending logic directly into their own stack. It supports transaction tracking with callbacks, TPU contact info overrides, sending to arbitrary peers, multi-step identity updates, and blocklist/allowlist controls.

Can I run Jet myself? Yes. The Yellowstone Jet TPU client is open source and available as a Rust crate. If you want the lowest possible latency, integrating it directly into your backend removes all intermediaries (keep in mind, that pre-Agave 4.0, stake weight still makes a significant difference).

Deshred transactions: the fastest path to Solana data

TL;DR

• Triton's new Deshred endpoint delivers the earliest on-chain signal, fully deserialised and reconstructed from shreds
• With upcoming protocol upgrades, shaving off milliseconds becomes non-negotiable for arbitrage bots, snipers, liquidators, market makers, copy-traders and HFT systems
• Waiting for a node to execute and replay a slot adds latency that varies with transaction complexity and account contention
• Deshred subscription removes that delay by exposing transaction intent as soon as entries are formed from shreds, bypassing tx execution, account locking, and replay
• It offers server-side filtering to automatically strip vote transactions and target specific accounts (static keys and dynamically loaded addresses from Address Lookup Tables (ALTs))
• Deshred is now available in paid beta as a new subscription type within Triton's Dragon's Mouth (yellowstone-grpc). If you're a Triton customer and want early access, reach out to get on the waitlist.

Introducing Deshred transactions (beta)

In high-frequency environments, execution speed is not the only latency bottleneck. Any trading system is only as profitable as its ability to react fast and accurately to market moves, which, in practice, means tracking and responding to other players' order flow.

Triton built Yellowstone gRPC (Dragon's Mouth) to push events as they happen on-chain, directly from the validator pipeline. However, it still reports only on replayed events, giving you a view of what just happened. Imagine being able to see the transactions before they're executed on the RPC – while the validator is still processing the slot.

With Deshred transactions, now you can.

Deshred is Triton's new streaming solution (currently in paid beta) that shifts data extraction further upstream in the validator pipeline, delivering transaction data to your backend before the node completes slot execution. This gives you a much earlier signal and a tangible advantage in how fast you can react to market events.

How Deshred transactions work (high level)

Before jumping into how exactly this new architecture allows you to be faster than the rest of the market, let's first recap what happens when someone sends a transaction on Solana.

After a validator includes a transaction in a block, it sends the block out as shreds – small, MTU-sized packets (~1,228 bytes) that together form micro-blocks called entries. Shreds are propagated via Turbine, Solana's block-propagation protocol, first to highly staked, co-located validators like Triton's, and then to the rest of the network.

From there, the shreds enter the receiving node's TVU (Transaction Verification Unit), which runs through several distinct stages, each adding its own latency:

The main difference between a Dragon's Mouth gRPC stream and Deshred transactions is when updates are pushed.

Standard Geyser streams emit data only after the node has replayed and executed a transaction. This ensures data integrity and provides full execution context – logs, balance changes, inner instructions, success/failure status – but the step-by-step nature of the Replay stage introduces a delay that scales with transaction complexity and account contention.

For most use cases, that delay is negligible, but for strategies that depend on the earliest possible intent detection and the slightest market activity, even Yellowstone gRPC sometimes arrives too late to act on.

Deshred streams address this by intercepting the pipeline immediately after shred arrival and entry reconstruction, at the CompletedDataSets (Blockstore) stage, bypassing the Replay stage entirely and streaming decoded transactions directly to your backend over gRPC.

Deshred transactions features

Deshred streams are built for one thing: giving you the earliest usable view of on-chain intent. They deliver:

Managed reconstruction. Shred assembly, erasure recovery, and entry deserialisation happen server-side. You receive fully reconstructed transactions over gRPC — no raw UDP packets, no Reed-Solomon decoding, no shred bookkeeping on your end.

Zero-overhead integration. Exposed as the SubscribeDeshred RPC in Yellowstone Dragon's Mouth, so you subscribe the same way you would for any other gRPC stream — no custom infrastructure required.

Noise reduction. Server-side vote filtering lets you drop vote transactions before they ever reach your backend, eliminating the majority of network traffic in a single flag.

Account filtering. Filter by accounts present in the transaction message — both static account keys and dynamically loaded addresses from Address Lookup Tables (ALTs). Isolate specific markets or programs (e.g. Raydium, Orca, Jupiter) while ignoring everything else.

Intercepting the pipeline that early does, however, come at a cost: some information simply isn't available yet. Here's how it stacks up against Triton's Yellowstone gRPC, the ecosystem's go-to streaming standard, on both features and datapoints.

Performance benchmarks: Deshred vs gRPC

As the breakdown above shows, the latency improvement stems directly from the computational work skipped. By avoiding transaction execution (signature verification, account locking, BPF/SVM execution, and state commitment), data is available as fast as the node can reconstruct entries from incoming shreds.

According to our benchmarks, Deshred delivers transactions with a p50 latency of ~6.3 ms and a p90 of ~20 ms from the moment shreds arrive at the node.

The exact advantage over Dragon's Mouth varies per transaction: a simple SOL transfer with no account contention may execute almost instantly in the scheduler, while a complex DeFi swap touching hot accounts can queue behind other transactions for significantly longer. The Replay stage delay is not a fixed number: it depends on instruction complexity, account lock contention, and overall slot load.

What Deshred guarantees is that you always see the transaction before any of that execution overhead occurs.

Who should use Deshred transactions?

We've built Deshred transactions alongside our Yellowstone gRPC to serve very specific latency-sensitive use cases where seeing intent before execution can be more valuable than seeing the result after the fact.

• Arbitrage: Detect price dislocations across AMMs before state updates propagate to the rest of the network.
• Market making: React to incoming order flow and adjust quotes before executions settle – tighter spreads with lower adverse selection.
• Copy trading: Identify target wallet activity at the intent level, ahead of other copy traders who wait for confirmed execution.
• Liquidations: Forecast liquidation events from pending position changes and resolve risky positions faster.
• HFT signal ingestion: Feed models with raw chain intent data for the earliest possible feature extraction.

If your application is not millisecond-sensitive or depends on confirmed account state, use Dragon's Mouth, Whirligig or Fumarole instead. They remain the correct choice for frontends, wallets, explorers, indexers, and analytics platforms.

Getting started

Deshred transactions are integrated directly into Yellowstone Dragon's Mouth as a new gRPC subscription type: SubscribeDeshred.

This endpoint is only available on Triton One's gRPC servers and is currently in paid beta with limited availability. If you want access, please reach out. The Yellowstone gRPC codebase is open-source, but the SubscribeDeshred implementation relies on the Triton fork of the Agave validator's Geyser plugin interface, which adds the deshred transaction notifier to the CompletedDataSets pipeline. It is not part of the default Agave release. Anyone is free to implement the same approach (as the code is public), but it will not work out of the box on a stock Agave node.

Here is a minimal Rust example that subscribes to a deshred transaction:

use {
    futures::{sink::SinkExt, stream::StreamExt},
    solana_signature::Signature,
    std::collections::HashMap,
    tonic::transport::channel::ClientTlsConfig,
    yellowstone_grpc_client::GeyserGrpcClient,
    yellowstone_grpc_proto::prelude::{
        subscribe_update_deshred::UpdateOneof, SubscribeDeshredRequest,
        SubscribeRequestFilterDeshredTransactions, SubscribeRequestPing,
    },
};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let endpoint = std::env::var("ENDPOINT")
        .unwrap_or("http://127.0.0.1:10000".into());
    let x_token = std::env::var("X_TOKEN").ok();

    let mut client = GeyserGrpcClient::build_from_shared(endpoint)?
        .x_token(x_token)?
        .tls_config(ClientTlsConfig::new().with_native_roots())?
        .http2_adaptive_window(true)
        .initial_connection_window_size(8 * 1024 * 1024) // 8 MiB
        .initial_stream_window_size(4 * 1024 * 1024) // 4 MiB
        .connect()
        .await?;

    let request = SubscribeDeshredRequest {
        deshred_transactions: HashMap::from([("deshred".into(),
            SubscribeRequestFilterDeshredTransactions {
                vote: Some(false),
                account_include: vec![],
                account_exclude: vec![],
                account_required: vec![],
            },
        )]),
        ping: None,
    };

    let (mut tx, mut stream) =
        client.subscribe_deshred_with_request(Some(request)).await?;

    while let Some(msg) = stream.next().await {
        match msg?.update_oneof {
            Some(UpdateOneof::DeshredTransaction(update)) => {
                let info = update.transaction.as_ref().unwrap();
                let sig = Signature::try_from(info.signature.as_slice())?;
                println!("slot={} sig={sig} vote={}", update.slot, info.is_vote);
            }
            Some(UpdateOneof::Ping(_)) => {
                tx.send(SubscribeDeshredRequest {
                    ping: Some(SubscribeRequestPing { id: 1 }),
                    ..Default::default()
                }).await?;
            }
            Some(UpdateOneof::Pong(_)) => {}
            None => break,
        }
    }
    Ok(())
}

Key points about the example:

• http2_adaptive_window(true) enables dynamic HTTP/2 flow control, letting the window grow automatically under high throughput instead of staying at the 64 KiB default. Combined with explicit initial window sizes (8 MiB connection, 4 MiB stream), this prevents back-pressure stalls on bursty deshred streams.
• vote: Some(false) drops vote transactions server-side. Votes make up the majority of on-chain transactions and are rarely useful for trading strategies.
• The response includes loaded_writable_addresses and loaded_readonly_addresses – these are addresses resolved from Address Lookup Tables for V0 transactions, giving you the full account set even before execution.

FAQs

What is a shred in Solana?

A shred is the smallest unit of block data propagation in Solana: a signed packet that carries a fragment of block data (or parity for recovery) for UDP broadcast via Turbine. Blocks are serialized into entry batches, and each batch is split into fixed-size chunks that become data shreds; coding shreds are generated over groups of data shreds (FEC sets) using Reed–Solomon erasure coding to enable recovery from packet loss. The maximum serialized shred size (SHRED_SZ_MAX) is 1228 bytes, derived from the IPv6 minimum link MTU (1280) minus IPv6+UDP headers (48) and an additional 4 bytes reserved for an optional nonce; with Merkle authentication, coding shreds remain 1228 bytes while data shreds may be smaller (e.g., 1203 bytes).

Why is deshredding needed?

Deshredding reconstructs complete entries from raw shreds, making transaction data readable before the node's Replay stage processes it. Without deshredding, the transaction data is scattered across multiple UDP packets and mixed with erasure-coding redundancy. This reconstruction is essential for ultra-low-latency applications like HFT, arbitrage, and MEV.

What is Yellowstone gRPC?

Yellowstone gRPC (Dragon's Mouth) is a high-performance Geyser plugin for streaming Solana data via gRPC over HTTP/2, providing real-time updates on accounts, transactions, slots, blocks, and entries with advanced server-side filtering. Built, open-sourced, and maintained by Triton, it has become a standard across the Solana ecosystem.

Can Deshred transactions and Dragon's Mouth be combined?

Yes. Use Deshred for earliest signal detection, to see what is about to be executed, and Dragon's Mouth for the confirmed result with full execution context (status, balance changes, logs, inner instructions). Many strategies benefit from both: Deshred for speed, Dragon's Mouth for confirmation.

How does Deshred compare to raw shred streaming in latency?

Deshred adds a small amount of server-side processing (entry reconstruction and ALT resolution) compared to receiving raw shreds, but it eliminates the substantial client-side complexity of shred assembly, erasure recovery, and entry deserialisation. The net latency difference is negligible (microseconds) while the engineering effort saved is significant.

Is this private order flow?

No. Deshred transactions are extracted from shreds that have already been propagated to the network via Turbine. Every validator receiving those shreds has access to the same data. Deshred simply makes it easier to consume by handling reconstruction server-side and exposing it over gRPC.

How does the Transaction Validation Unit (TVU) process a block?

The table below shows each stage in order, with stream tap-in points marked.

Are there any disadvantages to using Deshred transactions?

Yes. Because Deshred intercepts the pipeline before execution, you only receive the signed instruction data and the accounts referenced: no execution metadata: success/failure status, logs, balance changes, inner instructions, compute units, or return data.

You also get no finality guarantees. A deshredded transaction may fail execution, land on a forked slot, or never confirm. Your application needs to handle all of these scenarios the same way it would when using processed.

Solana gRPC anti-patterns E1: serverless gRPC subscribers

TL;DR

• Serverless functions (like Lambda or GCF) let you run code without managing a server
• They need zero management, but run in an ephemeral, resource-constrained environment that shuts down every 15 minutes on Lambda (9–60 minutes on GCF) and has to be started up again
• Every cold start leaves you dependent on your cloud provider’s state and adds an extra 200 ms to 2+ seconds of delay on average
• On top of that, the function has to do a TCP and TLS handshake, HTTP/2 negotiation, and then the gRPC subscribe request, totalling 3-4 round trips each time
• Using Lambda (and similar tools) to subscribe to Solana events leads to dropped messages, latency spikes, and inconsistent performance
• It also causes you to miss transaction confirmations, because the overhead latency often takes longer than it does for the event to land in a block
• The fix is to use a VPS or bare metal server that keeps the connection open permanently, lets you configure it manually, and allows for much higher bandwidth

Introduction

We’ve been running infrastructure for the most demanding workloads on Solana since before its testnet. Over the past 6 years, we’ve spent almost every day optimising our code, breaking things and chewing glass (and we’ll continue to do so). But while we handle the heavy lifting, there are decisions on your end that can make or break the whole setup.

Along the way of powering both enterprises and startups, we’ve seen the same mistakes come up again and again. As our customers (that’s you!) are building the most ambitious things on the fastest L1, we want to be proactive and make sure the infrastructure side of things, even on your end, never gets in the way.

This article is the first in a series where we break down the most common Solana streaming anti-patterns, so you can avoid them early instead of fixing in prod.

First up is using Lambda and other serverless functions to subscribe to gRPC streams, resulting in constant data skips and missing transaction confirmations.

What is Lambda?

Lambda is Amazon’s serverless compute service. You upload a function, AWS runs it on demand, and you pay only for the milliseconds it runs. As it’s purpose-built for short-lived workloads, each execution window is capped at 15 minutes (default is 3s). If your function runs longer, AWS stops the process, and you have to start again from scratch in a new environment, with all the usual cold-start costs.

During execution, network throughput depends on the function's current load and the amount of memory you’ve allocated. Because you are typically sharing it with thousands of other tenants, you will see significant jitter and inconsistent performance.

Google Cloud Functions and Azure Functions work similarly and share similar constraints. For the rest of this article, we will use “Lambda” as shorthand for all of them, since it is the most popular option.

Serverless functions VS servers

A server, whether it’s a bare metal box or a VPS, is a machine you configure yourself. You choose the CPU, the RAM, the bandwidth, set up the OS, deploy your code, wire your process manager, and maintain it over time. Think of it like renting an office: you pick the building, set up the furniture, choose the internet plan, and stay for as long as you’re paying. Nobody else can use it while you’re away, and it’s at your disposal whenever you need it.

A serverless function is much easier to get started with. You write your application logic, hand it to the cloud provider, and they decide where and how to run it. That is more like joining a shared coworking space. You avoid the hassle and can just show up and work, but you have zero control over the environment. Desks might be full, your seat might be taken when you get back from lunch, and you can’t rearrange the furniture or stay past closing hours.

For bursty, stateless workloads such as REST APIs, image processing, or scheduled tasks, this trade-off is perfect. You handle a request, return a response, and you’re done. For a gRPC stream that needs to stay open for hours, days, or indefinitely, it’s a killer.

What is the problem? 

One of the biggest benefits of gRPC streaming over polling is avoiding the constant request-response trips. You establish a subscription once and get a low-latency, continuous data firehose. Setting that up isn’t free, though. Every new connection has to complete a multi-step handshake before sending any data:

1. Opening the TCP connection (one network RT)  
2. Setting up encryption (one RT with TLS 1.3, two with TLS 1.2)  
3. Exchanging HTTP/2 settings for gRPC (another RT)  
4. Sending the gRPC subscribe request with the program, accounts, and commitment you want to receive (final RT)

That is 3-4 network RTs before a single update arrives (happening every 15 minutes). And every time, while you are reconnecting and resubscribing, the chain keeps moving. Any block produced or transaction included in that gap is data you’ll never see.

On top of that, Lambda has to provision the execution environment before the handshake even starts. AWS needs to allocate the runtime, initialise your code, and set up networking. This is the cold start, and it adds an overhead delay on top of the handshake (on average, 500 ms-2s).

If you send a transaction and only then spin up a Lambda to listen for its confirmation, you are looking at 600 ms to 2.2+ seconds just to get your listener online. By that point, the transaction is usually already in a block, and you have missed it.

This is not a one-time problem either. Lambda’s 15-minute cap means the platform kills your subscription every quarter hour, and retrying just reruns the same slow sequence, without fixing data gaps.

The fix: stay online

If you are going to build on the fastest chain out there, your infrastructure has to keep up. Get a server (VPS or bare metal), keep your connection open, and make sure you have enough network capacity for heavy streams.

It’s more hands-on than a serverless function, but for most Solana builders, it’s the right choice and saves you a lot of headache in the long run.

The end of the black box: Triton’s new RPC pricing

TL;DR

• Traditional RPC pricing relies on abstract compute units and rigid fixed plans
• This makes infrastructure costs hard to predict, track, and plan around
• Credits and CUs hide the gap between “cheap” and “expensive” requests in lengthy conversion tables
• Fixed tiers push you into bundles bloated with features you don't need
• Developers are forced to spend weeks forecasting their traffic patterns and still risk overpaying, or underprovisioning and hitting overages
• That’s why we moved to a model where you pay for what you actually use, finally making RPC pricing simple, fair, and transparent
• We split the bill into simple categories based on two real cost drivers: bandwidth (moving data) and compute complexity (processing it) 
• This creates a feedback loop where you can see exactly which parts of your workload drive your bill and optimise them
• Triton’s connection limits, RPS, and unit costs are the same on every subscription, so you are never forced to upgrade until you are ready to scale
• We also don’t charge an “emergency” premium, and bill all overages at base rates

Introduction

In the infrastructure market, pricing is often marketed as simple and transparent, but once you run real workloads, it becomes confusing and hard to predict.

If you have built on Solana for any length of time, you have probably run into the credits or compute units (CU) model and the strict fixed plans that sit under it. You sign up for a plan that promises “50 million requests.” You deploy your bot or dashboard. A week later, your service is turned off, or worse, you're silently shifted into "overage" pricing, where every request costs 3x compared to the base plan.

Providers introduce credits and CUs to make things feel simpler on the surface, but in practice, the model often traps teams that don’t have the time to simulate every query pattern up front.

At Triton One, we think a pricing model that optimises for marketing and margins instead of developer success is fundamentally broken. To walk the talk, we built a pricing model that’s truly transparent, fair and straightforward to work with, with no CUs, rigid bundles, or per-method credit tables. You get enterprise performance at a developer price point.

“Standard” pricing models fail most builders

How credits and CUs hide your real costs

One of the biggest sources of confusion for Solana developers is the disconnect between a request and a credit.

100 million credits sounds like a lot if you assume 1 request equals 1 credit. But once you learn that the query you use most often costs 40 credits to run, it becomes clear you’ll hit your limit much sooner than a month.

Not all requests are created equal. A simple getSlot or getBalance is lightweight and puts almost no strain on the node. A getProgramAccounts query with complex filters might require the node to scan memory, filter results, and serialise a large payload.

In the CU model, that heavy request might be weighted at 50, 100 or even 500 credits.

If you're building a trading platform, doing HFT or spinning up indexers, you're not sending “average” queries. You're sending expensive ones. As a result, your “100 million credits” can evaporate after only a few hundred thousand actual calls.

To be fair, many providers publish detailed CU tables for every method. The problem is that this information is not practical to use in real life. You're expected to trust an “average” CU per request, or spend days modelling every call type and traffic pattern before you even pick a plan. 

In the end, most teams guess, ship, and only discover the real cost once their infrastructure’s already built on a closed stack that’s painful to move away from.

How simple tiers force you to overpay

To make things worse, these credits are often locked inside rigid, one-size-fits-all plans. You end up paying for an entire bundle loaded with extras you don’t want just to get the one thing you actually need. 

This leads to 2 predictable outcomes:

Paying for air
You upgrade to the $499 tier for the higher throughput ceiling while knowing you won’t need all the “included” credits and features. You’re paying for bundled resources you never touch, and end up subsidising other users who can fully consume what that tier includes.

The overage cliff
You pick a plan that looks fine on paper, but because your queries are heavier than their “average,” you run out by week 2. Now you’re paying punitive overage rates just to keep your app online.

From flat fees to usage-based pricing

For years, Triton avoided the credit and tier mess by charging a flat monthly fee. It was simple and honest: 1 price, unlimited requests, no overages and no special rate limits depending on a plan.

But simplicity came with tradeoffs. The high entry cost made it harder for solo developers, hackathon teams, and early-stage startups to get access to our premium infrastructure. 

So we asked ourselves: what pricing would work for the developer with a $150 budget and the institution with a $50,000 one, without subsidising one or overcharging the other?

We landed on a model where people pay for what they actually use.

• It's simple because there are only two usage dimensions with clear prices: gigabytes of bandwidth and millions of queries
• It's transparent because you can see exactly which part of your workload drives cost
• And it's fair because limits and unit prices don't change when you cross an arbitrary threshold

How do we price usage?

In practice, the cost of RPC comes down to 2 things: how much data you move and how much work the node has to do to serve it. We bill those 2 cost drivers separately as bandwidth and compute complexity. Because pricing tracks actual cost, we offer the best rates we can to every builder without hiding anything in bundles, CUs or overage tables.

Bandwidth. Moving data costs money. Whether it's websocket traffic or large RPC payloads, we charge a simple rate per gigabyte transferred.

Compute complexity. We group requests into simple categories by how hard they are to serve. Since streaming doesn’t require much compute, it incurs only bandwidth costs, whereas RPC calls have a per-million-query rate.

You can find the complete pricing list on our website, but here’s a summary:

• All streaming services: $0.08/GB
• Standard RPC calls, gTLA and Steamboat (gPA): $0.08/GB + $10/M
• Recent ledger requests (last 3 epochs): $0.08/GB + $10/M
• Historical ledger requests: $0.08/GB + $25/M
• Metaplex DAS, Photon API: $0.08/GB + $50/M

How is this better than classic pay-as-you-go?

Most pay‑as‑you‑go models still rely on credits and complex tables. While that reduces the risk of surprise overage rates or overpaying for bloated bundles, cost forecasting remains almost as tricky as with fixed tiers.

Our new pricing is usage-based, but also designed to be simple to work with. Instead of abstract units, your bill maps back to a small set of real cost drivers you can actually track and plan around. That creates a direct feedback loop with your code, making it much easier to identify bottlenecks early and optimise them fast.

You typically start with a prepaid PAYG balance to test, benchmark your traffic, and quantify your infrastructure needs. Once your pattern is stable, we turn that into a tailored monthly plan that covers your expected load, so you get predictable billing and can go into overages at the base rate instead of getting cut off like on a prepaid balance.

Unlocking premium infrastructure for every builder

This shift is about removing barriers.

By moving to usage-based pricing, we're unlocking Triton’s enterprise-grade RPC stack for everyone. A builder can now start with a $125 prepaid balance and get the same speed, latency, and reliability as our largest institutional clients on the shared infrastructure.

We're not hiding the complexity. We're exposing it so you can control it.
Fair. Transparent. Developer-centric.

Solana gRPC streaming optimisation and troubleshooting (2026 guide)

TL;DR

• Solana’s average daily TPS has almost doubled since December (832 → 1,570). That means x4 more account changes, and the bandwidth needed to stream them
• If your client can’t keep up with this increased throughput, data accumulates in buffers, causing you to drift away from the tip and get disconnected from the stream
• For latency‑sensitive, high‑volume workloads, following best practices stops being optional
• For full‑chain subscriptions (accounts + transactions), you should plan around a 10 Gbps download capacity from your subscriber host
• Target round-trip time of ≤ 50 ms to your RPC endpoint. The further away you are, the more “perfect” other conditions need to be for your client to keep up with the chain
• Always enable adaptive window sizing. There’s no zero downside to having it on
• If your latency is ≥ 7 ms, enable zstd compression. You add a small CPU delay to save substantial network time by reducing payload size
• Use the Triton Yellowstone test client to check if you’re keeping up with the chain and your observed throughput
• If you prioritise data completeness, persistence, availability and resumability over raw low-latency, use Fumarole instead of Dragon’s Mouth

Introduction 

With the new Agave and Firedancer rollouts, Solana is only getting faster. Average TPS has already doubled since December, and a full‑chain feed (transactions + accounts) can now spike up to ~1.3-1.8 Gbps during busy periods. Naturally, more users have started reporting stream disconnects. 

After reviewing many cases, we’ve seen that the limiting factor is usually the client‑side setup, and the good news is that most of these bottlenecks are straightforward to fix.

gRPC streaming bottlenecks

Let’s start by defining the two things your stream (think of it as a pipe) depends on: latency (length of the pipe) and bandwidth (its width). 

Latency is the time between sending a request and receiving a response, usually measured as RTT (round‑trip time). It increases with distance: the farther you are from the server, the more propagation delay you add and the higher your floor on latency (bounded by the speed of light in fibre).

Bandwidth is how much data your connection can move per second (sometimes called throughput). In this article, we’ll use a metric called bandwidth delay product (BDP) to describe the “volume” of the pipe: how much data can be in flight at once. BDP is simply bandwidth × RTT. For example, at ~2 Gbps and 10 ms RTT, Solana geyser traffic gives you ~2.38 MiB in flight.

We’ll keep referring to these terms in each bottleneck below.

1. Your flow control window isn’t set to adaptive

gRPC runs on HTTP/2, which uses a flow‑control window to decide how much data can be in flight before acknowledgements arrive. Unlike a “subscribe and forget” UDP feed, where packets are sent without delivery guarantees, HTTP/2 runs over TCP and only allows the server to send data up to the current window size before it must wait for the client to acknowledge what it has received.

The farther you are from our server, the longer the server waits for acknowledgements, and the larger the window needs to be to keep the pipe full. If your window size is too small compared to the BDP (in-flight volume) of your connection, you’re leaving part of your bandwidth idle. 

How to fix: your window size needs to be >= BDP. The simplest way to achieve this is to enable adaptive window sizing. This lets the client and server negotiate window sizes dynamically based on current throughput and measured latency. There’s no good reason to disable this, and we strongly recommend keeping it on.

GeyserGrpcBuilder::from_shared(“https://your_endpoint”)
	.http2_adaptive_window_size(true)

2. You haven't considered ZSTD compression

If you’re doing large or full‑chain subscriptions without compression, you’re sending more data over the wire than necessary. That extra volume increases the required BDP, making the stream more sensitive to packet loss and jitter and, over time, more likely to drift, buffer, and disconnect.

How to fix: if your latency is higher than 8 ms (for the full Geyser traffic), and you’re experiencing disconnects, we recommend enabling zstd compression to reduce bandwidth requirements (and window-size). At 30 ms or more, we almost always suggest using it to lower the risk of falling behind the chain.

GeyserGrpcBuilder::from_shared(“https://your_endpoint”)
	.accept_compressed(Some(CompressionEncoding::Zstd))

3. You’re too far away from Triton

One of the biggest drivers of gRPC latency is how far your subscriber is from the endpoint. Distance doesn’t just add the raw speed‑of‑light cost in fibre – as most locations aren’t directly connected, longer routes also need more routers, with each “stop” adding extra delay.

We run nodes in all the main Solana clusters, and you want to be as close as possible to one of those locations. Here are some example distances and the RTT latency they typically translate to:

To see your actual RTT, run ‎ping <endpoint> from your server.

Because of the HTTP/2 framework used in yellowstone-grpc, the maximum supported window size is 14.6MiB. Therefore, the ceiling latency for full‑chain streaming is 14.6 MiB / 2 Gbps (edge‑case Solana throughput) ≈ 60 ms. We recommend targeting below 50ms to give yourself some safety margin.

Regardless of workload, higher RTT always means less tolerance for jitter and variable network quality, so lower is always better.

How to fix: move closer. On major cloud providers, you can easily switch your instance’s location to one of the main Solana data centres. If you cannot easily change location, enabling zstd compression can, in certain circumstances, fix the issue.

4. Your network bandwidth is insufficient

10 Gbps download capacity is strongly recommended for large or full‑chain subscriptions. Different regions have very different connectivity, so it can be harder to reach that speed in parts of Asia or South Africa than in the US. 

Also, many cloud instance types cap the network at ~1 Gbps by default, which is only enough for much narrower, focused Solana streams.

How to fix:

1. Reduce the amount of data you request. Once you’ve enabled compression and adaptive window sizing, the next lever is scope. Narrow your subscription to include only what you need (for example, specific programs or transactions only), so the required bandwidth fits your current capacity.
2. Increase bandwidth. If you really need full‑chain or other large feeds, move your subscriber to an instance type or provider that offers higher download capacity (10 Gbps+).
3. Enable Zstd. Enabling compression reduces the bandwidth requirements.

5. You have single‑threaded receive‑and‑process pipeline

A common anti‑pattern in streaming clients is processing data inside the receive loop. If your code receives a transaction, parses it, writes it to a database, and then sends the acknowledgement, all in a single thread, you will almost certainly fill buffers and disconnect under current chain activity.

How to fix: decouple ingestion from processing. Your receive loop should only push messages into a queue/channel and immediately wait for the next one. Use a worker pool to handle parsing, writes, and any other tasks.

How to test your gRPC streaming capacity

We’ve built a tool to check whether your setup can keep up with Solana for a specific subscription, using the exact flags and filters you intend to use in production. It also reports on your actual throughput, so you can confirm whether changes in your code affect how well you track the tip of the chain.

It works by sending a lightweight, application‑level ping message to your subscriber together with the data stream every 10 seconds. The result is:

• Good: if you see the ping number increase by 1 every ~10 seconds, it means you are keeping up perfectly. (You should also see throughput of ~60–80 Mbps for full-chain scans)
• Bad: if you see the new ping every 12+ seconds, or not at all, your client is too slow for the data volume you are requesting, and your setup needs further adjustment

To run the test, download the latest client binary (e.g., client-ubuntu-22.04) and create a subscription with the same settings you plan to use in production. See example code:

./client-ubuntu-22.04 \
  --http2-adaptive-window true \
  --compression zstd \
  --endpoint https://<your-endpoint>.rpcpool.com \
  --x-token <your-token> \
  subscribe \
  --transactions \
  --accounts \
  --stats

When to use Fumarole instead

Dragon's Mouth is designed for traders and bots where ultra-low latency is the metric that matters most. It is a stateless firehose, streaming what the chain is doing right now and does not keep track of where you are, what you missed, or give you an option to restart from disconnection and backfill. 

If your workload is:

• Indexing
• Analytics/Accounting
• Compliance
• Archival
• Involves streaming confirmed data only (e.g. wallets)

You should be using Fumarole instead. It’s purpose‑built for these use cases and is the most reliable and complete data‑streaming service on Solana. 

It adds a state storage layer between multiple downstream Dragon’s Mouth instances and your client, caching ~23 hours of history and the exact position (cursor) where a disconnect occurred (if it does). By decoupling streaming (Dragon’s Mouth) from storing and from the frontend instances that serve the data, it isolates failures on each side and makes the overall pipeline much more robust.

1. Reconnect. If you disconnect, you can resume exactly where you left off using a cursor
2. Backfill. You can replay historical data for up to ~23 hours without complex custom logic
3. Scale. You can use consumer groups to shard the stream across multiple readers

Troubleshooting checklist

If you’re experiencing issues on Triton endpoints and want our help, don’t hesitate to reach out. Before messaging support, please make sure you have the following information ready (we’ll ask for it):

• What is your download capacity? 10 Gbps is ideal.
• What is your RTT to the endpoint? < 50 ms is ideal.
• Have you enabled HTTP/2 adaptive window and zstd compression? Highly recommended.
• What throughput and ping interval does the test client report?

Complete guide to Solana streaming and Yellowstone gRPC

TL;DR

• Starting in 2021, standard RPC polling (repeatedly asking the chain for data) was too slow for HFT, MEV, and high-performance indexing. By the time you get the data, it’s already stale
• In 2021, Solana recognised this limit and added the Geyser plugin system to Agave. This allowed the node to emit all data directly from memory, enabling the ecosystem to build plugins that run outside the node but tap into its state
• Triton pioneered the use of gRPC for this interface, building the Yellowstone gRPC plugin. It allows you to subscribe to the specific data you need and receive it the moment it arrives
• Shortly, other providers and the whole ecosystem adopted Yellowstone to move from pull → push for any workload that needs fresh, structured data: trading, analytics, DEXs, RFQ engines, indexers, explorers, and portfolio management tools
• We never run streaming services on voting validators. We use dedicated, non-voting nodes specifically for streaming to ensure the stream never competes with consensus (or other RPC requests) for resources
• Some of the streaming benefits are: minimising latency and data loss, receiving lightweight payloads (strongly typed Protobufs), eliminating "429 Too Many Requests”, and much more

Introduction

If you are building a trading bot, a real-time indexer, or a DEX on Solana, you have likely hit the "RPC Wall." You hammer an endpoint with getAccountInfo every 200ms, only to get rate-limited or, worse, realise your data is 200ms old by the time it reaches your application logic.

Unlike EVM chains, Solana moves at (almost) the speed of light. On a 400ms block time, being only a little late isn't a thing.

At Triton One, our mission is IBRL – Increase Bandwidth, Reduce Latency. Providing high-performance open-source streaming solutions for the community is one of the ways we achieve it.

This guide walks through how streaming on Solana works, what the Yellowstone stack looks like, how to choose a provider when streaming is your primary workload, when to use RPC vs streaming (and which streaming tools to consider), and how to get started.

How does the Yellowstone Geyser plugin work?

At its core, Yellowstone gRPC (or Dragon's Mouth, as we call it) is a piece of software that compiles down to a dynamic shared library (a .so file on Linux).

It utilises the Geyser Plugin Interface provided by Solana Labs. When a validator client starts up, we pass it a configuration flag telling it to load our library into its own memory space. Once loaded, Yellowstone isn't just "watching" the node; it becomes part of the node. It registers callbacks (hooks) directly with the node’s AccountsDb and Bank.

Here’s the step-by-step of the data flow:

• Whenever the node processes a transaction or updates an account state in memory, it triggers a callback to our plugin
• We capture raw data, accounts, slots, blocks, and transactions before they are even written to disk
• Instead of waiting for a client to request it, we immediately serialise it to Protobuf and push it out via a gRPC interface opened by the plugin
• You receive the data stream (at the commitment level of your choice: processed, confirmed, or finalised)

This bypasses the entire JSON-RPC HTTP layer, eliminating request parsing, JSON serialisation overhead, and polling loops. You subscribe once; the node keeps sending data until you disconnect (unsubscribe).

Where do we run it?

We don’t run Yellowstone on voting validators. Neither do we run it together with nodes serving RPC calls, and we advise our customers with dedicated nodes to do the same (streaming and streaming-only nodes). The goal of streaming is to deliver data immediately, and we want to ensure that speed isn't compromised by "noisy neighbours" spamming heavy RPC calls.

Instead, we run dedicated streaming RPC nodes. These are full bare-metal Solana nodes that follow the cluster and verify the ledger, but don’t vote.

• Optimised for data. Tuned specifically to handle the massive I/O load of streaming
• No contention. Your gRPC subscription never competes with the consensus
• Isolation. We keep streaming nodes physically and logically isolated from general RPC traffic
• Network topology. We run these nodes next to validators in top-tier data centres to shave every last microsecond of physical latency, optimising the path from validators to RPCs and from there to you

How to run Triton’s Geyser plugin yourself?

While we sell managed infrastructure, we believe the core tools should be shared. We do this to empower more innovation on the network, protect the ecosystem from single points of failure, and give you alternatives to proprietary SDKs from the moment you start building.

We maintain the suite so you can tinker with it or bootstrap it anytime.

Yellowstone streaming ecosystem

"Yellowstone" isn't just one engine; it's a suite of open-source tools we built to handle different customer needs. Each project is named after a geyser at Yellowstone National Park because, like a geyser, this infrastructure manages high-pressure, high-speed streams. We’ll focus on its 4 core components:

1. Dragon’s Mouth (aka Yellowstone gRPC)

What it is: Triton’s original ultra-low latency Geyser-fed gRPC interface.
How it works: It connects directly to the node's memory, ingests raw bank data, outputs strongly typed Protobufs, and immediately sends them over the gRPC connection. This is also our "source of truth" for other Yellowstone tools.
Use it for: the absolute lowest possible latency. This is for HFT, MEV, RFQ desks, liquidation engines, and arbitrage traders identifying market inefficiencies.

This was our first product in the suite. As revolutionary as it was, it solved only the problems of speed and wasted bandwidth, and only for the backends.
But at Triton, being the serial problem-solvers we are, we wanted to help everyone. So we kept shipping.

Solana shreds 
    │  
    │  
    ▼
[Validator / Follower] 
    │ Geyser callbacks  
    │ 
    ▼  
[Dragon's Mouth plugin] 
    │ 
    │ Protobuf over HTTP/2  
    ▼  
[gRPC streams → traders / indexers / infrastructure]  

2. Whirligig WebSockets

What it is: A high-performance WebSocket proxy that allows you to reap the benefits of Dragon's Mouth for the frontends.
How it works: It stands between the Dragon’s Mouth plugin and your client. Whirligig ingests the high-speed gRPC stream and translates it into standard Solana JSON-RPC WebSocket messages.
Use case: Ultra-low latency for frontends (Live feeds for DEXs, dApps & Wallets)

You are probably wondering, why build another WebSocket if Solana JSON-RPC already had one?

Standard WebSocket implementation was a great first “draft” at the beginning of Solana, but with Solana's massive throughput and breakneck speed, standard websockets became unreliable under load, degrading in performance, and frequently disconnecting. Furthermore, they were slow: internally waiting until the end of each slot, rather than streaming updates as they occur within the slot.

Whirligig solved all of these issues by moving streaming logic outside of Agave, while maintaining complete backward compatibility.

[Dragon’s Mouth stack]  
    │
    │ gRPC  
    ▼ 
[Whirligig proxy] 
    │ 
    │ WebSocket (Solana WS API)  
    ▼  
[browser / dApp]  

3. Fumarole reliable streams

What it is: A high-availability, persistent, multiplexed streaming service.
How it works: It connects to multiple downstream Dragon's Mouth nodes, aggregates the data, removes duplicates (so you don't process the same block twice), sends it through the gRPC connection, and tracks your position in the data stream.
Use case: When you need whole blocks or confirmed commitment levels for indexers, analytics, lending protocols, and compliance systems that demand 100% data completeness.

We built Fumarole to end the struggle with streaming reliability and eliminate the need for complex backfilling and redundancy logic. Data gaps happen for two reasons:

• Node restarts: validators patch and reboot
• Client disconnects: your server goes down, or the network blips

At Triton, we eliminate p.1 via health checks, redundancy, and immediate auto-failover. However, p.2 is just as important.

To eliminate the issue, we created a service that doesn't try for the "perfect scenario" but works well because disconnects happen. It remembers exactly the moment of disconnect, and once reconnected, you start precisely from where you left off, eliminating the need for complex backfilling and redundancy logic.

[DM node A] [DM node B] [DM node C]  
  └─────── gRPC events ───────┘  
                  │
                  │
                  ▼  
              [Fumarole]  
         merge + dedupe + log  
                  │ 
                  │  gRPC (cursor)  
                  ▼  
    [indexers / DeFi / analytics]  

4. Old Faithful historical streams

What it is: Historical data streaming via gRPC.
How it works: It takes data from our massive historical archive and streams it via gRPC as if it were happening live.
Use it for: Backfilling databases, compliance auditing, taxes, and booting up new indexers.

While developing Old Faithful (the only complete, verified, and public Solana archive), we realised the same gRPC interface could be used to replay history. This solves the "cold start" problem for protocols, relying on streaming. Now you can replay the entire chain history through the exact same pipe you use for live data.

[warehouse nodes]
      │  
      │ snapshots  
      ▼  
[Old Faithful CAR builder] 
      │ 
      │ CAR archives  
      ▼  
[storage: disk / S3 / IPFS]  
   │                    │  
   │ RPC/gRPC (history) │ Geyser replay  
   ▼                    ▼  
[apps needing history]  [Historical streams → indexers]  

Shred streaming

If you’re building on Solana, you’ve probably heard of shred streaming. Simply put, shreds are the atomic units of a block: fixed-size, erasure-coded packets of block data that a leader cuts from batched transactions and broadcasts to other validators, who use them to reconstruct entries and replay the full block

High-staked validators are the first to receive shreds. Standard RPC nodes sit much further downstream in Turbine. If you let nature (or Solana) take its course, you’re waiting an extra 15-80 ms (or even >200 ms for certain slots) for propagation hops and block reconstruction before you see anything.

But at Triton, we bypass the wait through:

• Colocation: our streaming nodes are colocated with high staked validators, giving an edge through rebroadcast shreds whenever they have leader slots
• Global shred distribution network: we automatically distribute all shreds that hit our edge routers through our global network of low-latency networking links to all our streaming nodes, so they see shreds as soon as they enter our network.

By optimising the ingestion step, we eliminate the physical hops and give you a real, measurable speed advantage.

[leader]  
   │
   │ shreds via Turbine  
   ▼  
[high-stake Triton validator]  
   │
   │ early shreds + replay  
   ▼  
[relay nodes]  
   │
   │ low-latency hop  
   ▼  
[streaming nodes]  
   │
   │ gRPC / WS  
   ▼  
[HFT / RFQ / bots / indexers]  

Decision matrix: when to use what

By now, you’ve probably realised that “streaming” on Solana isn’t one thing; it’s a family of patterns that solve different problems. The only question left is which tool to use, and when.

To make that easier, here’s a simple decision matrix mapping scenarios to the Yellowstone (and non-Yellowstone) component that fits best:

When is Solana RPC polling enough?

Before you tear down your infrastructure, let's talk about when you should stick with RPC polling. You likely don’t need streaming if:

• There's no need for real-time data
• Your ops are mostly happening off-chain
• Requests are infrequent (once every few minutes/hours)
• Your requests don’t have a pattern; they are random, and you wouldn't need to "subscribe" to any one of them for a long period

Industries that usually stick to RPC:

• Centralised exchanges (one-off reads)
• Minting / burning (transactional / one-off)
• RWA / tokenisation (infrequent updates)
• DePIN (high volume but often batched)
• Infrastructure (ephemeral sessions)

How to choose an RPC provider

Speed matters; a lot. But without the other pillars in place, it won’t take you very far. Here’s the complete checklist to keep in mind when you choose a provider for streaming-heavy systems:

24/7 uptime

It doesn't matter if your p99 is 90ms if the service goes down during market volatility. You need to be sure your infrastructure will stay responsive no matter what.

Data freshness

Some providers will serve you cached data at breakneck speeds, but if that data is stale (higher chances when cached), acting on it will be useless, and sometimes cost you losses.

Feature depth

Many providers simply host our open-source Yellowstone plugin. That's great (we built it for the community), but if you need advanced features like persistent, high-availability streaming, or enhanced WebSockets, you want the team that constantly ships, improves and pioneers such tools.

Engineering support

Many providers simply host our open-source Yellowstone plugin. That's fine (we built it for the community), but if you need advanced features like Fumarole (deduplication) or Whirligig (WS proxy), you want the team that actually builds and maintains the code.

Vendor-lock

Vendor lock is easy to ignore when things are going well and very hard to fix in an emergency (changes of terms, unmet scaling needs, or surprise overages). Before you commit to any RPC provider, check whether core components are open source and confirm that you can run the same stack elsewhere. The more of your pipeline you can’t move without rewriting, the more dependent you are on the provider’s will.

Pricing

If you are building an analytics dashboard, trading bot, explorer, DEX, or liquidator, streaming will be a major expense.

Some providers hide this with “credits” that get expensive at scale, or gate streaming behind high-tier plans. Here’s how the most popular Solana providers compare when it comes to streaming:

Comparison (price per GB of bandwidth streamed):

Implementation guide

We don’t believe in proprietary lock-in. The same clients we use in production are open source, so you can read the code, adapt it to your stack, and self-host your own instance.

Rust example

The gold standard for performance:

use {
    futures::StreamExt,
    std::collections::HashMap,
    yellowstone_grpc_client::GeyserGrpcClient,
    yellowstone_grpc_proto::prelude::{
        CommitmentLevel, SubscribeRequest, SubscribeRequestFilterSlots,
        SubscribeRequestFilterAccounts, subscribe_update::UpdateOneof,
    },
};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    // Connect to the gRPC endpoint
    let mut client = GeyserGrpcClient::build_from_shared("https://your-endpoint.rpcpool.com")?
        .x_token(Some("your-x-token".to_string()))?
        .connect()
        .await?;

    // Build subscription request
    let mut slots = HashMap::new();
    slots.insert(
        "client".to_string(),
        SubscribeRequestFilterSlots {
            filter_by_commitment: Some(true),
            interslot_updates: Some(false),
        },
    );

    let mut accounts = HashMap::new();
    accounts.insert(
        "client".to_string(),
        SubscribeRequestFilterAccounts {
            account: vec![], // specific account pubkeys
            owner: vec!["675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8".to_string()], // Raydium AMM
            filters: vec![],
            nonempty_txn_signature: None,
        },
    );

    let request = SubscribeRequest {
        slots,
        accounts,
        commitment: Some(CommitmentLevel::Processed as i32),
        ..Default::default()
    };

    // Subscribe and handle updates
    let (mut _tx, mut stream) = client.subscribe_with_request(Some(request)).await?;

    while let Some(message) = stream.next().await {
        match message?.update_oneof {
            Some(UpdateOneof::Slot(slot)) => {
                println!("Slot: {}, Status: {}", slot.slot, slot.status);
            }
            Some(UpdateOneof::Account(account)) => {
                println!("Account update at slot: {}", account.slot);
            }
            _ => {}
        }
    }

    Ok(())
}

TypeScript example

We recently released a NAPI upgrade for the grpc-js client for TypeScript. This increases throughput by 4x compared to standard JS implementations, removing the single-thread bottleneck (read the deep dive).

import Client, {
  CommitmentLevel,
  SubscribeRequest,
} from "@triton-one/yellowstone-grpc";

async function main() {
  // Connect to the gRPC endpoint
  const client = new Client("https://your-endpoint.rpcpool.com", "your-x-token", {
    grpcMaxDecodingMessageSize: 64 * 1024 * 1024, // 64MiB
  });

  await client.connect();

  // Subscribe to events
  const stream = await client.subscribe();

  // Handle stream events
  const streamClosed = new Promise<void>((resolve, reject) => {
    stream.on("error", (error) => {
      reject(error);
      stream.end();
    });
    stream.on("end", resolve);
    stream.on("close", resolve);
  });

  // Process incoming data
  stream.on("data", (data) => {
    if (data.slot) {
      console.log(`Slot: ${data.slot.slot}, Status: ${data.slot.status}`);
    }
    if (data.account) {
      console.log(`Account update at slot: ${data.account.slot}`);
    }
  });

  // Build and send subscription request
  const request: SubscribeRequest = {
    accounts: {
      client: {
        account: [],
        owner: ["675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8"], // Raydium AMM
        filters: [],
      },
    },
    slots: {
      client: { filterByCommitment: true },
    },
    transactions: {},
    transactionsStatus: {},
    entry: {},
    blocks: {},
    blocksMeta: {},
    commitment: CommitmentLevel.PROCESSED,
    accountsDataSlice: [],
    ping: undefined,
  };

  await new Promise<void>((resolve, reject) => {
    stream.write(request, (err) => (err ? reject(err) : resolve()));
  });

  await streamClosed;
}

main().catch(console.error);

Streaming vs RPC performance comparison

We’ve spent years obsessing over these microseconds, so you don’t have to. Here’s how the main approaches compare at a high level.

*Measured from a Triton mainnet RPC endpoint

Start building

Streaming is how you keep up with Solana’s throughput and turn microseconds into an edge instead of a liability.

Whether you use Triton’s managed services or bootstrap your own Dragon’s Mouth and Whirligig stack on bare metal, you get:

• Open-source building blocks
• Production-grade performance and reliability
• A path that doesn’t vendor-lock you

OSS Report: January 2026

If January is any indication, 2026 is going to be massive for the open-source stack, with clear themes starting to take shape. 

On one side, there's the explosion of “vibe coding,” where the barrier to hacking on Solana is dropping at crazy speeds. On the other, there's a growing focus on privacy, particularly around institutional use cases.

We believe the best infrastructure is built in the open, not only shipping OSS ourselves, but also celebrating every team doing the same. From Agave updates to new privacy primitives and community hackathon highlights, here's the January roundup of all things open-source:

Privacy tooling and updates

Starting off, the Solana Foundation unveiled Contra, a private payment channel on Solana that lets institutions run high-speed, fully private transaction rails. It locks assets in on-chain escrow and then executes high‑throughput transfers off‑chain with SMT/Merkle‑based withdrawal proofs, role‑based authorities, and mint whitelists to prevent unauthorised deposits or double‑spends.

Halborn released SSTS, an open-source security token standard built on Token-2022 that adds compliance-focused extensions (KYC/AML, verification, corporate actions) so traditional securities like stocks, bonds, and RWAs can live and trade on-chain in a regulator-friendly way. It assumes one mint per security and one token account per holder, and then layers a neutral, extensible rules engine so issuers can encode their custom workflows.

Chainflow released a critical tool for operators that don't want their private keys on a network‑connected device. It lets you build transactions online, sign them fully offline, and broadcast them hours or days later without worrying about blockhash expiry. It fixes classic air‑gapped pain points using durable nonce accounts, ships as a single standalone binary with human‑readable transaction previews for SOL and SPL transfers.

Alongside these releases, the Solana Privacy Hackathon has been underway from 12 January to 1 February, producing a new wave of ZK tooling. These are the submissions that seem to have caught the most traction (at the moment of writing):

AnonMesh (X)turns every user into a peer in an off-grid mesh, relaying encrypted Solana transactions and messages over Bluetooth and LoRa (via Meshtastic) until they reach a connected “beacon” that settles them on-chain using Arkham for confidential execution. By combining nonce-based serialised transactions with Meshtastic, it gives people in censored environments a censorship-resistant way to use Solana without direct internet access.

Secure Legion (X) is a serverless, metadata-resistant messaging application that utilises a "Ping-Pong Wake Protocol" and TAP heartbeat instead of central servers, layering hybrid post-quantum crypto and hardware-backed keys on top of an integrated Zcash/Solana wallet so users get peer-to-peer coordination and payments without exposing identity, communication patterns, and social network.

Privacy Swap is a ZK-powered protocol that breaks the on-chain link between sender and receiver for SPL tokens using Light Protocol compressed tokens and the Pinocchio SDK. It moves users into a universal privacy pool, then out via a DEX aggregator with Groth16 proofs, nullifiers, and a keeper pattern to prevent double spends and timing leaks, while still supporting fractional claims, shareable links, and gasless swaps.

AI and vibe coding

You could hardly open X this month without running into a wave of new “vibe coding” projects. Low fees, high throughput, and powerful LLM coding assistants are feeding into a loop where on Solana ideas turn into deployed code within days or even hours.

Solana Vibe Coding Hackathon proved it’s more than just hype, receiving over 150 public submissions in only 10 days. The creativity was off the charts, but more importantly, it resulted in real functionality: tools, games, and agents were built. Here's the highlight reel:

Air O2 (X) is a consumer app that turns global air quality into an interactive, 3D “air audit” map, using an AI‑generated Mapbox globe and an LLM health assistant to translate sensor data into personalised, plain‑language advice. The longer‑term vision is a peer‑to‑peer network where users’ phones and portable purifiers act as on‑chain data oracles, validating public sensors and “mining” hyper‑local pollution readings that feed into a Solana‑backed marketplace for clean‑air destinations and services.

DEV K-Line Simulator (X) is a strategy game that simulates running a meme token launch from the developer’s seat, complete with live‑updating K‑lines, random “whale/KOL/FUD” events, and an 18‑action control panel for pumping, dumping, and narrative management. A Next.js frontend talks to an Express/PostgreSQL backend that monitors in‑game metrics and market state, firing off chain‑sleuth “exposure” events and sharp drawdowns when certain thresholds are hit.

Onchain Cupid (X) is a Solana‑based dating and social app that matches people by comparing their wallet holdings instead of swipes or questionnaires. Under the hood it pulls token data, runs a cosine‑similarity and weighted scoring algorithm on two wallets’ portfolios, and wraps the result in a polished Next.js front end with AI‑generated commentary, playful labels, and shareable cards.

Over in the student ecosystem, AI is also "taking over". Out of 89 projects submitted to the Solana Student Hackathon, 65 mentioned AI in some way. The 1st place winner, Quarry, built a decentralized data marketplace and AI Agent that queries datasets that are micropayment gated with x402, and an in-built reputation system using Solana Attestation Service (SAS). It was built by Belleville High School students, which feels very “only on Solana”.

If reading all that made you want to vibecode something yourself, these are the frameworks to bookmark:

• Solana Agent Kit (SendAI): toolkit that lets AI agents call 60+ on‑chain actions across Solana protocols (Jupiter, Raydium, etc.) for token flows and NFT management.
• ElizaOS: lightweight TypeScript framework for autonomous, character‑style agents (for example X/Discord bots) with native Solana plugins for trading and on‑chain actions.
• GOAT Toolkit (Great Onchain Agent Toolkit): universal adapter that gives agents access to 200+ blockchain tools across Solana and EVM, useful when you need multi‑chain reach from one API.
• Rig: Rust library for building modular, scalable LLM apps with support for agentic workflows, streaming, tool use, and on-chain kit for Solana integration.
• LangChain: standard stack for modular, stateful agent workflows; LangGraph adds graph‑based orchestration for multi‑step tool use and Solana‑aware agents.
• Solana Dev Skill: Claude Code skill that encodes the current Solana best‑practice stack (framework‑kit, Kit, Anchor/Pinocchio, LiteSVM, Surfpool, Codama) so the model behaves like a Solana‑native dev.

Infrastructure and developer tooling updates

While the application layer innovates with agentic workflows and privacy payments, the infrastructure layer has been doing the upgrades that keep the network secure and IBRLing.

Yellowstone gRPC Node.js SDK. We shipped a major update to our JS gRPC client, introducing NAPI‑as‑an‑Engine (NaaE) while keeping it fully backwards compatible with existing ‎@grpc/grpc-js. The old setup ran everything on the main event loop, so heavy protobuf parsing could block application logic and trigger HTTP/2 backpressure; by moving connection management and deserialisation into Rust and bridging it back to Node via NAPI, we 4x-ed the data throughput. Read the

JetStreamer v0.4.0. Jetstreamer is a high‑throughput toolkit for streaming Solana ledger via Triton’s Old Faithful. The 4.0 update exposes transaction logs for all epochs and, by using lencode plus optimised diffing, cuts account‑update payload sizes by up to 80% in specific benchmarks, making historical data cheaper to pull.

SLV (Solana Validator Toolkit), the successor to solv from ValidatorsDAO, is a toolkit for quickly building, testing, and deploying Solana validators. It streamlines upgrade, configuration, and launch workflows and now adds Jito BAM client integration, snapshot downloads via aria2, Agave testnet and Firedancer mainnet presets, and support for remote builds.

Client and validator updates

Agave patch v3.0.14 shipped as a critical security update addressing two issues: a gossip‑layer bug that could be used to crash validators and a vote‑processing bug that could be abused to censor votes. Both were fixed in coordination with Firedancer, Jito, and the Solana Foundation, and once the release was out, operators moved quickly, with nearly 20% of stake upgrading within the first 24 hours.

Later in the month, Agave v3.1 landed with a batch of performance and RPC improvements for validators and builders. Restart times drop to a couple of minutes, with disk I/O during replay down by ~93%, and scheduler fixes mean banking workers now spend about 91% of their time actually processing transactions (up from 61%), with epoch transitions reduced to under 400ms. 

This release also includes critical SWQoS updates: congestion-triggered fallback logic that kicks in at 90% TPU load, expanded unstaked connection slots (from 500 to 2,000) to reduce handshake churning, and latency compensation via BDP scaling to stop high-latency connections from being artificially throttled.

One last thing...

We’re convinced the network’s future depends on open code, opportunity, and community. 

Right now we are working on a new initiative with Solana Foundation that goes back to the roots of why we built Project Yellowstone and Old Faithful, so keep an eye out!

Comprehensive guide to white-label validators on Solana

TL;DR

• White-label validator services let you run a branded Solana node without managing operations, hardware, upgrades, or failover.
• If you do not have, or plan to have, at least 150,000 SOL in stake (estimated at the time of writing), you should consider delegating to another validator, as running your own would operate at a loss.
• Most popular use cases for validator-as-a-service (VaaS) are institutional treasury funds, DeFi applications, DAOs, protocols, and non-profits.
• Key separation is non-negotiable if you want to remain in control of your funds. If the provider holds your withdraw authority, you are essentially an unsecured lender.
• APY is how much money your validator makes you and your delegators. Uptime, skip rates, and Jito MEV optimisation define your APY.

Introduction

A Solana validator does 3 things: it votes every block (~400ms) to secure consensus, it produces blocks when selected as leader (earning transaction fees, priority fees, and MEV tips), and it votes on SIMDs and governance proposals.

If you are considering running one, you already know the first 2 (the ones that generate revenue) require constant operational attention: client upgrades, skip rate monitoring, health checks, hardware tuning, and failover management during network events.

That is where white-label services come in. It is the infrastructure equivalent of ghostwriting: the provider handles operations while you:

• Control branding. Your validator name appears in explorers and on-chain.
• Set commission. You decide the fee structure that works for your P&L, regulatory requirements, or delegator expectations.
• Participate in governance. You influence the protocol direction by voting on SIMDs and governance proposals.

Who needs a white-label validator?

On Solana, you have 3 paths for staking. Here is how the economics and operations compare.

When each option makes sense

Self-hosted. Makes sense when you have large stake volume, an in-house DevOps team, and a need for maximum control over infrastructure.

Simple delegation. Makes sense for smaller players, retail holders, or DeFi-native users who have less than 150,000 SOL to stake and prioritise yield over brand visibility and governance.

White-label. Makes sense for anyone holding over 150,000 SOL without DevOps resources. The most common audiences:

Institutional treasuries and funds

If you hold a substantial SOL amount (150k+), paying 0% commission to yourself via a white-label node is often cheaper than paying 5–10% commission to a public validator. You also gain governance power and brand visibility on-chain.

Consumer dApps

Apps like Phantom, or exchanges, need to offer staking to their users. By using a white-label provider, they can spin up their own branded validator, collect fees from their user base, and offload the operational burden to infrastructure specialists.

Protocols and non-profits

Running a validator allows DAOs and non-profits to generate sustainable revenue from their community’s stake rather than relying on finite grants. It turns community support into an operational runway.

The break-even math behind running a validator

Before evaluating providers, you must understand the break-even math.

Revenue sources

Expense sources

The core takeaway on validator economics

Inflation rewards are distributed proportionally to all staked SOL across the network. Running a validator does not give you extra inflation rewards—it lets you earn fees on top of what you would get by delegating elsewhere.

The break-even stake depends on the effective fee yield—the APY validators earn specifically from transaction fees and typically do not share with stakers. At the time of writing, this sits at roughly 0.37–0.4%.

Break-even estimate. At 0% commission and ~0.4% effective fee yield, break-even stake ≈ 150,000 SOL (600 SOL / 0.4%).

Selecting a provider: 3 core criteria

Once you have confirmed the economics work for your stake, evaluate providers across these dimensions: security, privacy, and performance.

Funds custody and security

A Solana validator uses 3 keypairs:

• Identity and vote account keys (hot). The provider must hold these. These keys must be on the server to sign blocks and votes in real time. If the provider loses these, your node goes offline, but funds remain safe.
• Withdraw authority (cold). Must be generated and held by you. This key controls where rewards go and is required to withdraw the vote account’s balance.
• Staker authority. Delegation control should be held by you when your compliance model requires it.

Non-negotiable rule. If a provider asks for your withdraw authority “for easy setup”, walk away. They are effectively taking custody of your revenue stream.

Privacy and discretion

A proper white-label provider acts as your ally. They should never use your brand in their marketing without explicit consent, and your node should appear entirely sovereign on explorers like Solana Beach or validators.app.

• Need-to-know basis. If you require it, only essential employees should know your identity. Proper providers can enforce strict internal access controls.
• Historical track record. If discretion matters, choose providers who have never leaked client information, or used client brands for self-promotion without permission.

APY: the performance metric

Uptime is just one metric. A validator can respond to pings while failing to produce blocks. You should also ask about skip rate, MEV capture, and block packing.

• Skip rate. The % of time your validator failed to produce a block. High skip rate means lost block rewards. Network average is ~0.07–0.17%, while top providers achieve ~0.05% (estimated). You want a provider that tunes for network latency and peers directly with high-stake nodes.
• Jito and MEV. If you want to maximise returns, look for a provider running the Jito-Solana client (or compatible), which captures MEV tips from searchers. Today, ~90% of validators run Jito or a compatible client (estimated).
• Block packing. Hardware must be powerful enough (CPUs, RAM) to pack transactions efficiently during high-traffic events. More transactions packed means more priority fees captured. If the CPU chokes, you drop transactions, and APY suffers.
• Uptime. Reliable providers target 99.9%+ uptime through redundant hardware, premium data centres, and automatic hot-swap backup systems that move the validator key and tower file immediately when a node fails.

The bottom line

For protocols, dApps, and institutions with sufficient stake—and a need for brand visibility, governance participation, or regulatory positioning—a white-label validator makes strategic sense.

In practice, the provider you choose determines whether that validator remains secure, performant, and economically sustainable long term, so choose carefully.

→ Contact us to deploy your validator

How to choose an RPC provider for a high-performance Solana wallet

TL;DR

• Wallets have specific RPC demands: fast token and asset retrieval, real-time updates, transaction history fetching, and smart transaction routing during congestion.
• DAS API and custom gPA indexes are essential for fetching fungible tokens, NFTs, program, and staking accounts without scanning the whole chain state.
• Real-time updates require gRPC for browser extensions and backend pipelines, and WebSockets for frontend UI.
• For most wallets, shared infrastructure wins on global distribution, cost, and auto-scaling over dedicated nodes.
• When choosing a provider, focus on global coverage, asset and program accounts indexes, gRPC streaming, SWQoS routes, MEV protection, support, and predictable pricing.

What do users expect from wallets?

Perceived speed is speed

Users expect you to display their holdings quickly and accurately. If data is “loading” for more than a second, they will assume you are slow across the board.

Real-time updates

Balance changes, incoming transfers, and confirmations should appear instantly.

Protection from bad actors

Your users might not need to be the fastest into a trade, but they do not want to be sandwiched by a malicious validator.

Complete transaction history on request

Users want to see every swap they did in the last month. They do not want to wait 10 seconds for it to load.

Congestion tolerance

During latency spikes or NFT mints, transactions that would normally land can time out. Users hate it when transactions just disappear.

To meet these requirements, you need a stack that goes beyond standard JSON-RPC. You want asset APIs, streaming feeds for different use cases, accessible Solana history, and optimised and protected transaction routing during congestion.

What should wallets expect from an RPC provider?

Fetching data: DAS API and Steamboat vs raw RPC

For most wallets, the majority of the workload is “simple” data retrieval. However, this “simple” task can quickly turn into massive payloads, high compute consumption, and timeouts—especially for popular mints, large programs, wallet NFT inventories, or heavy getProgramAccounts reads.

In practice, wallets solve this with indexing solutions: DAS (digital asset standard) API for unified asset and balance retrieval, and custom indexes (like Steamboat) for making repeated gPA queries faster and cheaper.

DAS helps wallets deliver fast, responsive UX at all times with:

• Near-instant token-account lookups
• Simplified Solana asset querying
• Accurate, up-to-date state across all token accounts

Custom indexes help you serve results from a purpose-built index instead of scanning the chain for every request. For example, with Steamboat, you get:

• Direct pre-indexed DB reads
• Predictable performance at scale
• Fast metadata, portfolio, and staking lookups

Real-time updates: gRPC and WebSockets streaming

Polling is slow and gets expensive at scale because you keep asking for state that has not changed. Streaming flips the model. You receive only the updates as soon as they happen on-chain, which typically cuts read calls by 80% or more, and improves confirmation latency.

The Yellowstone tools (authored by Triton) let you consume raw slot, block, and account updates with minimal latency, keeping your wallet perfectly synced with the network.

• Dragon’s Mouth (Yellowstone gRPC). The core stream for backend pipelines and browser-extension clients.
• Whirligig. A Rust-based proxy that bridges gRPC to WebSockets, enabling the same ultra-low latency data and real-time UI updates in browser frontends.

Transaction sending: priority fees, MEV protection, and SWQoS

For a wallet, transaction sending comes down to 3 requirements: minimum transaction drops, reliable inclusion even when the network is busy, and protection against harmful validator behaviour.

Priority fee calculation

Solana’s getRecentPrioritizationFees RPC often returns zero as the recent “minimum” priority fee. Use custom priority fee APIs that support percentile-style logic, so your transactions get included without overbidding.

SWQoS lane

Stake-weighted quality of service gives you reserved transaction bandwidth, increasing the transaction’s chance to reach the leader under congestion. This lets your users’ transfers, swaps, deposits, and staking actions land predictably, even during network latency spikes.

MEV protection

Some validators engage in harmful MEV strategies like sandwiching or frontrunning. To prevent this, you can use open-source tools, like Yellowstone Shield (authored by Triton), that let you attach a custom allowlist or blocklist policy to every sendTransaction.

Reliability and performance: what matters more

People often see latency as the number 1 enemy. For wallets, however, it’s often downtime, jitter, stale data, and ineffective support.

Uptime and global distribution

You want globally distributed infrastructure with 99.99% uptime, smart routing, continuous health checks, and automatic failover. This reduces the risk of degraded performance, stale responses, and wallet downtime.

Low and consistent latency

Sub-second responses are non-negotiable for Solana wallets, but it’s not just about a low median. Jitter and tail latency must stay stable under load, so performance does not fall apart when volume spikes.

Direct engineering support

Know who you’ll speak to when something breaks. Support should be a direct channel to engineers for integration debugging, configuration guidance, and urgent troubleshooting—not a generic ticket loop.

Shared vs dedicated: how to choose

Shared RPC pools are great for most wallet use cases. Shared infrastructure routes each user to the nearest region with smart routing, which keeps latency low across locations, and absorbs spikes when thousands of users open the app at once—without you doing capacity planning.

Dedicated infrastructure is a good fit for streaming when millisecond-level differences matter. It offers predictable performance and greater control, but typically does not match the global distribution benefits of a shared fleet.

Pricing and scaling

Pricing predictability 

40 million “credits” looks like a lot until you factor in the cost of heavy operations like DAS queries, historical access, or getProgramAccounts. With these calls costing 3, 5, or even 100 credits per request, that balance evaporates quickly. You should be able to estimate spend upfront, not 2 weeks in when you hit an overage cliff.

Bloated tiers

Plans often force you to upgrade to the higher tier just to lift a limit (like getting a higher throughput ceiling), even if you do not need all the included credits or features. Make sure you are not paying for bundled resources you don’t use, subsidising other users and the provider.

Vendor lock-in is a hidden cost

Closed-source tools and enhanced APIs can be convenient, but if too much of your backend depends on them, migrating later means rewriting the whole stack. If you value long-term control and plan to scale, use open-source standards wherever possible.

RPC provider checklist for Solana wallets

Use this to compare providers against your wallet’s actual workload.

Bottom line

A high-performance Solana wallet in 2026 can’t be built only with standard JSON-RPC access.

Pick the provider whose strengths match the user experiences you refuse to compromise on. Users won’t thank you for great RPC infrastructure, but they will keep using your wallet because it feels instant and reliable.

What is Solana RPC: nodes, endpoints, and data access

TL;DR

• Solana is a blockchain where applications need a way to communicate with the network.
• RPC (remote procedure call) is the protocol that bridges this gap – it’s the communication layer between your app and the blockchain.
• RPC nodes expose this interface through endpoints (URLs), allowing developers to read on-chain data and broadcast transactions.
• In this guide, we’ll explore how RPC nodes work, the different types of endpoints available, and how to choose the right infrastructure for your Solana application.

Solana RPC explained

Let’s say you've built a UI. You've written a program in Rust or Anchor. You are ready to ship. But for now, your code (frontend) is isolated from Solana (backend). Your app still needs a way to read what's happening on-chain, and submit transactions to the network.

That gateway is remote procedure call. It lets your application call a method on a remote server (an RPC node), and get a structured response back.

In practice, these methods do 1 of 2 things:

• Read state. Query wallet balances, token accounts, programme data, recent blockhashes, signatures, and more.
• Write state. Send transactions, like swaps, mints, or transfers, that change Solana state.

Understanding the key RPC concepts

Here is a clear breakdown of what the core RPC concepts mean.

RPC vs API

RPC is a style of API (application programming interface). You might have used REST APIs before, which are resource-based (GET /users/123). RPC APIs, on the other hand, are action-based (you call a method name with params). On Solana, when builders say “API”, they are usually referring to the JSON-RPC interface.

RPC vs RPC node

RPC is the interface and the methods your app uses to communicate with Solana.

RPC node is the server running Solana node software (such as Agave) that exposes JSON-RPC endpoints for applications to interact with.

For example, when someone says “my RPC is down”, they usually mean their provider’s RPC node isn't responding.

RPC node vs RPC endpoint

RPC node. The machine running the Solana client, with CPU, RAM, and NVMe storage.

RPC endpoint. The URL your app uses to connect to an RPC node, such as HTTP (https://) for request-response calls and WebSocket (wss://) or gRPC streams for subscriptions and streaming.

RPC nodes vs validator nodes

They run the same Solana software, Agave (this is expected to change with the Alpenglow rollout), but are optimised for different workloads.

Validators focus on producing blocks and voting on other block producers’ blocks.

RPC nodes are optimised for serving data and broadcasting transactions to the network for processing.

Simple mental model to understand RPCs

Imagine the Solana ledger (history) as an endless, ancient scroll located inside a great library (the Solana network). Scribes (validators) can write on the scroll (produce blocks) only one at a time (the current leader), while the others watch closely to agree that the history is being written correctly (reaching consensus).

It’s a busy, high-stakes environment inside the library, and normal people (dApps and users) must stay outside the library walls. That’s where the librarians come in (RPC nodes) to act as the critical bridge.

They read the scroll in real time to tell you what’s been written (current state), and they take your requests (transactions) and rush them to the scribe circle to be included in history.

We take pride in being one of the most reliable “librarians” in the ecosystem, but not all providers are equal. If your librarian is slow or overwhelmed, you are left waiting outside the walls (high latency) or facing total silence (downtime). In other cases, you are handed data that's already outdated (stale data) or receive only a fraction of the records you requested (missed slots).

RPC communication methods: HTTP, WebSocket, and gRPC

These are different transports for the same job: reading on-chain state, and interacting with the network.

HTTP RPC

Mechanism. You ask, the node returns a JSON-formatted response, and the connection closes.

Use case. One-off reads and transaction submission.

Trade-off. It’s inefficient for certain workloads. You repeatedly re-fetch unchanged data instead of receiving updates only when events occur, driving up both latency and costs.

WebSocket RPC

WebSockets are still part of the RPC surface, with responses delivered over a persistent connection.

Mechanism. You subscribe, the node pushes JSON-formatted updates as state changes, and the connection stays open until you unsubscribe.

Use case. Real-time UIs, frontends, and notifications.

Trade-off. Connections drop. You need reconnection and backfill logic. Standard WebSockets can have limitations at scale. Some providers use enhanced WebSocket implementations (like Triton’s Whirligig) or alternative streaming protocols (like gRPC) for better performance at high throughput.

gRPC (Geyser-based)

gRPC is a high-performance streaming protocol used with the Geyser plugin interface.

Mechanism. Similar to WebSocket subscriptions, but you receive updates as protobuf messages over a persistent HTTP/2 connection.

Use case. High-throughput dApps, indexers, and latency-sensitive bots.

Trade-off. More engineering work than WebSockets, such as parsing and deserialisation.

Types of Solana RPC endpoints

Choosing your RPC infrastructure strategy

There are 4 primary strategies for accessing Solana RPC nodes, each with distinct trade-offs.

1. Use an RPC provider (most popular)
   • How it works. Sign up, get API keys, and integrate the endpoint.
   • Advantage. Fastest route to production-ready. Higher reliability, higher throughput, support, and often, automatic scaling.
   • Example providers. Triton One (Solana-native); Alchemy and QuickNode (Ethereum-native with Solana support).
2. Run your own Solana validator (self-hosting)
   • When to use. Large exchanges, hedge funds, or teams with dedicated DevOps staff, requiring complete control.
   • Requirements. High-performance hardware (for example, 768GB+ RAM, 4TB+ NVMe), significant initial sync time, and ongoing maintenance.
   • Cost. High operating cost (roughly $3,000–$15,000+/month in resources and staffing).
3. Public endpoints
   • When to use. Only for learning and local development.
   • Limitation. Rate-limited, can be slow and unreliable. Generally not suitable for any live production environment.
4. Hybrid / multi-provider strategy
   • Recommended. Best practice for production apps that demand maximum reliability.
   • How it works. Use multiple providers simultaneously (primary endpoint from one, backup from another), and automatically switch endpoints on failure.
   • Benefit. Eliminates a single point of failure, enables load balancing, and ensures graceful degradation during outages.

Real-world use cases of Solana RPC nodes

RPC nodes are the fundamental infrastructure for almost every on-chain interaction.

• Wallet balance checking. Wallets (like Phantom, Solflare, and Backpack) call RPC methods to instantly fetch and display your SOL and token balances.
• Trading and token swaps. RPC nodes broadcast the signed transaction (via sendTransaction) to the network. Any latency directly impacts execution quality and can be the difference between a successful trade and a failure.
• DeFi protocol queries. Protocols (like lending or AMMs) constantly query programme data via RPC to check collateral health, or accurately price swaps.
• NFT operations and verification. Marketplaces (like Magic Eden, Tensor, and Exchange Art) use RPC calls to verify ownership, fetch metadata, and record purchases.
• Bot operations and arbitrage. High-frequency traders and bots rely on the absolute lowest RPC latency. Even a 100ms difference is critical for capturing opportunities.
• Analytics and indexing. Services (like Solscan, Jupiter Portfolio, and Circular.fi) rely on billions of RPC calls to aggregate historical data and build searchable, human-readable views of the blockchain.

Key decision criteria: what to look for in an RPC provider

Public endpoints are free, but heavily rate-limited, and can get crowded. They're fine for learning and early MVPs, but when you ship a production app, you usually need a private endpoint from a provider.

When choosing an infrastructure partner, consider:

• Consistent low latency. If RPC is slow, your app lags. If you are trading, execution degrades. Tools like Thorofare can help measure this.
• Reliability. If nodes go down, your app goes down. Uptime and failover matter as much as speed (sometimes more, depending on your use case).
• Streaming support. If you are indexing or trading, you’ll probably need gRPC streaming access for high throughput and ultra-low latency.
• Ledger access. If you need deep history (more than 3 epochs), check how the provider serves historical data, and whether ledger streaming is available.
• Support. When things break, you want an engineer on the other side, not a generic ticket loop.
• Pricing clarity. Estimate cost from your actual method mix. If you want predictable spend, look for transparent pricing and overage rules you can model.
• Lock-in. Prefer providers that you can leave. This means they don’t force you into proprietary SDKs or long-term contracts. That 10% discount on a 12-month subscription stops looking good the moment you discover better infrastructure that follows open standards at a cheaper price point.

Frequently asked questions

What is a Geyser plugin?

A Geyser plugin runs inside a validator and streams data out, typically over gRPC. It is used for real-time ingestion and indexing. Many RPC providers use the Yellowstone gRPC protocol (an open-source streaming standard) as their Geyser plugin layer.

Why did my transaction say “sent” but never “landed”?

Submitting a transaction is not the same as confirming it. On Solana, transactions generally face 2 distinct failure modes.

1. Dropped before landing. This typically happens during congestion or due to expired blockhashes (insufficient priority fees are a common culprit). In this scenario, the transaction never touches the chain, and you pay 0 fees.

2. Landed but failed. A transaction can successfully land in a block and still fail execution. This occurs because transaction instructions resulted in error given the current Solana state. Common examples include triggered slippage limits, insufficient balances, or a bot attempting a double spend with a duplicate signature. In these instances, the protocol correctly processes the fee, but aborts the action to protect the state.

By default, RPC nodes simulate transactions and reject invalid ones instantly, ensuring errors cost you nothing. However, developers often enable skipPreflight to shave off milliseconds. This bypasses the safety check, causing the RPC to blindly broadcast a transaction that may fail on-chain – you save a few milliseconds on latency, but you risk paying a transaction fee for a failure record.

Can I use a custom RPC in my wallet?

Most major wallets don’t currently offer direct custom RPC configuration, though many have placed it on their roadmaps. At this stage, Backpack is one of the few that supports it natively.

To set it up: open the Backpack main menu → choose the network → select RPC connection → enter the custom menu → paste your private RPC URL.

What are Solana commitment levels?

Commitment controls how certain you want your read results to be. Solana defines 3 levels.

A transaction is processed when it has been processed by a node and is visible, but not yet confirmed by a supermajority of stake. It is confirmed (the common default for most applications) once the block has been voted on by a supermajority of stake (66%+). It is finalised after 31 or more subsequent confirmed blocks have been built after it.

Higher speed means lower certainty, and higher certainty means more delay.

What are devnet, testnet, and mainnet?

Solana runs multiple clusters for different purposes. Devnet is used for development and experiments. Testnet is mainly used by validators to test upgrades and network changes under realistic conditions. Mainnet is the production network where real assets live. RPC providers typically expose separate endpoints for each cluster.

Should you run your own Solana node?

For most teams, no.

Self-hosting can make sense for large exchanges, market makers, and latency-sensitive bot ops, but it demands constant operational overhead. The burden of upgrades, monitoring, and on-call rotations rarely makes economic sense compared to a provider.

Typical specs for an RPC node:

• RAM. 768GB (ECC preferred)
• CPU. 24+ high-frequency cores
• Disk. 4TB+ NVMe
• Bandwidth. 1Gbps unmetered

Does a private RPC hide my wallet address?

No. Once the transaction is on-chain, it is public. Private endpoints primarily reduce failed submissions and improve execution reliability. They do not provide anonymity.

What are common RPC errors?

• HTTP 429 too many requests. You exceeded a rate limit. Fix with retries and backoff, batching requests, caching results, or upgrading to a private endpoint.
• HTTP 503 / 504 gateway timeout. The node or gateway is overloaded, unhealthy, or offline. Fix with retries and failover logic, and reassess the provider if it happens often.
• -32603 internal error. The node failed internally. Validate parameters, retry the request, and log raw requests if it persists.

We’ve put together a full error list here.