INVAR Open app

Measured on Robinhood Chain

Two clocks, and only one of them stops

Robinhood Chain produces a block every 0.101 s, without pause. The exchange that decides what these assets are worth is matching orders 18.7% of the time. Everything below is read from the chain or computed by js/sessions.js, which builds the exchange calendar from its published rules and checks itself against known dates before any of this runs.

101ms
between blocks, measured over a hundred thousand of them
18.7%
of the chain’s life the exchange has been matching orders
80h
the longest unbroken closure in the window
1.4m
blocks produced inside that closure, during which the market never opened once

Where the clock goes

Regular session 18.7%
Pre-market 15.9%
After hours 11.6%
Shut 53.8%
Share of the chain’s life in each session class, from 2026-04-30 to 2026-09-04. Computed minute by minute against the exchange calendar: 10 full holidays and 2 early closes in 2026, weekends, and the daylight-saving transitions.

Where the transfers go

Regular session 15.4%
Pre-market 10.5%
After hours 18.7%
Shut 55.4%
Share of 196,887 tokenised-equity transfers, sampled across 300 windows spread uniformly through the chain’s active range. 0.150% of that range was actually read.

Transfers per hour of each kind of time

The share above is not the finding. The four classes have wildly different durations, so “most transfers happen while the market is shut” would be true of a market that traded perfectly evenly. A rate has its denominator built in.

Regular session 79,203
Pre-market 60,789
After hours 147,224
Shut 98,231
Per hour of each kind of time, the tape runs faster while the exchange is shut than while it is open: 79,203 transfers an hour while the market is matching orders, against 98,231 an hour while it is shut — 124% of the open rate. The busiest hour of the four is after hours, at 147,224 an hour.

What this does and does not say

It does not say the on-chain price is wrong while the exchange is shut. It says there is nothing for it to be wrong about: for 81% of the clock there is no auction in the underlying anywhere in the world, and any number quoted then is an opinion about what the auction will say when it reopens.

That is a normal state of affairs for a derivative, and it is priced accordingly everywhere it is acknowledged. What is not normal is quoting it with no marker. Every front page in this category prints a share price and none of them prints which clock it was read on.

The chain’s own memory

Worth knowing if you intend to check any of this yourself. The public node answers eth_getLogs from block zero — 127 days of complete event history — and refuses a state question at any block older than 10 minutes with metadata is not found. 6,031 blocks of state, against 54m blocks of logs.

That asymmetry is why everything on this site is built from events and from the latest state, never from historical state, and it is why the Bar contract records its own price history rather than leaving it to be reconstructed.

The chain was not always this fast

A single “seconds per block” figure would be wrong about one end of this chain or the other. From block 1 it ran at about two minutes a block for two months; from block 4.5m onward it runs at a tenth of a second and has not varied since.

BlockDates / block
1 2026-04-30 117.9755
4.5m 2026-07-08 0.1003
9.1m 2026-07-13 0.1003
14m 2026-07-19 0.1004
18m 2026-07-24 0.1003
23m 2026-07-29 0.1002
27m 2026-08-04 0.1003
32m 2026-08-09 0.1003
36m 2026-08-14 0.1003
41m 2026-08-19 0.1003
45m 2026-08-25 0.1003
50m 2026-08-30 0.1012

Averaged over the whole chain the answer is 0.202 s; over the last hundred thousand blocks it is 0.1012 s. The site quotes the second, and the sampling for every measurement here is restricted to the fast range for the same reason — uniform in block number is uniform in time only when the block time is constant.

How the sample was checked. A sample that over-represents one class makes every share above a property of the sampling rather than of the chain. The scanner compares the seconds of each class it actually looked at against the calendar’s own shares over the same range and refuses to write a result if any class is off by more than a tenth. Worst deviation in this run: 6.1%. Windows dropped for hitting the node’s ten-thousand-row cap: 0 — a truncated window is censored toward whichever session happened to be busy, so it is discarded rather than counted.