The headers around the point where each Bitcoin Knots BLAKE2b chain left Bitcoin Core's chain, decoded and validated here with the schema engine and its Knots overlay. The headers are a static snapshot from a Knots node; they never change, so nothing is fetched live.
how this works
Not a new genesis. Knots keeps Bitcoin's history up to the last shared block. On mainnet the split is at 961,632, the start of difficulty period 477: Knots' 961,632–961,639 are eight ordinary SHA256d blocks that Core's chain does not have (Core mined different blocks at those heights), and 961,640 is the first BLAKE2b block with the 164-byte header. On testnet4 the split and the first BLAKE2b block coincide at 150,308. All of these are hard checkpoints in Knots, so a Knots node never reorganises onto Core's branch. Core rejects the first BLAKE2b header outright: it reads the version field as a signed integer and bit 31 makes it negative.
Each row runs the engine's header rules: link to the previous header, proof of work (SHA256d before the fork, BLAKE2b from it), difficulty, median time past, future time, version, timewarp, plus the overlay's fork rules (v1 until the fork, v2 from it, committed height, reserved flag bits). Difficulty is checked from the second header on, median-time-past once eleven prior headers are in view. Hover a mark for the rule name.
Engine: bitcoin-desktop/schema@v0.0.25 via jsDelivr, unmodified; the BLAKE2b support is the knots-blake2b overlay. Data: boundary-mainnet.json, boundary-testnet4.json (from a local Knots node; the Core-side hash from a local Core node). Header layout: docs/header-v2.md. Live tip: headers page. Source: play-grounds/knots.