BNS Names on L1 - feedback requested

Goal: Allow existing BNS names to be traded as Ordinals

Why: Recent events have shown a demand for L1-based assets, in the form of inscriptions and BRC-20s. Marketplace support is broad, and liquidity is high. Allowing BNS names to be traded as Ordinals provides value to BNS name holders, and it removes any excuse for Ordinals marketplaces to not list the “original” BTC names.

Ask: Please provide feedback. The idea behind this project is to be a “first step” in making BNS more L1-friendly. I’d love feedback on questions like:

  • Is this the right “first step”, or is there a better initial strategy?
  • Is this a product you’d like to use, as a BNS user?
  • What would you prefer resources spent on - this project or a BNS upgrade? See the notes at the bottom of this post for more info.

This document is mainly intended to describe the functional aspects of this project. There are many other important facets of the project, like how to evangelize and grow usage, which are not deeply covered here.

How it works (high level)

  1. A user owns a BNS name
  2. User inscribes an Ordinal
    a. They are provided an SVG or image to inscribe
  3. After inscribing, user calls a Stacks contract to lock their name
    a. The Stacks contract keeps track of the inscription / name association
  4. The inscription is now part of an “official BNS names” Ordinals collection. It is traded, transferred, etc
    a. The BNS API will track all transfers of these inscriptions and use the BTC address of the current inscription owner as the “owner” of this name. This will allow wallets to support “send BTC to BNS” for L1-based names
  5. The inscription owner may choose to bridge back to L2. To bridge back to L2:
    a. User transfers their inscription to a burn address
    b. User calls the Stacks contract to unlock the L2 name

A few important details:

  • An oracle is required to verify certain states, such as the final owner of an inscription. Due to the complexity of Ordinal theory, there are no known solutions for a Stacks contract to trustlessly track ownership of an inscription through multiple transfers.

How it works (low level)

Bridging to L1

A BNS name owner can visit Dots (our BNS app) to manage the process of bridging to L1.

Mint the inscription

The first step is to mint a new inscription. The app will provide the exact content of the inscription, so that each inscription has a consistent style and includes the correct name. To prevent minting duplicate inscriptions, the inscription will not be the standard name.namespace text format. Instead, a light SVG or image will be used.

Lock the BNS name on L2

Once the inscription is minted, the app prompts the user to lock their BNS name in a Stack contract.

Due to limitations of BNS, the name must be a BNSx name. Otherwise, the Stacks contract cannot “escrow” multiple names under one contract. The app will provide an easy interface to migrate to BNSx and lock their name in a single transaction.

The Stacks contract will verify the contents of the inscription and keep track of all inscription-based state, such as the inscriptionId used for each name.

Trade on L1

Once the BNS name is locked on L2, the Stacks contract acts as the “source of truth” for the official set of BNS names on L1. We will expose this via API endpoints for marketplaces to consume.

When an L1-based BNS name is transferred, our API will use the current owner’s BTC address as the owner of a name.

Bridging back to L2

A L1-based name can be transferred and traded unlimited times before being bridged back to L2. We will provide a UI in Dots to bridge back to L2.

Transfer the inscription to a burn address

A standard will be provided for deterministic burn addresses that allows for associating the intended STX address to receive the L2 name. An example p2sh burn address script is:




This script can never be spent, but it allows for constructing a STX address from the “embedded” public key.

Call a Stacks contract to unlock the L2 name

Once the inscription is transferred to a burn address, the user calls a Stacks contract to unlock the name.

Before calling the contract, the app fetches signatures from an oracle service, which will be used to verify that the inscription has been transferred to the burn address. The payload of signed data from the oracle includes:

  • inscriptionId

  • ownerAddress - the current owner of the inscription

  • blockHash - the block hash (and height) where this data is valid. This allows for only a single confirmation to pass before the name can be unlocked

The user calls a Stacks contract, providing the information from the oracle. The stacks contract verifies that the current inscription owner matches the burn address for a specific STX address. Once all data is verified, the BNS name is transferred to the STX address.


Marketplace listings

This project is only successful if marketplaces adopt these names as an “official” BNS project. Our hope is that Gamma can be an early supporter, followed by other marketplaces.

Resources vs BNS upgrade

This project requires resources that could also be spent on pushing forward a BNS contract upgrade. This project is likely easier to accomplish than a full upgrade, and doesn’t require any changes to BNS contracts. Still, there is an argument to be made that all effort should be spent on a BNS upgrade first.

In my opinion, it makes more sense to spend time to launch this project. The launch of Ordinals has created a sense of urgency for better L1 compatibility. I’m hoping this post can shed light on the desirability of this project, which can help answer this question of prioritization.

Would love to support the initiative at Gamma. Let’s talk about what needs to be done.


Good idea




Great Idea!


Love this initiative!


@Muneeb get tweeting you hero!

BNS will be the future of Identity


This project is only successful if marketplaces adopt these names as an “official” BNS project. Our hope is that Gamma can be an early supporter, followed by other marketplaces.


Hey Hank!

I am top BNS bull since December 2021.

I really appreciate what you have done and been doing for BNS.

I support your proposal 100%, and I am being been in L1 24/7 since March this year.
Your proposal and eventual implementation might be game change for BNS and Stacks.

Full support​:sunglasses::heart:


