DEV Community: OrbitFlare RPC

Solana RPC Pricing Explained: RPS vs Compute Units vs Dedicated

OrbitFlare RPC — Wed, 04 Nov 2026 15:08:50 +0000

To recap, there are three ways to pay for Solana RPC services: requests per second (the capacity limit you subscribe to), compute units/credits (each method uses different amounts of units out of the monthly allocation) or flat-rate dedicated capacity. Pricing model becomes a crucial thing when choosing the best Solana RPC provider as the same traffic will cost you several times more depending on the model you subscribe to. In this article, I'll review all three pricing models, show you how to estimate your monthly expenses under each of them and reveal all the details that you shouldn't ignore in your first invoice.

Summary of key takeaways

There are three types of pricing models available: RPS, credit/compute units and flat-rate dedicated capacity. Each pricing model can be a good fit for certain workloads and a bad fit for others.

Credit-based pricing makes certain methods much more expensive than others. Look at the table of method costs before choosing the provider.

RPS pricing model is consistent and treats all methods equally, which makes it a good choice for bots and data-heavy applications.

Some of the additional costs include streaming (often priced separately), archive access, regional endpoints, transaction landing and others.

Three pricing models for Solana RPC services

OrbitFlare prices their shared plans by requests per second without any credit metering, while the dedicated nodes are priced at the flat rate. Other providers rely on compute units or credits. Neither pricing model is universally better. Both of them have pros and cons which make them suitable for particular applications.

How to estimate your monthly expenses under each pricing model

Before estimating your traffic costs, gather real traffic stats for a week. Here are the metrics you will need:

Peak requests per second value, sustained over a minute (not an average), which will serve as the baseline to choose RPS plan size.
Monthly requests per method. In credit pricing, you will pay according to the method weight, thus you will need to know how many of your requests are of getAccountInfo type and how many are getProgramAccounts.
Your streaming load: subscriptions count and message rate.

Once you have these values, calculate your cost for a week under each of the models. Typical result: read-heavy consumer applications pay less on credits, while trading bots/indexers pay less on the RPS pricing model. Anything above a few hundred sustained RPS with a custom client pays less on dedicated capacity.

Weights that matter in credit-based pricing

Credit providers provide you with the tables of method costs. These values can differ from one provider to another. Make sure you read each of these tables carefully instead of guessing:

Cheap across all providers: getBalance, getAccountInfo, getLatestBlockhash, getSlot.
Method costs can vary: sendTransaction, simulateTransaction, getMultipleAccounts. They can cost you the base price in some schemes and a multiple in others. Some of the history methods like getTransaction, getSignaturesForAddress and getBlock are among the most expensive for some providers and cost the base price for others.
Heavier than the others: getProgramAccounts, which can cost you twice or even 10 times more compared to the regular read.

If your application performs a lot of getProgramAccounts calls in a loop, your monthly cost for the credit plan can become an order of magnitude higher than it looks like. This method is the most common cause of 'our Solana RPC bill tripled' stories. The solution is either to implement a data feed (gRPC subscriptions as a replacement of the polling) or switch to another pricing model which doesn't weight methods.

Hidden lines on your invoice

Streaming. WebSocket subscriptions and especially Geyser gRPC are often priced separately as a different product or higher tier. If your architecture relies on streaming, don't forget to price it. All OrbitFlare plans include WebSockets, while the top tier plan includes mainnet gRPC and others require an add-on (more details on gRPC).

Archive access. Queries for historical blocks and transactions reach a separate storage tier where older data is kept and charged separately. Some providers provide a window of archive data, others charge extra for older data or require a different plan for archive access. OrbitFlare includes archive data in every plan; Historical Data is meant for large and sustained historical jobs and backfills.

Regional endpoints. Serving your traffic from the closest endpoint is the performance feature that can be charged separately. Make sure you know which regions are included in the particular plan; OrbitFlare provides the list of regions by city, for example Solana RPC in Tokyo.

Transaction landing. Stake-weighted forwarding, bundle relay and other related services are sometimes priced as a different product with its own pricing model. For a trading workload it is not optional, thus it should be priced in advance. OrbitFlare's service is called Apex and is priced as a per-transaction tip on top of the network fees.

Overage behavior. With credit pricing the exhaustion of the monthly quota either throttles your application or charges overage with the higher price; with RPS pricing the exceeding of the ceiling results in rate-limit errors. You should know which of the behaviors you will experience before a launch day.

Free tiers and their purpose

All the major providers offer a free tier and they are really helpful as you can develop and test your application before making any payments. However, they are not for production usage. The limits are small, the transaction forwarding is often unstaked and support is at the community level. The useful step to try is to run your traffic on the free tier for a few days and study the dashboard usage stats. This is the baseline you should use for the cost comparison above.

Shared, reserved or dedicated?

Free tier: for prototyping. No costs, small limits.
Reserved capacity plan (RPS or credits): for production in most of the cases. Cost depends on the ceiling or allowance of the plan.
Dedicated node: flat monthly fee for the node reserved for you, with a custom client if needed. The cheapest choice per request at high volumes, but not a good choice at lower ones. Dedicated Nodes lists OrbitFlare's starting price.

The move to the dedicated plan usually happens when you've already paid for the top shared tier but still reach its ceiling, or when you need some specific client configuration which is not available in the shared tier.

A practical way to compare two providers

Gather method-level usage stats for the last week from your current provider or from the logs.
Price that week under each candidate model with the help of the published tables: RPS pricing based on your peak, credit pricing based on method weights.
Estimate streaming, archive, regions and transaction landing costs as separate lines.
Consider the cost of the failed launch hour: what will it cost you if the provider throttles or drops your transactions at peak? The cheaper plans with unstaked forwarding carry this risk.
Test the top two candidates for a week with the real traffic and compare landing rate and latency, not only price.

Step four is the one which most of the teams skip and later regret. The comparison of the major Solana RPC providers can help with the qualitative assessment of the models.

Conclusion

There are three pricing models for Solana RPC services, and the pricing model defines your cost more than the headline figure. Analyze your method mix and peak throughput, price the same period under each of the models, add lines for streaming, archive, regions and transaction landing, and consider the cost of the Solana RPC provider which drops your transactions when it matters. Run your candidates side by side for a week and choose the one based on the landing rate and latency.

OrbitFlare's pricing model is requests per second with no method weighting and with WebSockets included in every tier. Staked connections are available from the Developer tier up, and mainnet gRPC is included in the top tier and is also available as an add-on for the tiers below. Current pricing is on the pricing page.

Originally published at orbitflare.com.

Agave 4.4: What Changes for Solana Developers

OrbitFlare RPC — Thu, 29 Oct 2026 12:43:33 +0000

On 28 October 2026, Anza announced Agave v4.4.0 as stable, recommended for 20% of mainnet stake and for testnet and devnet. Now, mainnet uses 4.3.2, so this is what validators will move to over the next few weeks. It adds three new gates, alongside the SIMD-0290 gate that was already in 4.3 and waits to be activated, along with a brief list of RPC and operator changes. None of the gates are active, but two change the content of blocks and program accounts, so check before they flip.

Key Takeaways

SIMD-0290 lets blocks have transactions whose fee payer can't pay. Transactions like that show up as failed, with a zero fee and no logs.
SIMD-0433 makes program upgrades resize the program data account to the new binary, refunding surplus rent.
SIMD-0317 requires 32:32 FEC sets, and SIMD-0599 removes inactive stake from reward calculations.
Rent is already down to 5,080 lamports per byte on mainnet; the next cut to 2,575 awaits testnet.
getTransaction and getSignatureStatuses support minContextSlot, and account subscriptions obey dataSlice.

This guide is for developers deploying indexers, bots, and programs on Solana, as well as for everybody who works with raw blocks.

Where things stand

We read the gate accounts on mainnet and testnet directly on 29 October 2026 (mainnet epoch 1071).

The timing is important to remember. Epochs are still 432,000 slots long, and on our Amsterdam node it took about 25.5 hours each to process epochs 1069 and 1070, with an average slot duration of 213 milliseconds once skipped slots are counted. Gates activate at epoch boundaries, so a scheduled activation becomes live about a day later.

SIMD-0290: blocks can carry transactions that cannot pay

Today, the presence of just one transaction whose fee payer can't pay enough to cover the fee makes the whole block invalid. With SIMD-0290, this requirement is relaxed for recent-blockhash transactions (and durable nonce transactions are waiting for SIMD-0297 activation). Such a transaction stays in the block but doesn't execute anything. It is a step towards asynchronous execution.

We reviewed the 4.4.0 codebase to learn how such transactions are recorded in the block:

The status of a transaction is an error, the same error that used to make the whole block invalid, for instance InsufficientFundsForFee or AccountNotFound.
The fee is zero. Nothing transfers and account states don't change.
There are no log messages, inner instructions, or return data.
Such a transaction contributes to block limits according to its full requested compute unit limit, rather than actual usage. This makes it impossible for a leader to stuff too many free transactions into a block.

Calculations that sum meta.fee over failed transactions will give incorrect results here, and algorithms that expect every failed transaction to have logs or a paid fee payer need to be checked. Consider a transaction failure with zero fee and no logs as "included, not executed".

SIMD-0433: program upgrades resize the account

Loader v3 allows increasing the size of a program data account using ExtendProgram, but never reducing it, meaning that when a program is rewritten to a smaller binary (like in the case of Pinocchio), it keeps paying rent for the original size. Once SIMD-0433 activates, the Upgrade operation resizes the account to fit the new ELF plus metadata header. The surplus rent is refunded to the spill account, and a larger binary grows the account without a separate ExtendProgram call.

Before the next deployment after the activation, make sure that:

The spill account exists. It is where the refunds will go, so make sure that it is your account.
The lamports for growth. The extra rent should be in the program data account or in its buffer prior to Upgrade, otherwise it fails with InsufficientFunds.
The rent you overpaid earlier. Upgrading resets the account balance to the minimum required rent and sends the rest to the spill account, even without SIMD-0433. Programs deployed before the two rent cuts receive some of the deposit back on the next upgrade.
Upgrades via CPI. Multisig and governance programs that upgrade a program via CPI still have the 10 KiB per-instruction growth limit. Perform the ExtendProgram operation in several iterations first to increase the size, or upgrade on the top level.

SIMD-0317: fixed 32:32 FEC sets

