Both tools solve the same problem: proving a file existed at a certain point in time, without exposing the file itself. The difference isn't the cryptography. It's what happens after the hash is anchored, when someone who wasn't there for the setup needs to check the proof. An adjuster, an opposing attorney, a claims examiner. Someone who has the file and a proof document, and thirty seconds to decide if it's real.

What OpenTimestamps is and how it works

OpenTimestamps is an open-source Bitcoin timestamping protocol. You install the client, hash your file locally, and submit that hash to one or more calendar servers. The calendar servers aggregate incoming hashes into a Merkle tree and periodically commit the tree's root to the Bitcoin blockchain in a single transaction. Your hash never touches Bitcoin directly. It rides inside a batch with everyone else's.

The client produces a .ots receipt file: a Merkle path showing how your hash combines with sibling hashes to reach the root that got committed on-chain. That receipt starts in a "pending" state, tied to a calendar server's promise that a Bitcoin transaction is coming. Once the transaction confirms, you run an upgrade step to pull in the confirmation data, and the receipt becomes independently checkable against the Bitcoin blockchain itself.

This is a protocol and a toolset, not a service. There's no account, no hosted certificate page, no dashboard showing your anchored files, and no support line. You run the calendar server request yourself, hold onto the .ots file yourself, and run verification yourself (or hand the file and receipt to someone else who runs the open-source verifier). If a claims department needs a link they can send to a third party that just displays "verified" without anyone installing anything, OpenTimestamps doesn't produce one. It produces a receipt file and a command-line tool.

What ProofLedger does differently

ProofLedger takes the same starting move, hash the file locally, and adds a hosted layer on top. A SHA-256 hash gets submitted through the API or web app, and the platform anchors it to two chains: Polygon for a fast confirmation, and Bitcoin for a slower, independently verifiable batch anchor with its own Merkle proof. The file itself never leaves the machine it's hashed on. Only the 64-character hash goes anywhere.

Each anchored hash gets a public verification page at a stable URL. Anyone with the link, no account, no software install, can see the hash, the transaction IDs, and links to the underlying block explorers. That page is what closes the gap OpenTimestamps leaves open: something you can hand to opposing counsel or a claims auditor that resolves on its own.

Dual-chain anchoring matters here specifically because it gives two independent ledgers making the same claim. Someone skeptical of Polygon's validator set can check the Bitcoin anchor instead, and vice versa. Neither anchor depends on ProofLedger staying online to remain checkable. The transaction data lives on public chains regardless of what happens to the company running the platform.

Verifying a proof yourself

For OpenTimestamps, verification runs through its own ots command-line tool: ots verify <file>.ots checks the receipt against the file and, once the Bitcoin transaction has confirmed, against the blockchain itself. That's the intended and only path. There's no separate hosted lookup page; the receipt file plus the client is the whole verification surface.

For a hash anchored through this platform, there are two ways to check it. The public endpoint takes a hash with no authentication required:

GET https://proofledger.io/api/v1/verify?hash=<sha256>

It returns whether the hash was found, its anchor record, and links to the relevant block explorers. Anyone can query it, including someone with no relationship to the account that created the proof.

The second path is offline, using the verify-proof package:

pip install verify-proof
from verify_proof import hash_file, verify_proof, load_proof

file_hash = hash_file("evidence.pdf")
proof = load_proof("proof.json")
result = verify_proof(file_hash, proof)

print(result["verified"], result.get("message") or result.get("error"))

The CLI equivalent:

verify-proof hash evidence.pdf
verify-proof verify evidence.pdf --proof proof.json

verify_proof() checks the file's current hash against the hash recorded in the proof, and if the proof includes a Merkle path, recomputes the root and confirms it against the anchored transaction. No network call happens during this check. It's a pure offline comparison against the proof's own claimed structure, which means the file can be verified years later even if every server involved in issuing it is gone. Confirming that the transaction ID itself is real still means checking a block explorer, same as with an OpenTimestamps receipt.

Which fits your situation

If you're comfortable running the calendar server submission yourself, holding onto .ots files, and either you or the recipient is willing to install and run the OpenTimestamps client to check them, that setup works and costs nothing beyond your own time. The tradeoff is that every verification depends on someone, you or the person you send the file to, operating that toolchain correctly. There's no link you can drop into an email that resolves for a non-technical reader on its own.

That's the specific gap this platform is built to close. A public, stable verification URL means a claims examiner or an attorney's paralegal can check a proof without installing anything. Dual-chain anchoring means the claim doesn't rest on a single blockchain's continued availability. And for teams anchoring more than a handful of files, the REST API and evidence-organization features (Evidence Packs, case-level grouping) handle volume in a way a one-file-at-a-time CLI workflow doesn't.

If your evidence pipeline needs to hand off a proof to someone outside your own technical setup, that handoff is the thing to weigh most heavily when choosing between the two.