A Poisson process is a random event process where events occur independently at a stable average rate, but with unpredictable spacing.
▦ Transaction Velocity (10-min intervals, not per-block)
5,109,373 txs mapped
Transaction volume shown chronologically. Each row = one hour of the scan, each column = a 10-minute window. Read top-to-bottom for earlier-to-later.
Coverage: 2026-04-29 09:22 → 2026-04-30 10:19 UTC
Dark cells indicate 10-minute windows where no block was mined — a natural result of the Poisson process governing Proof of Work. Transactions during these windows appear in the next mined block.
⬡ Script Usage Taxonomy
10,251,446 outputs
How Bitcoin scripts were used in this scan window. The section is organized into three primary dimensions plus three context views:
Purpose — what outputs are for (Payment, Data Publication, Contracts/Tokens, TxBlaster)
Protocol — open standards defining data format
Content Type — MIME types declared in published data outputs (ordinal envelopes and B:// protocol)
Overlay Directory — BRC-88 SHIP/SLAP advertisements (current federation + new this window)
Identifiable Patterns — apps, mini-protocols, token deployments, content categories observed in the data (editorial)
Script of the Day — one notable script from the scan window
OP_RETURN data is prunable at scale (requires indexing). STAS and Spendable metadata remain in the UTXO set.
Purpose— what outputs are for
Shown two ways: overall proportions (donuts), then byte-level structures within each purpose (cards).
All chain activity
→
Excluding TxBlaster
re-normalized for visibility
TxBlasterPaymentData PublicationContracts
TxBlaster: 5,028,279 transactions (98.41%).
Excluding TxBlaster, the window saw 81,094 transactions (1.59%) across Payment, Data Publication, and Contracts.
Byte-level structures within each purpose. Each TxBlaster tx contributes 1 P2PK + 1 OP_RETURN, so its outputs are counted only in the TxBlaster card below — not in Payment or Data Publication.
Metanet here refers to the 2018–2019 nChain protocol (4-byte "meta" push in OP_RETURN defining a DAG of parent-txid-linked records). Not to be confused with the newer BRC-100 "Metanet" wallet/overlay ecosystem, which uses the same word for a different thing.
Content Type‡— MIME types declared in published data outputs
Topic registrations announce who is hosting which overlay topics. New ads are sparse; the federation accumulates over time. How overlay networks work →
Live federation
SHIP ads182
SLAP ads90
Unique operators43
Snapshot as of 2026-04-30 13:38 UTC.Counts reflect the union of unspent SHIP/SLAP UTXOs across the four BSV SDK bootstrap trackers (overlay-us-1, overlay-eu-1, overlay-ap-1, users.bapp.dev), deduplicated by transaction outpoint. Trackers maintain independent indexes; some entries may be stale on individual trackers.
New this window
No new SHIP/SLAP advertisements registered in this scan window.
Identifiable Patterns— observed in the data (editorial)
Identifiable patterns in transaction data — apps, mini-protocols, token deployments, content categories — appearing across OP_RETURN, ordinal envelopes, PushDrop, and other output types. Most chain activity has no such identifier.
Some patterns from WoC tags, others identified through analysis.
What it does: This script begins with OP_RETURN, which terminates execution and marks the output as unspendable. The remaining bytes carry arbitrary data.
Why it matters: Currently the most common method for data publication. Used by protocols like B://, MAP, AIP, and TreeChat for files, metadata, and social content.
Selected from 5101167 candidates in this category.
*Spendable metadata (heuristic): Scripts with signature verification followed by data removed via OP_DROP. Metadata not consumed by validation logic but remains on-chain.
†Unique structures: A contract structure is a normalized script skeleton with variable data (hashes, signatures, pubkeys) removed.
‡Content Types: MIME types declared in data publication outputs. Sourced from two structures: ordinal envelopes (1Sat-style spendable inscriptions) and B:// protocol OP_RETURN publications. Outputs that don’t declare a MIME type aren’t counted here.
§application/bsv-20 covers both BSV-20 and BSV-21: Both protocols declare "p":"bsv-20" in their JSON and most inscriptions inherit the legacy application/bsv-20 MIME type. Protocol differentiation happens via JSON fields (tick = BSV-20 ticker mode, sym/id = BSV-21 tickerless mode) — see the BSV-20 / BSV-21 breakdown under DATA PUBLICATION above.