ENS research: verify resolved addresses at the observation time
An ENS name is a dynamic resolution path, not a permanent certificate of who controls an address. A name that resolves to one address today may have resolved elsewhere at the time of an older transaction. Research should preserve the historical resolution evidence before attaching one identity label to years of activity.
The ENS resolution documentation distinguishes the registry, resolver and queried records, and instructs clients to verify reverse names through forward resolution. The workflow below applies those mechanics to dated research labels. It does not establish the real-world legal identity of the registrant or address controller.
Record the full lookup question
Save the exact normalized name, network, target record type, observation block and retrieval time. A cryptocurrency address record, text record and content hash are different queries. Do not infer an address for every chain from one returned address record.
Identify the resolver selected for the name at that observation point, then obtain the relevant record under the resolver’s supported method. Save raw returned values and any required offchain resolution dependencies. A current lookup attached to an old transaction date is still current evidence, not a historical lookup.
Keep registration ownership, resolver configuration, record destination and transaction signing authority in separate fields. They can be different roles. A text record claiming a company affiliation is a published claim requiring its own corroboration, not independent proof that the company controls every named address.
Hypothetical reassigned destination
Assume a fictional name resolves to address A at block 1,000 and to address B at block 2,000. A researcher at block 2,100 uses the current result B to label all transactions mentioning the name since block 500.
| Observation point | Assumed forward record | Supported label |
|---|---|---|
| Block 1,000 | Address A | Name resolved to A at that point |
| Block 2,000 | Address B | Name resolved to B at that point |
| Block 2,100 | Address B | Current result, not proof of older mapping |
The current lookup cannot establish that B was the destination at block 1,000. Nor do observations at only two endpoints identify the exact transition block. The mapping could have changed several times between them. Retain bounded observations unless complete update history and applicable resolution rules support an interval.
Now suppose address C advertises the fictional name through reverse resolution, but the name’s forward record points to B. Reverse text alone does not establish a matching primary name for C. Preserve the mismatch and display the address rather than promoting the unverified reverse association into an identity label.
All names, addresses and blocks in this example are hypothetical. No real registrant or transaction is being identified.
Preserve historical limits
For ordinary onchain records, historical state or a complete applicable change history may support reconstruction. Offchain resolvers, wildcard rules and external dependencies can require additional evidence. A failed historical query should remain unavailable, not be replaced silently by the current value.
When recording a name-to-address interval, note the evidence establishing both endpoints and the scope of the claim. Registration renewal, transfer, expiry or resolver changes can be review triggers, but do not assume every such event necessarily changes the destination. Inspect the actual record path.
For address-flow analysis, use the address as the stable transaction identifier and attach the name as dated metadata. If the label changes, preserve the underlying transactions and revise only the relevant association. This prevents a familiar name from merging unrelated address histories without evidence.
The final result should say which name resolved to which record, on which network and at which verified point. It cannot prove beneficial ownership, control of private keys or continuity of a real-world person. Recheck after resolution changes, reverse-forward mismatches or missing historical dependencies.
A resolver’s retrieval time can differ from the time represented by an offchain response. Preserve any available validity interval and response provenance instead of treating a successful network request as historical coverage. If those fields cannot establish the earlier state, restrict the association to the actual observation. The absence of historical resolution is a data limitation, not evidence that the name lacked a record.
FAQ
Does a reverse ENS name prove an address’s identity?
No. Verify the corresponding forward record and keep real-world identity claims separate from technical resolution.
Can today’s ENS lookup label historical transfers?
Only as explicitly current metadata. A historical identity assertion requires evidence for the resolution state at the relevant time.