DEV Community: Craig Solomon

Auto-Hash Every File That Hits Your Folder

Craig Solomon — Thu, 07 May 2026 08:59:54 +0000

Auto-Hash Every File That Hits Your Folder

I needed a way to hash files the second they hit my machine. Not when I remember to do it. Not after I've already shared them. The moment they land.

The pattern's simple: watch a folder, hash anything new, store the hash. Later you can anchor those hashes to a blockchain for timestamps. But first you need the hashes captured automatically.

Here's the Python script that does it.

The Watchdog + Hash Pipeline

Two pieces: watchdog monitors filesystem events, verify-proof handles the SHA-256 hashing.

pip install watchdog verify-proof

The watchdog library fires events when files get created, modified, or deleted. We catch the "created" event and immediately hash the new file:

import os
import json
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
from verify_proof import hash_file
from datetime import datetime

class HashHandler(FileSystemEventHandler):
    def __init__(self, watch_folder):
        self.watch_folder = watch_folder
        self.hash_log = os.path.join(watch_folder, '.file_hashes.json')
        self.hashes = self.load_existing_hashes()

    def load_existing_hashes(self):
        if os.path.exists(self.hash_log):
            with open(self.hash_log, 'r') as f:
                return json.load(f)
        return {}

    def save_hashes(self):
        with open(self.hash_log, 'w') as f:
            json.dump(self.hashes, f, indent=2)

    def on_created(self, event):
        if not event.is_directory and not event.src_path.endswith('.file_hashes.json'):
            self.hash_new_file(event.src_path)

    def hash_new_file(self, filepath):
        try:
            file_hash = hash_file(filepath)
            relative_path = os.path.relpath(filepath, self.watch_folder)

            self.hashes[relative_path] = {
                'sha256': file_hash,
                'hashed_at': datetime.now().isoformat(),
                'size_bytes': os.path.getsize(filepath)
            }

            self.save_hashes()
            print(f"Hashed: {relative_path} -> {file_hash[:16]}...")

        except Exception as e:
            print(f"Failed to hash {filepath}: {e}")

The handler stores everything in a .file_hashes.json file inside the watched folder. Each file gets its SHA-256, timestamp, and size recorded.

Running the Watcher

The main loop starts the observer and keeps it running:

def start_watching(folder_path):
    if not os.path.exists(folder_path):
        os.makedirs(folder_path)
        print(f"Created watch folder: {folder_path}")

    handler = HashHandler(folder_path)
    observer = Observer()
    observer.schedule(handler, folder_path, recursive=True)

    observer.start()
    print(f"Watching {folder_path} for new files...")
    print("Press Ctrl+C to stop")

    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        observer.stop()
        print("\nStopping watcher...")

    observer.join()

if __name__ == "__main__":
    import sys
    import time

    watch_folder = sys.argv[1] if len(sys.argv) > 1 else "./watched_files"
    start_watching(watch_folder)

Run it with:

python file_watcher.py /path/to/your/folder

Drop a file into the folder and you'll see:

Hashed: photo_001.jpg -> a1b2c3d4e5f67890...

The script runs until you Ctrl+C it. It catches subdirectories too if you've got nested folders.

What the Hash Log Looks Like

After dropping a few files, your .file_hashes.json looks like this:

{
  "photo_001.jpg": {
    "sha256": "a1b2c3d4e5f67890abcdef1234567890abcdef1234567890abcdef1234567890",
    "hashed_at": "2026-05-07T14:30:15.123456",
    "size_bytes": 2048576
  },
  "documents/contract.pdf": {
    "sha256": "b2c3d4e5f67890a1abcdef1234567890abcdef1234567890abcdef1234567890",
    "hashed_at": "2026-05-07T14:31:22.789012",
    "size_bytes": 1024000
  }
}

Each entry proves the file existed at that hash on that timestamp. The hash is what you'd anchor to a blockchain later.

Verification Against Existing Proofs

If you've already got blockchain timestamp proofs for some files, you can verify them against your hash log:

from verify_proof import load_proof, verify_proof

def verify_existing_proof(hash_log_path, proof_path):
    with open(hash_log_path, 'r') as f:
        hashes = json.load(f)

    proof = load_proof(proof_path)

    # Find the file that matches this proof
    for filepath, data in hashes.items():
        if data['sha256'] == proof.get('hash'):
            result = verify_proof(data['sha256'], proof)

            if result['verified']:
                print(f"✓ {filepath} verified against blockchain proof")
                print(f"  Anchored: {result['anchored_at']}")
                print(f"  Chain: {result['blockchain']}")
            else:
                print(f"✗ {filepath} failed verification: {result.get('error')}")
            return

    print("No matching file found for this proof")

This connects your local hash log with blockchain timestamp proofs you've collected.

What's Next

This script handles the "capture everything" part. For the blockchain anchoring, you'd take the hashes from your log file and submit them through a timestamping service.

The pattern scales: point this at your photo import folder, your Git hooks directory, or anywhere files show up that you need timestamped later. The hashes get captured immediately, even if you're offline when the files arrive.

You can extend it to filter file types, skip temporary files, or trigger different actions based on file extensions. The core loop stays the same: watch, hash, log.

Offline Verification of Blockchain-Anchored Files: A Forensic Workflow

Craig Solomon — Thu, 07 May 2026 08:42:16 +0000

Offline Verification of Blockchain-Anchored Files: A Forensic Workflow

A claims adjuster uploads photos from a loss site. The blockchain anchor proves they existed before the storm hit. But how do you actually verify that proof without calling external APIs? You need local verification that works offline.

That's what I built the verify-proof package for. Hash a file, check it against a blockchain proof, get a clear verified/not-verified result. No network calls required.

Install and Hash Files

The package gives you both CLI tools and Python functions. Start with installation:

pip install verify-proof

The CLI can hash any file:

verify-proof hash document.pdf
# SHA256: a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456
# File: document.pdf

In Python, use hash_file() for the same thing:

from verify_proof import hash_file

# Hash any file type
file_hash = hash_file("evidence.jpg")
print(f"SHA256: {file_hash}")
# SHA256: a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456

The function returns a 64-character hex string. Same algorithm the blockchain anchors use.

Working with Proof Dictionaries

Blockchain proofs come as JSON files with specific fields. The package expects these keys:

proof_dict = {
    "hash": "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456",
    "algorithm": "sha256",
    "blockchain": "polygon", 
    "tx_id": "0x1234567890abcdef1234567890abcdef12345678",
    "anchored_at": "2024-03-15T10:30:00Z",
    "service": "ProofLedger"
}

If the proof includes a merkle path (for Bitcoin batch anchoring), add:

proof_dict["merkle_path"] = [
    {"position": "left", "hash": "abc123..."},
    {"position": "right", "hash": "def456..."}
]

