Skip to main content
Give each customer a readable ENS name they can recognize and share instead of relying only on wallet addresses. Subnames can support branded onboarding, customer profiles, and username-based payments in compatible wallets and apps.

​
Addresses break payment products

  1. Nobody knows who 0x71C7…F2a9 is. Addresses are unreadable and impossible to confirm at a glance — the highest-friction input in consumer finance.
  2. Wrong-address transfers are irreversible. Address poisoning targets payment behavior; tracked attempts rose from ~628,000 in November 2025 to 3.4 million in January 2026, with one user losing close to 50 million USDT. You can only prevent it, by making the destination human-readable before the user signs.
  3. Siloed usernames. Cash App usernames work in Cash App, Revolut usernames work in Revolut, etc. but none interoperate. The moment your user wants to pay someone outside your app, they’re back to copying and pasting a raw address.
  4. Your brand is invisible, but it shouldn’t be. Every external transfer shows an anonymous string. A name like alice.yourbank.id puts your brand in the other side’s app, in explorers, and in transaction history — distribution you don’t pay for.

​
Why ENS usernames

Claim at signup

alice.yourapp.eth, issued automatically with the account. No transaction, no gas, no extra step for the user to understand.

Send by name

The user types a name. Your app resolves it, displays the avatar and profile, and only then enables the confirm button.

Request and payment links

Share a name instead of an address. It fits in a message, a bio, an invoice, or a QR code, and it does not change when the user rotates wallets.

One name, every chain, 1,000+ apps

Store address records per chain under the same name. The sender picks a person, your app picks the rail.

Interoperable by default

Because these are ENS names, someone in a different wallet can pay your user without your app being involved at all.

Secured and verified

Resolution is verified onchain through ENS, so the name your user pays is provably the account it belongs to. Lookalike addresses and spoofed handles are attack surface.
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.