Researchers Document Draft Papers With a Verifiable Timestamp

How Researchers Can Document Draft Papers With a Verifiable Timestamp

A verifiable timestamp lets you show that a specific version of your manuscript existed at or before a given moment, without publishing it. You compute a cryptographic hash (a fingerprint) of the file, record that fingerprint somewhere that can't be quietly edited later, and keep the original file safe. Anyone can then re-hash your file and check that it matches the record.

What it gives you is evidence of existence. It does not prove you wrote the paper, and it doesn't replace publishing a preprint. Used at the right moments, though, it's a cheap, private way to build a trail of how a piece of work developed.

Why researchers bother documenting drafts?

Most of the time nobody asks. Then, occasionally, somebody does.

A reviewer's later paper looks suspiciously close to the manuscript you submitted. A collaborator leaves and disputes who contributed what. A funder or integrity office asks when a particular analysis was first written up. A supervisor wants to know whether the thesis chapter predates the conference paper. In each case the question is the same: what existed, and when?

The usual answers are weaker than people assume. Email to yourself can be reconstructed. File "date modified" fields are edited by any copy operation or by anyone with a text editor. Cloud storage version history sits inside a platform you don't control, and it can disappear when an account closes or an institution changes provider.

How timestamping a draft works?

The process has three parts.

First, the file is run through a hash function. SHA-256, specified in NIST's Secure Hash Standard (FIPS 180-4), turns any file into a fixed 64-character string. Change a single comma in the manuscript and the string changes completely. Nobody can work backwards from the string to the paper.

Second, that string is recorded with a time in a system built to resist later alteration. That could be a trusted timestamp authority following RFC 3161, or a public blockchain.

Third, to verify later, you take the exact same file, hash it again, and compare the result to the record. If they match, that file existed no later than the recorded time.

The phrase "exact same file" is where researchers get caught, so it deserves its own section.

What exactly should you hash?

A hash applies to bytes, not to "the paper" as an idea. Open a Word document and save it again without changing a word, and the bytes may change. Export a PDF twice and you can get two different files. So the habit that matters is simple: freeze a version, then hash that frozen file.

For a typical manuscript, a workable pattern looks like this:

Export the draft to PDF and treat that file as the snapshot. Also keep the editable source (the .docx or the LaTeX folder) alongside it.

If the paper depends on data, figures, and analysis code, put the whole bundle in a single archive and hash the archive. Then never rebuild that archive. Re-zipping the same files can produce a different hash because of embedded metadata, so the archive you stamped must be the archive you store.

Give the file a name that carries the version, such as smith-lab_gene-regulation-draft_v3_2026-10-05.pdf, and keep a short plain-text log of which file corresponds to which milestone.

If you lose the original, the timestamp is nearly useless, because there's nothing to re-hash. Store the stamped file somewhere durable, preferably in two places.

When to timestamp?

You don't need to stamp every keystroke. The moments that tend to matter are the ones where a draft changes hands or status:

1-The first complete draft, when the central claim is on paper.

2-Before sending it to a collaborator, supervisor, or anyone outside your group.

3-Immediately before journal submission.

4-After major revisions in response to review.

5-When a dataset or code release is finalized.

Think of it as a series of dated footprints rather than a single stamp. A sequence of hashes across months tells a more convincing story than one lone record.

How this compares with what researchers already use?

None of these options is wrong. They answer slightly different questions.

Preprint servers such as arXiv, OSF Preprints, SSRN, bioRxiv and medRxiv make your work public, give it a citable identity, and put a date on it that the research community recognizes. For establishing visible priority, that's hard to beat. The trade-offs are that the work becomes public, some servers moderate before posting, and not every field or journal workflow suits early posting. If you can post a preprint, that's often the right move. A private timestamp is for the stretch of time before you can or want to.

Git history is excellent for tracking change. But commit dates are self-reported and can be set to anything, and history can be rewritten before it's pushed. Git is a good working record and a weak independent time witness. Many people combine the two: they stamp a hash of a tagged release.

Electronic lab notebooks and institutional records are valuable, especially for wet-lab work, and they often carry institutional weight. They depend on the platform and the institution's retention rules, though, and they don't help much for a drafted manuscript that lives in your own folders.

