What is a Transparency Service?
A Transparency Service (TS) registers signed statements, issues a receipt proving inclusion, and anchors them to an append-only log — so a record can be shown to exist and to never have been quietly dropped or rewritten.
What it does
- 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.
- Anchor. 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, anchor |
| 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 anchoring 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 anchoring makes it trustworthy ↗