Following Bitcoin money through UTXOs: one declarative query

1. Flow evidence, not balances

One boundary up front, because it is the honest thing to state and it shapes everything below. This data tells you about movement: which address sent value into a transaction and which addresses it went to. It does not give you an address's current balance. A balance would mean summing every unspent output an address controls across all of history, which is a different and heavier reconstruction. What follows traces flows, not holdings.

That is still most of what fund tracing needs. Following value from one address to the next, transaction by transaction, is the core of Bitcoin forensics, and it is exactly what inputs and outputs give you. For the investigation workflow that chains these hops together, see compliance data for crypto.

2. Inputs and outputs in one shape

The request is the same declarative shape as every other chain, with Bitcoin's tables instead of logs: a window, the inputs and outputs tables, and a field selection. Bitcoin uses Bitcoin Core's own field names, so an input's sender is prevoutScriptPubKeyAddress (the address of the output being spent) and an output's recipient is scriptPubKeyAddress. This is the actual request, as a curl you can paste:

The response is newline-delimited JSON, one block per line, with the matching inputs and outputs attached. A single real output from that stream:

Each input carries prevoutScriptPubKeyAddress and prevoutValue (the address and amount of the output it spends); each output carries scriptPubKeyAddress, value in BTC, and scriptPubKeyType. Because a block returns inputs and outputs as flat arrays, every row also carries a transactionIndex: group inputs and outputs by it, and join to the txid in the transactions table, to rebuild each transaction's senders and recipients. The one input without these is the coinbase (transactionIndex 0): it mints new value rather than spending a prior output, so its prevoutScriptPubKeyAddress and prevoutValue come back null, and flow logic should skip that row. The Portal's Bitcoin MCP tools normalize these to sender, recipient, and type for an agent, and the Pipes SDK has a Bitcoin source that streams the identical query into your own database for a standing flow table.

3. Reading a payment and its change

A single real transaction shows the basic flow. One input funds two outputs: a payment to one address, and change back to the sending address. The change is recognizable because it returns to the exact address that funded the input.

4. Consolidation: many inputs, one output

The payment shape above is one of a handful that recur in flow analysis, and they all fall straight out of reading inputs against outputs. A consolidation spends several outputs controlled by one address into a single output, the pattern a wallet or exchange uses to sweep small UTXOs together. A real one from the same block, transaction 81acc1c4…a66635:

Three inputs, all from bc1q4f5u…xfpe5l, collapse into one legacy output, with 0.00000816 BTC left as fee. Reading the same inputs and outputs the other way, several outputs from one input, is a fan-out; the most informative non-payment shape, an output that carries data instead of value, is the subject of the next section.

5. Output types, including OP_RETURN

Every output carries a script type, which tells you the address format and, in one case, that the output carries data rather than value. Block 954,236 alone contains legacy, P2SH, SegWit, and Taproot outputs:

A real OP_RETURN-bearing transaction in the same block makes it concrete. Transaction ee4f2a5b…06099f pays one Taproot output and attaches a single zero-value data marker, exactly as the stream returns them:

The nulldata output moves no coins; its scriptPubKeyAddress comes back null and its value is zero. It is a marker a protocol writes onchain, and reading it is just another output type in the same query, which is what makes this dataset as useful for protocol activity as for plain payments.

6. Why this is harder elsewhere

For the EVM equivalent of following value inside a transaction, see internal transactions explained. For the one-query-shape idea across machines, see one query shape, every VM, and for how landing many chains together works, multi-chain indexing.