Proof of Existence vs OpenTimestamps: which timestamping fits your work?

If you only need a compact, portable timestamp that anyone can verify against a public blockchain, OpenTimestamps is an excellent, focused choice. If you need a richer on-chain proof record — one that can also carry signatures, sealed (encrypted) payloads, recipient delivery, content-addressed storage pointers, and Merkle batching — Label 309 is built for that. They overlap on the core claim ("these bytes existed by time T") and diverge on everything around it.

Both prove existence by time without asking you to trust a company's server. The difference is shape: OpenTimestamps produces a small external proof file; Label 309 publishes a structured record on Cardano. This post lays out where each one fits.

What is OpenTimestamps?

OpenTimestamps is a protocol and toolset for blockchain timestamping, most commonly anchored to Bitcoin. The idea is simple: you hash your data, build a timestamp proof, and the commitment eventually lands in a Bitcoin transaction. From then on, anyone can check that the data existed before that block's time.

To keep costs down, OpenTimestamps uses calendar servers that aggregate many users' hashes into a single Bitcoin transaction, so you do not need one transaction per file. The client produces a portable .ots proof file that travels next to your data.

Verification is where the trust model shows: you verify the .ots proof against the original file and a Bitcoin chain view, with no trusted server in the loop. The official client notes that local verification needs a Bitcoin Core node — a pruned node is enough.

It is an elegant, mature design for minimal, independently verifiable timestamps.

What is Label 309?

Label 309 is an open, vendor-neutral standard for Proof of Existence records on Cardano. The record lives inside a Cardano transaction's metadata under metadata label 309, and the block time of that transaction is the witness that the committed bytes existed no later than that moment. The standard is the durable artifact; CardanoWall's web app, command-line tool, and SDKs are reference implementations downstream of it.

The standard has been submitted to the Cardano CIP process and is under review by the CIP editors as a Metadata-category proposal (the open pull request currently appears under a tentative number). Note that the on-chain identifier — metadata label 309 — is separate from any CIP number it is eventually assigned.

To verify a Label 309 proof, anyone fetches the Cardano transaction from a public explorer, reassembles the canonical record, validates its structure, checks confirmation depth, verifies any signatures, and recomputes the committed content hashes or Merkle inclusion proofs. At the simplest level it answers the same question OpenTimestamps does. But it is not a single proof file — it is an on-chain record format designed to carry several proof layers at once. For a fuller walkthrough, see how Label 309 works and what actually goes on the blockchain.

What is the real difference between them?

OpenTimestamps is purpose-built for timestamping. Label 309 is built for a complete Proof of Existence record.

OpenTimestamps is the better fit when the question is:

Did this file exist before this Bitcoin-attested time?
Can I keep a small proof file and verify it later?
Can I timestamp without revealing the file's contents?
Can calendar servers batch many requests so I do not pay per file?

Label 309 is the better fit when the question is:

Did this file, manifest, or Merkle root exist by this Cardano block time?
Did a specific identity key sign the record?
Can the file itself be sealed (encrypted) and recovered later?
Can the record be encrypted for specific recipients?
Can one record commit to thousands or millions of leaves at once?
Can the public verify it with no CardanoWall account and no access to our servers?

Both are proof systems rooted in public consensus. Their shape — and therefore the workflows they unlock — is different.

What does OpenTimestamps do especially well?

OpenTimestamps is at its best for minimal, public timestamping built around an external proof object. You timestamp a file, keep the .ots proof next to it, and later upgrade the proof once the commitment is confirmed in Bitcoin. The calendar model lets many users share the cost of anchoring.

It also has a healthy narrowness. It does not try to be a confidential delivery system, a media-provenance standard, a software-signing ecosystem, or a legal notary. It timestamps, and it does that one job cleanly. For people who want Bitcoin-backed timestamps from a battle-tested tool, that focus is a feature.

What does Label 309 add on top of the timestamp?

Label 309 wraps structure around the timestamp claim. A single record can include:

