DEV Community: Craig Solomon

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.

Notarization vs. Blockchain Timestamp: What Each Actually Authenticates

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

Pre-loss evidence documentation · blockchain anchoring · notarization · FRE 901(b)(9) · FRE 902(13)

Meta description: Notarization proves who appeared before a notary on a given date. A blockchain timestamp proves a file existed at a specific moment. For timing disputes, those aren't the same thing.

A risk manager for a commercial property firm keeps a signed, notarized inspection report for every building in the portfolio. Good practice. When a claim surfaces three years after a roof inspection, they pull the report and send it to counsel.

The notarization proves the inspector appeared before a notary and attested to the document on a specific date. That's not nothing.

But the dispute isn't about who signed the report. It's about whether the roof condition documented in that report predates the damage event. And on that question, the notarization is silent.

This is the distinction most claims documentation guidance skips. Notarization and blockchain timestamps both sound like "proof something is real." They're not the same kind of proof.

What Notarization Actually Certifies

A notary public is a state-commissioned officer. Their function is narrow: verify the identity of the person appearing before them, witness the signing of a document, and certify the signer appeared voluntarily and knowingly.

The notary stamp establishes a fact about an event that happened in front of them. Not a fact about the document's history. Not a fact about when the underlying content was created or last modified.

Under FRE 902(8), acknowledged instruments are self-authenticating in federal proceedings. An acknowledged instrument accompanied by a certificate of notarization doesn't require live testimony to be admitted. That's a genuine procedural advantage.

What it doesn't establish: temporal existence of the underlying file. A notarized inspection report still has the same problem as an unnotarized one. Someone drafted it at some point before the notarization. The notarization happened later. Nothing about that process proves when the inspection occurred, when the photos were taken, or whether the content was modified in the window between creation and attestation.

For identity disputes, notarization works. For timing disputes, it's the wrong tool.

What a Blockchain Timestamp Establishes

A blockchain anchor ties a SHA-256 hash to a public distributed ledger. The hash is a 64-character fingerprint derived from every byte of the file. Alter one character in a document, change one pixel in an image, and the hash changes completely.

The chain writes the hash at a specific block. Independent validators confirm that block. The timestamp isn't controlled by any single party and can't be revised retroactively.

What this proves: the file existed in this exact form at this moment. Not who created it. Not who held it. Just that these bytes were present somewhere in the world when the anchor was written.

That's the specific claim that matters in a timing dispute. Whether the roof inspection predates the storm. Whether the site photo was taken before the loss. Whether the pre-treatment imaging existed before the procedure was contested.

Dual-chain anchoring strengthens that claim. ProofLedger anchors to both Polygon for instant confirmation and Bitcoin in a daily batch with merkle proofs. Independent verification across two chains means the temporal claim doesn't rest on a single network's integrity.

The Authentication Framework in Court

For either mechanism to be useful in a dispute, it has to satisfy authentication requirements at trial or in discovery.

Notarization has a clear federal hook: FRE 902(8) provides for self-authentication of acknowledged instruments without live testimony. The notary functions as the foundation.

Blockchain timestamps work under a different framework. FRE 901(b)(9) allows authentication of evidence produced by "a process or system that produces an accurate result." Blockchain meets that standard once the proponent lays the foundation: how the hash is derived, how the chain records it, why the block timestamp is reliable. Expert testimony or a written certification from the anchoring service establishes that predicate.

FRE 902(13) shortens the path. It allows self-authentication of machine-generated records through written certification, without requiring a live expert at trial. A proof record from a blockchain anchoring service, paired with a written certification, can satisfy FRE 902(13). That matters when the dispute goes to deposition or a preliminary hearing and counsel needs to lay authentication without scheduling an expert.

The framing distinction is worth keeping straight: FRE 901(b)(9) is about the reliability of the underlying process; FRE 902(13) is the mechanism that allows admission without live testimony. Neither is a substitute for the other in argument.

Per-Document Economics at Portfolio Scale

The cost of notarizing a single document is low. Individual notary fees are modest. For a one-off contract or affidavit, the overhead is minor.

But claims portfolios don't process individual documents. A commercial property carrier working through a busy storm season may be dealing with hundreds of inspection reports, photo bundles, field assessments, and contractor estimates across open files. Notarizing each one means scheduling notarial acts, managing originals, and tracking turnaround across a high-volume file set.

More practically: notarization is an administrative step that happens downstream. The inspector doesn't call a notary at the moment the site visit ends. The photos don't get acknowledged when they're shot on location. The process happens later, when someone decides documentation needs to be formalized.

Blockchain anchoring doesn't require scheduling. It runs at the moment the file is processed. An inspector finishes a site report, that file gets hashed and anchored, and the proof record exists before anyone has left the property. The cost per proof is fixed. The timing is contemporaneous with the event.

For portfolios managing pre-loss documentation across many properties or claim files, that operational difference matters independently of the per-document cost comparison. Volume doesn't require proportional scheduling overhead, and timing doesn't depend on an administrative decision made later.

When Both Are the Right Answer

These mechanisms solve adjacent problems. There are scenarios where you need both.

A pre-inspection report might need to establish two separate facts: who conducted the inspection and attested to the findings, and that the condition documented existed before a loss event. Notarization handles the first. A blockchain anchor made at the time of report creation handles the second.

A contract executed before a construction project might need to prove identity and timing. Sign and acknowledge for identity. Anchor the signed document the same day for the temporal record.

They're not competitors. Claims teams that treat them as interchangeable options are asking the wrong question. The question is what you're trying to prove and where each mechanism leaves a gap.

The Window That Closes

The problem with reactive documentation is that the useful window usually closes before anyone realizes it mattered.

Photos taken at a site inspection aren't notarized the day they're shot. Reports aren't anchored because no one was thinking about authentication when the file was saved. The moment of capture passes, and with it the only moment when the temporal claim would be clean.

A notarized affidavit produced during discovery says: "I appeared before this notary recently and attested to these documents." It doesn't say when the documents were created or whether the contents are identical to what was originally captured.

An anchor made at the time of capture says: these bytes existed at this moment. The chain wrote it. No subsequent attestation changes what the record shows.

That's why documentation decisions belong at intake. The anchor has to exist before the dispute, before the claim, before anyone knew the evidence would matter.

Dual-chain anchoring, evidence packs, and a public verify URL for every proof — proofledger.io.

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

Reliable Webhooks for Async Proof Pipelines: Signatures, Idempotency, and Replay Protection

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

