DEV Community: OrbitFlare RPC

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 provider-side index like DAS API for 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.

Resources

Copy Trading Architecture: Centralized vs Decentralized

OrbitFlare RPC — Mon, 14 Sep 2026 12:50:02 +0000

The difference in copy trading architecture centralized vs decentralized lies in the place where the trade is copied: a private platform ledger or a public chain. A centralized platform mirrors trades between accounts which it already controls. A decentralized platform needs to detect a trade outside of its control and submit another one before the window closes.

What's the real architectural difference between centralized and decentralized copy trading?

Centralized copy trading mirrors a trade within the platform's infrastructure without involving blockchain. Decentralized copy trading observes a public wallet on a blockchain, detects an order made by the wallet and executes another one to follow it.

eToro explains the operation principle of its CopyTrader system: you allocate $1,000 to a trader who has $10,000 on their account, and when they open a $1,000 position, a $100 position opens automatically in your account. It is proportional, executed on the platform's infrastructure and custodial. There is no wallet to monitor since the platform sees everything in advance.

Decentralized copy trading doesn't allow any of that visibility. The wallet's transactions arrive on the public ledger and nothing will push them to you, so you have to retrieve transactions yourself and fast enough that there is still a time to submit a copy trade.

How does a decentralized copy trading platform's architecture actually work?

This is a combination of a detection layer and an execution layer, and almost all mistakes are made on the detection layer, by failing to see a transaction in time. The platform should see the transaction instantly, decode the trade and execute it before it is too late.

The problem lies with the detection layer. Polling an RPC endpoint for signatures of the wallet works theoretically until you realize that you miss the trades and you receive updates periodically. OrbitFlare's own trader infrastructure page states that "Copy trading fails on latency and on gaps. Polling getSignaturesForAddress means you find out after the fact and miss anything that lands between calls." The fix for that is a push model, a gRPC stream filtered by an account id server-side so that you receive transactions instantly.

The execution layer then needs to submit a copy trade fast and protect from front-running. Here the MEV protection becomes useful, since Jito bundles offer fast landing and revert protection, so a copy trade transaction either lands or fails without costing you the position.

How do you actually build a copy trading platform on blockchain?

Three components must operate to submit a trade: a low-latency data stream for detecting the trades of the source wallet, a decoder which understands the instructions of the DEX, and an execution pipeline which submits the trade quickly enough. A failure in any one of the components renders useless the rest of them.

We made a working example of this exact architecture available instead of just explaining it. solana-copy-trader template uses Jetstream instead of polling, can decode swaps across Jupiter, Raydium, and Pump.fun, and uses Jito MEV protection so that a copy trade lands safely without risking getting sandwiched. The platform is written with Rust, Tokio, gRPC and Redis, not because this is an unusual tech stack, but because copy trading is a streaming problem first and this is the stack which is efficient at processing a constant flow of transactions in real time without falling behind. The majority of copy-trading bots in the wild are broken at the decoding step, because they can decode swaps of one DEX and silently miss trades routed to any other DEX.

What does the future of decentralized copy trading look like?

More and more platforms will switch to the streaming model because the platforms which copy trades one block late will keep losing fills to the platforms which use the streaming infrastructure. The copy trading infrastructure will become the question not of whether it should be decentralized or not, but how much latency it can tolerate depending on the strategy being followed. A slow-moving position tracker can get away with polling, but a sniper copy trade bot cannot.

The best copy trading platforms, centralized or decentralized, converge to the same requirement: the platform must see the source event instantly, not on the next scheduled update. This is true regardless of whether you run a copy trading platform for retail followers or a copy bot for a specific strategy, because the infrastructure underlying the crypto copy trading platform is increasingly becoming the same as the infrastructure for market data.

Frequently asked questions

Is decentralized copy trading always better than centralized? Not necessarily. It trades the simplicity of the platform for the non-custodial feature and the ability to verify transactions publicly at the expense of the necessity to implement an infrastructure for detecting and racing on the blockchain transactions.

What is the minimal latency a decentralized copy trading platform needs? There is no definite answer, because the latency requirements depend on the specific strategy being implemented.

Want to see how the infrastructure of streaming-based copy trading looks in reality? OrbitFlare's trader solutions cover RPC, gRPC and Shredstream products which are commonly used for building such a bot.

Resources

Solana Devnet vs Mainnet vs Testnet: Which Cluster for What

OrbitFlare RPC — Fri, 11 Sep 2026 14:00:38 +0000

There are three public clusters in Solana: Mainnet Beta, Devnet, and Testnet. Mainnet Beta is a production network with live SOLs, Devnet provides a way to test applications for free with freely airdropped SOL, but without any financial risk, while Testnet is supposed to be used by core developers and validators to test the next release of the network itself, and it is intentionally unstable and is not intended for application testing. Develop on Devnet, deploy to Mainnet and avoid deploying to Testnet except for validator software testing. This article is devoted to a thorough description of each cluster, how to direct your wallet and code to a cluster, practical differences between them and common mistakes made because of confusion with their usage.

The three clusters

"Beta" in the name of Mainnet is historical, as it supports real value for years and works as a production network.

Devnet: a development platform

Devnet uses the same validator software as Mainnet (sometimes even a newer version), runs identical programs and exposes the same RPC API, which means that the code can easily be switched from Devnet to Mainnet by changing an URL. You can get SOL from the faucet (there are some limitations on rate; do not request too much), deploy programs and verify end-to-end flows with zero financial risks.

There are two caveats with Devnet: firstly, it can be reset, destroying all deployed programs and accounts; keep scripts of deployments to be able to redeploy programs. Secondly, it is quiet: there is no congestion, no competition for the block space and no saturation of transaction forwarding. It verifies the correctness of the logic but does not give any information about landing rate, priority fees and latency under load.

OrbitFlare provides Devnet and Mainnet URLs per account; every OrbitFlare plan, even free, includes Devnet.

Mainnet Beta: the home of the value

Devoted to real SOL, real users and real competition for block space. All validations on Devnet, although helpful, are not enough here: network congestion appears during important events, leaders prioritize staked connections and priority fees are real market. The low-latency infrastructure guide covers specifics of this environment.

Testing on Mainnet before launching should be done in small scales: just replicate the same transaction flow, spend real fees and measure landing rate in peak periods.

Testnet: generally not suitable for applications

Testnet is used for validators to be able to run release candidates and for core teams to test network changes under load. It is updated frequently, may fork or be reset and tooling is oriented towards node operators. Application developers testing their programs on Testnet face instability without any benefits. In case if some tutorial tells you to use Testnet for your dApp, this tutorial is probably outdated; use Devnet instead.

In case if you are going to operate a validator on Mainnet, you can run one on Testnet as a proving ground.

Pointing wallets and code to a cluster

Wallets: most wallets have a network switcher (Mainnet, Devnet, Testnet) in settings and a separate RPC field per network. Switch to Devnet to verify the application running on a Devnet deployment; return to Mainnet before handling real funds.

Code: cluster is defined by an RPC URL. Keep one URL per environment in configuration (for example, SOLANA_RPC_URL for production environment with a connection to Mainnet and a separate variable for development environment with a connection to Devnet), do not derive one from another at runtime. Local test validator (solana-test-validator) is the fourth way to test your code: a private cluster on a local computer, instant and free, without any network involvement.

Program addresses are different in different clusters for your own programs (each program is deployed separately per cluster), but core programs (token program, system program, associated token program) have the same addresses. Well-known third-party programs are usually deployed both on Devnet and Mainnet at identical addresses, but still better to verify.

Practical differences

The main difference is that Devnet verifies the correctness of the logic and Mainnet verifies the performance and economics. Bots, in particular, may work perfectly on Devnet and become unprofitable or unable to land on Mainnet, which explains the emphasis on Mainnet testing in the sniper bot guide with small transaction volumes.

Common mistakes

Incorrect URL in production. A release targeted to Devnet looks working but actually performs no real operations. Separate configurations and startup check of genesis hash will help to overcome this problem.
Testing landing on Devnet. Transactions always land on Devnet, so measure on Mainnet.
Expecting that a certain program exists on Devnet. Some Mainnet programs are not deployed on Devnet or are deployed at different addresses; better to verify this.
Relying on Devnet state. Resets destroy it; keep scripts of redeployments and seed data.
Using Testnet for dApps. Its instability does not provide any benefits.

Conclusion

Devnet is for development, Mainnet is for production and Testnet is for network-level testing. Keep separate cluster URLs per environment, verify the genesis hash at startup, verify your logic on Devnet and performance on Mainnet with small-scale tests and understand that landing, fees or latency characteristics cannot be verified on a quiet cluster.

OrbitFlare provides Devnet and Mainnet URLs through a free account; RPC plans cover the Mainnet path in case of deployment under load.

Solana Archive Nodes and Historical Data: What Needs an Archive and How to Use It

OrbitFlare RPC — Fri, 11 Sep 2026 13:55:20 +0000

