BRC-174 Defines Consensus-Unique Name Tokens for Verified Identity Resolution

Identity Infrastructure Watch / Network & Protocol

In Brief

BRC-174 introduces a specification for resolving human-readable names to cryptographically verified identity keys using transferable one-satoshi name tokens whose uniqueness is enforced by Bitcoin Script. The design separates discovery from authority: an index can tell a wallet where a name token currently resides, but the wallet is expected to verify the token’s lineage, current ownership binding and transaction evidence independently before trusting the result. The complete resolver remains to be implemented. (Beersy)

News Report

A newly published Bitcoin Request for Comments proposes a way for human-readable names to resolve to BSV Blockchain identities without requiring a conventional domain owner or central naming registrar to determine who controls each name.

BRC-174, “Consensus-Unique Name Tokens — Identity Binding and Verified Resolution,” was published August 28 and authored by Matt Archbold. The specification uses OpNS as its reference namespace and combines covenant-enforced name uniqueness, 1Sat Ordinal lineage, identity-key binding and independently verifiable lookup. (Beersy)

The problem begins with a distinction between a readable name and a trustworthy identity.

Anyone can create metadata containing a string such as archie, but the string alone does not establish that only one such identity exists or that a wallet should trust a particular key associated with it.

BRC-174 therefore defines several separate properties that must be verified before a name can safely resolve.

First is uniqueness and control.

Under the reference model, a name exists as a transferable one-satoshi token created through a covenant structure. The covenant is designed so that a second valid token for the same name within that namespace cannot be created. Competing attempts ultimately contend over the same spendable state, making duplicate issuance a transaction-consensus problem rather than a naming dispute settled by a registrar. (Beersy)

That uniqueness is not absolute across every possible naming system. BRC-174 explicitly recognizes that another namespace could exist under another genesis. A resolver therefore has to know which namespace root it trusts and verify that the name being presented actually descends from that configured root. (Beersy)

The second requirement is authenticity through lineage.

A resolver does not accept an inscription containing the correct text as sufficient evidence. It traces the current one-satoshi token back to its origin and then verifies that the origin itself descended from the configured namespace genesis.

That separates an authentic name token from an unrelated output carrying an identical name string. (Beersy)

The third layer is the identity binding.

BRC-174 places an asserted identity public key into a signed PushDrop locking script on the name token’s current output. The locking key is derived from the identity key being asserted, while a required signature demonstrates control of that identity.

As a result, the name and its current identity relationship remain tied to the spendable token rather than existing as a separate assertion in a service provider’s database. (Beersy)

That also gives revocation a particular meaning.

Spending the name token destroys its existing identity binding because the old output no longer exists. The name itself is not destroyed or recycled; it continues through the new output and can subsequently be rebound to another identity key by its holder. (Beersy)

The fourth component is findability, but BRC-174 deliberately treats an index as a data source rather than an authority.

An index can answer a practical question — where is the current output for this name? — but the client is expected to verify the returned transaction evidence locally. The resolver checks the BEEF evidence, traces the token’s lineage, confirms that the output is unspent, decodes the identity binding and verifies the corresponding key derivation and signature before accepting the identity. (Beersy)

If different indexes return conflicting candidates, the specification says the resolver should verify them rather than silently trusting one provider.

This is what distinguishes the model from a conventional naming service in which the directory operator itself determines the current mapping.

Once a name resolves successfully to an identity key, applications can use existing BRC infrastructure to act on that result. BRC-174 describes deriving payment destinations through BRC-42 and BRC-43, while messaging can use BRC-33. (Beersy)

The specification is related to, but different from, BRC-169, which BSV TIMES covered in August.

BRC-169 defines universal handle addressing of the form @handle@ecosystem, where uniqueness exists within an ecosystem or domain. BRC-174 addresses a different requirement: names whose uniqueness is enforced within a covenant-backed namespace and whose identity binding can be independently verified rather than assigned by the ecosystem host. (Beersy)

The two approaches can therefore coexist rather than requiring one naming system for every application.

Several components beneath BRC-174 already exist.

The specification says its identity-binding format is deployed through the @1sat/actions SDK, while the OpNS reference overlay is open source and self-hostable. bOpen’s public repository collection includes opns-overlay among its overlay infrastructure projects. (GitHub)

The SHIP/SLAP discovery approach used by the proposal is also already present in Hodos Browser, which combines a native BRC-100 wallet with overlay discovery and other BRC services. (Beersy)

The complete BRC-174 resolution algorithm, however, is not yet implemented by the authors.

The specification says Hodos currently resolves names through certifier-filtered identity lookups rather than performing the full lineage and identity-binding verification required by BRC-174. That limitation is explicitly disclosed in the specification. (Beersy)

BRC-174 should therefore be understood as a published interoperability specification with several underlying components already deployed, rather than a completed end-to-end naming system operating according to every rule it defines.

BSV TIMES Read

Human-readable identifiers become much more useful when applications can verify them rather than merely look them up.

A conventional directory can make a name easy to find, but it also becomes the authority capable of assigning, changing or withholding the association between that name and its user.

BRC-174 takes a different approach. The index remains useful for locating the current record, but the evidence needed to decide whether that record is genuine comes from the token’s transaction history, locking script and identity signature.

That distinction can be summarized as:

the index tells you where to look; the blockchain evidence lets you decide whether to believe what you found.

There are still conventions in the system. A client must know which namespace genesis it recognizes, and the complete resolver described by BRC-174 still needs to be implemented and tested in real wallets.

But the architecture is notable because it separates discoverability from authority. If that model proves practical, readable names could become portable application infrastructure rather than accounts granted by whichever service happens to operate the directory.