Let’s start with a demo

To help you develop an intuition for how proof of storage works, let’s start with a game.

Imagine yo’ve decided to store a collection of paint cans in a remote warehouse. You would like to verify that the warehouse still has your paint, but you would rather not ship the entire cans back and forth every time you check. In fact, let’s make it a goal that we should verify the stored paint with as small a sample as possible. How could we do it?

Before sending the paint away, you create a small small “tag” for each can by mixing it with a secret pigment known only to you. The tags are tiny compared to the paint cans.

When it’s time to verify your storage, you send the warehouse a challenge: a random challenge color and a recipe describing which cans to mix and in what proportions. The warehouse follows the recipe, and mixes and sends you back the result, a tiny drop containing a blend of the challenge and and the paint cans in their storage.

Using your secret pigment, and the tags you created earlier, you can verify that the proof the warehouse sent back must have been created from the cans you have stored. If any paint is missing, or has become corrupted, you’ll know.

An important thing to notice about this game is that the large and heavy paint cans never have to move. The tags are tiny, the challenge is tiny, and the proof is tiny. So tiny, in fact, that you you could run this game continuously and it not be a burden, so you can receive ongoing evidence that your paint is still there. Have a look at the “confidence” graph, which shows how likely it is that, if there was a problem, you would have caught it. Every time you check, the confidence goes up.

Why This Matters

Most storage is rarely accessed.

Compliance archives, machine learning datasets, personal backups, log files, often sit for months or years. You upload the data, pay the storage bill every month, and you trust that it’s stil there. If a storage provider loses a file six months after it was uploaded, and you won’t find out until you need it.

Proof-of-storage systems like ours solve this. By sending a small cryptographic challenge and verifying the response, you get evidence, not merely a promise, that the provider holds your exact data at this moment. No download required. The math guarantees that a provider who has deleted your data cannot construct a valid response.

Reputation vs Evidence

Large cloud providers like S3 have an answer to the question of trust: decades of operational history. They’ve earned a reputation through years of reliability, and for many users that reputation is sufficient. If you already trust the provider, additional cryptographic verification may not feel necessary.

But reputation has a problem: it isn’t transferable. Every new storage provider starts with zero. To compete with an established name, they have to ask potential customers to take them on faith — a high bar that incumbents cleared simply by being around long enough, or early enough to the market. New providers are immediately disadvantaged regardless of their quality of service.

Cryptographic proof of storage changes that calculus. A provider that gives you a verifiable proof doesn’t need to ask you to believe their uptime page. You can issue a challenge yourself, verify the response with mathematics, and arrive at your own conclusion — independent of how long that provider has been in business. Call it portable trust: the ability to earn confidence through evidence rather than history.

Our goal with this feature is to reduce the amount of trust required to use a storage service on the internet. A provider that gives you a cryptographic proof doesn’t need you to believe them. You can verify it yourself, every day, with a few bytes of network traffic. That changes the competitive landscape for everyone.

The Trust Layer

Content-addressed systems such as IPFS solve several critical problems on a decentralized internet: Finding content without a central index, and verifying the content retrieved from an untrusted source.

A CID lets you know that the content you have now is the content you asked for. If even a single byte changes, the CID changes. However, the CID does not tell you whhether anyone is still storing it. Pinning services like Pinion are the persistent storage layer for IPFS.

How do you know that the pinning service is actually storing your data? Traditionally, the answer has been reputation and trust for the company that runs the service. Our proof of storage system does something new. Our proof of storage system provides you with evidence that your storage provider is actually storing your data. You can verify the proof without trusting the provider at all.

How to Use Pinion Proof of Storage

Proof of storage is built into the Pinion dashboard. Once you’ve pinned content, enabling continuous storage proofs takes only a few clicks.

1. 1
   Pin your content

   Upload files or CAR archives to Pinion. Once pinned, you have a CID — the cryptographic identifier for your content.
2. 2
   Enable storage proofs

   From the dashboard, create a proof key for your pinned content. Pinion walks your DAG, computes tags for every block, and returns your client setup — a small blob you keep locally.
3. 3
   Issue challenges

   Use the Pinion dashboard to run challenges automatically on a schedule, or use the API to issue them yourself. Each challenge takes milliseconds and transfers only a few hundred bytes.
4. 4
   Verify responses

   Verification runs on your machine, against your locally-held client setup. No trust in Pinion required at the verification step — only the mathematics.