BNS Upgrade: managed namespace improvements

BNS
#1

This post is part of a larger effort to discuss potential features to be included in an upgraded version of BNS. Please see the megathread for more information.

Proposal: improve functionality for namespaces with custom rules for registration and transfers.

A “managed namespace” refers to a namespace that uses custom logic for determining things like pricing, gated registration, and limitation around transfers.

This would enable functionality like:

  • Requiring registrations to be paid in a token other than STX
  • Setting a different pricing formula than the current length-based formula
  • Gating registration behind rules specified in an external contract

As an example, imagine a hypothetical NFT project called “Bitcoin Dogs” who wants to setup and manage a .dog namespace. The rules for this namespace are:

  • Only owners of a “dog” NFT can register a name
  • Registration fees go directly to the “Bitcoin Dogs” creators
  • If a .dog owner no longer owns any NFTs, their name can be revoked
  • .dog names can only be transferred to other “dog” NFT owners

This proposal would implement functionality to enable this use case.

How this currently works in BNS:

The current BNS contract already includes almost all necessary functionality for this use case, but it requires clever mechanisms to work. The best example is the “community namespace” project. This contract takes advantage of the fact that a namespace owner (the principal that registered the namespace) can update the namespace’s pricing function. To enable custom registration and pricing, the community namespace project implements a flow where:

  • Only approved principals (i.e. contracts) can make registrations
  • During registration, the pricing function is updated so that all names are free
  • The name is registered with no cost
  • The pricing function is updated to be maximally high, preventing “normal” registrations

This setup allows for custom pricing and registration rules, where the registration fee is transerred to a separate address instead of being burnt.

Specific changes:

This proposal would make this type of functionality more explicit, without the need for extra steps to modify a price function. Instead the new BNS contract would include new functionality:

  • Namespace properties to determine if “normal” registrations are allowed (using the current pricing function formula)
  • Namespace properties to specify whether a namespace owner is allowed to call “namespace manager” functions
  • Namespace manager functions:
    • mng-transfer: allow the manager to arbitrarily transfer any name in its namespace
    • mng-burn: allow the manager to burn any name in its namespace
    • mng-register: allow the manager to register a new name in its namespace
    • mng-set-token-uri: allow the namespace manager to set a custom URL for fetching SIP16 metadata for this namespace
    • mng-set-transfers-allowed: specify whether names in this namespace can be transferred by the name owner
      • The mng-transfer method can be used in this instance to set custom rules on transfers
Megathread: BNS upgrade discussion
#2

+1 to making this functionality more specific.

It might be useful to have granular settings for this. Example: Some namespaces might gate registrations but commit to never burning or transfer names.

1 Like