The verify_proof() function takes your file hash and this proof dictionary:

from verify_proof import verify_proof

result = verify_proof(file_hash, proof_dict)

if result["verified"]:
    print(f"✓ Verified on {result['blockchain']}")
    print(f"  Transaction: {result['tx_id']}")
    print(f"  Anchored: {result['anchored_at']}")
else:
    print(f"✗ Verification failed: {result['error']}")

Complete Verification Script

Here's a working script that loads a proof file and verifies any document:

import sys
from verify_proof import hash_file, verify_proof, load_proof

def verify_document(file_path, proof_path):
    """Verify a file against its blockchain proof."""

    # Hash the file
    print(f"Hashing {file_path}...")
    file_hash = hash_file(file_path)
    print(f"SHA256: {file_hash}")

    # Load the proof
    print(f"Loading proof from {proof_path}...")
    proof = load_proof(proof_path)

    # Verify
    result = verify_proof(file_hash, proof)

    if result["verified"]:
        print("\n✓ VERIFICATION SUCCESSFUL")
        print(f"  Blockchain: {result['blockchain']}")
        print(f"  Transaction ID: {result['tx_id']}")
        print(f"  Anchored at: {result['anchored_at']}")
        print(f"  Service: {result['service']}")

        # Show merkle verification if present
        if result.get("merkle_verified"):
            print(f"  Merkle root: {result['merkle_root']}")

    else:
        print("\n✗ VERIFICATION FAILED")
        print(f"  Error: {result['error']}")
        print(f"  File hash: {result['file_hash']}")
        print(f"  Proof hash: {result['proof_hash']}")

    return result["verified"]

if __name__ == "__main__":
    if len(sys.argv) != 3:
        print("Usage: python verify.py <file> <proof.json>")
        sys.exit(1)

    file_path = sys.argv[1]
    proof_path = sys.argv[2]

    verified = verify_document(file_path, proof_path)
    sys.exit(0 if verified else 1)

Run it like this:

python verify.py contract.pdf contract_proof.json

The script handles both simple proofs and merkle-tree proofs. It prints clear success/failure output and exits with the right code for shell scripting.

What This Gets You

Offline verification means opposing counsel can't claim the proof service was down when they tried to verify. The adjuster can verify evidence without internet access. The forensic examiner can validate timestamps from an air-gapped machine.

The package does pure cryptographic verification. It checks that your file hash matches the proof, validates merkle paths if present, and confirms all the signatures line up. It doesn't make network calls to confirm the transaction exists on-chain, but that's often fine. You're proving the file existed when the anchor was created, not that the blockchain transaction was valid.

For batch verification of many files, wrap this in a loop. For CI/CD integration, there's a GitHub Action. For command-line work, the CLI tools work in any shell script.

The verify-proof package source is on GitHub. The PyPI page has more examples. I built it to give everyone the same verification logic, whether you're running ProofLedger, ProofAnchor, or any other blockchain anchoring service that produces compatible proofs.

Chain of Custody for Digital Evidence in Insurance Disputes

Craig Solomon — Mon, 04 May 2026 05:45:18 +0000

Imagine a property damage claim with a disputed loss date. The policyholder submits a folder of photos documenting the building's condition before and after the event. The carrier's expert reviews the batch and flags a problem. Some images appear inconsistent with the claimed timeline. Now both sides are staring at metadata that says one thing and circumstantial evidence that suggests another.

Nobody can prove when the photos were actually taken.

This is the chain of custody problem for digital evidence. And it's different from physical evidence in ways that courts, adjusters, and attorneys encounter more frequently as documentation goes paperless.

What Chain of Custody Means for Digital Files

Physical evidence has an established chain: intake log, custody transfer form, controlled storage, documented access. When a document or object changes hands, there's a record.

Digital files don't work that way by default. A photo taken on a smartphone passes through at least four or five systems before an adjuster sees it: the camera app, the device's storage, a cloud backup service, an email attachment, a claims platform upload. At each step, file system timestamps can update. Metadata fields can be overwritten. Platform re-compression strips embedded data entirely.

By the time a file arrives in discovery, the original chain is often broken. What's left is a file, a timestamp field, and a question about whether that field was ever trustworthy.

Why Metadata Doesn't Establish Timing

EXIF data is the most common answer people reach for. The photo has a timestamp. It says it was taken before the loss.

That argument has limits. EXIF is an attribute written by the capture device at the moment of capture, but it can be edited after the fact using widely available software. Windows modifies file system timestamps when files are copied or moved. Most platforms strip or modify EXIF on upload. Courts and opposing counsel know all of this.

The technical fact is that EXIF lives inside the file. Anything inside the file can be changed by anyone with access to the file. That's not a speculation about fraud. It's how file formats work.

FRE 901(b)(9) allows courts to authenticate evidence produced by "a process or system that produces an accurate result." Metadata assertion from within the file doesn't meet that standard on its own, because the file itself is the thing whose integrity is in question. You can't authenticate the document by pointing to something written on the document.

What Blockchain Timestamping Does Instead

ProofLedger takes a different approach. When a file is submitted, the system computes its SHA-256 hash and anchors that hash to the blockchain. The file stays on the submitting machine. Only the hash goes on-chain.

That distinction matters for two reasons.

First, the hash is a cryptographic fingerprint of the file's exact state at that moment. Change one pixel in a photo and the hash changes completely. The anchor doesn't prove the file hasn't changed since submission; it proves what state the file was in at the moment of anchoring.

Second, the on-chain record exists independently of the file. It's on a public ledger, not in the file's metadata. Transferring the file doesn't affect it. Re-uploading doesn't affect it. A platform stripping EXIF on compression doesn't affect it. The ledger entry is permanent and separate.

This breaks the chain of custody problem at its root. The timestamp is no longer a claim inside the file that someone could have edited. It's an external record on a public blockchain that predates any dispute.

Authentication Under FRE 901(b)(9)

Courts can authenticate blockchain records under FRE 901(b)(9), which covers evidence produced by a process or system that generates an accurate result. The foundation typically requires expert testimony or certification explaining how the anchoring system works and why the hash-chain relationship is reliable.

This is a process authentication argument, not a self-authentication argument. That distinction matters for how you prepare the foundation.

For self-authentication without live testimony, FRE 902(13) and FRE 902(14) are the applicable rules. Both were added in 2017. Both allow authentication of machine-generated records through written certification. A qualified person with knowledge of how the system works provides that certification, and the record is admissible without calling the witness to testify at trial.

ProofLedger's proof records and verification certificates are designed to support both paths: expert testimony under 901(b)(9) when that route is preferred, or written certification supporting 902(13) and 902(14) when the goal is self-authentication without live testimony.

What the Dual-Chain Setup Adds

