Log & epochs

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

The hash chain

Every log entry is a signed object. Entries are chained by hash: an entry’s hash is the BLAKE3 digest of its own canonical bytes concatenated with the previous entry’s hash. The genesis entry uses an empty-string sentinel in place of a predecessor.

Because each entry commits to its predecessor, inserting, removing, or editing any entry changes every subsequent entry hash — and therefore the head.

The log’s entry types are exactly: Employer Descriptor, Entity Attestation (KYB), Epoch Open, Epoch Close, Delegation, Attestation, Family Supersession, Status Change, Revocation, Reissue, and Checkpoint.

The log and the revocation set are append-only, enforced by the storage layer, which rejects updates and deletes outright. That enforcement guards against application bugs; the real defense against a malicious rewrite is the witnessed head, not the store.

Epochs: authority that can be rotated

An attestation is signed by the registrar, not the employer. The employer authorizes a registrar by opening an epoch:

• An Epoch Open is signed by the employer. It carries the employer identifier, the epoch number, the registrar public key, the sequence number from which that registrar’s signatures become valid, a pointer to the prior epoch’s closing head, and an effective time. The prior-epoch pointer is empty for epoch 1.
• An Epoch Close is signed by the employer to end an epoch at a definite point. It carries the employer identifier, the epoch number, the final sequence number, and the final head hash.

The chain of epochs verifies back to epoch 1: each Epoch Open is employer-signed, and each prior-epoch pointer must match the preceding epoch’s closing head. This is what lets an employer switch registrars without invalidating history — the new registrar opens epoch k+1 pointing at the old epoch’s final head, and every attestation from epoch k still verifies. See Misbehavior & switching.

Delegations: type- and rate-capped authority

Naming a registrar is not enough; the employer also bounds what it may do via a Delegation. A delegation names the employer, the epoch, and the registrar key, and then constrains authority along four axes:

Bound	Meaning
Allowed types	Which attestation types the registrar may mint
Daily cap	The maximum number of mints permitted per day
Sequence range	A starting sequence number, and an optional ending sequence number that acts as a forward-only revocation point
Time window	The earliest and latest “as of” time a minted claim may carry

A registrar-signed attestation is valid only if some covering delegation:

1. is for the attestation’s epoch,
2. includes the attestation’s type among its allowed types,
3. begins at or before the attestation’s log sequence number and, if it names an ending sequence number, ends at or after it, and
4. has a time window containing the attestation’s “as of” time.

The registrar enforces this when writing, and every verifier re-checks it at import. A mint of a type the delegation never allowed is rejected even though the registrar’s signature over it is valid — the canonical statement of the “signed ≠ authorized” rule.

Signed heads & checkpoints

The head of a log is its latest sequence number paired with the corresponding head hash. There are two ways the head is published:

• A Signed Head carries the employer identifier, epoch, sequence number, and head hash. It is signed by the registrar and returned inside every operation receipt, so wallets retain a head for each attestation they hold.
• A Checkpoint carries the employer identifier, sequence number, head hash, and a publication time. It is signed by the registrar and mirrored to at least two independent mirrors at a configurable cadence and at every epoch boundary. The checkpoint’s publication time is exactly the “not revoked as of 14:02” line on the verdict card. The same head is optionally published to the directory, giving offline verifiers a survivable freshness anchor when the registrar is unreachable.

Because a Signed Head binds the employer, sequence number, and head hash together, two of them from the same registrar with equal employer and sequence number but different head hashes constitute a conflicting-head proof: self-verifying evidence that the registrar rewrote witnessed history. The wallet, the Signer, the dashboard, and the verifier all run the same conflict check.

Inclusion receipts

When the registrar appends an entry it returns an operation receipt naming the employer, the assigned log sequence number, the new entry’s hash, and the resulting signed head — epoch, sequence, head hash, and the registrar’s signature over it.

The worker’s wallet retains the receipt. It is the worker’s independent proof that a specific attestation was included in the log at a specific head — proof that survives even if the employer’s registrar later disappears or tries to disown the entry.