Edition 90

Block timing. Mean interval 616.1 seconds (10.3 min) over 143 measured intervals across 144 blocks; median 499 seconds (8.3 min). Range 8 s to 2486 s (41.4 min).

Cadence. Average interval 10.3 min — on schedule relative to the 10-minute target. 8 pools produced today's blocks.

Largest block. Block 951,398 at 284,703 transactions, the peak load in the window. Avg tx/block across all 144 blocks was 14,190.

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: CUVVE 39, taal.com 33, GorillaPool 27, qdlnk 17, SA100 10, molepool.com 6, taal.com_Teranode 4, unknown 4. 140 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).

New to the radar flags addresses from today's top whale movements that have not appeared in any whale-tier transaction during the observation window. This could indicate a new large holder, a previously sub-threshold address crossing into whale territory, or a long-dormant address reactivating.

Recurring addresses are identified by tracking output scripts across all whale transactions (≥ 100 BSV) over the full 91-day observation window. An address appearing here has been involved in large-value movements on multiple separate days.

Behavior is based on whether an address predominantly receives (Accumulator), predominantly sends (Distributor), or does both in roughly equal measure (Exchange-Like).

Confidence reflects how many indicators align: transaction frequency, directional balance, and tier presence. High = 3+ indicators; Medium = 2; Low = 1.

All classifications are probabilistic. No identity or ownership claims are made. Addresses are derived from transaction output scripts.

TPS is computed over the 24.5 hours of the scan window in 10-minute intervals, not per block. The peak is the busiest 10-minute window observed (327,185 transactions, ≈ 545 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. 4 unique structures observed today across 190 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-31 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 script preview above is the actual on-chain ASM (truncated for display); the skeleton normalizes pushes to <DATA> for pattern comparison across transactions. Opcodes shown are the unique ones present in the script, not the sequence order.