ProofLedger anchors to two independent blockchains: Polygon for near-immediate confirmation, and Bitcoin through daily batch anchoring with merkle proofs.

A single-chain anchor is verifiable. Two independent chains are more defensible. Polygon and Bitcoin use different cryptographic protocols, different consensus mechanisms, and different global validator networks. A record that exists on both chains creates a corroborating timestamp that doesn't depend on the integrity of either chain alone.

For admissibility arguments, this matters in a specific way. An opposing expert challenging a single-chain timestamp engages with one system. An opposing expert challenging a dual-chain timestamp has to argue that both chains produced erroneous results at the same moment. That's a harder argument to sustain.

Building a Defensible Chain of Custody

A practical workflow looks like this:

At the time of documentation, hash the files immediately. Don't wait until the claim is contested.
Submit the SHA-256 hash to ProofLedger via the web interface or the REST API.
Store the proof ID and certificate URL with the claim file.
If the timestamp is challenged later, use the public verify endpoint to confirm the anchor. Opposing counsel can run this check themselves, without any cooperation from the submitting party.

The public verify endpoint requires no authentication. Any auditor, attorney, or expert with the file and the proof ID can independently confirm that a file with this exact hash was anchored at a specific time. That independent verifiability is what makes the timestamp useful for chain of custody purposes. It doesn't require trusting the submitting party's word about when the file was created.

Claims teams managing higher volumes can use the REST API (BUSINESS plan) to integrate anchoring directly into their documentation workflow. The POST /api/v1/proof endpoint accepts a SHA-256 hash and returns a proof ID, status, and certificate URL. The GET /api/v1/verify endpoint is public, rate-limited at 120 requests per hour per IP, so third-party verification doesn't require any involvement from the originating party.

The Core Problem This Solves

Chain of custody for digital files has always depended on trust. Trust that the submitting party didn't alter the files. Trust that the metadata wasn't manipulated. Trust that the platform preserved the original timestamps.

A blockchain-anchored timestamp replaces that trust dependency with cryptographic verification. The chain of custody question shifts from "do you believe the metadata?" to "can you explain why the hash anchor is wrong?" Those are different questions with very different burdens.

For insurance disputes, forensic matters, or any context where timing and integrity are contested, that shift is the point. See how it works at proofledger.io.

Merkle proof validation explained with working code

Craig Solomon — Sat, 02 May 2026 13:08:53 +0000

Merkle proof validation explained with working code

When you anchor a file to a blockchain, you're not storing the file itself. You're storing a hash that proves the file existed at that moment. ProofAnchor anchors SHA-256 hashes to the Polygon blockchain, with the file never leaving your machine. But how do you prove your specific file hash is actually included in that blockchain transaction? That's where Merkle proofs come in.

The Merkle tree structure

Think of a Merkle tree like a tournament bracket, but for hashes. Your file hash sits at a "leaf" position. Each level up combines pairs of hashes until you reach a single "root" hash. That root hash is what gets stored on the blockchain.

The proof gives you a path from your leaf to the root, plus the "sibling" hashes you need to reconstruct the tree. If you can rebuild the same root hash the blockchain shows, your file was definitely included.

Let's see this in action with real code:

pip install verify-proof

Manual Merkle proof validation

Here's how to manually walk a Merkle proof using the same logic verify-proof uses internally:

import hashlib
from verify_proof import hash_file, verify_proof, load_proof

def validate_merkle_proof_manual(file_hash, merkle_path):
    """
    Manually validate a Merkle proof by walking from leaf to root.
    Uses the same combination logic as the verify-proof package.
    """
    current = file_hash

    print(f"Starting with file hash: {current}")

    for i, step in enumerate(merkle_path):
        sibling = step.get("hash", "")
        position = step.get("position", "right")

        print(f"\nStep {i + 1}:")
        print(f"  Current: {current}")
        print(f"  Sibling: {sibling}")
        print(f"  Position: {position}")

        # Critical: this is the exact logic verify-proof uses
        if position == "left":
            combined = sibling + current     # sibling left, current right
        else:
            combined = current + sibling     # current left, sibling right

        # Hash the combined hex string (as bytes, not UTF-8)
        current = hashlib.sha256(bytes.fromhex(combined)).hexdigest()
        print(f"  Combined: {combined}")
        print(f"  New hash: {current}")

    print(f"\nFinal root: {current}")
    return current

# Test with a sample proof structure
sample_proof = {
    "hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "algorithm": "sha256",
    "merkle_path": [
        {"position": "right", "hash": "a1b2c3d4e5f6"},
        {"position": "left", "hash": "f6e5d4c3b2a1"}
    ],
    "blockchain": "polygon",
    "tx_id": "0x1234567890abcdef",
    "anchored_at": "2024-03-15T10:30:00Z",
    "service": "ProofAnchor"
}

file_hash = sample_proof["hash"]
merkle_path = sample_proof["merkle_path"]

# Manual validation
manual_root = validate_merkle_proof_manual(file_hash, merkle_path)

# Compare with verify-proof package
result = verify_proof(file_hash, sample_proof)
package_root = result.get("merkle_root", "")

print(f"\nManual calculation: {manual_root}")
print(f"Package calculation: {package_root}")
print(f"Match: {manual_root == package_root}")

Validating real proof files

In practice, you'll have actual .proof.json files to validate. Here's how to process them:

import json
import os
from pathlib import Path

def validate_document_proofs(directory_path):
    """
    Find all .proof.json files in a directory and validate them
    against their corresponding documents.
    """
    directory = Path(directory_path)
    proof_files = list(directory.glob("*.proof.json"))

    results = []

    for proof_path in proof_files:
        # Assume the document has the same name without .proof.json
        document_name = proof_path.name.replace(".proof.json", "")
        document_path = directory / document_name

        if not document_path.exists():
            print(f"Warning: No document found for {proof_path.name}")
            continue

        try:
            # Load the proof
            proof_data = load_proof(str(proof_path))

            # Hash the actual file
            actual_hash = hash_file(str(document_path))

            # Validate the proof
            result = verify_proof(actual_hash, proof_data)

            results.append({
                "file": document_name,
                "verified": result["verified"],
                "blockchain": result.get("blockchain", "unknown"),
                "anchored_at": result.get("anchored_at", "unknown"),
                "merkle_verified": result.get("merkle_verified", False)
            })

            print(f"{document_name}: {'✓' if result['verified'] else '✗'}")
            if not result["verified"]:
                print(f"  Error: {result.get('error', 'Unknown error')}")
            else:
                print(f"  Anchored: {result['anchored_at']}")
                if "merkle_root" in result:
                    print(f"  Merkle root: {result['merkle_root'][:16]}...")

        except Exception as e:
            print(f"Error processing {proof_path.name}: {e}")
            results.append({
                "file": document_name,
                "verified": False,
                "error": str(e)
            })

    return results

