# Universal Hash Resolution Protocol

Ty Everett (<ty@projectbabbage.com>)

## Abstract

This document describes the Universal Hash Resolution Protocol (UHRP), a standard framework for content availability advertisement implemented with a UTXO-based overlay network. UHRP enables content hosts to advertise the availability of a particular file by creating a UTXO-based advertisement token, which is then submitted to the UHRP overlay and tracked by [BRC-22](/brc/overlays/0022.md) overlay network nodes. UHRP provides resilience to single points of failure and ensures content accessibility even if one host is offline, because multiple entities can be paid by content providers to keep content available.

## Motivation

In the digital world, consumers often require access to specific content without regard for the hosting source. Content providers, on the other hand, have a vested interest in maintaining wide availability of their offerings, even during host outages. Existing systems, however, do not provide a standardized and robust means of connecting users to their required files.

UHRP addresses this by enabling multiple content hosts to advertise the availability of content using UTXOs. Users can seek the content based on its hash, ensuring they connect to the files they need via an overlay network that is resilient to single points of failure. Content providers wishing to ensure consistent availability can pay multiple hosts, so that content remains available even if one host goes down.

This new paradigm not only streamlines content availability but also enables new hosts to build reputation by demonstrating opportunity cost (for example, by paying higher than normal transaction fees to miners on hosting commitments). Over time, service providers and applications can build a trusted list of UHRP hosts, thereby improving the overall reliability and trustworthiness of the content hosting ecosystem.

## Specification

### Status Note

The content-addressing idea remains current, and `bsv-blockchain/ts-sdk` includes `StorageUtils`, `StorageDownloader`, and `StorageUploader` helpers for UHRP-style storage. Some details below are historical:

* Current SDK UHRP URLs encode the SHA-256 file hash with Base58Check prefix `ce00`; callers may use the bare string or a `uhrp:` / `uhrp://` prefix.
* Current SDK download resolution queries BRC-24 service `ls_uhrp` with `{ "uhrpUrl": "..." }` and expects an `output-list` response.
* Current SDK resolution reads PushDrop advertisement fields with the download URL in field 3 and an expiry timestamp in field 4.
* Current SDK upload helpers interact with storage servers through authenticated HTTP routes such as `POST /upload`, `GET /find?uhrpUrl=...`, `GET /list`, and `POST /renew`; the direct file upload itself is a `PUT` to the server-provided upload URL.
* The older `UHRP` topic/provider naming and the NanoSeek/NanoStore tooling references below are legacy. New overlay implementations should use BRC-87 names such as `tm_uhrp` / `ls_uhrp` or another explicitly documented `tm_` / `ls_` pair.

A UHRP advertisement token comprises a Bitcoin UTXO with a locking script containing the following components:

* `<public key>`: This is the public key associated with the host that is making the advertisement.
* `OP_CHECKSIG`: Ensures that if the token becomes spent, a signature was made using the host's private key.
* `Protocol prefix`: A protocol prefix pushed onto the stack, with a value of `1UHRPYnMHPuQ5Tgb3AF8JXqwKkmZVy5hG`.
* `<address>`: The base58 version of the address corresponding to the `<public key>`.
* `<hash>`: The next 32 bytes are the SHA-256 hash of the content being advertised.
* `<url>`: The HTTPS URL where the host is advertising that the content is available for download.
* `<expiryTime>`: A UTF-8 encoded version of a decimal integer representing the Unix timestamp of the advertisement expiry.
* `<contentLength>`: A UTF-8 encoded version of a decimal integer representing the byte length of the content.
* `<signature>`: A digital signature over the concatenated fields fields from the host's `<public key>`.

Upon creation and submission of an advertisement to a [BRC-22](/brc/overlays/0022.md) overlay network node for the historical `UHRP` topic, the node will track the UTXO and facilitate its lookup via a [BRC-24](/brc/overlays/0024.md) lookup service with the historical provider name `UHRP`. Current SDK download resolution uses lookup service `ls_uhrp`. If the token ever becomes spent, the advertisement is canceled. The spending transaction may contain more information justifying the host's revocation (such as a DMCA notice), but any such stipulation is beyond the scope of this initial document, and left for others to specify later.

## Implementation

Tools such as [NanoSeek](https://github.com/p2ppsr/nanoseek) (for downloading) and [NanoStore-Publisher](https://github.com/p2ppsr/nanostore-publisher) (for uploading to a NanoStore provider) have been created by the Babbage team. To implement the serialization format, the [`uhrp-url` tool](https://github.com/p2ppsr/uhrp-url) can be used.

Questions about this initial draft specification should be directed to the author.


---

# 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://hub.bsvblockchain.org/brc/overlays/0026.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.
