Forem: Craig Solomon

Walking Up a Merkle Tree: SHA-256 Proof Validation in Python

Craig Solomon — Mon, 18 May 2026 13:00:01 +0000

You get a file hash and a Merkle proof that claims it's anchored in some blockchain transaction. How do you verify that claim without trusting the service that gave you the proof?

I built ProofLedger to create these proofs, but the verification should work independently. Anyone can validate a Merkle proof with the right algorithm. Here's how to walk up the tree from leaf to root.

What's Actually in a Merkle Proof

A Merkle proof is a list of sibling hashes that lets you reconstruct the path from your file's hash up to the Merkle root. Each step combines your current hash with a sibling hash to produce the parent hash.

The proof tells you two things for each step:

The sibling hash (as a hex string)
Which side to put it on ("left" or "right")

# Example proof structure
proof = {
    "hash": "a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3",
    "merkle_path": [
        {
            "hash": "b5d4045c3f466fa91fe2cc6abe79232a1a57cdf104f7a26e716e0a1e2789df78",
            "position": "right"
        },
        {
            "hash": "c3d4045c3f466fa91fe2cc6abe79232a1a57cdf104f7a26e716e0a1e2789df79",
            "position": "left"  
        }
    ]
}

That's it. No magic, no proprietary formats. Just a starting hash and a list of directions.

The Hash Combination Algorithm

Each step up the tree combines two 64-character hex strings into one. The critical part is getting the concatenation order right.

import hashlib

def combine_hashes(left_hex, right_hex):
    """Combine two hex hashes into their parent hash."""
    # Concatenate the hex strings
    combined_hex = left_hex + right_hex

    # Convert to bytes, then hash
    combined_bytes = bytes.fromhex(combined_hex)
    parent_hash = hashlib.sha256(combined_bytes).hexdigest()

    return parent_hash

# Example
left = "a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3"
right = "b5d4045c3f466fa91fe2cc6abe79232a1a57cdf104f7a26e716e0a1e2789df78" 
parent = combine_hashes(left, right)
print(f"Parent: {parent}")

The order matters. combine_hashes(A, B) produces a different result than combine_hashes(B, A). That's why the proof needs to specify position.

Walking the Full Path

Now you can iterate through the proof steps. Start with your file hash. At each step, combine it with the sibling hash in the specified position.

def verify_merkle_proof(file_hash, merkle_path):
    """Walk up a Merkle tree and return the computed root."""
    current = file_hash.lower()  # Normalize to lowercase

    for step in merkle_path:
        sibling = step["hash"].lower()
        position = step["position"]

        if position == "left":
            # Sibling goes left, current goes right
            current = combine_hashes(sibling, current)
        else:
            # Current goes left, sibling goes right  
            current = combine_hashes(current, sibling)

        print(f"Step: {current}")

    return current

# Test with our example proof
file_hash = "a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3"
merkle_path = [
    {
        "hash": "b5d4045c3f466fa91fe2cc6abe79232a1a57cdf104f7a26e716e0a1e2789df78",
        "position": "right"
    },
    {
        "hash": "c3d4045c3f466fa91fe2cc6abe79232a1a57cdf104f7a26e716e0a1e2789df79",
        "position": "left"  
    }
]

computed_root = verify_merkle_proof(file_hash, merkle_path)
print(f"Computed root: {computed_root}")

The function returns the root hash. That's what should match the value stored on-chain.

Complete Verification Function

Here's a complete verifier that handles the proof structure and validates the result:

import hashlib
import json

def hash_file(filepath):
    """Generate SHA-256 hash of a file."""
    sha256_hash = hashlib.sha256()
    with open(filepath, "rb") as f:
        for chunk in iter(lambda: f.read(4096), b""):
            sha256_hash.update(chunk)
    return sha256_hash.hexdigest()

def verify_proof(file_path, proof_data):
    """Verify a complete Merkle proof against a file."""
    # Hash the file
    file_hash = hash_file(file_path)

    # Extract proof components
    claimed_hash = proof_data["hash"]
    merkle_path = proof_data.get("merkle_path", [])

    # Verify file hash matches claim
    if file_hash != claimed_hash.lower():
        return {
            "verified": False,
            "error": f"File hash {file_hash} doesn't match claimed {claimed_hash}"
        }

    # If no merkle path, just verify the hash
    if not merkle_path:
        return {
            "verified": True,
            "file_hash": file_hash,
            "merkle_root": file_hash  # Root is just the file hash
        }

    # Compute the Merkle root
    computed_root = verify_merkle_proof(file_hash, merkle_path)

    return {
        "verified": True,
        "file_hash": file_hash,
        "merkle_root": computed_root,
        "path_length": len(merkle_path)
    }

# Usage
with open('proof.json', 'r') as f:
    proof = json.load(f)

result = verify_proof('document.pdf', proof)
print(json.dumps(result, indent=2))

Why This Matters for Evidence

You don't need to trust the timestamping service. The Merkle proof lets you independently verify that your file hash was included in the transaction. You can check the blockchain explorer yourself to confirm the root hash exists on-chain.

The proof can't be forged after the fact. If someone tries to create a fake proof for a file that wasn't actually anchored, the computed root won't match what's on the blockchain.

For legal or forensic use, this means opposing counsel can verify your evidence timestamps independently. They don't have to trust ProofLedger, ProofAnchor, or any other service. They just run the algorithm against the blockchain data.

That's the point of cryptographic proofs. Math, not trust.

ProofLedger

Craig Solomon — Mon, 18 May 2026 13:00:00 +0000

A claims adjuster arrives at a commercial property loss three days after Hurricane Milton made landfall. The policyholder hands over 200 photos documenting pre-storm conditions. The timestamps show they were taken two weeks before the hurricane. The adjuster has a problem: how do you prove those photos weren't actually taken after the loss and backdated?

This is where ProofLedger's blockchain anchoring solves a fundamental evidence authenticity challenge that costs insurers millions in disputed claims annually.

Traditional digital evidence carries no immutable proof of when it was created. File metadata can be altered. Timestamps can be changed. Cloud storage dates reflect upload times, not creation times. In litigation, opposing counsel will challenge every piece of digital evidence that lacks independent verification.

