If you're documenting evidence and researching provenance standards, you'll run into C2PA (Content Credentials) fast. It's backed by Adobe, Google, Microsoft, and OpenAI, and some newer phone hardware now signs photos with it at capture. That's real adoption. But C2PA and a blockchain anchor solve different problems, and knowing which one you're actually reaching for matters before a dispute forces the question.

What C2PA is and how it works

C2PA embeds cryptographically signed provenance metadata directly inside a file. When a camera or an editing tool supports it, every capture or edit gets recorded in a manifest: who created the file, what device captured it, what changes were made, in what order. That manifest travels with the file as an embedded credential.

The trust model is straightforward. A relying party opens the file, reads the embedded signature, and checks it against the signing certificate. If the signature validates, the provenance claims in the manifest are attributed to whoever signed them. It's a direct answer to "what happened to this file and who did it."

The limitation is structural, not a flaw in the spec. The credential lives inside the file. Move the file, and the credential moves with it, as long as nothing strips it out along the way. Upload the photo to a platform that recompresses images. Convert it from RAW to JPEG. Send it through an email client that regenerates thumbnails. Any of these can drop the embedded manifest, sometimes as a side effect of formats or platforms that were never built with C2PA in mind. The file survives. The provenance doesn't always make the trip with it.

For a claims department or a litigation team, that's the gap that matters. A field photo captured on a C2PA-aware phone might carry a clean manifest at the moment it's taken. By the time it's pulled from a claims portal six months later for a deposition, the manifest may or may not still be attached, and there's often no way to know why it's missing if it's gone. The file itself doesn't tell you whether stripping happened at upload, at storage, or somewhere in between.

What ProofLedger does differently

ProofLedger doesn't put anything inside the file. It hashes the file with SHA-256 and anchors that hash to two blockchains: Polygon, which confirms fast, and Bitcoin, added as a daily batch with a Merkle proof. The file itself never leaves the machine it's on. Only the 64-character digest goes anywhere.

That distinction is the whole point. Because the anchor doesn't live in the file, nothing that happens to the file afterward can touch it. Recompress it, convert it, re-upload it twenty times across twenty platforms: the SHA-256 hash of the exact original bytes was anchored the moment it was created, and that anchor exists independently on a public ledger. You don't need the file's internal metadata to survive intact. You need the file's original bytes, and a proof that a specific hash of those bytes existed on a specific date.

Every proof gets a public verification page. Anyone, including opposing counsel or a third-party auditor, can check whether a hash was anchored and when, without needing an account or a relationship with ProofLedger.

Verifying a proof yourself

This is where the two approaches diverge most in practice. Verifying a C2PA credential means trusting the tool that reads the embedded manifest and validates it against the signing certificate chain. Verifying a ProofLedger anchor means checking a public ledger directly, and you can do that offline.

Hash a file locally with the verify-proof CLI:

pip install verify-proof
verify-proof hash myfile.pdf

That prints the SHA-256 digest and the file path. Nothing leaves your machine for that step.

To anchor a hash, verify-proof's create command submits only the digest to ProofLedger's API:

verify-proof create myfile.pdf --bitcoin

Output looks like this:

Proof submitted to ProofLedger.

  Proof id      : 34
  SHA-256       : 4d2c1216b50e3936edb1cebd02770c41c976d9cb9cc9e5517d187d3b535a2deb
  Filename      : myfile.pdf
  Status        : approved
  Created       : 2026-09-06T22:23:00.301Z
  Certificate   : https://proofledger.io/cert/34
  Verify        : https://proofledger.io/verify.html?hash=4d2c1216...

Anyone can then confirm a hash independently through the public endpoint, no account needed:

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

That returns whether the hash was found and, if so, the proof record and a blockchain explorer link. An attorney reviewing evidence from the other side of a case can run that check themselves, on their own timeline, without asking anyone for permission.

The offline verification path also covers a saved proof file directly:

verify-proof verify myfile.pdf --proof proof.json

All of this happens without a network call except the initial anchor. The Python package underneath (verify_proof plus proofledger_api for submission) exposes the same functions if you're building verification into a pipeline rather than running it by hand.

Which fits your situation

C2PA answers "who made this and what was done to it." That's a question about authorship and edit history, and it's a useful one, especially as more capture hardware signs at the point of creation. But the answer lives inside the file, which means its availability at the moment you need it depends on every system the file passed through along the way having respected the credential. If your evidence chain runs through a platform upload, a format conversion, or a compression step you don't control, that's the dependency you're accepting: you won't know the manifest is gone until you go looking for it and it isn't there.

ProofLedger answers a narrower, different question: did this exact set of bytes exist at this point in time. The proof isn't embedded in anything that can be stripped, because it was never inside the file to begin with. It sits on a public ledger, checkable by anyone, independent of what platform the file later travels through.

For pre-loss documentation, claims evidence, or anything that might end up in front of a judge asking about chain of custody, that independence is the property worth having. A photo taken before a loss needs a timestamp that survives the file's entire journey through claims software, email, and discovery, not just the moment it was captured. That's what a hash anchored to two separate blockchains is built to do.