You're building a pipeline that anchors files to a blockchain. Files arrive, you hash them, you submit the hash for anchoring, and then you wait. Polygon confirmation might come back in seconds. Bitcoin confirmation runs on a daily batch. Downstream systems (case management software, audit logs, document portals) need to know when confirmation happens. You need webhooks.

But a naive webhook implementation creates new failure modes: duplicate processing, replay attacks, silent failures on retry, and receivers that can't tell a legitimate event from a forged one. Four patterns address all of this.

HMAC-SHA256 Signature Verification

Your receiver needs proof that a webhook came from your system. HMAC-SHA256 ties a signature to both the payload content and a shared secret. If either changes, the signature fails.

On the dispatcher side:

import hashlib
import hmac
import json
import time

WEBHOOK_SECRET = "your-shared-secret"

def sign_payload(payload: dict, secret: str) -> str:
    body = json.dumps(payload, sort_keys=True, separators=(",", ":"))
    return hmac.new(
        secret.encode("utf-8"),
        body.encode("utf-8"),
        hashlib.sha256
    ).hexdigest()

def build_event(event_type: str, data: dict, idempotency_key: str) -> dict:
    return {
        "event": event_type,
        "idempotency_key": idempotency_key,
        "timestamp": int(time.time()),
        "data": data
    }

On the receiver side:

from flask import Flask, request, abort
import hashlib
import hmac

app = Flask(__name__)
WEBHOOK_SECRET = "your-shared-secret"

