Proof of priority (OpenTimestamps)

This page covers what a cryptographic timestamp is, why AI4Meta uses Bitcoin via OpenTimestamps, how to download a proof bundle, how to verify one yourself, and what to do if you believe your work was misappropriated.

What is a cryptographic timestamp?

A cryptographic timestamp is a small piece of data that proves a specific document existed in a specific form at a specific UTC time — without anyone having to be trusted to vouch for it.

The mechanism, in plain English: AI4Meta computes a fingerprint of your project (a SHA-256 hash). That fingerprint is bundled with thousands of other fingerprints into a Merkle tree, and the root of that tree is written into a Bitcoin transaction. Once that Bitcoin block is mined, the timestamp is permanent. To forge it, an attacker would have to rewrite Bitcoin's history, which is the practical definition of impossible at the dollar scale of Bitcoin's mining hashrate.

A reviewer holding only the proof bundle and your final project export can verify, on their own laptop, that your project existed in this exact form at this exact UTC time. They do not have to trust AI4Meta. They do not even have to trust Bitcoin's operators. The math is the proof.

Why Bitcoin?

We considered alternatives and chose Bitcoin specifically. The reasons:

• Free. Anchoring via OpenTimestamps' public calendar service is gratis. There is no per-stamp fee, no subscription. The OpenTimestamps consortium aggregates millions of stamps into a single Bitcoin transaction, so the per-stamp Bitcoin fee is sub-cent and is paid by the calendar operator.
• Durable. Bitcoin has been operating continuously since 2009. No competing chain has comparable longevity, and longevity is precisely what a priority proof needs — a proof from 2026 needs to verify in 2046.
• Publicly verifiable. Anyone can run a Bitcoin node and verify the chain independently. There is no vendor whose API you depend on.
• No vendor lock-in. OpenTimestamps is an open protocol (RFC-style spec), and the verification client is open source. If the OpenTimestamps consortium ever shut down, every existing proof would still verify against the Bitcoin chain — the calendar is only needed to create proofs, not to check them.

We considered RFC 3161 timestamping, but it requires trusting a Time Stamping Authority (TSA), and TSAs have a habit of being subpoenaed, going out of business, or changing root certificates. We considered Ethereum, but its longevity track record is shorter and its governance more politicized. We considered building our own anchoring chain — a non-starter; a single-vendor chain has no credibility as a third-party arbiter.

Lifecycle of a stamp

When AI4Meta stamps your project, four things happen, in this order:

1. Stamp submitted. AI4Meta computes the SHA-256 hash of the canonical project state and submits it to the OpenTimestamps calendar server. This happens within seconds of the lifecycle event (protocol lock, screening completion, extraction completion).
2. Calendar acknowledgement. The calendar server returns a "pending" proof acknowledgement. This already gives you a non-cryptographic timestamp from a known third party — useful, but not yet anchored. Status in the UI: Pending.
3. Bitcoin anchoring. Within roughly 24 hours (the calendar batches submissions into a single daily Bitcoin transaction), the hash is committed to a Bitcoin block. The proof is upgraded from "pending" to "complete". Status in the UI: Anchored.
4. Permanent. Once anchored, the proof is permanent. Bitcoin block reorganizations of more than a few blocks do not happen in practice; AI4Meta waits for six confirmations (~one hour after the anchor block) before marking the proof permanent.

You can use a Pending proof in a complaint, but a Anchored proof is dramatically more persuasive. If you have time, wait the 24 hours.

Where to find your proofs

In the workspace:

• Open Settings → Provenance.
• The page lists every stamp event with status (Pending / Anchored), the UTC timestamp, the SHA-256 of the canonical project state, and a Download proof bundle button.
• The proof bundle is a small ZIP (typically under 10 KB) containing the .ots proof file and a manifest of what was stamped.

For programmatic access: the same data is exposed at GET /api/v1/projects/:id/provenance. See the API documentation for details.

Verifying a proof manually

You do not need AI4Meta to verify a proof. Anyone on the planet can verify it on their own machine. This is the point of the design.

Install the OpenTimestamps client:

pip install opentimestamps-client

Then run:

ots verify project_state.json.ots -f project_state.json

The client will tell you, in plain text, whether the file matches the proof and at what UTC timestamp the proof was anchored to Bitcoin. Example successful output:

Got 1 attestation(s) from https://alice.btc.calendar.opentimestamps.org
Success! Bitcoin block 893421 attests data existed as of 2026-04-26 03:14:07 UTC

If the file has been modified at all — even a single byte — the verification fails. There is no way to "almost" pass the check.

For full documentation of the OpenTimestamps client, see the project on GitHub.

What to do if you suspect priority theft

If you believe a published article or preprint has copied protected aspects of your project (codebook, search strategy, full extracted dataset, or unique methodology innovations), here is the recommended sequence:

1. Gather your proof bundle. From Settings → Provenance, download the bundle for the lifecycle event that contains the misappropriated material. (Codebook lift → protocol lock bundle. Specific data extractions → extraction completion bundle.)
2. Identify the contested publication. Note the journal, DOI, posted date, and authors. Save a PDF of the contested article to your local machine in case it changes.
3. Verify your bundle yourself. Run ots verify against your project export so you have a fresh confirmation that the proof is intact. Save the verifier's output.
4. File a COPE complaint with the journal of the contested publication. Most major journals follow COPE's guidelines for handling misconduct allegations. The complaint should include:
   • Your verified proof bundle and the verifier's output.
   • Your AI4Meta project export (the canonical project state file).
   • The contested publication PDF and the specific passages or figures you allege were copied.
   • A clear timeline showing your stamp predates the contested publication.
5. Optionally, consult your institution's research integrity office. They handle the institutional side: contacting the contested authors' institution, filing under research-misconduct policy, supporting any subsequent investigation.
6. Consider posting a short technical note describing the misappropriation, with the verified proof attached. This is not always advisable (it can be read as combative before the journal investigation completes), but in some fields it is the norm.

The proof bundle is the load-bearing exhibit in steps 4-6. Without it, you have your word against theirs; with it, you have a third-party-verifiable timeline that the contested authors cannot dispute on cryptographic grounds.

FAQ

Does anchoring fail sometimes?

The OpenTimestamps calendar can have brief outages. AI4Meta retries automatically; if a calendar is down for an extended period, we fall back to a secondary calendar. Stamping is best-effort and queued; you will see a Pending status until anchoring succeeds. If you have a stamp stuck in Pending for more than 72 hours, contact support.

What if OpenTimestamps shuts down?

Existing proofs continue to verify against the Bitcoin blockchain forever; the calendar is only needed to create new proofs. Even in the worst case (the entire OpenTimestamps consortium disappears), you can still use any existing AI4Meta proof bundle in a priority dispute.

Can I stamp my project on demand, outside the three automatic events?

Yes. Settings → Provenance → Stamp now triggers an additional stamp at the current project state. Useful before submitting a manuscript or sending a sensitive share link.