Memberships
Membership standing is derived by applying the recorded events for one member and one creator in order. The host cannot establish validity merely by returning a status from its own database.
States and transitions
A membership is subscribed, or revoked. It begins with an issuance, continues through extensions, and ends with a revocation. It may begin again afterwards.
| Transition | Licensed by | Constraints |
|---|---|---|
| Subscribe | A receipt from a current provider, plus a host-signed entitlement | First membership starts at sequence zero; receipt values match the entitlement |
| Renew | A new receipt and a new entitlement | Sequence increments by exactly one; paid-through strictly increases; same member key |
| Cancel | A membership revocation | Names the entitlement being revoked |
| Refund | A membership revocation | Identical on-log form to cancel |
| Lapse | A membership revocation | Identical on-log form to cancel |
| Reissue | A fresh receipt and entitlement at the next sequence | Only from revoked |
Invalid transitions include:
- The sequence number is not exactly one higher than the previous.
- An extension does not increase the paid-through period.
- The member key differs from the membership’s bound key.
- An issuance arrives onto a membership that is already live.
Periods
Paid coverage is expressed as a billing-period ordinal: an ordered period number, rather than a timestamp. The creator’s current period begins at zero and advances through valid recorded payment events. It cannot move backwards, and an event cannot jump it forward by more than one period.
Standing is evaluated against that recorded progress:
| Standing | Meaning |
|---|---|
| Active | The current period is covered by the membership’s paid-through period. |
| In grace | Paid coverage has ended, but the grace allowance accepted by the verifier remains. |
| Expired | Paid coverage and accepted grace have ended, with no revocation yet recorded. |
| Revoked | The history contains a revocation ending the membership. |
Grace is measured in recorded periods. It is an input to the verifier’s policy; a service may require paid standing and decline grace.
Once grace is exhausted, the host can record a lapse as a revocation. Until then, the membership is already expired. Delaying the lapse entry must not extend access.
For example, a membership paid through period four is active at period four, in grace at period five if one grace period is accepted, and expired at period six. These are positions in the billing history, not dates inferred from a device clock.
Cancel, refund and lapse are indistinguishable
All three are membership revocations naming the same subject, and produce byte-identical entries. A verifier cannot tell which occurred.
This is deliberate. A verifier’s legitimate question is “is this membership currently good?” — not “did this person cancel, get refunded, or have a card decline?” Answering only the first is both sufficient and less revealing.
A completed refund flow must also record the corresponding membership revocation. A verifier that receives history containing that event rejects the revoked membership. Old evidence cannot reveal a refund that occurred after its checkpoint, which is why freshness remains a separate requirement.
Subject binding
A membership binds one member key, and only that key may present it. Presentation by another key returns wrong subject — never a partial or weaker pass. The service checking access must authenticate control of the presenting identity. A copied credential alone should not grant access; deliberately shared secrets remain outside that protection.
Presentation to a specific verifier is authorised by a share grant signed by that same member key, naming one verifier and expiring at a log position.
What a member holds
- Their identity key for that creator.
- The current membership and the receipt it references.
- The material needed to unseal content they are entitled to.
Together with the supporting directory and history evidence, those holdings support offline verification. Moving them to another device requires the account material described in Devices.
The membership identifies one relationship. The host still knows the memberships it records, and the creator needs an audience view to distribute content access. Separate identities limit cross-creator correlation; they do not hide membership from every participant.