ProofLedger creates that verification by anchoring SHA-256 file hashes to both Polygon and Bitcoin blockchains at the moment of capture. The blockchain timestamp becomes permanent, immutable proof that the evidence existed at that specific point in time. No one can alter it retroactively.

Here's the workflow that transforms evidence documentation:

The policyholder uses ProofLedger to anchor their pre-loss photos immediately after taking them. The system generates SHA-256 hashes of each file and writes those hashes to the Polygon blockchain instantly, then batches them to Bitcoin daily with merkle proofs for additional permanence. The files themselves never leave the policyholder's device - only the mathematical fingerprint gets anchored.

When the loss occurs, the adjuster can verify every photo's timestamp independently. The blockchain record proves exactly when each piece of evidence was created. There's no relying on file metadata or trusting the claimant's word.

In court, this creates powerful authentication under Federal Rule of Evidence 901(b)(9), which allows authentication of evidence produced by "a process or system that produces an accurate result." The blockchain's cryptographic verification provides the foundation needed for admissibility.

For self-authentication without live testimony, FRE 902(13) and 902(14) allow machine-generated records through written certification. A blockchain anchor with proper documentation can qualify for this streamlined authentication process.

The dual-chain approach adds redundancy. Polygon provides instant confirmation and low transaction costs for high-volume documentation. Bitcoin offers the deepest security and longest track record for permanent archival. Together, they create neutral temporal authority that courts can rely on.

Evidence packs in ProofLedger organize proof by claim, case, or matter. Adjusters can set loss dates and clearly distinguish pre-loss documentation from post-loss assessment photos. The system generates comprehensive reports showing the timeline of evidence creation relative to the loss event.

This matters beyond individual claims. Insurance fraud involving staged or backdated evidence costs the industry billions annually. Blockchain anchoring makes temporal fraud exponentially more difficult. You can't fake a blockchain timestamp after the fact.

The technology scales from single-photo verification to enterprise-wide evidence management. Large carriers are implementing blockchain anchoring as standard practice for high-value claims and litigation-prone lines of business.

For professionals handling disputed claims, blockchain-anchored timestamps transform evidence from "he said, she said" into mathematically verified fact. That's the difference between settling nuisance claims and defending them successfully in court.

ProofLedger

Craig Solomon — Fri, 15 May 2026 13:00:00 +0000

An adjuster walks into a water damage claim. The homeowner has photos of the affected area on their phone, timestamped three days before the storm hit. Perfect evidence of pre-existing conditions, right?

Not so fast. Those timestamps can be manipulated. The camera's internal clock can be reset. The metadata can be altered. In court, opposing counsel will challenge every aspect of when those photos were actually taken.

This is where ProofLedger's blockchain anchoring creates unshakeable proof. Instead of relying on device metadata that can be questioned, the system generates a cryptographic hash of each file and anchors it to both Polygon and Bitcoin blockchains. The blockchain timestamp can't be altered, can't be backdated, and exists independently of the file itself.

Here's how it works in practice. The homeowner takes photos of existing damage on Monday. ProofLedger immediately anchors the SHA-256 hash to Polygon, creating an instant blockchain record. The same hash gets included in Bitcoin's daily merkle proof batch. When the storm hits Wednesday and causes additional damage, there's now immutable proof that the Monday photos existed before the loss event.

The legal foundation is solid. Courts can authenticate blockchain timestamps under FRE 901(b)(9), which covers evidence produced by a process that generates an accurate result. The authentication requires establishing that the blockchain process reliably records data without tampering. For self-authentication without live testimony, FRE 902(13) allows written certification of machine-generated records.

This matters beyond individual claims. Risk managers documenting property conditions before policy renewals can prove their assessments weren't created retroactively. Construction professionals photographing project milestones can demonstrate compliance timelines that can't be questioned later. Forensic consultants analyzing evidence can establish exactly when their documentation was created.

The dual-chain approach provides redundancy. Polygon offers instant confirmation for immediate verification needs. Bitcoin provides the ultimate security layer through proof-of-work consensus and widespread network adoption. If one network faces technical issues, the other maintains the temporal anchor.

Your files never leave your device. Only the cryptographic hash gets anchored to the blockchain. The original evidence remains in your custody while the timestamp proof exists on a public, immutable ledger that anyone can verify.

Evidence packs organize everything by case, claim, or matter. Each pack tracks the loss date and marks items as pre-loss or post-loss based on their blockchain timestamps. When litigation comes, you hand over organized proof that shows exactly what evidence existed when.

The strongest chain of custody combines multiple layers. Document the evidence properly. Maintain proper handling procedures. And anchor the temporal proof to a blockchain that can't be altered.

Claims get disputed. Evidence gets questioned. Timestamps get challenged. But a blockchain anchor stands up to scrutiny because it exists independently of any single party's control. It's neutral temporal authority for when evidence actually existed.

When You Need to Prove You Created Something First

Craig Solomon — Wed, 13 May 2026 17:52:58 +0000

A photographer posts their street photography series on Instagram. Three weeks later, they see the exact same composition in a stock photo site, credited to someone else. The dispute comes down to one question: who shot it first?

This isn't hypothetical. It's happening right now as AI makes copying easier and proving original creation harder. You need blockchain timestamping: an immutable record that proves when your work existed. ProofAnchor does exactly that, anchoring your file's cryptographic fingerprint to the Polygon blockchain the moment you upload it.

Here's how it works. You drag your photo into ProofAnchor. The system creates a SHA-256 hash of your file. A unique fingerprint that changes completely if even one pixel gets altered. That hash gets written to the Polygon blockchain with a timestamp. Your file never leaves your device. Only the mathematical proof goes on-chain.

The result? Permanent, independently verifiable proof of existence. Anyone can check the blockchain record. Courts can verify it. Copyright offices can reference it. The timestamp can't be faked, backdated, or deleted because it's distributed across thousands of blockchain nodes worldwide.

Traditional copyright registration takes weeks and costs money. ProofAnchor takes seconds and starts free. Both serve different purposes. Copyright gives you legal protection, while blockchain timestamping gives you proof of when you had the work first. Smart creators use both.

The AI problem makes this urgent. Large language models and image generators train on everything they can scrape. Your unpublished novel, your portfolio shots, your demo tracks. They're all potential training data. When AI outputs something suspiciously similar to your work, proving prior creation becomes your only defense.

