DEV Community: Craig Solomon

A checksum fixes half the problem.

Craig Solomon — Wed, 26 Aug 2026 13:00:00 +0000

A structural engineer submits an inspection report in a construction defect case. Opposing counsel pulls up the PDF properties, points to a "modified" date three weeks after the cover page, and asks the engineer to explain it on the stand. Nothing in the report changed. Software auto-updated the file when someone printed it. But now the report's credibility is the issue, not the roof.

That date on the PDF isn't a record of when the content was written. It's a record of the last time the operating system touched the file. Printing touches it. Opening it in a viewer that re-indexes fonts touches it. Copying it to a shared drive touches it. None of that is "someone edited this document." All of it can move the modified date.

Here's the part that catches people off guard: even if you never open a file again, metadata isn't tamper-evident. A modified date sits in the file system, not the file. Change your system clock, copy the file, and the new copy inherits whatever date you want it to have. There's no cryptographic link between the timestamp and the content. It's a label, not a proof.

A checksum fixes half the problem.

Run a file through SHA-256 and you get a hash, a fixed-length fingerprint of the content. Change one pixel, one character, one byte, and the hash changes completely. That's genuinely useful. It tells you a file hasn't been altered since the hash was generated.

What it doesn't tell you is when that hash was generated. You could compute a SHA-256 hash today for a photo you claim was taken last year. The hash proves the file matches itself. It says nothing about the timeline. Integrity and timing are two different problems, and a checksum only solves one of them.

Timing requires something outside your control.

To prove a file existed at a specific point in time, you need a record that you can't quietly edit afterward. A blockchain anchor works because the ledger isn't yours. You generate the hash locally (the file itself never leaves your device), and that hash gets written into a transaction on a public chain. Once it's confirmed, anyone can independently verify that exact hash existed in that block, at that time. Not because you said so. Because the network recorded it and thousands of nodes agree on the record.

ProofLedger anchors to two chains for a reason. Polygon confirms in seconds, so you get a timestamp almost immediately after capture. Bitcoin adds a daily batch anchor with a merkle proof tying your hash into that day's block, giving you the security of the most battle-tested chain in existence without paying Bitcoin fees on every file. Two independent, verifiable records instead of one.

Where this fits in a legal proceeding matters too.

Courts can authenticate blockchain-anchored records under FRE 901(b)(9), the rule covering evidence "produced by a process or system that produces an accurate result." That requires laying a foundation, usually expert testimony or a technical certification explaining how the anchoring process works and why it's reliable. It's not automatic. Separately, FRE 902(13) and 902(14) cover self-authentication of machine-generated records through written certification, added in 2017 specifically for cases like this, where a party wants to skip live testimony and authenticate via certified documentation instead. Different rule, different mechanism, and knowing which one applies to your situation is worth a conversation with counsel before you're in front of a judge.

If your organization is also using C2PA content credentials at capture, that's a good complement, not a substitute. C2PA embeds who captured a file, when, and with what device, directly into the file's metadata. The problem is that metadata lives inside the file. Re-upload it to a platform that strips metadata, convert the format, and the credential can disappear before it's ever needed. A blockchain anchor doesn't have that failure mode, because it was never stored in the file to begin with. It exists on a ledger the file doesn't control.

The engineer on the stand didn't need a better PDF. He needed a record, made the day the report was finished, that existed independently of the document and couldn't be explained away by a software quirk. That's the gap between a timestamp anyone can produce and one nobody can dispute.

See how dual-chain anchoring works

FRE 901 Blockchain Evidence Authentication: What the Standard Actually Requires

Craig Solomon — Fri, 21 Aug 2026 13:00:00 +0000

Meta description: How blockchain timestamps satisfy FRE 901(b)(9) and FRE 902(13) for evidence authentication in insurance claims and litigation.

You have a blockchain timestamp. The file hash is anchored on Bitcoin. Six months before the loss. Now someone's asking how you authenticate it.

That question comes up the moment blockchain-anchored evidence reaches a dispute. ProofLedger anchors file hashes to both Polygon and Bitcoin, and the records it generates are designed to satisfy the authentication standard from the start.

Under FRE 901(b)(9), evidence can be authenticated by showing it was produced by "a process or system that produces an accurate result." Blockchain timestamps fit this pathway. But the rule requires foundation. It isn't self-authenticating.

That distinction matters.

Self-authentication is FRE 902(13) and 902(14). Those provisions, added in 2017, allow machine-generated records to be admitted through written certification without live testimony. A blockchain anchor record can qualify under 902(13) when a proper certification accompanies the submission. That's the cleaner path at trial, and the one claims professionals should plan for.

FRE 901(b)(9) is still relevant for the foundation argument. It establishes that the blockchain itself is a reliable system. Expert testimony about how SHA-256 hashing works, how Polygon confirmation operates, and how Bitcoin's proof-of-work creates immutability satisfies the process-reliability standard. But it's a heavier lift than certification.

Here's the practical workflow. An adjuster or forensic consultant creates an evidence pack in ProofLedger at the time of site documentation. Each file gets SHA-256 hashed. Only the hash leaves the device; the original file stays local. The hash is anchored to Polygon for an immediate timestamp, then batched to Bitcoin with a daily merkle proof. The resulting certificate ties the hash to both chains, both timestamps.

When that evidence reaches discovery, the certificate is the starting point. Under FRE 902(13), it can be self-authenticated through written certification. Under FRE 901(b)(9), it supports expert testimony about process reliability. Either way, the anchor record is the foundation.

What it proves: the file existed at that hash value, at that moment. Not that the contents are true. Not that the file was the only version. But that the bit-for-bit document a party is presenting today existed before the loss date. That's the gap most digital evidence can't close.

Metadata timestamps can be changed. File creation dates can be altered. A blockchain anchor can't. The Bitcoin record has been continuously secured since 2009 by a network with more computing power than any single actor can match. A timestamp recorded there isn't going anywhere.

For claims professionals, the value shows up early. Risk managers and property managers who anchor documentation before a loss create a provenance record that survives the chain-of-custody challenges that come later in litigation. The anchor exists independent of the file, independent of any platform, independent of anything that might change hands during a claim.

FRE 901 blockchain evidence authentication isn't a theoretical discussion anymore. More carriers and legal teams are asking about it. The question now is whether the anchor records you're relying on were made correctly.

Anchor before the loss, not after. Risk documentation, not claim documentation.

Stacking C2PA Content Credentials with Blockchain Timestamps in Python

Craig Solomon — Thu, 20 Aug 2026 13:00:00 +0000

A file arrives from the field. It has C2PA content credentials: the camera model, GPS coordinates, capture time, an edit history. Solid provenance data.

Now it gets uploaded to a claims portal. The portal re-encodes it. Or it gets forwarded as an email attachment and the MIME handler strips the XMP block. Or someone converts it to a different format before anyone thinks to extract the metadata.

The C2PA manifest is gone. It lived inside the file, and the file changed.

A blockchain anchor doesn't work that way. Once a SHA-256 hash is written to an immutable ledger, the proof exists independently. No re-encoding touches it. No transfer strips it.

This post builds a Python pipeline that reads C2PA provenance data, hashes the file locally, and anchors the hash via REST API. Two evidence layers. One script.

What Each Layer Proves

C2PA (Content Credentials) answers provenance questions: which device captured the file, what software processed it, what edits were applied, and what the signing certificate's timestamp says. The standard has broad industry backing. Samsung Galaxy S25 and Google Pixel 10 now sign images natively at the camera level, so coverage from hardware is growing.

The limitation is architectural. A C2PA credential is a signed block embedded in the file. Strip the file's metadata, convert the format, or run it through a tool that doesn't preserve the XMP block, and the credential disappears. There's no independent copy.

A blockchain anchor is a different kind of proof. It answers: did this exact byte sequence exist at this point in time? The hash is computed from the file's bytes on your local machine. Only the hash goes anywhere. The anchor lives on a public ledger that anyone can read without touching the original file.

These are different questions. C2PA says where and how. Blockchain says when. If what's being disputed is timing, whether a file was created before or after a specific event, you need both.

Reading the C2PA Manifest

pip install c2pa-python requests

