Edition 223

Block timing. Mean interval 580.3 seconds (9.7 min) over 142 measured intervals across 144 blocks; median 425 seconds (7.1 min). Range 2 s to 3155 s (52.6 min). One sub-3-second interval observed.

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

Largest block. Block 970,687 at 3,495 transactions, the peak load in the window. Avg tx/block across all 144 blocks was 949.

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,735). 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.

Miners are identified by their coinbase tag, a free-text field the block's miner writes into its own coinbase transaction. That miner may be a pool or someone mining solo. The tag is self-reported and unsigned: consensus does not check it, and Teranode reads the same field to name miners. Blocks with no tag, or a tag not on our list, appear as unrecognized. The _Teranode suffix (e.g., taal.com_Teranode) marks blocks whose coinbase tag mentions Teranode, which is also self-reported rather than 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 33, qdlnk 24, SA100 20, GorillaPool 20, CUVVE 19, taal.com 15, molepool.com 6, Mining-Dutch 4, taal.com_Teranode 2, Bitofsin 1. 144 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 225-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 22.8 hours of the scan window in 10-minute intervals, not per block. The peak is the busiest 10-minute window observed (3,614 transactions, ≈ 6 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. 10 unique structures observed today across 106,071 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-12 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.