Edition 75

Block timing. Mean interval 468.3 seconds (7.8 min) over 142 measured intervals across 144 blocks; median 318 seconds (5.3 min). Range 5 s to 2790 s (46.5 min).

Cadence. Average interval 7.8 min — running fast relative to the 10-minute target. 8 pools produced today's blocks.

Largest block. Block 949,371 at 280,843 transactions, the peak load in the window. Avg tx/block across all 144 blocks was 22,763.

Pool identification is by coinbase signature; pools that don't sign or use unrecognized tags appear as untagged producers. The _Teranode suffix (e.g., taal.com_Teranode) marks blocks attributed to a pool running the Teranode node software — based on observable signals in the block data, not a formal protocol marker. GorillaPool.io may also be running a Teranode (observed in the Teranode explorer); when blocks become attributable to that node, they would appear with the suffix as well.

Block counts: Mining-Dutch 48, taal.com 25, CUVVE 20, qdlnk 18, GorillaPool 12, molepool.com 7, SA100 6, Kryptex 5. 141 of 144 blocks identified.

Tier thresholds. Major > 10K BSV; Notable 1K – 10K BSV; Significant 100 – 1K BSV. Counts are unique transactions in the 24-hour window moving value within these bands; the 100-BSV floor excludes ordinary day-to-day payments.

Shape is input-count → output-count. Pattern is heuristic:

Neutral: typical payment shape (1→2 or 2→2, one payment + change).
Consolidation: many inputs, few outputs (UTXO cleanup or sweep).
Distribution: few inputs, many outputs (payouts, faucet, batch send).

TPS is computed over the 18.4 hours of the scan window in 10-minute intervals, not per block. The peak is the busiest 10-minute window observed (280,852 transactions, ≈ 468 tx/s for that window).

Price source: real-time quote at scan completion. 24h change is from a rolling 24-hour spot reference.

Dark cells indicate 10-minute windows where no block was mined: a natural result of the Poisson process governing Proof of Work.2 Transactions broadcast during those windows appear in the next mined block.

Each row = one hour of the scan. Each column = a 10-minute bucket within that hour. Read left-to-right within a row, then down to the next hour.

Purpose classifies outputs by what they're locked to:

Payment: P2PKH, P2PK, multisig (spendable value).
Data Publication: OP_RETURN, ordinal envelopes, spendable metadata (carrying data).
Contracts: STAS tokens, custom locking scripts (programmable spend conditions).

Spendable metadata (heuristic): scripts with signature verification followed by data removed via OP_DROP. Metadata isn't consumed by validation logic but remains on-chain in the UTXO set.

Unique structures: a contract structure is a normalized script skeleton with variable data (hashes, signatures, pubkeys) removed. 8 unique structures observed today across 128 contract outputs.

Content Types are MIME declarations 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 MIME type. Protocol differentiation happens via JSON fields (tick = BSV-20 ticker mode; sym/id = BSV-21 tickerless mode).

BRC-88 SHIP/SLAP. Topic registrations on chain that announce which overlay services a node hosts. SHIP is the intake side (which topics this node accepts); SLAP is the query side (which topics this node can answer for).

endpoints = unique (URL, identity key) pairs. advertisements = signed unspent UTXOs on chain, each declaring one endpoint hosts one topic. topics = named overlay services like tm_uhrp or ls_ship.

Snapshot from 2026-05-16 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.

Patterns are matched against a curated catalog of known protocols and application signatures: MAP tags, B:// envelopes, AIP, OPUB, ordinal mime declarations, custom STAS structures. Some come from WoC tags; others are identified through analysis. New patterns are added editorially as they emerge.

Counts are unique transactions touching each application's recognizable structures. A transaction can match more than one pattern.

Selection is editorial: one script per day from a curated category (Data Carrier, Token Mint, Complex Contract, Hash Puzzle, etc.). Candidate count shows how many similar scripts appeared in the same window.

The skeleton normalizes pushes to <DATA> for pattern comparison across transactions.