BitcoinDatabase.com

Query the chain · Crypto tax API

Crypto tax API for Bitcoin cost basis and historical price data

A crypto tax engine needs three things for every Bitcoin transaction: what moved and when, the fair market value in US dollars at the exact moment it happened, and enough history to reconstruct cost basis. Most price APIs give you only the middle piece, so you still stitch a separate chain source to it. This crypto tax API supplies all three from one source: address and transaction history back to the 2009 genesis block over REST, with the historical price on the same timeline, so you can pair each transaction with the FMV that applied when it confirmed.

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 ...

That is what tax and accounting software actually consumes. Pull an address or xpub history over REST to seed a user's transaction list, then read the price at each block time to value acquisitions and disposals, or run SQL over the indexed chain, which grows with every new block, to band a wallet's coins into cost-basis cohorts. You keep control of the accounting method and the final gain or loss; we deliver clean, reproducible, audit-friendly inputs. This is informational on-chain and market data, not tax, accounting, financial or legal 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 Crypto tax API

Price at the moment of each transaction

Capital gains math is only as good as the value you assign at the time of the trade. Because historical price lives in the same schema as the chain, you get the fair market value that applied at a transaction block time in the same query that returns the transaction, with no separate feed to reconcile.

Full history for real cost basis

Reconstruct a wallet from its first receive to today: every acquisition, disposal, fee and UTXO across the full holding period, so a tax engine can apply FIFO, LIFO or specific-identification against a complete and consistent record.

Reproducible and audit-friendly

The same query pinned to the same block height returns the same numbers every time, and you can export the underlying rows. That is what turns a tax figure into something an accountant or auditor can trace back to the chain.

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.

  • Pull an address or xpub transaction history for a tax report
  • Value each acquisition and disposal at its block-time price
  • Reconstruct cost basis across a full holding period
  • Band a wallet into cost-basis cohorts in SQL
  • Separate transfers between own wallets from taxable disposals
  • Export audit-ready rows behind every gain or loss
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 Crypto tax API

No. This is the data layer a crypto tax calculator runs on. It returns Bitcoin transaction history, the fair market value at each transaction time and cost-basis inputs; your software or accountant applies the accounting method and computes the final gain or loss. It is informational data, not tax advice.
Because historical price is indexed alongside the chain, every transaction can be joined to the market price that applied at the block time it confirmed, in one query. That gives a tax engine the fair market value in US dollars at the moment of acquisition or disposal without stitching a separate price feed to a separate blockchain source.
Cost basis is what you paid for the coins you disposed of, including fees, valued in US dollars at the time you acquired them. The hard part is not the arithmetic, it is assembling a complete acquisition history and matching each disposal to specific lots under the method you use. That needs every receive, spend and fee for the wallet, each paired with the dollar value that applied when it confirmed.
The fair market value in US dollars at the time the transaction occurred. That makes the timestamp you attach to a price as important as the price itself, and block timestamps are not reliably ordered, so two transactions can appear to happen out of sequence. Pin valuations to block height rather than to a wall-clock time and the result becomes reproducible.
The IRS has moved toward per-wallet and per-account basis tracking rather than a single universal pool, which is the approach Revenue Procedure 2024-28 addresses. Practically it means your data layer has to keep lots separated by the wallet holding them instead of merging everything. Confirm how it applies to your situation with a CPA, because facts differ.
Each disposal needs a description of the property, the acquisition date, the disposal date, the proceeds and the cost basis, which produces the gain or loss. In Bitcoin terms that means resolving every spend to the specific inputs it consumed, dating each of those inputs to the block that confirmed it, and valuing both ends in dollars. Missing acquisition history is what forces a zero basis.
Move the question on-chain rather than guessing from exchange exports. A transfer between wallets you control is a spend whose outputs land on addresses you also control, so with the full address set for a user you can classify it as internal rather than a disposal. Without that address set, self-transfers look identical to sales and get taxed as if they were.
Usually because of three inputs rather than a calculation bug: which price source and timestamp valued each transaction, whether self-transfers were correctly classified, and which lot-matching method was applied. Change any one and the gain moves. This is why the underlying rows matter more than the summary figure, and why reports that cannot be traced back to block heights are hard to defend.
Yes, that is the intended use. Pull an address or xpub history over REST to seed a user's transaction list, read the price at each block time to value acquisitions and disposals, and run SQL when you need to band a wallet into cost-basis cohorts across a full holding period. You keep the accounting method and the final numbers. We supply reproducible inputs, not tax advice.
No public block explorer we tested does. On 8 September 2026 we requested the same confirmed transaction from mempool.space, Blockstream Esplora, BlockCypher and blockchain.com. All four returned HTTP 200 and none carried a USD amount, a price or any fiat field. That is expected: an explorer reports what the chain records, and the chain records satoshis, not dollars.
You join the transaction to a price series using the confirmed block timestamp, not the broadcast time, because a transaction can sit in the mempool for hours and only the block time is verifiable afterwards. BitcoinDatabase stores price_at_creation_usd directly on each output, so the acquisition value travels with the coins instead of being recomputed on every read.
Revenue Procedure 2024-28 ended universal cost basis for digital assets and requires wallet-by-wallet or account-by-account tracking, effective 1 January 2025. Brokers began reporting gross proceeds on Form 1099-DA for 2025 sales, with adjusted basis reporting following for 2026. This is informational only and not tax advice; confirm treatment with your own advisor.
We costed a production indexed Bitcoin node in AWS at roughly $390 to $430 per month before any engineering time, and that buys the raw chain only. It does not include the price join, extended public key derivation or lot accounting, which are usually the larger share of the work for a tax product.

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