Network & Protocol

Most internet services are discovered through a domain name.

That works well until the domain itself becomes unavailable. A registrar intervention, hosting failure, DNS problem or other disruption can leave an application unable to locate a service even when that service is still operating somewhere else.

Proposed BRC-211 — Signed On-Chain Reachability Manifest, submitted by RexStarBSV on October 10, explores a different way to preserve that connection.

The proposal defines a signed record containing multiple locations at which a service may be reached. Those locations can include ordinary web domains, alternative domains, raw IP addresses, Tor onion services, IPFS locations, Nostr relays or an application shell carried on-chain. Each endpoint can be assigned a priority so a client knows which route to try first. GitHub

Separating Service Identity From Service Location

The important idea is not simply to put a list of backup URLs on BSV Blockchain.

BRC-211 separates who the client trusts from where the service happens to be running.

A compatible application ships with the service operator’s public key embedded in its build. When the client retrieves candidate reachability manifests, it verifies their signatures against that key and accepts the newest valid sequence permitted by its stored rules.

This means the blockchain record does not become trustworthy merely because it is on-chain.

Anyone could publish a competing manifest. What matters is whether the record carries a valid signature from the key the client already recognizes. GitHub

If the service later moves from one hosting provider to another, the operator can publish a newer signed manifest containing the new endpoints without asking the client to treat a replacement domain as a new source of authority.

That is the architectural distinction BRC-211 is trying to create: service identity can remain stable while service location changes.

A Fallback Beneath Existing Discovery

The proposal is not intended to replace the existing BSV Blockchain overlay-discovery model.

BRC-211 describes itself as operating beneath systems such as SHIP and SLAP. Once a client successfully reaches an appropriate service endpoint, the existing overlay-discovery mechanisms can continue from there.

It can also complement domain-hosted manifests. A client might use the normal domain while it works and consult the signed on-chain reachability information when that route is unavailable. GitHub

That makes the proposed manifest closer to a bootstrap and continuity mechanism than a new application-directory system.

The Discovery Source Still Does Not Have to Be Trusted

A client still needs somewhere from which to obtain candidate manifests.

BRC-211 allows those candidates to be supplied by a node or overlay host, but the source does not become the authority over the manifest itself. A hostile source could withhold a valid record, but it should not be able to create a replacement that passes signature verification without the issuer’s private key. GitHub

The proposal also includes sequence rules intended to prevent a client from being silently pushed back to an older valid manifest after it has already seen a newer one.

This does not guarantee availability. A user still needs access to at least one source from which to obtain the manifest and at least one listed endpoint that remains reachable.

A compromised issuer key would also undermine the model, while an endpoint whose domain has itself been seized may remain dangerous if it is still listed.

The proposal documents those residual risks rather than presenting the blockchain as a substitute for every other availability or security mechanism. GitHub

Reference Implementations Exist, but Deployment Does Not Yet

BRC-211 is more developed than a conceptual outline.

The proposal includes test vectors covering signed manifests, tampered payloads, sequence selection, version handling, script encodings and the client build-pin rule. Those vectors are tested against a Python reference implementation and two TypeScript readers, one using @noble/curves and another using @bsv/sdk. GitHub

But there is an equally important limitation: the author states that no manifest has yet been published on-chain.

PR #313 also remains open and unmerged.

So BRC-211 should currently be understood as a proposed and tested interoperability design, not as a service-discovery system already operating across deployed applications.

A Different Kind of Continuity

Domains remain useful because they give people readable and familiar ways to reach internet services.

BRC-211 does not try to remove them.

Instead, it asks whether a service should become unreachable solely because its usual location identifier disappears.

By placing a signed list of possible routes outside any single domain and tying authority to an issuer key rather than the current server address, the proposal attempts to give installed clients another way to reconnect when infrastructure changes.

That is a relatively narrow function, but it illustrates a broader infrastructure principle: the identity of a service does not necessarily have to be inseparable from the location through which it is reached.

Whether that model proves useful will depend on implementation, deployment and real-world recovery testing. For now, BRC-211 provides a concrete proposal for how that separation could work.

Proposed by

RexStarBSV

Other notable BRC work includes:

• BRC-145 — Registry-Free Typed Content Anchor with On-Chain Code Provenance, defining typed content commitments and software/build provenance without a central type registry. GitHub
• BRC-179 — Signed Capability Manifest for Wallet and Tool-Server Method Exposure, defining a signed record of which methods a wallet or agent tool server exposes. Beersy
• BRC-181 — Wallet-Enforced Autonomous-Agent Spend Policy, placing hard spending-policy enforcement in the wallet rather than relying on an autonomous agent to restrict itself. Beersy
• BRC-225 — Animated-QR Air-Gap Transport for Arbitrary Payloads, defining a framed QR transport for moving larger payloads to and from offline systems. Beersy

Source Links

BRC-211 — Signed On-Chain Reachability Manifest, GitHub PR #313

BSV TIMES – Under the Surface

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.

BSV TIMES – Under the Surface

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.

Update — October 13, 2026