Ideas
“Pitch deck v1 — Skylark”
f4a91b3e…d27c
Browser-side SHA-256 · Anchored in Bitcoin · No trusted third party
Anchor what you know, before they say you didn’t.
Drop a file or paste text. Your browser computes its fingerprint locally and stamps the fingerprint into the Bitcoin blockchain via OpenTimestamps. The original content never leaves your device. What you get back is a permanent, reproducible receipt.
Your file stays local
Only the hash is recorded
Verifiable by anyone, forever
01
How it works
Four steps. No magic.
-
01
Prepare a stable document.
PDF is ideal because the bytes don’t shuffle. Any file works — the fingerprint is computed over raw bytes, not over the rendered content.
-
02
Compute the fingerprint locally.
Your browser hashes the file with SHA-256 via Web Crypto. The hash is the only thing sent to ProofLedger. We never see the file’s bytes, name, or text content.
-
03
Anchor the fingerprint in Bitcoin.
We submit the hash to the OpenTimestamps calendar network, which aggregates it into a Merkle tree and anchors the root in a Bitcoin block. Roughly six hours later, your proof carries a real block height.
-
04
Keep the proof. Keep the original.
Verification needs both. Anyone with the original file plus the proof can recompute the hash and confirm the Bitcoin attestation independently — no ProofLedger required.
02
Transparency
What ProofLedger sees. What it doesn’t.
What we see
- The 64-character SHA-256 hash you submit.
- The title and (if you submitted one) the file name.
- An optional private note. Never shown publicly.
- The OpenTimestamps proof bytes returned by the calendar.
- Your IP, briefly, for rate-limit accounting.
What we don’t see
- The file’s bytes, contents, or text body.
- Any password, key, or identifier inside the file.
- Other documents that share the same fingerprint (there are none).
- Whether the same file has been certified elsewhere.
- Anything about who you are, unless you tell us.
03
Verification
What “verified” actually means.
Every proof page runs five independent checks at the moment you open it. Each one answers a different question. None of them require you to trust ProofLedger.
-
01
The file digest is what it says it is.
SHA-256 turns any file into a 64-character fingerprint. Two different files cannot share the same fingerprint — the math forbids it. If the proof says the digest is
cf64e0…68aband your re-hashed file produces the same value, you’re looking at the same bytes someone certified at that moment in time. You re-hash the file yourself; we never see it. -
02
A commercial timestamp authority signed it.
RFC 3161 is the standard for trusted timestamps used by Acrobat, the EU eIDAS framework, and most of the legal/financial industry. We submit the digest to DigiCert, who returns an attestation signed with their private key: “at this exact second, this digest existed.” We verify the signature against their embedded certificate ourselves.
-
03
The signing certificate is from a trusted authority.
Acrobat ships with a list of cert authorities it trusts by default — the Adobe Approved Trust List (AATL). When you open a stamped PDF in Acrobat, the green checkmark you see is exactly this check. We bundle the same roots into the verification stack and confirm the signing certificate chains back to one of them — as of the moment the timestamp was created, not as of today.
-
04
That certificate hasn’t been revoked.
Trusted authorities revoke their own certificates when they detect compromise. We ask the authority’s OCSP responder, in real time, whether the signing key is still in good standing. A clean OCSP response proves the certificate behind the timestamp is still authoritative right now — not just when it was issued.
-
05
It’s anchored in Bitcoin.
The OpenTimestamps protocol aggregates hashes into a Merkle tree, then publishes the tree’s root inside a Bitcoin transaction. We re-walk the tree from your file digest and confirm the result equals the actual Merkle root recorded in the block at the height the proof claims. This is the strongest layer: rewriting it would require rewriting Bitcoin itself.
The five together answer one question: does this digest exist at this moment in time, witnessed by infrastructure I don’t control?
The first four come from established cryptographic standards that pre-date ProofLedger by decades. The last one rides on the most expensive computation on Earth. None of them require trusting us — every check is independently re-runnable with the evidence bundle you can download from any proof page.
04
Use cases
A short, opinionated list of what to certify.
Anywhere a date matters more than a signature. Examples are fictional but the format is real.
Predictions
“Election call — district 4”
9b031c…77a8
Research
“Hypothesis register — batch 17”
2c11e9…1f4d
Legal
“Whistleblower memo — pre-disclosure”
cc88d3…02b9
Art
“Lyrics — track 03”
7a3e21…4b10
Real estate
“Move-in inventory — apt 4B”
d50fa1…9930
Personal
“Promise letter — sent unsigned”
10ef99…aa01
Digital
“Post text before deletion”
5b22d4…ce72
Yours