The c2pa-python package wraps the Rust C2PA SDK. The Reader class takes a MIME type and a binary stream. Check the README for your installed version, since the API has evolved across releases.

import c2pa
import json

MIME_MAP = {
    "jpg": "image/jpeg",
    "jpeg": "image/jpeg",
    "png": "image/png",
    "gif": "image/gif",
    "mp4": "video/mp4",
    "mov": "video/quicktime",
    "pdf": "application/pdf",
}

def get_mime(filepath: str) -> str:
    ext = filepath.rsplit(".", 1)[-1].lower()
    return MIME_MAP.get(ext, "application/octet-stream")

def read_c2pa(filepath: str) -> dict | None:
    """Return parsed manifest store, or None if no C2PA data."""
    try:
        with open(filepath, "rb") as f:
            reader = c2pa.Reader(get_mime(filepath), f)
            raw = reader.json()
        return json.loads(raw) if raw else None
    except Exception:
        return None

If the file has no C2PA credentials, you get None. That's expected. The anchor pipeline runs either way.

The manifest store JSON has a nested structure. The active manifest lives under manifests[active_manifest]. Here's how to pull the fields most useful for an evidence record:

def summarize_manifest(store: dict) -> dict:
    active_key = store.get("active_manifest", "")
    active = store.get("manifests", {}).get(active_key, {})
    sig_info = active.get("signature_info", {})
    assertions = [
        a.get("label")
        for a in active.get("assertions", [])
        if a.get("label")
    ]
    return {
        "claim_generator": active.get("claim_generator"),
        "format": active.get("format"),
        "signing_time": sig_info.get("time"),
        "signing_issuer": sig_info.get("issuer"),
        "assertions": assertions,
    }

signing_time is the timestamp from the credential authority. Useful context. But it's not an independent timestamp. It comes from the certificate authority that issued the manifest. Don't treat it as equivalent to a blockchain anchor.

Hashing and Anchoring

The file never leaves your machine. Only the SHA-256 hash goes to the API.

import hashlib
import time
import requests

ANCHOR_URL = "https://proofledger.io/api/v1/proof"
API_KEY = "sk_YOUR_KEY_HERE"

def sha256_file(filepath: str) -> str:
    h = hashlib.sha256()
    with open(filepath, "rb") as f:
        for chunk in iter(lambda: f.read(65536), b""):
            h.update(chunk)
    return h.hexdigest()

def anchor_hash(sha256: str, filename: str) -> dict:
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    }
    body = {"sha256": sha256, "filename": filename}

    for attempt in range(3):
        resp = requests.post(ANCHOR_URL, json=body, headers=headers, timeout=30)

        if resp.status_code == 201:
            return resp.json()

        if resp.status_code == 400:
            raise ValueError(f"Bad request: {resp.text}")

        if resp.status_code in (401, 403):
            raise PermissionError("Invalid API key or insufficient plan.")

        if resp.status_code == 409:
            return {**resp.json(), "_is_duplicate": True}

        if resp.status_code == 429:
            wait = int(resp.headers.get("Retry-After", 60))
            print(f"Rate-limited. Waiting {wait}s.")
            time.sleep(wait)
            continue

        resp.raise_for_status()

    raise RuntimeError("Failed after 3 attempts.")

This calls the ProofLedger v1 REST API. The 409 response means the hash was already anchored. The response body includes duplicate_of, pointing to the original proof ID. Treat the earliest anchor as canonical.

The API requires a Professional or Business plan key (format: sk_...). Polygon anchoring happens automatically on submission. Bitcoin is an optional paid escalation per proof.

Third-Party Verification

Anyone with the SHA-256 can verify the anchor without credentials:

def verify_anchor(sha256: str) -> dict:
    url = f"https://proofledger.io/api/v1/verify?hash={sha256}"
    resp = requests.get(url, timeout=15)
    resp.raise_for_status()
    return resp.json()

This endpoint is public and rate-limited to 120 requests per hour per IP. No API key needed. Opposing counsel can run this check on a hash you provide.

result = verify_anchor(file_hash)
if result.get("found"):
    print(f"Anchored: {result['proof']['anchored_at']}")
    print(f"Explorer: {result.get('explorer_url')}")
else:
    print("Not found.")

Putting It Together

import json
from pathlib import Path

def process_file(filepath: str) -> dict:
    path = Path(filepath)

    sha256 = sha256_file(filepath)

    raw_manifest = read_c2pa(filepath)
    manifest_summary = summarize_manifest(raw_manifest) if raw_manifest else None

    proof = anchor_hash(sha256, path.name)

    record = {
        "file": path.name,
        "sha256": sha256,
        "c2pa": manifest_summary,
        "anchor": {
            "proof_id": proof.get("id"),
            "status": proof.get("status"),
            "certificate_url": proof.get("certificate_url"),
            "is_duplicate": proof.get("_is_duplicate", False),
            "duplicate_of": proof.get("duplicate_of"),
        },
    }

    sidecar = path.with_suffix(".proof.json")
    sidecar.write_text(json.dumps(record, indent=2))

    return record

if __name__ == "__main__":
    import sys
    for filepath in sys.argv[1:]:
        r = process_file(filepath)
        dup_note = " (duplicate)" if r["anchor"]["is_duplicate"] else ""
        print(f"{r['file']}: {r['anchor']['proof_id']}{dup_note}")

Run it on any files:

python c2pa_anchor.py site_photo.jpg inspection_report.pdf dashcam.mp4

Each file gets a .proof.json sidecar with the C2PA manifest summary (null if no credentials were present), the SHA-256, and the anchor record.

What You Have

For each file you process:

Original file, unchanged, on your machine
C2PA manifest summary when credentials are present: signing time, claim generator, assertion labels
SHA-256 anchored to a public ledger
A .proof.json sidecar tying both layers together

The C2PA layer tells you origin: which device, which pipeline, what the signing certificate says. The blockchain layer tells you existence: these bytes were recorded before anyone could dispute the timing.

Strip the C2PA data and the blockchain anchor still holds. The ledger doesn't care what happened to the file afterward.

C2PA coverage at the hardware level is growing. More files will arrive with credentials already embedded. Capturing those credentials alongside the anchor, before they get stripped somewhere downstream, adds maybe 20 lines to a file intake script.

One practical note: pin c2pa-python to a specific version in your requirements.txt. The SDK is actively developed and the API has changed between minor releases. Pin it, test it, and check the release notes before upgrading.

What format are the bulk of your incoming files? And are you seeing real C2PA credentials on production files yet, or mostly synthetic credentials in test images?

How Do Organizations Create Blockchain-Anchored Timestamps for Legal Evidence?

Craig Solomon — Wed, 19 Aug 2026 13:00:00 +0000

Organizations create blockchain-anchored timestamps for legal evidence by generating a SHA-256 hash of a file, then submitting that hash to a public blockchain network where it gets recorded in a specific block. The blockchain's timestamp becomes an independent, tamper-evident record showing the file (or rather, its fingerprint) existed at that exact moment, without the file itself ever leaving the organization's system.

That's the mechanism. The harder question is which method to use, and why it matters more than most people assume once a claim or dispute reaches discovery.

The Real Options for Timestamping Legal Evidence

A few approaches exist today, and they're not equally strong.

Notarization is the oldest method. A notary witnesses a signature and stamps a document with a date. It works for paper, it's legally recognized, and it doesn't scale to a folder of 400 site-inspection photos or a video file. Someone has to physically show up.

Cloud storage metadata (Google Drive upload dates, email timestamps, file system "created" dates) is what most people rely on by default. The problem: this metadata lives inside a system the organization itself controls, and it can be altered. A "created" date on a local file can be changed with a few clicks. Opposing counsel knows this, and it's the first thing a forensic examiner checks.

OpenTimestamps is a free, open protocol that anchors a file hash to the Bitcoin blockchain through a network of calendar servers. The cryptographic proof it produces is legitimate. What it lacks is a workflow: no hosted certificate, no branded verification page a claims adjuster or opposing counsel can open without technical setup, no case-organization layer. It's a proof format, not a documentation process.

