A project team sends a revised drawing to a contractor. Months later a dispute surfaces and someone needs to establish which version was in play before a change got made. They pull the file. The other side pulls a file. Both are named the same thing...and now everyone is arguing about which is the "real" one, with no way to settle it beyond "no, trust ME bro!".

That is not an exotic edge case. It is Tuesday in construction, insurance, legal, healthcare, and every other industry where documents carry real weight. The underlying question is the same every time: how do you prove a file existed before a certain moment, without asking anyone to take your word for it?

Almost every answer a company has today is somebody's word. A file-system timestamp is the word of whoever controls the server. A notarized PDF is the word of the notary, good only as long as the notary's firm is still around to pull the record, just as a screenshot is the word of the person holding it. For most of software history, "when did this exist" has been answered by trusting a database and the company running it. That trust never shows up as a line item until the first time a record gets disputed.

We see people building on IPFS every single day, and two open-source tools, used together, give builders a real answer to this problem. Before getting into how they work, it helps to name what they are actually solving.

Every claim about a document is really three separate claims. What identifies the exact content. When establishes its history. And Who Vouches determines whether anyone actually has to take your word for any of it. Businesses lose arguments because they collapse all three into one, then discover too late that none of them hold up.

There is a clean way to organize a product around those three questions. We call it the Proof Stack.

The first problem: nobody can agree on what the file is

Go back to that contractor dispute. The core issue is not that someone lied, it is that there is no way to tell whether the files are the same, different, or when either version appeared. A file name is a label just as a folder is a location and neither one alone proves anything about the bytes inside.

IPFS solves the What layer by addressing files by their content rather than their name or location. Every file on IPFS gets a CID, a content identifier derived from a cryptographic hash of the file's own bytes. Change anything at all and the CID changes. The address is the fingerprint.

A CID does not point to where a file sits on a server, it names exactly which bytes you mean, and a recipient can pull a copy from any provider and check it against that single reference. Nobody has to vouch for the file's identity, because the identity and the file are the same thing. An approval workflow could ask the approver to sign a record that includes the drawing's CID. A recipient then has an explicit, unforgeable reference against which to check the drawing they received.

NFTs reached for IPFS first for this reason, and as we see firsthand here at Pinata, the definition of what belongs there has kept expanding ever since. Transaction logs. Model inputs. Supply-chain records. Legal documents. Anything whose identity needs to outlive the company that made it. (IPFS FTW!)

That solves What, but here is the gap it leaves: a CID proves which bytes. It says nothing about the day those bytes first existed. For the contractor dispute, knowing the file is authentic does not settle who had it when.

The second problem: nobody can prove when the file existed

This is the harder problem, and the one most teams do not even try to solve. A file's creation date lives in metadata that any server administrator can change. A database timestamp is only as trustworthy as the database operator.

For a business that needs to establish a timeline in front of a third party, vague, low trust answers do not hold up. Enter: Bitcoin and OpenTimestamps.

Opentimestamps anchors a file to Bitcoin's blockchain. Before getting into how, it is worth pausing on why Bitcoin specifically.

If "digital gold" is all you have heard, meet the Bitcoin maximalist, those that who swear every other chain is a casino and Bitcoin is THE sound money and nothing else. There is real affection owed to that crowd. Under the memes is one of the most stubborn, principled developer communities in software, people who have spent over a decade maintaining the most tamper-resistant ledger humanity has built, largely because they believe in it. They are still shipping. And that same stubbornness produced something most people never think to use: the hardest ledger to rewrite is also the most reliable public clock ever made.

OpenTimestamps turns that clock into proof, and the usage is almost offensively simple. No account. No wallet. No API key.

bash

$ pip3 install opentimestamps-client$ ots stamp my-file        # hashes locally, submits a digest, writes my-file.ots# wait for the commitment to land in a Bitcoin block (a few hours)$ ots upgrade my-file.ots  # pulls in the completed Bitcoin proof$ ots verify my-file.ots   # re-checks the proof against Bitcoin

Under the hood, OpenTimestamps hashes your file locally, so your bytes never leave your machine during stamping: only a small digest travels. Free public calendar servers batch thousands of those digests into a single Bitcoin transaction, so one on-chain write timestamps an entire batch at once. The operators cover the anchoring cost, which is how a protocol riding the most expensive block space in crypto stays free to the person stamping a file.

Two things matter for builders shipping this in a real product.

First, that fresh .ots file is a pending receipt, not a finished proof. The commitment lands in a Bitcoin block after a few hours, and only then can you upgrade it into a proof a third party can verify standalone. Design for the wait: show the real state, retry the upgrade, and do not archive until upgrade and verify both come back clean. The completed file is the artifact that survives even if every calendar server goes dark, so that is the one you keep.

