Signed records
Signed records state who authorised an action, what it applies to and where it belongs in the history. This page describes their meaning and relationships. The representation rules are explained in Signatures and encoding.
Creator record
The routing and policy record a name resolves to. Signed by the creator root.
| Contains | Meaning |
|---|---|
| Root public key | The creator’s identity, and their identifier |
| Profile commitment | Hash of the display profile blob |
| Delegation commitment | Hash of the currently valid host delegation |
| Provider list | Ordered payment provider keys |
| Manifest commitment | Hash of the current content manifest head; absent before the first publish |
| Schedule commitment | Hash of the current tier schedule |
| Sequence number | Higher supersedes |
The provider list is ordered: the first entry is the processor of record and the rest are failover order. A host cannot reorder it, insert itself, or route outside it.
Re-pointing after a host switch means publishing a record with a higher sequence number.
Host delegation
The grant that lets a host sign. Signed by the creator root.
| Contains | Meaning |
|---|---|
| Creator | Whose log this covers |
| Host key | The host being delegated to |
| Epoch | The single epoch covered |
| First and last position | The inclusive range of log positions the host may occupy |
| Expiry | Display and operator policy only — never consulted for validity or freshness |
A host action outside its epoch or outside its position range is invalid even when validly signed by that host. See Delegation and switching.
Epoch close and epoch open
A close fixes the position and hash of the last entry in the epoch. An open names the epoch being started, its first position, the close it chains from, and the host taking over.
- An opened epoch is exactly one higher than the closed one, and starts at the next position.
- The chaining commitment means epochs form an unbroken sequence; a gap or an overlap does not verify.
- A normal close is signed by the outgoing host. A forced close is signed by the creator root and needs no cooperation from that host.
Tier schedule
What is on offer. Signed by the creator root, so a host cannot alter pricing or scope.
Each tier carries an identifier unique to the creator, a price in minor units, a currency, a period length, the set of content classes it entitles, and whether it is still active.
Deactivating a tier prevents new issuance under that offering. Existing membership evidence remains part of history, but access to a requested content class also depends on the current schedule and the verifier’s policy. Historical issuance and present access are separate questions.
Entitlement
The membership itself. Signed by the host holding a valid delegation at the time of issuance.
| Contains | Meaning |
|---|---|
| Member key | The bound member identity for this creator |
| Creator | Whose membership this is |
| Tier | Which tier was purchased |
| Paid through | The last billing period ordinal paid for |
| Sequence number | Per member and creator; higher supersedes |
| Receipt commitment | Hash of the payment receipt that licensed it |
Presentable only by the bound member key. Presentation by any other key returns wrong subject — never a weaker pass. The service must authenticate control of the presenting identity. Comparing a claimed identity with the record is insufficient. Binding prevents a copied credential alone from granting access; it cannot prevent deliberate sharing of account secrets.
Payment receipt
Evidence a payment happened. Signed by a payment provider, and carrying the provider, creator, member, tier, period, amount, currency and an opaque provider reference.
Valid only from a provider in the creator’s current ordered list. A well-formed receipt signed by any other key licenses nothing.
Content item and manifest head
A content item records a publication, a supersession, or a removal. It carries its position in the content chain, a commitment to the previous item, the content class, and the hash of the sealed blob. Supersession and removal name the item being acted on.
Removal is an explicit chained event, never a silent deletion.
The manifest head names the newest content item, so a client can find the end of the chain without walking it.
Share grant
A member authorising one verifier to see one membership. Signed by the bound member key.
It carries a commitment to the entitlement, the grantor, the single verifier key it is for, a human-readable purpose, and an expiry.
- A grant is not bearer material. It names one verifier.
- Expiry is expressed as a log position after which the grant is dead, not as a timestamp.
Invite
An invitation connects an imported audience entry to a single-use claim. It identifies the creator and offering, commits to the claim token, and contains a derived value used to recognise duplicate imports.
Redeeming an invitation still requires valid evidence for the resulting membership. Importing a roster does not transfer payment instruments, recurring-charge authorisations or the previous service’s billing history. See Privacy.
Device certificate
A device certificate describes authority granted to a device under a root identity, including a limited capability where appropriate. Replacing or revoking the certificate changes the grant; it does not erase secrets the device already holds.
In particular, a device that has received account-wide recovery material cannot be made harmless by changing a certificate alone. Devices distinguishes certification from replication of account secrets.
Provenance
A provenance attestation is a third party’s signed statement about a subject. It supplements the evidence without becoming the creator’s root of authority.
A verifier may require particular supporting attestations under its own policy. Missing required attestations cause that policy to fail; a verifier that does not require them can evaluate the underlying membership without them. Attestation policy is therefore part of the trust decision, not a universal endorsement.
Revocation
Ends the validity of a subject. It names what kind of thing is being revoked — a device certificate, a host delegation, a share grant, a membership, or an invite — together with a commitment to the specific object.
Cancel, refund and lapse are all membership revocations and are byte-identical on the log. All three read as revoked, and a verifier cannot distinguish them. This is deliberate; see Memberships.