Both services anchor a file hash to a blockchain. The core workflow is similar: submit a hash, receive proof of a timestamp. What differs is the trust model behind verification -- specifically, whether confirming that timestamp requires the vendor to be operational, and what proof you actually hold when it doesn't.

For legal and insurance contexts, that distinction isn't theoretical. A claim filed today might be litigated in three years. Chain of custody arguments can hinge on whether a third party can independently verify a timestamp, not just whether you possess a certificate.

What OriginStamp Is and How It Works

OriginStamp is a hosted blockchain timestamping service with a REST API. You submit a hash; they batch multiple submissions into a Merkle tree and anchor the root to Bitcoin on a periodic schedule. Out of that process comes a certificate or proof document confirming your hash was included in that batch.

The trust model runs through the vendor. OriginStamp manages submission processing, the batch schedule, certificate issuance, and verification. A third party confirming a timestamp queries their system or checks against the certificate they issued.

The architectural question is what happens at the moment of verification. A Merkle path is in principle independently verifiable -- if you have the full path from your hash up to the anchored root, you can reconstruct the computation and check it against the Bitcoin transaction without involving OriginStamp. Whether their certificate contains everything needed to do that, and whether the reconstruction is practical without their tooling, is worth confirming before a dispute requires it.

There's also a timeline consideration. Hosted services change. APIs deprecate. If a verification workflow depends on a vendor's portal being online, the durability of that verification depends on the vendor. For legal matters that can take years, that's a real variable.

What ProofLedger Does Differently

ProofLedger anchors to two independent chains: Polygon (instantly) and Bitcoin (in a daily batch with full Merkle proofs). Only the SHA-256 hash is transmitted. The file stays on the anchoring party's machine.

Each proof returns a public verification URL that resolves to the on-chain anchor record. Any verifying party has three independent paths:

  • The public URL, which any browser can load
  • The verify-proof CLI or Python package, which performs offline Merkle path verification against the proof JSON
  • Any public Polygon or Bitcoin block explorer, using the transaction ID included in the proof

None of these require ProofLedger's API to be responding. The anchor transactions exist on both blockchains independently of the service.

The two-chain structure matters for durability. Bitcoin has operated continuously since 2009. Multiple independent explorer services index it. Expert testimony about its operation and reliability as a ledger is well-established territory for courts. Polygon provides the immediate anchor for operational workflows. Together, the proof doesn't depend on either chain's current state in isolation, and the Bitcoin record carries the weight of a long-running public ledger that predates most of the disputes it might be cited in.

Verifying a Proof Yourself

Independent verification uses the verify-proof package. No ProofLedger account required. No network call to the service.

Install:

pip install verify-proof

Hash your file:

verify-proof hash evidence.pdf

Verify against the proof JSON:

verify-proof verify evidence.pdf --proof proof.json

Exit code 0 means verified. Exit code 1 means not verified. The package walks the Bitcoin Merkle path locally using SHA-256 -- the same hash combination logic used at anchor time. Nothing leaves your machine during this step.

The Python API gives you the same verification programmatically:

from verify_proof import hash_file, load_proof, verify_proof

file_hash = hash_file("evidence.pdf")
proof = load_proof("proof.json")
result = verify_proof(file_hash, proof)

if result["verified"]:
    print(result["blockchain"])     # "bitcoin"
    print(result["tx_id"])          # Bitcoin transaction ID
    print(result["anchored_at"])    # ISO timestamp
    print(result["merkle_root"])    # computed from the Merkle path

The tx_id in that result is a standard Bitcoin transaction ID. Any party with access to a block explorer -- opposing counsel, a carrier's expert, a court-appointed examiner -- can look it up independently. It's a transaction on a public ledger, not a ProofLedger-specific identifier.

Package: https://pypi.org/project/verify-proof/ Source: https://github.com/Fulcrum-Enterprises/verify-proof

Which Fits Your Situation

If you need a third-party timestamp certificate for compliance or internal records, and your verification workflow runs through a vendor's portal or issued certificate, OriginStamp is a functional hosted service with an API.

If the timestamp will be challenged in a legal or insurance context, the question shifts. Can the verifying party confirm the anchor without calling on the vendor? Is the Merkle path fully self-contained in what you hold? Does your verification workflow survive the vendor changing its API or going dark?

ProofLedger is built for the scenario where those questions have to have clean answers. The proof file contains the full Merkle path. Transaction IDs are on two public blockchains. The verify-proof package performs the reconstruction offline, and any party can replicate it independently.

Under FRE 901(b)(9), courts authenticate evidence produced by a process that generates an accurate result. Blockchain anchoring supports that foundation, but it requires laying it -- typically expert testimony or written certification about the process and its reliability. An independently verifiable Merkle path to a public Bitcoin transaction gives an expert something concrete and reproducible to attest to. That's a different position than attesting to a vendor-issued certificate.

For authentication without live testimony, FRE 902(13) and FRE 902(14) allow machine-generated records to be self-authenticated through written certification. A dual-chain proof with a public verification URL and a reproducible Merkle path gives the certifying party the materials that certification requires.

The argument isn't that hosted timestamping is unreliable. It's that independent verifiability is a specific property, and whether you have it depends on architecture. Pre-loss documentation, insurance claims where timing will be contested, chain of custody for disputed evidence -- these are contexts where "the vendor can confirm it" isn't the same as "anyone can confirm it."

proofledger.io