def verify_signature(payload_bytes: bytes, signature: str, secret: str) -> bool:
    expected = hmac.new(
        secret.encode("utf-8"),
        payload_bytes,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

@app.route("/webhook/proof-confirmed", methods=["POST"])
def handle_proof_confirmed():
    sig = request.headers.get("X-Webhook-Signature", "")
    if not verify_signature(request.data, sig, WEBHOOK_SECRET):
        abort(401)
    # continue processing...
    return "", 200

Two things matter here. First, use hmac.compare_digest() for the comparison, not ==. The constant-time comparison blocks timing attacks where an attacker probes the signature character by character to reconstruct it. Second, serialize with sort_keys=True on the dispatcher side. JSON object key ordering varies across languages and serializers. If the dispatcher and receiver produce different byte sequences from the same dict, signatures that should match won't.

Idempotency Keys

Retries happen. Network connections drop mid-flight. Receivers return a 500 that was actually processed. Your dispatcher re-sends. Without idempotency protection, the same event processes twice and you get duplicate records in your audit log or document management system.

The fix: include a stable idempotency key in every event. Derive it from the underlying fact, not from the delivery attempt. proof_{proof_id}_anchored is stable across retries. A freshly generated UUID per attempt is not.

import redis
from flask import Flask, request, abort

app = Flask(__name__)
r = redis.Redis(host="localhost", port=6379, db=0)
IDEMPOTENCY_TTL = 86400  # 24 hours

@app.route("/webhook/proof-confirmed", methods=["POST"])
def handle_proof_confirmed():
    sig = request.headers.get("X-Webhook-Signature", "")
    if not verify_signature(request.data, sig, WEBHOOK_SECRET):
        abort(401)

    event = request.get_json()
    key = event.get("idempotency_key")
    if not key:
        abort(400)

    cache_key = f"webhook:seen:{key}"
    if r.exists(cache_key):
        return "", 200  # already processed, safe to ack

    r.setex(cache_key, IDEMPOTENCY_TTL, "1")
    process_event(event)
    return "", 200

The TTL keeps your Redis key space from growing indefinitely. Set it to at least as long as your retry window. If you retry for up to 4 hours, a 24-hour TTL gives you a reasonable safety margin.

One edge case: what if the event processes but Redis fails before setex completes? You'd process it again on the next retry. For most use cases this is acceptable (a duplicate audit entry is annoying, not catastrophic). If you need strict exactly-once semantics, wrap the Redis write and the downstream write inside a database transaction instead.

Exponential Backoff with Jitter

When delivery fails, you retry. But if you retry on a fixed schedule and 50 events fail at the same time (a receiver restart, a transient network issue), they all retry simultaneously. That burst can cause the receiver to fail again.

Exponential backoff with jitter spaces retries out:

import requests
import random
import json
import hmac
import hashlib

WEBHOOK_SECRET = "your-shared-secret"

def dispatch_webhook(url: str, payload: dict, max_attempts: int = 5) -> bool:
    body = json.dumps(payload, sort_keys=True, separators=(",", ":"))
    sig = hmac.new(
        WEBHOOK_SECRET.encode("utf-8"),
        body.encode("utf-8"),
        hashlib.sha256
    ).hexdigest()
    headers = {
        "Content-Type": "application/json",
        "X-Webhook-Signature": sig,
    }

    for attempt in range(max_attempts):
        try:
            resp = requests.post(url, data=body, headers=headers, timeout=10)
            if resp.status_code == 200:
                return True
            if resp.status_code in (400, 401, 403):
                return False  # non-retryable
        except requests.RequestException:
            pass

        if attempt < max_attempts - 1:
            delay = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(delay)

    return False

The non-retryable check matters. A 401 means the signature is wrong. Retrying won't fix that. You need to investigate the shared secret or signing logic. A 400 means malformed payload. Only retry on 5xx responses and network errors where the problem might actually resolve.

The jitter term (random.uniform(0, 1)) breaks synchronization across concurrent dispatchers. Without it, multiple workers retrying at the same base delay still hit the receiver in a synchronized wave.

Replay Protection

An attacker who intercepts a valid webhook can replay it later. The payload is signed, but the signature is still valid because neither the secret nor the content changed. For any event that triggers a state change (marking a proof as confirmed, updating a claim record), replay is a real attack surface.

The timestamp window blocks this. Include a Unix timestamp in the payload and reject events where that timestamp falls outside a 5-minute window:

import time
from flask import Flask, request, abort

REPLAY_WINDOW_SECONDS = 300

@app.route("/webhook/proof-confirmed", methods=["POST"])
def handle_proof_confirmed():
    sig = request.headers.get("X-Webhook-Signature", "")
    if not verify_signature(request.data, sig, WEBHOOK_SECRET):
        abort(401)

    event = request.get_json()

    event_ts = event.get("timestamp", 0)
    if abs(int(time.time()) - event_ts) > REPLAY_WINDOW_SECONDS:
        abort(400)

    key = event.get("idempotency_key")
    if not key:
        abort(400)

    cache_key = f"webhook:seen:{key}"
    if r.exists(cache_key):
        return "", 200

    r.setex(cache_key, IDEMPOTENCY_TTL, "1")
    process_event(event)
    return "", 200

The timestamp check and idempotency check cover different attack surfaces. The timestamp window rejects replays from outside 5 minutes. The idempotency key catches exact duplicates within the window. You need both.

Operational note: if your dispatcher and receiver clocks aren't synchronized (NTP drift is common in container environments), you'll get false rejections near the window boundary. Keep the window at 5 minutes minimum, and monitor for 400 errors that correlate with clock skew alerts on your infrastructure.

The Full Event Shape

Here's the payload structure that ties all four patterns together:

event = build_event(
    event_type="proof.anchored",
    idempotency_key=f"proof_{proof_id}_anchored",
    data={
        "proof_id": proof_id,
        "sha256": file_hash,
        "blockchain": "polygon",
        "tx_id": transaction_id,
        "anchored_at": anchored_at_iso,
    }
)

The receiver verifies the signature, checks the timestamp window, checks the idempotency key, then processes. Four checks, one linear code path.

These patterns apply to any async workflow where the triggering action and the confirmation happen at different times on different schedules. Blockchain anchoring is an obvious example because confirmation is inherently network-driven. I use all four in ProofLedger because Polygon and Bitcoin settle on completely different timelines, and the downstream systems that consume proof confirmations can't afford to handle duplicates or forged events.

What's your approach when the event processes successfully but the idempotency write fails? Database transaction around both, a separate dedup table, or something else?

Victor Stanley v. Creative Pipe and the Culpability Gap Blockchain Anchoring Closes

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

The case

Victor Stanley, Inc. v. Creative Pipe, Inc., 269 F.R.D. 497 (D. Md. 2010) is a federal discovery dispute that became one of the most-cited opinions in ESI sanctions law. Creative Pipe failed to preserve electronically stored information after the duty to preserve had clearly attached. Judge Grimm used it to build a systematic framework for courts deciding what sanctions fit what degree of preservation failure.

The framework survived the parties. It's still cited when courts need to calibrate a sanctions response to a specific culpability tier.

What the court held

The opinion mapped each culpability tier from negligence through gross negligence to willful destruction, assigning remedies that scale accordingly. Negligent conduct supports lesser sanctions; willful spoliation opens the door to adverse inference instructions or case-terminating sanctions.

The 2015 amendments to FRCP 37(e) later codified aspects of this graduated approach at the federal level, specifically the intent-to-deprive threshold for adverse inferences. Victor Stanley remains foundational for practitioners in circuits that apply nuanced culpability gradations beyond what 37(e) addresses.

The question courts have to answer

Spoliation disputes come down to two things: what did the party have, and what happened to it after the duty to preserve attached?

The first question is harder than it sounds. Metadata can be altered after the fact. What a custodian says they had on a specific date carries only as much weight as their credibility. File system logs are often ambiguous about the threshold question: did this document exist before the key date?

How a blockchain anchor changes the analysis

A timestamp anchored to a public blockchain doesn't depend on any of that. It's a permanent, independently verifiable record that a specific file hash existed at a specific moment. No custodian testifies to it. No metadata can be retroactively adjusted.

Verification is direct:

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

The response returns the anchor transaction, block height, and timestamp. The record either exists on the ledger or it doesn't.

For Victor Stanley-style disputes, the value is in what that record establishes before litigation begins. An organization that anchors key documents as part of standard retention creates an independent, court-verifiable record of what existed and when. If preservation questions arise, the blockchain record answers them without relying on custodian recollection or contested logs.

Courts can authenticate these records under FRE 901(b)(9), which allows authentication of evidence produced by a process that generates an accurate result. Where self-authentication without live testimony is needed, FRE 902(13) provides a path through written certification.

The culpability gap

The Victor Stanley sanctions framework is calibrated to what a court can actually prove about intent. Willful destruction draws harsher sanctions than negligence because it's harder to prove and more corrosive to the discovery process.

Blockchain anchoring doesn't eliminate spoliation disputes. But it shifts the evidentiary ground. An organization with a pre-loss anchor record can demonstrate what they had, objectively, without asking a court to resolve competing custodian narratives. A party challenging that record has to contend with an immutable public ledger.

The gap Victor Stanley addresses has always existed because proof of timing is genuinely difficult. Anchoring documents as they're created doesn't close that gap entirely, but it changes the nature of the dispute from credibility contest to ledger verification.

Construction Defect Claims and Burden of Proof: What Pre-Loss Documentation Has to Establish

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

Pre-loss documentation · blockchain anchoring · construction defect · FRE 901(b)(9) · FRE 902(13)

Meta description: Nevada's Supreme Court puts the burden on insureds to prove coverage in construction defect claims. Here's what pre-loss documentation has to establish and why. (158 chars)

A contractor finishes a commercial renovation. Three years later, the building owner files a construction defect claim: water intrusion that allegedly began during the original build. The insurer responds with a simple question. Prove when the damage started.

The owner produces photos, inspection records, maintenance logs. Every document was created after the tenant reported a problem. Nothing predates the date the insurer is disputing. The timeline stays open.

This isn't a unique fact pattern. Claims Journal reported this week that the Nevada Supreme Court ruled the insured must prove coverage owed in construction defect litigation. Courts aren't going to resolve timing ambiguity in your favor. The burden sits with the party making the claim. Meeting it requires documentation that was built before the dispute, not assembled after it.

Why After-the-Fact Documentation Fails

Construction defects have long latency. A waterproofing failure doesn't produce visible damage immediately. Water infiltration, settling, mold growth. These emerge over time. By the time a claim is filed, the gap between when the defect allegedly began and when anyone documented it can be years.

Documentation assembled during that gap looks reactive. Photos taken three weeks before the claim was filed don't tell a court anything about what the condition was two years ago. Opposing counsel knows this. So do courts.

File metadata doesn't close the gap either. EXIF timestamps in photos can be changed in under a minute with free software. The date field in a Word document reflects when the file was last saved, not when the condition it describes existed. These are routinely challenged in discovery, and for good reason.

Volume doesn't help if the timing is wrong. A thousand photos with contested timestamps isn't stronger documentation than ten photos with verifiable ones.

What Pre-Loss Documentation Has to Prove

The shift that matters is not how much you document. It's when you establish a verifiable record.

Documentation created before a dispute, before a claim, before a problem is reported: this exists independently of any litigation motive. That independence matters. Courts ask whether the process that produced the timestamp is reliable. Not whether you have a lot of records. Whether the records can be authenticated as existing when you say they did.

FRE 901(b)(9) allows authentication of evidence produced by "a process or system that produces an accurate result." That's the evidentiary framework for blockchain-anchored timestamps. But 901(b)(9) requires a foundation: usually expert testimony or a qualified certification explaining the anchoring process. It doesn't self-authenticate.

For that, you want FRE 902(13). Under 902(13), a written certification from a qualified person establishes authenticity without live testimony. No expert on the stand. No deposition. The certification itself does the work at trial.

Know which rule you're relying on before a dispute arises. Building documentation around 902(13) compliance means generating the right certification materials at anchoring time, not trying to reconstruct them two years later in discovery.

How Blockchain Anchoring Works

ProofLedger computes a SHA-256 hash of any file and records that hash on two independent blockchains. Polygon confirms the anchor instantly. Bitcoin anchors run daily via batch, connecting individual file hashes to confirmed Bitcoin blocks through merkle proofs. Two chains, two independent verification paths, one workflow.

The file never leaves the device. Only the hash goes on-chain. A SHA-256 hash is a fixed-length fingerprint of the file's contents at that moment. If a single byte changes, the hash changes. Which means an anchored hash proves the file existed, unchanged, at the time it was anchored.

Each anchor produces a public verify URL. Opposing counsel can check it. An expert witness can check it. An auditor can check it. No account required. The result is either "hash found, anchored at this time on these chains" or "hash not found." There's no version of that answer that can be gamed after the fact.

Bitcoin's proof-of-work immutability is the deeper layer. Altering a Bitcoin block requires redoing the computational work of every subsequent block in the chain. That's not a practical attack. It means a hash anchored to Bitcoin stays anchored, regardless of what happens to the original file.

Practical Documentation Workflow for Construction Defect Exposure

The point of failure in most construction defect documentation isn't the absence of records. It's when the records were made.

Before construction begins, document the existing property condition. Site photos, deficiencies already present, condition assessments. Anchored at the time of inspection, this establishes a baseline that predates any claimed defect. If water intrusion was already present before the contractor arrived, that's a fact the baseline can establish.

During construction, anchor documentation at milestones. Structural inspections, waterproofing layers before they're covered up, punch list completion. Each anchored set creates a sequential record of what was done and when.

After any complaint or remediation, anchor immediately. The timestamp on the anchor is the evidentiary fact. Documenting a repair thoroughly and anchoring two weeks later loses the benefit. The gap is the problem.

Evidence packs organize anchored files by case, claim, or matter, with loss dates and pre/post indicators. When a claim arrives, the timeline is already structured rather than scattered across drives and email threads with contested metadata.

When the Insured's Burden Changes the Calculation

Construction defect litigation is slow. Discovery windows are long. Documentation that looked adequate at claim filing can look thin three years in, when opposing counsel has worked through every metadata field and every file creation date.

The Nevada ruling is a useful frame for how courts approach this. The insured must prove coverage owed. That means proving not just what the condition was, but when it existed relative to the policy period. An adjuster's inspection report that can't be placed in time is documentation without authentication. It shows something. It doesn't prove when.

An anchored inspection report, site photos anchored the day they were taken, a maintenance log anchored the day it was written: these aren't just evidence. They're verifiable facts on two independent public ledgers. The same answer comes back for both parties. That's what neutral temporal authority means in practice. The timestamp isn't a claim someone is making. It's a mathematically settled fact.

Documentation assembled after the fact is documentation assembled under litigation motive. Courts understand this distinction. Anchored records that predate any dispute don't carry that problem.

If your workflow involves construction defect exposure, the time to build the record is before anything goes wrong. Anchor before the loss, not after. Risk documentation, not claim documentation.

Start documenting your construction projects before disputes arise at proofledger.io

The Original File Problem: What FRE 1002 Actually Requires When Digital Evidence Is Disputed

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

Picture this: an adjuster photographs storm damage on day one. Three months later, those photos live on a carrier's cloud backup. At deposition, opposing counsel asks whether the photos produced in discovery are the originals or backup copies. The adjuster can't say with certainty. The phone was replaced. The cloud platform may have applied compression. Opposing counsel moves to exclude on best-evidence grounds.

This is the FRE 1002 problem for digital evidence. It comes up more than practitioners expect.

What the Best Evidence Rule Requires

FRE 1002 states that to prove the content of a writing, recording, or photograph, the original is required.

FRE 1001(d) defines "original" for electronic evidence: the recording itself, or any counterpart intended to have the same effect. A digital photograph is its original byte sequence. A compressed copy, a re-encoded version, or a file that passed through a platform's processing pipeline may or may not be the same item.

FRE 1003 provides practical relief: a duplicate is admissible to the same extent as an original unless a genuine question is raised about the original's authenticity, or admission would be unfair. Courts don't exclude duplicates automatically. But once opposing counsel raises a credible authenticity question, the burden shifts to the proponent to answer it.

FRE 1004 allows other evidence when the original has been lost without bad faith, is unobtainable through judicial process, or is in an opponent's possession. None of these provisions resolve the core problem: when the proponent can't establish that the file they're offering is byte-for-byte identical to what they originally captured, the authentication question stays open.

Where Digital Evidence Creates the Gap

The gap isn't usually fraud. It's workflow.

A claims professional photographs a flooded warehouse. The photos go from camera roll to email to a shared drive to a claims management system. Each step is an opportunity for platform compression, automatic re-encoding, or metadata stripping. By the time litigation starts two years later, the "original" may not exist on any accessible device. What's available is a cascade of copies.

Under FRE 1003, any of those copies can be attacked. Opposing counsel doesn't need to prove the copies were tampered with. They need to raise a genuine question. That question is easy to raise when the chain between device and courtroom has several unmonitored steps.

And most claims workflows have no point where anyone asks: is this still the file we started with?

The file doesn't remember.

What a Hash Establishes

A SHA-256 hash is deterministic. The same file always produces the same hash. A file that has changed by even one byte produces a completely different hash. This is not metadata. It's not a field someone typed into the file's header. A hash is a mathematical output derived from the entire byte sequence of the file.

When a file is hashed and that hash is anchored to a public blockchain, two things become independently verifiable later: the exact byte content of the file at the time of anchoring, and when that hash was committed to the chain.

When the file is produced in discovery, hash it again. If the output matches the on-chain record, the authenticity question under FRE 1003 has an answer. The file hasn't changed. Not one byte. That's math, not testimony.

I built ProofLedger to anchor hashes to both Polygon and Bitcoin because single-chain verification leaves the process-reliability argument on a single foundation. Two independent public ledgers, both recording the same hash, make the FRE 901(b)(9) case considerably stronger. The public verify endpoint at proofledger.io/verify.html is accessible to any third party without authentication, which matters when opposing counsel or a court-appointed examiner wants to check the hash independently.

Laying the Authentication Foundation

Introducing a hash comparison at trial requires its own evidentiary foundation. FRE 901(b)(9) is the mechanism: authentication via evidence produced by a process or system that generates an accurate result. The blockchain anchoring process, with deterministic cryptographic operations and a public ledger record, fits that framework.

FRE 902(13) allows self-authentication of machine-generated records via written certification, eliminating the need for live expert testimony. That matters in budget-constrained litigation where an expert deposition is a real cost.

This isn't automatic. The proponent still needs to establish what SHA-256 does, what the blockchain record represents, and how the verification process works. But that foundation is available and defensible. EXIF metadata doesn't have an equivalent foundation. It can be changed after the fact. The on-chain hash record cannot.

What This Means Monday Morning

Three practical steps:

Hash and anchor at capture. The gap between file creation and anchoring is the gap opposing counsel will attack. Don't wait until the claim is filed.

Keep the original file. The hash proves the file hasn't changed, but only if the original still exists to re-hash. Platform compression shouldn't be the only surviving copy.

Brief your documentation team on the FRE 1003 attack surface. The question "is this the original file?" should have a reliable answer at every stage of a claim. In most workflows right now, it doesn't.

The best evidence rule was designed for paper. Digital files have properties paper doesn't: they copy silently, platforms alter them without notice, and the chain between capture and courtroom is long. An on-chain hash is the one thing that can answer the original-versus-copy question with something other than "I think so."

How to Create Tamper-Proof Records for Pre-Loss Documentation

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

An attorney receives a document production request. Among the files: 200 photos the property owner claims were taken before the loss. The file timestamps say what they say. But file timestamps can be changed in seconds by anyone with basic computer access.

That's the problem with digital evidence right now. The evidence may be genuine. The documentation around it almost certainly isn't verified. When the dispute hits discovery, chain of custody becomes the entire argument.

ProofLedger was built for this gap: pre-loss documentation that creates a verifiable record before anyone disputes the timeline.

When you anchor a file in ProofLedger, the original document never leaves your device. The platform generates a SHA-256 hash of the file, a mathematical fingerprint unique to that exact file at that exact moment. That hash gets anchored to two public blockchains: Polygon for instant confirmation, and Bitcoin's proof-of-work network for daily batch anchoring with merkle proofs.

The result is a tamper-proof record that exists independently of the file itself. You can't change it, no platform can strip it, and no format conversion can corrupt it.

Chain of custody for digital evidence has always had a weak link: proving when a file was captured. File metadata is mutable. Cloud storage timestamps depend on server accuracy, screenshots can be backdated, and neither method produces a record on a ledger that no party to the dispute controls. A blockchain timestamp works differently. The anchor transaction appears on a public ledger at a specific block height, in sequence with every other transaction before and after it. That sequence cannot be altered without rewriting the entire chain.

For evidence authentication purposes, blockchain records can be authenticated under FRE 901(b)(9) as output from a process that produces an accurate result. FRE 902(13) allows machine-generated records to be self-authenticated through written certification, without requiring live expert testimony in every proceeding.

Evidence preservation before the loss is where this matters most. A risk manager who photographs a facility hazard in February needs to prove those photos existed before the March incident. For an insured documenting property condition before a storm, the same question: can you prove the record predates the claim? A blockchain anchor answers that question on a public ledger no party controls.

Evidence packs in ProofLedger let you organize blockchain evidence by case, matter, or claim, with loss dates and pre/post indicators built in. When files get produced in discovery, the anchor transaction travels with them.

A property manager documents roof condition before tenant occupancy. Photos, inspection reports, contractor notes: all anchored. Six months later, the tenant claims pre-existing damage. The property manager's files show what the roof looked like before occupancy. The blockchain anchor proves the record predated move-in. Chain of custody intact. Timeline verified.

That's what tamper-proof records provide. Not a claim the evidence is authentic. A cryptographic proof on a public ledger that anyone can verify independently.

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

Pippins v. KPMG: Proportional Preservation and the Gap Anchoring Fills

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

The case

In Pippins v. KPMG LLP, 279 F.R.D. 245 (S.D.N.Y. 2012), former audit associates brought a class action alleging KPMG violated the Fair Labor Standards Act. As discovery opened, plaintiffs sought a preservation order requiring KPMG to retain the individual hard drives of every former associate whose work might fall within the relevant period. The scope question reached Magistrate Judge Cott.

What the court held

Magistrate Judge Cott declined to require that level of preservation. The court held that preservation obligations must be proportional to the case's needs, the relevance of what's being preserved, and the burden on the party required to preserve it. Pippins remains a frequently cited limiting principle on sweeping hardware retention demands, standing for the proposition that courts won't impose preservation costs disproportionate to the likely evidentiary value of the material.

Where blockchain anchoring fits

The Pippins holding is practically sensible. Requiring a company to warehouse hundreds of individual hard drives from former employees, potentially for years, would impose costs that courts are right to check. But the limiting principle carries a cost of its own. When physical media isn't preserved under a proportionality ruling, what's lost isn't just the hardware. The authentication record for what was on that hardware becomes dependent on secondary evidence. And secondary evidence, in litigation where file content or timing is contested, is a harder argument than a verifiable artifact that predates the dispute.

SHA-256 hash anchoring doesn't preserve the drive. It creates a permanent, on-chain record that a specific file, with specific byte-level content, existed at a documented moment. That record goes to Polygon for near-immediate confirmation and to Bitcoin in a daily batch with merkle proofs. Both chains are public and independently verifiable at proofledger.io. The proof lives on the ledger regardless of what happens to the original hardware.

What the anchor establishes: file integrity (the content is byte-for-byte unchanged from the moment of anchoring) and a timestamp (the hash was recorded before or after a given date). What it doesn't establish: that the file still exists in its current form, or that the content is accurate. The authentication argument for a blockchain record runs under FRE 901(b)(9), which allows evidence produced by a process that generates an accurate result to be authenticated by foundation describing how that process works. The SHA-256 algorithm and the dual-chain anchoring mechanism are the process. The on-chain transaction record is the output.

For third-party verification without any platform dependency, the verify-proof Python package supports fully offline checks. It takes a local file and a proof record, computes the SHA-256 hash locally, and confirms or rejects the match against the on-chain record. Opposing counsel and auditors can run that verification independently. Nothing requires trusting a portal.

Take the Pippins scenario to its logical end. If KPMG's former associates had anchored their work files at creation, the court's proportionality ruling on hardware retention would be unchanged. What would be different: the authentication record wouldn't depend on the hardware decision. The hash anchor exists on a public blockchain. Whether the drive was preserved becomes a separate question from whether the file's content is independently verifiable.

The takeaway for practitioners

Proportional preservation doctrine protects parties from unreasonable retention burdens. But it doesn't generate the authentication record you need when the original media is gone and the content is disputed. FRE 902(14) allows authentication of electronic data identified by hash value through written certification. FRE 901(b)(9) supports the process reliability argument for blockchain records. Anchoring file hashes before any preservation duty attaches keeps practitioners out of the FRCP 37(e) sanctions analysis entirely, because the authentication record doesn't live on hardware subject to proportionality limits. It lives on a public ledger, independent of any retention decision.

References

Pippins v. KPMG LLP, 279 F.R.D. 245 (S.D.N.Y. 2012)
FRE 901(b)(9): authentication based on process or system producing accurate result
FRE 902(14): self-authentication of electronic data identified by hash value
FRCP 37(e): sanctions for failure to preserve electronically stored information

Chain of Custody Gaps in Digital Evidence: How Blockchain Timestamps Close Them

Craig Solomon — Tue, 30 Jun 2026 00:05:00 +0000

A risk manager documents a parking lot hazard in March. Cracks in the asphalt, photographed and filed in a SharePoint folder. Six months later, a slip-and-fall claim arrives. The plaintiff's attorney argues the damage was present for over a year and the property owner failed to act.

The risk manager has photos. File metadata can be altered. A SharePoint timestamp isn't evidence. ProofLedger exists for exactly this gap: blockchain timestamps that prove when digital evidence existed, on a public ledger that nobody controls.

This is the core problem with evidence preservation in insurance and legal work. The documentation exists. The dates exist. But without a tamper-proof record tied to an independent source, the evidence can be challenged at any time.

Here's how the workflow runs. Drag site inspection files into the platform and it generates a SHA-256 hash of each one, then anchors that hash to two public blockchains: Polygon for instant confirmation within seconds, and Bitcoin for proof-of-work immutability on the oldest continuously running decentralized network. Your original files never leave your device. Only the hash goes on-chain. What comes back is a blockchain evidence record with a timestamp nobody can alter after the fact.

For evidence authentication in litigation, courts can admit blockchain-anchored records under FRE 901(b)(9), which covers evidence produced by a process or system that generates an accurate result. Under FRE 902(13), machine-generated records can be self-authenticated through written certification. No live expert testimony required. That distinction matters when a claims team is trying to resolve a dispute without scheduling a forensics expert.

Files can be organized into evidence packs by case, claim, or matter, with each item marked as pre-loss or post-loss. That structure makes the chain of custody readable during discovery, without reconstructing a timeline from individual file dates.

Pre-loss documentation is the use case this workflow was built for. A risk manager runs site inspection photos through the anchoring process before filing anything. A public adjuster anchors their scene documentation on arrival, before remediation starts. A contractor photographs completed work and anchors it at project close. Each anchor is a blockchain evidence record that predates any future dispute.

The distinction between pre-loss and post-loss records is often the dispute itself. Chain of custody gaps don't show up until someone challenges the timeline. By then, going back to establish when the evidence actually existed isn't an option.

Standard file metadata doesn't hold under adversarial conditions. It's editable by design. Forensic witnesses can testify to that, which means every unanchored file is a potential vulnerability in a coverage dispute or a litigation timeline.

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

Batch File Anchoring in Python: Concurrency, Rate Limits, and Resumable Progress

Craig Solomon — Tue, 30 Jun 2026 00:00:04 +0000

You have a directory of evidence files that need blockchain-anchored timestamps. Maybe it's a pre-loss documentation archive. Maybe it's a set of site inspection photos captured before a dispute filed.

A for-loop over the directory will work until it doesn't. Hit a rate limit, crash without saving state, and you're starting over with no record of what actually made it through.

This is the worker pattern I'd reach for when bulk archiving through ProofLedger's v1 API. Three things the naive loop skips: concurrent submissions, 429 backoff that reads the Retry-After header, and resumable progress so a crash doesn't reset the whole job.

Hash First, Then Submit

The ProofLedger v1 API anchors a SHA-256 digest, not the file itself. The file stays on your machine. Step one is always local hashing.

import hashlib

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

Chunked reads keep memory flat regardless of file size. A 4GB video and a 10-page PDF go through the same function.

The base API call takes the digest in the request body, with your API key in the Authorization header.

import requests

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

def anchor_hash(digest: str, filename: str) -> dict:
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    }
    payload = {"sha256": digest, "filename": filename}
    resp = requests.post(API_URL, json=payload, headers=headers, timeout=30)
    resp.raise_for_status()
    return resp.json()