C2PA Content Credentials takes a different approach. Backed by Adobe, Google, Meta, Microsoft, and OpenAI, C2PA embeds cryptographically signed provenance metadata directly inside a file, recording who captured it, when, with what device, and what edits followed. Samsung's Galaxy S25 and Google's Pixel 10 now sign photos at the camera level. The EU AI Act's Article 50 will require machine-readable content marking by August 2, 2026, and C2PA is the industry's chosen path there. Its limitation: the credential lives inside the file. Convert the format, strip metadata on upload to a platform, or transfer it the wrong way, and the credential can disappear before it ever reaches a courtroom.

Blockchain-anchored timestamping platforms anchor a file's hash externally, independent of the file itself. ProofLedger is one example built for this specifically: it hashes a file locally, anchors that hash to Polygon for an instant confirmation, and offers an optional Bitcoin anchor for additional immutability. Because the anchor lives on a public ledger rather than inside the file, it survives file transfers, format conversions, and platform re-uploads that would strip a C2PA credential.

Why Dual-Chain Anchoring Matters for Evidence

Anchoring to two independent networks is not redundancy for its own sake. Polygon confirms in seconds, which is useful when someone needs a timestamp immediately, at the moment of capture, not hours later. Bitcoin has processed blocks continuously since 2009 and represents a different kind of durability: rewriting Bitcoin's history would require overpowering more than half the network's accumulated proof-of-work, which is why it's treated as the gold standard for long-term immutability.

Anchoring to both means a single point of failure in one network doesn't undermine the record. If a party wants to attack the timing claim, they'd need to defeat two independently operated, publicly auditable systems, not one.

What a Blockchain Timestamp Does and Doesn't Prove

Here's where a lot of marketing overstates things, and where it matters to be precise for a legal or insurance audience.

A blockchain timestamp proves that a specific hash existed at a specific block, at a specific time. It does not, by itself, prove who created the file, what the file depicts, or that the file wasn't altered before it was hashed. It's a timing record, not a content authentication record.

Courts have a real framework for this. Under FRE 901(b)(9), evidence can be authenticated by showing it comes from "a process or system that produces an accurate result." That requires laying a foundation, typically expert testimony or a technical explanation of how the hashing and anchoring process works. It is not automatic. FRE 902(13) and 902(14), added in 2017, go further for machine-generated records: they allow self-authentication through written certification, without live testimony, if the certification meets the rule's requirements. These are the actual self-authentication rules, and they're worth citing by name if the goal is admissibility, not the more general 901(b)(9) process-reliability standard.

Pair a blockchain anchor with C2PA where possible and the two layers do different jobs. C2PA answers "who captured this, and with what." The anchor answers "did this exist before the date in question, and has anyone tampered with the record since." Neither replaces expert testimony. Both make that testimony easier to give.

How to Create a Blockchain-Anchored Timestamp, Step by Step

The process itself is simple, and that's intentional. It's the same regardless of file type, whether it's a 12-page inspection report or a multi-gigabyte site-walk video.

Hash the file locally. A SHA-256 hash is generated on the organization's own device. The file never uploads anywhere.
Submit the hash for anchoring. Polygon anchoring is free and unlimited on every tier. A Bitcoin anchor is available as a paid add-on for cases where the extra network adds value, litigation holds, high-value claims, anything likely to face a serious authentication challenge.
Receive a public verification record. A verify URL lets anyone (opposing counsel, an auditor, a claims examiner) confirm the hash independently, without needing an account or believing the organization's word for it.
Keep the certificate with the case file. Organized documentation, tagged by matter or claim number with loss-date context, is what turns a single proof into a defensible record months or years later when the dispute actually surfaces.

Teams that need this at scale (a claims department anchoring inspection photos across dozens of open files, or a firm handling recurring discovery production) can automate the process through a REST API, and developers can verify proofs offline with an open source verify-proof package rather than relying on a hosted page. Whatever the entry point, the underlying record works the same way: a hash, anchored publicly, checkable by anyone.

The choice isn't really between "blockchain or nothing." It's between a timestamp that lives only inside a system the organization controls, and one that exists independently of it. For evidence that might sit untouched for three years before a dispute even starts, that difference is the whole point. A tool like proofledger.io exists for exactly that gap: anchor the hash the day the evidence is captured, keep the file where it already lives, and have a record ready before anyone asks for one.

Beyond Authentication: FRE 803(6) and the Hearsay Problem in Blockchain Evidence

Craig Solomon — Mon, 17 Aug 2026 13:00:01 +0000

The authentication argument gets all the attention. FRE 901(b)(9), process reliability, blockchain cryptography. But admissibility has two separate problems, and the hearsay question is the one that catches practitioners off-guard.

Picture this: opposing counsel stipulates to authentication. They're not challenging whether the process was reliable or whether the hash matches the file. Their objection is hearsay. The proof certificate, they argue, is an out-of-court statement offered to prove when the file existed. Authentication doesn't answer that.

FRE 803(6) does.

Authentication and Hearsay Are Not the Same Problem

FRE 901(b)(9) authenticates evidence from a reliable process or system. FRE 902(13), added in 2017, handles that through written certification. No live testimony required. Both answer the same question: is this what it claims to be?

Hearsay is a different question. An out-of-court statement offered for the truth of the matter asserted runs into FRE 802 unless an exception applies. The business records exception under FRE 803(6) is the relevant one here. For blockchain timestamps, building both arguments before a dispute starts is worth the work.

What FRE 803(6) Actually Requires

The exception covers records of regularly conducted activity. For a record to qualify:

The record was made at or near the time of the event it describes
By or from someone with knowledge of that event
In the course of a regularly conducted business activity
Making the record was a regular practice of that activity
A records custodian can testify to those elements, or the record comes with certification under FRE 902(11) or 902(13)
The opponent can't show the source or circumstances indicate untrustworthiness

The timing element is the one that trips people up. "At or near the time" means contemporaneous with the event. A blockchain anchor created weeks after an inspection, or after demand letters are exchanged, loses the 803(6) argument. The exception is built for routine records, not retroactive documentation.

Two Records, Two Separate Analyses

A blockchain evidence situation involves two distinct records. Conflating them creates gaps.

The first is the blockchain entry itself. A Polygon transaction or Bitcoin merkle proof is a machine-generated output of a cryptographic process. Courts analyze that under FRE 901(b)(9) as evidence from a reliable process or system. It's a computational output, not a human assertion about what happened.

The second is the proof certificate or receipt that documents the connection between a specific file hash and a specific on-chain transaction. That certificate is created at the time of anchoring, typically by an automated system, and delivered to the party as a record of what was anchored and when. Opposing counsel who frames that certificate as hearsay isn't wrong to try. Authentication alone doesn't close that objection. The blockchain ledger entry and the certificate are separate records, and each has its own admissibility path.

The Stronger Argument Runs Through the Party's Own Records

I think the cleanest 803(6) path isn't built on the service provider's documentation. It's built on the party's own.

If a claims team, forensic firm, or law department adopts a written protocol to anchor evidence files at intake, the anchoring record becomes part of that organization's business records. Created at intake. By the person who received the file. In the regular course of evidence handling. As part of documented standard procedure. That's the structure 803(6) was designed to cover.

The foundation then runs through the organization's records custodian, not the blockchain service. And if the certification path under FRE 902(11) is available, the custodian doesn't need to testify. A written certification covering the four 803(6) elements handles it.

This is the argument that holds up in practice. The service provider's documentation structure isn't what makes it work. The party's own workflow is.

Layering the Rules

Each rule answers a different objection.

FRE 902(13) provides self-authentication for machine-generated records through written certification. That's the answer to "is the blockchain record authentic?" without live testimony. FRE 803(6) covers the hearsay objection to the proof certificate, when the anchoring was part of regular business practice. Process reliability under FRE 901(b)(9) supports both.

Dual-chain anchoring adds to the 901(b)(9) argument specifically. ProofLedger anchors to both Polygon and Bitcoin. Two independent blockchains, separate consensus mechanisms, both recording the same file hash at the same moment. Process reliability through redundancy is harder to attack than a single-source timestamp.

No single rule does everything. The practitioners who think through all three before a dispute are the ones who aren't scrambling during the opening hour of a hearing to explain why they skipped a step.

What This Means Monday Morning

