Log & epochs

Each employer has exactly one append-only log, written by a single registrar at a time. This page covers how the log is chained, how authority over it is granted and rotated through epochs, and the signed heads that make its history witnessable.

The hash chain

Every log entry is a signed tn-* object, and entries are chained by hash: each entry’s hash is BLAKE3(payload_bcs || prev_hash), where prev_hash is the previous entry’s hash (empty for the first entry). Because each entry commits to its predecessor, inserting, removing, or editing any entry changes every later hash — and therefore the head.

The event log and revocations are append-only, enforced by database triggers. Those triggers guard against application bugs; the real defence against a malicious rewrite is the witnessed head, not the database.

Epochs: authority that can be rotated

An attestation is signed by the registrar, not the employer. The employer authorizes a registrar by signing an EpochOpen that names the registrar’s key and the sequence number its signatures become valid from, and chains to the previous epoch by referencing that epoch’s final head. An EpochClose ends an epoch at a definite sequence and head.

The chain of epochs verifies back to the first one, since each EpochOpen is employer-signed and points at the prior epoch’s closing head. This is what lets an employer change registrars without invalidating history: the new registrar opens the next epoch pointing at the old epoch’s final head, and every attestation from the previous epoch still verifies. See Misbehavior & switching.

Delegations: what a registrar may mint

Naming a registrar is not enough; a Delegation bounds what it may do. It lists the attestation types the registrar may mint, a daily mint cap, a sequence range it is valid across (with an optional forward-only revocation point), and a time window the claims’ as_of must fall in.

A registrar-signed attestation is valid only if some delegation for its epoch allows its type, covers its sequence number, and contains its as_of in the time window. The registrar enforces this, and every verifier re-checks it on import — so a mint of a type the delegation never allowed is rejected even though the signature on it is genuine. This is the “signed is not the same as authorized” rule.

Signed heads & checkpoints

The head of a log is its latest sequence number and hash. It is published two ways:

• A LogHead is returned inside every operation receipt, so wallets keep a witnessed head for each attestation they hold.
• A Checkpoint is the same head with a timestamp, mirrored to at least two independent locations at a regular cadence and at every epoch boundary. Its timestamp is exactly the “not revoked as of 14:02” line on the verdict card.

Because a head names a single (employer, seq, hash), two registrar-signed heads for the same employer and sequence but different hashes are a self-verifying conflicting-head proof that the registrar rewrote history. The wallet, the Signer, the dashboard, and the verifier all run the same check.

Inclusion receipts

Each time the registrar appends an entry it returns an operation receipt — the entry’s sequence number and hash plus the signed head covering it. The wallet keeps it as independent proof that a specific attestation was in the log at a specific head, which survives even if the registrar later disappears or tries to disown the entry.