How we verify RPC provider pricing: sources, dates and a 45-day freshness rule

Many "best RPC provider" articles are written by a provider, and many of them rank their author first. That is not necessarily dishonest, but it makes them hard to use: the reader cannot tell which numbers were read from a public page last week, which were remembered from last year, and which were measured under conditions only the author controls. Alchemy's "best Base RPC provider" benchmark (read 2026-09-22) is an example of the genre: its author comes first, its tables carry no per-provider source links, and it compares no pricing. (It is a performance benchmark; we cite it only for how it is sourced, not for any of its results.)

We also sell RPC access, so our comparisons deserve the same suspicion. This post describes the rules behind our provider comparisons, our per-provider profiles such as Helius, and the monthly RPC pricing index, so you can decide how far to trust them — and check them yourself.

The problem with vendor listicles

Three things go wrong in comparison content, and each has a mechanical fix.

1. Unsourced cells. A table says "Provider X: 25 RPS" with no link. The fix is a source per cell, not per article.
2. Silent aging. Prices and limits change; an article dated this year may carry last year's numbers. The fix is a date per cell, and a build that notices when those dates get old.
3. Unfalsifiable measurements. Speed tests depend on where the client runs, which methods it calls and when. The reader cannot reproduce them. The fix, for us, is to leave them out.

The rest of this post is how those fixes are implemented.

Rule 1: a source URL per cell

Competitor facts live in one dataset of 15 providers. Every price row carries two fields besides the numbers: source_url, the public page the figure was read from, and last_verified, the day someone read it. All 33 price rows have both. Providers that we describe in more detail — Alchemy, Ankr, Chainstack, Helius, QuickNode and Triton One — also have a catalog block, where each cell (billing model, free plan, chains, streaming, archive, WebSocket, throughput) carries its own URL and date, because one provider's pricing page and its docs are often read on different days.

On the pages, the sources are visible. In the pricing index every table cell has a numbered marker that resolves to its URL and the date it was read, and the same rows are downloadable as CSV. A per-cell source is also why some rows say less than you might expect: the per-call weight of a provider's heavier methods is left unset when the full list was not read, and the calculation that uses it is labelled as a lower bound.

The dataset contains public information only: every figure is taken from the provider's own public site or documentation.

Rule 2: a date per cell, and the older side wins

A comparison page is built from two sources: the competitor's facts and ours. Early versions of our compare pages dated the page with our own fact date. The result was a page that said "last updated" last week at the top while the competitor figures underneath were months older — technically true, and misleading.

Now the date shown at the top of a comparison is the older of the two sides' verification dates. The page is only as current as its staler half, and that is the date it claims. Best-provider pages built from several providers take the oldest date among every cell they show.

The pricing index applies the same idea to the whole snapshot: each monthly file records the day it was taken (asOf), and a provider enters that month's snapshot only if every cited cell is within 45 days of it and has an https source.

Rule 3: the freshness gate

Dates are only useful if something acts on them. Our test suite includes a freshness gate over the provider dataset: it fails when any provider, any price row or any catalog cell has a last_verified date more than 45 days old, when a date is missing or malformed, or when a date is in the future (with one day of slack for time zones). Forty-five days is the monthly refresh cadence plus two weeks of margin.

When the gate fails, the message names the provider, the plan or cell, and its age, and says what to do: re-check the source URL, update the figure if it changed, bump the date. The only honest way to make it pass again is to read the source. That means a stale competitor price does not linger on the site because nobody remembered it: the test suite goes red until someone re-reads the page.

The same rule decides what the pricing index may claim. A research dataset is indexable by search engines only when its latest snapshot is typed as a sourced public dataset, contains at least one third-party row, and every cell of every row is sourced and fresh. An empty or stale snapshot keeps the page out of the index.

How the pricing index turns prices into comparable numbers

Published plans are not directly comparable: one sells credits, another compute units, a third calls per second. The index adds one derived view on top of the sourced cells — the monthly cost of a sustained load of 25 and 100 requests per second on Ethereum and Solana — and prints the arithmetic under every cell.