Blocks transit through Turbine as shreds, grouped into forward error correction (FEC) sets. Every client already sends 32 data shreds and 32 coding shreds per set, but receivers still accept all kinds of combinations. SIMD-0317 mandates 32:32 sets, and any other set will be dropped on ingest. The gate checks the size of the Merkle proof generated from a 64-shred set in the codebase.

It also fixes the size: 995 bytes of payload in each data shred and 31,840 bytes per set. Receivers can validate shred indices without waiting for coding shreds, and two valid shreds from one set with distinct Merkle roots prove equivocation. There is no practical difference for teams decoding shreds themselves, including ShredStream consumers, as the senders use the same format anyway.

SIMD-0599: inactive stake leaves the rewards path

Partitioned epoch rewards currently traverse every stake account regardless of whether it has effective or activating stake in it. They earn nothing, but they still affect the number of partitions and the lattice hash. SIMD-0599, jointly developed by Anza and Firedancer engineers, removes stake that didn't have any effective or activating stake in the whole rewarded epoch from this calculation.

Stakes that deactivate at the boundary still receive rewards for their last epoch, and the users see no difference. The optimization is significant though. Scanning the mainnet stake accounts on our Amsterdam node we found that out of 1,364,680 delegated stake accounts 232,962 (17.1%) were completely inactive, storing about 3.28 million SOL. All of these accounts, every client processes at every epoch boundary now.

Rent: two steps live, step three gated

SIMD-0437 reduces the lamports_per_byte parameter from 6,960 to 696 in five steps, each separately gated. The first and the second step are live on mainnet. The third one, down to 2,575, is already in 4.3.0-rc.1 and is pending activation on testnet. The fourth and fifth steps (to 1,322 and 696) are not on the activation schedule yet.

This is how the rent for a standard 165-byte token account (rent is calculated on the size of the data + 128-byte overhead) looks now:

Any hardcoded 2039280 in the code is already incorrect on mainnet. Always calculate the minimum rent from getMinimumBalanceForRentExemption or the Rent sysvar, because this value changes three more times.

RPC and operator changes in 4.4

These updates come with the binary and don't wait for a gate:

getTransaction supports minContextSlot.
getSignatureStatuses supports commitment and minContextSlot, and still defaults to processed. If the node is behind, it returns error -32016, allowing load-balanced clients to retry on a different node and not get stale data.
accountSubscribe and programSubscribe respect dataSlice. A zero-length slice returns empty data, which is useful for watching lamport or owner changes without paying for the account data.
getLeaderSchedule returns the new error -32022 if the requested identity is not present in the schedule.
Validators running an external scheduler need version 5 of the bindings. The --experimental-retransmit-xdp-* command line flags are gone in favor of --xdp-interface, --xdp-cpu-cores and --xdp-zero-copy.

What this means on OrbitFlare

Our devnet already runs 4.4, and you can start experimenting with minContextSlot and dataSlice subscriptions right now. Our mainnet regions will follow Anza's adoption guidance without any changes in URLs, keys, or gRPC subscriptions. The gated changes will activate at the same slot for all nodes. What may require an update is your code: handling zero-fee failures, preparing the spill account for upgrades, and calculating rent at runtime.

Conclusion

Agave 4.4 looks quite uneventful on the surface. SIMD-0290 and SIMD-0317 move Solana towards validation that doesn't depend on execution, while SIMD-0433 and rent cuts make state maintenance less expensive. Check your indexer for zero-fee failures before the gate reaches testnet, and don't hardcode rent values.

Resources

Originally published at orbitflare.com.

What Is JSON-RPC? How Solana's Node API Works

OrbitFlare RPC — Mon, 26 Oct 2026 18:23:32 +0000

What is JSON-RPC?

JSON-RPC is a remote procedure call protocol which is encoded in JSON. The latest version 2.0 of the protocol (see jsonrpc.org) defines the request object, the response object, the error object and the batch semantics and nothing else. It doesn't define a transport, authentication or a type system. Such a minimalistic approach makes JSON-RPC a widely used protocol: it's implemented by Ethereum, Solana, Bitcoin Core and other systems.

JSON-RPC request format:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBalance",
  "params": ["83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri"]
}

JSON-RPC response format:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": { "context": { "slot": 1 }, "value": 0 }
}

The id binds the response to a particular request, which allows a client to send multiple requests using one connection and process the responses accordingly. In case of an error, the response contains an error object with a numeric code and a message instead of a result.

Three useful features:

Stateless. Each request contains everything needed to process it. There's no session kept on the server side, which makes balancing between multiple RPC nodes easy.
Transport-agnostic. HTTP is the default transport for request-response calls and WebSockets are used to allow a server to push notifications.
Batchable. The client can send an array of request objects and receive an array of response objects in return, which reduces roundtrips.

How Solana uses JSON-RPC

A Solana node exposes a JSON-RPC 2.0 interface, documented at solana.com/docs/rpc. The Solana node API is divided into two groups depending on the transport used.

HTTP methods perform request and response calls. You may query a balance, an account, a block, a transaction or submit a signed transaction and receive a response. Examples of such methods: getAccountInfo, getBalance, getBlock, getTransaction, getLatestBlockhash, sendTransaction, simulateTransaction, getProgramAccounts.

WebSocket methods subscribe to notifications. You make a subscription once and receive a notification from a node every time it encounters a relevant event. All notifications are wrapped in the JSON-RPC protocol. Examples of such methods: accountSubscribe, logsSubscribe, programSubscribe, signatureSubscribe, slotSubscribe.

The methods themselves adhere to the JSON-RPC protocol specification. Solana introduces conventions in the params: the configuration object as the last parameter, which may contain commitment, encoding and some method-specific filters.

An RPC provider (such as OrbitFlare) runs nodes that expose this API and adds what raw nodes don't have: authentication, rate limiting, regional endpoints, load balancing and transaction forwarding prioritization. The RPC nodes page describes this in detail.

Commitment levels: the parameter that changes the answer

A Solana block passes through several levels of commitment and most read methods take a commitment parameter which allows you to select the level. With the advent of Alpenglow's Votor consensus algorithm replacing TowerBFT on mainnet in October 2026, the number of commitment levels was reduced to two in practice:

The same getBalance call may return different values depending on the commitment (a processed read and a finalized one), and each value is correct for the commitment level it corresponds to. When the results look strange, verify the commitment before doing anything else.

Also, for transaction submission, commitment determines what sendTransaction's preflightCommitment will simulate against and what signatureSubscribe will wait for.

The methods you will actually use

Having a good understanding of about a dozen methods will cover most cases.

Reading state

getAccountInfo: the data and metadata for a single account. The workhorse.
getMultipleAccounts: several accounts in one call. Use it instead of calling getAccountInfo in a loop.
getProgramAccounts: all accounts owned by a program, with optional filters. It's a very powerful but also very expensive method that is frequently priced or capped separately.
getBalance: lamports of an account.
getTokenAccountBalance and getTokenAccountsByOwner: balances of SPL tokens.

Blocks and transactions

getLatestBlockhash: the recent blockhash a transaction must reference to be valid. Call it immediately before signing.
getBlock and getTransaction: block and transaction details with a possibility to set an encoding.
getSignaturesForAddress: a paginated history of transactions affecting a particular address.

Submitting

simulateTransaction: simulate a transaction execution against the current state without sending it to the cluster. Use it to detect errors and estimate compute usage.
sendTransaction: submit a signed transaction. A node forwards it to the current leader. A signature is returned, but not the confirmation. The confirmation process is done separately.

Subscribing

accountSubscribe: receive notifications on account changes.
logsSubscribe: receive notifications for transactions whose logs mention a particular address or program.
signatureSubscribe: a single notification for a transaction reaching the desired commitment level.

Encoding and data size

Account data and transactions may be big and JSON encoding may be verbose. Most methods have an encoding parameter. base64 encoding is efficient for raw account data; jsonParsed encoding provides decoded fields for known programs (for example, for the token program) at the cost of size; base58 is a legacy encoding, slow and limited to account data of 128 bytes or less. Use base64 if you're going to parse the data yourself and use jsonParsed for decoding by the node.

Two practices related to size reduce your bandwidth usage and prevent rate limiting:

Use dataSlice in getAccountInfo and getProgramAccounts to receive only the necessary bytes.
Use getMultipleAccounts and batch requests instead of multiple individual calls.

Errors and what they mean

JSON-RPC errors have a code and a message. Some errors are common for Solana:

Blockhash not found or transaction expired: the blockhash you used is too old. Get a fresh blockhash and sign again.
Transaction simulation failed: the program returned an error. The logs in the error data will usually show the instruction that failed and why.
Rate limited (HTTP 429 from a provider): you exceeded your plan's request or compute budget. Batch requests, use subscriptions or upgrade.
Node is behind: the node is lagging behind the cluster. Providers automatically route around it; a self-hosted node requires fixing.

Remember: sendTransaction returning a signature means "accepted for forwarding", not a confirmation. Always confirm a transaction separately using either signatureSubscribe or a getSignatureStatuses poll and be prepared to re-sign with a new blockhash if the transaction expires.

Where JSON-RPC stops being the right tool

JSON-RPC is great for querying and submissions. It's a bad choice for three workloads. Knowing the boundaries saves you from fighting the protocol:

State streaming with high frequency. If you require getting every change to thousands of accounts as soon as it happens, WebSocket subscriptions grow to thousands of subscriptions and JSON encoding leads to a serialization bottleneck. Geyser gRPC (Yellowstone) streams account and transaction updates from a plugin running inside the node, filtered on the server side, in a binary encoding. See the gRPC product page for both Yellowstone and Jetstream services.

Detection of events with the lowest possible latency. A WebSocket notification arrives after the node processes the block. A shred-level feed lets you see the block as it's constructed by the leader. The difference is crucial for sniping, liquidations and copy trading. See what is Shredstream.

Priority transaction delivery. sendTransaction forwards a transaction through an unstaked connection which gets dropped first under congestion. Staked lanes and Jito bundles are different routes, described in how to land transactions on Solana.

A typical production stack uses all three: JSON-RPC for reading and submissions, gRPC for state streaming and a shred-level feed for events where the lowest latency matters.

A minimal client walkthrough

Any Solana client library hides the same process. Understanding it without the wrapper makes debugging easier.

