How do I timestamp a document to prove it existed on a date?

What a cryptographic hash is

A cryptographic hash is a fixed-length fingerprint computed from a file: the same input always produces the same output, and changing a single character produces a completely different fingerprint. It is one-way, so the original text cannot be recovered from the hash, and finding two different files that share a hash is not feasible with today's computers.

SHA-256 and Keccak-256 are the two you will meet most often. SHA-256 is the everyday standard used by Bitcoin and most timestamping authorities. Keccak-256 is the hash used throughout Ethereum and Ethereum-compatible chains such as Polygon, and it is the one TrustChain uses when it anchors a signed agreement. Both produce a 64-character hexadecimal string, both are fine for timestamping, and the only requirement is to record which one you used.

1. Same file in, same fingerprint out, every time
2. Change one character and the whole fingerprint changes
3. The fingerprint cannot be reversed to reveal the text
4. The fingerprint is the same length whether the file is one line or one gigabyte

Why publishing a hash proves existence at a date

Publishing the hash instead of the document is the whole trick. The hash reveals nothing about the content, so it can sit in public, and because nobody can feasibly construct a document to match a chosen hash after the fact, a dated public record of the hash shows that exactly that content existed by that date.

The strength of the proof comes from the record, not the hash. A hash written in your own notebook proves nothing, because you control the notebook and its dates. A hash in a Bitcoin or Polygon block, or inside a timestamping authority's signed token, is dated by a system you do not control and that many other people watch.

Keep the original file, byte for byte. The proof only works if you can later produce a file that hashes to the published value, and a re-saved PDF, a re-typed text or a document with tracked changes will hash differently. Store the exact file in more than one place, with a note of which hash function you used and where the hash was published.

What a timestamp does not prove

A timestamp proves that specific bytes existed at or before a date. It proves nothing else, and it does not even prove the document was written on that date: a text written in January and anchored in March carries a March timestamp. Three further things are often read into a timestamp that it cannot carry, and this is true of every method in this guide, including a Polygon anchor or a signed authority token.

1. Who wrote it. Anyone can hash any file, including one copied from someone else. A hash in a block or a token identifies neither the author nor the person who published it, unless a separate identity step ties a person to the act.
2. That it was agreed. A timestamped contract draft shows the draft existed, not that the other party saw it, accepted it or signed it. Agreement needs a record of each party assenting to the same text.
3. That it is true. A hash of an invoice, a statement or a claim says nothing about whether the contents are accurate. It is a fingerprint of the bytes, not a check on the facts.

Public blockchain anchors: Polygon and Bitcoin

A blockchain anchor puts the hash into a transaction on a public chain, and the block that includes it carries the date. On Polygon or Ethereum the hash goes into the transaction data or a contract event. On Bitcoin the usual route is OpenTimestamps, a free open protocol that gathers many hashes into one Merkle tree, commits the root in a single Bitcoin transaction, and hands you a small proof file to keep.

The strengths are independence and longevity. No company needs to stay in business for the proof to keep working, anyone can look up the transaction on a public block explorer, and once the block is confirmed and buried under later blocks the record is tamper-evident: it cannot be altered without the change being visible to everyone running the network.

The weaknesses are precision and identity. A block timestamp is set by the network and is approximate rather than exact: on Bitcoin it can be off by an hour or more, so treat it as proof of the day rather than the minute. An OpenTimestamps proof can take hours to be fully confirmed, and you must keep the transaction id or proof file yourself. Above all, a transaction identifies no one: it shows that some wallet published this hash at this time, and nothing about who wrote or agreed to the document.

Timestamping authorities and notaries

A timestamping authority is a server that signs your hash together with the current time and returns a token. The common standard is RFC 3161, and the European eIDAS framework defines a qualified version with supervised providers. You submit the hash, not the document, so the authority learns nothing about the content.

Strengths: precise time, a widely recognised format, and support built into many document and code-signing tools. Weaknesses: you are trusting the authority's clock, its key handling and its continued existence, and checking a token later requires software that understands the format. If the authority's signing key is ever compromised, every token it issued becomes questionable.

A notary is the human alternative. A notary checks identity, witnesses a signature and records the date in a register. That is a different kind of evidence from a hash, and it is the only method on this list that speaks to who was in the room. The limits are cost, scheduling, and the fact that the notary usually attests to a signing on paper, not to the bytes of a digital file: a notarised paper copy and an edited digital copy can drift apart unless you hash the file as well.

Why emailing it to yourself is weak

