DEV Community: OrbitFlare RPC

p-token: How Solana Rewrote Its Most Important Program

OrbitFlare RPC — Thu, 28 May 2026 17:24:06 +0000

TL;DR: The SPL Token program is the most-used piece of code on Solana. Nearly every non-vote transaction touches it, and it was quietly burning about 10% of every block's compute. So Anza rewrote it from scratch in a zero-dependency framework called Pinocchio and got a token transfer down from 4,645 compute units to 76. Then came the scary part: they swapped the new code in at the same address the old program lived at, behind a feature gate, at an epoch boundary, while billions of dollars sat in accounts that point to it. This is p-token (SIMD-0266). It's byte-for-byte compatible, so your client code didn't change a line. It went live on mainnet in spring 2026, and most people never noticed. That was the whole idea. Below: what happened under the hood, why a transfer got 60x cheaper, how you replace the most important program on a $100B+ network while it's running, and the one thing that did change for anyone reading token data off the chain.

There's a program on Solana that your code calls more than any other, whether you wrote that call or not. Every USDC transfer. Every swap leg. Every memecoin mint, every NFT that's really an SPL token, every "wrap SOL" in a Jupiter route. It's the SPL Token program. It lives at TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA, and for years it was one of the least efficient things on the network, for a simple reason: nobody thought about it. It just worked, so it never got touched.

Then someone added it up. Token instructions were eating roughly 10% of the compute units in every block. Not 10% of token-related blocks. 10% of all blockspace, everywhere, all the time, for a program whose job is mostly "subtract here, add there."

So Anza rewrote it. The new version is called p-token. It does the exact same thing as the old one, byte-for-byte, for a fraction of the compute. Then they replaced the old program in place: same address, same accounts, live on mainnet. Almost nobody noticed. That last part is the one worth understanding.

The Most Expensive Cheap Thing on Solana

Compute units are the scarce resource on Solana. Not money, not storage. Compute. Every block has a hard cap, currently 60M CU, with a 12M budget per account write lock. Every instruction draws from that cap. When blocks fill up, your transaction's priority comes down to fee per compute unit. CU is the currency that actually rations blockspace.

Against that backdrop, look at what the old SPL Token program charged for the single most common operation on the network:

A plain Transfer: 4,645 CU
A TransferChecked: 6,200 CU

That sounds small until you remember how often it runs. Transfer and TransferChecked together are nearly half of all token-program activity, and the token program is ~10% of all blockspace. So you're paying that 4,645 on a huge number of transactions every day, and a big chunk of it isn't doing anything useful. Some of it was pure logging: before a single lamport moved, the program would write Program log: Instruction: Transfer to the transaction log, and that one line burned around 103 CU.

The waste wasn't in the logic. The logic of a token transfer is trivial. The waste was in everything wrapped around it: how the program received its accounts, how it parsed them, and how much machinery the standard Solana program model dragged in before the first useful line ran. p-token's whole idea is that you can keep the logic identical and throw away the wrapping.

Here's what "throw away the wrapping" actually bought, per instruction:

Instruction	p-token	old SPL Token	Saving
`transfer`	76	4,645	~98%
`transfer_checked`	105	6,200	~98%
`initialize_mint`	105	2,967	~96%
`initialize_account`	154	4,527	~97%
`mint_to`	119	4,538	~97%
`burn`	126	4,753	~97%
`approve`	124	2,904	~96%
`close_account`	120	2,916	~96%
`freeze_account`	146	4,265	~97%
`sync_native`	61	3,045	~98%

