Policy decisions on RPC gateways usually look like arbitrary upsell tactics from the outside. This post is the inside version — why we restrict certain JSON-RPC methods to the Dedicated tier, what's in the shared-tier allowlist, and why the line falls where it does.

The short version

Subglow's JSON-RPC gateway has a static allowlist with two tiers:

Standard — allowed on every paid plan (Sniper, Pro, Dedicated). Cheap, bounded methods.
Archival — allowed only on Dedicated. Expensive, unbounded methods that can starve shared infrastructure.

Anything not in the allowlist is rejected with -32001 method-not-allowed. The allowlist is not a rate-limiting surface — it's a capacity-protection surface. Rate limiting is a separate enforcement layer (the daily quotas) and fires after the allowlist check.

The standard allowlist

Every paid plan, including Sniper, can call these methods without restriction (subject to daily request caps):

Account + balance reads:

getAccountInfo
getMultipleAccounts
getBalance
getTokenAccountBalance
getTokenAccountsByOwner
getTokenAccountsByDelegate
getTokenSupply
getTokenLargestAccounts

Slot / block / epoch:

getSlot, getSlotLeader, getSlotLeaders
getEpochInfo, getEpochSchedule, getLeaderSchedule
getBlockHeight, getLatestBlockhash, isBlockhashValid
getFirstAvailableBlock, getGenesisHash, getIdentity

Fees + simulation:

getFeeForMessage, getRecentPrioritizationFees
simulateTransaction

Transaction reads (bounded):

getTransaction (recent)
getTransactionCount

Submits:

sendTransaction, sendRawTransaction (counted in a separate bucket)

This covers every method a typical Solana trading bot, copy trader, or sniper needs. If your workload stays inside this list, you never have to think about the gating.

The archival allowlist (Dedicated-only)

These methods are gated to Dedicated:

getProgramAccounts
getSignaturesForAddress
getBlock, getBlocks
getConfirmedBlock, getConfirmedBlocks, getConfirmedSignaturesForAddress2, getConfirmedTransaction (deprecated names)
getParsedTransaction
getAssetsByOwner, getAsset, searchAssets (DAS API)

Calling any of these on Sniper or Pro returns:

{"error":{"code":-32001,"message":"archival-disabled: <method> requires Dedicated plan"}}

Why this specific list? Each entry has a specific failure mode on shared infrastructure.

getProgramAccounts without filters

The single most expensive RPC method on Solana. A naive call against the Pump.fun program iterates the full accounts index, returns gigabytes of data, and takes ~4 seconds of dedicated node CPU. Running that on a shared backend means every other customer's p50 latency — including, crucially, your p50 latency on other methods — jumps for those 4 seconds.

The failure mode is silent. Nothing visible breaks; your dashboard shows a mysterious latency spike that correlates with nothing you did.

We could try to protect shared infra with query-time limits and rejection heuristics, but the accurate policy is: if you need getProgramAccounts, you need provisioned capacity, which is what Dedicated gives you.

getSignaturesForAddress

Returns the signature history for an account. On a hot account — say, a popular AMM pool — that's hundreds of thousands of signatures, scanned sequentially. Same class of problem as getProgramAccounts: unbounded response size, long node CPU occupation.

getBlock / getBlocks

Scales with block size. A congested Solana block has thousands of transactions; deserializing and returning the full block eats RAM and bandwidth. Historical getBlock lookups also require archival nodes with older slot data, which is a different class of infrastructure than the edge nodes serving reads.

DAS API (getAssetsByOwner, searchAssets)

The Digital Asset Standard is a separate index. It's not the validator's native state; it's a derived database that providers build by ingesting mint and metadata events. Running DAS on shared capacity is cheap-ish, but "cheap-ish and unbounded" is still a capacity risk, and most of our Sniper / Pro customers don't need NFT indexing. Dedicated customers get it as part of their provisioned stack.

What happens when the allowlist rejects a method

Rejection is fast and explicit. The gateway parses the method name, compares against the allowlist, and returns a standard JSON-RPC error before forwarding anything upstream. You don't get charged (the daily cap doesn't increment for rejected requests), and you don't wait for a timeout — rejection is synchronous.

The error codes we use:

-32001 method-not-allowed — the method isn't in any tier's allowlist. Either it doesn't exist in Solana RPC or it's not something we proxy.
-32001 archival-disabled: <method> requires Dedicated plan — the method is valid but gated to Dedicated.
-32005 rpc-quota-exceeded — the method is allowed but you hit your daily cap.
-32005 send-tx-quota-exceeded — same, but for the separate sendTransaction bucket.

Why not just charge more per archival call?

This is the obvious alternative — let everyone call getProgramAccounts and charge credits. Most competitors do exactly this. Two reasons we don't:

1. Credit pricing hides the capacity problem. A customer sees a big bill and assumes they're paying for speed. They're actually paying for a method that's silently degrading everyone else's latency. Credits don't surface that; dedicated capacity does.

2. Credit pricing ties the billing model to the capacity model. We run flat caps. A per-method credit surcharge on archival would force us to reintroduce credit math for this one case, which defeats the point of flat caps. Gating is the cleaner product boundary.

What if I legitimately need archival on a shared plan?

Honestly: you don't, for most workloads. Work through the pattern:

Need historical transaction data? Stream via gRPC in real time and index it yourself. One-time historical backfill is a Dedicated use case.
Need NFT ownership queries? DAS on Dedicated, or use an NFT-specific provider.
Need to enumerate token holders? getTokenAccountsByDelegate and getTokenLargestAccounts are both in the standard allowlist.

If you've worked through those and still need raw archival, talk to us. Dedicated is custom — we size the archival surface to your actual query pattern instead of giving you a generic "yes" and watching you exhaust it on week one.

Why Archival JSON-RPC Methods Are Dedicated-Only on Subglow (And the Full Allowlist)