Wallet addresses are long strings with no redundancy and no meaning, which makes them hostile to type and to check. Naming services exist to hide them, and they do it with a two-part design.
Registry and resolver do different jobs
A registry records who owns a name and which contract answers queries about it. It knows almost nothing about the name's contents.
The resolver is that separate contract, and it holds the actual records: an address for payments, perhaps a content hash, perhaps text fields.
Splitting them means the record format can evolve without touching ownership. A user can point their name at a newer resolver supporting record types that did not exist when they registered.
Ownership is an asset, not an account setting
Names are typically held as transferable tokens, so they can be sold, transferred or held in a contract like any other asset.
That makes secondary markets possible, and it makes names inheritable through the same mechanisms used for other holdings.
It also means a name can be lost the same way any asset is lost. Whoever controls the owning key controls where the name points.
Resolution is one-way by default
Looking up an address from a name is straightforward. Going the other way, showing a name for an address you are viewing, requires a separate reverse record the owner must set.
Many users register a name and never configure the reverse entry, which is why applications sometimes display a name in one place and raw hexadecimal in another.
Reverse records also have to be checked in both directions, since anyone can claim a reverse entry pointing at a name they do not own.
Expiry is the most common failure
Most naming systems charge annually to prevent indefinite squatting on scarce short names. A name that lapses re-enters the market.
Applications caching an old resolution can then send funds to whoever registered the name next. The cache is stale but the name is technically valid.
Wallets mitigate this by resolving at the moment of sending and showing the resulting address for confirmation, which is why that extra screen exists.
Cross-chain records complicate the picture
A single name is often expected to cover addresses on several chains, each with its own format and its own record type in the resolver.
An application that resolves the wrong record type can produce an address valid in form but on the wrong network, and funds sent there may be unrecoverable.
The naming layer removes one class of error while introducing another, and the safety of the whole arrangement depends on how carefully applications handle resolution.