An ENS name is a useful human-readable reference, but its current holder and resolved address can change. An application that treats the name string as a permanent person identifier can accidentally transfer old reputation, permissions, or payment expectations to a new holder. Expiry makes that continuity problem especially visible.
TL;DR: Store authenticated account identity separately from a display name, preserve the address used for historical actions, and re-resolve names in the correct chain context before new actions. Track registration lifecycle without assuming that expiry instantly stops resolution. A newly registered familiar name should not inherit a previous holder's application history merely because the spelling is unchanged.
Case file one: the old collaborator's name still looks familiar
A fictional project workspace, Fieldbook, has a collaborator displayed as orchard.eth. The collaborator originally authenticated with account A, earned a history of accepted work, and received payments to an address resolved from the name at the time. Months later, the name's registration lapses and another person eventually registers it.
The new holder configures the same name to resolve to account B. A teammate opens an old project page and sees orchard.eth beside the previous contributor's work. If the page looks up the current name resolution and replaces the historical address with B, it has silently reassigned the past work to someone else.
The mistake is not in ENS resolving the name to its current configuration. The mistake is in the application's identity model. A current mapping answers where the name points now. It does not establish who performed a historical action or who should inherit permissions granted to a different authenticated account.
Fieldbook therefore gives each application account a durable internal identity and records the authenticated address or account relationship that supports it. ENS names are associated display records with observation times and verification context. They improve readability without becoming the sole key that owns work history.
The historical project page can show the name observed at the time alongside the original account identity. If the name later changes hands, the application can explain that the historical label differs from current resolution. This preserves useful context without rewriting the past or implying that a former holder still controls the name.
A name-based URL also needs an explicit policy. Does a route point to the current holder of a name or to a particular historical account? Both behaviors can be legitimate, but they should not be mixed. A durable profile URL should not silently redirect to a new person simply because a reusable display label changed ownership.
Case file two: expiry is a lifecycle, not one universal switch
For the .eth registration lifecycle described by ENS's current support documentation, expiry is followed by a ninety-day grace period during which renewal remains possible and another person cannot register the name. The documentation says resolution can continue during that period. This means expired is not equivalent to unresolved or already reassigned. ENS grace-period guidance
If the name is not renewed before the grace period ends, it becomes available for a new registration with a temporary premium that declines over twenty-one days. Someone can register during that premium period; it is not an additional exclusive reservation for the former holder. The lifecycle details here are checked against ENS documentation as of October 22, 2026. ENS temporary-premium guidance
Fieldbook displays the lifecycle status separately from current resolution. A name may still resolve while its registration is in a state requiring attention. Conversely, a valid registration does not guarantee that an address record is configured correctly. Combining both into a single green check would conceal different facts.
The application does not apply the .eth timing rules blindly to every ENS-compatible name. Imported DNS names, subnames, and other registration arrangements can have different control and lifecycle mechanisms. The name's actual registry and management structure determine which status checks are appropriate.
The product's renewal reminder is similarly scoped. It can tell a user that a particular registration is approaching expiry, but it should not promise that receiving a reminder guarantees continued control. Delivery failures, changed contact settings, and delayed action remain possible. The application should make the underlying expiry information accessible rather than hiding it behind a notification service.
For the identity model, the critical transition is not only the expiry timestamp. It is a change in the relationship among the name, its control, its records, and the authenticated account the application previously knew. Expiry is one reason that relationship may change, but an ordinary transfer or record update can create a similar continuity question.
The identity table stores relationships with time
Fieldbook's account record contains an internal account identifier and its verified authentication relationships. A separate name-observation record contains the normalized name, resolved address, relevant chain or address type, observation time, and evidence context. A third record captures the address actually used for a payment or other historical action.
This separation answers three different questions: who is signed in, what name currently represents an address, and where a particular past action went. A single name column cannot reliably answer all three. The database structure should preserve the distinctions that the user interface needs to communicate.
Suppose account A changes its primary name from orchard.eth to orchardstudio.eth without changing the authenticated account. Fieldbook should preserve its work history and permissions because the underlying account relationship is continuous. The display name can update without creating a new application identity.
Now suppose orchard.eth begins resolving to B while A remains authenticated. Fieldbook should not move A's permissions to B. It can remove or qualify A's current display association with the old name and allow B to establish its own account relationship. The shared spelling is not evidence that A authorized a transfer of application rights.
A user may intentionally migrate to a new wallet. That requires an account-linking or recovery process appropriate to the application, with evidence connecting the old and new account relationships. Name control alone should not automatically satisfy that process unless the application has explicitly designed its authorization model around transferable name ownership and communicated the consequences.
This last exception matters. Some applications deliberately make a resource belong to whoever currently controls a name. That is a different product contract from a personal account. The interface should say so clearly, and historical contributions should still preserve their actual authorship and action records.
Case file three: reverse resolution needs a return trip
An address can have a reverse record naming a preferred ENS label. Applications should verify that the returned name resolves forward to the same address in the relevant chain context before displaying it as a primary name. ENS documentation explicitly describes this bidirectional verification and recommends falling back to the address when it fails. ENS primary-name documentation
Fieldbook treats a reverse result as a candidate display label until that check succeeds. It does not assign the label first and verify later in the background while the user is making a consequential decision. A stale or mismatched reverse record can otherwise make an address appear associated with a name it no longer controls through the expected relationship.
The check is contextual. A name can have different address records for different chains or address types. A forward match for one context is not automatically a match for another. The application needs to know which address relationship it is presenting, particularly when its users operate across several networks.
The verification result is still a current naming relationship, not proof of a person's real-world identity or continuity with every previous holder. A newly registered name can correctly forward-resolve to B and have a matching reverse record. That establishes the current relationship while leaving the historical identity question unchanged.
The user interface can communicate this without overwhelming users. It can show the verified name together with an address preview and provide details on demand. For established contacts, it can flag that the current resolved address differs from the one previously saved. The useful warning concerns a concrete change, not a vague suggestion that all names are untrustworthy.
A cache should retain the verification context and age. Caching only the reverse name while discarding the forward check can produce a label that appears verified long after the relationship changed. The application should refresh according to its workflow and invalidate observations when relevant account or network context changes.
Case file four: a payment draft outlives its resolution
A teammate creates a payment draft to orchard.eth while it resolves to A. The draft remains open for several days. Before submission, the name resolves to B. Should the application send to the old address or the new one? There is no universal answer independent of the user's intent, but silently choosing either can be wrong.
Fieldbook distinguishes a draft addressed to a saved contact from a draft addressed to a live name. For a saved contact, the application can preserve the previously verified address relationship and ask the user to review a detected change. For a live name, it can resolve again at confirmation and clearly show the current destination before authorization.
The confirmation record includes the name entered, the address actually selected, the network context, and the time of resolution. The transaction history then records the executed destination. It does not later replace that address with whatever the name resolves to when someone opens the history page.
A changed destination should invalidate an earlier confirmation. If the user reviewed A, the interface should not submit B merely because a background refresh completed between review and signing. The application needs a coherent binding between the destination displayed for authorization and the destination encoded in the transaction.
The opposite race is possible too. A slow response for an earlier name or chain can arrive after the user edits the recipient. The application must match responses to the current input and context rather than showing whichever request returned last. This is an ordinary asynchronous interface problem with an unusually consequential output.
The resolution failure states should also be distinct. No configured address, unsupported address type, temporary provider failure, and a changed record are different conditions. Reusing a cached address for every failure may conceal a stale destination; replacing every failure with a blank field may obscure useful historical context. The product should state what is known and require a fresh supported resolution when its transaction policy calls for one.
Case file five: sign-in proves an account relationship
Sign-In with Ethereum defines an authentication message and verification process for establishing sessions with Ethereum accounts. The relying application checks the signature and message context, including fields that bind the request to its intended scope. ENS information can enrich the account's presentation after authentication, but a readable name is not a substitute for that verification. ERC-4361
Fieldbook's session is associated with the authenticated account relationship, not with a string returned by a naming lookup. If orchard.eth changes its address record during the session, the application does not silently change the session's owner. It can update the display association or require additional checks for name-dependent features without transferring unrelated permissions.
A feature explicitly authorized by current name ownership may need a different freshness rule. For example, an application might allow the current controller of a project name to edit that name's public landing page. In that case, the authorization check should inspect the relevant current control relationship at the point of action, rather than relying on a name seen during an old login.
The distinction between authentication and authorization is practical here. Authentication establishes the account acting in the session. Authorization determines whether that account may perform a specific operation under the application's rules. ENS resolution can be relevant evidence for some rules, but it should not become an accidental shortcut for every permission in the system.
A name transfer should therefore have predictable effects. It might transfer access to a deliberately name-owned resource while leaving personal messages, billing history, and authored work with the original account. The product should define those boundaries before users trade or lose names, not discover them after a new holder appears.
Case file six: subnames inherit a different continuity problem
A project issues alice.project.eth to a contributor. The contributor may reasonably treat it as an identity label, but its control can depend on the parent name, registrar, wrapper configuration, or issuance arrangement. The application should inspect the actual mechanism rather than assuming that every subname behaves like an independently registered second-level .eth name.
For Fieldbook, the subname is an affiliation claim whose issuer and control model are recorded separately from the user's account identity. If the project changes ownership or revokes an assignment where its system permits that, the user's historical work should not disappear. The current affiliation and the history of authorship are different records.
This model also handles organizational renaming. A contributor can move from one project namespace to another while keeping the same authenticated account and history. The interface may show the former affiliation on old contributions and the current affiliation on the profile, with dates that explain the transition.
The application should avoid inferring permanence from a visually long or specific name. A subname can look more personal than a short .eth name while depending on another party's continued control. The relevant evidence is the issuance and control arrangement, not the apparent uniqueness of the spelling.
ENS's registrar documentation describes the .eth registration architecture, providing a starting point for distinguishing registrar-controlled names from other namespace arrangements. Integrators should use the documentation and deployed contracts appropriate to the name they support. ENS ETH registrar documentation
Normalization preserves the intended name before resolution
Users can enter names with Unicode characters and different textual forms. ENS name processing uses a specified normalization process before name hashing and resolution. An application should use a maintained implementation of the relevant ENS rules rather than inventing a lowercasing or character-removal shortcut. ENS name-processing documentation
Fieldbook retains the normalized form used for resolution and presents the name clearly during confirmation. It does not silently transform an unsupported input into a different valid name. If the input cannot be normalized under the supported rules, the user should receive a precise correction opportunity rather than an unexpected destination.
Normalization does not establish identity continuity. Two observations of the same normalized string can refer to different holders at different times. It solves the question of which name is being queried, while the account and lifecycle model solves the question of what relationship that name currently represents.
The application also avoids merging accounts because their displayed labels look similar. Search results can show names and address context without treating visual similarity as equivalence. A user selecting a familiar contact should be able to distinguish the saved account from a newly encountered name with similar appearance.
The migration test changes the name holder while preserving history
Fieldbook's test fixture begins with orchard.eth associated with A. A creates a project, receives a permission, and records a payment destination. The fixture then changes the name relationship to B. The expected result is that A retains the project history and account-specific permission, while new live-name resolution produces B where the workflow explicitly requests it.
A second fixture changes only A's display name. The application should update presentation without duplicating the account or losing saved relationships. A third fixture leaves a stale reverse record that no longer forward-resolves to A. The display should fall back appropriately while preserving A's authenticated identity.
A fourth fixture places the name in grace period while resolution still succeeds. The application should show the lifecycle warning without falsely claiming the name is already available to another registrant. A fifth fixture models a new registration after release and verifies that historical reputation does not transfer automatically.
The payment test holds a draft open while the resolved address changes. It checks that the final authorization binds to the address the user actually reviewed. The history test then changes the name again and verifies that the executed payment destination remains unchanged in the record.
These tests are valuable because they encode the product's intended continuity rules. A successful resolution call is only one step in the workflow. The application must also preserve the meaning of identity, history, and authorization as names evolve.
The useful promise is readable identity with explicit continuity
ENS can make applications substantially easier to use by replacing opaque addresses with meaningful names. That benefit is strongest when the application also preserves the underlying account and action context. A readable label should help users recognize a relationship without silently becoming proof that the relationship has never changed.
Fieldbook's final design treats names as current, contextual associations and historical labels as recorded observations. It refreshes resolution for new actions, verifies primary names bidirectionally, and keeps authentication and permissions attached to their intended subjects. A familiar name can change hands without carrying someone else's past along with it.