# Example usage
# results = validate_document_proofs("./documents")

What's next

Merkle proofs are the mathematical foundation that makes blockchain timestamps trustworthy. The verify-proof package handles all this complexity for you, but understanding the underlying mechanics helps you debug edge cases and build confidence in the verification.

Check out the full source code to see how the package implements additional features like algorithm selection and error handling.

Blockchain Timestamps as Business Records: The FRE 803(6) Argument

Craig Solomon — Fri, 01 May 2026 20:43:57 +0000

Blockchain Timestamps as Business Records: The FRE 803(6) Argument

The authentication challenge clears. The foundation under FRE 901(b)(9) is laid. The blockchain timestamp is authenticated.

Then opposing counsel stands up. "Objection. Hearsay."

And they're right. A blockchain record is an out-of-court statement offered for the truth of what it asserts: that a specific file existed at a specific time. Without a hearsay exception, it's inadmissible regardless of how well it authenticates.

FRE 803(6) is where that exception lives. And I'd argue it gets less attention than it deserves.

What FRE 803(6) Actually Requires

The business records exception allows admission of records made in the regular course of any business activity, provided they meet four conditions:

The record was made at or near the time of the recorded event
By someone with knowledge, or from information transmitted by someone with knowledge
As a regular practice of the business
Kept in the course of a regularly conducted business activity

"Business" under FRE 803(6) is broader than the word implies. Courts have read it to include any organization or association. The question isn't whether money changes hands. It's whether the record was created in a systematic, reliable way.

A blockchain network creates records automatically, in real time, at the moment of anchoring. No human decides whether to log the transaction. The protocol does it every time. That's about as "regular practice" as it gets.

The Trustworthiness Condition

FRE 803(6) has a backdoor: a record can be excluded if "the source of information or the method or circumstances of preparation indicate a lack of trustworthiness." This is where opposition pushes.

The argument will be that blockchain records are self-generated, unverified by any human, and therefore untrustworthy. It's not a frivolous argument. But it doesn't hold up.

Trustworthiness under 803(6) doesn't require human verification. It requires that the method of creation be reliable. Courts applying this standard look at whether the record was created contemporaneously, by a system designed to do exactly that, without incentive to misrepresent the data.

A blockchain anchor satisfies all three. The timestamp is created at the moment of anchoring, not reconstructed after the fact. The system was built for this purpose. The blockchain has no stake in what hash gets anchored to it. It doesn't care who wins the lawsuit.

901(b)(9) and 803(6) Are Not the Same Argument

This distinction matters for litigation strategy. Conflating them costs cases.

FRE 901(b)(9) is an authentication rule. It establishes that the record is what it claims to be, specifically a product of a process that generates accurate results. That foundation is required before the record can even be considered by the trier of fact.

FRE 803(6) is a hearsay exception. It kicks in after authentication. You need both.

An attorney who clears 901(b)(9) and assumes the timestamp record is in evidence has gotten one step right. If opposing counsel then raises a hearsay objection with no 803(6) foundation in place, the record still goes out.

The practical overlap is worth noting: the certification work that supports FRE 902(13) self-authentication tends to support the 803(6) argument too. A written certification documenting the automated anchoring process, its regularity, and the absence of human intervention in the anchoring step serves both foundations. One document, two evidentiary purposes. That's worth building into the standard case preparation workflow before the motion deadline.

What Dual-Chain Anchoring Adds

I built ProofLedger to anchor every hash to both Polygon and Bitcoin. That decision was about verification redundancy. But it ends up supporting the 803(6) argument in a specific way.

Two chains mean two independent records, each capable of satisfying the business records foundation on its own. If opposing counsel attacks the Polygon record's trustworthiness (network behavior, validator questions, whatever the theory), the Bitcoin record stands independently. Same hash. Different chain. Two corroborating business records from unrelated systems.

Process reliability through redundancy. It strengthens the 803(6) argument the same way it strengthens the 901(b)(9) argument: the more independent systems produce identical results, the harder it is to argue the process is untrustworthy.

Three Documents to Prepare Before the Motion

The paralegal preparing blockchain timestamps for a case file needs to distinguish between three distinct things:

The FRE 902(13) certification. This handles authentication. A written certification from the anchoring service establishing that the record is what it claims to be. Gets past the authentication gate. Does not address hearsay.

The 803(6) custodian declaration. This handles hearsay. It needs to establish who operates the anchoring service, how the process works, that it runs identically for every record, and that the declarant has personal knowledge of those facts. Different document, different legal function, different evidentiary gate.

The proof record itself. Transaction hash, block explorer link, certificate URL. This is the evidence. The first two documents are the foundation that lets it in.

Preparing the 902(13) cert without the 803(6) declaration means you're ready for one objection, not two. Opposing counsel will raise both. Better to have the custodian declaration ready before the filing deadline than to scramble for it during a hearing.

One more thing to anticipate: the argument that self-generated records are inherently untrustworthy. Courts applying 803(6) to automated records (ATM logs, electronic medical records, access control system entries) have accepted mechanical reliability and contemporaneous creation as sufficient. Blockchain anchors belong in that category. The trustworthiness argument is winnable. But it needs to be prepared before the motion is filed, not answered on the fly.

The authentication fight gets most of the attention. Rightly so. But if hearsay is in play, the 803(6) foundation is what actually gets the timestamp into evidence.

Hurricane Property Claim: Pre-Loss Photo Authentication (Hypothetical)

Craig Solomon — Fri, 01 May 2026 20:43:44 +0000

Hurricane Property Claim: Pre-Loss Photo Authentication (Hypothetical)

Hypothetical scenario — illustrative only. Not based on a specific customer engagement.

The scenario

A homeowner files a claim after a major hurricane, providing inspection photos they describe as pre-storm documentation of the roof and exterior. The carrier questions the timing. File metadata shows timestamps, but EXIF data is mutable on any device, and notarizing a later statement that the photos were taken pre-storm proves attestation, not timing.

How ProofLedger applies

Before storm season, the property owner anchors SHA-256 hashes of their inspection photos to both Polygon and Bitcoin via ProofLedger. The files stay on their own device; only the hash goes on-chain. Polygon provides an immediate timestamp record; Bitcoin's daily batch anchor adds a second independent chain via merkle proof. If a dispute arises later, any party, including opposing counsel or an independent examiner, can verify the timestamp using the public verify URL or the verify-proof package, without contacting ProofLedger.

Expected outcome

The dual-chain timestamp would establish that those specific file hashes existed on-chain before the storm's recorded landfall date, creating a foundation for authentication under FRE 901(b)(9) as output from a process that produces an accurate result. This could support the policyholder's position in a coverage dispute and would give counsel a chain-of-custody record mathematically tied to the original files. Independent verifiability across two public chains is what distinguishes this from mutable file metadata or a notarized statement about when photos were taken.