C2P1 content credentials help here too, but they're fragile. Upload a photo to most social platforms and the embedded credential gets stripped. Your blockchain timestamp stays permanent regardless of what any platform does to your file.

ProofAnchor works for any digital file. Writers timestamp manuscripts before sending to beta readers. Musicians anchor demos before sharing with labels. Developers prove code authorship before open-sourcing. Photographers lock in timestamps before client presentations.

The process costs almost nothing. Polygon transactions run pennies, not dollars. You get immediate proof without waiting for bureaucratic approval or paying recurring fees.

This isn't about paranoia. It's about having options when disputes happen. Maybe that photographer could've avoided months of legal back-and-forth with a simple blockchain record showing they had the shot first. Maybe the stock photo thief would've thought twice knowing the real creator had immutable proof.

Proving you created something first shouldn't be complicated. Upload your file, get your blockchain timestamp, keep working. When someone claims they had your idea first, you'll have the receipt that matters.

The question isn't whether you'll face a creation dispute. It's whether you'll have proof when you do.

ProofAnchor

Craig Solomon — Wed, 13 May 2026 17:52:16 +0000

A photographer uploads their best shot to Instagram. Three months later, they find it selling as a print on Etsy. The seller claims they took it first.

Who's lying? Without proof of when each person had the file, it's one word against another. Courts need evidence, not stories.

