How receipt signatures work

Before a clip is posted, Everpop records a prediction commitment: a small, immutable record of what our ranker predicted for that clip and when. The record is signed with ed25519, so anyone can later check — without trusting us— that the prediction is exactly what our key signed and hasn't been rewritten since. The commit time we record sits before the post time we record, so our own timeline shows the prediction was logged before the clip went live; what the signature itself proves is origin and integrity, and we spell out exactly where that boundary sits in the worked example below.

Everything you need is on the receipt itself. A receipt page shows the signing-key id and the SHA-256 of the commitment's stored payload, and its Payload & signature expander reveals the exact signed payload string and the signature. Prefer machine-readable? Every receipt link has the form /r/<postId>?t=<token> — take those same two values and fetch /api/receipts/commitment?post=<postId>&t=<token>to get the payload, signature, key id, and the post's publish time as byte-exact JSON.

One field to know about: the payload includes the creator's internal account id — an opaque identifier, not an email or a name. It is part of the signed bytes, so it cannot be redacted without invalidating the signature, and it is only visible to people the creator chose to share the receipt link with.

What exactly is signed — and what isn't

The signature covers the pre-publish prediction only. The measured 48-hour and 7-day numbers on a receipt come from the YouTube Analytics API and are not separately signed yet — they are real API reads, but the cryptographic guarantee on this page applies to the prediction commitment, nothing else.

The public key

The verification key is published at /api/receipts/public-key — a machine-readable JSON response with the key in two standard encodings (SPKI DER base64, and the raw 32-byte point base64url), the key's id, the payload schema version, and its own verify instructions. The publicKeyIdshown on a receipt is the first 16 hex characters of sha256 over the raw public key; match it against the endpoint's to confirm you're holding the right key after any rotation.

The canonical payload

Each commitment stores the exact string that was signed — canonical JSON with a frozen field order, versioned by its v field (currently pc1):

{
  "v": "pc1",
  "clipId": "...",
  "userId": "...",
  "modelVersion": "...",
  "basis": "channel",
  "predictedPercentile": number | null,
  "predictedPercentileDisplay": number | null,
  "at": "2026-07-09T14:03:22.187Z"   // ISO timestamp at commit time
}

Nulls are explicit so an absent prediction can't be forged into a zero. The signature is base64url-encoded ed25519 over the UTF-8 bytes of this exact string — verify against the stored payload, never a re-serialization.

A worked example: what to check

Fully self-serve from any receipt link /r/<postId>?t=<token> — fetch the commitment, fetch the key, check two things:

import { createPublicKey, verify } from "node:crypto";

const { payload, signature, postedAt } = await (
  await fetch(`https://everpop.app/api/receipts/commitment?post=${postId}&t=${token}`)
).json();
const { publicKeySpkiBase64 } = await (
  await fetch("https://everpop.app/api/receipts/public-key")
).json();
const key = createPublicKey({
  key: Buffer.from(publicKeySpkiBase64, "base64"),
  format: "der",
  type: "spki",
});

// 1. The signature verifies against the published key.
verify(null, Buffer.from(payload, "utf8"), key,
  Buffer.from(signature, "base64url"));            // → true

// 2. Everpop's own recorded commit time is before its recorded post time.
new Date(JSON.parse(payload).at) < new Date(postedAt); // → true

Check 1 is the cryptographic guarantee. It proves the prediction is exactly the bytes Everpop's key signed and hasn't been altered since — that is what ed25519 gives you: origin and integrity. It needs no trust in us.

Check 2 is a consistency check on our own records. Both the commit time (in the payload) and the post time are values Everpop records; ed25519 proves the bytes, not when they were signed. So check 2 shows our timeline is internally consistent — the prediction was logged before the post — but that ordering rests on our records, not on cryptography, because the signing time isn't independently timestamped. We state this plainly rather than overclaim it.

If check 1 fails, don't trust the prediction — and please tell us at security@everpop.app.

Key rotation

A key rotation mints a new publicKeyId; old commitments stay verifiable because each row carries its own payload and any archived copy of the public-key response still verifies it. The endpoint always serves the current key.