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)
2,920,042 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-05-05 08:07 → 2026-05-06 10:25 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
6,128,886 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: 2,801,468 transactions (95.94%).
Excluding TxBlaster, the window saw 118,574 transactions (4.06%) 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 directory
endpoints = unique (URL, identity key) pairs
advertisements (ads) = signed unspent UTXOs on chain, declaring one endpoint hosts one topic
topics = named overlay services like tm_uhrp or ls_ship
SHIP — intake side
43 endpoints
across 51 topics
SLAP — query side
32 endpoints
across 46 topics
The directory itself:tm_ship(21) · tm_slap(21) · ls_ship(6) · ls_slap(6)
Snapshot from 2026-05-06 11:15 UTC.Counts come from the four trackers hardcoded into the BSV SDK (overlay-us-1, overlay-eu-1, overlay-ap-1, users.bapp.dev). BSV apps query these to find which servers host the overlay topics they need.
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 embeds data inside a conditional branch. The OP_FALSE OP_IF block carries the payload (marked "ord"), while the P2PKH suffix enforces signature-based ownership.
Why it matters: Encodes ownership into individual satoshis. Transferable by spending the UTXO.
*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.