That's fine for a single file. A batch job needs real error handling on top.

Handling 429s

The API is rate-limited. When you're submitting files concurrently, you'll hit 429s. The right response is to back off and retry, reading the Retry-After header rather than guessing.

import time

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

    for attempt in range(6):
        try:
            resp = requests.post(API_URL, json=payload, headers=headers, timeout=30)
        except requests.RequestException:
            if attempt == 5:
                raise
            time.sleep(2 ** attempt)
            continue

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

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

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

        time.sleep(2 ** attempt)

    raise RuntimeError(f"Anchoring failed for {filename} after 6 attempts")

The 400/401/403 group is non-retryable. A 400 means your hash is malformed. A 401 or 403 means your key is wrong or on the wrong plan tier. Retrying those wastes time and burns rate limit. The requests.RequestException branch handles network timeouts and connection drops separately from HTTP status codes.

Six attempts is enough ceiling to clear a sustained rate-limit window without hanging the job indefinitely.

Concurrency

ThreadPoolExecutor with five workers gets you parallel submissions without hammering the endpoint hard enough to trigger a flood of 429s.

The choice of as_completed over executor.map matters here. With executor.map, you'd have to wait for all futures before processing any results. With as_completed, each resolved future triggers a disk write immediately. If the script crashes, you restart and pick up where the last successful write landed.

