Blockchain timestamping records a fingerprint of a file, its SHA-256 hash, on a public ledger. Later, anyone with the file can recompute the fingerprint and find it on chain. That shows the file existed in that exact form no later than the moment it was recorded. For a business record, the real test comes later, when someone questions the record. The other side, or an auditor, asks how they're supposed to check it, and the answer depends on which option you used. This page starts from that question and works backwards through the main approaches.

If you want a straight tour of the tools by mechanism, the earlier page Blockchain Timestamping Tools: How the Main Options Actually Work covers that ground. This one is about the folder you hand over when a record is challenged.

What a hash is, and why only the hash leaves your hands

SHA-256 turns any file into a value 256 bits long, written as 64 hexadecimal characters. Change one byte of the file and the value changes completely. You can't get the file back from the hash.

So every option below works the same way at the start. You hash the file on your own machine and send only the hash to whatever records the time. The contract, the spreadsheet or the photo stays where it is. Where the options differ is in who records the hash, what you get back, and what someone else has to trust when they check it.

One limit applies to all of them. A timestamp on a hash shows that this exact file existed no later than a given moment. It doesn't show who made the file, when a photo was taken, or that the contents are true. Those questions are answered with other evidence.

What each option is and how it works

RFC 3161 timestamping authorities

RFC 3161 is an IETF standard. Your client sends a TimeStampReq containing the hash to a Timestamping Authority, such as DigiCert, Sectigo or FreeTSA. The authority signs the hash and the time with its private key and sends back a TimeStampToken.

openssl ts -query -data record.pdf -sha256 -cert -out record.tsq
openssl ts -verify -data record.pdf -in record.tsr -CAfile tsa-chain.pem

What goes in your records: the token, plus the authority's certificate chain.

What the other side has to trust: the authority, its key and its certificate chain. The time is valid because the authority says so and its signature checks out. It isn't recorded on a public ledger.

Hosted blockchain anchoring services

A vendor runs an API. You send it a hash, and the vendor anchors it to a public chain for you. OriginStamp is one service built this way.

What goes in your records: whatever the service sends back. That might be a receipt, a link to a portal, or enough data to trace the hash to a transaction yourself.

What the other side has to trust: that depends on the service, so ask these questions architecturally. Which chains does it anchor to? Can someone confirm the record without going through the vendor? If the vendor is unavailable when the record is challenged, what do you still hold? If verification runs through the vendor's site, the vendor has to be around for the check to work.

Self-operated protocols: OpenTimestamps

OpenTimestamps is an open-source protocol for Bitcoin timestamping. Calendar servers collect submitted hashes and combine them with Merkle aggregation, a tree of hashes in which many hashes get rolled up into a single value that's then written to Bitcoin. You keep a proof file that traces your hash up to that value.

What goes in your records: the proof file.

What the other side has to trust: Bitcoin, and the arithmetic of the proof. The protocol and tools are yours to run. There's no hosted certificate page, no managed verification link for a third party who doesn't use the tools, and no vendor to call. Whoever checks the record has to run the tools or have someone run them.

Transparency logs: Sigstore and Rekor

Sigstore was built for software artifacts. Cosign signs an artifact using a short-lived certificate issued by Fulcio, tied to an identity provider. The signature is recorded in Rekor, a transparency log operated by the Sigstore project.

What goes in your records: the signature and the log entry.

What the other side has to trust: the log and its operator, plus the identity provider behind the certificate. To check an entry, they query the log.

What you may already have, and what it shows

Some business records already carry integrity controls. They answer different questions from a timestamp.

A checksum stored next to the file, in a release note or a storage bucket, shows that two copies match. It doesn't show when the checksum first existed, because whoever controls the storage controls that date. That's correct for what it's for, which is matching files.

S3 Object Lock and similar write-once controls stop deletion or overwriting for a retention period. The account owner sets them up. A third party is trusting that the owner configured them, and when.

