How Fast Is Blockonomics? A Head-to-Head API Benchmark

Why This Matters

Every Bitcoin application depends on its API in ways that rarely get talked about.
A payment gateway. A wallet. A block explorer integration. All of them live or die by two things: how fast a call comes back, and whether the API holds up once real traffic hits it.

These aren't edge cases. They're the questions that actually decide whether an API is worth building on.

What We Tested

We picked four Bitcoin block explorer APIs: Blockonomics, Blockchain.com, Blockstream and Mempool.space”

For each one, we hit the three endpoints that almost every integration actually uses:

  • Balance lookup: checking the current balance of a wallet address
  • Address history: pulling the full transaction history for an address
  • Transaction detail: fetching the details of a single transaction by its ID

No synthetic test data. We used real, confirmed mainnet addresses and transaction IDs, the same kind of data any live application would be querying.

Then we measured two separate things.

Latency, how long a single request takes to come back. This matters most when a real person is waiting

Throughput, how many requests an API can actually handle per second when several calls are firing at once. This matters most when your app is under real load, not a quiet afternoon with one user.

Methodology

Latency

For each explorer and each endpoint, we sent the same request multiple times, one after another, and timed how long each one took to come back. We measured the average response time, p50 (median) and the p99(the slowest 1% of requests).

The average tells you what a typical call feels like. The p99 tells you what happens on a bad day, when the network hiccups or the API is under strain.

Throughput

Timing one request at a time tells you nothing about load. So for throughput, we sent several requests at once and kept adding more.

For each explorer and endpoint, we ran four tests: 1, 3, 5 and 10 requests sent at the same time. Each test ran for 8 seconds. As soon as one request got its answer, the next one went out. Then we counted how many came back successfully every second, and how many failed.

Every request used a random address or transaction from our test set. We waited 10 seconds between tests so one wouldn’t affect the next. If an API was already failing more than half its requests, we stopped adding more.

We kept the load low on purpose. These are public APIs with their own limits, and we wanted to see what a developer would run into in real use.

Results

Latency

First, the average response time for each endpoint.

Blockonomics had the lowest average on balance lookups (249 ms) and address history (289 ms).

Blockchain.com came second on both. On transaction detail, Blockchain.com had the lowest average at 406 ms, against 529 ms for Blockonomics.

Mempool.space sat in the middle. Blockstream was the slowest on every endpoint, averaging over a second on address history and transaction detail.

Averages can hide a lot, so here is the median.

This is where Blockonomics stands out. A typical balance request came back in 45 ms, and a typical address history request in 51 ms. The next best explorer, Blockchain.com, sat around 350 ms on both.

On transaction detail, Blockchain.com’s median was the lowest at 351 ms, and Blockonomics came in at 445 ms.

Notice the gap between Blockonomics's median (45 ms) and its average (249 ms) on balance lookups. Most requests were very fast, and a few slow ones pulled the average up. The slowest 1% shows how slow.

Blockchain.com had the tightest tail on balance (1,061 ms) and transaction detail (1,022 ms).

On address history, Mempool.space and Blockchain.com both stayed under 1,000 ms at p99, while Blockonomics reached 2,195 ms. Blockstream had the worst tail on transaction detail at 4,414 ms.

Throughput

Now the load test. First, the most requests per second each API returned at its best.

Peak Throughput by Explorer and Endpoint

On balance lookups and address history, Blockonomics returned the most requests per second: about 99 on balance and 59 on address history. Blockstream and Blockchain.com were at around 5 to 6 on both. Blockchain.com’s numbers came while many of its requests were being rejected, which we cover in Errors below.

On transaction detail, Blockstream returned 5.6 and Blockchain.com 5.4. Blockonomics returned 2.2 and Mempool.space 0.2.

Blockonomics handled far more traffic than anyone else on balance lookups and address history.

That’s the top number for each API. This next chart shows the whole run, from 1 request at a time up to 10, so you can see where each one levels off and where errors start.

Throughput as Concurrency Increases

Errors

Speed only counts if the requests actually work. We counted a request as failed if the API sent back an error, or if we got no answer within 10 seconds.


Blockonomics returned no errors at 1 or 3 requests at a time on any endpoint. On balance lookups and address history, the first failures showed up at 10 at a time: a handful of balance requests, and 2% of address history requests, got no answer in time. On transaction detail, 6% got no answer at 5 at a time and 43% at 10.

Blockchain.com has no bars at 10 requests at a time. That’s on purpose. Whenever an API failed more than half its requests at one level, we didn’t go any higher, and that happened with Blockchain.com on every endpoint.

Blockchain.com had errors from the very first test. At 1 request at a time, between 11% and 16% failed with a 503 error, which means the service was unavailable. At 3 at a time, between 35% and 42% failed, mostly with a 429 error, which means too many requests. At 5, between 51% and 65% failed.

Blockstream returned no errors in any of its 12 tests.

Mempool.space started returning 429 errors on balance lookups at 5 at a time, with 13% of requests failing, and 48% at 10. Address history and transaction detail show 0% in the chart, but only between 1 and 10 requests finished in each 8 second test, so those zeros don’t tell us much.

Conclusion

Blockonomics was fastest for a typical balance or address history request, and it returned the most requests per second on both under load.
On transaction detail, Blockchain.com and Blockstream did better.
Blockstream was the slowest on latency, but it returned no errors in any test, while Blockchain.com started failing requests from the first one.

Mempool.space sat in the middle on latency. Under load it began returning rate limit errors at 5 requests at a time on balance lookups, and its throughput was low.

So the right pick depends on what your app does. And since this was one set of tests from one place, run the same test with your own traffic before you decide.