What to monitor in each phase

Read Activation and fork paths and Scenarios and the split matrix first. This article assumes the state machine and the outcome space.

The four guardrails

Four cautions recur across every phase. They are printed on the live panels too, and stated once here, plainly:

• Absence is not rejection. A transaction missing from a node's mempool is a policy or timing outcome. It is never, on its own, proof that the transaction would be invalid in a block.
• A header bit is a claim, not enforcement. Bit 4 in a header says a miner set a bit. It does not prove the miner validated the new rules or will reject an invalid block.
• Signalling is not hashrate. The share of blocks that signal is a share of blocks, measured after the fact. It is a rough proxy at best for hash power that would actually sustain a separate branch.
• Node counts are not economic weight. A crawl counts reachable listening nodes advertising a flag. It is not hash power, not settlement demand, and not authenticated enforcement. A single node can be spoofed, and a thousand non-mining nodes produce no blocks.

The instruments and what each one measures

Each live panel maps to exactly one measurement. The table is the reference; the phase sections below say when each one matters.

Deployment state, every phase

The primary introspection RPC in the reviewed clients is getdeploymentinfo. For the reduced_data deployment, the fields worth recording are status and status_next, since, the bit number, the current period's elapsed, count, threshold, and possible, the max_activation_height, the activation height once known, and height_end for the temporary active interval. The top-level active field concerns the next block. Around any boundary, always record the queried tip hash as well as the height, because state is branch-relative and a reorg can otherwise make an observation ambiguous.

Voluntary STARTED (now through height 961,631)

Watch: the per-period signalling count against the 1,109 threshold, and whether any completed period reaches it (which would move the whole schedule earlier and skip the mandatory window).

Panel: signalling by period.

Guardrail: bit 4 is a header claim, not enforcement, and signalling is not hashrate. A qualifying signal needs both the top pattern 001 and bit 4; a bit set under a different top pattern does not count.

For context, and only as a dated snapshot, the walkthrough's direct header counts through block 957,808 showed every completed period below 1 percent: the highest absolute count was 20 of 2,016 in period 474 (about 0.99 percent), and period 475 had 2 signals in its first 209 blocks. On that basis the walkthrough's evidence-based base case is that no early threshold is reached, which moves the decisive event to the mandatory height. That is a base case, not a certainty: a large pool switching templates can move the signal rate far faster than extrapolating old blocks would suggest.

Transaction relay is already partly partitioned in this phase, because the BIP software applies RDTS-style checks as mempool policy before the rules are consensus rules. That is what the mempool-divergence panel begins to show even now.

Panel: mempool divergence (Core vs Knots).

Guardrail: absence is not rejection. A transaction the Knots mempool drops is failing a relay-policy check, not being ruled consensus-invalid.

Mandatory signalling (heights 961,632 through 963,647)

This phase applies only if the branch is still STARTED at 961,632.

Watch: the first non-signalling header at or after 961,632, whether a valid signalling alternative child of the last common block exists, and whether any node reports a second tip. A non-signalling block is rejected at header validation with reason bad-version-reduced_data, before its body is downloaded.

Panel: chain tips, backed by split telemetry if a fork materialises.

Guardrail: the header signal now tells you which branch a block can belong to, but it still does not prove enforcement of the transaction rules, which are not active yet. A miner can cross this window on an all-signalling history without ever running the validation that would reject an RDTS-invalid transaction later.

This is also where the parent-choice distinction from the scenarios article becomes concrete. Setting bit 4 and mining on the BIP-valid parent are two different acts. The signalling panel shows the first; only the chain-tips panel, tracking which parent each block extends, shows the second.

Lock-in and activation (heights 963,648 through 965,663, then from 965,664)

Watch: in LOCKED_IN, the schedule to activation and whether the branch keeps advancing. From ACTIVE, the first RDTS-invalid block body, which is where the transaction rules finally bite.

Panel: event clock and split telemetry.

