Thanks for raising these concerns, @Babo. If I can attempt to summarize them:
- The use of additional APIs will exacerbate the bugginess of BNS data as provided to wallets and apps alike
- Their use will also incur greater counterparty risk
- By wrapping names in BNSx contracts, apps may accidentally facilitate the transfer of assets to wrapper contracts, where they get “trapped”, by mistaking them for end-user principals
Please let me know if I missed any or didn’t capture these right.
I’m certainly sympathetic to these concerns, though I’m skeptical that they’re dealbreakers for moving forward here with some initial integrations (at least on the Hiro Wallet side).
Per #1, are there other BNS-related bugs that have impacted the Stacks Blockchain API over the past year in addition to the three here you’ve listed? Two of them appear resolved already, with the third reported just this week.
If there were a significantly more – especially ones that have remained unresolved for extended periods of time – I’d also be concerned about the complexity of another API for BNS data.
Per #2, this is true in principle, though Mechanism is a relatively well-known member of the Stacks community so the risk seems low to me in this case, especially if the idea here is that we’ll rely on their API only in the short-term until Hiro integrates the functionality directly into the Stacks Blockchain API.
I’ll check with the API team at Hiro to see just where this functionality factors into their roadmap so we have a better sense of that timing and duration of this risk.
Per #3, do we know of real-world use cases where this could actually happen? In both Hiro Wallet and Xverse, it appears that sends aren’t permitted to contracts in any case (so the BNS lookup feature does indeed break, but no funds are put at risk):
However, granted that such a transfer does end up happening, could the wrapper contract itself could support withdrawals on the part of the name owner of any standardized FTs or NFTs that have been sent to it?
Finally, as far as the “extensive peer review” you mention, do you recommend we follow a particular process or get a particular set of eyes on BNSx?
I’m sympathetic with the idea of moving (relatively) quickly in trying out BNSx and seeing how it performs in real life, since pre-launch discussions around BNS have stagnated historically. And it does seem best that folks try it on for size as an optional enhancement before needing to revoke their BNS (v1) names and commit more fully to BNSx. That way we also avoid the need to choose “either/or” as a community.
However, we certainly want to minimize anywhere things can go wrong, especially if users’ funds could be at risk. So please do continue to pressure test all of this.