Fetching a blockhash. getLatestBlockhash with finalized commitment (since Alpenglow, it's the same state that confirmed used to provide you, and confirmed is being phased out).
Building the transaction. Instructions, accounts, the fee payer and the blockhash.
Simulation. simulateTransaction to detect program errors and read compute usage.
Setting the priority fee. A compute budget instruction with the compute unit price suitable for the accounts you're using.
Signing and sending. sendTransaction with the skipPreflight flag set explicitly (false for safety, true if you've already simulated the transaction).
Confirmation. signatureSubscribe with the required commitment and a timeout to trigger a re-sign on expiration.

Each step involves a JSON-RPC call. Whenever something goes wrong, repeat the exact JSON-RPC call with a plain HTTP client and look at the response; the error object will almost always say what the problem is.

Conclusion

JSON-RPC is a four-field request and a two-field response and this is the reason Solana chose it to build its node API. Learn the dozen methods that cover most needs, use the commitment deliberately, batch and slice your requests to avoid the rate limit and treat sendTransaction as the beginning of the confirmation process. Whenever you run into the limitations of JSON-RPC, which occurs with high-frequency streaming and lowest-latency event detection, move to gRPC and shred-level feeds.

For an endpoint to make calls against, the RPC plans include a free tier with WebSockets and the gRPC service is available when streaming outgrows subscriptions.

Originally published at orbitflare.com.

Solana TPS Explained: Real Throughput vs the Headline Number

OrbitFlare RPC — Fri, 23 Oct 2026 19:25:05 +0000

Summary: Solana's transactions per second (TPS) number is one of the most cited and, at the same time, most misunderstood metrics in the crypto space. The theoretical cap is in the tens of thousands, while the sustainable mainnet number is in the low thousands. Starting October 21, 2026, thanks to the Alpenglow upgrade, all transactions are user transactions because validator votes never go through the blocks anymore. For your application, there are three critical numbers: TPS during peak times, how much throughput you get during the network congestion, and the latency between submission and finality. This article explains the way TPS is counted on the current Solana network, why there is such a huge difference, and how to think about throughput for your application.

Key Takeaways

Solana's TPS numbers do not include any transactions other than user transactions. Since the introduction of the Votor consensus (Alpenglow) on mainnet on October 21, 2026 (epoch 1064), every transaction is a user transaction as validator votes are exchanged peer-to-peer and aggregated into BLS certificates, so no vote transaction ever enters a block. TPS figures from before that date included votes and are not comparable.

A Solana block occurs every 200 ms (starting October 9, 2026) and finality is targeted at about 150 ms after the block (compared to about 12.8 seconds with TowerBFT). confirmed and finalized describe the same state now.

The throughput cap on Solana is measured in compute units per block and per account, not transactions per block. The limit is 50 million compute units per 200 ms block (the 100 million of SIMD-0286 was set for 400 ms blocks and scales with slot time) and 20 million per writable account.

The congestion on Solana is localized to the hot accounts: thousands of transactions can go through while just one pool is saturated. The per-account write budget is the bottleneck on Solana.

For your application, throughput is a function of the priority fee and a staked submission path, not the network TPS.

How TPS is counted

Each Solana block (slot occurs every 200 ms) carries a list of transactions. The TPS number is a simple calculation of the number of transactions in recent blocks divided by the elapsed time. There are three aspects that may affect this calculation significantly:

User transactions only. The introduction of the Votor consensus (Alpenglow) on mainnet on October 21, 2026, shifted voting off-chain: the validator sends its vote to other validators directly, votes are aggregated into a BLS certificate, and the block finalizes once at least 80% of the stake notarizes the block in the first round (or 60% in the second round in case the fast path is missed). Proof of History no longer regulates the block production, and the tick entries stop appearing in the shred stream. As a result, each transaction inside a block is a transaction that a user or a program sends. If an explorer still shows a separate "non-vote" or "true" TPS line, that distinction is historical: the two lines are now the same number. Before October 21, 2026, the TPS data included votes, which constituted about two-thirds of the total, so a chart that spans the upgrade shows a drop that is an accounting change, not a loss of throughput.

Fails are counted. A transaction that runs and fails because of slippage checks, program errors, and so on takes up space in a block and is counted. At volatile times, many of the DEX transactions may fail, thus the TPS number looks high although successful user throughput is much lower.

Choosing the period of averaging makes a difference. A spike in one second versus the average over one day are very different things and with Solana blocks every 200 ms, the one-second period covers only five blocks.

Theoretical versus real throughput

There is a difference between the theoretical max and the real performance because of three reasons: real transactions are heavier than benchmark transactions, real networks have latency between leaders, and the limit is the per-block compute budget, not the transactions per block.

The real limit: compute units, not transaction count

Solana does not enforce a transactions-per-block limit. Solana enforces the compute-per-block limit and the per-account compute limit inside a block. A block can have up to 50 million compute units at today's 200 ms slots: SIMD-0286 raised the limit to 100 million on 29 July 2026 for 400 ms blocks, and SIMD-0525 scales the per-block limits with the slot time, so the capacity per second of 250 million units is unchanged. A single writable account can use up to 20 million per block, meaning one hot account can occupy at most 40% of a block. Anza has proposed raising the per-block limit back to 100 million; that is a discussion, not an active change. Each transaction requests and consumes compute units: a simple transfer transaction uses a few hundred units while a complex DEX route can cost hundreds of thousands of units. With blocks every 200 ms, the network offers those 50 million units five times a second.

Two important conclusions follow from the above:

First, heavy transactions lower the TPS. A block with many swaps can accommodate fewer transactions than the block with simple transfers. Therefore, the TPS is partially reflecting the workload of the network rather than the capacity.

Second, hot accounts create local congestion. Each account has its per-block write budget, and one hot pool or token can be saturated, while other parts of the network have a lot of capacity. That is the reason why one memecoin launch can saturate one DEX pool, making the trading unfeasible while other transfers go well. Congestion on Solana is localized, and so is the fee market. Priority fee estimation must take into account the accounts you interact with, not the global average. Solana transaction fees explained covers that market.

What TPS means for your application

The aggregate TPS tells you almost nothing about the chances of success of your transaction. Three numbers matter the most:

Priority relative to other transactions that target the same accounts. Trading the hot pool, you compete with everybody else who accesses that pool for its write budget and your priority is determined by the priority fee. Estimate the fees per pool, not globally.

Your submission path. During the congestion, the network leader prioritizes the transactions that came via staked connections first. Unstaked submissions are dropped first, regardless of the network capacity. A stake-weighted QoS lane or a Jito bundle preserves your throughput during TPS spikes. See Solana MEV relayers compared for the options.

Latency to finality. The transaction that lands in the next slot (200 ms) versus the transaction that is five slots behind are two different throughput numbers for your application even if the TPS is the same. Region matters: the distance to the current leader determines the minimum time. Alpenglow targets finality about 150 ms after a block is produced, so waiting for finalized takes almost nothing extra and confirmed is the same state (note: confirmed will be removed from the RPC in a later release; use finalized in new code). One effect of faster slots is that a blockhash still expires in 150 blocks, or about 30 seconds. So offline signing workflows have less time margin now.

For the read-heavy applications, the relevant question becomes how quickly you observe changes, which is dependent on your choice of data feed rather than TPS. Geyser and gRPC feeds now have a bank_id next to each slot, so the consumer application should buffer by both slot and bank. What is Shredstream covers the earliest possible observation point.

How to measure throughput that matters to you

Landing rate: during the busy hour, out of transactions that you submit, how many of them land within two slots (400 ms)? That number reflects your effective throughput. If it drops in the busy hour, the fix is the path rather than the fee: OrbitFlare Apex routes each send to the current leader from a regional endpoint.
Slot delta: the distribution of the gap between submitted and landed slots. The tail of the distribution is what your users actually experience.
Failure rate: among your landed transactions, how many of them fail to execute because of the slippage or the stale state? Every failed transaction consumes the fee without any benefit.
Compute units per transaction: are you requesting way too many compute units? Overrequesting adds to your cost and congests the blocks.

Tightening your compute budgets, estimating the priority per account, and submitting transactions via the staked connection path will increase your effective throughput much more than any network-wide change.

Why the headline number still matters

Aggregate TPS is a reasonable proxy for the health of the network and its ability to handle the load without degradation. Sustainable TPS in the thousands with the subsecond finality allows consumer applications to treat Solana as a transactional backend. Network upgrades of 2026 (100 million compute unit blocks in July, 200 ms slots in October, Alpenglow consensus on October 21, and new validator clients such as Firedancer) continuously increase the ceiling. Phase two of Alpenglow, Rotor, is still to come as the replacement of Turbine block propagation. But please, do not confuse the ceiling with your own throughput. The latter is engineered by you.

Conclusion

Solana's TPS headline is a single figure that mixes fails and light transactions and tells you almost nothing about your application. The throughput that matters to you is localized: the write budget of the accounts you access, your priority fee relative to others accessing the same accounts, and whether your transactions go through a staked path to a nearby leader. Measure landing rate during peak hours, tune the compute and priority fees, and engineer your own throughput, not the network's.

If you need the submission path that is resilient to the peaks in the headline TPS, OrbitFlare RPC plans provide the staked transaction landing in eleven regions.

Originally published at orbitflare.com.

How Solana Validators Work and How to Choose One to Stake With

OrbitFlare RPC — Wed, 21 Oct 2026 12:22:20 +0000

In short, a Solana validator votes on blocks and, in proportion to the stake delegated to it, takes turns producing them. It earns rewards from protocol inflation and, if it uses the Jito client, from MEV tips, and distributes them to its delegators after taking a commission. For a user of the platform who stakes SOL, the choice of validator matters for their yield and downtime risk; for the one building applications on Solana, validators are where their transactions go in the end. This article describes how validators work, what they earn, what the numbers about performance mean, and how to choose a validator to delegate to.

Key takeaways

A validator earns two streams of income: from voting, which brings inflation rewards, and from running the Jito client, which makes it eligible for MEV tips. Both are shared with delegators, after commission.

A validator’s commission is only part of the story. Even a 0% validator that skips a lot of slots can pay less than a 5% validator that never misses a slot.

Delegating does not move your SOL. It delegates your stake’s voting and leading weight to the validator, and you control your tokens; you can change delegation or unstake them. Activation and deactivation occur at epoch boundaries.

The numbers that predict your yield are skip rate, vote credits, uptime, and commission, in that order of how often they are overlooked.

What a validator does

Every validator runs the Solana client with a vote account and stake delegated to it. That gives rise to two functions.

Voting. Every block the validator sees, it sends a vote transaction confirming it. Voting is how the network achieves consensus and how a validator earns vote credits every epoch. Votes cost SOL in transaction fees, so a validator that is not staked with SOL loses money.

Leading. The leader schedule for every epoch assigns slots to validators in proportion to their stake. When a validator gets a turn, it produces four consecutive blocks (about 1.6 seconds in total) by gathering the transactions, sorting them and sending the block through Turbine. The performance of a validator as a leader is measured in its “skip rate”, which is the share of assigned slots in which the validator failed to produce a block.

It should also be mentioned that the leader rotation is why latency on Solana is relative to a moving target, a theme that runs through network infrastructure for low-latency trading.

How validators earn

Inflation rewards form the steady basis, which depend on the network inflation, the stake share and voting performance of a validator. MEV tips are the variable part, which depends on the validator running the Jito client and the network activity in general; for more detail about the latter, see Jito bundles and tips explained.

Rewards accumulate every epoch boundary (which occurs every 2-3 days) and are automatically compounded, if you do not remove them from staking.

How delegation works

Delegating to a validator creates a stake account, which you control and is allocated to the validator’s vote account. Your SOL is not sent anywhere, so a validator cannot use it. What a validator receives is the voting and leader-schedule weights of your stake.

Activation. The new stake is activated at the next epoch boundary, but there is a warm-up limit per epoch.
Deactivation. Withdrawal of the stake occurs the same way, but in the opposite direction. You need to plan on a few days for redelegation to complete.
Risk. Solana does not have slashing at the moment, so delegating to a bad validator means losing rewards, not principal. In other words, a bad validator lowers your yield.

Most wallets support native staking. The page of Stake SOL helps to stake using the validator of OrbitFlare, and the staking calculator predicts your yield and compares validators.

The performance numbers and what they mean

The trap is to evaluate on the commission rate alone. A 0% validator that skips slots and votes too late receives fewer credits and therefore pays out less. Another trap is that a validator which advertises a low commission rate to lure more stake and raises it later is a well-known practice. Always check the commission history, not just the current commission rate.

How to choose a validator

Filter by performance. Low skip rate on several epochs, close to the maximum amount of vote credits and no recent delinquency.
Then compare commission rate and MEV commission rate together. A validator that runs the Jito client with a reasonable MEV commission rate will usually out-earn a non-Jito validator with lower commission.
Check the validator’s operator. Who operates it, where the hardware is, if there is information about the configuration. Anonymous validators with no track record are a risk to your yield, not principal, but still a risk.
Consider decentralisation. Delegating to validators that do not belong to large stake pools contributes to the network, and some validators are selected specifically for that.
Re-check every one or two epochs. Performance can change; a validator that was top-performing in the previous quarter can stop doing it now.

The staking calculator does the bulk of work automatically: it fetches the performance and commission rate of the validators you chose and predicts the difference in yield.

Running a validator yourself

Operating a validator is a business with an internal operational challenge. You will need current generation hardware (fast NVMe, lots of RAM, many CPU cores and good bandwidth), a data center that is located near other stake, monitoring to catch slot lag before it becomes delinquency, and plans for frequent client updates. Also, you need delegated stake to earn anything at all, and attracting it requires a performance record and a public presence.

Most people who want exposure to validator rewards prefer to delegate. As for the technical side of operating validators, the article of Solana node types explained contains details on what it needs vs regular RPC nodes.

Conclusion

A Solana validator votes, takes turns producing blocks in proportion to the stake, and earns inflation rewards and MEV tips, which it distributes to delegators after commission. Delegation assigns your stake’s weight, without transferring your SOL, and the choice of validator affects your yield through skip rate, vote credits and uptime, way before the commission rate even enters the picture. Filter by performance, then by commission and MEV commission rate, check the operator and re-check every few epochs.

To verify the numbers yourself, run two validators through the staking calculator. To delegate to ours, the validator page provides everything you need.

Originally published at orbitflare.com.

Building a Solana Liquidation Bot: Oracle Updates, Bundles and Landing First

OrbitFlare RPC — Mon, 19 Oct 2026 12:00:14 +0000

The Solana liquidation bot acts according to the stream of oracle updates and the rhythm of lending protocols to attack the vulnerable positions precisely when they become undercollateralized and attempt to execute an atomic repay-and-seize transaction before other bots do. The reward for such actions is a protocol liquidation bonus, and this strategy is the most legitimate way to exploit MEV on Solana as the opportunity is defined by protocol rules, the payoff is known in advance, and the competition is won by how fast you observe the oracle update and how successfully you place a Jito bundle. This guide will explain the architecture, the feeds, the bundle construction process, and the economics that will distinguish a successful liquidator from one who pays tips for nothing.

Key Takeaways

Liquidations are triggered by oracle price updates, so the race starts with the oracle account update rather than a risky position appearance. Observing the price change first is the only edge.

Repay-and-seize must be executed atomically. With a Jito bundle it either succeeds or fails; a regular transaction can leave you repaying someone's loan without receiving the collateral. OrbitFlare Apex carries either from a regional endpoint to the current leader, with a record of where it landed.

Keep all the at-risk positions in memory using a gRPC feed to make the hot path free of RPC requests when the oracle updates.

Tip sizing is the profitability key: the bonus is known, so tip a fraction of the bonus which will help you to win the auction without giving the edge to the validator.

How liquidations work on Solana lending protocols

The borrower provides the collateral and takes a loan. Protocols define a certain health factor or loan-to-value ratio, so once the price of the collateral decreases or the price of the debt increases, passing the ratio limit, the position becomes liquidatable. Then any user can repay the debt or a part of it and get collateral valued higher than the repaid debt; the excess of collateral price over the repaid debt will be the liquidation bonus.

Here is what you need to consider when building a liquidation bot:

The trigger is the oracle update. Prices change once the oracle account is updated. Positions do not become liquidatable on a timer; they become liquidatable the very instant the oracle price crosses the limit.
The payoff is known. Protocols publish the bonus percent. You can calculate in advance how much a successful liquidation is worth.
It is a race. All the liquidators see the same oracle update. Whichever bundle lands first gets the position.

Architecture

The indexer and the oracle watcher are the two feeds, and they deserve different observation points. The position state must be complete and precise, and this is ensured by Yellowstone gRPC. The oracle update must be seen as early as it is physically possible, so the shred-level feed is the way to go: you can observe the price update while the block containing it is still being built. This mechanism is explained in What is Shredstream; the feed is Jetstream gRPC.

The hot path, step-by-step

An oracle account update is received from the shred-level feed with the new price.
The evaluator calculates health for all the positions exposed to the asset in question. As the positions are stored in memory and sorted by their sensitivity, it is a scan of the at-risk tail, not the entire book.
For every position that became liquidatable, calculate the maximum repayable amount, collateral, and the net bonus after any swap needed to bring the collateral back to the repaid asset.
The bundle is built: repay instruction, seize instruction, possibly the unwind swap, and the tip transfer in the final transaction.
The bundle is simulated locally against the observed state. Bundles which fail the simulation or have a net bonus less than the floor are discarded.
The tip size is calculated from the simulated net bonus and the bundle is submitted to the nearest Jito block engine.
Everything is recorded regardless of the landing success.

None of steps two to six depends on a network request. This is the design principle, and that is what the shred-level oracle feed and the in-memory position book give you.

Why the bundle must be atomic

Liquidation is a process of two state changes: your repayment of the debt and your acquisition of the collateral. Executed as two separate transactions, these actions can be interrupted by a competitor, or the second can fail, leaving you repaying the debt of another participant. A Jito bundle executes these transactions sequentially and atomically in the same block, or drops the bundle entirely. It is this feature that makes liquidation bots use bundles rather than staked lanes. Jito bundles and tips explained describes the construction and limitations.

Also, a bundle enables the unwind: if you receive the collateral in one token, but need another one, the swap in the same bundle will convert it before the price change happens.

Tip economics

The bonus is known before the bundle is submitted, so the tipping is a rational decision, not a gamble.

Floor: the tip and the priority fees should leave the net bonus above your minimum; otherwise skip the position.
Ceiling: tipping the entire bonus wins the auction but leaves nothing for you. The goal is to tip a fraction which historically wins for positions of this size.
Adaptation: record tips on bundles that beat you (visible on-chain via tip-account transfers) and adjust. In volatile periods competition (and thus winning tips) is increased, and in calm periods it is decreased.

A costly mistake: tipping fixed, high tips to "guarantee" the win. Your bot will be winning more liquidations, but losing money on each of them.

Infrastructure

Placement: collocated near stake and near a Jito block engine region. This way both oracle feed and bundle transmission latencies are minimized.
Feeds: Jetstream for oracle accounts and Yellowstone for position state, both from the same region where the bot is placed.
Dedicated capacity: a dedicated node with the Jito client eliminates the shared-infrastructure variation from both feeds.
Multi-region setup is preferable if protocols that you cover operate all the time and leaders switch across the globe; see the low-latency infrastructure guide about routing.

Risk management

Volatile periods concentrate liquidations and trigger many risks simultaneously. Design for the crash, not calm days.

Measuring the bot

Oracle observation lag: the difference between the observed slot and the slot where the oracle update landed. Zero with the shred-level feed in the correct region.
Latency from the oracle update to bundle submission: your code's latency must be well under a millisecond.
Auction win rates: by position sizes and by tip fraction.
Net bonus realized vs simulated, per liquidation.
Rejected bundles by reason: stale state (read side too slow) versus lost auction (tip too low).

It is this last line that will tell you whether you need to invest in the infrastructure or tips.

Conclusion

The Solana liquidation bot is a race of oracle updates with an atomic payoff. Keep all the positions in memory using the Yellowstone gRPC feed, observe the oracle accounts using the shred-level feed, evaluate and assemble the bundle without a single network call, simulate it, size the tip from the known bonus, and submit to the nearest block engine. Then measure the oracle observation lag and reasons for rejected bundles, and spend accordingly.

The two feeds are provided by Jetstream gRPC; for the bundle side and comparison with other approaches see Solana MEV relayers compared.

FAQ

Which protocols can I liquidate on?

Any lending protocol that permits permissionless liquidation, which is most of them on Solana. Each has its own accounts, instructions and bonus rules; the architecture here is protocol-agnostic, the bundle builder is per protocol.

Do I need Jito for liquidations?

Practically, yes. Atomic repay-and-seize is the property that makes the strategy safe, and bundles are how you get it. A staked lane cannot guarantee the two legs land together.

How much capital do I need?

Enough to repay the largest position you intend to take plus tips across attempts, allocated so a cluster of simultaneous opportunities does not exhaust it mid-crash. Flash-loan style patterns exist on some protocols and change the capital requirement; check each protocol.

Is a liquidation bot ethical?

Liquidations are a designed, necessary function of lending protocols: they keep the protocol solvent and borrowers agree to the terms. It is generally regarded as legitimate market activity. This guide is engineering, not legal or ethical advice for your jurisdiction.

Why do I see the oracle update but lose the race?

Either your feed is later than a competitor's (compare against a shred-level reference), your bundle path is longer (region, block engine choice), or your tip is below the winning level. The rejected-bundle breakdown tells you which.

Can I run this on a shared RPC plan?

For development and small positions, a reserved plan with Jetstream and Yellowstone is workable. For competitive operation during volatility, dedicated infrastructure near stake is what the winners run.

Originally published at orbitflare.com.

Alpenglow: How Solana Swaps Its Consensus in One Slot

OrbitFlare RPC — Fri, 16 Oct 2026 14:17:32 +0000

Solana consensus has been using the same design since 2020. Every validator publishes votes as transactions in the blocks, adds increasingly strong lockouts and declares a block final once 32 more blocks have built upon it. It works, but it lacks a published safety proof, consumes over half of all transactions in the network, and its finality takes seconds despite the rest of the stack working in milliseconds.

Alpenglow is its replacement. The design is due to Quentin Kniep, Jakub Sliwinski, and Roger Wattenhofer, who left ETH Zurich and joined Anza after publishing their research on liveness issues in TowerBFT. Alpenglow was published in May 2025. Validators approved SIMD-0326 in September 2025 with 98.27% of participating stake in favor, and the protocol has been running on a community cluster privately for five months, undergone a bug bounty, rehearsed nine migrations and flipped on testnet and devnet. Mainnet is next.

Why TowerBFT Has to Be Replaced

There are three layers in today's consensus. Proof of History provides validators with a shared clock through continuous hashing. Turbine propagates blocks via a tree of validators, and Alpenglow will preserve this functionality for now. TowerBFT is a voting layer where every validator sends a transaction with the vote for the block it received, and this vote transaction is included into a future block similarly to others. Once there are 32 blocks built upon a block, it is rooted.

This 32-slot wait is responsible for the famous 12.8-second delay at 400-ms slots. Slots are 200 ms now under SIMD-0525, so the wait takes about 7 seconds on mainnet. Way before this moment, the block is optimistically confirmed at 66% of stake, which is what confirmed reports and most applications use.

The reasons for switching to Alpenglow are listed explicitly in SIMD-0326. Finality is slow for anyone requiring a no-rollback guarantee. Vote transactions make up between 54% and 59% of all mainnet transactions in late September 2026, according to Solana Compass, and each of them costs the validator about 5,000 lamports, which adds up to roughly 2.16 SOL per epoch. The votes go through gossip and are verified on chain. And, finally, TowerBFT lacks a formal safety proof. Votor solves all four of these.

Votor: Two Voting Paths at Once

The leader broadcasts the block in chunks via erasure coding. The moment a validator receives a valid and complete block with a parent block that it has already voted for, it broadcasts the notarization vote directly to every other validator. There is no transaction and no gossip here, just a signed UDP message. Then two paths of actions begin at the same time.

First, the fast path: if some validator collects notarization votes from 80% of stake, it puts together the fast-finalization certificate and declares the block final after a single round. Then the slow path: once 60% of stake has notarized, every validator casts a finalization vote, and a finalization certificate is created from 60% of them.

The first path to succeed wins. If 80% of stake is close to you, the fast path wins. If only 60% is close to you, two fast rounds among the latter can beat the single slow round that needs to gather 80%. The protocol does not have to guess the case.

The 80% and 60% thresholds are a result of the fault model. Under 20% Byzantine stake, any 60% certificate will be composed of votes from over 40% of honest stake, and since any honest validator can cast only one notarization or skip vote per slot, it is impossible for two different blocks to gather 60%. This is the basis of the safety proof of the algorithm. Every certificate consists of one BLS aggregate signature and a bitmap of signers, and thus is small enough to fit in one UDP message.

Timeouts are replacing PoH. When a validator receives a certificate for the block before the leader's four-slot window, it sets a timer for each slot in this window at once. In Agave, the base timeout is 400 ms plus one block time per slot, so at 200 ms blocks, the first slot in a window times out 600 ms after the parent block becomes ready. If the block arrives first, the validator votes for it. If the timer fires first, it broadcasts a skip vote for this slot and all subsequent unvoted slots in this window. No clocks need to be synchronized, as every validator just measures local short intervals. A skip certificate at 60% is a definitive outcome, and the next leader builds upon the latest notarized block, effectively ignoring the skipped slot.

Two fallback votes help to deal with leaders broadcasting different blocks to different validators. A validator who skips a block can switch to a notar-fallback vote once it notices 40% of stake notarizing a block, while a notarizing validator can switch to skip-fallback once it becomes obvious that no block can collect 80%. This guarantees that every slot will end with either a notarized block or a skip certificate. If no slot finalizes for 10 seconds, the validators rebroadcast their latest certificates and increase timeouts by 5% per window, so eventually even a regional outage resolves itself without coordination.

The 20+20 Model, Honestly

The main claim is that Alpenglow tolerates 40% of stake going down. This is correct, but an imprecise statement, and an accurate one is important.

Under complete asynchrony, Alpenglow is safe as long as Byzantine stake is less than 20%. Even an adversary controlling the whole network and delaying every message could not make two honest nodes finalize conflicting blocks. In addition to this, 20% of crashed stake does not affect the safety. As long as the propagation layer does not deliver different blocks for the same slot to different honest nodes, liveness is preserved. Thus, crash-only faults under 40% stake are always tolerated.

However, an adversary who controls a leader with 18% stake and can partition the honest network into two isolated clusters and broadcast different blocks to each of them can stall a slot. A well-distributed validator set makes it hard to do, but it is a known liveness attack. Therefore, understand 40% fault tolerance as 20% malicious plus 20% crashed, not as 40% malicious.

Compared with TowerBFT's 33% Byzantine bound, Alpenglow is worse against a coordinated attack by more than 20% and less than 33% of stake and better against anything else. The trade-off here is that in a large proof-of-stake network, a coordinated attack by a third of stake is not the most likely scenario. Bugs, misconfigurations and outages are, and these correspond to crashes. Signing two conflicting votes is a provable violation under SIMD-0326, but slashing is a separate proposal and is not live yet.

Rotor Is Not Shipping Yet

Rotor is the second part of the design. It replaces Turbine's multilayer tree with a single layer of stake-weighted relays, and makes the leader's upload bandwidth not a limit anymore. Reaching 80% of stake would take around 150 nodes and roughly 2 ms. This is not included in the planned 21 October activation. The Foundation marks it as a feature for a later stage without any date, SIMD-0326 carves it out for its own proposal, and Turbine remains. Fast leader handover and geo-aware handoff are postponed as well.

Votes Are Out of the Blockchain

Three changes happened on the mainnet months before the migration to make off-chain voting possible.

BLS keys (SIMD-0387, July 8, 2026). Since the Ed25519 signatures cannot be aggregated, every validator had to register a 48-byte BLS public key in its vote account with proof of possession. A vote account without one will behave like unstaked when Alpenglow is active, and getVoteAccounts will show a blsPubkeyCompressed field, which is null for those accounts that haven't performed this operation.

The Validator Admission Ticket (SIMD-0357, July 22, 2026). Once the vote transactions are gone, the vote fees disappear too. The VAT replaces them with a flat fee, burned from the vote account at the beginning of each epoch, and gives admission to the next epoch. It was 1.6 SOL per epoch at 400 ms slots and scales with slot time, so at today's 200 ms slots, it is 0.8 SOL per epoch, compared with roughly 2.16 SOL that validators spend on vote fees now. The first charge will be done at the beginning of epoch 1064 and funds epoch 1065. A vote account that cannot pay is not admitted, and that validator neither votes nor produces blocks for the next epoch. The set of admitted validators is capped at 2,000 by stake, which is way above the roughly 680 voting validators today.

Rewards continue to exist. The leader of slot s+8 may include BLS aggregations of votes received for slot s; each included vote earns its voter a share of issuance, and the leader earns the same as each voter for performing the aggregation.

Thus, the practical outcome is that the vote account, not the identity account, has to remain funded. Anza recommends routing block revenue into the vote account to cover VAT automatically and warns that the reward paid at the epoch boundary is too late to rescue a validator that lacks funds at the admission time.

The Migration: Switching Consensus Engines in One Slot

SIMD-0384 describes the process of switching. Its goal is that no user-signed transaction should be dropped and if the migration fails, nothing will happen at all.

Activation. The feature gate becomes active at epoch 1064, which starts at slot 459,648,000, and the Foundation expects it to start around 15:00 UTC on Wednesday, 21 October. For now, nothing changes.

Boundary. Exactly 5,000 slots later, at slot 459,653,000 and about 18 minutes afterward, leaders start packing vote transactions only into blocks. Honest validators will mark any block with a user transaction as dead, and TowerBFT will stop rooting. Since all further blocks will contain only votes, rollbacks of any of them incur zero cost to users.

Genesis. The validators will wait for the block at or after the boundary carrying TowerBFT votes from at least 82% of stake in its direct child. Blocks usually carry votes from over 95% of stake, so the boundary block will usually pass immediately. The last block prior to the boundary in this chain will become Alpenglow's genesis block, every validator will sign a BLS genesis vote for it, and with 82% of stake, the genesis certificate will form.

Handoff. Seeing the valid certificate, every validator will launch Votor from the genesis block, disable TowerBFT, roll back all blocks past the genesis in the same way duplicate-block handling works, and enable user transactions again. The genesis certificate will be recorded in the first Alpenglow block and in an on-chain account, so a validator restarting from a later snapshot will know what consensus engine to run. Anza estimates the handoff to take hundreds of milliseconds, and Triton One estimates a user-visible gap of about two slots.

If 82% never signs the genesis, there will be no abort step, as there is no need for it. The validators will continue using TowerBFT, and the migration will not complete. There is no intermediate phase when the chain uses neither engine.

The client diversity issue. Firedancer's v26.10.2 release published on 14 October and labeled as mainnet ready supports Alpenglow consensus, but not the migration from TowerBFT to Alpenglow. So, for the migration itself, every validator must use a client descended from Agave 4.3.0, and that is practically Agave, Jito-Solana or Harmonic Salsa, and then may switch back to Firedancer. According to Solana Compass, as of 13 October, about 15.8% of stake among the top 500 validators used Firedancer-family clients. If this stake stays as is, what remains is barely above the 82% threshold. Anza has been quite explicit that these operators have to switch beforehand.

The Track Record

The community cluster became operational on 11 May 2026 with over 40 nodes. The first migration attempt uncovered two bugs that Anza acknowledged on the validator call of the Foundation and hotfixed. The next attempt completed successfully, and the cluster has been running since then. A public explorer shows the finalization time of about 107 ms and around 96% of blocks taking the fast path. A bug bounty lasted from August 5 to August 19, and featured a fund of up to 50,000 SOL, 115 researchers and more than 300 submissions. Anza has reported payouts exceeding 25,000 SOL, though the breakdown of severity has not been published. Testnet flipped on September 24 at slot 444,625,255, and devnet on September 25 at slot 504,148,999. Agave 4.3 including the full Alpenglow code was recommended for all mainnet validators on September 21.

The 150 ms figure is based on the latency simulation with real validator latencies, with a median around 110 to 130 ms and the slowest node below 200 ms. Consider it an expectation, not a fixed number. A 54 ms testnet median circulated without any publicly named source, so we do not reproduce it.

What Will Change for Developers

Execution will not change. The SVM, transaction formats, programs, fees and priority fees will stay the same. All below is about consensus outputs and data you rely on.

Commitment levels. confirmed and finalized converge to the same state, defined as 60% of stake voting to finalize or 80% of stake notarizing, and finalized will arrive about 150 ms after the block instead of 32 slots later. They both will work on the activation day, and confirmed commitment level is scheduled for future removal, so use finalized in new code. Do not switch early. Until the genesis certificate is present, finalized commitment on the mainnet still means a 32-slot wait. Check getAgGenesisCert on your RPC, which will return null under TowerBFT and a certificate object once Alpenglow is live. The meaning of getBlockCommitment disappears, as there is no lockout stack to report.
Transaction counts. Vote transactions will disappear from blocks, so per-block counts and every TPS chart will drop by over half without any change in actual activity. Adjust alerting thresholds before 21 October.
Multiple candidate blocks per slot. A leader may produce multiple blocks for a slot, and only one will be notarized, so Agave 4.3 will tag Geyser events with a bank_id, and Yellowstone gRPC will expose it. If you build blocks from transactions or account updates, group them by slot and bank id, keep the candidate that reached confirmed and discard others. The ids are node-local, so align blocks across providers by blockhash only. The four legacy Geyser callbacks become deprecated in favor of bank-scoped ones.
Ticks and block footer. PoH ticks will disappear from the shred stream. Alpenglow blocks start with a BlockHeader marker and will end with a versioned footer (SIMD-0307) containing the producer timestamp, a client user-agent string and the leader's latest finalization certificate. The footers are accessible via a gRPC opt-in filter, but are not accessible via JSON-RPC yet.
Clock sysvar. The layout will be the same, but the unix_timestamp will become set by the leader in a bounded range, not derived from a stake-weighted median of votes. Use it as an approximation.
Blockhash expiration. Slots still exist, and the 150-slot window will remain the same, corresponding to about 32 seconds at current slot timing. Fetch blockhashes at confirmed or higher, as a hash of a vote-only block that will be rolled back during the migration is useless.
Yellowstone gRPC. The plugin release for Alpenglow is v16.0.0-rc10+solana.4.3.0. Old clients will continue streaming but will not be able to see bank_id and footers.
Migration day for bots. Expect one or two slots of vote-only blocks somewhere near the boundary, followed by a small break in the slot numbering sequence. Read at confirmed through that window, and hold back from the activation slot until the genesis certificate appears if you are conservative. Jito’s BAM nodes will go into maintenance mode during the transition.

Requirements for Validators. If you operate a validator, here are the three requirements you need to satisfy: operate a client based on Agave 4.3.0, since Firedancer can’t help you through the transition; register a BLS key and confirm it with solana vote-account; keep the vote account balance at the rent-exempt minimum plus 0.8 SOL before epoch 1064, with a refill plan. Otherwise, you’ll be left outside the admitted set and earn nothing until you sort it out.

Things That Alpenglow Does Not Do

It does not improve throughput. “100 times improvement” is about finality latency, not block limits, execution, and compute budget.
It did not cut the slot time. The transition from 400 ms to 200 ms was SIMD-0525, implemented in four phases from August to October, unrelated to Alpenglow.
It does not eliminate MEV. The window from block visibility to finality narrows to around 150 ms, thus squeezing the latency arbitrage space, but it does not change the block building incentives.
It does not bring in slashing, Rotor, or fast leader handover.
It is not quantum-resistant. There is an experimental quantum-resistant hash-signature scheme called Quantumglow, with no plans on the schedule yet.

Implications for Building on OrbitFlare

As we run RPC, WebSocket, Yellowstone gRPC, Jetstream, and Shredstream, all the above features land on our infrastructure stack and on yours.

RPC and WebSocket users will benefit the most for free. Once getAgGenesisCert starts returning a certificate on mainnet, the guaranteed finalized state will come in a sub-second timeframe, and your signature status flow will respond even faster. Do not switch to finalized prematurely, and do reset any alerts about transaction counts. The gap described in our commitment levels explainer between confirmed and finalized is going away.

Yellowstone gRPC and Jetstream users should implement bank_id processing mentioned above if they build blocks from the transaction-level data and upgrade to the Alpenglow client release prior to activation day. For Jetstream users who act on decoded transactions at processed, their logic will remain the same, but the window where that data is ahead of finality will become shorter, from seconds to about 150 ms.

Shredstream users will be impacted the least as Turbine will stay, and so will shreds. Ticks will disappear, blocks will acquire a header marker and a footer, and under SIMD-0337 the FEC sets will be fixed at 32 data shreds plus 32 coding shreds. Rotor, when it ships, is the change that touches the propagation path, and our Shredstream piece covers how the current one works.

In case you are uncertain about your category, contact us in the OrbitFlare Discord channel prior to activation rather than after.

The Short Version

Alpenglow is a protocol with published proofs, a fault model that is worse for one particular type of attacker, but better for all others, and a migration that cannot lose user transactions or leave the chain between two engines. The primary risk on 21 October is not about the protocol itself; it is about ensuring that all validators run a single client family for the transition, and about one sixth of stake has to move before then. If the transition experience repeats the testnet and devnet one, then the transition will take a few hundred milliseconds, and Solana will wake up with 150 ms finality and votes off the chain.

OrbitFlare is a Solana infrastructure layer providing RPC, WebSocket, Yellowstone gRPC, Jetstream shred-decoded streaming, and Shredstream services.

Resources

Originally published at orbitflare.com.

How to Build a Solana Indexer: Streams, Backfill, Decoding and Reconciliation

OrbitFlare RPC — Wed, 14 Oct 2026 12:36:06 +0000

Short answer: a Solana indexer consumes the chain's account and transaction streams and transforms them into a queryable database specific to your application. Token holders, pool activity, NFT transfers, and protocol positions: whatever your product needs, in order to answer faster than an RPC call can. The indexer architecture consists of a stream consumer (Geyser gRPC for live), a backfill source (archive RPC for history), a decoder for every program, an idempotent database writer, and a gap/reorg handling routine. This post describes every part, the decisions that make the indexer robust under load, and the underlying infrastructure.

Key Takeaways

Index via Geyser gRPC stream, not via polling. Filters on the server side provide exactly the accounts and programs of interest, at node-processing latency.

Backfill history via an archive once, stay live afterwards. Combining them without a cutover point usually results in holes in the index.

Every write must be idempotent and keyed by the slot and the signature, due to stream replays and forks.

Decode using the program's own layout and version the decoder; program upgrades cause silent corruption most often.

What an indexer is for

An indexer is a tool to precompute answers to your questions and serve them from a database. Solana's RPC provides the answers to such questions as "this account now" or "that transaction happened". But it does not answer aggregate and historical questions efficiently: who holds a token, the hourly volume of a pool, the ownership history of an NFT. The indexer computes the answers by consuming the stream of account writes and transactions and storing them into the database of your choice.

The indexer output serves your product needs, whether it's a relational database for analytics, a hot-path key-value database, or a search engine for discovery. While the output varies between products, the input is always the same: the account writes and transactions, filtered to the programs you are interested in, and ordered by slot.

Architecture

The live consumer

Subscribe to the stream using Yellowstone gRPC filters for the accounts (by owner program with memcmp filters on discriminators in case multiple account types exist) and the transactions (including your programs). If the indexer does not handle rollbacks, request confirmed commitment; processed commitment is earlier, but can be rolled back.

Track the slot number on every message. Your consumer's current slot number vs the chain's current slot number is the lag metric that shows how well your indexer keeps up with the chain, and a hole in the series of slots is a trigger for a gap reprocess. Yellowstone gRPC explained describes the stream subscription model; WebSockets vs gRPC explains why the stream uses gRPC at this scale.

Backfill

The history prior to the beginning of the live feed comes from archive RPC. The usual approach:

Find the slot number at which your live consumer starts.
Walk getSignaturesForAddress for your programs backwards starting from this slot, paging until you find the first slot that needs to be indexed.
Fetch each transaction via getTransaction (or a block via getBlock if the density of the transactions is high enough) and pass it through the same decoder and writer as in the live path.
Stop at the cutover slot number. Transactions newer than this one are live, and older are from backfill. They should not overlap without idempotent writes.

Backfill is where the request budgets go to die. Batch, page carefully, and use the plan whose archive access and rate limits match the job; historical data is this tier in OrbitFlare, and Solana RPC pricing explained explains why archival calls are expensive under credit pricing.

Decoding

The account data are bytes arranged according to the layout defined by the owning program; the instruction data as well. Decode using the IDL or layout of the program, and treat the decoder as versioned code: in case of a program upgrade and a layout change, the old accounts may contain the old layout until rewritten. A decoder that relies on a single layout silently corrupts the index.

Three practices:

Key decoders by the program ID and discriminator, and handle the unknown discriminators by logging and skipping, not guessing.
Calculate token balance differences using pre and post token balances from the transaction metadata. They are independent from the instruction decoding and thus work regardless of any unknown layout.
Store the raw bytes in addition to decoded records for a retention period to be able to replay the decoding fix without fetching everything again.

Writing idempotently

The streams replay after disconnection, backfill overlaps the live feed at the cutover point, and forks at the processed commitment may deliver the same slot twice with different content. The writer must be ready for all three: every record is keyed by the slot and the signature (and the instruction index where relevant), and writing the same key twice is either no operation or an overwrite, never a duplicate.

Two patterns:

Upsert by the key for current-state tables (holder balances, pool state).
Append-only events are keyed by the signature and the index for history, with a unique constraint that excludes duplications.

Commit in slot order and track the last completely written slot as a checkpoint; on restart, the indexing resumes from this point.

Reconciliation

Gaps and reorgs happen and should be expected, not an exception.

Gaps: if your consumer skips some slots in its sequence, refetch the corresponding blocks from the archive RPC and process them with the pipeline.
Reorgs: at processed commitment, a slot can be superseded. Either index at confirmed (easier option) or maintain the window of unconfirmed writes that can be rolled back when a slot is superseded.
Drift checks: regularly compare the sample of indexed state against live getAccountInfo requests; the discrepancy means some problem with the decoder or writing.

Infrastructure

Streaming: a gRPC endpoint in the region where the indexer is running, with the throughput generated by your filters.
Archive: an endpoint with the required history depth and a request budget that is capable of surviving the backfill.
Dedicated capacity when your filter volume is high or backfill is continuous; a dedicated node removes shared limits from both paths.
Database: sized for write throughput in slot order, with indexes optimized for your queries rather than for ingest.

Conclusion

A Solana indexer is a live gRPC consumer with an archive backfill and a cutover point, with a decoder per program, idempotent database writer keyed by slot and signature, and a reconciler that handles gaps and reorgs. Start by getting the keys and commitment level right, since they define whether the indexer will stay correct under load or not. Then choose the streaming and archive endpoints that match your filters and backfill needs, and implement the drift checks to avoid undetected corruption.

OrbitFlare's gRPC service covers the live path, historical data the backfill, and dedicated nodes the volume. For token and NFT questions the Digital Asset API answers ownership and metadata queries without an index of your own.

Originally published at orbitflare.com.

How to Run a Solana Validator: Hardware, Setup, Operations and Economics

OrbitFlare RPC — Mon, 12 Oct 2026 13:09:30 +0000

Running a Solana validator requires managing a highly capable server staying synchronized with the chain, casting votes on every new block, and generating blocks on time, while gathering enough delegated stake to be profitable. The technical aspect of configuring can take only a day, but running a validator is a lifelong dedication to hardware, networking, upgrading, and monitoring. Only once a validator gets a trusted name from delegators does the business pay off.

This guide will cover hardware requirements, the step-by-step setup process, operations details, economic factors, and the honest decision if you should consider running a validator or delegating the stake.

Should you run one?

Consider becoming a validator to run an infrastructure-related business, having delegable stake or the way to gather it, and being ready for permanent operations. Consider delegating your stake if you are interested in staking yield; the staking calculator allows comparing options.

Do not become a validator in order to "have a node for your app". Validator is a poor RPC server (API traffic and voting compete); the proper option is an RPC node.

Hardware and location

Requirements grow with each network upgrade; current minimal configurations are listed in official documentation, while the typical configuration exceeds it. General outline does not change much, however:

Frankfurt, Amsterdam, and the East coast of the United States are regions with large stake accumulation and validator density because of that. Metered Internet egress is the dominant source of the bandwidth cost in public clouds.

The setup sequence

Provision your server host: tweak OS (file descriptor limits, network buffer sizes, huge page allocation), provision separate disks for accounts and ledger, provide time synchronization.
Install your client: official Agave client or a popular Jito-Solana client (which provides MEV capability), or a newer Firedancer-based client. Pin its version; updating should be deliberate and done with care.
Generate necessary keypairs: for identity, for vote account, and for authorized withdrawer which you store securely offline. Keep identity private key on the node, while withdrawer stays offline.
Create a vote account with set-up commission and fund the identity account with sufficient amount of SOL to cover vote fees.
Restore the node starting from snapshot and not from the genesis, allowing it to catch up with the chain tip.
Check if the node is successfully synced, casting votes and listed in validator list with right commission.

Perform the setup process on testnet first: testnet was created for such purposes (devnet vs mainnet vs testnet). Testing the update and restart processes on the testnet prevents any damage during the process on the mainnet.

Daily operations

Upgrades: clients receive regular updates, some become obligatory by a set deadline. Follow announcement channels, test the update on testnet and perform the upgrade on mainnet in the window selected by you to not coincide with being a leader.

Monitoring: watch for lag compared to the cluster, per epoch vote credits compared to peers, skip rate, delinquency status, disk usage and its rate of growth, network usage, and the SOL balance on the identity account for vote fee. You have to set alerts for all of them; otherwise, validator loses reputation without any notice.

Restarts: schedule them in advance. Restart of the node during its leadership slots leads to skipping of them. Snapshots reduce time required for a restart process, but do not make it instant.

Key maintenance: keypair for authorized withdrawer is used to withdraw rewards from the vote account; make sure this key stays offline. Change the identity key pair only after testing.

Ledger management: as the chain grows, set up retention and pruning parameters, otherwise the disk will fill up and prevent further operation of the node.

The economics

The process of getting profitability starts with losses for new validators. To get stakeholders' trust, you have to present good performance, join available delegation programs, offer reasonable commission without previous bait-and-switch history and operate well for as long as it takes for public metrics to speak for you.

Failure modes

Synchronization failure because disks or network throughput was chosen by the minimum possible value; node failed to keep up with chain under load.
Missing obligatory update; validator is disconnected from the cluster.
Restarting during leader slots and skipping of leader slots due to it.
Running out of vote fee SOL on the identity account.
Exposing validator public RPC port and lowering vote performance by doing so.
Loss of key or online storage of withdrawer key.

All of those failure modes are easily avoided with proper monitoring and runbook, that's why initial testing on testnet is important.

Conclusion

Running a Solana validator is infrastructure business: latest generation bare-metal server close to other stakes, deliberate client selection and provisioning process, testing on testnet and monitoring on lag, skip rate and vote credits thereafter. Only after delegators trust the public metrics, the business starts earning money, and until that, it requires spending some. If your goal is staking yield, delegate it to the validator; if you need a Solana node to run your application, either run a dedicated node or rent RPC access. You have to become a validator only if running one is the goal itself.

OrbitFlare operates Jito-enabled validator you could delegate to, and staking calculator allows you to evaluate your choice before making it.

Resources

Solana RPC for AI Agents: MCP, Tools and Guardrails

OrbitFlare RPC — Thu, 17 Sep 2026 12:07:34 +0000

An AI agent acting on Solana requires exactly the same components a trading bot requires, arranged in a way safe for the language model to use: a read path to current chain state, a write path to land transactions, and guardrails that bound the agent's spending and signature power. In 2026, this means an MCP (Model Context Protocol) server and tools wrapping the provider's RPC, gRPC, and transaction-landing endpoints, keeping keys and limits on the server side. Here we cover what exactly an agent needs from Solana infrastructure, how to expose it via MCP and tools, latency and cost issues, and guardrails that prevent an autonomous agent from turning into a costly incident.

What an AI agent needs from Solana infrastructure

The column on the right is the relevant one. A model can reason well on structured results and terribly on raw account bytes, and must never be able to construct a transaction from a raw RPC endpoint. Each capability is a tool, and the schema is where the guardrails live.

MCP: the standard interface

MCP allows a model to discover and invoke tools provided by a server via a standard protocol. In case of Solana, an MCP server wraps a provider's endpoints and exposes various tools, including get_account, get_token_balances, simulate_swap, send_transaction and others, each with typed inputs and outputs.

OrbitFlare provides an MCP server and agent tooling for its endpoints; docs.orbitflare.com/agents describes the installation procedure and the available tools, including the CLI and SDK versions. The principles described below are applicable whether you use that server or implement your own.

Keep credentials on the server side. The MCP server stores the RPC key and, in case the agent is allowed to sign, the signing key or delegated signer. The model sees the tool names and results, but never the secrets.

Make reads broad and sends narrow. Expose many read tools with generous limits and one or two send tools with strict policy. The agent should be able to explore anything freely and only able to act through a gate.

Return structured and decoded data. Decode token accounts, pool reserves and transaction metadata on the server side. Passing raw base64-encoded strings as the tool result wastes the context and is prone to misunderstandings.

Guardrails that belong to the tool layer

A prompt is not a guardrail. You can talk the model out of following the prompt instruction; but you cannot do that when the limit or cap is enforced on the server side in the code.

Latency: slower than a bot, but not optional

An agent's workflow consists of observe, reason, act stages, with the reason step requiring hundreds of milliseconds to several seconds. This is much slower than a trading bot, leading some teams to think that the latency issue can be completely ignored here. But it cannot, because of the following reasons.

First, outdated observation gets amplified by the long reasoning time: an agent reading a pool price, thinking for three seconds and acting upon it acts based on the price several slots old. Provide the agent with a fresh read immediately prior to sending, with a simulation returning an error in case the state moved.

Second, an event-driven agent requires prompt wake-up. An agent reacting to a wallet movement or a governance proposal should be triggered by a subscription (Yellowstone gRPC or WebSockets), not a polling by a timer.

For agents doing trading, the execution path is the same as for bots: a staked submission lane to avoid dropping the transaction under the load.

Cost: agents are very chatty

A model exploring the problem can invoke a dozen of read tools per step. When multiplied by steps and number of agents, it will consume the entire request budget. There are three ways to handle it.

Cache on the server side. Account reads that were not changed since the last slot require no additional RPC calls; and a Yellowstone subscription keeps the cache hot.
Batch in the tool. A get_token_balances tool should do a single getMultipleAccounts call, not a separate one per account.
Prefer a pricing model that does not weight methods. Agents call expensive methods (getProgramAccounts, history) freely; while credit-based pricing penalizes that.

A reference setup

Provider endpoints: a keyed RPC URL, a Yellowstone gRPC endpoint, and a staked send path, all in the region close to your agent's host.
MCP server with stored credentials, exposing decoded read tools, a simulation tool, triggers for subscriptions and a policy-gated send tool.
Agent runtime (any model with tool invocation) with the MCP server, a limited signing key and the kill switch checked on every send.
Observability: every tool invocation logged with input parameters, result, latency and cost, so you can trace what the agent did and why.
Evaluation: re-run recorded tool invocations trace against new prompts or models.

Conclusion

Solana infrastructure for AI agents is exactly the same read, write and guardrails stack as a bot, provided as typed tools via MCP with credentials and policy on the server side. Give the agent broad, decoded and cached reads; mandatory simulation step; and a narrow, limited, allowlisted send path with a kill switch. Trigger it by subscriptions rather than timers, and price for the chatty access.

Documentation of OrbitFlare's agents has the MCP server and SDK. The RPC plans and gRPC service are the provider endpoints behind it.

Resources

Solana WebSockets vs gRPC: When to Switch and How

OrbitFlare RPC — Wed, 16 Sep 2026 12:33:23 +0000

Both WebSocket and gRPC are meant to push Solana updates to the application without the need for client-side polling; for some types of dashboard subscriptions, the two can be used interchangeably. Differences arise when working on a larger scale: WebSocket subscriptions happen on the RPC layer after the block processing, transfer JSON, and become hard to maintain past several dozen subscriptions. On the other hand, Geyser gRPC is integrated into the node process, transfers binary data, applies server-side filters, and works well with thousands of accounts on a single stream. The suggested way to migrate is from WebSockets to gRPC as soon as the subscription count, message rate, or latency become a problem, whereas WebSockets continue to be used in simple scenarios.

Operational mechanisms

WebSocket is a subscription part of the Solana JSON-RPC API. A WebSocket Secure (WSS) connection is established with an RPC node, subscribe requests are performed, and the node starts pushing notifications in JSON format when matching events reach the chosen commitment level. The events themselves are collected by the node in its internal block processing, and the RPC service then formats and sends them.

Geyser gRPC is a plugin running inside the node process. It receives every account write, transaction, slot, and block, processed by the node, and streams the subset of it that satisfies the user-defined filters using a gRPC connection based on Protocol Buffers. No intermediary RPC layer is involved here, and no JSON is used. Yellowstone is the default plugin, and you can find details about the subscription model of Yellowstone gRPC in its documentation.

Comparative overview

Use cases for WebSockets

Transaction confirmation: the signatureSubscribe functionality provides a simple tool to track a transaction until it reaches the desired commitment level.
Simple dashboards: keeping track of just a few accounts and the balances and logs of some programs using WebSocket capabilities is quite easy.
Notifications where some latency is not a concern: notifications where some hundred milliseconds delay is acceptable.
Client simplicity: wide library support with almost no dependencies.

Use cases for gRPC

Mass account watching: keeping track of hundreds of wallets or all accounts belonging to a certain program with gRPC subscriptions is much easier than with WebSockets.
High message rate: the high message rate becomes a performance bottleneck for JSON serialization and per-subscription overhead on WebSockets; gRPC can handle the high throughput of streams.
Latency-sensitive logic: apps like trading, liquidation, and copy-trading bots require earlier visibility and server-side filters.
Comprehensive transaction metadata at scale: Yellowstone transaction updates contain inner instructions, balance changes, and logs; the information vital for indexing.

There is a third option for workloads where a single event is being watched that comes before both WebSockets and gRPC ones: shred-based streams like Jetstream where the transactions reconstructed from the leader broadcasts prior to node processing of the blocks are sent. The Shredstream architecture explains why it works in advance.

Migration from WebSockets to gRPC

The transition doesn't have to be a full-scale thing done at once. The steps can be the following:

Measure your baseline metrics: number of subscriptions, message rate, and latency between the slot of the event and the processing of it by the app. It will show what subscriptions to migrate.
Migrating the largest subscription first: it usually involves the programSubscribe or many accountSubscribe requests. Replace them with one gRPC accounts filter scoped to the program owner.
Migrating the latency-sensitive subscription next: the subscription that drives the bot's logic. Replace it with gRPC transactions or accounts filter at the processed or confirmed commitment.
Keeping the simple subscriptions on WebSockets until you have reasons to migrate them: for instance, signatureSubscribe for your own transactions.
Handling reconnections and possible gaps. gRPC streams are prone to disconnections; perform idempotent resubscriptions and check the state of the stream against the chain after a long pause.

Common mistakes

Opening a WebSocket for every account. Better to multiplex the subscriptions on one connection or, even better, migrate them to gRPC.
Client-side filtering on gRPC: subscribe widely and filter locally, thus consuming extra bandwidth and latency. Use the filters in the subscription request.
Using processed commitment without considering rollbacks: the earliest commitment on either transport is reversible; use confirmed ones unless you can handle the reversion.
Polling and subscribing to the same thing simultaneously: if you have a subscription, stop polling the same data, as it wastes the request bandwidth and is slower.
Ignoring slot gaps: keep track of the slot corresponding to each message; the growing difference between the message slots and the current slot shows that the consumer is falling behind.

Cost aspects

WebSocket is included in most plans, even free tiers, because the node processes each event only once irrespective of the subscriber count. gRPC is usually a higher tier or a separate product because it transfers much more data per client.

Conclusion

Both WebSocket and gRPC transfer Solana updates; the differences are in the node interface, data serialization, filters, and scalability capabilities. WebSockets are to be used in simple, small-scale, and latency-tolerant subscriptions, as well as for confirming one's transactions. Geyser gRPC should be used for multi-account watching, high message rate, latency-sensitive logic, and the shred stream in case you need an early event visibility prior to the node block processing. The transition should be gradual with the prioritization of subscriptions depending on the workload.

OrbitFlare provides WebSocket on all plans and Yellowstone and Jetstream gRPC across all eleven regions. You can find more details on the gRPC page.

Resources

getProgramAccounts Alternatives: Stop Scanning, Start Streaming

OrbitFlare RPC — Tue, 15 Sep 2026 12:51:08 +0000

getProgramAccounts retrieves all accounts belonging to the given program with optional filtering in one request. It makes the method extremely costly, rate-limited and prone to throttling, making it the most expensive, rate-limited and throttled call in Solana RPC API. There are multiple options to use instead for anything else than a one-shot request: Geyser gRPC subscription streaming the accounts continuously, indexer pre-populated once for cheap querying, getMultipleAccounts if the addresses are known, or a provider-side index like the Digital Asset API (DAS) for tokens and NFTs. Below you'll find the explanation of why the call is costly, what are the use-cases for it and alternatives for each of the use cases.

Description of the method and the source of the cost

getProgramAccounts(programId, filters) requests the node to fetch all accounts with the given program as the owner and, optionally, filter them by data size and by memcmp filters on the account data. Node must look into its account index with the given owner, apply the filters and serialize the response.

The request is cheap for a small program owning just a few hundred accounts. On the contrary, a token program, a major decentralized exchange or a lending protocol owns millions of accounts. Even with tight filters, the node does lots of scanning and produces a huge response. Providers limit this call (by rate, response size or require filters and dataSlice), weight the call very heavy in credit pricing and may offload the call to the specialized hardware. Applications repeatedly calling this method in a loop to monitor accounts are the most common cause of throttling and unexpected invoicing.

Use cases in which the method remains a good choice

One-shot discovery: finding all accounts of the given kind to seed an indexer or a cache.
Small programs: programs controlled by the user with a limited number of accounts.
Development: exploring a program's accounts while developing it.

In all three cases the use of dataSlice to get only the necessary bytes and applying tight memcmp filters on the discriminator is advised to reduce the size of the response.

Alternative 1: subscribe to the accounts with Yellowstone gRPC

If the reason to call getProgramAccounts repeatedly is to detect changes in accounts, a subscription is better than scanning. A Yellowstone gRPC account filter by the owner program (same memcmp conditions) will stream all writes to each matching account. It eliminates the loop and provides lower latency than any polling period.

Alternative 2: build an indexer and query your own storage

When the goal is to answer some aggregate questions (e.g., all holders of a mint, all positions above a certain threshold, all pools for the given pair) the proper solution is a database built from the stream and queried using SQL or a key-value lookup. Seed the indexer with a single getProgramAccounts call or archival backfill and keep it up-to-date via gRPC to avoid scanning the chain for the same question again.

Alternative 3: `getMultipleAccounts` for known addresses

If the target accounts are known (they are derived addresses or have been identified by an indexer), fetch them directly. getMultipleAccounts returns up to one hundred accounts per call and takes a fraction of the cost of a scan over a whole program. Many looping implementations of getProgramAccounts actually request "fetch these fifty accounts I already know" in the wrong way.

Accounts like associated token accounts, PDAs and pool accounts should be derived, not searched.

Alternative 4: provider-side indexes

There are some questions that are asked often enough for providers to maintain their own indices. The most famous example is NFTs: Digital Asset Standard (DAS) API can answer "which assets does this wallet own" and "what is the metadata of a given asset" for standard and compressed NFTs without any program scans from the client side. NFT and DAS indexing on Solana explains the issue. For token holders, balances and other questions check whether there is an index provided by your provider.

Decision framework by the question

If the continuous usage of the method is still needed

Always use memcmp filters on the discriminator and use dataSlice to fetch only the necessary bytes.
Request data at the confirmed commitment level; finalized commitment will give you the old snapshot anyway without any gain for a scan.
Cache the results and compute the diffs instead of re-fetching the whole datasets.
Prefer pricing models that don't weight the method specifically.
**Consider getting a dedicated node if the scans are critical for your product: it will have a fixed hardware cost and no per-call costs and reduce the throttling risk.

Conclusion

getProgramAccounts is a discovery method that turned into a polling method. It explains the throttling of applications and invoice increases. Substitute endless loops with Yellowstone gRPC subscription when you need to detect changes, with indexer for fast aggregate queries, with getMultipleAccounts if the addresses are known or with a provider-side index like DAS if you need to work with NFTs. Keep using the method for one-shot discovery with dataSlice and filters.

OrbitFlare's gRPC service is the streaming alternative to getProgramAccounts, and the RPC plans are priced by requests per second with no method weighting, so the call costs the same as other methods when you need it.