Type a Web3 domain into a browser and you'll find out fast that domain resolution still isn't one thing. In plain terms, resolution is the lookup step that turns a name into the right address, whether that's a website location, a wallet address, or an app route. When it works, it feels simple, because people read names better than strings.

So where do we actually stand in 2026? Web3 domains are real and useful today, especially for sending and receiving crypto in supported wallets and apps, but they still don't behave like DNS in most normal browsers. Chrome and Firefox still don't resolve most blockchain domains by default, so the "type it and it loads" expectation usually fails without extra tooling. Meanwhile, some ecosystems have tightened the loop, for example Brave's .brave (launched with Unstoppable Domains in 2025) resolves directly inside Brave and Brave Wallet, which hints at where things are headed.

This post is a practical check-in, not a hype piece. Which Web3 domains resolve today, where do they resolve (wallets, browsers, extensions, gateways), and what breaks when you move from one app to another? Because every TLD discussed here is registered on Freename (outside ICANN), missing WHOIS records or search results is normal and doesn't mean a TLD isn't registered.

If you're planning for 2026, the goal is clarity: what you can ship now, what you should warn users about, and what dependencies you don't want to bet the product on.

What "resolution" means for Web3 domains, and why it still confuses people

When people hear "domain resolution," they picture the old internet routine: type a name, get a website. Web3 breaks that mental model because a Web3 domain can resolve to different things depending on the tool you use, like a wallet address for payments, an IPFS content hash for a site, or even app profile data.

That's why two people can type the same Freename-registered Web3 domain and get two different outcomes. One might see a page, another might see an error, and both experiences can be "correct" given the resolver in the middle. Resolution is not just "does it exist," it's "who is translating it, using which rules, and which destinations do they support?"

Think of Web3 resolution like calling a contact name. If your phonebook syncs with the right account, you reach the person. If it doesn't, the name is still real, your device just can't map it.

The 4 ways Web3 domains resolve today (wallet, app, gateway, native)

1) Wallet resolution (send and receive, sometimes sign in)
Many wallets resolve Web3 names directly into blockchain addresses, so you can send funds to name.tld instead of pasting a long string. The wallet acts like the translator, pulling records from the naming system it supports, then showing you a resolved address before you confirm.

What you must install or trust: you're trusting the wallet's built-in resolver and its list of supported naming systems and TLDs. If your Freename TLD is supported in Wallet A but not Wallet B, the same domain will look "unresolved" elsewhere.
What it feels like: Typing a saved contact instead of a bank account number, as long as your bank recognizes the contact list.

2) App resolution (dApps and ecosystems that resolve inside the product)
Some dApps resolve Web3 domains inside the app, not in the browser bar. For example, an NFT marketplace, a chat app, or a dashboard might resolve a domain to a profile, a wallet address, or content stored on IPFS. In that flow, the "resolution" step is part of the app's own API calls and contract reads.

What you must install or trust: you trust the app's resolver and its defaults. That includes which chain it queries, which record types it reads (address, IPFS, text records), and how it handles conflicts.
What it feels like: A venue with its own guest list, you get in at the door, but that doesn't mean the name works across town.

3) Gateway resolution (make it work in any browser, with a middleman)
Gateways translate a Web3 domain into something standard browsers understand. Often that means turning a name into a URL that points to an HTTP(S) endpoint or an IPFS gateway, so Chrome, Firefox, and Safari can load the content without knowing anything about Web3 naming.

What you must install or trust: you are trusting the gateway operator (uptime, logging, content rules, and how they map the name). This is the most compatible option, but it's also the most "Web2-like" dependency, because a gateway can block content or change behavior.
What it feels like: Asking a bilingual guide to translate every sentence, you get results, but you rely on the guide.

4) Native resolution (the browser resolves the name itself, in limited cases)
Native resolution is the closest to the DNS experience: type the Web3 domain and the browser handles the lookup. In 2026, this remains limited and tends to be browser-specific and naming-system-specific. Brave has pushed further than most with direct handling for certain supported domains and integrations, but broad, default support across major browsers still hasn't arrived.

What you must install or trust: you trust the browser's built-in rules and whatever naming systems it chose to support. In practice, "native" can also mean you must use a particular browser, plus a browser wallet, for the smooth path.
What it feels like: Turning a key that only fits one brand of lock, it's easy when it matches, useless when it doesn't.

