Receipts as evidence.

This page summarizes how a receipts.you receipt maps to the electronic-evidence and electronic-timestamp frameworks most commonly cited by practitioners. It is informational, not legal advice. Citations link to the controlling text where available.

The short version: a receipt is a self-authenticating record of a cryptographic fact (an exact byte-sequence existed at a specific time, signed by a key whose public PEM we publish, and independently anchored to OpenTimestamps). The legal weight of that fact varies by jurisdiction and by use case; the frameworks below are the ones we hear about most often.

§ The object

What a receipt is, technically.

A receipt is a small, self-contained record containing:

The SHA-256 hash of the original file (32 bytes; a one-way digest, preimage-resistant).
An ECDSA P-256 signature over a canonical JSON envelope of { id, original_hash, signed_at, signer_kid }, using a key whose public part is published at /.well-known/receipts-pubkey.pem.
An OpenTimestamps proof: the hash is committed to an independent decentralized timestamping network, so the existed-at-or-before time is anchored externally and cannot be backdated.
Optionally, a second hash for the QR-stamped composite (so the file the user shares is also covered) and an optional plain-text note + source URL the user supplied.

Three independent verification pathways exist: (a) by hash, against our database; (b) by ECDSA signature, against our published public key, offline with openssl; (c) by OpenTimestamps anchor, against the timestamp network, with no involvement from receipts.you at all. The third matters most for evidentiary use: this proof would still verify if receipts.you's entire infrastructure disappeared tomorrow.

§ EU — eIDAS

Article 41 — electronic timestamps.

Regulation (EU) No 910/2014 (the eIDAS Regulation) governs electronic identification and trust services for electronic transactions in the EU internal market. Read the regulation.

Article 41(1) establishes the central admissibility rule: “An electronic time stamp shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements of the qualified electronic time stamp.”

In plain English: an EU court cannot reject a timestamp just because it is electronic, and it cannot reject it just because it isn't a qualified timestamp issued by a QTSP (qualified trust service provider). A non-qualified timestamp — which is what a receipts.you receipt is — remains admissible.

Article 41(2) grants qualifiedelectronic timestamps an additional presumption of accuracy and integrity. Receipts.you receipts are not qualified timestamps. For court-grade certification with that statutory presumption, complement with a QTSP service like TrueScreen — receipts.you provides strong, free, independent provenance that pairs well with a QTSP's formal certification.

Article 3(33) defines an electronic timestamp as data “in electronic form which binds other data in electronic form to a particular time establishing evidence that the latter data existed at that time.” A receipts.you receipt meets this definition: the SHA-256 hash (the “other data”) is bound to the signed_at timestamp via ECDSA signature, with independent corroboration via OpenTimestamps.

§ US — Federal Rules of Evidence

FRE 901 and 902(13).

US federal practice on authenticating electronic evidence turns on Rule 901 (authentication generally) and the 2017 amendment to Rule 902 (self-authenticating records). FRE 901 · FRE 902.

Rule 901(a) requires the proponent to “produce evidence sufficient to support a finding that the item is what the proponent claims it is.” Rule 901(b)(9) permits authentication by “evidence describing a process or system and showing that it produces an accurate result.” A SHA-256 hash comparison against a signed timestamped record fits this pattern directly — it is a deterministic, publicly-documented process that produces a verifiable result.

Rule 902(13) (added effective Dec 2017) makes records generated by an electronic process or system that produces an accurate result self-authenticating, subject to a certification from a qualified person. In practice this means a properly-described cryptographic timestamping system can satisfy the authentication requirement without live expert testimony at trial — the certification + the publicly verifiable proof are enough.

Rule 902(14) (the parallel provision for data copied from electronic devices, also Dec 2017) is the natural vehicle for screenshot evidence: a hash comparison establishes that the file is the same one that was captured.

For practitioners: a receipts.you receipt provides the hash + signature + external timestamp anchor a 902(13) certification needs to point at. You still need the certification itself (a Rule 902(11) / 902(13) declaration from someone qualified to describe the system), but the underlying record meets the technical bar.

