You have a file. You need to prove it existed before a specific date. The question isn't whether to use cryptographic proof. It's which path produces a verification record that a third party can follow without your help.
Four approaches cover most of what's in practice: local hashing against a public ledger, RFC 3161 timestamps from a trusted authority, hosted anchoring services, and notarization. Each produces a different verification path. Each asks a third party to trust something different.
---
Local Hashing Against a Public Ledger
This is the base-layer approach. You compute a SHA-256 hash of your file and embed that hash in a blockchain transaction. Bitcoin's OP_RETURN field is the standard mechanism. The transaction gets mined into a block, and the block's timestamp becomes the record.
What you hold afterward: the transaction ID (TXID) and the original file.
Verification is trustless. Any third party can recompute the SHA-256 hash from the original file, look up the TXID on any Bitcoin block explorer, confirm the hash appears in the transaction output, and read the block timestamp. No service needs to be running. No certificate authority needs to still exist. The verification path is direct: file to hash, hash to blockchain record.
The operational tradeoff is real. Writing an OP_RETURN transaction requires a funded Bitcoin wallet, fee management, and a system to record the TXID and link it back to each file. There is no certificate. The output is a raw transaction that you have to know how to read and explain to anyone reviewing it later.
OpenTimestamps runs on this model. It batches hashes via calendar servers, builds a Merkle tree, and anchors the Merkle root to Bitcoin. The result is an .ots proof file anyone can verify given the original file and the proof. But that verification requires either a Bitcoin node or a calendar server, and the proof format needs explanation for a non-technical audience.
---
RFC 3161 Trusted Timestamps
RFC 3161 is an IETF standard for cryptographic timestamps issued by a Trusted Service Provider (TSP). The workflow: submit a hash of your document to the TSP. The TSP returns a signed timestamp token containing your hash, a timestamp from the TSP's trusted clock, and a digital signature over both.
What you hold: the timestamp response file (.tsr), the original document, and the TSP's certificate chain.
Verification is cryptographic but not trustless. A third party confirms that the signature on the timestamp token is valid and that the TSP's certificate chains to a recognized root certificate authority. The implicit question is whether they trust that certificate authority and whether the TSP's clock was accurate at signing time.
Authentication in U.S. federal court would typically proceed under FRE 901(b)(9), which allows authentication of evidence produced by a process that generates an accurate result. A TSP's process can satisfy that standard, but it requires foundation-laying. Expert testimony or certification about the TSP's reliability. Self-authentication under FRE 902(13) allows machine-generated records to authenticate via written certification without live testimony; RFC 3161 timestamps could potentially qualify, depending on what the certifying party can attest to.
The practical limitation for evidence-heavy use cases is format. A .tsr file is a binary blob. It is not human-readable. Verifying it requires OpenSSL or equivalent tooling. For a claims examiner or opposing counsel reviewing a dispute, the verification path runs through software they may not have and a certificate chain they may not recognize.
RFC 3161 is well-established in regulated document-signing contexts, particularly under European eIDAS rules. For PDF signing and contract management, the standard is embedded in existing workflows. For standalone evidence timestamps that need to survive into litigation, the friction is higher.
---
Hosted Anchoring Services
Hosted services accept a file hash and anchor it to a blockchain on your behalf. You don't need a funded wallet, a Bitcoin node, or code to write a blockchain transaction. The service handles the anchoring and returns a structured proof.
The trust model differs from raw blockchain access. The third party verifying your proof is trusting that the service faithfully submitted your hash without modification. That trust can be reduced by checking on-chain directly, taking the transaction ID from the proof and confirming the hash on a public explorer, but the service is a party in the chain.
ProofLedger anchors to both Polygon and Bitcoin. Polygon anchoring is immediate. Bitcoin uses a daily batch cycle with Merkle inclusion. The proof JSON contains a merkle_path that lets a verifier walk from the file hash to the Merkle root that was anchored on-chain. Each proof gets a public verification URL that any third party can visit without an account, software, or explanation from you.
The file never leaves the user's machine. Only the SHA-256 hash is submitted and anchored.
The REST API supports automated workflows. POST /api/v1/proof submits a hash. GET /api/v1/verify?hash=<sha256> is public. No authentication, usable by opposing counsel or a carrier's SIU without any account.
---
Notarization
Traditional notarization is the oldest approach and the least suited to digital files.
A notary witnesses a document's execution. They attest to who appeared, when, and what document was presented. They don't hash the file. They don't create a content fingerprint. For digital files, what a notarized document establishes is: this person, on this date, presented something to this notary. What it does not establish is that the file hasn't been modified since then, or that the file in a dispute is byte-for-byte identical to the one the notary saw.
Some digital notarization services layer hash verification on top. The notary session records a hash before signing. That moves the model closer to anchoring, but verification still runs through the notary's records rather than a public ledger.
For evidence authentication focused on content integrity and timing, notarization does not produce what the standard requires. For document execution workflows where a party's identity and intent are the point, it fits.
---
Verifying a Proof Yourself
For a ProofLedger proof, offline verification uses the verify-proof PyPI package.
pip install verify-proofHash the original file:
verify-proof hash evidence.pdfVerify against a downloaded proof file:
verify-proof verify evidence.pdf --proof proof.jsonThe CLI prints "VERIFIED: ..." or "FAILED: ..." and exits with a zero or non-zero exit code. Verification is entirely offline. No network call. No account. The package confirms that the hash of the file matches the hash recorded in the proof, and that the Merkle path is mathematically consistent with the on-chain Merkle root.
One thing it does not do: confirm that the transaction actually exists on-chain. For that, take the tx_id from the proof JSON and look it up on any Polygon or Bitcoin block explorer. That lookup is what closes the loop between the offline mathematical verification and the public ledger record.
For RFC 3161 timestamps, OpenSSL handles verification:
openssl ts -verify -in timestamp.tsr -data original-document.pdf -CAfile tsa-chain.pemThis confirms the signature is valid and the hash matches. It requires the correct TSP certificate chain, which you have to obtain separately.
---
Which Fits Your Situation
The right approach depends on what your audience can follow without guidance.
A raw OP_RETURN approach is trustless. The verification path is open to anyone with access to a block explorer. But turning that into something a claims adjuster or attorney can review without your help requires work. You need to document what the hash is, which transaction contains it, and why the block timestamp is authoritative. OpenTimestamps handles the anchoring but the proof format puts the explanatory burden on you.
RFC 3161 is embedded in document-signing and regulated record-keeping workflows. The verification path runs through PKI rather than a public ledger. For evidence that needs to survive a dispute in U.S. litigation, explaining the certificate chain to a non-technical audience adds friction that isn't present with blockchain-anchored proofs. The dependency is a certificate authority, not a public ledger.
Notarization does not produce content-integrity proof. If the question is what was in the file and when, notarization doesn't answer it.
ProofLedger is built for the gap between technical correctness and practical usability. Dual-chain anchoring means the proof has two independent verification paths. The public verification URL means any third party can confirm the proof without an account or software. The verify-proof package means a forensic examiner or technical reviewer can run verification offline.
For evidence that needs to be defensible in a claim or dispute, the verification path has to be walkable by someone who wasn't there when the anchor happened. That's what ProofLedger is built to support.