Can a receipt be tampered with or forged?

Two attacks matter, and the design addresses both.

Tampering with history. Receipts sit on a BLAKE3-sealed, append-only spine: every record is covered by a sealed segment hash, and each segment seal commits to its predecessor. Edit, reorder, insert, or delete anything and verification fails at that point. This is not best-effort: the context export, offline verify, tamper-rejection sequence runs as a release-blocking CI gate, so a daemon build that fails to catch tampering never ships.

Forging new receipts. Every receipt is signed with Ed25519 under the acting passport. Forging one requires that passport's signing key; possessing the database is not enough. And because there are no anonymous writes, there is no unsigned path into the store to forge through.

What remains is the honest answer every vendor owes you: if an attacker holds a passport's key, they can sign as that passport, which is why revocation propagates with per-agent acks and a closing attestation.