Every serious question about timestamping eventually arrives at the same place: is this actually going to hold up? You are being asked to trust that a string of hexadecimal characters, recorded somewhere you cannot see, will one day persuade someone that you wrote something first.
It is a fair question, and it deserves a straight answer rather than a brochure.
What a Bitcoin timestamp actually proves
Precisely one thing: that a specific file existed, in exactly its current form, no later than a specific moment.
That is narrower than most people assume, and it is worth being clear about. It does not prove you are the author. It does not prove nobody else had the same idea. It does not register a copyright — copyright already exists automatically the moment you fix a work in tangible form under Section 13 of the Copyright Act, 1957.
What it proves is the thing disputes actually turn on. When two people claim the same work, the argument is almost never about who could have written it. It is about who had it first, and who can show it.
How it works, without the marketing
Your file never moves. Your device computes a SHA-256 hash — a 64-character fingerprint. Change a single comma and the fingerprint changes completely. Reverse it back into the original file and you cannot; that is what makes it safe to publish.
The hash is committed to Bitcoin. Not in its own transaction — that would be slow and expensive. OpenTimestamps aggregates many hashes into a Merkle tree and commits the single root to the Bitcoin blockchain. You receive a proof file, a .ots, containing the path from your hash to that root and the block that carries it.
Anyone can check it. Given your original file and the .ots, anyone can recompute the hash, walk the Merkle path, and confirm the block. Open-source tooling, no account, no permission, nothing from us.
That last property is the whole point, and it is worth sitting with: the proof does not require ProofChain to exist. If we vanished tomorrow, your file and your proof file would still verify, because Bitcoin is not ours.
The objection: "you do not use a certified timestamp authority"
This is the sharpest version of the question, and it is usually raised by someone who knows what they are talking about.
RFC 3161 defines a Time Stamping Authority — an independent company that signs a hash with the current time and hands back a token. Those tokens are familiar in regulated industries, and a lawyer who has seen one before will reasonably ask why you do not have one.
ProofChain issued them until September 2026. We stopped, deliberately.
Because in India, a foreign TSA buys you no statutory advantage. Under Section 85B of the Evidence Act — carried into the Bharatiya Sakshya Adhiniyam, 2023 — a court shall presume a secure electronic record has not been altered when the timestamp comes from a CCA-licensed Certifying Authority. That presumption is genuinely valuable; it shifts the burden onto the other side.
But it attaches to CCA licensing, not to the RFC 3161 protocol. A timestamp from an American or European authority, however reputable, does not get it. It is ordinary electronic evidence — exactly what the Bitcoin record already is, without a second bill and a second dependency.
So the choice was never "one layer or two." It was between one anchor that nobody controls, and that same anchor plus a certificate that looked more official than it legally was. We would rather tell you what you actually have.
What a certificate authority cannot do, and Bitcoin can
It cannot outlive its own signing key. A TSA token is only as verifiable as the certificate chain behind it. Chains expire. Authorities are acquired, restructured, and wound up. A Bitcoin block from 2026 will be as checkable in 2050 as it is today, by anyone, because verifying it requires no cooperation from anybody.
It cannot be independent of the party issuing it. A TSA is a company with a private key. It is a very well-run single point of failure, but it is one. Bitcoin has no key to compromise and no office to subpoena.
It cannot be checked without trusting somebody. Validating a TSA token means trusting that authority's chain. Validating a Bitcoin anchor means checking a public ledger.
The honest limitation
Here is the part most services leave out.
A Bitcoin timestamp is technically stronger and legally newer. A judge who has seen a signed certificate before will recognise one instantly. A Merkle path to a block header may need explaining, and that explanation may need someone qualified to give it.
That is a real cost, and you should plan for it rather than be surprised by it:
Keep the original file. Without it there is nothing to hash, and the certificate alone proves nothing. This is the single most common way people lose an otherwise perfect proof.
Keep the .ots proof file. It is what lets the other side verify the anchor without going through you — which is precisely what makes it persuasive.
Lead with the certificate, not the blockchain. Your ProofChain certificate is written to satisfy Section 63 of the BSA 2023: it carries the SHA-256 hash, the algorithm, the time, and the Section 63(4) certificate the statute requires. That is the document you produce. The blockchain anchor is the thing that makes it impossible to fake, and it is there when someone wants to test it.
What Section 63 actually asks for
The BSA 2023 modernised how electronic records enter evidence. Section 63 requires that an electronic record be produced with a certificate identifying the record, describing how it was produced, and — new, and significant — stating its hash value.
Read that again, because it matters: the statute asks for a hash. It does not ask for a timestamp authority. A SHA-256 hash, a certificate describing its production, and an independently verifiable record of when it existed is not a workaround for what the law wants. It is the shape of it.
In practice
A screenwriter registers a draft on 15 January. In August, a production company releases something with the same structure and two of the same set pieces. They say independent creation.
What the writer produces: the original file; a certificate naming its SHA-256 hash and the date; a .ots proof tying that hash to a specific Bitcoin block; and an invitation for the other side to verify all of it themselves.
For that to be fabricated, someone would need to have rewritten a Bitcoin block from January — which would mean redoing every block since, against the whole network. It is not a thing that can be argued about; it is a thing that can be checked.
The bottom line
One anchor that nobody owns beats two anchors where the second one is a company. We removed a layer that looked reassuring and bought nothing the first one did not already provide, and we would rather be straightforward about what you are getting: a hash you can recompute, a block anyone can look up, and a certificate written to the section of the law that actually governs this.
Registrations made before September 2026 also carry an RFC 3161 token. Those remain valid, downloadable and verifiable — nothing has been taken away from anyone who has one.