This is exactly why ProofAnchor exists. It creates permanent, third-party proof of when your creative work existed. Not proof of ownership (that's copyright). Proof of timing. When did you have this file first?

Here's how it works. You drag your photo into ProofAnchor. The service generates a SHA-256 hash of your file. That's a unique digital fingerprint that changes completely if even one pixel gets modified. That hash gets anchored to the Polygon blockchain with a timestamp.

Your file never leaves your device. Only the hash goes on-chain.

The result? Permanent proof that this exact version of your work existed at this specific moment. Anyone can verify it independently using the blockchain. No trusting ProofAnchor. No trusting any company. The proof lives on a public ledger that can't be edited or deleted.

Traditional copyright registration takes weeks and costs money per filing. ProofAnchor takes seconds and costs pennies. You can timestamp every iteration, every draft, every version as you create it.

The timing matters more than people think. Copyright law has a "first to create" principle, but proving when you created something has always been nearly impossible. Dated emails can be faked. File metadata gets stripped when you upload to platforms. Cloud storage timestamps show when you uploaded, not when you created.

Blockchain timestamps can't be faked.

Think about your creative process. You don't just make one final version. You iterate. You draft, revise, experiment. Each version is a step in your creative journey. Each version deserves protection.

A musician records a demo. Timestamps it. Six months later, they hear something similar on the radio. They can prove their demo existed first.

A designer creates a logo concept. Timestamps it. The client tries to claim they designed it themselves. The blockchain says otherwise.

A writer finishes their novel. Timestamps each chapter as they complete it. Someone plagiarizes sections and claims they wrote them first. The proof is permanent.

AI makes this more urgent. Training datasets scraped millions of creative works without permission. Your art, your writing, your photos might be in there. When AI generates something that looks like your work, how do you prove you had it first?

You can't. Unless you timestamped it.

ProofAnchor doesn't just protect finished work. It protects your creative process. Every draft, every iteration, every breakthrough moment can be anchored permanently. The blockchain remembers what platforms forget.

Your creativity deserves better than "trust me, I made this first." It deserves proof.

Does Blockchain Proof of Existence Hold Up in Court?

Craig Solomon — Wed, 13 May 2026 13:50:26 +0000

You spent months perfecting your design. Someone else publishes it and claims they created it first. You have a blockchain timestamp. They don't. Does that matter in court?

The short answer: blockchain timestamps can serve as evidence of temporal priority, but they're not automatically admissible or conclusive. Like any digital evidence, their weight depends on how they're presented and what you're trying to prove.

Here's what creators need to know about using blockchain timestamps as evidence.

How Courts Evaluate Digital Evidence

Federal Rules of Evidence 901(b)(9) provides the framework for authenticating digital records. Courts look for evidence that shows:

The record accurately reflects what it purports to show
The system that created it was functioning properly
No one altered the record after creation

Blockchain timestamps meet these criteria because they create a cryptographic fingerprint of your file at a specific moment. The hash gets anchored to a public ledger that thousands of nodes verify. Change one bit in your file, and the hash changes completely.

But the timestamp only proves one thing: a file with that exact hash existed when the blockchain recorded it. It doesn't prove who created the file or what the file contains without additional evidence.

What Blockchain Timestamps Actually Prove

A Reddit thread last week highlighted the confusion around digital proof. A creator accused of plagiarism asked how format protection works for social media content. The core issue: proving temporal priority when anyone can copy and modify digital work.

Blockchain timestamps solve the "when" question specifically:

They prove: A file with a specific SHA-256 hash existed at the recorded time.

They don't prove: Who created it, whether it's original, or what the file contains.

This distinction matters. If someone copies your work and timestamps their version later, the blockchain record shows your hash came first. But you still need to prove the copied work derives from your original file.

Real-World Applications in Legal Disputes

Courts have admitted blockchain evidence in several contexts:

Contract disputes: Timestamped agreements show when terms were finalized.

Intellectual property cases: Hash records establish creation dates for copyrightable works.

Trade secret litigation: Blockchain timestamps prove when confidential information existed in specific forms.

The key is presenting blockchain evidence as part of a broader proof strategy, not as standalone validation of ownership.

Technical Authentication Requirements

When presenting blockchain timestamps as evidence, courts typically require:

Chain of custody documentation: How the file moved from creation to timestamping to courtroom presentation.

System reliability evidence: Proof that the blockchain network and timestamping service operated correctly.

Hash verification: Demonstration that the file produces the same hash recorded on the blockchain.

Services like ProofAnchor (proofanchor.com) provide this documentation by anchoring file hashes to the Polygon blockchain and generating verification reports that include transaction IDs, block numbers, and timestamp details.

Combining Blockchain Proof with Copyright Registration

Smart creators use blockchain timestamps and copyright registration together:

Blockchain timestamp: Proves temporal priority within hours of creation.

Copyright registration: Establishes legal ownership and enables statutory damages.

The combination covers both timing and ownership. Your blockchain record shows you had the work on a specific date. Copyright registration shows you own it and gives you enforcement tools.

This matters because copyright protection begins when you create a work, but registration provides additional legal benefits. The blockchain timestamp bridges the gap between creation and formal registration.

Practical Steps for Creators

If you plan to use blockchain timestamps as evidence:

Document your process: Keep records of how and when you timestamp files.

Maintain file integrity: Don't modify timestamped files. Any changes invalidate the hash.

Verify periodically: Check that your blockchain anchors remain accessible and verifiable.

Combine with metadata: Export creation dates from your software, save multiple file versions, document your creative process.

Consider professional guidance: Complex disputes benefit from legal counsel familiar with digital evidence.

Limitations and Realistic Expectations

Blockchain timestamps aren't magic bullets. They work best when:

You timestamp original work before sharing it publicly
You can prove continuous control of the file
The dispute centers on timing rather than ownership

They're less useful when:

Multiple parties claim independent creation
The work builds on existing copyrighted material
You need to prove substantial similarity in infringement cases

Courts evaluate evidence holistically. A strong case combines multiple forms of proof rather than relying on any single record.

The Bottom Line

Blockchain timestamps can strengthen your position in intellectual property disputes, but they're tools in a toolkit, not complete solutions. They excel at proving temporal priority for digital files. They complement but don't replace copyright registration, creator documentation, and other forms of evidence.

The technology works. The legal framework exists. But success depends on understanding what blockchain timestamps prove and presenting that evidence effectively within established legal standards.

C2PA Content Credentials and Blockchain Anchoring: Closing the Chain-of-Custody Gap

Craig Solomon — Wed, 13 May 2026 13:00:00 +0000

C2PA credentials embed provenance in the file. Blockchain anchoring is independent of it. For admissible evidence, both layers matter.

Imagine a homeowner documents roof condition before a forecasted hailstorm, shooting 80 photos on a Samsung Galaxy S25. The phone signs each image at the camera level using C2PA content credentials: device identity, timestamp, GPS coordinates, all embedded cryptographically in the file. Airtight provenance.

Those photos get uploaded to a claim portal. The portal resizes them for storage. The C2PA manifest is gone.

The adjuster now has 80 photos and no provenance. Did they exist before the storm? There's no embedded credential to check. File system timestamps show when files were written to disk, not when the underlying content was created. EXIF data can be altered by any photo editor. The homeowner is back to asking the carrier to take their word for it.

That's the chain-of-custody gap C2PA wasn't built to close.

What C2PA Content Credentials Actually Do

C2PA (Coalition for Content Provenance and Authenticity) is an industry standard backed by Adobe, Google, Meta, Microsoft, and OpenAI. It defines a format for cryptographically signed provenance metadata embedded directly inside media files.

When a C2PA-capable device captures a photo or video, it signs a manifest: who captured it, what device, what timestamp, what edits were applied afterward. That manifest travels inside the file as part of the file format. AI generation tools from Adobe Firefly and Microsoft Designer embed credentials in synthetic content so recipients can identify it as AI-generated.

The EU AI Act Article 50 mandates machine-readable content marking by August 2, 2026. C2PA is the path the industry is converging on. Hardware adoption is already at scale: Samsung Galaxy S25 and Google Pixel 10 both sign media natively. That curve will accelerate.

For forensic and legal purposes, C2PA answers a real question: what is the origin and history of this file? A court can authenticate the output of a C2PA-compliant device under FRE 901(b)(9), which covers evidence produced by a process or system that generates an accurate result. Expert testimony or documentation establishing the reliability of the C2PA signing process satisfies that foundation.

But there's a hard architectural limit.

The Limitation C2PA Can't Fix

The credential lives inside the file.

Any process that touches the file can strip the embedded manifest. This isn't a bug in the standard. It's a consequence of embedding metadata inside a file container: the metadata survives only if every downstream system handles it correctly. In practice, most systems don't.

Common scenarios where C2PA credentials don't make it:

Claim portals and document management systems that re-encode or resize on upload
Email clients that strip metadata to reduce attachment size
Format conversions (HEIC to JPEG is a routine one)
Any intermediary that wasn't built with C2PA preservation in mind

In a property claim dispute where the opposing party challenges whether documentation predates the loss date, a stripped credential is no credential at all. You're arguing about EXIF fields that the other side can challenge in five minutes with any photo editor.

The credential has to survive to the point of the dispute. In claims and litigation, that point can be years later and through a chain of handling no one controlled at the time of capture.

Where Blockchain Anchoring Fits

A blockchain anchor doesn't live in the file. It lives on a public ledger.

The mechanics: compute a SHA-256 hash of your file. That hash is a 64-character fingerprint, deterministic (same file always produces the same hash) and irreversible (you can't reconstruct the file from the hash). Submit that hash for anchoring. The file never leaves your device. What gets written to the chain is a permanent, timestamped record: this specific hash existed at this specific moment.

Because the ledger is public and append-only, that record can't be altered retroactively. Opposing counsel, an auditor, an expert witness: anyone can verify independently using a public verify endpoint or the verify-proof Python package for offline verification. No account, no access credentials, no dependency on ProofLedger continuing to operate.

Critically, the anchor survives everything that happens to the file afterward. Stripped metadata, format conversion, platform re-upload, none of it changes the SHA-256 hash of the original file. If you anchored before the claim event and need to prove it two years later, you verify the hash of the original file against the on-chain record. Either the hash matches or it doesn't.

That independence from file handling is what makes blockchain anchoring useful where C2PA alone fails.

The Authentication Question in Court

Using either layer in court requires meeting the right evidentiary standard.

C2PA credentials, when intact, are evidence of a process. That process is authenticatable under FRE 901(b)(9) with testimony or documentation establishing that C2PA-compliant hardware and software produce accurate provenance records. The foundation is on the proponent to lay.

Blockchain timestamps work the same way under 901(b)(9): you're authenticating the output of the anchoring process by showing the process is reliable. That typically means establishing how hashing and blockchain anchoring work, and why the ledger can't be retroactively altered.

The more interesting path for blockchain anchoring is FRE 902(13), which allows machine-generated records to be self-authenticated through written certification. Rather than calling a live expert, the proponent submits a written certification establishing the mechanics of the anchoring process. That certification, combined with the public ledger record, provides the foundation courts look for under 902(13). Whether a specific court accepts that certification for a specific proof is a question for counsel familiar with that court's practices. But the self-authentication path exists, and it matters because it removes the live-expert dependency.

FRE 902(14) extends this to certified copies of electronic records. If the use case involves producing a certified copy of the anchored hash record as a court exhibit, 902(14) is the rule governing how that certification works.

C2PA credentials don't yet have a clear path under 902(13) or 902(14). The standard is new enough that courts haven't worked through it. That will develop as adoption grows and device manufacturers begin issuing standardized certifications. For now, the authentication burden for C2PA remains heavier than for a blockchain-anchored hash with a certification on file.

Using Both Layers

The strongest chain-of-custody documentation answers two distinct questions.

C2PA answers: what is the history of this file? Device identity, capture timestamp, edit history embedded at creation. Useful for demonstrating continuity between what was captured and what appears in discovery.

A blockchain anchor answers: when did this file exist? Independently, on a public ledger, completely outside the file itself. Survives any chain of handling.

These are different questions, and the evidence needed to answer each one is different. A C2PA credential without a blockchain anchor can be stripped. A blockchain anchor without provenance metadata establishes timing but not origin. Together, they establish both.

What This Means for Documentation Practices

The practical protocol for pre-loss documentation should now include both steps:

Capture on C2PA-capable hardware when possible (Samsung Galaxy S25, Google Pixel 10, or any C2PA-compliant device)
Anchor the original file hash to the blockchain before any upload or transfer

Step two is what protects the timing record if step one gets stripped in transit. A property manager documenting building condition before a tenant move-out, a contractor archiving site conditions before a renovation, a risk manager anchoring baseline inspection photos: the protocol is the same regardless of file type. The product doesn't care what's inside the file. It hashes bytes.

ProofLedger anchors the SHA-256 hash to both Polygon and Bitcoin. Polygon confirms immediately. Bitcoin anchors in a daily batch with merkle proofs, adding the permanent settlement layer. The resulting proof is independently verifiable by anyone with the original file, including parties who have no relationship with ProofLedger.

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

If your documentation practice doesn't include an independent timing anchor alongside C2PA, the EU AI Act rollout and the hardware adoption curve make this a reasonable moment to add one. The credential in the file is better than nothing. It just shouldn't be the only record that the evidence existed.

Learn how ProofLedger handles dual-chain anchoring.

When AI Companies Scrape Your Work: The Evidence Problem Every Creator Faces

Craig Solomon — Tue, 12 May 2026 01:34:25 +0000

Google faces a lawsuit over its Lyria music AI allegedly training on copyrighted YouTube tracks. The case highlights a problem every creator now faces: when AI systems scrape your work without permission, copyright law protects you less than you think.

The real issue isn't whether you own your work. It's whether you can prove when you created it.

Copyright Registration Won't Save You From AI Scraping

Most creators believe copyright registration provides bulletproof protection. They're wrong about the timeline.

Copyright exists the moment you create something. But proving that moment in court requires evidence. A copyright certificate only proves you filed paperwork months after creation. In disputes over AI training data, that gap matters.

Consider a musician who uploads an original track to SoundCloud in January. They register it with the Copyright Office in June. An AI company scrapes SoundCloud in March and trains a model that can generate similar music. The registration certificate proves nothing about January.

The Copyright Office processes applications in 3-6 months for standard cases. During that window, your work lives unprotected in practical terms. Not legally unprotected. Factually unprotected. You can't prove the creation date that triggers your copyright.

Notary Public: Expensive and Limited

Some creators turn to notaries for timestamp evidence. A notary can witness that you possessed a document on a specific date. But notarization costs $5-25 per document and requires physical presence. For digital creators producing multiple works weekly, notarization becomes expensive fast.

Notaries also vary in their willingness to authenticate creative work without clear legal guidance. The process works for contracts and legal documents. Creative files exist in a gray area many notaries prefer to avoid.

More importantly, notarized documents can be disputed. They prove you showed something to a notary, not that you created it. A skilled attorney can question the notary's memory, the document's authenticity, or whether modifications happened before notarization.

Blockchain: Third-Party Verification That Sticks

Blockchain timestamping solves the evidence gap. When you anchor a file's SHA-256 hash to a public blockchain, you create permanent, independently verifiable proof the file existed at that block time.

No one can dispute the timestamp. Blockchain records are public, immutable, and maintained by thousands of independent nodes. A file hash anchored to Polygon block 52,847,291 existed when that block was mined. Period.

The hash proves file integrity too. If someone claims you modified your work after seeing their AI-generated version, the blockchain hash proves the exact file existed before their claim. Hash comparison is mathematical, not testimonial.

Your File Never Leaves Your Device

ProofAnchor creates blockchain timestamps without uploading your work anywhere. The service computes your file's SHA-256 hash locally, then anchors only that hash to Polygon. Your original file stays on your device.

This matters for confidential work. A songwriter can timestamp demos without sharing them. A novelist can anchor manuscript drafts without publication risk. The blockchain proves the file existed without revealing its contents.

Evidence Lawyers Actually Want

Blockchain timestamps create the kind of evidence copyright attorneys prefer: third-party verified, tamper-proof, and independently checkable. No relying on your word, your computer's clock, or a notary's memory.

When an AI company claims your work doesn't predate their training data, blockchain timestamps answer definitively. The proof exists on a public ledger anyone can verify.

Copyright law protects your work. But protection without proof is just theory. Blockchain timestamping turns theory into evidence that stands up in court.

ProofAnchor creates blockchain timestamps in seconds. Your work gets the evidence it deserves.

Content Credentials and Blockchain: Why Creators Need Both Standards

Craig Solomon — Tue, 12 May 2026 01:34:09 +0000

Publishers are suing tech companies over AI training on copyrighted work. These lawsuits highlight a gap that's becoming critical for every creator: proving not just who made something, but when they made it.

Two standards are emerging to solve this problem. Content Credentials (C2PA) and blockchain timestamping. Most creators think it's one or the other. It's not. You need both.

What C2PA Content Credentials Actually Do

Content Credentials is an open standard backed by Adobe, Google, Meta, Microsoft, and OpenAI. It embeds a cryptographically signed record directly into your files.

The credential documents who created the file, what device captured it, and every edit made afterward. Samsung Galaxy S25 phones sign photos automatically at the camera level. Adobe Creative Suite adds credentials to exports. Google Pixel 10 cameras embed them natively.

Think of it as a digital birth certificate that travels with your file. The signature proves authenticity. If someone modifies your photo, the credential shows exactly what changed and when.

The technical implementation uses public-key cryptography. Your device generates a private key and signs a manifest describing the file's creation. Anyone can verify the signature using the corresponding public key, confirming the credential wasn't forged.

Where C2PA Falls Short

Here's the problem: Content Credentials live inside the file itself. Upload your photo to Instagram, Twitter, or most platforms. The metadata gets stripped. The credential disappears.

This isn't malicious. Platforms compress images, strip EXIF data, and reprocess files for performance. Your carefully embedded credential gets deleted in the process.

Even worse: if you publish your work anywhere online, someone can download it and claim they created it. They can't forge your C2PA signature, but they can remove it entirely and create their own.

C2PA proves who made the current version of a file. It doesn't prove who had it first.

Why Blockchain Timestamping Is Different

Blockchain anchoring works the opposite way. Instead of embedding proof in your file, it records proof outside your file. On a public ledger that no platform can touch.

ProofAnchor takes your file's SHA-256 hash and anchors it to the Polygon blockchain. The hash proves your exact file existed. The blockchain timestamp proves when. Both are permanent.

Upload your photo to Instagram. The platform strips everything. But your blockchain anchor remains untouched. Anyone can verify you had that exact file hash at that exact time, regardless of what Instagram did to the metadata.

The anchor is independent. It survives file compression, platform changes, and metadata stripping. If someone steals your work and claims they made it, the blockchain shows you had it first.

The EU AI Act Changes Everything

Starting August 2026, the EU AI Act requires machine-readable provenance markers on AI-generated content. Content Credentials will likely become the standard for compliance.

But here's what the regulation misses: proving something is human-made requires proving when the human made it. C2PA shows who and what. Blockchain shows when.

A photographer shoots a landscape photo in 2025. Samsung embeds a C2PA credential proving human capture. But if AI generates a similar image in 2027, how do you prove the human version came first?

The C2PA credential proves the photo wasn't AI-generated. The blockchain anchor proves you had it before AI could have made it.

Different Problems, Different Solutions

C2PA and ProofAnchor solve different parts of the same problem.

C2PA answers: Who created this? What device captured it? How was it edited?

ProofAnchor answers: When did this file exist? Can you prove you had it first?

Together they create complete provenance. C2PA proves authenticity. Blockchain proves priority.

A musician records a track and uploads it to streaming platforms. Adobe embeds C2PA credentials proving human creation and documenting the recording equipment used. ProofAnchor anchors the track's hash to Polygon, timestamping when the file existed.

Six months later, AI generates a similar track. The musician has two layers of proof: C2PA showing human creation, and blockchain showing they had their version first.

Why You Can't Pick Just One

Platform metadata gets stripped. Files get recompressed. Credentials disappear.

But blockchain anchors survive anything platforms do to your files. They prove temporal priority when authenticity isn't enough.

Copyright registration takes weeks. Blockchain timestamping takes seconds. C2PA proves human creation. Blockchain proves you had it first.

The future of creator protection isn't choosing between standards. It's using both where they're strongest.

ProofAnchor anchors your work to Polygon in seconds. Try it free at proofanchor.com.

Why Dual-Chain Anchoring (Polygon + Bitcoin) Strengthens Evidence Admissibility

Craig Solomon — Mon, 11 May 2026 13:00:00 +0000

Dual-chain anchoring to Polygon and Bitcoin means two independent verification paths. Why that matters when opposing counsel challenges your blockchain evidence.

Opposing counsel's job is to find the crack. With a single-chain blockchain timestamp, there's one to find: who controls the chain?

That question isn't frivolous. It's the right question for any evidence that depends on a third-party system to establish timing. And if your documentation lives on only one ledger, the trustworthiness of that ledger is the entire argument.

The Single-Chain Problem

A blockchain timestamp proves that a specific hash existed at a specific time, according to a specific ledger. Authentication challenges eventually reach the same question: what makes this ledger trustworthy?

For any single chain, an expert witness has to explain that chain's consensus mechanism, its validator set, its governance history, and why that specific network hasn't been manipulated or reorganized in ways that affect your record. That's a defensible argument. But it's one thread, and threads get pulled.

Two independent chains produce two separate proofs that agree. Bitcoin's proof-of-work consensus and Polygon's proof-of-stake consensus operate under entirely different mechanisms, controlled by entirely different participants, recorded on entirely different ledgers. For both to contain the wrong timestamp for the same hash, the error would have to propagate across two networks with no connection to each other. That's not a realistic attack to construct, which means it's not a realistic argument to make in opposition.

How Polygon and Bitcoin Work Together

ProofLedger anchors the same SHA-256 hash to both chains, but on different timelines.

Polygon confirms within minutes. You get near-instant proof that a file existed at the moment of submission, which matters for time-sensitive documentation. A site inspection photo, a pre-storm roof condition report, a baseline video of equipment condition: when those files are anchored, the Polygon timestamp records the moment.

Bitcoin anchors in daily batches using merkle proofs. Each hash is included in a merkle tree, that root is anchored to the Bitcoin blockchain, and the merkle proof lets anyone verify a specific file's inclusion in that batch without relying on ProofLedger to report it accurately. Bitcoin's proof-of-work history runs over 15 years. The accumulated computational work behind that chain makes rewriting it economically prohibitive at any realistic scale.

The two records reinforce each other. Polygon gives you speed. Bitcoin gives you permanence. Neither proof depends on the other to be valid. But together, they create a position where an authentication challenge has to defeat both verification paths simultaneously.

What Independent Verification Actually Means

ProofLedger's public verify endpoint is proofledger.io/api/v1/verify?hash=<sha256>. No authentication required. 120 requests per hour per IP. The endpoint returns the proof record with explorer URLs for both chains.

Opposing counsel can run verification themselves. An auditor can run it. A forensic expert retained by either side can run it. There's nothing to subpoena. The verification doesn't require asking ProofLedger for anything. Both anchors are on public ledgers that anyone can query directly.

This matters because a common challenge to timestamping services is the argument that the record is only as trustworthy as the company that issued it. When verification runs against two independent public networks, the company issuing the original proof becomes less central to the admissibility argument. The ledgers speak for themselves.

FRE 901(b)(9): Process Reliability at Two Points

Authentication of a blockchain timestamp under FRE 901(b)(9) requires establishing that the evidence was produced by "a process or system that produces an accurate result." This is a foundation requirement: expert testimony or technical certification that the process is reliable.

Dual-chain anchoring gives that foundation more to work with. You're not just establishing that one system produced an accurate result. You're establishing that two systems, operating under entirely different consensus models, produced records that agree. The convergence is part of the reliability argument.

This doesn't automate authentication. You still lay the foundation. But the foundation is structurally more defensible when two independent ledgers corroborate the same hash at the same time.

Self-Authentication Under FRE 902(13) and 902(14)

If the proof record is presented with a written certification from ProofLedger attesting to the process used to generate and anchor the hash, FRE 902(13) is the applicable path. Machine-generated records can self-authenticate under 902(13) through a written certification, without live testimony.

FRE 902(14) covers certified electronic copies of electronic records. The right path depends on how the proof is packaged and the specific jurisdiction. That's a question for counsel who knows the court.

What dual-chain anchoring adds here isn't a different evidentiary rule. It's additional corroboration if the certification alone gets challenged. The certification establishes the process. The two ledgers provide independent verification of the output. Those are separate layers of support, and having both matters when authentication is genuinely contested.

A Concrete Example

Imagine a public adjuster documenting a commercial property before hurricane season. She photographs the roof, the structural exterior, the HVAC units on the rooftop deck. The files get anchored. Six months later, a storm causes significant damage and a dispute arises over what was pre-existing versus storm-caused.

On single-chain anchoring, the evidence stands on one ledger's record. A technical challenge can concentrate entirely on that chain's reliability.

On dual-chain anchoring, the same documentation is independently verifiable on both Polygon and Bitcoin. A challenge to the Polygon record has to contend with the Bitcoin anchor confirming the same hash. A challenge to the Bitcoin record has to contend with the Polygon anchor. Defeating both, under different consensus mechanisms, producing agreeing records, is a qualitatively different argument. It's not impossible to construct in theory. It's impractical enough that most challenges don't survive contact with it.

The File Never Leaves the Machine

For anyone new to how this works: the file itself doesn't go anywhere. What gets anchored to both chains is the SHA-256 hash, a fixed-length fingerprint of the file's contents. A 4GB drone survey and a two-page site inspection report take the same path. The product doesn't distinguish by file type, category, or claim. It hashes bytes and anchors the hash.

This means the file can't be intercepted or exposed during submission. It also means chain-of-custody integrity starts the moment documentation is created and holds through the anchoring process, because nothing with the file's actual content ever leaves the device.

Anchor Before the Dispute

The admissibility argument is the courtroom argument. The practical argument is more direct.

A timestamp anchored before the loss date proves pre-loss existence. Dual-chain anchoring means that proof is verifiable two ways, independently, by anyone with the hash and an internet connection. The documentation that was treated as routine at the time it was created becomes the strongest record available when timing is disputed.

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

If you handle evidence across claims or matters where timing authenticity gets challenged, the dual-chain verification model is worth reviewing.

Verify a blockchain timestamp in Python (10 lines)

Craig Solomon — Mon, 11 May 2026 10:32:06 +0000

You've got a file and a .proof.json claiming it was timestamped on a blockchain. Is the proof real? Here's how to verify it in Python. The proof was generated by ProofAnchor, a service that anchors SHA-256 hashes to the Polygon blockchain. The file itself never leaves the user's machine; only the hash is anchored.

Install the verification package

The verify-proof package handles the cryptographic verification for you. It works with ProofAnchor proofs and any OpenTimestamps-compatible proof format.

pip install verify-proof

The package gives you three functions: hash_file() to get a file's SHA-256 digest, load_proof() to read a proof file, and verify_proof() to check if they match.

The verification script

Here's the complete verification in 10 lines:

from verify_proof import hash_file, load_proof, verify_proof

# Hash the original file
file_hash = hash_file("document.pdf")

# Load the blockchain proof
proof = load_proof("document.pdf.proof.json")

# Verify they match
result = verify_proof(file_hash, proof)

print(f"Verified: {result['verified']}")
print(f"Transaction: {result.get('tx_id', 'None')}")

That's it. The verify_proof() function returns a dict with the verification result. If verified is True, the file hash matches the proof and the proof contains a transaction ID. If it's False, something doesn't match.

The proof file contains the expected hash, the blockchain transaction ID, and optionally a Merkle path if the proof was batched with other files. The verify_proof() function checks that your file's hash matches the hash in the proof, and that the proof structure is valid.

Handle missing proofs and errors

Real workflows need error handling. Here's a more robust version:

import os
from verify_proof import hash_file, load_proof, verify_proof

def verify_file_proof(file_path):
    proof_path = f"{file_path}.proof.json"

    if not os.path.exists(proof_path):
        return {"error": "No proof file found"}

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

        if result['verified']:
            return {
                "status": "VERIFIED",
                "blockchain": result.get('blockchain', 'unknown'),
                "anchored_at": result.get('anchored_at'),
                "tx_id": result.get('tx_id')
            }
        else:
            return {
                "status": "FAILED", 
                "reason": result.get('error', 'Hash mismatch')
            }
    except Exception as e:
        return {"error": f"Verification failed: {str(e)}"}

# Test it
result = verify_file_proof("important-document.pdf")
print(result)

This version checks if the proof file exists, catches any exceptions during verification, and returns structured results you can use in larger applications.

Batch verification

If you have a folder full of files with matching proof files, you can verify them all:

import os
from pathlib import Path
from verify_proof import hash_file, load_proof, verify_proof

def verify_folder(folder_path):
    folder = Path(folder_path)
    results = []

    for file_path in folder.glob("*"):
        if file_path.suffix == ".json" or file_path.is_dir():
            continue

        proof_path = folder / f"{file_path.name}.proof.json"

        if proof_path.exists():
            try:
                file_hash = hash_file(str(file_path))
                proof = load_proof(str(proof_path))
                result = verify_proof(file_hash, proof)

                results.append({
                    "file": file_path.name,
                    "verified": result['verified'],
                    "tx_id": result.get('tx_id'),
                    "blockchain": result.get('blockchain')
                })
            except Exception as e:
                results.append({
                    "file": file_path.name, 
                    "error": str(e)
                })

    return results

# Verify everything in a folder
results = verify_folder("./documents")
verified_count = sum(1 for r in results if r.get('verified'))
print(f"Verified {verified_count}/{len(results)} files")

This scans a folder, finds files with matching .proof.json files, and verifies each pair. Useful for document archives or backup verification.

What's next

The verify-proof package handles the crypto for you, but verification is offline-only. It confirms the file matches the proof structure, but doesn't check if the transaction ID actually exists on-chain. For that, you'd query a blockchain explorer API separately.

Get the package at PyPI or check the source at GitHub. The package works with any proof format that includes a file hash and transaction reference.

What Is a Neutral Temporal Authority? How Blockchain Timestamps Solve the Evidence Timing Problem

Craig Solomon — Sat, 09 May 2026 21:26:25 +0000

A contractor documents a commercial roof before hurricane season. Forty-two photos. Organized in a shared drive, names carry the date, EXIF data shows the capture time. Six months later, when the carrier disputes pre-loss condition, opposing counsel challenges every image. Where's the proof they were taken before the storm?

The photos exist. The dates exist. The proof doesn't.

The Problem with "Timestamped" Evidence

When people say their files are timestamped, they usually mean one of three things: the filename has a date, the EXIF metadata shows a capture time, or the file's "modified" attribute in the operating system is visible.

None of these hold up in a dispute.

EXIF fields can be changed with free software in under a minute. File system timestamps reset on copy, sync, or backup. Device clocks can be wrong or adjusted. These aren't fringe failure modes. They're routine vulnerabilities opposing counsel knows how to exploit.

Video evidence has the same problem, often in ways that aren't obvious. A video file carries a device clock, encoding timestamps, sometimes GPS data. But every one of those fields is self-reported. It's the camera saying when it thinks the footage was captured. That's evidence from a party with a direct interest in the outcome.

Courts care about this distinction. A party's own records, created on their own devices, raise authenticity questions. What you need is a neutral third party that can verify when evidence existed without any ability to manipulate the timeline after the fact.

What Makes a Timestamp "Neutral"

A neutral temporal authority has three characteristics:

Independence. It operates outside the control of any party to the dispute. The entity creating the timestamp can't be influenced, bribed, or pressured by either side.

Immutability. Once a timestamp is recorded, it can't be changed or deleted. Not by the original creator, not by administrators, not by court order.

Verifiability. Any party can independently confirm the timestamp's accuracy without relying on testimony from the authority itself.

Traditional timestamping services fail on at least one of these criteria. A corporate timestamping service might be independent, but their records can be altered by employees or lost in a system failure. Government agencies might be trustworthy, but they don't offer public verification. Digital certificates expire and can be revoked.

How Blockchain Creates True Temporal Neutrality

Blockchain networks solve the neutral authority problem by distributing timestamp verification across thousands of independent nodes worldwide. No single entity controls the ledger. No administrator can alter historical records. Every timestamp can be verified by anyone with internet access.

Here's how it works for evidence documentation:

Hash creation. When you document evidence, ProofLedger calculates a SHA-256 hash of each file. This hash is a unique digital fingerprint. If even one pixel in a photo changes, the hash changes completely.
Blockchain anchoring. That hash gets written to both Polygon (for instant verification) and Bitcoin (for maximum security). The blockchain records the exact block number and timestamp when the hash was anchored.
Independent verification. Anyone can look up that hash on the blockchain and see exactly when it was recorded. The timestamp comes from the blockchain itself, not from ProofLedger or any other party.

The evidence files never leave your device. Only the hash gets anchored. This means your sensitive documentation stays private while the timestamp becomes public and verifiable.

Legal Framework: How Courts Handle Blockchain Timestamps

Federal courts can authenticate blockchain timestamps under FRE 901(b)(9), which allows authentication of evidence produced by "a process or system that produces an accurate result." This requires laying a foundation through expert testimony or certification about how blockchain verification works.

For records that meet certain requirements, FRE 902(13) and 902(14) allow self-authentication of machine-generated records through written certification. No live testimony required. These rules, added in 2017, specifically address the challenge of authenticating digital records in modern litigation.

The key advantage: blockchain timestamps create an independent record that exists outside any party's control. When an adjuster's photos are challenged, the timestamp isn't coming from the adjuster's device or the carrier's system. It's coming from a distributed network that no single entity can manipulate.

Real-World Application: Pre-Loss Documentation

Consider a property manager documenting a building's condition before wildfire season. Traditional approach: take photos, store them on the company server, hope the metadata holds up if there's a claim.

With blockchain anchoring: each photo gets hashed and anchored the moment it's taken. Six months later, when a fire damages the building and coverage becomes an issue, the timestamp evidence is ironclad. The blockchain shows exactly when each image existed. No one can claim the photos were taken after the loss or that the timestamps were manipulated.

The same principle applies to construction progress documentation, equipment inspections, accident scenes, product defects, or any situation where the timing of evidence matters more than the content.

Why Independent Verification Matters

In traditional evidence disputes, timestamp challenges often become battles of expert witnesses. One side brings a digital forensics expert to challenge the metadata. The other side brings their own expert to defend it. The jury has to decide which expert to believe.

Blockchain timestamps eliminate that dynamic. The verification process is mathematical, not testimonial. Any expert can independently verify when a hash was anchored by checking the public blockchain. There's no opinion involved, no competing interpretations. Either the hash appears in a specific block at a specific time, or it doesn't.

This shifts the authentication burden from "trust our expert" to "verify the math." For insurance and legal professionals dealing with evidence challenges, that's the difference between a disputed timestamp and an accepted one.

Building Evidence That Lasts

The goal isn't just to create evidence. It's to create evidence that survives challenge. Traditional timestamps depend on the integrity of the creating party. Blockchain timestamps depend on the integrity of mathematics and distributed consensus.

When evidence timing becomes a dispute, having a neutral temporal authority makes the difference between a credible record and a questioned one. The blockchain doesn't care who wins the case. It just records what happened when.

That neutrality is what makes blockchain timestamps court-ready from day one. Not because they're new or impressive, but because they're independently verifiable by any party to a dispute.