DEV Community: Craig Solomon

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.

How Opposing Counsel Attacks Blockchain Timestamp Evidence (and What the Technical Record Shows)

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

Picture this: a plaintiff's attorney submits blockchain-anchored photographs as proof that property damage existed before a policy lapsed. Defense moves to exclude them at trial. Not because the photos are doctored. Because, they argue, the timestamp can't be authenticated.

That's where most blockchain-evidence disputes actually land. Not on the file's content. On whether the timestamp proves what it claims to prove.

Here are the four attacks that surface in discovery and at trial, and the technical record that answers each one.

1. "SHA-256 Can Be Reversed or Forged"

This surfaces most often in a Daubert motion. The argument: cryptographic hash functions are complex and potentially fallible. If the hash can be forged, the timestamp proves nothing.

The technical record: SHA-256 has no known collision vulnerabilities. NIST has certified it as a federal cryptographic standard for over two decades. A collision (two different files producing identical hashes) would require computational resources that don't exist at any practical scale. Under the Daubert framework from Daubert v. Merrell Dow Pharmaceuticals, Inc., 509 U.S. 579 (1993), and the FRE 702 reliability standard, the methodology has been tested, subjected to peer review, and its error rate is for practical purposes zero.

What to prepare: an expert declaration or FRE 902(13) written certification explaining SHA-256's preimage resistance and collision resistance properties. For the Daubert motion, cite NIST publications directly. The four Daubert factors (tested, peer-reviewed, known error rate, general acceptance) are all in your favor.

2. "Block Timestamps Are Unreliable"

This one has real substance. Bitcoin consensus doesn't require precise timestamps. Nodes accept blocks whose timestamps fall within roughly two hours of the network-adjusted time. A block timestamped at 3:00 PM could have been accepted within a window on either side of that.

Defense will point to this variance to argue the timestamp is too imprecise to establish whether evidence predated a specific event.

Two answers. First, block confirmation depth: a transaction buried under dozens of subsequent blocks is increasingly resistant to retroactive manipulation, because reorganizing deep blocks requires growing computational resources with each additional confirmation. Second, dual-chain verification. Polygon confirms in seconds using smart-contract precision. Bitcoin confirms daily in batched merkle trees with independent node consensus. Two chains operating under different consensus mechanisms both need to be compromised to fabricate a consistent timestamp. That's the FRE 901(b)(9) argument: independent redundancy creates a process that produces an accurate result even when either chain's timing carries variance.

I built the dual-chain architecture specifically because this objection is real. One chain with timing variance is attackable at a Daubert hearing. Two independent chains under different consensus models aren't. And acknowledging Bitcoin's timing window in your expert declaration is the stronger move. The Daubert inquiry rewards intellectual honesty. A declaration that explains the limitation and then explains why dual-chain confirmation answers it is more persuasive than one that pretends the limitation doesn't exist.

3. "You Can't Prove Who Anchored It"

Authentication of the file doesn't authenticate the anchor. Defense will argue that even if the hash is valid and the timestamp reliable, there's no proof the claiming party submitted the file at that time. Anyone could have anchored any hash to any block.

This is where FRE 902(13) does the most work. The rule, effective December 1, 2017, allows a written certification from a qualified person to self-authenticate records "generated by an electronic process or system that produces an accurate result." No live expert required. The certification establishes who submitted the hash, when, which chain received it, and what transaction ID resulted.

The certification should include the SHA-256 hash itself, so the opposing party can run an independent verification. Hash the original file. Compare it to the anchored hash on-chain. Confirm they match. SHA-256 is deterministic: same file, same hash, on any machine, with any tool. If they match, the files are identical. The opposing party doesn't need to trust the submitting party. They can verify against the public ledger independently.

That's the FRE 901(b)(9) process-reliability argument in its cleanest form. The question isn't whether the submitting party is credible. It's whether the process (SHA-256 hash, blockchain submission, public ledger recording, merkle proof inclusion) produces an accurate result. It does, and you can prove that with the record alone.

4. "The Record Is Hearsay"

A blockchain transaction is an out-of-court statement offered to prove the truth of the matter asserted: that a hash existed at a given time. That's facially hearsay.

Two routes through it.

FRE 803(6) covers business records made at or near the time of the event by someone with knowledge, kept in the regular course of a regularly conducted activity. A records custodian or FRE 902(11) written certification lays the foundation without live testimony.

FRE 902(13) handles machine-generated records directly. A record generated by a process or system that produces an accurate result is self-authenticating by written certification. No hearsay foundation required. No live witness. The certification is the foundation.

In practice, 902(13) is the cleaner route because it doesn't require establishing "regular course of business." The question under 902(13) is only whether the record was generated by a reliable process. Use 803(6) as a backup for courts that want the additional business-records foundation.

One thing worth noting: authentication under 901(b)(9) or 902(13) doesn't guarantee the record comes in. It still needs to survive relevance challenges and Rule 403 balancing. But getting past the hearsay objection and authentication challenge is where most blockchain-evidence disputes get resolved, and both 902(13) and 803(6) give you the tools to do it without expert testimony at trial.

What This Means Monday Morning

If you're building a blockchain-anchored evidence file, structure the record for each of these challenges before they arise.

At anchoring: Record the SHA-256 hash, both transaction IDs (Polygon and Bitcoin), block numbers, and timestamps. Keep these with the case file, not separate from it.

Before discovery: Prepare a FRE 902(13) written certification or secure a qualified expert willing to execute a declaration covering SHA-256 collision resistance, the dual-chain confirmation process, Bitcoin's timing variance and why dual-chain answers it, and the public verifiability of the anchor.

For opposing counsel: Give them the hash and both transaction IDs. The public verification endpoint at proofledger.io/verify.html returns the full anchoring record for any hash, no account required. When opposing counsel can verify independently against the public ledger, they're no longer relying on your chain of custody. The ledger is the record. That changes the evidentiary posture.

A blockchain timestamp designed to answer each of these attacks with documentation (not argument) is different from one submitted bare and defended ad hoc. Build the record before you need to use it.

Video Evidence in Disputed Claims: Why Footage Timing Is the Authentication Problem

Craig Solomon — Fri, 31 Jul 2026 13:00:00 +0000

Meta description: Dashcam footage and security video can't prove their own timing. Here's what authentication under FRE 901(b)(9) actually requires for disputed claims.

A thread on r/Insurance this week illustrates the problem well. A driver gets rear-ended on the freeway. The other driver disputes liability. There's a police report. There are photos of the damage. No dashcam. The poster's conclusion: "just my word against his."

The framing of "word against word" suggests the problem is credibility. It's usually not. The problem is authentication. And authentication of video and photo evidence in disputed claims is a technical and legal question that file metadata can't answer on its own.

What File Metadata Actually Proves