If your organization anchors evidence files as part of standard practice, document the practice explicitly. A written policy covering who anchors, when, using what process, and where the records are kept gives the 803(6) foundation something to stand on. Undocumented workflows and inconsistent practice create gaps opposing counsel will use.

Anchor at the earliest point in the workflow. First inspection, first receipt, first capture. The business records timing element requires contemporaneous records. Anchoring after a dispute is anticipated changes the analysis entirely.

For the authentication layer, prepare the FRE 902(13) certification before you need it. A written certification describing the anchoring process, the cryptographic method, and the chain of custody for the records is more useful built in advance than assembled under deadline.

The hearsay objection to blockchain evidence isn't common yet. But the argument is available, and opposing counsel is learning. Building the 803(6) foundation now, while it's a procedural choice rather than a gap to patch, is the right time to do it.

Pre-Loss Documentation: Why File Timestamps Don't Prove Timing (And What Does)

Craig Solomon — Fri, 14 Aug 2026 13:00:00 +0000

A claims examiner is reviewing a disputed commercial property loss. The insured has submitted a folder of pre-loss photos. Good condition. No visible damage. Timestamps on the files read six months before the reported loss date.

File timestamps can be reset in under a minute. Cloud backups prove when a file was uploaded, not when it was shot. Nothing in that folder establishes provenance beyond reasonable doubt.

ProofLedger solves exactly that problem. Before the loss, when the policyholder anchors a photo or inspection report, a SHA-256 hash of that file is written to two blockchains: Polygon for instant confirmation and Bitcoin for proof-of-work immutability. The original file never leaves the device. What gets anchored is a cryptographic fingerprint, verifiable by anyone with the hash.

The documentation practice is straightforward. A commercial property owner anchors photos and inspection reports after each site visit through ProofLedger. Each anchor creates a timestamped record on Polygon within seconds and queues for the daily Bitcoin batch with a merkle proof tying it to that day's block. The property owner receives a certificate they can store with their policy documents.

When a claim comes in, the carrier's examiner doesn't have to take the insured's word for when the photos were taken. They verify the Bitcoin transaction independently. The timestamp on-chain predates the loss. The SHA-256 hash matches the file in the submission. That's a chain of custody built on temporal verification that no metadata manipulation can replicate.

Under FRE 901(b)(9), a blockchain record can be authenticated as the output of a process or system that produces an accurate result. Authentication still requires foundation, typically a technical declaration explaining how the anchoring process works. It's not self-authenticating under that rule. FRE 902(13) and 902(14) are the self-authentication provisions, applying to machine-generated records authenticated by written certification without live testimony.

For most insurance disputes, the practical question isn't litigation admissibility. It's whether the documentation survives a provenance challenge at the coverage review stage. Pre-loss anchoring shifts that burden. The insured isn't asking the carrier to trust a timestamp. The insured is pointing to a public ledger the carrier can verify independently.

One distinction that matters: a blockchain-anchored timestamp proves the file existed at a specific point in time. It doesn't prove ownership, identity, or the accuracy of what's depicted. The anchor is temporal verification, not a statement of truth about the underlying content. Carriers should evaluate it as one layer of documentation, alongside inspection records, purchase receipts, and policy history.

That's the point of neutral temporal authority. The ledger isn't vouching for the insured. It's establishing a fixed reference point that neither side can move.

Anchor before the loss, not after. Risk documentation, not claim documentation.

Watch-Folder Anchoring in Node.js: chokidar, Queues, and Rate-Limit Backoff

Craig Solomon — Thu, 13 Aug 2026 13:00:01 +0000

A file lands in an intake folder. You want a hash anchored to the blockchain the moment it arrives. Not batched overnight. Not manually triggered. Just: file detected, hashed, proof committed. While the file stays exactly where it is.

Here's how to build that service in Node.js. By the end you'll have a watcher that detects new files, streams them through SHA-256, queues API calls to stay under rate limits, and retries intelligently when limits are hit.

Why chokidar, and Why awaitWriteFinish Matters

Node's built-in fs.watch has platform inconsistencies and fires events before a file finishes writing. chokidar fixes both.

npm install chokidar

The critical option is awaitWriteFinish. Without it, a large upload triggers the add event while the file is still coming in. You hash an incomplete file. The anchor is wrong. Downstream verification fails.

import chokidar from 'chokidar';

const watcher = chokidar.watch('./intake', {
  persistent: true,
  ignoreInitial: false,
  awaitWriteFinish: {
    stabilityThreshold: 2000,  // ms of size stability before firing
    pollInterval: 200,
  },
});

watcher.on('add', (filePath) => {
  console.log(`Detected: ${filePath}`);
});

watcher.on('error', (err) => console.error('Watcher error:', err));

ignoreInitial: false means files already sitting in the folder when the service starts will be processed too. For a claims-intake pipeline, that's usually what you want. Startup should pick up anything that arrived while the service was down.

Streaming SHA-256 with Node's Built-In crypto

Don't load the whole file into memory. Stream it:

import { createHash } from 'crypto';
import { createReadStream } from 'fs';

async function sha256(filePath) {
  return new Promise((resolve, reject) => {
    const hash = createHash('sha256');
    const stream = createReadStream(filePath);
    stream.on('data', (chunk) => hash.update(chunk));
    stream.on('end', () => resolve(hash.digest('hex')));
    stream.on('error', reject);
  });
}

Output is always 64 hex characters. A 4KB text file and a 2GB video go through the same function. The hash doesn't care about file type or size.

A Queue for Backpressure

If 40 files land at once, a field inspector uploads a full photo set, you don't want 40 simultaneous API calls. Rate limits kick in immediately and cleanup gets messy.

A concurrency-limited queue handles this without extra dependencies:

class Queue {
  constructor(concurrency = 3) {
    this.concurrency = concurrency;
    this.running = 0;
    this.pending = [];
  }

  add(task) {
    return new Promise((resolve, reject) => {
      this.pending.push({ task, resolve, reject });
      this.drain();
    });
  }

  drain() {
    while (this.running < this.concurrency && this.pending.length > 0) {
      const { task, resolve, reject } = this.pending.shift();
      this.running++;
      Promise.resolve()
        .then(() => task())
        .then(resolve, reject)
        .finally(() => {
          this.running--;
          this.drain();
        });
    }
  }
}

const queue = new Queue(3);

Three concurrent calls is a reasonable default. The drain() method refills slots as tasks complete, so the queue drains at whatever pace the API allows.

Calling the Anchoring API

ProofLedger's v1 endpoint takes a SHA-256 hex string and an optional filename. On success it returns a proof record including a hosted certificate URL. On a duplicate submission it returns 409 with a duplicate_of field. The ID of the first anchor for this hash.

import path from 'path';

const ANCHOR_ENDPOINT = 'https://proofledger.io/api/v1/proof';
const API_KEY = process.env.ANCHOR_API_KEY;

async function anchor(filePath) {
  const digest = await sha256(filePath);
  const filename = path.basename(filePath);

  const res = await fetch(ANCHOR_ENDPOINT, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ sha256: digest, filename }),
  });

  if (res.status === 409) {
    const body = await res.json();
    console.log(`Already anchored: ${filename} (original: ${body.duplicate_of})`);
    return { duplicate: true, original: body.duplicate_of };
  }

  if (!res.ok) {
    const err = new Error(`API error: ${res.status}`);
    err.status = res.status;
    if (res.status === 429) {
      err.retryAfter = res.headers.get('Retry-After') || '5';
    }
    throw err;
  }

  const proof = await res.json();
  console.log(`Anchored: ${filename}`);
  console.log(`  Proof ID: ${proof.id}`);
  console.log(`  Certificate: ${proof.certificate_url}`);
  return proof;
}

certificate_url is a hosted proof page. Readable by anyone, no authentication required. When a dispute comes up later, that URL is what you share.

Native fetch is available in Node 18+. For Node 16, install node-fetch and the import is the same.

Retry Logic: Separating Retriable Errors from Fatal Ones

Not all errors should retry. A 400 means malformed input. Retrying won't fix it. A 401 or 403 means your credentials are wrong or your plan doesn't include API access. Those are not transient.

A 429 is different. Wait for the Retry-After header, then continue.