§ Canada — PIPEDA & Evidence Acts

Electronic documents and trusted timestamps.

Canadian admissibility of electronic records is governed primarily by the Canada Evidence Act RSC 1985, c. C-5, with parallel provincial provisions (e.g., Ontario's Evidence Act, Quebec's Act to establish a legal framework for information technology).

Canada Evidence Act, Section 31.1 places the burden of authenticating an electronic document on the party seeking to introduce it: they must prove it is what they claim via “evidence capable of supporting a finding”. Section 31.3 permits proof of integrity via evidence that the system in which the record was recorded was operating properly, or — relevantly here — that the record was “recorded or stored by a party who is adverse in interest to the party seeking to introduce it” or by a neutral third party.

A receipts.you receipt — a hash signed by a key whose public part we publish, anchored externally to OpenTimestamps — serves the integrity-of-system function under s. 31.3. The cross-jurisdiction OpenTimestamps anchor is independent of any party to the litigation.

PIPEDA (the Personal Information Protection and Electronic Documents Act) is most often cited here for its Part 2 — Electronic Documents framework, which establishes the legal recognition of electronic documents and signatures for federal purposes. Our hash-only data model also means we are not, in practice, a custodian of personal information about end-users — we never see the image, so we cannot disclose what we never collected. See our privacy page for the data inventory.

§ Honest limits

What a receipt is not.

A receipts.you receipt is not:

A qualified electronic timestamp under eIDAS Art 42 — that requires a QTSP audit. Use a QTSP (e.g., TrueScreen) in parallel for that statutory presumption.
A notarized affidavit. A receipt attests to cryptographic facts, not to the identity of the person who minted it (we don't require accounts).
A statement that the depicted content is true. The receipt only attests that these exact bytes existed at this exact time. The bytes may depict fabricated content; we can't and don't evaluate truth-of-content.
A substitute for chain-of-custody documentation. The receipt is one element; the rest of the chain (who took the screenshot, how it was preserved, etc.) still needs the usual evidentiary scaffolding.
A guarantee of admissibility in any particular court. Admissibility turns on the totality of the record, judge's discretion, and jurisdiction-specific rules.

We are upfront about all of this on the landing page and the FAQ. The frame we sell — and that this page formalizes — is byte-level provenance, not truth-machine.

§ Practical

Using a receipt in a filing.

The pieces you typically need to attach or describe:

The original file as captured (preserve the byte-exact version offline).
Its SHA-256 hash (you computed this in your browser at seal time; the value is on the receipt page).
The receipt URL (https://receipts.you/r/<id>) and a printable PDF / screenshot of the receipt page as it appeared at filing.
Our public verification key as published at /.well-known/receipts-pubkey.pem at the time of sealing. The page exposes the current key; rotated keys remain available under their old signer_kid.
The OpenTimestamps proof (the ots file referenced from the receipt page, once the Bitcoin anchor confirms — typically within ~6 hours of sealing).
A declaration / certification describing the system that produced the record. Boilerplate for FRE 902(13) and Canada Evidence Act s. 31.3 declarations is straightforward; we're happy to share templates by email ([email protected]).

Independent verification by opposing counsel is a feature, not a bug. They can re-hash the original file with any SHA-256 tool, verify the signature with openssl dgst -sha256 -verify receipts-pubkey.pem, and check the OpenTimestamps proof against any timestamp calendar. None of those steps require us.

Not legal advice

This page is informational and reflects our own engineering understanding of the cited frameworks. It is not a substitute for advice from a lawyer admitted in your jurisdiction. We do not represent clients, we do not file evidence on anyone's behalf, and we make no warranty that a court will admit a receipts.you receipt in any specific proceeding. Where jurisdiction-specific procedural rules differ from the federal defaults summarized above, those local rules control.

Spotted a citation that needs correcting, or want us to add a jurisdiction? Email [email protected].