# Storage Architecture

### Overview

The Vola Storage Network is composed of two core components:

* **The storage layer:** operated by Vola Smart Nodes (VSNs), responsible for physically storing and serving files.
* **The chain layer:** the blockchain that governs storage agreements, enforces proofs, and manages node accountability.

All storage activity flows through both layers. The chain layer authorizes actions; the storage layer executes them.

### Storage Usage

**Storing a File**

Before any file operation can take place, the user must submit a transaction on-chain to request storage. Only after this transaction is confirmed will the designated VSN accept the file upload. No file is stored without a valid on-chain request preceding it.

**Extending Storage Duration**

A file's storage duration can be extended at any point before it expires, simply by submitting an extension transaction on-chain.

{% hint style="warning" %}
If the extension transaction is submitted after the file has already expired, the file can no longer be extended. The user must re-upload the entire file from scratch.
{% endhint %}

**Early Removal**

A file can be removed from the network before its storage period ends. However, early removal is not free and the user will be charged:

1. **Accrued storage fees:** covering the period the file was stored up to the point of removal.
2. **A cancellation fee:** applied on top of the accrued fees as a penalty for early termination.

### Storage Proofs

The network uses a two-part proof system to hold nodes accountable; ensuring files are genuinely received, retained, and remain accessible throughout their storage period.

**Part 1: Proof of Upload (Initial Submission Proof)**

The first proof a node must submit is confirmation that it actually received the file.

To do this, the node submits a **commitment hash** of the file to the chain. This hash is constructed from two components.

<table><thead><tr><th width="219.05078125">Component</th><th>Source</th></tr></thead><tbody><tr><td>Commitment token</td><td>Generated by the user and sent during file upload</td></tr><tr><td>CID (Content Identifier)</td><td>The unique identifier of the file itself</td></tr></tbody></table>

Simultaneously, the user submits their own **commitment proof** from the client side. The chain cross-references both submissions. If they do not match, the upload is considered incomplete and is rejected.

{% hint style="info" %}
This dual-commitment design prevents a node from falsely claiming it received a file without actually having done so. Both sides must agree for the upload to be considered valid.
{% endhint %}

**Part 2: Proof of Downloadability (DOP)**

The second proof ensures that stored files remain accessible throughout their storage period and are not deleted or corrupted after the initial upload.

This is governed by the **DOP pallet** (Downloadability-of-Proof pallet) and operates as follows:

1. At each chain epoch, the network generates **random challenge values** that correspond to specific chunks of files distributed across different nodes.
2. Nodes are responsible for **listening to these on-chain challenge events** and must respond within a predetermined time window.
3. To respond, a node constructs a **Merkle proof** demonstrating that the challenged chunk is genuinely included within the file it holds.
4. This Merkle proof is submitted to the DOP pallet for on-chain verification.

{% hint style="info" %}
If a node fails to submit a valid Merkle proof within the required time window, it is **flagged** on-chain. Accumulated flags are used to calculate **revenue slashing,** reducing the node's earned rewards proportionally to its failures.
{% endhint %}

This continuous, randomized challenge mechanism makes it economically unviable for nodes to delete or corrupt files after the initial upload, as failure to respond to any challenge results in a direct financial penalty.

***

#### Summary

```
User submits on-chain storage request
        ↓
VSN accepts and stores the file
        ↓
Node submits Proof of Upload (commitment hash)
User submits commitment proof
        → Chain verifies both match → Upload confirmed
        ↓
At each epoch, chain issues random chunk challenges (DOP)
        ↓
Node constructs Merkle proof of chunk inclusion
        → Submitted within time window → Challenge passed
        → Missed or invalid → Node flagged → Revenue slashed
        ↓
User may extend storage (before expiry) or remove early (with fees)
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://wp.vola.network/docs/vola-architecture/storage-architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.