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)
4,965,101 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-08 10:48 → 2026-05-09 10:28 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,231,024 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: 4,857,653 transactions (97.84%).
Excluding TxBlaster, the window saw 107,448 transactions (2.16%) 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.
PAYMENT
P2PKH358,512
P2PK23,000
Multisig23
DATA PUBLICATION
OP_RETURN133,605
Ordinal envelopes346
↳ BSV-20 tokens0
↳ BSV-21 tokens225
↳ NFT/media121
Spendable metadata*73
CONTRACTS / TOKENS
STAS tokens (Gen 2)0
STAS tokens (Gen 3)116
Custom locking scripts43
8 unique structures†
TXBLASTER
P2PK (change side)4,857,653
OP_RETURN (data side)4,857,653
Protocol— open standards defining data format
MAP: 1,649Metanet: 1,416B://: 1,187AIP: 748
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-09 11:16 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 locks coins to a hash (fingerprint) of a public key. To spend them, the spender must reveal the public key and provide a valid signature proving they control the matching private key.
Why it matters: This template forms the standard payment mechanism in the original Bitcoin design and is widely used by wallets.
*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.