Trusted timestamp authorities (RFC 3161) provide a signed time attestation from a third party. In the EU, the eIDAS Regulation (EU) No 910/2014 gives electronic time stamps a legal framework, with additional effects for qualified time stamps. They work well, though they involve trusting the authority and usually a paid account.

Blockchain anchoring records the hash on a public ledger, so verification doesn't depend on any one company staying in business. That is the approach Certelo uses.

How Certelo approaches it?

Certelo calculates the SHA-256 hash locally, on your own device. The manuscript itself isn't uploaded to create the proof. Only the hash is anchored to the Electra Protocol blockchain.

For researchers, that last point matters more than it first appears. Unpublished results are often under embargo, covered by a collaboration agreement, or simply not yours alone to share. Being able to build a dated record without sending the draft to a third party removes that concern from the decision.

One honest caveat about hashes in general: a hash of a long, unique file reveals nothing practical. But a hash of something very short and guessable, like a one-line hypothesis, could in theory be tested by someone guessing candidate texts. For a full manuscript or data bundle this isn't a realistic worry. For a tiny snippet, add some unpredictable material (a private note, a random string) to the file before hashing.

To check a record later, you supply the original file, its hash, or the certificate information, and compare it against what the blockchain shows. You can also run the hash yourself with standard tools, so the check doesn't rest on trusting Certelo's interface.

A hypothetical example

This is an illustration, not a real record.

A postdoc finishes a full draft in March, exports it to PDF, and stamps it. In May she shares it with a collaborator at another institution, stamping the revised version first. In September she submits to a journal, stamping the submitted PDF and the archive containing the analysis code. Months later, a dispute comes up about whether a particular analytical approach appeared in her work before a competing preprint. She can produce the March, May and September files, re-hash each one, and show the matches against records dated before the preprint appeared.

That doesn't settle who deserves credit. It does turn "I had this earlier" from an assertion into something others can test.

What a timestamp can't do?

This is where overclaiming does the most damage, so plainly:

* It doesn't prove you wrote the file. Anyone can stamp any file, including one that isn't theirs.

* It doesn't establish originality, novelty, or ownership of the ideas.

* It doesn't replace publication, which is how academic priority is normally recognized.

* It's not a substitute for authorship agreements with co-authors or for your institution's research data policies.

* Whether any particular court, journal, or integrity body will accept it, and how much weight they give it, depends on the jurisdiction and the circumstances. This article isn't legal advice.

What it can do is support an evidentiary record: this exact content existed no later than this time. Combined with drafts, emails, notebooks, and version history, that's a useful piece of a larger picture.

Frequently asked questions

Is a timestamp the same as posting a preprint?

No. A preprint is public and carries a recognized identity in the scholarly record. A timestamp is private and records only that a file existed. They complement each other.

Can I timestamp a manuscript without making it public?

Yes. With client-side hashing, only the fingerprint is recorded, and the manuscript stays with you.

Will this stop someone from scooping me?

No. It can't prevent anything. It can only help you demonstrate afterwards what you had and when.

Do I need to timestamp every version?

No. Stamp the milestones that matter: first full draft, before sharing, before submission, after major revision.

What happens if I edit the file after stamping it?

The new file has a different hash and won't match the old record. That's the point. Stamp the new version as a new record and keep both.

Can co-authors each stamp the same draft?

They can, and the earliest valid record for that exact file is the relevant one. It's worth agreeing in advance who keeps the originals.

Does a Git commit work instead?

Git is great for tracking changes, but commit dates are self-reported and editable, so it works best alongside an independent timestamp rather than in place of one.

Putting it into practice

Pick your next milestone, freeze the file, hash it, and store the original somewhere safe. The habit costs a few minutes and can matter a great deal if the question ever comes up. If you'd like to try it, you can create a record with Certelo, and verify any existing one using the original file.

EXTERNAL SOURCES

* NIST FIPS 180-4, Secure Hash Standard (SHA-256)

* IETF RFC 3161, Time-Stamp Protocol

* Regulation (EU) No 910/2014 (eIDAS), provisions on electronic time stamps (Articles 41–42), via EUR-Lex

* arXiv, OSF Preprints, SSRN, bioRxiv/medRxiv submission and moderation pages, for the preprint comparison

* Electra Protocol official documentation, for any statement about the chain