The case
In Williams v. Sprint/United Management Co., 230 F.R.D. 640 (D. Kan. 2005), plaintiffs in an employment discrimination case challenged Sprint's ESI production after Sprint converted Excel spreadsheets to static TIFF images. The conversion stripped the metadata embedded in the originals, removing the contextual record of when, how, and by whom the documents were edited. The core dispute: whether embedded metadata was a discoverable component of the record or merely an artifact of native file format that a producing party could discard in conversion.
What the court held
The court held that ESI must generally be produced in a form that preserves its metadata, treating embedded metadata as a discoverable component of the underlying record rather than something that can be jettisoned in format conversion. Sprint was ordered to reproduce the documents in native format. The decision predated, and was consistent with, the 2006 amendment to FRCP 34(b)(2)(E), which codified that ESI must be produced in the form it is ordinarily maintained or in a reasonably usable form or forms.
Where blockchain anchoring fits
Williams settled the discoverability question. It didn't settle the authenticity question that follows.
Native file metadata is mutable. Excel modification timestamps, EXIF capture fields in photographs, document creation dates in PDFs. These values live inside files that parties create, store, and produce. A forensic examiner can often detect manipulation, but the structural problem persists: the chain of custody for the metadata and the chain of custody for the file are the same chain. If the file can be altered, the metadata can be altered. Producing native ESI with intact metadata, as Williams requires, tells the court the metadata exists. It doesn't tell the court whether the metadata was accurate when the file was first created.
Think about what this looks like in a property insurance dispute. A policyholder submits photographs after a water loss. The EXIF timestamps in those files show the photos were taken before the reported loss date. Williams compliance is satisfied: native format, metadata intact, production was proper. But the EXIF timestamp is exactly what's in dispute. Camera clocks get reset. Photos get transferred between devices, re-saved. The metadata has no independent witness to what it said on the day those files were actually created.
A SHA-256 hash anchored to Polygon and Bitcoin provides that independent witness. The anchor is recorded at a specific moment on two public blockchains, outside any party's custody or control. No format conversion strips it. No production decision touches it. If the photos were anchored on the day they were taken, the dual-chain record reflects the content and timing of those files independently of anything inside them.
What blockchain anchoring proves: a file with exactly this content existed at this point in time. What it cannot prove: that the file still exists, or that its contents are accurate. Those are separate evidentiary questions. For the timing dispute common to insurance claims, employment matters, and contract cases (did this document exist before the adverse event), the anchor answers it independently of embedded metadata.
The verify-proof package allows offline verification against both Polygon and Bitcoin without a network call to ProofLedger or any centralized service. Opposing counsel and court-appointed forensic examiners can validate the anchor themselves against the public ledger.
Williams identified one failure mode: parties discarding metadata through format conversion. The harder problem follows: even compliant native production doesn't tell the court whether the metadata was accurate when the file originated.
The takeaway for practitioners
Williams compliance (native ESI production with intact metadata) protects against spoliation exposure under FRCP 37(e), but it doesn't resolve disputes about whether preserved metadata accurately reflects when a file was created and in what state. FRE 901(b)(9) authenticates evidence produced by a process or system generating an accurate result; a dual-chain blockchain anchor is that kind of process, creating a record that sits outside any party's control and any party's production decisions. For self-authentication without live expert testimony, FRE 902(13) covers the blockchain anchor record as a machine-generated record from a reliable electronic process, and FRE 902(14) provides a path for certifying that a specific file corresponds to its anchored hash value.
References
- Williams v. Sprint/United Management Co., 230 F.R.D. 640 (D. Kan. 2005)
- FRE 901(b)(9): Authentication of evidence produced by a process or system generating an accurate result
- FRE 902(13): Self-authentication of records generated by an electronic process or system
- FRE 902(14): Self-authentication of electronic data identified by hash value
- FRCP 37(e): Sanctions for failure to preserve ESI
- FRCP 34(b)(2)(E): ESI production form requirements (2006 amendment)
