A timestamp proof is only as good as the verification behind it. Anyone can claim a file existed on a certain date. What matters is whether a third party, an opposing attorney, a claims auditor, a judge, can check that claim without taking your word for it. Verification approaches split on one question: does checking the proof require trusting an intermediary, or can the reader confirm it independently?

What most verification models require you to trust

Most timestamping and notarization services route verification through the same channel they use to sell the service: a hosted portal. You upload a file, or the recipient does, and the platform tells you yes or no. The check happens on their servers, using their database, and the answer comes back as a page render, not a computation you can inspect. If the service is down, sold, or shut down, the verification path goes with it. If the company's incentives shift, so does what "verified" means. You're not checking math. You're checking a claim made by the same party that issued the original claim.

A second model publishes a signed certificate, PDF or otherwise, that asserts a timestamp exists. The certificate has a signature block, maybe a QR code, maybe a reference number. Confirming it usually means calling back to the issuer's system, or trusting that the signature itself is legitimate without an independent path to recompute it. This is closer to a notarized document than a cryptographic proof. It's an assertion backed by an institution's word, not a derivation the reader can run.

Both models can be perfectly honest and perfectly functional right up until the moment someone needs to defend the proof in a deposition. That's when "I checked the portal and it said verified" runs into "how do we know the portal wasn't lying, or wrong, or offline the day this mattered." A witness who can only say "the vendor confirmed it" is one cross-examination question away from a shrug.

What ProofLedger does differently

ProofLedger anchors the SHA-256 hash of a file to Polygon and, when requested, to Bitcoin. The file never leaves the machine it's hashed on. Only the 64-character digest goes on-chain. Verification doesn't route through a company's opinion about the file. It routes through the blockchain itself, plus a Merkle path anyone can walk by hand.

That distinction is the whole point of dual-chain anchoring. Polygon confirms fast. Bitcoin, batched daily with Merkle proofs, adds a second, independently operated ledger with its own miners, its own history, its own permanence. Neither chain needs ProofLedger to keep existing in order for the proof to remain checkable. If ProofLedger disappeared tomorrow, the transaction and the hash would still be sitting on Polygon and Bitcoin, readable by any block explorer.

There's also a public verification endpoint: GET https://proofledger.io/api/v1/verify?hash=<sha256>, no authentication required, 120 requests per hour per IP. Opposing counsel can hash the file themselves and query it. No account, no login, no dependency on being a ProofLedger customer.

Verifying a proof yourself

This is the part worth actually running rather than taking on faith.

Install the package:

pip install verify-proof

Hash a file:

verify-proof hash evidence.pdf

That prints the SHA-256 digest and the file path. Compare it against the hash recorded in the proof. If they match, you've confirmed the file hasn't changed since it was anchored.

To check the full proof, including the Merkle path back to the anchored root:

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

Under the hood, this is a Python function anyone can also call directly:

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"])       # True or False
print(result["tx_id"])          # blockchain transaction ID
print(result["merkle_root"])    # computed, not read from the proof

The Merkle verification logic combines each sibling hash with the current hash, left or right depending on position, then re-hashes. Critically, it does that combination on the raw bytes (bytes.fromhex(combined)), not on the UTF-8-encoded string. That distinction matters, get it wrong and you'll compute a different root than the package does, and think a valid proof failed.

None of this calls out to ProofLedger's servers. It's local computation against a JSON file the holder already has. It confirms the proof is internally consistent. It does not, by itself, confirm the transaction ID is real and on-chain, that's a separate step, done by pasting the tx_id into a public block explorer for Polygon or Bitcoin. Two checks, both independent of ProofLedger staying operational: one cryptographic, one on-chain.

Which fits your situation

If verification runs through a vendor's login screen, that's the dependency the receiving party is accepting: the platform's continued existence, its database integrity, and its willingness to keep answering the question the same way six years from now when the claim actually goes to trial. Under FRE 901(b)(9), a party can authenticate evidence produced by a process that generates an accurate result, but that requires laying a foundation, someone testifying to how the process works. A portal that just says "verified" with no visible mechanism makes that foundation harder to build, not easier.

If verification runs through a certificate you take on faith, you're trusting a signature you likely can't independently re-derive, which puts you in roughly the same position: the document says what it says because an institution says so.

ProofLedger's proof is built to be checked the other way. The hash is public math anyone can rerun. The Merkle path is public math anyone can rerun. The transaction sits on Polygon and Bitcoin, both queryable by any explorer, independent of ProofLedger's servers being online. That's also what makes FRE 902(13) and 902(14) relevant here, both allow self-authentication of machine-generated records through written certification, without live testimony, precisely because the process is mechanical and repeatable rather than an institution's subjective call.

For a claims file, a discovery production, or evidence headed toward a dispute, that's the difference that ends up mattering: not who says it's verified, but whether the person reading it six years later can check that for themselves.