Edition 221

Block timing. Mean interval 647.1 seconds (10.8 min) over 143 measured intervals across 144 blocks; median 428 seconds (7.1 min). Range 3 s to 3496 s (58.3 min).

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

Largest block. Block 970,308 at 12,208 transactions, the peak load in the window. Avg tx/block across all 144 blocks was 1,153.

Source: node_status messages on the public BSV gossip layer, observed by our own libp2p listener and deduplicated by peer ID. This counts the publicly-announcing set only — a node that does not broadcast status, or runs inside a private cluster, will not appear, so read it as a floor, not a full census.

“Caught up” means within one block of the chain tip (currently 970,446). Stalled or still-syncing nodes are excluded from that count. “Public relay” here means a node that publicly forwards gossip to the rest of the mesh; only two do, and both announce under the same operator label and share infrastructure, so the public mesh’s reachability appears to lean on a single operator.

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: Kryptex 27, CUVVE 25, SA100 24, qdlnk 22, GorillaPool 18, taal.com 11, Mining-Dutch 10, molepool.com 4, KardanPool 1, Bitofsin 1, Unrecognized 1. 143 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 223-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 25.7 hours of the scan window in 10-minute intervals, not per block. The peak is the busiest 10-minute window observed (12,208 transactions, ≈ 20 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. 12 unique structures observed today across 105,976 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 topic managers (tm_ names) a node accepts transactions for. SLAP is the query side: which lookup services (ls_ names) a node answers queries for.

endpoints = unique (URL, identity key) pairs. advertisements = signed unspent UTXOs on chain, each declaring one endpoint hosts one topic manager or lookup service. Names come in pairs per overlay, e.g. tm_uhrp (advertised via SHIP) and ls_uhrp (advertised via SLAP). SHIP and SLAP are overlays themselves, so ls_ship is a lookup service and is advertised via SLAP, despite the name.

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

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.