(Benchmark figures from the official p-token upgrade page and SIMD-0266. Exact counts drift a few units between Solana releases and benchmark runs, but the shape doesn't.)

That's the whole pitch in one table. Same instruction set, same account layouts, same results, for 95-98% less compute. On a plain transfer, the operation Solana runs most, that's 4,645 CU down to 76: about 60x cheaper.

What p-token Actually Is

First, kill the most common misconception: p-token isn't a new token spec, isn't a Token-2022 successor, and isn't something you migrate to. It's a from-scratch reimplementation of the existing SPL Token program, compatible byte-for-byte: same instruction discriminators, same account layouts, same error codes, same everything an outside observer can see. Hand it the bytes for an InitializeMint instruction and it reads them the same way, writes the same account state, and returns the same errors as the program it replaces.

The "p" is for Pinocchio, the framework it's built on. Pinocchio is where the savings come from.

Pinocchio began as a personal experiment by Fernando "Febo" Otero, an engineer at Anza, aimed at one specific frustration: the solana-program crate historically dragged in a heavy, constantly churning dependency tree, and he wanted out. The experiment caught on inside Anza and absorbed enough of the team to become a real project, and a genuinely different way to write a Solana program. Its tagline is "Create Solana programs with no external dependencies attached," and it means that literally. It's no_std, it has zero external crates, it lets you drop the heap allocator entirely, and it never copies your accounts into owned memory. It's a solana-program replacement built for two things: minimum compute and minimum binary size.

p-token, the rewrite of SPL Token on top of Pinocchio, was the proof. It shrank the program binary from 131 KB to 95 KB and cut compute by ~95%. Febo and Jon Cinque wrote it up as SIMD-0266: Efficient Token Program, and that proposal is what carried it to mainnet.

Where the Compute Actually Went

This part is useful even if you never touch p-token, because it explains why a normal Solana program costs more than its logic suggests.

When the Solana runtime invokes your program, it hands over one thing: a pointer to a serialized byte buffer. That buffer holds the program ID, the accounts, and the instruction data, all packed into a specific layout. What your program does with it next is where frameworks split apart.

The standard solana-program entrypoint, the one almost every program uses, does the friendly thing. Before a single line of your logic runs, its deserialize routine walks that buffer and builds owned Rust structures. It allocates a Vec<AccountInfo> on the heap, and for every account it wraps the lamports and data in Rc<RefCell<…>>, reference-counted smart pointers you can mutate through. That's convenient. It's also a pile of allocations and copies on every single invocation, and it grows with the number of accounts. You pay for it whether or not your program touches those accounts. It even sets up a heap allocator and a panic handler you may never use.

Pinocchio refuses to do almost all of that.

Pinocchio's account type is basically a typed pointer into the runtime's input buffer. It doesn't copy the account data anywhere. It reads lamports, owner, and data in place, through the pointer. That's what "zero-copy" means here. Instead of a heap Vec, it writes those pointer-views into a fixed-size array on the stack. No Rc, no RefCell, no allocator, no std. With one macro you can forbid heap allocation entirely, so the compiler guarantees your program never touches the heap.

Most of the compute reduction came from two changes: replacing the standard entrypoint and switching to zero-copy account access. The rest came from dropping solana-program, hand-writing the instruction dispatch, and removing the per-instruction log line. (Remember, that log line alone cost ~103 CU, pure overhead just to print the instruction's name.)

The tradeoff is real, and worth saying plainly: Pinocchio is much more manual. No automatic account validation, no account model, no IDL generation, more unsafe, more pointer arithmetic, more ways to shoot yourself in the foot. Anchor hands you guardrails. Pinocchio hands you the bare runtime and trusts you to check signers, ownership, and writability yourself. For a tiny, frozen-spec program like SPL Token, which gets audited to death and almost never changes, that's a fine bargain. For your app, it usually isn't. If you want a middle ground, Steel keeps zero-copy parsing but adds back some ergonomics. At the far extreme, there's hand-written sBPF assembly. Pinocchio sits close to that assembly end.

Three Things It Can Do That the Old One Couldn't

Byte-for-byte compatibility means p-token can't remove behavior. But it can add. SIMD-0266 ships three new instructions, all purely additive.

batch (discriminator 255). This is the sleeper. A cross-program invocation has a fixed cost of roughly 1,000 CU just to make the call, before the called instruction does anything. A program that does several token operations in one transaction pays that ~1,000 CU every time. Think of an AMM handling a deposit: transfer A, transfer B, mint LP. Three calls, three times the entry cost. batch lets you bundle multiple token instructions into a single invocation, so you pay the CPI entry cost once for the whole batch instead of once per instruction.

withdraw_excess_lamports (discriminator 38). Over the years, people have accidentally sent plain SOL straight to mint and multisig accounts, where it just sits above the rent-exempt minimum with no way out. The total isn't small: something like 177,000 SOL, tens of millions of dollars, stuck in token mint accounts. This instruction lets the proper authority sweep that excess back out. (Discriminator 38 deliberately matches Token-2022's existing equivalent.)

unwrap_lamports (discriminator 45). A cleaner path for native (wrapped) SOL. You move lamports straight out of a native token account to a destination, skipping the old dance of creating and closing a temporary account.

Swapping the Engine While the Plane Is Flying

Now for the audacious part.

You have a program at Tokenkeg…VQ5DA. Hundreds of billions of dollars of token accounts name it as their owner. Thousands of other programs call into it by that address. And its upgrade authority was burned long ago, so for all practical purposes it's immutable. You can't just send an upgrade transaction. So how do you replace its code without asking the whole ecosystem to migrate to a new address? Migrating was explicitly rejected, because adoption would crawl and most of the benefit would evaporate.

You do it at the runtime level, behind a feature gate, and you let consensus perform the swap atomically. Here's how it goes:

Pre-deploy the verified bytecode to a separate staging address: ptok6rngomXrDbWf5v5Mkmu5CEbB51hzSCPDoj9DrvF. This is just a holding pen. The audited code sits on-chain, where anyone can inspect it, before anything changes. That "ptok…" address is the source, not the destination.
Ship the change behind a feature gate (ptokFjwyJtrwCa9Kgo9xoDS59V4QccBGEaRFnRPnSdP) inside a new validator release. Operators upgrade their software, but nothing actually switches yet.
Vote. Because this carries enormous economic weight, SIMD-0266 went to a stake-weighted validator vote and needed the standard supermajority of participating stake. It passed in early 2026.
Activate at an epoch boundary. Once enough stake is running the new code, the feature gate flips. Every validator's runtime, in lockstep, replaces the executable at Tokenkeg…VQ5DA with the bytecode from the staging address, through the Upgradeable BPF Loader. The address keeps its identity. Only the code behind it changes.

The swap doesn't go through the normal upgrade path, so the frozen upgrade authority never gets in the way. The validators just agree to run the new code at the next epoch boundary. p-token went live on Solana mainnet in spring 2026, at epoch 971. To stay in sync, validators needed Agave v3.1.7+ or Firedancer v0.812.30108+. Devnet had switched over earlier. For almost everyone (users, wallets, and other programs), the only thing they noticed was that token transactions got cheaper. Nothing to update, nothing to migrate.

Rewriting the Crown Jewels Without Losing Them

Here's the question that should make any serious engineer nervous. You just rewrote, from scratch, in a framework that leans heavily on unsafe and raw pointers, the single program that holds the largest share of value on Solana. Then you atomically replaced the old one with it. A subtle bug here isn't a worse user experience. It's the backbone of every DeFi position on the network behaving differently than the code that secured it yesterday. How do you ever get comfortable with that?

The answer is one of the more interesting safety-engineering stories in recent Solana history, and it's worth knowing, because it isn't "we audited it and hoped."

Differential testing against real history (Neodyme). This is the strongest pillar. Neodyme built a harness in their Riverguard fuzzer that replayed essentially every mainnet transaction that ever touched the token program through both programs, old and p-token, and diffed the results. The question wasn't "do the tests pass." It was "given the actual transactions that really happened on Solana over months, does the new program produce byte-identical account state, the same metadata, and the same error codes, in the same priority order, as the old one?" After months of running: not a single divergence. The same harness measured the payoff. Over one sample window (Aug 3-11, 2025), p-token would have saved 8.9-9.1 trillion compute units, about 12% of the entire chain's blockspace, vote transactions and all. That 12% is the honest, auditor-measured number to anchor on, more so than the per-instruction headline percentages.

Independent audits that actually found things (Zellic). Zellic audited both Pinocchio and p-token and surfaced 8 findings, one Critical and three High. Among them: an out-of-bounds read in a memory-copy helper (copy_val) caused by a loose generic bound, plus several memory-safety traps from the heavy use of unsafe and MaybeUninit. All were fixed.

The bug that proves the point (Asymmetric Research). Before mainnet, Asymmetric Research found a real loss-of-funds bug. Tellingly, it lived in the new functionality, not the replicated logic. As an optimization, p-token defers some ownership checks to the runtime's end-of-transaction validation. The new batch instruction runs multiple state transitions in one invocation. Combine the two and you could craft a fake native-token account, bump a victim's wrapped-SOL balance with no real lamports to back it, then restore the fake account's bytes before the runtime's ownership check ran. The tampering was invisible to validation. The fix was to add explicit ownership checks to batch.

Formal verification (Runtime Verification) rounds out the stack as a third independent leg. Alongside it sit Anza's own differential fuzzer, which by Neodyme's account had already caught everything Neodyme later flagged, and Firedancer's fuzzing tools.

Stack it all up, and the case for trusting p-token isn't "trust us." It's a hard, narrow spec: be byte-identical to a program we've run for years. That spec got checked against real chain history at scale. Multiple independent teams attacked it and found real bugs, which got fixed. Formal proofs went on top. And the whole thing rolled out behind a vote and a feature gate, so it only switched on once the network agreed. The leftover risk isn't zero. It never is. But it was driven down about as carefully as a change like this can be.

What Actually Changes for You

For most people building on Solana, the honest answer is nothing. Your client code keeps working, because the instruction and account layouts are identical. Your transfers just got cheaper. Done.

But there are two groups who should pay attention, and because you're reading an OrbitFlare post you're probably in one of them.

If you index or stream token activity, the logs changed. Remember that ~103 CU log line p-token deleted? A lot of indexers identified token instructions by scraping exactly that text, matching on Program log: Instruction: Transfer to label what happened. p-token doesn't emit it. If your pipeline leans on log strings to classify token instructions, it goes blind on the new program. The fix is the thing you should have been doing anyway: decode the instruction data against the IDL instead of reading prose out of logs. The updated IDL ships in the solana-program/token repo, with refreshed clients (@solana-program/token and spl-token-client) that expose the new instructions. This is the one concrete migration the upgrade forces, and it lands on data infrastructure, not on apps. If you consume a stream that already hands you decoded, structured transactions, this was a non-event. If you built your own log-scraping layer, this is your cue to retire it.

If you trade, the priority math shifted. Priority is fee per compute unit. A token-heavy transaction that now burns a fraction of the CU it used to can command higher priority for the same fee or tip, or hold the same priority for less. And clawing ~10% of compute back into every block raises the ceiling on how much the network can do before blocks fill. If your edge depends on landing transactions during congestion, both of those are worth re-tuning around.

And for everyone: the most-used program on the chain is now one of the smallest, fastest, most-scrutinized things on it. That's a good direction for the whole stack you're building on.

The Quiet Upgrade

The flashy Solana upgrades get the headlines: Firedancer, new consensus, bigger blocks. p-token got almost none of that, and it may end up mattering more day-to-day than any of them, precisely because it touches the one program everything else routes through. It didn't add a feature. It took the single most common thing the network does, made it about 60x cheaper, and slid the new engine in under the old one's address without asking anyone to change a line.

That's the kind of upgrade you only notice if you go looking at the compute meter. Which, if your business runs on Solana, is exactly where you should be looking.

OrbitFlare builds the infrastructure under Solana apps: RPC, WebSocket, Yellowstone gRPC, Jetstream shred-decoded streaming, and Shredstream.

Resources

Building a Live Solana TPS Meter with OrbitFlare's TypeScript SDK

OrbitFlare RPC — Fri, 22 May 2026 21:18:18 +0000

Every Solana dashboard tells you the network's TPS. None of them tell you how busy the one program you care about is right now. Did Pumpfun cool off after a launch? Is Raydium spiking? Is the program your bot listens to still alive in the last 30 seconds? You're stuck picking between a smoothed-out aggregate or a paid dashboard that refreshes once a minute.

The smallest thing that answers the question directly is below. Point it at any Solana program, get a live transactions-per-second gauge in the terminal with a recent-signatures tape under it. One TypeScript file, less than 100 LoC, runs in a terminal, built on @orbitflare/sdk.

jetstream tx rate: pumpfun (6EF8rrec...)
chain slot:        421442130

last 1s:     14 tx/s
last 10s:    9.7 tx/s avg

recent signatures:
   0.1s ago  slot 421442129  4bpPQBUHmobNJ4SS9ETLaMwY...
   0.4s ago  slot 421442128  Gsi3P32j6h9Yx3ce1gfHR5Pa...
   0.7s ago  slot 421442128  55AWdcey9N1WTYkmQDXPeKHD...
   ...

Full source: github.com/orbitflare/jetstream-tx-rate.

The honest meter problem

The meter could be built with one Jetstream subscription: filter on the program, count transactions per second. That gets done in 50 lines. The problem only shows up the first time the program goes quiet for ten seconds. The meter reads zero. So does the signature tape. And now there's no way to know whether the program is actually idle or whether the SDK silently lost the connection three minutes ago.

The fix is one extra subscription on a second transport. WebSocket slotSubscribe() ticks every ~400ms whether anything is happening or not, because the chain itself never stops.

The clients

import { JetstreamClientBuilder } from '@orbitflare/sdk/jetstream';
import { WsClientBuilder } from '@orbitflare/sdk/ws';

const jet = new JetstreamClientBuilder()
  .url('http://jp.jetstream.orbitflare.com')
  .build();

const ws = await new WsClientBuilder()
  .url('ws://ams.rpc.orbitflare.com')
  .build();

That's it for setup. Jetstream needs no api key. WebSocket picks one up from ORBITFLARE_LICENSE_KEY if set.

The two subscriptions

WebSocket pipes the chain slot into a shared variable. One callback, no state machine:

let currentSlot = 0;
const slotSub = await ws.slotSubscribe();
slotSub.on((s) => {
  if (typeof s?.slot === 'number') currentSlot = s.slot;
});

Jetstream gets the transaction firehose, filtered server-side to just the program of interest. for await drains it and stamps each arrival:

const stream = jet.subscribe({
  transactions: {
    target: {
      accountInclude: [],
      accountExclude: [],
      accountRequired: [program],
    },
  },
  accounts: {},
  ping: { id: 1 },
} as any);

const arrivals: number[] = [];
const recent: { slot: number; sig: string; at: number }[] = [];

for await (const u of stream) {
  const sig = u.transaction?.transaction?.signature;
  if (!sig) continue;
  const now = Date.now();
  arrivals.push(now);
  recent.unshift({ slot: Number(u.transaction!.slot), sig: bs58.encode(sig), at: now });
  if (recent.length > 10) recent.length = 10;
}

The accountRequired filter is the load-bearing piece. It tells the Jetstream server to only ship transactions where the program is in the account list, so the bandwidth that reaches the laptop is already the data that matters. No client-side filtering, no wasted parsing.

Two pieces of state, both trivial. arrivals is a list of millisecond timestamps the renderer reads to compute rates. recent is a 10-element ring of the most recent signatures, kept in arrival order, displayed as a scrolling tape under the gauge.

The renderer

Every second, the renderer does three things. First it drops any timestamp older than 10 seconds from arrivals. Then it counts: how many timestamps in the last 1 second (that's the instantaneous rate), and the total count divided by 10 (that's the rolling 10-second average). Finally it clears the screen with an ANSI escape and prints the dashboard.

function render(): void {
  const now = Date.now();
  while (arrivals.length && now - arrivals[0]! > 10_000) arrivals.shift();
  const last1s = arrivals.filter((t) => now - t <= 1_000).length;
  const last10sAvg = arrivals.length / 10;

  process.stdout.write('\x1B[2J\x1B[H');
  console.log(`jetstream tx rate: ${label} (${program.slice(0, 8)}...)`);
  console.log(`chain slot:        ${currentSlot}\n`);
  console.log(`  last 1s:  ${String(last1s).padStart(5)} tx/s`);
  console.log(`  last 10s: ${last10sAvg.toFixed(1).padStart(5)} tx/s avg\n`);
  console.log('recent signatures:');
  for (const r of recent) {
    const age = Math.max(0, (now - r.at) / 1000).toFixed(1);
    console.log(`  ${age.padStart(4)}s ago  slot ${r.slot}  ${r.sig.slice(0, 24)}...`);
  }
}

setInterval(render, 1_000);
render();

Running it

git clone https://github.com/orbitflare/jetstream-tx-rate.git
cd jetstream-tx-rate
npm install
npm start pumpfun       # or raydium, jupiter, or any raw program id

Signatures land within a second of the first run. Watching Pumpfun for five minutes shows it idling around 8-15 tx/s on a slow afternoon and spiking to 50-80 when a launch hits. Raydium runs lighter on average but every big swap is a visible jolt. Any program ID on Solana gets the same view of how busy it actually is, not how busy it averages out.

What this tiny snippet doesn't have to do

Reconnects, regional failover, api-key scrubbing, ping/pong liveness, the protobuf wire format, the WebSocket re-subscribe dance after a drop. The SDK handles all of it the same way across both transports. None of it shows up in the source. What's left is a filter, a callback, and the rendering math.

That’s the trade. And a good one. Use the SDK’s plumbing, write the part that’s actually yours.

Resources

Full source: github.com/orbitflare/jetstream-tx-rate
@orbitflare/sdk on npm
SDK docs

Three new ways into OrbitFlare: Introducing the CLI, MCP, and Skills

OrbitFlare RPC — Wed, 13 May 2026 06:53:29 +0000

You write a Solana app and the questions that come up while you're writing it almost never live in the same place as the code. You want a fee sample for an address that touches Raydium so you can decide whether your priority-fee bid is going to land or sit. You want to know what your account balance is before you spin up a heavier plan. You want to scaffold a copy-trader because you've thought of a strategy and you'd rather see it move on chain before you talk yourself out of it. You want your editor's AI to stop hallucinating gRPC field names that haven't existed since the Yellowstone proto last changed.

Every one of those is a context switch. Tab over to the dashboard, click through. Open a new terminal, dig out the right curl. Re-explain to the agent that no, this is Jetstream's proto, not Yellowstone's, and the field is account_include, not account_filter. Each one is small. They add up.

The three things below close those gaps where they actually live: in your terminal, in your agent's context window, and in the chat surface where you're already typing.

The CLI

orbitflare is a single binary that puts every piece of the OrbitFlare surface area one command away from your shell. RPC queries, two flavors of gRPC streaming, WebSocket subscriptions, project scaffolding from a small library of templates, login and key management, plan browsing, on-chain top-ups in USDC, and a TUI dashboard for watching the whole account move in real time. Every command supports --json, so you can pipe any output into the next thing in the chain.

cargo install orbitflare
orbitflare auth login --x-orbit-key ORBIT-...

That's the install and the one-time login. Credentials land in the OS keychain, the RPC license key gets pulled in for you so you don't have to thread it through every command, and orbitflare auth status is there when you need to confirm which profile you're talking to.

rpc handles one-shot reads:

orbitflare rpc slot
orbitflare rpc balance <ADDRESS>
orbitflare rpc tokens <WALLET>
orbitflare rpc tx <SIGNATURE>
orbitflare rpc history <WALLET> --limit 50

ws mirrors Solana's four pubsub subscription types. Each takes a --commitment to override the default and a --json flag for one-line-per-update output:

orbitflare ws slot
orbitflare ws account EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
orbitflare ws logs --mentions 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8
orbitflare ws signature <sig>

--ws-url is global and auto-derived from your RPC URL when you don't pass one, which is most of the time.

jet and grpc are the firehoses. Both take a YAML config that describes which transactions, accounts, or slots you want to see, expand ${ENV_VAR} references inline, and stream the matching events as they happen:

orbitflare jet --config stream.yml
orbitflare grpc --config grpc-stream.yml

template --list shows what's available and template --install <name> clones the chosen example into your working directory, which is the fastest way to see how an OrbitFlare-shaped project is wired end to end:

orbitflare template --install solana-copy-trader

plan list, plan compare --all, pay check-balance, and pay topup <AMOUNT> cover the account side, the same things you'd otherwise be clicking through the dashboard to reach. dashboard opens the TUI when you want all of it in one panel.

Streaming and RPC inside the CLI run on top of the published orbitflare-sdk crate, which means multi-endpoint failover, exponential retry with jitter, active ping/pong liveness checks, automatic reconnection on disconnect, and URL sanitization that keeps your api key out of error messages and tracing spans all come along for free.

Skills

If you've spent any time in Claude Code, Cursor, or Codex, you've already noticed the model is confident about Solana in general and confidently wrong about Solana specifics maybe a third of the time. It writes you a getProgramAccounts call without the dataSlice you almost certainly need. It assumes Jetstream's proto looks like Yellowstone's because Yellowstone is what's in its training set and Jetstream isn't. It invents CLI flags that don't exist because flag shapes are the kind of thing models are happy to extrapolate.

@orbitflare/skills fixes the OrbitFlare half of that. One npx command drops the skill into your agent's skills directory:

npx @orbitflare/skills@latest                # ~/.claude/skills/orbitflare
npx @orbitflare/skills@latest --project      # ./.claude/skills/orbitflare
npx @orbitflare/skills@latest --cursor       # ~/.cursor/skills-cursor/orbitflare
npx @orbitflare/skills@latest --codex        # ~/.codex/skills/orbitflare

A SKILL.md and a references/ folder land on disk, all pulled straight from the official documentation. The contents cover the things a generic Solana training set tends to miss. Which transport fits which question. The two-key model: ?api_key= on the URL for chain reads, X-ORBIT-KEY in a header for the Customer API. What getTransactionsForAddress does in one call that stock getSignaturesForAddress plus a getTransaction fan-out can't match. The exact YAML shape orbitflare grpc and orbitflare jet expect.

Restart the agent and try something you'd otherwise have to spell out the long way:

Stream Pump.fun trades using OrbitFlare Jetstream.

The agent reaches into the skill, writes a jetstream.yml with the right account_include, and hands you back the orbitflare jet --config jetstream.yml to run. Ask for the same thing in Rust and it pulls in orbitflare-sdk with the jetstream feature and writes out the JetstreamClientBuilder chain. The model could have guessed something plausible on its own. With the skill, the first guess is the right one.

The MCP server

@orbitflare/mcp is an MCP server that exposes 53 OrbitFlare capabilities as discrete tools, one per capability, so any MCP host (Claude Desktop, Claude Code, Cursor, Windsurf, Codex CLI, Gemini CLI, VS Code) can call them directly from the chat window.

Most hosts share the same JSON block, pointed at npx:

{
  "mcpServers": {
    "orbitflare": {
      "command": "npx",
      "args": ["@orbitflare/mcp@latest"],
      "env": {
        "ORBITFLARE_API_KEY": "your-license-key",
        "ORBITFLARE_NETWORK": "mainnet"
      }
    }
  }
}

The file path varies by host (Claude Desktop's claude_desktop_config.json, Cursor's ~/.cursor/mcp.json, Codex CLI's TOML at ~/.codex/config.toml), but the shape is the same. If you'd rather not put the key in the host config, drop the env block and call setApiKey from the chat once.

MCP works best when the question maps cleanly to a single capability. The model picks the tool, you don't:

What's a competitive priority fee right now for an account that touches Raydium?

That fans out to getRecentPrioritizationFees with the right address, and the model summarizes the P50/P75/P90/P99 percentiles into chat. You don't have to know the JSON shape of the response.

Build me a Yellowstone gRPC config that streams Jupiter swap transactions from Frankfurt.

That hits subscribeTransactions, which returns a ready-to-use YAML you can drop straight into orbitflare grpc --config.

Quote 1 SOL to USDC with 0.3% slippage.

That hits getSwapQuote, which runs through Jupiter Metis routing. SOL and USDC get auto-resolved to their mint addresses, and the response carries the route, expected output, and price impact.

All 53 tools are independently callable. No internal action router, no pagination dance for large payloads, and setApiKey swaps either of the two keys at runtime.

The docs are also exposed as MCP resources under orbitflare://docs/*, so the model grounds answers in pages it can actually quote.

Three places, one stack

Three different surfaces, same stack underneath. Same license keys. Same eleven regions (ash, ny, la, slc, ams, fra, lon, dub, siau, tok, sgp). Same docs, just exposed differently to whichever surface is asking.

Pick whichever fits how you work. The CLI when you're in a shell. The skill when you're in your IDE with an agent open. The MCP server when you're in a chat window and would rather not turn the question into a coding task in the first place. You'll probably end up with all three.

Resources

orbitflare on crates.io (CLI v0.3)
@orbitflare/skills on npm
@orbitflare/mcp on npm
Docs

If you build something with any of these, or run into a rough edge that should be smoother, we'd love to hear about it and help you out.

Top Solana RPC Providers in 2026 - A Comprehensive Guide

OrbitFlare RPC — Fri, 01 May 2026 18:46:34 +0000

For a long time, picking a Solana RPC provider was a one-line decision: pick the cheapest endpoint that didn't fall over. The interesting question was whether you could afford a dedicated node or had to live on shared infrastructure. That world is mostly gone.

In 2026, "Solana RPC" usually means a stack of five things that used to be distinct products. Plain JSON-RPC is the floor. On top of it sit WebSocket subscriptions, Yellowstone-style gRPC streams, shred-level feeds tapped before validators finish execution, and staked transaction submission with SWQoS routing. Most of the providers below offer some subset. A few offer all of them. At least two of the names you keep seeing on these lists don't really play the same game anymore.

What to Actually Benchmark

Reading a provider's website is not benchmarking. Five things worth putting on a real test rig from your own infrastructure before signing anything:

p99 latency on the methods your app actually calls. Average latency is marketing. The slowest 1% of requests is what breaks production. Pick the three or four methods that dominate your traffic (getAccountInfo, sendTransaction, simulateTransaction, getSignaturesForAddress are typical) and measure p99 from your own server for at least an hour during real chain activity. The gap between providers shows up in the long tail, not the median.
Transaction land rate during congestion. Pick a known busy window (a vote epoch transition, a major mint, a memecoin event) and submit a few hundred test transactions through each provider you're evaluating. Track what percentage land on the first try. Staked submission and SWQoS routing typically push this into the high 90s; unprioritized submission can fall into the 60s. Land rate at p50 congestion is the number every provider quotes; land rate at p99 is the one that matters.
Reconnect behavior under partial failure. Most providers' SDKs survive a clean disconnect. The interesting case is a flaky upstream: connection technically alive, packets dropping, slot lag silently growing. Simulate it (tc qdisc add dev eth0 netem loss 5% on Linux is one easy approach) and watch whether the client recovers, retries, or just keeps yielding stale data. Whoever hides the failure longest hurts you the most.
The pricing curve at 10x your current load. Free tiers and starter plans are decoys. The real number is what the bill becomes at the volume you'd hit if your product worked. Build a quick spreadsheet: project your request mix to 10x scale, run it through each provider's pricing page, see which ones double, which ones quadruple, and which ones quietly switch you to a custom-quote tier.
The shape of what's above plain JSON-RPC. Raw RPC is a commodity. The actual differentiators are the surfaces above it: parsed transactions, token and NFT metadata APIs, shred-level feeds, regional pops, archival depth, observability dashboards. Match your real needs against what each provider has shipped, not what they list on a coming-soon page. If a feature isn't documented, it doesn't exist for buying purposes.

1. OrbitFlare

OrbitFlare runs the full transport stack for Solana: RPC, WebSocket, Yellowstone-compatible gRPC, and two shred-layer products. Jetstream delivers decoded shreds over gRPC (the server parses the transaction for you), while Shredstream forwards raw shreds over UDP straight from top-of-Turbine validators in 9 regions. Coverage spans 11 regional pops on three continents: four in the US (Ashburn, New York, Los Angeles, Salt Lake City), five in Europe (Amsterdam, Frankfurt, London, Dublin, Siauliai), and two in Asia (Tokyo, Singapore). A single SDK talks to all four transports through one builder pattern, which kills the per-transport plumbing tax any non-trivial Solana app eventually accumulates.

The Jetstream path sits closer to the leader than any Geyser-based feed by definition. Geyser fires after the validator commits the transaction. Shred decoding produces a parsed transaction before that. For anyone timing entries on swap rumors, copy-trading an active wallet, or detecting pool creations before they're in a block, that window matters.

What OrbitFlare doesn't ship: NFT-heavy parsing APIs and cross-chain coverage. If those are the problem, Helius and QuickNode are the right calls.

2. Triton One

Triton built Yellowstone. That alone earns them a top spot on any honest list, because the standard everyone else implements is the standard they wrote. Their public products read like an institutional menu: Dragon's Mouth for live gRPC, Steamboat for archival queries, Old Faithful for historical block data, Cascade Marketplace for SWQoS routing.

They run dedicated nodes by default. Observed latency sits around 100ms, which is competitive with anyone. They have the longest credible track record powering large protocols. Openbook, Pyth, and Wormhole have all leaned on Triton at various points, and that kind of operational reputation isn't bought, it accumulates.

The catch is the price tag. Dedicated nodes start in the high four figures per month, with Cascade pricing on top if staked submission is needed. Triton is institutional infrastructure and prices itself that way. For something that genuinely needs the guarantees they offer (large DeFi, exchange backends, capital-heavy MEV operations), they're worth the spend. For a side project a few months in, the pricing page is the bouncer.

3. Helius

Helius is the Solana-native incumbent, and usually the right answer when the requirement is "I need a lot of Solana-specific tooling and I want it now." Their RPC runs through staked validator nodes for SWQoS priority on transaction submission. Beyond plain RPC, they ship an Enhanced Transactions API, the Digital Asset Standard (DAS) read API, parsed webhooks, and LaserStream for low-latency gRPC.

If your app is heavy on token metadata, NFT data, or anything that would otherwise require a custom indexer to enrich raw RPC output, Helius has done that work and exposes it under one account. Their free tier at 1M credits per month is one of the more generous on this list, which makes the on-ramp for hobby projects almost frictionless. They also operate a top-staked validator, which gives them more leverage on transaction landing than most.

The tradeoff worth flagging: the Enhanced APIs are useful but sticky. Once your code is wired to "give me a parsed transaction with token transfers labeled," moving to another provider means writing the parser yourself. That's not a knock on their engineering. It's a portability choice worth making consciously.

4. GetBlock

GetBlock benchmarks #1 on raw latency in Asia, EU, and Africa, which is credible for users outside North America. Their dedicated nodes ship with Yellowstone gRPC included rather than as an add-on, unusual at their price point, and they offer a LandFirst transaction submission product that competes with paid SWQoS tiers elsewhere.

Their shared tier is fine for hobby projects but they're at their best as a regional dedicated provider. They also offer free engineering help for custom configurations, worth mentioning not as praise but as a signal of where they sit. You're getting hands-on attention you wouldn't get from QuickNode or Alchemy at the same spend.

5. RPC Fast

RPC Fast is the most opinionated provider on this list. They run bare-metal dedicated nodes only, ship Jito ShredStream on by default, and price everything custom. The pitch is straightforward: HFT-grade infrastructure for teams that can write a procurement email.

Their automated failover claim of sub-50ms recovery is aggressive enough that it's worth pressure-testing in a real benchmark before signing anything, but the underlying setup (bare-metal nodes, geographic redundancy) is the right shape for it. Yellowstone gRPC is supported but not their primary streaming pitch. ShredStream is.

The catch is the pricing model. Custom-only is fine when the budget exists; it's a wall when the goal is to spin up a node over the weekend. Skip this one if "request a quote" isn't a workflow you can run.

6. Alchemy

Alchemy supports 37+ chains and has the deepest developer tooling in crypto, the kind of metering, logging, replay, and trace infrastructure you'd expect from a much older industry. For teams already using them on EVM, adding Solana is two clicks and a billing change.

What you get: solid latency (40-60ms observed in North America and Asia), a generous free tier (30M compute units a month), and the most polished docs on this list. What you don't get: Solana-specific depth. There's no equivalent of Helius's parsed APIs, no Jetstream-style shred feed, and the highest shared plan caps at 300 RPS.

Alchemy is the right answer when Solana is one of several chains being supported and managing two relationships isn't appealing. It's not the right answer when Solana is the hot path.

7. QuickNode

QuickNode is the EC2 of crypto RPC. They support 75+ chains across 120+ networks, have the most polished dashboard in the space, and offer a long shelf of add-ons to compose per-project. MEV protection, transaction speed boosters, NFT and token APIs, Yellowstone gRPC on port 10000, and so on.

For multi-chain teams, especially ones that want a single vendor for both EVM and Solana, QuickNode is the pragmatic answer. Their ops are mature, their SLAs are real, and their support is responsive in ways most of this list isn't.

Where they're not the obvious pick: pure Solana work where every dial needs to be turned up. Standard tiers cap shared throughput around 400 RPS, which sounds like plenty until a sniper is fanning blockhash refreshes through a launch. The Solana-specific depth, parsed APIs, shred-level feeds, fine-grained staked submission, is shallower than what Helius, Triton, or OrbitFlare offer.

8. Ankr

Ankr runs a decentralized RPC network across 80+ chains, with throughput up to ~1,500 RPS on premium tiers. Pricing is pay-as-you-go from around $6 per 1M requests, which is the most cost-effective option on this list for low-volume reads.

Two things to know. Their network model means there's no single dedicated machine, traffic is load-balanced across operators. That's fine for read-heavy workloads, less ideal when predictable latency for transaction submission is a requirement. SWQoS access is gated behind their premium tier.

Pick Ankr when cost per read matters more than tail latency. Skip it for any hot path.

9. Chainstack

Chainstack quietly turned on Jito ShredStream by default on their Solana nodes in early 2026, shipped a Trader Node product with priority routing, and run real SOC 2 Type II compliance, which matters more than people admit when the goal is to onboard institutional customers.

Their Unlimited Node tier at $149/mo is the best flat-rate offer in the market. Full RPC, WebSocket, and gRPC access without the per-request metering that turns other providers' pricing pages into spreadsheet exercises. That directly undercuts OrbitFlare's Growth tier on raw monthly cost. Chainstack sits below the providers above in this ranking because their Solana product is one of many things they offer rather than their entire business. For teams already on Chainstack for EVM work, extending to Solana is a one-tab decision.

10. Syndica

Syndica is Solana-only and has leaned hard into observability. ChainStream gives a query layer over historical Solana data. Their dashboards show what RPC traffic actually looks like, with request mix, p99 latency by method, and error rates broken down in a way most providers don't bother with.

The core RPC is solid but isn't differentiated on raw speed. The reason to pick Syndica is the diagnostics. When a team is trying to figure out why a particular method is slow, or which addresses are eating most of their getAccountInfo budget, having that data already collected beats writing a metrics pipeline from scratch.

Best fit for teams with their hands full of Solana-specific debugging and a real need to understand their own usage in production.

Dedicated vs Shared

A quick note, because people still ask this every week.

Shared nodes get you started faster and cost less, but they come with noisy-neighbor effects. When another tenant runs a heavy getProgramAccounts query on the same instance, p99 latency spikes. On the better providers this is minor. On cheaper ones it can be severe.

Dedicated nodes remove the noise but introduce configuration and capacity questions that used to be the provider's problem. You pick the region. You pick the hardware tier. You pay whether your traffic is full or empty.

The right answer depends more on predictability requirements than on scale. A small trading operation that needs consistent latency belongs on dedicated before a much larger read-heavy app that can tolerate occasional spikes. Every major provider on this list offers both shapes. Pick the one that matches what you need to be certain about.

By Use Case

The honest mapping, since "no universal winner" sounds wise but doesn't help anyone make a decision:

Trading, MEV, sniping. OrbitFlare, Triton One, or RPC Fast. All three give shred-level or sub-block feeds and serious latency. OrbitFlare for teams that want one SDK across the whole transport surface. Triton if the team is already built around Yellowstone and the institutional reputation is part of the buying decision. RPC Fast if the budget is open and procurement is an option.
Solana-native dApps with NFT or token surfaces. Helius. The Enhanced Transactions API and DAS will save weeks of indexer work. Plan for the portability cost when moving.
Multi-chain teams. QuickNode for breadth and ops maturity, Alchemy for developer tooling depth, Chainstack for the flat-rate pricing. The right answer depends on existing relationships more than the technology.
Institutional workloads with compliance requirements. Chainstack (SOC 2 Type II) or Triton One. Helius is also SOC 2 certified but fewer of their enterprise customers talk about it publicly.
Cost-sensitive read workloads. Ankr. Pay-as-you-go pricing is the cheapest cost-per-request on this list.
Solana with regional concentration outside North America. GetBlock for Africa benchmarks. OrbitFlare for any of the 11 regions across the US, Europe (including Eastern Europe via Siauliai), and Asia (Tokyo and Singapore).
Production debugging on Solana. Syndica's observability layer earns its rank.

At a Glance

The Floor

There is no universal best. There is a worst, though, and that's running anything you care about on a public RPC endpoint and being surprised when it stops responding the moment a launch hits. Pick something on this list. The cheapest paid tier of any of them beats free.

To compare specifics against OrbitFlare, or to get help sizing the right tier for a workload, get in touch.

The OrbitFlare SDK: One Rust Crate for Every Solana Transport

OrbitFlare RPC — Sun, 26 Apr 2026 15:38:00 +0000

Building a Solana app in Rust tends to mean you collect SDKs. One for JSON-RPC because you need get_balance and get_transaction for the obvious one-shot reads. One for WebSocket because polling for account changes gets tired fast. One for gRPC because Yellowstone is the only realistic way to keep up once your volume passes a certain threshold. And often a fourth for whatever specialized feed you've signed up for on top of it, because the first three stop being enough the moment latency starts mattering to your app.

Each one arrives with its own types, its own error model, its own opinions about how to reconnect when the socket drops, and its own way of threading auth into a URL. You end up writing the same wrapper code in four slightly different places - retry the request, fall back to a secondary endpoint, redact the api key out of log lines, time out when the connection has gone silent - and none of it is the reason you started the project. It's the least interesting code in any Solana app, and somehow it ends up being the most fragile too.

The OrbitFlare Rust SDK

OrbitFlare sits at the other end of that problem. We run Solana RPC, WebSocket, and gRPC endpoints, plus our own Jetstream feed for the cases where Geyser-based streams can't keep up.

Our new Rust SDK is what you use to talk to any of it, and it's shaped around a single builder pattern and a single error type across every transport, so the code you write to call get_balance over HTTP reads almost identically to the code you write to open a binary gRPC firehose.

What that buys you, beyond a shorter Cargo.toml, is that all the plumbing you would otherwise be writing per-client lives once, in one place, and gets better over time instead of drifting in four directions at once.

The Transports

The crate exposes four transport modules, each behind its own feature flag.

rpc is the typed JSON-RPC client you'll reach for whenever you need a one-shot read, a transaction submission, or a historical lookup.
```
let rpc = RpcClientBuilder::new()
    .url("http://ams.rpc.orbitflare.com")
    .build()?;
```
ws gives you the pub/sub surface for the things you want to watch as they happen on-chain: slots, accounts, signatures, and log filters.
```
let ws = WsClientBuilder::new()
    .url("ws://ams.rpc.orbitflare.com")
    .build()
    .await?;
```
grpc is the Yellowstone-compatible firehose, where you open one long-lived subscription, hand the server a set of filters, and let it stream every matching event straight from the validator's Geyser plugin.
```
let geyser = GeyserClientBuilder::new()
    .url("http://ams.rpc.orbitflare.com:10000")
    .build()?;
```
jetstream has the same API shape as the gRPC client, but the data comes out of our own shred-decoded pipeline rather than Geyser, which is a meaningful win when "earlier" matters to what you're building.
```
let jetstream = JetstreamClientBuilder::new()
    .url("http://ams.jetstream.orbitflare.com")
    .build()?;
```

Installation

cargo add orbitflare-sdk --features <features>

The available features are rpc, ws, grpc, and jetstream. Pick whichever combination your app actually needs and your dependency tree stays lean.

What You Don't Have to Write

The boring infrastructure around any transport client - reconnect, fallback, liveness, api key handling - is where most of the bugs in any Solana app quietly live, and it's fundamentally the same work regardless of which protocol you're speaking.

The SDK handles it once, on your behalf, and runs the same implementation across every client. When a socket drops, the subscriptions you had on it get re-registered against the new connection. When a primary endpoint starts misbehaving, the client backs off and cycles through whatever fallback URLs you chained onto the builder, bringing the primary back into rotation once it recovers.

And anywhere a URL might end up in an error log, the api key gets redacted out of it first and you start grepping your tracing output.

In a Real Project

Most apps built on the SDK end up with roughly the same shape. You construct the clients you need up front, hand them off to whichever parts of the app are going to use them, and let the SDK manage the underlying connections for the lifetime of the process.

use orbitflare_sdk::{
    GeyserClientBuilder, Result, RpcClientBuilder, WsClientBuilder,
};

#[tokio::main]
async fn main() -> Result<()> {
    let rpc = RpcClientBuilder::new()
        .url("http://ams.rpc.orbitflare.com")
        .build()?;

    let ws = WsClientBuilder::new()
        .urls(&[
            "ws://ams.rpc.orbitflare.com",
            "ws://lon.rpc.orbitflare.com",
        ])
        .build()
        .await?;

    let geyser = GeyserClientBuilder::new()
        .url("http://ams.rpc.orbitflare.com:10000")
        .build()?;

    // ... use rpc, ws, geyser
    Ok(())
}

The demo we're going to build over the rest of this post is a small wallet ticker. You pass in a pubkey at the command line, and the program prints a live view of that wallet's SOL balance along with every token account it owns, updating the display in place as the balances change. Around 120 lines of code end to end.

It uses the same pattern the code sketch above hinted at. The RPC client handles the bootstrap - one get_balance for the SOL side, one get_token_accounts_by_owner for the SPL tokens, and a handful of small lookups to decorate each account with its mint's decimals so the output reads as token amounts rather than raw integers.

From there the WebSocket client takes over: we open an account_subscribe for the wallet itself and one for each token account we found, merge the updates into a single stream inside the app, and redraw the dashboard whenever any of them tick. The RPC client gets you the starting state; the WebSocket client keeps it honest from there.

Setting Up the Project

Create a new Cargo project and pull in the dependencies you'll need:

[package]
name = "wallet-ticker"
version = "0.1.0"
edition = "2024"
rust-version = "1.85"

[dependencies]
orbitflare-sdk = { version = "0.2.0", features = ["rpc", "ws"] }
tokio = { version = "1.52.1", features = ["full"] }
serde_json = "1.0.149"
base64 = "0.22.1"

orbitflare-sdk with the rpc and ws features gives you exactly the two transports this project uses and nothing else.

Tokio's full feature is convenient for a tutorial; in a production app you'd bare that down to the runtime pieces you actually rely on.

base64 and serde_json show up because WebSocket account updates arrive as base64-encoded bytes wrapped in a JSON envelope, and you'll be reaching into both.

Building the Clients

RpcClient::build is synchronous; WsClient::build is async because it actually opens the socket. The Arc wrap on ws is there because each subscription will live in its own tokio::spawn and they all need to reach the same underlying connection:

let rpc = RpcClientBuilder::new()
    .url("http://ams.rpc.orbitflare.com")
    .commitment("confirmed")
    .build()?;

let ws = Arc::new(
    WsClientBuilder::new()
        .url("ws://ams.rpc.orbitflare.com")
        .build()
        .await?,
);

The Bootstrap

Pulling the wallet's current state is two RPC calls:

let mut sol_lamports = rpc.get_balance(&wallet).await?;
let raw_tokens: Vec<Value> = rpc
    .get_token_accounts_by_owner(&wallet, None, None)
    .await?;

get_token_accounts_by_owner returns each entry in jsonParsed encoding, so the mint address, token amount, and decimals are already structured fields you can lift straight into a HashMap<pubkey, Holding>. The pubkey you key by is the token account's own address - that's the id you'll subscribe to in the next step, not the mint.

Subscribing Concurrently

Once you have the list of accounts, you need one subscription for the wallet itself and one per token account. The shape that works is a tokio::spawn per subscription sharing an Arc<WsClient>, with all of them pushing updates into a single mpsc channel the main loop drains:

let ws = Arc::new(ws);
let (tx, mut rx) = mpsc::channel::<Update>(1024);

for pubkey in holdings.keys().cloned().collect::<Vec<_>>() {
    let ws = Arc::clone(&ws);
    let tx = tx.clone();
    tokio::spawn(async move {
        let Ok(mut sub) = ws.account_subscribe(&pubkey, "confirmed").await else {
            return;
        };
        while let Some(v) = sub.next().await {
            // decode v["data"][0] as an SPL token account,
            // then send an Update down tx
        }
    });
}

The tokio::spawn is what makes this scale. A naive for pubkey in ... { ws.account_subscribe(...).await? } loop works too, but it serializes one subscribe per round-trip. That's fine for a dozen accounts, painful for a few hundred, and flat-out unusable on wallets with thousands of token accounts. Spawning lets every subscription open in parallel, and the first updates start landing in the channel before the last subscribe ack even comes back.

The Render Loop

Everything comes together in a short loop that reads the next update, mutates local state, and redraws:

while let Some(update) = rx.recv().await {
    match update {
        Update::Sol(lamports) => sol_lamports = lamports,
        Update::Token { account, amount } => {
            if let Some(h) = holdings.get_mut(&account) {
                h.amount = amount;
            }
        }
    }
    render(&wallet, sol_lamports, &holdings);
}

Run it against any Solana address:

ORBITFLARE_LICENSE_KEY=ORBIT-KKKKKK-EEEEEE-YYYYYY cargo run --release -- <pubkey>

You'll see the dashboard populate within a few hundred milliseconds as the RPC bootstrap lands, then each line ticks in place the moment something touches the wallet on-chain:

wallet: CKs1E69a2e9TmH4mKKLrXFF8kD3ZnwKjoEuXa6sz9WqX

  SOL     0.040420950
  EPjF...Dt1v      42.500000
  So11...1112       0.005000

Ctrl+C to quit. The full source - about 140 lines of Rust end to end, including the render function, the state types, and the bootstrap parse loop - is linked at the bottom of the post.

That's about it for the SDK in broad strokes - a builder per transport, a shared error and retry story, and the reconnect and fallback work kept inside the crate where you don't have to think about it.

The ticker above is the smallest app that meaningfully exercises more than one of the clients at a time, but the shape scales up from there: the same pattern works just as well when you're stitching together a copy trader, a liquidation monitor, or anything else that needs to move between one-shot reads and live streams in the same loop.

With the SDK in place, the plumbing is off your plate and what's left is the part of the project that's actually yours to build. Which, for most of us, is the only reason we started one in the first place.

Resources

If you build something with the crate, or run into a rough edge that should be smoother, we'd love to hear about it and help you out!