The Gap Between Capture and Proof
A photograph's history usually has a hole in it. The camera records a capture time that anyone can change in a menu. Verification or signing happens days or weeks later, once the shoot is culled and edited. Everything between those two moments, from the card backup to the working copies, rests on the photographer's word.
Whoever challenges a photograph aims at exactly that hole. When did these files first exist? Who besides you can confirm it? A hash log kept on your own laptop answers with "trust me", and our chain of custody guide shows how quickly courts discount records that exist only in the hands of the party presenting them.
Lumethic Offloads closes that gap. It takes the hash manifest your offload tool already writes during every card backup and anchors it with an independent timestamp, minutes after the shoot.
What Offloads Does
When you back up a card with a professional transfer tool such as OffShoot, Silverstack, ShotPut Pro or YoYotta, the tool writes a manifest: a list of every copied file with its checksum. That manifest is a complete fingerprint of the card at the moment of backup. Until now it mostly sat in the destination folder, useful for detecting copy errors and little else.
Offloads turns it into a fixed point in time. You upload the manifest, Lumethic signs it and has it countersigned by an independent timestamp authority under RFC 3161, the standard protocol for trusted timestamping. The result is a receipt stating that this exact manifest, and with it the fingerprint of every file in it, existed no later than the anchor date.
Two properties matter here. The date comes from a third party, not from Lumethic and not from you. And the receipt can be checked by anyone: it is self-contained JSON that verifies against the manifest bytes on our public receipt checker. That check needs no account and does not depend on trusting Lumethic.
From Card Backup to Anchored Receipt
The workflow adds one step to what you already do:
- Offload the card as usual. Your tool writes the manifest next to the copied files: a zipped ascmhl folder (ASC MHL), a single .mhl file, hashdeep output, or a plain JSON hash list.
- Upload the manifest at lumethic.com/offloads, or let a post-transfer script submit it automatically.
- Lumethic anchors it. The manifest is parsed, signed and countersigned by the timestamp authority, usually in under a minute.
- Keep the receipt. Download it as JSON, file it with your case or project documentation, or share it as a public link.
The photographs themselves never travel. Only the manifest is uploaded, a few kilobytes even for a full card, and your files stay on your drives.
Where It Fits in the Chain of Custody
Our six-step chain of custody guide puts verifiable transfer and cryptographic hashing at step 3: hash every file right after transfer, log the values and seal the original card. Practitioners have followed that advice for years, and it has a quiet weakness. The hash log lives with the person who produced it. Opposing counsel does not have to claim you altered anything. They only need to point out that nothing outside your own records fixes the date of the list.
An anchored offload removes that objection. The manifest is the hash log, and the timestamp authority's countersignature fixes it in time. Backdating it then becomes technically infeasible. Your log entry for step 3 shrinks to one line: the receipt identifier and the anchor date.
The anchor also carries forward. When you later verify individual files with Lumethic, each verification links back to the offload it appeared in, and the provenance timeline shows both events with their attested times. A photograph can then arrive at a dispute with an unbroken, independently dated history: on the card by this date, verified in this state on that date. And when selected frames become exhibits, the Lightroom plugin covers the final step: it checks on export that the delivered JPEG derives from the verified RAW and embeds Content Credentials in the file.
One detail matters for long-running cases: receipts stay valid even if you delete the offload from your account later. They verify against the manifest bytes, wherever those are held.
What a Receipt Proves, and What It Does Not
A valid receipt proves three things. The manifest existed no later than the anchor date. Lumethic received exactly those bytes and stored them unchanged. And the summary in the receipt follows from them.
It deliberately claims nothing else. It does not say the photographs are authentic, name who uploaded the manifest, or vouch for the camera's clock. That restraint is what makes the receipt hold up: every statement in it can be checked cryptographically, so none of it depends on anyone's credibility.
This matches how photographs are actually used in a dispute. They are usually accepted because the photographer testifies to what they show. An anchored offload does not replace that testimony, it backs it up: faced with the suggestion that the files were generated or edited after the fact, you can show they existed unchanged from the day of the backup.
Content-Bound or Event-Only: The Checksum Decides
Every offload receives one of two grades, and your transfer tool's checksum setting decides which. Most tools default to xxHash, a checksum built for speed rather than tamper resistance. An anchor built on xxHash proves the offload happened at the anchored time (Lumethic labels this "offload event only"), but it cannot bind the file contents. MD5 and SHA-1 land in the same grade, since both have known collision attacks.
C4, the content-addressing checksum in the ASC MHL standard, can bind contents. Switch your tool's checksum type to C4 and every future offload earns the content-bound grade, where the anchor covers what the files contained, not merely that a copy took place. The setting usually sits in the tool's transfer or verification preferences and takes a minute to change. If your work may ever face scrutiny, change it before the next shoot.
Automatic Uploads From the Field
Anchoring works best when nobody has to remember it. A scoped API key, which can submit offloads and read nothing else, lets a field laptop upload each manifest the moment a transfer finishes. OffShoot triggers this with a post-transfer script, and any tool that can run a command after copying can call the same one-liner. Set it up once, and every card you back up from then on carries an independent timestamp, whether or not the shoot ever ends up contested.
Offloads is live now for all Lumethic accounts at lumethic.com/offloads.
Offloads FAQ
Does an anchored offload prove my photos are authentic? No. It proves the files existed no later than the anchor date, in exactly the state the checksums describe. Whether a photograph is an unedited camera original is a separate question, answered by RAW verification. The two combine well because they answer different questions.
Can software lock the files on a memory card? No. Memory cards give software no way to make files immutable, ours included. The working practice is different: flip the card's write-protect switch after the shoot, offload with one of the tools above, and anchor the manifest. Anchoring does not prevent later changes. It makes them detectable, which is what a dispute actually requires.
Are my photos uploaded to Lumethic? No. Only the manifest is uploaded, the hash list your offload tool writes. The photographs stay on your drives.
What happens if I delete an offload later? Receipts you already downloaded or shared stay valid. They verify against the manifest bytes wherever those are held. Deleting Lumethic's copy removes a convenience, not the proof.
Which checksum should my offload tool use? C4. It is the one checksum in the ASC MHL standard that binds file contents, so anchors built on it receive the content-bound grade. xxHash, MD5 and SHA-1 all lead to offload-event-only anchors.
Can someone check a receipt without a Lumethic account? Yes. Receipts are self-contained JSON, and the receipt checker works without signing in. Shared receipt pages are public as well.
