# Storage

Storage should be done during gossipsub communication and stored locally; this way, all peers or certain roles will all have the same data, allowing them to come to the same conclusion when scoring one another.

Alternatives to using the gossipsub for specific use cases can use the DHT record storage or DHT providers.

***

## GossipSub + Local Storage

In most cases, using a [GossipSub](/copy-of-subnet-template/communication/gossipsub.md) and storing the messages locally is preferred, especially in cases where all peers, specific roles, or a subset of peers should have replicated data. This is achieved because messages are broadcast across the network, and each receiving peer validates and persists them locally, causing the same data to be consistently stored across all peers, specific roles, or a subset of peers.

This mirrors how Bitcoin and Ethereum propagate data: blocks and transactions are broadcast across the network, and each node validates and stores them locally, resulting in a replicated state.

#### Usage

In most cases, using the GossipSub and storing the gossiped messages locally, especially for more frequent messages, such as:

* heartbeats
* status updates
* attestations
* commit-reveals
* live network events
* data all peers or a subset of peers should replicate

***

## DHT

The ServerBase class automatically exposes the subnet to the DHT class.

### DHT Records

Records in a Distributed Hash Table (DHT) are stored by assigning keys (content hashes) and values (data or provider addresses) to specific peers whose Node IDs are closest to the key based on a distance metric, such as XOR.

In short, DHT records are stored by a subset of peers responsible for a key. When queried, multiple peers return the data, and the requester verifies consistency (e.g., via signatures or hashes). This enables fully decentralized data storage.

{% hint style="info" %}
DHT records should only be used for use cases where GossipSub can't work.
{% endhint %}

#### Usage

**Use DHT records** when there is low-frequency data, such as:

* storing an IPFS link to a file that will never change
* storing peer info
* data that should be retrieved under a low frequency

***

### DHT Provider

A **DHT provider** is a peer within a Distributed Hash Table (DHT) network that advertises and stores data, making it searchable by other peers. It maps specific content identifiers (such as file hashes) to its own address, enabling decentralized content discovery and file sharing.

#### Usage

* Content discovery (files, datasets, models)
* Service discovery (APIs, inference providers, roles)
* Dynamic data ownership/location tracking
* Compute / resource marketplaces (I have this hardware)
* Selective data hosting (partial network storage)
* Capability advertisement (what a peer can do)


---

# 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://docs.hypertensor.org/copy-of-subnet-template/storage.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.