A standard Solana RPC node maintains only a recent history of ledger data, so requests for blocks, transactions, or signatures older than some time window return no results. An archive, or, more precisely, an archive data tier, holds the full ledger history in a separate long-term storage and delivers it via the same RPC API. You need access to archive data if you want to obtain a wallet's history, the trades of a pool from some months ago, or any block created before last week; most people rent it rather than maintain it themselves. This post explains what the retention window is, which methods use the archive, what it means to run an archive, and how to use historical data efficiently.

Retention window

Any Solana validator or RPC node stores the ledger (i.e., blocks and transactions) in a local database that gradually accumulates entries. Due to the huge amount of history, nodes perform pruning: they keep a certain number of recent slots and drop older ones. The window is measured in days. Requests for any slots within the window succeed, while requests for any slots outside the window return null or an error that the slot is unavailable.

That might be unexpected for teams that are familiar with other chains, where a full node can deliver any history. On Solana, the full history is an explicitly separate product.

What is an archive tier

An archive is a long-term storage of all blocks and transactions starting from genesis or from the moment when the archive was turned on; all blocks and transactions are delivered via the same RPC methods. The reference implementation uses a wide-column database (there is support for a BigTable-style backend), and providers maintain something similar to that. When an RPC node receives a request for a slot that is out of the local retention window, it forwards the query to the archive.

On your side, nothing changes: the same call for a transaction works for transactions created yesterday or two years ago as long as the endpoint has an archive access.

Which methods use the archive

