A record you can't rewrite

A cryptographic signature proves that whoever holds a private key signed a particular statement. That is powerful — but notice what it does not prove: it does not prove when the statement was signed, and it does not stop the signer from later issuing a different, conflicting statement, or an operator from quietly deleting an inconvenient record. For a proof of origin, "when" and "unaltered forever" are the entire point. Closing that gap is a different problem than signing — and it is the problem transparency logs were built to solve.

A signature is not a timeline

Imagine a registry that signs every proof of origin with an Ed25519 key. Strong signatures, clean cryptography. Now imagine the operator wants to cheat. Nothing in the signature scheme itself stops them from:

• backdating a proof to claim earlier origin,
• issuing a second, conflicting proof for the same content,
• or deleting a record that later becomes inconvenient.

Signatures authenticate a statement. They say nothing about the history of statements — whether the set has been added to honestly, or rewritten. That history is what you actually need to trust an origin claim.

The append-only idea

A transparency log is a public ledger with one rule: records can only be added, never edited, deleted, or reordered. Once something is in, it is in — and anyone can check that the rule was followed. The structure that makes this efficient and verifiable is the Merkle tree.

Merkle trees in one paragraph

Take every record and hash it — those hashes are the tree's leaves. Hash each pair of leaves together to get their parent; hash pairs of parents; keep going until a single hash remains at the top: the root. Because every level feeds the one above it, changing any record changes its leaf, which changes every hash on the path to the root — so the root is a compact fingerprint of the entire log. (0byte, like Certificate Transparency, domain-separates the hashes — a distinct prefix byte for leaves versus internal nodes — to block a class of tree-manipulation tricks.)

Two proofs anyone can check

Merkle trees give you two lightweight proofs that need no trust in the operator:

• Inclusion proof. To show a specific record is in the log, the operator provides a short chain of sibling hashes leading from that record's leaf up to the published root. You recompute the root yourself; if it matches, the record is genuinely in the tree. This takes on the order of log(n) hashes — a few dozen, even for a log of billions.
• Consistency proof. To show the log only grew between two points in time — nothing removed or rewritten — the operator provides hashes proving the old root is fully contained in the new one. This is what makes "append-only" verifiable rather than a promise.

The attack it stops

The subtle attack against any log is the split view: show one version of history to you and a different version to someone else. Transparency logs defeat this with consistency proofs plus independent monitors and gossip — parties that watch the published roots and compare notes. A log that ever presents two inconsistent histories gets caught, because the roots won't reconcile. Trust shifts from "the operator is honest" to "cheating is detectable by anyone watching."

Borrowed from the web's own trust layer

This is not experimental. It is the machinery behind Certificate Transparency, standardized in RFC 6962 (and updated in RFC 9162). After certificate authorities mis-issued TLS certificates, browsers began requiring that certificates appear in public, append-only CT logs so mis-issuance can't happen in the dark. The same Merkle-tree structure that keeps the web's certificate system honest is what 0byte uses to keep content origin honest.

Why origin needs this, specifically

A proof of origin is only as trustworthy as the registry's worst day. If the party holding the records can rewrite them, then a "proof" is just a claim you are asked to take on faith — and the whole value proposition collapses. Permanence is not a nice-to-have; it is the product. You cannot delete a proof to manufacture a different origin later, and you cannot backdate your way into someone else's timeline, because the log's own math would betray the edit.

Signing tells you who. The log tells you when, and makes it true forever. Provenance needs both.

Further reading: How Certificate Transparency works · RFC 6962 — Certificate Transparency · RFC 9162 — Certificate Transparency v2.0