Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

Data Infrastructure / Content Resolution

Bridget Doran has published a new plain-language explanation of the Universal Hash Resolution Protocol, or UHRP, making an older piece of BSV infrastructure considerably easier to understand.

BRC-26 itself is not new.

What is new is the effort to explain a technical protocol in terms of a problem almost every internet user already understands: a link stops working because the place hosting the file has changed or disappeared.

A conventional web address effectively says:

Get this file from this location.

UHRP changes the starting point:

Get me the file that matches this hash.

The difference is small in wording but important in architecture.

The file is identified by what it is

A cryptographic hash acts like a fingerprint derived from the contents of a file.

If the file changes, the hash changes. If two copies contain exactly the same bytes, they produce the same hash.

That means an application can identify the content it wants independently of the particular server currently storing it.

Under BRC-26, a host can publish an advertisement saying that it serves the content corresponding to a particular hash.

The advertisement includes the hash, a download location, an expiry time, the content length and a signature from the host.

Those advertisements can then be indexed through an overlay lookup service.

If several independent hosts advertise the same content hash, an application is no longer tied to one permanent URL. It can locate an available provider, retrieve the file and verify that the downloaded bytes match the requested hash.

The host can change.

The content identity does not.

UHRP does not put the file itself on-chain

This distinction is important.

UHRP is not a protocol for storing large documents, photographs, videos or other ordinary files directly on BSV Blockchain.

The file remains with a storage provider.

What the protocol provides is a common way to identify that file and discover hosts advertising its availability.

That allows storage and content identity to remain separate.

A file could move from one server to another, be mirrored by several providers or survive the disappearance of its original host while remaining addressable by the same hash.

The application does not have to trust the filename or URL alone to determine whether it received the correct object. It can calculate the hash of what was downloaded and compare it with the content identifier it requested.

Multiple hosts can advertise the same object

This gives UHRP a useful resilience property.

One content provider can arrange for several hosts to serve the same material.

If one disappears or becomes unavailable, another host advertising the same hash may still provide the identical content.

That does not guarantee permanent availability. Someone still has to keep a copy of the file and continue serving it.

What UHRP removes is the requirement that the content remain at one particular network location forever.

This makes it potentially useful for application assets, user-controlled files, published documents and other data that should remain retrievable even when the infrastructure hosting a particular copy changes.

The implementation language has moved on

The original BRC-26 specification contains references to tools such as NanoSeek and NanoStore and uses some older terminology for the overlay services around UHRP.

Those references are now historical.

The maintained BRC documentation notes that current @bsv/sdk tooling includes StorageUtils, StorageDownloader and StorageUploader for UHRP-style storage.

Current lookup behavior also uses newer overlay-service naming, including ls_uhrp, rather than relying on the older provider names found in the original examples.

That matters because an older BRC can otherwise appear abandoned when the underlying concept has simply moved into newer tooling.

The content-addressing model remains part of the maintained TypeScript development stack.

A small idea with a wider implication

UHRP addresses a very specific technical question: how can software find a particular piece of content without treating one server address as the permanent identity of that content?

But the distinction points toward something broader.

Data infrastructure becomes more resilient when what something is can be separated from where a copy happens to be stored today.

The storage provider can change.

The server can change.

Several providers can serve identical copies.

An application can still ask for the same content and independently check that the file it received is the one it requested.

BRC-26 has existed for years. Bridget’s new explainer does not introduce a new protocol or release.

Its value is making an existing infrastructure idea much easier to see: content can be identified independently of its location, while encryption and key ownership can remain separate again. The server may store the bytes, but it does not necessarily need to control either the identity of the content or the key required to read it.

Source Links

Bridget Doran — UHRP Explained Without the Jargon / BRC-26 — Universal Hash Resolution Protocol / BSV TypeScript Stack

UHRP Explained Without the Jargon
BRC-26 on BSV Hub
BSV TypeScript Stack

September 15, 2026