Thanks hank for putting this together.

I am fully supportive of this proposal. Let’s start with this as soon as possible <3


Thank you very much!

we will moon!


amazing! super sup.hank is top top


Great Idea!


How/where would the zonefile and profile data be stored? Or is bns on L1 limited to send btc to bns? Can we sign-in with bns on L1?


Are the signatures needed - can’t the L1 burn transaction be verified directly in clarity?

Thanks Hank - great post!


This approach suffers from an unnecessary fatal flaw - locking a BNS name.

This freezes name owners from using their names for anything other than an inscription! By locking the name, users can’t sign in to Web 3.0 apps, and will have their profile closed on - the only Stacks identity app. BNS is supposed to be used for identity.
Also, this Dots approach is centralized - because of the complexity, it’s highly likely that only Dots will have the tools to implement their approach. Additionally, the Dots approach is part of their BNSx tools which is controversial and has failed to be adopted by several key applications and users.

The better approach that avoids all of the above is not to lock the BNS name after the user inscribes an Ordinal.

BNS to Ord - not locking name

Indexers and APIs will read the standardized formatted file as a Stacks BNS name, as well as the address of the owner. This is similar to .sats Ordinal names.

BNS to Ord Names

For reference, there are 290,000 .sats names vs 241,800 BNS names. Creating a new, complex approach to Ordinal names doesn’t make sense. Following the current Ordinal name approach that users are comfortable with makes sense.

Because there are more .sats names than BNS names, an essential consideration in adoption is to appeal to Ordinal .sats name owners who are not currently Stacks users. They will find BNS to Ordinal names more attractive if they can take their Ordinal .sats and “convert” them into BNS .sats names.

I own the .sats BNS namespace and am working on this capability with Janus Names.

Ordinal .sats to BNS .sats

Presenting a cohesive model of:

  • Ordinal .sats names to BNS .sats and
  • BNS names to Ordinal names
    to non-BNS, .sats users significantly increase appeal to a broader audience.

In last Friday’s BNS working group, Larry Salibra said that presenting Ordinal to BNS and BNS to Ordinal is a better market approach, where we come from a position of strength.

In summary, not locking the BNS name after the user inscribes an Ordinal is a better approach because
1. It is less complex
2. Users aren’t frozen from using their name
3. Centralization risks are reduced
4. Easily plugs into existing Ordinal name methods and infrastructure
5. Can be presented to Bitcoiners cohesively with the .sats —> BNS .sats functionality

This project requires resources much better spent on pushing forward a BNS contract upgrade. I recommend seeing it through to benefit Stacks for the long term.


**Update to post
Someone on Twitter made the argument that the “L2 name has to be frozen so that L1 name won’t conflict and duplicated with L2, the proposal is aim to attract more liquidity on ordinals.”

However, once the L1 name is inscribed it will be considered the official name by indexers and APIs. Similar to .sats.
There are more .sats names than BNS names, so it works well enough considering the downsides of locking names.


Hey Ragnar, the reason for locking the Stacks-based name is so that ownership can be transferred on L1, while allowing the new L1 owner to later claim the Stacks-based name if they choose to. If the Stacks NFT is not moved away from the owner’s wallet, there is no way to support this bi-directional functionality. This would negate any of the value around being able to use L1 liquidity to trade the inscription, because you’re not actually buying ownership of the BNS name


You can verify that a specific TX happened on L1, but you cannot use Clarity to track an inscription over multiple transfers. This is due to the complexity of “sats” (in Ordinals theory). In order to do this in Clarity, Clarity needs to know the exact Sat<->UTXO set since the start of Bitcoin, which is too complex to keep an entire index of in Clarity.

You can reference the section in the BIP around location proofs to see an overview of how to prove the current location of a Sat/Inscription.

I really don’t like that using signatures is part of this design - it’s a huge drawback. But, to my knowledge, it’s the only practical way of verifying the location of a specific inscription. If a different/better approach is found, I would completely support it!


Great proposal Hank! I fully support this L2-to-L1 solution and definitely agree that this should be prioritised over BNS v2 considering that we have limited dev resources. I believe providing BNS investors with choice is important and the ability to be able to trade BNS on Ordinals marketplaces will be advantageous and there are certainly more pro’s than con’s to building this bridge. :slightly_smiling_face:

As part of the creation of the inscription creation/burn & locking process, I’m wondering whether it’s possible to be able to take a small fee for the BNS treasury?

This is something that I’m eager (I think most of the Council are in agreeance) to start building up for BNS to help us fund future developments, partnerships, promotion/marketing and other initiatives.


I understand. However, you don’t need to have bi-directional functionality to have L1 liquidity. Look at .sats. names. They have incredible liquidity and no attachment to BNS names.

Furthermore, having an inscription control the ownership of the name is somewhat superfluous and complex. People want to create BNS name inscriptions with as little friction, cost, and complication as possible. Currently, BNS names have plenty of liquidity. Adding another layer to trade names adds complexity, confusion, and cost. It actually will reduce liquidity.

But these are all secondary to the critical flaw - locking names freezes BNS functionality. It breaks apps. It causes issues with sending and receiving STX and Bitcoin. None of these things are worth locking a name to create an Ordinal inscription. You can create an Ordinal inscription without locking names.