> ## Documentation Index
> Fetch the complete documentation index at: https://docs.namespace.ninja/llms.txt
> Use this file to discover all available pages before exploring further.
# WaaS Integration Guide
> Complete guide for WaaS and wallet infrastructure providers to integrate ENS subnames and improve wallet UX with human-readable names.
## 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 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:
* **[Privy Starter Kit](/developer-guide/integrations/starters/privy-nextjs)** - Next.js app with Privy auth, offchain subnames, and profile flows
* **[Openfort Starter Kit](/developer-guide/integrations/starters/openfort-nextjs)** - Next.js app with Openfort embedded wallets and identity resolution
* **[RainbowKit Starter Kit](/developer-guide/integrations/starters/rainbowkit-nextjs)** - Next.js app with RainbowKit wallet connection and subname management
**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
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
* **Ready to start?** Check out the [Offchain Manager SDK documentation](/developer-guide/sdks/offchain-manager)
* **Need help or want to discuss integration?** Join our [Telegram Builders Group](https://t.me/+5FAwyiKOTeswNTIy)