Your browser is already at work.
Using the Prove Dashboard
A walkthrough of every section of the Storage Verification page and how to get the most evidence out of it.
The four roles
Many proof-of-storage systems have been developed over the years. Each one works a little differently and comes with its own strengths, limitations, and tradeoffs.
To make these systems easier to discuss, we break them down into four common roles:
Tagger
Prepares the data for proving by generating the cryptographic metadata that makes future proofs possible.
Challenger
Asks the Prover to demonstrate possession of specific pieces of data.
Prover
Stores the data and generates proofs showing that it is still available.
Verifier
Checks the proof and determines whether the challenge was answered correctly.
These are roles. One person or system may perform several at the same time.
For example, some protocols require secret information to verify proofs. In those systems, the Tagger and Verifier must be the same party, which means that party must also act as the Challenger. Other protocols support public verification, allowing anyone to act as a Challenger or Verifier. Pinion uses a publicly verifiable scheme.
Pinion uses the following arrangement:
Proof keys are at the center of Pinion’s arrangement. A proof key is a cryptographic key pair: Pinion holds the private key and the tags it created with that key, while you hold the public key. Because the verification scheme is publicly verifiable, the public key is all you need to issue challenges and check proofs. Your browser generates a proof key automatically on your first visit to the dashboard, and you can generate additional keys or export a key at any time.
Tagger
Pinion acts as the tagger. Creating tags requires access to all the block data, so content must reach the pinned state before tagging can begin. This can take a few seconds to a few minutes after upload, because an IPFS node walks every block in the DAG and verifies its integrity. Once content is pinned, Pinion generates small pieces of metadata called tags, derived from the actual block data using the proof key. Each tag is stored by Pinion and associated with the specific proof key that created it.
Challenger
You are the challenger. To begin challenging Pinion, you export the proof key from the dashboard. The exported file is a JSON setup file containing your public key and the list of CIDs eligible to be challenged: one for every block tagged under that key. This file can be large for content with many blocks, but it is transferred once at setup time. After that, challenge messages are tiny, typically tens of bytes, regardless of how many blocks you ask Pinion to inspect. You control how comprehensive each challenge is: you can sample a small fraction of blocks at regular intervals, or inspect all blocks at once. More comprehensive challenges require Pinion more time to respond, but the size of the challenge and proof on the network stays the same either way.
Prover
Pinion acts as the prover. When a challenge arrives, Pinion reads the compact challenge message, determines exactly which blocks need to be inspected, and computes a proof against the actual stored block data. That proof is sent back to you. The computation is done over real stored content, so a valid proof demonstrates that Pinion holds the data at the moment the challenge was answered.
Verifier
You are the verifier. Your exported proof key contains everything needed to check Pinion’s response. The scheme is publicly verifiable, so you can run verification from your browser or from a compatible third-party client. Third-party clients let you run verification on infrastructure you control, independently from your browser session. If the proof checks out, you have cryptographic confirmation that Pinion possessed all the inspected blocks at the time of the challenge.
When you open the dashboard, your browser immediately begins issuing challenges and verifying responses in the background. By the time you finish reading this page, it will have already accumulated evidence.
The Evidence Curve
The first thing you see on the dashboard is the Evidence Curve. It shows how the probability of detecting a storage failure accumulates as you issue more challenges. The shape of the curve depends on how many blocks your pins contain and what fraction you sample per challenge, but the direction is always the same: up and to the right.
The dot on the curve marks where you are right now. As your browser sends more challenges and Pinion returns more verified proofs, the dot moves right, tracing your personal evidence record. A dot near the top of the curve means that if something were wrong with your storage, you would almost certainly have caught it by now.
When you have more than one challenger key active, each key gets its own colored dot on the same curve, letting you compare evidence from your browser and any external challengers at a glance.
The Local Challenger
The Local Challengeris your browser. It is created automatically on your first visit to the dashboard and persisted in your browser’s local storage so it survives page reloads. You do not need to create it, name it, or manage it. It just runs.
The Local Challenger automatically mirrors your pin list. When you pin a new file, Pinion tags its blocks and the challenger picks it up. When you delete a pin, it is removed from the challenger’s scope. Every pinned CID is always in play.
The card shows three live stats: the number of blocks tagged across all your pins (more blocks = more surface area for each challenge), the total number of challenges sent since the key was created, and your current evidence level as a percentage. You can pause the automatic background proofs or trigger a manual round at any time.
Challenge CIDs
While the Local Challenger runs continuously in the background, the Challenge CIDs panel lets you issue challenges on demand. Select individual pins, choose what fraction of their blocks to sample, and hit Challenge. The results appear in the Verification Log below immediately.
Each row shows the pin’s CID, how many blocks are tagged, and its current evidence percentage. You can challenge a single pin, a subset, or all of them at once. Whether challenging one pin, or one thousand, the challenge and proof size is the same.
The Block sampleslider controls what fraction of each pin’s blocks are sampled per round. A higher sample means more evidence per challenge but slightly more data transferred. At 100%, every block is included in every round.
The Verification Log
Every challenge your browser issues produces an entry in the Verification Log. Each entry records whether the proof Pinion returned was valid. A PASS means the mathematics checked out. Pinion produced a proof that requires possession of your actual block data to construct. A FAIL means the proof was invalid and something may be wrong.
The log shows the timestamp, which CIDs were challenged, and the result. Because verification runs entirely in your browser against your locally-held client setup, Pinion has no way to tamper with what you see here.
External Challengers
Your browser is convenient, but it only runs when the tab is open. For continuous, unattended verification from a server, a CI pipeline, or a monitoring system, Pinion lets you create External Challengers.
An external challenger is a key associated with a specific set of CIDs you choose. When you create one, you select which pins to include, and Pinion tags those blocks and prepares a client setup. You then export the challenger as a JSON file: a self-contained configuration that includes the key, the tagged block IDs, and the server endpoint.
That JSON file can be imported into any compatible challenger application. You can run challenges against Pinion from anywhere, at any frequency, without touching the dashboard. The dashboard still shows the evidence level for each external challenger (polled every few minutes), so you have a unified view of all your verification activity.
External challengers work from the configuration file you exported at setup time, which defines exactly which CIDs they track. Because that file is fixed, they do not mirror changes to your pin list automatically. If you add new pins you want covered, open the Manage pins view on the card and check them. If a pin is deleted, the card will flag it as a stale tag so you can clean it up.
Reading the results
A PASS means Pinion produced a valid proof for the blocks sampled in that round. The sampled blocks were present and intact at that moment, and each round adds to the cumulative evidence that your full dataset is in good health, with no missing or corrupted blocks.
A FAIL means the proof did not verify for those specific blocks. Transient issues such as a network error or a key mismatch can produce a spurious failure. Investigate any FAIL you see, and contact us if you need help.
Keep challenging us
Every verified proof is a data point. The more you challenge us, the harder it becomes for any storage failure to go undetected. Your browser is already doing this for you, but the more you engage, the stronger your evidence record becomes.