Solana RPC Rate Limits Explained

If your Solana app starts returning 429 Too Many Requests, the fix is usually not "retry faster". It is to understand the difference between your requests-per-second ceiling, your monthly credit budget, and the way your client handles bursts.

This page explains the published Carbium RPC limits, how they relate to real workloads, and how to handle throttling safely for wallets, bots, and backend services.

Part of the Carbium full-stack Solana infrastructure stack.

Carbium RPC limits by plan

Carbium publishes both a monthly credit quota and a requests-per-second cap for each RPC tier:

These figures are reflected in Carbium's published pricing and internal skill documentation used for docs maintenance.

Rate limits vs monthly credits

Developers often mix these up, but they solve different problems:

In practice:

• A wallet or dashboard can stay well within monthly credits and still trigger 429 responses during a short burst.
• A bot can stay under the RPS cap but still exhaust its monthly credits if it runs constantly.
• Higher tiers increase both the long-term budget and the short-term throughput ceiling.

Which endpoints use your RPC key

Carbium's RPC key covers both the standard JSON-RPC endpoint and the streaming endpoint:

gRPC access requires the Business tier or above.

What a 429 means

A 429 Too Many Requests response means your client sent traffic faster than your current plan allows. It does not automatically mean:

• your API key is invalid
• Carbium is down
• the Solana method itself is broken

For Carbium, the operational guidance is straightforward:

Safe retry pattern for Solana clients

When you hit rate limits, the goal is to reduce pressure instead of amplifying it.

Good retry behavior

• Use exponential backoff.
• Add jitter so many workers do not retry at the same time.
• Separate read traffic from write traffic if possible.
• Cache hot reads such as balances, recent slots, and token metadata.
• Queue bursty background jobs instead of firing them all at once.

Dangerous retry behavior

• Blindly retrying every failed request in parallel.
• Retrying sendTransaction without first checking whether the transaction already landed.
• Polling aggressively from browser clients with shared API keys.

For transactions specifically, Carbium's internal guidance is:

Do not blindly retry sendTransaction until you have checked getSignatureStatus.

Example: JSON-RPC with a basic backoff

const RPC_URL = `https://rpc.carbium.io/?apiKey=${process.env.CARBIUM_RPC_KEY}`;

async function rpcCall(method: string, params: unknown[] = [], retries = 5) {
  let delayMs = 500;

  for (let attempt = 0; attempt <= retries; attempt++) {
    const res = await fetch(RPC_URL, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        jsonrpc: "2.0",
        id: 1,
        method,
        params,
      }),
    });

    if (res.status !== 429) {
      return res.json();
    }

    if (attempt === retries) {
      throw new Error("Rate limit exceeded after retries");
    }

    await new Promise((resolve) => setTimeout(resolve, delayMs));
    delayMs = Math.min(delayMs * 2, 10_000);
  }
}

This pattern is intentionally simple. For production workloads, add jitter and centralize request budgeting so multiple workers do not compete blindly.

Choosing the right tier

The right plan depends on traffic shape, not only on total volume.

If you are evaluating Carbium specifically for trading bots, stream processors, or low-latency infra, the important threshold is that gRPC starts at Business.

How to reduce rate-limit pressure

Before upgrading, check whether your client is wasting requests:

1. Reuse a single RPC connection pool instead of creating new clients for every job.
2. Cache responses that do not need sub-second freshness.
3. Replace constant polling with streaming where that fits your architecture.
4. Monitor which methods consume the most traffic in the Usage dashboard.
5. Split environments so development traffic does not compete with production traffic.

When to move up a tier

Move up when one of these becomes true:

• you see recurring 429 responses during normal operation, not only during tests
• your workload needs gRPC / streaming access
• multiple teams or services share one key and compete for the same budget
• your monitoring shows that throughput spikes are part of normal traffic

📘

Need more than a free test endpoint? Review the published limits in RPC Pricing and Usage Tiers before you scale traffic patterns that depend on burst throughput.

🔶

Building a wallet, trading bot, or Solana backend? Compare plans and start with Carbium at carbium.io.