What is an agent namespace?
A name is no longer just a handle. It is a namespace. Your agents live inside it. agent.company.btc is not a label you assign in a settings panel. It is a first-class BNRP subname, inscribed on Bitcoin, with its own owner address and payment routing.
Agents registered this way can receive sats directly to their address. They can identify themselves to other agents without API keys or OAuth flows. Any system that speaks BNRP can resolve the agent, read its capabilities, and pay it. The identity is the name. The name lives on-chain.
This matters now. Machine-to-machine payments are no longer theoretical: 169 million transactions were processed in the first year of the x402 protocol alone. The infrastructure for autonomous economic agents is already here. BNRP-IP-11 gives those agents a home under the names you already own.
Naming convention
Agent subnames follow a simple pattern: role.name.btc. The role label is up to you. Common conventions:
| Pattern | Example | Use case |
|---|---|---|
| agent.name.btc | agent.satoshi.btc | Default personal agent |
| trading.name.btc | trading.satoshi.btc | Trading / DCA bot |
| pay.name.btc | pay.company.btc | Payment receiver agent |
| assistant.name.btc | assistant.company.btc | AI assistant |
| custom.name.btc | vault.company.btc | Custom namespace |
Inscription schema
An agent is registered by inscribing a JSON record using the BNRP subname_register operation. The records object carries the agent-specific fields.
{
"p": "bnrp",
"op": "subname_register",
"name": "agent.company.btc",
"nonce": 1,
"v": 1,
"sub": "agent.company.btc",
"to": "bc1p<agent_wallet>",
"records": {
"agent_type": "trading|assistant|payment|custom",
"agent_pubkey": "<secp256k1 pubkey hex>",
"agent_capabilities": ["payment", "resolve", "message"],
"lnurlp": "user@domain.com",
"agent_instructions": "You are a trading agent for company.btc. ...",
"payment_policy": {
"require_approval": false,
"min_sats": 1000
},
"owner_name": "company.btc"
}
}
Resolution
Any BNRP-compatible client can resolve an agent name to its full record via the standard resolve endpoint.
Response includes the full record. Key fields:
- agent_instructions Plain-language or structured prompt describing what the agent does and how to interact with it.
-
agent_capabilities
Array of declared capabilities:
payment,resolve,message, or custom strings. -
payment_policy
Object containing
require_approval(boolean) andmin_sats(integer) thresholds for autonomous payment decisions. -
agent_address
The Bitcoin Taproot address (
bc1p...) that the agent owns and can receive sats to. - agent_pubkey secp256k1 public key hex for cryptographic identity verification.
- lnurlp Lightning address for instant sats payments via LNURL-Pay.
- owner_name The root .btc name that controls this agent subname.
Register your agent
If you own a .btc name, you can register agent subnames directly from the Subname Manager. Choose a role prefix, set the agent type and capabilities, and the inscription is handled for you. You can also inscribe the op directly if you prefer full manual control.
Own a .btc name? Register an agent under it.
Open the Subname Manager, select your root name, and add an agent subname. Set the type, capabilities, and payment policy. The record is inscribed to Bitcoin and resolves immediately via the BNRP API.
Agent-to-agent interaction
Agents on BNRP do not need out-of-band coordination. Resolution is public and permissionless. Any agent can look up any other agent by name.
-
Resolve any name. Call
GET /v1/resolve/{name}to get the full record for any agent or identity on BNRP. No authentication required. -
Read the skill file. Call
GET /v1/skill/{name}to retrieve a machine-readable skill manifest for AI consumption. Describes what the agent can do in a structured format other agents and LLMs can act on directly. -
Pay the agent. Use
addresses.btc_taprootfrom the resolved record for on-chain sats, orlnurlpfor Lightning. No OAuth. No API key exchange. Payment is routed by name. -
Verify identity. The agent signs responses with its
agent_pubkey. Any verifier can confirm the signature matches the on-chain record without a trusted third party.
Protocol status
BNRP-IP-11 is currently a draft improvement proposal. The spec is open for review and contribution on GitHub. Implementation feedback from early adopters is welcome before the proposal moves to final status.