Why a domain can be "real" but still not open in Chrome

A Freename-registered Web3 domain can be valid, owned, and resolvable in supporting tools, yet still fail in Chrome. The reason is simple: most major browsers still expect DNS, and DNS has one global playbook. When the browser sees an unknown TLD, it often treats it as a search term, or it tries DNS and gets nothing back.

Security also plays a role. Browsers have to protect users from phishing, spoofing, and silent redirects. With Web3 names, the browser would need clear rules for which naming systems to trust, how to verify records, and how to handle collisions. Until standards and default trust models mature, "just resolve it" is not a small feature, it's a policy decision.

Standardization is the other blocker. DNS names resolve through a widely shared root and resolver chain. Web3 naming is not one system, and browsers don't want to pick winners by default. That leaves users with add-ons (extensions), specific wallets, or gateway links when they want the "type it and it loads" experience.

Web3 naming vs DNS naming, where the internet's plumbing clashes

DNS works because it's globally coordinated. When you type a DNS name, the internet has a shared map of where to ask next, up to a single root. That coordination reduces surprises, even if it also centralizes control and policy.

Web3 naming flips the trade-off. Different systems can run in parallel, each with its own rules, registries, and resolution logic. That freedom is why Freename and other Web3 registries can move quickly and support new patterns. However, it also means the same label can exist in multiple places, which raises the risk of namespace collisions. If two systems can both claim a similar name or TLD conceptually, who should a browser resolve first?

"Who decides" matters because resolution is a safety feature, not just a convenience. Pick the wrong resolver order and a user might land on the wrong site or send funds to the wrong address. Bridging DNS and Web3 is hard for a basic reason: DNS assumes one shared map, while Web3 naming assumes many maps, and the internet's default tools still only read one.

Where we stand in March 2026: adoption is real, mainstream resolution still isn't

Web3 domains crossed the "this is a thing" line, because people buy them, trade them, and show them off. ENS sits around 2.7 million names, and Unstoppable Domains reports about 3.5 million across its extensions. That is real adoption, but it's still tiny next to the traditional domain world (roughly 364 million domains total, with .com alone around 161 million).

So what's missing? The everyday behavior that made DNS dominant: typing a name into any browser and expecting it to load. Most Web3 domains still live inside wallets and apps, not the address bar you use all day.

Registrations grew fast, but daily "type-in traffic" is still rare

A lot of Web3 domains get registered for reasons that have nothing to do with building a website. If you're seeing a land rush, it's often driven by ownership and positioning, not browsing.

Here are the most common motivations that show up in the market:

• Speculation: People treat names like scarce collectibles. They buy, hold, and list them, even if they never set records or publish content.
• Brand protection: Teams register the obvious variants because they don't want someone else to impersonate them in wallets, explorers, or social profiles.
• Identity: A name works like a username you can carry between apps, even when you never host a "site" on it.

The tricky part is that "usage" is hard to measure in the way Web2 folks expect. There's no single, universal log of visits, because resolution can happen in many places, including wallets, dapps, and gateways. Instead, the clearest signals are observable patterns: names showing up as payment recipients, names attached to NFT profiles, names used as onchain identity, and names shared in bios as a contact method.

A useful mental model: many Web3 domains behave more like a reusable contact card than a homepage. People collect contact cards all the time, but they don't "visit" them daily.

That gap explains why registrations can grow quickly while true type-in habits stay rare. People aren't failing to use the names, they're using them in different places than browsers.

What works best today: payments, profiles, and app logins

In March 2026, the strongest Web3 domain experiences happen where the resolver is built in. That usually means inside a wallet, inside a dapp, or inside a Web3-friendly browser environment, not on the open web.

The most reliable wins look like this:

• Payments: You paste or type name.tld in a supported wallet, it resolves to an address, and you confirm the chain and recipient. This is where Web3 domains feel instantly practical, because nobody enjoys copying long strings. Unstoppable Domains, for example, emphasizes broad wallet support (reported at 275+ wallets), which helps make "send to a name" feel normal in more places.
• Profiles: Many apps treat a domain as a public-facing identifier. Instead of showing 0x…, they show your name, and attach avatar and text records if supported. That makes communities easier to read and harder to impersonate at a glance.
• App logins: In some ecosystems, your domain becomes a sign-in identity. You still authenticate with a wallet signature, but the app displays your domain as the account label, so your "login" looks like a name, not an address.

