The core promise is consistent across all of them: anchor a cryptographic hash, create a record that the hash existed at a specific moment, and make that record verifiable later. What separates them is who holds the trust, what verification actually looks like when it's needed, and what a professional hands over when evidence timing becomes the dispute.

Three main approaches cover most of the field: self-operated open protocols, RFC 3161 time stamp authorities, and hosted blockchain anchoring services.

Self-operated protocols: OpenTimestamps

OpenTimestamps is an open-source protocol for Bitcoin timestamping. You run a client locally. Calendar servers operated by volunteers aggregate hashes from many users into Bitcoin transactions using Merkle trees. The resulting attestation is a small .ots file you keep alongside the original.

Trust sits with Bitcoin itself. If you can verify the Merkle path from your hash to a confirmed Bitcoin transaction, the timestamp holds. No company intermediary in that chain, no vendor infrastructure to trust beyond the blockchain.

Verification is local and offline once the Bitcoin transaction confirms:

ots verify yourfile.pdf yourfile.pdf.ots

What this asks of every future verifier: the .ots file, the matching original, and a working OpenTimestamps client. In a technical context, that's a workable path. In litigation or insurance workflows, where the audience may be a claims examiner, judge, or opposing attorney, the verification path adds friction that typically requires expert facilitation.

Calendar servers also batch Bitcoin transactions, so anchoring isn't immediate. Confirmation takes hours, not seconds.

RFC 3161 time stamp authorities

RFC 3161 is the IETF standard for cryptographic timestamping. A time stamp authority receives a hash, signs it with its private key at the moment of receipt, and returns a time stamp response file (TSR). The proof of timing derives from the CA's certificate chain.

Major certificate authorities operate TSAs: DigiCert, Sectigo, GlobalSign, and others. Free options like FreeTSA also exist. RFC 3161 timestamps appear in PDF digital signatures, code signing certificates, and document authentication workflows where PKI is the established trust framework.

Trust is PKI-based. You trust the TSA's clock accuracy, its key management practices, and the CA's root certificate. Verification means checking the TSR against the certificate chain. That chain carries an expiry date.

Long-term validation is the ongoing operational consideration. A TSR signed today is valid for as long as the signing certificate is valid and SHA-256 remains unbroken. Litigation that surfaces years after evidence was created may require certificate renewal or long-term validation (LTV) layers. Document standards like PDF/A and PAdES handle this systematically. In ad hoc evidence workflows, the burden falls on the user.

RFC 3161 timestamps don't anchor to a public blockchain. Authentication runs through the CA infrastructure, not an independently auditable ledger. For a blockchain-based authentication argument, that's a different trust path entirely.

Hosted blockchain anchoring services

Several services accept a hash via API or web interface, anchor it to a blockchain on your behalf, and return a certificate or transaction ID. The category shares a common trust pattern: the service makes the on-chain call and certifies when it happened.

Independent verification typically runs through a blockchain transaction ID any explorer can confirm, through a hosted portal, or both. The structural question is what the proof depends on for long-term verifiability: does the certificate reference on-chain data any third party can retrieve independently, or does meaningful verification run through the vendor's infrastructure?

Most services in this category anchor to a single chain. Dual-chain anchoring exists but isn't the standard assumption for the category.

What ProofLedger does

ProofLedger anchors a SHA-256 hash to both Polygon and Bitcoin. Both chains, not one. The file never leaves the user's machine. Only the hash goes on-chain.

Polygon anchoring is immediate and unlimited on every plan, including the free tier. Bitcoin anchoring is a paid per-anchor option, batched daily with Merkle proofs.

Every proof gets a public verification URL. Anyone with the URL can check the hash, both blockchain transaction IDs, and the anchored timestamp without creating an account. A claims examiner, opposing counsel, or auditor can open it in a browser. That matters when the verifier wasn't part of creating the proof and isn't going to install software to check a timestamp.

The REST API is available on Professional and Business plans. Three endpoints: submit a hash, retrieve proof status, or verify any hash. The public verify endpoint requires no authentication and handles 120 requests per hour per IP. Third parties can call it directly without going through any vendor portal.

For offline verification, the verify-proof Python package handles it locally with no network call:

pip install verify-proof
verify-proof verify evidence.jpg --proof proof.json

Evidence Packs (Standard plan and above) organize proofs by case, claim, or matter with loss dates and pre/post indicators, turning individual anchors into structured records a professional can navigate and hand over.

Verifying a proof yourself

OpenTimestamps: install the client, run ots verify. Everything is local. The constraint is keeping the .ots attestation matched to the original file from the moment of anchoring forward.

RFC 3161: verify the TSR against the TSA's certificate chain. PDF readers handle this natively for signed documents. OpenSSL handles standalone TSR files. The certificate chain must be retained alongside the TSR for any future verification.

ProofLedger: two paths.

The public verify URL is the default for non-technical verifiers. Open it, confirm the hash and both transaction IDs, done.

For scripted or offline verification:

from verify_proof import hash_file, verify_proof, load_proof

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

print(result["verified"])      # True
print(result["blockchain"])    # "polygon" or "bitcoin"
print(result["tx_id"])         # blockchain transaction ID for on-chain lookup
print(result["anchored_at"])   # ISO timestamp

The tx_id in the result is independently confirmable in any blockchain explorer. The package doesn't make that call, but the data is there if you want to run it yourself.

Which fits your situation

OpenTimestamps removes vendor dependency entirely. The tradeoff: every future verifier needs the .ots file, the matching original, and a working client. In evidence disputes, that path typically requires expert facilitation to walk non-technical parties through it.

RFC 3161 timestamps are bound to a PKI certificate chain. The chain has an expiry, and long-term validity depends on CA continuity and certificate management. Authentication doesn't run through a public blockchain, which matters if the argument being made requires an independently auditable ledger anyone can query.

With hosted blockchain services, the architecture matters more than the category label. If meaningful verification runs through a vendor's portal, that portal is a dependency. If it runs through on-chain data any blockchain explorer can retrieve, it isn't.

ProofLedger is built for evidence workflows where the verifier wasn't part of creating the proof. The dual-chain anchor puts the same hash on two independent public blockchains. The public verify URL gives non-technical verifiers a path that requires no software and no vendor login. Offline verification is available for parties who need it.

If evidence timing is what's contested, the verification path has to hold up under scrutiny from parties who are actively looking for it to fail. That's the design problem each approach above solves differently.