Skip to content
Design documentation for a protocol at the proof-of-concept stage. Interfaces are not stable and this describes intended behaviour.

Protocol overview

This section specifies the Tenure protocol: the objects that travel on the wire, how they are encoded and signed, how authority is delegated and revoked, and how a credential is verified.

  1. Architecture — the actors (employer, registrar, KYB attester, worker, verifier, mirrors) and what each is and isn’t trusted for.
  2. Roles & the trust model — who signs facts about a person, who merely records order, and why verification is permissionless.
  3. Objects — the object catalogue and the claim schemas.
  4. Wire format — the domain-tagged canonical encoding rule, and the split between signed bytes and display transport.
  5. Log & epochs — the per-employer append-only hash chain, epoch-scoped authority, delegations, signed heads, and checkpoints.
  6. Verification — the pure five-check predicate and the one-time import verification of a full log.
  7. Claim families — how exact, band, and threshold variants are minted and retired together.
  8. Sharing & bundles — the worker’s signed consent record and the sealed bundle that carries everything a verifier needs, offline.
  9. Privacy — derive-then-purge, per-employer keys, and the public / authorized / holder-held data split.
  10. Misbehavior & switching — conflicting-head proofs and the epoch transition that lets an employer fire its registrar.

These are additive to the core protocol and never on the critical path of a verification.

  • Directory integration — an optional external transparency directory for trustless registrar discovery and a survivable freshness anchor.
  • Mel integration — the confederal endgame: a shared verifiable namespace, offchain non-equivocation, and light-client-first verification, with what is built separated from what is still to come.
  • Selective disclosure — the shipped design is signed bands and thresholds, deliberately not zero knowledge; the research track and its accepted limitations are stated plainly.

These hold everywhere in the protocol; the rest of this section builds on them.

  • Canonical bytes are BCS with a domain-separation tag. The only bytes ever signed or hashed are the serialization of a version-tagged label paired with the object body. The tag rides inside the signed bytes, so a signature over one object kind can never be replayed as another. JSON is a display projection — never signed, never hashed.
  • One signature scheme. All signatures are Ed25519. The permitted cryptography is exactly Ed25519, BLAKE3, X25519 with age-style sealing (ChaCha20-Poly1305 and HKDF), and an operating-system randomness source. Nothing else. No JWT.
  • The employer key is the root of trust. Every valid attestation chains back to an employer-signed epoch chain. The registrar signs under delegations the employer issued; a mint outside its delegation is invalid even though it is signed.
  • The log is truth. The event log and the revocation records are append-only; the set of current attestations is a projection materialized from the log. Hash chaining — each entry’s hash is BLAKE3 over the entry’s canonical payload bytes concatenated with the previous entry’s hash — plus externally witnessed signed heads make rewriting previously seen history detectable.
  • The verify predicate is pure. Chain, KYB attestation, grant, revocation set, and the current time all arrive as arguments. The same predicate runs in the portal, the wallet, and the static verify page, and an independent second implementation reproduces its results byte for byte.
Quantity Encoding
IDs ULIDs (strings)
Public keys lowercase hex
Signatures base64url, no padding
Hashes lowercase hex (empty string = genesis / none-yet)
Money integer cents (never floats)
Dates unix seconds
Enums (canonical) BCS variant indices; string forms exist only for storage and display