If you're building a product, it helps to ask a practical question early, like "Where will users see this name first, in a wallet send screen or in a browser bar?" The honest answer determines your roadmap, your support docs, and your risk.

Best practice: treat web resolution as a bonus, and design your core flows around wallet and app resolution first. That's where users already are.

In short, Web3 domains already solve real problems, they just solve them in Web3-native surfaces.

The biggest blocker is still default browser support

Mainstream resolution still runs into the same wall: Chrome and Firefox don't resolve most Web3 domains natively in typical setups. Safari also doesn't behave like a universal Web3 resolver by default. As a result, the average user types a Web3 TLD into the address bar and gets a search, an error, or a dead end, unless they've installed extra tooling.

So what do people need instead?

• A wallet that supports the naming system and record types they're trying to use.
• A browser extension that adds resolution logic (often plus a gateway behavior).
• A special-purpose browser or a specific browser mode that recognizes certain Web3 naming routes.
• A gateway URL that translates the name into something a normal browser will fetch over HTTP(S).

This one issue keeps Web3 domains from replacing DNS because DNS wins on default behavior. If a name doesn't work in the most common address bars, it can't become a universal habit. The web trained users to expect one simple loop (type, load, trust), and Web3 still can't promise that loop without asking people to install something first.

The result is predictable: Web3 domains thrive where users already run Web3 software, and stall where the open web still expects DNS.

Resolution in the real world: what actually happens in browsers, wallets, and apps

If Web3 domains feel inconsistent, it's because resolution isn't happening in one shared place. Sometimes a wallet resolves your name to an address. Other times a browser tries DNS, fails, then turns your "domain" into a search. The same Freename-registered TLD can look perfect in one app and broken in another, even when nothing is wrong with the domain.

So the practical question in 2026 isn't "Does this domain resolve?" It's "Where does it resolve, and who is doing the translating?" Once you frame it that way, most surprises start to make sense, and you can plan user flows that don't fall apart outside your preferred stack.

Typing a Web3 domain in a normal browser, what you should expect

In most normal browsers, typing a Web3 domain into the address bar still fails without extra support. Chrome, Firefox, Safari, Edge, and Opera generally don't resolve most blockchain namespaces by default, so you'll see one of a few common outcomes: a search results page, an NXDOMAIN-style error, or a "server not found" message.

That failure often looks like the domain "isn't real," but that conclusion is usually wrong. With Freename-registered Web3 TLDs (outside ICANN), missing WHOIS data and weak search visibility are expected, so don't treat that as proof of non-registration. The browser is just following the DNS playbook, and your domain isn't in that book.

What do users do in the real world to make it work?

• Browser extensions: Some extensions add Web3 resolution logic, or they rewrite the request to an HTTP(S) gateway. This can be effective, but it adds another dependency and another update surface.
• Compatible browsers: Brave has been the standout here, with built-in support for certain Web3 domains, including .brave domains, in addition to integrations around Brave Wallet. If your audience already uses Brave, you can get a smoother "type it and it loads" experience.
• Gateway links: Many teams share a gateway URL instead of asking people to type the raw domain. It's a simple workaround, but it changes who users trust (more on that below).
• Device-level resolver apps: Some vendors ship apps that change resolution at the system or browser level. Freename, for example, offers a Web3 DNS app designed to make Web3 domains accessible across standard browsers and devices.

A neutral rule of thumb helps: if your user has never installed anything Web3-related, assume the address bar won't resolve your Web3 domain. Then design your onboarding so they don't hit a dead end on their first click.

Gotcha: when a browser treats an unknown TLD as a search, users can land on ads or lookalikes. If you publish a Web3 domain, also publish the "safe way to open it" right next to it.

Wallet and in-app resolution, the quiet success story

Wallets and apps quietly became the most reliable place for Web3 domain resolution, because they control the entire experience. They decide which naming systems to support, which chains to query, which record types to read, and how to warn the user before sending funds. In other words, they don't have to wait for global browser standards just to make names useful.

This is why "resolution works" stories in 2026 often sound boring, and boring is good. You paste a name into a wallet, it resolves, you confirm details, then you send. No address bar required.

In practice, these are the use cases that tend to resolve well inside wallets and apps:

