OriginStamp vs ProofLedger: Architecture, Verification, and What You Hold

Both are hosted services. You send a file's hash through an API, and a record of that hash ends up in a public blockchain transaction. If that were the whole story there would be little to compare. The part that matters is what you are holding on the day you need to show the proof to someone else, and whether the vendor has to be reachable for that to work. This post describes each service's architecture from its public documentation and then walks through the check you can run yourself.

What OriginStamp does

OriginStamp is a hosted timestamping service with a web dashboard and a REST API. You submit a hash and it returns a timestamp record. According to its documentation, submitted hashes are collected into a Merkle tree and the root is anchored in a blockchain transaction on a schedule; its documentation lists the chains it anchors to, Bitcoin among them.

What you get back is a certificate and a proof record for your submission. Checking a timestamp runs through OriginStamp's verification page or its tooling: you present the hash or the file, and its system reports whether and when it was anchored.

The thing to confirm from its documentation before you rely on it is what the proof record contains. Because many hashes share one transaction, the only thing that connects your hash to the on-chain root is the path of sibling hashes between them. If the proof record you download carries that full path, you can recompute the root yourself and compare it with the transaction, with no further help from the vendor. If it does not, the vendor's page is the only way to make that connection.

Where the dependency actually lives

Separate the two layers.

The on-chain layer is public. Once a transaction is confirmed, anyone with a block explorer can see that a given value was recorded at a given block and time. That part is not the vendor's to control, whichever vendor wrote it.

The layer on top is the vendor's: the certificate format, the lookup page, the tooling that walks the path from your hash to what is on chain, and the database that remembers which submission went into which batch. If a check depends on any of that, it depends on the vendor still running it. The question to ask of any hosted anchoring service, OriginStamp or ProofLedger, is which layer your check runs through.

What ProofLedger does

ProofLedger takes a SHA-256 hash and anchors it in its own Polygon transaction, usually within a minute. One transaction per proof. The file stays on your machine; the request carries the hash, an optional file name and an optional external_id (your own record id, which makes a repeat of the same request return the same proof).

curl -X POST https://proofledger.io/api/v1/proof \
  -H "Authorization: Bearer sk_your_key" \
  -H "Content-Type: application/json" \
  -d '{"sha256": "b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9", "filename": "report.pdf", "external_id": "report-7781"}'

A new proof answers 201 with its id, polygon_status (PENDING until the transaction is recorded), a certificate_url and a verification_url. When the anchor lands, GET /api/v1/proof/{id} shows polygon_status as ANCHORED with the transaction hash in chain_tx and a Polygonscan link in explorer_url; a webhook registered with POST /api/v1/webhooks delivers the same moment as a proof.polygon.anchored event.

Then download the bundle and keep it with the file:

curl -H "Authorization: Bearer sk_your_key" \
  "https://proofledger.io/api/v1/proof/42/bundle?download=1" -o report.pdf.proof.json

Abridged, the bundle looks like this:

{
  "format": "verify-proof/1",
  "service": "proofledger",
  "hash": "b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9",
  "algorithm": "sha256",
  "blockchain": "polygon",
  "tx_id": "0xabc123...",
  "anchored_at": "2026-10-15T02:11:09.512Z",
  "merkle_path": [],
  "proof_id": 42,
  "certificate_url": "https://proofledger.io/cert/42"
}

merkle_path is empty because the hash is in its own transaction; there is no tree to climb. The bundle is the whole of what you need to hold: hash, chain, transaction id, anchor time.

Applied to the two layers above: the Polygon transaction is the record. ProofLedger's certificate page, its public verify endpoint and its database are convenience views of that transaction. They are useful, and none of them is required for the check.

For completeness: before 15 October 2026 ProofLedger also anchored some proofs on Bitcoin in daily batches, and bundles from that period carry a Merkle path; every proof since is Polygon only.

Running the check yourself

The open-source verify-proof tool (PyPI and npm) checks a file against its bundle with no network and no account:

pip install verify-proof
verify-proof verify report.pdf --proof report.pdf.proof.json

Exit code 0 means the file matches the bundle and the bundle names a transaction; the output tells you which transaction to look up. Exit code 1 means it does not match. From Python:

from verify_proof import hash_file, load_proof, verify_proof

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

if result["verified"]:
    print(result["blockchain"])   # "polygon"
    print(result["tx_id"])        # transaction to open on a block explorer
    print(result["anchored_at"])  # anchor time, as the bundle records it
else:
    print(result["error"])

What it does: recompute the file's SHA-256, compare it with the hash in the bundle, and report the transaction. What it does not do: read the chain. The anchor time stays the bundle's claim until you open the transaction id on a block explorer and see the hash and the block time there. That second step needs nothing from ProofLedger either.

If a third party has only a hash, the public endpoint answers without a key, rate limited to 120 requests an hour per IP:

curl "https://proofledger.io/api/v1/verify?hash=b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9"

It returns found, and when found the proof's chain_tx and an explorer_url. Treat it as a shortcut to the transaction, not as the record.

What either proof shows

A file with this exact hash existed by the time of the anchoring transaction, and the file in hand has not changed since. Not who made it, not that its contents are accurate, not who owns it. Whether a court accepts any of this is for the court and the lawyers.

Which fits your situation

If you want a hosted timestamp with a dashboard and a certificate, and your verification will run through the vendor's page, OriginStamp does that. Read its documentation on what the downloadable proof contains, and test a recompute yourself before you depend on it.

If you want each hash in its own public transaction, a bundle in a documented open format, a webhook when the anchor lands, and a check that runs with the vendor absent, ProofLedger is built around that. Keep the file and the bundle together, and the proof stays checkable as long as the Polygon chain and any explorer for it exist.

To check a ProofLedger proof without ProofLedger: run verify-proof verify on the file and its bundle, then open the bundle's tx_id on any Polygon block explorer. The API is documented at https://proofledger.io/api.html.