Takeaway

When the question is timing, the answer needs to come from a record that can't be edited after the question is raised.

When Evidence Timing Becomes the Dispute

Craig Solomon — Fri, 01 May 2026 20:42:53 +0000

When Evidence Timing Becomes the Dispute

Meta description: A photo's EXIF data says it was taken before the loss. Opposing counsel challenges the timestamp. Your documentation strategy just became the weak link in a million-dollar claim.

The basement photos look perfect. Finished flooring, updated electrical, no water damage anywhere. The EXIF metadata shows they were captured three weeks before Hurricane Milton made landfall.

Defense counsel pulls the file properties during discovery. "Your Honor, these timestamps can be altered with any photo editing software. There's no independent verification these images existed before our client allegedly caused the flooding."

The adjuster has solid documentation. What they don't have is proof of when that documentation was created.

That's when pre-loss evidence becomes a timing problem, not a documentation problem.

The Authentication Gap in Claims Documentation

Traditional file timestamps fail under scrutiny. EXIF metadata can be edited. File creation dates reset during transfers. Even cloud storage timestamps only prove when a file was uploaded to a platform, not when it was originally created.

A $2 million water damage claim turns on whether basement photos existed before the incident. The photos themselves are legitimate. The timing can't be proven.

Defense wins on a technicality that shouldn't exist.

This happens because standard documentation methods weren't designed for adversarial environments. They capture content, not immutable proof of when that content existed.

Blockchain Anchoring: Neutral Temporal Authority

A blockchain anchor creates independent proof that evidence existed at a specific point in time. The process is straightforward: generate a SHA-256 hash of your file, submit that hash to a blockchain network, receive an immutable timestamp.

The file never leaves your device. Only the mathematical fingerprint gets anchored.

When someone challenges timing later, you point to the blockchain record. The timestamp can't be altered, backdated, or disputed. It exists on a public ledger that no single party controls.

Courts can authenticate blockchain timestamps under Federal Rule of Evidence 901(b)(9), which allows authentication of evidence produced by a reliable process. The blockchain's consensus mechanism and cryptographic proofs satisfy the reliability requirement.

For machine-generated records, FRE 902(13) provides a path to self-authentication through written certification, eliminating the need for live expert testimony in many cases.

Dual-Chain Strategy for Critical Evidence

ProofLedger uses both Polygon and Bitcoin networks for evidence anchoring. Polygon provides instant confirmation for immediate proof needs. Bitcoin offers the highest level of security through daily batch processing with merkle proofs.

The combination covers both scenarios: rapid response during active claims and bulletproof documentation for complex litigation.

Evidence packs organize your anchored proof by case, claim, or legal matter. Each pack tracks loss dates and clearly indicates pre-loss versus post-loss evidence. When discovery requests come in, everything is already organized and independently verified.

Building Documentation That Survives Challenge

Strong evidence documentation starts before you need it. Anchor routine property inspections, maintenance records, and condition assessments as standard practice.

When a loss occurs, you have established proof that your evidence existed beforehand. No one can challenge the timing because the blockchain record is immutable and publicly verifiable.

The photos matter. But proving when they were taken matters more.

Learn more about blockchain evidence anchoring at proofledger.io.

FRE 902(14): Certified Electronic Copies and the Hash Requirement Courts Actually Need

Craig Solomon — Fri, 01 May 2026 20:42:43 +0000

FRE 902(14): Certified Electronic Copies and the Hash Requirement Courts Actually Need

Electronic evidence gets copied. A lot. From the original device to forensic imaging. From forensic imaging to attorney work product. From work product to discovery production. Each transfer creates a potential authenticity question: is this copy accurate?

That's what FRE 902(14) addresses. And the mechanism courts consistently require for that authentication is hash verification.

What Rule 902(14) Actually Covers

Rule 902(14) was added to the Federal Rules of Evidence in 2017, alongside 902(13). They're companion rules that modernized electronic evidence authentication. But they cover different problems.

Rule 902(13) handles records generated by an electronic process or system. Server logs, automated transaction records, system-generated timestamps. The question: was this output produced by a reliable process?

Rule 902(14) handles data copied from an electronic device, storage medium, or file. The question: is this copy an accurate reproduction of the original?

When original electronic evidence is imaged, exported, or transferred and then offered in court, 902(14) is the self-authentication path. No live witness required to testify about the copying process. Just a written certification that meets the rule's requirements.

The Hash Verification Standard

Courts applying 902(14) consistently look for hash verification in the certification. Hash comparison proves bit-for-bit accuracy between the original and the copy. Different files produce different hashes. Identical files produce identical hashes.

The certification under 902(14) must describe the process used to ensure accuracy. Hash verification is the industry standard process for that assurance. A certification that says "we used standard forensic procedures" without specifying hash comparison often gets challenged. A certification that documents hash verification rarely does.

The Timing Problem with Traditional Hash Verification

Standard hash verification works perfectly when you control both the original and the copy. Crime scene investigators image a suspect's hard drive. They generate hashes of the original and the copy. Perfect chain of custody.

But evidence often exists before there's a reason to preserve it. Claim files, construction photos, maintenance records, communications. You don't know you need verified copies until the dispute starts. By then, the original device may be gone, reformatted, or legally inaccessible.

Traditional hash verification can't work retroactively. You can't prove a copy matches an original if the original no longer exists.

Blockchain Anchoring as Pre-Loss Hash Documentation

Blockchain anchoring solves the timing problem. Instead of waiting for a dispute to generate hashes for comparison, the hash gets anchored at creation time. The blockchain provides immutable documentation that a specific file with a specific hash existed at a specific time.

When that file is later copied for litigation, hash verification works even without access to the original device. The copy's hash can be compared against the blockchain-anchored hash from the time of creation. Match proves accuracy. Mismatch proves alteration.

This approach satisfies 902(14)'s certification requirements. The process used to ensure accuracy is documented on an immutable ledger. The timing of that process is cryptographically verified. The chain of custody doesn't depend on preserving the original device.

Practical Application

An insurance carrier receives claim photos. They're anchored to blockchain at the time of submission. Months later, during litigation, the carrier produces copies of those photos. The certification under 902(14) documents hash verification against the blockchain anchor.

The court doesn't need testimony about imaging procedures or device preservation. The blockchain anchor provides the original hash. The current files provide the comparison hash. Match equals authenticity under 902(14).

Chain of custody becomes mathematical rather than testimonial. Either the hashes match or they don't. Either the blockchain timestamp predates the loss or it doesn't. Simple verification that any court can understand and any party can independently confirm.

ProofLedger provides dual-chain anchoring on Polygon and Bitcoin networks for evidence that may need court admissibility later.

