REST API
PROOFLEDGER · HOW IT WORKS
How ProofLedger proves what you knew.
No magic. No blind trust. Mathematics and time.
Fingerprint
Global registry
Permanent proof
The essential idea, in 30 seconds
The essential idea
Your file
stays with you
ProofLedger
SHA-256 hash
Global registry
forever
Imagine you slip a document into an envelope, seal it, and deposit it in a Swiss bank that nobody controls — not even us.
ProofLedger does exactly that, digitally.
Your document never leaves your computer. ProofLedger computes its digital fingerprint — a unique 64-character sequence that exclusively represents your file. If a single bit changes, the fingerprint changes completely.
This fingerprint — and only the fingerprint — is sent and written into a public registry maintained and verified around the clock by thousands of computers worldwide.
Result: it becomes mathematically prohibitive to contest that your document existed on that date.
How it works in detail
Three steps. Then you’re done.
01 You compute the fingerprint locally.
Drop a file or paste text. Your browser hashes it with SHA-256 via Web Crypto. The 64-character fingerprint is the only thing that ever reaches us. We do not see the bytes, the file name, or the words inside.
02 We anchor it in Bitcoin and seal it with a trusted signature.
The fingerprint goes to the OpenTimestamps calendar network, which aggregates it into a Merkle tree and writes the root into a Bitcoin transaction. In parallel, DigiCert co-signs the same fingerprint with an Adobe-Trust-List RFC 3161 timestamp. You get a real block height in roughly six hours and a trusted signature in seconds.
03 You keep the receipt. Forever, and anywhere.
Your evidence bundle is a ZIP — proof, OpenTimestamps file, RFC 3161 token, certificate, machine-readable verification. Anyone holding the original file can re-run every check independently. ProofLedger could disappear tomorrow and your proof would still hold up.
The proof, in two equations
Two equalities decide whether your proof is real.
Everything we do collapses to two cryptographic comparisons. Either both hold and your timestamp is genuine, or one fails and the proof is worth nothing. We compute both ourselves on every verification, and so can you, with the bundle alone.
Match #1 — Digest equality
SHA-256(your_file) ===
timestamp.signed_digestThe bytes you have now are the bytes that were signed.
SHA-256 turns any file into a 64-character fingerprint. Two different files cannot share the same fingerprint — the math forbids it. We hand you the fingerprint that DigiCert and Bitcoin co-witnessed; you re-hash your file and confirm it matches. If it does, the file in your hand is bit-for-bit the file we timestamped. If it doesn’t, the file has changed.
Match #2 — Bitcoin anchor equality
merkle_walk(digest, ots_proof) ===
bitcoin_block[height].merkle_rootThat fingerprint existed before that Bitcoin block was mined.
OpenTimestamps batches your fingerprint with thousands of others into a Merkle tree, then writes the tree’s root into a Bitcoin transaction. We replay the tree from your fingerprint upward and check that the result equals the Merkle root recorded in the block at the height the proof claims. To fake this, an attacker would need to rewrite Bitcoin from that height forward — the most expensive computation in the world.
Both true → the file existed at this moment, and a public, decentralised ledger says so.
Both equalities are testable from the evidence bundle on any proof page. Nothing to take on faith — not from us, not from DigiCert, not from any single party. The math either matches or it doesn’t.
The supporting evidence
Five independent checks back the two matches.
Every proof page runs all five at the moment you open it. Each one answers a different question. None of them require trusting ProofLedger.
-
01
The signature is real.
We verify the RFC 3161 signature against DigiCert’s embedded certificate ourselves. This proves the timestamp wasn’t forged after the fact — DigiCert’s private key signed exactly these bytes at exactly this moment.
-
02
The signing certificate chains to a trusted root.
We carry the same Adobe Approved Trust List (AATL) roots Acrobat uses for its green checkmark, and verify the certificate chain back to one of them — as of the moment the timestamp was created, not as of today. This is what makes the timestamp portable across legal and financial institutions.
-
03
The certificate hasn’t been revoked.
We ask DigiCert’s OCSP responder, in real time, whether the signing key is still in good standing. A clean response confirms the certificate behind your timestamp is still authoritative now — not just when it was issued. Responses are cached at the responder’s recommended TTL so verification stays fast.
-
04
The signed digest matches your file digest.
Match #1, on the verification side. We pull the digest the TSA actually signed out of the RFC 3161 token and compare it to your file’s hash. A real-but-wrong-file token gets caught here. False on this is the most common reason a proof fails.
-
05
The Merkle anchor reconstructs to the real Bitcoin block.
Match #2, in full. We replay the OpenTimestamps Merkle proof from your digest, fetch the actual Bitcoin block header at the claimed height, and confirm the reconstructed root equals the block’s merkle_root. This is the strongest layer — it leans on Bitcoin’s entire mining economy.
A worked example
The five checks, on a real proof.
Same five checks, this time bound to concrete numbers from a confirmed proof on the live system. Every value below is also visible on the proof page itself — open both side by side if you like.
-
01
The signature is real.
We pulled the RFC 3161 token DigiCert returned at minting time, parsed the embedded signing certificate, and asked Web Crypto to verify the signature over the exact bytes the TSA signed. Result: valid. The fingerprint on file was signed by DigiCert’s timestamping key — no other key produces the same signature.
What you’ll see: signature_valid: true on the verification panel.
-
02
The signing certificate chains to a trusted root.
The signing certificate is one in a chain — the TSA cert is signed by DigiCert’s intermediate, which is in turn signed by a DigiCert AATL root. We carry both AATL roots locally and walked the chain back to one of them, using the timestamp’s gen-time as the validity moment (Acrobat’s LTV semantic). Result: valid.
What you’ll see: cert_chain_valid: true.
-
03
The certificate hasn’t been revoked.
We asked DigiCert’s OCSP responder, in real time, whether the signing certificate has been revoked since issuance. The response itself is signed and verified end-to-end. We cache the answer at the responder’s recommended TTL so a hot read is fast.
What you’ll see: cert_not_revoked: true with status good (or cached-good on a hot read).
-
04
The signed digest matches the file digest.
The TSA signed a specific 32-byte hash. We extracted that hash from inside the RFC 3161 token and compared it byte-for-byte to the file digest recorded for this proof. Both are the same SHA-256 fingerprint that started the whole chain.
The fingerprint:
cf64e0134f6fcd73028c5e3e5a160dfb531895ac704fd772529ca11267ee68ab -
05
The Merkle anchor reconstructs to the real Bitcoin block.
The OpenTimestamps file lists the operations needed to walk from this proof’s fingerprint up to a Merkle root. We replayed those operations, fetched the actual Bitcoin block at the height the proof claims, and confirmed the reconstructed root equals the block’s
merkle_root. To fake this match, an attacker would need to rewrite the Bitcoin chain from that block forward.Block height: 947,295 · Block hash:
00000000000000000001858786f6a9a61625be456e6b318cf519980563eb8062
All five passed. The proof is, on this date, fully verified — by us in your browser, by us in the API, and by anyone holding the bundle and a copy of the original file.
What we touch. What we don’t.
Privacy is the easy half.
What we see
- The 64-character SHA-256 hash you submit.
- An optional title and file name (you choose).
- An optional private note. Never shown publicly.
- The OpenTimestamps and RFC 3161 receipts the providers return.
- 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.
Built for your stack
A first-class API, not an afterthought.
Mint, read, verify, and stream proof events from any backend. REST under /v1, OpenAPI 3.1 spec, signed webhooks, scoped tokens for embeddable clients.
Webhooks
Get notified when a proof confirms.
Scoped tokens
Hand short-lived JWTs to your client.
Idempotent
Retry safely. Same key, same answer.
OpenAPI 3.1
Generate clients in any language.
Reference
Read the API contract.
Use cases
Anywhere a date matters more than a signature.
You don’t need a notary. You need proof that a thing existed before something else happened. Examples are fictional; the format is real.
Ideas
“Pitch deck v1 — Skylark”
f4a91b3e…d27c
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
Whatever a date will matter for, later.
FAQ
Frequently asked questions
But isn’t Bitcoin just a cryptocurrency?
Bitcoin is also the most decentralised public ledger ever built. We use it as a write-once timestamp surface, not as money. Each block records a Merkle root that batches thousands of fingerprints; once mined, that root is impossible to alter without rewriting Bitcoin from that block forward.
Can ProofLedger modify a proof after the fact?
No. The proof bundle contains the OpenTimestamps file and the RFC 3161 token, both signed by parties we don’t control. Once issued, the bundle stands or falls on its own bytes — even we can’t re-date or alter what’s in it.
What happens if I lose my original file?
Verification needs both the proof bundle and the original file. Without the file, the proof shows that something existed at that moment, but you can’t demonstrate what it was. Keep both. Treat the bundle like a notarised envelope and the file like its contents.
Can I certify any type of file?
Yes. The fingerprint is computed over raw bytes — PDFs, images, audio, video, source code, ZIPs, anything. Stable formats (PDF, plain text, source files) verify most reliably because their bytes don’t shuffle between renderings.
How long before my proof is confirmed?
The RFC 3161 timestamp is signed instantly. Bitcoin anchoring takes roughly six hours — that’s how long it takes the OpenTimestamps calendar to aggregate fingerprints and write the Merkle root into a Bitcoin block. The proof page updates automatically when the anchor lands.
How can I prove it was ME who submitted it?
The fingerprint proves the bytes existed at that moment, not who submitted them. Pair it with conventional identity (signed PDF, GPG, witnessed delivery) when authorship matters. The timestamp is the date stamp; identity is a separate concern.
What is a .ots file?
The OpenTimestamps proof — a small binary file that contains the Merkle path from your fingerprint up to a Bitcoin block. Standard format, ~500 bytes, verifiable with any OpenTimestamps client (we don’t need to be online for it to work).
What is a .tsr file?
The RFC 3161 timestamp token — a signed binary that says “at this exact moment, this fingerprint existed,” signed by an Adobe-Trust-List authority (DigiCert in our case). Verifiable in Acrobat, OpenSSL, or any compliant tool.
What if ProofLedger shuts down tomorrow?
Your proof keeps working. Both the Bitcoin anchor and the RFC 3161 token are verifiable independently of us — the OpenTimestamps file plus the original file is enough to demonstrate the anchor; the .tsr plus DigiCert’s public certificates is enough to verify the signature. We are convenient; we are not load-bearing.