If you've ever tried to forecast your Solana RPC bill more than a week out, you know the game. You estimate your normal traffic, you add a safety margin, you pick a credit-metered plan. Then a Pump.fun cycle hits, your scanner fires 10× more account reads, and the first of the month you open an invoice 40% higher than you budgeted.

This post breaks down why credit metering does that, where the silent overcharges hide, and why we run Subglow JSON-RPC on flat daily caps instead.

What credit metering actually is

The typical Solana RPC provider assigns a "credit weight" (or "compute unit cost", or "CU") to every JSON-RPC method based on how expensive that method is to serve. Numbers are not standardized, but the shape is roughly:

getAccountInfo — 1 credit
getBalance — 1 credit
getLatestBlockhash — 2 credits
sendTransaction — 5–10 credits
getSignaturesForAddress — 10–15 credits
getBlock — 15–30 credits
getProgramAccounts — 20–100+ credits (some providers charge per byte returned)

Your plan has a monthly credit bucket. Every call drains some credits. When the bucket is empty you either get throttled or your next tier auto-renews.

On paper the design sounds fair — heavy methods cost more, so heavy users pay more. In practice it has three consequences that almost nobody models correctly before they sign up.

Consequence 1: Your bill is a function of market volatility

Your Solana bot's traffic pattern isn't a flat line. It's a spiky curve that tracks meme-coin activity, Pump.fun graduation waves, airdrop days, and big liquidation events.

During normal weeks your scanner might fire 10k getAccountInfo calls and 200 sendTransaction calls per day. That's about 12k credits — comfortably under a mid-tier plan.

During a graduation wave, your scanner is polling account states 5× harder to confirm new Raydium pools. 50k getAccountInfo calls, 15k getTokenAccountsByOwner, 20k getProgramAccounts to enumerate active pools, 1k sendTransaction. With typical weights: 50k×1 + 15k×3 + 20k×40 + 1k×5 = 900k credits in one day. You'll exhaust a $50/mo plan before lunchtime.

The punishing part isn't the volume — it's the weighting. getProgramAccounts at 40× inflates your spike into a bill rollover.

Consequence 2: The pricing model punishes exactly the workloads Solana is good at

Solana's whole selling point is cheap, high-frequency state reads. You're supposed to be able to check 1000 token balances in a single poll without thinking about it. Credit metering inverts that incentive: heavy reads are expensive, so the pricing model nudges you toward building a slower, poll-averse bot.

The workarounds are well-known and all bad:

Cache aggressively and hope your cached data isn't stale enough to cost you a trade.
Polygon your reads into getMultipleAccounts batches — better, but still credit-scaled.
Push as much logic as possible into streaming, which is where gRPC wins — but now you're running two providers.

Flat-rate pricing removes the "cache to save money" pressure. If every call costs the same fraction of your daily cap, you call whatever you actually need. Your bot is simpler.

Consequence 3: Credit math is nearly impossible to simulate

Try this exercise before committing to a credit-metered plan: estimate your monthly bill.

You need:

Per-method call rate, broken down by method.
Per-method credit weight (which the provider may change).
An assumption about traffic spikes.
An assumption about response size for byte-scaled methods like getProgramAccounts.

Most teams give up and pick a plan based on the marketing page, then discover the real number 30 days later. The flat-rate answer is much cleaner: "I do ~X requests/day, which plan includes X? That one."

The Subglow model

Every Subglow plan includes a flat daily JSON-RPC cap — see the pricing page for the current numbers. Every method in the standard allowlist counts as one request. It doesn't matter whether it's a getBalance or a getTokenAccountsByOwner — one request, one count.

sendTransaction is the one exception, and it's exceptional for operational reasons, not billing reasons. It has its own separate daily bucket so that a scanner spike can't starve your submit path. There's a separate post on why we built it that way.

Archival methods (getProgramAccounts without filters, wide getBlock / getSignaturesForAddress scans) are gated to the Dedicated tier — not because we want to upsell, but because running them on shared infra silently degrades every other customer's p50. More on that here.

When credit metering makes sense

Let's be fair. Credit metering isn't universally worse. It's better when:

Your workload is extremely read-heavy but your method mix is dominated by cheap methods like getAccountInfo.
You rarely spike — your traffic is predictable, not Pump.fun-correlated.
You're willing to pay for the flexibility of not committing to a tier.

In those cases, a credit plan can be cheaper than a flat plan. If that sounds like you, run the numbers. If it doesn't — if you're a sniper bot, a copy trader, a Pump.fun scanner, a Jupiter aggregator feeder — flat pricing is almost always the right call.

How to pick

Two questions:

Does my traffic spike with market conditions? If yes — flat.
Do I run methods with credit weights above 10×? If yes — flat.

Both yes? Definitely flat. Both no? Credit metering might squeeze a few dollars out. One yes, one no? Flat is the lower-risk bet because credit overruns are asymmetric — you can't underpay, you can only overpay.

Flat JSON-RPC Pricing vs Credit Metering: The Hidden Cost of "Compute Units" on Solana