Transparency feed#

Signed checkpoints prove your log's integrity to outsiders. The transparency feed addresses the harder question — proving it against Sigilbase itself — by making copies of your checkpoint roots exist outside Sigilbase. Once a root is public and mirrored, not even the operator of this service can rewrite the history beneath it undetected: a rewritten past would need new roots, and the old ones are already in other people's hands.

The feed is opt-in per stream (owners toggle it on the Streams page; part of external anchoring on the Business and Enterprise plans), unauthenticated, and deliberately cache-friendly. Mirror it. Copies existing outside Sigilbase are the entire point — a cron job that fetches latest daily and appends to a file is a meaningful audit control.

What is published, and what never is#

Each entry contains hashes and signatures only: a checkpoint's sequence range, checkpoint_hash, merkle_root, seal time, Ed25519 signature, and the signing key id. Payloads, actors, actions, resources, names, and slugs never appear. Feeds are addressed by random identifiers — one for the account, one per stream — so a feed reveals nothing about whose it is unless the owner chooses to say. Enabling is effectively permanent in one sense: disabling stops future publication, but roots already published are already public.

Endpoints#

A page of roots:

{
  "feed": "sigilbase-transparency/1",
  "tenant": "3f9c2b8a71d04e5f9b6a2c1d8e7f4a90",
  "page": 1,
  "page_size": 100,
  "entries": [
    {
      "stream": "b81d4c2e9f7a40318c6d5e2f1a0b9c87",
      "checkpoint_seq_range": {"from": 1, "to": 4},
      "checkpoint_hash": "1d78a3d9d7fbe21e18cdeaf6acec0eca75ad647a66b057e1e96873b37abbdec9",
      "merkle_root": "4a157629882340d739370041b824b38334a98777cfb805b89de4a7551c27b0d2",
      "signed_at": "2026-07-09T09:20:00.000000Z",
      "signature": "fbaeacd76624ef225988cb7b6c9112a25f57b8bab2e081659fa7ff17ca42a008...",
      "key_id": "2152f8d19b791d24453242e15f2eab6cb7cffa7b6a5ed30097960e069881db12"
    }
  ]
}

The list is append-only by construction: entries have a dense position per feed, pages are fixed windows over it, and a full page never changes (it is served with an immutable cache header; the growing final page only ever appends). If a mirror ever observes a published page change, that is evidence of tampering — keep both copies.

signature is the checkpoint's own Ed25519 signature over the raw bytes of checkpoint_hash; key_id is the signing key's public key, cross-checkable against GET /api/v1/keys. To tie a feed entry to an evidence bundle, match checkpoint_hash.

Super-roots#

Fetching every root forever is more than most mirrors want. Once a day, each opted-in stream gets a super-root: the SHA-256 of a canonical JSON preimage over that day's published roots, Ed25519-signed with the checkpoint signing key:

{"day":"2026-07-09","roots":["1d78a3d9...","6c22f0a1..."],"stream":"b81d4c2e9f7a40318c6d5e2f1a0b9c87","v":1}

Archiving one signed hash per stream per day is enough to later prove the whole day's roots were published as-is. A mirror holding the day's roots pages can recompute the preimage and check both hash and signature.

Relationship to the rest of the trust model#

The feed publishes exactly what evidence bundles and the verifier already prove — it adds distribution, not new claims. The core promise (chain, checkpoints, proofs, exports, verifier) is complete without it on every plan; anchoring is additional assurance against the strongest adversary, the operator. See How verification works for where each mechanism contributes.