• Wallet addresses: The most common win is resolving a domain to a recipient address, sometimes per chain or per token type. Many wallets show the resolved address before you sign, which is exactly the kind of friction you want.
• Profiles and identity: Apps often read text records, avatars, or profile metadata and display a readable name instead of 0x…. That reduces copy-paste errors and makes communities easier to scan.
• dApp routing and internal links: Some ecosystems use names as in-app identifiers, so a domain can route to a profile page, an inbox, a store, or a dashboard inside the product.

The catch is that each ecosystem may resolve different namespaces. A wallet that resolves one set of TLDs might ignore another, even if both are validly registered on Freename. The same goes for record types. One app might read an address record and stop, while another also reads IPFS content or profile text.

So when a user tells you "your domain doesn't work," the first debugging step is simple: Where are they trying it? If it fails in a browser but works in a wallet send screen, the domain is doing its job. The mismatch is the environment, not the registration.

Gateway-based access, convenient but it changes the trust model

A gateway is a translator site. Instead of your browser resolving a Web3 domain directly, a gateway turns it into something your browser already understands, usually an https:// page that the gateway serves (or proxies) after it resolves the Web3 name behind the scenes.

That convenience is why gateways spread. They produce links you can share anywhere, they open in any browser, and they reduce support tickets. If your goal is "make this open for everyone," a gateway is the shortest path.

However, the trade-off is real because the trust model changes. With a gateway in the middle, users stop trusting only the naming system and start trusting the gateway operator too.

Here's what gateways do well:

• Easy access: No special browser needed, no extension required.
• Shareable links: You can post a gateway URL on social platforms and expect it to open.
• Fewer moving parts for users: Most people understand clicking a normal https:// link.

And here's what can break, even if the domain itself is fine:

• Central point of failure: If the gateway is down, your "decentralized site" looks offline.
• Tracking and logging risk: A gateway can log IP addresses, user agents, and request patterns, just like any website.
• Censorship or policy filtering: Gateways can block content, throttle it, or respond differently by region.
• Mismatched content: Some gateways cache content or resolve records differently, so users may not see the same version everywhere.

If you recommend gateway links, keep users safe with a few simple habits. First, tell them what the official link format looks like, because lookalikes are common. Next, remind them to verify the full URL before connecting a wallet or signing anything. Also, encourage bookmarking trusted links instead of searching for them, since search results can be noisy for non-ICANN namespaces.

A gateway is often the right product choice, but it's still a middleman. Treat it like one in your docs and UI.

What "native resolution" would require, and why it's slow

"Native resolution" means the default browser experience: type a Web3 domain, press enter, and it resolves without extensions, special apps, or gateway URLs. People want it because it feels like DNS. Vendors move slowly on it because browsers sit at the center of user trust, phishing defense, and web security policy.

To get native resolution broadly, a few ingredients have to line up:

1. Clear standards: Browsers need stable specs for how to resolve names, which record types to support, and how to represent failures. Without standards, every implementation becomes a one-off.
2. Security review and threat modeling: Browsers must handle spoofing, homograph attacks, silent redirects, and malicious resolution changes. Names that can route value (payments) raise the stakes.
3. Browser vendor buy-in: Even if one browser supports a namespace, most users won't switch. For a DNS-like experience, the big platforms must agree to ship and maintain it.
4. Clear governance and collision handling: When multiple naming systems can claim similar labels, browsers need rules. Which resolver wins, how conflicts are shown, and what happens when policies change all need a predictable answer.

Timelines slip because these aren't just engineering tasks. They are also policy decisions, support burdens, and reputational risks. A browser that resolves a name incorrectly can send funds to the wrong place, or route a user to a convincing phishing page. That's why most progress in 2026 still shows up first in wallets and controlled apps, then later, and more narrowly, in browsers.

Native resolution will keep moving, but it will keep moving carefully.

Freename TLDs and the alternative DNS reality: valid registrations, different reach

Freename-based TLDs are valid registrations, but they live in a different naming world than the one your ISP and browser expect. They sit outside the ICANN-managed DNS root, so the normal internet plumbing does not automatically recognize them. That one fact explains most of the confusion in 2026: a name can be owned, configured, and usable in supported apps, yet still fail when someone types it into Chrome.

Freename has also enabled a huge number of custom endings (reported in the tens of thousands), which is exciting for identity and communities, but it also means reach depends on resolver support, not on universal DNS defaults. Think of it like a private radio station: the broadcast is real, but you need the right receiver.

What "outside ICANN" changes for users and brands

