← Blog

Is OpenTimestamps enough, or do I need a registry?

2026-10-22 · OpenStela

Often, yes. If what you need is a dated, checkable record that a file existed, and you're the one who will present that evidence later, OpenTimestamps does the job for free. It needs no account, your file never leaves your computer, and it works on any file type. A registry like OpenStela earns its place in a narrower set of cases: when someone else has to check the record without you sending them files, when you want your name and your account of how you made the work frozen alongside the date, or when the work is going to be bound to a character or sold.

Both approaches answer the same question: did this exact file exist by this date? Neither one decides who made it or who owns it. This post walks through the do-it-yourself steps first, because if they cover you, you can stop there. Then it sets out where the two differ, with the limits of each. For the wider field (notaries, government registration, emailing yourself), see Five ways to prove a file existed on a date.

What OpenTimestamps actually does

OpenTimestamps is an open standard for timestamping on the Bitcoin blockchain. Your file is reduced to a hash, a fixed-length fingerprint. Public calendar servers collect many hashes, combine them, and write the result into Bitcoin. You get back a small .ots proof file that links your file's hash to a Bitcoin block.

A few facts from the project's own pages, checked on 2026-10-22:

• The calendar servers "are free to use and they don't require any registration or api key." They run on donations.
• On the website, "the hash is calculated on your browser preserving your privacy." The file itself isn't sent anywhere. Only the digest is.
• The client README says it "takes a few hours for the timestamp to get confirmed by the Bitcoin blockchain," because the servers don't write one transaction per timestamp.
• The project states its scope plainly: "A timestamp proves that some data existed prior to some point in time."

That last line is the whole promise, and it's exactly what a timestamp should claim.

Doing it yourself, step by step

About ten minutes of work, plus a few hours' wait you don't have to watch.

1. Freeze the file first. Export the final version you want to date. Don't open and re-save it afterward. One changed byte gives a different hash.
2. Stamp it in the browser. Go to opentimestamps.org and drop the file on the stamp area. The proof file downloads automatically, named after your file with .ots on the end.
3. Or stamp it from the command line. If you have Python 3, run pip3 install opentimestamps-client, then ots stamp yourfile.wav. This creates yourfile.wav.ots next to the original. It can stamp many files in one command. One caution, from the README's privacy section: files stamped together share most of their proof, which is strong evidence that the same person stamped them. Stamp separately if you don't want two projects linked.
4. Come back after a few hours and upgrade the proof. A fresh .ots file is incomplete. It still relies on a calendar server to supply the path to the Bitcoin block. Run ots upgrade yourfile.wav.ots once the timestamp is confirmed. That writes the path into the proof itself, so verifying no longer depends on that calendar staying online. The README is direct about this dependency: old timestamps stay verifiable "provided that the relevant calendar data is available." Upgrading is how you stop depending on that.
5. Write a short note and stamp that too. The .ots file records nothing about what the file is. So write a plain text file: the title, the date you made it, the tools you used, and what you did yourself (the lyrics, the edit, the selection from 200 generations). Stamp the note the same way. Now the context has a date as well.
6. Store the pair in two places. Keep the original file and its .ots side by side, in your working folder and in a backup. Lose either one and there is nothing to verify.
7. Verify when you need to. ots verify yourfile.wav.ots checks the proof against Bitcoin. Per the README, verifying from the command line needs a local Bitcoin Core node, though a pruned node is fine. If you don't run a node, the OpenTimestamps website accepts an .ots file for verification in the browser.

You now have a date anyone can check with free, open tools, without trusting you or any company.

When the free tool is enough

OpenTimestamps is the better fit, not just the cheaper one, in these situations:

• You'll present the evidence yourself. If a dispute comes up, you'll be the one handing over the file, the proof and your notes. Nobody needs to look you up beforehand.
• The file isn't a song, image or video. A LoRA's .safetensors file, a project file, a layered PSD, a prompt log or a script can all be stamped. OpenStela's upload registration takes audio (mp3, m4a, wav), images (jpg, png, webp) and video (mp4, webm), with size limits per type.
• The work is unreleased and should stay private. OpenTimestamps never sees the file. On OpenStela, a work you upload is stored on our server, even if you keep its page private.
• You have a lot of files. Stamping is scriptable and has no daily cap. A registry has limits. OpenStela caps how many works one account can register per day, and uploaded files count against 300 MB of storage.
• You don't want to depend on any company. OpenTimestamps is a protocol, not a service you sign up for. Once a proof is upgraded, it needs only the file and Bitcoin.

What a registry adds, and what it costs you

What OpenStela adds over a bare timestamp, and the trade-offs.

Other people can check without you. When you register a work, it gets a public page if you choose, and its SHA-256 fingerprint can be pasted into the verify page by anyone. A buyer or a festival can look it up without an .ots file or a Bitcoin node. With OpenTimestamps, the checker needs the original file from you.

The context is part of the record, not a side file. OpenStela builds an authorship record: the file's fingerprint, the name you publish under, the creation date you state, the tools you used, a rights declaration and, if AI was involved, your own description of what you contributed (that field is required for AI works). The record's hash is what goes on chain, so the claims and the file are dated together. Once written, the record is frozen. You can change only the title, a note and whether it's public. The note from step 5 does something similar, but only if you remember to write and keep it.

Works can belong to a character, and move with it. A work can be bound to a registered character. The binding is a second record with its own date. If the character is sold through the platform's deal room, the works bound only to it move to the buyer with their records. A timestamp has no idea what a character is. Where can you sell an AI character? covers that side.

Someone else keeps the batches. Records are batched each night into a Merkle tree, and the 32-byte root is written to Arbitrum One. You don't run an upgrade step or keep track of .ots files.

The costs, stated plainly:

• You need an account, and for uploaded works, we hold a copy of the file. Links to already-published work (for example a Suno or YouTube page) take almost no storage, but then you're registering a public link, not a private file.
• You're trusting a company for the convenient layers. The public page and the lookup exist only while OpenStela runs. The protection against that is the Proof Pack. Download it and you hold the record, its Merkle proof and the chain transaction, which is enough to recompute everything offline. Once a song is registered, how do you prove it existed that day? shows the recomputation, and the continuity page states what we commit to if the service ends.
• The contribution text is your own statement. We don't check whether it's true, and we don't judge the work's content.
• Limits apply. Registering works is free within the storage and daily limits above. Characters are free up to 50 per account. The only fee is on sales: 5% (minimum $15) to the seller when a deal reaches the transfer step. See pricing.

Side by side

Checked 2026-10-22 against opentimestamps.org, the client README and OpenStela's own code and pricing.

Using both

They don't compete. Both use SHA-256 of the file, so the same file has the same fingerprint in each. (Run ots info on a proof and the first line shows the file's SHA-256.) A sensible split:

1. Stamp every draft and working file with OpenTimestamps as you go. It's free and private, and it builds a dated trail of how the work developed.
2. When you release a work, register the final file on OpenStela, with your contribution written into the record and a page you can link.
3. Keep the .ots proofs anyway. If the earliest draft carries an earlier date than the registry record, that sequence is itself evidence. The background is in How do I prove a file existed on a certain date?.

Why does any of this matter? In Taiwan, copyright exists from the moment a work is finished, with no registration. The Intellectual Property Office's copyright Q&A (October 2021) adds that you carry the burden of proving your rights, and recommends keeping drafts, backups, edit histories and discussions. In the US, the Copyright Office's general FAQ says copyright exists from creation, but you'll have to register before suing over a US work. No timestamp, free or not, does that for you. For what a record can and can't show, read What a character ID proves, and what it doesn't.

This is general information, not legal advice.