What is a Transparency Service?
A Transparency Service (TS) registers signed statements in an append-only log and issues a receipt proving inclusion — so a record can be shown to exist, and a later attempt to drop or rewrite it would be detectable.
You don't call this service directly. seal() registers the digest for you and hands back a witnessed record — this page explains what's happening underneath.
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, keep the log |
| 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 keeping a log 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 ↗