5. Legal Framework

Craig Solomon — Fri, 01 May 2026 20:41:55 +0000

5. Legal Framework

Authentication Standards for Blockchain-Anchored Evidence

A photo submitted as pre-loss documentation enters a predictable sequence of challenges. Opposing counsel questions when it was taken. The file metadata shows a timestamp. Counsel argues metadata is editable. The phone manufacturer's logs show a creation date. Counsel argues the phone clock can be manipulated. The claimant's testimony affirms the date. Credibility becomes the issue, and credibility is exactly what litigation is designed to contest.

This is the authentication problem for digital evidence. The federal rules for resolving it are specific, numbered, and already in force.

FRE 901(b)(9): Process-Based Authentication

Federal Rule of Evidence 901 establishes the general standard: the proponent must produce sufficient evidence to support a finding that the item is what the proponent claims.

FRE 901(b)(9) provides a specific mechanism: authentication is satisfied by "evidence describing a process or system and showing that it produces an accurate result." This is the evidentiary foundation for blockchain timestamp authentication in federal proceedings.

Two points are worth stating plainly, because they are routinely conflated in legal and insurance practice.

First: FRE 901(b)(9) is not self-authentication. It requires a foundation, typically expert testimony or technical documentation, establishing that the anchoring process produces reliable, accurate results. The blockchain record alone does not authenticate itself under this rule. The process must be described and its accuracy demonstrated.

Second: authentication under 901(b)(9) is about the process, not the metadata. EXIF timestamps embedded in a file are metadata fields. They are not output from a certified process. When an authentication argument rests on EXIF data, opposing counsel has a straightforward response: the field is editable. Authentication under 901(b)(9) requires demonstrating that a systematic process produced the result and that the process works. A public blockchain ledger with independent validator consensus is a process. A metadata field written by the device is not.

FRE 902(13) and 902(14): Self-Authentication for Machine-Generated Records

The 2017 amendments to the Federal Rules of Evidence added two categories that substantially change the authentication burden for digital records.

FRE 902(13) provides for self-authentication of "a record generated by an electronic process or system that produces an accurate result, as shown by a certification of a qualified person" complying with the certification requirements in FRE 902(11) or (12). No live testimony required.

FRE 902(14) addresses copies of electronically stored information under the same certification framework.

The practical effect: a written certification from the party operating the anchoring process can satisfy authentication without calling a technical witness at trial. This matters in claims contexts where litigation is already resource-intensive. A written certification that describes the hash anchoring process, identifies the specific hash and its on-chain transaction records, and attests that the process produces accurate results satisfies the rule's requirements.

The certification approach is already established in federal practice for electronic records generally. FRE 902(13) extended it to machine-generated records specifically, reflecting the courts' recognition that these records are generated by process, not by human observation, and that human testimony about a machine's output is often less reliable than a certification describing how the machine operates.

Daubert and Process Reliability

In federal courts applying Daubert v. Merrell Dow Pharmaceuticals, 509 U.S. 579 (1993), expert testimony about technical processes must satisfy reliability criteria: the methodology must be testable, subject to peer review, have a known error rate, and be generally accepted in the relevant field.

SHA-256 hashing and blockchain consensus mechanisms meet these criteria without meaningful controversy. SHA-256 is a NIST-standardized algorithm with mathematically established collision resistance. The Bitcoin and Polygon consensus mechanisms are public, documented, and independently audited by cryptographers worldwide. An expert offering foundation testimony under 901(b)(9) has a strong evidentiary record to draw on.

The dual-chain architecture strengthens this foundation. When the same SHA-256 hash is recorded on both Polygon and Bitcoin, two independent networks confirm the same fact. Each has different validator sets, different consensus logic, different global infrastructure. Agreement between them is not coordination. It's independent corroboration. From a Daubert reliability standpoint, dual-chain confirmation is a materially stronger position than single-chain.

Challenges and Their Limits

Blockchain timestamps are not immune to attack at trial, but the available challenges are narrow.

The most common challenge is temporal: did the anchor occur before or after the loss event? This is a factual question. The blockchain timestamp is publicly verifiable by any party with the hash and the transaction ID. If the anchor predates the documented loss date on the blockchain's ledger, that is the record. The argument fails unless the challenger can demonstrate that the loss itself occurred earlier than claimed, redirecting the dispute to a different factual question.

A second challenge concerns custody at the time of anchoring: did the file match the hash at the moment it was submitted? Nothing in the blockchain record prevents a party from altering a file and then anchoring the altered version. This is a custody argument, not a technical one. The response is documentation: when was the file created, by whom, on what device, and how was the original preserved between creation and anchoring. Chain of custody practices answer that question. The blockchain answers the separate question of whether the hash existed at a specific point in time. Neither replaces the other.

What cannot be challenged: the on-chain record itself. It is on a public ledger. It cannot be back-dated, altered, or deleted. Opposing counsel can verify it independently using the public verify endpoint at proofledger.io/api/v1/verify (no authentication required) or via the verify-proof PyPI package for offline verification. The verification is deterministic: the hash either matches the on-chain record, or it doesn't.

Proposed FRE 707

In June 2025, the Judicial Conference approved proposed FRE 707, a new rule specifically addressing machine-generated evidence. The public comment window closed in February 2026.

If adopted, FRE 707 would create an explicit evidentiary framework for records produced by automated systems, distinct from existing rules that address human-generated records with digital characteristics. Blockchain timestamps, which are fully machine-generated (no human observation or attestation involved in the anchoring process), fit the proposed rule's scope directly.

The proposed rule reflects a gap that has been apparent in federal practice for years. FRE 901 and 902 were written before blockchain infrastructure existed at scale. Courts have applied them to blockchain records by analogy, and that approach has generally held. But an explicit rule eliminates the foundation-laying exercise that 901(b)(9) currently requires. Organizations that establish consistent blockchain timestamp procedures before FRE 707's adoption will be positioned to take advantage of the streamlined admissibility path when the rule takes effect.

The Authentication Chain in Practice

A properly structured evidentiary submission using blockchain-anchored documentation follows a predictable sequence.

The file is SHA-256 hashed at the time of documentation and submitted for anchoring. The hash (not the file) is recorded on Polygon, typically within the same session, and included in a Bitcoin merkle batch within 24 hours. A proof record is generated with a certificate URL and transaction IDs for both chains. The file itself never leaves the submitting party's possession.

At the point of a dispute, the proof record is preserved alongside the original file. A certification can be issued describing the anchoring process and the specific on-chain record. That certification supports self-authentication under FRE 902(13) without live testimony.

Any party to the proceeding can independently verify the record. The hash, the transaction IDs, and the block timestamps are public. The verification tools are public. There is no proprietary system that opposing counsel cannot inspect.

