[Supanode](https://supanode.xyz/)[Learn](https://supanode.xyz/learn)Translate RPC pricing into your actual workload

# Translate RPC pricing into your actual workload

Compare method weights, sustained load, bursts and billing periods using one request profile.

**On this page**[Start with a workload, not a request allowance](https://supanode.xyz/learn/rpc-credits-vs-flat-pricing#start-with-a-workload-not-a-request-allowance)[Convert sustained and peak traffic into weighted load](https://supanode.xyz/learn/rpc-credits-vs-flat-pricing#convert-sustained-and-peak-traffic-into-weighted-load)[Budget recovery without starving live requests](https://supanode.xyz/learn/rpc-credits-vs-flat-pricing#budget-recovery-without-starving-live-requests)[Read the actual burst policy](https://supanode.xyz/learn/rpc-credits-vs-flat-pricing#read-the-actual-burst-policy)[Handle 429 with a bounded read retry](https://supanode.xyz/learn/rpc-credits-vs-flat-pricing#handle-429-with-a-bounded-read-retry)[DAS sizing starts with method availability](https://supanode.xyz/learn/rpc-credits-vs-flat-pricing#das-sizing-starts-with-method-availability)[Check DAS peak RPS and page traffic independently](https://supanode.xyz/learn/rpc-credits-vs-flat-pricing#check-das-peak-rps-and-page-traffic-independently)[Compare credit, per-call and flat budgets on the same DAS workload](https://supanode.xyz/learn/rpc-credits-vs-flat-pricing#compare-credit-per-call-and-flat-budgets-on-the-same-das-workload)[Accept the plan against observable limits](https://supanode.xyz/learn/rpc-credits-vs-flat-pricing#accept-the-plan-against-observable-limits)[Sources](https://supanode.xyz/learn/rpc-credits-vs-flat-pricing#sources)

## Start with a workload, not a request allowance

A plan must satisfy both total usage and the pace of requests. A low monthly average can hide an overloaded refresh interval or a recovery job. Record raw calls, provider-defined weights, response bytes, concurrent requests and historical depth separately. A billing credit is not necessarily a rate-limit unit, and neither is a Solana on-chain compute unit.

All workload sizes, prices and example plan limits below are hypothetical planning inputs. They are not Supanode quotes, measured provider benchmarks or promised burst allowances. Use the current product Docs and pricing terms for an actual purchase.

## Convert sustained and peak traffic into weighted load

Measure calls by method over representative busy and quiet periods. Calculate the sustained requirement over the period your application must continuously serve, and retain short-window peaks separately. A daily average alone does not size an interactive service. Supanode documents method-specific RPC weights; copy the current weight for each exact method rather than assigning one unit to every call.

| Hypothetical method class | Weight per call | Sustained calls/s | Peak calls/s |
| --- | --- | --- | --- |
| Light read | 1 | 30 | 90 |
| Heavy read | 10 | 2 | 6 |

```
sustained_raw_rps = 30 + 2 = 32
sustained_weighted_units_per_second = 30*1 + 2*10 = 50
peak_raw_rps = 90 + 6 = 96
peak_weighted_units_per_second = 90*1 + 6*10 = 150
```

These two rates describe the same method mix at different load levels. Keep any separate heavy-method, send-TPS, subscription-update or connection limit in the model too. A JSON-RPC batch is a transport container: the protocol does not define how its individual calls are billed or admitted.

## Budget recovery without starving live requests

Assume replayable read work accumulates at 50 weighted units/s during a 120-second outage. The backlog is 6,000 weighted units. At 100 units/s of total usable capacity and 50 units/s of ongoing live work, only 50 units/s remain for recovery, so draining the backlog takes 120 seconds. If usable capacity is no greater than live demand, this queue cannot drain.

```
backlog = 50 * 120 = 6000 weighted units
required_recovery_rate = 6000 / 60 = 100 units/s
normal_live_plus_recovery = 50 + 100 = 150 units/s
peak_live_plus_recovery = 150 + 100 = 250 units/s
planning_capacity = 250 * 1.20 = 300 units/s
```

For a 60-second recovery target that can overlap the measured peak, this example needs 250 units/s before margin and 300 units/s with 20% added planning headroom. The extra 50 units/s is spare capacity, not a provider burst promise. Reserve a bounded recovery queue, prioritize live requests and verify the source still retains the missing interval. Recalculate if backfill methods have different weights, the outage loses unrecoverable data, or response parsing becomes the bottleneck.

## Read the actual burst policy

A fixed window, sliding window and token bucket admit short spikes differently. Ask what the budget is shared across, which window applies, whether weights consume it, and which independent concurrency or byte limits apply. A monthly allowance does not answer these questions.

For example, an idealized token bucket refilling at 100 units/s with capacity 200 units can admit at most its initial tokens plus the tokens refilled during an interval. Starting full, a three-second interval has an upper budget of 200 + 3\*100 = 500 units. A different arrival pattern, an initially empty bucket, other limiters or server capacity can reduce what is accepted. Bucket capacity is a count of tokens; it is not a guaranteed rate multiplier.

Amazon API Gateway documents token-bucket throttling as one implementation example. That does not describe Supanode. Supanode's current RPC limits document a 10-second sliding aggregation window and method weights; use those current terms and a representative trial to evaluate spikes. Do not infer a universal 2x burst, independent budgets per connection or unlimited heavy queries.

## Handle 429 with a bounded read retry

HTTP 429 signals rate limiting. Retry-After is optional; when present it can be a delay in whole seconds or an HTTP date. Keep the client clock accurate for date-based delays. A missing header does not mean retry immediately. Reduce offered load and apply backoff with jitter through a shared admission gate for workers that consume the same provider budget.

This Python 3.11+ example accepts an already configured async HTTPX client. It handles one read request, allows at most four total attempts and has a 20-second overall deadline covering I/O and sleeps. It never shortens a server-requested delay: if the delay exceeds the remaining deadline, the call times out and must be deferred. Authentication and the shared rate gate belong in the caller.

```
import asyncio
import random
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

READ_METHODS = {"getAssetsByOwner", "searchAssets"}


def retry_after_seconds(value):
    if not value:
        return None
    value = value.strip()
    if value.isascii() and value.isdigit():
        return float(value)
    try:
        when = parsedate_to_datetime(value)
        if when.tzinfo is None:
            when = when.replace(tzinfo=timezone.utc)
        return max(0.0, (when - datetime.now(timezone.utc)).total_seconds())
    except (TypeError, ValueError, OverflowError):
        return None


async def read_das(client, url, payload, *, budget=20.0):
    if payload.get("method") not in READ_METHODS:
        raise ValueError("This retry policy is for the listed read methods only")
    if not 0 < budget <= 20:
        raise ValueError("Overall budget must be greater than 0 and at most 20s")
    async with asyncio.timeout(budget):  # Python 3.11+; includes sleeps and I/O
        for attempt in range(4):  # four total attempts, not four retries
            response = await client.post(url, json=payload, timeout=5.0)
            if response.status_code != 429:
                response.raise_for_status()
                body = response.json()
                if "error" in body:
                    raise RuntimeError("Inspect the JSON-RPC error separately")
                return body
            if attempt == 3:
                break
            advised = retry_after_seconds(response.headers.get("Retry-After"))
            backoff = random.uniform(0.0, min(4.0, 0.5 * (2 ** attempt)))
            await asyncio.sleep(max(advised or 0.0, backoff))
    raise RuntimeError("Rate limit persists; defer work instead of looping")
```

An HTTP 200 response can still contain a JSON-RPC error, which needs its own classification. The example does not blindly retry those errors or transaction submissions. For a batch, match responses by id and retry only unresolved retryable reads. Stop the recovery worker or reschedule later when the attempt/deadline budget is exhausted; an immediate outer retry loop would defeat these bounds.

## DAS sizing starts with method availability

DAS is an indexed digital-asset API, not the standard Solana validator RPC method set. First confirm the provider exposes the needed DAS method, asset types, pagination options and freshness. This calculation does not announce a Supanode DAS product. A flat standard-RPC plan cannot be assumed to include DAS.

For a separate hypothetical wallet dashboard, suppose 2,000 wallets each have 350 relevant assets. Each wallet refreshes six times per day. Use pages of 100 records and assume this known, stable inventory needs four calls per refresh. Metaplex documents page/limit and cursor-related pagination options; confirm the chosen provider's actual implementation. Stable ordering, checkpoints and deduplication matter when ownership changes during a scan.

```
pages_per_refresh = ceil(350 / 100) = 4
calls_per_wallet_per_day = 4 * 6 = 24
calls_per_day = 2000 * 24 = 48000
calls_per_30_days = 48000 * 30 = 1440000
average_DAS_rps = 1440000 / (30 * 86400) = 0.556
```

This count excludes extra getAsset/getAssetProof calls, discovery queries and retries. If a pagination implementation needs an additional terminal request or a rescan, add those calls explicitly. Caching repeated wallet results can lower refresh traffic, but cache invalidation and proof freshness must still match the application.

## Check DAS peak RPS and page traffic independently

Now assume 100 of those wallets refresh within the same 10 seconds. Four pages each produce 400 requests, or 40 DAS calls/s over that interval. The 0.556 monthly-average RPS did not reveal this peak. If the requests arrive within one second instead, that peak is 400 calls/s. Stagger refresh starts and pace page requests; a window average alone does not constrain sub-second arrivals.

Suppose the hypothetical service charges 20 billing credits per DAS call but consumes five rate-limit units per call. These are deliberately separate assumptions. The monthly baseline is 28.8 million billing credits, while the ten-second peak needs 200 admission units/s. With 20% planning headroom, check at least 48 DAS calls/s and 240 admission units/s, plus any shared load.

```
baseline_credits = 1440000 * 20 = 28800000
peak_rate_units = 40 * 5 = 200 units/s
mean_response_payload = 250000 bytes per page  # assumed measured mean
monthly_payload = 1440000 * 250000 = 360 GB
peak_payload_rate = 40 * 250000 = 10 MB/s = 80 Mbit/s
with_20_percent_headroom = 12 MB/s = 96 Mbit/s
```

GB and MB here use decimal units. The 250 kB mean is a scenario assumption, not a fixed DAS response size. Measure compressed wire bytes and decoded memory separately, including the effect of display options and partial pages. Network headers, TLS overhead and off-chain metadata downloads add traffic. Larger pages reduce call count but can increase latency, memory and timeout risk; run the same inventory with another supported page size and recheck both axes.

## Compare credit, per-call and flat budgets on the same DAS workload

The following fictional offers all use a 30-day period and the same 1.44 million baseline DAS calls. For a sensitivity case, add 10% chargeable repeated calls: 1.584 million calls and 31.68 million credits. Assume those repeated calls transfer full responses when estimating an upper workload of 396 GB. This is a planning reserve, not a measured error rate.

| Fictional offer | Baseline calculation | With 10% extra chargeable calls |
| --- | --- | --- |
| Credit: $45 includes 20 million credits; $3 per extra million; 20 credits/call | $45 + (28.8 - 20)\*$3 = $71.40 | $45 + (31.68 - 20)\*$3 = $80.04 |
| Per-call: $0.00006 for each DAS call | 1,440,000\*$0.00006 = $86.40 | 1,584,000\*$0.00006 = $95.04 |
| Flat: $82 includes DAS, 50 DAS calls/s, 250 admission units/s and 500 GB | $82 if every stated limit fits | $82 if every stated limit still fits |

The fictional flat offer clears this scenario's paced 48-call/s and 240-unit/s targets, and its 500 GB allowance exceeds the 396 GB reserve. That alone does not establish enough instantaneous burst capacity, concurrent queries or receiver bandwidth. The credit and per-call offers need the same capacity checks before their lower or higher bill is meaningful. Check how each actual provider charges failed calls, retries, optional fields and egress; do not mix credit weights from one provider with another provider's prices.

## Accept the plan against observable limits

1.  Capture per-method calls, weighted admission usage and transferred bytes during a representative peak.
2.  Run a bounded recovery job beside live traffic and measure how long its queue takes to drain.
3.  Verify 429 handling, Retry-After behavior and the shared rate gate without submitting real transactions.
4.  Check monthly volume, peak DAS RPS, method weights, concurrency, payload size, egress and retention as independent acceptance conditions.
5.  Record the exact product, billing period, included methods and check date. A protocol feature or a price headline cannot substitute for this contract.

## Sources

-   [Supanode RPC method weights](https://supanode.xyz/docs/solana/rpc/whats-available)
-   [Supanode RPC aggregation window and rate limits](https://supanode.xyz/docs/solana/rpc/limits)
-   [JSON-RPC 2.0 batches](https://www.jsonrpc.org/specification#batch)
-   [RFC 6585 section 4: HTTP 429](https://www.rfc-editor.org/rfc/rfc6585#section-4)
-   [RFC 9110 section 10.2.3: Retry-After](https://www.rfc-editor.org/rfc/rfc9110.html#section-10.2.3)
-   [Amazon API Gateway token-bucket example](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
-   [Metaplex DAS pagination](https://www.metaplex.com/docs/dev-tools/das-api/guides/pagination)
-   [Metaplex getAssetsByOwner parameters](https://www.metaplex.com/docs/dev-tools/das-api/methods/get-assets-by-owner)
-   [Metaplex DAS display options](https://www.metaplex.com/docs/dev-tools/das-api/display-options)

## Continue reading

[Understand the Solana DAS API](https://supanode.xyz/learn/solana-das-api)[Handle JSON-RPC batches](https://supanode.xyz/learn/json-rpc-batch-responses)[Historical state and transaction history](https://supanode.xyz/learn/archive-node-vs-full-node)[Current Solana RPC limits](https://supanode.xyz/docs/solana/rpc/limits)

---
Source: https://supanode.xyz/learn/rpc-credits-vs-flat-pricing