Executed freezes, and enough to recompute every one

Preconditions

What has to exist before the first entry

Definitions frozen at v1.0

The measurement definitions reach v1.0 and stop moving. Each part is versioned on its own, and both the endpoint definitions and magnitude are now frozen at v1.0. The content schema still rejects any entry that cites a candidate (unfrozen) version, so this precondition stays enforced by the build rather than by editorial memory — a figure computed under an unfrozen definition cannot be compared with the next one, the exact problem this project exists to fix.

Verifier released at a pinnable tag

The open-source verifier is published at a tag you can pin and run. No entry is published before the program that reproduces it is public — the sequence is deliberate and it is not reversible.

One execution final and independently recomputed

An enforcement action is final under its chain’s declared finality rule, and its recomputation agrees on two independently operated nodes. Agreement on one node is a result; agreement on two is a measurement.

Publication policy

Constraints, not promises

A promise is something we could quietly stop keeping. Each of the following is enforced somewhere other than editorial goodwill — in the content schema, in the build, or in the shape of the data itself.

Executed only, enforced by the build

An entry may describe only an action that has already taken effect on chain. The content schema accepts exactly one value for the stage field, so an entry in any other state is rejected at build time rather than caught by a reviewer.

Nothing unexecuted is released on a delay

An action that has not executed never appears here — not at ten minutes, not at ten days. A delay is not a mitigation; it is the same publication with a timer attached. Once an action has executed there is nothing left to escape, which is the whole reason the retrospective side is safe to publish and the other side is not.

Every entry ships its own definitions version

Entries name the definitions version they were computed under. Changing a definition never rewrites a published entry; a recomputed figure is published as a new entry that references the old one.

Corrections are publications, not deletions

If an entry is wrong it is corrected in place as a new revision that states what changed and why, and the superseded text stays readable. A retraction is an entry. Nothing disappears quietly, because a record that can disappear quietly is not a record.

A 24-hour cooldown, measured from our recomputation

An entry is not published until at least 24 hours after the moment we finish recomputing it — not 24 hours after the action executed. The clock starts when our recomputation is complete, giving the definitions, the digest, and the review a fixed settling period before anything is fixed in the record. The schema enforces the gap between recomputed_at and published, so an entry inside the cooldown fails the build.

Entry format

Every field a published entry carries

This is the complete field set — not a summary of it. The list is the content schema, so a field cannot appear in an entry without appearing here, and an entry missing a required field fails the build.

entry:        FS-0000-0000
lang:         en
title:        "<title>"
stage:        EXECUTED
executed_at:  0000-00-00T00:00:00Z
initiated_at: null
magnitude:    0.0            # null when unmeasurable (non-EVM / anomaly)
immobilised:
  units:      "0"
  decimals:   0
chain:        "<chain>"
asset:        "<asset>"
defs_version:
  endpoints:  "1.0"
  magnitude:  "1.0"
verification:
  tx_ref:     "0xdddd…dddd"
  precursor_tx_ref: "0xdddd…dddd"   # absent when initiated_at is null
  verifier:   "v0.0.0"
  digest:     "sha256:dddd…dddd"
sources:
  - label:    "<label> (retrieved 0000-00-00)"
    url:      "https://example.org/"
recomputed_at: 0000-00-00T00:00:00Z
published:    0000-00-00
reviewed_by:  editorial+disclosure

Verification

You will not have to take our word for a single number

Every published entry is a claim about public chain state, so every published entry is checkable by anyone with a node and the definitions. The procedure below is the whole of it. It requires no credential from us and works when our own servers are down.

1. 01 Take tx_ref from the entry and fetch that transaction from any full node or public explorer for the stated chain. Nothing in this step comes from us.
2. 02 Confirm the transaction is final under the finality rule declared for that chain on the methodology page, then read its block timestamp. That is executed_at.
3. 03 Read U and T by freeze type: for an in-place freeze, the target’s balance and the total supply at the end of the execution block; for a destroy or clawback, the burned amount from the transaction’s event logs and the total supply at the end of the preceding block. Where the chain’s standard nodes serve only the latest state, neither is readable at that block: rebuild U from the contract’s transfer log instead, as the methodology page sets out, and expect T — and therefore the magnitude — to stay null. Check the U you have against the immobilised field, apply the published magnitude function to U / T, round to one decimal, and compare with the magnitude field. For an entry whose magnitude is null, verify the stated blind-spot reason instead.
4. 04 If the entry names a precursor_tx_ref, fetch that transaction too, check that it sits in an earlier block than the execution and carries the same target, and take its block timestamp: that is initiated_at, and executed_at minus it is the interval. If there is no precursor_tx_ref, initiated_at is null, no interval exists for this event, and none is published.
5. 05 Run the verifier at the tag named in the entry, pointed at your own node. It reads the entry and public chain state and prints a digest.
6. 06 Compare that digest with the digest field. Byte equality or the entry is wrong; there is no partial pass.
7. 07 If it does not match, tell us. A reported mismatch is answered publicly, and if the entry is wrong it is corrected as a new revision that says what changed.

Read the full definitions →

Boundaries

What the Bulletin will not carry, including once it is full

Any time figure split by issuer

Intervals are aggregated across issuers and across chains. A per-issuer table of intervals is an operational map rather than a research finding, and it would be read as one by the people best placed to use it that way.

A coverage table or a supported-issuer list

Which enforcement surfaces are observed, and how well, is not published. In a table like that the empty cells carry more information than the full ones, and they carry it to the wrong reader.

A quoted or typical lead time

No interval is offered as typical, expected, or contractual. Whatever interval exists is a by-product of how an issuer happens to be governed, and an issuer can take it to zero without telling anyone — including us.

A byline

Entries are published under the company name and nothing else. There is no author whose reputation you are asked to weigh; the verification block is what you check instead.

A ranking, a directory, or a bulk export

The Bulletin is a record of executed actions, not a list of parties. Entries are ordered by time and there is no export that turns them into a dataset about anyone.