Signed git commits and tags tie a commit to whoever holds the key. The commit date is metadata the committer sets and can rewrite. A signature shows who signed. It doesn't show when.

What ProofLedger does differently

ProofLedger runs one process for every file. It hashes the bytes with SHA-256, anchors the hash, and returns a proof. There's no separate handling for different file types. A PDF, a database export and a video all go through the same process, and none of them leave your machine. Only the hash goes on chain.

Two chains. The hash is anchored to Polygon as soon as it's submitted. Bitcoin anchoring is optional on each request and runs in a daily batch. When you request it, the same hash sits on both chains, and each can be checked on its own. ProofLedger's Bitcoin proof is no stronger cryptographically than any other Bitcoin timestamp. What ProofLedger adds is the platform around the proof.

A link anyone can open. Every proof has a public verify URL. Whoever is checking the record doesn't need an account, the tools or your help.

A public lookup by hash. The v1 REST API has three endpoints:

  • POST /api/v1/proof submits a hash and needs a Bearer sk_ key from Account > API Keys. The body is {"sha256": "<64 hex chars>"}, with an optional filename label and an optional bitcoin_requested boolean. It returns 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. Only the owner can call it.
  • GET /api/v1/verify?hash=<sha256> is public and needs no auth. It's limited to 120 requests per hour per IP. Opposing counsel or an auditor can call it directly.

Full docs are at proofledger.io/api.html, and the OpenAPI spec is at /openapi.json.

Automation. There is a GitHub Action for CI/CD. The verify-proof package's create command, and its submit_proof call, anchor a hash through the same POST endpoint.

Verifying a proof yourself

Whoever checks the record doesn't need to take ProofLedger's word for anything. Here's how the check works.

1. Hash the file you were given.

sha256sum record.pdf # Linux
shasum -a 256 record.pdf # macOS

If this doesn't match the anchored hash exactly, it's a different file. That includes a re-saved, re-exported or compressed copy, even if it looks the same.

2. Look the hash up. Open the proof's public verify URL, or query the endpoint directly:

curl "https://proofledger.io/api/v1/verify?hash=<64-hex-digest>"

3. Check it offline. Install the verify-proof package from PyPI:

pip install verify-proof

It runs the same check on your own machine, without a network connection, so the result doesn't depend on ProofLedger's site being up.

4. Go to the chain. The proof's Polygon transaction and Bitcoin transaction ID can be looked up on public chain data. Neither chain has an operator whose word you're taking.

A timestamp is only worth something if the person relying on it can check it without asking whoever issued it. That's why the check is public, can run offline, and leads back to two public ledgers.

What a court still needs from you

A ledger record doesn't authenticate itself in court. FRE 901(b)(9) covers authenticating evidence of a process that produces an accurate result, and it needs a foundation showing how the process works. FRE 902(13) and 902(14) let machine-generated records and copies be self-authenticated when a qualified person certifies them. Whichever option you use, someone still explains the process. What a public anchor changes is that the other side can run the same check you did.

Which fits your situation

The choice is about what the person checking your record has to trust, and whether they can check it on their own.

With an RFC 3161 token, they're trusting the authority's key and certificate chain. With a hosted service, they're relying on whatever that vendor gave you, and possibly on the vendor still being there. With a self-operated protocol, the proof leads back to Bitcoin, but checking it means running the tools yourself, and there's no shareable page for someone who doesn't. With a transparency log, they're trusting the log's operator and an identity provider. Stored checksums, locked buckets and signed commits are controlled by whoever owns the storage or the key.

ProofLedger anchors the hash to public ledgers that nobody operates, gives each proof a link anyone can open, offers a public lookup by hash, and lets the check run offline with verify-proof. The file stays with you throughout. It works only from the moment of anchoring. Nothing can go back and record a date that was never recorded, so the hash has to go on chain before anyone questions the record.

Plans, limits and how Bitcoin anchors are billed are on the pricing page. ---