Bitcoin RPC Node Providers Compared: Best for Wallet and Exchange Teams

Choosing a Bitcoin RPC provider usually turns into a spreadsheet of prices, regions and requests per second. That comparison is fine as far as it goes, and it misses the thing that actually decides whether the provider can do your job. A managed Bitcoin node is not a database. It answers questions about blocks and transactions, and it cannot answer questions about addresses, because Bitcoin Core does not keep an address index. Providers then narrow the surface further by disabling expensive calls, and each one signals that differently.

So we measured it rather than reasoning about it.

What we called

On 1 September 2026 we sent JSON-RPC requests to every public Bitcoin endpoint we could reach without an API key, from one US machine, inside a few minutes. Eight providers were tried. Three answered: QuickNode's documentation endpoint, PublicNode (operated by AllNodes, which its own error messages name) and the Tatum gateway. Ankr, NOWNodes, GetBlock, Blockdaemon and Chainstack all required a key, returning 401, 404 or 422.

All three that answered reported the same tip, block 965,040, which is a useful sanity check that we were talking to real mainnet nodes rather than a cache.

Two details in that table are worth pausing on. The nodes are two major Core releases apart, 31.1.0 against 29.3.0, while sitting on the same block. And the Tatum gateway answered five calls before returning HTTP 429 with a body stating a limit of 5 requests per minute, which is honest and clearly documented in the response itself, but it is a demo rather than something to build against.

Which Bitcoin RPC methods actually work?

We ran the same 31 methods against QuickNode and PublicNode. Tatum rate limited before the matrix could complete, so it is excluded from this comparison rather than represented by partial data.

The last row is the one to remember. generatetoaddress is a regtest mining call that has no business succeeding on public mainnet infrastructure. On QuickNode it is refused. On PublicNode it returned HTTP 200 with a well formed body whose result is an empty array. Nothing errored. A client that branches on "did this call return an error" concludes it worked and mined nothing.

Why does getbalance not work on a Bitcoin node?

Because Bitcoin has no account balances to look up. The ledger is a set of unspent transaction outputs, and Bitcoin Core indexes those by transaction id and output index so it can validate spends quickly. There is no map from address to coins, so when you hand a node an address it genuinely has nowhere to look. A balance is a derived figure: find every output ever paid to that address, subtract the ones already spent, and sum the rest. Building and maintaining that derivation is what a Bitcoin address balance API does for you, and it is the work every provider that answers address questions has quietly done.

The getbalance call in Core is a wallet method. It reports the balance of the node's own wallet, not of an arbitrary address, so even a node that exposed it would not answer the question people are asking.

Can I look up a Bitcoin address balance with an RPC node?

In principle once, with scantxoutset and an addr() descriptor, which sweeps the entire UTXO set looking for matching outputs. In practice, no, because that sweep takes seconds of full-throttle disk and CPU per call and no shared provider will let you do it. QuickNode refuses it explicitly with HTTP 400 and error -32604. PublicNode simply never responded inside our 12 second timeout. Both are defensible; the effect for you is identical.

It is also worth knowing that even if it ran, scantxoutset only sees currently unspent outputs. It cannot give you an address's transaction history, its first-seen date, or a balance as of a past block, because spent outputs are not in the UTXO set at all. History needs a full index over every block, which is a different piece of infrastructure entirely.

What do the Bitcoin RPC error codes mean?

This is where provider-agnostic code quietly breaks. There is no shared contract for "this method is unavailable here". Across two providers we collected four distinct signals for what is conceptually the same refusal:

• -32601 Method not found inside an HTTP 200 response, the standard JSON-RPC code, used by QuickNode for wallet and address methods.
• -32604 this request method is not supported with HTTP 400, used by QuickNode for calls it deliberately blocks.
• -32701 Method X is not allowed with HTTP 501, used by PublicNode, with a message pointing you at a dedicated node product.
• HTTP 429 with a plain JSON body and no JSON-RPC error object at all, from the Tatum gateway when the free limit is exceeded.

Add HTTP 503 (PublicNode's answer to stop) and the HTTP 200 empty result above, and a client that only checks the HTTP status will mishandle at least three of these. If your code talks to more than one provider, or you might switch providers later, treat "unavailable" as a set of cases rather than one, and assert on the shape of the result rather than the absence of an error. The same discipline applies to any third-party endpoint your pipeline depends on: it is worth having something that watches the endpoint and tells you when its answers change, because a provider quietly tightening a method list does not look like an outage.

Which Bitcoin RPC provider is best for a wallet or exchange team?

Split the decision by what the call does rather than by vendor.

For writes, use a node provider and pay for it. Broadcasting, mempool acceptance testing, live fee policy and block templates all need a real node with real peers, and this is what QuickNode, Chainstack, Blockdaemon and the rest are genuinely good at. QuickNode's public endpoint answered every write-adjacent read we tried and exposed the most node introspection of the three. Our fuller breakdown of its surface and current pricing is on the QuickNode Bitcoin API alternative page, and the equivalent read of Alchemy's Bitcoin offering, which has no ordinals or runes product at all, is on the Alchemy Bitcoin API comparison.

For reads that start with an address, do not shop for a node at all. No configuration of any node provider will answer "what does bc1q... hold", "what did it hold in March", or "which addresses received from this cluster". Those are index questions. That is what a hosted Bitcoin node API with an index behind it exists for, and it is why teams commonly run both: a node provider for the write path, an indexed database for the read path.

For free endpoints, use them for exactly what they are. PublicNode was the fastest thing we measured at a 0.043 second median, which is genuinely impressive for a free service, and it is fine for a health check or a block height poll. It also blocks node introspection and gave us that HTTP 200 empty result. Do not put a product on it.

Do I need a Bitcoin node provider or an indexed API?

Answer three questions. Does your product broadcast transactions? If yes, you need node access, full stop. Do your queries begin with an address, an xpub, a balance, a UTXO set or a date range? If yes, you need an index, and no node plan will substitute. Do you need both? Most wallet and exchange teams do, which is the honest answer even though it means two line items.

The cost comparison people usually skip is self-hosting. Running your own unpruned node with an address index is not just the node: our own measurement put a production-grade setup in AWS at roughly $390 to $430 a month, and the nodes we probed were carrying about 872 GB of chain each before any index is layered on top. That is before the engineering time to keep an indexer from silently drifting behind the tip, which is the failure mode that actually hurts. We wrote up the full arithmetic in how much it costs to run a Bitcoin node, and the architectural trade-off in Bitcoin RPC versus a REST API.

What we did not measure

Being clear about the limits of this is more useful than overselling it. These were public demo and free endpoints, not the paid production tiers our readers would actually buy, and a demo endpoint's method list and a paid endpoint's method list are not required to match. Latency figures come from one US machine at one moment, seven calls each, so read them as an order of magnitude and not a benchmark. We tested 31 methods, not the full Core surface. And Tatum is represented here only by its rate limit, because we deliberately did not keep hammering a free gateway to fill in a table.

What does generalize is the structural part, and it does not depend on any of those caveats: Bitcoin Core has no address index, the one call that could work around that is too expensive for shared infrastructure, and so every managed node is missing the same half of the problem. If your roadmap has address history, balance snapshots, UTXO sets or holder cohorts in it, plan for an indexed Bitcoin blockchain API from the start rather than discovering the gap after you have built against RPC. For the wider field, including pricing and rate limits across the main providers, see our comparison of the best Bitcoin APIs.

All figures above were measured on 1 September 2026 from a single US machine. Informational on-chain data and engineering notes only, not financial or investment advice.