one or more content hashes per item;
content-addressed storage pointers (ar:// for Arweave, ipfs:// for IPFS);
optional record-level signatures over the whole record;
an encryption envelope for a sealed item, with the ciphertext held off chain;
per-recipient key slots that wrap the content key to chosen recipients;
Merkle commitments that bind one on-chain root to an arbitrarily large off-chain leaf list;
a supersedence pointer to an earlier record (append-only — it never revokes the prior record);
namespaced extension keys reserved for future companion specifications.

This matters as soon as a workflow needs more than "I have a timestamp proof file." For example, a sender can seal a file, address it to a recipient, publish the encrypted ciphertext at a content-addressed URI, and still keep the public record independently verifiable — see hash, sign, seal, share. A high-volume AI service can publish one Merkle root that stands in for many generated outputs, and a CI/CD pipeline can sign a release-evidence record covering a whole manifest set — see one record for thousands of files. Those workflows need a richer record than a bare .ots proof carries.

Which one is more decentralized?

This is the wrong place for slogans, so be precise about what each model asks you to trust.

OpenTimestamps anchors to Bitcoin, whose proof-of-work history is a very strong basis for timestamping. The proof verifies independently once the data it needs is available — a complete .ots proof verifies fully against a local Bitcoin node, while an incomplete one still needs a calendar server to supply the path to the block header.

Label 309 anchors to Cardano. Its verification trusts the public Cardano chain, the record bytes, and the content hash — and nothing else. It does not require trust in CardanoWall or in any publisher-operated server for the core proof; a verifier needs only the transaction reference, optionally the content bytes, and a public explorer it chooses for itself.

Neither is "more decentralized" in the abstract. The practical question is which chain, tooling, proof shape, cost model, and ecosystem fit your workflow.

What about privacy — does either leak the file?

Both can timestamp without publishing the private file, and both have honest limits.

OpenTimestamps calendar servers receive commitments, not plaintext files. But the project is candid that timestamping leaks metadata: creating several timestamps in close succession lets an adversary link them, batching files in one command produces near-identical commitment operations that suggest a common author, and the calendar REST API does not currently attempt to provide privacy. Nonces keep the calendar from learning what was timestamped, but the surrounding metadata is not hidden.

Label 309 keeps plaintext off chain for hash-only proofs, and for sealed proofs it encrypts the plaintext and stores only ciphertext at a content-addressed URI. By design, the chain reveals no recipient public keys — a recipient recognizes a message only by successfully trial-decrypting a slot, so there is no addressee field to read. What it still cannot hide is timing, fee payment, gateway access, account behavior, and ordinary operational mistakes. A sealed record keeps plaintext readable only to key holders; it does not guarantee anonymity, and a recipient can always leak plaintext after decrypting it.

In both systems, privacy is a property of the whole workflow, not of the proof format alone.

Can you use both together?

Yes — and for high-stakes records it can be worth it. To get two independent public timing paths, anchor the same manifest with both:

Create your release, dataset, media, or evidence manifest.
Hash the manifest.
Create an OpenTimestamps proof for the hash or file.
Publish a Label 309 proof for the same manifest, or for a Merkle root that contains it.
Keep both proof references alongside the original evidence.

That gives you one Bitcoin-oriented path and one Cardano-native, Label 309-structured path. Use both when the extra redundancy is worth the operational overhead; for most work, one is plenty.

When should you choose OpenTimestamps?

Choose OpenTimestamps when the job is bare timestamping and a Bitcoin-anchored proof is exactly what you want. It fits well for:

simple file timestamps;
Git or PGP timestamping workflows;
teams that already run and trust Bitcoin verification;
workflows that prefer carrying an external .ots proof file;
minimal commitments that need no richer on-chain record.

It is intentionally focused, and that focus is the point.

When should you choose Label 309?

Choose Label 309 when the proof record itself needs more than a timestamp. It fits well for:

Cardano-native Proof of Existence;
signed records that bind authorship to the proof;
sealed (encrypted) files committed on chain;
confidential delivery to specific recipients;
Merkle batching for large or recurring sets;
content-addressed storage pointers;
CardanoWall's web, API, CLI, SDK, or self-hosted gateway paths;
application protocols that want a shared proof format under metadata label 309.

The whole thing is open source under github.com/cardanowall, so you are never locked into one vendor's tooling to read or write a record. See Label 309 is open source and how to verify a record yourself.

What does neither system prove?

Neither one proves truth, ownership, authorship, legality, or quality on its own. OpenTimestamps proves a timestamped commitment. Label 309 proves a timestamped commitment plus whatever optional layers a record carries. Either way, a proof shows that exact bytes existed by a public time — not who is right, who owns what, or whether the content is lawful. The surrounding claims still need signatures, identity context, process evidence, legal analysis, and human judgment. We unpack this in what a proof does not prove.

The short version

OpenTimestamps is a strong, focused, Bitcoin-anchored timestamping system. Label 309 is a Cardano-native Proof of Existence record format with room for signatures, sealed preservation, recipient delivery, content-addressed storage, Merkle batching, and future extensions. Pick the one whose proof shape matches the question you actually need to answer — or use both when redundancy is worth it.

If you want the broader comparison set, see Proof of Existence vs a Timestamp Authority and the foundational what is Proof of Existence.