What is a Transparency Service?
A Transparency Service (TS) registers signed statements, issues a receipt proving inclusion, and witnesses them into an append-only log — so a record can be shown to exist and to never have been quietly dropped or rewritten.
You don't call this service directly. seal() (today's API: emit()) registers the digest for you and hands back a witnessed record — this page explains what's happening underneath.
The notary analogy
Think of it like a notary. A notary doesn't read your document for truth and doesn't vouch that what it says is accurate — a notary confirms that a specific document existed, in a specific form, at a specific time, and stamps a record of that fact into a public book anyone can check later. A Transparency Service does the same thing for a capsule's digest: it doesn't know or care what the capsule says, only that it existed, unaltered, as of a given moment — and, via the append-only log, that the moment can't quietly be moved later.
Why it's like a git push
Unpushed commits on your laptop can be rewritten, reordered, or dropped without a trace — git commit --amend, git rebase, anything goes, because only you can see them. Once you git push to a shared remote, that history is checkable by anyone with access: force-pushing over it leaves evidence, and a stranger who cloned the repo before the rewrite can prove what used to be there. A self-attested capsule is the unpushed commit — internally consistent, but only your word that it hasn't been quietly edited since. Witnessing it is the push: an independent, append-only copy now exists that you don't control alone.
What this actually establishes
Auditor register — what the record proves, and what it doesn't
A witnessed record is not a true record. The Transparency Service attests existence, order, and completeness — never accuracy or intent. It never grades the content up: it doesn't know whether the underlying action was appropriate, only that the statement describing it existed at a given time and hasn't been silently dropped or rewritten since.
Independently checkable without trusting the log operator: each signature (from the bytes), each inclusion proof (that the leaf is really in the tree), and consistency between any two tree heads (that history wasn't rewritten). Still resting on operational trust in the log operator: durable storage, non-equivocation (one consistent view for everyone), and a stable, published signing key — that's the trust commitment a Transparency Service carries that a verifier does not.
Registration ≠ Receipt ≠ Witnessing. Registration is the act of submitting the statement. A Receipt is the signed proof the service hands back. Witnessing is the log operator co-signing the checkpoint so the log can't equivocate later — three distinct things, often conflated. “Anchor” is avoided as a verb here because it collides with the unrelated PKI term trust anchor.
How it works
What it does, mechanically:
- Register. Accepts a
COSE_Sign1signed statement and appends its digest as a leaf in the log. - Receipt. Returns a signed inclusion proof you can verify offline against the log's public key.
- Witness. Publishes a signed tree head and the proofs that keep the log append-only over time.
What it is — and is NOT
A verifier checks evidence and holds nothing. A transparency service holds state and carries operational trust. Conflating the two is the most common mistake, so the boundary is worth stating plainly:
| Verifier | Transparency Service | |
|---|---|---|
| Operation | verify only | register statements, issue receipts, witness |
| State | none (stateless) | a durable, append-only log |
| Trust commitment | none — verify it yourself | uptime, integrity, non-equivocation |
| Risk class | low (read-only utility) | high (operational trust infrastructure) |
| Who must trust whom | nobody trusts the operator | the ecosystem trusts the log operator |
A verifier that begins storing submissions, issuing receipts, or witnessing has silently become a transparency service with all of its obligations.
The trust model
What you verify yourself: each signature, each inclusion proof, and consistency between any two tree heads — all from the bytes, offline. What the log commits to operationally: durable append-only storage, non-equivocation (one consistent view for everyone), and a stable, published signing key.
capsule-emit: The public log, explained ↗ · Why witnessing makes it trustworthy ↗