async function anchorWithRetry(filePath, maxAttempts = 5) {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await anchor(filePath);
    } catch (err) {
      const status = err.status;

      if (status === 400 || status === 401 || status === 403) {
        console.error(`Non-retryable error ${status}: ${path.basename(filePath)}`);
        throw err;
      }

      if (status === 429) {
        const waitSec = parseInt(err.retryAfter || '5', 10);
        console.warn(`Rate limited. Waiting ${waitSec}s (attempt ${attempt}/${maxAttempts})`);
        await sleep(waitSec * 1000);
        continue;
      }

      // Network errors, 5xx — exponential backoff
      const backoff = Math.min(1000 * 2 ** attempt, 30000);
      console.warn(`Attempt ${attempt} failed: ${err.message}. Retry in ${backoff}ms`);
      await sleep(backoff);
    }
  }

  throw new Error(`All ${maxAttempts} attempts failed: ${path.basename(filePath)}`);
}

function sleep(ms) {
  return new Promise((r) => setTimeout(r, ms));
}

Capping backoff at 30 seconds keeps recovery reasonable without hammering the API during an outage.

Wiring It Together

import chokidar from 'chokidar';
import { createHash } from 'crypto';
import { createReadStream } from 'fs';
import path from 'path';

const INTAKE_DIR = process.env.INTAKE_DIR || './intake';
const API_KEY = process.env.ANCHOR_API_KEY;

if (!API_KEY) {
  console.error('ANCHOR_API_KEY is not set');
  process.exit(1);
}

const queue = new Queue(3);

const watcher = chokidar.watch(INTAKE_DIR, {
  persistent: true,
  ignoreInitial: false,
  awaitWriteFinish: {
    stabilityThreshold: 2000,
    pollInterval: 200,
  },
});

watcher.on('add', (filePath) => {
  queue
    .add(() => anchorWithRetry(filePath))
    .catch((err) => {
      console.error(`Final failure for ${path.basename(filePath)}: ${err.message}`);
    });
});

watcher.on('error', (err) => console.error('Watcher error:', err));

console.log(`Watching ${INTAKE_DIR} for incoming files...`);

Run it:

ANCHOR_API_KEY=sk_YOUR_KEY_HERE node service.mjs

Drop a file into ./intake/. It gets detected, hashed, and anchored. Duplicates are logged and skipped. Rate limits are respected. The certificate URL hits stdout for every successful anchor.

What to Add Before Production

The service above handles the core flow. A few patterns worth layering on:

SQLite state tracking. If the service restarts mid-batch, in-flight work is lost. A single-table SQLite database, file path, SHA-256 digest, proof ID, status, lets you skip already-anchored files on startup. Check before calling anchor().

Startup sweep. ignoreInitial: false already replays existing files. Pair it with the database check and the service self-heals: files that arrived while it was down get anchored on next start, files already anchored get skipped.

JSON logs. In production, emit structured log objects with filePath, digest, proofId, anchoredAt, and durationMs. Easier to query later when you need to find a specific file's proof record.

The core service is around 80 lines. Enough to drop in front of a claims-intake upload folder, a document export directory, or any pipeline where files arrive asynchronously and timing matters.

For offline verification against a proof JSON file, the verify-proof PyPI package handles it without network calls: github.com/Fulcrum-Enterprises/verify-proof

What does your file-intake setup look like? Curious whether people are handling backpressure with a library like p-queue or rolling their own.

How Forensic Consultants Create Verifiable Digital Evidence Records

Craig Solomon — Wed, 12 Aug 2026 13:00:05 +0000

A forensic consultant's verifiable record has to answer two questions: did this file change, and when did it exist? SHA-256 hashing at acquisition answers the first. Chain of custody documentation, methodology reports, and blockchain anchoring address the second.

Hash Verification: The Technical Foundation

SHA-256 is the current standard for digital evidence integrity. It's a one-way function: run any file through the algorithm and you get a fixed-length string. Change a single byte and the hash changes completely. A year later, that same unmodified file produces the same string.

Write-blockers handle the acquisition side. Hardware or software write-blockers prevent any data from being written to original storage media during imaging. A forensic consultant creates a bit-for-bit copy, hashes both the original and the copy, and records that both hashes match. The original is preserved exactly as found.

Tools like FTK Imager, EnCase, and Autopsy automate this workflow. They log acquisition time, hardware identifiers, hash values, and tool version. That log becomes part of the case file.

Chain of Custody: The Procedural Layer

Technical integrity doesn't stand alone. Every transfer of evidence gets documented: who received it, from whom, at what time, under what conditions. Evidence storage has to be secure and logged. Any analysis performed on the evidence gets recorded with the methodology, the tools used, and the findings.

This procedural record exists separately from hash verification. Both matter for admissibility. The hash proves the file wasn't modified. The custody log proves the file was handled properly.

Forensic Reports and Methodology Documentation

Forensic conclusions have to survive challenge. That means explaining the tools used (including version numbers), the methodology followed, the findings, and how those findings were reached.

Under Daubert, courts evaluate whether expert methodology is scientifically valid and reliably applied. A forensic expert who can't explain the acquisition process, or who used improperly validated tools, is vulnerable to a methodology challenge before the findings ever reach the jury.

Courts authenticate digital evidence under FRE 901(b)(9), which allows authentication of evidence produced by a process or system that generates an accurate result. This requires laying a foundation: typically, expert testimony explaining the methodology, the tools, and why the output is reliable. That's not self-authentication. Self-authentication for machine-generated records comes through FRE 902(13) and FRE 902(14), which allow written certification in place of live testimony.

File System Timestamps: What They Don't Prove

EXIF data in a photo might show a creation date. File system metadata shows access and modification times. Both are useful starting points. Neither is authoritative.

File system timestamps can be changed, and EXIF data can be stripped or edited during transfer. Moving a file from one device to another often updates the modification timestamp. A challenge that targets metadata will raise doubt about any timestamp that lives inside the file or on the same storage medium as the file.

Forensic consultants document these limitations in their reports. A hash proves the file's content is unchanged. It doesn't independently establish when that content was created.

Blockchain Anchoring: An Independent Temporal Record

Anchoring the hash to a public blockchain provides a timestamp that's external to the file and to the consultant's own infrastructure.

The mechanism: compute the SHA-256 hash of a file, submit it to a blockchain network, and receive a transaction record with a block timestamp. The blockchain can't be retroactively altered. Anyone with the file and the transaction record can independently verify that a file with that exact hash existed at that block timestamp.

Options exist at different usability levels. OpenTimestamps offers free Bitcoin anchoring and its proof is cryptographically sound. The tradeoff is usability: the output requires technical tools to verify, and there's no hosted verification page that a judge, opposing counsel, or claims examiner can read without specialized knowledge.

ProofLedger anchors to both Polygon (instant confirmation) and Bitcoin (daily batch with Merkle proofs). The file stays with the consultant. Only the hash goes on-chain. Each anchor produces a public verification URL and a certificate usable by non-technical parties, which matters when the end audience is litigation counsel or a claims department rather than a technical peer. Professional and Business plans include a REST API for workflows that need automated anchoring at acquisition.

A blockchain anchor doesn't make evidence automatically admissible. Under FRE 901(b)(9), the proponent still needs to explain the process: what was hashed, when, how the transaction was recorded, and how the blockchain timestamp can be read. What the anchor provides is a timestamp from an independent system with no incentive to backdate.

Combining the Layers

A forensic consultant building a complete verifiable record works with several layers together:

Write-blocked acquisition with logged hash values
A custody log documenting every transfer and handler
Detailed methodology documentation for expert reports
Blockchain anchoring of file hashes at the time of acquisition

Each layer addresses a different vulnerability. The write-blocker and hash protect against undetected modification. The custody log addresses handling and access questions. The methodology documentation supports Daubert review. The blockchain anchor supplies a timestamp that doesn't depend on the file's own metadata.

For disputed matters, the strength of the record depends on how early in the process these steps were applied. An anchor taken the day evidence is acquired is harder to challenge than one taken weeks later.

Practical Considerations for Forensic Consultants