from concurrent.futures import ThreadPoolExecutor, as_completed
from pathlib import Path

MAX_WORKERS = 5

def process_file(path: Path) -> tuple:
    digest = hash_file(str(path))
    result = anchor_hash(digest, path.name)
    return str(path), digest, result

Five concurrent threads also keeps log output readable. Bump MAX_WORKERS to 20 and you get 20 interleaved error messages whenever something goes wrong.

Resumable Progress

Write to disk after every successful anchor. Every one. The progress file is cheap to write; restarting an entire archive job is not.

import json

PROGRESS_FILE = "anchor_progress.json"

def load_progress() -> dict:
    p = Path(PROGRESS_FILE)
    return json.loads(p.read_text()) if p.exists() else {}

def save_progress(progress: dict) -> None:
    Path(PROGRESS_FILE).write_text(json.dumps(progress, indent=2))

The progress dict is keyed by file path. Each entry stores the SHA-256 digest, proof ID, status, and certificate URL. Any path already in the file is skipped on startup.

One caveat: this assumes files in your archive are immutable after capture. If a file might get overwritten between runs, you'd want to re-hash and compare the stored digest before deciding to skip.

The duplicate_of Response

If you submit a hash that's already been anchored, the API returns a duplicate_of field pointing to the original proof ID.