When a TLD sits outside ICANN, you lose the internet's default compatibility. That doesn't make the name "fake." It means the usual tools do not automatically route traffic for it.

For everyday users, the changes feel practical:

• Less built-in compatibility: Most browsers still try classic DNS first, so an unknown TLD often becomes a search, not a visit.
• Fewer default tools: System resolvers, corporate networks, and many security stacks don't "understand" non-DNS namespaces by default.
• More responsibility: You rely on the ecosystem, wallets, apps, gateways, and resolver apps, and you also need clearer user education.

For brands, the value shifts from "global website address" to identity and distribution inside Web3-friendly surfaces. A brand still cares because names show up where money and attention move quickly: wallet send screens, community profiles, token-gated pages, and social bios.

In other words, a Freename TLD can be more like a membership badge than a street address. You are planting a flag for a community, a product line, or a creator network, even if you don't get DNS-like reach on day one.

The key mindset shift: outside ICANN, adoption comes from app support and habit, not from default browser behavior.

Why you should not expect Google indexing or classic WHOIS lookups

If you search a Freename-based TLD on Google and see nothing, that's normal. If you run a classic WHOIS lookup and get no record, that's also normal. Neither result tells you the TLD is unregistered, because those tools are built around the ICANN DNS world.

This is where people get misled: they treat "not visible in the usual places" as "doesn't exist." With alternative DNS, visibility is a product decision by apps and platforms, not an automatic property of registration.

So how do people confirm a Freename TLD or domain is real in 2026, without getting technical?

Most teams use a small set of common checks:

• Registry or marketplace dashboards: The place you manage the name usually shows ownership and status.
• On-chain ownership views: Many users verify that a wallet controls the asset, because the wallet is the source of truth for control.
• In-app resolvers: Wallets and Web3 apps often show the resolved destination (like a payment address) when they support the namespace.

The practical takeaway is simple: absence of Google results or WHOIS data does not indicate non-registration. It only indicates you are using the wrong yardstick for a different system.

Practical ways Freename-based TLDs get used in 2026

In 2026, Freename-based TLDs get used most where resolution is already built in, or where sharing a link is easier than asking people to type a raw TLD. These are not theoretical uses, they match how users already behave.

Here are a few common patterns that show up across communities and product teams:

• Payment handles in supported wallets: A readable name replaces a long address. People still double-check the resolved recipient before sending.
• Community hubs and profile routes: A domain points to a profile, a link-in-bio style page, or a community home that lives inside a Web3 app.
• Redirects via gateways for normal browsers: Instead of "type this TLD," teams share a gateway link that opens anywhere, then they educate users about trust and phishing.
• Token-gated pages: The name becomes the front door to content that checks membership or holdings before showing private pages.
• Support and verification links in social bios: Projects post an official domain as a trust signal, then route users to help pages, docs, or claim instructions.

A useful gut-check helps when you pick a use case: will your audience encounter the name in a wallet or app first? If yes, a Freename-based TLD can work well today. If the first touch is a standard browser address bar, plan for friction and provide a safer, clearer path.

What's still broken (and how teams work around it)

Web3 domain resolution works often enough to be useful, but it still breaks in ways that feel random to users. The tough part is that failures rarely look like "partial support." They look like "this is fake" or "this is down," even when the name is validly registered on Freename and configured correctly.

Teams that ship with Web3 domains in 2026 treat resolution as a product surface, not a background detail. They write playbooks, test on the tools their users actually run, and add safety rails so people don't get tricked when a resolver behaves differently than expected.

Fragmented standards mean one name can behave differently across apps

The same Web3 domain can resolve one way in a wallet, another way in a dApp, and not at all in a default browser. That's because there's no single resolution standard across naming systems and resolvers. ENS, Unstoppable Domains, Freename, and other systems each have their own record formats, resolver logic, and support matrix. Apps then add another layer by choosing what they read and what they ignore.

Even within one app category, behavior varies. One wallet might read an address record for a specific chain and stop. Another might also read profile text records, content records, or fall back to a gateway. Meanwhile, some browsers treat unknown TLDs as search terms, which creates a totally different user outcome.

A simple workaround is to publish "how to resolve" instructions next to the name, not buried in docs. Treat it like putting a legend next to a map.