Guardrail: activation is not a split. An active-period violation usually requires the block body and the UTXO or script checks to detect, so a valid-looking header can still sit on top of an invalid block. And if no violating block is ever mined, the rule difference stays latent and one chain can persist. The absence of a split-telemetry panel in this phase is the null-result case, not a verdict that enforcement failed.

The enforcement census, throughout

Watch: the count of reachable nodes advertising service bit 27 (NODE_REDUCED_DATA).

Panel: enforcement census.

Guardrail: node counts are not economic weight, and the service bit is spoofable. It is an unauthenticated handshake claim, not proof of validation. A user-agent string is even weaker evidence, because the official Knots release uses an ordinary Knots user agent while the standalone client adds a BIP-110 suffix, so the bit is the only census signal that survives.

As a dated snapshot only: a public crawl on 2026-07-02 reported roughly 2,483 nodes (about 9.6 percent) running the RDTS-capable Knots v29.3.knots20260508 build and roughly 789 (about 3.0 percent) running the standalone client, for an enforcing-capable set near 12.6 percent of listening nodes. These are software-reported reachability cohorts, not authenticated enforcement, hash power, or economic weight.

Pool intent, through the signalling phases

Watch: per-endpoint Stratum job intent, meaning whether the jobs a pool endpoint pushes carry bit 4.

Panel: pool intent.

Guardrail: intent to signal is not proof of enforcement, and an endpoint's advertised job is not the template a downstream miner ultimately builds. Treat separate endpoints as separate sources.

As a dated snapshot only: on 2026-07-14, direct probes observed one large pool operating three distinct endpoints, one signalling bit 4, one not, and a default endpoint that was announced to switch to signalling. The lesson generalises: capture each endpoint separately and capture transitions, and read the result as work advertised by a public endpoint, not as attached hashrate or local enforcement.

Peers and topology, throughout

getpeerinfo shows advertised service flags, connection direction and type, user agent, and best-known heights. Useful observations are service bit 27 (often rendered REDUCED_DATA?), automatic versus manual connections, inbound versus outbound direction, repeated disconnects following invalid headers, and peers whose best chainwork or height diverges. Treat every identity and service field as a claim to be corroborated against actual header and block behaviour.

The P2P overlay does not cleanly split into two networks. The BIP software prefers peers advertising the new bit but keeps Bitcoin's genesis, magic, port, and encodings, so inbound and manual cross-branch connections can remain, and transactions valid on both sides can keep crossing them. A retained cross-branch peer does not make the remote branch valid, and it is not replay protection. For fork monitoring specifically, an ordinary node's getchaintips is not a complete archive: invalid mandatory-window headers are rejected before normal indexing, and low-work anti-DoS logic can hide a deeply lagging alternative. Dedicated capture uses manual peers, explicit permissions, separate nodes, and persistent raw header and block storage.

Freshness: read the bead, not just the number

Every live panel carries its own freshness bead (live, caution, or stale), set per source rather than for the page as a whole. Fast-moving sources like mempool divergence and chain tips warn within a minute; block-paced sources like signalling warn after tens of minutes; the enforcement crawl is hourly and warns after a few hours. A stale bead means the reader is looking at materially old data, which is itself worth knowing before drawing any conclusion from the number next to it.

What to watch

This whole article is the watch list. The one-line version: read each panel as the single thing it measures, read its freshness bead before its value, and never let one instrument answer a question that belongs to another. Then open the Live dashboard, where these same panels and guardrails are laid out in the bottom-up order a real split would appear.

Sources

This page restates the BIP-110 technical walkthrough sections What to monitor in each phase (deployment state, header signals, peers, chain tips and rejected data, mempools and replay exposure) and P2P topology and data propagation. The dated signalling figures are from that walkthrough (block 957,808 snapshot); the dated node-count and pool-endpoint figures are from the BIP-110 current-state refresh (2026-07-02 and 2026-07-14). All current values on the Live page are rendered from the read model, not from these snapshots.