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)
- A user owns a BNS name
- User inscribes an Ordinal
a. They are provided an SVG or image to inscribe - After inscribing, user calls a Stacks contract to lock their name
a. The Stacks contract keeps track of theinscription/nameassociation - 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 - 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:
OP_PUSHBYTES 32
{stxPublicKey}
OP_FALSE
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.
Notes
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.