This last detail changes the way you design applications. There is no "balance at slot X" method on Solana. If you need any historical balances or positions, you should rebuild them yourself from the history of transactions (from pre- and post-balance in every transaction's metadata).

Typical archive queries

wallet history: all transactions of an address, done with the combination of getSignaturesForAddress and subsequent getTransaction calls. Required by explorers, portfolio trackers, tax calculators.
protocol analytics: all swaps at a pool during a period, re-created from blocks or from the lists of signatures for a program.
indexer backfill: filling all the pre-live data.
compliance and audit: proving what happened and when.
research: any walk through history.

Running your own archive

It is the most expensive Solana infrastructure to maintain: the historical data is huge and grows by each slot, the backing storage has to grow along with that, and the ingestion process should never lag behind. Providers or large indexers with their dedicated data team are usually the ones who run it. For most projects, the option of renting access to the archive is reasonable. OrbitFlare historical data tier is an archive tier and is available via the same API endpoints as the whole service.

Using historical data efficiently

Historical calls are the heaviest and, under credit-based pricing, the most expensive requests in the API. There are four ways of reducing cost and latency:

Page getSignaturesForAddress requests with before and until and stop as soon as you reach the range that you need; don't scan the whole history if you need only last month.
Use getBlock with transaction details if a block contains many interesting transactions, and use getTransaction if there are few. It is very wasteful to fetch an entire block to get a single transaction.
Cache immutable results. Finalized transactions never change; you should store them once.
Backfill once, then stay live. Use a gRPC stream to receive new data and an archive for pre-backfill data.

Choose a pricing model that works well with the historical queries. Under requests-per-second pricing model, a historical call is the same as any other call; under credit pricing model, it is usually weighted heavier.

Conclusion

Solana's standard nodes forget history after some days; anything older is an archive query delivered from a separate long-term storage via the same RPC API. Historical calls to getBlock, getTransaction, and getSignaturesForAddress against old slots need an archive access; current-state calls never do, and there is no historical-state calls at all; thus, history reconstruction is an indexing task. Rent an archive access rather than run it yourself, do efficient paging and caching, and choose a pricing model that doesn't punish heavy requests.

OrbitFlare historical data tier delivers the full history through the standard API endpoints; combine it with the gRPC service for the post-backfill data.

Agave 4.2: Transaction V1 Breaking Changes Checklist

OrbitFlare RPC — Thu, 10 Sep 2026 00:02:52 +0000

Transaction V1 activates on Solana mainnet at the next epoch boundary on 10 September 2026. The new version increases the maximum transaction size from 1,232 bytes to 4,096 bytes and adds a new format that cannot be read by the old client libraries.

Only one item on the list causes an error; all others allow code to function with incorrect numbers.

Current status of each change

Agave 4.2 was released on 11 August 2026; however, none of the changes have been activated on that date. Every change has its own activation gate, which explains the different dates mentioned above.

1. Require v1 on every call that returns transactions

What fails. Any call that returns transactions and has not been declared compatible with version 1.

How it fails. With an error (the only item causing an error). The error code is -32015. The whole call fails, not just this particular transaction. As a consequence, a single v1 transaction in a block breaks the getBlock call for the whole block.

Where to verify. getBlock, getTransaction, getTransactionsForAddress when transactionDetails is full, and the transactionSubscribe and blockSubscribe WebSocket subscriptions.

Recommended action. Add maxSupportedTransactionVersion: 1 to every relevant endpoint. Update the SDK first and check its ability to read v1 transactions; otherwise, requesting an unsupported version will merely move the error. For TypeScript, use @solana/kit 8.0 or higher, or @solana/web3.js v3. For Rust, use solana-rpc-client-api 4.2 or higher.

2. Read the priority fee from the header

What fails. Any way to estimate the fees by looking for ComputeBudget instruction.

How it fails. Without an error. A v1 transaction doesn't contain a ComputeBudget instruction; any code scanning for it fails to find anything, reports zero, and proceeds further. Thus, every v1 transaction appears to pay zero priority fee.

Reason for change. With v0, validators needed to look through the instruction data to calculate the bid of a transaction, which took time. With v1, the compute budget moves into the header, where the priority fee, the compute unit limit, the account data size limit, and the heap request reside. In case a v1 transaction contains a ComputeBudget instruction, it is simply ignored.

Recommended action. Use the priorityFee property from the transactionConfig object. Watch the units carefully; in legacy and v0 the number meant the price in micro-lamports per compute unit. In v1, it means the total in lamports. Thus, the priorityFee of 50000 corresponds to 50,000 lamports for the whole transaction.

3. Stop assuming updates for every writable account

What fails. Everything that correlates transactions to accounts, performs reconciliation, and counts the number of account updates.

How it fails. Without an error. Agave 4.2 stops writing accounts that a transaction locked for writing but didn't update; thus, those accounts stop emitting updates in getBlock and gRPC and WebSocket streams. Providers deploying the new release start getting approximately 80% fewer events, although depending on the kind of data you monitor.

Recommended action. Consider the absence of the update event as a signal of "unchanged" rather than as an error. The fee payer is the only account that can be assumed updated reliably. Thus, adapt your monitoring code to the situation; you'll start getting a lot fewer update events, even without service failures.

4. Add a new reward type

What fails. Parsers limited to the fixed number of reward types.

How it fails. Without an error. The stake account being deactivated produces a final payout with type DeactivatedStake, which appears together with other types (fee, rent, staking, voting) in getBlock and blockSubscribe rewards. Parsers unaware of the new value simply skip it.

Recommended action. Add DeactivatedStake to the list of accepted reward types. During the update, make sure to log the unknown values, so that you'll start seeing the newly introduced values in logs instead of holes in numeric outputs.

5. Update Token-2022 parsing

What fails. Anything that parses Token-2022 instructions or mint extensions from jsonParsed responses.

How it fails. Some expected fields might be missing, whereas some absent fields might appear.

Changes.

depositConfidentialTransfer and withdrawConfidentialTransfer no longer have separate source and destination fields; there is a single account field now, since the two were always equal.
unwrapLamports, confidentialBurn, permissioned burn, and batch operations are parsed as JSON instead of raw bytes. unwrapLamports has the amount as a string and it can be omitted if the whole balance is unwrapped.
Mints with unknown extensions no longer return an empty extensions array, but the full correct one, which can have some names unknown before.

Recommended action. Adapt your code to the new account field structure, don't reject extension names you don't know yet, and consider the absence of unwrapLamports amount as the sign of complete unwrap.

6. Stop using the hardcoded slot time

What fails. Anything that relies on 400 ms interval.

How it fails. Slowly accumulates problems: timeouts trigger too soon, estimates of blocks per window go wrong, and calculations of duration based on slot count become wrong.

Recommended action. Mainnet has switched to 350 ms at epoch 1020 (21 August 2026) and to 300 ms at epoch 1024 (28 August). SIMD-0525 reduces the slot time by 50 ms each time, approaching 200 ms. The 250 ms value is currently active on testnet but not on mainnet. Don't hardcode the value; calculate the time either based on block timestamps or configure it so that the future changes would be done via configurations, not new releases.

Versions to pin

The minimum version corresponds to the earliest release able to read v1.

Note: orbitflare-sdk-proto is an internal dependency of the Rust SDK and is included automatically; direct pinning is only needed if you consume the protos directly.

Go users need to regenerate the protobuf bindings from the current Yellowstone protos and solana-storage-proto, not from an older pinned file.

If decoding transactions manually

If you parse raw transaction bytes, be it the provided decode example, a custom shred decoder, or your own parser, there are three layout changes.

The version byte is 129 now, allowing distinguishing v1 transactions from legacy and v0.
Signatures come at the end of the transaction, not at the beginning.
The compute budget moves from the instructions into the header.

Address lookup tables do not exist in v1; practically, this is fine, because the 4,096-byte limit allows listing the accounts directly.

Conclusion

There are six items to check, with the only one failing definitively. Other five allow normal operation with erroneous measurements.

Do it in the following order: first fix the reading calls (the primary source of errors), then the fee interpretation, then the account and reward parsing, and finally the timing constants.

OrbitFlare's RPC, Yellowstone gRPC, and Jetstream systems deploy the current Agave release in all regions, handling the format changes on the server side. Jetstream sends v1 transactions without requiring subscription change.

Resources

Solana RPC Rate Limits: How They Work and How to Stop Hitting Them

OrbitFlare RPC — Tue, 08 Sep 2026 15:11:31 +0000

In short, the provider, not the protocol, enforces the Solana RPC rate limits, which are available in three forms: a number of requests per second, a monthly quota of credits or compute units, and per-method limits applied to costly operations such as getProgramAccounts. If you reach one of these limits you receive an HTTP 429 response or a JSON-RPC error, and the solution is seldom to upgrade to a more expensive plan; instead it is generally necessary to stop polling, to batch the data you fetch, to subscribe to changes and to cache the data that doesn't change. This guide outlines how the limits work, how to determine which one you have hit, and the modifications that reduce request volume by a factor of ten.

Key Takeaways

Public endpoints limit requests per IP address, and strictly so, while provider plans impose limits per key and include a budget that can be viewed in a dashboard.

The three types of limits fail in different ways: if the RPS limit is exceeded the system returns a 429 immediately, if the credit allowance is exhausted it either throttles the request or charges for the overage, and a heavy method may be refused completely.

Nearly all limit problems involve polling. Simply replace a poll loop with a subscription and the calls will be eliminated.

Regard a keyed URL as a credential; if the key is leaked it will use up your quota on someone else's machine.

How the limits work

The Solana protocol does not have the idea of an API rate limit; instead, a node will respond to whatever request it is able to handle. Such limits are necessary since nodes are finite and the providers have to share them. Three methods are commonly used, often being combined.

Limit	How it is measured	What hitting it looks like
Requests per second	A sliding window per key or per IP	Immediate 429 on the excess requests
Monthly allowance (credits or compute units)	Each method deducts a weight from a pool	Throttling or overage billing when the pool is empty
Per-method limits	Caps or refusals on heavy methods	Errors specific to `getProgramAccounts`, large `getBlock` calls, archive queries

The public endpoints are the ones with the lowest numbers and are associated with your IP address. The public mainnet endpoint, for example, allows 100 requests per 10 seconds per IP, 40 requests per 10 seconds per IP for any single method, 40 concurrent connections per IP, and 100 MB of data per 30 seconds, and Solana's own documentation says that it is not intended for production applications. For provider plans, the numbers are given according to each tier and usage is displayed in a dashboard, which should be the first place you check when there's a problem.

Diagnosing which limit you hit

When receiving an HTTP 429 with bursts: you have exceeded the number of requests per second. Check for loops, parallel fan-out, or a retry storm.
Either 429 or the rate is reduced towards the end of the month: the allowance is used up. Check the usage at the method level since the typical cause is a heavy method being called in a loop.
Errors occur only in the case of a particular method: there is a per-method limit. The usual examples are getProgramAccounts and the extensive getLogs or getSignaturesForAddress ranges.
If you see usage that you do not recognise, the key may have been leaked. Rotate it and find out who is calling with it.

Cutting request volume

The fixes listed below are given in order of the amount of request volume they usually save.

Use subscriptions instead of polling. If a loop calls getAccountInfo once every second, it ends up making 86,400 calls per account each day and detects changes with a delay. However, using a WebSocket accountSubscribe or a Yellowstone gRPC accounts filter results in no calls being made and means that changes are detected instantly. This one change eliminates most of the request volume in most applications.
Do not call getProgramAccounts in a loop. It is the most intensive method in the API and at the same time the one that providers restrict the most.
Batch. getMultipleAccounts can retrieve up to 100 accounts with a single call; by using JSON-RPC batch requests (an array of request objects sent in a single POST, which the Solana RPC specification supports), several calls can be combined into a single round trip. Ten calls are then made as one.
Store data that is immutable and changes slowly. Finalised transactions never change, so they can be cached for as long as you like. Program accounts that have been decoded once can be kept, and token metadata also changes rarely. The time-to-live period for the cache should match the frequency with which the data actually changes.
Use dataSlice and precise filters. Only retrieve the bytes that are required. This is cheaper in terms of compute units and results in faster responses everywhere.
Fix the retries. When receiving a 429 response, use exponential backoff with jitter and avoid attempting an immediate retry since a retry storm can turn a short-term limit into a lengthy outage.
Instead of checking the status via getSignatureStatuses at intervals of a few hundred milliseconds, confirm the transactions using signatureSubscribe.

Designing for limits from the start

Use one connection per process, and reuse it with keep-alive; establishing a new connection for each request results in latency and causes the limits to be reached more quickly.
Prepare a budget on a per-feature basis by determining the number of calls that each part of the application makes per user action and then monitoring this figure in the provider's dashboard as the features are released.
Assign separate keys for each service and environment. A job that goes wrong in the staging environment should not use up the resources allocated to production, and a leak in one service should not cause all the other services to fail.
Monitor the 429 rate and usage in relation to the allowance, with alerts triggered well in advance of exhaustion.

When you actually need a bigger plan

Once the adjustments mentioned above have been made, ongoing legitimate traffic that exceeds the plan's ceiling is the reason to upgrade. The other reason is when you need a feature which the tier doesn't provide: gRPC streaming, archive depth, regional endpoints, or a staked transaction path. And when high levels of sustained traffic are involved, a dedicated node eliminates rate limits altogether since your limitation will then be determined by the hardware rather than by a shared budget.

The plans offered by OrbitFlare are based on requests per second without taking into account the weight of individual methods, meaning that a heavy method does not use up part of the allowance; the tiers are listed on the RPC nodes page.

Conclusion

The rate limits on Solana RPC services are a feature provided by the provider and come in three forms: per second, per allowance, and per method. Work out which of these you are encountering by looking at the error messages and using the dashboard, then reduce the volume by subscribing rather than polling, phasing out loops using getProgramAccounts, batching the requests, caching the results, slicing the data, and correcting the retry mechanism. It is only after that that a bigger plan becomes appropriate, and at a real scale a dedicated node makes the issue disappear.

The OrbitFlare RPC plans state their requests-per-second budgets and offer WebSockets on all tiers; the gRPC service is the subscription option which makes most polling unnecessary.

Resources

Solana clusters and public RPC endpoint limits
Solana JSON-RPC documentation
getMultipleAccounts reference
OrbitFlare RPC plans
OrbitFlare pricing
OrbitFlare dedicated nodes

How to Build a Solana Sniper Bot: Detection, Filters and Execution

OrbitFlare RPC — Tue, 08 Sep 2026 14:04:21 +0000

In a nutshell, a Solana sniper bot is a type of program that spots a new liquidity pool or a token listing as soon as it appears on the blockchain and then places a buy order before the wider market has had a chance to react. Since the entire approach is a race that takes place in milliseconds, the bot essentially consists of three parts: a detection layer which picks up the event first, a decision layer which filters out potential scams, and an execution layer which carries out the transaction while the price is still exactly as it was when it was observed. This article examines each of these layers, explains where the time is actually spent, and outlines the failure modes that distinguish bots that function in real conditions from those that only work on the testnet.

Key Takeaways

The speed of detection is what gives you the edge. A bot which learns about a pool from a finalised block is already hundreds of milliseconds slower than one that reads shreds or uses a low-latency gRPC stream.

The reason for most losses isn't that the bot is slow; it's that it buys the wrong thing. Honeypot checks, authority checks, and liquidity sanity checks should be included in the hot path and not left until a later review.

Execution requires a prioritised write path; if a simple sendTransaction is carried out at the time of a launch, it goes out over an unstaked connection and usually loses to snipers who are on staked ones.

Build around the leader schedule, since the region from which your transaction leaves is determined by where the current leader is sitting.

How does a Solana sniper bot actually work?

A sniper bot monitors on-chain events, detects the establishment of a tradeable market, decides within microseconds whether or not to take action, and then carries out a swap. On Solana the events that are worth keeping an eye on are the instructions which create or initialise a pool on a DEX program (Raydium, Orca, Meteora and the launchpad programs that migrate into them) and the first liquidity deposit that makes the pool tradeable.

The pipeline has four stages, and each stage has a latency budget:

Stage	What happens	Typical budget
Observe	See the pool creation instruction on chain	Where most of the race is won or lost
Decode	Parse accounts, mint, liquidity, authorities	Sub-millisecond if done in memory
Decide	Run safety filters and position sizing	Sub-millisecond for precomputed rules
Execute	Build, sign, and land the swap	Network bound; region and path decide it

All the parts that come after 'observe' take place within your own process and can therefore be made faster through normal engineering techniques. Since the 'observe' and 'execute' stages rely on infrastructure, the remainder of this guide focuses most of its attention on that area.

Detection: where the race is decided

There are four methods of working out that a pool has been made, and these methods are not the same.

1. Polling an RPC. Continuously calling either getProgramAccounts or getSignaturesForAddress. This is simple but terribly slow: you only find out about the pool a few seconds after it has been created, and you end up hitting your rate limit as a result. It can be of use only for research and never for actual live sniping.

2. WebSocket subscriptions. By using logsSubscribe or programSubscribe on the DEX program, you will receive a push notification whenever a matching transaction is processed. This represents the basic requirement for a functioning bot, but the notifications are sent after the RPC node has processed the block, which is after the leader has produced it and after it has been propagated.

3. Geyser gRPC (Yellowstone). The Geyser plugin sends out a gRPC stream which provides account and transaction updates as the node is processing them, with filtering carried out on the server so that you only get the data for which you have subscribed. It has lower latency than WebSockets and is much more selective. This is the minimum requirement for most serious bots.

4. Shreds. When a leader is forming a block, it sends out fragments called shreds. If you look at these fragments directly or use a service which reconstructs the transactions from them, you will be able to see the pool creation as the block is still being put together, prior to any RPC node having processed it. This represents the earliest possible point at which observation can take place, and it is what distinguishes consistently early bots from the rest.

In reality the stack is as follows: it includes a Shredstream-fed stream for the hot path, a gRPC stream as the source of structured data, and WebSockets as the fallback option. Because OrbitFlare's Jetstream gRPC provides the stream derived from the shreds with the transaction already decoded, your bot receives a typed event instead of raw packets. Details about the mechanics can be found in what is Shredstream.

Decoding the event correctly

When an event occurs, the bot requires the pool address, both token mints, the initial liquidity amounts, and the accounts that it will need in order to carry out a swap. Two rules prevent this stage from becoming a bottleneck.

Parse in memory, never fetch. Each time you make a getAccountInfo call after the event it involves a round trip that you can't afford. Decode the instruction data and the accounts list from the transaction itself and keep the DEX program layouts in your binary, along with a warm cache of the token program, the associated token program and the common vault layouts.

Precompute what you can. The address of your wallet's associated token account for a particular mint is deterministic. The swap instruction for a given DEX is a template as well. Before the event takes place, prepare as much of the transaction as possible and then insert the mint and pool addresses when they become available.

A good decode stage runs in less than a millisecond. If yours is slower, profile it before changing anything.

Deciding: the filters that save you money

It's speed that gets you into the trade, while filters keep you out of the trades which were meant to take your money. The typical traps found on Solana launches, and the safeguards that detect them:

Trap	What it looks like	Check
Mint authority retained	Creator can mint unlimited supply after launch	Require mint authority to be revoked or null
Freeze authority retained	Creator can freeze your token account	Require freeze authority to be null
Fake or tiny liquidity	Pool exists but has trivial depth	Minimum liquidity threshold in SOL terms
Liquidity not locked or burned	Creator pulls liquidity after you buy	Check LP token destination; prefer burned LP
Sell tax or transfer hook	Token program extension blocks or taxes transfers	Inspect Token-2022 extensions; skip unknown hooks
Concentrated holder	One wallet holds most of the supply	Holder distribution check via indexer or cached data

Each of these has to be based on data that you already possess or that you can obtain from a single cached source. A filter which requires three RPC calls is one that causes you to be delayed. Since many bots have a background indexer that continuously monitors token metadata and holder distributions, the hot path performs a hash lookup instead of making a network request.

This also applies to position sizing. You should decide the maximum amount of SOL per trade, the maximum slippage, and the maximum share of the pool's liquidity that you are willing to take up before the event takes place. These should be set as constants and read by the hot path, not made into calls.

Executing: landing the buy

You first observed the pool and concluded that it was safe; at this stage the transaction has to get to the current leader before all the others'. This is entirely an infrastructure issue and it has four parts.

Priority fee. Set the compute unit price high enough to win ordering within the block. Since the fee market on Solana is specific to the accounts you interact with, the relevant price is the one that other snipers are paying on this pool, not the overall median fee for the network. Estimating the fee dynamically, based on recent transactions that have involved the same DEX program, is better than using a fixed fee.

Write path. When a launch is taking place the public TPU gets overwhelmed by other snipers and as a result the unstaked connections are dropped first. In this case you should use either a Jito bundle (one that includes a tip reflecting the expected edge) or a stake-weighted QoS lane. We look at all the options in how to land transactions on Solana. A staked lane is generally the better default choice for single-leg sniping since the bundle auction involves an extra step.

Region. In the current slot the leader is a particular validator located in a specific datacentre. When a transaction goes from Frankfurt to a leader based in Ashburn, it pays for the Atlantic twice: once when your data arrives and again when the block returns. Serious bots operate in more than one region and submit their transactions from the one closest to the scheduled leader. The region pages show where OrbitFlare has a presence.

Retry strategy. Send the transaction to both the current leader and the next one, then stop. Blindly resending it for ten seconds will burn through the rate limit and often results in a worse fill in a later slot that you didn't want.

A reference architecture

Putting the stages together, a production sniper looks like this:

Streams: a gRPC subscription powered by Shredstream and filtered to include only the DEX programs that you trade, together with a gRPC subscription from Yellowstone for account state, and also a WebSocket fallback.
Indexer: a background process which keeps the token metadata, authorities, and holder distributions in memory, fed by the same streams.
Hot path: there is one single-threaded event loop in each region which carries out the decoding, filtering, sizing, building, signing, and submission. If your language permits it, there should be no allocations on the hot path; Rust is the most commonly used language and Go can be used as well.
Submission: in each region there is a staked write path together with leader schedule tracking so that the appropriate region can be selected for each event.
Post-trade: this is a distinct process which keeps an eye on the position, handles the exits, and records the result for later analysis.

The fundamental rule concerning design is that nothing on the hot path should wait for a network request; all the data it needs must have been included with the event or should have been cached previously.

Measuring whether your bot is actually fast

Statements about latency without actual measurement are just guesses. To obtain accurate figures, record three timestamps for each event: the time at which the event was observed, the time when the transaction was submitted, and the slot in which it landed. Then track:

Observe-to-submit time. This is your own code. You should achieve sub-millisecond performance with a well-built bot.
Submit-to-landing slot delta. The difference between the slot you submitted in and the slot the transaction actually landed in. This is your infrastructure. A zero indicates that you landed in the slot you had aimed for.
Landing rate during launches. The proportion of submitted transactions that landed at all within the 60 seconds surrounding a launch.
Fill quality. The executed price compared to the price at the time of observation. This figure shows whether being fast actually translated into being early.

If you look at the results for different regions and for different write paths, you will usually find that one region is early for a subset of the leaders but late for the others; this is the kind of data that you need in order to justify a multi-region deployment.

Common mistakes

Using a public or shared RPC for the hot path. It is unreliable precisely when it is needed due to rate limits and the shared capacity. A dedicated node or a plan with reserved capacity should be the standard choice.
Filtering after submitting. Bots end up with frozen tokens because they buy first and then check.
One region. The leader schedule is global and a single-region bot is late for most of it.
Ignoring Token-2022 extensions. Transfer hooks and fees are valid features and can also be very effective as traps. Skip any tokens with extensions that you do not explicitly understand.
Fixed priority fees. The fee applicable at the time of a launch can be many times higher than the quiet-hour fee. This should be estimated dynamically.
No exit plan. Paper gains turn into real losses when you get in quickly without having a strategy for getting out.

Conclusion

A Solana sniper bot is essentially a race based on latency that also involves a safety issue; in order to win the observation phase you need to use either shred-level or gRPC streaming, keep the decode and decision phases in memory, and then carry out the transaction via a staked, region-aware write path. You should measure the time taken from observation to submission, from submission to landing, and the fill quality, and let these figures guide all of your infrastructure decisions.

If you wish to make the transition from a working bot to an early one, the Jetstream gRPC service provides you with the event stream derived from shreds, and the RPC plans include the staked write path as well, and both are available in the regions where the leaders are.

Resources

Solana Commitment Levels Explained: Processed, Confirmed and Finalized

OrbitFlare RPC — Mon, 07 Sep 2026 21:36:55 +0000

When you build on Solana, you may encounter the terms processed, confirmed and finalized. These are what are known as the commitment levels.

Key Takeaways

There is no single right choice when it comes to deciding which commitment level to use. Each situation is different, but there is usually a wrong choice for a given job.

If you see unexpected behaviour such as transactions that are present one moment and gone the next, you may be using inconsistent commitment levels.

processed refers to the node having executed the block that contains the transaction. It is the fastest option but the block may still be skipped over by the cluster.

confirmed means that more than two thirds of the stake voted on the block. Rollback is highly unlikely.

finalized means the block has reached maximum lockout and cannot be rolled back.

What are commitment levels?

Commitment levels define how certain you can be that the state has become permanent. A commitment level is a way for us to communicate the degree of certainty that the transaction or the block will remain in the ledger.

Solana creates a block for every slot. This is currently 350ms on mainnet since the decrease from 400ms in August 2026.

When blocks are produced, they are only provisional, as the next leader(s) might choose to build on a different fork. Once more than two thirds of the stake has voted on that block during subsequent slots, the block becomes confirmed. Solana uses a consensus mechanism currently known as Tower BFT, where blocks become more solidified as further votes come in. Eventually, a block is finalized when it has reached maximum lockout and cannot be undone. This usually happens around 32 slots after the block was confirmed. At the current slot time that is somewhere between 11 and 13 seconds.

There is a consensus upgrade known as Alpenglow, which is designed to improve the finality time to around 150ms. The current release plan by Anza suggests it might be enabled on mainnet as soon as 28 September 2026, although Anza's schedules are tentative. Once that happens, the commitment levels will still apply, but the waiting time for finalized should be much shorter than it is today.

The three levels

Level	Meaning	Typical delay	Can it roll back?
`processed`	The queried node has executed the block	Immediate	Yes, if the block is skipped
`confirmed`	More than two thirds of stake has voted on the block	Usually a few slots, so around a second or less	Practically never
`finalized`	The block has reached maximum lockout (the node treats it as rooted)	About 32 slots after confirmed, so roughly 11 to 13 seconds depending on slot time	No

It is worth noting that if you do not pass a commitment level, the RPC will use finalized by default. This is the safest option, but it is also the slowest. Many applications are waiting longer than they need to because of this default, without having made a decision about it.

Where commitment levels come up

As you use the RPC endpoints, you can see there are a few places where commitment levels come up.

Data requests

When you make reads, for example with getAccountInfo, getBalance or getTokenAccountBalance, you can pass in the commitment level. The same account may return a different value at each of the three levels. Each value is correct for its level. Similarly, when you subscribe to data, you can specify the commitment level. This applies to WebSocket subscriptions such as accountSubscribe and logsSubscribe, and to Yellowstone gRPC. A subscription at processed will give you events earliest, but some of those events may belong to a block that is later skipped.

Sending transactions

When using the sendTransaction method, you should keep the commitment level consistent within the flow. There is a preflightCommitment parameter which decides which state the simulation runs against. Solana's documentation says that this should always be the same commitment level that you used when fetching the blockhash. This applies to simulateTransaction as well. You might also be concerned about a particular piece of data changing between when you build the transaction and submit it. Reading that data at the same commitment level as the preflight helps to avoid this.

Fetching a blockhash

You can pass a commitment level to getLatestBlockhash as well. This matters more than you might expect. A blockhash is only valid for around 151 blocks, which is roughly 60 to 90 seconds. If you fetch the blockhash at finalized, it is already around 32 slots old when you receive it. This means you lose around 11 to 13 seconds of the time in which it is valid. For this reason, it is generally recommended to fetch the blockhash at confirmed.

Checking a transaction

When you check on a transaction, for example using signatureSubscribe or getSignatureStatuses, the response will tell you which commitment level the transaction has reached. A transaction that has landed at processed is not the same as a transaction that has landed at confirmed. It may still be skipped.

Which commitment level should I use?

Situation	Use	Why
Displaying a balance in a wallet	`confirmed`	Fresh enough, will not flicker back
Deciding to release goods, credit an account, or settle	`finalized`	Irreversible actions need irreversible state
A trading bot reacting to a price move	`processed` (with rollback handling) or a shred-level feed	Earliest signal, and the bot tolerates reverts
Fetching a blockhash to sign	`confirmed`	Fresh and safe
Waiting for your own transaction before the next step	`confirmed`, and `finalized` for the last step of a payment	Balance speed against certainty per step
An indexer	`confirmed`	Avoids having to implement rollback logic

The trading bot case is a little different from the others. There is a way to observe Solana that is earlier than any of the commitment levels. This is the shred broadcast from the leader, which happens before any node has processed the block. We have written about this in our shredstream article. Trading systems that need the earliest possible signal may use this, but they need to be able to handle the fact that some of the blocks they see will be skipped later on.

Common mistakes

Most of the problems people run into come from using different commitment levels in the same flow. Some examples are below.

The first is a balance that appears to change back. This can happen when one call is made at processed and another at finalized. The user sees one balance, then a different one. The solution is to make both calls at the same commitment level.

The second is a transaction that appears and then disappears. This happens when a transaction is seen at processed, the application acts on it, and then the block is skipped. It is safer to act on transactions at confirmed or later.

The third is an expired blockhash. This can happen when the blockhash was fetched at finalized. As explained above, the blockhash is older at this level, so it may expire before the transaction lands. Fetching at confirmed avoids this.

The fourth is a mismatch in preflight. This happens when the transaction is simulated against state that is different from the state it actually executes against, or when the preflight commitment does not match the blockhash commitment. Both should be aligned.

The fifth is an event that is later reverted. This can happen when a subscription at processed delivers an event, the application writes it to a database, and the block is then skipped. You may want to subscribe at confirmed instead, or implement rollback handling in the application.

Keeping it consistent

It is a good idea to decide on a commitment level for each part of your system and pass it explicitly. Relying on library defaults is not recommended, because the defaults vary between libraries and are often finalized. A common approach is to use confirmed for reads, finalized for settlement, and processed (or shreds) with rollback handling for anything that needs to be fast. It is also helpful to record the commitment level alongside each result, so that if two values disagree you can see why.

The commitment level is passed in the same way whether you are using JSON-RPC or Yellowstone gRPC, so the same considerations apply on the streaming side.

Conclusion

Commitment levels are how you choose between speed and certainty on Solana. processed is the fastest option but it is provisional. confirmed is the sensible default for most cases. finalized should be used for anything that cannot be undone. Set the level explicitly, keep it consistent within each flow, and remember that if you need to react faster than any commitment level allows, the leader's own broadcast is available before any node has processed the block.

OrbitFlare's RPC plans support every commitment level on every endpoint. The gRPC service streams at the commitment level of your choice, and Jetstream provides the view from before any commitment level exists.

Resources

Network Infrastructure for Low-Latency Solana Trading

OrbitFlare RPC — Mon, 07 Sep 2026 20:39:44 +0000

Why Solana Latency Is Different

We've watched teams overinvest in every part of the stack regardless of whether they actually need each piece.

This is a problem because low latency trading infrastructure on Solana is different and it has more moving parts than what you might be used to. This guide will focus on infrastructure decisions that are specific to Solana's architecture, and how the architecture determines your infrastructure choices. It is meant for traders, bot developers, and infrastructure engineers building systems for trading or bots. We'll focus specifically on end-to-end latency on Solana (from seeing an on-chain event, to getting a transaction into a block). If you are building a wallet or an analytics product, a lot of this will be more than you need, but the first two layers will still save you money.

There are four main layers that we'll cover: placement, observation, submission and routing. The first two are the most applicable for any Solana users. The latter two are applicable for more sophisticated trading bots, and can be deferred as needs arise.

Placement: refers to the geographic proximity of your servers to Solana's validator network.
Observation: how you observe the chain, from raw shreds, via the gRPC API, WebSockets or polling.
Submission: how you submit transactions (with staked TX lanes, via the bundle API or otherwise)
Routing: determining the optimal region to send transactions to. This is because Solana's current architecture means that the leader (the node that produces blocks) changes every 4 slots, which is approximately 1.4s at the current slot time.

A quick note on the numbers in this article. Solana's mainnet slot time was 400ms for most of the network's life, but it was reduced to 350ms on 21 August 2026 (epoch 1020) as the first stage of SIMD-0525. Further reductions to 300ms, 250ms and eventually 200ms are planned, each behind its own feature gate, and testnet is already on the 250ms to 200ms stage. So a leader window today is 4 x 350ms = 1.4s. We've used the 350ms figure throughout. If you are reading this after another reduction has been activated, just adjust the arithmetic. More on this at the reduced slot times page.

Key Takeaways

Latency on Solana is relative to the leader, and the leader changes every four slots (about 1.4 seconds at 350ms slots). Whatever is fast in one region will be slow for most of the schedule.
Reads are more important than writes. Seeing an event earlier makes every decision after it better. A faster submission path only helps once you've already decided.
Raw shreds are the earliest point where you can observe the chain. Anything that works off processed blocks is at least one processing step behind.
Unstaked connections are the first to be dropped during congestion. A staked (prioritized) write path is what keeps your transactions flowing in the exact conditions you built the system for.
Build for the worst hour, not the average hour. Average numbers don't tell you anything about what happens during a token launch.
Alpenglow is expected to bring finality down to around 150ms (sometimes 100ms). It doesn't remove the geographic component of latency, so placement and routing still matter after it ships.

Layer One: Placement

Placement is the most fundamental aspect of trading infrastructure on Solana. The next three layers are important but they can only go so far to improve the latency if your servers are far from the leader.

Solana's design has three properties that impact your placement.

Validators are spread globally, and the leader schedule walks through them in proportion to the stake they control. So the more stake there is in a region, the more often the leader is in that region. As of 2026 Europe is the largest cluster by a wide margin and Frankfurt in particular is the single biggest concentration of stake.
Blocks are produced by a leader who changes every 4 slots (approximately 1.4s), and the schedule is deterministic. The leader schedule for an epoch is calculated from the ledger state at the start of the previous epoch, so it is known ahead of time. An epoch is 432,000 slots, which at 350ms per slot works out to roughly 42 hours.
While producing a block, the leader splits it up into messages called shreds (erasure coding means that there are extra coding shreds, so any given section of a block can be recovered if some of the data shreds go missing), and broadcasts them via its peer-to-peer network, Turbine, while the block is still being built. Nodes then have to recombine the shreds and replay the transactions to reconstruct the block.

Turbine is a multi-layered tree structure, with a fanout of 200 in each layer, and propagation moves from the root to the leaves. The process is documented in the Turbine docs.

For any given block, a user that is observing raw shreds will observe the block much faster than users via RPC. RPCs will report blocks at processed commitment (which requires replaying the block on the node itself) which introduces another hundreds of milliseconds or potentially an entire slot of latency on top of however long the shreds took to arrive.

These three properties mean that you can expect to see a pattern of fast and slow time, where you will be very fast when the leader is close by, but slower during the rest of the schedule. A tradeoff can be made between costs and this fast/slow time, depending on your strategy.

Some options for placement, in approximate increasing order of cost and complexity:

Have a server in a single region. Ideally this would be where a lot of stake is (e.g. Frankfurt, Amsterdam, the US east coast). This would mean that your system is slow for a good part of the schedule, but the cost is much lower. If you are using unstaked routes, it would also mean your transactions are dropped first during congestion (which is why we recommend at least one staked connection).
Have servers in multiple regions. This is the preferred option for latency-sensitive trading systems. By spreading servers closer to each of the leaders, and submitting from whichever one is closest to the current leader, you can minimize the impact of a leader being far away, and the cost is still reasonable given the value. Europe plus one US region covers most of the schedule in practice. This is the part of the infrastructure that is the least obvious on how to build, but also the most important for overall latency. It may not be obvious where to put servers initially, but we've seen where a lot of stake is concentrated, and can advise on it. We also publish per-region pages like Solana RPC in Frankfurt and Solana RPC in New York so you can see where the infrastructure actually is.
Run your own node next to your bot (colocation). This means a Solana node on the same host or in the same rack as your strategy, near stake, so you remove a network hop on both the read and the write side. It is the fastest option and also the most expensive, since a healthy node needs fast NVMe, 100+ Mbps of Turbine traffic, and somebody on call when it breaks.

Some other important points:

Reads are more important than writes because being able to see data faster gives you a more substantial edge. It helps you make all other decisions faster (including transaction submission). The best trading strategies have to do with acting faster than other people, so this matters.
Network latency between continents is a real bottleneck. The current minimum round-trip time between the US east coast and Europe is approximately 70-90 milliseconds over good fiber, and this is impossible to build around. This is why it's so important to have servers in each region.
Alpenglow, the next major Solana upgrade, is expected to have much lower finality times (around 150ms median, sometimes 100ms). It won't remove the geographic component of latency or obviate the importance of placement and routing.
The network isn't always under maximum capacity. It is important to build a system that is optimized for times of high congestion because many strategies will make money during that time, and congestion is worst during periods of token launches. You can't build your infrastructure to handle average usage per hour. The system has to be able to hold up during times of launch.

Layer Two: Observing the Chain

There are five different points at which you can observe the chain. They are listed here from earliest to latest. Each of them is the right choice for some use case. The expensive mistake is using one of the later ones for a strategy that is sensitive to latency, and then trying to make up the difference in code.

Observation point	What you see	Relative timing	Fits
Raw shreds	Block fragments as the leader broadcasts them	Earliest	Sniping, liquidations, anything reacting to a single event
Shred-derived gRPC	Transactions reconstructed from shreds and decoded	Near earliest	Copy trading, sniping with less client complexity
Geyser gRPC (Yellowstone)	Account and transaction updates as the node processes the block	After processing	Market making, indexing, state tracking
WebSocket subscriptions	Notifications after the node processes and commits	Later	Dashboards, alerts, non-critical bots
RPC polling	Whatever you ask for, when you ask	Latest	Research, reconciliation

The difference between raw shreds and Geyser gRPC is the block processing time on the node. In most setups this is the largest delay that can actually be avoided. We have written about this in more detail in our shredstream article.

Some things to know before choosing:

Shred data is raw. A full shred stream is somewhere in the range of 50-100 Mbps of UDP traffic, and to turn it into transactions you need to do deshredding, Reed-Solomon recovery, and deserialization. This has to happen somewhere, either in your own code or in a service. In our experience it is the biggest single leverage point in the whole stack, and it's what Jetstream gRPC is for: transactions reconstructed from shreds sourced at the top of Turbine, delivered over a normal gRPC stream, with the deshredding done on our side.
Match the level of detail to the decision. Shred-level streams are faster partly because they leave out inner instructions and full metadata. Yellowstone gives you all of that (inner instructions, account updates and so on) but it arrives one processing step later. Most serious systems use both. The shred-level feed is the hot path that tells you something happened, and Yellowstone is the structured source of truth that you check before acting on state.
Commitment levels are a choice, not a default. If your logic waits for "confirmed" or "finalized", you are waiting hundreds of milliseconds to whole seconds longer than "processed". Sometimes that fork protection is what you want. It should just be a decision you made and not something you inherited from a code sample.

Layer Three: Submitting Transactions

Seeing an event early is not much use if your transaction doesn't land. During congestion the leader's transaction processing unit (TPU) is saturated, and Solana decides whose connections get served first based on stake. This is the stake-weighted QoS mechanism, which gives stake-weighted priority to 80% of the leader's TPU capacity. There are four ways to get a transaction in, and our comparison covers them in more depth. In short:

Plain RPC forwarding. The node forwards your transaction to the leader over an unstaked connection. This is fine when the network is quiet and is the first thing to be dropped when it isn't.
Stake-weighted QoS lane. Your transaction goes over a staked connection and is served before unstaked traffic. This should be the default for anything high volume.
Jito bundles. A group of up to 5 transactions that execute sequentially and atomically at the top of a Jito-enabled leader's block. Bundles compete with each other on tips. If any transaction in the bundle fails, none of them are committed. This is the tool for multi-leg strategies and for bidding on priority explicitly. See Jito's docs for the details.
Direct TPU forwarding. Your own forwarder speaks QUIC directly to the leader's TPU. This is the fastest option when you are colocated and staked, and unreliable when you are not.

Priority fees and tips sit above all four of these. A transaction paying the base fee on the best connection will still lose to a worse connection that pays more. Fees are bids in an auction, and it is a mistake to treat them as a cost to be minimized.

The rule we give people is: bundles when you need atomicity, the staked lane for everything else, and direct forwarding only if you are colocated and staked. If you'd rather not build this layer yourself, there are landing services for it. OrbitFlare's Apex, for example, combines Shredstream-routed submission, Jito bundle support, and stake-weighted QoS behind one endpoint, with per-transaction analytics so you can see the landing rate.

Layer Four: Routing Between Regions

Once you have servers in more than one region and you have the leader schedule, the router has one job per transaction, which is to decide which region sends it. It needs three inputs:

The current slot and the upcoming leaders. These come from the deterministic schedule via getLeaderSchedule.
A mapping from validator identity to datacenter region. This has to be built by parsing gossip continuously, because validators move and the mapping goes stale.
The latency from each of your regions to each leader region. This should be measured with your own probes and not taken from a published ping table (those are someone else's numbers from someone else's rack).

The output is something like "submit from region X, and also from region Y if the next leader is there". You cover the slot boundary by targeting the current leader and the next one, and then you stop. Resending from every region for seconds at a time is how bots burn through rate limits, get dropped as duplicates, and land in the wrong slots. It is the most common routing mistake we see, and usually it's someone's idea of being safe.

Routing helps on the read side as well. A feed in Frankfurt sees Frankfurt blocks first, so a strategy that reacts to events globally should consume feeds from several regions and deduplicate by signature. The same shred data arriving twice is redundancy, not two events.

What Alpenglow Changes, and What It Doesn't

Alpenglow is Solana's consensus overhaul and no infrastructure guide written in 2026 can really skip it. The governance vote (SIMD-0326) passed in early September 2025 with 98.27% of the participating stake voting yes. Community validator testing started in May 2026. Anza's Agave v4.3 release schedule has mainnet feature activation targeted for 28 September 2026, with the usual caveat that Anza's schedules are tentative. Two pieces of it matter for this article.

Votor replaces Tower BFT voting. Votes move off chain into lightweight aggregated certificates, and finality drops from about 12.8 seconds to around 150ms median (sometimes as fast as 100ms). Vote transactions also stop taking up block space.

Rotor replaces Turbine's multi-hop tree with a single-hop, stake-weighted relay broadcast. Blocks are still erasure-coded into shreds. In the whitepaper's numbers, with 1 Gb/s of bandwidth, transmitting 1,500 shreds takes about 18ms.

The Alpenglow whitepaper has the full detail. For your infrastructure the effects are fairly specific:

The read side stays shred-first. Rotor still uses shreds, so the earliest observation point is still the propagation layer and not the processed block. Faster propagation actually makes the node's processing gap a bigger share of the total delay, not smaller.
Geography still matters. In Anza's simulations the consensus overhead is roughly a 2x multiplier on the raw network latency, so finality is bounded by how far the leader is from the stake supermajority. A leader in New York with most of the stake in Europe is still looking at something like 200ms. Placement and leader-aware routing don't change.
Congestion moves, it doesn't go away. Freed-up vote capacity adds throughput headroom, and demand has always grown to fill block space. Keep the prioritized write path.
Block production gets more regular. Alpenglow drops Proof of History timing in favor of fixed slot timeouts, which should make your latency measurements more repeatable.

Plan for Alpenglow as the current model getting faster and not as a replacement for it.

Ultra-Low Latency: What Separates the Top Tier

Everything above gives you a fast stack. The tier where trading firms compete with each other adds three more decisions.

VPS or bare metal. A Solana VPS near stake is the right starting point (cheap, deployed in minutes, milliseconds from the regional leader). The problem is that virtualized neighbors burn your CPU and add jitter that an average ping never shows. The top tier moves to bare metal or trader nodes, meaning a machine that runs only your strategy, because at that level tail consistency matters more than average speed.
Temporal submission. Default routing targets the current leader. Because the schedule is deterministic you can instead send to the next leader while it is still building its block, and land at the start of its window rather than the end of the previous one. This is a legitimate use of public information and it is how the fastest bots make the 1.4 second rotation work for them instead of against them.
Proximity to the block engine, not just the validators. For bundle strategies, distance to the Jito block engine relays matters as much as distance to the leaders. Colocating your submission in a region with block engine presence removes one more hop from the write path that is most sensitive to latency.

The principle at this tier does not change. Each upgrade should remove one identifiable stage from the loop, and if you can't say which milliseconds an upgrade removes, you are buying marketing and not speed.

Putting the Layers Together

Strategy	Placement	Read path	Write path	Routing
New-pool sniping	Multi-region near stake, or colocated	Shred-derived gRPC	Staked lane, or bundle with edge-based tip	Leader-aware
Copy trading	Multi-region	Shred-derived gRPC with wallet filters	Staked lane	Leader-aware
Atomic arbitrage	Colocated near block engine and stake	Raw shreds plus Yellowstone for pool state	Jito bundles	Nearest block engine
Market making	Single or dual region	Yellowstone gRPC	Staked lane	Leader-aware for cancels
Liquidations	Multi-region	Shred-derived for oracle updates	Jito bundles	Leader-aware
Wallet or payments app	Single region	WebSockets	Staked lane or reliable RPC with retries	Not needed

The pattern is the same in every row. The read path depends on how early you need to see events. The write path depends on whether you need atomicity. The placement depends on how much of the leader schedule you need to be fast for.

Where the Milliseconds Go

If you walk through one loop from event to landing, the optimization targets pick themselves.

The leader builds the block and broadcasts shreds. This is fixed by the protocol, there is nothing to optimize.
Shreds reach a node. This is network distance to the leader, so it's a placement problem.
The node processes the block and exposes it. You skip this entirely if shreds are your event source. Otherwise you pay the node's processing time. This is your read path choice.
Your feed delivers events to your process. Local network plus serialization. Minimal if you are colocated.
Decode, decide, build, sign. This is your own code, and it should be under a millisecond.
Your transaction reaches the leader. Network distance plus TPU queuing. Placement and write path.
The leader includes it. Priority fee, stake, or tip. Write path.

Stages two, three and six dominate, and all three are infrastructure decisions. Stage five is the one that everybody over-optimizes.

How to Benchmark Before You Buy

Vendor numbers are measured from the vendor's rack to their nearest leader. You should measure from wherever your bot is actually going to run. The fastest RPC for trading is not the one with the best number on a landing page, it is the one that wins these four measurements from your own servers.

Observation lag. Timestamp the same transaction on each feed (shred-derived, Yellowstone, WebSocket) and take the spread. That spread is the value of the earlier feed, in your region, on your traffic.
Landing rate by leader region. Send a cheap transaction through each write path every few seconds for a week. Record the slot it landed in relative to the slot you sent it in, and bucket the results by the leader's region. Then look at the worst hours (token launches, liquidation cascades) and not the averages.
Fill quality. For a live strategy, this is the executed price against the price at the time you observed the event. It is the only number that proves the stack is actually early.
Feed continuity. Count gaps and reconnects per day on each feed. A feed that is 5ms faster but drops twice a day during launches is slower in expectation.

Our benchmarks page is built on exactly this methodology. It is run from multiple regions against the live leader schedule, so the numbers can be reproduced and don't have to be taken on faith.

Common Mistakes

Optimizing code before infrastructure. A sub-millisecond decoder behind a feed that is 300ms late is a fast bot that is always late.
One region. You are fast for a minority of the schedule and slow for the rest.
An unstaked write path in production. It works in testing and then fails during exactly the launches you built the bot for.
Resending forever. This burns rate limits, causes late landings, and makes your own metrics lie to you.
A zero priority fee on a fast path. Connection quality and fees multiply. If either one is zero you still lose the auction.
Measuring averages. The average hides the congested hours, and that is where the edge is. Measure the tail.
Not reconciling. Without the observed slot, submit time and landed slot for each transaction, you can't tell which layer went slow.

FAQ

What does low-latency network infrastructure for Solana trading look like?

Servers placed near stake concentrations, a data feed that is as early as possible (ideally shred-level), a prioritized submission path, and routing that follows the rotating leader schedule. The whole point is to shrink the loop from an on-chain event to your responding transaction landing in a block.

How many regions do I need to trade on Solana?

One region near stake (Frankfurt, Amsterdam, or the US east coast) is a sensible start. Two or three regions covering Europe and North America will handle most of the leader schedule. Beyond that the returns diminish quickly once the stake-heavy regions are covered.

Are shreds faster than gRPC?

Yes. Shreds stream while the leader is still building the block. Yellowstone gRPC delivers after the node has processed the block, which adds the processing time on top. Shred-based gRPC services reconstruct transactions from shreds and keep almost all of that lead, and you don't have to do the deshredding yourself.

Should I use Jito bundles?

Only if you need atomicity (several transactions that must land together, as in multi-leg arbitrage) or you want to bid for priority explicitly through tips. For everything else a single transaction on a staked lane is the better trade.

Will Alpenglow make low-latency infrastructure obsolete?

No. Finality drops to around 150ms and Rotor speeds up propagation, but both are still bounded by the physical network latency between leaders and stake. Shreds stay the earliest observation point, and placement near stake still decides who sees and lands first.

What should I measure before choosing an RPC provider?

Observation lag between feed types, landing rate bucketed by leader region during congested hours, fill quality against the price at observation, and feed continuity. Measure from your own servers for at least a week and weight the worst hours, because averages hide exactly the conditions you are building for.

Does any of this change for AI trading agents?

No. An agent in the trading loop runs the same event-to-landing loop as a rule-based bot: listen on a feed, decide, submit. The only difference is that the decision step takes longer, which makes the milliseconds saved everywhere else more valuable, not less.

Four Decisions

Where do you sit relative to a leader that moves every four slots? How early do you observe the chain? How does your transaction get into a saturated leader? And which region submits as the schedule rotates? Whether you are a solo bot operator or a firm evaluating providers, the framework is the same. Place near stake in more than one region. Read the hot path from shreds or a shred-derived stream. Write through a staked lane, or bundles when you need atomicity. Route by the schedule. Then measure observation lag, landing rate in the worst hour, and fill quality, and let the data decide the next upgrade. Alpenglow will make all of this faster. It won't make any of it optional.

The OrbitFlare stack maps onto the four layers directly: Shredstream and Jetstream gRPC on the read side, staked transaction landing in the RPC plans on the write side, and eleven regions to route across. Start with the measurements, and the rest follows from the data.

OrbitFlare builds Solana infrastructure for teams that need speed: RPC nodes, Jetstream gRPC streaming, trading APIs, and Shredstream. Get in touch if you want help designing your stack.

Resources

Solana documentation on Turbine
Alpenglow: a new consensus for Solana (Anza)
Reduced slot times (SIMD-0525)
Agave v4.3 release schedule (Anza)
What is Shredstream?
How to land transactions on Solana
Stake-weighted QoS guide
Jito bundle documentation
Jetstream V2 docs
OrbitFlare benchmarks

The OrbitFlare SDK Comes to Go: Building a Slot Radar

OrbitFlare RPC — Mon, 03 Aug 2026 14:25:12 +0000

The OrbitFlare SDK now speaks Go. It's the third language after Rust and TypeScript, and it ships the same surface as both: RPC, WebSocket, Yellowstone gRPC, and Jetstream clients, each in its own package, with the same builder pattern and the same connection plumbing handled for you. If you've used either of the other SDKs, you already know this one.

go get github.com/orbitflare/orbitflare-sdk-go

To show it off, we wanted to build something small that no other post on this blog has built. Every tutorial we've written so far watches transactions: a wallet ticker, a TPS meter, an indexer, a trade tracker. Nobody has watched the thing underneath all of them. Slots.

A slot is the network's heartbeat. Every 400 milliseconds or so, some validator has the leader role, produces a block, and hands off. Sometimes a leader fails to produce and the slot is skipped. Your transactions land inside this rhythm, and if you send them, the rhythm decides your fate: who the current leader is, how far away the next one is, and whether slots are completing cleanly or dying.

Jetstream v2 has a stream for exactly this, and the Go SDK ships it. SubscribeSlots emits an event when a slot goes ALIVE (first shred received), COMPLETE (last shred received), or DEAD (skipped or superseded). So the demo picked itself: a slot radar. One terminal screen showing the current slot and leader, the measured slot time, who's up next, and every skipped slot as it happens. Around 180 lines of Go, using two clients from the SDK.

slot radar · epoch 1011

  slot 436945880 · leader Fd7b…69Nk
  measured slot time: 443ms avg over last 30

  next up:
    slot 436945884  Awes…vpLM  (in 4 slots, ~1.6s)
    slot 436945888  GYx8…3YGQ  (in 8 slots, ~3.2s)
    slot 436945892  EdFU…sk6w  (in 12 slots, ~4.8s)
    slot 436945896  5pPR…HzSm  (in 16 slots, ~6.4s)

  last 60 slots: ✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗✗✓✓✓✓✓✓✓●
  skipped this session: 4  (latest: 436945871)

The Clients

Two builders, one per client.

rpcClient, err := rpc.NewBuilder().
    URL("http://ams.rpc.orbitflare.com").
    APIKey(os.Getenv("ORBITFLARE_LICENSE_KEY")).
    Build()

jet, err := jetstreamv2.NewBuilder().
    URL("http://ams.jetstream.orbitflare.com").
    Build()

Every client accepts multiple URLs if you want failover, and the first one is the primary. That's the whole setup.

The Schedule

The slot stream tells us what's happening right now, but "who leads next" lives in the leader schedule, which is an RPC question. Two calls give us the schedule:

raw, _ := rpcClient.Request(ctx, "getEpochInfo", []any{})
var epoch struct {
    Epoch        uint64 `json:"epoch"`
    AbsoluteSlot uint64 `json:"absoluteSlot"`
    SlotIndex    uint64 `json:"slotIndex"`
}
json.Unmarshal(raw, &epoch)
epochStart := epoch.AbsoluteSlot - epoch.SlotIndex

raw, _ = rpcClient.Request(ctx, "getLeaderSchedule", []any{nil})
var schedule map[string][]uint64
json.Unmarshal(raw, &schedule)

leaderBySlot := make(map[uint64]string, 432_000)
for leader, idxs := range schedule {
    for _, i := range idxs {
        leaderBySlot[epochStart+i] = leader
    }
}

There's one small trap here, and it's the reason for the getEpochInfo call. The schedule comes back keyed by validator identity with slot indexes relative to the epoch start, not absolute slot numbers. Subtracting slotIndex from absoluteSlot gives you the epoch's first absolute slot, and adding that to each index turns the whole schedule into a flat slot → leader map.

The Slot Stream

Now the live side. SubscribeSlots returns a stream, and a goroutine drains it into a channel:

slots := jet.SubscribeSlots()
defer slots.Close()

events := make(chan *pb.SlotEvent, 1024)
go func() {
    for {
        ev, err := slots.Next(ctx)
        if err != nil {
            log.Fatal(err)
        }
        events <- ev
    }
}()

The main loop is one select over two channels: slot events mutate state, and a 500ms ticker redraws the screen. This is the whole engine of the program:

for {
    select {
    case ev := <-events:
        s := ev.GetSlot()
        status[s] = ev.GetStatus()
        if s > maxSlot {
            maxSlot = s
        }
        if ev.GetStatus() == pb.SlotStatus_SLOT_STATUS_ALIVE {
            if s == lastSlot+1 && !lastAlive.IsZero() {
                timings = append(timings, time.Since(lastAlive))
            }
            lastSlot, lastAlive = s, time.Now()
        }
        if ev.GetStatus() == pb.SlotStatus_SLOT_STATUS_DEAD {
            skipped = append(skipped, s)
        }
    case <-ticker.C:
        render(status, leaderBySlot, maxSlot, timings, skipped, epoch.Epoch)
    }
}

Solana's 400ms slot time is a target, not a promise, and the honest way to measure the real one is the gap between consecutive ALIVE events, since ALIVE fires when the first shred of a slot reaches the network. Averaging the last 30 gaps gives you the network's actual current pace, measured from your own connection. Our run above says 443ms.

The Render

The render function walks state and prints. The next-up list scans forward from the current slot and collects the next four distinct leaders:

printed, cur := 0, leaderBySlot[maxSlot]
for s := maxSlot + 1; printed < 4 && s < maxSlot+400; s++ {
    if l := leaderBySlot[s]; l != "" && l != cur {
        fmt.Printf("    slot %d  %s  (in %d slots, ~%.1fs)\n",
            s, short(l), s-maxSlot, float64(s-maxSlot)*0.4)
        printed++
        cur = l
    }
}

and the tape, which maps the last 60 slots to one glyph each: ✓ for complete, ● for alive, ✗ for dead, and · for slots we haven't heard about. A skipped slot shows up as a ✗ in the tape the moment the network gives up on it.

Running It

git clone https://github.com/orbitflare/slot-radar.git
cd slot-radar
ORBITFLARE_LICENSE_KEY=ORBIT-... go run .

The schedule loads in a couple of seconds, the first slot event lands right after, and from there the radar just ticks. Leaders hand off every four slots, the measured slot time drifts between roughly 390 and 430 milliseconds depending on the day, and every few minutes a ✗ appears when a leader misses its window.

What the SDK Did

The program never mentions reconnection, and that's the point. If the Jetstream connection drops, the stream re-establishes and keeps delivering. If the primary endpoint misbehaves and you gave the builder fallback URLs, the client rotates through them and brings the primary back when it recovers. Keepalives, retry backoff, and API key redaction in error output all come along without a line of your code, and they behave identically to the Rust and TypeScript SDKs, because the three are kept in lockstep.

What's left in the source is the part that's actually yours: two RPC calls, one subscription, and a select loop. That's the trade the SDK offers in every language now, including Go.

Resources

Full source: github.com/orbitflare/slot-radar
orbitflare-sdk-go on GitHub | pkg.go.dev reference
Go SDK docs
Jetstream v2 docs

If you build something with the Go SDK, or hit an edge that should be smoother, come tell us on Discord. We'd love to see what you ship.

DEV Community: OrbitFlare RPC

Solana RPC for AI Agents: MCP, Tools and Guardrails

What an AI agent needs from Solana infrastructure

MCP: the standard interface

Guardrails that belong to the tool layer

Latency: slower than a bot, but not optional

Cost: agents are very chatty

A reference setup

Conclusion

Resources

Solana WebSockets vs gRPC: When to Switch and How

Operational mechanisms

Comparative overview

Use cases for WebSockets

Use cases for gRPC

Migration from WebSockets to gRPC

Common mistakes

Cost aspects

Conclusion

Resources

getProgramAccounts Alternatives: Stop Scanning, Start Streaming

Description of the method and the source of the cost

Use cases in which the method remains a good choice

Alternative 1: subscribe to the accounts with Yellowstone gRPC

Alternative 2: build an indexer and query your own storage

Alternative 3: getMultipleAccounts for known addresses

Alternative 4: provider-side indexes

Decision framework by the question

If the continuous usage of the method is still needed

Conclusion

Resources

Copy Trading Architecture: Centralized vs Decentralized

What's the real architectural difference between centralized and decentralized copy trading?

How does a decentralized copy trading platform's architecture actually work?

How do you actually build a copy trading platform on blockchain?

What does the future of decentralized copy trading look like?

Frequently asked questions

Resources

Solana Devnet vs Mainnet vs Testnet: Which Cluster for What

The three clusters

Devnet: a development platform

Mainnet Beta: the home of the value

Testnet: generally not suitable for applications

Pointing wallets and code to a cluster

Practical differences

Common mistakes

Conclusion

Solana Archive Nodes and Historical Data: What Needs an Archive and How to Use It

Retention window

What is an archive tier

Which methods use the archive

Typical archive queries

Running your own archive

Using historical data efficiently

Conclusion

Agave 4.2: Transaction V1 Breaking Changes Checklist

Current status of each change

1. Require v1 on every call that returns transactions

2. Read the priority fee from the header

3. Stop assuming updates for every writable account

4. Add a new reward type

5. Update Token-2022 parsing

6. Stop using the hardcoded slot time

Versions to pin

If decoding transactions manually

Conclusion

Resources

Solana RPC Rate Limits: How They Work and How to Stop Hitting Them

How the limits work

Diagnosing which limit you hit

Cutting request volume

Designing for limits from the start

When you actually need a bigger plan

Conclusion

Resources

How to Build a Solana Sniper Bot: Detection, Filters and Execution

How does a Solana sniper bot actually work?

Detection: where the race is decided

Decoding the event correctly

Deciding: the filters that save you money

Alternative 3: `getMultipleAccounts` for known addresses