The open-source verifier

What the verifier checks

Point it at the public log. It will:

• Refetch everything. The full log from the public API, plus every signed checkpoint from the public anchor. Nothing is trusted as served.
• Recompute the hashes. Every entry hash and the Merkle root are rebuilt from scratch, and the hash chain is verified to be unbroken.
• Verify the signatures. Each checkpoint's Ed25519 signature is checked against the pinned public key, and the entry count is checked to only ever grow.
• Replay the counts. You don't have to take the API's number on faith, because the verifier never asks for it. It rebuilds every total from the raw log entries it has just checked against the signed root, and --counters prints those totals as a CSV: an auditor states the numbers themselves rather than quoting ours. The served count is only a fast copy of that sum; the signed log rather than our server, is the source of truth.
• Audit the revocations. The public revocation feed is checked against the op=4 entries actually present in the log, and those reversals are subtracted while recomputing the final counters.
• Compare the anchors. The checkpoint the API serves is compared against the copy in emojery-log, which catches a "split view" where we would show one history to you and another to everyone else.
• Cross-check an independent log. Each checkpoint is confirmed to be present in Sigstore Rekor, a public transparency log run by a different organization, carrying our exact signed bytes, so a second party we don't operate has independently witnessed each checkpoint. This runs by default; an unreachable Rekor is reported as skipped, never a false failure. This is the fast witness; the Bitcoin walk below is the slow one, and the two cover different failures.
• Walk to Bitcoin. With the optional --ots deep audit, the OpenTimestamps proof is walked down to the actual Bitcoin block that seals a checkpoint root, so the replayed history cannot be backdated or rewritten.

What exactly a checkpoint is, and where each piece of data lives, is on the transparency log page.

Verify it yourself

No cloning needed; one command runs the checks above:

npx github:khasky/emojery-verifier \
  --repo https://raw.githubusercontent.com/khasky/emojery-log/main

Add --ots for the Bitcoin deep audit. The same checks run daily against production and feed the public status page.

There is nothing else to point it at: the log is published as files, and the verifier reads only those — the signed checkpoints and the chunk digests from the repository, the entries themselves from the mirror the repository names. A chunk is admitted only if its bytes hash to the digest committed in git, so a copy served by anyone is checked exactly as strictly as ours.

Reading no entries at all still checks the whole published history — every archived signature, the consistency proofs and the Bitcoin witness — in seconds:

npx github:khasky/emojery-verifier --entries none \
  --repo https://raw.githubusercontent.com/khasky/emojery-log/main

A publish lands a tick behind the checkpoint that covers it, so a full run audits the newest checkpoint the published entries cover and tells you which one that is.

Add --stats for a per-day activity report (reactions, distinct pseudonymous authors, revocations) derived from the entries alone — the same series our status page charts, recomputed without us, no signed aggregate from us to trust, since the series falls straight out of the entries.

Run your own scheduled audit

The verifier repository ships the same GitHub Actions workflow we use: it runs the full verification daily and reports the verdict. Fork emojery-verifier, enable Actions on your fork, and add LOG_PUBKEY as a variable on the fork's production environment (Settings, then Environments), set to the log key printed in that repository's README. From then on your copy audits our production log every day, on infrastructure we don't control, and a run that goes red means the log did not verify. The more independent watchers, the less anyone has to take our word for anything.

The log key

Every checkpoint is signed with the project's Ed25519 log key. The public half lives in exactly one authoritative place — pinned in the verifier source (and printed in its README), so the verifier works with no key argument at all. This page deliberately does not restate the value: a copy here could silently drift from the one the tool actually checks against.

Substituting the key would mean tampering with the public verifier repository itself, in the open and under version control, and every historical checkpoint signed with the real key would still expose the swap.

What this proves, and what it doesn't

Strong claims need clear edges. Here is exactly what the cryptography guarantees, and where it stops.

What the math proves

Every count is a replay of public entries — the total is whatever the log adds up to, nothing more. Nothing is removed silently: the only way to change a number is to append a new entry that is signed, anchored, and permanently visible. If the served history ever differs from the anchored one, the verifier fails and tells you where.

What the math can't prove

A revocation carries a public reason_code, but no hash can prove the stated reason is truthful. Cryptography proves what was claimed and when; whether the claim is true is a separate question. That limit is inherent to any transparency log, and we would rather state it than let you assume otherwise.

Why abuse is still detectable

Like Certificate Transparency, the log is built for detection rather than prevention, and detection has teeth here:

• Revocations are whole-account. There is no way to reverse one inconvenient vote. Removing a vote means visibly reversing that account's entire history, and that collateral noise shows up on the public feed and the status page.
• The affected user is a living witness. The extension keeps your reaction history on your device. If your votes vanish from the counts without your request, you hold the evidence.
• Anyone can watch. The revocation feed is public, the status page charts daily revocation counts by reason, and the open-source verifier flags any pseudonym whose history is only partially revoked. The feed is paged, and every page says whether more remain, so the whole history is reachable, and a partial view can never pass for the complete one.