How we measure

Where do the numbers come from?

We measure ourselves, from full nodes we run or from our own header clients connected directly to network peers. Each report says which. We do not publish their addresses, hostnames or locations, so nobody can tune a network around our measurement.

Third party explorers serve as a cross check, never as the source of a published number.

What is a measurement window?

Each measurement has a fixed start and end in UTC, agreed before it starts. Before and after comparisons use two windows of the same length. Every published number names its window and the method version it was counted with.

What do we count?

• Blocks per second and per minute.
• Block time distribution. Median, p90, p99 and the longest gap between two blocks.
• Transactions per minute.
• Confirmation and acceptance time. From first sight of a transaction to its first block, and to the depth the network counts as final.
• Fees. Per transaction and per block.
• Stale and orphaned blocks. The stale block rate in % of all blocks seen.
• Propagation delay. The gap between the first and the last of our measurement points to see a block.
• Difficulty adjustment. How fast difficulty follows a change in hashrate.

Which method IDs do we use?

Each way of counting has a fixed ID. Every report and every measurement page names the IDs it uses, with a measurement uncertainty line for each number. An ID never changes its meaning. A changed method gets a new ID.

• PH-M-001, block intervals from headers
• PH-M-002, reorg depth from the listener
• PH-M-003, peer protocol version at the handshake
• PH-M-004, propagation from the listener
• PH-M-005, stale blocks after six confirmations
• PH-M-006, forecast of an activation time

The same IDs are described in METHODS.md in github.com/pulsehawk/methods, with the code as it is published.

PH-M-001 Block intervals from headers

Our own header client fetches block headers from network peers and checks hash linkage, proof of work from the difficulty bits and the checkpoints of the node software. Intervals are header time minus the header time of the block before.

Validation. Each run compares 500 block hashes with two independent peers. All 500 matched on Zcash mainnet on 2 November 2026, and on the Bitcoin Cash tempnet with two different node implementations on 28 October 2026.

Code. The calculation from our recorded data is in upgrade_report/report_v1.py. The implementation that records the data, our header client and listener, in github.com/pulsehawk/methods follows.

PH-M-002 Reorg depth from the listener

Our listener connects to peers without running a node, follows the tip from every announced block and logs each switch to another branch with its depth in blocks. The same listener raises the chain split signal.

Validation. Replayed on 29 October 2026 against our recording of the Zcash NU7 testnet of 17 October 2026, 776 chain blocks and 5 orphaned blocks of depth 1, with a reorg of depth 2 and a chain split added on purpose. Every case was detected as set.

Code. The calculation from our recorded data is in upgrade_report/report_v1.py. The implementation that records the data, our header client and listener, in github.com/pulsehawk/methods follows.

PH-M-003 Peer protocol version at the handshake

Our listener reads the protocol version each peer sends in the version handshake and counts the peers below the minimum protocol version of an upgrade. Only the version is kept, no address.

Validation. Checked in the replay of 29 October 2026. There is no independent comparison yet.

Code. The calculation from our recorded data is in upgrade_report/report_v1.py. The implementation that records the data, our header client and listener, in github.com/pulsehawk/methods follows.

PH-M-004 Propagation from the listener

Our listener records the first announcement of every block in milliseconds and the spread between the first and the last peer that announced it.

Validation. Compared on 28 October 2026 with the public rufitnes/tempnet-data set for the Bitcoin Cash tempnet. All 4,207 blocks matched by hash, and the first announcement differed from his receive time by a median of 0.01 s.

Code. The calculation from our recorded data is in upgrade_report/report_v1.py. The implementation that records the data, our header client and listener, in github.com/pulsehawk/methods follows.

PH-M-005 Stale blocks after six confirmations

A block counts as stale when it was announced to our listener and is not in the chain six blocks later. The share is stale blocks over chain blocks plus stale blocks.

Validation. Compared on 28 October 2026 with the reorg events in rufitnes/tempnet-data. The two measure different things, a node logs a reorg only when its own tip had moved. There is no independent count of the same quantity yet.

Code. The implementation in github.com/pulsehawk/methods follows.

PH-M-006 Forecast of an activation time

From the block pace we counted over the last full UTC days, 20,000 draws give the median time at which a block height is reached and a 90 % band. Every forecast is published with its date and scored on our track record.

Validation. The first check against a real activation is Zcash NU7 (ZIP 259) on mainnet, listed on our track record.

Code. The report rows are computed in upgrade_report/report_v1.py. The implementation of the forecast itself in github.com/pulsehawk/methods follows.

What are the rules we publish by?

What is in a report?

1. Summary. The answer in a few sentences, with dates.
2. Window. Start and end in UTC, network, node software versions.
3. Charts and tables. Median, p90, p99 and the longest gap, before and after.
4. Method. The method version used, with any deviation named.
5. Raw data. A CSV with every block and timestamp we counted.

The first public sample report is Zcash NU7 on testnet, published on 18 October 2026.

What do we not do?

We do not review or audit code. We do not audit security. We make no statements about prices. We do not run validators or mine for clients, and we never publish node IPs or hostnames.