The receipt's threat model, explicitly

What a receipt defeats

1. Post-hoc edit of the screenshot file. Any change to the bytes — even a single pixel — produces a different SHA-256. Verification returns mismatch. The most common form of evidence dispute (“you edited the screenshot before showing me”) becomes provably wrong.
2. Post-hoc backdating of the timestamp by us. The OpenTimestamps anchor commits the receipt's hash to the Bitcoin blockchain within ~30 minutes. We cannot rewrite Bitcoin history; the timestamp becomes un-changeable.
3. Forgery of a receipt by anyone who isn't us. The ECDSA signature requires our private key. Without it, no one can mint a valid receipt. Our public key is published; forgery would be immediately provable.
4. Recompression by intermediary platforms. The perceptual-hash layer (pHash + dHash, AND-gated) recovers a verdict of recompressed even after Twitter, WhatsApp, Discord, or Telegram re-encode the file on their CDN. The original seal remains valid; the recompressed copy is correctly identified as a faithful re-encoding.
5. QR paste-on-fake attacks. Both the original and the QR-stamped composite are hashed. Pasting a real QR onto a fake image fails verification because the fake's bytes match neither stored hash. The verdict returnsmismatch.
6. Single-party deletion of evidence. The receipt is append-only on our side and externally anchored on a public chain. Deletion requires both compromising us AND rewriting Bitcoin history — neither feasible.

What a receipt explicitly does NOT defeat

1. Fabrication of the content depicted before sealing. A perfectly real-looking screenshot of a fake tweet, properly sealed, is a perfectly real screenshot of a fake tweet. The receipt proves the file existed at the timestamp shown; it does not prove the depicted content was authentic. This is the central honest-framing point. Receipts.you settles screenshot-evidence disputes; it does not certify reality.
2. Identity binding of the screenshotter. Receipts are anonymous. The receipt proves a file existed; it does not prove who took the screenshot. Identity binding requires separate evidence (witnesses, account-side records, chain-of-custody documentation).
3. Compromise of the screenshotter's device pre-seal. If the attacker has the screenshotter's phone before the seal happens, they can write any image they want and seal it. The receipt honestly proves they did so at the timestamp shown. Device-level trust is a precondition, not a consequence, of the receipt.
4. Compromise of our signing key. If our private key were stolen, an attacker could mint forged receipts. We mitigate via: hardware-key custody, no-export policy, ongoing security audits. If a compromise ever happened, we'd publish a transparency notice and rotate the key; pre-compromise receipts remain verifiable under the old key, future receipts use the new one.
5. Collusion between us and an adversary. If we colluded with someone to backdate a receipt, the OpenTimestamps anchor on the public chain would still betray the collusion — the anchor lands when it lands, and any gap between the claimed timestamp and the anchor block time is detectable.
6. Determined adversarial collusion against the watermark (Snitch Tracker). The DWT+DCT+SVD watermark has honest limits documented at the watermark post. Rotation past a few degrees defeats it. AI image-to-image rewrites defeat it. Multiple-variant averaging attacks defeat it. The watermark is designed for the single-leaker threat model, not state-actor adversaries.
7. Subpoena disclosure of receipt records. We can be compelled to disclose what we have: hash, signature, timestamp, country code, IP-at-seal-time (held for rate limiting). We can't disclose what we don't have (the image content). Users with subpoena-exposure concerns should layer with VPN/Tor at seal time.

Where the boundary sits

The boundary is at the seal moment. Everything that happensat or after the seal is cryptographically attested: the bytes, the timestamp, the anchor. Everything that happens before the seal — device compromise, content fabrication, identity of the screenshotter — is outside the receipt's defense. The receipt is honest about what it covers.

For most users in most situations, this boundary is exactly right. The dispute they're trying to win is usually about what happened to the file after they took the screenshot (deleted, recompressed, allegedly edited). The receipt makes that part un-disputable. The substantive question (what the screenshot depicts) is left for the substantive process.

The adversaries we're not trying to defeat

• Nation-state APTs targeting us specifically. If a sophisticated state-level adversary wanted to compromise our infrastructure to mint forged receipts, the receipts they forge would be detectable via the OpenTimestamps anchor (which requires actually anchoring before the claimed time), but our continued operation post-compromise would be in question. Mitigation: published key rotation policy, transparency reports, no single-point-of-failure for the chain of trust.
• Bitcoin-level chain attacks. If Bitcoin itself were catastrophically attacked (51% reorg, mining centralization), recent OTS anchors might fail. Mitigation: pair with secondary anchor (qualified-timestamp provider, separate chain) for high-stakes evidence.
• Collusion among the user, us, and Bitcoin miners simultaneously. Theoretically the failure case; practically infeasible at the costs involved.

How to use the threat model

Match your evidence stack to the actual threat you face:

• For most personal evidence (gaslighting ex, marketplace dispute, parent disagreement): the receipt alone is sufficient. The threat is dispute over the screenshot's authenticity, which the receipt defeats cleanly.
• For journalism and research: layer with archive.today/Wayback for URL-side independence and with primary-source interviews for content authentication. The receipt is one layer of several.
• For court and regulatory submissions: pair the receipt with your expert witness's offline-verification recipe (see the openssl walkthrough). For QTSP-required EU jurisdictions, use a qualified-timestamp provider as well.
• For whistleblower / high-risk-of-retaliation contexts: layer with VPN/Tor at seal time, store the receipt JSON and public key on multiple personal devices, and consult counsel about jurisdiction-specific protections before disclosure.

The receipt is a strong, honest, narrowly-scoped cryptographic primitive. For most evidence shapes it's sufficient. For edge cases it's a foundation layer in a broader stack. The honest framing — what it does and doesn't cover — is in this post for a reason: knowing the boundary is what lets you use the tool well.