DEV Community: OrbitFlare RPC

Alpenglow: How Solana Swaps Its Consensus in One Slot

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

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

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

Why TowerBFT Has to Be Replaced

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

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

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

Votor: Two Voting Paths at Once

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

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

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

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

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

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

The 20+20 Model, Honestly

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

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

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

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

Rotor Is Not Shipping Yet

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

Votes Are Out of the Blockchain

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

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

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

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

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

The Migration: Switching Consensus Engines in One Slot

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

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

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

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

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

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

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

The Track Record

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

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

What Will Change for Developers

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

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

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

Things That Alpenglow Does Not Do

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

Implications for Building on OrbitFlare

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

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

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

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

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

The Short Version

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

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

Resources

Originally published at orbitflare.com.

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

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

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

Key Takeaways

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

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

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

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

What an indexer is for

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

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

Architecture

The live consumer

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

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

Backfill

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

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

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

Decoding

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

Three practices:

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

Writing idempotently

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

Two patterns:

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

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

Reconciliation

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

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

Infrastructure

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

Conclusion

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

OrbitFlare's gRPC service covers the live path, historical data the backfill, and dedicated nodes the volume.

Originally published at orbitflare.com.

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

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

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

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

Should you run one?

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

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

Hardware and location

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

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

The setup sequence

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

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

Daily operations

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

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

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

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

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

The economics

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

Failure modes

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

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

Conclusion

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

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

Resources

Solana RPC for AI Agents: MCP, Tools and Guardrails

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

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

What an AI agent needs from Solana infrastructure

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

MCP: the standard interface

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

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

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

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

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

Guardrails that belong to the tool layer

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

Latency: slower than a bot, but not optional

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

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

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

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

Cost: agents are very chatty

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

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

A reference setup

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

Conclusion

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

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

Resources

Solana WebSockets vs gRPC: When to Switch and How

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

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

Operational mechanisms

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

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

Comparative overview

Use cases for WebSockets

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

Use cases for gRPC

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

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

Migration from WebSockets to gRPC

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

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

Common mistakes

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

Cost aspects

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

Conclusion

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

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

Resources

getProgramAccounts Alternatives: Stop Scanning, Start Streaming

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

getProgramAccounts retrieves all accounts belonging to the given program with optional filtering in one request. It makes the method extremely costly, rate-limited and prone to throttling, making it the most expensive, rate-limited and throttled call in Solana RPC API. There are multiple options to use instead for anything else than a one-shot request: Geyser gRPC subscription streaming the accounts continuously, indexer pre-populated once for cheap querying, getMultipleAccounts if the addresses are known, or 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.

DEV Community: OrbitFlare RPC

Alpenglow: How Solana Swaps Its Consensus in One Slot

Why TowerBFT Has to Be Replaced

Votor: Two Voting Paths at Once

The 20+20 Model, Honestly

Rotor Is Not Shipping Yet

Votes Are Out of the Blockchain

The Migration: Switching Consensus Engines in One Slot

The Track Record

What Will Change for Developers

Things That Alpenglow Does Not Do

Implications for Building on OrbitFlare

The Short Version

Resources

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

What an indexer is for

Architecture

The live consumer

Backfill

Decoding

Writing idempotently

Reconciliation

Infrastructure

Conclusion

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

Should you run one?

Hardware and location

The setup sequence

Daily operations

The economics

Failure modes

Conclusion

Resources

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

Alternative 3: `getMultipleAccounts` for known addresses