BitcoinDatabase.com

Query the chain · Network stats

Bitcoin network stats API for hashrate, difficulty and block metrics

The health of the Bitcoin network shows up in a handful of numbers: the estimated hashrate securing it, the mining difficulty that resets every 2,016 blocks, how long blocks are actually taking, block size and weight, transactions per block, and the fees paid to confirm them. The Bitcoin network stats API computes all of these from every block on the indexed chain, so you can read the current state or rebuild the history as the index grows, without running Bitcoin Core or scraping a chart site.

or try it below ↓

REST API · SQL · dashboards · address history from genesis

Query Console
btc
try:

Hit Run to query the Bitcoin blockchain.

Live from the chain for .

BTC

Balance trail

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Reading the chain ...

Each block header already carries its difficulty and timestamp, so hashrate estimates, difficulty over time and real block intervals fall straight out of the index, alongside per-block size, fee totals and transaction counts. Pull a single current figure over REST for a status page, or run SQL to chart difficulty across every adjustment epoch, measure how block times drifted around a halving, or correlate fees with mempool pressure. This is informational on-chain data and analytics, not financial or investment advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

History from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with Network stats

Hashrate and difficulty

Read the estimated network hashrate and the mining difficulty that adjusts every 2,016 blocks, both derived from block headers and timestamps on the indexed chain, and rebuild the full difficulty and hashrate history across every adjustment epoch in SQL.

Real block metrics

Go past the 10-minute target to how blocks actually behaved: real block intervals, block size and weight, transactions per block and total fees paid, all computed per block so you can chart how the network moved over any window.

Current or historical

Pull one current figure over REST for a status page or widget, or query the indexed chain, which grows with every new block in SQL to study how hashrate, difficulty, block times and fees shifted around halvings and demand spikes, without running a node yourself.

What it handles

The indexed Bitcoin chain, queryable your way

Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.

  • Read estimated hashrate and current difficulty
  • Rebuild difficulty history across every adjustment epoch
  • Measure real block intervals versus the 10-minute target
  • Track block size, weight and transactions per block
  • Chart total fees paid per block over any window
GET /v1/address/{addr} query result
200 · JSON
{
  "address": "bc1qxy2k…l0wdv8",
  "balance_btc": 68432.10,
  "balance_usd": 4612165420,
  "tx_count": 1284,
  "unspent_outputs": 37,
  "first_seen": "2014-02-09"
}
indexed from genesis · to the satoshi ✓ reconciled block-by-block

Why BitcoinDatabase

One platform, queryable three ways

Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.

REST API

Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.

SQL access

Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.

Compliance-first

Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.

Good questions

Questions about Network stats

The protocol targets ten minutes, and any short window you measure will disagree with that, sometimes wildly. Across blocks 965,782 to 965,796 on 6 September 2026 we measured a median interval of 185 seconds and a mean of 249 seconds, with the extremes at 23 seconds and 542 seconds. Block discovery is a Poisson process, so a fifteen block sample tells you almost nothing about the long run average. Measure over a difficulty epoch if you want a figure that means something.
Essentially full, and more consistently than most people expect. Every block in the 965,782 to 965,796 window on 6 September 2026 sat between 3,992,581 and 3,997,795 weight units, which is 99.8 to 99.9 percent of the 4,000,000 weight unit cap. Transaction counts over the same window ranged from 4,431 to 7,052 with a median of 6,397. Weight, not transaction count, is the number that tells you whether a block is full, because transaction sizes vary enormously.
No, and this window is a clean counterexample. Blocks were 99.8 percent full by weight on 6 September 2026 while the median fee rate ran between 0.34 and 1.00 satoshis per virtual byte, and total fees per block ranged from 0.0046 to 0.0152 BTC. A block fills whenever there is enough demand at any price, including very cheap transactions. Fullness measures space used; fee rate measures competition for it, and they move independently.
Small, and currently shrinking. In the 6 September 2026 window the median block collected 0.0081 BTC in fees against a 3.125 BTC subsidy, so fees were about 0.26 percent of miner revenue. When we measured a 144 block window on 30 August 2026 the same figure was 0.438 percent. Both are real, and the gap between them over six days is the reason to compute this over your own window rather than quote a number you read somewhere.
It is always an estimate, never a measurement. Nobody can count hashes, so hashrate is inferred from how quickly blocks were found relative to the difficulty in force. That makes the estimate only as stable as the window you compute it over, and short windows are badly behaved: our fifteen block sample above had a median interval of 185 seconds against a ten minute target. Use a full difficulty epoch, and treat any single day hashrate figure as noisy.
Bitcoin mining difficulty is a measure of how much work it takes, on average, to find a block the network accepts. Miners search for a block hash below a target, and difficulty expresses that target as a readable number, where 1 was the easiest setting at launch. The value is written into every block header, so the difficulty at any past height is a recorded fact, not an estimate.
Every 2,016 blocks, which is roughly two weeks at the ten minute target but drifts with actual block times. The adjustment moves difficulty toward whatever value would have produced ten minute blocks over the epoch just finished, and it is clamped so it cannot move by more than a factor of four in either direction. Because the adjustment is retrospective, difficulty always lags a real change in hashrate by up to two weeks.
Block weight against the 4,000,000 cap, median fee rate, transaction count per block and the fee share of miner revenue. Together those tell you whether space is scarce, what it currently costs, and whether the cost is trending. Balances and volumes matter for market questions; these four matter for whether your transactions confirm and what they will cost. Query them per block rather than per day, because daily averages hide exactly the congestion spikes you are planning against.
It returns network-level metrics computed from every indexed block: estimated hashrate, mining difficulty, real block intervals, block size and weight, transactions per block and total fees paid. You can read the current value over REST or rebuild the full historical series in SQL, without running Bitcoin Core.
Hashrate is an estimate, not a directly measured number. It is inferred from the mining difficulty and how quickly recent blocks were found: if blocks arrive faster than the 10-minute target at a given difficulty, more hashing is implied. Because BitcoinDatabase holds every block header and timestamp, it computes this estimate and its full history for you as informational data.
The block subsidy is 3.125 BTC, set by the April 2024 halving, and the miner also collects the fees paid by every transaction in the block. The subsidy halves every 210,000 blocks, so it falls to 1.5625 BTC around April 2028. The API reads the reward from each block's coinbase transaction, subsidy and fees separately.
Around the year 2140. More than 95 percent of the supply is already issued, but each halving cuts new issuance in half, so the last million or so bitcoin is released in ever smaller amounts over more than a century. Once the subsidy drops below one satoshi, miners are paid by transaction fees alone.

Explore more

More ways to query Bitcoin with BitcoinDatabase

Stop running a node. Just query Bitcoin.

Run your first query now and get on-chain data back by REST API, SQL or dashboard, with address history back to the genesis block over REST. Informational on-chain data only, not financial advice.

See pricing

History from genesis over REST · SQL · dashboards · addresses, transactions, UTXOs, metrics