Edition 228

Block timing. Mean interval 635.5 seconds (10.6 min) over 142 measured intervals across 144 blocks; median 497 seconds (8.3 min). Range 2 s to 5206 s (86.8 min). One sub-3-second interval observed.

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

Largest block. Block 971,334 at 82,712 transactions, the peak load in the window. Avg tx/block across all 144 blocks was 1,176.

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 971,449). 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 49, qdlnk 25, GorillaPool 16, CUVVE 15, SA100 13, taal.com 12, molepool.com 5, KardanPool 3, themule.online 3, taal.com_Teranode 1, zpool.ca 1, Bitofsin 1. 144 of 144 blocks identified.

Large transactions are transactions in these blocks whose outputs add up to 100 BSV or more. Major > 10K BSV; Notable 1K – 10K BSV; Significant 100 – 1K BSV. The 100-BSV floor excludes ordinary day-to-day payments. A transaction's size includes change returned to the sender, so it is how much value the transaction handled, not how much changed hands. The line under each transaction shows what was actually paid out.

Shape is input-count → output-count. Pattern is heuristic: Neutral is a typical payment (one payment plus change); Consolidation is many inputs to few outputs (UTXO cleanup or sweep); Distribution is few inputs to many outputs (payouts, batch send).

The address under a transaction is its largest output that is not change. An output paid back to one of the transaction's own input addresses counts as change (“back to the sender”). A wallet that sends change to a fresh address can't be told apart this way, so the address shown may still be the sender's. Internal transfer means the sending addresses and every address paid belong to the same holder we follow (below), so the coins likely stayed with one owner.

New address means the address has not appeared, as sender or receiver, in any stored large transaction since tracking began on March 2, 2026. Stored transactions are mostly 1,000 BSV and up; before October 16, 2026 only each day's top 10 were stored. A new address could be a new large holder, an address that only moved smaller amounts before, or a long-dormant address coming back. Seen before gives the first date the address appeared and how many stored transactions it has been in.

Large holders we follow are groups of addresses we treat as one owner, because they have been spent together as inputs or linked by hand from on-chain evidence. For each one, we add up every stored transaction touching its addresses in these blocks: coins received minus coins sent. Moves between a holder's own addresses cancel out, so a large transfer that only shuffles coins internally shows near zero. A holder is listed when it ends the blocks 25,000 BSV or more up or down. Addresses outside these groups are not counted, so a large payment to a new address does not show up here.

All classifications are probabilistic. Grouping addresses into a holder is an inference from on-chain links, not proof of common ownership, and no identity is claimed.

TPS is computed over the 25 hours of the scan window in 10-minute intervals, not per block. The peak is the busiest 10-minute window observed (82,712 transactions, ≈ 138 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. 13 unique structures observed today across 59,108 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-17 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.