Skip to main content

​
Overview

As a Wallet-as-a-Service (WaaS) provider, you can make your product feel simpler and safer by adding ENS subnames. Instead of users dealing with long hexadecimal addresses like 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb, they see friendly names like alice.wallet.eth that work across wallets, apps, and chains. Why this matters:
  • Better UX: Users send money to alice.wallet.eth instead of copying/pasting long addresses
  • Reduced errors: Human-readable names reduce typos and mistaken transactions
  • Brand recognition: Every subname carries your brand (e.g., .wallet.eth)
  • Universal compatibility: Works across 1,000+ wallets, countless apps and multiple chains
  • New revenue stream: Monetize subname creation through tiered developer plans

​
Three Integration Paths

Here are three simple ways to add ENS subnames, depending on your goals:

1. Template/Starter Kit

2. Branded Usernames

3. Ecosystem Wallets

​
1. Template or Starter Kit

Best for: Understanding the integration flow and testing the user experience A simple starter kit that demonstrates how ENS subnames replace hexadecimal wallet addresses in your application. This is the fastest way to experience how subnames work in practice.

​
What You Get

A complete, working example showing:
  • How users create their own subname during onboarding
  • How to replace address displays with human-readable names
  • Reverse resolution: show a subname instead of an address (e.g., alice.wallet.eth instead of 0x742d...0bEb)
  • The complete flow from creation to resolution

​
Technical Approach

We provide ready-to-use starter kits built with popular WaaS providers: This serves as your opening path to experience the complete subname flow before implementing it in your product.

​
2. Branded Usernames with Your ENS Name

Best for: Issuing subnames directly to your users with your brand identity. Give every user a Web3 username that carries your brand. When users onboard, they get a subname like alice.wallet.eth that’s instantly resolvable across all wallets, dapps, and services where your wallet infrastructure is integrated. Example: Like Uniswap usernames (e.g., uni.eth). You can offer your own brand usernames (e.g., alice.wallet.eth).

​
Business Benefits

  • Brand visibility: Every subname reinforces your brand (.wallet.eth appears everywhere)
  • Improved onboarding: Users get a memorable name instead of an address during signup
  • Cross-platform identity: Same username works wherever your service is integrated
  • Monetization opportunity: Create tiered plans limiting subname creation by developers
  • Future-proof: Start with offchain (gasless, instant) and migrate to onchain when needed

​
User Experience Flow

  1. User signs up → Gets wallet address 0x742d...0bEb
  2. During onboarding → User chooses username alice
  3. System creates subname → alice.wallet.eth is issued via API
  4. Username works everywhere → User can send/receive as alice.wallet.eth across all integrated apps

​
Monetization Strategy

You can monetize subname creation by:
  • Free tier: X subnames per developer/month
  • Pro tier: Unlimited subnames
  • Enterprise: Custom limits + support
Control this through your backend—simply track usage and enforce limits before calling the Namespace API.

​
3. Ecosystem or Global Wallets

Best for: Allowing developers to bring their own ENS name and issue subnames to their users Enable developers using your wallet infrastructure to issue subnames with their own ENS name (e.g., happy.brand.eth instead of happy.wallet.eth). This turns subnames into a service you offer, letting developers customize the identity layer for their applications.

​
Business Benefits

  • New product offering: Subname-as-a-Service becomes a core feature
  • Developer retention: Unique identity solution keeps developers on your platform
  • Revenue opportunity: Charge per subname created or through tiered plans
  • Competitive differentiation: Not all WaaS providers offer branded identities
  • Scalable architecture: Same backend, multiple developer brands

​
Use Case Example

A developer building a payment app:
  1. Registers payments.eth as their brand name
  2. Uses your wallet infrastructure for transactions
  3. Issues subnames like alice.payments.eth to their users
  4. Users send money as alice.payments.eth instead of addresses
  5. Brand is visible everywhere: .payments.eth appears across all integrations

Dynamic — Global Identity

See how Dynamic implements global identities for their ecosystem wallets.

​
Same Benefits, Multiple Brands

This approach provides the same benefits as approach #2, but with developer-owned brand names:
  • ✅ Better UX (names instead of addresses)
  • ✅ Reduced transaction errors
  • ✅ Brand visibility (each developer’s .eth name)
  • ✅ Universal compatibility (works everywhere)
  • ✅ Revenue opportunity (charge developers for usage)

​
Next Steps