If you're documenting evidence before a dispute happens, you need a way to prove a file existed at a specific point in time. 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 and to Bitcoin. You never upload the file. Only the 64-character hash goes anywhere, and it goes to two public blockchains 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. Polygon anchoring confirms fast. Bitcoin anchoring settles in a daily batch using a Merkle tree, so a single Bitcoin transaction can anchor many hashes at once while each one still gets an individually checkable proof path. Verifying either chain doesn't require trusting ProofLedger's continued operation. The transaction is on a ledger that thousands of independent nodes maintain, 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:

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

verify-proof verify document.pdf --proof proof.json
# VERIFIED: hash matches, anchored on polygon, tx 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.

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=<sha256>

No authentication. Anyone, including opposing counsel or an auditor, can confirm whether a given hash was anchored and pull the blockchain explorer links 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 an evidence record meant to hold up in a dispute 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 on Polygon and Bitcoin. Either chain, independently, gives a verifier a path to confirm timing without asking ProofLedger for anything. Add a Bitcoin anchor for a settlement layer that isn't tied to any single blockchain's continued operation either, and you have two independent public records instead of one private signature.

For claims documentation, forensic evidence, or pre-loss records that might get challenged 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 chains exist.