Overview
BNS One is the frontend for Bitcoin Name System domain management on the Stacks blockchain. BNS maps human-readable names (like ayden.btc) to Stacks addresses, functioning similarly to ENS on Ethereum but anchored to Bitcoin's security model through Stacks' proof-of-transfer consensus. BNS One provides a single interface where users search for available names, register them, manage their portfolio, and trade on a built-in marketplace powered by the Gamma API.
I built the entire frontend as sole developer through Red Block Labs. The project was funded by the Stacks Foundation, with the client (who goes by Snazzy) handling the grant relationship and product direction. Rocky Nguyen led the engagement on our side, and Christina Vu provided the design work in Figma. The development milestone covered both BNS One and a companion informational site at bns.foundation.
How It Started
The Stacks Foundation funded BNS One through a milestone-based grant. The design phase was completed first, with Christina producing a full Figma for both the app and the BNS community website. Once the design milestone was signed off and paid, the development work began with a clear target: have both projects production-ready before Thanksgiving 2024.
The existing BNS tools were fragmented. Searching for domain availability, registering names, managing renewals, and trading on the secondary market all happened in different places. Most of these tools assumed users already understood Stacks wallet mechanics and transaction flows. Snazzy wanted something that unified these actions into one experience and felt approachable to people who had never interacted with on-chain naming systems before.
Infrastructure and Setup
Before writing any application code, I had to wire up the hosting and services layer. Snazzy created accounts on Cloudflare (for hosting and DDoS protection), Supabase (for the database and user authentication), and Resend (for transactional emails like domain expiration warnings). I connected the domains from GoDaddy, configured the deployment pipeline, and set everything up during a series of calls with Snazzy in November 2024.
"It is generally a bad practice to share passwords through email, especially Google email. I would highly recommend you change the passwords."
I noticed that Snazzy initially shared credentials over email, which I let them know is a security risk. We moved exchanged sensitive information through more secure platforms. It was one of those moments that made us think about how we want to handle operational security throughout our team's projects.
I did not preserve a Cloudflare dashboard screenshot from the 2024 setup calls, but this was the stage where I configured hosting, DNS records, and deployment routing for both domains.
Search and Registration
The search experience is the core interaction on BNS One. Typing a name shows availability, pricing, and expiration status. I built the search to be responsive and informative without overwhelming users who might not understand why a name is unavailable or what a preorder transaction means.
The registration flow handles the multi-step Stacks transaction (preorder followed by register) behind a single visible action. BNS name registration on Stacks requires two separate on-chain transactions with a waiting period between them. I built clear progress indicators for each confirmation stage so users understood that the process was working, even when it took time to settle on-chain.
The Individual Registration Problem
Partway through the QA process, Snazzy raised a critical UX issue: BNS does not support bulk registration or renewal. Each name requires its own on-chain transaction. The original design showed an order summary that implied you could check out multiple names at once, which was technically impossible.
"Each selected name will need to be secured individually. We're unable to bulk register/renew at the moment."
We went back and forth on the solution. Snazzy wanted a "Register" button next to each domain in the cart rather than a single "Proceed to Payment" action. I proposed placing the button below each domain entry rather than cramming it next to the trash icon, which would have been visually cluttered. On success, the button transitions to "Successfully Registered" so users can track which names in their selection have been secured and which still need action.
This was the kind of problem that required me to understand the blockchain constraint before I could design the right interaction pattern. I could not just build what the Figma showed because the Figma assumed functionality that did not exist at the protocol level.
Domain Dashboard
Registered domain owners get a management dashboard showing all their BNS names, expiration dates, linked addresses, and renewal actions. The interface surfaces what matters: is this name about to expire, is it pointed to the right address, does it need renewal. Supabase stores user preferences and notification settings, and Resend handles the expiration warning emails so users do not lose names they forgot about.
Marketplace
The marketplace mirrors functionality from Gamma (the primary NFT marketplace on Stacks) using their API, rendered with the BNS One interface. Users can list their BNS names for sale, browse available names, and complete purchases through on-chain escrow. The listing process walks sellers through pricing and duration, while buyers see a clean catalog with filtering by price, name length, and category.
Integrating the Gamma marketplace API meant BNS One could offer trading functionality without building escrow infrastructure from scratch. The marketplace data stays in sync with Gamma's listings, so anything listed on BNS One is also visible in the broader Stacks NFT ecosystem.
QA and the Final Push
We used Ruttl for the QA process, which let Snazzy leave comments directly on the rendered pages asynchronously. He was thorough. The first pass produced a significant number of comments across both BNS One and the BNS community website, mostly around alignment with the Figma, missing copy, and interaction details that needed polish.
"They're looking great, however they're not quite there yet and I've left quite a lot of comments (apologies) across both projects for you to look into."
The deadline was tight. Snazzy wanted everything complete by November 15 so that a separate developer could start connecting the Clarity smart contract layer and have a production-ready beta by the following Monday. I worked through the Ruttl tickets systematically, closing them as I resolved each issue. Some were simple spacing fixes. Others, like the registration flow redesign, required rethinking the interaction model entirely.
I finished both projects on time. On November 18, Snazzy confirmed completion via GitHub and submitted the milestone to the Stacks Foundation for payment release.
I also no longer have the exact historical screenshot of Snazzy's original comment thread, but this example reflects the same Ruttl-style async review workflow we used throughout QA.
The BNS Community Website
Alongside BNS One, I built the BNS community website at bns.foundation. This was a separate informational site explaining the Bitcoin Name System, the community around it, and how to get involved. The scope was smaller than BNS One but shared the same design system and deployment infrastructure. Both sites lived under the same Cloudflare account and shipped together as part of the development milestone.
Results
Both projects were completed within the November 2024 timeline. The Stacks Foundation released the development milestone funding, Snazzy confirmed receipt, and we transferred the GitHub repositories to the BNSOne organization account. The handover call on November 24 closed out the engagement cleanly.
BNS One shipped as the primary frontend for BNS domain management in the Stacks ecosystem, unifying search, registration, management, and trading into a single application. The companion BNS Foundation site provides the educational context that brings new users into the ecosystem.
What I Learned
This project compressed a lot of infrastructure work into a short timeline. I set up hosting, databases, email services, domain configuration, and deployment pipelines alongside the actual application development, all within a few weeks.
The biggest technical lesson was about building interfaces for blockchain constraints. The individual registration limitation was not something the design anticipated because the designer was working from a user experience perspective, not a protocol limitation perspective. I learned to validate assumptions about on-chain capabilities early rather than discovering them during QA when the deadline is breathing down your neck.
Working with Snazzy also refined how I handle detailed client feedback. His Ruttl comments were specific and high-volume, which is actually the ideal situation. Vague feedback costs more time than thorough feedback, even when the thorough feedback feels overwhelming in the moment. I would rather receive forty precise tickets than five that say "this doesn't feel right."