Skip to main content

Overview

As a Wallet-as-a-Service (WaaS) provider, you can make your product feel more intuitive and safer by integrating ENS subnames. Instead letting users use hexadecimal addresses like 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb, they use friendly usernames 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 hexadecimal addresses.
  • Improved security: When transacting, using human-readable names eliminates address spoofing, hijacking, and other scams.
  • Brand recognition: Every subname carries your brand (e.g., *.wallet.eth), generating millions of impressions across social spaces.
  • Universal compatibility: Works across 1,000+ wallets, countless apps, and multiple chains.
  • New revenue stream: Monetize subname creation through tiered developer plans.

Three Integration Types

There are three simple ways to add ENS subname registrations, depending on your goals:

1. Template or Starter Kit

Best for: Understanding the integration flow and testing the user experience, and quickly seeing how ENS subnames replace wallet addresses in your app.

What You Get

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

Technical Approach

We provide ready-to-use starter kits built with popular WaaS providers:
This integration type 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 to your ecosystem of users and builders with your brand identity. Turn every user into a brand ambassador with personalized Web3 usernames. Use your ENS names as a base (e.g., alice.wallet.eth) and issue human-readable names to users. ENS subnames are instantly resolvable across all wallets, dapps, and services where your wallet infrastructure is integrated. One unified namespace becomes the root identity layer for every user, builder, or integration.

Examples

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 for controlled 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 subnamealice.wallet.eth is issued via API
  4. Works everywhere → User transacts 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.
This integration type is ideal for projects that want to connect their entire ecosystem of apps, wallets, or products under one unified naming system.

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 enables subnames to become a service you offer, allowing developers to 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 pay.eth as their brand name.
  2. Uses your wallet infrastructure for transactions.
  3. Issues subnames like alice.pay.eth to their users.
  4. Users send money as alice.pay.eth instead of addresses.
  5. Brand is visible everywhere: *.pay.eth appears across all integrations.

Same Benefits, Multiple Brands

This type 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