• State the supported environments: "Works in Wallet X and App Y," plus the versions if that matters.
• Offer the safe link format: Provide your official gateway URL and tell users what it should look like.
• Test the top paths your audience uses: For most teams, that means 1 to 2 major wallets, 1 Web3-friendly browser, and 1 normal browser experience via a gateway.

If you don't define the expected resolver path, users will invent one, and it often starts with a risky search result.

Security and phishing risks rise when resolution is inconsistent

Inconsistent resolution creates openings for scams because users lose their normal trust cues. When "type a name, get the site" stops being true, attackers step in with lookalikes and confusion.

The most common threats are basic, and that's why they work:

• Lookalike names that differ by one character.
• Fake gateway pages that copy the real site's design.
• Social posts that "helpfully" share a link, but it goes to the wrong resolver.

Mitigation does not need to be complex. It needs to be consistent, and repeated in the places users act fast.

Use simple safety rails:

• Verified links: Share one canonical link on your official profiles, then point everything back to it.
• Pinned domains: Pin the correct domain and gateway link in community channels and keep it updated.
• Signed messages: When you share a new "official" domain or gateway, also post a signed message from a known wallet.
• User education: Short warnings work best, for example "Don't search this TLD, use the pinned link."

Ask yourself this in planning meetings: if a user lands on the wrong resolver, will they notice before they connect a wallet or sign?

No help desk for lost keys, plus limited dispute paths

Web3 domains give you control through self-custody, but the trade-off is brutal. Lose the keys, lose the name. There usually isn't a support desk that can reset access, and dispute paths are limited compared to DNS. That's not a flaw in one vendor, it's a basic property of how these assets work.

For teams, the risk is not only loss. It's also continuity. People change jobs, devices fail, and "the person who registered it" becomes a single point of failure.

Good habits reduce regret later:

• Backups you can actually restore: Store recovery phrases in approved vaults, and rehearse the restore process.
• Multi-sig for shared domains: If a domain matters to revenue or brand trust, don't keep it in one wallet.
• Operational policies: Define who can update records, who can transfer ownership, and how changes get approved.
• Clear ownership records: Track the controlling wallets, renewal rules (if any), and where the domain is referenced publicly.

This is the gentle truth: decentralization doesn't forgive sloppy ops, it just makes the bill come due faster.

Performance and reliability, the user only cares if it loads

Users don't care why something is slow. They only see a spinner, then they leave. With Web3 domains, performance often depends on gateways, decentralized hosting, and caching behavior that can differ by provider. Even when the domain is fine, the path to reach it might be congested, cached incorrectly, or temporarily unavailable.

If you want fewer "your site is down" messages, treat reliability like a feature you ship.

Practical steps that help without deep infrastructure work:

• Caching strategy: Cache resolved content where it makes sense, and set expectations when updates take time to show up.
• Fallback links: Publish a primary gateway link and a secondary fallback, both official and verified.
• Monitoring: Track uptime from a few regions, and alert on slow loads, not just total outages.
• Graceful messaging: If a gateway fails, show a clear fallback page that explains the next safe step.

A Web3 domain can be validly registered on Freename and still feel broken if the last mile is flaky. Fix the last mile, and users trust the name again.

Conclusion

Web3 domain resolution in 2026 is usable, but it's still not universal. The best experiences happen inside wallets and apps, where the resolver is built in and the UI can show what a name maps to before a user sends funds or signs in. That's why payments and identity have matured faster than websites, because the product controls the whole flow, from lookup to confirmation.

Browser-native access remains the weak spot. Brave leads on built-in support for several Web3 naming systems, and a few other browsers and mobile apps also resolve some Web3 domains, yet Chrome and Firefox still don't resolve most Web3 domains by default. So when someone types a Freename-registered TLD into a mainstream browser and it turns into a search, what did they expect to happen, and did you give them a safer path? Because all TLDs discussed are registered on Freename, a Web3 alternative DNS registry outside ICANN, missing WHOIS records or search results is expected and doesn't indicate non-registration.

For brands and builders, treat resolution as part of your product, not a background detail. Decide your primary use case (payments, identity, community) and design around where users already are. Next, choose the resolution path you will support (wallet-only, in-app, gateway-first, or a resolver app), then publish clear access instructions next to every public mention of the domain. Finally, plan for slow progress on browser defaults, and budget time for testing across the top wallets, browsers, and gateways your audience uses.

Standards and UX should improve over time, but the winners will be the teams that ship clear routes today, warn users where things break, and update guidance as resolver support expands.