When we started Subglow we thought gRPC was enough. Streams are where the interesting latency numbers live, streams are where pre-parsed JSON actually changes your p99, and streams are what every serious Solana trading bot needs. We built around that and shipped.

Then customers showed up asking variations of the same question:

"I want to stream from you, but I also need a getTokenAccountsByOwner endpoint, a getLatestBlockhash I can trust, and a sendTransaction endpoint that doesn't share a credit bucket with my Pump.fun scanner. Do I need to buy Helius and Subglow?"

The honest answer until recently was: yes, most users kept a Helius or QuickNode account on the side for the JSON-RPC surface. That's two bills, two credential surfaces, two latency paths, and exactly one service that actually cares about your workload.

So we bundled it. Every paid Subglow plan now includes a flat-priced JSON-RPC endpoint at rpc.subglow.io on the same API key you use for gRPC. Let me walk through why we structured it the way we did.

One API key, two endpoints

The single-credential rule is a product decision, not a technical shortcut. Subglow's entire pitch is that we refine Solana data into something your bot can consume without engineering overhead. Asking you to manage two keys, two quotas, and two dashboards for the same logical workload undermines that.

Concretely: your Subglow API key opens grpc.subglow.io:443 for Yellowstone streams and https://rpc.subglow.io/<apiKey> for JSON-RPC reads and writes. Same billing tier, same dashboard usage view, same support Telegram.

Flat quotas, no credit metering

We already don't meter credits for gRPC. Extending that principle to RPC means every plan has a flat daily JSON-RPC cap. Sniper gets 50k RPC/day. Pro gets 500k. Dedicated is unlimited.

Every major competitor prices JSON-RPC through some variant of credit metering where methods have different "weights" — a getAccountInfo is cheap, getProgramAccounts is expensive, sendTransaction is somewhere in between. The math is hard to reason about, especially when your actual traffic pattern shifts with market conditions. During a Pump.fun cycle your scanner fires 10× more account reads, your credit balance craters, and the weekend upsell email arrives.

Flat caps mean you can spike 10× without the bill moving. You hit the cap or you don't. If your workload consistently needs more, you upgrade — and the upgrade is predictable.

Why sendTransaction gets its own bucket

We considered putting sendTransaction in the same pool as reads. We decided against it for one specific reason: during a market spike, your reads starve your writes.

Picture a typical sniper bot. Normal volume: 10k reads/day, 200 sendTx/day. A Pump.fun graduation wave lands and your scanner is now firing 40k reads/day because you're polling account states to confirm the new Raydium pool. On a shared credit pool, those reads burn through the budget your submit path needed to actually buy. You detected the opportunity perfectly, and the provider returns 429 on sendTransaction.

Separating the buckets is a cheap policy decision that removes an entire failure mode. On Subglow, Sniper gets 2k sendTx/day and Pro gets 20k, completely independent of your read quota. Read path spiking has no effect on your submit budget.

Method allowlist: why archival is Dedicated-only

One thing we explicitly did not do: make everything available on every tier. Archival JSON-RPC methods — getProgramAccounts without filters, historical getBlock, wide getSignaturesForAddress scans — are gated to the Dedicated tier.

This isn't a capacity grab. It's a latency protection. One unfiltered getProgramAccounts scanning the full Pump.fun program state takes ~4 seconds of dedicated node CPU and walks dozens of GB of accounts data. Running that on shared infrastructure silently degrades every other customer's p50 — including yours, if you happened to be the one doing the read.

We'd rather reject the request with a clear error than silently throttle and miss the root cause. If your workload needs archival, Dedicated provisions archival capacity sized for your traffic.

How we actually build it

Under the hood, the JSON-RPC gateway is a thin Rust reverse proxy. It:

Resolves your API key against our own API (with an in-memory cache, so it hits Neon Postgres once per 60s per key).
Checks two Redis counters — total RPC requests today and sendTransaction today — against your plan's caps.
Validates the JSON-RPC method against an allowlist keyed to your plan.
Forwards the request to our edge RPC backends.
Pipes the response straight back.

The gRPC gateway is similarly structured, with the added complexity of bidirectional streams. It speaks the Yellowstone protocol so your existing client code — @triton-one/yellowstone-grpc, yellowstone-grpc-client, grpcio + protobuf — works unchanged.

Both gateways write usage counters back to Postgres every ~30 seconds so the dashboard view stays current.

What this changes for existing Subglow users

If you already have a Sniper or Pro plan:

Your gRPC setup didn't change. Same endpoint, same filters, same API key.
Your plan now includes the RPC quota listed on the pricing page, effective immediately.
Your dashboard at /dashboard/usage now shows two bars — gRPC messages and JSON-RPC requests — plus a third counter for sendTransaction.
Point your existing JSON-RPC client at https://rpc.subglow.io/<apiKey> to start using it. The connection docs at /docs/rpc have copy-paste snippets for TypeScript, Python, and Rust.

If you're evaluating Subglow for the first time, the short version is: one plan, one API key, gRPC + JSON-RPC bundled. Compare that to stacking two providers with overlapping credit pools and figure out which math ends up cheaper for your actual traffic pattern.

Why Subglow Bundles JSON-RPC With gRPC (And Why sendTransaction Lives In Its Own Bucket)