OpenTimestamps is a protocol you operate. A client sends your file's hash to calendar servers, the calendars aggregate hashes into a Merkle tree and anchor the root to Bitcoin, and you keep the resulting proof file. Readers go looking at other options when they need something outside that scope: a verification page a non-technical third party can open in a browser, a REST API with keys behind it, a vendor relationship, or a standards-based timestamp that drops into an existing certificate workflow. The useful way to compare the options is not by chain. It is by what you end up holding, and what the person on the other side has to do with it.
The main alternatives to OpenTimestamps
RFC 3161 timestamping authorities
RFC 3161 is an IETF standard for timestamping over a certificate-based trust model. FreeTSA, DigiCert, Sectigo and others operate Timestamping Authorities under it.
How it works: your client builds a TimeStampReq containing the SHA-256 hash of the file and posts it to the authority. The authority signs the hash together with its own clock reading using its private key, and returns a TimeStampToken. On the command line, openssl ts -query builds the request and openssl ts -verify checks the reply.
Who you have to trust: that authority and its certificate chain. The timestamp means what it says because a named organization asserts it and signs that assertion with a key tied to a chain of certificates.
How a third party verifies it: they need the token, the file, the authority's certificate, the chain above it, and tooling that can validate all of it. The check is cryptographic, and it resolves to a question about one issuer's key and the status of its certificates at the relevant time. That is the tradeoff you take on under this model. The evidentiary weight of the timestamp is bound to the standing of the authority that issued it.
Hosted blockchain timestamping services
This category covers services that take a hash through an API and anchor it to a public chain on your behalf. OriginStamp is a hosted blockchain timestamping service with an API.
How it works: you hash the file locally, send the hash to the service, and the service writes it to a chain in its own transaction, usually batching many customers' hashes together to share the on-chain cost.
Who you have to trust: the vendor, for the window between submission and anchoring. After the transaction confirms, the chain holds the record and the vendor's cooperation is no longer required for the record to exist. Whether it is required for the record to be checkable is a separate question, and it is the one worth asking.
How a third party verifies it: it depends on what the service hands back. Three architectural questions decide it. Which chains carry the anchor. Whether a recipient can walk the path from your file's hash to a confirmed on-chain transaction using public data and local tooling. And what you are left holding if the service is unavailable on the day someone challenges the file. Ask those before you ask about anything else.
Transparency logs built for software artifacts
Sigstore is the main example. It combines cosign, Fulcio and Rekor. It was built for signing and verifying software artifacts, and its shape reflects that.
How it works: cosign signs an artifact using a short-lived certificate issued by Fulcio, which binds the certificate to an identity from an identity provider such as a GitHub or Google account. The signature is then recorded in Rekor, an append-only transparency log operated by the Sigstore project.
Who you have to trust: the transparency log and the identity provider. The log's job is to make entries publicly auditable and non-removable. The identity provider's job is to attest who was signing.
How a third party verifies it: by querying the log and validating the certificate's identity binding. What comes out of that is an identity-bound signature plus a log entry showing when it was recorded. The trust model has operators in it, which is the structural difference from a public ledger with none. And the verification path runs through tooling and concepts built for release pipelines, which is the other thing to weigh if the file in question is a photograph or a PDF and the recipient is not an engineer.
ProofLedger
ProofLedger anchors the SHA-256 hash of any file to Polygon and Bitcoin, and gives every proof a public verification URL.
How it works: one engine, no file-type-specific pipeline. The bytes are hashed with SHA-256 on your machine, the 256-bit hash, 64 hex characters, is submitted, and a proof comes back. The product does not look inside the file and does not need to. The file itself never leaves your machine, which is true for every file type and every size, including the ones too large or too confidential to upload anywhere.
The anchor is dual. The same hash goes to Polygon and to Bitcoin, so the record is independently verifiable on two public chains rather than one. Polygon anchoring happens right away. Bitcoin is optional and batched daily.
Who you have to trust: for the record to exist, the chains. There is no issuing authority whose key has to be validated and no certificate chain to resolve. The claim the anchor supports is exact, and worth being exact about: this file existed in this precise byte-for-byte form no later than the moment of the anchor. It says nothing about who made the file, and nothing about when the content inside it was created.
How a third party verifies it: three ways, and this is where the platform does its work.
Every proof gets a public verification URL that anyone can open in a browser, with no account and no login. Opposing counsel or an auditor can check a hash without contacting you and without being handed credentials.
The verify-proof package on PyPI performs the same check offline and locally. A recipient who does not want to call any server, or who works on a machine that cannot reach one, runs the check themselves against public chain data.
The REST API v1 has exactly three endpoints. POST /api/v1/proof submits a hash with Bearer sk_ auth, taking a body of {"sha256": "<64 hex chars>", "filename": optional label, "bitcoin_requested": optional boolean} and returning 201 with id, sha256, status, created_at, duplicate_of, certificate_url and verification_url. GET /api/v1/proof/:id returns status, chain_tx and bitcoin_txid to the owner. GET /api/v1/verify?hash=<sha256> is public, needs no auth, and is rate limited to 120 requests per hour per IP so a third party can use it directly. Docs are at proofledger.io/api.html and the OpenAPI spec is at /openapi.json. Keys come from Account > API Keys. There is a GitHub Action for CI/CD, and the verify-proof package's create command and submit_proof call hit the same POST endpoint. Plans and what each includes are on the pricing page.
Verifying a proof yourself
Hash the file with whatever your operating system ships:
sha256sum contract.pdfCheck that hash against the public endpoint, with no key and no account:
curl "https://proofledger.io/api/v1/verify?hash=3b2f1a...64hex"Or do it without any network call at all:
pip install verify-proofThe package runs the check offline and locally. For a recipient, that matters more than it sounds. A timestamp is only worth something if the person relying on it can confirm it without asking the issuer for help, which means the issuer cannot quietly become a dependency of your evidence.
Which fits your situation
Each model asks you to accept a different thing.
A self-operated protocol asks you to keep and manage the proof artifact yourself, and to be the one who explains it when a recipient asks how to check it. There is no hosted certificate page to send and no API to call.
An RFC 3161 authority asks you to put the weight of the timestamp on one organization's private key and the certificate chain above it, and asks your recipient to validate that chain.
A hosted anchoring service asks you to accept whatever verification path that vendor's architecture produces, including what happens to it when the vendor is not reachable.
A transparency log asks you to trust an operated log plus an identity provider, through tooling shaped for software releases.
ProofLedger is built for the case where the check matters as much as the anchor. Two chains carry the same hash. The file stays with you. Any recipient can verify from a browser, from a terminal with no network, or straight against the public endpoint. Start at proofledger.io.