◐ rebuilding Bitcoin chain analytics are being rebuilt after a transaction-parser fix. Historical figures shown may be inaccurate until the re-ingest completes.
⬡ SUBSTRATE 🔒 sovereign Bitcoin value-flow graph · multi-collection join, one pass · ready Contact ▸ ⌘K research.semurg.io

Document demo: the join with nothing to join across

You are looking at Bitcoin value-flow graphtransaction + address documents, linked by value-flow edges in one Semurg substrate. Ask it to join transactions to addresses and prior transactions in one pass and it runs the real query live on this box, on data you can download and re-run yourself.

Click an example in the agent rail, or ask to join 3 deep, or change the hop count. Every run is measured end to end, on this box, on the real dataset. Nothing is pre-computed.

the live Bitcoin value-flow graph, transactions and addresses linked by value-flows (prev-tx to tx to address), parsed straight off the P2P network · Bitcoin mainnet P2P (our own block-parser node, no bitcoind, no REST). Transactions and addresses are 64-byte containers; the foreign keys between them are edges. A multi-collection join is one traversal pass, no $lookup, no per-collection index. Measured live.

the document-store leader
A $LOOKUP PER LINK. A cross-collection join needs a $lookup stage for each linked collection, each with its own index and its own pass, then a $match to filter, three indexes and three passes stitched together for one question.
semurg, one engine
Nothing to join across. The foreign keys are edges in the one store, so transaction to address to prior transaction is followed in a single traversal sweep with the filter fused in, no $lookup, no per-collection index.
The join tax is eliminated, not just a faster join.
The live Bitcoin blockchain: transaction and address documents linked by value-flow edges, 188.97M docs. Measured live on this box. Re-pull the chain over Bitcoin P2P and re-run it yourself.
ask the agent to join the collections, the live one-pass result renders here
Honest framing: a by-key fetch of one resident document is a wash, we do not claim to beat a document store at its own point-lookup. The structural win is the multi-collection join. A document store stitches it with a $lookup stage per linked collection (an index plus a pass each), then a $match to filter. Here the foreign keys are edges in the one store, so there is nothing to join across: the links are followed in a single pass, the filter fused in, no index built, no second engine. The win is collapse, the join tax is eliminated. Cold and warm are both shown, never our-hot against their-cold.