It can come from multiple places. Two team members photographing the same document separately. A file copied into multiple subdirectories before ingestion. The same report exported under two filenames.

When you see duplicate_of, the original proof is canonical. Don't create a new anchor for identical bytes.

def record_result(progress: dict, key: str, digest: str, result: dict) -> None:
    entry = {
        "sha256": digest,
        "proof_id": result.get("id"),
        "status": result.get("status"),
        "certificate_url": result.get("certificate_url"),
    }
    if result.get("duplicate_of"):
        entry["duplicate_of"] = result["duplicate_of"]
        print(f"  Duplicate: {Path(key).name} -> original {result['duplicate_of']}")
    else:
        print(f"  Anchored: {Path(key).name} -> {result.get('id')}")

    progress[key] = entry
    save_progress(progress)

The certificate_url from the original anchor is what you'd attach for chain-of-custody documentation. The duplicate_of field gives you the ID to find it.

Full Script

import hashlib
import json
import time
import requests
from concurrent.futures import ThreadPoolExecutor, as_completed
from pathlib import Path

API_URL = "https://proofledger.io/api/v1/proof"
API_KEY = "sk_YOUR_KEY_HERE"
PROGRESS_FILE = "anchor_progress.json"
MAX_WORKERS = 5


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


def load_progress() -> dict:
    p = Path(PROGRESS_FILE)
    return json.loads(p.read_text()) if p.exists() else {}


