Sending & receiving BTC with names: a draft standard

Hi Stacks friends!

There’s a lot of excitement around BNS and with that - which I’m thrilled to see! With that, there’s a growing list of asks for a future version of BNS. One of the things users are asking for is the ability to send and receive bitcoin with .btc names.

What the people want is something like this:


This isn’t something that needs to wait for an update to BNS. It’s something that can be done today with existing BNS functionality…all it needs are relatively simple developer tools and wallet support and an agreed upon standard.

I’ve put together a draft of such a standard to enable BNS names to bitcoin address mapping. It takes advantage of BNS’s compatibility with a subset of DNS zone file functionality to enable this feature without having to deploy new or updated smart contracts. The standard itself is actually name system agnostic: tools built to work with it will work not only with BNS names but also enable name-address (or account!) mappings on DNS names and other name systems such as HNS that support zone files.

Take a look at the blog post explaining how it works for some background before heading over to the draft standard document for more details.

I’d love your feedback…especially from wallet and application developers. Does this approach make sense? Is this useful for you? I’m happy to contribute this to any group that has formed that is looking to move BNS forward or, alternatively, resurrect the BNSWG.

Would this implementation be a new library, or a PR to an existing library like stacks.js?
Or, some other solution entirely i’m not thinking of?

This was actually brought up in a SIP call last week i think (i had been seeing the same requests in the community for a feature like this), and, like you, i see this as very possible today - but it’d be great to get ahead and standardize how it’s done.

The approaches you’re referring to seem good to me, but i’ll dig in a little deeper to see if i can find any issues with what’s being proposed. overall, it’s very similar to what i was thinking of as a potential SIP - but offloading this work to a library or something makes more sense.

1 Like

My feedback is this is dope af


Thank you for drafting and sharing this Larry! I think this is so important for BNS and Stacks. Would love to hear from others in the ecosystem. Xverse is definitely interested in implementing this standard.

Question - does this need to be a SIP or should BNS have it’s own improvement proposal process BNSIP?


This is great, strongly supported!

1 Like

Ideally, there’d be a SIP for it, since it’d be an ecosystem-wide standard.

1 Like

bns support registering names with underscore, like _b.btc, do i understand it right what for _b.btc address will be _btc._addr._b.btc ?

There’s nothing here that has to be tied to Stacks/Bitcoin/BNS.

@markjr wrote up similar ideas with a DNS (instead of BNS) focus recently in Bitcoin Magazine: Simplifying Bitcoin Addresses DNS - Bitcoin Magazine - Bitcoin News, Articles and Expert Insights

Since it is applicable to more than just the BNS/bitcoin ecosystem, my first instinct would be to make a new library. Something that akes a zone file as an input, has some functions to manipulate (add/remove/update) the addresses the name points at and then outputs the zone file. Library developers could choose to integrate this functionality into their libraries if they want but wouldn’t have as long as it gives developers access to the “raw” zone file.

1 Like

Yes. for _b.btc the name of TXT resource record would be _btc._addr._b.btc

Love this proposal! :heart:

We need more like this! Thank you for the write-up.

For this standard to get wider adoption, I think we need to solve the uniqueness of top level domains that users and wallets need to know when they want to resolve a name. Which blockchain/resolver service should they use for friedger.btc, friedger.bitcoin, friedger.fren, friedger.eth,,, blog.friedger? This is probably out of scope of the standard, but it should be mentioned that a mechanism should be established. Maybe is a place for that. web3domainalliance tries to create at least no overlaps between their members (like ICANN?).

Then once, the wallet managed to find the zone file which is the correct ticker that the user wants to use and that the recipient intended to publish?

In section 3.1 “Resource Record Namespace” the definition is left out.

coin’s ticker symbol name

Which ticker should be used here? ISO proposal “XBT” or commonly used “BTC”. What happens if a project/exchange decides to change a ticker. Do all users need to change their zone files?

Some more stories about changing token tickers, e.g. at

Probably, similar results can be achieved with the use of did:web specification. The W3C ( published a recommendation in July 2022 to integrate into the DID a web reference in order to use the trust that users have in the Internet DNS, calling it did:web, to speed up DID’s adoption.
Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Some of this has been addressed here GitHub - paradigma-cl/dappprofile: Stacks dapp public profile
Then having trustable interactions the DID addresses can be used to transfer funds to domain names.

Thanks for sharing Larry, this is great. The Hiro Wallet will of course implement the standard.


  • Are wallets expected to support DNS hosted names in addition to DNS names? Is there the possibility of naming collisions between BNS & DNS names?

  • Is it within the remit of the spec to discuss potential scope for abuse? Is DNS spoofing a concern?

  • Using a single address to receive funds has privacy implications. Would it be the responsibility of wallets to educate users of this? Are there any best practices to minimise divulging financial information? Should users frequently update their listed addresses, or is this futile as all addresses have at some point been public?

1 Like

If we have a mapping from a name to a DID, then here is a proposal to use a DID document for specifying how to receive btc payments (using various methods with or without privacy protections) :

1 Like

You are welcome! Thank you for commenting!

I agree - it is out of scope of this standard.

Agree it’s problematic and we’ve been punting on this for a while.

I personally think we should make BNS names look obviously not like ICANN DNS names…but that’s a discussion for another day (or at least another thread).

I think it’s just by convention. BTC refers to whatever there’s consensus around. Yes, all users would have to change their zone files. This increases the cost of changing - which is a good thing.

It sounds like this would require running a web server separate to and in addition to a stacks node or a DNS server? I might be reading it wrong?

Some of good suggestions re privacy here. Can we use DID documents without running something in addition to a stacks node (for BNS) or a DNS server (for ICANN DNS)?

I wouldn’t expect stacks wallets to support DNS names.

This is one reason I wouldn’t expect stacks wallets to support DNS. This isn’t an issue with BNS.

@light shared some suggestions on twitter to improve privacy which we can further investigate and perhaps add as either recommendations or requirements.

@fluidvoice and @RagnarLifthrasir also suggested more be done for privacy on the stacks layer

1 Like

Also @TO voiced support of more privacy here on the forum.

1 Like

Thanks for this detailed proposal, Larry! We’d love to support such functionality in Hiro Wallet along the lines of this proposed standard.

I’ve created an issue in our repo here so we can track our implementation details: Support BTC sends to BNS names · Issue #2924 · hirosystems/stacks-wallet-web · GitHub

@larry in standards/ at main · bnswg/standards · GitHub, is there text missing after “Trailing commas”?

I’m also curious if you considered any other formats besides comma-delimited for the TXT RR.

There was early support for DID in stacks-node some time ago. However, I don’t see any proposal to make use of the already developed did:stacks method. It is there ready to be used!