Which heights carry a post-quantum certificate, and how to compute the next one.
The rule today
An anchor height is any height on the grid H + k * 128, where H = 17,225,968. Not every multiple of 128: the grid is offset from that height. A client that tests height % 128 == 0 will pick the wrong blocks and reject valid ones.
Before block 17,225,968 the interval was 32, on its own grid.
History of the interval
| From block | Interval | Note |
|---|---|---|
| 13,014,000 | 32 | Anchor rules armed, minimum seals 0 |
| 13,034,000 | 32 | Minimum 3 of 9 |
| 14,961,456 | 32 | Minimum 6 of 9, a full quorum |
| 17,047,600 | 32 | Certificate format v2, hybrid |
| 17,225,968 | 128 | Current |
Deriving it rather than assuming it
The reliable way to find anchor heights is to read them off the chain: walk back from the head until you find two headers that carry a certificate, and the distance between them is the interval and their positions fix the grid. The interval has changed twice, so a hard-coded value has been wrong twice; deriving it from the chain is the form that keeps working.
A node's own copy of the schedule comes from the published package, not from a page. See Configure.
Why the interval exists at all
Cost. An anchor header carries the certificate, which is tens of kilobytes. A certificate in every block would multiply that across every height, and the result is not a storage inconvenience: it is a chain whose headers grow faster than any ordinary node can keep.
With an interval, the same security property survives with a bounded rewrite window: an adversary without the post-quantum keys can rewrite at most the tail since the last anchor, which at interval 128 is roughly 70 seconds of chain.
Seals attached versus seals required
The minimum is a floor, not a cap. Nodes attach as many valid seals as arrive in time, so a certificate at a six-of-nine minimum commonly carries eight or nine. Sizing anything from the minimum will under-count; measure the header.