def save_progress(progress: dict) -> None:
    Path(PROGRESS_FILE).write_text(json.dumps(progress, indent=2))


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

    for attempt in range(6):
        try:
            resp = requests.post(API_URL, json=payload, headers=headers, timeout=30)
        except requests.RequestException:
            if attempt == 5:
                raise
            time.sleep(2 ** attempt)
            continue
        if resp.status_code == 201:
            return resp.json()
        if resp.status_code == 429:
            time.sleep(int(resp.headers.get("Retry-After", 60)))
            continue
        if resp.status_code in (400, 401, 403):
            raise ValueError(f"{resp.status_code}: {resp.text}")
        time.sleep(2 ** attempt)

    raise RuntimeError(f"Failed: {filename}")


def record_result(progress: dict, key: str, digest: str, result: dict) -> None:
    entry = {
        "sha256": digest,
        "proof_id": result.get("id"),
        "status": result.get("status"),
        "certificate_url": result.get("certificate_url"),
    }
    if result.get("duplicate_of"):
        entry["duplicate_of"] = result["duplicate_of"]
        print(f"  Duplicate: {Path(key).name} -> original {result['duplicate_of']}")
    else:
        print(f"  Anchored: {Path(key).name}")
    progress[key] = entry
    save_progress(progress)


def main(directory: str) -> None:
    progress = load_progress()
    pending = [
        f for f in Path(directory).rglob("*")
        if f.is_file() and str(f) not in progress
    ]
    print(f"Pending: {len(pending)}")

    def process(path: Path) -> tuple:
        digest = hash_file(str(path))
        result = anchor_hash(digest, path.name)
        return str(path), digest, result

    with ThreadPoolExecutor(max_workers=MAX_WORKERS) as pool:
        futures = {pool.submit(process, f): f for f in pending}
        for future in as_completed(futures):
            f = futures[future]
            try:
                key, digest, result = future.result()
                record_result(progress, key, digest, result)
            except Exception as e:
                print(f"  Error: {f.name}: {e}")


if __name__ == "__main__":
    main("./evidence-archive")

What to Run Next

The progress file is useful beyond crash recovery. Once the batch finishes, parse it to pull all certificate_url values for a summary report. Filter for duplicate_of entries to find which files in your archive have identical content.

For third-party verification, the GET /api/v1/verify?hash=<sha256> endpoint is public and requires no authentication. Opposing counsel, auditors, or anyone with the original file can independently confirm the anchor. It's rate-limited to 120 requests per hour per IP, which is plenty for verification workflows.

For offline verification against a saved proof JSON, the verify-proof package handles that without any network calls.

When Evidence Timing Becomes the Dispute

Craig Solomon — Tue, 30 Jun 2026 00:00:03 +0000

A commercial property claim crosses your desk. Water damage to a server room, tenant says it happened during last Tuesday's storm. The property manager provides photos showing the damage, but the timestamps show they were taken three days before the storm hit.

Now what started as a straightforward water damage claim becomes a timing dispute. Did the damage exist before the storm? Was the tenant aware of a pre-existing leak? The photos exist, but proving when they were captured becomes the central issue.

This is where blockchain timestamping changes the game. ProofLedger anchors SHA-256 file hashes to both Polygon and Bitcoin blockchains, creating immutable proof that evidence existed at a specific point in time. The original files never leave your device. Only the cryptographic hash gets anchored to the blockchain.

