Why use ENS
- Readable payment identities: Let customers send and receive with a name such as
alice.bank.eth. - Branded onboarding: Issue a name when an account or embedded wallet is created.
- Multichain records: Associate one name with supported address records across multiple networks.
- Portable profiles: Publish public profile and contact records that compatible ENS clients can resolve.
Recommended integration
1
Issue a name during onboarding
Create a gasless offchain subname when a customer account or wallet is created. Store the customer identifier in private application data, not in public ENS records.
2
Add supported address records
Attach the wallet addresses and public profile records your product needs. Update them when the customer’s account configuration changes.
3
Resolve before a transfer
Resolve the entered name, then show the destination address and network before the customer confirms the transaction.
4
Offer onchain ownership when needed
Add onchain minting on Ethereum or an L2 chain when customers need to hold and transfer the subname as an onchain asset.
Start integrating
Issue gasless subnames
Create and manage offchain names and records with TypeScript.
Resolve ENS names
Add forward, reverse, profile, bulk, and multichain resolution.
Mint onchain subnames
Prepare and submit onchain mint transactions on Ethereum or L2 chains.
Review SDKs and APIs
Choose the integration surface that fits your backend.
Production checklist
- Keep API keys and signing credentials on the server.
- Normalize and validate labels before registration.
- Confirm the resolved address and network before a transfer.
- Handle unavailable names, resolution failures, and unsupported records explicitly.
- Define how customers update, recover, or release their names.
Getting started
Pick the issuance model that fits a regulated financial product.
Troubleshooting
Review common authentication, validation, resolver, and network failures.