BNRP: Bitcoin Name Resolution Protocol

What is BNRP?

BNRP is an open resolution layer for BTC-native names. It gives wallets, marketplaces, and apps a shared way to read name records — ownership, avatars, addresses, inscriptions, and provenance data — directly from Bitcoin-native sources.

It is not a registry. It does not issue names. It is the resolver: a standard for reading what already exists on-chain.

BNRP resolves

name owner address
name primary Bitcoin address
name avatar / inscription link
name text records (Twitter, website, description)
name marketplace listing status
address primary name (reverse lookup)
namespace supported resolver / indexer

What BTCNative uses it for

BTCNative uses BNRP to index, verify, and display BTC-native identity records across supported namespaces including .btc, .sats, .x, .ord, and others.

Verify ownership

Cross-reference name inscriptions with on-chain owner data before displaying any listing.

Resolve identity cards

Display avatars, display names, descriptions, and linked social handles from on-chain records.

Address resolution

Map Bitcoin names to wallet addresses for display and payment routing.

Provenance signals

Flag first-inscription canonicality and surface re-inscription warnings on buy/sell surfaces.

Reverse lookup

When a wallet connects, resolve the address back to a primary name for display in the nav.

Marketplace status

Show whether a name is currently listed, its price, and last sale data alongside BNRP records.

What BNRP does not mean

BNRP does not custody names. Names are Bitcoin inscriptions. They live on-chain. BNRP only reads them.

BNRP does not own names. Ownership is determined by which address holds the inscription on Bitcoin.

BNRP does not replace Bitcoin. It is a read layer on top of Bitcoin. Bitcoin consensus is the ground truth.

BNRP does not guarantee market value. Resolution and indexing have no bearing on price. Markets determine value.

BNRP is not a partnership claim. Displaying a name from any collection does not imply partnership with that project, marketplace, or wallet unless explicitly stated.

Resolver examples

These are illustrative examples of how BNRP reads name data. Live data is fetched from on-chain sources at resolution time.

Owner: verified on-chain
Primary address: bc1p… connected
Avatar: inscription-linked
Listing: not listed

Owner: verified on-chain
Primary address: bc1p… connected
Avatar: none set
Listing: listed

Owner: unresolved placeholder
Primary address: unavailable
Avatar: none set
Listing: listed

Developer reference

BNRP provides a normalized record model for BTC-native names. The API returns a consistent shape regardless of which underlying indexer resolved the name.

GET /v1/resolve/{name} Forward resolve — name → records

GET /v1/reverse/{address} Reverse resolve — address → primary name

GET /v1/batch?names=a,b,c Batch resolve — up to 20 names

Base URL: https://api.bnrp.name/v1/

Normalized record model

{
  "name": "example.btc",
  "owner": "bc1p...",
  "primaryAddress": "bc1p...",
  "avatar": "inscriptionId or URL",
  "records": {
    "twitter": "",
    "website": "",
    "description": ""
  },
  "listing": {
    "status": "listed",
    "price": "",
    "marketplace": "BTCNative"
  },
  "provenance": {
    "source": "unisat | btcname | sns",
    "verifiedAt": "2026-01-01T00:00:00Z"
  }
}

Live API Source on GitHub

Records

One name. Many addresses.

A single BTC-native name can carry records for any chain. Your .btc name is the canonical identity root. Every record below is optional and set by the owner.

Bitcoin (P2TR)

Primary on-chain address. Verified against the inscription owner at resolution time.

Lightning address

LNURL or Lightning address for instant, low-fee BTC payments without on-chain fees.

Ethereum

Optional ETH address record for cross-ecosystem interoperability. Never the root of trust.

Solana

Optional SOL address record. Useful for holders who operate across chains.

Website

URL to a personal site, portfolio, or project. Resolved and surfaced on name profiles.

X / Twitter

Social handle stored in your inscription record. Displayed on your BTC Native profile page.

Example — full record set

GET https://api.bnrp.name/v1/resolve?name=satoshi.btc

{
  "name": "satoshi.btc",
  "owner": "bc1p...",
  "addresses": {
    "BTC":       "bc1p...",
    "LIGHTNING": "satoshi@getalby.com",
    "ETH":       "0x...",
    "SOL":       "So1..."
  },
  "profile": {
    "display":      "Satoshi",
    "com.twitter": "satoshi",
    "url":         "https://bitcoin.org"
  },
  "via": "unisat",
  "resolved_at": "2026-04-23T20:00:00Z",
  "cached": true
}

Bitcoin is always the root. All other address fields are optional owner-set records.

Roadmap

Subnames & namespaces

Coming next