A photo or video file contains embedded timestamps. The filename might include a capture date. Dashcam footage often burns a timestamp directly into the frame. Security cameras write timestamps into the archive.

None of it is independently verifiable.

File creation dates can be altered in under a minute. EXIF metadata is mutable, deletable, and frequently stripped by the platforms people use to share files. A timestamp burned into dashcam footage reflects the device's internal clock, which may or may not be synchronized to an external time source, and which can be adjusted manually. Device clocks drift. They reset after battery failures.

In auto claims, property claims, and premises disputes, file metadata is treated as a starting point, not a conclusion. When opposing counsel has a reason to challenge timing, these are the pressure points.

FRE 901(b)(9) and the Foundation Requirement for Video Evidence Authentication

Federal Rule of Evidence 901(b)(9) allows authentication of evidence produced by a process or system by showing that the process produces an accurate result.

The critical word is "showing." Foundation has to be laid. Courts have been consistent on this: 901(b)(9) authenticates a reliable process, not a timestamp field. For video evidence, the proponent has to demonstrate how the footage was captured, what time source the device used, how the file was stored and transferred, and whether it remained intact throughout.

That last element, chain of custody for the digital file, is where timing disputes concentrate. A dashcam file exported to a phone, uploaded to a cloud drive, and submitted via email has moved through multiple environments before anyone asks for it in discovery. Each transfer is a potential interruption in the chain.

FRE 901(b)(9) doesn't require perfection. It requires a showing that the underlying process is reliable. But the more complex the handling history, the more that showing costs, in time, in expert fees, and in litigation exposure.

Why Video Evidence Timing Disputes Are Getting More Common

Video evidence is everywhere in claims now. Doorbell cameras. Ring cameras. Security systems. Dashcams. Bodycams on delivery drivers. Footage from the utility worker who inspected the property two weeks before the loss.

The footage exists. The question of when it was recorded is harder than it looks.

Security camera systems are notorious for clock drift. Many facilities never synchronize their systems to an accurate external time source, and when a claim surfaces months after an incident, determining whether the timestamp is accurate requires forensic examination of the system itself. That's not always possible if the system has been replaced or updated since the incident.

Dashcam footage raises a different problem. Most drivers never verify that the dashcam's internal clock is correct until they actually need the footage in a dispute. A device configured years ago may be running hours off from the actual time.

For property claims, the question of whether a photo documents pre-loss condition or post-loss damage often hinges on exactly this timing gap. The photo looks the same either way. The timestamp is what distinguishes them. And the timestamp is what can be challenged.

How Blockchain Anchoring Creates Independent Timing Proof

A blockchain anchor doesn't trust the file's metadata. It creates external, independent proof of existence at a specific point in time.

The mechanics: a SHA-256 hash of the file is computed locally. That hash, a unique mathematical fingerprint of the file's exact contents, gets anchored to a public blockchain. The original file never moves. Only the hash goes on-chain.

The anchor is independently verifiable by anyone. Opposing counsel can verify it. An auditor can verify it. It doesn't require trusting the device, the platform, or the person who submitted the file. The anchor either matches the file or it doesn't. If it matches, the file existed in exactly its current form when the anchor was recorded.

ProofLedger anchors to both Polygon, for immediate confirmation, and Bitcoin, through a daily batch process with Merkle inclusion proofs. Two independent public ledgers. Neither can be retroactively altered without controlling a majority of the computing power that has secured Bitcoin since its launch. The economic cost of that attack is not a realistic risk vector.

This is what a neutral temporal authority means in practice. Not a signature on a document. An anchor on a public ledger that belongs to no one.

Practical Application: Anchoring at Capture, Not at Dispute

The window for pre-loss anchoring is narrow and often missed.

An adjuster on-site for a first inspection can hash and anchor every photo and video before leaving the property. The anchor ties each file to that day. If the claim later goes to litigation and opposing counsel challenges when the inspection photos were taken, the anchor provides a response that doesn't rely on the device clock or the file's metadata.

The same principle applies before a loss happens at all. A commercial property manager running a tenant move-in inspection anchors the footage the same day. A facilities team documenting equipment condition before a contractor arrives anchors those photos at capture. The timeline becomes part of the record from the start, not a contested assertion reconstructed during discovery.

Evidence Packs organize documentation by claim, case, or matter, with loss date and pre/post indicators built in. The structure reinforces what the anchor proves: this file, at this time, in this condition.

Self-Authentication Under FRE 902(13)

The anchor record itself is a machine-generated record. FRE 902(13) allows self-authentication of machine-generated records through written certification, without live expert testimony.

For claims and litigation professionals, that distinction matters. Instead of scheduling expert testimony to establish how blockchain timestamping works, the party offering the anchor can authenticate it by certification. The technical foundation is documented in the certificate. Opposing counsel can object; the proponent just doesn't have to call a technical witness to get past authentication.

FRE 902(13) was added in 2017. It exists precisely for machine-generated records that can be authenticated by process, not by human witness. A blockchain anchor fits that category.

What a Blockchain Anchor Doesn't Prove

Authentication and credibility are different problems.

A blockchain anchor proves a file existed in its current form at the time of anchoring. It doesn't prove the content is accurate, that the footage depicts what the submitting party claims, or that nobody prepared the scene before the camera captured it.

A security camera video anchored before a loss proves the file existed at that date. Whether the footage actually shows pre-loss property condition as claimed, that's a separate argument, supported by the footage itself, not by the anchor.

Timing is one element of a claim file. A well-anchored file with weak underlying evidence is still weak evidence. The anchor addresses the timing problem specifically. It doesn't substitute for the rest.

A Documentation Standard Before the Dispute Starts

The dashcam discussion on r/Insurance points at something that shows up across auto, property, premises, and construction claims. The documentation exists. The timing can't be proved. The dispute survives longer than it should because nobody can cut through it with something verifiable.

Anchoring at capture doesn't eliminate disputes. It eliminates one specific line of attack: the argument that nobody can verify when the documentation was created.

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

proofledger.io

Idempotent File Anchoring in Python: SHA-256 as a Deduplication Key

Craig Solomon — Thu, 30 Jul 2026 13:00:00 +0000

You set up an evidence file intake. Files arrive throughout the day: reports, photos, PDFs from field adjusters. Some are duplicates. The same photo emailed and then uploaded through the portal. A retry loop that fires twice because the first request timed out. A processor copying from two different source folders.

If you anchor every incoming file without deduplicating first, you end up with multiple proof records for the same content. That's not a catastrophic failure. But the earlier anchor is the one that matters. It establishes when the file existed. Every anchor after the first is noise, and if your pipeline can't tell the difference, you can't reliably cite the earliest timestamp when it counts.