• A month is 30 days, so a sustained rate r is r × 2,592,000 requests.
• For a credit or compute-unit plan, requests are multiplied by the provider's published per-call weight, and the cheapest plan whose rate limit covers the load is chosen, including overage where the provider sells it.
• For a pay-per-call rate, the cost is requests × the published price per million.
• For our own plans, the cost is the cheapest plan whose read limit covers the load, taken from the same plan matrix that powers the pricing page and the rate limits reference.
• The per-million figure is simply that monthly cost divided by requests in millions.

Trials and free plans are excluded from the entry-plan column, and our own free plan is always named for what it is: a 7-day trial. Our row is labelled as ours, comes last, and links to our plans; competitor rows are alphabetical, and the page uses no ranking or score language. To estimate a bill for your own method mix rather than a flat sustained load, use the RPC cost calculator.

What we deliberately do not compare

• Response times and speed rankings. A speed figure is a measurement of one client, in one place, calling one method mix at one time. Readers cannot reproduce it, and a vendor's own figure is the least checkable of all. We do not publish them for competitors or for ourselves.
• Uptime. Status pages are self-reported and define incidents differently. The index carries no uptime figures.
• Providers we have not re-read. Nine of the 15 providers in the dataset are named in the index as "not re-read for this snapshot" and are not priced, because we have no sourced per-call weight for them. They appear when their pages are read and dated, not before.
• Anything we cannot source. An undated number from memory, however likely, does not ship.

What we do compare is what a buyer can verify: plan prices, billing units and per-call weights, included volume, rate limits per plan, supported chains, and the cost of the same sustained load under each published model. Our own side of that — flat monthly plans limited only by requests per second, with no credits, compute units or overage — is stated from our Solana and Ethereum limit references, which are the same numbers our gateway enforces.

How to check a fact yourself

1. Find the cell on the index or a comparison page and follow its source marker to the provider's page.
2. Compare the figure with what the page says today, and note the date.
3. If they differ, the fact is wrong or out of date — whatever the cell's date says.

That last step is the point of the whole method. A table that tells you where every number came from and when can be proven wrong by anyone with a browser, which is exactly what makes it worth reading. The same method applies to our worked examples, such as the DAS cost comparison: every unit price in it has a URL and a date. For the general difference between the pricing models themselves, see RPC credits vs flat pricing.

When this is the wrong approach

• Your decision depends on performance from your own servers. Our comparisons will not answer it. Run your own test from your own region against your own method mix, with trial keys from each provider.
• You need contract terms. Public pages do not show negotiated enterprise pricing, discounts or support terms, and we do not guess at them.
• The snapshot is old. Each index month is a snapshot. If the page you read is from a month that has passed, the prices in it are history, not current terms.

Sources

1. Triport provider dataset: 15 providers; 33 price rows, each with source_url and last_verified; catalog blocks with per-cell sources for Alchemy, Ankr, Chainstack, Helius, QuickNode and Triton One. Published through /compare, provider profiles and the RPC pricing index (September 2026 snapshot, asOf 2026-09-22).
2. Triport freshness gate: 45-day maximum age per provider, price row and catalog cell; missing, malformed and future dates fail; comparison pages dated by the older of the two sides.
3. Triport pricing index method: 30-day month (2,592,000 seconds), sustained loads of 25 and 100 requests per second on Ethereum and Solana, cheapest covering plan, per-million cost; trial and free plans excluded from the entry-plan column; nine providers listed as not re-read.
4. Triport, rate limits and tiers, Solana limits and Ethereum limits: flat monthly plans, per-category RPS, no daily quota; pricing: 7-day trial.
5. Alchemy blog, post benchmarking "the best Base RPC provider" — https://www.alchemy.com/blog, read 2026-09-22 (speed comparison of four paid endpoints over one measurement window; no per-provider source links; no pricing comparison; author ranked first).