Emailing a document to yourself is the folk method, and it is weak for three reasons. You control the mailbox, so a message can be deleted and re-created with an altered attachment. Header dates are plain text and can be edited on the way in or in an exported file. And the content sits in the mailbox in full, so it is neither private nor compact.

The one thing it has going for it is the receiving timestamp on the mail provider's server, which you do not control. That is slightly better than nothing, but the provider is not attesting to anything, its logs are not designed as evidence, and it will not help you retrieve a server-side record years later. If you want something as easy that actually proves the date, hash the file and stamp the hash with OpenTimestamps: it is one command and the public calendars are free.

Where TrustChain fits

A bare timestamp answers one question: did these bytes exist by this date. TrustChain is built for a different one: did both verified parties agree to this exact text, and when. Both parties verify identity once with a photo ID and a selfie through Sumsub and sign the same final text; once both have accounts they can also talk in an end-to-end encrypted chat. An unverified account can't sign.

At signing, TrustChain writes a timestamped audit entry for each signature from an identity-verified account. Browsers and apps can't edit it, and it is the part a hash alone can't supply. Anchoring is optional: it computes a Keccak-256 fingerprint of the signed record and writes it in a Polygon mainnet transaction, which dates it publicly. On the Free plan ($0, no card: 1 agreement and 3 AI Advisor requests a month), an extra agreement or an extra Polygon anchor costs $1 each, one-off, and anchors require a verified identity. Pro at $19 a month includes 20 agreements and 20 anchors; Elite at $49 includes 100 of each. Plans are monthly and cancel any time.

If you anchor, the fingerprint and an internal record ID go on-chain, with two empty wallet slots, never the text, names or emails. The agreement text is stored on TrustChain's servers so it can compute the fingerprint and serve the record, certificate and PDF, which are free on every plan. The chat is end-to-end encrypted and TrustChain can't read the messages. The public link opens without an account and shows the record's status and, if it was anchored, its fingerprint, never the parties' identities; the title appears only on agreements created on the Elite plan. If the record is anchored, the Polygon transaction can be checked on any block explorer independently of TrustChain. TrustChain's smart contract on Polygon mainnet is 0x649Bc303d15E173D95B4d379e163868b03cf5Fec.

None of this changes what a timestamp is. An anchored fingerprint and its date can be checked anywhere; whether an agreement is enforceable depends on where the parties are and what they agreed, and TrustChain makes no claim about that.

• trustchain-verify on GitHub: an open, read-only checker that compares a public record with its Polygon transaction, with no account or keys
• How TrustChain records a signature: what each audit entry records, and who can and can't change it

Do it by hand

Pick one hash function and write down which one. These steps are for a file you hash yourself: a TrustChain fingerprint also covers internal record and account IDs, so it will not match a hash of the agreement text. For SHA-256, every mainstream operating system ships a tool. For Keccak-256, the function TrustChain uses and the one used across Ethereum-compatible chains, you need a short script, because the sha3-256 option in OpenSSL and similar command-line tools is NIST SHA-3, which uses different padding and gives a different result from Keccak-256.

Online hash calculators are convenient but come with two caveats. Anything you paste or upload leaves your machine, so never use one for a document you would not publish; a tool that runs entirely in your browser is better, and one rough check is to disconnect from the network before hashing and see whether it still works. And an unfamiliar site can mislabel its algorithm, so cross-check at least one result against a local command before you rely on it.

Once you have the hash, publish it somewhere dated that you do not control: an OpenTimestamps proof, a timestamping authority token, or a transaction on a public chain. Then store the exact original file with a note of the algorithm, the hash and where it was published.

To check later, run the same command on the same file and compare the two 64-character strings; the 0x prefix and letter case do not matter, but every other character must match. If they differ, the file has changed or you used a different algorithm or encoding, and the usual culprits are a re-saved PDF, converted line endings or a trailing newline. If the hash was anchored on-chain, open the transaction on a block explorer, find the hash in its data, and compare it the same way.

1. SHA-256 on macOS: shasum -a 256 agreement.pdf
2. SHA-256 on Linux: sha256sum agreement.pdf
3. SHA-256 on Windows (PowerShell): Get-FileHash agreement.pdf -Algorithm SHA256
4. Keccak-256 with Python (pip install pycryptodome first): python3 -c "from Crypto.Hash import keccak; print(keccak.new(digest_bits=256, data=open('agreement.txt','rb').read()).hexdigest())"
5. Keccak-256 with Node.js (npm install ethers first): node -e "const {ethers}=require('ethers'); console.log(ethers.keccak256(require('fs').readFileSync('agreement.txt')))"