SHA-256 solves this cleanly. Two identical files always produce the same hash. The hash is the natural idempotency key.

Two Tiers, One Rule

The strategy here has two stages.

Local SQLite first. Before touching any API, hash the incoming file and check a local database. If that digest is already in the table, return the existing proof record and skip the network call. Fast, offline, free.

API dedup signal second. If the same hash was anchored from a different client, or before this local DB existed, POST /api/v1/proof returns a duplicate_of field pointing to the original proof ID. That original is the canonical anchor.

Both tiers enforce the same rule: the earliest anchor wins.

Setting Up Local State

pip install requests

The SQLite table is straightforward. SHA-256 is the primary key.

import sqlite3

def init_db(db_path: str = "anchors.db") -> sqlite3.Connection:
    conn = sqlite3.connect(db_path)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS anchors (
            sha256          TEXT PRIMARY KEY,
            proof_id        TEXT NOT NULL,
            anchored_at     TEXT,
            status          TEXT,
            certificate_url TEXT
        )
    """)
    conn.commit()
    return conn

Inserts use INSERT OR IGNORE. If the hash is already present, the insert is a no-op and the first record stays.

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

No upsert. No conflict resolution. First record wins.

Hashing Files

Chunk the read so large files don't blow up memory. A 4GB video and a 10KB text file take the same path.

import hashlib

def compute_sha256(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()

This returns the hex digest you'll send to the API. The file itself goes nowhere.

Calling the API

The v1 proof endpoint takes a SHA-256 hex digest, an optional filename, and an optional bitcoin_requested flag. Auth is a Bearer token from your ProofLedger account.

import time
import requests
from typing import Optional

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

def call_anchor_api(digest: str, filename: Optional[str] = None) -> dict:
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    }
    body: dict = {"sha256": digest}
    if filename:
        body["filename"] = filename

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

        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 60))
            time.sleep(retry_after)
            continue

        if resp.status_code in (400, 401, 403):
            resp.raise_for_status()

        resp.raise_for_status()
        return resp.json()

    raise RuntimeError(f"Anchor API failed after 3 attempts for digest {digest}")

A few things worth calling out.

Rate-limit responses (429) parse the Retry-After header before sleeping. Don't use a fixed interval. The API tells you exactly how long to wait, and that value shifts based on your tier's reset window.

400, 401, and 403 are non-retryable. A malformed hash, a bad key, or a permissions mismatch won't fix itself on retry. Raise immediately and let the caller decide.

Timeouts and 5xx responses fall through the loop naturally.

The Dedup Worker

Here's where both tiers connect.

import os

def get_cached_anchor(conn: sqlite3.Connection, sha256: str) -> Optional[dict]:
    row = conn.execute(
        "SELECT proof_id, anchored_at, status, certificate_url FROM anchors WHERE sha256 = ?",
        (sha256,),
    ).fetchone()
    if row:
        return {
            "proof_id": row[0],
            "anchored_at": row[1],
            "status": row[2],
            "certificate_url": row[3],
        }
    return None


def anchor_file(filepath: str, conn: sqlite3.Connection) -> dict:
    digest = compute_sha256(filepath)
    filename = os.path.basename(filepath)

    # Tier 1: local cache
    cached = get_cached_anchor(conn, digest)
    if cached:
        return {"source": "local_cache", "duplicate": True, "sha256": digest, **cached}

    # Tier 2: API
    data = call_anchor_api(digest, filename)

    # If duplicate_of is present, the API has seen this hash before.
    # Use the original proof ID, not the new record's ID.
    canonical_id = data.get("duplicate_of") or data["id"]

    store_anchor(
        conn,
        sha256=digest,
        proof_id=canonical_id,
        anchored_at=data.get("created_at", ""),
        status=data.get("status", "pending"),
        certificate_url=data.get("certificate_url", ""),
    )

    return {
        "source": "api",
        "duplicate": "duplicate_of" in data,
        "sha256": digest,
        "proof_id": canonical_id,
        "status": data.get("status"),
        "certificate_url": data.get("certificate_url"),
    }

The duplicate_of field is the API's signal that it's already seen this hash. It contains the ID of the original proof record. Store that ID, not the new record's ID.

This distinction matters for evidence documentation. If a document was anchored three months ago and now arrives in a new intake batch, the relevant timestamp is the one from three months ago. That anchor establishes the file existed before whatever event is now in dispute. Citing last Tuesday's duplicate record instead is technically valid but gives the wrong timestamp.

Running It

if __name__ == "__main__":
    import sys

    conn = init_db()

    if len(sys.argv) < 2:
        print("Usage: python worker.py <file> [file ...]")
        sys.exit(1)

    for path in sys.argv[1:]:
        result = anchor_file(path, conn)
        print(
            f"{path}: "
            f"source={result['source']}, "
            f"duplicate={result['duplicate']}, "
            f"proof_id={result['proof_id']}"
        )

Run it twice on the same file:

$ python worker.py inspection-report.pdf
inspection-report.pdf: source=api, duplicate=False, proof_id=prf_abc123

$ python worker.py inspection-report.pdf
inspection-report.pdf: source=local_cache, duplicate=True, proof_id=prf_abc123

Second run never touches the API. Same proof ID both times.

Extending From Here

A few natural additions depending on your pipeline.

Status polling. The initial anchor returns status: "pending". Poll GET /api/v1/proof/:id on a background schedule and update the status column when it flips to anchored. The proof ID is already in your table, so this is just a lookup and an update.

Third-party verification. Once anchored, GET /api/v1/verify?hash=<sha256> is public with no API key required. Pass the hex digest and the endpoint returns the proof record and blockchain explorer links. An auditor or opposing party can check the anchor without touching your credentials.

File-watcher integration. This worker composes cleanly with a watchdog or chokidar watcher. The watcher fires on new files, calls anchor_file(), and the SQLite table handles deduplication automatically. You don't need separate filename or modification-time tracking. The hash covers it.

Multi-worker state. SQLite works for a single-node worker. If you're running multiple workers against the same intake folder, you'll want a shared state store. PostgreSQL with INSERT ... ON CONFLICT DO NOTHING gives you the same semantics. The canonical_id = data.get("duplicate_of") or data["id"] logic stays unchanged.

For offline verification of anchored files, the verify-proof PyPI package handles local Merkle proof validation with no network call.

What do you use for idempotency state in file ingestion pipelines? SQLite, Redis, Postgres? Curious how others have handled the multi-worker case without a central DB.

How a Business Can Prove Asset Conditions Before a Hurricane, Theft, or Flood

Craig Solomon — Wed, 29 Jul 2026 13:00:01 +0000

The strongest pre-loss documentation isn't the most detailed. It's documentation that can survive a challenge about when it was created.

Carriers and opposing counsel don't need to prove your photos are fabricated. They only need to raise a question about timing. If there's no independent record answering that question, the documentation's evidentiary weight can collapse.

Why Timing Becomes the Actual Dispute

A file's metadata timestamp is not reliable proof of when it was created. EXIF data in photos can be modified in standard editing software. File system timestamps reset when files are copied, compressed, or migrated to a new drive. Cloud storage "upload date" fields reflect when a file arrived at the platform, not when it was originally captured.

In a property dispute or theft claim, this gap is commonly raised. A photo showing equipment in good condition "before" a loss becomes contested if there's no independent record establishing when that photo existed.

Photographs and video are still central to any documentation package. The problem is relying on file metadata alone for the timing proof.

Documentation Methods That Hold Up to Scrutiny

Physical inspection reports with dated signatures. A third-party inspector visiting the property before a loss creates a record with independent timestamps: the inspection date, the company's records, possibly a notarized signature. This is solid but expensive at scale and difficult to repeat frequently across multiple locations.

Notarized records and certified appraisals. A notary's stamp establishes that a document existed in front of them on a specific date. For high-value individual assets, this approach works well. For routine documentation across a large property portfolio, the logistics don't scale.

Cloud platform access logs. Google Drive, Microsoft SharePoint, and similar services record upload timestamps and version histories. A third party controls those records, which adds some independence. The limitation: the platform can be disputed, the records aren't cryptographically immutable, and they don't constitute proof that a specific file existed in a specific form at a specific time.

Blockchain-anchored timestamps. A SHA-256 hash of any file, whether a photograph, a video walkthrough, a PDF appraisal, or an inventory spreadsheet, can be submitted to a public blockchain. The hash is recorded on an immutable public ledger. Anyone can independently verify that the file existed in that exact form at that block's timestamp, without accessing the file itself.

How a Blockchain Anchor Actually Works

The hash is a fixed-length fingerprint of a file's contents. It's not the file. The file stays on your device or server. Change one byte of the file and the hash changes completely. Two different files will never produce the same hash. A file that matches its on-chain hash proves it hasn't been altered since the anchor was created.

ProofLedger submits that hash to two independent public blockchains: Polygon, which returns a near-instant confirmation, and Bitcoin, through a daily batch with merkle proofs. The dual-chain record matters for evidentiary purposes because the same timing claim is now supported by two independent ledgers, neither controlled by the same party. Polygon timestamping is free on every plan. Bitcoin anchoring is a per-anchor escalation, available when proof-of-work immutability is worth the cost for high-stakes documentation.

What an anchor proves: the file existed in its current form at or before that block time. What the anchor doesn't prove: whether the file accurately depicts what it appears to show, or that the underlying conditions are as represented. Those are content questions. The hash is a timing and integrity proof, not a verification of what's in the image.

The Legal Foundation: FRE 901(b)(9) and FRE 902(13)/(14)

For disputes that become litigation, authentication is the central issue. FRE 901(b)(9) allows courts to authenticate evidence produced by a "process or system that produces an accurate result." A blockchain timestamp can meet this standard, but it requires laying a foundation. That typically means expert testimony or a technical certification explaining how the system works and why it reliably produces accurate output.

FRE 902(13) and 902(14), added to the Federal Rules in 2017, provide a more direct path. They allow self-authentication of machine-generated records through written certification, without live expert testimony. A blockchain anchor record accompanied by a proper 902(13) or 902(14) certification can be admitted without calling a witness to establish foundation.

Neither rule makes any record automatically admissible. They define the pathway. The certification still needs to be prepared correctly, and the documentation needs to meet other applicable evidentiary standards.

Building a Pre-Loss Documentation Workflow

For businesses managing property across multiple sites, a practical pre-loss workflow combines several layers:

Routine, dated photographs and video walkthroughs of key assets and conditions. Not just after a major purchase or renovation. The consistency of pre-loss photos matters as much as their detail. A single walkthrough a week before a storm is weaker than quarterly documentation going back two years.

Anchor files at or near capture. If documentation exists at known times before a loss, the blockchain record establishes timing independent of file metadata or platform upload dates.

Organize by location, asset, or policy period. A claim that maps to specific coverage is easier to support when documentation is grouped to match. Combining pre-loss photos, an appraisal PDF, and a current inventory spreadsheet for the same facility into a single evidence package creates a more defensible record than a folder of unrelated files with similar timestamps.

Review and update documentation before each storm season or when significant asset conditions change. An anchor from several years ago may be technically valid as a timestamp. Whether it reflects conditions at the time of a specific loss is a separate question entirely.

The Case for Starting Before the Event

Most property disputes that hinge on timing aren't fraud investigations. They're cases where documentation existed, the documentation is accurate, and there's simply no independent record placing it before the loss date. Good-faith claims fail on that narrow point.

Pre-loss anchoring addresses that specific gap. It's not a substitute for physical inspections or certified appraisals. It's a layer that adds independent, verifiable timing to files a business is already creating. For businesses generating significant property documentation routinely, building that layer into the workflow before the next storm season is the move worth making now.

Start documenting before the loss with ProofLedger

Zubulake's Preservation Trigger: The "When Did You Know" Problem Blockchain Anchoring Addresses

Craig Solomon — Mon, 27 Jul 2026 13:00:00 +0000

The case

Zubulake v. UBS Warburg LLC, 217 F.R.D. 309 (S.D.N.Y. 2003), arose from an employment discrimination claim by Laura Zubulake against UBS Warburg, alleging gender discrimination and retaliation after she was passed over for a promotion and eventually terminated. The central discovery dispute involved emails stored on backup tapes, expensive to restore, with competing claims about what had been preserved, what had been destroyed, and when. The litigation produced five rulings by Judge Shira Scheindlin, collectively forming the most-cited federal framework for ESI preservation duties.

What the court held

Judge Scheindlin held that the duty to preserve evidence attaches when litigation is "reasonably anticipated." Not when a complaint is filed, and not when a formal litigation hold memo is circulated. She developed a seven-factor cost-shifting test to allocate the expense of restoring inaccessible ESI, distinguishing accessible data (producing party pays) from inaccessible data on backup tapes (subject to judicial balancing). The 2015 amendments to FRCP 37(e) displaced portions of the Zubulake sanctions framework with a uniform federal standard, but the preservation trigger analysis remains foundational.

Where blockchain anchoring fits

The "reasonably anticipated" standard creates a problem that's easier to state than to prove: how do you demonstrate, years later, that you had a specific document at a specific moment and preserved it from that point forward? In Zubulake, the dispute wasn't only whether UBS preserved the emails. It was whether what was eventually produced reflected what had actually existed and when.

A SHA-256 hash anchored to two public blockchains addresses that evidentiary gap directly. The anchor doesn't change when the duty attaches. But it creates something the Zubulake framework couldn't account for: an immutable, timestamped record that a specific file existed, with specific content, at a specific moment. If a party anchors litigation-relevant documents when legal action first becomes foreseeable, they create evidence that speaks to the exact question courts ask under Zubulake: what did you have, and when?

The anchor is independent of the file and independent of the producing party's own systems. It lives on two public chains regardless of what happens to the original document, regardless of backup tape failures, retention policy expiration, or system migrations that postdate the preservation trigger. Opposing counsel can verify the anchor directly against the chain without depending on the producing party's representations about what existed.

Zubulake's cost-shifting analysis is also worth examining here. The court split ESI into accessible data (producing party pays) and inaccessible data on backup tapes (subject to balancing). Anchoring doesn't reduce tape restoration costs. But if a file was anchored when it was created or when it became litigation-relevant, that hash can verify any subsequently located copy without requiring full restoration of every candidate tape. Locate the file anywhere. Active systems, backup media, the opposing party's own production. Run SHA-256, compare against the anchor. Verification becomes a computation, not a credibility question.

That verification can happen entirely offline. The verify-proof PyPI package lets a forensic examiner confirm a ProofLedger anchor without network calls, without server availability, and without any step that depends on a third party's uptime. The examiner hashes the file locally and checks the on-chain record. Cross-examination has very little to work with there.

The takeaway for practitioners

The "reasonably anticipated" trigger in Zubulake is a factual standard, which means it turns on what evidence exists about what a party knew and when. A blockchain timestamp creates evidence on that exact point. Not as a substitute for a litigation hold, but as a durable record showing a specific file existed with specific content at a documented moment. Under FRCP 37(e), courts evaluating whether a party took "reasonable steps to preserve" ESI look at the full factual picture. A timestamp independently verifiable on two public chains, by any party or by the court itself, is part of that picture. For authentication of the anchored records, FRE 902(14) allows self-authentication of electronic data identified by hash value via written certification. No live expert required.

References

Zubulake v. UBS Warburg LLC, 217 F.R.D. 309 (S.D.N.Y. 2003)
FRCP 37(e) (failure to preserve electronically stored information)
FRE 902(14) (self-authentication of electronic data via hash value certification)

Skip the Duplicate: Building an Idempotent File-Anchoring Worker in Python

Craig Solomon — Thu, 23 Jul 2026 13:00:00 +0000

You're processing a folder of evidence files and some of them were already anchored last week. Your script crashed at file 47 and you need to rerun it. Two services are ingesting from the same drop zone at the same time.

All three problems have the same root cause: no deduplication. And they all produce the same outcome: redundant submissions that waste API quota, create ambiguous records, and make downstream bookkeeping messy.

The fix isn't complicated. An idempotent worker checks before it submits. And when the race window catches it anyway, it handles the duplicate_of response correctly.

Check the Hash Before You Touch the API

The first move is a pre-flight check. Before calling the write endpoint, ask the public verification endpoint if the hash already exists:

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

No auth required. Returns { "found": true, "proof": {...} } or { "found": false, "sha256": "..." }. Rate-limited at 120 requests per hour per IP, so it costs nothing in API quota and nothing in authentication overhead.

Here's the hash computation and pre-flight:

import hashlib
import requests

VERIFY_URL = "https://proofledger.io/api/v1/verify"

def sha256_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()

def check_existing(file_hash: str) -> dict | None:
    resp = requests.get(VERIFY_URL, params={"hash": file_hash}, timeout=10)
    resp.raise_for_status()
    data = resp.json()
    return data.get("proof") if data.get("found") else None

If check_existing() returns something, you're done for that file. Store the proof ID and move on. If it returns None, proceed to submit.

One thing worth caching locally: once a hash is anchored, it doesn't become unanchored. So if you've seen found: true for a hash, write it to disk and skip the pre-flight forever on that hash. That's how you stay well under the 120/hr rate limit across large batches.

Submitting and the `duplicate_of` Field

Pre-flight check eliminates most duplicates. But two workers running concurrently can both see found: false for the same hash and both POST it within milliseconds of each other. The API handles this case without error. When the second submission lands, the response includes a duplicate_of field pointing to the ID of the earlier proof.

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

def submit_proof(file_hash: str, filename: str | None = None) -> dict:
    headers = {"Authorization": f"Bearer {API_KEY}"}
    body = {"sha256": file_hash}
    if filename:
        body["filename"] = filename
    resp = requests.post(SUBMIT_URL, json=body, headers=headers, timeout=15)
    resp.raise_for_status()
    return resp.json()

def canonical_id(submission: dict) -> str:
    return submission.get("duplicate_of") or submission["id"]

Always store canonical_id(submission), not submission["id"]. If duplicate_of is present, the earlier proof is the canonical one. A third-party verifier, an auditor, or opposing counsel checking your evidence records should see the same proof ID you have on file. Using a later duplicate's ID creates a mismatch that's technically harmless but annoying to explain.

Checking Anchor Status

After a successful POST, the proof sits in a pending state while the blockchain transaction propagates. You can poll GET /api/v1/proof/:id (auth required, owner only) to check when it confirms:

import time

PROOF_URL = "https://proofledger.io/api/v1/proof"

def wait_for_anchor(proof_id: str, max_polls: int = 12, interval: int = 15) -> dict | None:
    headers = {"Authorization": f"Bearer {API_KEY}"}
    for attempt in range(max_polls):
        resp = requests.get(f"{PROOF_URL}/{proof_id}", headers=headers, timeout=10)
        resp.raise_for_status()
        data = resp.json()
        if data.get("polygon_status") == "anchored":
            return data
        if attempt < max_polls - 1:
            time.sleep(interval)
    return None

For batch jobs, you usually don't want to block per file waiting for confirmation. Submit everything, store the IDs, check status later. Polygon confirmation is fast. ProofLedger's Bitcoin anchoring runs on a daily batch with Merkle proofs, so that chain takes longer by design.

A Complete Worker

Here's the full thing: hash, pre-flight, submit with retry, handle duplicate_of, save progress.

import hashlib
import json
import os
import time
import requests

VERIFY_URL = "https://proofledger.io/api/v1/verify"
SUBMIT_URL = "https://proofledger.io/api/v1/proof"
API_KEY = "sk_YOUR_KEY_HERE"
PROGRESS_FILE = "anchored.json"


def sha256_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()


def load_progress() -> dict:
    if os.path.exists(PROGRESS_FILE):
        with open(PROGRESS_FILE) as f:
            return json.load(f)
    return {}


def save_progress(progress: dict) -> None:
    with open(PROGRESS_FILE, "w") as f:
        json.dump(progress, f, indent=2)


def anchor_file(path: str, progress: dict) -> None:
    file_hash = sha256_file(path)

    if file_hash in progress:
        print(f"  skip (cached): {path}")
        return

    verify_resp = requests.get(VERIFY_URL, params={"hash": file_hash}, timeout=10)
    verify_resp.raise_for_status()
    verify_data = verify_resp.json()

    if verify_data.get("found"):
        proof_id = verify_data["proof"]["id"]
        progress[file_hash] = {"id": proof_id, "source": "pre-flight"}
        print(f"  found (pre-flight): {path} -> {proof_id}")
        save_progress(progress)
        return

    headers = {"Authorization": f"Bearer {API_KEY}"}
    body = {"sha256": file_hash, "filename": os.path.basename(path)}

    for attempt in range(3):
        try:
            resp = requests.post(SUBMIT_URL, json=body, headers=headers, timeout=15)

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

            if resp.status_code in (400, 401, 403):
                print(f"  non-retryable {resp.status_code}: {path}")
                return

            resp.raise_for_status()
            data = resp.json()
            proof_id = data.get("duplicate_of") or data["id"]
            source = "duplicate_of" if data.get("duplicate_of") else "submitted"
            progress[file_hash] = {"id": proof_id, "source": source}
            print(f"  {source}: {path} -> {proof_id}")
            save_progress(progress)
            return

        except requests.Timeout:
            if attempt == 2:
                print(f"  timeout after 3 attempts: {path}")
                return
            time.sleep(2 ** attempt)


def run(directory: str) -> None:
    progress = load_progress()
    files = [
        os.path.join(root, fname)
        for root, _, filenames in os.walk(directory)
        for fname in filenames
    ]
    print(f"{len(files)} files in {directory}")
    for path in files:
        anchor_file(path, progress)


if __name__ == "__main__":
    import sys
    run(sys.argv[1] if len(sys.argv) > 1 else ".")

A few design notes worth calling out.

Progress is keyed by hash, not by path. If a file gets renamed or moved, it won't be re-submitted. Hash identity is what the anchoring system cares about, so that's what your progress tracker should care about too.

The 429 handler reads Retry-After from the response header instead of sleeping a fixed amount. Hardcoded sleep intervals are almost always wrong. The server's value accounts for its current load and rate window.

Non-retryable errors (400/401/403) exit immediately. A 400 means your hash is malformed. A 401/403 means your key is wrong or expired. Neither gets better with retries.

Running It

pip install requests
python anchor_worker.py ./evidence-files/

On the first run, it hits the verify endpoint for every file it hasn't seen. On reruns, anything in anchored.json is skipped entirely, no network calls. Anything found via pre-flight is recorded without touching your submission quota. Only genuinely new hashes reach the POST endpoint.

If you want to check a specific file's proof later, the id in your progress file maps to the certificate: https://proofledger.io/cert/<id>. And the public verify endpoint works independently for anyone who needs to confirm a hash without your records:

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

That independence is the point. I made that endpoint public so your database isn't the only source of truth for a file's anchor. Anyone can check. That's what a neutral anchor is for.

Interested in the Merkle proof structure that backs the Bitcoin anchoring side? Source for the verify-proof PyPI package is at https://github.com/Fulcrum-Enterprises/verify-proof if you want to dig into the offline verification path.

What are you anchoring? Drop a comment with your use case.

Pre-Loss Evidence Documentation: The Case for Blockchain-Anchored Timestamps

Craig Solomon — Wed, 22 Jul 2026 13:00:00 +0000

An attorney gets a discovery response with 400 photos. All timestamped the week before trial. The insured claims these were taken right after purchase, two years earlier. There's no way to verify that. The photos exist. The metadata exists. But metadata can be changed.

The same gap exists across property management, construction, and risk consulting. Any professional who documents conditions before work begins or before a loss occurs is vulnerable to this problem if their timestamps can be challenged.

Pre-loss evidence documentation depends on one thing: proving when a file existed, not when someone says it did. ProofLedger anchors that proof to a public blockchain before any dispute starts.

Here's the workflow. A property manager, a risk consultant, a contractor doing site documentation anchors SHA-256 hashes of their files to Polygon (instant confirmation) and Bitcoin (daily batch with merkle proofs). The original files never leave the device. Only the hash is anchored. What gets created is a blockchain-anchored timestamp that proves the file existed at that exact moment in time.

That timestamp changes the argument in litigation.

Temporal Verification vs. File Metadata

Temporal verification through blockchain anchoring isn't about trusting a vendor. It's about creating a neutral temporal authority: a record that exists independently of the party who created the evidence, independently of the platform that stored it, independently of any claims system that touched it afterward.

Courts can authenticate blockchain records under FRE 901(b)(9), which covers evidence produced by a process that generates an accurate result. With proper foundation, typically a technical certification explaining the anchoring method, blockchain-anchored timestamps can support authentication of when a file existed. FRE 902(13) goes further, allowing machine-generated records to be self-authenticated through written certification without live testimony.

That combination matters for chain of custody in high-stakes disputes. The record doesn't need an expert to explain it at deposition if the certification is filed correctly.

The Workflow in Practice

A risk manager documenting a commercial property before a lease signing anchors every photo, every condition report, every inspection form. If a claim surfaces three years later, the pre-loss evidence already exists on the blockchain. The dispute shifts from "when were these taken?" to "can you challenge an immutable record secured by Bitcoin's proof-of-work since 2009?"

That's a different argument. It usually goes differently.

Pre-loss documentation has always mattered. What's changed is whether it can be made tamper-evident without depending on a vendor's server, a platform's API uptime, or file metadata surviving format conversion. A blockchain anchor doesn't depend on any of those. It exists on a public ledger regardless of what happens to the file afterward.

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

Notarization vs. Blockchain Timestamping: Which Fits a Claims Portfolio

Craig Solomon — Mon, 20 Jul 2026 13:00:00 +0000

A commercial property manager handles risk documentation for 40 properties. Every quarter, site photos, inspection reports, and maintenance logs accumulate. Some of those files will matter if a claim surfaces two years from now.

Notarization is the traditional answer to that problem. But apply it to an active portfolio with ongoing monthly documentation, and it starts to look less like a solution and more like a bottleneck.

Blockchain timestamping offers a different path. Not better in every situation. Different. Understanding where each fits is what builds a workflow that holds up when a dispute goes to litigation.

What Notarization Actually Establishes

A notary performs three things: verifying the identity of the signer, witnessing the execution, and recording the date and time. That seal creates a legally recognized record that a specific person executed a document at a specific time.

For contracts, deeds, and sworn affidavits, that's powerful. Courts have accepted notarized documents for centuries. No foundational argument is required when opposing counsel sees the seal.

But notarization has structural limits that matter at scale.

Scope is narrow. A notary seal attests to a signature event, not a file's integrity. If you notarize a cover page attached to 300 inspection photos, the seal covers the signing, not the contents of the photos themselves.

Timing requires physical presence. You can't notarize retroactively, and in many states, remote notarization carries additional authentication requirements that vary by jurisdiction.

Cost and friction accumulate. At $5-15 per notarization, a portfolio generating 50 documents per month is looking at $3,000-$9,000 per year in notarization costs alone, before travel or coordination time.

What Blockchain Timestamping Actually Establishes

A blockchain timestamp doesn't touch identity. It doesn't verify who created a file or that a specific person signed anything. What it establishes is simpler and, in the right context, more useful: that a specific file, with this exact content, existed at this exact moment in time.

The mechanism is a SHA-256 hash, a cryptographic fingerprint of the file's contents. That hash gets anchored to a public blockchain. The record is immutable. Anyone can verify it independently, without relying on the platform that created it.

Courts can authenticate blockchain records under FRE 901(b)(9), which covers evidence produced by a process that generates an accurate result. FRE 902(13) and 902(14) go further, allowing self-authentication of machine-generated records through written certification. No live expert testimony required.

For pre-loss documentation, this matters. An adjuster shows up to a loss site. The photos exist. There's no proof they were taken before the storm. A blockchain-anchored hash from three months prior changes that.

The Scale Difference

Here's where the workflows diverge.

A notarization event takes scheduling, physical or remote coordination, and per-document fees. For a single critical document, that's manageable. For 200 photos, a maintenance log, and a drone survey updated quarterly, it's not sustainable.

A blockchain timestamp takes seconds. The file never leaves the device. Only the hash is transmitted. You can batch-timestamp an entire folder of pre-loss documentation in the same time it would take to locate a notary's phone number.

For portfolio-scale risk documentation, the math is simple. For individual high-stakes legal instruments, notarization's established chain of acceptance often outweighs the overhead.

Where Each Belongs

Use notarization for:

Signed agreements, contracts, and amendments
Sworn statements and affidavits
Any document where the identity of the signer is the primary question

Use blockchain timestamping for:

Pre-loss site photos and inspection records
Ongoing maintenance and compliance documentation
Forensic evidence that needs to establish timing without routing through a third party
File volumes where per-document fees would be prohibitive

Many claims operations use both. A notarized contract establishes the agreement. Blockchain-anchored inspection records establish the condition of the property at the time of inspection. They answer different questions.

The Verification Layer

One practical difference: blockchain timestamps are independently verifiable by anyone with the original file and a public blockchain explorer. You don't need the issuing platform to confirm anything.

ProofLedger anchors to both Polygon (instant confirmation) and Bitcoin (daily batch with merkle proofs). Verification runs against /api/v1/proof?hash=[sha256] and returns the anchor block, timestamp, and chain confirmation. Opposing counsel can run that check themselves without coordinating with anyone.

A notarized document requires the seal, the notary's records, and potentially the notary's live testimony if authenticity is challenged. A blockchain record requires a hash and a public ledger.

Neither is universally superior. The question is which authentication problem you're solving.

For ongoing portfolio documentation, the operational math increasingly favors timestamping. For the documents that define the terms of a claim, notarization's centuries of legal precedent still carry weight that a newer technology is still building.

The strongest documentation workflows for complex commercial claims don't choose between them. They use each for what it actually does.

Blockchain Timestamping for Pre-Loss Evidence: Why File Metadata Isn't Enough

Craig Solomon — Fri, 17 Jul 2026 13:00:00 +0000

A public adjuster gets called in on a commercial property claim three weeks after a storm. The insured has photos of the roof condition taken before the event. Timestamps in the file metadata put them eight months prior. The carrier is skeptical. And without something more than metadata, it has good reason to be.

The carrier's position: metadata is not proof. It's not wrong.

A JPEG timestamp is a field in the file header. Anyone with basic software can change it. Courts know this.

Blockchain timestamping for pre-loss documentation exists to close this gap. ProofLedger anchors a SHA-256 hash of each file to two public blockchains at the moment of capture. Polygon confirms the record instantly. Bitcoin processes a daily batch with merkle proofs. The original files never leave the device. What lands on-chain is a cryptographic fingerprint tied to a specific point in time.

This is what temporal verification looks like in practice. A risk manager documents a property in January, each photo anchored as it's captured. The blockchain entry exists before any loss occurs. Months later, a storm claim comes in. The property manager has those January photos, and with them, blockchain-anchored timestamps confirming the capture date on two independent public ledgers. That's a materially different evidentiary position than metadata alone.

The chain-of-custody gap in digital evidence authentication isn't hypothetical. It's a recurring issue in commercial property and casualty litigation. Defense counsel has learned to challenge file metadata as a timing source, and carriers increasingly scrutinize provenance of photos, inspection reports, and condition records. Courts can authenticate blockchain records under FRE 901(b)(9), which covers evidence produced by a process that generates an accurate result. This requires a technical foundation, typically through certification explaining how the anchoring process works. For machine-generated records, FRE 902(13) allows authentication through written certification without live witness testimony.

An opposing party challenging a blockchain-anchored timestamp has to explain why two independent public ledger records are wrong. That's a harder argument than pointing to a file header that anyone could have modified.

Evidence packs organize anchored files by case, claim, or matter, each with a loss date, pre/post indicators, and a verification record exportable for counsel or carrier review. The structure maps to how adjusters and attorneys actually build a file.

Chain-of-custody documentation built on blockchain anchoring isn't a replacement for thorough evidence collection. It's the layer that makes the timing of that collection independently provable when metadata alone won't hold up.

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

Notarization vs. Blockchain Timestamps: What Each One Proves Under the Federal Rules

Craig Solomon — Thu, 16 Jul 2026 13:00:00 +0000

Picture this: a contractor produces a notarized pre-construction inspection report. The property owner files a claim alleging the contractor caused structural damage during the project. The contractor's defense rests on that report, which documented pre-existing conditions before any work started.

The notary stamp is authentic. The signature is genuine. No one disputes either.

What opposing counsel disputes is when the inspection actually happened. The notarization date is the date someone signed the document, not the date the conditions were observed. And they're not wrong to raise it.

Notarization and blockchain timestamps solve different authentication problems. Treating them as interchangeable creates gaps that surface at the worst possible moment.

What Notarization Actually Authenticates

Under FRE 902(8), a document acknowledged by a notary public is self-authenticating. The notary confirms two things: the identity of the signer, and that the person executed the document voluntarily in the notary's presence.

That's the full scope. Notarization is identity and attestation authentication. It answers "who signed this" and "did they sign it freely." It doesn't authenticate when the underlying facts were observed, when the document was drafted, or whether the photographs attached were taken at the time described.

For standard transactional documents (deeds, affidavits, contracts where timing isn't disputed), that scope is usually enough. In insurance claims, construction disputes, and pre-loss documentation, timing is often the entire dispute.

The Gap Notarization Leaves

A notarized inspection report signed June 1 proves someone signed a document on June 1. It doesn't prove the photographs were taken on June 1. It doesn't establish that the written condition assessment reflects observations made before the first day of construction, rather than observations recorded later to fit a narrative.

Underlying content can predate or postdate the signature. The notary isn't verifying the accuracy of the content, the timestamps on attached photographs, or the sequence of the inspector's work. The stamp authenticates the signature event, not the evidentiary timeline.

In disputes where liability turns on when a condition existed, that gap matters more than practitioners often recognize until they're already in it.

What Blockchain Timestamps Authenticate

FRE 901(b)(9) allows authentication of evidence produced by a process or system that generates an accurate result. A blockchain anchor fits this standard: it's a cryptographic process that records the SHA-256 hash of a file on a distributed ledger at a verifiable moment in time.

The authentication is about WHEN, not WHO.

A blockchain-anchored file proves that specific data existed in its exact state at the moment of anchoring. The content can't change afterward without producing a different hash. The ledger record is permanent and public. No human attestation is required for the timestamp itself.

FRE 902(13), added December 1, 2017, extends this further. It allows self-authentication of records generated by an electronic process or system through written certification. No live expert witness required. A qualified certification from the anchoring service satisfies the rule. That's the path that removes expert testimony cost from the authentication question entirely.

The distinction matters: 901(b)(9) governs the process-reliability argument you'd support with expert testimony. 902(13) is the self-authentication path that bypasses the live witness requirement. Know which argument you're making before the deposition transcript is due.

The Dual-Chain Difference

On the process-reliability question under 901(b)(9), the architecture of the anchoring system matters.

Anchoring to Polygon and Bitcoin independently creates two transaction records on chains with different validator sets, different consensus mechanisms, and entirely different audit histories. If either chain had a systematic flaw, the other doesn't share it. That redundancy is the technical foundation for the process-reliability argument.

Bitcoin uses merkle proofs: multiple files are batched into a single daily transaction, and each file receives a cryptographic proof that it was included in that batch. The merkle proof is verifiable offline, without relying on any service remaining operational. For evidentiary value that needs to hold up years from now, that architecture matters.

A ProofLedger-anchored file produces both records: a Polygon transaction that settles in seconds, and a Bitcoin transaction with its merkle proof from the daily batch. Both are independently verifiable at proofledger.io/verify.html without additional software.

Two independent verification paths under two independent systems is a stronger process-reliability argument than one.

When You Need Both

Some documentation scenarios call for notarization and blockchain anchoring together. Knowing when to layer them is worth having straight before the dispute.

A notarized affidavit from a field inspector, combined with blockchain-anchored photographs from that inspection session, closes both authentication questions:

The notarization authenticates the inspector's identity and attestation under FRE 902(8).
The blockchain anchors establish that those photographs existed at that specific timestamp, under FRE 901(b)(9) and 902(13).

The notary answers "who." The blockchain answers "when and exactly what." Together they cover what neither handles alone. Used independently, each leaves a gap opposing counsel will find.

What This Means Monday Morning

Three practical points.

When advising clients on pre-loss or pre-dispute documentation, ask what the likely dispute will be about. If the question is identity and attestation, notarization may be sufficient. If the question is timing (which in property damage, construction defect, and environmental matters, it usually is), a notarized document without a timestamp anchor leaves the timing question open.

Understand the FRE 902(13) self-authentication path before you need it in discovery. The rule allows written certification in place of live expert testimony. That changes the cost calculation on authentication disputes considerably. Know whether the anchoring service can provide the certification the rule requires.

And don't substitute one tool for the other. They're complementary, not competing. The goal is to have both working before the dispute arises, not to litigate at trial about which one you have.

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

DEV Community: Craig Solomon

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

Two Dedup Layers, Not One

The State Layer

Hashing and the API Call

Handling duplicate_of

Wiring the Worker

Verifying a File After Anchoring

A Few Production Notes

C2PA Content Credentials and the Chain-of-Custody Gap

How Opposing Counsel Attacks Blockchain Timestamp Evidence (and What the Technical Record Shows)

1. "SHA-256 Can Be Reversed or Forged"

2. "Block Timestamps Are Unreliable"

3. "You Can't Prove Who Anchored It"

4. "The Record Is Hearsay"

What This Means Monday Morning

Video Evidence in Disputed Claims: Why Footage Timing Is the Authentication Problem

What File Metadata Actually Proves

FRE 901(b)(9) and the Foundation Requirement for Video Evidence Authentication

Why Video Evidence Timing Disputes Are Getting More Common

How Blockchain Anchoring Creates Independent Timing Proof

Practical Application: Anchoring at Capture, Not at Dispute

Self-Authentication Under FRE 902(13)

What a Blockchain Anchor Doesn't Prove

A Documentation Standard Before the Dispute Starts

Idempotent File Anchoring in Python: SHA-256 as a Deduplication Key

Two Tiers, One Rule

Setting Up Local State

Hashing Files

Calling the API

The Dedup Worker

Running It

Extending From Here

How a Business Can Prove Asset Conditions Before a Hurricane, Theft, or Flood

Why Timing Becomes the Actual Dispute

Documentation Methods That Hold Up to Scrutiny

How a Blockchain Anchor Actually Works

The Legal Foundation: FRE 901(b)(9) and FRE 902(13)/(14)

Building a Pre-Loss Documentation Workflow

The Case for Starting Before the Event

Zubulake's Preservation Trigger: The "When Did You Know" Problem Blockchain Anchoring Addresses

The case

What the court held

Where blockchain anchoring fits

The takeaway for practitioners

References

Skip the Duplicate: Building an Idempotent File-Anchoring Worker in Python

Check the Hash Before You Touch the API

Submitting and the duplicate_of Field

Checking Anchor Status

A Complete Worker

Running It

Pre-Loss Evidence Documentation: The Case for Blockchain-Anchored Timestamps

Temporal Verification vs. File Metadata

The Workflow in Practice

Notarization vs. Blockchain Timestamping: Which Fits a Claims Portfolio

What Notarization Actually Establishes

What Blockchain Timestamping Actually Establishes

The Scale Difference

Where Each Belongs

The Verification Layer

Blockchain Timestamping for Pre-Loss Evidence: Why File Metadata Isn't Enough

Notarization vs. Blockchain Timestamps: What Each One Proves Under the Federal Rules

What Notarization Actually Authenticates

The Gap Notarization Leaves

What Blockchain Timestamps Authenticate

The Dual-Chain Difference

When You Need Both

What This Means Monday Morning

Handling `duplicate_of`

Submitting and the `duplicate_of` Field