Not every court treats blockchain timestamps identically. A forensic consultant should be prepared to explain the process plainly: what a blockchain is, why the timestamp is reliable, and how the transaction can be independently verified. Some courts will require live testimony under FRE 901(b)(9); in others, written certification under FRE 902(13) or FRE 902(14) may be sufficient to authenticate without calling a witness.

Practices adequate for civil matters may not survive criminal discovery. Chain of custody standards, methodology requirements, and admissibility thresholds are higher in criminal proceedings. Consultants who work across both contexts should apply the more stringent standard throughout.

The tools keep improving. The underlying principle doesn't: verifiable digital evidence requires both technical integrity and procedural rigor. The hash proves nothing changed. The custody log proves the right people handled it correctly. The anchor proves it existed when you say it did.

For consultants who want dual-chain anchoring with a public verification page non-technical parties can actually read, proofledger.io is worth exploring. Polygon anchoring is free on every plan.

Idempotent File Anchoring: SHA-256 Dedup Before You Call the API

Craig Solomon — Mon, 10 Aug 2026 13:00:04 +0000

Building any intake pipeline, you'll hit the same problem eventually. Files arrive from multiple sources. Some you've already processed: re-uploads of the same document, copies from two different intake paths, items your worker errored on last run and re-queued. Call the anchoring API blindly and you end up with multiple proof records for identical bytes.

The ProofLedger v1 API returns a duplicate_of field in its 201 response when it detects a hash it's already seen. But that's only half the solution. A network round-trip costs time and quota even when it comes back as a duplicate. Hash-based local deduplication is the other half.

Here's how to build a worker that handles both layers.

Hash Locally First

The core pattern: compute the SHA-256 digest before making any API call. If you've seen this digest before, skip it. If you haven't, submit it.

Two things you need: a persistent record of digests you've already anchored, and chunked hashing so large files don't blow memory.

import hashlib
import json
from pathlib import Path

SEEN_DB = Path("anchored_hashes.json")

def load_seen():
    if SEEN_DB.exists():
        with open(SEEN_DB) as f:
            return json.load(f)
    return {}

def save_seen(db):
    with open(SEEN_DB, "w") as f:
        json.dump(db, f, indent=2)

def hash_file(path: str) -> str:
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for chunk in iter(lambda: f.read(65536), b""):
            h.update(chunk)
    return h.hexdigest()

65536-byte chunks keep memory flat regardless of file size. The load_seen / save_seen pair gives you a persistent record that survives worker restarts.

Submitting and Reading `duplicate_of`

When duplicate_of appears in the API response, its value is the proof ID of the earliest anchor for that hash. That's the canonical ID. The new proof ID from this call is irrelevant.

import requests

API_URL = "https://proofledger.io/api/v1/proof"
API_KEY = "sk_YOUR_KEY_HERE"

def anchor_file(file_path: str, seen: dict) -> dict:
    digest = hash_file(file_path)

    if digest in seen:
        return {
            "status": "skipped",
            "reason": "already_anchored",
            "digest": digest,
            "original_proof_id": seen[digest]["proof_id"],
        }

    response = requests.post(
        API_URL,
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={
            "sha256": digest,
            "filename": Path(file_path).name,
            "bitcoin_requested": True,
        },
        timeout=30,
    )

    if response.status_code == 201:
        data = response.json()

        if data.get("duplicate_of"):
            canonical_id = data["duplicate_of"]
            seen[digest] = {"proof_id": canonical_id}
            save_seen(seen)
            return {
                "status": "duplicate",
                "canonical_proof_id": canonical_id,
                "digest": digest,
            }

        proof_id = data["id"]
        seen[digest] = {"proof_id": proof_id}
        save_seen(seen)
        return {"status": "anchored", "digest": digest, "proof_id": proof_id}

    if response.status_code == 429:
        retry_after = response.headers.get("Retry-After", "unknown")
        raise RuntimeError(f"Rate limited. Retry-After: {retry_after}")

    if response.status_code in (400, 401, 403):
        raise RuntimeError(f"Non-retryable {response.status_code}: {response.text}")

    raise RuntimeError(f"Unexpected status {response.status_code}")

The 429 path raises instead of silently skipping. That's by design. Backoff logic belongs at the call site, where you can log which file triggered the limit and decide whether to wait or drain a queue before retrying.

One Hash, One Record

When duplicate_of comes back, the earliest anchor is already established. That's your temporal claim. Any later anchor for the same bytes doesn't strengthen anything. In a legal or claims context, it creates confusion about which proof is authoritative.

The rule is simple: one hash, one canonical proof ID. Store the duplicate_of value and discard the rest.

import os

def process_directory(directory: str):
    seen = load_seen()
    counts = {"anchored": 0, "skipped": 0, "duplicate": 0, "errors": 0}

    for root, _, files in os.walk(directory):
        for filename in files:
            file_path = os.path.join(root, filename)
            try:
                result = anchor_file(file_path, seen)
                status = result["status"]
                counts[status] += 1
                short_hash = result["digest"][:12]
                print(f"{status.upper()}: {filename} ({short_hash}...)")
            except RuntimeError as e:
                counts["errors"] += 1
                print(f"ERROR: {filename}: {e}")

    print(f"\nDone. {counts}")

Point this at a directory with a mix of new and previously processed files. The output breaks down new anchors, local hits, API-level duplicates, and errors. Everything accounted for before you report results upstream.

Closing the Crash Window with SQLite

One failure mode to think through: your worker anchors a file, gets a 201 back, then crashes before writing to anchored_hashes.json. On the next run, it re-hashes the same file, hits the API again, and receives duplicate_of. No data loss; one wasted API call.

For small batches, that's acceptable. For anything serious, swap the JSON file for SQLite with a unique constraint on the digest column.

import sqlite3