Here's how the workflow actually works. A property manager documents a site visit by uploading photos to ProofLedger. The system generates a SHA-256 hash of each file and anchors that hash to Polygon for instant confirmation, then to Bitcoin in daily batches with merkle proof verification.

When the claim becomes disputed months later, the blockchain anchor provides neutral temporal authority. The hash on the blockchain matches the hash of the original file, proving it existed at the recorded timestamp. No party can alter the blockchain record. It would require attacking Bitcoin's network, a multi-billion dollar impossibility, to alter a single timestamp.

Court Authentication Under Federal Rules

Courts can authenticate blockchain records under FRE 901(b)(9), which allows authentication of evidence produced by a process that generates an accurate result. The rule requires laying a foundation through expert testimony or written certification, but once established, the blockchain timestamp carries the same weight as any other authenticated record.

For self-authentication without live testimony, FRE 902(13) and FRE 902(14) cover machine-generated records through written certification. These rules, added in 2017, recognize that reliable automated systems can produce court-ready evidence without requiring the operator to testify in person.

The key is establishing that the blockchain process itself is reliable. Bitcoin's consensus mechanism and cryptographic security provide exactly that foundation. The network has operated continuously since 2009 without successful attacks on its timestamp integrity.

Beyond Water Damage Claims

Evidence timing disputes appear across the industry. Roofing claims where storm damage gets attributed to pre-existing wear. Construction defect cases where the question becomes whether photos document the original installation or later repairs. Fire investigations where the sequence of documentation affects subrogation recovery.

A blockchain anchor removes the guesswork. The timestamp becomes a mathematical fact, not a disputable metadata field that can be altered in post-processing.

The dual-chain approach matters here. Polygon provides instant confirmation for time-sensitive documentation. Bitcoin provides long-term immutability through its proof-of-work security model. Evidence packs organize the proof by claim, case, or matter, with clear pre-loss and post-loss categorization.

That commercial water damage claim? With blockchain timestamping, the timing question gets resolved in discovery, not at trial. The photos either have valid pre-storm timestamps or they don't. The blockchain record provides the neutral authority both sides can accept.

Chain of custody just got a mathematical backbone.

Apple v. Samsung: How Institutional Processes Triggered an Adverse Inference

Craig Solomon — Mon, 29 Jun 2026 23:45:09 +0000

The case

Apple Inc. v. Samsung Electronics Co., 888 F. Supp. 2d 976 (N.D. Cal. 2012) was a patent infringement action in which Apple moved for sanctions based on Samsung's failure to preserve relevant evidence. After the duty to preserve attached, Samsung continued operating automatic email deletion routines without implementing adequate litigation holds for employees likely to possess responsive communications. The sanctions motion placed Samsung's organizational response to the hold obligation under scrutiny, not the conduct of any individual custodian.

What the court held

Judge Lucy Koh imposed an adverse-inference instruction, finding that Samsung's failure to suspend routine deletion policies after the preservation duty attached was sanctionable under the federal common law spoliation framework then in effect. The ruling made clear that systemic institutional failure could generate liability without proof that any individual deliberately destroyed evidence. The 2015 amendment to FRCP 37(e) subsequently raised the bar: courts now require a finding that the party acted with "intent to deprive" before imposing an adverse inference, a threshold the pre-amendment negligence standard Judge Koh applied in 2012 did not require.

Where blockchain anchoring fits

The Apple-Samsung sanctions motion illustrates a preservation failure that exists upstream of any individual's choices. Documents weren't deleted because someone decided to delete them. They were deleted because institutional systems kept running on schedule after they should have stopped. The company's own infrastructure became the mechanism of loss.

A blockchain anchor operates entirely outside those institutional systems. Anchoring a SHA-256 hash to Polygon and Bitcoin creates a record on public, immutable ledgers that no internal deletion routine can reach. A system can remove the underlying file. It cannot alter a transaction already confirmed on two independent chains. The record of the file's existence, and its exact content at the time of anchoring, persists regardless of what any company-side system does next.

What an anchor proves is bounded and specific. It proves that a file producing that exact hash existed at the moment of anchoring. Content integrity too: any modification produces a completely different hash. What it doesn't prove is that the original file still exists, or that its contents are factually accurate. Those are distinct questions, and a blockchain timestamp doesn't resolve either of them.

This distinction matters for sanctions analysis. If files were anchored before the deletion routine ran, the hashes on-chain establish that those files existed at a specific point in time with specific content. The files are still gone. But the anchors document the prior existence and the exact state of the content, which is relevant to evaluating prejudice under FRCP 37(e)(1). A party seeking curative measures can point to the on-chain record to establish the scope of what was lost. A party defending against sanctions can demonstrate that the content existed and was preserved in hash form before the deletion occurred.

Verification doesn't require cooperation from the party whose systems are under examination. The public endpoint at https://proofledger.io/api/v1/verify?hash=<sha256> returns proof status, chain transaction IDs, and explorer URLs without authentication. For entirely offline verification, the verify-proof Python package performs the same check against on-chain data without contacting any ProofLedger servers. In a case where one party's infrastructure is itself under scrutiny, the ability to verify through a process that neither party controls is directly relevant to reliability under FRE 901(b)(9).

The dual-chain structure adds corroboration. Polygon provides near-instant finality. Bitcoin's daily batch anchoring uses merkle proofs that let any verifier confirm a specific hash's inclusion in a Bitcoin transaction. Two independent chains, neither controlled by the anchoring party, corroborating the same timestamp: that is the kind of process reliability FRE 901(b)(9) addresses.

The takeaway for practitioners

Apple v. Samsung established that courts will examine institutional preservation processes, not just individual conduct, when assessing sanctions for ESI loss. Under FRCP 37(e)(1), courts retain authority to impose curative measures proportionate to prejudice even where intent to deprive can't be shown. An anchor doesn't replace a litigation hold or restore a deleted document. What it creates is an independent, verifiable record of prior existence on a public chain that institutional processes cannot retroactively alter. For admissibility, FRE 901(b)(9) covers authentication of evidence from a process or system that generates an accurate result. Where self-authentication without live testimony is available, FRE 902(13) permits written certification of machine-generated records.

References

Apple Inc. v. Samsung Electronics Co., 888 F. Supp. 2d 976 (N.D. Cal. 2012)
FRCP 37(e) (2015 amendment): ESI preservation, curative measures, and adverse-inference standard
FRE 901(b)(9): Authentication of evidence from a process or system producing an accurate result
FRE 902(13): Self-authentication of machine-generated records via written certification