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)
6,810,298 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-13 10:27 → 2026-05-14 10:21 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
13,356,851 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,010,842 transactions (58.89%).
Excluding TxBlaster, the window saw 2,799,456 transactions (41.11%) 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
P2PKH3,433,505
P2PK13,500
Multisig54,513
DATA PUBLICATION
OP_RETURN1,832,320
Ordinal envelopes624
↳ BSV-20 tokens0
↳ BSV-21 tokens440
↳ NFT/media184
Spendable metadata*78
CONTRACTS / TOKENS
STAS tokens (Gen 2)0
STAS tokens (Gen 3)559
Custom locking scripts68
10 unique structures†
TXBLASTER
P2PK (change side)4,010,842
OP_RETURN (data side)4,010,842
Protocol— open standards defining data format
Metanet: 1,900MAP: 1,447B://: 868AIP: 456OPUB: 42
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-14 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.
Selected from 3433505 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.