Top-level names will be able to issue subnames under their namespace. A collector who owns artist.btc could issue shop.artist.btc or vault.artist.btc as independently resolvable names. Each subname carries its own BNRP records and resolves through the same open protocol.

shop.artist.btc Storefront — issued by artist.btc holder

vault.punk.btc Cold storage namespace — controlled by punk.btc

dev.satoshi.btc Developer identity — separate records, same root

pay.brand.btc Payment address sub-namespace for brands

Issuance model

The parent name holder controls subname issuance. No platform permission required. Records are inscribed on Ordinals and resolved via BNRP API.

Resolution

Subnames resolve through the same api.bnrp.name/v1/resolve endpoint. No new DNS or off-chain infrastructure needed.

Ownership

Each subname is an inscription owned by the subname holder. Transfer of the parent does not transfer subnames — each resolves independently.

This is a protocol roadmap item. Subname issuance is not yet live. Follow @btcnativename for updates.

Resolution model

Permanent history. Current state.

Bitcoin inscriptions are permanent. BNRP does not edit old inscriptions. Instead, each update creates a new Bitcoin-native record. The resolver reads the latest valid record, while the full history remains visible.

Latest valid inscription wins.

A newer inscription is not automatically valid. BNRP validates each update against these requirements:

Authorized by the current owner or delegated manager
Matches the namespace policy
Uses a newer nonce or version number
Is confirmed or safely indexed (not unconfirmed or chain-reorged)
Has not been revoked or superseded by a later valid record

A newer inscription is not valid unless it is authorized by the correct owner, delegate, or namespace policy. Do not assume the newest inscription is the current record.

Supported record operations

registerrecord_register

updaterecord_update

revokerecord_revoke

registersubname_register

updatesubname_update

revokesubname_revoke

delegatedelegate_add

delegatedelegate_remove

updatepolicy_update

registersubname_transfer

revokesubname_freeze

Not all operations are live on BNRP indexing today. This is the full planned operation set. Current support: record_register, record_update. Subname ops are roadmap.

Scope

What BNRP does not mean

BNRP does not custody names.

BNRP does not own names.

BNRP does not replace Bitcoin.

BNRP does not guarantee market value.

BNRP is not a claim of partnership with any collection, marketplace, wallet, or protocol unless explicitly stated.

BNRP does not use Ethereum-style smart contracts. Subnames are Bitcoin-native records interpreted through BNRP resolver rules.

Developer model

Full resolver record schema

This is the extended BNRP record model including resolver state, namespace data, record history, and provenance.

Extended record model

{
  "name": "example.btc",
  "owner": "bc1...",
  "primaryAddress": "bc1...",
  "avatar": "inscriptionId or URL",
  "records": {
    "twitter": "",
    "website": "",
    "description": ""
  },
  "listing": {
    "status": "listed",
    "price": "",
    "marketplace": "BTCNative"
  },
  "provenance": {
    "source": "unisat | btcname | sns",
    "verifiedAt": ""
  },
  "resolver": {
    "protocol": "BNRP",
    "rule": "latest-valid-inscription-wins",
    "currentRecord": "",
    "recordHistory": []
  },
  "namespace": {
    "enabled": false,
    "policy": "parent-controlled",
    "subnameCount": 0,
    "delegates": []
  }
}

Subname record (roadmap)

{
  "name": "shop.artist.btc",
  "type": "subname",
  "parent": "artist.btc",
  "label": "shop",
  "status": "active",
  "authorization": {
    "authorized": true,
    "method": "parent-owner",
    "verifiedAt": ""
  },
  "owner": "bc1...",
  "records": {
    "btc": "bc1...",
    "website": "https://example.com",
    "avatar": "inscription-id"
  },
  "policy": { "type": "parent-controlled" },
  "currentRecord": {
    "rule": "latest-valid-inscription-wins",
    "inscriptionId": "",
    "nonce": 3,
    "op": "subname_update",
    "verifiedAt": ""
  },
  "recordHistory": [
    { "inscriptionId": "", "op": "subname_register", "nonce": 1, "status": "superseded" },
    { "inscriptionId": "", "op": "subname_update",   "nonce": 2, "status": "superseded" },
    { "inscriptionId": "", "op": "subname_update",   "nonce": 3, "status": "current" }
  ],
  "provenance": { "source": "bnrp", "createdAt": "", "updatedAt": "" },
  "resolver": { "health": "ok", "verifiedAt": "" }
}

Full API reference Source on GitHub

BNRP: Bitcoin NameResolution Protocol

What is BNRP?

What BTCNative uses it for

What BNRP does not mean

Resolver examples

Developer reference

One name. Many addresses.

Subnames & namespaces

Permanent history. Current state.

What BNRP does not mean

Full resolver record schema

BNRP: Bitcoin Name
Resolution Protocol