Watch the network
Real blocks, read live from Kaspa's own public API. Kaspa makes about 10 a second; this page checks in every 9 seconds and shows what it actually fetched, not a simulation of the rest. If the API can't be reached, this page says so instead of faking it.
Measuring the network's real pace…
Reading the first blocks…
Kaspa targets 10 new blocks every second. Most of what you're watching arrive is a block holding exactly one transaction: the miner paying itself.
What this page shows, what it can't, and why
Blocks, in parallel
Kaspa doesn't pick one miner's block and discard the rest the way a single-chain network does. Several blocks can be valid at once; GHOSTDAG later orders and merges them instead of throwing them away. The count at the top of this page is tipHashes from a live read of api.kaspa.org/info/blockdag: the number of block tips the network is holding open right now. Each new tip is then fetched individually from api.kaspa.org/blocks/{blockId}.
Who mined it
Each block card names the payout address and the self-reported miner tag from the block's own coinbase data (the API's extra.minerAddress and extra.minerInfo fields). Neither is a verified identity: a pool can rotate payout addresses, and the tag is a plain string the miner chose to write, not something the network checks. This site's own data notes 32 distinct coinbase payout addresses over a short sample as "block producers," explicitly flagging that rotation would inflate that count. Treat every miner label here the same way.
Blue and red
A block tagged red below was real and mined honestly, but arrived too late in its local ordering to be counted in the ledger's accepted history; a "blue" block was. That is GHOSTDAG's actual job: keep the block, decide whether it counts.
What's inside: mostly nothing yet
A block with only its own coinbase transaction and zero spends is marked Empty. Most blocks arrive that way today. That is not this page failing to find activity: it is Kaspa's actual current usage. The same figure appears sitewide: about 0.9 transactions per second sustained, and 89.5% of the raw transaction count is the one-per-block coinbase payout, not economic activity (data/l1-chains.json, cross-checked against live API reads).
Covenants
When a transaction output carries a network-verified covenantId, this page shows a covenant tag. That field comes straight from the API's own parsed transaction data, not a guess: Toccata-era Kaspa enforces covenants and covenant IDs in consensus, and the site's own August 2026 reads found roughly 28,000 ever created and about 500 still active. They are uncommon in the ordinary block feed; expect long stretches with none.
App attribution: only where it's really written down
Kaspa has no protocol-level field that names an app. What this page can honestly show is narrower: some transactions carry a plain-text tag at the front of their payload, such as ciph_msg:1:comm:…, which identifies the on-chain messaging protocol some Kaspa apps use to write encrypted messages into transactions. When a payload starts with a tag like that, this page shows an app: ciph_msg pill and nothing more: it is reading a literal string the transaction's own sender chose to include, not inferring anything. Any other payload here is unlabeled binary; guessing what wrote it would be exactly the kind of fabricated attribution this page exists not to do, so it stays unlabeled.
A ZK opcode call is not shown
Kaspa's script system supports a ZK verifier opcode, but the public REST API returns transaction scripts as opaque hex, not as decoded opcodes. Detecting one would mean disassembling script bytes client-side and matching a specific opcode value, which this page does not attempt. If that byte-level check turns out to be cheap and reliable, it's a reasonable thing to add later; today it isn't shown, rather than shown as a guess.
What a full block explorer has that this page doesn't
Explorers like Kaspa.stream run their own indexer against a database, which lets them show things a single API read cannot: a miner leaderboard built by clustering many blocks' payout addresses over time, top-address balances, and historical charts. Every one of those requires storing and aggregating history somewhere; a static page calling the public API on each visit has no database to build that from, and re-deriving it client-side on every load would mean hammering the API far past anything reasonable. This page only shows what one API read, right now, actually contains.
Why this only shows a handful of blocks per check
api.kaspa.org sits behind a Cloudflare edge cache with max-age=8: two requests inside that window get the identical cached response, so checking faster than every 8 seconds would not surface a single extra block, only waste requests. This page checks every 9 seconds. But Kaspa itself is producing roughly 10 blocks a second, so each check's tipHashes array (the network's current open tip set, typically 5 to 9 hashes) is a small sample of everything that actually happened since the last check, not the full count. The line above the block feed states both numbers plainly: how many blocks the network produced in that window against how many this page could fetch and show. The blocks-per-second figure next to it is not looked up anywhere; it is computed live from the change in blockCount between this page's own polls.
Endpoints used: api.kaspa.org/info/blockdag (tip hashes and blockCount, polled every 9 seconds; the API's own cache doesn't refresh faster than about 8 seconds, confirmed live 2026-08-22) and api.kaspa.org/blocks/{blockId} (one call per newly seen tip, header + transactions + color, capped at 16 per check; observed tip-set width stayed at 5-9 across dozens of live samples, and no per-IP rate limit is documented or was observed). Source for the API surface: api.kaspa.org/openapi.json. Baseline throughput and coinbase-share figures: this site's data/l1-chains.json, cross-checked against live reads on 2026-08-22. Covenant and block-producer caveats: this site's own CLAIMS.yml.