Fantastic! This sounds like a viable solution that should work for all.
1 Like
Hey. I know we are in the final stages, but wanted to flag a potentially big issue.
My current understandng is that the fee structure on v2 replicates that on v1 - i.e. fixed pricing in stx.
This presents a problem as stacks adoption grows and token price increases. 2 stx per .btc can quickly become unaffordable to most, and dont get me started on .id pricing in that scenario.
ENS marks pricing to the dollar at any one time and so remains agnostic of token price. This is a lot better as a solution to changes in the crypto token price.
Was this considered? Is there scope to make a change? I think its a fairly big issue as with the current model success for the stacks token arguably creates a fall off in adoption for BNS names. The two should rise together.
2 Likes
Hey! I can definitely see your concern, but we want to keep the pricing just as it is on V1, the good thing is that for managed namespaces pricing is 100% editable.
For unmanaged namespaces remember that the designated import address can modify the pricing function to be in line with market needs
3 Likes
the designated import addresses are contraled by BNS core multisigs？
Thanks, can you expand on that second paragraph? I don’t follow.
Also, is the pricing for .locker set yet?
1 Like
I am the holder of . ordinals namespace, this name space are controlled by a multiplesig contract, what will happen to the . ordinals namespace when V2 deployed? Can i provide a EOA address to get the V2 namespace authority
Do I understand correctly that the pricing for renewal of BNS names can be changed to meet the needs of the market for all V2 BNS namespaces?
not namespaces that existed on V1. So .btc, .id etc remain on fixed pricing as they were. New namespaces can be managed on V2, but I believe pricing can be set at registration, but is then locked. Happy to be corrected there.
Even if it can be changed periodically, it cannot be marked to the dollar such that it always costs the same to register/renew in USD terms.
1 Like
Re: new managed namespaces
The price isn’t strictly locked! With the managed namespace contract you can make both registration & renewal prices variables if you’d like, or, If the managed namespace contract has a call into ‘mng-manager-transfer’ then an updated manager contract would also change the pricing.
You’re right in that we can’t mark stx to the dollar, but you can just charge in a stablecoin for example.
2 Likes
Very interesting - thanks
1 Like
Hey ya’ll! Coming with an unfortunate update from me & @setpato:
On Thursday, September 26th afternoon, an issue was found with the BNS V2 airdrop’s airdrop format.
To dive into the technicals, an issue was inadvertently introduced as a result of preserving the v1 name details for each v2 name. Specifically, we maintained the exact value for the ‘renewal-height’ property.
Previously, this renewal-height was checked against the Stacks chain height. For BNS V2, this check was updated against the Bitcoin / ‘burn-chain height’ to align name registration timing and expiration with the upcoming Nakamoto upgrade.
Why? During the migration, the existing ‘renewal-height’ field for each name was not properly overwritten. Each name still pointed to a Stacks block-height, not Bitcoin/burn-chain. This meant that upon the migration completion, every name would have already expired (creating all sorts of cascading issues). Thankfully, we discovered this while testing out the BNSv2 SDK - when names unexpectedly came back as expired.
Again, this is an issue for the renewal-heights for the airdrops. This was not a bug in the BNS V2 contract itself.
When we realized that this could negatively affect users, we stopped the airdrop migration in progress to re-start and ensure a smooth delivery of BNS names to all users. The final BNS V2 smart contract and wallet address distribution of the names has changed.
As a result, the final BNS v2 smart contract and wallet address distribution of the names has changed.
New address: SP2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D96YPGZF.BNS-V2
What you need to do – while you may see an extra, blank NFT in your wallet, there is no action required to receive your BNS V2 name. Simply disregard any names already airdropped.
The Trust Machines & SetDev team are working diligently to remedy this and appreciates the community’s understanding.
TL;DR: The BNS v2 airdrop will take a bit (approx. one week) longer than anticipated but is in progress to ensure smooth delivery to all BNS users.
2 Likes
what happens if someone minted a name on v1 during the upgrade to v2?
I found on gamma an interesting one that was minted 12 days ago… seems like in that wallet there was no v2 airdrop… will be this name available on v2 or you will airdrop the names purchased during this period too?
The transaction would fail. During the airdrop the contract is in “migration mode” and no new names can be registered.
Although the airdrop looks finished now, the contract status has not yet been switched. I believe the team is still running through some tests first. Until it is updated you also can’t transfer names yet via the BNSv2 contract.
I am sure an update will be posted here soon.
1 Like
if you check the logs of the name-registar contract you will find that a lot of name-register functions was confirmed… but maybe I’m wrong https://explorer.hiro.so/txid/SP1JTCR202ECC6333N7ZXD7MK7E3ZTEEE1MJ73C60.name-registrar?chain=mainnet
This contract is calling BNSv1 to register names. They will not be airdropped with the migration because they are registered after the snapshot window. If users want to register those in BNSv2 they’ll have to do so when the option becomes available.
This is the contract address for BNSv2:
SP2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D96YPGZF.BNS-V2
Thanks for the clarification! But still don’t understand how it was possible if the contract was paused.
Haven’t counted them but there is about a 50% success rate.
I confirm the name was available on v2
I just become the first minter on the new contract.
864864.btc in my wallet 
1 Like
Sorry for the delay. The BNSv1 contract can’t be pauzed. Some of the decentralized apps have simply stopped their UI from working while the upgrade was ongoing. The contract can still be called directly or with dapps that did not go into maintenance mode.
BNSv2 couldn’t used to register names until after the airdrop was finished, there was a switch in the contract. Now it can’t be turned off though. There are special managed namespaces that have different rules but the .btc namespace can be used permissionlessly now too.
1 Like
Hi @Werner1 thanks for replying.
I have another question about v2. I’m trying to build a small tool to bulk register/listing domains, but it will not work bc of the contract-caller principal switching to my contract address when I call the functions.
In the v1 you had only one domain per wallet, so it make sense, but actually with more nfts in a wallet there is a need to iterate trough bulk actions.
The only solution I can find is to create a custodial marketplace with built-in bulk functions, but I believe is not the best in terms of consensus.
I deployed a contract to bridge stx20 stxmap to nft and I exposed all the public functions as bulk functions too, folding a list of token ids into single actions (list, buy, transfer etc)
There is some workaround to achieve the same goal with the actual BNS-v2 contract or the only way is the custodial marketplace?
Do you think that leveraging the in-app stacking wallet (the wallet created by your private key and the website key) could be a valid workaround to have seamless bulk actions (at least up to 27x)?
I appreciate all your suggestions 
Eriq