def init_db(db_path="anchored.db"):
    conn = sqlite3.connect(db_path)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS anchors (
            digest TEXT PRIMARY KEY,
            proof_id TEXT NOT NULL,
            anchored_at TEXT
        )
    """)
    conn.commit()
    return conn

def is_seen(conn, digest):
    row = conn.execute(
        "SELECT proof_id FROM anchors WHERE digest = ?", (digest,)
    ).fetchone()
    return row[0] if row else None

def record_anchor(conn, digest, proof_id, anchored_at=None):
    conn.execute(
        "INSERT OR IGNORE INTO anchors (digest, proof_id, anchored_at) VALUES (?, ?, ?)",
        (digest, proof_id, anchored_at),
    )
    conn.commit()

INSERT OR IGNORE handles concurrent workers cleanly. The first process to insert wins. The second sees the row already there and skips. If it got far enough to call the API, it receives duplicate_of and lands on the same canonical ID anyway.

Write the row immediately after getting the 201. Don't batch the writes. A crash between anchoring and writing costs one API call per file on retry. A crash between a full batched anchor run and a batched write costs the whole batch.

What to Build Next

Wire a rate-limit backoff loop around the anchor_file call. On 429, read Retry-After from the response header and sleep for exactly that many seconds before retrying. Don't spin; the header tells you what the server needs.

If intake volume outpaces synchronous directory walking, feed file paths into a queue and run workers in parallel. The dedup layer here is already concurrency-safe via INSERT OR IGNORE.

Third-party verification doesn't need your API key. The public GET /api/v1/verify?hash=<sha256> endpoint is unauthenticated, rate-limited to 120 requests per hour per IP, and returns the full proof record including blockchain explorer URLs. An auditor or opposing counsel can verify the anchor themselves without touching your credentials.

For offline verification once you've got a proof record, the verify-proof package on PyPI checks the hash and walks the Merkle path locally, no network call required.

What about intake systems that already anchored duplicates before you added this dedup layer? The duplicate_of field handles that retroactively too. Feed your archive through the worker above, collect the canonical IDs, and let the others go. The earliest anchor is still on-chain, unchanged.

Have you built dedup into a file ingestion pipeline before? What did you end up using for the seen-hash store?

How Businesses Can Document Asset Conditions Before an Insurance Loss

Craig Solomon — Fri, 07 Aug 2026 13:00:01 +0000

Businesses have four main options for documenting asset conditions before a loss: physical inspection reports, notarized records, cloud storage with metadata logging, and blockchain-anchored timestamps. A solid pre-loss documentation strategy typically uses more than one, because each creates different types of evidence with different legal weight.

A timestamp proves when a file existed. An inspection report establishes what a professional observed. Understanding the difference determines which combination fits your risk profile.

Physical Inspection Reports and Condition Records

A formal inspection report, signed by a licensed professional or third-party inspector, is the foundation of most pre-loss documentation programs. For commercial real estate, this means condition surveys before tenants move in and at each lease renewal. For equipment-heavy businesses, it means periodic asset assessments with photographs, serial numbers, and condition ratings.

The strength is credibility. A signed report from a qualified professional carries obvious weight in a dispute. The limitation is cost and frequency. Most organizations can't commission a new inspection every time conditions change.

Photographs taken during an inspection help, but photo timestamps have a problem. EXIF metadata can be altered. A photo of clean equipment taken after a loss can be backdated to appear pre-loss. The inspection report anchors those photos in time through the professional's signature, but the digital files themselves don't independently prove when they existed.

Notarized Documentation

A notary public certifies identity and that a document was presented in their presence at a specific time. For asset condition records, notarization adds a layer of third-party confirmation that's harder to dispute than a filename or EXIF date.

The limitation is scope. Notarization documents the paper, not the content of the files attached to it. Whether the photographs accurately represent the asset's condition on that date still depends on the integrity of the underlying files. Notarized records work best as a supplemental layer for high-value assets where formal documentation justifies the extra step.

Cloud Storage and File Metadata

Storing pre-loss photos and inspection records in cloud storage creates a version history. Services that log file creation and modification dates can show when a file first appeared in the system, and those logs may be producible as business records under FRE 803(6) in litigation.

But cloud timestamps have a gap. What the log records is when the file arrived in the system, not when the content was created. If photos are uploaded days after they were taken, the cloud log reflects the upload date. If EXIF metadata was altered before upload, the cloud timestamp doesn't catch that.

Cloud storage is a useful organizational layer. It's not a standalone proof of when a file was originally created.

Blockchain-Anchored Timestamps as Pre-Loss Evidence

A blockchain anchor works differently from the methods above. It takes a cryptographic hash (SHA-256) of a file and records that hash to an immutable public ledger at a specific time. The original file stays on your device. Only the hash goes on-chain.

What an anchor proves: a file producing that exact hash existed at the time of anchoring. What it doesn't prove: the depicted conditions match reality, or that the evidence will be admissible without additional foundation work.

Courts evaluating blockchain-anchored evidence typically look to FRE 901(b)(9), which allows authentication of evidence produced by a reliable process or system. Establishing that foundation requires a qualified witness or certification explaining how the anchoring process works. Under FRE 902(13), a written certification from a qualified person can satisfy authentication of machine-generated records without live testimony, and FRE 902(14) extends that self-authentication framework to data copied from electronic files.

For pre-loss documentation, the practical value is in timing. Anchor inspection photos and condition reports the day they're created. If a loss occurs months or years later, the blockchain record proves those specific files existed before the loss date, independent of file metadata and immune to the backdating that makes EXIF timestamps attackable.

ProofLedger anchors SHA-256 hashes to both Polygon (confirming within seconds) and Bitcoin (via a daily batch with Merkle proofs). Polygon anchoring is free and unlimited on every plan. Bitcoin anchoring is a paid escalation for matters where proof-of-work immutability adds weight. Every anchor generates a public verification URL that opposing counsel, auditors, or courts can check directly.

Combining Layers for Stronger Pre-Loss Documentation

The most defensible pre-loss documentation isn't any single method. It's combining them.

A signed inspection report, photographs taken during inspection, and those same photographs anchored to a blockchain the same day creates a chain that's difficult to attack. The inspection report establishes credibility. The anchor proves the files existed before any loss date. And the original files, unchanged since creation, produce the same hash on every verification.

This layered approach also provides options as a dispute evolves. Some matters settle before formal litigation; a notarized condition report may be sufficient. Others proceed to discovery; blockchain timestamps paired with FRE 902(13) certification can support authentication without requiring the original inspector to testify again.

One thing doesn't work: anchoring after a loss and claiming pre-loss documentation. The timestamp proves when the file was anchored. If that time follows the loss date, the proof establishes nothing useful.

What to Document, and When

Different business types have different exposure patterns, but the underlying logic is the same: anchor before anything looks like a potential claim.

Commercial real estate: Annual condition surveys, photographs at each tenancy change, anchored the day they're taken. Roof, HVAC, plumbing, and structural elements are where disputes concentrate.

Equipment-heavy operations: Anchor condition reports and operational photos at each maintenance interval. When equipment is new, anchor the purchase records and initial condition photographs on the same day.

Construction and contracting: Anchor site condition photos before work begins and at each phase completion. Documenting pre-existing conditions your crew didn't create matters most when a dispute arises years later.

High-value property portfolios: Anchor before major weather events when possible. Documentation predating a storm or flood by months carries different weight than documentation created after a claim is anticipated.

The Timing Is the Point

An anchor from two years before a loss is stronger evidence than one from two weeks before. Documentation from the day of a routine inspection is more defensible than documentation created when a claim is already anticipated.

The discipline is anchoring as part of the documentation workflow itself, not in response to risk. Anchor before the loss, not after. Risk documentation, not claim documentation.

If you want to start with blockchain anchoring, proofledger.io offers free unlimited Polygon timestamping on every tier. Anchor your next set of condition photos when you take them, and you'll have a verifiable pre-loss record that predates any future dispute by exactly as long as you've been documenting.

Using SHA-256 as an Idempotency Key in a File Anchoring Pipeline

Craig Solomon — Thu, 06 Aug 2026 13:00:00 +0000

You run an ingestion job Monday. The same files get queued again Wednesday because a failed upload triggered a retry. Or two different teams independently drop the same document into your pipeline. SHA-256 doesn't care which scenario it is. The same bytes always produce the same hash. That hash is your natural idempotency key.

This article builds a Python worker that uses that property to deduplicate anchoring requests before they hit the API. It also handles the case where the API already knows about a hash your local state doesn't.

Two Dedup Layers, Not One

There are two places to catch duplicates.

Layer 1: local state. A SQLite database tracking every hash you've successfully anchored. Before calling the API, check whether the hash is already in your state file. If it is, skip the call entirely. Zero API usage, zero quota consumption.

Layer 2: the API's duplicate_of field. When you submit a hash that's already anchored, the API returns the new proof record plus a duplicate_of field pointing to the original proof ID. This catches what local state misses: two workers running in parallel, a state file that was deleted and rebuilt, or a client who anchored the same file independently before you did.

Both layers matter. Local state prevents wasted API calls. The API check is the safety net for everything else.

The State Layer

SQLite handles this well. JSON files don't survive concurrent writes safely.

import sqlite3
from pathlib import Path

DB_PATH = Path("anchor_state.db")

def init_db(conn: sqlite3.Connection) -> None:
    conn.execute("""
        CREATE TABLE IF NOT EXISTS anchored (
            sha256      TEXT PRIMARY KEY,
            proof_id    TEXT NOT NULL,
            anchored_at TEXT
        )
    """)
    conn.commit()

def already_anchored(conn: sqlite3.Connection, sha256: str) -> dict | None:
    row = conn.execute(
        "SELECT proof_id, anchored_at FROM anchored WHERE sha256 = ?",
        (sha256,)
    ).fetchone()
    if row:
        return {"proof_id": row[0], "anchored_at": row[1]}
    return None

def record_anchor(
    conn: sqlite3.Connection,
    sha256: str,
    proof_id: str,
    anchored_at: str,
) -> None:
    conn.execute(
        "INSERT OR IGNORE INTO anchored (sha256, proof_id, anchored_at) VALUES (?, ?, ?)",
        (sha256, proof_id, anchored_at),
    )
    conn.commit()

INSERT OR IGNORE is the key detail. If two threads race to insert the same sha256, one wins and the other silently discards. No exception, no duplicate row, no corrupted state.

The already_anchored function runs before every API call. If it returns a result, the worker logs the existing proof ID and moves on.

Hashing and the API Call

Large files need chunked reading. Loading gigabytes into memory at once fails in production.

import hashlib
import requests
import time

def hash_file(filepath: str) -> str:
    h = hashlib.sha256()
    with open(filepath, "rb") as f:
        for chunk in iter(lambda: f.read(65536), b""):
            h.update(chunk)
    return h.hexdigest()

def call_anchor_api(sha256: str, filename: str, api_key: str) -> dict:
    while True:
        resp = requests.post(
            "https://proofledger.io/api/v1/proof",
            headers={"Authorization": f"Bearer {api_key}"},
            json={"sha256": sha256, "filename": filename},
            timeout=30,
        )
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", "60"))
            print(f"Rate limited. Waiting {retry_after}s.")
            time.sleep(retry_after)
            continue
        resp.raise_for_status()
        return resp.json()

The 429 retry loop reads the Retry-After header and waits. Don't blindly retry on 400, 401, or 403. Those are caller errors: bad hash format, invalid key, or wrong plan tier. raise_for_status() converts them to exceptions. The caller decides what to do with them.

Handling `duplicate_of`

from pathlib import Path

def process_file(
    filepath: str,
    api_key: str,
    conn: sqlite3.Connection,
) -> dict:
    sha256 = hash_file(filepath)
    filename = Path(filepath).name

    # Layer 1: local check
    existing = already_anchored(conn, sha256)
    if existing:
        return {
            "file": filename,
            "sha256": sha256,
            "status": "skipped",
            "proof_id": existing["proof_id"],
        }

    # Layer 2: API call
    try:
        result = call_anchor_api(sha256, filename, api_key)
    except requests.exceptions.HTTPError as e:
        return {"file": filename, "sha256": sha256, "status": "error", "error": str(e)}

    proof_id = result.get("id", "")
    anchored_at = result.get("created_at", "")
    duplicate_of = result.get("duplicate_of")

    if duplicate_of:
        # The canonical anchor predates this one. Record the original.
        record_anchor(conn, sha256, duplicate_of, anchored_at)
        return {
            "file": filename,
            "sha256": sha256,
            "status": "duplicate",
            "canonical_proof_id": duplicate_of,
        }

    record_anchor(conn, sha256, proof_id, anchored_at)
    return {
        "file": filename,
        "sha256": sha256,
        "status": "anchored",
        "proof_id": proof_id,
    }

When duplicate_of is present, store the original proof ID, not the new one. If someone later asks "what's the proof for this file?", the answer is the earliest anchor. That's the one with the timestamp that matters for a pre-loss documentation argument.

Wiring the Worker

import os
import sqlite3
from pathlib import Path

API_KEY = os.environ.get("PROOFLEDGER_API_KEY", "sk_YOUR_KEY_HERE")
INCOMING = Path("./incoming")

def run(directory: Path, api_key: str) -> None:
    conn = sqlite3.connect(str(DB_PATH))
    init_db(conn)

    files = [f for f in directory.iterdir() if f.is_file()]
    print(f"Processing {len(files)} files.")

    counts: dict[str, int] = {"anchored": 0, "skipped": 0, "duplicate": 0, "error": 0}

    for filepath in files:
        result = process_file(str(filepath), api_key, conn)
        status = result["status"]
        counts[status] = counts.get(status, 0) + 1
        ref = (
            result.get("proof_id")
            or result.get("canonical_proof_id")
            or result.get("error", "")
        )
        print(f"  [{status}] {result['file']} -> {ref}")

    conn.close()
    print(
        f"\nAnchored: {counts['anchored']}, Skipped: {counts['skipped']}, "
        f"Duplicate: {counts['duplicate']}, Errors: {counts['error']}"
    )

if __name__ == "__main__":
    run(INCOMING, API_KEY)

Run this against the same directory twice. The second run should show all files as skipped with zero API calls. That's the behavior you want.

Verifying a File After Anchoring

Once a file is anchored, the proof lives at https://proofledger.io/cert/<proof_id>. Verification doesn't need the API. The verify-proof package does it entirely offline:

from verify_proof import hash_file as vp_hash_file, verify_proof, load_proof

# proof.json downloaded from the certificate page or stored by your pipeline
proof = load_proof("evidence_photo_proof.json")
file_hash = vp_hash_file("evidence_photo.jpg")
result = verify_proof(file_hash, proof)

if result["verified"]:
    print(f"Verified on {result['blockchain']} at {result['anchored_at']}")
else:
    print(f"Not verified: {result['error']}")

No network connection required. Useful for forensic environments with restricted internet access, or for opposing counsel who wants to verify independently without hitting your infrastructure.

Note that verify_proof checks hash integrity and Merkle path structure. It does not make a live blockchain call to confirm the tx_id exists on-chain. For that, use the explorer_url from the proof record or GET /api/v1/verify?hash=<sha256> (public, no auth, 120 requests/hr per IP).

A Few Production Notes

Concurrent workers. SQLite serializes writes but allows concurrent reads. INSERT OR IGNORE handles the race correctly when two workers hash the same file at the same time. For high-volume pipelines with many parallel workers, move the state layer to Postgres. The queries above don't change, only the connection string does.

State file loss. If anchor_state.db gets deleted, the worker falls through to Layer 2. The API catches any hashes it's already seen and returns duplicate_of. You'll make more API calls than necessary on that first recovery run, but no data is lost and no incorrect anchors get created.

Monthly quota. The API call still happens in the duplicate_of case, and it still counts against your monthly proof quota. Local state is what prevents that consumption on repeated runs. Keep the state file around, and back it up alongside your proof records.

The underlying idea is that SHA-256 is a pure function: same input, same output, every time. No coordination protocol needed. No distributed lock. The hash is the key, and the key is stable across retries, restarts, and concurrent workers.

Source for the verify-proof package is at github.com/Fulcrum-Enterprises/verify-proof.

What are you using for state tracking in your file ingestion pipelines? SQLite, Postgres, Redis? Curious what other approaches people are running in production.

C2PA Content Credentials and the Chain-of-Custody Gap

Craig Solomon — Wed, 05 Aug 2026 13:00:00 +0000

Content Credentials are having a moment. Samsung Galaxy S25 and Google Pixel 10 sign media natively at the camera level. Adobe, Google, Meta, Microsoft, and OpenAI are all behind the standard. The EU AI Act Article 50 mandates machine-readable content marking by August 2, 2026, and C2PA is the compliance path the industry has converged on.

For insurance and legal professionals, this matters. A C2PA credential embedded in an image records who captured it, when, with what device, and what processing was applied. That provenance metadata travels with the file and can be verified independently.

But it has a limitation the claims and legal audience needs to understand.

The credential lives inside the file.

During a platform re-upload, a format conversion, or a routine file transfer, that metadata can be stripped. Not maliciously, necessarily. A workflow tool that doesn't preserve XMP metadata. A CMS that recompresses images on upload. A PDF conversion that drops sidecar data. The credential is gone, and the chain of custody has a gap, with no record it ever existed.

In a claims context, that gap is significant. If an insured submits property documentation through three different software tools between capture and submission, and one strips the C2PA data, you're reviewing an unverified file. The provenance that existed at the moment of capture no longer exists at the moment of review.

A blockchain anchor solves a different problem. ProofLedger computes a SHA-256 hash of the file at the moment of anchoring and records that fingerprint on Polygon (confirmed instantly) and Bitcoin (daily batch with merkle proof). The original files stay on the device. What gets recorded is a cryptographic commitment to the file's exact state at a specific point in time.

That record exists on a public ledger. No platform touches it. No file transfer strips it. No party to the dispute controls it. If the file changes at all after anchoring, the hash won't match, and the mismatch is itself evidence.

The strongest documentation chain uses both layers. C2PA says: here is where this file came from, how it was captured, and what was applied to it. A blockchain anchor says: this file existed, in this exact state, before this date. Together, they address different attack vectors. Neither substitutes for the other.

For court authentication, FRE 901(b)(9) covers evidence produced by a process that generates an accurate result. FRE 902(13) is the self-authentication standard for machine-generated records, allowing written certification without live witness testimony. Risk managers and outside counsel who understand these rules can design documentation workflows around them before a dispute, not in response to one.

C2PA compliance addresses the EU regulatory question. Blockchain anchoring addresses the chain-of-custody question. They're related, but they're not the same question.