That transparency is the point. The authentication argument doesn't depend on trust in the anchoring platform. It depends on the blockchain's properties: public, immutable, independently verifiable. The legal framework for those properties is already written.

Notarization vs. Blockchain Timestamps: What Each Actually Proves in Court

Craig Solomon — Fri, 01 May 2026 20:41:44 +0000

Notarization vs. Blockchain Timestamps: What Each Actually Proves in Court

The photographs were notarized. Notary seal on the cover letter. The insurance company denied the claim anyway, arguing the photos couldn't be verified as pre-loss.

The notary hadn't been at the loss site. The notary certified the signature. That's all a notary does.

This confusion costs claimants money and costs attorneys credibility. Evidence gets submitted with notarized cover sheets and everyone assumes authentication is solved. It isn't. At least not for the question that usually matters most: when was this evidence created?

What Notarization Actually Proves

A notary public certifies one thing: that the person who signed a document is who they claim to be. Under FRE 902(8), a document bearing a notary seal is self-authenticating. The court accepts it without additional testimony about the notary's identity.

That's genuinely useful. An affidavit. A power of attorney. A property deed.

What notarization doesn't establish: when the underlying evidence was created, whether photographs depict pre-loss conditions, or whether files were modified between creation and submission.

FRE 902(8) answers "who." It doesn't answer "when." In pre-loss documentation disputes, "when" is the question.

The Timestamp Problem

Every camera writes a timestamp. So does every phone, every dashcam, every telematics device.

Courts have stopped treating this as reliable authentication.

EXIF data is editable with free software. File timestamps change on copy, move, or backup. Device clocks can be wrong, and often are. These fields reflect what software reported, not what actually happened.

FRE 901(b)(9) authenticates "evidence about a process or system and showing that it produces an accurate result." A camera's internal clock doesn't meet that bar unless you can establish, through expert testimony or other foundation, that the clock was accurate at the time of capture. Metadata alone doesn't do it.

Submitting photographs and pointing to the EXIF timestamp is an authentication problem waiting to be exploited. The field exists. That's not the same as proving the field reflects reality.

What a Blockchain Timestamp Proves

A blockchain anchor doesn't store your file. It stores a SHA-256 hash of your file, anchored to a public ledger at a specific timestamp.

The mechanism: your file is hashed on your device. Only the hash goes on-chain. That hash is deterministic. The same file always produces the same output. Change one byte and the hash changes completely. A matching hash confirms the file hasn't been modified since anchoring.

The anchor timestamp is written into the blockchain by network consensus across thousands of independent nodes. It can't be retroactively altered. Polygon confirms within seconds. Bitcoin anchoring via a daily batch with a merkle proof adds verification against the most scrutinized ledger in existence.

For authentication under FRE 901(b)(9), the process is the argument. Hash function, network consensus, cryptographic verification. These are the mechanisms a practitioner lays foundation for with expert testimony or technical certification. The process produces an accurate result. That's what the rule requires.

FRE 902(13) and 902(14): Removing the Expert Witness Requirement

FRE 901(b)(9) requires foundational testimony. Someone explains the process before the evidence comes in, usually an expert.

Two 2017 amendments change that calculus.

FRE 902(13) covers "a record generated by an electronic process or system that produces an accurate result, as shown by a certification of a qualified person that complies with the certification requirements of Rule 902(11) or (12)." Written certification. No live testimony required.

FRE 902(14) covers "data copied from an electronic device, storage medium, or file, if authenticated by a process of digital identification, as shown by a certification of a qualified person that complies with the certification requirements of Rule 902(11) or (12)." This is directly on point for hash-verified file integrity. When opposing counsel or an auditor verifies that the current file's hash matches the on-chain anchor, they're doing exactly what 902(14) contemplates.

The certification requirements under 902(11) and 902(12) are specific: attest to the accuracy of the process, provide advance notice to opposing counsel, make the certification available for inspection. A generic cover letter doesn't satisfy this. A proper technical certification attesting to the anchoring mechanism, hash function, and verification procedure can.

Used together, 902(13) and 902(14) let you bring blockchain timestamp evidence in without putting an expert on the stand. That's a real advantage in cost and trial scheduling.

The Key Distinction

Notarization and blockchain timestamps authenticate different things.

Notarization under FRE 902(8): the signer is who they say they are.

Blockchain timestamp under FRE 901(b)(9) and FRE 902(13): this file, in this exact state, existed at this specific time.

For pre-loss evidence disputes, you need the second one. The question isn't who submitted the document. It's whether the photographs were taken before or after the loss date.

A notarized photo with no timestamp authentication doesn't establish pre-loss existence. A blockchain-anchored hash establishes exactly that, with a mechanism courts can evaluate under the Federal Rules.

This isn't either/or. A notarized affidavit describing the circumstances of capture, combined with a blockchain anchor of the underlying files, gives you both: identity verification and temporal proof. Use both when the stakes warrant it.

Monday Morning

If you're submitting evidence in a dispute: Don't assume notarization solves authentication. It handles the identity question. For timestamp integrity, you need a process courts can evaluate under FRE 901(b)(9), or a certification that satisfies FRE 902(13) and 902(14).

If you're challenging evidence: The absence of verifiable timestamp authentication is a legitimate basis for a motion to exclude. EXIF metadata alone doesn't satisfy FRE 901(b)(9). Ask what process produced the timestamp and how opposing counsel plans to establish that process was accurate.

If you're building a documentation workflow: Anchor files at capture, not submission. A blockchain anchor created well before any dispute carries a timestamp that predates any adversarial incentive. One created the week before trial is technically valid but harder to defend under cross.

FRE 902(8) is useful. FRE 901(b)(9), FRE 902(13), and FRE 902(14) are the rules that matter for temporal authentication. Know the difference before the motion gets filed.

proofledger.io

Timestamped Site Inspections in a Construction Defect Dispute (Hypothetical)

Craig Solomon — Fri, 01 May 2026 20:17:57 +0000

Timestamped Site Inspections in a Construction Defect Dispute (Hypothetical)

Hypothetical scenario — illustrative only. Not based on a specific customer engagement.

The scenario

A mid-size general contractor faces a defect claim on a recently completed commercial building. The owner alleges that water infiltration damage resulted from workmanship failures during the build phase. The contractor has inspection photos and field notes from multiple site visits, but cannot establish that these records existed before the claim was filed. File system timestamps and email metadata are easily disputed in litigation.

How ProofLedger applies

During active construction, the superintendent photographs relevant areas at each inspection. Each file's SHA-256 hash is submitted to ProofLedger for anchoring to both Polygon and Bitcoin. Only the hash moves across the network. The original files stay on the superintendent's device. Each anchor produces an immutable record that those specific files existed at that specific moment in time. If the dispute proceeds to litigation, any party can verify each proof against its chain record using the public verify endpoint or the offline verify-proof package, with no dependence on the contractor's own systems.

