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)
3,231,664 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-03 11:26 → 2026-05-04 10:11 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,710,048 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: 3,107,527 transactions (96.16%).
Excluding TxBlaster, the window saw 124,137 transactions (3.84%) 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
P2PKH400,083
P2PK16,000
Multisig12
DATA PUBLICATION
OP_RETURN77,159
Ordinal envelopes1,169
↳ BSV-20 tokens0
↳ BSV-21 tokens953
↳ NFT/media216
Spendable metadata*31
CONTRACTS / TOKENS
STAS tokens (Gen 2)0
STAS tokens (Gen 3)458
Custom locking scripts82
6 unique structures†
TXBLASTER
P2PK (change side)3,107,527
OP_RETURN (data side)3,107,527
Protocol— open standards defining data format
MAP: 1,582B://: 1,096AIP: 451OPUB: 123
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
76 endpoints
across 67 topics
SLAP — query side
55 endpoints
across 64 topics
The directory itself:tm_ship(22) · tm_slap(22) · ls_ship(8) · ls_slap(8)
Snapshot from 2026-05-04 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 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.