If you need to show later that a file existed at a specific point in time, you need a record made at that time by something outside your own control. RFC 3161 timestamping authorities have done this since 2001, using a trusted third party and its certificate. Blockchain anchoring does the same job with a different trust model: a public ledger instead of a vendor. The two approaches solve the same problem in structurally different ways, and the difference matters once someone challenges the proof.

What RFC 3161 timestamping authorities are and how they work

RFC 3161 is an IETF standard that defines a request-and-response protocol for timestamping. You hash a document, send that hash to a Timestamping Authority (TSA), and the TSA signs it with its private key. The response is a timestamp token: your hash, the time the TSA recorded, and a digital signature over both.

Companies like DigiCert, Sectigo, and FreeTSA operate TSAs. Each one holds a certificate issued under a certificate chain, the same X.509 model that underlies TLS on the web. To trust the timestamp, a verifier has to trust that certificate chain: the TSA's certificate, the intermediate CA that issued it, and the root CA at the top. Verification software (OpenSSL, Adobe's PDF timestamp checks, most PKI toolkits) walks that chain and confirms none of the certificates involved have expired or been revoked.

This is a trusted third party model. The proof is only as strong as your confidence in the TSA's key management, and only as available as the TSA's ability to keep affirming that chain. If a TSA discontinues operations, changes its certificate infrastructure, or a certificate in the chain expires without a documented long-term validation path, revalidating an old timestamp gets harder. None of this means the protocol is unsound. RFC 3161 timestamps are widely used and accepted in signing contexts precisely because the PKI model they're built on is well understood. But the proof's durability is tied to an institution, not to a document you hold independent of anyone's continued cooperation.

What ProofLedger does differently

ProofLedger anchors a SHA-256 hash of a file to Polygon. You never upload the file. Only the 64-character hash goes anywhere, and it goes into a public blockchain transaction rather than to a single signer's private key.

The trust model shifts from an institution's certificate chain to a public ledger anyone can independently read. Each proof is its own Polygon transaction, usually confirmed within a minute, so the hash itself is on chain and there is no batch path to recompute. Checking that transaction doesn't require trusting ProofLedger's continued operation. It is on a ledger maintained by independent validators, not in a database only one company controls.

Every proof gets a public verification URL. Every anchor can also be checked with an open-source tool rather than a vendor's private validator. That's a meaningful difference from a TSA relationship, where the verification tooling and the trust anchor both trace back to the same signer.

Verifying a proof yourself

With a TSA-issued timestamp, verification typically runs through PKI tooling that checks the token's signature against the TSA's certificate and walks the chain to a trusted root. That's standard, and it works well as long as the chain resolves.

With a ProofLedger anchor, verification doesn't depend on ProofLedger staying online. The verify-proof package on PyPI does the check locally against the proof bundle you saved from GET /api/v1/proof/{id}/bundle:

pip install verify-proof
verify-proof hash document.pdf
# SHA256: 4d2c1216b50e3936edb1cebd02770c41c976d9cb9cc9e5517d187d3b535a2deb
# File: document.pdf

verify-proof verify document.pdf --proof proof.json
# VERIFIED: File matches the proof bundle. The bundle says it was anchored on polygon at 2026-10-15T02:11:09.512Z in transaction 0x8f3a...

That command hashes the file on your machine and checks it against the proof data you already have. No network call happens during verification, by design: a check that depends on the issuing service isn't really independent verification. It does not read the chain either; open the transaction it names on any Polygon block explorer to confirm the anchor.

For a hash you don't have a proof file for yet, the public endpoint works without an account:

GET https://proofledger.io/api/v1/verify?hash=4d2c1216b50e3936edb1cebd02770c41c976d9cb9cc9e5517d187d3b535a2deb

No authentication. Anyone, including an auditor or a counterparty, can confirm whether a given hash was anchored and pull the blockchain explorer link directly.

Which fits your situation

An RFC 3161 timestamp works within a model you're likely already comfortable with if your organization already validates certificate chains for other purposes, like signed PDFs or code signing. But that comfort comes with a dependency: the proof's long-term verifiability rests on a certificate chain that has to keep resolving, years or decades after the fact, through whatever CA infrastructure exists at that point. If you're building a record meant to be checked five or ten years from now, that's the tradeoff you're accepting: continued institutional cooperation, not just cryptographic math.

ProofLedger is built for the case where you want a proof that doesn't depend on any one party staying in business or keeping a signing key secure indefinitely. The hash goes into a Polygon transaction. That transaction, on its own, gives a verifier a path to confirm timing without asking ProofLedger for anything: one public record instead of one private signature.

For records that might be questioned years after they're created, that's the case for anchoring to a public ledger over trusting a single signer's certificate chain. Start with the file on your own machine, hash it, and anchor the hash. The verification path stays open to anyone who needs to check it, for as long as the chain exists. The API is documented at https://proofledger.io/api.html.