Expected outcome

This inspection record could establish a site condition timeline that predates the claim filing, supporting the contractor's position on causation. Under FRE 901(b)(9), which allows authentication of evidence from a process or system that produces an accurate result, the dual-chain anchor record could satisfy foundation requirements for admissibility, provided counsel lays the appropriate foundation through certification or expert testimony. The contractor would be positioned to show not just what conditions looked like at each visit, but when that documentation was created.

Takeaway

When a defect dispute turns on when a condition first appeared, a blockchain-anchored inspection record provides a factual baseline that file metadata and email threads cannot.

Verify Blockchain-Anchored Files Offline with Python

Craig Solomon — Fri, 01 May 2026 19:44:31 +0000

Verify Blockchain-Anchored Files Offline with Python

A claims adjuster uploads photos from a loss site. The blockchain anchor proves they existed before the damage occurred. But three months later, during litigation discovery, how do you actually verify those proofs without calling the original service?

I built the verify-proof package to solve this. Files get anchored to blockchains, but verification shouldn't depend on API uptime or service availability. The proof should be self-contained and verifiable offline.

Installing and Hashing Files

The verify-proof package handles SHA-256 hashing and proof verification locally. No network calls, no service dependencies.

pip install verify-proof

The hash_file() function computes SHA-256 digests:

from verify_proof import hash_file

# Hash any file type
file_hash = hash_file("evidence.jpg")
print(f"SHA-256: {file_hash}")
# Output: SHA-256: a1b2c3d4e5f6789...

You can also use the CLI:

verify-proof hash evidence.jpg
# SHA256: a1b2c3d4e5f6789...
# File: /path/to/evidence.jpg

The hash is what gets anchored to the blockchain. The file stays on your machine.

Verifying Blockchain Proofs

Blockchain anchoring services return a proof JSON that contains the anchor details. Here's what a typical proof looks like:

{
  "hash": "a1b2c3d4e5f6789abcdef...",
  "algorithm": "sha256",
  "blockchain": "polygon",
  "tx_id": "0x1234567890abcdef...",
  "anchored_at": "2026-04-30T14:30:00Z",
  "service": "ProofLedger",
  "merkle_path": [
    {"position": "right", "hash": "b2c3d4e5f6789abc..."},
    {"position": "left", "hash": "c3d4e5f6789abcde..."}
  ]
}

The verify_proof() function validates this structure offline:

from verify_proof import verify_proof, load_proof
import json

# Load proof from file
proof = load_proof("evidence_proof.json")

# Verify against the file
file_hash = hash_file("evidence.jpg")
result = verify_proof(file_hash, proof)

if result["verified"]:
    print(f"✅ Verified: {result['message']}")
    print(f"Blockchain: {result['blockchain']}")
    print(f"Transaction: {result['tx_id']}")
    print(f"Anchored: {result['anchored_at']}")
else:
    print(f"❌ Failed: {result['error']}")

Understanding Merkle Path Verification

The interesting part is the Merkle path. When files get batched for blockchain anchoring, they're organized into a Merkle tree. Your file's hash is a leaf, and the proof shows the path from that leaf to the root that was actually anchored on-chain.

Here's how the verification works step by step:

import hashlib

def trace_merkle_path(file_hash, merkle_path):
    """
    Walk up the Merkle tree from leaf to root
    """
    current = file_hash
    print(f"Starting with file hash: {current}")

    for i, step in enumerate(merkle_path):
        sibling = step["hash"]
        position = step["position"]

        if position == "left":
            # Sibling goes left, current goes right
            combined = sibling + current
        else:
            # Current goes left, sibling goes right
            combined = current + sibling

        # Hash the combined hex strings (as bytes)
        current = hashlib.sha256(bytes.fromhex(combined)).hexdigest()
        print(f"Step {i+1}: {position} sibling -> {current}")

    print(f"Final root: {current}")
    return current

# Example with real proof structure
file_hash = "a1b2c3d4e5f6789abcdef123456789abcdef123456789abcdef123456789abcdef"
merkle_path = [
    {"position": "right", "hash": "b2c3d4e5f6789abcdef123456789abcdef123456789abcdef123456789abcdef"},
    {"position": "left", "hash": "c3d4e5f6789abcdef123456789abcdef123456789abcdef123456789abcdef1234"}
]

merkle_root = trace_merkle_path(file_hash, merkle_path)

The verify-proof package does this same calculation and compares the result to what's expected for that transaction ID.

CLI Verification Workflow

You can also verify from the command line:

# Hash the file
verify-proof hash evidence.jpg

# Verify against the proof
verify-proof verify evidence.jpg --proof evidence_proof.json

The CLI exits with status 0 on success, 1 on failure. Perfect for shell scripts or CI pipelines.

What This Actually Validates

The verify-proof package checks three things:

File integrity: Does the SHA-256 of your file match the hash in the proof?
Merkle path: Does the path from your file hash lead to the claimed Merkle root?
Proof structure: Does the proof contain the required fields (tx_id, blockchain, etc.)?

What it doesn't do: verify that the transaction ID actually exists on the blockchain. That requires a separate API call to a blockchain explorer. The package keeps verification local and offline.

Building Verification Into Your Workflow

Here's a complete verification script you might use in a forensic workflow:

#!/usr/bin/env python3

import os
import sys
from verify_proof import hash_file, verify_proof, load_proof

def verify_evidence_bundle(evidence_dir):
    """
    Verify all files in a directory against their proof files
    """
    results = []

    for filename in os.listdir(evidence_dir):
        if filename.endswith('.json'):
            continue

        file_path = os.path.join(evidence_dir, filename)
        proof_path = os.path.join(evidence_dir, f"{filename}.proof.json")

        if not os.path.exists(proof_path):
            print(f"⚠️  No proof file for {filename}")
            continue

        try:
            file_hash = hash_file(file_path)
            proof = load_proof(proof_path)
            result = verify_proof(file_hash, proof)

            if result["verified"]:
                print(f"✅ {filename}: Verified on {result['blockchain']}")
                results.append(True)
            else:
                print(f"❌ {filename}: {result['error']}")
                results.append(False)

        except Exception as e:
            print(f"💥 {filename}: Error - {e}")
            results.append(False)

    return all(results)

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: verify_bundle.py <evidence_directory>")
        sys.exit(1)

    evidence_dir = sys.argv[1]
    success = verify_evidence_bundle(evidence_dir)
    sys.exit(0 if success else 1)

The beauty of offline verification is reliability. Your evidence validation doesn't break when APIs go down, services shut down, or networks fail. The blockchain anchor is permanent. The verification logic is deterministic. As long as you have the file and the proof, you can validate the timestamp.