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: allow a Stacks principal to own more than one name
The current BNS contract requires that any Stacks principal cannot own more than one name at a time. For users that wish to own more than one name, this requirement results in a user experience with more friction. BNS users use various workarounds, including scripts and using multiple addresses, to custody multiple names.
Additionally, the single name requirement adds significant limitations or difficulties to the ability for smart contracts to be built on top of BNS.
There are various arguments in favor of keeping the “one name per address” rule:
Providing a “canonical name”
Only allowing an address to own a single name simplifies the answer to determine what the “canonical name” is for a given address. For apps like wallets, there is a benefit to this simplicity and can result in reduced confusion. When an address owns more than one name, this becomes more complicated.
Counterargument: To preserve the ability to determine a “canonical name” for a given address, a new version of BNS will provide a contract-based mechanism for keeping track of an address’s “primary name”. Addresses with one name will have this set automatically, and addresses with multiple names can call a method to update their primary name. Functionality will be included to automatically update an address’s primary name in the case that the primary name is transferred.
Reducing “name squatting” and other speculative use cases
A separate argument in favor of preserving one-name-per-address is that it makes it harder for speculators and name squatters to buy and own many names. The argument is that such behavior worsens the overall utlity of BNS, because it makes it harder for non-speculative users to own their desired name.
Counterargument: Regardless of arguments about whether speculation is good or not, the truth is that it’s not possible to build an open and permissionless system while preventing this behavior. Many users already utilize many workaround to the one name requirement, and can use tools to automate bulk registration and name management without friction. Apps like Gamma have demonstrated the ability to build marketplaces despite the challenges that the single name requirement adds. Protocols like BNSx further demonstrate the ability for abstractions to work around this requirement.
- SIP issue 37
- (links to other discussions needed)