Second, be precise about what the proof actually claims. It proves the committed data existed before a specific block was mined. Bitcoin block timestamps are miner-selected and can be off by multiple hours, which is exactly why the client shows a date rather than a clock reading. If a business needs a tighter wall-clock time, or needs to prove the content is accurate rather than merely old, that evidence has to come from the application through signatures and capture procedure. A fabricated report can receive a perfectly valid timestamp. The timestamp answers When, not whether it is true.

That solves When. But a third gap remains: even with an authentic file and a Bitcoin-anchored date, someone still has to vouch that the file and the proof are connected, and that the people involved are who they say they are.

The third problem: someone is always vouching for something

Every chain of evidence eventually hits a point where a human or an institution is standing behind it. And every one of those relationships is a cost, a dependency, and a potential failure point. The smart money in every data-heavy business is quietly trying to get rid of as many of them as possible.

This is where IPFS and OpenTimestamps compound. Pin the file to IPFS with Pinata, and What is answered by a CID anyone can verify. Stamp and upgrade with OpenTimestamps, and When is answered by Bitcoin. Pin the completed .ots proof to IPFS right next to the file, and the evidence now travels with the asset, retrievable by its own CID, dependent on no server staying alive.

Run the Proof Stack this way and the custodian layer resolves to nobody. Not Pinata. Not OpenTimestamps. Not a single maintainer. If every calendar server went dark tomorrow, a completed proof still verifies against Bitcoin. If Pinata disappeared, the CIDs still describe the exact bytes and the content stays retrievable from any node that holds it. You have swapped a chain of custodians, each of whom had to be paid and trusted and kept alive, for two cryptographic facts that cost a fraction of a cent to produce. For a company generating verifiable records at scale, trust stops being a recurring expense and becomes a one-time computation. Your CFO will understand that sentence faster than your engineers do.

Two parts of Who Vouches stay on the builder's side of the line, and good products design for them on purpose. Attribution is one: proving who signed or approved something requires digital signatures plus a real link between the signing key and the person, and that link is the application's job to establish. Availability is the other: pinning protects content from garbage collection, but genuine independence from any single provider means retaining copies elsewhere with a backup process that actually runs. And if records are confidential, public IPFS is public. Encrypt before distributing, keep keys recoverable, or reach for private pinning. Pinata runs separate public and private services so builders can pick the model that fits the record.

Who is already building this

This is not a hypothetical use case and there are already whole industries circling the exact problem the Proof Stack solves, and most of them would never use those words.

Insurance. A carrier that stamps inspection photos, incident reports, and telematics logs through an authenticated capture flow answers When before a loss is ever contested, without asking a court to trust the carrier or the claimant. The capture quality and the link to the actual property still matter, which is the Who layer doing its job.

Real-world asset tokenization. Every tokenized asset drags paperwork behind it, appraisals and custody attestations and audit reports, and that off-chain evidence has always been the weak half of the trade. Pin it and stamp it, and the documents inherit the same verifiability as the token they back. The token proves ownership onchain. The Proof Stack gives the paperwork the same teeth. Rights in the underlying asset still live in the legal arrangement, a line the ERC-6065 real-estate token work draws explicitly, and that is a feature, not a gap.

Research teams can package a dataset, the analysis code, and a signed description of an experiment, then hand collaborators a stable, verifiable reference for the exact materials under discussion. Digital ownership follows the same logic, because a transfer you can date is a chain of custody you can defend.

The industries that have not realized it yet

The most interesting opportunities are in industries that have never once called themselves crypto and there is a lot of room to build for them.

In construction, a trillion dollars of annual work runs on fights over who approved which drawing and when, so imagine an app that stamps every change order the instant it is uploaded, pairs it with the signed approval, and turns the usual lawsuit over timelines into a thirty-second verification. In insurance, a claims pipeline where every photo carries its own tamper-proof date, so backdating collapses before it starts. In healthcare, consent forms and lab results that prove when they were signed and that nothing moved since. In supply chain, a certificate of origin any downstream buyer can verify without calling the exporter. Warranties. Legal discovery. Academic credentials. Each one is a product waiting to be built, and each one rests on the same two tools.

None of those buyers will wake up wanting a blockchain. They will wake up with problems to solve, like a desire to stop losing arguments with contractors about dates. The teams that solve them first will not be selling Bitcoin or IPFS by name. They will sell a product that proves itself, with the Proof Stack humming quietly underneath.