Checked in your browser. A fingerprint goes to the public log only when you choose to look it up — never the file.
Check any file
Not sure what you have? Drop it here and the right check starts by itself.
What it recognises
- A .beatproof file — the offline proof from Sigelith Desktop or the apps. We read the fingerprint it names, and you can look it up in the public log.
- A certificate (PDF) — the one you downloaded when stamping. We read the fingerprint printed on it.
- A file proof from Sigelith Backup (.sigelith-proof) — checked right here: its path to the backup version’s seal and the stamp it names. Drop the file itself as well, and we confirm it is the same one.
- A Handover evidence package or defect proof (.zip) — checked right here, offline, with the same verifier as the file handover checker.
- A sealed capsule (.json) — handed over to the Capsule page, where it opens once its moment has come.
- Any other file — its fingerprint is computed in your browser, and you decide whether to look it up.
This checker runs in your browser, but its code comes from our server. When it matters, check without it: with Sigelith Desktop, which is open source, or by hand, following the guide for experts.
The package stays on your device. This page opens it in your browser and recomputes every signature, commitment and time itself — nothing is uploaded and no request is made. A time counts only with a receipt signed by the Sigelith log key built into this page.
Add the other party’s copy (optional)
If the other party kept its own package of the same handover, add it here. Its answer and log proofs are taken into account — this settles the case where the recipient signed two different answers.
Result
What the package shows
Cards carry no names. Who stands behind a fingerprint is shown by the binding and by your own records — compare the fingerprints with the ones you know.
What the preview showed — and what the package holds
What the recipient signed
The recipient signed a structured answer; this is its fixed reading, not free text.
Disclosed content
The sender attached the exact content of the package. It matches the hash committed in the offer, so these are the files the recipient could open.
All checks
What this proves — and what it does not
- The sender’s key signed an offer to the recipient’s key, committing to the exact encrypted package.
- The recipient’s key signed an acceptance, stating that it holds that encrypted package.
- The key part was recorded in the public log after the acceptance and before its deadline. From that moment the recipient could open the package: that is the time of delivery.
- With the disclosed content, anyone can check which files the package held.
- A defect proof settles whether the package was what the sender offered: anyone can recompute it, and a false claim fails the same computation.
It does not prove that anyone read or understood the content, or who stands behind a key — that is what binding a card to a person is for. It is not a formal service of documents under any particular law; what it weighs in a dispute is for a court to decide. Silence proves nothing: an offer without an answer is a status, not evidence.