The Minion Network
IPFS pinning services are the persistence layer of the decentralized web. Without storage verification, they are also the trust layer. The Assurance Layer separates those two things.
IPFS solved content addressing, a way to verify that data you retrieve is authentic. The CID is a cryptographic commitment to the content itself. You cannot be served the wrong data.
What IPFS did not solve is whether data is being retained. There is no protocol-level mechanism to verify that a remote node holds your content without downloading all of it and recomputing the Merkle root. At terabyte scale that is operationally infeasible. At petabyte scale it is impossible. Storage verification does not exist at the IPFS protocol layer. That is the gap.
This is not a niche limitation. It is why organizations with serious data go to Amazon and Google rather than IPFS pinning services. A new provider asking for trust is not an improvement over an established one. It is the same dependency with less track record. Only a provider that can be verified mathematically is structurally different.
Storage proofs, specifically PDP and POR protocols from academic cryptography, have been the known answer to this problem for fifteen years. What was missing was an implementation for IPFS. We built it.
The Core Protocol
41 bytes in. Cryptographic proof of possession out.
This exchange, unchanged regardless of dataset size, is why the Assurance Layer replaces trust with verification.
- 1.Generate a random 41-byte seed. Send it to Pinion. You are not sending any data. Just a random number.
- 4.Receive the proof. Verify it locally in under a millisecond. No Pinion involvement required.
challenge (41 bytes)
proof (80–288 bytes)
- 2.Use the seed to sample the stored dataset uniformly. The seed determines which blocks are sampled. We cannot predict or precompute this.
- 3.Compute a cryptographic proof against the sampled blocks. Return it. This proof is only computable by someone holding the data.
Verification by download does not scale
At TB+ scale, confirming that your data is intact by re-downloading it is the same operation as restoring from backup. Without the Assurance Layer, you have no verification. That was the gap, and it blocked IPFS adoption for every workload where data integrity actually matters.
Distributed storage requires verifiable storage
Independence from centralized providers is only real if you can verify the alternative. A “decentralized” service that runs on trust is not decentralized. It is centralized under different management. The Assurance Layer is what makes the distinction meaningful.
Verification makes trustless operation possible
Without the Assurance Layer, a network can only accept operators it already trusts, which requires vetting, credentialing, and legal liability. With it, the protocol verifies instead. Anyone can operate a node without needing to be trusted first.
Research: Working Drafts
Protocol-Level Storage Verification
What the Assurance Layer looks like in practice: implemented and running.
Your data matters. You shouldn’t have to take our word for it.
Every IPFS pinning service asks you to trust them. We are a new provider. You have no reason to trust us yet. Instead of asking for trust, the Assurance Layer lets you demand proof. At any time, you can challenge us and verify mathematically that we hold your data. If we cannot prove it, we do not deserve your business.
PDP and POR protocols work by committing to a dataset at storage time through cryptographic tags. A verifier can then issue a compact challenge that samples the full dataset uniformly. The prover must respond with a proof that could only be generated by someone who holds the data. No download required.
Pinion implements five variants of these protocols against the IPFS Merkle DAG structure. The exchange is constant-size: a 41-byte challenge, an 80–288-byte proof, regardless of dataset size. A petabyte archive and a 1 GB file are audited by the same exchange.
The verification protocol
Why the Assurance Layer was necessary
IPFS CID verification tells you data is authentic after you download it. It cannot tell you data is being stored before you need it. These are different guarantees, and only one of them existed at the protocol level.
Re-downloading to verify is not a strategy at scale. At hundreds of terabytes it costs days of transfer time and thousands in egress fees, and it only reflects the state at the moment of download, not whether the data will be there tomorrow.
Without storage proofs, a provider can lose blocks silently, cache only frequently-requested content, or fetch data on demand when challenged. None of this is detectable by the client. The Assurance Layer closes that gap. The guarantee is mathematical, not contractual. Any authorized party can run the verification independently.
Ready to pin with proof?
Start using Pinion today. Challenge us whenever you want. The protocol does not require you to trust us first.
Talk to Us
Tell us what you’re building and what challenges you’re facing.
We’re talking to customers so we can build the right set of features. Schedule a call with an engineer who can actually implement your feedback.