Current offer: every account has 1 reset chance(s) to top its balance back up to 30,000,000 CU in one click. New accounts start with 30,000,000 CU. Learn more →
Guides

Per-method pricing: reading CU and price per million calls

Understand BlockVectra's CU metering, method weight resolution rules, price per million calls formula, and how to estimate per-cycle usage and costs.

BlockVectra meters service usage on a per-method basis. Whether you query JSON-RPC methods or Data API endpoints across any supported chain, all usage is measured in standardized Compute Units (CU).

This guide walks through what a CU represents, the exact method weight resolution rules, how to convert CU weights into a price per million calls in USD, and how to estimate per-cycle costs.

What is a CU and why per-method pricing

According to the official Pricing page and the Terms of Service, CU and per-method metering are defined as follows:

  • Pricing page FAQ: "A CU (Compute Unit) measures the resources a call consumes: different JSON-RPC methods consume different amounts of CU based on their weight — a higher weight means more load on the node." In addition, the Pricing page intro states: "Usage is metered in CUs (Compute Units): each JSON-RPC method consumes a set number of CUs based on its weight. Usage is totaled across all chains, JSON-RPC and Data API combined."
  • Terms of Service: “"Compute unit" or "CU" means the unit in which we meter calls. The number of CU each method or data endpoint consumes (its "CU weight") is shown on the Pricing page.” Furthermore, “We meter your calls in CU: each method or data endpoint is metered at its CU weight. CU weights, the conversion between CU and billing units, and the price of billing units are as published on the Pricing page and in the Console at the relevant time, and may differ by method, product or network. Usage is totalled for each settlement period and deducted from your Credits; see the Pricing page for how settlement works. You can view your usage, charges and top-ups in the Console; usage figures may lag slightly.”

Why per-method pricing

As the Pricing page puts it, "a higher weight means more load on the node." CU weights therefore reflect the relative load each method places on the node: a higher-weight method consumes more CU per call, and its price per million calls scales accordingly.

Method weight resolution rules

When a client sends a request, how is its CU weight resolved? The API specification (x-rpc-methods.cu.resolution) defines the resolution precedence verbatim:

resolution: exact > longest prefix (pattern ending in *) > the '*' row

The Pricing page explains this matching order: "Resolved in order: exact method match → the longest matching prefix rule ending in * → the default weight for anything else."

The 3-tier matching process works as follows:

  1. Exact match: The system first checks the method weight table for an exact name match. For example, calls to eth_call, eth_getLogs, or data.block adopt the exact CU weight of their respective rows if a same-named row exists in the table.
  2. Longest prefix match (pattern ending in *): If no exact match exists, the system evaluates pattern rules ending with *, selecting the longest matching prefix. For instance, any debug trace method (such as debug_traceTransaction, debug_traceCall, or debug_traceBlockByNumber) matches the debug_trace* wildcard rule.
  3. Default wildcard match (the '*' row): If neither an exact match nor a prefix pattern matches, any unlisted JSON-RPC method falls back to the default * row weight. Note: The default * fallback applies only to JSON-RPC methods. Data API methods (prefixed with data.) do not use the default wildcard; requests outside available coverage return appropriate status codes and are not billed.

Converting CU per call to price per million calls

When planning infrastructure budgets, developers often measure costs in dollars per million requests.

Conversion formula

Under the platform pricing model:

  • Paid credits are denominated in billing units: units_per_usd (billing units per 1 USD).
  • Each billing unit contains a fixed number of CUs: cu_per_unit (CUs per billing unit).
  • Therefore, 1 USD provides units_per_usd × cu_per_unit total CUs.

When a method consumes a given CU weight per call, the price for one million (1,000,000) calls is calculated as:

Price per 1M calls (USD) = weight × 1,000,000 ÷ (units_per_usd × cu_per_unit)

For how settlement works, see the Pricing page.

Common methods price table

The table below lists representative methods across matching rules, showing their resolved weights and list price per million calls. All values are read and computed at build time from the platform plans API (GET /v1/plans):

Active Conversion Parameters

1 USD = 10,000 billing units, 1 billing unit = 1,000 CU (1 USD = 10,000,000 CU).

Formula: CU weight × 1,000,000 ÷ (10,000 × 1,000) USD.

MethodResolution RuleCU per callPrice per 1M calls (USD)
eth_blockNumberExact match1$0.1
eth_callExact match15$1.5
eth_getLogsExact match30$3
debug_traceTransactionPrefix match (debug_trace*)100$10
data.blockExact match5$0.5
* (Any other unlisted method)Default fallback (*)10$1

The CU weights and list prices above are dynamically read and calculated from the platform plans API (GET /v1/plans) at build time.

Billing boundaries: what is not billed

Understanding how CU weights are calculated is only half of the picture — developers also need to know which calls are free.

BlockVectra bills only upon response; early rejections are never charged. Because billing rules span HTTP status codes, JSON-RPC error codes, and Data API responses, this guide does not repeat every edge case. For the full table of rules and recommended developer actions, please refer directly to the dedicated guide:

👉 What is not billed: error codes and billing rules

How to estimate your per-cycle costs

Estimating per-cycle costs helps teams choose between the Free Plan allowance and upgrading to paid capacity:

1. Identify your method distribution and frequency

Break down your application's expected traffic by method:

  • Lightweight polling or sync checks (such as eth_blockNumber);
  • User-triggered contract calls (such as eth_call);
  • Event indexing or historical transfer queries (such as eth_getLogs or Data API transfer endpoints).

2. Use the official usage estimator

Rather than calculating manually, you can use the interactive estimator on the Pricing page:

👉 Go to the Pricing page usage estimator

Select your methods and enter daily call volumes. The estimator will calculate:

  • Total CU per usage cycle;
  • Share of the Free Plan cycle allowance;
  • Implied average calls per second;
  • Estimated cost at list price for usage exceeding the free quota.

3. Review the Free Plan guide

To see what the free allowance covers, refer to the Free Plan guide.

Next steps

On this page