A claims team storing pre-loss photos in S3 with Object Lock enabled might assume they've solved the timing problem. They haven't. Object Lock and versioning answer a narrower question: has this file been deleted or changed since a given date? They say nothing about when the photo was actually taken, and they depend entirely on the same account holder who uploaded the file to have configured the lock correctly, before anyone had a reason to dispute it.

What S3 Object Lock is and how it works

S3 Object Lock is a write-once-read-many (WORM) control built on top of S3 versioning. Once enabled on a bucket, an object version can be placed under a retention period during which it can't be deleted or overwritten. AWS offers two modes: governance mode, which blocks deletion for most users but can be bypassed by an account with s3:BypassGovernanceRetention permission, and compliance mode, which locks the object for the retention window with no override, not even by the root account. A separate legal hold flag can pin an object indefinitely regardless of retention date.

The account owner sets all of this up. They enable versioning, turn on Object Lock at bucket creation, choose the mode, and set the retention period. AWS enforces the rule mechanically, but the rule itself, and the decision of when to apply it, comes from the customer's own configuration. If that configuration is loosened, misapplied, or set up after the fact, the guarantee only covers what happened from that point forward. Nothing in Object Lock verifies when the underlying photo, video, or document was originally captured. It verifies that a specific stored version hasn't been touched since it was locked, and the lock itself has a start time chosen by the same party who uploaded the object.

That's a real and useful guarantee for retention compliance, records management, and backup integrity. It is a different guarantee from proving that a piece of evidence existed before a loss occurred, especially when the entity being trusted to have configured the lock correctly is also the party with an interest in the outcome of a dispute.

What ProofLedger does differently

ProofLedger doesn't store the file at all. A SHA-256 hash is computed locally and only the hash is submitted for anchoring, first to Polygon, then batched to Bitcoin with a Merkle proof. The file stays wherever it already lives, in S3, on a laptop, in a case management system. What goes on-chain is a fixed-length digest tied to a specific timestamp, on a ledger that isn't operated by the party submitting the hash and isn't operated by ProofLedger either.

That's the structural difference. Object Lock protects a file inside a system the account owner controls and can reconfigure. A blockchain anchor exists on infrastructure the person submitting the evidence doesn't control and can't retroactively edit, no matter what permissions their AWS account has. If the hash of a photo was anchored on March 3rd and the loss happened March 10th, a party reviewing the claim doesn't have to trust that the claimant's bucket policy was set up correctly and never loosened. They can recompute the hash of the photo and check it against a public record that predates the point of dispute.

The two aren't solving the same layer of the problem. Object Lock is about custody after storage: has this exact stored copy been altered. A ProofLedger anchor is about origination: did this exact set of bytes, identified by its hash, exist at this exact time, attested to by a system nobody involved in the claim operates.

Verifying a proof yourself

Every anchor gets a public verification page, and the underlying check doesn't require an account or a login. Anyone, including opposing counsel or a third-party auditor, can confirm a hash was anchored by hitting the public endpoint directly:

GET https://proofledger.io/api/v1/verify?hash=<sha256>

No authentication, no API key. It returns whether the hash was found, along with the proof record and a block explorer link for the anchoring transaction.

For local, offline verification without any network call, the verify-proof package does the same check against a saved proof file:

pip install verify-proof

verify-proof hash ./site-photo.jpg
# SHA256: 4d2c1216b50e3936edb1cebd02770c41c976d9cb9cc9e5517d187d3b535a2deb
# File: ./site-photo.jpg

verify-proof verify ./site-photo.jpg --proof ./proof.json
# VERIFIED: hash matches, anchored on polygon, tx confirmed

verify-proof verify recomputes the hash of the file in front of you and checks it against the hash and Merkle path recorded in the proof file. It makes no network calls during verification, which is deliberate: a check that depends on asking the vendor whether its own proof is valid isn't independent verification. The only command that talks to ProofLedger's servers is create, which submits a new hash for anchoring, not the commands that check one.

That's the part an S3 bucket policy can't offer. There's no equivalent public, vendor-independent page where a third party can type in a hash and confirm on their own that a specific version of a file was locked on a specific date without asking AWS, and without trusting the bucket owner's account settings.

Which fits your situation

If your evidence workflow already runs through S3, Object Lock is worth having. It stops accidental deletion, it satisfies internal retention policy, and compliance mode gives you a hard backstop against tampering by anyone with account access, including your own admins. None of that is in question.

What it doesn't give you is a timestamp a skeptical third party has to accept without trusting your AWS configuration. The retention clock starts when your account locked the object, set by the same organization that has a stake in when the claim says the photo was taken. If a dispute turns on proving a document existed before a specific date, the strength of that proof depends on convincing the other side that the lock was set correctly, on time, and hasn't been reconfigured since, which is a chain of trust that runs entirely through one party's cloud account.

ProofLedger is built for the piece Object Lock doesn't cover: an independently checkable record of when a file's hash existed, sitting outside any storage account either side controls. It doesn't replace your storage or retention policy. It gives you something to point to when someone asks not "was this file protected from deletion" but "how do I know this wasn't created after the fact."