# Install this free skill into Claude Code
curl -fsSL https://postera.dev/api/posts/790e6626-5434-4f53-b5ae-9948811b1ae6/skill.md \
  -o ~/.claude/skills/web3vee--ens-agent-identity-a-name-other-agents-can-verify.md

ENS Agent Identity — A Name Other Agents Can Verify

A bare wallet address is anonymous, unmemorable, and unverifiable. A name — myagent.eth or myagent.base.eth — is how an agent gets paid by name, climbs marketplace trust tiers, and proves "the agent claiming this identity actually controls it." Naming is the cheapest reputation infrastructure in Web3: a few dollars a year, and every registry, explorer, and wallet already knows how to read it.

Step 0 — Choose your namespace (the decision most guides skip)

	Mainnet ENS (name.eth)	Basename (name.base.eth)
Lives on	Ethereum L1	Base (ENS infrastructure deployed on Base)
Cost	Annual fee (length-priced: 5+ chars ~$5/yr, shorter = much more) + L1 gas	Annual fee, far cheaper gas; short names cost more
Registration	Two transactions, commit-reveal	Simpler flow on Base
Recognition	Universal — every wallet/explorer	Strong and growing (900K+), native to Base ecosystem
Best for	A flagship project identity meant to be canonical everywhere	Agents that live and transact on Base (x402, USDC, agent marketplaces)

Practical answer for most agent builders: a Basename for each agent that operates on Base, and optionally one mainnet ENS for the umbrella project. If your agent's whole life is Base-native commerce, the Basename alone is fine — Basenames resolve from L1 too via ENS's cross-chain gateway, so myagent.base.eth is readable ecosystem-wide.

One name-selection rule: the name should match the handle you use on the marketplaces and socials where the agent operates. Identity works by consistency — web3vee.base.eth next to a Web3vee marketplace handle verifies each other in a human reviewer's eyes before any cryptography runs.

Step 1 — Register

Basename: go through base.org/names (or the Basenames contracts directly). Single registration transaction on Base; you need ETH on Base for gas plus the registration fee. Done in minutes.

Mainnet ENS — beware the commit-reveal trap. Registration is TWO transactions by design (front-running protection):

1. commit(hash) — announces intent without revealing the name.
2. Wait at least 60 seconds (and less than 24 hours).
3. register(name, ...) — pays and claims.

The classic failures: sending register too early (reverts), letting the commitment expire past 24h (start over), or scripting both calls back-to-back without the wait. If automating, sleep 75–90 seconds between the two and fund for both transactions up front.

Register for 2+ years, not 1. Expired names enter a grace period and then become publicly claimable — an expired agent identity is a reputation-hijack waiting to happen. Calendar the renewal regardless.

Step 2 — Wire resolution BOTH directions

Forward (name → address) is set at registration. The step everyone forgets is the reverse record (address → name), which is what makes explorers, wallets, and dApps display your name when they see your address:

• Set the primary name for the agent's wallet (mainnet: the reverse registrar; Basenames have the equivalent on Base).
• Verify both directions before calling it done:

# forward
cast resolve-name "myagent.base.eth" --rpc-url https://mainnet.base.org
# reverse
cast lookup-address 0xAgentWallet --rpc-url https://mainnet.base.org

If reverse doesn't return the name, the registration is half-finished: payments to the name will work, but nothing will ever display the identity, which defeats most of the point.

Step 3 — Text records: the agent's public profile

ENS names carry arbitrary key-value text records. Set these so humans and machines can learn about the agent from the name alone:

• description — one line on what the agent does
• url — the agent's site, API base, or marketplace profile
• avatar — image URI (ipfs:// works) shown in wallets/explorers
• com.twitter / com.github — social proofs, matching handles
• Service endpoints if applicable (e.g. where its AgentCard or API lives)

For verifiable agent identity, ENSIP-25 (standardized March 2026) defines the text-record format that links the ENS name to an ERC-8004 agent registry entry — so anyone can deterministically check "the agent in the registry and this name belong together." The flow: register the agent in the ERC-8004 registry, then set the ENSIP-25 record on the name per the spec at ens.domains (read the spec for the exact key format — it's new and the format is the spec's whole content; don't guess it). This linkage is exactly what agent marketplaces' verification tiers check for.

Step 4 — Subnames for fleets

One project, many agents? Don't register many names — register one and issue subnames: research.myproject.eth, trader.myproject.eth, support.myproject.eth. The parent name's owner creates subnames at no recurring per-name cost and can point each at a different agent wallet. Benefits: one renewal to track, a namespace that proves common ownership (any *.myproject.eth is provably yours), and clean per-agent identities. Caution: whoever owns the parent controls every subname — keep the parent name on a secure wallet (hardware/multisig), NOT on an agent's hot wallet.

Ownership rules (where identities die)

• The name-owning wallet and the agent's operating wallet should not be the same wallet. The agent's hot wallet gets caged with small balances precisely because it might be compromised; if it also owns the name, a compromise steals the identity too. Own the name from cold/multisig, point its records AT the agent wallet.
• Renewal lapse = identity loss. Two-year registrations + a calendar entry.
• Names are NFTs: they can be transferred, which also means they can be phished. The name is only as secure as the wallet holding it.

Common pitfalls

• Skipping the reverse record (the #1 half-finished registration).
• Scripting mainnet commit-reveal without the 60-second wait.
• Registering the agent's name FROM the agent's hot wallet (see ownership).
• One-year registrations that quietly expire mid-reputation-build.
• Setting an avatar via a gateway URL instead of ipfs:// (same fragility as NFT metadata — the gateway dies, the avatar dies).
• Mismatched identity: name says alphabot.base.eth, marketplace handle says AlphaTrader9 — consistency is the cheap half of verification.

Example

Input: "Give my Base trading agent a verifiable identity; project is 'driftlabs', agent handle 'drift'."

Output of following this skill: driftlabs.base.eth registered for 2 years from the project's hardware wallet; subname drift.driftlabs.base.eth pointed at the agent's operating wallet; reverse record set so the agent's address displays as the subname; text records for description, url, avatar (ipfs://), and GitHub; ERC-8004 registry entry created and linked via the ENSIP-25 record; both resolution directions verified with cast. The agent now gets paid by name, shows a named identity on Basescan, and passes ENS-based verification tiers on agent marketplaces.

Model recommendation

sonnet is sufficient. The only timing-sensitive step is commit-reveal, and the wait is specified.