SNS and Bonfida: history of .sol naming and where SNS goes next

SNS (Solana Name Service) is how Solana turns wallet strings into human names ending in .sol. Bonfida is the organization and open-source surface that created and still maintains much of that stack. If you only know “type alice.sol in Phantom,” this piece is the history under that UX — and the forward path after rebrand, V2 product, and the $SNS community token.

Sites: sns.id (V2) · v1.sns.id · bonfida.org. Docs: docs.sns.id. Technical resolution deep-dive already on DevRels: SNS registry program and how .sol resolves.

Click to zoom

Thesis

Naming on Solana started as infrastructure work (a hierarchical name program + registration UX). Over time the product brand consolidated around SNS and the .sol community, while Bonfida remains the historical and engineering root. The “future of SNS” is less a new chain primitive and more: community alignment ($SNS), broader identity utility (records, Web2 via sol.site, agents), and keeping resolution boringly reliable for every wallet and dapp.

Timeline (condensed)

Messari and similar research short-hands often say “SNS, formerly Bonfida” for the project identity. For engineers, keep both names: Bonfida org/repos/SDK paths still appear in dependency trees; users live on sns.id.

What Bonfida built (the technical inheritance)

The lasting technical contribution is the name registry model on Solana:

• A Name Service program that stores name records as accounts (PDAs derived from a hash of the label plus class/parent) — deterministic lookup, no centralized DNS for on-chain resolution.
• .sol-specific registration and marketplace flows on top of that primitive.
• Client libraries and guides so wallets resolve name.sol → pubkey and reverse lookups without inventing their own registry.
• Adjacent experiments: name tokenization, batch resolvers, widgets, Twitter/X handle association docs, cross-chain bridge experiments.

// conceptual — see DevRels technical article for full resolution
hash = SHA-256("SPL Name Service" || label)
PDA  = find_program_address([hash, class, parent], NameServiceProgram)
// record holds owner + data (SOL address, IPFS, text, …)

That design is why .sol feels like “just works” infrastructure: once a wallet integrates the SDK (or equivalent RPC helpers), every registered name is the same shape of account read.

What SNS is now (product surface)

Live homepage counters (holders, registrations, partners) move constantly — treat the site as source of truth, not this article’s snapshot.

$SNS: why a new token

Official FAQ framing: after ambitious early plans, pivots, rebrand, and leadership change, .sol holders remained. $SNS is positioned as a community token by .sol holders for .sol holders — aligning future SNS decisions with frequent users rather than only a small contributor set.

Bonfida’s “Welcoming a New Era” post (May 2025) is the narrative bridge: $SNS as cleaner foundation purpose-built for today’s .sol community after the project’s highs and lows since ~2020.

Future of SNS (builder-relevant, not price talk)

Stripped of hype, the forward path that actually changes integration work:

What is not a sober “future” claim: that SNS replaces all other identity systems, or that $SNS mechanics alone guarantee adoption. Naming wins when resolution is ubiquitous and names are cheap enough to experiment with — both are product and ecosystem problems.

Practical guidance for builders

How this pairs with the technical article

• SNS: registry program and how .sol resolves — PDAs, headers, code paths.
• This article — institutional history, brand shift, token/community layer, product roadmap context for product managers and integrators.

Resources

• sns.id · docs · $SNS tokenomics · whitepaper PDF
• bonfida.org · GitHub org Bonfida (SDK and tools)
• sol.site docs
• SNS on DevRels

Bottom line

Bonfida wrote Solana’s naming chapter into the chain; SNS is how that chapter is branded, governed, and productized for the next stretch — community token, V2 surfaces, Web2 bridges, and agent-ready identity. Builders should keep resolving .sol as core UX infrastructure, track records/sol.site/agent APIs as the expansion set, and treat $SNS as the coordination layer for the .sol community rather than a substitute for solid resolution code.